From bmanning@ISI.EDU Thu Jun 20 15:10:10 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 29 Jun 100 18:25:34 -0700 (PDT) Subject: Is there any way at all to get off this list In-Reply-To: <200006292034.PAA09932@CREATURE.telecom.ou.edu> from "Stan J creature's user" at Jun 29, 0 03:34:06 pm Message-ID: <200006300125.SAA14185@boreas.isi.edu> % % % Does anyone know how to unscubscribe from the 6bone list? Please help. % % stan@creature.telecom.ou.edu % send a note to: majordomo@isi.edu with the text in the body of: unsubscribe 6bone -- --bill From bmanning@ISI.EDU Thu Jun 20 15:10:10 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 12 Jul 100 08:04:22 -0700 (PDT) Subject: 6Bone registry web interface In-Reply-To: from "Peter Bunclark" at Jul 11, 0 08:29:50 am Message-ID: <200007121504.IAA00472@boreas.isi.edu> % % % % On Mon, 10 Jul 2000, Bob Fink wrote: % % > At 11:33 PM 7/10/2000 -0400, Florent Parent wrote: % > > % > >You can now use the web interface to create/update/delete your 6Bone % > >registry objects. Available at % > >http://www.viagenie.qc.ca/en/ipv6/registry/index.shtml % > % > % > Excellent - this is a great improvement! Thanks to the Viagenie staff for % > doing this. Thanks to David Kessens for helping. % % Now if someone could only find a way of weeding out all the dead % entries... I've often thought, a good addition to the html-generator % would be to ping all the ``application ping 3ffe:...'' entries and % highlight them in red if they don't ping! % % Pete. One way might be to see if the servers for the delegation(s) are answering and authoritative. --bill From fink@es.net Tue Jun 4 04:36:01 2002 From: fink@es.net (Bob Fink) Date: Mon, 03 Jun 2002 20:36:01 -0700 Subject: [6bone] pTLA request INET-TH - review closes 17 June 2002 Message-ID: <5.1.0.14.0.20020603203034.025ce748@imap2.es.net> 6bone Folk, INET-TH has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 17 June 2002. Please send your comments to me or the list. Thanks, Bob === >Date: Mon, 3 Jun 2002 09:11:28 +0700 (GMT+0700) >From: Sanan Kurkulsatsanakit >To: >cc: >Subject: pTLA prefix request > >Hi Bob, > >This is a pTLA prefix request from Internet Thailand Public Company >Limited. Please review and notify us for any update. > >Many thanks, >Sanan > > >================================================================================ > 1. The pTLA Applicant must have a minimum of three (3) months > qualifying experience as a 6Bone end-site or pNLA transit. During > the entire qualifying period the Applicant must be operationally > providing the following: > > a. Fully maintained, up to date, 6Bone Registry entries for their > ipv6-site inet6num, mntner, and person objects, including each > tunnel that the Applicant has. >-------------------------------------------------------------------------------- >We have 3 delegated 6bone prefix (/48) as following: >- 3FFE:B80:61F::/48 from FREENET6 >- 3FFE:B00:4050::/48 from VIAGENIE >- 3FFE:2900:1101::/48 from SPRINT > ><<< ipv6-site >>> >% RIPEdb(3.0.0b2) with ISI RPSL extensions > >ipv6-site: INET-TH >origin: AS4618 >descr: Internet Thailand Public Company Limited >country: TH >prefix: 3FFE:B80:61F::/48 >prefix: 3FFE:B00:4050::/48 >prefix: 3FFE:2900:1101::/48 >application: ping ipv6-gw66.inet.co.th >tunnel: IPv6 in IPv4 ipv6-gw66.inet.co.th -> www.freenet6.net >VIAGENIE STATIC >tunnel: IPv6 in IPv4 ipv6-gw66.inet.co.th -> rap.viagenie.qc.ca >VIAGENIE BGP4+ >tunnel: IPv6 in IPv4 ipv6-gw66.inet.co.th -> >sl-bb1v6-sj.sprintlink.net SPRINT BGP4+ >contact: BS5-6BONE >contact: INOC1-6BONE >remarks: ipv6-site is operational since 20011225 >mnt-by: MNT-INET >changed: snakk@inet.co.th 20011227 >changed: snakk@inet.co.th 20011229 >changed: snakk@inet.co.th 20020117 >changed: snakk@inet.co.th 20020129 >source: 6BONE > ><<< inet6num >>> >inet6num: 3FFE:B80:61F::/48 >netname: INET-TH >descr: Internet Thailand Public Company Limited >country: TH >admin-c: BS5-6BONE >tech-c: INOC1-6BONE >notify: noc@inet.co.th >mnt-by: MNT-INET >changed: snakk@inet.co.th 20011225 >changed: snakk@inet.co.th 20011227 >source: 6BONE > >inet6num: 3FFE:B00:4050::/48 >netname: INET-TH >descr: Internet Thailand Public Company Limited >country: TH >admin-c: BS5-6BONE >tech-c: INOC1-6BONE >notify: ipv6@inet.co.th >mnt-by: MNT-INET >changed: snakk@inet.co.th 20020529 >source: 6BONE > >inet6num: 3FFE:2900:1101::/48 >netname: INET-TH >descr: Internet Thailand Public Company Limited >country: TH >admin-c: BS5-6BONE >tech-c: INOC1-6BONE >notify: ipv6@inet.co.th >mnt-by: MNT-INET >changed: snakk@inet.co.th 20020529 >source: 6BONE > > ><<< mntner >>> >% RIPEdb(3.0.0b2) with ISI RPSL extensions > >mntner: MNT-INET >descr: Maintainer of INET-TH 6bone objects >admin-c: BS16-AP >tech-c: CN2-TH >tech-c: SK13-AP >tech-c: SK26-TH >upd-to: noc@inet.co.th >auth: CRYPT-PW * >auth: CRYPT-PW * >remarks: This object is automatically converted from the RIPE181 >registry >mnt-by: MNT-INET >changed: snakk@inet.co.th 20010107 >changed: snakk@inet.co.th 20010108 >changed: auto-dbm@whois.6bone.net 20010117 >source: 6BONE > ><<< person >>> >% RIPEdb(3.0.0b2) with ISI RPSL extensions > >role: INET-TH Network Operation Center >address: Internet Thailand Public Company Limited >address: 108 Bangkok Thai Tower Bldg., 12 Fl., >address: Rangnam Rd., Rajdhevee, >address: Bangkok 10400, Thailand >phone: +66-2640-0345 >fax-no: +66-2640-0456 >e-mail: noc@inet.co.th >admin-c: BS5-6BONE >tech-c: SK2-6BONE >nic-hdl: INOC1-6BONE >remarks: This object is automatically converted from the RIPE181 >registry >notify: noc@inet.co.th >mnt-by: MNT-INET >changed: snakk@inet.co.th 20010108 >changed: auto-dbm@whois.6bone.net 20010117 >changed: snakk@inet.co.th 20011225 >source: 6BONE > >person: Buncha Srisamanuwat >address: Internet Thailand Public Company Limited >address: 108 Bangkok Thai Tower Bldg., 12 Fl., >address: Rangnam Rd., Rajdhevee, >address: Bangkok 10400, Thailand >phone: +66-2640-0345 >fax-no: +66-2640-0456 >e-mail: athicha@inet.co.th >nic-hdl: BS5-6BONE >remarks: This object is automatically converted from the RIPE181 >registry >notify: athicha@inet.co.th >mnt-by: MNT-INET >changed: snakk@inet.co.th 20010108 >changed: auto-dbm@whois.6bone.net 20010117 >changed: snakk@inet.co.th 20011225 >source: 6BONE > >person: Sanan Kurkulsatsanakit >address: Internet Thailand Public Company Limited >address: 108 Bangkok Thai Tower Bldg., 12 Fl., >address: Rangnam Rd., Rajdhevee, >address: Bangkok 10400, Thailand >phone: +66-2640-0345 >fax-no: +66-2640-0456 >e-mail: snakk@inet.co.th >nic-hdl: SK2-6BONE >remarks: This object is automatically converted from the RIPE181 >registry >notify: snakk@inet.co.th >mnt-by: MNT-INET >changed: snakk@inet.co.th 20010108 >changed: auto-dbm@whois.6bone.net 20010117 >changed: snakk@inet.co.th 20011225 >source: 6BONE > >person: Chakrit Noisuwan >address: Internet Thailand Public Company Limited >address: 108 Bangkok Thai Tower Bldg., 12 Fl., >address: Rangnam Rd., Rajdhevee, >address: Bangkok 10400, Thailand >phone: +66-2640-0345 >fax-no: +66-2640-0456 >e-mail: chakrit@inet.co.th >nic-hdl: CN2-6BONE >notify: chakrit@inet.co.th >mnt-by: MNT-INET >changed: snakk@inet.co.th 20011225 >changed: snakk@inet.co.th 20011225 >source: 6BONE > >person: Nattapong Jatupongpairoj >address: Internet Thailand Public Company Limited >address: 108 Bangkok Thai Tower Bldg., 12th Fl., >address: Rangnam Rd., Rajdhevee, >address: Bangkok 10400, Thailand >phone: +66-2640-0345 >fax-no: +66-2257-7275 >e-mail: jnatta@inet.co.th >nic-hdl: NJ2-6BONE >notify: jnatta@inet.co.th >mnt-by: MNT-INET >changed: snakk@inet.co.th 20020521 >source: 6BONE > >person: Prasong Sakulwongwattana >address: Internet Thailand Public Company Limited >address: 108 Bangkok Thai Tower Bldg., 12th Fl., >address: Rangnam Rd., Rajdhevee, >address: Bangkok 10400, Thailand >phone: +66-2640-0345 >fax-no: +66-2257-7275 >e-mail: psongs@inet.co.th >nic-hdl: PS9-6BONE >notify: psongs@inet.co.th >mnt-by: MNT-INET >changed: snakk@inet.co.th 20020521 >source: 6BONE > >person: Karaked Kedchumpol >address: Internet Thailand Public Company Limited >address: 108 Bangkok Thai Tower Bldg., 12th Fl., >address: Rangnam Rd., Rajdhevee, >address: Bangkok 10400, Thailand >phone: +66-2640-0345 >fax-no: +66-2257-7275 >e-mail: karaked@inet.co.th >nic-hdl: KK13-6BONE >notify: karaked@inet.co.th >mnt-by: MNT-INET >changed: snakk@inet.co.th 20020521 >source: 6BONE > >-------------------------------------------------------------------------------- > b. Fully maintained, and reliable, BGP4+ peering and connectivity > between the Applicant's boundary router and the appropriate > connection point into the 6Bone. This router must be IPv6 > pingable. This criteria is judged by members of the 6Bone > Operations Group at the time of the Applicant's pTLA request. >-------------------------------------------------------------------------------- >We have 2 BGP perring with SPRINT and VIAGENIE > >IPv6-Router#show ipv6 interface brief >Ethernet0 [up/up] > 3FFE:2900:1101:0:2B0:64FF:FEFC:E2E1 >Loopback0 [up/up] > unassigned >Tunnel11 [up/up] <--- SPRINT > 3FFE:2900:1100:1::2 >Tunnel99 [up/up] <--- VIAGENIE > 3FFE:B00:C18::99 > >IPv6-Router#show ip interface brief >Interface IP-Address OK? Method Status >Prot >ocol >Ethernet0 203.150.14.66 YES NVRAM up >up > >Loopback0 203.150.16.66 YES NVRAM up >up > >Tunnel11 unassigned YES NVRAM up >up <--- SPRINT > >Tunnel99 unassigned YES NVRAM up >up <--- VIAGENIE > >IPv6-Router#show bgp ipv6 summary >BGP router identifier 203.150.16.66, local AS number 4618 >BGP table version is 265470, main routing table version 265470 >225 network entries and 427 paths using 58061 bytes of memory >359 BGP path attribute entries using 21540 bytes of memory >348 BGP AS-PATH entries using 9812 bytes of memory >9 BGP community entries using 216 bytes of memory >0 BGP route-map cache entries using 0 bytes of memory >180 BGP filter-list cache entries using 2160 bytes of memory >213 received paths for inbound soft reconfiguration >BGP activity 56658/276904 prefixes, 219207/218780 paths, scan interval 15 >secs > >Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down >State/PfxRcd >3FFE:B00:C18::98 > 4 10566 746846 346002 265470 0 0 13:33:53 >0 <--- VIAGENIE >3FFE:2900:1100:1::1 > 4 6175 352396 171730 265470 0 0 1d02h >212 <--- SPRINT > >-------------------------------------------------------------------------------- > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > entries for the Applicant's router(s) and at least one host > system. >-------------------------------------------------------------------------------- >The main DNS server is "rns1.v6.inet.co.th". >Our formal forward domain name for IPv6 is "v6.inet.co.th". >And we have DNS reverse (ip6.int) delegation from SPRINT >(3ffe:2900:1101::/48) only. > ># nslookup -type=soa v6.inet.co.th >v6.inet.co.th > origin = rns1.v6.inet.co.th > mail addr = hostmaster.inet.co.th > serial = 2002052803 > refresh = 21600 (6H) > retry = 7200 (2H) > expire = 604800 (1W) > minimum ttl = 43200 (12H) >v6.inet.co.th nameserver = rns1.v6.inet.co.th >rns1.v6.inet.co.th internet address = 203.150.14.111 >rns1.v6.inet.co.th IPv6 address = 3ffe:2900:1101:0:210:64ff:fe30:7cb9 > ># nslookup > > ls -d v6.inet.co.th >$ORIGIN v6.inet.co.th. >@ 12H IN SOA rns1 hostmaster.inet.co.th. ( > 2002052803 ; serial > 6H ; refresh > 2H ; retry > 1W ; expiry > 12H ) ; minimum > > 12H IN NS rns1 >FREENET6 12H IN AAAA 3ffe:b80:61f:: >SPRINT 12H IN AAAA 3ffe:2900:1101:: >VIAGENIE 12H IN AAAA 3ffe:b00:4050:: > >core-gw 12H IN A 203.150.14.66 > 12H IN AAAA 3ffe:2900:1101:0:2b0:64ff:fefc:e2e1 > >netcen 12H IN A 203.150.14.120 > 12H IN AAAA 3ffe:2900:1101:0:220:afff:fed3:6a4c >rns1 12H IN A 203.150.14.111 > 12H IN AAAA 3ffe:2900:1101:0:210:64ff:fe30:7cb9 >www 12H IN A 203.150.14.120 > 12H IN AAAA 3ffe:2900:1101:0:220:afff:fed3:6a4c > > ># dig -t any 1.0.1.1.0.0.9.2.e.f.f.3.ip6.int @ns1.sprintv6.net > >; <<>> DiG 8.3 <<>> -t 1.0.1.1.0.0.9.2.e.f.f.3.ip6.int @ns1.sprintv6.net >; (1 server found) >;; res options: init recurs defnam dnsrch >;; got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 >;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2 >;; QUERY SECTION: >;; 1.0.1.1.0.0.9.2.e.f.f.3.ip6.int, type = ANY, class = IN > >;; ANSWER SECTION: >1.0.1.1.0.0.9.2.e.f.f.3.ip6.int. 4H IN NS rns1.v6.inet.co.th. > >;; AUTHORITY SECTION: >9.2.e.f.f.3.ip6.int. 4H IN NS ns1.sprintv6.net. > >;; ADDITIONAL SECTION: >ns1.sprintv6.net. 4H IN A 63.167.40.5 >ns1.sprintv6.net. 4H IN AAAA 2001:440:1239:1001::2 > > >-------------------------------------------------------------------------------- > d. A fully maintained, and reliable, IPv6-accessible system > providing, at a mimimum, one or more web pages, describing the > Applicant's IPv6 services. This server must be IPv6 pingable. >-------------------------------------------------------------------------------- >Our common webpage for IPv6 is "http://www.v6.inet.co.th". >It can be IPv6 pingable. > ># ping6 www.v6.inet.co.th >PING6(56=40+8+8 bytes) 3ffe:2900:1101:0:220:afff:fed3:6a4c --> >3ffe:2900:1101:0:220:afff:fed3:6a4c > >16 bytes from 3ffe:2900:1101:0:220:afff:fed3:6a4c, icmp_seq=0 hlim=64 >time=0.32 ms >16 bytes from 3ffe:2900:1101:0:220:afff:fed3:6a4c, icmp_seq=1 hlim=64 >time=0.19 ms >16 bytes from 3ffe:2900:1101:0:220:afff:fed3:6a4c, icmp_seq=2 hlim=64 >time=0.186 ms >16 bytes from 3ffe:2900:1101:0:220:afff:fed3:6a4c, icmp_seq=3 hlim=64 >time=0.185 ms >16 bytes from 3ffe:2900:1101:0:220:afff:fed3:6a4c, icmp_seq=4 hlim=64 >time=0.189 ms > >--- www.v6.inet.co.th ping6 statistics --- >5 packets transmitted, 5 packets received, 0% packet loss >round-trip min/avg/max = 0.185/0.214/0.320 ms > >================================================================================ > 2. The pTLA Applicant MUST have the ability and intent to provide > "production-quality" 6Bone backbone service. Applicants must > provide a statement and information in support of this claim. > This MUST include the following: > > a. A support staff of two persons minimum, three preferable, with > person attributes registered for each in the ipv6-site object > for the pTLA applicant. >-------------------------------------------------------------------------------- >person: Buncha Srisamanuwat >notify: athicha@inet.co.th > >person: Sanan Kurkulsatsanakit >notify: snakk@inet.co.th > >person: Chakrit Noisuwan >notify: chakrit@inet.co.th > >person: Nattapong Jatupongpairoj >notify: jnatta@inet.co.th > >person: Prasong Sakulwongwattana >notify: psongs@inet.co.th > >person: Karaked Kedchumpol >notify: karaked@inet.co.th > >-------------------------------------------------------------------------------- > b. A common mailbox for support contact purposes that all support > staff have acess to, pointed to with a notify attribute in the > ipv6-site object for the pTLA Applicant. >-------------------------------------------------------------------------------- >The common mailbox for IPv6 in INET-TH is "ipv6@inet.co.th" > >ipv6-site: INET-TH >contact: INOC1-6BONE > >role: INET-TH Network Operation Center >e-mail: ipv6@inet.co.th >nic-hdl: INOC1-6BONE > >================================================================================ > 3. The pTLA Applicant MUST have a potential "user community" that > would be served by its becoming a pTLA, e.g., the Applicant is a > major provider of Internet service in a region, country, or focus > of interest. Applicant must provide a statement and information in > support this claim. >-------------------------------------------------------------------------------- >INET-TH is the most market-shared ISP of corporate customers in Thailand. >We are providing Internet Access Service for both Corporate and Individual >customers. We also provide Hosting, Co-location, Internet Data Center and >E-commerce Services. We are the first ISP in Thailand that became to >public >company limited. Our coverage is overall of Thailand 76 provinces last >year. > >As a 6BONE pTLA, we have a plan of testbed with our subscribers with >policy >of not charging services. We welcome whoever want to connect us with >6BONE prefix. > >We also plan to request IPv6 address space from APNIC within this year. >Then >we will provide our commercial services in IPv6. > >================================================================================ > 4. The pTLA Applicant MUST commit to abide by the current 6Bone > operational rules and policies as they exist at time of its > application, and agree to abide by future 6Bone backbone > operational rules and policies as they evolve by consensus of the > 6Bone backbone and user community. >-------------------------------------------------------------------------------- > >INET-TH commit and agree to the current and future 6BONE operational rules >and policies. > ><<< Internet Thailand Public Company Limited >>> From fink@es.net Tue Jun 4 13:36:51 2002 From: fink@es.net (Bob Fink) Date: Tue, 04 Jun 2002 05:36:51 -0700 Subject: [6bone] pTLA request INET-TH - review closes 17 June 2002 Message-ID: <5.1.0.14.0.20020604053539.0239eff8@imap2.es.net> 6bone Folk, INET-TH has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 17 June 2002. Please send your comments to me or the list. Thanks, Bob === Date: Mon, 3 Jun 2002 09:11:28 +0700 (GMT+0700) From: Sanan Kurkulsatsanakit To: cc: Subject: pTLA prefix request Hi Bob, This is a pTLA prefix request from Internet Thailand Public Company Limited. Please review and notify us for any update. Many thanks, Sanan ================================================================================ 1. The pTLA Applicant must have a minimum of three (3) months qualifying experience as a 6Bone end-site or pNLA transit. During the entire qualifying period the Applicant must be operationally providing the following: a. Fully maintained, up to date, 6Bone Registry entries for their ipv6-site inet6num, mntner, and person objects, including each tunnel that the Applicant has. -------------------------------------------------------------------------------- We have 3 delegated 6bone prefix (/48) as following: - 3FFE:B80:61F::/48 from FREENET6 - 3FFE:B00:4050::/48 from VIAGENIE - 3FFE:2900:1101::/48 from SPRINT <<< ipv6-site >>> % RIPEdb(3.0.0b2) with ISI RPSL extensions ipv6-site: INET-TH origin: AS4618 descr: Internet Thailand Public Company Limited country: TH prefix: 3FFE:B80:61F::/48 prefix: 3FFE:B00:4050::/48 prefix: 3FFE:2900:1101::/48 application: ping ipv6-gw66.inet.co.th tunnel: IPv6 in IPv4 ipv6-gw66.inet.co.th -> www.freenet6.net VIAGENIE STATIC tunnel: IPv6 in IPv4 ipv6-gw66.inet.co.th -> rap.viagenie.qc.ca VIAGENIE BGP4+ tunnel: IPv6 in IPv4 ipv6-gw66.inet.co.th -> sl-bb1v6-sj.sprintlink.net SPRINT BGP4+ contact: BS5-6BONE contact: INOC1-6BONE remarks: ipv6-site is operational since 20011225 mnt-by: MNT-INET changed: snakk@inet.co.th 20011227 changed: snakk@inet.co.th 20011229 changed: snakk@inet.co.th 20020117 changed: snakk@inet.co.th 20020129 source: 6BONE <<< inet6num >>> inet6num: 3FFE:B80:61F::/48 netname: INET-TH descr: Internet Thailand Public Company Limited country: TH admin-c: BS5-6BONE tech-c: INOC1-6BONE notify: noc@inet.co.th mnt-by: MNT-INET changed: snakk@inet.co.th 20011225 changed: snakk@inet.co.th 20011227 source: 6BONE inet6num: 3FFE:B00:4050::/48 netname: INET-TH descr: Internet Thailand Public Company Limited country: TH admin-c: BS5-6BONE tech-c: INOC1-6BONE notify: ipv6@inet.co.th mnt-by: MNT-INET changed: snakk@inet.co.th 20020529 source: 6BONE inet6num: 3FFE:2900:1101::/48 netname: INET-TH descr: Internet Thailand Public Company Limited country: TH admin-c: BS5-6BONE tech-c: INOC1-6BONE notify: ipv6@inet.co.th mnt-by: MNT-INET changed: snakk@inet.co.th 20020529 source: 6BONE <<< mntner >>> % RIPEdb(3.0.0b2) with ISI RPSL extensions mntner: MNT-INET descr: Maintainer of INET-TH 6bone objects admin-c: BS16-AP tech-c: CN2-TH tech-c: SK13-AP tech-c: SK26-TH upd-to: noc@inet.co.th auth: CRYPT-PW * auth: CRYPT-PW * remarks: This object is automatically converted from the RIPE181 registry mnt-by: MNT-INET changed: snakk@inet.co.th 20010107 changed: snakk@inet.co.th 20010108 changed: auto-dbm@whois.6bone.net 20010117 source: 6BONE <<< person >>> % RIPEdb(3.0.0b2) with ISI RPSL extensions role: INET-TH Network Operation Center address: Internet Thailand Public Company Limited address: 108 Bangkok Thai Tower Bldg., 12 Fl., address: Rangnam Rd., Rajdhevee, address: Bangkok 10400, Thailand phone: +66-2640-0345 fax-no: +66-2640-0456 e-mail: noc@inet.co.th admin-c: BS5-6BONE tech-c: SK2-6BONE nic-hdl: INOC1-6BONE remarks: This object is automatically converted from the RIPE181 registry notify: noc@inet.co.th mnt-by: MNT-INET changed: snakk@inet.co.th 20010108 changed: auto-dbm@whois.6bone.net 20010117 changed: snakk@inet.co.th 20011225 source: 6BONE person: Buncha Srisamanuwat address: Internet Thailand Public Company Limited address: 108 Bangkok Thai Tower Bldg., 12 Fl., address: Rangnam Rd., Rajdhevee, address: Bangkok 10400, Thailand phone: +66-2640-0345 fax-no: +66-2640-0456 e-mail: athicha@inet.co.th nic-hdl: BS5-6BONE remarks: This object is automatically converted from the RIPE181 registry notify: athicha@inet.co.th mnt-by: MNT-INET changed: snakk@inet.co.th 20010108 changed: auto-dbm@whois.6bone.net 20010117 changed: snakk@inet.co.th 20011225 source: 6BONE person: Sanan Kurkulsatsanakit address: Internet Thailand Public Company Limited address: 108 Bangkok Thai Tower Bldg., 12 Fl., address: Rangnam Rd., Rajdhevee, address: Bangkok 10400, Thailand phone: +66-2640-0345 fax-no: +66-2640-0456 e-mail: snakk@inet.co.th nic-hdl: SK2-6BONE remarks: This object is automatically converted from the RIPE181 registry notify: snakk@inet.co.th mnt-by: MNT-INET changed: snakk@inet.co.th 20010108 changed: auto-dbm@whois.6bone.net 20010117 changed: snakk@inet.co.th 20011225 source: 6BONE person: Chakrit Noisuwan address: Internet Thailand Public Company Limited address: 108 Bangkok Thai Tower Bldg., 12 Fl., address: Rangnam Rd., Rajdhevee, address: Bangkok 10400, Thailand phone: +66-2640-0345 fax-no: +66-2640-0456 e-mail: chakrit@inet.co.th nic-hdl: CN2-6BONE notify: chakrit@inet.co.th mnt-by: MNT-INET changed: snakk@inet.co.th 20011225 changed: snakk@inet.co.th 20011225 source: 6BONE person: Nattapong Jatupongpairoj address: Internet Thailand Public Company Limited address: 108 Bangkok Thai Tower Bldg., 12th Fl., address: Rangnam Rd., Rajdhevee, address: Bangkok 10400, Thailand phone: +66-2640-0345 fax-no: +66-2257-7275 e-mail: jnatta@inet.co.th nic-hdl: NJ2-6BONE notify: jnatta@inet.co.th mnt-by: MNT-INET changed: snakk@inet.co.th 20020521 source: 6BONE person: Prasong Sakulwongwattana address: Internet Thailand Public Company Limited address: 108 Bangkok Thai Tower Bldg., 12th Fl., address: Rangnam Rd., Rajdhevee, address: Bangkok 10400, Thailand phone: +66-2640-0345 fax-no: +66-2257-7275 e-mail: psongs@inet.co.th nic-hdl: PS9-6BONE notify: psongs@inet.co.th mnt-by: MNT-INET changed: snakk@inet.co.th 20020521 source: 6BONE person: Karaked Kedchumpol address: Internet Thailand Public Company Limited address: 108 Bangkok Thai Tower Bldg., 12th Fl., address: Rangnam Rd., Rajdhevee, address: Bangkok 10400, Thailand phone: +66-2640-0345 fax-no: +66-2257-7275 e-mail: karaked@inet.co.th nic-hdl: KK13-6BONE notify: karaked@inet.co.th mnt-by: MNT-INET changed: snakk@inet.co.th 20020521 source: 6BONE -------------------------------------------------------------------------------- b. Fully maintained, and reliable, BGP4+ peering and connectivity between the Applicant's boundary router and the appropriate connection point into the 6Bone. This router must be IPv6 pingable. This criteria is judged by members of the 6Bone Operations Group at the time of the Applicant's pTLA request. -------------------------------------------------------------------------------- We have 2 BGP perring with SPRINT and VIAGENIE IPv6-Router#show ipv6 interface brief Ethernet0 [up/up] 3FFE:2900:1101:0:2B0:64FF:FEFC:E2E1 Loopback0 [up/up] unassigned Tunnel11 [up/up] <--- SPRINT 3FFE:2900:1100:1::2 Tunnel99 [up/up] <--- VIAGENIE 3FFE:B00:C18::99 IPv6-Router#show ip interface brief Interface IP-Address OK? Method Status Prot ocol Ethernet0 203.150.14.66 YES NVRAM up up Loopback0 203.150.16.66 YES NVRAM up up Tunnel11 unassigned YES NVRAM up up <--- SPRINT Tunnel99 unassigned YES NVRAM up up <--- VIAGENIE IPv6-Router#show bgp ipv6 summary BGP router identifier 203.150.16.66, local AS number 4618 BGP table version is 265470, main routing table version 265470 225 network entries and 427 paths using 58061 bytes of memory 359 BGP path attribute entries using 21540 bytes of memory 348 BGP AS-PATH entries using 9812 bytes of memory 9 BGP community entries using 216 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 180 BGP filter-list cache entries using 2160 bytes of memory 213 received paths for inbound soft reconfiguration BGP activity 56658/276904 prefixes, 219207/218780 paths, scan interval 15 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 3FFE:B00:C18::98 4 10566 746846 346002 265470 0 0 13:33:53 0 <--- VIAGENIE 3FFE:2900:1100:1::1 4 6175 352396 171730 265470 0 0 1d02h 212 <--- SPRINT -------------------------------------------------------------------------------- c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) entries for the Applicant's router(s) and at least one host system. -------------------------------------------------------------------------------- The main DNS server is "rns1.v6.inet.co.th". Our formal forward domain name for IPv6 is "v6.inet.co.th". And we have DNS reverse (ip6.int) delegation from SPRINT (3ffe:2900:1101::/48) only. # nslookup -type=soa v6.inet.co.th v6.inet.co.th origin = rns1.v6.inet.co.th mail addr = hostmaster.inet.co.th serial = 2002052803 refresh = 21600 (6H) retry = 7200 (2H) expire = 604800 (1W) minimum ttl = 43200 (12H) v6.inet.co.th nameserver = rns1.v6.inet.co.th rns1.v6.inet.co.th internet address = 203.150.14.111 rns1.v6.inet.co.th IPv6 address = 3ffe:2900:1101:0:210:64ff:fe30:7cb9 # nslookup > ls -d v6.inet.co.th $ORIGIN v6.inet.co.th. @ 12H IN SOA rns1 hostmaster.inet.co.th. ( 2002052803 ; serial 6H ; refresh 2H ; retry 1W ; expiry 12H ) ; minimum 12H IN NS rns1 FREENET6 12H IN AAAA 3ffe:b80:61f:: SPRINT 12H IN AAAA 3ffe:2900:1101:: VIAGENIE 12H IN AAAA 3ffe:b00:4050:: core-gw 12H IN A 203.150.14.66 12H IN AAAA 3ffe:2900:1101:0:2b0:64ff:fefc:e2e1 netcen 12H IN A 203.150.14.120 12H IN AAAA 3ffe:2900:1101:0:220:afff:fed3:6a4c rns1 12H IN A 203.150.14.111 12H IN AAAA 3ffe:2900:1101:0:210:64ff:fe30:7cb9 www 12H IN A 203.150.14.120 12H IN AAAA 3ffe:2900:1101:0:220:afff:fed3:6a4c # dig -t any 1.0.1.1.0.0.9.2.e.f.f.3.ip6.int @ns1.sprintv6.net ; <<>> DiG 8.3 <<>> -t 1.0.1.1.0.0.9.2.e.f.f.3.ip6.int @ns1.sprintv6.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2 ;; QUERY SECTION: ;; 1.0.1.1.0.0.9.2.e.f.f.3.ip6.int, type = ANY, class = IN ;; ANSWER SECTION: 1.0.1.1.0.0.9.2.e.f.f.3.ip6.int. 4H IN NS rns1.v6.inet.co.th. ;; AUTHORITY SECTION: 9.2.e.f.f.3.ip6.int. 4H IN NS ns1.sprintv6.net. ;; ADDITIONAL SECTION: ns1.sprintv6.net. 4H IN A 63.167.40.5 ns1.sprintv6.net. 4H IN AAAA 2001:440:1239:1001::2 -------------------------------------------------------------------------------- d. A fully maintained, and reliable, IPv6-accessible system providing, at a mimimum, one or more web pages, describing the Applicant's IPv6 services. This server must be IPv6 pingable. -------------------------------------------------------------------------------- Our common webpage for IPv6 is "http://www.v6.inet.co.th". It can be IPv6 pingable. # ping6 www.v6.inet.co.th PING6(56=40+8+8 bytes) 3ffe:2900:1101:0:220:afff:fed3:6a4c --> 3ffe:2900:1101:0:220:afff:fed3:6a4c 16 bytes from 3ffe:2900:1101:0:220:afff:fed3:6a4c, icmp_seq=0 hlim=64 time=0.32 ms 16 bytes from 3ffe:2900:1101:0:220:afff:fed3:6a4c, icmp_seq=1 hlim=64 time=0.19 ms 16 bytes from 3ffe:2900:1101:0:220:afff:fed3:6a4c, icmp_seq=2 hlim=64 time=0.186 ms 16 bytes from 3ffe:2900:1101:0:220:afff:fed3:6a4c, icmp_seq=3 hlim=64 time=0.185 ms 16 bytes from 3ffe:2900:1101:0:220:afff:fed3:6a4c, icmp_seq=4 hlim=64 time=0.189 ms --- www.v6.inet.co.th ping6 statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.185/0.214/0.320 ms ================================================================================ 2. The pTLA Applicant MUST have the ability and intent to provide "production-quality" 6Bone backbone service. Applicants must provide a statement and information in support of this claim. This MUST include the following: a. A support staff of two persons minimum, three preferable, with person attributes registered for each in the ipv6-site object for the pTLA applicant. -------------------------------------------------------------------------------- person: Buncha Srisamanuwat notify: athicha@inet.co.th person: Sanan Kurkulsatsanakit notify: snakk@inet.co.th person: Chakrit Noisuwan notify: chakrit@inet.co.th person: Nattapong Jatupongpairoj notify: jnatta@inet.co.th person: Prasong Sakulwongwattana notify: psongs@inet.co.th person: Karaked Kedchumpol notify: karaked@inet.co.th -------------------------------------------------------------------------------- b. A common mailbox for support contact purposes that all support staff have acess to, pointed to with a notify attribute in the ipv6-site object for the pTLA Applicant. -------------------------------------------------------------------------------- The common mailbox for IPv6 in INET-TH is "ipv6@inet.co.th" ipv6-site: INET-TH contact: INOC1-6BONE role: INET-TH Network Operation Center e-mail: ipv6@inet.co.th nic-hdl: INOC1-6BONE ================================================================================ 3. The pTLA Applicant MUST have a potential "user community" that would be served by its becoming a pTLA, e.g., the Applicant is a major provider of Internet service in a region, country, or focus of interest. Applicant must provide a statement and information in support this claim. -------------------------------------------------------------------------------- INET-TH is the most market-shared ISP of corporate customers in Thailand. We are providing Internet Access Service for both Corporate and Individual customers. We also provide Hosting, Co-location, Internet Data Center and E-commerce Services. We are the first ISP in Thailand that became to public company limited. Our coverage is overall of Thailand 76 provinces last year. As a 6BONE pTLA, we have a plan of testbed with our subscribers with policy of not charging services. We welcome whoever want to connect us with 6BONE prefix. We also plan to request IPv6 address space from APNIC within this year. Then we will provide our commercial services in IPv6. ================================================================================ 4. The pTLA Applicant MUST commit to abide by the current 6Bone operational rules and policies as they exist at time of its application, and agree to abide by future 6Bone backbone operational rules and policies as they evolve by consensus of the 6Bone backbone and user community. -------------------------------------------------------------------------------- INET-TH commit and agree to the current and future 6BONE operational rules and policies. <<< Internet Thailand Public Company Limited >>> From bmanning@ISI.EDU Thu Jun 6 19:18:28 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 6 Jun 2002 11:18:28 -0700 (PDT) Subject: [6bone] random walk? Message-ID: <200206061818.g56IISa02140@boreas.isi.edu> both nodes in LA. very impressive.... ---------------------------------------------------- traceroute6 to lime.ep.net (2001:478:6::1) from 3ffe:0:1::c620:242, 30 hops max, 12 byte packets 1 3ffe:0:1::1 9.531 ms * 0.498 ms 2 3ffe:c00:8023:e::1 11.849 ms 11.881 ms 11.392 ms 3 london1-manchester1-gw.ipv6.kewlio.net 219.342 ms edt-cisco.ipv6.edisontel. it 193.543 ms 193.373 ms 4 3ffe:2900:1:5::2 727.936 ms 3ffe:800::fffb:0:0:6 164.302 ms 166.069 ms 5 gate.ipv6.wanadoo.be 181.536 ms 290.697 ms * 6 2001:768:e:1::2 357.994 ms 3ffe:c00:8023:c::1 213.895 ms 213.377 ms 7 3ffe:81d0:ffff:2::23 487.803 ms 2001:288:3b0::c 708.252 ms 2001:288:3b0::1 e 402.871 ms 8 3ffe:8320:1::25 1028.21 ms london1-manchester1-gw.ipv6.kewlio.net 460.173 ms 459.098 ms 9 2001:780::b 449.21 ms 3ffe:c00:8023:25::1 264.226 ms 251.315 ms 10 3ffe:c00:8023:25::2 330.116 ms * 335.899 ms 11 3ffe:c00:8023:25::1 492.054 ms 401.806 ms 420.531 ms 12 3ffe:c00:8023:25::2 412.062 ms 809.992 ms 608.478 ms 13 3ffe:c00:8023:25::1 607.878 ms 415.899 ms 492.083 ms 14 * 3ffe:c00:8023:25::1 488.384 ms 551.468 ms 15 3ffe:c00:8023:25::2 564.566 ms 564.617 ms 567.17 ms 16 3ffe:c00:8023:25::1 577.971 ms 568.394 ms 571.052 ms 17 3ffe:c00:8023:25::2 647.445 ms 650.442 ms 653.109 ms 18 3ffe:c00:8023:25::1 642.521 ms 643.35 ms 3ffe:8260:fd:6::1 1278.51 ms !A 19 grnet-hurricane.ipv6.grnet.gr 2778.35 ms 2001:780::b 1757.16 ms 3ffe:c00:8 023:1e::2 2009.55 ms 20 2001:780::b 2096.76 ms 2091.27 ms 2084.79 ms 21 3ffe:c00:8023:1e::2 2222.58 ms 1922.16 ms 1659.08 ms 22 2001:478:ffff::1e 1655.09 ms 1648.34 ms 1631.33 ms 23 3ffe:c00:8023:1e::2 1842.8 ms 1824.69 ms 1794.77 ms 24 2001:780::b 1288.24 ms 1411.98 ms 1417.64 ms 25 2001:478:ffff::1e 1415.71 ms 1284.05 ms 1279.68 ms 26 2001:780::b 1391.3 ms 2001:478:ffff::1e 1487.08 ms 1696.65 ms 27 2001:470:1fff:2::5 1878.89 ms 1874.68 ms 1890.85 ms 28 2001:780::b 1910.57 ms 1931.28 ms 1912.06 ms 29 2001:470:1fff:2::5 1962.74 ms 3ffe:c00:8023:24::2 2586.11 ms 2593.85 ms 30 3ffe:c00:8023:24::1 2662.59 ms 2650.47 ms 2587.02 ms -- "When in doubt, Twirl..." -anon From mail@thomas--schaefer.de Thu Jun 6 20:34:28 2002 From: mail@thomas--schaefer.de (Thomas Schaefer) Date: Thu, 6 Jun 2002 21:34:28 +0200 Subject: [6bone] random walk? In-Reply-To: <200206061818.g56IISa02140@boreas.isi.edu> References: <200206061818.g56IISa02140@boreas.isi.edu> Message-ID: <200206062134.28910.mail@thomas--schaefer.de> 6. Juni 2002 20:18 wrote Bill Manning: > very impressive.... > from a different point of view: host:~ # traceroute6 2001:478:6::1 traceroute to 2001:478:6::1 (2001:478:6::1) from 3ffe:b80:d17:1:2a0:ccff:fe20:5d7c, 30 hops max, 16 byte packets 1 3ffe:b80:d17:1::1 (3ffe:b80:d17:1::1) 0.87 ms 0.577 ms 0.567 ms 2 3ffe:b80:2:95f3::1 (3ffe:b80:2:95f3::1) 365.829 ms 361.016 ms 375.314 ms 3 2001:780::b (2001:780::b) 814.896 ms 358.293 ms 353.315 ms 4 3ffe:b00:c18::6b (3ffe:b00:c18::6b) 492.258 ms 461.492 ms * 5 3ffe:b00:c18::3 (3ffe:b00:c18::3) 561.88 ms 560.234 ms 578.585 ms 6 2001:780::b (2001:780::b) 571.196 ms 570.055 ms 570.962 ms 7 * 3ffe:b00:c18::6b (3ffe:b00:c18::6b) 650.221 ms 660.813 ms 8 3ffe:b00:c18::3 (3ffe:b00:c18::3) 778.641 ms 779.591 ms 776.91 ms 9 * * 2001:780::b (2001:780::b) 775.771 ms 10 * 3ffe:b00:c18::6b (3ffe:b00:c18::6b) 857.956 ms 874.645 ms 11 3ffe:b00:c18::3 (3ffe:b00:c18::3) 1028.26 ms 1004.38 ms 1054.79 ms 12 2001:780::b (2001:780::b) 1042.59 ms 993.64 ms 999.804 ms 13 3ffe:b00:c18::6b (3ffe:b00:c18::6b) 1098.09 ms 1082.68 ms 1116.46 ms 14 3ffe:b00:c18::3 (3ffe:b00:c18::3) 1222.71 ms 1217.99 ms 1196.03 ms 15 2001:780::b (2001:780::b) 1270.78 ms 1207.47 ms 1198.48 ms 16 3ffe:b00:c18::6b (3ffe:b00:c18::6b) 1323.21 ms 1286.93 ms 1308.19 ms 17 3ffe:b00:c18::3 (3ffe:b00:c18::3) 1416.23 ms 1422.7 ms 1437.84 ms 18 2001:780::b (2001:780::b) 1414.32 ms 1413.82 ms 1445.82 ms 19 3ffe:b00:c18::6b (3ffe:b00:c18::6b) 1520.97 ms 1629.09 ms 1555.38 ms 20 * 3ffe:b00:c18::3 (3ffe:b00:c18::3) 1627.2 ms 1667.6 ms ... host:~ # ping6 2001:478:6::1 PING 2001:478:6::1(2001:478:6::1) from 3ffe:b80:d17:1:2a0:ccff:fe20:5d7c : 56 data bytes From 3ffe:b00:c18::6b icmp_seq=1 Time exceeded: Hop limitFrom 3ffe:b00:c18::6b icmp_seq=2 Time exceeded: Hop limitFrom 3ffe:b00:c18::6b icmp_seq=3 Time exceeded: Hop limit --- 2001:478:6::1 ping statistics --- 8 packets transmitted, 0 received, +3 errors, 100% loss, time 7042ms Regards, Thomas Schäfer From jorgen@hovland.cx Thu Jun 6 21:21:53 2002 From: jorgen@hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Thu, 6 Jun 2002 22:21:53 +0200 Subject: [6bone] random walk? References: <200206061818.g56IISa02140@boreas.isi.edu> Message-ID: <012301c20d97$cc3f52c0$0200000a@hera> It is most likely due to flapping and people using default-routes. Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure Origin codes: i - IGP, e - EGP, ? - incomplete Network From Flaps Duration Reuse Path * 2001:478::/35 2001:750:E::A 1 00:01:55 15589 8954 4554 * 3FFE:82B0:0:1:1 1 00:01:54 24765 109 4554 Joergen Hovland ----- Original Message ----- From: "Bill Manning" To: <6bone@ISI.EDU> Sent: Thursday, June 06, 2002 8:18 PM Subject: [6bone] random walk? > both nodes in LA. > very impressive.... > > ---------------------------------------------------- > > traceroute6 to lime.ep.net (2001:478:6::1) from 3ffe:0:1::c620:242, 30 hops max, > 12 byte packets > 1 3ffe:0:1::1 9.531 ms * 0.498 ms > 2 3ffe:c00:8023:e::1 11.849 ms 11.881 ms 11.392 ms > 3 london1-manchester1-gw.ipv6.kewlio.net 219.342 ms edt-cisco.ipv6.edisontel. > it 193.543 ms 193.373 ms > 4 3ffe:2900:1:5::2 727.936 ms 3ffe:800::fffb:0:0:6 164.302 ms 166.069 ms > 5 gate.ipv6.wanadoo.be 181.536 ms 290.697 ms * > 6 2001:768:e:1::2 357.994 ms 3ffe:c00:8023:c::1 213.895 ms 213.377 ms > 7 3ffe:81d0:ffff:2::23 487.803 ms 2001:288:3b0::c 708.252 ms 2001:288:3b0::1 > e 402.871 ms > 8 3ffe:8320:1::25 1028.21 ms london1-manchester1-gw.ipv6.kewlio.net 460.173 > ms 459.098 ms > 9 2001:780::b 449.21 ms 3ffe:c00:8023:25::1 264.226 ms 251.315 ms > 10 3ffe:c00:8023:25::2 330.116 ms * 335.899 ms > 11 3ffe:c00:8023:25::1 492.054 ms 401.806 ms 420.531 ms > 12 3ffe:c00:8023:25::2 412.062 ms 809.992 ms 608.478 ms > 13 3ffe:c00:8023:25::1 607.878 ms 415.899 ms 492.083 ms > 14 * 3ffe:c00:8023:25::1 488.384 ms 551.468 ms > 15 3ffe:c00:8023:25::2 564.566 ms 564.617 ms 567.17 ms > 16 3ffe:c00:8023:25::1 577.971 ms 568.394 ms 571.052 ms > 17 3ffe:c00:8023:25::2 647.445 ms 650.442 ms 653.109 ms > 18 3ffe:c00:8023:25::1 642.521 ms 643.35 ms 3ffe:8260:fd:6::1 1278.51 ms !A > 19 grnet-hurricane.ipv6.grnet.gr 2778.35 ms 2001:780::b 1757.16 ms 3ffe:c00:8 > 023:1e::2 2009.55 ms > 20 2001:780::b 2096.76 ms 2091.27 ms 2084.79 ms > 21 3ffe:c00:8023:1e::2 2222.58 ms 1922.16 ms 1659.08 ms > 22 2001:478:ffff::1e 1655.09 ms 1648.34 ms 1631.33 ms > 23 3ffe:c00:8023:1e::2 1842.8 ms 1824.69 ms 1794.77 ms > 24 2001:780::b 1288.24 ms 1411.98 ms 1417.64 ms > 25 2001:478:ffff::1e 1415.71 ms 1284.05 ms 1279.68 ms > 26 2001:780::b 1391.3 ms 2001:478:ffff::1e 1487.08 ms 1696.65 ms > 27 2001:470:1fff:2::5 1878.89 ms 1874.68 ms 1890.85 ms > 28 2001:780::b 1910.57 ms 1931.28 ms 1912.06 ms > 29 2001:470:1fff:2::5 1962.74 ms 3ffe:c00:8023:24::2 2586.11 ms 2593.85 ms > 30 3ffe:c00:8023:24::1 2662.59 ms 2650.47 ms 2587.02 ms > > -- > "When in doubt, Twirl..." -anon > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From jeroen@unfix.org Thu Jun 6 23:13:50 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Fri, 7 Jun 2002 00:13:50 +0200 Subject: [6bone] random walk? In-Reply-To: <012301c20d97$cc3f52c0$0200000a@hera> Message-ID: <000a01c20da7$740e7800$420d640a@unfix.org> Jørgen Hovland wrote: > It is most likely due to flapping and people using default-routes. > > Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal, > r RIB-failure > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network From Flaps Duration Reuse Path > * 2001:478::/35 2001:750:E::A 1 00:01:55 > 15589 8954 4554 > * 3FFE:82B0:0:1:1 1 00:01:54 > 24765 109 4554 jeroen@noc:~$ traceroute6 2001:478:6::1 traceroute to 2001:478:6::1 (2001:478:6::1) from 3ffe:4007:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 fe0.breda.ipv6.concepts-ict.net (3ffe:4007:1:1::1) 0.488 ms 0.385 ms 0.346 ms 2 se2.ams-ix.ipv6.concepts-ict.net (3ffe:4007:0:10::1) 3.559 ms 3.576 ms 3.746 ms 3 ams-ix.sara.xs4all.net (2001:7f8:1::a500:3265:1) 4.085 ms 4.741 ms 4.111 ms 4 nikhef.ams-ix.ipv6.intouch.net (2001:7f8:1::a500:8954:1) 4.25 ms 4.107 ms 4.125 ms 5 3ffe:800::fffb:0:0:5 (3ffe:800::fffb:0:0:5) 161.881 ms 161.794 ms * 6 3ffe:800::fffb:0:0:5 (3ffe:800::fffb:0:0:5) 168.316 ms !H * 161.958 ms !H @Intouch (www.ipng.nl/bgp/ :) EP-NET ISI-LAP 2001:0478::/35 3.5% 0.0% view http://www.ipng.nl/bgp/history/35-EP-NET.html : 90.3% ( 130 / 144 ) ISI-LAP 8.3% ( 12 / 144 ) SURFNET - BELNET-BE - BELBONE-BE - 4589 - CYBERNET - REGIO-DE - SPACENET-D - ISI-LAP 0.7% ( 1 / 144 ) CERN - EDISONTEL - 12337 - REGIO-DE - SPACENET-D - ISI-LAP 0.7% ( 1 / 144 ) CISCO - ITESM - XS4ALL-NL - OXYGEN - SPRINT - ISI-LAP ISI-LAP doesn't nicely connect to you but are announcing it... btw... QWEST-IPV6 has an unstability rating of 57.6% here... which is quite high imho, nothing bad but not quite nice either ;) btw2: check the list at http://dmoz.org/Computers/Internet/Protocols/IP/IPng/IPv6_Route_Views/ to check where it could go wrong. btw3: Nice to see ep.net going v6 when are the servers following ? :) Greets, Jeroen From pim@ipng.nl Sun Jun 9 18:22:47 2002 From: pim@ipng.nl (Pim van Pelt) Date: Sun, 9 Jun 2002 19:22:47 +0200 Subject: [6bone] ifconfig and EUI-64 Message-ID: <20020609172247.GA2781@bfib.colo.bit.nl> Hi guys, Does anyone know why exactly the ifconfig programs for the BSDs, Linux and most probably Solaris are not able to autoconfigure their own addresses, by not using the RS/RA schema, but a local autoconfiguration such as the Cisco IOS: interface FastEthernet0/0 ipv6 enable ipv6 address 2001:7b8:4:1234::/64 eui-64 ! which will let the fa0/0 device figure out its own address using the lower order 64 bits of its linklocal address in the specified prefix. This behavior is missing in the Unix world and I for one would like to see it implemented. Anybody against this ? groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From ww@GROOVY.NET Sun Jun 9 20:06:30 2002 From: ww@GROOVY.NET (ww@GROOVY.NET) Date: Sun, 9 Jun 2002 15:06:30 -0400 Subject: [6bone] ifconfig and EUI-64 In-Reply-To: <20020609172247.GA2781@bfib.colo.bit.nl>; from pim@ipng.nl on Sun, Jun 09, 2002 at 07:22:47PM +0200 References: <20020609172247.GA2781@bfib.colo.bit.nl> Message-ID: <20020609150630.A18427@GROOVY.NET> On Sun, Jun 09, 2002 at 07:22:47PM +0200, Pim van Pelt wrote: > > which will let the fa0/0 device figure out its own address using the > lower order 64 bits of its linklocal address in the specified prefix. > > This behavior is missing in the Unix world and I for one would like to > see it implemented. Anybody against this ? There was a discussion about this some time ago on the NetBSD tech-net mailing list. The debate centered on whether it was better to have this functionality in the ifconfig binary or in some sort of script that would call ifconfig after calculating the lower order 64 bits. The problem with the latter is that it might assume that /usr is mounted which may not be true until after networking has been configured. I can't think of any very strong argument about why what you suggest should not be implemented within ifconfig(8). Cheers, Will From jeroen@unfix.org Sun Jun 9 20:56:12 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Sun, 9 Jun 2002 21:56:12 +0200 Subject: [6bone] ifconfig and EUI-64 In-Reply-To: <20020609150630.A18427@GROOVY.NET> Message-ID: <000c01c20fef$b5a53a20$420d640a@unfix.org> ww@GROOVY.NET wrote: > On Sun, Jun 09, 2002 at 07:22:47PM +0200, Pim van Pelt wrote: > > > > which will let the fa0/0 device figure out its own address using the > > lower order 64 bits of its linklocal address in the specified prefix. > > > > This behavior is missing in the Unix world and I for one would like to > > see it implemented. Anybody against this ? > > There was a discussion about this some time ago on the NetBSD > tech-net mailing list. The debate centered on whether it was > better to have this functionality in the ifconfig binary or > in some sort of script that would call ifconfig after calculating > the lower order 64 bits. The problem with the latter is that it > might assume that /usr is mounted which may not be true until > after networking has been configured. > > I can't think of any very strong argument about why what you > suggest should not be implemented within ifconfig(8). FreeBSD 4.2 had the /etc/rc.network6 init script setup so that it would check for a prefixcmd_enable="YES" and if that was true it would use the prefix from ipv6_prefix_ and do a 'prefix ' which sets up an anycast address, after which, the system (read: kernel) knows how to autoconfig that device. Unfortunatly for some odd reason this 'feature' was taken from newer (4.4+) FreeBSD's. The 'prefix' command is still there but the rc.network6 script is now used, the prefix command is completely ignored. As this comes from the KAME upstream they probably know the reason why that happened? Greets, Jeroen PS: snippets from the 'prefix' manpage: DESCRIPTION prefix is used to assign an prefix to a network interface and/or renum- bering network interface prefixes. prefix must be used at boot time to define the network prefix of each interface present on a machine; it may also be used at a later time to renumbering multiple interface's prefixes and other prefix related parameters. prefix is router-only command, so you must do following to use it. % sysctl -w net.inet6.ip6.forwarding=1 If net.inet6.ip6.forwarding is set to 0, prefix command fails by EPERM error. HISTORY The prefix command first appeared in WIDE/KAME IPv6 protocol stack kit. IPv6 and IPsec support based on the KAME Project (http://www.kame.net/) stack was initially integrated into FreeBSD 4.0 From hansolofalcon@worldnet.att.net Sun Jun 9 21:07:20 2002 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Sun, 9 Jun 2002 16:07:20 -0400 Subject: [6bone] ifconfig and EUI-64 In-Reply-To: <20020609150630.A18427@GROOVY.NET> Message-ID: <000001c20ff1$4373e940$2a52580c@who> Hello from Gregg C Levine Pim, I am in total agreement with you on this. Both distributions of Linux which I run here, do support IPv6, but do it strangely. I am inclined to keep an open mind here, on what preference happens. The strange thing I found with NetBSD is that during the installation process it wanted to autoconfig an IPv6 address, then things broke down because my system wasn't being properly configured for that version. FreeBSD on the other hand did want to, but I told it to not do that. And back to Linux, I'll spare you folks my complaints on that problem grouping. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."  Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: 6bone-admin@mailman.isi.edu [mailto:6bone-admin@mailman.isi.edu] On > Behalf Of ww@GROOVY.NET > Sent: Sunday, June 09, 2002 3:07 PM > To: Pim van Pelt > Cc: 6bone@ISI.EDU > Subject: Re: [6bone] ifconfig and EUI-64 > > On Sun, Jun 09, 2002 at 07:22:47PM +0200, Pim van Pelt wrote: > > > > which will let the fa0/0 device figure out its own address using the > > lower order 64 bits of its linklocal address in the specified prefix. > > > > This behavior is missing in the Unix world and I for one would like to > > see it implemented. Anybody against this ? > > There was a discussion about this some time ago on the NetBSD > tech-net mailing list. The debate centered on whether it was > better to have this functionality in the ifconfig binary or > in some sort of script that would call ifconfig after calculating > the lower order 64 bits. The problem with the latter is that it > might assume that /usr is mounted which may not be true until > after networking has been configured. > > I can't think of any very strong argument about why what you > suggest should not be implemented within ifconfig(8). > > Cheers, > Will > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone From aangel@transa.infoarc.sodaknet.com Mon Jun 10 00:21:51 2002 From: aangel@transa.infoarc.sodaknet.com (Aaron Angel) Date: 09 Jun 2002 19:21:51 -0400 Subject: [Fwd: Re: [6bone] ifconfig and EUI-64] Message-ID: <1023664911.56010.21.camel@transa.infoarc.sodaknet.com> Ehk; forgot to Cc: the list. -----Forwarded Message----- > From: Aaron Angel > To: Pim van Pelt > Subject: Re: [6bone] ifconfig and EUI-64 > Date: 09 Jun 2002 19:21:08 -0400 > > On Sun, 2002-06-09 at 13:22, Pim van Pelt wrote: > > Hi guys, > > > > Does anyone know why exactly the ifconfig programs for the BSDs, Linux > > and most probably Solaris are not able to autoconfigure their own > > addresses, by not using the RS/RA schema, but a local autoconfiguration > > such as the Cisco IOS: > > > The KAME stack comes with rtsol and rtsold; the former sends > solicitations once, the latter is a daemonized version. > > As far as Linux goes (or anything supported, for that matter), > distributions which use INRIA support it in ifconfig with the eui64 > keyword...exactly how, I'm not sure; I don't use it. From Francis.Dupont@enst-bretagne.fr Tue Jun 11 08:55:40 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Tue, 11 Jun 2002 09:55:40 +0200 Subject: [6bone] ifconfig and EUI-64 In-Reply-To: Your message of Sun, 09 Jun 2002 19:22:47 +0200. <20020609172247.GA2781@bfib.colo.bit.nl> Message-ID: <200206110755.g5B7teT98855@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: Does anyone know why exactly the ifconfig programs for the BSDs, Linux and most probably Solaris are not able to autoconfigure their own addresses, by not using the RS/RA schema, but a local autoconfiguration such as the Cisco IOS: => note that Ciscos are usually routers so can't use RS/RA. interface FastEthernet0/0 ipv6 enable ipv6 address 2001:7b8:4:1234::/64 eui-64 ! which will let the fa0/0 device figure out its own address using the lower order 64 bits of its linklocal address in the specified prefix. => EUI-64 should be from the MAC address not from the link-local address but I agree the intended behavior is not well reflected by the name. This behavior is missing in the Unix world and I for one would like to see it implemented. Anybody against this ? => I like to have this and the possibility to explicitely set the link-local address too. Regards Francis.Dupont@enst-bretagne.fr From Francis.Dupont@enst-bretagne.fr Tue Jun 11 09:01:13 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Tue, 11 Jun 2002 10:01:13 +0200 Subject: [Fwd: Re: [6bone] ifconfig and EUI-64] In-Reply-To: Your message of 09 Jun 2002 19:21:51 EDT. <1023664911.56010.21.camel@transa.infoarc.sodaknet.com> Message-ID: <200206110801.g5B81DT98888@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: > As far as Linux goes (or anything supported, for that matter), > distributions which use INRIA support it in ifconfig with the eui64 > keyword...exactly how, I'm not sure; I don't use it. => I can answer, from man ifconfig: eui64 (inet6 only) The real IPv6 address is computed by replacing the last 64 bytes of the given address with the Interface Identifier. For a point-to-point interface, if a destination address is given and has a null Interface Identifier part, the Interface Identifi- er part of this destination address is filled by the Interface Identifier part of the link-local destination address (which must be present). The interface ID is picked up from the (first) link-local address and if there is none from the link-layer address. There is a provision for point-to-point links (i.e. set the peer interface ID too). The last versions perform this in ifconfig itself but you can implement the same idea in the kernel or in a script. Thanks Francis.Dupont@enst-bretagne.fr From pim@ipng.nl Tue Jun 11 09:58:10 2002 From: pim@ipng.nl (Pim van Pelt) Date: Tue, 11 Jun 2002 10:58:10 +0200 Subject: [Fwd: Re: [6bone] ifconfig and EUI-64] In-Reply-To: <1023664911.56010.21.camel@transa.infoarc.sodaknet.com> References: <1023664911.56010.21.camel@transa.infoarc.sodaknet.com> Message-ID: <20020611085810.GB26532@bfib.colo.bit.nl> On Sun, Jun 09, 2002 at 07:21:51PM -0400, Aaron Angel wrote: | Ehk; forgot to Cc: the list. Aaron, Thanks for the remarks but I was specifically stating that I wish _not_ to use the Router Discovery protocol on a host. Let us say that our box is a router itself, then we would like to set the interface addresses in the global scope implicitly by specifying something like: # ifconfig gx0 inet6 2001:7b8:3:1234:: -prefixlen 64 -eui64 Which would make the box calculate the lower order 64 bits via the MAC address (thanks, Francis) in stead of having the user set it explicitly. Your rtsol/rtsold (and the standard Linux/Windows behavior) have nothing to do with this. I should check out the INRIA comment though, thanks for that hint! groet, Pim | | -----Forwarded Message----- | | > From: Aaron Angel | > To: Pim van Pelt | > Subject: Re: [6bone] ifconfig and EUI-64 | > Date: 09 Jun 2002 19:21:08 -0400 | > | > On Sun, 2002-06-09 at 13:22, Pim van Pelt wrote: | > > Hi guys, | > > | > > Does anyone know why exactly the ifconfig programs for the BSDs, Linux | > > and most probably Solaris are not able to autoconfigure their own | > > addresses, by not using the RS/RA schema, but a local autoconfiguration | > > such as the Cisco IOS: | > > | > The KAME stack comes with rtsol and rtsold; the former sends | > solicitations once, the latter is a daemonized version. | > | > As far as Linux goes (or anything supported, for that matter), | > distributions which use INRIA support it in ifconfig with the eui64 | > keyword...exactly how, I'm not sure; I don't use it. | | _______________________________________________ | 6bone mailing list | 6bone@mailman.isi.edu | http://mailman.isi.edu/mailman/listinfo/6bone -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From dwaddington@lucent.com Tue Jun 11 14:18:08 2002 From: dwaddington@lucent.com (Daniel G Waddington) Date: Tue, 11 Jun 2002 09:18:08 -0400 Subject: [6bone] Public Announcement - Bell Labs IPv6 Probing Experiments Message-ID: PUBLIC ANNOUNCEMENT - BELL LABS IPv6 PROBING EXPERIMENTS To all 6Bone users and network administrators: Bell Laboratories, NJ, is currently performing experiments in IPv6 network topology discovery that involves sending a number of source routed IPv6 probe packets (from 3ffe:2900:c00c:1102:210:5aff:fe9e:9e3b) into the 6Bone network. This is purely a research experiment aimed at collecting router topology information about the 6Bone network. The data that we are collecting from the network will hopefully help us, and the rest of the IPv6 community, to better understand the nature of large scale IPv6 deployment (e.g. effects of tunnelling on routing infrastructure). Some of you may already have noticed that we have been dispatching probes on and off for the last 3 months on to the 6Bone network. Since this is an experimental infrastructure overseen by the IETF, the results will be made publically available to the IETF community in the coming months on www.ipv6.bell-labs.com. If you do not wish to be part of this experiment, then given your router addresses we can eliminate you from the search space. However, we can assure you that probe traffic will be kept to a minimum and that once we have a complete set of data, the experiments will be performed less frequently. Please do not hesitate to contact me if you have any further questions or issues to raise on this matter. Sincerely Yours, Daniel G. Waddington Networking Research Lab Bell Laboratories, Lucent Technologies From itojun@iijlab.net Tue Jun 11 15:36:46 2002 From: itojun@iijlab.net (Jun-ichiro itojun Hagino) Date: Tue, 11 Jun 2002 23:36:46 +0900 Subject: [6bone] ifconfig and EUI-64 In-Reply-To: Francis.Dupont's message of Tue, 11 Jun 2002 09:55:40 +0200. <200206110755.g5B7teT98855@givry.rennes.enst-bretagne.fr> Message-ID: <20020611143646.9A3AD7B9@starfruit.itojun.org> >=> I like to have this and the possibility to explicitely set the link-local >address too. you can always remove then add. itojun From kre@munnari.OZ.AU Wed Jun 12 08:44:53 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Wed, 12 Jun 2002 14:44:53 +0700 Subject: [6bone] ifconfig and EUI-64 In-Reply-To: <200206110755.g5B7teT98855@givry.rennes.enst-bretagne.fr> References: <200206110755.g5B7teT98855@givry.rennes.enst-bretagne.fr> Message-ID: <18604.1023867893@munnari.OZ.AU> Date: Tue, 11 Jun 2002 09:55:40 +0200 From: Francis Dupont Message-ID: <200206110755.g5B7teT98855@givry.rennes.enst-bretagne.fr> | => I like to have this Me too. | and the possibility to explicitely set the link-local address too. Doesn't everyone already allow that? (Some of my systems have a whole bunch of link local addresses assigned to various interfaces - after all, there are 2^64 to choose from on every link, and no nets I use have nearly that many connected hosts, so each host can have lots...) What I want, which is maybe what you meant, is the ability to explicitly set the IID, from which the link-local, and global (and site-local...) addresses are computed. That is so when a new prefix appears in a RA, the new address will automatically be generated using the IID I specified (which is why simply specifying the whole address doesn't work). kre From Francis.Dupont@enst-bretagne.fr Wed Jun 12 13:07:56 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Wed, 12 Jun 2002 14:07:56 +0200 Subject: [6bone] ifconfig and EUI-64 In-Reply-To: Your message of Wed, 12 Jun 2002 14:44:53 +0700. <18604.1023867893@munnari.OZ.AU> Message-ID: <200206121207.g5CC7uT06279@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: | and the possibility to explicitely set the link-local address too. Doesn't everyone already allow that? => no, for instance in KAME you have to recompile the kernel with "options IP6_AUTO_LINKLOCAL=0"... What I want, which is maybe what you meant, is the ability to explicitly set the IID, from which the link-local, and global (and site-local...) addresses are computed. => on a reasonable system to set the link-local address or the IID are equivalent. That is so when a new prefix appears in a RA, the new address will automatically be generated using the IID I specified (which is why simply specifying the whole address doesn't work). => the subject of this thread is the extension of this to the ifconfig command. Thanks Francis.Dupont@enst-bretagne.fr From kre@munnari.OZ.AU Wed Jun 12 16:08:41 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Wed, 12 Jun 2002 22:08:41 +0700 Subject: [6bone] ifconfig and EUI-64 In-Reply-To: <200206121207.g5CC7uT06279@givry.rennes.enst-bretagne.fr> References: <200206121207.g5CC7uT06279@givry.rennes.enst-bretagne.fr> Message-ID: <20785.1023894521@munnari.OZ.AU> Date: Wed, 12 Jun 2002 14:07:56 +0200 From: Francis Dupont Message-ID: <200206121207.g5CC7uT06279@givry.rennes.enst-bretagne.fr> | => no, for instance in KAME you have to recompile the kernel with | "options IP6_AUTO_LINKLOCAL=0"... Then what you mean isn't what you said, I use KAME, and I have lots of link local addresses, and I never knew that option existed. I suspect that what you mean is "not automatically generate a link local based upon the IID" but that's a different thing to "explicitly set the link local address". | => on a reasonable system to set the link-local address or the IID are | equivalent. Only if you make the assumption that there is only one link-local address. That's not a reasonable assumption I don't think. There's no reason not to have several. eg: In general I prefer regular auto-config'd addresses (EUI-64 and all that in the IID). But for debugging (ping of the address, etc) it is nice if they also have nice easy to use LL addresses, like fe80::1 fe80::2 and such, so I just go assign those. It can also be convenient to have fe80::a.b.c.d where a.b.c.d is the IPv4 address assigned to the interface, as that's then a real easy way to match things, and know which is which (from the ancient past, I tend to simply know what IPv4 addr applies to every system around). But I want only one IID for the interface - which one of those should the kernel pick, if it was to treat them as equivalent. | => the subject of this thread is the extension of this to the ifconfig | command. Yes, I know, what I would like to be able to do is ifconfig interface inet6 iid 77 and if I do that before anything else has enabled IPv6 on the interface, it should simply use "77" (which would be a hex string with an arbitrary number of :'s up to 5, with an implied (maybe required explicit) leading ::) when it first enabled the interface and configures its first link local. Being able to specify "prefix xxx::" I would also like. The "iid" is mostly for hosts, "prefix" for routers (iid for routers too, but specifying both iid and prefix is just the same as specifying the whole address on a router, which doesn't get more prefixes from RAs). kre From Francis.Dupont@enst-bretagne.fr Wed Jun 12 18:11:29 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Wed, 12 Jun 2002 19:11:29 +0200 Subject: [6bone] ifconfig and EUI-64 In-Reply-To: Your message of Wed, 12 Jun 2002 22:08:41 +0700. <20785.1023894521@munnari.OZ.AU> Message-ID: <200206121711.g5CHBTT07971@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: | => no, for instance in KAME you have to recompile the kernel with | "options IP6_AUTO_LINKLOCAL=0"... Then what you mean isn't what you said, I use KAME, and I have lots of link local addresses, and I never knew that option existed. => this option is not documented but gives a way to disable the automatic (i.e. out of control) generation of a link-local address when an interface comes up. I suspect that what you mean is "not automatically generate a link local based upon the IID" but that's a different thing to "explicitly set the link local address". => this is a matter of wording: my idea is the IID doesn't exist by itself. And I assume that to have a link-local address is equivalent to have IPv6 enabled on the interface. | => on a reasonable system to set the link-local address or the IID are | equivalent. Only if you make the assumption that there is only one link-local address. That's not a reasonable assumption I don't think. There's no reason not to have several. => but there is no need to have several too... eg: In general I prefer regular auto-config'd addresses (EUI-64 and all that in the IID). => I agree but I'd like to have the control for the rare cases where something else is better. But for debugging (ping of the address, etc) it is nice if they also have nice easy to use LL addresses, like fe80::1 fe80::2 and such, so I just go assign those. It can also be convenient to have fe80::a.b.c.d where a.b.c.d is the IPv4 address assigned to the interface, as that's then a real easy way to match things, and know which is which (from the ancient past, I tend to simply know what IPv4 addr applies to every system around). => when cut&paste is not available fe80::1, ..., are very convenient. But I want only one IID for the interface - which one of those should the kernel pick, if it was to treat them as equivalent. => this is the point we disagree: I want only one link-local for the interface and the (unique) IID is taken from the link-local. I don't believe the result will be very different but this is not exactly the same thing. | => the subject of this thread is the extension of this to the ifconfig | command. Yes, I know, what I would like to be able to do is ifconfig interface inet6 iid 77 and if I do that before anything else has enabled IPv6 on the interface, it should simply use "77" (which would be a hex string with an arbitrary number of :'s up to 5, with an implied (maybe required explicit) leading ::) when it first enabled the interface and configures its first link local. Being able to specify "prefix xxx::" I would also like. The "iid" is mostly for hosts, "prefix" for routers (iid for routers too, but specifying both iid and prefix is just the same as specifying the whole address on a router, which doesn't get more prefixes from RAs). => I write this "ifconfig interface inet6 fe80::77/64" and "ifconfig interface inet6 xxx::/plen eui64 alias". As I've said our disagreement is only about details... Regards Francis.Dupont@enst-bretagne.fr PS: for an obscure reason KAME /etc/rc.network6 script supports full addresses and prefixes but in the wrong order... From jeroen@unfix.org Wed Jun 12 18:21:05 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Wed, 12 Jun 2002 19:21:05 +0200 Subject: [6bone] 3FFE:6700::/32 - Another pTLA space hijack Message-ID: <001701c21235$8900e8a0$420d640a@unfix.org> jeroen@purgatory:~$ whois 3FFE:6700::/32 inet6num: 3FFE:6700::/32 netname: AZURVP-V6 descr: AzurVP Network. None profit organisation. country: FR admin-c: AD5-6BONE tech-c: AD5-6BONE mnt-by: MNT-AZURVP changed: a_dailliez@yahoo.fr 20020611 source: 6BONE person: Amaury DAILLIEZ address: 506 chemin des ecoliers phone: +33614912547 nic-hdl: AD5-6BONE url: http://www.azurvp.net mnt-by: MNT-AZURVP changed: a_dailliez@yahoo.fr 20020605 source: 6BONE This is the second time some 'entity' has simply chosen to steal some address space. Previous time went unseen when (also some french entity) though to hijack 3ffe:6777::/32. They replied with "I didn't saw the rules concerning the pTLA spaces" which could also be read as "I didn't know I couldn't just take this cool castle, I didn't saw a sign when I went in". Could the 3ffe://16 object be protected with mnt-lower's to the real pTLA holders ? "Look mummy I got a /32 on the internet all for myself", but then written in leet... Greets, Jeroen From michel@arneill-py.sacramento.ca.us Wed Jun 12 18:43:28 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 12 Jun 2002 10:43:28 -0700 Subject: [6bone] 3FFE:6700::/32 - Another pTLA space hijack Message-ID: <2B81403386729140A3A899A8B39B046405E0FC@server2000.arneill-py.sacramento.ca.us> The one thing that bugs me is that I don't even see what this kind of behavior achieves. Not only nobody will route it, but now he's on the blacklist. Maybe we should have an age verification system and not allow 14 year-old to register /32s. Amaury, nettoies tes merdes de la base de données, merci. Michel. -----Original Message----- From: Jeroen Massar [mailto:jeroen@unfix.org] Sent: Wednesday, June 12, 2002 10:21 AM To: 6bone@ISI.EDU Cc: a_dailliez@yahoo.fr Subject: [6bone] 3FFE:6700::/32 - Another pTLA space hijack jeroen@purgatory:~$ whois 3FFE:6700::/32 inet6num: 3FFE:6700::/32 netname: AZURVP-V6 descr: AzurVP Network. None profit organisation. country: FR admin-c: AD5-6BONE tech-c: AD5-6BONE mnt-by: MNT-AZURVP changed: a_dailliez@yahoo.fr 20020611 source: 6BONE person: Amaury DAILLIEZ address: 506 chemin des ecoliers phone: +33614912547 nic-hdl: AD5-6BONE url: http://www.azurvp.net mnt-by: MNT-AZURVP changed: a_dailliez@yahoo.fr 20020605 source: 6BONE This is the second time some 'entity' has simply chosen to steal some address space. Previous time went unseen when (also some french entity) though to hijack 3ffe:6777::/32. They replied with "I didn't saw the rules concerning the pTLA spaces" which could also be read as "I didn't know I couldn't just take this cool castle, I didn't saw a sign when I went in". Could the 3ffe://16 object be protected with mnt-lower's to the real pTLA holders ? "Look mummy I got a /32 on the internet all for myself", but then written in leet... Greets, Jeroen _______________________________________________ 6bone mailing list 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone From fink@es.net Thu Jun 13 03:27:47 2002 From: fink@es.net (Bob Fink) Date: Wed, 12 Jun 2002 19:27:47 -0700 Subject: [6bone] Illegal registry of 3FFE:6700::/32 Message-ID: <5.1.0.14.0.20020612190531.02a62e90@imap2.es.net> Amaury DAILLIEZ, You are in violation of 6bone address allocation rules and general 6bone policy. Please reply to me immediately so I can at least understand your motivation for this, and hopefully you can maintain your future reputation with the 6bone/ipv6 community. Whatever your response, however, I have deleted your inet6num entry for 3FFE:6700::/32 as it is a hijacking of unallocated space. Depending on your reply, I will decided whether to delete your mntner and person objects as well. Also note that no 6bone pTLA is likely to peer with you, nor should be willing to do so, given the unauthorized nature of your inet6num entry and its prefix range. Hoping to hear from you, Bob Fink === >From: "Jeroen Massar" >To: <6bone@ISI.EDU> >Cc: >Subject: [6bone] 3FFE:6700::/32 - Another pTLA space hijack >Date: Wed, 12 Jun 2002 19:21:05 +0200 > >jeroen@purgatory:~$ whois 3FFE:6700::/32 > >inet6num: 3FFE:6700::/32 >netname: AZURVP-V6 >descr: AzurVP Network. None profit organisation. >country: FR >admin-c: AD5-6BONE >tech-c: AD5-6BONE >mnt-by: MNT-AZURVP >changed: a_dailliez@yahoo.fr 20020611 >source: 6BONE > >person: Amaury DAILLIEZ >address: 506 chemin des ecoliers >phone: +33614912547 >nic-hdl: AD5-6BONE >url: http://www.azurvp.net >mnt-by: MNT-AZURVP >changed: a_dailliez@yahoo.fr 20020605 >source: 6BONE > > >This is the second time some 'entity' has simply chosen to steal some >address space. >Previous time went unseen when (also some french entity) though to >hijack 3ffe:6777::/32. >They replied with "I didn't saw the rules concerning the pTLA spaces" >which could also be >read as "I didn't know I couldn't just take this cool castle, I didn't >saw a sign when I went in". > >Could the 3ffe://16 object be protected with mnt-lower's to the real >pTLA holders ? > >"Look mummy I got a /32 on the internet all for myself", but then >written in leet... > >Greets, > Jeroen > >_______________________________________________ >6bone mailing list >6bone@mailman.isi.edu >http://mailman.isi.edu/mailman/listinfo/6bone From kre@munnari.OZ.AU Thu Jun 13 11:25:04 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Thu, 13 Jun 2002 17:25:04 +0700 Subject: [6bone] ifconfig and EUI-64 In-Reply-To: <200206121711.g5CHBTT07971@givry.rennes.enst-bretagne.fr> References: <200206121711.g5CHBTT07971@givry.rennes.enst-bretagne.fr> Message-ID: <23511.1023963904@munnari.OZ.AU> Date: Wed, 12 Jun 2002 19:11:29 +0200 From: Francis Dupont Message-ID: <200206121711.g5CHBTT07971@givry.rennes.enst-bretagne.fr> | => this option is not documented but gives a way to disable the | automatic (i.e. out of control) generation of a link-local address | when an interface comes up. Thanks for the explanation, that's what I guessed when you mentioned it. | => this is a matter of wording: my idea is the IID doesn't exist by itself. That's something with which I disagree then, as I believe it does, though certainly it is a minor point. | And I assume that to have a link-local address is equivalent to have IPv6 | enabled on the interface. Yes I would treat those two as being essentially the same, no IPv6 operating interface should ever be without a LL address. | => but there is no need to have several too... No, it isn't required (except perhaps for a node acting as a proxy for another node - wouldn't a VRRP router need to take over the LL address of the router it is pretending to be, and wouldn't a HA need to at least act as if it owns the addresses of mobile nodes?) But there's a difference between not being required (if it never is) and not being useful. I see no reason to forbid multiple LL addresses for a node. | => this is the point we disagree: I want only one link-local for the | interface and the (unique) IID is taken from the link-local. Yes, that's where we disagree. | I don't believe the result will be very different but this is not exactly | the same thing. Not very different, we both want the same functionality, I just want a little more generality than you do. Also, if I decide that fe80::1 is the one and only LL addr for an interface, that doesn't mean that I want 3ffe:abcd::1 to necessarily be the global address assigned - in many cases I'd still like that one to be EUI-64 based. So, I really would prefer to separate the issues of assigning a LL address, and setting the IID that should be used to auto-configure addresses. | As I've said our disagreement is only about details... Almost, but not quite. | PS: for an obscure reason KAME /etc/rc.network6 script supports full | addresses and prefixes but in the wrong order... I use KAME as incorporated into NetBSD, which has no such script, (IPv6 stuff is handled along with IPv4 stuff in /etc/rc.d/network) so I'm afraid I can't quite follow that reference. kre From fink@es.net Thu Jun 13 15:27:59 2002 From: fink@es.net (Bob Fink) Date: Thu, 13 Jun 2002 07:27:59 -0700 Subject: [6bone] pTLA request ICPNET-PL - review closes 27 June 2002 Message-ID: <5.1.0.14.0.20020613072453.0293b1d8@imap2.es.net> 6bone Folk, ICPNET-PL has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 27 June 2002. Please send your comments to me or the list. Thanks, Bob === >Date: Thu, 13 Jun 2002 09:50:16 +0200 >From: Bartosz Waszak >To: Bob Fink >Subject: pTLA Request for ICPNET (AS13110), resubmit > >Hello! > >Here we present our corrected application for a 6Bone pTLA. > >RFC 2772: > >7. Guidelines for 6Bone pTLA sites > > > > The following rules apply to qualify for a 6Bone pTLA allocation. > > It should be recognized that holders of 6Bone pTLA allocations are > > expected to provide production quality backbone network services > > for the 6Bone. > > > > 1. The pTLA Applicant must have a minimum of three (3) months > > qualifying experience as a 6Bone end-site or pNLA transit. During > > the entire qualifying period the Applicant must be operationally > > providing the following: > >We have about 6 months experience as a 6bone end-site. > > > a. Fully maintained, up to date, 6Bone Registry entries for their > > ipv6-site inet6num, mntner, and person objects, including each > > tunnel that the Applicant has. > >ipv6-site: ICPNET-PL >origin: AS13110 >descr: Internet Cable Provider (major broadband service in country) >country: PL >prefix: 3FFE:8010:7:11::/64 >prefix: 3FFE:8010:7:F00::/56 >prefix: 3FFE:8320:2:5::/64 >application: ping ontario.ipv6.icpnet.pl >application: www www.ipv6.icpnet.pl >application: smtp ontario.ipv6.icpnet.pl >application: ftp ftp.ipv6.icpnet.pl >tunnel: IPv6 in IPv4 ontario.ipv6.icpnet.pl -> 6bone-gw.6bone.pl >ICM-PL BGP4+ >tunnel: IPv6 in IPv4 ontario.ipv6.icpnet.pl -> ipv6-gw.man.poznan.pl >POZMAN BGP4+ >tunnel: IPv6 in IPv4 ontario.ipv6.icpnet.pl -> >nautilus.ipv6.icpnet.pl ICPNET STATIC >tunnel: IPv6 in IPv4 ontario.ipv6.icpnet.pl -> chaos.wmid.amu.edu.pl >UNDEFINE BGP4+ >contact: IS2-6BONE >remarks: joined projects: SCIFI (operational since Sep 2000) and UNISOFT >notify: ipv6@ipv6.icpnet.pl >mnt-by: MNT-SCIFI >changed: waszi@ipv6.icpnet.pl 20020611 >source: 6BONE > >inet6num: 3FFE:8010:7:F00::/56 >netname: ICPNET-PL >descr: Internet Cable Provider >country: PL >admin-c: BW3-6BONE >tech-c: IS2-6BONE >remarks: ICPNET, pilot project for transition Cable Modem access to ipv6 >notify: ipv6@ipv6.icpnet.pl >mnt-by: MNT-SCIFI >changed: waszi@ipv6.icpnet.pl 20020611 >source: 6BONE > >inet6num: 3FFE:8010:7:11::/64 >netname: ICPNET-PL >descr: Internet Cable Provider >country: PL >admin-c: BW3-6BONE >tech-c: IS2-6BONE >remarks: ICPNET, pilot project for transition Cable Modem access to ipv6 >notify: ipv6@ipv6.icpnet.pl >mnt-by: MNT-SCIFI >changed: waszi@ipv6.icpnet.pl 20020611 >source: 6BONE > >inet6num: 3FFE:8320:2:5::/64 >netname: ICPNET-PL >descr: Internet Cable Provider >country: PL >admin-c: BW3-6BONE >tech-c: IS2-6BONE >remarks: ICPNET, pilot project for transition Cable Modem access to ipv6 >notify: ipv6@ipv6.icpnet.pl >mnt-by: MNT-SCIFI >changed: waszi@ipv6.icpnet.pl 20020611 >source: 6BONE > >role: ICP Staff >address: ul. Owsiana 17 >address: 61-666 Poznan >address: POLAND >e-mail: ipv6@ipv6.icpnet.pl >admin-c: BW3-6BONE >tech-c: KP4-6BONE >nic-hdl: IS2-6BONE >mnt-by: MNT-SCIFI >changed: waszi@ipv6.icpnet.pl 20020611 >source: 6BONE > >person: Bartosz Waszak >address: ul. Owsiana 17 >address: 61-666 Poznan >address: POLAND >phone: +48618280132 >e-mail: waszi@ipv6.icpnet.pl >nic-hdl: BW3-6BONE >url: http://www.ipv6.icpnet.pl/ >notify: waszi@ipv6.icpnet.pl >changed: waszi@ipv6.icpnet.pl 20020603 >source: 6BONE > >person: Krzysztof Palicki >address: ul. Owsiana 17 >address: 61-666 Poznan >address: POLAND >phone: +48618280132 >e-mail: chris@poczta.icpnet.pl >nic-hdl: KP4-6BONE >url: http://www.ipv6.icpnet.pl/ >notify: chris@poczta.icpnet.pl >changed: chris@poczta.icpnet.pl 20020612 >source: 6BONE > > > b. Fully maintained, and reliable, BGP4+ peering and connectivity > > between the Applicant's boundary router and the appropriate > > connection point into the 6Bone. This router must be IPv6 > > pingable. This criteria is judged by members of the 6Bone > > Operations Group at the time of the Applicant's pTLA request. > >We have three BGP4+ peerings, and some static tunnels + native IPv6 >connections. > >BGP router identifier 62.21.98.6, local AS number 13110 >451 BGP AS-PATH entries >7 BGP community entries > >Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ >Up/Down State/PfxRcd > >ICM: >3ffe:8010:7:11::1 > 4 8664 32644 5793 0 0 0 01:02:02 217 > >AMUWMID: >3ffe:8010:7:6a00::3e > 4 58502 4991 1295 0 0 0 21:22:09 217 > >POZMAN: >3ffe:8320:1::30 4 9112 15817 10549 0 0 0 01w0d05h 211 > >router is pingable via IPv6: >[root@voyager /]# ping6 ontario.ipv6.icpnet.pl >PING ontario.ipv6.icpnet.pl(3ffe:8320:2:5:2::1) 56 data bytes >64 bytes from 3ffe:8320:2:5:2::1: icmp_seq=1 ttl=63 time=8.792 msec >64 bytes from 3ffe:8320:2:5:2::1: icmp_seq=2 ttl=63 time=7.087 msec > > > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > > entries for the Applicant's router(s) and at least one host > > system. > >We maintain DNS entries for ipv6.icpnet.pl and for 3ffe:8010:7:f00::/56 > >Our primary DNS server for IPv6 is: ontario.icpnet.pl >Secondary: ww2.icpnet.pl > >;; global options: printcmd >ipv6.icpnet.pl. 600 IN SOA ontario.icpnet.pl. >hostmaster.ontario.icpnet.pl. 2002061101 10800 600 604800 86400 >ipv6.icpnet.pl. 600 IN NS ww2.icpnet.pl. >ipv6.icpnet.pl. 600 IN NS ontario.icpnet.pl. >ipv6.icpnet.pl. 600 IN MX 0 voyager.ipv6.icpnet.pl. >ipv6.icpnet.pl. 600 IN MX 10 ontario.ipv6.icpnet.pl. >z-portal-gw.amuwmid-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:11:2::1 >ftp.ipv6.icpnet.pl. 600 IN CNAME ontario.ipv6.icpnet.pl. >z-voyager-gw.icm-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:11::1 >z-portal-gw.icpnet-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::c >z-voyager-gw.icpnet-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::a >irc.ipv6.icpnet.pl. 600 IN CNAME ontario.ipv6.icpnet.pl. >z-portal-gw.ktnet-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::1 >localhost.ipv6.icpnet.pl. 600 IN A 127.0.0.1 >nautilus.ipv6.icpnet.pl. 600 IN A 62.21.3.239 >nautilus.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8320:2:5:1::2 >news.ipv6.icpnet.pl. 600 IN CNAME ontario.ipv6.icpnet.pl. >ontario.ipv6.icpnet.pl. 600 IN A 62.21.98.6 >ontario.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8320:2:5:2::1 >z-portal-gw.pbern-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::7 >z-portal-gw.pollus-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::5 >z-amuwmid-gw.portal-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:11:2:: >z-icpnet-gw.portal-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::d >z-ktnet-gw.portal-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed:: >z-pbern-gw.portal-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::6 >z-pollus-gw.portal-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::4 >z-thelema-gw.portal-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::2 >z-undefine-gw.portal-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::8 >z-portal-gw.thelema-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::3 >z-portal-gw.undefine-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::9 >voyager.ipv6.icpnet.pl. 600 IN A 62.21.3.1 >voyager.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8320:2:5:1::1 >z-icm-gw.voyager-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:11::2 >z-icpnet-gw.voyager-gw.ipv6.icpnet.pl. 600 IN AAAA 3ffe:8010:7:f00:feed::b >www.ipv6.icpnet.pl. 600 IN CNAME ontario.ipv6.icpnet.pl. >ipv6.icpnet.pl. 600 IN SOA ontario.icpnet.pl. >hostmaster.ontario.icpnet.pl. 2002061101 10800 600 604800 86400 >;; Query time: 23 msec >;; SERVER: 62.21.98.6#53(ontario.icpnet.pl) >;; WHEN: Wed Jun 12 21:03:10 2002 >;; XFR size: 36 records > >$ORIGIN . >$TTL 600 ; 10 minutes >f.0.7.0.0.0.0.1.0.8.e.f.f.3.ip6.int IN SOA dns.portalcafe.pl. >root\@scifi.eu.org. ( > 2002051806 ; serial > 10800 ; refresh (3 hours) > 600 ; retry (10 minutes) > 604800 ; expire (1 week) > 86400 ; minimum (1 day) > ) > NS dns.portalcafe.pl. > NS voyager.ipv6.icpnet.pl. >$ORIGIN f.0.7.0.0.0.0.1.0.8.e.f.f.3.ip6.int. >$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.d.e.e.f.0.0.f.0.7.0.0.0.0.1.0.8.e.f.f.3.ip6.int. >0 PTR z-ktnet-gw.portal-gw.ipv6.icpnet.pl. >1 PTR z-portal-gw.ktnet-gw.ipv6.icpnet.pl. >2 PTR z-thelema-gw.portal-gw.ipv6.icpnet.pl. >3 PTR z-portal-gw.thelema-gw.ipv6.icpnet.pl. >4 PTR z-pollus-gw.portal-gw.ipv6.icpnet.pl. >5 PTR z-portal-gw.pollus-gw.ipv6.icpnet.pl. >6 PTR z-pbern-gw.portal-gw.ipv6.icpnet.pl. >7 PTR z-portal-gw.pbern-gw.ipv6.icpnet.pl. >8 PTR z-undefine-gw.portal-gw.ipv6.icpnet.pl. >9 PTR z-portal-gw.undefine-gw.ipv6.icpnet.pl. >a PTR z-voyager-gw.icpnet-gw.ipv6.icpnet.pl. >b PTR z-icpnet-gw.voyager-gw.ipv6.icpnet.pl. >c PTR z-portal-gw.icpnet-gw.ipv6.icpnet.pl. >d PTR z-icpnet-gw.portal-gw.ipv6.icpnet.pl. > > > d. A fully maintained, and reliable, IPv6-accessible system > > providing, at a mimimum, one or more web pages, describing the > > Applicant's IPv6 services. This server must be IPv6 pingable. > >Our new IPv6 Accessible web page is under construction. >Currently on http://www.ipv6.icpnet.pl/ is info about how >to contact with us. > > > 2. The pTLA Applicant MUST have the ability and intent to provide > > "production-quality" 6Bone backbone service. Applicants must > > provide a statement and information in support of this claim. > > This MUST include the following: > > > > a. A support staff of two persons minimum, three preferable, with > > person attributes registered for each in the ipv6-site object > > for the pTLA applicant. > >person: Bartosz Waszak >e-mail: waszi@ipv6.icpnet.pl >nic-hdl: BW3-6BONE > >person: Krzysztof Palicki >e-mail: chris@poczta.icpnet.pl >nic-hdl: KP4-6BONE > > > b. A common mailbox for support contact purposes that all support > > staff have acess to, pointed to with a notify attribute in the > > ipv6-site object for the pTLA Applicant. > >ipv6@ipv6.icpnet.pl > >This address is configured as a "e-mail" attribute in the "role" object. > > > 3. The pTLA Applicant MUST have a potential "user community" that > > would be served by its becoming a pTLA, e.g., the Applicant is a > > major provider of Internet service in a region, country, or focus > > of interest. Applicant must provide a statement and information in > > support this claim. > >ICP is providing internet access by cable modems or directly to >our backbone by Ethernet. We have about 10'000 users, >so we are in Poland one of the major ISPs. > > > 4. The pTLA Applicant MUST commit to abide by the current 6Bone > > operational rules and policies as they exist at time of its > > application, and agree to abide by future 6Bone backbone > > operational rules and policies as they evolve by consensus of the > > 6Bone backbone and user community. > >We agree to abide by the rules as they exist now and as they may evolve in >the future. > > > When an Applicant seeks to receive a pTLA allocation, it will apply > > to the 6Bone Operations Group (see section 8 below) by providing to > > the Group information in support of its claims that it meets the > > criteria above. > > > >8. 6Bone Operations Group > > > > The 6Bone Operations Group is the group in charge of monitoring and > > policing adherence to the current rules. Membership in the 6Bone > > Operations Group is mandatory for, and restricted to, sites > > connected to the 6Bone. > > > > The 6Bone Operations Group is currently defined by those members of > > the existing 6Bone mailing list who represent sites participating in > > the 6Bone. Therefore it is incumbent on relevant site contacts to > > join the 6Bone mailing list. Instructions on how to join the list > > are maintained on the 6Bone web site at < http://www.6bone.net>. > >Regards > >-- >Bartosz Waszak >Internet Cable Provider Sp. z o.o. >(http://www.icpnet.pl/) From Ronald.vanderPol@rvdp.org Fri Jun 14 00:12:45 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Fri, 14 Jun 2002 01:12:45 +0200 Subject: [6bone] problem with ftp.netbsd.org Message-ID: <20020613231245.GA36510@rvdp.org> I cannot ftp to ftp.bsd.org: spock$ ftp ftp.netbsd.org Connected to ftp.netbsd.org. Tcpdump shows (spock is 2001:610:508:1001:260:1dff:fef6:7ff9): 00:37:02.458730 2001:610:508:1001:260:1dff:fef6:7ff9.1310 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: S [tcp sum ok] 3384697445:3384697445(0) win 57344 (len 40, hlim 64) 00:37:02.764566 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21 > 2001:610:508:1001:260:1dff:fef6:7ff9.1310: S [tcp sum ok] 131386982:131386982(0) ack 3384697446 win 32768 (len 40, hlim 54) 00:37:02.764799 2001:610:508:1001:260:1dff:fef6:7ff9.1310 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: . [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) 00:37:10.547821 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) 00:38:14.548802 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) 00:39:18.549774 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) 00:40:22.550736 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) 00:41:26.551704 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) 00:42:30.552678 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) 00:43:34.553613 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: R [tcp sum ok] 2:2(0) ack 1 win 58548 (len 20, hlim 64) Several people have informed me that they can reach ftp.netbsd.org over IPv6. I am thinking about a routing problem from ftp.netbsd.org towards me, but on the other hand the tcpdump above shows I do get one packet from ftp.netbsd.org in the handshaking phase. I tried this on freebsd-stable, netbsd-current and netbsd 1.5.3 with the same result. 'ftp -4 ftp.netbsd.org' is working fine. v6 ftp to other v6 ftp servers is also working, so no firewall issues. Traceroute is also working: spock$ traceroute6 -q 1 -l ftp.netbsd.org traceroute6 to ftp.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) from 2001:610:508:1001:260:1dff:fef6:7ff9, 30 hops max, 12 byte packets 1 kirk (2001:610:508:1001:220:afff:fec6:4faa) 3.201 ms 2 surrogate.ipv6.surfnet.nl (2001:610:508:1000::1) 7.9 ms 3 surfnet-bv.Amsterdam.ipv6.surf.net (2001:610:0:2001::1) 13.627 ms 4 PO4-0.CR2.Amsterdam1.surf.net (2001:610:16:3048::49) 16.897 ms 5 PO0-0.BR2.Amsterdam1.surf.net (2001:610:16:6004::6) 15.136 ms 6 ams-ix.sara.xs4all.net (2001:7f8:1::a500:3265:1) 13.938 ms 7 nikhef.ams-ix.ipv6.intouch.net (2001:7f8:1::a500:8954:1) 12.436 ms 8 3ffe:1280:1001:1::1 (3ffe:1280:1001:1::1) 382.62 ms 9 3ffe:80a::1 (3ffe:80a::1) 203.762 ms 10 3ffe:8050:ffff::fffd (3ffe:8050:ffff::fffd) 204.275 ms 11 ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) 306.499 ms Any suggestions what could be wrong here? rvdp PS This is quite annoying because I have the same problem with www.netbsd.org and I use mozilla-1.0. From jeroen@unfix.org Fri Jun 14 01:14:44 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Fri, 14 Jun 2002 02:14:44 +0200 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <20020613231245.GA36510@rvdp.org> Message-ID: <000b01c21338$7d28fe10$420d640a@unfix.org> > -----Original Message----- > From: 6bone-admin@mailman.isi.edu > [mailto:6bone-admin@mailman.isi.edu] On Behalf Of Ronald van der Pol > Sent: Friday, 14 June 2002 01:13 > To: 6bone@mailman.isi.edu > Subject: [6bone] problem with ftp.netbsd.org > > > I cannot ftp to ftp.bsd.org: > > spock$ ftp ftp.netbsd.org > Connected to ftp.netbsd.org. > > > Tcpdump shows (spock is 2001:610:508:1001:260:1dff:fef6:7ff9): > 8<---------------- jeroen@purgatory:~$ telnet -6 www.netbsd.org 80 Trying 3ffe:8050:201:1860:290:27ff:feab:19a7... Connected to www.netbsd.org. Escape character is '^]'. GET / HTTP/1.1 Host: www.netbsd.org ----------->8 wait wait wait, but no reply :( > Several people have informed me that they can reach ftp.netbsd.org over IPv6. HTTP has the same problem. > I am thinking about a routing > problem from ftp.netbsd.org towards me, > but on the other hand the tcpdump above shows I do get one packet from > ftp.netbsd.org in the handshaking phase. I even get a connect ;) > I tried this on freebsd-stable, netbsd-current and netbsd 1.5.3 with the same result. > Any suggestions what could be wrong here? Then again I am probably behind the same uplink (IPng/Intouch :) So it could still be between the netherlands and the US.... Greets, Jeroen From randy@psg.com Fri Jun 14 01:21:43 2002 From: randy@psg.com (Randy Bush) Date: Thu, 13 Jun 2002 17:21:43 -0700 Subject: [6bone] problem with ftp.netbsd.org References: <20020613231245.GA36510@rvdp.org> <000b01c21338$7d28fe10$420d640a@unfix.org> Message-ID: % ping6 ftp.netbsd.org PING6(56=40+8+8 bytes) 2001:418:1:0:2e0:18ff:fe02:6ec9 --> 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea 16 bytes from 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea, icmp_seq=0 hlim=59 time=33.077 ms 16 bytes from 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea, icmp_seq=1 hlim=59 time=32.97 ms 16 bytes from 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea, icmp_seq=2 hlim=59 time=32.597 ms % uname -a FreeBSD roam.psg.com 4.6-RC FreeBSD 4.6-RC #18: Fri May 24 14:09:23 PDT 2002 6 From itojun@iijlab.net Fri Jun 14 01:51:07 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Fri, 14 Jun 2002 09:51:07 +0900 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: Ronald.vanderPol's message of Fri, 14 Jun 2002 01:12:45 +0200. <20020613231245.GA36510@rvdp.org> Message-ID: <3827.1024015867@itojun.org> >I cannot ftp to ftp.bsd.org: >Several people have informed me that they can reach ftp.netbsd.org over >IPv6. > >I am thinking about a routing problem from ftp.netbsd.org towards me, >but on the other hand the tcpdump above shows I do get one packet from >ftp.netbsd.org in the handshaking phase. > >I tried this on freebsd-stable, netbsd-current and netbsd 1.5.3 with the >same result. > >Any suggestions what could be wrong here? there seems to be some config mistake within ISI (who hosts tp.netbsd.org), regarding to link MTU setting of tunnel interface. i heard that they have changed the config so it should be better now. (at least, it is much better for me) i myself have experienced it before - Juniper sets tunnel interface MTU to infinity, and KAME uses 1280. itojun From jeroen@unfix.org Fri Jun 14 01:55:39 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Fri, 14 Jun 2002 02:55:39 +0200 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: Message-ID: <001301c2133e$33f85cd0$420d640a@unfix.org> Randy Bush [mailto:randy@psg.com] wrote: > % ping6 ftp.netbsd.org > PING6(56=40+8+8 bytes) 2001:418:1:0:2e0:18ff:fe02:6ec9 --> > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea > 16 bytes from 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea, > icmp_seq=0 hlim=59 time=33.077 ms > 16 bytes from 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea, > icmp_seq=1 hlim=59 time=32.97 ms > 16 bytes from 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea, > icmp_seq=2 hlim=59 time=32.597 ms > > % uname -a > FreeBSD roam.psg.com 4.6-RC FreeBSD 4.6-RC #18: Fri May 24 > 14:09:23 PDT 2002 6 I got some of those too, they will syn/ack but no data :( tunnelserver.ipng.nl: 8<-------------------- jeroen@tunnelserver:~$ traceroute6 ftp6.netbsd.org traceroute6 to ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) from 2001:6e0::250:4ff:fe4a:7708, 30 hops max, 16 byte packets 1 Amsterdam.core.ipv6.intouch.net (2001:6e0::2) 1.75 ms 0.411 ms 0.388 ms 2 3ffe:1280:1001:1::1 (3ffe:1280:1001:1::1) 298.968 ms * 315.534 ms 3 3ffe:80a::1 (3ffe:80a::1) 159.079 ms 159.268 ms 158.932 ms 4 3ffe:8050:ffff::fffd (3ffe:8050:ffff::fffd) 160.742 ms 160.487 ms 159.343 ms 5 ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) 159.866 ms 159.95 ms 160.722 ms jeroen@tunnelserver:~$ ping6 ftp6.netbsd.org PING ftp6.netbsd.org(ftp6.netbsd.org) 56 data bytes 64 bytes from ftp6.netbsd.org: icmp_seq=0 time=160.3 ms 64 bytes from ftp6.netbsd.org: icmp_seq=1 time=349.0 ms 64 bytes from ftp6.netbsd.org: icmp_seq=2 time=197.7 ms 64 bytes from ftp6.netbsd.org: icmp_seq=3 time=202.2 ms 64 bytes from ftp6.netbsd.org: icmp_seq=4 time=206.6 ms 64 bytes from ftp6.netbsd.org: icmp_seq=5 time=210.5 ms --- ftp6.netbsd.org ping6 statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 160.3/221.0/349.0 ms jeroen@tunnelserver:~$ uname -a Linux tunnelserver 2.4.17ipng #1 Fri Jan 25 14:54:39 CET 2002 i586 unknown jeroen@tunnelserver:~$ telnet ftp6.netbsd.org 21 Trying 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea... Connected to ftp6.netbsd.org. Escape character is '^]'. -------------------->8 It will connect, but nothing more, something is dropping packets I think. Unfortunatly these boxes all take the same route over amsterdam.intouch (2001:6e0::2) so the problem could be behind that box, though I don't think it's that one as I kinda trust it :) Odd thing: connecting to port 80 on the ftp6.netbsd.org doesn't get refused. Is this thing a v6 loadbalancer ? :) Greets, Jeroen From itojun@iijlab.net Fri Jun 14 02:13:40 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Fri, 14 Jun 2002 10:13:40 +0900 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: itojun's message of Fri, 14 Jun 2002 09:51:07 +0900. <3827.1024015867@itojun.org> Message-ID: <4065.1024017220@itojun.org> > there seems to be some config mistake within ISI (who hosts s/ISI/ISC/ itojun From darko@hytron.net Fri Jun 14 02:17:57 2002 From: darko@hytron.net (Darko) Date: Thu, 13 Jun 2002 21:17:57 -0400 (EDT) Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <20020613231245.GA36510@rvdp.org> Message-ID: Try nslookup -q=AAAA ftp.bsd.org You will see that there is no AAAA record for that host, therefore you cannot use IPv6 to reach it. Darko On Fri, 14 Jun 2002, Ronald van der Pol wrote: > Date: Fri, 14 Jun 2002 01:12:45 +0200 > From: Ronald van der Pol > To: 6bone@mailman.isi.edu > Subject: [6bone] problem with ftp.netbsd.org > > I cannot ftp to ftp.bsd.org: > > spock$ ftp ftp.netbsd.org > Connected to ftp.netbsd.org. > > > Tcpdump shows (spock is 2001:610:508:1001:260:1dff:fef6:7ff9): > > 00:37:02.458730 2001:610:508:1001:260:1dff:fef6:7ff9.1310 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: S [tcp sum ok] 3384697445:3384697445(0) win 57344 (len 40, hlim 64) > 00:37:02.764566 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21 > 2001:610:508:1001:260:1dff:fef6:7ff9.1310: S [tcp sum ok] 131386982:131386982(0) ack 3384697446 win 32768 (len 40, hlim 54) > 00:37:02.764799 2001:610:508:1001:260:1dff:fef6:7ff9.1310 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: . [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) > 00:37:10.547821 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) > 00:38:14.548802 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) > 00:39:18.549774 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) > 00:40:22.550736 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) > 00:41:26.551704 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) > 00:42:30.552678 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: F [tcp sum ok] 1:1(0) ack 1 win 58548 (len 32, hlim 64) > 00:43:34.553613 2001:610:508:1001:260:1dff:fef6:7ff9.1308 > 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea.21: R [tcp sum ok] 2:2(0) ack 1 win 58548 (len 20, hlim 64) > > Several people have informed me that they can reach ftp.netbsd.org over > IPv6. > > I am thinking about a routing problem from ftp.netbsd.org towards me, > but on the other hand the tcpdump above shows I do get one packet from > ftp.netbsd.org in the handshaking phase. > > I tried this on freebsd-stable, netbsd-current and netbsd 1.5.3 with the > same result. > > 'ftp -4 ftp.netbsd.org' is working fine. v6 ftp to other v6 ftp servers > is also working, so no firewall issues. Traceroute is also working: > spock$ traceroute6 -q 1 -l ftp.netbsd.org > traceroute6 to ftp.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) from 2001:610:508:1001:260:1dff:fef6:7ff9, 30 hops max, 12 byte packets > 1 kirk (2001:610:508:1001:220:afff:fec6:4faa) 3.201 ms > 2 surrogate.ipv6.surfnet.nl (2001:610:508:1000::1) 7.9 ms > 3 surfnet-bv.Amsterdam.ipv6.surf.net (2001:610:0:2001::1) 13.627 ms > 4 PO4-0.CR2.Amsterdam1.surf.net (2001:610:16:3048::49) 16.897 ms > 5 PO0-0.BR2.Amsterdam1.surf.net (2001:610:16:6004::6) 15.136 ms > 6 ams-ix.sara.xs4all.net (2001:7f8:1::a500:3265:1) 13.938 ms > 7 nikhef.ams-ix.ipv6.intouch.net (2001:7f8:1::a500:8954:1) 12.436 ms > 8 3ffe:1280:1001:1::1 (3ffe:1280:1001:1::1) 382.62 ms > 9 3ffe:80a::1 (3ffe:80a::1) 203.762 ms > 10 3ffe:8050:ffff::fffd (3ffe:8050:ffff::fffd) 204.275 ms > 11 ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) 306.499 ms > > Any suggestions what could be wrong here? > > rvdp > > PS This is quite annoying because I have the same problem with > www.netbsd.org and I use mozilla-1.0. > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From tony@lava.net Fri Jun 14 02:45:30 2002 From: tony@lava.net (Antonio Querubin) Date: Thu, 13 Jun 2002 15:45:30 -1000 (HST) Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: Message-ID: On Thu, 13 Jun 2002, Darko wrote: > Try nslookup -q=AAAA ftp.bsd.org > You will see that there is no AAAA record for that host, therefore you > cannot use IPv6 to reach it. True enough but the problem was/is with ftp.netbsd.org, not ftp.bsd.org. % host -a ftp.netbsd.org Trying null domain rcode = 0 (Success), ancount=2 The following answer is not verified as authentic by the server: ftp.netbsd.org 3600 IN A 204.152.184.75 ftp.netbsd.org 3600 IN AAAA 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea From tlangdon@atctraining.com.au Fri Jun 14 03:50:18 2002 From: tlangdon@atctraining.com.au (Tony Langdon) Date: Fri, 14 Jun 2002 12:50:18 +1000 Subject: [6bone] problem with ftp.netbsd.org Message-ID: > Try nslookup -q=AAAA ftp.bsd.org > You will see that there is no AAAA record for that host, therefore you > cannot use IPv6 to reach it. Hmm, the site was ftp.netbsd.org,which does have IPv6 address. ; <<>> DiG 9.2.0 <<>> ftp.netbsd.org any ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40363 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 6 ;; QUESTION SECTION: ;ftp.netbsd.org. IN ANY ;; ANSWER SECTION: ftp.netbsd.org. 3594 IN A 204.152.184.75 ftp.netbsd.org. 3594 IN AAAA 3ffe:8050:201:1860:2a0:c9ff:feed :b7ea ..... Now for a ping... [root@ipv6gw1 rc.d]# ping6 ftp.netbsd.org PING ftp.netbsd.org(3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) 56 data bytes 64 bytes from 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea: icmp_seq=2 ttl=58 time=410 ms 64 bytes from 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea: icmp_seq=3 ttl=58 time=430 ms 64 bytes from 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea: icmp_seq=4 ttl=58 time=420 ms FTP connection worked fine for me also, no dramas [root@ipv6gw1 rc.d]# ftp 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea Connected to 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea (3ffe:8050:201:1860:2a0:c9ff: feed:b7ea). 220 ftp6.netbsd.org FTP server (NetBSD-ftpd 20020201) ready. Name (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea:root): anonymous 331 Guest login ok, type your name as password. Password: Also worked by name on IPv6 --- Outgoing mail has been scanned for Viruses. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.370 / Virus Database: 205 - Release Date: 5/06/2002 This correspondence is for the named person’s use only. It may contain confidential or legally privileged information or both. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this correspondence in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or rely on any part of this correspondence if you are not the intended recipient. Any opinions expressed in this message are those of the individual sender. From jeroen@unfix.org Fri Jun 14 03:58:11 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Fri, 14 Jun 2002 04:58:11 +0200 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <3827.1024015867@itojun.org> Message-ID: <001b01c2134f$523033b0$420d640a@unfix.org> itojun@iijlab.net wrote: > >I cannot ftp to ftp.bsd.org: > >Several people have informed me that they can reach ftp.netbsd.org over IPv6. > > > >I am thinking about a routing problem from ftp.netbsd.org towards me, > >but on the other hand the tcpdump above shows I do get one packet from > >ftp.netbsd.org in the handshaking phase. > > > >I tried this on freebsd-stable, netbsd-current and netbsd 1.5.3 with the > >same result. > > > >Any suggestions what could be wrong here? > > there seems to be some config mistake within ISI (who hosts > tp.netbsd.org), regarding to link MTU setting of tunnel interface. > i heard that they have changed the config so it should be better now. > (at least, it is much better for me) > > i myself have experienced it before - Juniper sets tunnel interface MTU > to infinity, and KAME uses 1280. Let's try again from purgatory.unfix.org: 8<-------------------------- jeroen@purgatory:~$ telnet www.jp.freebsd.org 21 Trying 3ffe:501:185b:101:2a0:24ff:fe57:e561... Connected to www.jp.freebsd.org. Escape character is '^]'. 220 tortoise.jp.freebsd.org FTP server (Version 6.00) ready. ^] telnet> q Connection closed. jeroen@purgatory:~$ telnet ftp6.netbsd.org 21 Trying 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea... Connected to ftp6.netbsd.org. Escape character is '^]'. -------------------------->8 Still no response back :( Greets, Jeroen From stuart@tech.org Fri Jun 14 04:51:12 2002 From: stuart@tech.org (Stephen Stuart) Date: Thu, 13 Jun 2002 20:51:12 -0700 Subject: [6bone] problem with ftp.netbsd.org Message-ID: <200206140351.g5E3pCk01953@lo.tech.org> If anyone is still having problems with TCP sessions to/from ftp.netbsd.org, please send me traceroutes. Thanks, Stephen From mail@thomas--schaefer.de Fri Jun 14 07:35:52 2002 From: mail@thomas--schaefer.de (Thomas Schaefer) Date: Fri, 14 Jun 2002 08:35:52 +0200 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: References: Message-ID: <200206140835.52758.mail@thomas--schaefer.de> Am Freitag, 14. Juni 2002 03:45 schrieb Antonio Querubin: > On Thu, 13 Jun 2002, Darko wrote: > > Try nslookup -q=AAAA ftp.bsd.org > > You will see that there is no AAAA record for that host, therefore you > > cannot use IPv6 to reach it. > > True enough but the problem was/is with ftp.netbsd.org, not ftp.bsd.org. > > And now it seems to work very well: ----------------------------------------------- thomas@witz:~> nslookup -query=any ftp.netbsd.org Note: nslookup is deprecated and may be removed from future releases. Consider using the `dig' or `host' programs instead. Run nslookup with the `-sil[ent]' option to prevent this message from appearing. Server: 212.185.252.201 Address: 212.185.252.201#53 Name: ftp.netbsd.org Address: 204.152.184.75 ftp.netbsd.org has AAAA address 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea thomas@witz:~> ftp 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea Connected to 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea. 220 ftp6.netbsd.org FTP server (NetBSD-ftpd 20020201) ready. Name (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea:thomas): anonymous 331 Guest login ok, type your name as password. Password: 230- Welcome to FTP.NetBSD.ORG Located in Palo Alto, CA, USA , , /( )` Home of \ \___ / | 100Mb Connectivity Courtesy of the FREE /- _ `-/ ' Internet Software Consortium MULTIPLATFORM (/\/ \ \ /\ NetBSD 1.5.2 OS / / | ` \ \ O O ) / | +--- Currently Supported Platforms ----+ \ `-^--'`< ' | DEC ALPHA, (STRONG)ARM32, ATARI, | \ (_.) _ ) / |BEBOX, COMMODORE AMIGA & MACROSYSTEMS | `.___/` / | DRACO, HP 300, INTEL x86, APPLE | `-----' / | MACINTOSH(68k & PPC, iMAC, G3, G4), | <----. __ / __ \ | MOTOROLA MVME68k, NEWS (68k & MIPS), | <----|====O)))==) \) /==== | NeXT, PC532, PMAX, POWERPC, SUN | <----' `--' `.__,' \ | SPARC(64), SUN 3/3X, DEC VAX, X68k | | | +--------------------------------------+ \ / MORE ARE UNDER DEVELOPMENT ______( (_ / \_____ (FL) ,' ,-----' | \ ALL FTP TRANSFERS AND COMMANDS ARE LOGGED. `--{__________) \/ 230- EXPORT NOTICE Please note that portions of this FTP site contain cryptographic software controlled under the Export Administration Regulations (EAR). None of this software may be downloaded or otherwise exported or re-exported into (or to a national or resident of) Cuba, Iraq, Libya, Sudan, North Korea, Iran, Syria or any other country to which the U.S. has embargoed goods. By downloading or using said software, you are agreeing to the foregoing and you are representing and warranting that you are not located in, under the control of, or a national or resident of any such country or on any such list. 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls -la 229 Entering Extended Passive Mode (|||49196|) 150 Opening ASCII mode data connection for '/bin/ls'. total 10984 drwxr-xr-x 9 0 wheel 512 Dec 13 1999 . drwxr-xr-x 9 0 wheel 512 Dec 13 1999 .. -rw-r--r-- 1 0 wheel 611 Jun 6 2000 .message drwxr-xr-x 2 0 wheel 512 Jul 17 1999 archive dr-xr-xr-x 2 0 wheel 512 Apr 17 2001 bin drwxr-xr-x 2 0 wheel 512 Dec 25 1997 etc d--x--x--x 4 0 wheel 512 Feb 4 16:25 hidden drwx-----T 2 234 netbsd 512 Jul 16 1999 lost+found -rw-rw-r-- 1 234 netbsd 5582055 Jun 12 19:58 ls-lRA.gz drwxr-xr-x 6 0 wheel 512 Jun 20 1999 pub dr-xr-xr-x 2 0 wheel 512 Dec 25 1997 usr 226 Transfer complete. ftp> bye 221- Data traffic for this session was 0 bytes in 0 files. Total traffic for this session was 3633 bytes in 1 transfer. 221 Thank you for using the FTP service on ftp6.netbsd.org. thomas@witz:~> ---------------------------------------------------------------- Regards, Thomas Schäfer From Ronald.vanderPol@rvdp.org Fri Jun 14 08:16:42 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Fri, 14 Jun 2002 09:16:42 +0200 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <20020614010018.1ACFA7E13@beowulf.gw.com> References: <20020613231245.GA36510@rvdp.org> <20020614010018.1ACFA7E13@beowulf.gw.com> Message-ID: <20020614071642.GB36510@rvdp.org> On Thu, Jun 13, 2002 at 21:00:18 -0400, Kimmo Suominen wrote: > An MTU mismatch was identified and corrected earlier today. Ah, thanks. Now I understand what is happening. > Please try again now, and let me know how it goes. It does not work yet: bones.rvdp.org$ ftp ftp.netbsd.org Trying 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea... Connected to ftp.netbsd.org. 421 Service not available, remote server timed out. Connection closed ftp> > I can currently get a successful ftp session connected from > 3ffe:26ff:10:8003:260:8ff:fe61:f82d, but the connection just > times out from 3ffe:2900:b00c:2:250:4ff:feac:7981, like this > > beowulf:~> ftp ftp.netbsd.org > Trying 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea... > Connected to ftp.netbsd.org. > > 421 Service not available, remote server timed out. Connection closed > > The tunnel experiencing the problem is via Sprint. Does anybody have access to ftp.netbsd.org to try to ping6 from it with various fragment sizes? rvdp From simon@limmat.switch.ch Fri Jun 14 10:14:43 2002 From: simon@limmat.switch.ch (Simon Leinen) Date: 14 Jun 2002 11:14:43 +0200 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <3827.1024015867@itojun.org> References: <3827.1024015867@itojun.org> Message-ID: >>>>> On Fri, 14 Jun 2002 09:51:07 +0900, itojun@iijlab.net said: > there seems to be some config mistake within ISI (who hosts > tp.netbsd.org), regarding to link MTU setting of tunnel > interface. i heard that they have changed the config so it > should be better now. (at least, it is much better for me) Yes, but that shouldn't matter early on in the FTP session - the first packets are all quite small. By the way, for me it works fine from a Solaris 8 machine, although the problem may simply have been fixed in the meantime. I'm appending tcpdump output from a complete session. > i myself have experienced it before - Juniper sets tunnel > interface MTU to infinity, and KAME uses 1280. -- Simon Leinen simon@babar.switch.ch SWITCH http://www.switch.ch/misc/leinen/ Computers hate being anthropomorphized. 10:30:42.770049 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: S [tcp sum ok] 3717258812:3717258812(0) win 32805 (len 44, hlim 60) 10:30:42.967472 ftp6.netbsd.org.ftp > babar.switch.ch.41522: S [tcp sum ok] 4094757220:4094757220(0) ack 3717258813 win 32768 (len 40, hlim 56) 10:30:42.967502 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: . [tcp sum ok] ack 1 win 32844 (len 32, hlim 60) 10:30:43.328349 ftp6.netbsd.org.ftp > babar.switch.ch.41522: P [tcp sum ok] 1:63(62) ack 1 win 33120 [flowlabel 0xf4865] (len 94, hlim 56) 10:30:43.328382 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: . [tcp sum ok] ack 63 win 32844 (len 32, hlim 60) 10:30:46.236393 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: P [tcp sum ok] 1:11(10) ack 63 win 32844 (len 42, hlim 60) 10:30:46.432911 ftp6.netbsd.org.ftp > babar.switch.ch.41522: P [tcp sum ok] 63:112(49) ack 11 win 33120 [flowlabel 0xf4865] (len 81, hlim 56) 10:30:46.524524 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: . [tcp sum ok] ack 112 win 32844 (len 32, hlim 60) 10:30:48.130238 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: P [tcp sum ok] 11:33(22) ack 112 win 32844 (len 54, hlim 60) 10:30:48.430036 ftp6.netbsd.org.ftp > babar.switch.ch.41522: . [tcp sum ok] ack 33 win 33120 [flowlabel 0xf4865] (len 32, hlim 56) 10:30:48.471005 ftp6.netbsd.org.ftp > babar.switch.ch.41522: P [tcp sum ok] 112:118(6) ack 33 win 33120 [flowlabel 0xf4865] (len 38, hlim 56) 10:30:48.564520 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: . [tcp sum ok] ack 118 win 32844 (len 32, hlim 60) 10:30:48.585777 ftp6.netbsd.org.ftp > babar.switch.ch.41522: . [tcp sum ok] 118:1326(1208) ack 33 win 33120 [flowlabel 0xf4865] (len 1240, hlim 56) 10:30:48.684532 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: . [tcp sum ok] ack 1326 win 32844 (len 32, hlim 60) 10:30:48.886186 ftp6.netbsd.org.ftp > babar.switch.ch.41522: P [tcp sum ok] 1326:1762(436) ack 33 win 33120 [flowlabel 0xf4865] (len 468, hlim 56) 10:30:48.984524 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: . [tcp sum ok] ack 1762 win 32844 (len 32, hlim 60) 10:30:49.184436 ftp6.netbsd.org.ftp > babar.switch.ch.41522: P [tcp sum ok] 1762:2491(729) ack 33 win 33120 [flowlabel 0xf4865] (len 761, hlim 56) 10:30:49.284539 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: . [tcp sum ok] ack 2491 win 32844 (len 32, hlim 60) 10:30:50.446337 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: P [tcp sum ok] 33:39(6) ack 2491 win 32844 (len 38, hlim 60) 10:30:50.642775 ftp6.netbsd.org.ftp > babar.switch.ch.41522: P [tcp sum ok] 2491:2539(48) ack 39 win 33120 [flowlabel 0xf4865] (len 80, hlim 56) 10:30:50.643278 babar.switch.ch.41523 > ftp6.netbsd.org.49202: S [tcp sum ok] 3014599293:3014599293(0) win 32805 (len 44, hlim 60) 10:30:50.734548 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: . [tcp sum ok] ack 2539 win 32844 (len 32, hlim 60) 10:30:50.838925 ftp6.netbsd.org.49202 > babar.switch.ch.41523: S [tcp sum ok] 823416627:823416627(0) ack 3014599294 win 32768 (len 40, hlim 56) 10:30:50.838956 babar.switch.ch.41523 > ftp6.netbsd.org.49202: . [tcp sum ok] ack 1 win 32844 (len 32, hlim 60) 10:30:50.839146 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: P [tcp sum ok] 39:45(6) ack 2539 win 32844 (len 38, hlim 60) 10:30:51.039516 ftp6.netbsd.org.ftp > babar.switch.ch.41522: P [tcp sum ok] 2539:2594(55) ack 45 win 33120 [flowlabel 0xf4865] (len 87, hlim 56) 10:30:51.134569 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: . [tcp sum ok] ack 2594 win 32844 (len 32, hlim 60) 10:30:51.385422 ftp6.netbsd.org.49202 > babar.switch.ch.41523: F [tcp sum ok] 516:516(0) ack 1 win 33120 [flowlabel 0xf4866] (len 32, hlim 56) 10:30:51.385451 babar.switch.ch.41523 > ftp6.netbsd.org.49202: . [tcp sum ok] ack 1 win 32844 (len 32, hlim 60) 10:30:51.386884 ftp6.netbsd.org.ftp > babar.switch.ch.41522: P [tcp sum ok] 2594:2618(24) ack 45 win 33120 [flowlabel 0xf4865] (len 56, hlim 56) 10:30:51.389623 ftp6.netbsd.org.49202 > babar.switch.ch.41523: P [tcp sum ok] 1:516(515) ack 1 win 33120 [flowlabel 0xf4866] (len 547, hlim 56) 10:30:51.389735 babar.switch.ch.41523 > ftp6.netbsd.org.49202: . [tcp sum ok] ack 517 win 32844 (len 32, hlim 60) 10:30:51.393974 babar.switch.ch.41523 > ftp6.netbsd.org.49202: F [tcp sum ok] 1:1(0) ack 517 win 32844 (len 32, hlim 60) 10:30:51.484554 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: . [tcp sum ok] ack 2618 win 32844 (len 32, hlim 60) 10:30:51.587775 ftp6.netbsd.org.49202 > babar.switch.ch.41523: . [tcp sum ok] ack 2 win 33120 [flowlabel 0xf4866] (len 32, hlim 56) 10:30:52.120699 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: P [tcp sum ok] 45:51(6) ack 2618 win 32844 (len 38, hlim 60) 10:30:52.320393 ftp6.netbsd.org.ftp > babar.switch.ch.41522: P [tcp sum ok] 2618:2624(6) ack 51 win 33120 [flowlabel 0xf4865] (len 38, hlim 56) 10:30:52.322111 ftp6.netbsd.org.ftp > babar.switch.ch.41522: FP [tcp sum ok] 2624:2810(186) ack 51 win 33120 [flowlabel 0xf4865] (len 218, hlim 56) 10:30:52.322233 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: . [tcp sum ok] ack 2811 win 32844 (len 32, hlim 60) 10:30:52.322846 babar.switch.ch.41522 > ftp6.netbsd.org.ftp: F [tcp sum ok] 51:51(0) ack 2811 win 32844 (len 32, hlim 60) 10:30:52.518550 ftp6.netbsd.org.ftp > babar.switch.ch.41522: . [tcp sum ok] ack 52 win 33120 [flowlabel 0xf4865] (len 32, hlim 56) From pim@ipng.nl Fri Jun 14 19:13:31 2002 From: pim@ipng.nl (Pim van Pelt) Date: Fri, 14 Jun 2002 20:13:31 +0200 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <200206140351.g5E3pCk01953@lo.tech.org> References: <200206140351.g5E3pCk01953@lo.tech.org> Message-ID: <20020614181331.GC2270@bfib.colo.bit.nl> On Thu, Jun 13, 2002 at 08:51:12PM -0700, Stephen Stuart wrote: | If anyone is still having problems with TCP sessions to/from | ftp.netbsd.org, please send me traceroutes. The MTU and tunnel setttings are unrelated. A TCP handshake uses Syn/SynAck/Ack packets without payload so these should be around 50 bytes. Stephen, I still cannot reach the site, from various Dutch ISPs, such as SURFnet (AS1103), Intouch (AS8954), BIT (AS12859) and Concepts (AS12871). A typical traceroute for AS12859 would be: [HoG] /hog.mnt/vol2/rsync/bfib/www$ traceroute6 ftp.netbsd.org traceroute6 to ftp.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) from 2001:7b8:3:17:2a0:24ff:fe56:6a60, 30 hops max, 12 byte packets 1 dapje.ipv6.network.bit.nl 1.169 ms 1.117 ms 1 ms 2 c7206.sara.ams-ix.ipv6.network.bit.nl 10.336 ms 9.678 ms 10.765 ms 3 ams-ix.sara.xs4all.net 10.653 ms 13.089 ms 11.801 ms 4 Gi1-2.BR1.Amsterdam1.surf.net 13.195 ms * 10.898 ms 5 nikhef.ams-ix.ipv6.intouch.net 9.658 ms 9.855 ms 9.633 ms 6 3ffe:800::fffb:0:0:5 168.34 ms 169.399 ms * 7 3ffe:800::fff9:0:0:2 343.838 ms 278.082 ms 189.127 ms 8 3ffe:8050:ffff::fffd 181.536 ms 178.031 ms 179.648 ms 9 ftp6.netbsd.org 178.405 ms 182.943 ms 179.327 ms And directly from AS8954 (intouch.net): pim@tunnelserver:~$ traceroute6 ftp.netbsd.org traceroute6 to ftp.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) from 2001:6e0::250:4ff:fe4a:7708, 30 hops max, 16 byte packets 1 Amsterdam.core.ipv6.intouch.net (2001:6e0::2) 0.522 ms 0.423 ms 0.389 ms 2 3ffe:800::fffb:0:0:5 (3ffe:800::fffb:0:0:5) 159.983 ms * 158.36 ms 3 3ffe:800::fff9:0:0:2 (3ffe:800::fff9:0:0:2) 167.842 ms 167.723 ms 167.985 ms 4 3ffe:8050:ffff::fffd (3ffe:8050:ffff::fffd) 169.695 ms 169.222 ms 169.645 ms 5 ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) 169.245 ms 169.039 ms 169.31 ms As Ronald has also witnessed, I see Syn, then SynAck, then I send Ack and the line goes dead (does this Ack ever reach the ftp6 server?). It also raises another point, which I find quite odd. I will mail about this later. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From pim@ipng.nl Fri Jun 14 19:17:24 2002 From: pim@ipng.nl (Pim van Pelt) Date: Fri, 14 Jun 2002 20:17:24 +0200 Subject: [6bone] BGP routing 'these days' Message-ID: <20020614181724.GD2270@bfib.colo.bit.nl> hi, When I traced to the NetBSD site just now, I saw that my path to them is kind of odd. At AMS-IX, several parties peer with each other, they normally would send a full view to each other on the native IPv6 peering point. Now I wonder why it is that a packet from my network to NetBSD, goes over several of these parties: 2 c7206.sara.ams-ix.ipv6.network.bit.nl, to 3 ams-ix.sara.xs4all.net, to 4 Gi1-2.BR1.Amsterdam1.surf.net, to 5 nikhef.ams-ix.ipv6.intouch.net, to The AS path for this would be AS12859 AS3265 AS1103 AS8954 And I am dead sure that AS12859 peers with AS8954 directly, and they both exchange full views. The localpref on these routes is 100 in both cases. Anybody want to guess why this transits AS3265 and AS1103 nevertheless ? :) groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From stuart@tech.org Fri Jun 14 20:17:13 2002 From: stuart@tech.org (Stephen Stuart) Date: Fri, 14 Jun 2002 12:17:13 -0700 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: Your message of "Fri, 14 Jun 2002 20:13:31 +0200." <20020614181331.GC2270@bfib.colo.bit.nl> Message-ID: <200206141917.g5EJHDk05423@lo.tech.org> > On Thu, Jun 13, 2002 at 08:51:12PM -0700, Stephen Stuart wrote: > | If anyone is still having problems with TCP sessions to/from > | ftp.netbsd.org, please send me traceroutes. > > The MTU and tunnel setttings are unrelated. A TCP handshake uses > Syn/SynAck/Ack packets without payload so these should be around 50 > bytes. I understand that. ISC receives routes from two sources: peers on the PAIX Palo Alto switch fabric, and a tunnel to ISI. I would like to determine if the people having problems share some property relating to that, like "people who still report problems all show the ISI tunnel in their traceroute." > Stephen, I still cannot reach the site, from various Dutch ISPs, such as > SURFnet (AS1103), Intouch (AS8954), BIT (AS12859) and Concepts > (AS12871). [traceroutes] The traceroutes you sent were helpful, as they all show the ISI tunnel in the traceroute. The problem showed up as the result of two variables in our network changing: our Palo Alto router changed from Cisco to Juniper, and our Redwood City router changed from Cisco to FreeBSD/zebra (this is not to be taken as a reflection on Cisco, the change was necessary for other reasons). To further comment on your observation regarding TCP - yes, the handshake is small, and in an environment where MTU mismatch would cause problems with larger packet sizes, a TCP session would tend to start and then hang, as the window size ramps up and datagram sizes approach interface MTU size. As was correctly noted by itojun, when the *interior* tunnel MTU sizes did not match, everyone suffered (including the iBGP session between the routers); when the MTUs were aligned in the manner that itojun noted (the Juniper was brought down to FreeBSD's setting) connectivity for some improved. Remaining problems *seem* to have the ISI tunnel in common. Interface MTU size on the tunnel interface toward the ISI router has now been matched, just as with the interior tunnel interface. > As Ronald has also witnessed, I see Syn, then SynAck, then I send Ack > and the line goes dead (does this Ack ever reach the ftp6 server?). That is an excellent question. I am not a member of the NetBSD development team, and I do not have access to their box to determine conclusively whether the ack really gets there. I can run tcpdump on the router immediately upstream to see if it is attempting to deliver it. If someone still having issues would like to coordinate a debugging session to look at that, please contact me privately. Stephen From stuart@tech.org Fri Jun 14 20:24:09 2002 From: stuart@tech.org (Stephen Stuart) Date: Fri, 14 Jun 2002 12:24:09 -0700 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: Your message of "Fri, 14 Jun 2002 04:58:11 +0200." <001b01c2134f$523033b0$420d640a@unfix.org> Message-ID: <200206141924.g5EJO9k05478@lo.tech.org> > Let's try again from purgatory.unfix.org: ftp.netbsd.org's path to purgatory.unfix.org traverses the ISC-ISI tunnel mentioned in my recent mail. Stephen From kim@tac.nyc.ny.us Fri Jun 14 20:49:16 2002 From: kim@tac.nyc.ny.us (Kimmo Suominen) Date: Fri, 14 Jun 2002 15:49:16 -0400 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <200206141917.g5EJHDk05423@lo.tech.org> from Stephen Stuart on Fri, 14 Jun 2002 12:17:13 -0700 References: <200206141917.g5EJHDk05423@lo.tech.org> Message-ID: <20020614194916.388177E10@beowulf.gw.com> The problem still exists for me. Below are the traceroutes for each direction and tcpdumps of an attempt. The tcpdump was a bit odd -- I kept seeing packets from beowulf to the ftp server even after I killed the ftp process (and I didn't see any other ftp processes on the machine). + Kim beowulf:~> ftp ftp.netbsd.org Trying 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea... Connected to ftp.netbsd.org. 421 Service not available, remote server timed out. Connection closed ftp> ^D beowulf:~> traceroute6 -q1 -w2 ftp.netbsd.org traceroute6 to ftp.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) from 3ffe:2900:b00c:2:250:4ff:feac:7981, 30 hops max, 12 byte packets 1 dit 0.57 ms 2 sl-bb1v6-rly-t-48.sprintv6.net 24.104 ms 3 2001:440:1239:1007::2 79.704 ms 4 2001:440:1239:1007::2 79.998 ms 5 3ffe:800::fff9:0:0:2 102.131 ms 6 3ffe:800::fff9:0:0:2 100.058 ms 7 ftp6.netbsd.org 103.044 ms nbftp:~> traceroute6 -q1 -w2 beowulf.gw.com traceroute6 to beowulf.gw.com (3ffe:2900:b00c:2:250:4ff:feac:7981) from 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea, 30 hops max, 12 byte packets 1 3ffe:8050:201:1860:200:f8ff:fe02:9a03 0.554 ms 2 3ffe:8050:ffff::fffe 1.624 ms 3 3ffe:800::fff9:0:0:1 11.548 ms 4 2001:478:ffff::a 21.554 ms 5 2001:440:1239:1007::1 22.501 ms 6 3ffe:2900:b:7::2 103.124 ms 7 3ffe:2900:b:7::2 101.241 ms 8 beowulf.gw.com 102.321 ms beowulf:~# tcpdump -i ex0 ip6 host ftp.netbsd.org tcpdump: listening on ex0 15:43:00.489420 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: S 3455727996:3455727996(0) win 16384 [flowlabel 0x3ef7f] 15:43:00.590674 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: S 3623584296:3623584296(0) ack 3455727997 win 32768 15:43:00.590852 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: . ack 1 win 16384 [flowlabel 0x3ef7f] 15:43:12.350259 beowulf.gw.com.49385 > ftp6.netbsd.org.ftp: F 450414700:450414700(0) ack 1762195173 win 16384 [flowlabel 0x3ef7d] 15:44:00.602554 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 15:44:01.602081 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 15:44:03.602073 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 15:44:07.602303 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 15:44:15.602535 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 15:44:16.352526 beowulf.gw.com.49385 > ftp6.netbsd.org.ftp: F 0:0(0) ack 1 win 16384 [flowlabel 0x3ef7d] 15:44:31.603116 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 15:45:03.604328 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] ^C 1085 packets received by filter 0 packets dropped by kernel nbftp:~# tcpdump -i fxp0 ip6 host beowulf.gw.com tcpdump: listening on fxp0 12:43:00.374725 ftp6.netbsd.org.ftp > beowulf.gw.com.49385: FP 1762195173:1762195272(99) ack 450414701 win 33120 [flowlabel 0xf496c] 12:43:00.534959 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: S 3455727996:3455727996(0) win 16384 [flowlabel 0x3ef7f] 12:43:00.535158 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: S 3623584296:3623584296(0) ack 3455727997 win 32768 12:43:00.634521 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: . ack 1 win 16384 [flowlabel 0x3ef7f] 12:43:00.657402 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: P 1:63(62) ack 1 win 33120 [flowlabel 0xf496d] 12:43:01.374715 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: P 1:63(62) ack 1 win 33120 [flowlabel 0xf496d] 12:43:03.374581 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: P 1:63(62) ack 1 win 33120 [flowlabel 0xf496d] 12:43:07.374813 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: P 1:63(62) ack 1 win 33120 [flowlabel 0xf496d] 12:43:12.394908 beowulf.gw.com.49385 > ftp6.netbsd.org.ftp: F 0:0(0) ack 0 win 16384 [flowlabel 0x3ef7d] 12:43:12.394995 ftp6.netbsd.org.ftp > beowulf.gw.com.49385: . ack 1 win 33120 [flowlabel 0xf496c] 12:43:15.374745 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: P 1:63(62) ack 1 win 33120 [flowlabel 0xf496d] 12:43:31.374797 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: P 1:63(62) ack 1 win 33120 [flowlabel 0xf496d] 12:44:00.646781 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 12:44:00.646872 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: . ack 2 win 33120 [flowlabel 0xf496d] 12:44:00.647275 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: FP 63:100(37) ack 2 win 33120 [flowlabel 0xf496d] 12:44:01.646876 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 12:44:01.646966 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: . ack 2 win 33120 [flowlabel 0xf496d] 12:44:03.374476 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: FP 1:100(99) ack 2 win 33120 [flowlabel 0xf496d] 12:44:03.646448 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 12:44:03.646523 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: . ack 2 win 33120 [flowlabel 0xf496d] 12:44:04.374417 ftp6.netbsd.org.ftp > beowulf.gw.com.49385: FP 0:99(99) ack 1 win 33120 [flowlabel 0xf496c] 12:44:07.647571 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 12:44:07.647649 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: . ack 2 win 33120 [flowlabel 0xf496d] 12:44:15.646881 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 12:44:15.646961 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: FP 1:100(99) ack 2 win 33120 [flowlabel 0xf496d] 12:44:16.396892 beowulf.gw.com.49385 > ftp6.netbsd.org.ftp: F 0:0(0) ack 0 win 16384 [flowlabel 0x3ef7d] 12:44:16.396983 ftp6.netbsd.org.ftp > beowulf.gw.com.49385: . ack 1 win 33120 [flowlabel 0xf496c] 12:44:31.648395 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 12:44:31.648548 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: . ack 2 win 33120 [flowlabel 0xf496d] 12:45:03.648837 beowulf.gw.com.49386 > ftp6.netbsd.org.ftp: F 1:1(0) ack 1 win 16384 [flowlabel 0x3ef7f] 12:45:03.648911 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: . ack 2 win 33120 [flowlabel 0xf496d] 12:45:08.373946 ftp6.netbsd.org.ftp > beowulf.gw.com.49385: FP 0:99(99) ack 1 win 33120 [flowlabel 0xf496c] 12:45:19.373862 ftp6.netbsd.org.ftp > beowulf.gw.com.49386: FP 1:100(99) ack 2 win 33120 [flowlabel 0xf496d] 12:45:20.399057 beowulf.gw.com.49385 > ftp6.netbsd.org.ftp: F 0:0(0) ack 0 win 16384 [flowlabel 0x3ef7d] 12:45:20.399138 ftp6.netbsd.org.ftp > beowulf.gw.com.49385: . ack 1 win 33120 [flowlabel 0xf496c] ^C 250449 packets received by filter 0 packets dropped by kernel | From: Stephen Stuart | Date: Fri, 14 Jun 2002 12:17:13 -0700 | | Remaining problems *seem* to have the ISI tunnel in common. Interface | MTU size on the tunnel interface toward the ISI router has now been | matched, just as with the interior tunnel interface. From gnea@garson.org Fri Jun 14 20:51:04 2002 From: gnea@garson.org (Scott Prader) Date: Fri, 14 Jun 2002 15:51:04 -0400 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <200206140835.52758.mail@thomas--schaefer.de> References: <200206140835.52758.mail@thomas--schaefer.de> Message-ID: <20020614195104.GA2498@gnea.net> Indeed, the following from a Debian (unstable release) setup through freenet6: [gnea@garson] [~] telnet -6 ftp6.netbsd.org 21 Trying 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea... Connected to ftp6.netbsd.org. Escape character is '^]'. 220 ftp6.netbsd.org FTP server (NetBSD-ftpd 20020201) ready. user anonymous 331 Guest login ok, type your name as password. pass gnea@garson.org 230- Welcome to FTP.NetBSD.ORG Located in Palo Alto, CA, USA , , /( )` -----------yada! [gnea@garson] [~] traceroute6 ftp6.netbsd.org traceroute to ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) from 3ffe:b80:2:9109::2, 30 hops max, 16 byte packets 1 3ffe:b80:2:9109::1 (3ffe:b80:2:9109::1) 236.375 ms 177.293 ms 149.612 ms 2 3ffe:8000:ffff:b::2 (3ffe:8000:ffff:b::2) 95.14 ms 206.992 ms 98.79 ms 3 3ffe:b00:c18::6b (3ffe:b00:c18::6b) 218.926 ms 252.254 ms 191.161 ms 4 paix-tunnel.fmt.ipv6.he.net (3ffe:81d0:ffff:1::1) 172.006 ms 231.26 ms 191.508 ms 5 paix-v6.isc.org (3ffe:80a::1) 212.827 ms 254.686 ms 219.655 ms 6 3ffe:8050:ffff::fffd (3ffe:8050:ffff::fffd) 286.989 ms 199.393 ms 285.002 ms 7 ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) 246.178 ms 274.975 ms 316.906 ms -----------yada! lftp seems to work to connect, but as soon as i attempt an ls, it segfaults: [gnea@garson] [~] grep dns .lftprc set dns:order inet6 inet [gnea@garson] [~] lftp lftp :~> o ftp6.netbsd.org lftp ftp6.netbsd.org:~> cd . cd ok, cwd=/ lftp ftp6.netbsd.org:/> ls Segmentation fault [gnea@garson] [~] I'll need to sit down and debug this later or see if there is a new version around the corner which fixes that, it's not a very big concern at this point in time. OTOH, it could be a malformed option set in .lftprc * Thomas Schaefer (mail@thomas--schaefer.de) cobbled forth: > And now it seems to work very well: > ----------------------------------------------- > thomas@witz:~> nslookup -query=any ftp.netbsd.org > Note: nslookup is deprecated and may be removed from future releases. > Consider using the `dig' or `host' programs instead. Run nslookup with > the `-sil[ent]' option to prevent this message from appearing. > Server: 212.185.252.201 > Address: 212.185.252.201#53 > > Name: ftp.netbsd.org > Address: 204.152.184.75 > ftp.netbsd.org has AAAA address 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea .oO Gnea [gnea at garson dot org] Oo. .oO url [http://gnea.net] Oo. "You can tune a filesystem, but you can't tune a fish." -Kirk McKusick From rogerj@student.uit.no Fri Jun 14 22:26:38 2002 From: rogerj@student.uit.no (Roger Jorgensen) Date: Fri, 14 Jun 2002 23:26:38 +0200 (CEST) Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <200206141917.g5EJHDk05423@lo.tech.org> Message-ID: On Fri, 14 Jun 2002, Stephen Stuart wrote: > > On Thu, Jun 13, 2002 at 08:51:12PM -0700, Stephen Stuart wrote: > > | If anyone is still having problems with TCP sessions to/from > > | ftp.netbsd.org, please send me traceroutes. > > > > The MTU and tunnel setttings are unrelated. A TCP handshake uses > > Syn/SynAck/Ack packets without payload so these should be around 50 > > bytes. > > I understand that. > > ISC receives routes from two sources: peers on the PAIX Palo Alto > switch fabric, and a tunnel to ISI. I would like to determine if the > people having problems share some property relating to that, like > "people who still report problems all show the ISI tunnel in their > traceroute." I've tried it from several machines, and sites and they all use the same route: 2 2001:730::1:2f (2001:730::1:2f) 157.299 ms 156.369 ms 155.876 ms 3 paix-tunnel.fmt.ipv6.he.net (3ffe:81d0:ffff:1::1) 161.154 ms 158.577 ms 159.025 ms 4 3ffe:80a::1 (3ffe:80a::1) 351.493 ms 231.817 ms 224.404 ms 5 3ffe:8050:ffff::fffd (3ffe:8050:ffff::fffd) 173.924 ms 169.901 ms 169.360 ms 6 ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) 169.013 ms * 169.903 ms zero problems for any of them, except two solaris boxes that couldn't connect at all to ftp.netbsd.org. However, those two solaris boxes worked fine when I ftp'ed to ftp.pasta.cs.uit.no (3ffe:2a00:100:3001::2) ... ------------------------------ Roger Jorgensen | IRC: James_B rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no ------------------------------------------------------- From stuart@tech.org Fri Jun 14 23:27:37 2002 From: stuart@tech.org (Stephen Stuart) Date: Fri, 14 Jun 2002 15:27:37 -0700 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: Your message of "Fri, 14 Jun 2002 15:49:16 EDT." <20020614194916.388177E10@beowulf.gw.com> Message-ID: <200206142227.g5EMRbk06200@lo.tech.org> > The problem still exists for me. > > Below are the traceroutes for each direction and tcpdumps of an attempt. I have a traceroute running on the router to watch for beowulf.gw.com; please try an FTP session again. > The tcpdump was a bit odd -- I kept seeing packets from beowulf to the > ftp server even after I killed the ftp process (and I didn't see any > other ftp processes on the machine). Probably just trying to tidy up the closed TCP session. Stephen From stuart@tech.org Fri Jun 14 23:29:12 2002 From: stuart@tech.org (Stephen Stuart) Date: Fri, 14 Jun 2002 15:29:12 -0700 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: Your message of "Fri, 14 Jun 2002 15:27:37 PDT." Message-ID: <200206142229.g5EMTCk06224@lo.tech.org> > > The problem still exists for me. > > > > Below are the traceroutes for each direction and tcpdumps of an attempt. > > I have a traceroute running on the router to watch for beowulf.gw.com; > please try an FTP session again. Sigh. s/traceroute/tcpdump/. Stephen From fink@es.net Sat Jun 15 00:46:18 2002 From: fink@es.net (Bob Fink) Date: Fri, 14 Jun 2002 16:46:18 -0700 Subject: [6bone] recent illegal inet6num registry Message-ID: <5.1.0.14.0.20020614164056.02a68148@imap2.es.net> I just wanted to conclude this particular illegal inet6num registry with a report that after discussing it with Mr. Amaury Dailliez, who is the Technical Manager of AzurVP Network France, I am convinced this was just an honest mistake of someone trying to figure out how to setup a legitimate inet6num entry. He is quite embarrassed about it and says he has never used the prefix in any way. Anyway, the bogus entry is removed and I believe we should treat Mr. Dailliez as a citizen of the 6bone in good standing. I certainly believe he is. Thanks, Bob Fink From fink@es.net Sat Jun 15 08:02:18 2002 From: fink@es.net (Bob Fink) Date: Sat, 15 Jun 2002 00:02:18 -0700 Subject: [6bone] pTLA request EURNETCITY - review closes 28 June 2002 Message-ID: <5.1.0.14.0.20020614235339.02a74488@imap2.es.net> 6bone Folk, EURNETCITY has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 28 June 2002. Please send your comments to me or the list. Thanks, Bob === >From: "Ferdinando Porcu" >To: >Subject: pTLA request for EURNetCity (AS20794) >Date: Wed, 12 Jun 2002 18:21:08 +0200 > >Hi Bob and 6bone members, > >On behalf of EURNetCity, I would like to submit our application for a pTLA. > >1. The pTLA Applicant must have a minimum of three (3) months > qualifying experience as a 6Bone end-site or pNLA transit. > >We are connected to the 6bone since Feb 2002 with a /48 from VIAGENIE. > >During the entire qualifying period the Applicant must be operationally >providing the following: > >a. Fully maintained, up to date, 6Bone Registry entries for their >ipv6-site inet6num, mntner, and person objects, including each >tunnel that the Applicant has. > >Our records on the 6bone database are up to date. >http://whois.6bone.net/cgi-bin/whois?eurnet-mnt >http://whois.6bone.net/cgi-bin/whois?eurnetcity > >b. Fully maintained, and reliable, BGP4+ peering and connectivity >between the Applicant's boundary router and the appropriate >connection point into the 6Bone. This router must be IPv6 >pingable. This criteria is judged by members of the 6Bone >Operations Group at the time of the Applicant's pTLA request. > >We have currently 3 BGP4+ peering sessions (CSELT and >RMNet) on a Juniper M10 Router > >c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) >entries for the Applicant's router(s) and at least one host >system. > >DNS server : dns.ipv6.eurnetcity.net - 3ffe:b80:731:1:2d0:b7ff:feaa:9bbb > >d. A fully maintained, and reliable, IPv6-accessible system >providing, at a mimimum, one or more web pages, describing the >Applicant's IPv6 services. This server must be IPv6 pingable. > >IPv6 Web server is at: http://www.ipv6.eurnetcity.net and is pingable > >2. The pTLA Applicant MUST have the ability and intent to provide > "production-quality" 6Bone backbone service. Applicants must > provide a statement and information in support of this claim. > This MUST include the following: > > a. A support staff of two persons minimum, three preferable, with > person attributes registered for each in the ipv6-site object > for the pTLA applicant. > >We have a mail entry to the group of technical people at: >network@eurnetcity.net >Tech persons on charge of IPv6 support are: >http://whois.6bone.net/cgi-bin/whois?FP4-6BONE >http://whois.6bone.net/cgi-bin/whois?FA3-6BONE > > b. A common mailbox for support contact purposes that all support > staff have acess to, pointed to with a notify attribute in the > ipv6-site object for the pTLA Applicant. > >The staff has access to the common mailbox: network@eurnetcity.net >3. The pTLA Applicant MUST have a potential "user community" that > would be served by its becoming a pTLA, e.g., the Applicant is a > major provider of Internet service in a region, country, or focus > of interest. Applicant must provide a statement and information in > support this claim. > >Eurnetcity will serve business and residential users in Rome Area for >broadband services such as >VoD, VoIP and internet traffic using his optical metro network to deliver >it. >We are actually offering our commercial services through PSTN and ISDN >dialup, dedicated lines, ADSL lines and colocation. >Our users base is about 1000 home-users and 100 enterprises > >4. The pTLA Applicant MUST commit to abide by the current 6Bone > operational rules and policies as they exist at time of its > application, and agree to abide by future 6Bone backbone > operational rules and policies as they evolve by consensus of the > 6Bone backbone and user community. > >We fully agree to all current and future operational rules and policies. > >When an Applicant seeks to receive a pTLA allocation, it will apply >to the 6Bone Operations Group (see section 8 below) by providing to >the Group information in support of its claims that it meets the >criteria above. > > >Best regards, >-- > >---------------------------------------------------------------- >Ferdinando Porcu > >Eurnetcity S.p.A. >Eurnetcity e' una iniziativa di Eur S.p.A. e Gruppo Acea >Resp. Servizi IP >Via Ciro il Grande, 16 >00144 ROMA > >Tel. +39.(0)6.5425.2268 >Fax +39.(0)6.5425.2055 >http://www.eurnetcity.it >http://www.eurnetcity.net >fporcu@eurnetcity.net >---------------------------------------------------------------------------- >------------------------------ >This communication contains information which is confidential and >may also privileged. It is for the exclusive use of the indented >recipient(s). If you are not the intended recipient(s), please note >that any distribution, copying or use of this communication or the >information in it is stricly prohibited. If you have received this >communication in error, please notify the sender immediately >and then destroy any copies of it. >---------------------------------------------------------------------------- >----------------- From pim@ipng.nl Sat Jun 15 09:35:46 2002 From: pim@ipng.nl (Pim van Pelt) Date: Sat, 15 Jun 2002 10:35:46 +0200 Subject: [6bone] whois and mnt-lower Message-ID: <20020615083546.GA24977@bfib.colo.bit.nl> Hi What are the current thoughts of the WHOIS database maintainers (and its software engineers) on the insertion of a maintained object for the 3ffe::/16 (or even 0::/0) range, and delegate mnt-lower to each company that received a pTLA allocation. This will take care of the problem Jeroen mentioned, and the apparent honest mistake Amaury's engineering team made. I for one would very much like to see this database cleaned up a bit more. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From fink@es.net Sat Jun 15 16:01:58 2002 From: fink@es.net (Bob Fink) Date: Sat, 15 Jun 2002 08:01:58 -0700 Subject: [6bone] whois and mnt-lower In-Reply-To: <20020615083546.GA24977@bfib.colo.bit.nl> Message-ID: <5.1.0.14.0.20020615075623.02a33a60@imap2.es.net> Pim, At 10:35 AM 6/15/2002 +0200, Pim van Pelt wrote: >Hi > >What are the current thoughts of the WHOIS database maintainers (and its >software engineers) on the insertion of a maintained object for the >3ffe::/16 (or even 0::/0) range, and delegate mnt-lower to each company >that received a pTLA allocation. > >This will take care of the problem Jeroen mentioned, and the apparent >honest mistake Amaury's engineering team made. > >I for one would very much like to see this database cleaned up a bit >more. There has been a 3FFE::/16 inet6num for the 6bone for some time (see below). We have not wanted to get into extended discussions, about what you suggest above, on the list to avoid attracting overmuch interest, however, David and I are discussing various approaches (including yours) and will eventually let the list know what's reasonable for us to do. Thanks, Bob === % RIPEdb(3.0.0b2) with ISI RPSL extensions inet6num: 3FFE::/16 netname: 6BONE descr: Test Address Space for the 6bone country: AR AT AU BE BG BR CA CM CN CZ DE DK EE ES FI FR GB GR HK HU IE IN IT JP KR KZ LT MX MY NL NO NZ PL PT RO RU SE SG SI SK TW UA US UY ZA admin-c: RLF1-6BONE tech-c: BM2-6BONE tech-c: DK13-RIPE rev-srv: ns.isi.edu rev-srv: imag.imag.fr remarks: contact RLF1-6BONE for allocation of a pTLA contact BM2-6BONE for reverse delegations contact DK13-RIPE for issues regarding the 6bone registry changed netname to 6bone remarks: This object is automatically converted from the RIPE181 registry mnt-by: RLF1-6BONE changed: davidk@ISI.EDU 19970908 changed: rlfink@lbl.gov 19970909 changed: fink@es.net 20000521 changed: fink@es.net 20000712 changed: auto-dbm@whois.6bone.net 20010117 source: 6BONE ipv6-site: 6BONE origin: AS293 descr: IETF NGTRANS Working Group IPv6 Testbed prefix: 3FFE::/16 contact: RLF1-6BONE remarks: This object is automatically converted from the RIPE181 registry url: http://www.6bone.net notify: fink@es.net mnt-by: RLF1-6BONE changed: fink@es.net 20001128 changed: auto-dbm@whois.6bone.net 20010117 source: 6BONE person: Robert L. Fink address: ESnet - Lawrence Berkeley National Laboratory phone: +1 510 486 5692 e-mail: fink@es.net nic-hdl: RLF1-6BONE remarks: change to my esnet email address remarks: This object is automatically converted from the RIPE181 registry notify: fink@es.net mnt-by: RLF1-6BONE changed: fink@es.net 19991206 changed: fink@es.net 20000521 changed: auto-dbm@whois.6bone.net 20010117 source: 6BONE person: Bill Manning address: po 12317, mdr, ca. usa phone: +1.310.322.8102 e-mail: bmanning@isi.edu nic-hdl: BM2-6BONE remarks: This object is automatically converted from the RIPE181 registry notify: bmanning@isi.edu changed: bmanning@isi.edu 19970401 changed: auto-dbm@whois.6bone.net 20010117 source: 6BONE -end From Ronald.vanderPol@rvdp.org Mon Jun 17 09:56:33 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Mon, 17 Jun 2002 10:56:33 +0200 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <200206141917.g5EJHDk05423@lo.tech.org> References: <20020614181331.GC2270@bfib.colo.bit.nl> <200206141917.g5EJHDk05423@lo.tech.org> Message-ID: <20020617085633.GB1463@rvdp.org> On Fri, Jun 14, 2002 at 12:17:13 -0700, Stephen Stuart wrote: > If someone still having issues would like to coordinate a > debugging session to look at that, please contact me privately. It is working for me now, but the path has changed. It used to be: spock$ traceroute6 -q 1 -l ftp.netbsd.org traceroute6 to ftp.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) from 2001:610:508:1001:260:1dff:fef6:7ff9, 30 hops max, 12 byte packets 1 kirk (2001:610:508:1001:220:afff:fec6:4faa) 3.201 ms 2 surrogate.ipv6.surfnet.nl (2001:610:508:1000::1) 7.9 ms 3 surfnet-bv.Amsterdam.ipv6.surf.net (2001:610:0:2001::1) 13.627 ms 4 PO4-0.CR2.Amsterdam1.surf.net (2001:610:16:3048::49) 16.897 ms 5 PO0-0.BR2.Amsterdam1.surf.net (2001:610:16:6004::6) 15.136 ms 6 ams-ix.sara.xs4all.net (2001:7f8:1::a500:3265:1) 13.938 ms 7 nikhef.ams-ix.ipv6.intouch.net (2001:7f8:1::a500:8954:1) 12.436 ms 8 3ffe:1280:1001:1::1 (3ffe:1280:1001:1::1) 382.62 ms 9 3ffe:80a::1 (3ffe:80a::1) 203.762 ms 10 3ffe:8050:ffff::fffd (3ffe:8050:ffff::fffd) 204.275 ms 11 ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) 306.499 ms Which did not work. Now it works with the path: bones.rvdp.org$ traceroute6 -q1 -l ftp.netbsd.org traceroute6 to ftp.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) from 2001:610:508:1001:202:2dff:fe0f:7d1, 64 hops max, 12 byte packets 1 2001:610:508:1001::1 (2001:610:508:1001::1) 5.074 ms 2 surrogate.ipv6.surfnet.nl (2001:610:508:1000::1) 41.915 ms 3 surfnet-bv.Amsterdam.ipv6.surf.net (2001:610:0:2001::1) 20.911 ms 4 PO4-0.CR2.Amsterdam2.surf.net (2001:610:16:5048::49) 35.221 ms 5 Gi0-0.AR1.Amsterdam2.surf.net (2001:610:16:5060::62) 38.964 ms 6 3ffe:2200:0:8000::1 (3ffe:2200:0:8000::1) 150.217 ms 7 aads-tunnel.fmt.ipv6.he.net (3ffe:81d0:ffff:1::3) 222.045 ms 8 paix-tunnel.fmt.ipv6.he.net (3ffe:81d0:ffff:1::1) 230.037 ms 9 3ffe:80a::1 (3ffe:80a::1) 212.591 ms 10 3ffe:8050:ffff::fffd (3ffe:8050:ffff::fffd) 233.241 ms 11 ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) 255.217 ms bones.rvdp.org$ Notice the last three hops of the path are the same: 9 3ffe:80a::1 (3ffe:80a::1) 203.762 ms 10 3ffe:8050:ffff::fffd (3ffe:8050:ffff::fffd) 204.275 ms 11 ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) 306.499 ms rvdp From kim@tac.nyc.ny.us Mon Jun 17 13:36:46 2002 From: kim@tac.nyc.ny.us (Kimmo Suominen) Date: Mon, 17 Jun 2002 08:36:46 -0400 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <20020617085633.GB1463@rvdp.org> from Ronald van der Pol on Mon, 17 Jun 2002 10:56:33 +0200 References: <20020614181331.GC2270@bfib.colo.bit.nl> <200206141917.g5EJHDk05423@lo.tech.org> <20020617085633.GB1463@rvdp.org> Message-ID: <20020617123646.5395C7E57@beowulf.gw.com> Same thing here -- connecting works fine, but the path has switched to go through he.net. + Kim | From: Ronald van der Pol | Date: Mon, 17 Jun 2002 10:56:33 +0200 | | On Fri, Jun 14, 2002 at 12:17:13 -0700, Stephen Stuart wrote: | | > If someone still having issues would like to coordinate a | > debugging session to look at that, please contact me privately. | | It is working for me now, but the path has changed. It used to be: [...snip...] From jon@jons.org Mon Jun 17 14:22:04 2002 From: jon@jons.org (Jon Christopherson) Date: Mon, 17 Jun 2002 06:22:04 -0700 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <20020617123646.5395C7E57@beowulf.gw.com> Message-ID: <000001c21601$fc255a80$19a14fc7@exodus> All Looks good from my end as well: ~ >traceroute6 -q1 -l ftp.netbsd.org traceroute6 to ftp.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) from 3ffe:c00:803d:2::2, 30 hops max, 12 byte packets 1 enigma (3ffe:c00:803d:2::1) 0.408 ms 2 3ffe:c00:8023:46::1 (3ffe:c00:8023:46::1) 28.688 ms 3 paix-tunnel.fmt.ipv6.he.net (3ffe:81d0:ffff:1::1) 39.49 ms 4 3ffe:80a::1 (3ffe:80a::1) 43.152 ms 5 3ffe:8050:ffff::fffd (3ffe:8050:ffff::fffd) 42.99 ms 6 ftp6.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) 42.044 ms Thanks! -jon -----Original Message----- From: 6bone-admin@mailman.isi.edu [mailto:6bone-admin@mailman.isi.edu] On Behalf Of Kimmo Suominen Sent: Monday, June 17, 2002 5:37 AM To: Ronald van der Pol Cc: Stephen Stuart; Pim van Pelt; 6bone@mailman.isi.edu Subject: Re: [6bone] problem with ftp.netbsd.org Same thing here -- connecting works fine, but the path has switched to go through he.net. + Kim | From: Ronald van der Pol | Date: Mon, 17 Jun 2002 10:56:33 +0200 | | On Fri, Jun 14, 2002 at 12:17:13 -0700, Stephen Stuart wrote: | | > If someone still having issues would like to coordinate a | > debugging session to look at that, please contact me privately. | | It is working for me now, but the path has changed. It used to be: [...snip...] _______________________________________________ 6bone mailing list 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone From jeroen@unfix.org Mon Jun 17 15:25:20 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Mon, 17 Jun 2002 16:25:20 +0200 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: <20020617085633.GB1463@rvdp.org> Message-ID: <001b01c2160a$d0c683b0$420d640a@unfix.org> Ronald van der Pol wrote: > On Fri, Jun 14, 2002 at 12:17:13 -0700, Stephen Stuart wrote: > > > If someone still having issues would like to coordinate a > > debugging session to look at that, please contact me privately. > Now going over he.net for me also. 8<------------------ jeroen@purgatory:~$ traceroute6 ftp.netbsd.org traceroute6 to ftp.netbsd.org (3ffe:8050:201:1860:2a0:c9ff:feed:b7ea) from 3ffe:8114:1000::27, 30 hops max, 12 byte packets 1 tunnel-026.ipng.nl 19.711 ms 18.527 ms 18.866 ms 2 Amsterdam.core.ipv6.intouch.net 19.779 ms 19.829 ms 19.759 ms 3 3ffe:c00:8023:1f::1 158.658 ms 159.031 ms 158.896 ms 4 paix-tunnel.fmt.ipv6.he.net 187.316 ms 184.295 ms 179.761 ms 5 paix-v6.isc.org 175.072 ms 179.622 ms 183.888 ms 6 3ffe:8050:ffff::fffd 182.342 ms 198.789 ms 207.795 ms 7 ftp6.netbsd.org 213.099 ms 224.759 ms 212.57 ms ------------------>8 And it now nicely works: 8<------------------ jeroen@purgatory:~$ telnet ftp.netbsd.org 21 Trying 3ffe:8050:201:1860:2a0:c9ff:feed:b7ea... Connected to ftp.netbsd.org. Escape character is '^]'. 220 ftp6.netbsd.org FTP server (NetBSD-ftpd 20020201) ready. ^] telnet> q ------------------>8 :) Greets, Jeroen From fink@es.net Mon Jun 17 15:25:38 2002 From: fink@es.net (Bob Fink) Date: Mon, 17 Jun 2002 07:25:38 -0700 Subject: [6bone] 6bone pTLA 3FFE:400B::/32 allocated to INET-TH Message-ID: <5.1.0.14.0.20020617071847.02982598@imap2.es.net> INET-TH has been allocated pTLA 3FFE:400B::/32 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to hostmaster@ep.net.] Thanks, Bob From todd@fries.net Mon Jun 17 16:10:25 2002 From: todd@fries.net (Todd T. Fries) Date: Mon, 17 Jun 2002 10:10:25 -0500 Subject: [6bone] Re: Got one IPV6 address from Freenet6 but not working. In-Reply-To: <3CD3F2B3.2000107@cisco.com> References: <3CD3F2B3.2000107@cisco.com> Message-ID: <20020617151025.GA27722@fries.net> Fwiw, itojun has recently found a problem with kdelibs that disabled getaddrinfo for most systems due to an absent memset in the configure script. Currently, this is fixed in the OpenBSD ports tree and the current cvs repository, but unfortunately not before 3.0.1 went out. -- Todd Fries .. todd@fries.net (last updated $ToddFries: signature.p,v 1.2 2002/03/19 15:10:18 todd Exp $) Penned by Paul Aitken on Sat, May 04, 2002 at 03:39:47PM +0100, we have: | Tapas, | | >I have got a IPV6 address from Freenet6. I can also ping to few of the | >IPV6 address, but when I goto www.kame.net i don't see the dancing | >turtle also at the end of the page it says "you are using IPv4",can | >somebody explain me why is this happening. | | Most likely your DNS is resolving www.kame.net into an IPv4 address. Use | a browser that supports IPv6 and a DNS server that supports AAAA records. | | Cheers. | -- | Paul Aitken | IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX | From stuart@tech.org Mon Jun 17 17:37:28 2002 From: stuart@tech.org (Stephen Stuart) Date: Mon, 17 Jun 2002 09:37:28 -0700 Subject: [6bone] problem with ftp.netbsd.org In-Reply-To: Your message of "Mon, 17 Jun 2002 16:25:20 +0200." <001b01c2160a$d0c683b0$420d640a@unfix.org> Message-ID: <200206171637.g5HGbSk18582@lo.tech.org> Late on Friday I depref'd from and prepended toward ISI (from ISC). That shifted the traffic to/from ISC's PAIX peers (like the nice folks at Hurricane Electric). Stephen From ww@GROOVY.NET Mon Jun 17 17:45:59 2002 From: ww@GROOVY.NET (ww@GROOVY.NET) Date: Mon, 17 Jun 2002 12:45:59 -0400 Subject: [6bone] Exchange Point Addresses Message-ID: <20020617124559.A13931@GROOVY.NET> Hi, At the Toronto Internet Exchange (TORIX) we've been talking about making it possible to peer natively over IPv6. The problem is getting addresses for the exchange -- RIPE seems to have a clear policy (they'll hand out a /64), but ARIN doesn't appear to. It would not be appropriate to use addresses from one of the providers at the exchange since TORIX has been, since its inception, provider neutral and we'd like to keep it that way. Any suggestions or pointers to how to go about acquiring some numbers for the exchange would be appreciated. Thanks, -w -- Will Waites ww@groovy.net From pim@ipng.nl Mon Jun 17 19:18:41 2002 From: pim@ipng.nl (Pim van Pelt) Date: Mon, 17 Jun 2002 20:18:41 +0200 Subject: [6bone] Exchange Point Addresses In-Reply-To: <20020617124559.A13931@GROOVY.NET> References: <20020617124559.A13931@GROOVY.NET> Message-ID: <20020617181841.GA5259@bfib.colo.bit.nl> On Mon, Jun 17, 2002 at 12:45:59PM -0400, ww@GROOVY.NET wrote: | Hi, | | At the Toronto Internet Exchange (TORIX) we've been talking about | making it possible to peer natively over IPv6. The problem is | getting addresses for the exchange -- RIPE seems to have a clear | policy (they'll hand out a /64), but ARIN doesn't appear to. It | would not be appropriate to use addresses from one of the providers | at the exchange since TORIX has been, since its inception, | provider neutral and we'd like to keep it that way. They give out a (non-aggregatable) /48, which is IMO almost 100% pointless (not a /64 like you mentioned). | Any suggestions or pointers to how to go about acquiring some | numbers for the exchange would be appreciated. As with your collegues at AMS-IX (NL), you will simply be left out in the cold. When you approach a registry with a remark like you just made, you will be told that you are no more special than any other company that wishes to have their own globally routable space (call it PI, call it TLA). At current, at least in the region I am active in (RIPE), IXPs cannot obtain address space without becoming dependant on a member. By the way, neither can the RIR itself. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From stuart@tech.org Mon Jun 17 20:02:24 2002 From: stuart@tech.org (Stephen Stuart) Date: Mon, 17 Jun 2002 12:02:24 -0700 Subject: [6bone] Exchange Point Addresses In-Reply-To: Your message of "Mon, 17 Jun 2002 12:45:59 EDT." <20020617124559.A13931@GROOVY.NET> Message-ID: <200206171902.g5HJ2Ok19154@lo.tech.org> > At the Toronto Internet Exchange (TORIX) we've been talking about > making it possible to peer natively over IPv6. The problem is > getting addresses for the exchange -- RIPE seems to have a clear > policy (they'll hand out a /64), but ARIN doesn't appear to. It > would not be appropriate to use addresses from one of the providers > at the exchange since TORIX has been, since its inception, > provider neutral and we'd like to keep it that way. Did you speak to anyone at ARIN about micro-allocations for exchange point use? Stephen From Robert.Kiessling@de.easynet.net Mon Jun 17 21:20:56 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 17 Jun 2002 20:20:56 +0000 Subject: [6bone] Exchange Point Addresses In-Reply-To: <20020617181841.GA5259@bfib.colo.bit.nl> References: <20020617124559.A13931@GROOVY.NET> <20020617181841.GA5259@bfib.colo.bit.nl> Message-ID: Pim van Pelt writes: > On Mon, Jun 17, 2002 at 12:45:59PM -0400, ww@GROOVY.NET wrote: > | At the Toronto Internet Exchange (TORIX) we've been talking about > | making it possible to peer natively over IPv6. The problem is > | getting addresses for the exchange -- RIPE seems to have a clear > | policy (they'll hand out a /64), but ARIN doesn't appear to. It > | would not be appropriate to use addresses from one of the providers > | at the exchange since TORIX has been, since its inception, > | provider neutral and we'd like to keep it that way. > They give out a (non-aggregatable) /48, which is IMO almost 100% > pointless (not a /64 like you mentioned). It fulfils exactly what it's made for: to provide neutral, provider-independent IPv6 addresses for the exchange mesh. There was and is a need for this, so it's far from "100% useless". > | Any suggestions or pointers to how to go about acquiring some > | numbers for the exchange would be appreciated. > > As with your collegues at AMS-IX (NL), you will simply be left out in > the cold. No, you're not. You can receive address space for the exchange mesh. There is no need for these addresses to be routable. Addresses for other services like web page, NTP etc. is a different story altogether. > When you approach a registry with a remark like you just > made, you will be told that you are no more special than any other > company that wishes to have their own globally routable space (call it > PI, call it TLA). Indeed. You are implying that the secondary services offered by exchange points are so important that they justify a different allocation policy. This in turn implies that you want to introduce PI to IPv6, which so far does not exist (TLA, sTLA are *not* PI, they clearly are PA). There is a clear consencus that this is not desirable. > At current, at least in the region I am active in (RIPE), IXPs cannot > obtain address space without becoming dependant on a member. By the > way, neither can the RIR itself. They can obtain address space like everone else. They just cannot get "PI" space, that is globally routable addresses not bound to an upstream. Of course they are free to fulil the requirements for an allocation, which is essentially to become a LIR and expect 200 customer assignments. Robert From pim@ipng.nl Mon Jun 17 20:31:05 2002 From: pim@ipng.nl (Pim van Pelt) Date: Mon, 17 Jun 2002 21:31:05 +0200 Subject: [6bone] Exchange Point Addresses In-Reply-To: References: <20020617124559.A13931@GROOVY.NET> <20020617181841.GA5259@bfib.colo.bit.nl> Message-ID: <20020617193105.GB5405@bfib.colo.bit.nl> On Mon, Jun 17, 2002 at 08:20:56PM +0000, Robert Kiessling wrote: | Pim van Pelt writes: | | > On Mon, Jun 17, 2002 at 12:45:59PM -0400, ww@GROOVY.NET wrote: | > | At the Toronto Internet Exchange (TORIX) we've been talking about | > | making it possible to peer natively over IPv6. The problem is | > | getting addresses for the exchange -- RIPE seems to have a clear | > | policy (they'll hand out a /64), but ARIN doesn't appear to. It | > | would not be appropriate to use addresses from one of the providers | > | at the exchange since TORIX has been, since its inception, | > | provider neutral and we'd like to keep it that way. | > They give out a (non-aggregatable) /48, which is IMO almost 100% | > pointless (not a /64 like you mentioned). | | It fulfils exactly what it's made for: to provide neutral, | provider-independent IPv6 addresses for the exchange mesh. There was | and is a need for this, so it's far from "100% useless". Hi Robert, Sitelocal will do fine for these things. If you can't route it, I don't see the point in having it allocated from the 2000::/3 aggregate. I would find fec0::/10 addresses in the peering mesh useful. We have seen (in practice) that not having globally routable peering meshes, potentially breaks Path MTU discovery. This can happen when all the hops to the endpoint are larger than the one used on the shared medium, making the last box before the shared medium hop generate a message to the originating host that the MTU should be set to its value. Some router implementations drop any packets from sources which they do not have a route to in their FIB. | > | Any suggestions or pointers to how to go about acquiring some | > | numbers for the exchange would be appreciated. | > | > As with your collegues at AMS-IX (NL), you will simply be left out in | > the cold. | | No, you're not. You can receive address space for the exchange | mesh. There is no need for these addresses to be routable. See above. | Addresses for other services like web page, NTP etc. is a different | story altogether. It's the story I was actually referring to in my original comment. | > When you approach a registry with a remark like you just | > made, you will be told that you are no more special than any other | > company that wishes to have their own globally routable space (call it | > PI, call it TLA). | | Indeed. | | You are implying that the secondary services offered by exchange | points are so important that they justify a different allocation | policy. This in turn implies that you want to introduce PI to IPv6, | which so far does not exist (TLA, sTLA are *not* PI, they clearly are | PA). Please don't put words in my mouth. I am not implying that I would like to have PI space in IPv6, on the contrary. | There is a clear consencus that this is not desirable. I consent to not having PI, I do not consent to having the 2001:7f8::/32 superblock with /48 allocations for peering meshes. | > At current, at least in the region I am active in (RIPE), IXPs cannot | > obtain address space without becoming dependant on a member. By the | > way, neither can the RIR itself. | | They can obtain address space like everone else. They just cannot get | "PI" space, that is globally routable addresses not bound to an | upstream. Of course they are free to fulil the requirements for an | allocation, which is essentially to become a LIR and expect 200 | customer assignments. This would be lying to the RIR, and that type of behavior is being actively promoted these days, for example at RIPE42, where RIPE joined the other two RIRs with the new allocation policies. For an IXP, which will not offer downstream customers connectivity via their AS, it would not be feasable to request an IPv6 allocation from the RIR in saying that they would have a business case for 200 customer allocations (which would be their members). Most independant IXPs I know of (although I admit that I do not know of many :-), are member associations, which will not be able to make a case at their RIR to meet the 200 potential end-sites criterium. So either they lie, or they break their independence by becoming a customer with one (or several) of their members. As much as I do not think that an IXP is a more special pig than other pigs, I also do not think that they should be bending the rules and forcing themselves into awkward positions to obtain address space. Oh, did I mention that the RIRs themselves face exactly the same problem ? groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From pekkas@netcore.fi Mon Jun 17 21:18:35 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 17 Jun 2002 23:18:35 +0300 (EEST) Subject: [6bone] Exchange Point Addresses In-Reply-To: <20020617181841.GA5259@bfib.colo.bit.nl> Message-ID: Pim, ww, Please note that IX allocation is not meant to be "globally routable". If you accept that, you can get IXP allocation, at least in RIPE region. Many IX's don't really need that (they only want addresses for e.g. switch fabrics or p-t-p addresses, not for services). IX, depending on how you build it, could have any kind of addressing you want. You could do private peerings and use addresses from either party. But that is very bothersome if the technique is based on broadcast medium, like Gigabit Ethernet. On Mon, 17 Jun 2002, Pim van Pelt wrote: > On Mon, Jun 17, 2002 at 12:45:59PM -0400, ww@GROOVY.NET wrote: > | Hi, > | > | At the Toronto Internet Exchange (TORIX) we've been talking about > | making it possible to peer natively over IPv6. The problem is > | getting addresses for the exchange -- RIPE seems to have a clear > | policy (they'll hand out a /64), but ARIN doesn't appear to. It > | would not be appropriate to use addresses from one of the providers > | at the exchange since TORIX has been, since its inception, > | provider neutral and we'd like to keep it that way. > They give out a (non-aggregatable) /48, which is IMO almost 100% > pointless (not a /64 like you mentioned). > > | Any suggestions or pointers to how to go about acquiring some > | numbers for the exchange would be appreciated. > > As with your collegues at AMS-IX (NL), you will simply be left out in > the cold. When you approach a registry with a remark like you just > made, you will be told that you are no more special than any other > company that wishes to have their own globally routable space (call it > PI, call it TLA). > > At current, at least in the region I am active in (RIPE), IXPs cannot > obtain address space without becoming dependant on a member. By the > way, neither can the RIR itself. > > groet, > Pim > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From bmanning@ISI.EDU Mon Jun 17 21:38:08 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 17 Jun 2002 13:38:08 -0700 (PDT) Subject: [6bone] Exchange Point Addresses In-Reply-To: <20020617124559.A13931@GROOVY.NET> from "ww@GROOVY.NET" at "Jun 17, 2 12:45:59 pm" Message-ID: <200206172038.g5HKc8N09094@boreas.isi.edu> you may wish to talk with Joe Abley. you may also wish to review www.ep.net % Hi, % % At the Toronto Internet Exchange (TORIX) we've been talking about % making it possible to peer natively over IPv6. The problem is % getting addresses for the exchange -- RIPE seems to have a clear % policy (they'll hand out a /64), but ARIN doesn't appear to. It % would not be appropriate to use addresses from one of the providers % at the exchange since TORIX has been, since its inception, % provider neutral and we'd like to keep it that way. % % Any suggestions or pointers to how to go about acquiring some % numbers for the exchange would be appreciated. % % Thanks, % -w % -- % Will Waites % ww@groovy.net % _______________________________________________ % 6bone mailing list % 6bone@mailman.isi.edu % http://mailman.isi.edu/mailman/listinfo/6bone % -- --bill From Robert.Kiessling@de.easynet.net Mon Jun 17 23:15:39 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 17 Jun 2002 22:15:39 +0000 Subject: [6bone] Exchange Point Addresses In-Reply-To: <20020617193105.GB5405@bfib.colo.bit.nl> References: <20020617124559.A13931@GROOVY.NET> <20020617181841.GA5259@bfib.colo.bit.nl> <20020617193105.GB5405@bfib.colo.bit.nl> Message-ID: Pim van Pelt writes: > | It fulfils exactly what it's made for: to provide neutral, > | provider-independent IPv6 addresses for the exchange mesh. There was > | and is a need for this, so it's far from "100% useless". > > Sitelocal will do fine for these things. If you can't route it, I don't > see the point in having it allocated from the 2000::/3 aggregate. I > would find fec0::/10 addresses in the peering mesh useful. Three things spring to my mind: 1. reverse DNS is not possible with site-local addresses 2. with site-local addresses on IXP LAN, a router is in two different local domains, with possible nasty interactions between the two "site local" domains 3. missing traceroutes hops through IPX LANs with site-local addresses > We have seen (in practice) that not having globally routable peering > meshes, potentially breaks Path MTU discovery. Then you see something I've never seen. RFC1918 addresses pose problems to PMTUD, that's true, but for different reasons. > Some router implementations drop any packets from sources which they do > not have a route to in their FIB. Which implementations do this? Even if you have such an implementation, you'd just need to nullroute the allocation from which IXP addresses are taken. > This would be lying to the RIR, and that type of behavior is being > actively promoted these days, [...] I didn't want to suggest to lie, but to honestly fulfil the criteria. > | There is a clear consencus that this is not desirable. > I consent to not having PI, I do not consent to having the 2001:7f8::/32 > superblock with /48 allocations for peering meshes. What would be your suggestion then? Giving routable blocks to IXPs which do not do end-user assignments *is* PI. > Oh, did I mention that the RIRs themselves face exactly the same problem ? You mentioned it. Still I fail see why this a problem. If it was, then is would be a problem not just for IXPs and RIPE, but for many other organsations too. IXPs and RIPE are not special in this respect. Robert From ww@GROOVY.NET Mon Jun 17 22:07:27 2002 From: ww@GROOVY.NET (ww@GROOVY.NET) Date: Mon, 17 Jun 2002 17:07:27 -0400 Subject: [6bone] Exchange Point Addresses In-Reply-To: <20020617181841.GA5259@bfib.colo.bit.nl>; from pim@ipng.nl on Mon, Jun 17, 2002 at 08:18:41PM +0200 References: <20020617124559.A13931@GROOVY.NET> <20020617181841.GA5259@bfib.colo.bit.nl> Message-ID: <20020617170727.A6406@GROOVY.NET> On Mon, Jun 17, 2002 at 08:18:41PM +0200, Pim van Pelt wrote: > > They give out a (non-aggregatable) /48, which is IMO almost 100% > pointless (not a /64 like you mentioned). My source for this was http://www.ripe.net/ripencc/mem-services/registration/ipv6/eix-interim.html "Since the address space does not need to be routable globally and an IXP is expected to only have one subnet, a /64 (64 bits of address space) will be assigned in most cases." Perhaps this does not reflect their actual policy. In any case if the addresses are not globally routeable, we might as well use site-local ones. It would befar better to use globally routeable addresses for exactly the reasons you point out -- i.e. path MTU discovery. Perhaps it is not impossible that a certain number of small exchange point blocks be allowed to leak unaggregated into the global routing table -- I suspect that the number of such blocks would be bounded above by 10000 or so (say about 300 countries in the world with on average 10 major cities, each with an internet exchange or two). It's clearly feasable technically, but less than elegant. > As with your collegues at AMS-IX (NL), you will simply be left out in > the cold. When you approach a registry with a remark like you just > made, you will be told that you are no more special than any other > company that wishes to have their own globally routable space (call it > PI, call it TLA). Which is unfortunate, since we don't really fit into their categories. In reality, TORIX is a couple of ethernet switches that live in shared physical space graciously donated by the managers of the local telco hotel. It is not a company, it is a shared community resource. And it has run into problems in the past being tied for one reason or another to a particular member of the exchage. So, what to do? ;) The way that ARIN seems to have tentatively addressed the issue is by trying to turn regional exchanges (a label which could reasonably be applied to TORIX since most of the ISPs in Ontario peer there) into sub-TLA registries for the region (http://www.arin.net/library/guidelines/ipv6_rir.txt section 4.2.3.1) which, I believe, is more responsibility than we would be willing to take on. They also have a RIPE-like policy proposal which doesn't appear to have been looked at in about a year and a half: http://www.arin.net/policy/2001_3.html Cheers, -w -- Will Waites ww@groovy.net From pekkas@netcore.fi Mon Jun 17 22:11:36 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Tue, 18 Jun 2002 00:11:36 +0300 (EEST) Subject: [6bone] Exchange Point Addresses In-Reply-To: <20020617193105.GB5405@bfib.colo.bit.nl> Message-ID: On Mon, 17 Jun 2002, Pim van Pelt wrote: > On Mon, Jun 17, 2002 at 08:20:56PM +0000, Robert Kiessling wrote: > | Pim van Pelt writes: > | > | > On Mon, Jun 17, 2002 at 12:45:59PM -0400, ww@GROOVY.NET wrote: > | > | At the Toronto Internet Exchange (TORIX) we've been talking about > | > | making it possible to peer natively over IPv6. The problem is > | > | getting addresses for the exchange -- RIPE seems to have a clear > | > | policy (they'll hand out a /64), but ARIN doesn't appear to. It > | > | would not be appropriate to use addresses from one of the providers > | > | at the exchange since TORIX has been, since its inception, > | > | provider neutral and we'd like to keep it that way. > | > They give out a (non-aggregatable) /48, which is IMO almost 100% > | > pointless (not a /64 like you mentioned). > | > | It fulfils exactly what it's made for: to provide neutral, > | provider-independent IPv6 addresses for the exchange mesh. There was > | and is a need for this, so it's far from "100% useless". > Hi Robert, > > Sitelocal will do fine for these things. If you can't route it, I don't > see the point in having it allocated from the 2000::/3 aggregate. I > would find fec0::/10 addresses in the peering mesh useful. Reverse DNS won't work nicely with traceroute w/ site-locals, though. How significant this is, is another question.. > Some router implementations drop any packets from sources which they do > not have a route to in their FIB. Broken implementations, or those using unicast RPF I guess. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From ww@GROOVY.NET Mon Jun 17 22:18:48 2002 From: ww@GROOVY.NET (ww@GROOVY.NET) Date: Mon, 17 Jun 2002 17:18:48 -0400 Subject: [6bone] ifconfig and EUI-64 In-Reply-To: <20020609172247.GA2781@bfib.colo.bit.nl>; from pim@ipng.nl on Sun, Jun 09, 2002 at 07:22:47PM +0200 References: <20020609172247.GA2781@bfib.colo.bit.nl> Message-ID: <20020617171848.A6505@GROOVY.NET> On Sun, Jun 09, 2002 at 07:22:47PM +0200, Pim van Pelt wrote: > > Does anyone know why exactly the ifconfig programs for the BSDs, Linux > and most probably Solaris are not able to autoconfigure their own > addresses, by not using the RS/RA schema, but a local autoconfiguration > such as the Cisco IOS: NetBSD-current now supports this :) i.e. ifconfig hme0 inet6 3ffe:1cdc:0:1234:: eui64 Cheers, -w From ww@GROOVY.NET Mon Jun 17 22:35:06 2002 From: ww@GROOVY.NET (ww@GROOVY.NET) Date: Mon, 17 Jun 2002 17:35:06 -0400 Subject: [6bone] Exchange Point Addresses In-Reply-To: ; from Robert.Kiessling@de.easynet.net on Mon, Jun 17, 2002 at 10:15:39PM +0000 References: <20020617124559.A13931@GROOVY.NET> <20020617181841.GA5259@bfib.colo.bit.nl> <20020617193105.GB5405@bfib.colo.bit.nl> Message-ID: <20020617173506.B6505@GROOVY.NET> On Mon, Jun 17, 2002 at 10:15:39PM +0000, Robert Kiessling wrote: > > > We have seen (in practice) that not having globally routable peering > > meshes, potentially breaks Path MTU discovery. > > Then you see something I've never seen. RFC1918 addresses pose > problems to PMTUD, that's true, but for different reasons. What are the different reasons? I would think that using any non-unique addresses (RFC1918 or site-local IPv6) would cause similar problems. Unique but non globally routeable addresses should be ok though (pace RPF), no? -w From itojun@iijlab.net Mon Jun 17 23:23:48 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Tue, 18 Jun 2002 07:23:48 +0900 Subject: [6bone] Exchange Point Addresses In-Reply-To: ww's message of Mon, 17 Jun 2002 12:45:59 -0400. <20020617124559.A13931@GROOVY.NET> Message-ID: <20020617222348.4AD6B4B24@coconut.itojun.org> >At the Toronto Internet Exchange (TORIX) we've been talking about >making it possible to peer natively over IPv6. The problem is >getting addresses for the exchange -- RIPE seems to have a clear >policy (they'll hand out a /64), but ARIN doesn't appear to. It >would not be appropriate to use addresses from one of the providers >at the exchange since TORIX has been, since its inception, >provider neutral and we'd like to keep it that way. > >Any suggestions or pointers to how to go about acquiring some >numbers for the exchange would be appreciated. at NSPIXP2 and NSPIXP6, we are using /64 block from WIDE (2001:200::/35). WIDE is operating these exchanges so it was a natural choice. another option is to use link-local address only on IX segment. draft-kato-bgp-ipv6-link-local-01.txt cisco and zebra are at least capable of doing it. traceroute doesn't really have problem, as many of the routers i know of do not do strict strong-host model. itojun From michel@arneill-py.sacramento.ca.us Mon Jun 17 23:43:07 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 17 Jun 2002 15:43:07 -0700 Subject: [6bone] Exchange Point Addresses Message-ID: <2B81403386729140A3A899A8B39B046405E119@server2000.arneill-py.sacramento.ca.us> Pim and 6boners, > Pim van Pelt wrote: > As with your collegues at AMS-IX (NL), you will simply be left > out in the cold. When you approach a registry with a remark like > you just made, you will be told that you are no more special than > any other company that wishes to have their own globally routable > space (call it PI, call it TLA). > At current, at least in the region I am active in (RIPE), IXPs > cannot obtain address space without becoming dependant on a member. > By the way, neither can the RIR itself. The ipv6mh list is working hard to provide you with geographical addresses so you don't stay in the cold too long. An example is available here: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt I welcome the 6bone community's comments on this. This test is about proposed allocation only, the protocols and practices are still cooking. Michel. From pim@ipng.nl Tue Jun 18 07:17:42 2002 From: pim@ipng.nl (Pim van Pelt) Date: Tue, 18 Jun 2002 08:17:42 +0200 Subject: [6bone] Exchange Point Addresses In-Reply-To: <2B81403386729140A3A899A8B39B046405E119@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E119@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020618061742.GC26448@bfib.colo.bit.nl> On Mon, Jun 17, 2002 at 03:43:07PM -0700, Michel Py wrote: | Pim and 6boners, | | > Pim van Pelt wrote: | > As with your collegues at AMS-IX (NL), you will simply be left | > out in the cold. When you approach a registry with a remark like | > you just made, you will be told that you are no more special than | > any other company that wishes to have their own globally routable | > space (call it PI, call it TLA). | > At current, at least in the region I am active in (RIPE), IXPs | > cannot obtain address space without becoming dependant on a member. | > By the way, neither can the RIR itself. | | The ipv6mh list is working hard to provide you with geographical | addresses so you don't stay in the cold too long. An example is | available here: | http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt I browsed through this allocation document. Nice work! What are the aggregation policies with these networks ? I see that the smallest allocation to cities would be /32. Who would announce for example the NL-Amsterdam block 2346:7600::/29 ? If it is anybody other than AS1200, in the case of AMS-IX, then they would be dependent on that particular AS (and most probably, the member operating that AS). Can you point me to a document that explains how this will solve the dependency issue raised ? Thanks, groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From pekkas@netcore.fi Tue Jun 18 07:53:53 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Tue, 18 Jun 2002 09:53:53 +0300 (EEST) Subject: [6bone] Exchange Point Addresses In-Reply-To: <20020617222348.4AD6B4B24@coconut.itojun.org> Message-ID: On Tue, 18 Jun 2002 itojun@iijlab.net wrote: > >At the Toronto Internet Exchange (TORIX) we've been talking about > >making it possible to peer natively over IPv6. The problem is > >getting addresses for the exchange -- RIPE seems to have a clear > >policy (they'll hand out a /64), but ARIN doesn't appear to. It > >would not be appropriate to use addresses from one of the providers > >at the exchange since TORIX has been, since its inception, > >provider neutral and we'd like to keep it that way. > > > >Any suggestions or pointers to how to go about acquiring some > >numbers for the exchange would be appreciated. > > at NSPIXP2 and NSPIXP6, we are using /64 block from WIDE > (2001:200::/35). WIDE is operating these exchanges so it was a natural > choice. > > another option is to use link-local address only on IX segment. > draft-kato-bgp-ipv6-link-local-01.txt > cisco and zebra are at least capable of doing it. Link-locals only seem to be a huge can of worms if someone forgets 'next-hop-self' with link-local eBGP peering, and link-local address would be distributed to iBGP. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From kre@munnari.OZ.AU Tue Jun 18 12:44:27 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Tue, 18 Jun 2002 18:44:27 +0700 Subject: [6bone] Exchange Point Addresses In-Reply-To: <20020617222348.4AD6B4B24@coconut.itojun.org> References: <20020617222348.4AD6B4B24@coconut.itojun.org> Message-ID: <7364.1024400667@munnari.OZ.AU> Date: Tue, 18 Jun 2002 07:23:48 +0900 From: itojun@iijlab.net Message-ID: <20020617222348.4AD6B4B24@coconut.itojun.org> | another option is to use link-local address only on IX segment. That assumes there's only one segment, which is not necessarily going to be true. | traceroute doesn't really have problem, as many of the routers | i know of do not do strict strong-host model. I don't think that "strong-host model" makes sense when applied to a router, but that's beside the point probably. This one assumes that everything in question has a a global address, but from where to get that address was the initial question. Note - there's no guarantee that a router in the middle of the exchange, which does not directly connect to any of the peering networks, will have any other global addresses (clearly, it could do, as you have done, use address space from one of the providers, but avoiding that is sometimes desirable). A non-routable global address (as others have said) should work just fine (non-routable in this context means "non routable from the world at large", not "non-routable from the connected networks" of course".) It needs to be global, so packets from it can be sent to everywhere, it doesn't need to be routable, as no-one needs to be able (from arbitrary places) to send packets back to it. If broken RPF implementations cause problems, they should be fixed (refusing packets that come from a path where the route to the destination is on another path can (in appropriate circumstances) be justified. Refusing packets because there's no current route makes no sense for the purposes RPF is used. Being global, there's no problem with IP6.ARPA lookups, or anything else like that. kre From michel@arneill-py.sacramento.ca.us Tue Jun 18 16:43:36 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 18 Jun 2002 08:43:36 -0700 Subject: [6bone] Exchange Point Addresses Message-ID: <2B81403386729140A3A899A8B39B046405E120@server2000.arneill-py.sacramento.ca.us> Pim, | Michel Py wrote: | The ipv6mh list is working hard to provide you with geographical | addresses so you don't stay in the cold too long. An example is | available here: | http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt > Pim van Pelt wrote: > I browsed through this allocation document. Nice work! Thank you. Please note that this is the _first_ shot at this scheme, so everything can potentially be changed. > What are the aggregation policies with these networks ? I see that > the smallest allocation to cities would be /32. Who would announce > for example the NL-Amsterdam block 2346:7600::/29 ? The short answer is nobody, but this requires an explanation a lot longer that belongs on the 6bone mailing list; this allocation is valid for two different protocols, GFN and MHAP. I ccd your question to the ipv6mh mailing list and I will address it there; if anyone answers it please take the 6bone out of the cc field. > If it is anybody other than AS1200, in the case of AMS-IX, then they > would be dependent on that particular AS (and most probably, the > member operating that AS). There are no dependencies on the AS. > Can you point me to a document that explains how this will solve > the dependency issue raised ? http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt This is only 1/2 of the story. The GFN draft is not yet available. Michel. From bmanning@ISI.EDU Tue Jun 25 03:09:25 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 24 Jun 2002 19:09:25 -0700 (PDT) Subject: [6bone] possible operational interest Message-ID: <200206250209.g5P29P310597@boreas.isi.edu> With the tacit permission of DISA, we have included the .MIL zone in the v6 DNS testbed. We expect to have stable .COM/NET/ORG/EDU visable as well within the next couple of weeks. -- --bill From Jeff.Thomas@ind.alcatel.com Tue Jun 25 18:02:50 2002 From: Jeff.Thomas@ind.alcatel.com (Jeff Thomas) Date: Tue, 25 Jun 2002 11:02:50 -0600 Subject: [6bone] IPv6 routing table size Message-ID: <3D18A23A.B5F454FD@alcatel.com> (Hopefully this is the right list for this question....) I have been curious about the size of routing tables when using IPv6. I had it in my mind that they would be considerably smaller due to aggregation properties. I surmised that even a large enterprise may not have more than a couple hundred routes in their core. Then I noticed in a presentation that someone in China (BII Group - presentation from IPv6 Summit in Beijing) was building an IPv6 router with over a million entries in their routing table. Am I off track? Large enterprises today may have tens of thousands of routes in v4, but using v6 wouldn't they be an order of magnitude smaller? Thanks, Jeff From pim@ipng.nl Tue Jun 25 22:08:11 2002 From: pim@ipng.nl (Pim van Pelt) Date: Tue, 25 Jun 2002 23:08:11 +0200 Subject: [6bone] IPv6 routing table size In-Reply-To: <3D18A23A.B5F454FD@alcatel.com> References: <3D18A23A.B5F454FD@alcatel.com> Message-ID: <20020625210811.GA29255@bfib.colo.bit.nl> On Tue, Jun 25, 2002 at 11:02:50AM -0600, Jeff Thomas wrote: | (Hopefully this is the right list for this question....) | | I have been curious about the size of routing tables when using IPv6. I | had it in my mind that they would be considerably smaller due to | aggregation properties. I surmised that even a large enterprise may not | have more than a couple hundred routes in their core. Then I noticed in | a presentation that someone in China (BII Group - presentation from IPv6 | Summit in Beijing) was building an IPv6 router with over a million | entries in their routing table. Am I off track? | | Large enterprises today may have tens of thousands of routes in v4, but | using v6 wouldn't they be an order of magnitude smaller? | There's currently some 250 prefixes in the TLA cloud (this is RIR '2001' and 6bone '3ffe'). I don't expect the amount of prefixes to be more than the amount of AS numbers in the long run. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From michel@arneill-py.sacramento.ca.us Tue Jun 25 23:12:21 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 25 Jun 2002 15:12:21 -0700 Subject: [6bone] IPv6 routing table size Message-ID: <2B81403386729140A3A899A8B39B046405E153@server2000.arneill-py.sacramento.ca.us> > Jeff Thomas wrote: > was building an IPv6 router with over a million > entries in their routing table. Am I off track? A _million_ ? whoa. I count 245 entries in the global v6 table now, and I am not aware of any v6 ISP with more than a few dozen thousand customers. > Large enterprises today may have tens of thousands of routes > in v4, but using v6 wouldn't they be an order of magnitude > smaller? One million subnets, yes; this would be totally unaggregated though. Should not be more than 50k-80k routes aggregated. I am not sure I would agree with an order of magnitude smaller, but I think that a v6 routing table should be smaller than the v4 equivalent. The biggest (v4) routing table I have seen myself is 200k and change. Michel. From JORDI PALET MARTINEZ" Message-ID: <00a401c21c97$69438fb0$8700000a@consulintel.es> I've seen also this presentation. I'm sure it was 1.000.000, but may be I'm wrong. It was Hitachi GR2000 ? If the performance is good enough, may be we solved the multihoming problem for a while ;-) Regards, Jordi Palet Consulintel ----- Original Message ----- From: "Michel Py" To: "Jeff Thomas" ; <6bone@mailman.isi.edu> Sent: Wednesday, June 26, 2002 12:12 AM Subject: RE: [6bone] IPv6 routing table size > > Jeff Thomas wrote: > > was building an IPv6 router with over a million > > entries in their routing table. Am I off track? > > A _million_ ? whoa. I count 245 entries in the global v6 table now, and > I am not aware of any v6 ISP with more than a few dozen thousand > customers. > > > Large enterprises today may have tens of thousands of routes > > in v4, but using v6 wouldn't they be an order of magnitude > > smaller? > > One million subnets, yes; this would be totally unaggregated though. > Should not be more than 50k-80k routes aggregated. > > I am not sure I would agree with an order of magnitude smaller, but I > think that a v6 routing table should be smaller than the v4 equivalent. > The biggest (v4) routing table I have seen myself is 200k and change. > > Michel. > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From bmanning@ISI.EDU Tue Jun 25 23:36:17 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Tue, 25 Jun 2002 15:36:17 -0700 (PDT) Subject: [6bone] IPv6 routing table size In-Reply-To: <2B81403386729140A3A899A8B39B046405E153@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Jun 25, 2 03:12:21 pm" Message-ID: <200206252236.g5PMaH510959@boreas.isi.edu> a single "million" is either way too large or way too small. Depends on if you beleive the aggregation model will hold. A prgmatic design choice would be for supporting a table size of 2x32nd number of entries, presuming CIDR. Is such a design practical? Not with todays technolgies. How much social engineering can be done to ensure that choice is not restricted? % > Jeff Thomas wrote: % > was building an IPv6 router with over a million % > entries in their routing table. Am I off track? % % A _million_ ? whoa. I count 245 entries in the global v6 table now, and % I am not aware of any v6 ISP with more than a few dozen thousand % customers. % % > Large enterprises today may have tens of thousands of routes % > in v4, but using v6 wouldn't they be an order of magnitude % > smaller? % % One million subnets, yes; this would be totally unaggregated though. % Should not be more than 50k-80k routes aggregated. % % I am not sure I would agree with an order of magnitude smaller, but I % think that a v6 routing table should be smaller than the v4 equivalent. % The biggest (v4) routing table I have seen myself is 200k and change. % % Michel. % % _______________________________________________ % 6bone mailing list % 6bone@mailman.isi.edu % http://mailman.isi.edu/mailman/listinfo/6bone % -- --bill From michel@arneill-py.sacramento.ca.us Wed Jun 26 00:01:23 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 25 Jun 2002 16:01:23 -0700 Subject: [6bone] IPv6 routing table size Message-ID: <2B81403386729140A3A899A8B39B046405E154@server2000.arneill-py.sacramento.ca.us> > Bill Manning wrote: > a single "million" is either way too large or > way too small. Depends on if you beleive the > aggregation model will hold. Agree. > A pragmatic design choice would be for supporting > a table size of 2x32nd number of entries, presuming > CIDR. If it's 2^32 sites, but not 2^32 routes, I agree. If it's 2^32 sites, _and_ 2^32 routes, I do not. > Is such a design practical? Not with todays technolgies. > How much social engineering can be done to ensure that > choice is not restricted? A lot, IMHO. Michel. From JORDI PALET MARTINEZ" <00a401c21c97$69438fb0$8700000a@consulintel.es> <3D190E8D.40BA24D3@alcatel.com> Message-ID: <017001c21cac$f65d56a0$8700000a@consulintel.es> Ok. Then you mean 863 ... the presentation is here http://www.ipv6.net.cn/event/presentation/ipv6-china-report.pdf ----- Original Message ----- From: "Jeff Thomas" To: "JORDI PALET MARTINEZ" Sent: Wednesday, June 26, 2002 2:45 AM Subject: Re: [6bone] IPv6 routing table size > I don't believe it was the Hitachi box. It presented the ideas for a new "high performance IPv6 router" and > had some other name like 862 or something like that associated with it. The presentation is the one from the > BII CTO from the Beijing Summit. That still seems like a crazy number. If it is true, so much for the > routing scalability of IPv6, huh? :-) > > JORDI PALET MARTINEZ wrote: > > > I've seen also this presentation. I'm sure it was 1.000.000, but may be I'm wrong. It was Hitachi GR2000 ? > > > > If the performance is good enough, may be we solved the multihoming problem for a while ;-) > > > > Regards, > > > > Jordi Palet > > Consulintel > > > > ----- Original Message ----- > > From: "Michel Py" > > To: "Jeff Thomas" ; <6bone@mailman.isi.edu> > > Sent: Wednesday, June 26, 2002 12:12 AM > > Subject: RE: [6bone] IPv6 routing table size > > > > > > Jeff Thomas wrote: > > > > was building an IPv6 router with over a million > > > > entries in their routing table. Am I off track? > > > > > > A _million_ ? whoa. I count 245 entries in the global v6 table now, and > > > I am not aware of any v6 ISP with more than a few dozen thousand > > > customers. > > > > > > > Large enterprises today may have tens of thousands of routes > > > > in v4, but using v6 wouldn't they be an order of magnitude > > > > smaller? > > > > > > One million subnets, yes; this would be totally unaggregated though. > > > Should not be more than 50k-80k routes aggregated. > > > > > > I am not sure I would agree with an order of magnitude smaller, but I > > > think that a v6 routing table should be smaller than the v4 equivalent. > > > The biggest (v4) routing table I have seen myself is 200k and change. > > > > > > Michel. > > > > > > _______________________________________________ > > > 6bone mailing list > > > 6bone@mailman.isi.edu > > > http://mailman.isi.edu/mailman/listinfo/6bone > > > > > > > > > > *********************************************************** > > Madrid 2002 Global IPv6 Summit > > See all the documents on line at: > > www.ipv6-es.com > > > > _______________________________________________ > > 6bone mailing list > > 6bone@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/6bone > > > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From Jeff.Thomas@ind.alcatel.com Wed Jun 26 02:00:41 2002 From: Jeff.Thomas@ind.alcatel.com (Jeff Thomas) Date: Tue, 25 Jun 2002 19:00:41 -0600 Subject: [6bone] IPv6 routing table size References: <2B81403386729140A3A899A8B39B046405E154@server2000.arneill-py.sacramento.ca.us> Message-ID: <3D191239.166D0BB@alcatel.com> Michel Py wrote: > > Bill Manning wrote: > > a single "million" is either way too large or > > way too small. Depends on if you beleive the > > aggregation model will hold. > > Agree. The bullet point from the presentation actually was "Routing table > 1M". I guess the point of the aggregation model holding is the root of my question. I was thinking it would hold, but it sounds like nobody is banking on it. What factors are considered here in holding the aggregation model in question? Jeff From michel@arneill-py.sacramento.ca.us Wed Jun 26 03:32:55 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 25 Jun 2002 19:32:55 -0700 Subject: [6bone] IPv6 routing table size Message-ID: <2B81403386729140A3A899A8B39B046405E156@server2000.arneill-py.sacramento.ca.us> Jeff, >>> Bill Manning wrote: >>> a single "million" is either way too large or >>> way too small. Depends on if you beleive the >>> aggregation model will hold. >> Michel Py wrote: >> Agree. > Jeff Thomas wrote: > The bullet point from the presentation actually was > "Routing table > 1M". Are you referring to the one below that Jordi just posted? > Jordi Palet wrote: > Ok. Then you mean 863 ... the presentation is here > http://www.ipv6.net.cn/event/presentation/ipv6-china-report.pdf If yes, I don't see where the scoop is. There are routers that handle 200k routes. Having people designing a router to hold 1M is yesterday's news. Without specific info, I'd bet you a buck that Cisco and Juniper are working on it, too. The fact that they are working on it does _not_ mean we will see a 1M prefixes routing table. A distinct possibility if no multihoming solution is released soon, put still only a possibility. > I guess the point of the aggregation model holding is the root of > my question. I was thinking it would hold, but it sounds like > nobody is banking on it. > What factors are considered here in holding the aggregation model > in question? The availability of a real IPv6 multihoming solution. Michel. From stuart@tech.org Wed Jun 26 04:51:04 2002 From: stuart@tech.org (Stephen Stuart) Date: Tue, 25 Jun 2002 20:51:04 -0700 Subject: [6bone] IPv6 routing table size In-Reply-To: Your message of "Tue, 25 Jun 2002 23:08:11 +0200." <20020625210811.GA29255@bfib.colo.bit.nl> Message-ID: <200206260351.g5Q3p4k98456@lo.tech.org> > I don't expect the amount of prefixes to be more than the amount of AS > numbers in the long run. In the long run, AS numbers will be 32 bits, too; perhaps someday people wll reminisce about when the routing table "only had a million prefixes?" Stephen From nhua@biigroup.com Wed Jun 26 07:11:02 2002 From: nhua@biigroup.com (Hua Ning) Date: Wed, 26 Jun 2002 14:11:02 +0800 Subject: [6bone] IPv6 routing table size References: <2B81403386729140A3A899A8B39B046405E154@server2000.arneill-py.sacramento.ca.us> <3D191239.166D0BB@alcatel.com> Message-ID: <001c01c21cd8$40a257d0$953d893d@huaning> hi , Jeff, It's me to make the presentation in China v6 Summit, (1) So far the size of v6 routing table is no more than hundreds, yet it's only in the period of v6 experiment and with few ISP to provide v6 service. (2) The aggregation model of v6 address can lower the number of entries in router, but considering the length of v6 address, the practical environment might not go as we plan it to be. (3) The actually size of v6 routing table has much to do with RIR's v6 allocation policy. Accroding to recent policy which will take effect in July, RIR is going to allocate /32 as minimal to v6 service provider, and v6 service provider will assign /48 to end site. If the end-site has its own AS number, should we let the /48 appear in global routing table ? (4) Considering the multi-homing environment, when a end-site get a /48 from providerA, get a second /48 from providerB, and get a third /48 from providerC, and no matter this end-site has AS number or not, If the end-site want to take full use of the three address space and the three links, we have to let the three prefixes to appear in global routing table. (5) To achieve better aggregation, RIRs should apply practices that maximize the potential for subsequent allocations to be made contiguous with past v6 allocations currently held. However, there can be no guarantee of contiguous allocation. See. http://www.apnic.net/mailing-lists/global-v6/archive/2002/04/msg00050.html (6) At present, one v6 provider might already hold 2 entries in rouring table, one is 3ffe block , another is 2001 block, we should expect more 3xxx or 2xxx to appear in the future, who knows. In summary, the size of v6 routing table can not be predicted precisely so far, but in my opinion, if v6 roll out in large scale in the world, the size won't be less than some dozens of thousand, and might be more than the size of v4. BTW: the 863 project for v6 router , 1M is for v4 and 200K is for v6. Regards, ------------------------------------------- Hua Ning Chief Engineer Beijing Internet-networking Institute, Beijing,China Mobile: +86-13501067449 Tel:+86-10-65660290 Fax:+86-10-65660297 ------------------------------------------- Subject: Re: [6bone] IPv6 routing table size > > Michel Py wrote: > > > > Bill Manning wrote: > > > a single "million" is either way too large or > > > way too small. Depends on if you beleive the > > > aggregation model will hold. > > > > Agree. > > The bullet point from the presentation actually was "Routing table > > 1M". > > I guess the point of the aggregation model holding is the root of my > question. I was thinking it would hold, but it sounds like nobody is > banking on it. > What factors are considered here in holding the aggregation model in > question? > > Jeff > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From michel@arneill-py.sacramento.ca.us Wed Jun 26 17:27:19 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 26 Jun 2002 09:27:19 -0700 Subject: [6bone] IPv6 routing table size Message-ID: <2B81403386729140A3A899A8B39B046405E15A@server2000.arneill-py.sacramento.ca.us> > (3) The actually size of v6 routing table has much to do with > RIR's v6 allocation policy. Accroding to recent policy which > will take effect in July, RIR is going to allocate /32 as > minimal to v6 service provider, and v6 service provider will > assign /48 to end site. If the end-site has its own AS > number, should we let the /48 appear in global routing table ? No. This is not the main issue, actually. One of the strong incentives organizations multihome is not to be tied to a specific ISP. There might be some PA site prefixes leaks, but we do not expect these to be out of control because a) they do not provide what multihomers want b) it would be necessary to pay the other ISPs to advertise their competitor's prefixes. > (4) Considering the multi-homing environment, when a end-site get > a /48 from providerA, get a second /48 from providerB, and get a > third /48 from providerC, and no matter this end-site has AS > number or not, If the end-site want to take full use of the three > address space and the three links, we have to let the three > prefixes to appear in global routing table. This scenario is not even on the table. Three times worse than PI is not going to happen. The main issue regarding the size of the routing table is everyone becoming a LIR. Michel. From fink@es.net Thu Jun 27 16:59:07 2002 From: fink@es.net (Bob Fink) Date: Thu, 27 Jun 2002 08:59:07 -0700 Subject: [6bone] 6bone pTLA 3FFE:400C::/32 allocated to ICPNET-PL Message-ID: <5.1.0.14.0.20020627085742.02bf4f58@imap2.es.net> ICPNET-PL has been allocated pTLA 3FFE:400C::/32 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to hostmaster@ep.net.] Thanks, Bob From fink@es.net Thu Jun 27 17:06:35 2002 From: fink@es.net (Bob Fink) Date: Thu, 27 Jun 2002 09:06:35 -0700 Subject: [6bone] pTLA request ECITY - review closes 14 July 2002 Message-ID: <5.1.0.14.0.20020627090222.02d32068@imap2.es.net> 6bone Folk, ECITY has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 14 July 2002 (due to travel to Yokohama). Please send your comments to me or the list. Thanks, Bob === >From: "Ettore De Simone" >To: "Bob Fink" >Cc: "hq@ecity.it" >Date: Mon, 24 Jun 2002 10:21:51 +0200 >Subject: pTLA Request for Ecity (AS16035) > >Hi Bob, > >please accept this application for a pTla for eCity. > > > > > 1. The pTLA Applicant must have a minimum of three (3) months > qualifying experience as a 6Bone end-site or pNLA transit. During > the entire qualifying period the Applicant must be operationally > providing the following: > >We are connected since May 15, 2001 with a /48 delegation from EDISONTEL. > > a. Fully maintained, up to date, 6Bone Registry entries for their > ipv6-site inet6num, mntner, and person objects, including each > tunnel that the Applicant has. > >Our 6bone registry records are up to date: > >http://whois.6bone.net/cgi-bin/whois?ecity >http://whois.6bone.net/cgi-bin/whois?ecity-mnt > > b. Fully maintained, and reliable, BGP4+ peering and connectivity > between the Applicant's boundary router and the appropriate > connection point into the 6Bone. This router must be IPv6 > pingable. This criteria is judged by members of the 6Bone > Operations Group at the time of the Applicant's pTLA request. > >We have currently 2 BGP4+ peering with EURNETCITY and RMNET via a Linux >box running Zebra. >IPv6 address of the router is router-v6.ipv6.ecity.it (3ffe:8171:5f::1) >and is pingable. > > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > entries for the Applicant's router(s) and at least one host > system. > >Primary server: >dns.ipv6.ecity.it 3ffe:8171:5f:1:202:b3ff:fe28:636f >Secondary server: dns2.ipv6.ecity.it 3ffe:8171:5f:1:202:b3ff:fe28:638d > > d. A fully maintained, and reliable, IPv6-accessible system > providing, at a mimimum, one or more web pages, describing the > Applicant's IPv6 services. This server must be IPv6 pingable. > >Our IPv6 site is at http://www.ipv6.ecity.it and is IPv6 pingable. > > 2. The pTLA Applicant MUST have the ability and intent to provide > "production-quality" 6Bone backbone service. Applicants must > provide a statement and information in support of this claim. > This MUST include the following: > > a. A support staff of two persons minimum, three preferable, with > person attributes registered for each in the ipv6-site object > for the pTLA applicant. > >Our technical staff is: > >http://whois.6bone.net/cgi-bin/whois?EDS1-6BONE >http://whois.6bone.net/cgi-bin/whois?GR4-6BONE > > b. A common mailbox for support contact purposes that all support > staff have acess to, pointed to with a notify attribute in the > ipv6-site object for the pTLA Applicant. > >We have two common mailboxes: ipv6@ecity.it and noc-ipv6@ecity.it > > 3. The pTLA Applicant MUST have a potential "user community" that > would be served by its becoming a pTLA, e.g., the Applicant is a > major provider of Internet service in a region, country, or focus > of interest. Applicant must provide a statement and information in > support this claim. > >eCity is an Application Service Provider located in Rome, Italy. It >provides Internet or dedicated-line access to centralized >Application Services in its Data Center to external and in-house >customers, as well as technical support, consulting services, >server housing and hosting, and internet access for its in-house customers. > > 4. The pTLA Applicant MUST commit to abide by the current 6Bone > operational rules and policies as they exist at time of its > application, and agree to abide by future 6Bone backbone > operational rules and policies as they evolve by consensus of the > 6Bone backbone and user community. > >We fully agree to all current and future operational rules and policies. > > > >Regards, > >Ettore De Simone > >eCity Systems and Network Administrator > > > > >================================================== >Ettore De Simone >Systems and Network Administrator >eCity S.r.l - Application Service Provider >Via Portuense 1555 - 00050 Roma >Tel. +39-6-65003149 Fax. +39-6-65003156 >Email: e.desimone@ecity.it >================================================== From fink@es.net Thu Jun 27 17:08:40 2002 From: fink@es.net (Bob Fink) Date: Thu, 27 Jun 2002 09:08:40 -0700 Subject: [6bone] pTLA request ECITY - review closes 14 July 2002 Message-ID: <5.1.0.14.0.20020627090719.02d14028@imap2.es.net> 6bone Folk, ECITY has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 14 July 2002 (a few days longer than usual due to travel to Yokohama). Please send your comments to me or the list. Thanks, Bob === From: "Ettore De Simone" To: "Bob Fink" Cc: "hq@ecity.it" Date: Mon, 24 Jun 2002 10:21:51 +0200 Subject: pTLA Request for Ecity (AS16035) Hi Bob, please accept this application for a pTla for eCity. 1. The pTLA Applicant must have a minimum of three (3) months qualifying experience as a 6Bone end-site or pNLA transit. During the entire qualifying period the Applicant must be operationally providing the following: We are connected since May 15, 2001 with a /48 delegation from EDISONTEL. a. Fully maintained, up to date, 6Bone Registry entries for their ipv6-site inet6num, mntner, and person objects, including each tunnel that the Applicant has. Our 6bone registry records are up to date: http://whois.6bone.net/cgi-bin/whois?ecity http://whois.6bone.net/cgi-bin/whois?ecity-mnt b. Fully maintained, and reliable, BGP4+ peering and connectivity between the Applicant's boundary router and the appropriate connection point into the 6Bone. This router must be IPv6 pingable. This criteria is judged by members of the 6Bone Operations Group at the time of the Applicant's pTLA request. We have currently 2 BGP4+ peering with EURNETCITY and RMNET via a Linux box running Zebra. IPv6 address of the router is router-v6.ipv6.ecity.it (3ffe:8171:5f::1) and is pingable. c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) entries for the Applicant's router(s) and at least one host system. Primary server: dns.ipv6.ecity.it 3ffe:8171:5f:1:202:b3ff:fe28:636f Secondary server: dns2.ipv6.ecity.it 3ffe:8171:5f:1:202:b3ff:fe28:638d d. A fully maintained, and reliable, IPv6-accessible system providing, at a mimimum, one or more web pages, describing the Applicant's IPv6 services. This server must be IPv6 pingable. Our IPv6 site is at http://www.ipv6.ecity.it and is IPv6 pingable. 2. The pTLA Applicant MUST have the ability and intent to provide "production-quality" 6Bone backbone service. Applicants must provide a statement and information in support of this claim. This MUST include the following: a. A support staff of two persons minimum, three preferable, with person attributes registered for each in the ipv6-site object for the pTLA applicant. Our technical staff is: http://whois.6bone.net/cgi-bin/whois?EDS1-6BONE http://whois.6bone.net/cgi-bin/whois?GR4-6BONE b. A common mailbox for support contact purposes that all support staff have acess to, pointed to with a notify attribute in the ipv6-site object for the pTLA Applicant. We have two common mailboxes: ipv6@ecity.it and noc-ipv6@ecity.it 3. The pTLA Applicant MUST have a potential "user community" that would be served by its becoming a pTLA, e.g., the Applicant is a major provider of Internet service in a region, country, or focus of interest. Applicant must provide a statement and information in support this claim. eCity is an Application Service Provider located in Rome, Italy. It provides Internet or dedicated-line access to centralized Application Services in its Data Center to external and in-house customers, as well as technical support, consulting services, server housing and hosting, and internet access for its in-house customers. 4. The pTLA Applicant MUST commit to abide by the current 6Bone operational rules and policies as they exist at time of its application, and agree to abide by future 6Bone backbone operational rules and policies as they evolve by consensus of the 6Bone backbone and user community. We fully agree to all current and future operational rules and policies. Regards, Ettore De Simone eCity Systems and Network Administrator ================================================== Ettore De Simone Systems and Network Administrator eCity S.r.l - Application Service Provider Via Portuense 1555 - 00050 Roma Tel. +39-6-65003149 Fax. +39-6-65003156 Email: e.desimone@ecity.it ================================================== From dragon@tdoi.org Thu Jun 27 22:47:35 2002 From: dragon@tdoi.org (Christian Nickel) Date: Thu, 27 Jun 2002 23:47:35 +0200 Subject: [6bone] fake/hijacked sTLA/pTLA's from AS1654 Message-ID: <001001c21e24$3fe16ff0$fd04a80a@alpha> This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C21E35.03472790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I'm receiving some strange routing informations from AS1654 via multiple other AS's. Have a look to the attached textfile. There are problems with SICS or someone announcing faked sTLA/pTLA's? greets, Christian ------=_NextPart_000_000D_01C21E35.03472790 Content-Type: text/plain; name="bgp_as1654.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="bgp_as1654.txt" i think this is the pTLA announced by SICS (AS 1654) *>i3ffe:200::/24 100 0 24765 = 1654 i the other fake/hijacked sTLA's and pTLA's are announced from AS 1654? *>i2001:208::/35 10 100 0 8379 = 24765 1654 i *>i2001:2d8::/35 100 0 1752 = 3265 15897 10566 2042 24765 1654 i *>i2001:3c0::/35 100 0 8627 = 12337 10566 5594 13193 109 6435 6342 3265 24765 1654 i *>i2001:528::/35 100 0 24765 = 10566 6175 3549 2713 2042 45328 8277 15589 1654 i *>i2001:5e0::/35 100 0 24765 = 10566 5594 2200 513 9264 7660 2500 11537 2603 1275 3320 1654 i *>i2001:738::/35 100 0 8627 = 6830 6175 7580 10566 13193 109 6342 3265 24765 1654 i *>i2001:7e8::/35 100 0 24765 = 15897 10566 17715 6939 2042 45328 8277 8379 1275 15589 1654 i *>i2001:7f8::/35 100 0 24765 = 10566 2042 45328 8277 8379 1275 15589 1654 i *>i3ffe:d00::/24 100 0 24765 = 10566 6939 3320 293 5609 8002 33 15589 1654 i *>i3ffe:e00::/24 100 0 24765 = 6939 17715 10566 8002 33 15589 1654 i *>i3ffe:1100::/24 100 0 24765 = 10566 5594 8002 33 15589 1654 i *>i3ffe:1400::/24 100 0 24765 = 10566 5594 8002 33 15589 1654 i *>i3ffe:1600::/24 10 100 0 8379 = 24765 1654 i *>i3ffe:1700::/24 100 0 24765 = 6939 17715 10566 8002 33 15589 1654 i *>i3ffe:1a00::/24 100 0 24765 = 6939 9044 10566 5594 6830 5609 33 15589 1654 i *>i3ffe:1b00::/24 100 0 24765 = 6939 9044 10566 5594 6830 5609 33 15589 1654 i *>i3ffe:1e00::/24 100 0 24765 = 6939 9044 10566 5594 6830 5609 33 15589 1654 i *>i3ffe:1f00::/24 100 0 24765 = 6939 9044 10566 5594 6830 5609 33 15589 1654 i *>i3ffe:2300::/24 100 0 24765 = 6939 9044 10566 5594 6830 5609 33 15589 1654 i *>i3ffe:2400::/24 100 0 24765 = 6939 9044 10566 5594 6830 5609 33 15589 1654 i *>i3ffe:2700::/24 100 0 24765 = 6939 9044 10566 5594 6830 5609 33 15589 1654 i *>i3ffe:2f00::/24 100 0 24765 = 6939 9044 10566 5594 6830 5609 33 15589 1654 i *>i3ffe:3000::/24 100 0 24765 = 6939 9044 10566 5594 6830 5609 33 15589 1654 i *>i3ffe:3400::/24 100 0 24765 = 6939 9044 10566 5594 6830 5609 33 15589 1654 i *>i3ffe:3a00::/24 500 100 0 8379 = 8379 10566 3265 1103 2200 513 9264 7660 2500 4725 6939 5539 3320 1654 i *>i3ffe:3b00::/24 500 100 0 8379 = 8379 10566 5594 2200 1916 1930 6939 145 293 109 5539 8472 1752 6830 1654 = i *>i3ffe:3c00::/24 500 100 0 8379 = 8379 10566 6939 3265 9264 7660 2500 3425 293 5609 4554 5539 8472 1752 = 6830 1654 i *>i3ffe:3d00::/24 100 0 1752 = 5408 10566 5594 2200 1103 3425 293 4554 278 6939 2042 45328 8277 8379 = 1275 15589 1654 i *>i3ffe:3e00::/24 500 100 0 8379 = 8379 10566 5594 6830 6939 145 6175 5408 2549 109 9264 7660 2500 4725 = 3748 1275 15589 1654 i *>i3ffe:3f00::/24 500 100 0 8379 = 8379 10566 3265 20834 513 9264 7660 2500 4725 6939 5539 3320 1654 i *>i3ffe:80f0::/28 100 0 24765 = 10566 5594 8002 33 15589 1654 i *>i3ffe:8210::/28 100 0 24765 = 10566 5594 8002 33 15589 1654 i *>i3ffe:8340::/28 100 0 24765 = 10566 6939 17715 109 9264 7660 2500 4725 3748 1275 5609 1654 i *>i3ffe:8390::/28 500 100 0 8379 = 8379 10566 15589 3320 2549 109 1251 3265 20834 1654 i *>i3ffe:83a0::/28 100 0 8379 = 5539 9044 10566 9264 7660 2500 4725 3748 1275 3320 1654 i *>i3ffe:83b0::/28 500 100 0 8379 = 8379 10566 6939 9264 7660 2500 4725 3748 1275 5609 1654 i *>i3ffe:83c0::/28 500 100 0 8379 = 8379 10566 9264 7660 2500 4725 3748 1275 5609 1654 i *>i3ffe:83d0::/28 100 0 8379 = 5539 9044 10566 6939 9264 7660 2500 4725 3748 1275 3320 1654 i *>i3ffe:83e0::/28 500 100 0 8379 = 8379 10566 6939 9264 7660 2500 4725 3748 1275 3320 1654 i *>i3ffe:83f0::/28 100 0 1752 = 5408 6175 7580 10566 3265 6435 278 6939 9264 7660 2500 4725 3748 1275 = 15589 1654 i *>i3ffe:8400::/28 500 100 0 8379 = 8379 10566 3265 6435 2549 109 3320 1275 15589 1654 i ------=_NextPart_000_000D_01C21E35.03472790-- From michel@arneill-py.sacramento.ca.us Fri Jun 28 00:10:21 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 27 Jun 2002 16:10:21 -0700 Subject: [6bone] fake/hijacked sTLA/pTLA's from AS1654 Message-ID: <2B81403386729140A3A899A8B39B046405E168@server2000.arneill-py.sacramento.ca.us> > Christian Nickel wrote: > I'm receiving some strange routing informations from > AS1654 via multiple other AS's. Have a look to the attached > textfile. There are problems with SICS or someone > announcing faked sTLA/pTLA's? This looks very much like the BGP withdraw route bug we had a while ago, and last time the AS that appeared to be the source of the problem did indeed not announce anything bad. Does someone remember what the resolution was? Michel. From jeroen@unfix.org Fri Jun 28 00:11:54 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Fri, 28 Jun 2002 01:11:54 +0200 Subject: [6bone] fake/hijacked sTLA/pTLA's from AS1654 In-Reply-To: <001001c21e24$3fe16ff0$fd04a80a@alpha> Message-ID: <001a01c21e30$07a85110$420d640a@unfix.org> Christian Nickel wrote: > Hi, > > I'm receiving some strange routing informations from AS1654 > via multiple other AS's. Have a look to the attached textfile. > There are problems with SICS or someone announcing > faked sTLA/pTLA's? Welll their router certainly is peeping up... and it is announcing certain routes that it shouldn't. Check http://www.ipng.nl/bgp/bgp-page-complete.html and http://www.ipng.nl/bgp/odd-routes.html It also shows a LOT of unaggregated prefixes... http://www.ipng.nl/bgp/odd-routes1.html Almost anything goes to SICS. It more or less looks like a replay from a _very_ old date. Most of the announced prefixes _are_ valid but haven't been in active use for a while. SICS guys CC:'d http://www.ipv6.sics.se/6bone_config/netstat_rn.dump looks kinda normal.... odd... Greets, Jeroen From rrockell@sprint.net Fri Jun 28 00:23:52 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Thu, 27 Jun 2002 19:23:52 -0400 (EDT) Subject: [6bone] fake/hijacked sTLA/pTLA's from AS1654 In-Reply-To: <2B81403386729140A3A899A8B39B046405E168@server2000.arneill-py.sacramento.ca.us> Message-ID: Last I checked, ingress and egress filters did the trick... Thanks Rob Rockell SprintLink (+1) 703-689-6322 Sprint IP Services ----------------------------------------------------------------------- On Thu, 27 Jun 2002, Michel Py wrote: ->> Christian Nickel wrote: ->> I'm receiving some strange routing informations from ->> AS1654 via multiple other AS's. Have a look to the attached ->> textfile. There are problems with SICS or someone ->> announcing faked sTLA/pTLA's? -> ->This looks very much like the BGP withdraw route bug we had a while ago, ->and last time the AS that appeared to be the source of the problem did ->indeed not announce anything bad. -> ->Does someone remember what the resolution was? -> ->Michel. -> ->_______________________________________________ ->6bone mailing list ->6bone@mailman.isi.edu ->http://mailman.isi.edu/mailman/listinfo/6bone -> From fink@es.net Fri Jun 28 14:15:19 2002 From: fink@es.net (Bob Fink) Date: Fri, 28 Jun 2002 06:15:19 -0700 Subject: [6bone] 6bone pTLA 3FFE:400D::/32 allocated to EURNETCITY Message-ID: <5.1.0.14.0.20020628061242.02e182a0@imap2.es.net> EURNETCITY has been allocated pTLA 3FFE:400D::/32 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to hostmaster@ep.net.] Thanks, Bob