From pasky@pasky.ji.cz Tue Jul 2 19:39:22 2002 From: pasky@pasky.ji.cz (Petr Baudis) Date: Tue, 2 Jul 2002 20:39:22 +0200 Subject: [6bone] Re: Please make 3ffe::/16 reverse-delegations under ip6.arpa Message-ID: <20020702183922.GL2947@pasky.ji.cz> Hello, Dear diary, on Thu, Jan 17, 2002 at 02:27:26PM CET, I got a letter, where Bill Manning told me, that... > It would have been nice if the RIRs and ICANN had considered this when they > enabled ip6.arpa. As it stands, they have beeen asked, repeatedly by me, and > now at the RIPE mtg as to why it has still not been done. I would like to ask, is there any progress in this issue? Delegation for 6bone address space is not there yet, and our users are already asking about that - we don't know what to tell them. Can we help in some way? Who we should ask why the delegation is not yet done? Thanks in advance, -- Petr "Pasky" Baudis * ELinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI occassional hacker . "Capitalism is the extraordinary belief that the nastiest of men, for the nastiest of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From dragon@tdoi.org Tue Jul 2 22:50:21 2002 From: dragon@tdoi.org (Christian Nickel) Date: Tue, 2 Jul 2002 23:50:21 +0200 Subject: Fw: [6bone] fake/hijacked sTLA/pTLA's from AS1654 Message-ID: <001001c22212$77022460$fd04a80a@alpha> ----- Original Message ----- From: "Lars Albertsson" To: "Jeroen Massar" Cc: "'Christian Nickel'" ; <6bone@mailman.isi.edu>; ; Sent: Friday, June 28, 2002 4:48 PM Subject: Re: [6bone] fake/hijacked sTLA/pTLA's from AS1654 > "Jeroen Massar" writes: > > > 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? > > Thanks for the heads up. Some time seems to have passed, however, and > some of the problems seems to have disappeared. > > > 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 > > I don't understand the implications of this page. I notice that SICS > is at the end of many lines, but I don't know what that means. Maybe > somebody can give me an example of a specific advertisement that we > make that isn't correct? > > > and http://www.ipng.nl/bgp/odd-routes.html > > It also shows a LOT of unaggregated prefixes... > > I see 3ffe:8400::/28, which is no longer in our routing tables, and > 3ffe:6000::/24, which seems to be announced to us by CALDAN. I don't > know why we are at the end of the chain, and would appreciate if > somebody could dig out a log entry with an invalid advertisement. We > are interested in getting rid of the problem, but we hardly have any > resources to debug possible issues without knowing the details. :( > Sorry about that... > > > http://www.ipng.nl/bgp/odd-routes1.html > > I don't see anything originated from us here now. > > > 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... > > Thanks for looking at our dumps. I can't see anything odd here now, > however. If you notice something, please tell me what. > > I think the router has restarted since you sent the mail, so some of > the issues may have vanished. > > Sorry if we have caused inconvenience. > > Mikael: I'll be on vacation next week, so if any problems requiring > urgent attention comes up, I can't handle it quickly. > > /Lalle > > From bmanning@ISI.EDU Wed Jul 3 17:10:50 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 3 Jul 2002 09:10:50 -0700 (PDT) Subject: [6bone] Re: Please make 3ffe::/16 reverse-delegations under ip6.arpa In-Reply-To: <20020702183408.GJ2947@pasky.ji.cz> from Petr Baudis at "Jul 2, 2 08:34:08 pm" Message-ID: <200207031610.g63GAo915006@boreas.isi.edu> % Hello, % % Dear diary, on Thu, Jan 17, 2002 at 02:27:26PM CET, I got a letter, where Bill % Manning told me, that... % > It would have been nice if the RIRs and ICANN had considered this when they % > enabled ip6.arpa. As it stands, they have beeen asked, repeatedly by me, and % > now at the RIPE mtg as to why it has still not been done. % % I would like to ask, is there any progress in this issue? Delegation for % 6bone address space is not there yet, and our users are already asking about % that - we don't know what to tell them. Can we help in some way? Who we should % ask why the delegation is not yet done? % % Thanks in advance, % % -- % % Petr "Pasky" Baudis RFC 3152 indicates that until the 6bone is subsumed by the RIRs that it will not show up in ip6.arpa. Bob Fink has had some discussion with the RIRs on what it will take to have the 6bone address assignments move from an engineering/development status to production/commercial status. No word on the status of those discussions. -- --bill From wizard@italiansky.com Sat Jul 6 10:25:44 2002 From: wizard@italiansky.com (Matteo Tescione) Date: Sat, 6 Jul 2002 11:25:44 +0200 Subject: [6bone] PPP6 Message-ID: <001701c224cf$1afdb520$8cf51150@local.comv6.com> Hello, I would like to know if there's an experimental version of PPP6 for cisco access server, I heard that few time ago it was available to some pTla, does anyone know somethin' more? Thanks a lot, Best regards, Matteo Tescione Ipv6 Dept. COMV6 - Italy From paitken@cisco.com Sat Jul 6 14:04:29 2002 From: paitken@cisco.com (Paul Aitken) Date: Sat, 06 Jul 2002 14:04:29 +0100 Subject: [6bone] PPP6 References: <001701c224cf$1afdb520$8cf51150@local.comv6.com> Message-ID: <3D26EADD.7080309@cisco.com> Matteo, > I would like to know if there's an experimental version of PPP6 for cisco > access server, I heard that few time ago it was available to some pTla, does > anyone know somethin' more? The right place to send this question is ipv6-support@cisco.com. But yes, we do support RFC 2472. Cheers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From pim@ipng.nl Sun Jul 7 12:31:20 2002 From: pim@ipng.nl (Pim van Pelt) Date: Sun, 7 Jul 2002 13:31:20 +0200 Subject: [6bone] whois.6bone.net Message-ID: <20020707113120.GA25263@bfib.colo.bit.nl> hi, Can sombody please check up on the 6bone database at whois.6bone.net ? It has been down for an extended period of time. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From michal-ipv6@logix.cz Tue Jul 9 13:47:08 2002 From: michal-ipv6@logix.cz (Michal Ludvig) Date: Tue, 9 Jul 2002 14:47:08 +0200 (CEST) Subject: [6bone] BGP confusion Message-ID: Hi all, I'm a little confused about using the AS numbers in IPv6 sites. Here is a part of the zebra's example: router bgp 7675 neighbor 3ffe:506:1000::2 remote-as 7675 neighbor 3ffe:506:1000::2 next-hop-self neighbor fe80::200:c0ff:fe30:9be3 remote-as 9377 neighbor fe80::200:c0ff:fe30:9be3 interface sit3 neighbor fe80::210:5aff:fe6b:3cee remote-as 7675 neighbor fe80::210:5aff:fe6b:3cee interface eth0 neighbor fe80::290:27ff:fe51:84c7 remote-as 4691 neighbor fe80::290:27ff:fe51:84c7 interface sit7 [...] If I understand it correctly, the 7675, 9377 and 4691 are numbers of autonomous systems. But how do I get an AS number of an IPv6 site? I'm about to set up BGP routing first inside my IPv6 network and then perhaps even for external tunnels, but what AS number should I use for my internal network with a prefix obtained from xs26.net? Is that an AS number of IPv4 address of my "border" router? Thanks in advance for clarifying this issue. Michal Ludvig -- http://www.ipv6.logix.cz From itojun@iijlab.net Tue Jul 9 14:27:50 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Tue, 09 Jul 2002 22:27:50 +0900 Subject: [6bone] Re: BGP confusion In-Reply-To: michal-ipv6's message of Tue, 09 Jul 2002 14:47:08 +0200. Message-ID: <20020709132750.1B44B4B27@coconut.itojun.org> >If I understand it correctly, the 7675, 9377 and 4691 are numbers of >autonomous systems. But how do I get an AS number of an IPv6 site? get one from your nearest RIR (RIPE, ARIN, APNIC) if you need a globally-unique AS number. if you just need to peer with your upstream and the route needs to go no further, you can use private AS number range. but you need to negotiate with your peers first. itojun From fink@es.net Wed Jul 10 15:05:45 2002 From: fink@es.net (Bob Fink) Date: Wed, 10 Jul 2002 07:05:45 -0700 Subject: [6bone] 6bone meeting in Yokohama Message-ID: <5.1.0.14.0.20020710065827.00b4feb8@imap2.es.net> 6bone Folk: I am scheduling a 6bone meeting in Yokohama on Wednesday, just after the ngtrans meeting ends, in the same room. It will be the usual timing to let the room clear for 15 minutes and ending 15 minutes before the next meeting starts. Wed. 17 July 11:45am - 12:45pm same room as ngtrans is in I will talk about the discussions I've been having with the registries about conversion of the 6bone address registry to the RIRs and giving the 6bone access to the ip6.arpa reverse registry that the RIRs operate. There is no formal draft yet, just the informal ideas, but I will present all that I know as of the meeting. See you there, Bob From tvo@EnterZone.Net Wed Jul 10 22:14:54 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 10 Jul 2002 17:14:54 -0400 (EDT) Subject: [6bone] problem setting up routing for a /48 Message-ID: I am having problems getting routing to work with IPv6 and linux. I have a tunnel set up to freenet6 on router1. Freenet6 has assigned 3ffe:b80:e32::/48 to me and I have 3ffe:b80:e32:1::1/64 bound up on lec0. [root@Border1 bin]# ip -6 address 1: lo: mtu 16436 qdisc noqueue inet6 ::1/128 scope host 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 inet6 fe80::250:4ff:fe76:4875/10 scope link 4: dummy0: mtu 1500 qdisc noqueue inet6 fe80::200:ff:fe00:0/10 scope link 8: lec0: mtu 1500 qdisc pfifo_fast qlen 100 inet6 fe80::220:48ff:fe0e:e3cc/10 scope link inet6 3ffe:b80:e32:1::1/64 scope global 9: sit1@NONE: mtu 1480 qdisc noqueue inet6 fe80::4223:5f1e/10 scope link inet6 fe80::4223:4025/10 scope link inet6 fe80::d173:7f16/10 scope link inet6 3ffe:b80:2:a8ac::2/128 scope global inet6 fe80::4223:5f01/10 scope link The routing table appears to be appropriate: [root@Border1 bin]# ip -6 route 3ffe:b80:e32:1::/64 dev lec0 proto kernel metric 256 mtu 1500 3ffe:b80:e32::/48 dev lec0 metric 1 mtu 1500 fe80::/10 dev dummy0 proto kernel metric 256 mtu 1500 fe80::/10 dev eth0 proto kernel metric 256 mtu 1500 fe80::/10 dev lec0 proto kernel metric 256 mtu 1500 fe80::/10 via :: dev sit1 proto kernel metric 256 mtu 1480 ff00::/8 dev dummy0 proto kernel metric 256 mtu 1500 ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 ff00::/8 dev lec0 proto kernel metric 256 mtu 1500 ff00::/8 dev sit1 proto kernel metric 256 mtu 1480 default dev sit1 metric 1 mtu 1480 unreachable default dev lo metric -1 error -101 I have 3ffe:b80:e32:1::2/64 bound up on router2: [root@Border2 bin]# ip -6 address 1: lo: mtu 16436 qdisc noqueue inet6 ::1/128 scope host 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 inet6 fe80::290:27ff:fecb:aafb/10 scope link inet6 3ffe:b80:e32:1::2/64 scope global 3: dummy0: mtu 1500 qdisc noqueue inet6 fe80::200:ff:fe00:0/10 scope link ...and the appropriate default (::/0) pointed at 3ffe:b80:e32:1::1 [root@Border2 bin]# ip -6 route 3ffe:b80:e32:1::/64 dev eth0 proto kernel metric 256 mtu 1500 fe80::/10 dev dummy0 proto kernel metric 256 mtu 1500 fe80::/10 dev eth0 proto kernel metric 256 mtu 1500 ff00::/8 dev dummy0 proto kernel metric 256 mtu 1500 ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 default via 3ffe:b80:e32:1::1 dev eth0 metric 1024 mtu 1500 unreachable default dev lo metric -1 error -101 The problem is that routing is problematic at best from router2: [root@Border2 bin]# ping6 www.6bone.net PING www.6bone.net(www.6bone.net) 56 data bytes >From 3ffe:b80:e32:1::1: Destination unreachable: Address unreachable >From 3ffe:b80:e32:1::1: Destination unreachable: Address unreachable --- www.6bone.net ping statistics --- 2 packets transmitted, 0 packets received, +2 errors, 100% packet loss If I ping www.6bone.net from router1: [root@Border1 bin]# ping6 www.6bone.net PING www.6bone.net(www.6bone.net) 56 data bytes 64 bytes from www.6bone.net: icmp_seq=0 hops=62 time=52.691 msec 64 bytes from www.6bone.net: icmp_seq=1 hops=62 time=72.086 msec --- www.6bone.net ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/mdev = 52.691/62.388/72.086/9.700 ms ...I can then reach it from router2. In the display below, I started a ping6 from router2 to www.6bone.net. I then started a ping6 from router1 (the gateway for router2) to www.6bone.net. As soon as the ping6 on router1 started, the ping6 on router2 starts working: [root@Border2 bin]# ping6 www.6bone.net PING www.6bone.net(www.6bone.net) 56 data bytes >From 3ffe:b80:e32:1::1: Destination unreachable: Address unreachable >From 3ffe:b80:e32:1::1: Destination unreachable: Address unreachable >From 3ffe:b80:e32:1::1: Destination unreachable: Address unreachable 64 bytes from www.6bone.net: icmp_seq=3 hops=61 time=53.873 msec 64 bytes from www.6bone.net: icmp_seq=4 hops=61 time=53.169 msec 64 bytes from www.6bone.net: icmp_seq=5 hops=61 time=53.721 msec --- www.6bone.net ping statistics --- 7 packets transmitted, 3 packets received, +3 errors, 57% packet loss round-trip min/avg/max/mdev = 53.169/53.587/53.873/0.403 ms I then stopped the ping6 on router1 and soon after, router2 could no longer reach www.6bone.net: [root@Border2 bin]# ping6 www.6bone.net PING www.6bone.net(www.6bone.net) 56 data bytes 64 bytes from www.6bone.net: icmp_seq=0 hops=61 time=58.586 msec 64 bytes from www.6bone.net: icmp_seq=1 hops=61 time=53.383 msec 64 bytes from www.6bone.net: icmp_seq=2 hops=61 time=59.519 msec 64 bytes from www.6bone.net: icmp_seq=3 hops=61 time=63.576 msec 64 bytes from www.6bone.net: icmp_seq=4 hops=61 time=61.473 msec 64 bytes from www.6bone.net: icmp_seq=5 hops=61 time=59.763 msec 64 bytes from www.6bone.net: icmp_seq=6 hops=61 time=53.719 msec 64 bytes from www.6bone.net: icmp_seq=7 hops=61 time=59.625 msec 64 bytes from www.6bone.net: icmp_seq=8 hops=61 time=59.989 msec 64 bytes from www.6bone.net: icmp_seq=9 hops=61 time=53.450 msec 64 bytes from www.6bone.net: icmp_seq=10 hops=61 time=53.551 msec 64 bytes from www.6bone.net: icmp_seq=11 hops=61 time=53.595 msec 64 bytes from www.6bone.net: icmp_seq=12 hops=61 time=59.718 msec 64 bytes from www.6bone.net: icmp_seq=13 hops=61 time=65.459 msec 64 bytes from www.6bone.net: icmp_seq=14 hops=61 time=53.319 msec 64 bytes from www.6bone.net: icmp_seq=15 hops=61 time=54.186 msec 64 bytes from www.6bone.net: icmp_seq=16 hops=61 time=56.177 msec 64 bytes from www.6bone.net: icmp_seq=17 hops=61 time=53.511 msec 64 bytes from www.6bone.net: icmp_seq=18 hops=61 time=53.473 msec 64 bytes from www.6bone.net: icmp_seq=19 hops=61 time=54.107 msec 64 bytes from www.6bone.net: icmp_seq=20 hops=61 time=59.824 msec 64 bytes from www.6bone.net: icmp_seq=21 hops=61 time=53.605 msec >From 3ffe:b80:e32:1::1: Destination unreachable: Address unreachable >From 3ffe:b80:e32:1::1: Destination unreachable: Address unreachable --- www.6bone.net ping statistics --- 24 packets transmitted, 22 packets received, +2 errors, 8% packet loss round-trip min/avg/max/mdev = 53.319/56.982/65.459/3.750 ms Traceroute6 yields the same results. As long as router1 has a ping6 going against www.6bone.net, router2 can get there via router1: [root@Border2 bin]# traceroute6 www.6bone.net traceroute to 6bone.net (3ffe:b00:c18:1::10) from 3ffe:b80:e32:1::2, 30 hops max, 16 byte packets 1 3ffe:b80:e32:1::1 (3ffe:b80:e32:1::1) 2.269 ms 1.306 ms 0.871 ms 2 3ffe:b00:c18:1:2a0:c9ff:fefc:1feb (3ffe:b00:c18:1:2a0:c9ff:fefc:1feb) 62.574 ms 93.856 ms 61.972 ms 3 www.6bone.net (3ffe:b00:c18:1::10) 82.151 ms 53.484 ms 53.66 ms ...within 30 seconds of stopping the ping6 to www.6bone.net on router1, router2 can't get there: [root@Border2 bin]# traceroute6 www.6bone.net traceroute to 6bone.net (3ffe:b00:c18:1::10) from 3ffe:b80:e32:1::2, 30 hops max, 16 byte packets 1 3ffe:b80:e32:1::1 (3ffe:b80:e32:1::1) 0.997 ms !H 1.668 ms !H 0.873 ms !H Can anyone tell me what I'm doing wrong here? I'm at my wits end! --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From michel@arneill-py.sacramento.ca.us Wed Jul 10 22:40:51 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 10 Jul 2002 14:40:51 -0700 Subject: [6bone] 6bone meeting in Yokohama Message-ID: <2B81403386729140A3A899A8B39B046405E1A4@server2000.arneill-py.sacramento.ca.us> Bob, > I am scheduling a 6bone meeting in Yokohama on Wednesday, just after > the ngtrans meeting ends, in the same room. It will be the usual > timing to let the room clear for 15 minutes and ending 15 minutes > before the next meeting starts. > Wed. 17 July 11:45am - 12:45pm same room as ngtrans is in > I will talk about the discussions I've been having with the > registries about conversion of the 6bone address registry to the > RIRs and giving the 6bone access to the ip6.arpa reverse registry > that the RIRs operate. > There is no formal draft yet, just the informal ideas, but I will > present all that I know as of the meeting. Would it be possible for you to post some slides sometime before the meeting? Although you will likely cover the topic in your presentation, I think the 6bone community would be interested to know, with regard to this conversion of the 6bone registry to the RIRs: - Will it trigger another RFC to update / replace 2471? - Will it change anything for existing assignments? - Will it change anything for future pTLA requests? - Will it change anything for special purposes requests? Thanks Michel. From fink@es.net Thu Jul 11 00:24:05 2002 From: fink@es.net (Bob Fink) Date: Wed, 10 Jul 2002 16:24:05 -0700 Subject: [6bone] 6bone meeting in Yokohama In-Reply-To: <2B81403386729140A3A899A8B39B046405E1A4@server2000.arneill- py.sacramento.ca.us> Message-ID: <5.1.0.14.0.20020710162247.00b50300@imap2.es.net> Michel, I'll post something after the meeting as it isn't quite ready yet and I'm about to leave for Yokohama. I am also meeting with the RIR folk in Yokohama to discuss more before the meeting. Bob At 02:40 PM 7/10/2002 -0700, Michel Py wrote: >Bob, > > > I am scheduling a 6bone meeting in Yokohama on Wednesday, just after > > the ngtrans meeting ends, in the same room. It will be the usual > > timing to let the room clear for 15 minutes and ending 15 minutes > > before the next meeting starts. > > Wed. 17 July 11:45am - 12:45pm same room as ngtrans is in > > I will talk about the discussions I've been having with the > > registries about conversion of the 6bone address registry to the > > RIRs and giving the 6bone access to the ip6.arpa reverse registry > > that the RIRs operate. > > There is no formal draft yet, just the informal ideas, but I will > > present all that I know as of the meeting. > >Would it be possible for you to post some slides sometime before the >meeting? > >Although you will likely cover the topic in your presentation, I think >the 6bone community would be interested to know, with regard to this >conversion of the 6bone registry to the RIRs: > >- Will it trigger another RFC to update / replace 2471? >- Will it change anything for existing assignments? >- Will it change anything for future pTLA requests? >- Will it change anything for special purposes requests? > >Thanks >Michel. > >_______________________________________________ >6bone mailing list >6bone@mailman.isi.edu >http://mailman.isi.edu/mailman/listinfo/6bone From michel@arneill-py.sacramento.ca.us Thu Jul 11 01:38:27 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 10 Jul 2002 17:38:27 -0700 Subject: [6bone] 6bone meeting in Yokohama Message-ID: <2B81403386729140A3A899A8B39B046405E1A6@server2000.arneill-py.sacramento.ca.us> Bob, > I'll post something after the meeting as it isn't quite ready yet > and I'm about to leave for Yokohama. I am also meeting with the > RIR folk in Yokohama to discuss more before the meeting. Thanks. Note that I personally am favorable to the conversion of the 6bone registry to RIRs, as the three or four drafts that the ipv6mh group will introduce sometime between Yokohama and Atlanta have some parts related to RIRs, and we wish to use some 6bone address space to beta-test the concepts. Michel. Bob At 02:40 PM 7/10/2002 -0700, Michel Py wrote: >Bob, > > > I am scheduling a 6bone meeting in Yokohama on Wednesday, just after > > the ngtrans meeting ends, in the same room. It will be the usual > > timing to let the room clear for 15 minutes and ending 15 minutes > > before the next meeting starts. > > Wed. 17 July 11:45am - 12:45pm same room as ngtrans is in > > I will talk about the discussions I've been having with the > > registries about conversion of the 6bone address registry to the > > RIRs and giving the 6bone access to the ip6.arpa reverse registry > > that the RIRs operate. > > There is no formal draft yet, just the informal ideas, but I will > > present all that I know as of the meeting. > >Would it be possible for you to post some slides sometime before the >meeting? > >Although you will likely cover the topic in your presentation, I think >the 6bone community would be interested to know, with regard to this >conversion of the 6bone registry to the RIRs: > >- Will it trigger another RFC to update / replace 2471? >- Will it change anything for existing assignments? >- Will it change anything for future pTLA requests? >- Will it change anything for special purposes requests? > >Thanks >Michel. > >_______________________________________________ >6bone mailing list >6bone@mailman.isi.edu >http://mailman.isi.edu/mailman/listinfo/6bone From fink@es.net Thu Jul 11 06:55:20 2002 From: fink@es.net (Bob Fink) Date: Wed, 10 Jul 2002 22:55:20 -0700 Subject: [6bone] 6bone meeting in Yokohama In-Reply-To: <2B81403386729140A3A899A8B39B046405E1A6@server2000.arneill- py.sacramento.ca.us> Message-ID: <5.1.0.14.0.20020710225457.02a49960@imap2.es.net> Michel, Thanks for the input. Bob === At 05:38 PM 7/10/2002 -0700, Michel Py wrote: >Bob, > > > I'll post something after the meeting as it isn't quite ready yet > > and I'm about to leave for Yokohama. I am also meeting with the > > RIR folk in Yokohama to discuss more before the meeting. > >Thanks. Note that I personally am favorable to the conversion of the >6bone registry to RIRs, as the three or four drafts that the ipv6mh >group will introduce sometime between Yokohama and Atlanta have some >parts related to RIRs, and we wish to use some 6bone address space to >beta-test the concepts. > >Michel. > > >Bob > >At 02:40 PM 7/10/2002 -0700, Michel Py wrote: > >Bob, > > > > > I am scheduling a 6bone meeting in Yokohama on Wednesday, just after > > > the ngtrans meeting ends, in the same room. It will be the usual > > > timing to let the room clear for 15 minutes and ending 15 minutes > > > before the next meeting starts. > > > Wed. 17 July 11:45am - 12:45pm same room as ngtrans is in > > > I will talk about the discussions I've been having with the > > > registries about conversion of the 6bone address registry to the > > > RIRs and giving the 6bone access to the ip6.arpa reverse registry > > > that the RIRs operate. > > > There is no formal draft yet, just the informal ideas, but I will > > > present all that I know as of the meeting. > > > >Would it be possible for you to post some slides sometime before the > >meeting? > > > >Although you will likely cover the topic in your presentation, I think > >the 6bone community would be interested to know, with regard to this > >conversion of the 6bone registry to the RIRs: > > > >- Will it trigger another RFC to update / replace 2471? > >- Will it change anything for existing assignments? > >- Will it change anything for future pTLA requests? > >- Will it change anything for special purposes requests? > > > >Thanks > >Michel. > > > >_______________________________________________ > >6bone mailing list > >6bone@mailman.isi.edu > >http://mailman.isi.edu/mailman/listinfo/6bone From jeroen@unfix.org Thu Jul 11 11:44:44 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 11 Jul 2002 12:44:44 +0200 Subject: [6bone] problem setting up routing for a /48 In-Reply-To: Message-ID: <000701c228c7$f8764a60$534510ac@cyan> John Fraizer wrote: > Can anyone tell me what I'm doing wrong here? I'm at my wits end! - What kernel version - What glibc version I see you got 4 different link-local addresses on your sit1 device. What's the ttl on this (sit1) device ? And how is your tunnel device configured for the rest? Check www.ipng.nl -> OS Setup for more hints :) Oh and ofcourse I shouldn't forget: www.bieringer.de -> Linux/IPv6. And for the rest, you might try and tcpdump your uplink, maybe something in between is not fine? Also you didn't point the 3ffe:b80:e32:1::2/64 to router2 from router1. Greets, Jeroen From pekkas@netcore.fi Thu Jul 11 15:20:22 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 11 Jul 2002 17:20:22 +0300 (EEST) Subject: [6bone] problem setting up routing for a /48 In-Reply-To: Message-ID: On Wed, 10 Jul 2002, John Fraizer wrote: > The routing table appears to be appropriate: > > [root@Border1 bin]# ip -6 route > 3ffe:b80:e32:1::/64 dev lec0 proto kernel metric 256 mtu 1500 > 3ffe:b80:e32::/48 dev lec0 metric 1 mtu 1500 > fe80::/10 dev dummy0 proto kernel metric 256 mtu 1500 > fe80::/10 dev eth0 proto kernel metric 256 mtu 1500 > fe80::/10 dev lec0 proto kernel metric 256 mtu 1500 > fe80::/10 via :: dev sit1 proto kernel metric 256 mtu 1480 > ff00::/8 dev dummy0 proto kernel metric 256 mtu 1500 > ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 > ff00::/8 dev lec0 proto kernel metric 256 mtu 1500 > ff00::/8 dev sit1 proto kernel metric 256 mtu 1480 > default dev sit1 metric 1 mtu 1480 ^^^^^^^ > unreachable default dev lo metric -1 error -101 Linux kernel does not work with "default" route when forwarding packets. Use 2000::/3 instead. -- 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 jeroen@unfix.org Thu Jul 11 17:49:43 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 11 Jul 2002 18:49:43 +0200 Subject: [6bone] problem setting up routing for a /48 In-Reply-To: Message-ID: <000b01c228fa$f596c8f0$420d640a@unfix.org> Pekka Savola wrote: > On Wed, 10 Jul 2002, John Fraizer wrote: > > The routing table appears to be appropriate: > > > > [root@Border1 bin]# ip -6 route > > 3ffe:b80:e32:1::/64 dev lec0 proto kernel metric 256 mtu 1500 > > 3ffe:b80:e32::/48 dev lec0 metric 1 mtu 1500 > > fe80::/10 dev dummy0 proto kernel metric 256 mtu 1500 > > fe80::/10 dev eth0 proto kernel metric 256 mtu 1500 > > fe80::/10 dev lec0 proto kernel metric 256 mtu 1500 > > fe80::/10 via :: dev sit1 proto kernel metric 256 mtu 1480 > > ff00::/8 dev dummy0 proto kernel metric 256 mtu 1500 > > ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 > > ff00::/8 dev lec0 proto kernel metric 256 mtu 1500 > > ff00::/8 dev sit1 proto kernel metric 256 mtu 1480 > > default dev sit1 metric 1 mtu 1480 > ^^^^^^^ > > unreachable default dev lo metric -1 error -101 > > Linux kernel does not work with "default" route when > forwarding packets. > Use 2000::/3 instead. Oops forgot about that one again :) On non-forwarding hosts (or even per-interface?) it does work. Hmm in that respect it should probably give out some kind of notification as it's really something one looks over ;) Then again it doesn't quite explain his "after a few seconds it doesn't ping anymore" behaviour. Greets, Jeroen From tvo@EnterZone.Net Mon Jul 15 07:45:36 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 15 Jul 2002 02:45:36 -0400 (EDT) Subject: [6bone] Anyone at the wheel at AS237 - MERIT? Message-ID: Nearly a week ago, I sent mail to the BOTH @merit.edu addresses listed in MNT-MERIT with regards to changing our tunnel configuraion with MERIT. I have yet to receive a reply. After 5 days, I contacted the MERIT NOC via telephone and indicated to them that I needed to change our tunnel configuration with their 6bone router. I swear to [insert deity you respect here]. I was told: "I don't think we're participating in the 6bone now." "I think it got dropped like a lot of other projects at MERIT." This is not a good sign as far as I'm concerned. I hate to have to call you folks out on the 6bone list but, if you would respond to email in a timely fashion, it would not have been necessary. So: Is anyone at the wheel at AS237 - MERIT? If not, does anyone ELSE have objection to us (AS13944) announcing the aggregate 3ffe:1c00::/24 so that we can get 6bone connectivity once again? I have temporary agreements with a few peers to accept our de-aggregated 3ffe:1ced::/32 but, I don't like breaking aggregation - and WOULDN'T DO SO IF SOMEONE AT MERIT WOULD FIX OUR TUNNEL SO IT WASN'T NECESSARY TO DO SO!!! So, if you're at the wheel at MERIT, please contact me. If you know how to get in touch with someone who IS at the wheel at MERIT, please have them contact me. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From fink@es.net Mon Jul 15 08:52:33 2002 From: fink@es.net (Bob Fink) Date: Mon, 15 Jul 2002 00:52:33 -0700 Subject: [6bone] 6bone pTLA 3FFE:400E::/32 allocated to ECITY Message-ID: <5.1.0.14.0.20020715004906.03a980b0@imap2.es.net> ECITY has been allocated pTLA 3FFE:400E::/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 tvo@EnterZone.Net Mon Jul 15 14:53:19 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 15 Jul 2002 09:53:19 -0400 (EDT) Subject: [6bone] Routing loop? In-Reply-To: Message-ID: I picked a prefix at random to traceroute6 to and think I found a routing loop: traceroute to 2001:2e8::1 (2001:2e8::1) from 3ffe:31ff:0:ffff::51, 30 hops max, 16 byte packets 1 3ffe:31ff:0:ffff::50 176.882 ms 176.801 ms 177.591 ms 2 2001:288:3b0::55 312.667 ms 312.772 ms 312.656 ms 3 * 3ffe:3600::4 543.027 ms 541.667 ms 4 3ffe:81d0:ffff:2::40 576.769 ms 587.26 ms 581.632 ms 5 * * 3ffe:8070:1:13::1 688.244 ms 6 3ffe:1cff:0:f4::1 649.931 ms 655.285 ms 649.573 ms 7 2001:288:3b0::55 656.604 ms 651.207 ms 651.558 ms 8 3ffe:3600::4 883.978 ms 882.055 ms 880.693 ms 9 3ffe:81d0:ffff:2::40 884.175 ms 921.358 ms 881.235 ms 10 3ffe:8070:1:13::1 1033.52 ms 1033.26 ms 1030.68 ms 11 3ffe:1cff:0:f4::1 991.511 ms 993.754 ms 989.158 ms 12 2001:288:3b0::55 987.796 ms 992.849 ms 992.887 ms 13 * 3ffe:3600::4 1220.62 ms 1222.94 ms 14 3ffe:81d0:ffff:2::40 1226.36 ms 1211.98 ms 1257.83 ms 15 3ffe:8070:1:13::1 1386.7 ms 1380.71 ms 1363.73 ms 16 3ffe:1cff:0:f4::1 1330.9 ms 1329.47 ms 1329.02 ms 17 2001:288:3b0::55 1336.74 ms 1383.23 ms 1376.04 ms 18 3ffe:3600::4 1567.68 ms 1565.46 ms 1558.71 ms 19 3ffe:81d0:ffff:2::40 1559.76 ms 1589.07 ms 1588.92 ms 20 3ffe:8070:1:13::1 1701.98 ms 1701.99 ms 1708.76 ms 21 3ffe:1cff:0:f4::1 1672.33 ms 1670.36 ms 1684.26 ms 22 2001:288:3b0::55 1667.09 ms 1667.08 ms 1679.95 ms 23 3ffe:3600::4 1907.8 ms 1898.95 ms * 24 3ffe:81d0:ffff:2::40 1909.34 ms 1904.17 ms 1915.81 ms 25 3ffe:8070:1:13::1 2091.27 ms 2051.24 ms 2088.11 ms 26 3ffe:1cff:0:f4::1 2004.85 ms 2005.63 ms 2005.39 ms 27 2001:288:3b0::55 2007.47 ms 2014.89 ms 2005.18 ms 28 3ffe:3600::4 2237.78 ms 2239.74 ms 2237.27 ms 29 3ffe:81d0:ffff:2::40 2286.25 ms 2244.75 ms 2245.92 ms 30 3ffe:8070:1:13::1 2381.61 ms 2379.24 ms 2389.26 ms --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From lucifer@lightbearer.com Mon Jul 15 23:32:04 2002 From: lucifer@lightbearer.com (Joel Baker) Date: Mon, 15 Jul 2002 16:32:04 -0600 Subject: [6bone] Anyone at the wheel at AS237 - MERIT? In-Reply-To: ; from tvo@EnterZone.Net on Mon, Jul 15, 2002 at 02:45:36AM -0400 References: Message-ID: <20020715163204.A1699@lightbearer.com> On Mon, Jul 15, 2002 at 02:45:36AM -0400, John Fraizer wrote: > > I have temporary agreements with a few peers to accept our de-aggregated > 3ffe:1ced::/32 but, I don't like breaking aggregation - and WOULDN'T DO SO > IF SOMEONE AT MERIT WOULD FIX OUR TUNNEL SO IT WASN'T NECESSARY TO DO > SO!!! And everyone wonders why customers are against aggregation schemes which force them to single-home or lie and pretend to be an ISP... -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/ From fink@es.net Wed Jul 17 01:15:09 2002 From: fink@es.net (Bob Fink) Date: Tue, 16 Jul 2002 17:15:09 -0700 Subject: [6bone] reminder of 6bone meeting after the ngtrans meeting today Message-ID: <5.1.0.14.0.20020716171351.02bda398@imap2.es.net> 6bone Folk: This is a reminder that we have a 6bone meeting in Yokohama on Wednesday, just after the ngtrans meeting ends, in the same room. It will be the usual timing to let the room clear for 15 minutes and ending 15 minutes before the next meeting starts. Wed. 17 July 11:45am - 12:45pm same room as ngtrans is in I will talk about the discussions I've been having with the registries about conversion of the 6bone address registry to the RIRs and giving the 6bone access to the ip6.arpa reverse registry that the RIRs operate. There is no formal draft yet, just the informal ideas, but I will present all that I know as of the meeting. See you there, Bob From tvo@EnterZone.Net Sat Jul 20 00:46:08 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Fri, 19 Jul 2002 19:46:08 -0400 (EDT) Subject: [6bone] Rogue announcement from rogue ASN? Message-ID: I'm seeing the following announcement: * 2001:430::/32 3ffe:1ced:ff05::2 0 22 10566 5594 13193 109 17965 5609 4554 278 6939 2497 5994 i * 3ffe:c00:8023:4::1 0 109 3748 3786 10566 8379 8277 45328 2042 6435 6175 2497 5994 i * 3ffe:31ff:0:ffff::50 0 1930 10566 5594 13193 109 17965 5609 4554 278 6939 2497 5994 i * 3ffe:8160:0:1::c 0 6435 6175 10566 5594 13193 109 17965 5609 4554 278 6939 2497 5994 i *> 3ffe:81d0:ffff:2::44 0 6939 3748 3786 10566 8379 8277 45328 2042 6435 6175 2497 5994 i 2001:430::/32 has not been assigned: [whois.arin.net] ARIN-001 2001:0400:0000:0000:0000:0000:0000:0000/23 DISN-LES-V6 2001:0430:0000:0000:0000:0000:0000:0000/35 I am pretty sure that if this was legit, I would be seeing it only one or two ASNs into AS22. The origin AS5994 is not assigned according to ARIN: [whois.arin.net] No match for "5994". %%%%%%%%%%%%%%%%%%% NO MATCH TIP %%%%%%%%%%%%%%%%%%%%%%%%% % % % ALL OF THE POINT OF CONTACT HANDLES IN THE ARIN % % WHOIS END WITH "-ARIN", IF YOU ARE QUERYING A POINT % % OF CONTACT HANDLE PLEASE ADD -ARIN TO YOUR QUERY. % % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The upstream is: aut-num: AS2497 as-name: IIJ descr: (Unknown) country: JP as-in: (Unknown) as-out: (Unknown) admin-c: TA032JP tech-c: TA032JP remarks: This information has been partially mirrored by APNIC from remarks: JPNIC. To obtain more specific information, please use the remarks: JPNIC whois server at whois.nic.ad.jp. (This defaults to remarks: Japanese output, use the /e switch for English output) changed: apnic-ftp@nic.ad.jp 20020717 source: JPNIC So, can someone tell me why: 1) I'm seeing a prefix that is not assigned yet. 2) I'm seeing it announced from an ASN that is not assigned. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From itojun@iijlab.net Sat Jul 20 01:43:19 2002 From: itojun@iijlab.net (Jun-ichiro itojun Hagino) Date: Sat, 20 Jul 2002 09:43:19 +0900 Subject: [6bone] bogus routes remain for /35 Message-ID: <20020720004319.C677C7BA@starfruit.itojun.org> 2001:2e8::/35 have transitioned to /32 (APNIC policy change), however, it seems that there /35 routes sitting around. from my eye inspection AS10566 (viagenie) is keeping this obsolete route (only 10566 appears in all the AS paths). could you check your BGP implementation, and address the issue ASAP? itojun MFEED - http://www.v6.mfeed.ad.jp/ipv6/lg.html 65526 10566 5594 6830 8627 1752 4725 4691 3265 10566 5594 6830 8627 1752 4725 4691 4697 10566 5594 6830 8627 1752 4725 4691 IMNet - http://www.inoc.imnet.ad.jp/lg/7.2k-lg-04.html 3425 293 145 7580 10566 9264 7660 2500 4725 4691 2500 4554 6939 10566 5594 6830 8627 1752 4725 4691 LavaNet - http://www.ipv6.lava.net/cgi-bin/lg.pl 6175 7580 10566 9264 7660 2500 4725 4691 6TAP - http://www.6tap.net/6tap/6tap-lg.html 6939 10566 5594 6830 8627 1752 4725 4691 11537 22 10566 5594 6830 8627 1752 4725 4691 2200 1930 10566 5594 6830 8627 1752 4725 4691 293 145 7580 10566 9264 7660 2500 4725 4691 From dragon@tdoi.org Sat Jul 20 02:08:56 2002 From: dragon@tdoi.org (Christian Nickel) Date: Sat, 20 Jul 2002 03:08:56 +0200 Subject: [6bone] Rogue announcement from rogue ASN? References: Message-ID: <000c01c22f8a$05d4f530$fd04a80a@alpha> ----- Original Message ----- From: "John Fraizer" To: <6bone@ISI.EDU> Sent: Saturday, July 20, 2002 1:46 AM Subject: [6bone] Rogue announcement from rogue ASN? > > I'm seeing the following announcement: > > * 2001:430::/32 3ffe:1ced:ff05::2 > 0 22 10566 5594 13193 109 17965 5609 4554 278 6939 2497 5994 i > * 3ffe:c00:8023:4::1 > 0 109 3748 3786 10566 8379 8277 45328 2042 6435 6175 2497 5994 i > * 3ffe:31ff:0:ffff::50 > 0 1930 10566 5594 13193 109 17965 5609 4554 278 6939 2497 5994 i > * 3ffe:8160:0:1::c > 0 6435 6175 10566 5594 13193 109 17965 5609 4554 278 6939 2497 5994 i > *> 3ffe:81d0:ffff:2::44 > 0 6939 3748 3786 10566 8379 8277 45328 2042 6435 6175 2497 5994 i > > > 2001:430::/32 has not been assigned: > I think this sTLA changed to the new RIR policy, but whois hasn't been updated (possible upgrade to new whois database in august 2002?) > [whois.arin.net] > ARIN-001 2001:0400:0000:0000:0000:0000:0000:0000/23 > DISN-LES-V6 2001:0430:0000:0000:0000:0000:0000:0000/35 > whois -h whois.arin.net DISN-LES-V6 NRL (for SSCC) (DISN-LES-V6) One Innovation Drive, Hanahan, SC 29406-4200 US Netname: DISN-LES-V6 Netnumber: 2001:0430:0000:0000:0000:0000:0000:0000/35 Maintainer: V6NV Coordinator: Brig, Michael (MB1166-ARIN) brigm@spawar.navy.mil Domain System inverse mapping provided by: NS1.V6.LES.DISA.MIL NS2.V6.LES.DISA.MIL Record last updated on 13-Sep-2000. > I am pretty sure that if this was legit, I would be seeing it only one or two ASNs into > AS22. > > The origin AS5994 is not assigned according to ARIN: > whois -h whois.nic.mil AS5994 USN SPAWAR SYSTEM CENTER CHARLESTON (UNCLAS-DEFUN-ASN) PO 190022 NORTH CHARLESTON, SC 29419 Autonomous System Name: UNCLAS-DEFENSENET Autonomous System Number: 5994 PLA: SPAWARSYSCEN CHARLESTON SC Technical Contact: Brig, Michael P. [SSCC NGI PROGRAM MANAGER] (MPB) (843) 218-4675 (DSN) 588-4675 (FAX)(843) 218-4675 BRIGM@SPAWAR.NAVY.MIL Administrative Contact: DoD, Hostmaster (HOSTMASTER) (800) 365-3642 (FAX)(703) 676-1749 HOSTMASTER@NIC.MIL Record last updated on 15-Sep-2000. > > [whois.arin.net] > No match for "5994". > > %%%%%%%%%%%%%%%%%%% NO MATCH TIP %%%%%%%%%%%%%%%%%%%%%%%%% > % % > % ALL OF THE POINT OF CONTACT HANDLES IN THE ARIN % > % WHOIS END WITH "-ARIN", IF YOU ARE QUERYING A POINT % > % OF CONTACT HANDLE PLEASE ADD -ARIN TO YOUR QUERY. % > % % > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > The upstream is: > > aut-num: AS2497 > as-name: IIJ > descr: (Unknown) > country: JP > as-in: (Unknown) > as-out: (Unknown) > admin-c: TA032JP > tech-c: TA032JP > remarks: This information has been partially mirrored by APNIC from > remarks: JPNIC. To obtain more specific information, please use the > remarks: JPNIC whois server at whois.nic.ad.jp. (This defaults to > remarks: Japanese output, use the /e switch for English output) > changed: apnic-ftp@nic.ad.jp 20020717 > source: JPNIC > > > > So, can someone tell me why: > > 1) I'm seeing a prefix that is not assigned yet. > 2) I'm seeing it announced from an ASN that is not assigned. > > --- > John Fraizer | High-Security Datacenter Services | > EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | > http://www.enterzone.net/ | Virtual, Dedicated, Colocation | > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From tvo@EnterZone.Net Sat Jul 20 02:51:33 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Fri, 19 Jul 2002 21:51:33 -0400 (EDT) Subject: [6bone] Rogue announcement from rogue ASN? In-Reply-To: Message-ID: Um, it doesn't exist. 2001:0430:0000:0000:0000:0000:0000:0000/35 is *NOT* 2001:0430:0000:0000:0000:0000:0000:0000/32 Note that the record is a /35. As of yesterday when 2001:4f0::/35 was assigned to us, ARIN was not allocating /32's according to the email I received from them. I requested a /32 per http://www.arin.net/ipv6/templates/instr.html Here's what ARIN said: Date: Thu, 18 Jul 2002 09:34:27 -0400 (EDT) From: V6 Registration Role Account To: John.Fraizer@ENTERZONE.NET Subject: Re: [ARIN-20020717.193] IPv6 REQUEST Hello, RE: Your IPv6 address request The American Registry for Internet Numbers (ARIN) administers IP Number registration including ISP CIDR, IPv6 and IPv4 Network Numbers, Autonomous System Number (ASN), Inverse Mapping (IN-ADDR), and Reassign (SWIP) requests. A message will be mail later on today containing your allocation of a IPv6 /35. ARIN does not issue /32's at this time, however you will be eligible for an upgrade to a /32 when the new policy goes into effect. You may already be aware of the http://www.arin.net/minutes/bot/bot12142000.html URL and the ARIN Board of Trustees' action on the IPv6 registration fee item from the October, 2000 member meeting. This IPv6 approval and allocation currently carry no fees for EnterZone, Inc per the board decision presented in the document. Regards, James Sybert IPV6 Registration Services American Registry for Internet Numbers ==================================================================== email v6@arin.net voice (703) 227-0660 ==================================================================== --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On Sat, 20 Jul 2002, Daniel Hirche wrote: > And btw! > > [whois.arin.net] > ARIN-001 > 2001:0400:0000:0000:0000:0000:0000:0000/23 > DISN-LES-V6 > 2001:0430:0000:0000:0000:0000:0000:0000/35 > > It exist. > > ASn too: > > [whois.nic.mil] > USN SPAWAR SYSTEM CENTER CHARLESTON (UNCLAS-DEFUN-ASN) > PO 190022 > NORTH CHARLESTON, SC 29419 > > Autonomous System Name: UNCLAS-DEFENSENET > Autonomous System Number: 5994 > PLA: SPAWARSYSCEN CHARLESTON SC > > > regards, > --daniel > > > On Fri, 19 Jul 2002, John Fraizer wrote: > > > > > I'm seeing the following announcement: > > [...] > From tvo@EnterZone.Net Sat Jul 20 02:57:16 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Fri, 19 Jul 2002 21:57:16 -0400 (EDT) Subject: [6bone] Rogue announcement from rogue ASN? In-Reply-To: <001101c22f8b$7606c530$fd04a80a@alpha> Message-ID: USN SPAWAR SYSTEM CENTER CHARLESTON (UNCLAS-DEFUN-ASN) PO 190022 NORTH CHARLESTON, SC 29419 Autonomous System Name: UNCLAS-DEFENSENET Autonomous System Number: 5994 PLA: SPAWARSYSCEN CHARLESTON SC Technical Contact: Brig, Michael P. [SSCC NGI PROGRAM MANAGER] (MPB) (843) 218-4675 (DSN) 588-4675 (FAX)(843) 218-4675 BRIGM@SPAWAR.NAVY.MIL Administrative Contact: DoD, Hostmaster (HOSTMASTER) (800) 365-3642 (FAX)(703) 676-1749 HOSTMASTER@NIC.MIL Record last updated on 15-Sep-2000. OK. So 5994 is valid. The enquiry at ARIN did not point me to the nic.mil database. It is still strange that I see the /32 (which I still say is rogue since ARIN hasn't changed the policy yet) via such a long route since I peer with AS22 *AT* SPAWAR System Center Charleston and Michael is our contact for that peering session. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From daniel@prisec.net Sat Jul 20 03:06:29 2002 From: daniel@prisec.net (Daniel Hirche) Date: Sat, 20 Jul 2002 04:06:29 +0200 Subject: [6bone] Rogue announcement from rogue ASN? In-Reply-To: References: Message-ID: <52694841.1027137989@[172.16.2.2]> Hi, --On Friday, July 19, 2002 9:51 PM -0400 John Fraizer wrote: > > Um, it doesn't exist. > > 2001:0430:0000:0000:0000:0000:0000:0000/35 is *NOT* > 2001:0430:0000:0000:0000:0000:0000:0000/32 It is ;-) http://www.ripe.net/ipv6/press-release-20020701.html RIPE said on July 1st, ALL RIR changed their policy to /32. *wondering* regards, --daniel > > Note that the record is a /35. As of yesterday when 2001:4f0::/35 was > assigned to us, ARIN was not allocating /32's according to the email I > received from them. I requested a /32 per > http://www.arin.net/ipv6/templates/instr.html > > Here's what ARIN said: > > Date: Thu, 18 Jul 2002 09:34:27 -0400 (EDT) > From: V6 Registration Role Account > To: John.Fraizer@ENTERZONE.NET > Subject: Re: [ARIN-20020717.193] IPv6 REQUEST > > Hello, > > RE: Your IPv6 address request > > The American Registry for Internet Numbers (ARIN) administers IP > Number registration including ISP CIDR, IPv6 and IPv4 Network Numbers, > Autonomous System Number (ASN), Inverse Mapping (IN-ADDR), and > Reassign (SWIP) requests. > > A message will be mail later on today containing your allocation > of a IPv6 /35. > > ARIN does not issue /32's at this time, however you will be eligible > for an upgrade to a /32 when the new policy goes into effect. > > You may already be aware of the > http://www.arin.net/minutes/bot/bot12142000.html URL and the ARIN > Board of Trustees' action on the IPv6 registration fee item from the > October, 2000 member meeting. This IPv6 approval and allocation > currently carry no fees for EnterZone, Inc per the board > decision presented in the document. > > Regards, > > James Sybert > IPV6 Registration Services > American Registry for Internet Numbers > ==================================================================== > email v6@arin.net > voice (703) 227-0660 > ==================================================================== > [....] From tvo@EnterZone.Net Sat Jul 20 03:28:34 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Fri, 19 Jul 2002 22:28:34 -0400 (EDT) Subject: [6bone] Rogue announcement from rogue ASN? In-Reply-To: <52694841.1027137989@[172.16.2.2]> Message-ID: On Sat, 20 Jul 2002, Daniel Hirche wrote: > Hi, > > --On Friday, July 19, 2002 9:51 PM -0400 John Fraizer > wrote: > > > > > Um, it doesn't exist. > > > > 2001:0430:0000:0000:0000:0000:0000:0000/35 is *NOT* > > 2001:0430:0000:0000:0000:0000:0000:0000/32 > > It is ;-) OK. Well, I put those in the wrong order. 2001:0430:0000:0000:0000:0000:0000:0000/32 is *NOT* 2001:0430:0000:0000:0000:0000:0000:0000/35 2001:0430::/32 only includes: 2001:0430:0000:0000:0000:0000:0000:0000 - 2001:0430:1FFF:FFFF:FFFF:FFFF:FFFF:FFFF > > http://www.ripe.net/ipv6/press-release-20020701.html > > RIPE said on July 1st, ALL RIR changed their policy to /32. > > *wondering* > > regards, > --daniel So, I should be announcing 2001:4f0::/32 even though the ARIN database says 2001:4f0::/35? --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From daniel@prisec.net Sat Jul 20 03:39:54 2002 From: daniel@prisec.net (Daniel Hirche) Date: Sat, 20 Jul 2002 04:39:54 +0200 Subject: [6bone] Rogue announcement from rogue ASN? In-Reply-To: References: Message-ID: <54699954.1027139994@[172.16.2.2]> Hi, --On Friday, July 19, 2002 10:28 PM -0400 John Fraizer wrote: > [...] > 2001:0430:0000:0000:0000:0000:0000:0000/32 is *NOT* > 2001:0430:0000:0000:0000:0000:0000:0000/35 > > 2001:0430::/32 only includes: > 2001:0430:0000:0000:0000:0000:0000:0000 - > 2001:0430:1FFF:FFFF:FFFF:FFFF:FFFF:FFFF 2001:0430::/32 includes 2001:0430::/35 > [...] >> http://www.ripe.net/ipv6/press-release-20020701.html >> >> RIPE said on July 1st, ALL RIR changed their policy to /32. >> >> *wondering* > [...] > > So, I should be announcing 2001:4f0::/32 even though the ARIN database > says 2001:4f0::/35? No, you should not, because it's 4:30am here and I went wrong. ARIN did not change their policy, only RIPE and APNIC did. Sorry for that confusion. Due to this, DISN-LES-V6 should not aggregate both /32 and /35 until ARIN did not change their policy. regards, --daniel From tvo@EnterZone.Net Sat Jul 20 04:11:47 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Fri, 19 Jul 2002 23:11:47 -0400 (EDT) Subject: [6bone] Rogue announcement from rogue ASN? In-Reply-To: <54699954.1027139994@[172.16.2.2]> Message-ID: On Sat, 20 Jul 2002, Daniel Hirche wrote: > Hi, > > --On Friday, July 19, 2002 10:28 PM -0400 John Fraizer > wrote: > > > [...] > > 2001:0430:0000:0000:0000:0000:0000:0000/32 is *NOT* > > 2001:0430:0000:0000:0000:0000:0000:0000/35 > > > > 2001:0430::/32 only includes: > > 2001:0430:0000:0000:0000:0000:0000:0000 - > > 2001:0430:1FFF:FFFF:FFFF:FFFF:FFFF:FFFF > > 2001:0430::/32 includes 2001:0430::/35 > Doh! That should have said "2001:0430::/35 only includes:" > ARIN did not change their policy, only RIPE and APNIC did. Sorry for that > confusion. > > Due to this, DISN-LES-V6 should not aggregate both /32 and /35 until ARIN > did not change their policy. > > regards, > --daniel Anyone know when ARIN is going to follow suit with the rest of the world? --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From raphit@noemie.org Sat Jul 20 09:08:52 2002 From: raphit@noemie.org (Raphael Bouaziz) Date: Sat, 20 Jul 2002 10:08:52 +0200 Subject: [6bone] Rogue announcement from rogue ASN? In-Reply-To: ; from tvo@EnterZone.Net on Fri, Jul 19, 2002 at 07:46:08PM -0400 References: Message-ID: <20020720100852.A62257@noemie.org> On Fri, Jul 19, 2002, John Fraizer wrote: > I'm seeing the following announcement: > > * 2001:430::/32 3ffe:1ced:ff05::2 > 0 22 10566 5594 13193 109 17965 5609 4554 278 6939 2497 5994 i > * 3ffe:c00:8023:4::1 > 0 109 3748 3786 10566 8379 8277 45328 2042 6435 6175 2497 5994 i ^^^^^ AS5994 is OK, but I don't think that AS45328 is really assigned... -- Raphael Bouaziz. raphit@noemie.org - http://noemie.nerim.net/ Sysadmin Power Forever(TM). From b6354@ms25.hinet.net Sat Jul 20 13:57:35 2002 From: b6354@ms25.hinet.net (chad) Date: Sat, 20 Jul 2002 20:57:35 +0800 Subject: [6bone] (no subject) Message-ID: <002901c22fed$059487d0$280aa8c0@ren> This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C23030.13483D20 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0026_01C23030.13483D20 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0026_01C23030.13483D20-- From bmanning@ISI.EDU Sat Jul 20 14:23:31 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Sat, 20 Jul 2002 06:23:31 -0700 (PDT) Subject: [6bone] Rogue announcement from rogue ASN? In-Reply-To: from John Fraizer at "Jul 19, 2 11:11:47 pm" Message-ID: <200207201323.g6KDNVr27147@boreas.isi.edu> % On Sat, 20 Jul 2002, Daniel Hirche wrote: % % > Hi, % > % > --On Friday, July 19, 2002 10:28 PM -0400 John Fraizer % > wrote: % > % > > [...] % > > 2001:0430:0000:0000:0000:0000:0000:0000/32 is *NOT* % > > 2001:0430:0000:0000:0000:0000:0000:0000/35 % > > % > > 2001:0430::/32 only includes: % > > 2001:0430:0000:0000:0000:0000:0000:0000 - % > > 2001:0430:1FFF:FFFF:FFFF:FFFF:FFFF:FFFF % > % > 2001:0430::/32 includes 2001:0430::/35 % > % % Doh! That should have said "2001:0430::/35 only includes:" % % > ARIN did not change their policy, only RIPE and APNIC did. Sorry for that % > confusion. % > % > Due to this, DISN-LES-V6 should not aggregate both /32 and /35 until ARIN % > did not change their policy. % > % > regards, % > --daniel % % % Anyone know when ARIN is going to follow suit with the rest of the world? % % % % --- % John Fraizer | High-Security Datacenter Services | % EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | % http://www.enterzone.net/ | Virtual, Dedicated, Colocation | I beleive that you might see a change soon. -- --bill From bmanning@ISI.EDU Sun Jul 21 17:16:40 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Sun, 21 Jul 2002 09:16:40 -0700 (PDT) Subject: [6bone] 2001:478:: as /48 Message-ID: <200207211616.g6LGGe508924@boreas.isi.edu> this prefix has/is being carved up into /48 and /64 subnets for use at exchange points and other infrastructure support services. Do not expect to see it aggregated. -- bill manning From michel@arneill-py.sacramento.ca.us Sun Jul 21 19:35:47 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 21 Jul 2002 11:35:47 -0700 Subject: [6bone] 2001:478:: as /48 Message-ID: <2B81403386729140A3A899A8B39B046405E1F8@server2000.arneill-py.sacramento.ca.us> Bill, I don't see it as unaggregated and I believe I'm not the only one. I dropped my ipv6 prefix-lists and I have a BGP4+ feed from three different pTLAs. Is there any document you can point us to that specifies that it should be unaggregated? It is possible that a very small portion of the 6bone will actually see a /48, as my understanding is a number of us do indeed use something more or less than: ipv6 prefix-list strict seq 5 permit 3ffe::/17 ge 24 le 24 ipv6 prefix-list strict seq 10 permit 3ffe:8000::/17 ge 28 le 28 ipv6 prefix-list strict seq 15 permit 3ffe:4000::/18 ge 32 le 32 ipv6 prefix-list strict seq 20 permit 2000::/3 ge 16 le 16 ipv6 prefix-list strict seq 25 permit 2001::/16 ge 29 le 35 ipv6 prefix-list strict seq 30 deny 2000::/3 [prefix-list stolen from Pim Van Pelt] Michel. -----Original Message----- From: Bill Manning [mailto:bmanning@ISI.EDU] Sent: Sunday, July 21, 2002 9:17 AM To: 6bone@ISI.EDU Cc: Bill Manning Subject: [6bone] 2001:478:: as /48 this prefix has/is being carved up into /48 and /64 subnets for use at exchange points and other infrastructure support services. Do not expect to see it aggregated. -- bill manning _______________________________________________ 6bone mailing list 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone From tvo@ENTERZONE.NET Sun Jul 21 20:15:51 2002 From: tvo@ENTERZONE.NET (John Fraizer) Date: Sun, 21 Jul 2002 15:15:51 -0400 (EDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: <200207211616.g6LGGe508924@boreas.isi.edu> Message-ID: On Sun, 21 Jul 2002, Bill Manning wrote: > > > this prefix has/is being carved up into /48 and /64 subnets for > use at exchange points and other infrastructure support services. > > Do not expect to see it aggregated. > > -- bill manning > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > So, something on the order of: ipv6 prefix-list agregates seq 10 permit 2001:478::/35 le 64 ...should work to accept these prefixes, right? --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From pim@ipng.nl Sun Jul 21 20:18:33 2002 From: pim@ipng.nl (Pim van Pelt) Date: Sun, 21 Jul 2002 21:18:33 +0200 Subject: [6bone] 2001:478:: as /48 In-Reply-To: <2B81403386729140A3A899A8B39B046405E1F8@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E1F8@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020721191833.GC28689@bfib.colo.bit.nl> Hoi, The below prefix-list used to be used by me (and possibly others) only on outgoing announcements. However, with all sorts of individuals deliberately breaking the strict aggregation model by announcing and transitting /48s, I sometimes saw traffic to one of my peers' customers networks travel wicked paths, because they do send me aggregated routes (thus filtering the /48) but their customers peer with other people as well creating a more specific in my routing tables via operators who do not use egress filtering. This is why I have adapted the strict filtering in egress as well as ingress these days. By the way, looking at the 'strict' prefix list below, I would like to bring it to the general attention that '3ffe::/17' does no longer exist, since we started to use the /32 prefixes in 3ffe:4000::/18, thus chopping the lower half of the /16 in half. For 6bone, it is now: 3ffe::/18 ge 24 le 24 3ffe:4000::/18 ge 32 le 32 3ffe:8000::/17 ge 28 le 28 >From other places, I hear that having /48 or even /64 in the route table could be 'acceptable'. One might argue that an operator with a large router box with much memory can opt to have a 'full view' with all the more specifics, and an operator with a smaller box can opt to have a 'strict full view' with only aggregated prefixes. Nobody will lose connectivity in the latter case, if and only if we keep on having at least a route to the more specific in the aggregating AS. For me, I'll stick to BOFH mode (ie, strict filtering) until we have a best common practice. On Sun, Jul 21, 2002 at 11:35:47AM -0700, Michel Py wrote: | Bill, | | I don't see it as unaggregated and I believe I'm not the only one. I | dropped my ipv6 prefix-lists and I have a BGP4+ feed from three | different pTLAs. | | Is there any document you can point us to that specifies that it should | be unaggregated? It is possible that a very small portion of the 6bone | will actually see a /48, as my understanding is a number of us do indeed | use something more or less than: | | ipv6 prefix-list strict seq 5 permit 3ffe::/17 ge 24 le 24 | ipv6 prefix-list strict seq 10 permit 3ffe:8000::/17 ge 28 le 28 | ipv6 prefix-list strict seq 15 permit 3ffe:4000::/18 ge 32 le 32 | ipv6 prefix-list strict seq 20 permit 2000::/3 ge 16 le 16 | ipv6 prefix-list strict seq 25 permit 2001::/16 ge 29 le 35 | ipv6 prefix-list strict seq 30 deny 2000::/3 | | [prefix-list stolen from Pim Van Pelt] | | Michel. | | | -----Original Message----- | From: Bill Manning [mailto:bmanning@ISI.EDU] | Sent: Sunday, July 21, 2002 9:17 AM | To: 6bone@ISI.EDU | Cc: Bill Manning | Subject: [6bone] 2001:478:: as /48 | | | | this prefix has/is being carved up into /48 and /64 subnets for | use at exchange points and other infrastructure support services. | | Do not expect to see it aggregated. | | -- bill manning | _______________________________________________ | 6bone mailing list | 6bone@mailman.isi.edu | http://mailman.isi.edu/mailman/listinfo/6bone | _______________________________________________ | 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 tvo@ENTERZONE.NET Sun Jul 21 20:25:21 2002 From: tvo@ENTERZONE.NET (John Fraizer) Date: Sun, 21 Jul 2002 15:25:21 -0400 (EDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: <2B81403386729140A3A899A8B39B046405E1F8@server2000.arneill-py.sacramento.ca.us> Message-ID: On Sun, 21 Jul 2002, Michel Py wrote: > Bill, > > I don't see it as unaggregated and I believe I'm not the only one. I > dropped my ipv6 prefix-lists and I have a BGP4+ feed from three > different pTLAs. > > Is there any document you can point us to that specifies that it should > be unaggregated? It is possible that a very small portion of the 6bone > will actually see a /48, as my understanding is a number of us do indeed > use something more or less than: > > ipv6 prefix-list strict seq 5 permit 3ffe::/17 ge 24 le 24 > ipv6 prefix-list strict seq 10 permit 3ffe:8000::/17 ge 28 le 28 > ipv6 prefix-list strict seq 15 permit 3ffe:4000::/18 ge 32 le 32 > ipv6 prefix-list strict seq 20 permit 2000::/3 ge 16 le 16 > ipv6 prefix-list strict seq 25 permit 2001::/16 ge 29 le 35 > ipv6 prefix-list strict seq 30 deny 2000::/3 > > [prefix-list stolen from Pim Van Pelt] > > Michel. Michel, Bill was just notifying us that we SHOULD accept the prefixes as un-aggregated, not that they were in the wild yet, unaggregated. The reason you may not be seeing them (at least from us) as unaggregated is that I have yet to open up our filters to them until I get verification from Bill that my filter is right. I don't wanna leak the wrong thing. As for documentation, I generally take Bill at his word when it comes to things like this. Bill, if you will, please add CMH-IX (http://www.cmh-ix.net/) to the list of IPv6 exchanges at www.ep.net. The CMH-IX site itself will be updated to reflect this service sometime this weekend. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From tvo@EnterZone.Net Sun Jul 21 20:28:37 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Sun, 21 Jul 2002 15:28:37 -0400 (EDT) Subject: [6bone] ATTENTION akurathi_ravi@magicaldesk.com!!! Message-ID: Will akurathi_ravi@magicaldesk.com please do one or more of these things: (1)Have your mailserver stop sending these messages. (2)Beg your admin for a larger quota. (3)Purge your existing mailbox so you have room for new mail. I'm tired of receiving the following every time I post to the list: --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | Dear Sir/Madam Your message cannot be delivered to the recipient, akurathi_ravi@magicaldesk.com, because his/her mail box storage limit has exceeded. The summary of your previous message: From: John Fraizer To: Bill Manning Cc: 6bone@ISI.EDU Sent Date: Mon Jul 22 03:15:51 CST 2002 Subject: Re: [6bone] 2001:478:: as /48 Body: ***************** From dragon@tdoi.org Sun Jul 21 21:13:07 2002 From: dragon@tdoi.org (Christian Nickel) Date: Sun, 21 Jul 2002 22:13:07 +0200 Subject: [6bone] 2001:478:: as /48 References: <2B81403386729140A3A899A8B39B046405E1F8@server2000.arneill-py.sacramento.ca.us> <20020721191833.GC28689@bfib.colo.bit.nl> Message-ID: <003901c230f3$077bb850$fd04a80a@alpha> ----- Original Message ----- From: "Pim van Pelt" To: "Michel Py" Cc: "Bill Manning" ; <6bone@ISI.EDU> Sent: Sunday, July 21, 2002 9:18 PM Subject: Re: [6bone] 2001:478:: as /48 > Hoi, > > The below prefix-list used to be used by me (and possibly others) only on > outgoing announcements. However, with all sorts of individuals > deliberately breaking the strict aggregation model by announcing and > transitting /48s, I sometimes saw traffic to one of my peers' customers > networks travel wicked paths, because they do send me aggregated routes > (thus filtering the /48) but their customers peer with other people as > well creating a more specific in my routing tables via operators who do > not use egress filtering. > > This is why I have adapted the strict filtering in egress as well as > ingress these days. > > By the way, looking at the 'strict' prefix list below, I would like to > bring it to the general attention that '3ffe::/17' does no longer exist, > since we started to use the /32 prefixes in 3ffe:4000::/18, thus > chopping the lower half of the /16 in half. For 6bone, it is now: > > 3ffe::/18 ge 24 le 24 > 3ffe:4000::/18 ge 32 le 32 > 3ffe:8000::/17 ge 28 le 28 correct is: 3ffe::/18 ge 24 le 24 for 3FFE:0000::/24 thru 3FFE:3F00::/24 3ffe:4000::/20 ge 32 le 32 3FFE:4000::/32 thru 3FFE:7FFF::/32 3ffe:8000::/18 ge 28 le 28 3FFE:8000::/28 thru 3FFE:83F0::/28 3FFE:8400::/32 thru 3FFE:FFFF::/32 is for future use > > >From other places, I hear that having /48 or even /64 in the route table > could be 'acceptable'. One might argue that an operator with a large > router box with much memory can opt to have a 'full view' with all the > more specifics, and an operator with a smaller box can opt to have a > 'strict full view' with only aggregated prefixes. > > Nobody will lose connectivity in the latter case, if and only if we keep > on having at least a route to the more specific in the aggregating AS. > For me, I'll stick to BOFH mode (ie, strict filtering) until we have a > best common practice. > > On Sun, Jul 21, 2002 at 11:35:47AM -0700, Michel Py wrote: > | Bill, > | > | I don't see it as unaggregated and I believe I'm not the only one. I > | dropped my ipv6 prefix-lists and I have a BGP4+ feed from three > | different pTLAs. > | > | Is there any document you can point us to that specifies that it should > | be unaggregated? It is possible that a very small portion of the 6bone > | will actually see a /48, as my understanding is a number of us do indeed > | use something more or less than: > | > | ipv6 prefix-list strict seq 5 permit 3ffe::/17 ge 24 le 24 > | ipv6 prefix-list strict seq 10 permit 3ffe:8000::/17 ge 28 le 28 > | ipv6 prefix-list strict seq 15 permit 3ffe:4000::/18 ge 32 le 32 > | ipv6 prefix-list strict seq 20 permit 2000::/3 ge 16 le 16 > | ipv6 prefix-list strict seq 25 permit 2001::/16 ge 29 le 35 > | ipv6 prefix-list strict seq 30 deny 2000::/3 > | > | [prefix-list stolen from Pim Van Pelt] > | > | Michel. > | > | > | -----Original Message----- > | From: Bill Manning [mailto:bmanning@ISI.EDU] > | Sent: Sunday, July 21, 2002 9:17 AM > | To: 6bone@ISI.EDU > | Cc: Bill Manning > | Subject: [6bone] 2001:478:: as /48 > | > | > | > | this prefix has/is being carved up into /48 and /64 subnets for > | use at exchange points and other infrastructure support services. > | > | Do not expect to see it aggregated. > | > | -- bill manning > | _______________________________________________ > | 6bone mailing list > | 6bone@mailman.isi.edu > | http://mailman.isi.edu/mailman/listinfo/6bone > | _______________________________________________ > | 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 > ----------------------------------------------- > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > > From Robert.Kiessling@de.easynet.net Sun Jul 21 21:35:32 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 21 Jul 2002 21:35:32 +0100 Subject: [6bone] 2001:478:: as /48 In-Reply-To: References: Message-ID: John Fraizer writes: > Bill was just notifying us that we SHOULD accept the prefixes as > un-aggregated, not that they were in the wild yet, unaggregated. No, he did not. He said we cannot expect to see an aggregate, but that does *not* mean that we should accept /48's and /64's. At least in RIPE region those prefixes are given out with the explicit warning that they might not be routable. And in fact, for the specific purposes like exchange point meshes, they don't need to be announced at all. Please don't try to create "PI" space by suggesting that those prefixes should be accepted. Robert From Robert.Kiessling@de.easynet.net Sun Jul 21 21:39:34 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 21 Jul 2002 21:39:34 +0100 Subject: [6bone] MRTD BGP withdrawal bug Message-ID: Hello, from observations of BGP tables, I came to the conclusion that MRTD has a bug processing withdrawals of routing announcements. It looks like this bug leads to the well-known phantom prefixes with huge AS paths, coming together with routing loops. I haven't yet tried to reproduce it. Has anyone already taken a deeper look into it? Robert From dragon@tdoi.org Sun Jul 21 21:35:17 2002 From: dragon@tdoi.org (Christian Nickel) Date: Sun, 21 Jul 2002 22:35:17 +0200 Subject: [6bone] 2001:478:: as /48 References: <2B81403386729140A3A899A8B39B046405E1F8@server2000.arneill-py.sacramento.ca.us> <20020721191833.GC28689@bfib.colo.bit.nl> Message-ID: <001301c230f6$2014b030$fd04a80a@alpha> hm something is wrong >correct is: > >3ffe::/18 ge 24 le 24 >for 3FFE:0000::/24 thru 3FFE:3F00::/24 > >3ffe:4000::/20 ge 32 le 32 3ffe:4000::/18 ge 32 le 32 >3FFE:4000::/32 thru 3FFE:7FFF::/32 > >3ffe:8000::/18 ge 28 le 28 3ffe:8000::/20 ge 28 le 28 >3FFE:8000::/28 thru 3FFE:83F0::/28 > > >3FFE:8400::/32 thru 3FFE:FFFF::/32 is for future use From dragon@tdoi.org Sun Jul 21 21:47:27 2002 From: dragon@tdoi.org (Christian Nickel) Date: Sun, 21 Jul 2002 22:47:27 +0200 Subject: [6bone] 2001:478:: as /48 Message-ID: <002c01c230f7$d35d7d10$fd04a80a@alpha> i promise this was the last mail today ;) i should go to bed, too many errors in my mails sorry ----- Original Message ----- From: "Christian Nickel" To: "Pim van Pelt" Cc: <6bone@ISI.EDU> Sent: Sunday, July 21, 2002 10:35 PM Subject: Re: [6bone] 2001:478:: as /48 > hm something is wrong > > >correct is: > > > >3ffe::/18 ge 24 le 24 > >for 3FFE:0000::/24 thru 3FFE:3F00::/24 > > > >3ffe:4000::/20 ge 32 le 32 > > 3ffe:4000::/18 ge 32 le 32 > > >3FFE:4000::/32 thru 3FFE:7FFF::/32 > > > >3ffe:8000::/18 ge 28 le 28 > > 3ffe:8000::/20 ge 28 le 28 3ffe:8000::/22 ge 28 le 28 > > >3FFE:8000::/28 thru 3FFE:83F0::/28 > > > > > >3FFE:8400::/32 thru 3FFE:FFFF::/32 is for future use > > From bmanning@ISI.EDU Sun Jul 21 23:12:35 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Sun, 21 Jul 2002 15:12:35 -0700 (PDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: from John Fraizer at "Jul 21, 2 03:25:21 pm" Message-ID: <200207212212.g6LMCZh27191@boreas.isi.edu> % Michel, % % Bill was just notifying us that we SHOULD accept the prefixes as % un-aggregated, not that they were in the wild yet, unaggregated. The % reason you may not be seeing them (at least from us) as unaggregated is % that I have yet to open up our filters to them until I get verification % from Bill that my filter is right. I don't wanna leak the wrong thing. As % for documentation, I generally take Bill at his word when it comes to % things like this. 2001:478:x://48 are being used at a number of exchanges now and more are expected to follow. Some are being used for other infrastructure purposes, for which you may wish a route to. So the notice was more to point out that you should -NOT- accept aggregates in the range 2001:478::/35 (soon to be /32, as soon as ARIN adopts polciy changes). Its up to individual ISPs as to which prefixes they listen to and (the subset) of the listened to prefixes to announce. W.R.T. "PI" space, this qualifies just as much as the various RIR's ear-marked space for exchanges & infrastructure. The point is that if you see things in these ranges at all, they will likely be /48 or /64 entries. And there will be reasons to listen... :) % Bill, if you will, please add CMH-IX (http://www.cmh-ix.net/) to the list % of IPv6 exchanges at www.ep.net. The CMH-IX site itself will be updated % to reflect this service sometime this weekend. I've punted the request to Jeff. % % --- % John Fraizer | High-Security Datacenter Services | % EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | % http://www.enterzone.net/ | Virtual, Dedicated, Colocation | % % -- --bill From bmanning@ISI.EDU Sun Jul 21 23:14:58 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Sun, 21 Jul 2002 15:14:58 -0700 (PDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: <2B81403386729140A3A899A8B39B046405E1F8@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Jul 21, 2 11:35:47 am" Message-ID: <200207212214.g6LMEw327627@boreas.isi.edu> % Bill, % % I don't see it as unaggregated and I believe I'm not the only one. I % dropped my ipv6 prefix-lists and I have a BGP4+ feed from three % different pTLAs. Whom is aggregating this prefix? % Is there any document you can point us to that specifies that it should % be unaggregated? The original delegation request to ARIN specified that this range was being used for exchanges and infrastructure purposes. Exactly like the 198.32.0.0/16 space in v4 space. And the 3ffe:0: space in the 6bone. % Michel. % % % -----Original Message----- % From: Bill Manning [mailto:bmanning@ISI.EDU] % Sent: Sunday, July 21, 2002 9:17 AM % To: 6bone@ISI.EDU % Cc: Bill Manning % Subject: [6bone] 2001:478:: as /48 % % % % this prefix has/is being carved up into /48 and /64 subnets for % use at exchange points and other infrastructure support services. % % Do not expect to see it aggregated. % % -- bill manning % _______________________________________________ % 6bone mailing list % 6bone@mailman.isi.edu % http://mailman.isi.edu/mailman/listinfo/6bone % -- --bill From bmanning@ISI.EDU Sun Jul 21 23:15:46 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Sun, 21 Jul 2002 15:15:46 -0700 (PDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: from John Fraizer at "Jul 21, 2 03:15:51 pm" Message-ID: <200207212215.g6LMFkt27860@boreas.isi.edu> % % So, something on the order of: % % ipv6 prefix-list agregates seq 10 permit 2001:478::/35 le 64 % % ...should work to accept these prefixes, right? % This should be a /32 within a month. -- --bill From tvo@ENTERZONE.NET Mon Jul 22 01:09:56 2002 From: tvo@ENTERZONE.NET (John Fraizer) Date: Sun, 21 Jul 2002 20:09:56 -0400 (EDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: Message-ID: On 21 Jul 2002, Robert Kiessling wrote: > John Fraizer writes: > > > Bill was just notifying us that we SHOULD accept the prefixes as > > un-aggregated, not that they were in the wild yet, unaggregated. > > No, he did not. He said we cannot expect to see an aggregate, but that > does *not* mean that we should accept /48's and /64's. > > At least in RIPE region those prefixes are given out with the explicit > warning that they might not be routable. And in fact, for the specific > purposes like exchange point meshes, they don't need to be announced > at all. > > Please don't try to create "PI" space by suggesting that those > prefixes should be accepted. > > Robert > OK. This brings about the same implications as in IPv4 space. If you want traceroutes through exchange [x] to work without having at least ONE hop that has "* * *" for a return, you will accept the prefix and route it to *TRANSIT CUSTOMERS*. Perhaps you didn't read that into it. I did. I agree that unless you participate in exchange {x}, it is not important for you to accept these routes or send them to your customers. I seriously don't see the big deal with accepting de-aggregated space from EP.NET, a WELL ESTABLISHED EXCHANGE-POINT IP SPACE MAINTAINER. What I don't understand is why folks are leaking /48's /64's and for that matter, even /127's into the global IPv6 routing table. People: We're the TESTBED *AND (some of us)* the *PRODUCTION* IPv6 backbone. Set the example. Don't accept garbage from your downstreams and if you MUST do so, at minumum, don't send it to your other peers. I know that this must look hypocrytical of me since I begged everyone to accept 3ffe:1ced:32 deaggregates from 3ffe:1c00/24. I only requested so (and still do) because MERIT had not, and still had NOT responded to my requests to update our tunnel configuration. Without the tunnel in place to MERIT, our downstream (6bone addressed) customers (6bone addressed folks are NOT billed just so noone starts a war here) are dead unless other pTLA's accept 3ffe:1ced::/32 deaggregated from 3ffe:1c00::/24. I volunteer to fix this. I submit that if in the next week, MERIT does not respond to my multiple requests for action on their part, we all accept what I have been informed of (by persons who requested to remain anonymous for political reasons) being MERIT has abandoned their 6bone project. In such event, EnterZone volunteers to take over the 3ffe:1c00::/24 space and will move all downstream tunnels to our routers. At the same time, I call one EVERY OTHER participant in the 6bone to take a look at what prefixes you are originating. If it's not aggregated, and you don't have extenuating circumstances, as noted above, I suggest that you AGGREGATE NOW! Otherwise, you'll be listed in my weekly "These folks are not aggregating, lets beat them about the head and shoulders until they do" list that I'm goint to start posting to the list. We have a chance with IPv6 to set the standard BEFORE things get out of hand. Let us take advantage of it! --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From tvo@ENTERZONE.NET Mon Jul 22 01:12:04 2002 From: tvo@ENTERZONE.NET (John Fraizer) Date: Sun, 21 Jul 2002 20:12:04 -0400 (EDT) Subject: [6bone] MRTD BGP withdrawal bug In-Reply-To: Message-ID: People are *STILL* running MRTd? Hasn't it been undeveloped and abandoned by the original developers for SEVERAL *YEARS*? On 21 Jul 2002, Robert Kiessling wrote: > Hello, > > from observations of BGP tables, I came to the conclusion that MRTD > has a bug processing withdrawals of routing announcements. It looks > like this bug leads to the well-known phantom prefixes with huge AS > paths, coming together with routing loops. > > I haven't yet tried to reproduce it. > > Has anyone already taken a deeper look into it? > > Robert > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From koji@iijmio-mail.jp Mon Jul 22 02:11:58 2002 From: koji@iijmio-mail.jp (Koji Kondo) Date: Mon, 22 Jul 2002 10:11:58 +0900 (JST) Subject: [6bone] bogus routes remain for /35 In-Reply-To: <20020720004319.C677C7BA@starfruit.itojun.org> References: <20020720004319.C677C7BA@starfruit.itojun.org> Message-ID: <20020722.101158.60050076.koji@iijmio-mail.jp> AS4691 is not announcing the route of 2001:2e8::/35, but I can see this route from looking glass. http://www.v6.mfeed.ad.jp/ipv6/lg.html BGP routing table entry for 2001:2E8::/35, version 33588 Paths: (4 available, best #3) Advertised to non peer-group peers: 2001:3A0::1001 2001:3A0::2001 2001:3A0::2002 2001:3A0::2003 2001:3A0::3001 65526 10566 6939 15589 1275 5609 20745 20745 20745 20745 20745 20745 20745 109 5550 9112 13110 3320 680 5539 8627 6830 559 8758 9044 3FFE:81F1:1:2016::1 from 3FFE:81F1:1:2016::1 (213.91.4.3) Origin IGP, localpref 10, valid, external Community: no-export 65526 10566 6939 15589 1275 5609 20745 20745 20745 20745 20745 20745 20745 109 5550 9112 13110 3320 680 5539 8627 6830 559 8758 9044, (received-only) 3FFE:81F1:1:2016::1 from 3FFE:81F1:1:2016::1 (213.91.4.3) Origin IGP, localpref 100, valid, external Community: no-export 3265 10566 6939 15589 1275 5609 20745 20745 20745 20745 20745 20745 20745 109 5550 9112 13110 3320 680 5539 8627 6830 559 8758 9044, (received & used) 3FFE:8280:0:2000::6 from 3FFE:8280:0:2000::6 (194.109.5.254) Origin IGP, localpref 100, valid, external, best 4697 10566 6939 15589 1275 5609 20745 20745 20745 20745 20745 20745 20745 109 5550 9112 13110 3320 680 5539 8627 6830 559 8758 9044, (received & used) 3FFE:1801:0:1::3:179 from 3FFE:1801:0:1::3:179 (216.69.94.69) Origin IGP, localpref 100, valid, external -- koji From tvo@EnterZone.Net Mon Jul 22 03:00:58 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Sun, 21 Jul 2002 22:00:58 -0400 (EDT) Subject: [6bone] bogus routes remain for /35 In-Reply-To: <20020722.101158.60050076.koji@iijmio-mail.jp> Message-ID: On Mon, 22 Jul 2002, Koji Kondo wrote: > AS4691 is not announcing the route of 2001:2e8::/35, > but I can see this route from looking glass. > And your point is? You provide no documentation to who SHOULD be announcing the prefix. Help us out here. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From Robert.Kiessling@de.easynet.net Mon Jul 22 03:14:33 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 22 Jul 2002 03:14:33 +0100 Subject: [6bone] 2001:478:: as /48 In-Reply-To: References: Message-ID: John Fraizer writes: > OK. This brings about the same implications as in IPv4 space. If you > want traceroutes through exchange [x] to work without having at least ONE > hop that has "* * *" for a return, you will accept the prefix and route it > to *TRANSIT CUSTOMERS*. No, this is wrong. I don't know where this myth comes from. All you need to accept packets from that address space, but there's no need at all to be able to route *to* it, to avoid holes in traceroutes. Thus you don't need to accept any BGP routes from that block. Robert From Robert.Kiessling@de.easynet.net Mon Jul 22 03:18:48 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 22 Jul 2002 03:18:48 +0100 Subject: [6bone] bogus routes remain for /35 In-Reply-To: <20020722.101158.60050076.koji@iijmio-mail.jp> References: <20020720004319.C677C7BA@starfruit.itojun.org> <20020722.101158.60050076.koji@iijmio-mail.jp> Message-ID: Koji Kondo writes: > AS4691 is not announcing the route of 2001:2e8::/35, > but I can see this route from looking glass. See my message about MRTD. A bug in it is most likely the cause of this announcement. Robert > BGP routing table entry for 2001:2E8::/35, version 33588 > Paths: (4 available, best #3) > Advertised to non peer-group peers: > 2001:3A0::1001 2001:3A0::2001 2001:3A0::2002 2001:3A0::2003 2001:3A0::3001 > 65526 10566 6939 15589 1275 5609 20745 20745 20745 20745 20745 20745 20745 109 5550 9112 13110 3320 680 5539 8627 6830 559 8758 9044 > 3FFE:81F1:1:2016::1 from 3FFE:81F1:1:2016::1 (213.91.4.3) > Origin IGP, localpref 10, valid, external > Community: no-export From tvo@EnterZone.Net Mon Jul 22 03:33:06 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Sun, 21 Jul 2002 22:33:06 -0400 (EDT) Subject: [6bone] MRTD BGP withdrawal bug In-Reply-To: Message-ID: With exception to the NANOG list, which I have *NO DOUBT* would survive in the absence of MERIT, I've come to expect nothing less than failure from *ANYTNING* that had any root with MERIT. If you're still using MRTd, may I suggest that you upgrade to something that is at least maintained like perhaps: http://www.zebra.org/ There is even a commercial version and it doesn't even require that you donate your first and second born like the GateD code (also of MERIT fame) does. I'm *so* glad that I'm not from, and don't pay taxed to, Michigan. Otherwise, I would feel obligated to actually get *SOMETHING* for my money beyond funding some grad student's stipen. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On Sun, 21 Jul 2002, John Fraizer wrote: > > People are *STILL* running MRTd? Hasn't it been undeveloped and abandoned > by the original developers for SEVERAL *YEARS*? > > On 21 Jul 2002, Robert Kiessling wrote: > > > Hello, > > > > from observations of BGP tables, I came to the conclusion that MRTD > > has a bug processing withdrawals of routing announcements. It looks > > like this bug leads to the well-known phantom prefixes with huge AS > > paths, coming together with routing loops. > > > > I haven't yet tried to reproduce it. > > > > Has anyone already taken a deeper look into it? > > > > Robert > > > > _______________________________________________ > > 6bone mailing list > > 6bone@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/6bone > > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From koji@iijmio-mail.jp Mon Jul 22 04:12:37 2002 From: koji@iijmio-mail.jp (Koji Kondo) Date: Mon, 22 Jul 2002 12:12:37 +0900 (JST) Subject: [6bone] bogus routes remain for /35 In-Reply-To: References: <20020722.101158.60050076.koji@iijmio-mail.jp> Message-ID: <20020722.121237.46634409.koji@iijmio-mail.jp> >> AS4691 is not announcing the route of 2001:2e8::/35, >> but I can see this route from looking glass. > >And your point is? You provide no documentation to who SHOULD be >announcing the prefix. Help us out here. AS4691 has changed the announcing the prefix from 2001:2e8::/35 to 2001:2e8::/32. We should not remain /35. Robert has pointed out the MRTD bug. Koji Kondo From michel@arneill-py.sacramento.ca.us Mon Jul 22 06:41:27 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 21 Jul 2002 22:41:27 -0700 Subject: [6bone] MRTD BGP withdrawal bug Message-ID: <2B81403386729140A3A899A8B39B046405E1F9@server2000.arneill-py.sacramento.ca.us> Robert, > Robert Kiessling > from observations of BGP tables, I came to the conclusion > that MRTD has a bug processing withdrawals of routing > announcements. It looks like this bug leads to the well-known > phantom prefixes with huge AS paths, coming together with > routing loops. The huge AS paths are not new, neither is the fact that we know it's a withdrawal bug. May I ask how you pointed out that it's an MRTd bug? So far, my feeling is that the issue has been solved by "let's reboot the router and see what happens" method. Michel. From michel@arneill-py.sacramento.ca.us Mon Jul 22 06:51:20 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 21 Jul 2002 22:51:20 -0700 Subject: [6bone] 2001:478:: as /48 Message-ID: <2B81403386729140A3A899A8B39B046405E1FA@server2000.arneill-py.sacramento.ca.us> > Pim van Pelt wrote: > The below prefix-list used to be used by me (and possibly others) > only on outgoing announcements. This is consistent with me previously using it as ingress announcements, as I am an end-site and you are a pTLA. > This is why I have adapted the strict filtering in egress as well > as ingress these days. I agree. > By the way, looking at the 'strict' prefix list below, I would > like to bring it to the general attention that '3ffe::/17' does > no longer exist, since we started to use the /32 prefixes in > 3ffe:4000::/18, thus chopping the lower half of the /16 in half. > For 6bone, it is now: > 3ffe::/18 ge 24 le 24 > 3ffe:4000::/18 ge 32 le 32 > 3ffe:8000::/17 ge 28 le 28 Thanks for the precision. > From other places, I hear that having /48 or even /64 in the > route table could be 'acceptable'. I still have to see any kind of document that makes it "acceptable". > One might argue that an operator with a large router box with much > memory can opt to have a 'full view' with all the more specifics, > and an operator with a smaller box can opt to have a 'strict full > view' with only aggregated prefixes. This has similarities with what ipv6mh is currently working on (for geo prefixes); however, I can not see any reason to have PA specifics except your own. > Nobody will lose connectivity in the latter case, if and only if we > keep on having at least a route to the more specific in the > aggregating AS. For me, I'll stick to BOFH mode (ie, strict filtering) > until we have a best common practice. Or a multihoming protocol. Michel. From michel@arneill-py.sacramento.ca.us Mon Jul 22 06:57:00 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 21 Jul 2002 22:57:00 -0700 Subject: [6bone] 2001:478:: as /48 Message-ID: <2B81403386729140A3A899A8B39B046405E1FB@server2000.arneill-py.sacramento.ca.us> >> John Fraizer wrote: >> Bill was just notifying us that we SHOULD accept the prefixes as >> un-aggregated, not that they were in the wild yet, unaggregated. > Robert Kiessling wrote: > No, he did not. He said we cannot expect to see an aggregate, but > that does *not* mean that we should accept /48's and /64's. > At least in RIPE region those prefixes are given out with the > explicit warning that they might not be routable. And in fact, > for the specific purposes like exchange point meshes, they don't > need to be announced at all. > Please don't try to create "PI" space by suggesting that those > prefixes should be accepted. I strongly agree with Robert. Michel. From pekkas@netcore.fi Mon Jul 22 06:58:17 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 22 Jul 2002 08:58:17 +0300 (EEST) Subject: [6bone] 2001:478:: as /48 In-Reply-To: Message-ID: On 22 Jul 2002, Robert Kiessling wrote: > John Fraizer writes: > > > OK. This brings about the same implications as in IPv4 space. If you > > want traceroutes through exchange [x] to work without having at least ONE > > hop that has "* * *" for a return, you will accept the prefix and route it > > to *TRANSIT CUSTOMERS*. > > No, this is wrong. I don't know where this myth comes from. > > All you need to accept packets from that address space, but there's no > need at all to be able to route *to* it, to avoid holes in > traceroutes. Thus you don't need to accept any BGP routes from that > block. .. unless you use stuff like Unicast RPF which the most don't (in this context). -- 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 michel@arneill-py.sacramento.ca.us Mon Jul 22 07:07:01 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 21 Jul 2002 23:07:01 -0700 Subject: [6bone] 2001:478:: as /48 Message-ID: <2B81403386729140A3A899A8B39B046405E1FC@server2000.arneill-py.sacramento.ca.us> Bill, >> Michel Py wrote: >> I don't see it as unaggregated and I believe I'm not the only one. I >> dropped my ipv6 prefix-lists and I have a BGP4+ feed from three >> different pTLAs. > Bill Manning wrote: > Whom is aggregating this prefix? * 2001:470::/35 3FFE:1CED:FF02::1 0 13944 6939 i *> 3FFE:B00:C18::8C 0 10566 6939 i * 3FFE:8270:0:1::40 0 20834 15589 6939 i * 2001:480::/35 3FFE:1CED:FF02::1 0 13944 6939 668 i *> 3FFE:B00:C18::8C 0 10566 6939 668 i * 3FFE:8270:0:1::40 As far as I can tell, AS 6939 (Hurricane Electric) >> Is there any document you can point us to that specifies that >> it should be unaggregated? > The original delegation request to ARIN specified that this > range was being used for exchanges and infrastructure purposes. > Exactly like the 198.32.0.0/16 space in v4 space. And the > 3ffe:0: space in the 6bone. For assignment purposes, yes. But the delegation request is not a waiver to break aggregation, AFAIK. Michel. From michel@arneill-py.sacramento.ca.us Mon Jul 22 07:20:15 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 21 Jul 2002 23:20:15 -0700 Subject: [6bone] 2001:478:: as /48 Message-ID: <2B81403386729140A3A899A8B39B046405E1FD@server2000.arneill-py.sacramento.ca.us> >> John Fraizer wrote: >> OK. This brings about the same implications as in IPv4 space. >> If you want traceroutes through exchange [x] to work without >> having at least ONE hop that has "* * *" for a return, you will >> accept the prefix and route it to *TRANSIT CUSTOMERS*. > Robert Kiessling wrote: > No, this is wrong. I don't know where this myth comes from. > All you need to accept packets from that address space, but > there's no need at all to be able to route *to* it, to avoid > holes in traceroutes. Thus you don't need to accept any BGP > routes from that block. One more time I will agree with Robert here. The traceroute is based on the TTL expiring. Therefore, all that the network has to know is the route to the target, specifically meaning that each hop needs to have NLRI for the announcing router. So, the source hosts sends a datagram to the target with increasing TTL values, and each hop that dumps the datagram in the bit bucket sends a "time expired" message to the source host, and that's the way traceroute works. If, by "accident", the TTL expires in a router that the originating host has no specific route to, it does not matter, as what is required is that the router that expires the TTL is able to send the "time expired" to the originating host, not the opposite. > Pekka Savola wrote: >.. unless you use stuff like Unicast RPF which the most don't > (in this context). That would be easily solved by accepting the aggregate for that space. Michel. From jeroen@unfix.org Mon Jul 22 09:38:46 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Mon, 22 Jul 2002 10:38:46 +0200 Subject: [6bone] 2001:478:: as /48 In-Reply-To: Message-ID: <001b01c2315b$350ffb60$534510ac@cyan> John Fraizer wrote: > On 21 Jul 2002, Robert Kiessling wrote: > > > John Fraizer writes: > In such event, EnterZone volunteers to take over the > 3ffe:1c00::/24 space and will move all downstream tunnels to our routers. What's the reason that your company doesn't request it's own IPv6 space from ARIN ? > At the same time, I call one EVERY OTHER participant in the > 6bone to take a look at what prefixes you are originating. If it's not > aggregated, and you don't have extenuating circumstances, as noted above, I > suggest that you AGGREGATE NOW! Otherwise, you'll be listed in my weekly > "These folks are not aggregating, lets beat them about the head and shoulders > until they do" list that I'm goint to start posting to the > list. We have a chance with IPv6 to set the standard BEFORE things get out > of hand. Let us take advantage of it! A couple of URL's for thou: http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-i pv6-doering/R42-v6-table/ Or for comparison the RIPE40 and 41 versions: http://www.space.net/~gert/RIPE/ It also lists something from MERIT, who already are sending a 6bone routing report: http://www.merit.edu/mail.archives/html/6bone-routing-report/ Greets, Jeroen PS: I CC'd Larry who handled some of the 6bone routing report problems last time. From pim@ipng.nl Mon Jul 22 09:44:32 2002 From: pim@ipng.nl (Pim van Pelt) Date: Mon, 22 Jul 2002 10:44:32 +0200 Subject: [6bone] 2001:478:: as /48 In-Reply-To: <200207211616.g6LGGe508924@boreas.isi.edu> References: <200207211616.g6LGGe508924@boreas.isi.edu> Message-ID: <20020722084432.GA19008@bfib.colo.bit.nl> On Sun, Jul 21, 2002 at 09:16:40AM -0700, Bill Manning wrote: | | | this prefix has/is being carved up into /48 and /64 subnets for | use at exchange points and other infrastructure support services. | | Do not expect to see it aggregated. In the RIPE region, there were lengthy and quite heated discussions on how an IXP is to request address space. The superblock 2001:7f8::/32 was created and also carved into /48s for use on peering points. It was specifically forbidden to run support services (such as looking glasses, websites, mailservers, etc) in this address space and it was noted that these /48s need not be globally routable. John points out that not having a route for the /48 will break things like traceroute. This would then be due to reversed path filtering, which can be (and should be) disabled. Others point out that not having a route for the /48 will break things like path MTU discovery. This is also not true, except for those who do have RPF on the router originating the too large frame. Actually, I used to believe also that not having a route for the peering mesh breaks the pMTU, but people with a lot more brains than I assure me that there is nothing broken at the IXP unless the participating operators break their routers (eg by enabling RPF). To my knowledge, there is no router today which does RPF for IPv6, but I could be mistaken. Regarding Johns statement with regard to accepting broken space from somebody who is well known and respected, I am in total disagreement. I will be filtering according to RFC and in the case one exists, the BCP documents which are approved by my local community in the RIPE area. Accepting /48s from some /32 from ARIN does not belong to this set of policies, and I really don't see why any LIR, be they an IXP or no, should be able to change these policies on their own. As said previously, I have no real problem with parties who chose to deliberately leak a /48 into the global tables. Such has been done by the RIPE NCC (who have space from SURFnet, the nren) and possibly will be done by the AMS-IX (the dutch high volume peering point) in the future. This is because the current policies do not allow for these parties to obtain an aggregate for themselves. It is clear that if one is to accept the /48 from AMSIX or RIPENCC that they could have a better path to them. People who do not wish to carry the /48 in their tables, will still have a less specific route to the SURFnet aggregate. So in short: somebody should be aggregating 2001:478::/32 so that I (and most probably several other European operators) will have a path to the aggregate and be able to reach the /48s in a proper, RFC obeying manner. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From bmanning@ISI.EDU Mon Jul 22 12:34:55 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 22 Jul 2002 04:34:55 -0700 (PDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: <2B81403386729140A3A899A8B39B046405E1FC@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Jul 21, 2 11:07:01 pm" Message-ID: <200207221134.g6MBYte29441@boreas.isi.edu> % > Bill Manning wrote: % > Whom is aggregating this prefix? % % * 2001:470::/35 3FFE:1CED:FF02::1 0 13944 6939 i % *> 3FFE:B00:C18::8C 0 10566 6939 i % * 3FFE:8270:0:1::40 0 20834 15589 6939 i % * 2001:480::/35 3FFE:1CED:FF02::1 0 13944 6939 668 i % *> 3FFE:B00:C18::8C 0 10566 6939 668 i % * 3FFE:8270:0:1::40 % % As far as I can tell, AS 6939 (Hurricane Electric) er, 2001:478::/35 is -NOT- there, nor is any other segment of 2001:478::/35. You are not seeing it. % >> Is there any document you can point us to that specifies that % >> it should be unaggregated? % % > The original delegation request to ARIN specified that this % > range was being used for exchanges and infrastructure purposes. % > Exactly like the 198.32.0.0/16 space in v4 space. And the % > 3ffe:0: space in the 6bone. % % For assignment purposes, yes. But the delegation request is not a waiver % to break aggregation, AFAIK. You asked for a document, you got one. Just because you don't like what you got, does not means it does not exist. % % Michel. % -- --bill From bmanning@ISI.EDU Mon Jul 22 12:54:24 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 22 Jul 2002 04:54:24 -0700 (PDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: <2B81403386729140A3A899A8B39B046405E1FD@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Jul 21, 2 11:20:15 pm" Message-ID: <200207221154.g6MBsO703640@boreas.isi.edu> % > Pekka Savola wrote: % >.. unless you use stuff like Unicast RPF which the most don't % > (in this context). % % That would be easily solved by accepting the aggregate for that space. % % Michel. Such an aggregate will never exist, from the holder of 2001:478:: Only people who proxy aggregate will see such. I guess that it is useful to note that This thread was to point out that under no legitimate circumstances should anyone see the aggreagate 2001:478::/35 since all the delegations are of /48 or /64 and are to number exchanges and other infrastructure. I'd like folks to understand what accepting /48s in this range will mean. I'm not asking you to accept them. I'm asking you to -NOT- accept the aggregate. -- --bill From Robert.Kiessling@de.easynet.net Mon Jul 22 13:24:31 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 22 Jul 2002 13:24:31 +0100 Subject: [6bone] MRTD BGP withdrawal bug In-Reply-To: <2B81403386729140A3A899A8B39B046405E1F9@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E1F9@server2000.arneill-py.sacramento.ca.us> Message-ID: "Michel Py" writes: > The huge AS paths are not new, neither is the fact that we know it's a > withdrawal bug. Right. > May I ask how you pointed out that it's an MRTd bug? >From looking at BGP view before and after an router running MRTd. The AS in question annonced a path like "AS-guilty AS-other some-long-path", while AS-other has a different path for the prefix in question. I saw this for the same AS-guilty and different AS-others. > So far, my feeling is that the issue has been solved by "let's reboot > the router and see what happens" method. Right, but that's not an acceptable long-term solution. IMHO either AS-guilty fixes the problem, or their peers have to fix it for them. Robert From bmanning@ISI.EDU Mon Jul 22 13:19:55 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 22 Jul 2002 05:19:55 -0700 (PDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: <20020722084432.GA19008@bfib.colo.bit.nl> from Pim van Pelt at "Jul 22, 2 10:44:32 am" Message-ID: <200207221219.g6MCJtM14543@boreas.isi.edu> % | this prefix has/is being carved up into /48 and /64 subnets for % | use at exchange points and other infrastructure support services. % | % | Do not expect to see it aggregated. % In the RIPE region, there were lengthy and quite heated discussions on % how an IXP is to request address space. % % The superblock 2001:7f8::/32 was created and also carved into /48s for % use on peering points. It was specifically forbidden to run support % services (such as looking glasses, websites, mailservers, etc) in this % address space and it was noted that these /48s need not be globally % routable. whom announces 2001:7f8::/32 ? someone with a path to each and every exchange that gets a /48 ? and whom enforces the "no services" clause? % Regarding Johns statement with regard to accepting broken space from % somebody who is well known and respected, I am in total disagreement. % I will be filtering according to RFC and in the case one exists, the BCP % documents which are approved by my local community in the RIPE area. % Accepting /48s from some /32 from ARIN does not belong to this set of % policies, and I really don't see why any LIR, be they an IXP or no, % should be able to change these policies on their own. Modulo the exceptions you mention below ... :) EP.NET, LLC. is not an LIR. (thats a RIPE convention) Filtering is the responsibility of each ISP, according to their own policies. Nothing I do should affect how you set your own fitlering policies. % So in short: somebody should be aggregating 2001:478::/32 so that I (and % most probably several other European operators) will have a path to the % aggregate and be able to reach the /48s in a proper, RFC obeying manner. That is precisely what I'm asking -NOT- be done. There is no transit facility that will get you to all the exchanges numbered out of this range. e.g. 2001:478:200::/48 MAE-West 2001:478:1199::/48 MAE-Frankfurt 2001:478:39::/48 IX-SauPaulo 2001:478:1202::/48 CNIX-Beijing % % -- % ---------- - - - - -+- - - - - ---------- % Pim van Pelt Email: pim@ipng.nl % http://www.ipng.nl/ IPv6 Deployment % ----------------------------------------------- % -- --bill From pim@ipng.nl Mon Jul 22 14:00:37 2002 From: pim@ipng.nl (Pim van Pelt) Date: Mon, 22 Jul 2002 15:00:37 +0200 Subject: [6bone] 2001:478:: as /48 In-Reply-To: <200207221219.g6MCJtM14543@boreas.isi.edu> References: <20020722084432.GA19008@bfib.colo.bit.nl> <200207221219.g6MCJtM14543@boreas.isi.edu> Message-ID: <20020722130037.GB12882@bfib.colo.bit.nl> Hi Bill, To start off, I now see your point and have no further problems with the de-aggregated /48s. See in-line comments for some more thoughts. The only important issue left, in my oppinion, is if your /48 allocated IXPs will be offering services from within these non-aggregated chunks.. On Mon, Jul 22, 2002 at 05:19:55AM -0700, Bill Manning wrote: | % | this prefix has/is being carved up into /48 and /64 subnets for | % | use at exchange points and other infrastructure support services. | % | | % | Do not expect to see it aggregated. | % In the RIPE region, there were lengthy and quite heated discussions on | % how an IXP is to request address space. | % | % The superblock 2001:7f8::/32 was created and also carved into /48s for | % use on peering points. It was specifically forbidden to run support | % services (such as looking glasses, websites, mailservers, etc) in this | % address space and it was noted that these /48s need not be globally | % routable. | | whom announces 2001:7f8::/32 ? | someone with a path to each and every exchange that gets | a /48 ? and whom enforces the "no services" clause? Nobody announces or aggregates it. It is a placeholder for IXPs. It is much like the network we are talking about now, in all respects. | % Regarding Johns statement with regard to accepting broken space from | % somebody who is well known and respected, I am in total disagreement. | % I will be filtering according to RFC and in the case one exists, the BCP | % documents which are approved by my local community in the RIPE area. | % Accepting /48s from some /32 from ARIN does not belong to this set of | % policies, and I really don't see why any LIR, be they an IXP or no, | % should be able to change these policies on their own. | | Modulo the exceptions you mention below ... :) | EP.NET, LLC. is not an LIR. (thats a RIPE convention) | Filtering is the responsibility of each ISP, according | to their own policies. Nothing I do should affect how | you set your own fitlering policies. Indeed. If one choses not to accept the /48s, then there simply will be no route to those IXP networks. However, if I wanted to be able to reach the /48s, I would be forced to change my filtering policies. So in fact, depending on the given fact that these IXP /48s will be running services in their deaggregated network space, this will surely lead to either unreachable services, or changed (global) filtering policy guidelines. | % So in short: somebody should be aggregating 2001:478::/32 so that I (and | % most probably several other European operators) will have a path to the | % aggregate and be able to reach the /48s in a proper, RFC obeying manner. | | That is precisely what I'm asking -NOT- be done. There is no transit | facility that will get you to all the exchanges numbered out of this | range. e.g. | | 2001:478:200::/48 MAE-West | 2001:478:1199::/48 MAE-Frankfurt | 2001:478:39::/48 IX-SauPaulo | 2001:478:1202::/48 CNIX-Beijing These, and all other more specifics in the 2001:478::/32 network, will be unreachable from my site(s). I do hope people are not planning to run public services such as looking glass or websites/whois servers in these networks ? If so, those will not be reachable either for my customers, unless I can be somehow persuaded that IXPs are more special than other pigs. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From michel@arneill-py.sacramento.ca.us Mon Jul 22 15:44:28 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 22 Jul 2002 07:44:28 -0700 Subject: [6bone] 2001:478:: as /48 Message-ID: <2B81403386729140A3A899A8B39B046406C9A0@server2000.arneill-py.sacramento.ca.us> > er, 2001:478::/35 is -NOT- there, nor is any other > segment of 2001:478::/35. You are not seeing it. Doh. As I said previously, I don't see it indeed. > You asked for a document, you got one. Just because you > don't like what you got, does not means it does not exist. I beg your pardon, but I still have to see a link to it. Michel. From michel@arneill-py.sacramento.ca.us Mon Jul 22 16:11:59 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 22 Jul 2002 08:11:59 -0700 Subject: [6bone] MRTD BGP withdrawal bug Message-ID: <2B81403386729140A3A899A8B39B046405E1FE@server2000.arneill-py.sacramento.ca.us> > Robert Kiessling wrote: > From looking at BGP view before and after an router running > MRTd. The AS in question annonced a path like "AS-guilty > AS-other some-long-path", while AS-other has a different path > for the prefix in question. I saw this for the same AS-guilty > and different AS-others. This is consistent with what was observed before, indeed. >> So far, my feeling is that the issue has been solved by "let's reboot >> the router and see what happens" method. > Right, but that's not an acceptable long-term solution. IMHO > either AS-guilty fixes the problem, > or their peers have to fix it for them. This is not an acceptable long-term solution either. So what can we do? Even if we declare MRTd illegal, enforcing it would be another story. I vaguely tried to define a generic route-map for these with no success either. Michel. From rrockell@sprint.net Mon Jul 22 16:20:22 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Mon, 22 Jul 2002 11:20:22 -0400 (EDT) Subject: [6bone] MRTD BGP withdrawal bug In-Reply-To: <2B81403386729140A3A899A8B39B046405E1FE@server2000.arneill-py.sacramento.ca.us> Message-ID: If one allows bad prefixes to leak into one routing domain, and then passes these prefixes on to anyone, that routing domain is as guilty as the originator. Long-term solution: De-peer with those that violate AUP for the 6bone. This scales nicely, and model exactly what people on the internet do today. Thanks Rob Rockell SprintLink (+1) 703-689-6322 Sprint IP Services ----------------------------------------------------------------------- On Mon, 22 Jul 2002, Michel Py wrote: ->> Robert Kiessling wrote: ->> From looking at BGP view before and after an router running ->> MRTd. The AS in question annonced a path like "AS-guilty ->> AS-other some-long-path", while AS-other has a different path ->> for the prefix in question. I saw this for the same AS-guilty ->> and different AS-others. -> ->This is consistent with what was observed before, indeed. -> -> ->>> So far, my feeling is that the issue has been solved by "let's reboot ->>> the router and see what happens" method. -> ->> Right, but that's not an acceptable long-term solution. IMHO ->> either AS-guilty fixes the problem, -> ->> or their peers have to fix it for them. -> ->This is not an acceptable long-term solution either. -> ->So what can we do? Even if we declare MRTd illegal, enforcing it would ->be another story. I vaguely tried to define a generic route-map for ->these with no success either. -> ->Michel. -> ->_______________________________________________ ->6bone mailing list ->6bone@mailman.isi.edu ->http://mailman.isi.edu/mailman/listinfo/6bone -> From michel@arneill-py.sacramento.ca.us Mon Jul 22 16:21:47 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 22 Jul 2002 08:21:47 -0700 Subject: [6bone] 2001:478:: as /48 Message-ID: <2B81403386729140A3A899A8B39B046405E1FF@server2000.arneill-py.sacramento.ca.us> > Pim Van Pelt wrote: > So in short: somebody should be aggregating 2001:478::/32 so > that I (and most probably several other European operators) > will have a path to the aggregate and be able to reach the > /48s in a proper, RFC obeying manner. I agree. > These, and all other more specifics in the 2001:478::/32 network, > will be unreachable from my site(s). I do hope people are not > planning to run public services such as looking glass or > websites/whois servers in these networks ? The problem is, they are. > If so, those will not be reachable either for my customers, unless > I can be somehow persuaded that IXPs are more special than other pigs. This is really the core of the issue. IXPs do need a multihoming solution. The way to get it is _not_ to break PA because there is no PI. As I said many times before, any multihoming solution requires a clean PA space to work, no holes, no specifics. So please, we are not kids here. Instead of breaking things because they don't work the way we would like, let's try to see a little farther on the horizon and promote _aggregatable_ methods such as http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt. Michel. From tvo@EnterZone.Net Mon Jul 22 16:26:46 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 22 Jul 2002 11:26:46 -0400 (EDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: <001b01c2315b$350ffb60$534510ac@cyan> Message-ID: On Mon, 22 Jul 2002, Jeroen Massar wrote: > John Fraizer wrote: > > > On 21 Jul 2002, Robert Kiessling wrote: > > > > > John Fraizer writes: > > > > In such event, EnterZone volunteers to take over the > > 3ffe:1c00::/24 space and will move all downstream tunnels to our > routers. > What's the reason that your company doesn't request it's own IPv6 space > from ARIN ? You made the assumption that we don't have RIR space. It was incorrect. We do. I am offering to run the 3ffe:1c00::/24 space as well. We already have 6bone space out of that block and since MERIT seems unwilling to provide ongoing service to the block, I am offering to do so. I will *NOT* put folks on our RIR space for free but will gladly do so on 6bone address space. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From michel@arneill-py.sacramento.ca.us Mon Jul 22 16:34:32 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 22 Jul 2002 08:34:32 -0700 Subject: [6bone] 2001:478:: as /48 Message-ID: <2B81403386729140A3A899A8B39B046406C9A3@server2000.arneill-py.sacramento.ca.us> >> In such event, EnterZone volunteers to take over the >> 3ffe:1c00::/24 space and will move all downstream tunnels >> to our routers. I would suggest to fill a complete pTLA request and send it to Bob Fink, specifying that you wish to take over the MERIT block. Michel. From michel@arneill-py.sacramento.ca.us Mon Jul 22 16:39:33 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 22 Jul 2002 08:39:33 -0700 Subject: [6bone] 2001:478:: as /48 Message-ID: <2B81403386729140A3A899A8B39B046406C9A4@server2000.arneill-py.sacramento.ca.us> > Bill Manning wrote: > Such an aggregate will never exist, from the holder of > 2001:478:: Only people who proxy aggregate will see such. > I guess that it is useful to note that This thread was to > point out that under no legitimate circumstances should > anyone see the aggreagate 2001:478::/35 since all the > delegations are of /48 or /64 and are to number exchanges > and other infrastructure. I'd like folks to understand > what accepting /48s in this range will mean. I'm not asking > you to accept them. I'm asking you to -NOT- accept the > aggregate. I will create this aggregate myself (rather, configure a static route to it on each tunnel) if I decide to implement RPF checks and want my traceroutes working. > That is precisely what I'm asking -NOT- be done. There is > no transit facility that will get you to all the exchanges > numbered out of this range. e.g. > 2001:478:200::/48 MAE-West > 2001:478:1199::/48 MAE-Frankfurt > 2001:478:39::/48 IX-SauPaulo > 2001:478:1202::/48 CNIX-Beijing The question is: Why do you need a transit facility that will get you all the exchanges? I am sympathetic with the problem IXs (and other people) are having, but do keep in mind that by breaking PA you are shooting yourself in the foot regarding the availability of a longer-term solution. Michel. From tvo@EnterZone.Net Mon Jul 22 17:04:43 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 22 Jul 2002 12:04:43 -0400 (EDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: <2B81403386729140A3A899A8B39B046406C9A3@server2000.arneill-py.sacramento.ca.us> Message-ID: On Mon, 22 Jul 2002, Michel Py wrote: > >> In such event, EnterZone volunteers to take over the > >> 3ffe:1c00::/24 space and will move all downstream tunnels > >> to our routers. > > I would suggest to fill a complete pTLA request and send it to Bob Fink, > specifying that you wish to take over the MERIT block. > > Michel. I have already completed the pTLA request. Bob: 3ffe:1c00::/24 would be nice unless someone can re-animate those in charge of 3ffe:1c00::/24 currently. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From psb@ast.cam.ac.uk Mon Jul 22 17:12:19 2002 From: psb@ast.cam.ac.uk (Peter Bunclark) Date: Mon, 22 Jul 2002 17:12:19 +0100 (BST) Subject: [6bone] 2001:478:: as /48 In-Reply-To: <2B81403386729140A3A899A8B39B046405E1FF@server2000.arneill-py.sacramento.ca.us> Message-ID: Is this discussion nearly finished? If not, I wonder if it might be worth considering taking it into private space and one of you issuing an executive summary when it's all over... I could just unsubscribe, I guess, but that would be defeatist! Pete. From bmanning@ISI.EDU Mon Jul 22 17:15:44 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 22 Jul 2002 09:15:44 -0700 (PDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: <2B81403386729140A3A899A8B39B046406C9A4@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Jul 22, 2 08:39:33 am" Message-ID: <200207221615.g6MGFim21373@boreas.isi.edu> % > Bill Manning wrote: % > Such an aggregate will never exist, from the holder of % > 2001:478:: Only people who proxy aggregate will see such. % > I guess that it is useful to note that This thread was to % > point out that under no legitimate circumstances should % > anyone see the aggreagate 2001:478::/35 since all the % > delegations are of /48 or /64 and are to number exchanges % > and other infrastructure. I'd like folks to understand % > what accepting /48s in this range will mean. I'm not asking % > you to accept them. I'm asking you to -NOT- accept the % > aggregate. % % I will create this aggregate myself (rather, configure a static route to % it on each tunnel) if I decide to implement RPF checks and want my % traceroutes working. Hum.. This is exactly what SprintICM did eight years ago when they annoucnced 192.0.0.0/3 into the routing system. Many networks became unreachable. While your at it, you need to include the aggreates for the RIPE, APNIC, and ARIN /32s that are being/will be used for this exact same purpose. Proxy aggregation is lying to the routing system. While you can lie to yourself with relative impunity, lying to others is bad. -- --bill From bmanning@ISI.EDU Mon Jul 22 17:21:37 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 22 Jul 2002 09:21:37 -0700 (PDT) Subject: [6bone] 2001:478:: as /48 In-Reply-To: from Peter Bunclark at "Jul 22, 2 05:12:19 pm" Message-ID: <200207221621.g6MGLbJ24841@boreas.isi.edu> % Is this discussion nearly finished? If not, I wonder if it might be worth % considering taking it into private space and one of you issuing an % executive summary when it's all over... % I could just unsubscribe, I guess, but that would be defeatist! % % Pete. I think its pretty much dead. I just took the opporuntity to announce the policy of 2001:478 on delegations/aggregation, which predates the RIR policys for micro-allocations in their respective blocks. Some ISPs beleive that this is evil incarnate and agressivly filter. Others are more pragmatic and will adjust as their needs dictate. Certain RIR policies in regards to /48 & /64 delegations are unenforcable and the EP.NET, LLC. policy w.r.t. 2001:478 recognises this. --bill From Florent.Parent@viagenie.qc.ca Wed Jul 24 16:30:33 2002 From: Florent.Parent@viagenie.qc.ca (Florent Parent) Date: Wed, 24 Jul 2002 11:30:33 -0400 Subject: [6bone] bogus routes remain for /35 In-Reply-To: References: <20020720004319.C677C7BA@starfruit.itojun.org> <20020722.101158.60050076.koji@iijmio-mail.jp> Message-ID: <24690000.1027524633@blues.viagenie.qc.ca> Folks, I'm updating our router software today. This will hopfully get rid of this bogus announcement. Florent. --On 2002-07-22 03:18:48 +0100 Robert.Kiessling@de.easynet.net wrote: > Koji Kondo writes: > >> AS4691 is not announcing the route of 2001:2e8::/35, >> but I can see this route from looking glass. > > See my message about MRTD. A bug in it is most likely the cause of > this announcement. > > Robert > >> BGP routing table entry for 2001:2E8::/35, version 33588 >> Paths: (4 available, best #3) >> Advertised to non peer-group peers: >> 2001:3A0::1001 2001:3A0::2001 2001:3A0::2002 2001:3A0::2003 >> 2001:3A0::3001 65526 10566 6939 15589 1275 5609 20745 20745 20745 >> 20745 20745 20745 20745 109 5550 9112 13110 3320 680 5539 8627 6830 >> 559 8758 9044 3FFE:81F1:1:2016::1 from 3FFE:81F1:1:2016::1 (213.91.4.3) >> Origin IGP, localpref 10, valid, external >> Community: no-export From tvo@EnterZone.Net Wed Jul 24 23:41:48 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 24 Jul 2002 18:41:48 -0400 (EDT) Subject: [6bone] ip6.int or ip6.arpa or BOTH? Message-ID: For reverse records, which zones should I be creating? ip6.arpa or ip6.int? Traces from some places show our reverse and some do not. I have some machines (all using the same DNS servers) that show our reverse on our nets and some that do not. The machines that don't show ours WILL show *some* other networks reverses for ipv6 addresses. So, can someone tell me how I should be set up? I currently have ip6.int zones. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From bmanning@ISI.EDU Thu Jul 25 00:13:01 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 24 Jul 2002 16:13:01 -0700 (PDT) Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: from John Fraizer at "Jul 24, 2 06:41:48 pm" Message-ID: <200207242313.g6OND1A17819@boreas.isi.edu> % % For reverse records, which zones should I be creating? ip6.arpa or % ip6.int? Traces from some places show our reverse and some do not. I % have some machines (all using the same DNS servers) that show our reverse % on our nets and some that do not. The machines that don't show ours WILL % show *some* other networks reverses for ipv6 addresses. % % So, can someone tell me how I should be set up? I currently have ip6.int % zones. % % % --- % John Fraizer | High-Security Datacenter Services | % EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | % http://www.enterzone.net/ | Virtual, Dedicated, Colocation | % % % _______________________________________________ % 6bone mailing list % 6bone@mailman.isi.edu % http://mailman.isi.edu/mailman/listinfo/6bone % for 3ffe::/16 space, there is no current ip6.arpa delegation. -- --bill From tvo@ENTERZONE.NET Thu Jul 25 01:28:30 2002 From: tvo@ENTERZONE.NET (John Fraizer) Date: Wed, 24 Jul 2002 20:28:30 -0400 (EDT) Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: <200207242313.g6OND1A17819@boreas.isi.edu> Message-ID: On Wed, 24 Jul 2002, Bill Manning wrote: > % > % For reverse records, which zones should I be creating? ip6.arpa or > % ip6.int? Traces from some places show our reverse and some do not. I > % have some machines (all using the same DNS servers) that show our reverse > % on our nets and some that do not. The machines that don't show ours WILL > % show *some* other networks reverses for ipv6 addresses. > % > % So, can someone tell me how I should be set up? I currently have ip6.int > % zones. > % > % > % --- > % John Fraizer | High-Security Datacenter Services | > % EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | > % http://www.enterzone.net/ | Virtual, Dedicated, Colocation | > % > > > for 3ffe::/16 space, there is no current ip6.arpa delegation. > > > -- > --bill OK. Does that mean that for 3ffe::/16 space, I should be using ip6.int and for 2001:4f0::/35, I should be using ip6.arp? --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From kim@tac.nyc.ny.us Thu Jul 25 01:53:33 2002 From: kim@tac.nyc.ny.us (Kimmo Suominen) Date: Wed, 24 Jul 2002 20:53:33 -0400 Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: from John Fraizer on Wed, 24 Jul 2002 18:41:48 -0400 References: Message-ID: <20020725005333.DB36B7E04@beowulf.gw.com> More recent versions of glibc only seem to look in ip6.arpa (e.g. glibc-2.2.4-24 from RHL). Other systems only look in ip6.int (e.g. NetBSD). I've been maintaining both ip6.arpa and ip6.int in nibble format, so that at least all local nodes will be able to resolve names. I only edit files for ip6.arpa, and use a little Makefile to produce the ip6.int files. It would be nice to have ip6.arpa for 3ffe::/16, too... :-) + Kim IP6ZONES?= \ 3ffe:507:184.rev \ 3ffe:1ce1:100.rev \ 3ffe:26ff:10.rev \ 3ffe:2900:b00c.rev \ .for d in ${IP6ZONES} all:: ${d:S/:/_/g} ${d:S/:/_/g}: ${d} -rm -f ${.TARGET} ${SED} -e 's/ip6\.arpa/ip6.int/g' ${.ALLSRC} > ${.TARGET} .endfor | From: John Fraizer | Date: Wed, 24 Jul 2002 18:41:48 -0400 | | | For reverse records, which zones should I be creating? ip6.arpa or | ip6.int? Traces from some places show our reverse and some do not. I | have some machines (all using the same DNS servers) that show our reverse | on our nets and some that do not. The machines that don't show ours WILL | show *some* other networks reverses for ipv6 addresses. | | So, can someone tell me how I should be set up? I currently have ip6.int | zones. | | | --- | John Fraizer | High-Security Datacenter Services | | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | | | | _______________________________________________ | 6bone mailing list | 6bone@mailman.isi.edu | http://mailman.isi.edu/mailman/listinfo/6bone | From bmanning@ISI.EDU Thu Jul 25 02:07:00 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 24 Jul 2002 18:07:00 -0700 (PDT) Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: from John Fraizer at "Jul 24, 2 08:28:30 pm" Message-ID: <200207250107.g6P170613055@boreas.isi.edu> % > for 3ffe::/16 space, there is no current ip6.arpa delegation. % > % > --bill % % OK. Does that mean that for 3ffe::/16 space, I should be using ip6.int % and for 2001:4f0::/35, I should be using ip6.arp? % % --- You can put both into ip6.int. You can only put the 2001: stuff into ip6.arpa. Now the current RH resolver will only look in ip6.arpa. :( -- --bill From tvo@EnterZone.Net Thu Jul 25 02:19:24 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 24 Jul 2002 21:19:24 -0400 (EDT) Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: <20020725005333.DB36B7E04@beowulf.gw.com> Message-ID: OK. (1) What is nibble format? (2) Why would the glibc maintainers drop looking in ip6.int when there is no ip6.arpa for 3ffe::/16? I just want reverse to work for our zones. John On Wed, 24 Jul 2002, Kimmo Suominen wrote: > More recent versions of glibc only seem to look in ip6.arpa (e.g. > glibc-2.2.4-24 from RHL). Other systems only look in ip6.int > (e.g. NetBSD). > > I've been maintaining both ip6.arpa and ip6.int in nibble format, so > that at least all local nodes will be able to resolve names. I only > edit files for ip6.arpa, and use a little Makefile to produce the > ip6.int files. > > It would be nice to have ip6.arpa for 3ffe::/16, too... :-) > > + Kim > > IP6ZONES?= \ > 3ffe:507:184.rev \ > 3ffe:1ce1:100.rev \ > 3ffe:26ff:10.rev \ > 3ffe:2900:b00c.rev \ > > .for d in ${IP6ZONES} > all:: ${d:S/:/_/g} > > ${d:S/:/_/g}: ${d} > -rm -f ${.TARGET} > ${SED} -e 's/ip6\.arpa/ip6.int/g' ${.ALLSRC} > ${.TARGET} > .endfor From kim@tac.nyc.ny.us Thu Jul 25 02:31:32 2002 From: kim@tac.nyc.ny.us (Kimmo Suominen) Date: Wed, 24 Jul 2002 21:31:32 -0400 Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: from John Fraizer on Wed, 24 Jul 2002 21:19:24 -0400 References: Message-ID: <20020725013132.8CF6E7E04@beowulf.gw.com> | From: John Fraizer | Date: Wed, 24 Jul 2002 21:19:24 -0400 | | OK. | | (1) What is nibble format? $ORIGIN 2.0.0.0.c.0.0.b.0.0.9.2.e.f.f.3.ip6.arpa. 8.1.5.7.c.1.e.f.f.f.2.e.4.0.2.0 IN PTR beowulf.gw.com. Regards, + Kim From tvo@EnterZone.Net Thu Jul 25 02:56:32 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 24 Jul 2002 21:56:32 -0400 (EDT) Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: <20020725013132.8CF6E7E04@beowulf.gw.com> Message-ID: On Wed, 24 Jul 2002, Kimmo Suominen wrote: > | From: John Fraizer > | Date: Wed, 24 Jul 2002 21:19:24 -0400 > | > | OK. > | > | (1) What is nibble format? > > $ORIGIN 2.0.0.0.c.0.0.b.0.0.9.2.e.f.f.3.ip6.arpa. > 8.1.5.7.c.1.e.f.f.f.2.e.4.0.2.0 IN PTR beowulf.gw.com. > > Regards, > + Kim OK. That's how I've been doing things thus far. Now, I find a new problem. It doesn't appear that ARIN has delegated ip6.arpa for 2001:4f0::/35 to me. ; <<>> DiG 9.1.0 <<>> @arrowroot.arin.net soa 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.4.0.1.0.0.2.ip6.arpa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46690 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.4.0.1.0.0.2.ip6.arpa. IN SOA ;; AUTHORITY SECTION: 4.0.1.0.0.2.ip6.arpa. 10800 IN SOA arrowroot.arin.net. bind.arin.net. 2002041212 10800 3600 1209600 10800 ;; Query time: 100 msec ;; SERVER: 198.133.199.110#53(arrowroot.arin.net) ;; WHEN: Wed Jul 24 21:45:16 2002 ;; MSG SIZE rcvd: 149 > 4.0.1.0.0.2.ip6.arpa Server: arrowroot.arin.net Address: 198.133.199.110#53 4.0.1.0.0.2.ip6.arpa origin = arrowroot.arin.net. mail addr = bind.arin.net. serial = 2002041212 refresh = 10800 retry = 3600 expire = 1209600 minimum = 10800 > 0.f.4.0.1.0.0.2.ip6.arpa Server: arrowroot.arin.net Address: 198.133.199.110#53 ** server can't find 0.f.4.0.1.0.0.2.ip6.arpa.: NXDOMAIN Isn't THAT special. It doesn't look like the ip6.arpa zone has been updated at ARIN since April 12, 2002. [whois.arin.net] EnterZone, Inc (ENTERZONE-V6) 6227 Headley Road Gahanna, OH 43230 US Netname: ENTERZONE-V6 Netnumber: 2001:04F0:0000:0000:0000:0000:0000:0000/35 Maintainer: V6ZN Coordinator: Fraizer, John (JF1998-ARIN) John.Fraizer@ENTERZONE.NET +1 614 554-4356 Domain System inverse mapping provided by: NS1.ENTERZONE.NET NS2.ENTERZONE.NET Record last updated on 18-Jul-2002. It would be nice if the ip6.arpa records were REALLY delegated to my nameservers. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From kim@tac.nyc.ny.us Thu Jul 25 04:27:48 2002 From: kim@tac.nyc.ny.us (Kimmo Suominen) Date: Wed, 24 Jul 2002 23:27:48 -0400 Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: <200207250203.g6P239L9059592@khavrinen.lcs.mit.edu> from Garrett Wollman on Wed, 24 Jul 2002 22:03:09 -0400 References: <200207250203.g6P239L9059592@khavrinen.lcs.mit.edu> Message-ID: <20020725032748.25B7C7E10@beowulf.gw.com> I'm using $ORIGIN in the IPv6 reverse files to avoid excessively long lines. I also find it easier to move machines from one subnet to another by moving an entire PTR entry to be under a different $ORIGIN as opposed to having to edit the line too. This is especially useful when there are moves from one assigned block to another. I wish I could do "popd" or some sort of "cd .." with $ORIGIN. Or just limit the scope, maybe something like { $ORIGIN xxx. foo IN PTR yyy.zzz. } But that's probably off-topic here, already. + Kim | From: Garrett Wollman | Date: Wed, 24 Jul 2002 22:03:09 -0400 | | In article you w | rite: | | >I've been maintaining both ip6.arpa and ip6.int in nibble format, so | >that at least all local nodes will be able to resolve names. I only | >edit files for ip6.arpa, and use a little Makefile to produce the | >ip6.int files. | | There's really no need to go to all that work, since the records in | the zones are all the same but for the origin. We have: | | zone "2.1.0.0.a.1.2.1.2.0.0.2.ip6.int" { | type master; | file "primary/rev.ipv6.db"; | }; | | zone "2.0.0.0.1.e.c.1.e.f.f.3.ip6.int" { | type master; | file "primary/rev.ipv6.db"; | }; | | ..and everything works just peachy. (Actually, not quite everything, | because there's one address (prefix::1) which needs to map to | different things in our 6to4 and 6bone spaces, but we'll fix that by | giving both duties to one machine.) The zone file uses only | origin-relative addresses and does not contain a $ORIGIN directive. | | -GAWollman | | -- | Garrett A. Wollman | [G]enes make enzymes, and enzymes control the rates of | wollman@lcs.mit.edu | chemical processes. Genes do not make ``novelty- | Opinions not those of| seeking'' or any other complex and overt behavior. | MIT, LCS, CRS, or NSA| - Stephen Jay Gould (1941-2002) | From fink@es.net Thu Jul 25 06:20:05 2002 From: fink@es.net (Bob Fink) Date: Wed, 24 Jul 2002 22:20:05 -0700 Subject: [6bone] pTLA request UACH - review closes 7 August 2002 Message-ID: <5.1.0.14.0.20020724221208.025c37d8@imap2.es.net> 6bone Folk, UACH has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 7 August 2002. Please send your comments to me or the list. Also note that UACH has permission to use REUNA's ASN (AS11340) for 6bone pTLA purposes. Thanks, Bob === >From: "Christian Lazo R." >To: >Subject: request for pTLA >Date: Mon, 24 Jun 2002 12:12:29 -0700 > >Hello, > >As a SPTLA, I'm very much interested to be a PTLA. > >Therefore I'm sending my application in the order that you require: > > 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: > > I have esperience from june 2001 > > > 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: UACH >origin: AS45333 >descr: Universidad Austral de Chile > Instituto de Informatica >country: CL >prefix: 3FFE:8070:100C::/48 >application: ping routerv6.ipv6.cl >tunnel: IPv6 in IPv4 routerv6.inf.uach.cl -> >ipv6-gw.compendium.com.ar COMPENDIUM-AR BGP4+ >tunnel: IPv6 in IPv4 routerv6.inf.uach.cl -> >unam-ipv6-1.ipv6.unam.mx UNAM BGP4+ >tunnel: IPv6 in IPv4 routerv6.inf.uach.cl -> gwipv6.ipv6.itesm.mx >ITESM BGP4+ >tunnel: IPv6 in IPv4 routerv6.inf.uach.cl -> gw6.nic.mx NIC-MX BGP4+ >contact: CLR1-6BONE >url: http://ipv6.inf.uach.cl/ >notify: clazo@inf.uach.cl >mnt-by: MNT-UACH >changed: clazo@inf.uach.cl 20010626 >changed: clazo@inf.uach.cl 20010629 >changed: clazo@inf.uach.cl 20020618 >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. > > > > > > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > entries for the Applicant's router(s) and at least one host > system. > >[clazo@antillanca clazo]$ dig www.ipv6.cl > >; <<>> DiG 8.2 <<>> www.ipv6.cl >;; res options: init recurs defnam dnsrch >;; got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 >;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4 >;; QUERY SECTION: >;; www.ipv6.cl, type = A, class = IN > >;; ANSWER SECTION: >www.ipv6.cl. 14h41m4s IN A 146.83.248.3 > >;; AUTHORITY SECTION: >ipv6.cl. 14h41m4s IN NS ns.ipv6.cl. >ipv6.cl. 14h41m4s IN NS secundario.nic.cl. > >;; ADDITIONAL SECTION: >ns.ipv6.cl. 10h51m50s IN A 146.83.248.2 >ns.ipv6.cl. 14h23m6s IN AAAA 3ffe:8070:100c:2c01::a >secundario.nic.cl. 11h7m54s IN A 216.72.164.136 >secundario.nic.cl. 11h7m54s IN A 200.27.126.131 > >;; Total query time: 6 msec >;; FROM: antillanca.inf.uach.cl to SERVER: default -- 146.83.216.201 >;; WHEN: Mon Jun 17 21:25:35 2002 >;; MSG SIZE sent: 29 rcvd: 174 > > > 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. > >www.ipv6.cl > > > > 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. > > > > > > 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@inf.uach.cl > > > 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. > >The potential group that we are available to give this service is the >following: > >All the chilean universities counting with Internet and interested in >working with ipv6. > >There are also some other big Chileans firms such as Internet Service >Provider > >Nowadays, we are working with other Latin American universities in order >to grow up the interest to use IPv6 > >As you can see, our purpose is to become the IPv6 in Chile. > > 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. > > 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>. > > >greeting > >(sorry , but my Inglish is very bad) > >Christian >________________ >Christian Lazo R. >Instituto de Informatica >fono 56-63-221812 >Fac Cs de la Ingenieria >Universidad Austral de Chile From fink@es.net Thu Jul 25 06:27:21 2002 From: fink@es.net (Bob Fink) Date: Wed, 24 Jul 2002 22:27:21 -0700 Subject: [6bone] pTLA request ENTERZONE - review closes 7 August 2002 Message-ID: <5.1.0.14.0.20020724222105.020d7070@imap2.es.net> 6bone Folk, ENTERZONE has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 7 August 2002. Please send your comments to me or the list. Also note that ENTERZONE already has an ARIN issued sTLA prefix allocated (2001:04F0::/35) for their customers willing to pay for IPv6 service. They want to provide free experimental 6bone services to anyone who wants to experiment as well as providing production IPv6 services. Thanks, Bob === >Date: Wed, 17 Jul 2002 20:51:29 -0400 (EDT) >From: John.Fraizer@ENTERZONE.NET >To: fink@es.net >Subject: pTLA prefix request - updated > > > 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: > > 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. > > EnterZone has been a pNLA since March 1999 and has since March 30, >1999 maintained our ipv6-site, inet6num, mntner and person objects, >including each tunnel that we have active. > > > 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. > > EnterZone has during this time period experienced one outage with >respect to 6bone connectivity that was caused by catastrophic failure of >our (single at the time) 6bone router. Our IPv6 network now consists of >redundant border (border1.enterzone.net and border2.enterzone.net) and >core (core1.enterzone.net and core2.enterzone.net) routers to prevent >this single point of failure situation from occuring again. Note: Core1 >is currently being upgraded and is not at this time ipv6 accessable. > > > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > entries for the Applicant's router(s) and at least one host > system. > > EnterZone has maintained DNS forward and reverse records for >nitrous.ipv6.enterzone.net (v4 or v6 looking-glass) and ipv6.enterzone.net >(v6 only accessable website) in our nameservers since some time in >1999. In addition, all tunnel endpoint addresses have appropriate >ip6.int entries. > > 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. > > http://ipv6.enterzone.net/ while not pretty, includes up-to-date >information about EnterZones IPv6 site and services. > > http://nitrous.ipv6.enterzone.net/ is our IPv6 looking-glass running the >MRLG code that I wrote. > > 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. > > EnterZone maintains a 24x7 network operations center and has multiple >contacts associated with our ipv6-site object with appropriate person >objects registered in the 6bone registry. > > 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. > > EnterZone maintains the ipv6@enterzone.net mail alias that goes to all >network operations staff which is indicated in the notify attribute of our >ipv6-site 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. > > EnterZone is a regional NSP providing in High-Security Datacenter >services, dedicated connectivity services and colocation services. We >count 4 dialup providers among our customers and are working with these >providers in hopes to facilitate native IPv6 access services for their >dialup customers in the future. In addition, EnterZone owns and operates >the CMH-IX NAP [http://www.cmh-ix.net] and plans on implementing IPv6 >route servers at the exchange and encouraging native IPv6 peering >among its participants. > > 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. > > EnterZone has strived to abide by the 6bone operational rules since >the time of our connection to the 6bone in March of 1999. In recent >weeks, as a matter of necessity, we have been forced to announce our >specific 3ffe:1ced::/32 and request that our BGP peers accept and >redistribute this de-aggregated prefix to maintain connectivity for our >downstream IPv6 clients. This was necessary because the pTLA from which >we have our pNLA allocation has been unresponsive in modifying a tunnel >configuration. This modification was necessary because of events beyond >our control. Had our pTLA been responsive, we would never have announced >the more specific prefix however. Since March of 1999, this is the ONLY >instance in which we have not abided by the 6bone operational >rules. Please understand that we only announced our specific pNLA to >maintain connectivity because our pTLA was, and remains unresponsive. I >tried multiple emails, telephone calls, and ultimately a broadcast email >to the 6bone list to no avail. > > >Thank you for your consideration. > > > >--- >John Fraizer | High-Security Datacenter Services | >EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | >http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From randy@psg.com Thu Jul 25 06:28:52 2002 From: randy@psg.com (Randy Bush) Date: Wed, 24 Jul 2002 22:28:52 -0700 Subject: [6bone] ip6.int or ip6.arpa or BOTH? References: <20020725005333.DB36B7E04@beowulf.gw.com> Message-ID: > It would be nice to have ip6.arpa for 3ffe::/16, too... :-) soon randy From pim@ipng.nl Thu Jul 25 06:36:49 2002 From: pim@ipng.nl (Pim van Pelt) Date: Thu, 25 Jul 2002 07:36:49 +0200 Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: References: <20020725013132.8CF6E7E04@beowulf.gw.com> Message-ID: <20020725053649.GB17737@bfib.colo.bit.nl> John, At RIPE42 (the last meeting) it was proposed to start delegating in ip6.arpa (and keeping ip6.int for backwards compatibility) for each new request made after the 1st of July. The .int variant is supposed to be deprecated by RFC3152, but still widely used in the field for both 3ffe and 2001 networks. I remember having checked up on some of my own 2001 allocations a couple of months ago, and was quite sure that there was no .arpa delegation for me. Some weeks ago it mysteriously appeared. It's somewhere on my wishlist to create both delegations (ip6.int and ip6.arpa) by generating the one from the other, like Kim said. Debian also had a 'messup' a year ago when they suddonly decided to only resolve in .arpa, rendering Debian boxes without a reversed resolver for a while. They reverted to .int resolving due to complaints from the field ( ;-) ). I think it is time to start resolving .arpa zonefiles. I'd advise you to simply keep both and use something along the lines of what Kim has proposed (the Makefile). houdoe Pim On Wed, Jul 24, 2002 at 09:56:32PM -0400, John Fraizer wrote: | | On Wed, 24 Jul 2002, Kimmo Suominen wrote: | | > | From: John Fraizer | > | Date: Wed, 24 Jul 2002 21:19:24 -0400 | > | | > | OK. | > | | > | (1) What is nibble format? | > | > $ORIGIN 2.0.0.0.c.0.0.b.0.0.9.2.e.f.f.3.ip6.arpa. | > 8.1.5.7.c.1.e.f.f.f.2.e.4.0.2.0 IN PTR beowulf.gw.com. | > | > Regards, | > + Kim | | OK. That's how I've been doing things thus far. Now, I find a new | problem. | | It doesn't appear that ARIN has delegated ip6.arpa for 2001:4f0::/35 to | me. | | ; <<>> DiG 9.1.0 <<>> @arrowroot.arin.net soa | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.4.0.1.0.0.2.ip6.arpa | ;; global options: printcmd | ;; Got answer: | ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46690 | ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 | | ;; QUESTION SECTION: | ;1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.4.0.1.0.0.2.ip6.arpa. IN | SOA | | ;; AUTHORITY SECTION: | 4.0.1.0.0.2.ip6.arpa. 10800 IN SOA | arrowroot.arin.net. bind.arin.net. 2002041212 10800 3600 1209600 10800 | | ;; Query time: 100 msec | ;; SERVER: 198.133.199.110#53(arrowroot.arin.net) | ;; WHEN: Wed Jul 24 21:45:16 2002 | ;; MSG SIZE rcvd: 149 | | | | > 4.0.1.0.0.2.ip6.arpa | Server: arrowroot.arin.net | Address: 198.133.199.110#53 | | 4.0.1.0.0.2.ip6.arpa | origin = arrowroot.arin.net. | mail addr = bind.arin.net. | serial = 2002041212 | refresh = 10800 | retry = 3600 | expire = 1209600 | minimum = 10800 | | > 0.f.4.0.1.0.0.2.ip6.arpa | Server: arrowroot.arin.net | Address: 198.133.199.110#53 | | ** server can't find 0.f.4.0.1.0.0.2.ip6.arpa.: NXDOMAIN | | | Isn't THAT special. It doesn't look like the ip6.arpa zone has been | updated at ARIN since April 12, 2002. | | | [whois.arin.net] | EnterZone, Inc (ENTERZONE-V6) | 6227 Headley Road | Gahanna, OH 43230 | US | | Netname: ENTERZONE-V6 | Netnumber: 2001:04F0:0000:0000:0000:0000:0000:0000/35 | | Maintainer: V6ZN | | Coordinator: | Fraizer, John (JF1998-ARIN) John.Fraizer@ENTERZONE.NET | +1 614 554-4356 | | Domain System inverse mapping provided by: | NS1.ENTERZONE.NET | NS2.ENTERZONE.NET | | Record last updated on 18-Jul-2002. | | It would be nice if the ip6.arpa records were REALLY delegated to my | nameservers. | | | --- | John Fraizer | High-Security Datacenter Services | | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | | | | _______________________________________________ | 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 fink@es.net Thu Jul 25 06:50:04 2002 From: fink@es.net (Bob Fink) Date: Wed, 24 Jul 2002 22:50:04 -0700 Subject: [6bone] pTLA for Teredo testing - review closes 7 August 2002 Message-ID: <5.1.0.14.0.20020724222842.025c9768@imap2.es.net> 6bone Folk, Christian Huitema has requested a pTLA allocation for Teredo ("Tunneling IPv6 over UDP through NATs") service. I believe this request should be reviewed and discussed for approval. The open review period for this will close 7 August 2002. Please send your comments to me or the list. Note that Teredo was previously called SHIPWORM so is under that name in the I-D directory Thanks, Bob === >Subject: Prefix for Teredo >Date: Tue, 23 Jul 2002 18:04:11 -0700 >From: "Christian Huitema" >To: "Bob Fink" > >Bob, > >I am currently rewriting the Teredo draft to make it more IESG-friendly. >To experiment with the new design, we will need a "reasonable" IPv6 >prefix. In the original draft, I requested a /16, but that is perhaps >not realistic; in practice, I believe I could do with a /32. Is it >possible to get an experimental /32 prefix from the 6BONE allocation? > >-- Christian Huitema From jeroen@unfix.org Thu Jul 25 12:17:28 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 25 Jul 2002 13:17:28 +0200 Subject: [6bone] Summer cleanup time for IPv6 aggregation! Message-ID: <001401c233cc$de39cc70$534510ac@cyan> Boo, Okay, let's take a looky at this nice long filthy list of today (07/24/02 6Bone Routing Report). I cut out: - Prefixes from Different Origin AS - Unknown AS Numbers (not in 6bone registry) - The Top Five Most Active Prefixes (more than 1000 changes) Those shouldn't happen either, but the below stuff is something we shouldn't be seeing at all in the global routing tables. By the way AS45589 (which is part of 32768 - 64511) is reserved and it is causing a lot of crap. Watch the cutlines for comments. 'Big' spillers are cc'd. And avoid reading the sarcasm ;) 8<------------------- See http://www.merit.edu/ipma for a more detailed report on routing problems and recommendations on ways service providers can limit the spread of invalid routing information. Send comments and questions to ipma-support@merit.edu To unsubscribe from this list, send mail to 6bone-routing-report-request@merit.edu. A hypermail archive is available at http://www.merit.edu/mail.archives/html/6bone-routing-report/ Also see http://www.caida.org for more information about Internet statistics collection research efforts. --------------------------------------------- This report is for 07/24/02, peering with VIAGENIE (AS10566) UUNET-US (AS12199) CICNET (AS1225) (AS13676) UNAM (AS278) MIT-SIPB (AS3) ETRI (AS3748) CERNET (AS4538) SPRINT (AS6175) STEALTH (AS8002) INTEC (AS9612) --------------------------------------------- Size of 6Bone Routing Table: Max = 363, Min = 296, Average = 331 119 pTLAs (in 3ffe::/16), 134 sTLAs (in 2001::/16) 239 Unique Autonomous System (AS) numbers BGP4+ Traffic Summary: Announcements = 23443 Withdraws = 7524 Unique Routes = 403 Poorly Aggregated Announcements (>24 in 3ffe:0000::/18 or >28 in 3ffe:8000::/17 or >32 in 3ffe:4000::/18 or >35 in 2001::/16): Format: Prefix path AS-Path (Origin-AS -- Availability) asterisk(*) means the route is within its pTLA -------------------------------- VIAGENIE (AS10566) announced 26 route(s) 2001:6e0:20c:10::/128 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) 2001:6e0:0:10e::1/128 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) 2001:6e0:20c:10::b/128 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) 2001:6e0:20c:10::9/128 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) 2001:6e0:20c:10::7/128 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) 2001:6e0:20c:8::1/128 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) 2001:6e0:20c:10::4/128 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) 2001:6e0:20c:b::2/128 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) 2001:730:3::1:14/128 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) 3ffe:1300:4:1::/64 path 10566 6939 6347 (SAVVIS -- 52%) 3ffe:1300:4:3::/64 path 10566 6939 6347 (SAVVIS -- 52%) 3ffe:1300:4:4::/64 path 10566 6939 6347 (SAVVIS -- 52%) 3ffe:1200:3028:88a0::/64 path 10566 6939 3327 ( -- 51%) 3ffe:1300:4:2::/64 path 10566 6939 6347 (SAVVIS -- 52%) 2001:7f8:1::/64 path 10566 6939 3549 (GLOBALCENTER -- 52%) 2001:6e0:20c::/64 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) 2001:6e0:20c:1::/64 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) --------->8 Ehmm announcing and accepting /128's and /64's, how many entries do we want to have in the global routing table? Viagenie shouldn't accept these foreigns at all, private peering okay, but don't even try to announce it to the rest of the world. ipv6-site: NORTEL origin: AS762 descr: Nortel Networks, Billerica, MA country: US prefix: 3FFE:1300::/24 Cuddo's 2001:7f8:1::/64, the AMSiX IPv6 range in the US ;) ipv6-site: CHELLO origin: AS6830 descr: Chello Broadband country: NL prefix: 2001:730::/35 And those 2001:6e0::/32's should have been filtered too... 8<--------- * 3ffe:b00:4054::/48 path 10566 3758 (SINGNET -- 52%) 2001:6e0:20c::/48 path 10566 12523 (BUGFR/DELTA6-FR/DWAR/EUREDIT-FR -- 0%) 3ffe:3700:1f00::/48 path 10566 6939 209 (R0XX/R0XX-2 -- 52%) 3ffe:81d0:104::/48 path 10566 6939 4181 ( -- 52%) 3ffe:8070:1015::/48 path 10566 6939 11237 (EAFIT -- 52%) 3ffe:1300:4::/48 path 10566 6939 6347 (SAVVIS -- 52%) 2001:2b8:80::/41 path 10566 3786 17832 ( -- 52%) 2001:410:400::/40 path 10566 6939 818 ( -- 52%) 3ffe:2c03::/32 path 10566 2012 (ELTE-INF/MADNET/RIEB/PSZFB-NET/KOMJATA-KOLL/NEXCOM/DUNE/JGYTF/T-NET/STA JI/PR -- 52%) --------->8 That last /32 is a delegation from BT-LABS: inet6num: 3FFE:2C00::/24 netname: BT-LABS descr: pTLA delegation for the 6bone But that doesn't mean those /32's should appear. 8<--------- UUNET-US (AS12199) announced 20 route(s) 3ffe:28ff:ffff:4::103/127 path 12199 (UUNET-US -- 100%) 3ffe:28ff:ffff:4::100/127 path 12199 (UUNET-US -- 100%) * 3ffe:8090:7f00:1::1:0/112 path 12199 (UUNET-US -- 100%) * 3ffe:8090:7f00:1::2:0/112 path 12199 (UUNET-US -- 100%) 3ffe:3800::11:0/112 path 12199 (UUNET-US -- 100%) 3ffe:3800::13:0/112 path 12199 (UUNET-US -- 100%) * 3ffe:8090:4800:cfff::b:0/112 path 12199 (UUNET-US -- 100%) * 3ffe:8090:4800:4fff::2:0/112 path 12199 (UUNET-US -- 100%) * 3ffe:8090:48fc:10::1:0/112 path 12199 (UUNET-US -- 100%) 3ffe:3800::10:0/112 path 12199 (UUNET-US -- 100%) * 3ffe:8090:4800:cfff::9:0/112 path 12199 (UUNET-US -- 100%) 3ffe:3800::12:0/112 path 12199 (UUNET-US -- 100%) * 3ffe:8090:4800:cfff::7:0/112 path 12199 (UUNET-US -- 96%) * 3ffe:8090:4800:cfff::3:0/112 path 12199 (UUNET-US -- 100%) * 3ffe:8090:4800:cfff::1:0/112 path 12199 (UUNET-US -- 100%) * 3ffe:8090:4800:c005::/64 path 12199 (UUNET-US -- 100%) * 3ffe:8090:4800:4e20::/64 path 12199 (UUNET-US -- 100%) * 3ffe:8090:4800:c000::/64 path 12199 (UUNET-US -- 100%) * 3ffe:8090:4800:ce50::/60 path 12199 (UUNET-US -- 100%) * 3ffe:8090:4800:ce10::/60 path 12199 (UUNET-US -- 100%) --------->8 inet6num: 3FFE:8090::/28 netname: UUNET-US descr: pTLA delegation for the 6bone I wonder why UUNET gives out these more specifics to their peers, one word "aggregate". inet6num: 3FFE:3800::/24 netname: FIBERTEL descr: pTLA delegation for the 6bone inet6num: 3FFE:2800::/24 netname: VBNS descr: pTLA delegation for the 6bone 8<--------- CHELLO (AS6830) announced 16 route(s) 3ffe:2501:100::/48 path 10566 6939 6830 8733 (TVD -- 52%) 3ffe:8070:1010::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) 3ffe:8070:1010::/48 path 10566 6939 6830 (CHELLO -- 52%) 3ffe:2900:2004::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) 3ffe:2900:2004::/48 path 10566 6939 6830 (CHELLO -- 52%) 3ffe:1300:7::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) 3ffe:1300:7::/48 path 10566 6939 6830 (CHELLO -- 52%) 3ffe:327e:1::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) 3ffe:327e:1::/48 path 10566 6939 6830 (CHELLO -- 52%) 3ffe:4005:a::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) 3ffe:4005:a::/48 path 10566 6939 6830 (CHELLO -- 52%) 3ffe:80ee:556::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) 3ffe:80ee:556::/48 path 10566 6939 6830 (CHELLO -- 52%) 3ffe:200:c::/48 path 10566 6939 6830 2847 ( -- 52%) 3ffe:80b0:1002::/48 path 10566 6939 6830 8733 (TVD -- 52%) 2001:6e0:202::/48 path 12199 145 11537 786 109 5539 1853 6830 8209 ( -- 4%) 3ffe:400b:6002::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) 3ffe:400b:6002::/48 path 10566 6939 6830 (CHELLO -- 100%) 3ffe:81a0:1012::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) 3ffe:81a0:1012::/48 path 10566 6939 6830 (CHELLO -- 52%) 3ffe:2500:322::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) 3ffe:2500:322::/48 path 10566 6939 6830 (CHELLO -- 52%) 3ffe:8271:a080::/44 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) 3ffe:8271:a080::/44 path 10566 6939 6830 (CHELLO -- 52%) 3ffe:82bf::/32 path 10566 6939 6830 24643 (NEXTGEN-LAB -- 52%) 3ffe:2640::/32 path 10566 6939 6830 790 6793 (TELIAFI -- 51%) --------->8 And even more /48's, /44's and /32's and even double entries, great to spread those. inet6num: 3FFE:82B0::/28 netname: WEBONLINE-NET descr: WebOnline AS Keep those peerings private... 8<--------- IPV6-BITS-IN (AS4755) announced 8 route(s) * 3ffe:81e0:2:ffff::/128 path 10566 4755 (IPV6-BITS-IN -- 52%) * 2001:208:1:fd03::/80 path 10566 4755 (IPV6-BITS-IN -- 52%) * 3ffe:81e0::/64 path 10566 4755 (IPV6-BITS-IN -- 52%) * 3ffe:2e01:60::/64 path 10566 4755 (IPV6-BITS-IN -- 52%) * 3ffe:b00:4002::/64 path 10566 4755 (IPV6-BITS-IN -- 50%) * 2001:208:1:fd03::/64 path 10566 4755 (IPV6-BITS-IN -- 52%) * 3ffe:2e01:60::/48 path 10566 4755 (IPV6-BITS-IN -- 52%) * 3ffe:b00:4002::/48 path 10566 4755 (IPV6-BITS-IN -- 52%) --------->8 3ffe:81e0:2:ffff::/128 yeah I really would like to know globally where that tunnel endpoint goes ;) 3ffe:b00:4002::/64 "My office network is over here"... 8<--------- SMS (AS3274) announced 7 route(s) 2001:6c0:1fff:ffd0::/60 path 10566 6939 3274 2586 3249 ( -- 52%) 2001:6c0:2::/48 path 10566 6939 3274 2586 3249 ( -- 52%) 2001:670:8b::/48 path 10566 6939 3274 2586 3327 ( -- 52%) 3ffe:200:3a::/48 path 10566 6939 3274 2586 (UNINET -- 52%) 3ffe:200:48::/48 path 10566 6939 3274 2586 3327 ( -- 52%) 3ffe:200:25::/48 path 10566 6939 3274 2586 3221 (UT -- 52%) 2001:618:800::/42 path 10566 6939 3274 719 ( -- 52%) ABILENE (AS11537) announced 6 route(s) 2001:468:1f02::/48 path 12199 145 11537 6356 (UFL -- 4%) 2001:468:1f04::/48 path 12199 145 11537 6366 ( -- 4%) 2001:468:1f05::/48 path 12199 145 11537 7450 ( -- 4%) 2001:468:1f06::/48 path 12199 145 11537 11956 ( -- 4%) 2001:468:1300::/40 path 12199 145 11537 5786 ( -- 4%) 3ffe:2807::/32 path 10566 22 11537 195 (SDSCNET -- 52%) ---------->8 ABILENE-IPV6 2001:0468:0000:0000:0000:0000:0000:0000/35 Record last updated on 12-Mar-2001. Quite old, shouldn't those be /32's yet ? inet6num: 3FFE:2800::/24 netname: VBNS descr: pTLA delegation for the 6bone 8<-------- CERNET (AS4538) announced 4 route(s) 3ffe:c00:8023:4a::/64 path 12199 145 11537 786 5623 6939 4538 65272 (TELEPONT -- 4%) 3ffe:80b0:100::/48 path 4538 13226 (STBEN-BE -- 99%) 3ffe:2b00:1003::/48 path 4538 15180 (DIVEO-BR -- 100%) 3ffe:1200:3028::/48 path 4538 6939 (LJOSA/HURRICANE -- 99%) CISCO (AS109) announced 4 route(s) 2001:630:80::/48 path 10566 6939 109 3185 (ULANC -- 52%) 3ffe:200:77::/48 path 10566 6939 109 5550 ( -- 52%) 3ffe:8271:a100::/44 path 10566 6939 109 5550 ( -- 52%) 2001:420::/40 path 10566 6939 109 (CISCO -- 52%) ------>8 Even cisco :( 8<----- ATT-LABS-EUROPE (AS5623) announced 3 route(s) 2001:410:600::/40 path 12199 145 11537 786 5623 6939 818 6509 549 (SNO/SIDESHOW -- 4%) 3ffe:b00:2000::/40 path 12199 145 11537 786 5623 6939 818 ( -- 4%) 2001:410:200::/40 path 12199 145 11537 786 5623 6939 818 6509 8111 ( -- 4%) XS4ALL-NL (AS3265) announced 3 route(s) 3ffe:8271::/32 path 12199 145 11537 1103 3265 (XS4ALL-NL -- 61%) 3ffe:2c01::/32 path 12199 145 11537 1103 3265 (XS4ALL-NL -- 61%) 3ffe:81f1::/32 path 12199 145 11537 1103 3265 (XS4ALL-NL -- 61%) BELNET-BE (AS2611) announced 3 route(s) * 3ffe:80b0:1001::/48 path 10566 6939 6830 8733 2611 6774 (BELBONE-BE -- 52%) * 3ffe:608:2::/48 path 10566 6939 6830 8733 2611 (BELNET-BE -- 52%) * 2001:6a8:802::/48 path 10566 9044 5539 3561 5511 2611 (BELNET-BE -- 52%) VERAT (AS15982) announced 3 route(s) 3ffe:400:10e0::/48 path 12199 145 11537 786 109 15982 (VERAT -- 4%) * 3ffe:80a0:1005::/48 path 12199 145 11537 786 109 15982 (VERAT -- 4%) * 3ffe:8271:a090::/44 path 12199 145 11537 786 109 15982 (VERAT -- 4%) SPACENET-DE (AS5539) announced 2 route(s) 2001:650:10::/48 path 10566 9044 5539 3561 15709 ( -- 52%) 3ffe:8034::/34 path 10566 9044 5539 1853 (COSY -- 52%) UDG (AS2549) announced 2 route(s) * 3ffe:82f0:ffff::/126 path 10566 5408 2549 (UDG -- 52%) 3ffe:8240:8012::/48 path 10566 6939 2549 (UDG -- 52%) SPRINT (AS6175) announced 2 route(s) * 3ffe:290a::/32 path 12199 145 4554 6939 3265 15897 6175 (SPRINT -- 19%) * 3ffe:29a2::/32 path 12199 145 4554 6939 3265 15897 6175 11261 (ASCI -- 19%) NOKIA (AS14277) announced 2 route(s) 3ffe:a00:13::/48 path 10566 6939 14277 14609 ( -- 52%) 2001:670:8c::/48 path 10566 6939 14277 286 ( -- 52%) INR (AS2895) announced 2 route(s) * 3ffe:2406::/32 path 10566 22 109 2895 20515 ( -- 0%) * 3ffe:240b::/32 path 10566 22 109 2895 13032 (KUN-6 -- 0%) ------->8 inet6num: 3FFE:2400::/24 netname: INR descr: pTLA delegation for the 6bone descr: Institute for Nuclear Resarch Moscow, Russia The word in the topic: aggregate. Btw 'research'... and no you can't have my LOC coordinates ;) 8<------- INET-TH (AS4618) announced 2 route(s) 3ffe:b00:4056::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) 3ffe:b00:4050::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) INTEC (AS9612) announced 1 route(s) 2001:200:500::/40 path 10566 6939 3549 9612 (INTEC -- 52%) UUNET-NL (AS1890) announced 1 route(s) 2001:600:8::/48 path 4538 1890 (UUNET-NL -- 100%) UNI-C (AS1835) announced 1 route(s) 2001:6b0:8::/48 path 12199 145 11537 1103 6680 2603 1835 (UNI-C -- 4%) BT-LABS (AS1752) announced 1 route(s) 2001:7f8:2::/48 path 10566 6939 1752 (BT-LABS -- 52%) FUNET (AS1741) announced 1 route(s) 3ffe:2620::/32 path 10566 6939 6830 790 1741 (FUNET -- 51%) JOIN (AS1275) announced 1 route(s) 3ffe:2100:1:17::/64 path 4538 1275 (JOIN -- 97%) SWITCH (AS559) announced 1 route(s) * 2001:620:204::/48 path 10566 9044 5539 3561 5511 2611 559 (SWITCH -- 52%) REDIRIS (AS766) announced 1 route(s) 2001:7e0:c02::/48 path 10566 9044 5539 1853 6680 1103 766 12359 (INTELIDEAS -- 52%) ENTERZONE (AS13944) announced 1 route(s) * 3ffe:1ced::/32 path 10566 6939 13944 (ENTERZONE -- 46%) 8<----- We know the reason of this one ;) ----->8 SURFNET (AS1103) announced 1 route(s) 2001:6b0:4::/48 path 12199 145 11537 1103 6680 2603 (NORDUNET -- 4%) ASNET (AS9264) announced 1 route(s) 2001:288:3b0::/44 path 10566 6939 3549 9264 (ASNET -- 52%) UNAM (AS278) announced 1 route(s) * 2001:448:3::/48 path 278 18592 (CUDI -- 28%) EURNETCITY (AS20794) announced 1 route(s) 3ffe:b80:731::/48 path 10566 6939 6830 20794 (EURNETCITY -- 44%) CERN (AS513) announced 1 route(s) 2001:620:61c::/48 path 12199 145 11537 1103 6680 559 513 (CERN -- 4%) DOLPHINS-CH (AS8758) announced 1 route(s) * 3ffe:8150:2001::/48 path 10566 9044 8758 (DOLPHINS-CH -- 52%) MERIT (AS237) announced 1 route(s) 2001:468:1400::/40 path 12199 145 11537 237 (MERIT -- 4%) --------->8 As you can see many un-aggregated prefixes, for things like /128, /64 and /48 there is really no excuse for seeing them in the global routing table at some points in this world. Let the summer cleanup begin. Greets, Jeroen From narten@us.ibm.com Thu Jul 25 14:30:53 2002 From: narten@us.ibm.com (Thomas Narten) Date: Thu, 25 Jul 2002 09:30:53 -0400 Subject: [6bone] pTLA for Teredo testing - review closes 7 August 2002 In-Reply-To: Message from "Wed, 24 Jul 2002 22:50:04 PDT." <5.1.0.14.0.20020724222842.025c9768@imap2.es.net> Message-ID: <200207251330.g6PDUrO13111@rotala.raleigh.ibm.com> > Christian Huitema has requested a pTLA allocation for Teredo ("Tunneling > IPv6 over UDP through NATs") service. I believe this request should be > reviewed and discussed for approval. I'd like to better understand: - what is being requested exactly. Will any prefix of length /32 or shorter work? (this is a purely technical question) - What will this allocation be used for? experimentation and testing? Note that 6bone addresses are intended for experimentation, and must be returned at some point in the future. Thus, if this allocation will in practice be used in some sort of permanent sense (e.g., hardcoded in to-be-shipped products), using a pTLA seems inappropriate. Thomas From galania@ipv6.inictel.gob.pe Thu Jul 25 14:53:01 2002 From: galania@ipv6.inictel.gob.pe (Gino Francisco Alania Hurtado) Date: Thu, 25 Jul 2002 08:53:01 -0500 Subject: [6bone] ip6.int or ip6.arpa or BOTH? References: Message-ID: <3D4002BD.7000708@ipv6.inictel.gob.pe> The rule podria to be segun your version DNS that you use, I use bind 9,2 and this she is for the inverse one: zone "xxx.xxx.xxx.in-addr.arpa" { type master; file "xxx.xxx.xxx.in-addr.arpa.zone"; John Fraizer wrote: >For reverse records, which zones should I be creating? ip6.arpa or >ip6.int? Traces from some places show our reverse and some do not. I >have some machines (all using the same DNS servers) that show our reverse >on our nets and some that do not. The machines that don't show ours WILL >show *some* other networks reverses for ipv6 addresses. > >So, can someone tell me how I should be set up? I currently have ip6.int >zones. > > >--- >John Fraizer | High-Security Datacenter Services | >EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | >http://www.enterzone.net/ | Virtual, Dedicated, Colocation | > > >_______________________________________________ >6bone mailing list >6bone@mailman.isi.edu >http://mailman.isi.edu/mailman/listinfo/6bone > From fink@es.net Thu Jul 25 15:23:05 2002 From: fink@es.net (Bob Fink) Date: Thu, 25 Jul 2002 07:23:05 -0700 Subject: [6bone] pTLA for Teredo testing - review closes 7 August 2002 In-Reply-To: <200207251330.g6PDUrO13111@rotala.raleigh.ibm.com> References: Message-ID: <5.1.0.14.0.20020725070943.021999d8@imap2.es.net> Thomas, At 09:30 AM 7/25/2002 -0400, Thomas Narten wrote: > > Christian Huitema has requested a pTLA allocation for Teredo ("Tunneling > > IPv6 over UDP through NATs") service. I believe this request should be > > reviewed and discussed for approval. > >I'd like to better understand: > >- what is being requested exactly. Will any prefix of length /32 or > shorter work? (this is a purely technical question) > >- What will this allocation be used for? experimentation and testing? > Note that 6bone addresses are intended for experimentation, and must > be returned at some point in the future. Thus, if this allocation > will in practice be used in some sort of permanent sense (e.g., > hardcoded in to-be-shipped products), using a pTLA seems > inappropriate. In the pTLA review announcement the requesting email from Christian (see below) was included. It states an experimental /32. I do not know if it will be hardcoded. I believe that Teredo, as a transition mechanism candidate for standards track, is a good candidate for a 6bone prefix for testing/experimentation. I also believe that, like all other 3FFE::/16 address space users, it must be prepared to stop using this address space when the community decides to terminate 3FFE::/16 usage in general. Bob === >Subject: Prefix for Teredo >Date: Tue, 23 Jul 2002 18:04:11 -0700 >From: "Christian Huitema" >To: "Bob Fink" > >Bob, > >I am currently rewriting the Teredo draft to make it more IESG-friendly. >To experiment with the new design, we will need a "reasonable" IPv6 >prefix. In the original draft, I requested a /16, but that is perhaps >not realistic; in practice, I believe I could do with a /32. Is it >possible to get an experimental /32 prefix from the 6BONE allocation? -end From narten@us.ibm.com Thu Jul 25 15:41:11 2002 From: narten@us.ibm.com (Thomas Narten) Date: Thu, 25 Jul 2002 10:41:11 -0400 Subject: [6bone] pTLA for Teredo testing - review closes 7 August 2002 In-Reply-To: Message from "Thu, 25 Jul 2002 07:23:05 PDT." <5.1.0.14.0.20020725070943.021999d8@imap2.es.net> Message-ID: <200207251441.g6PEfB413698@rotala.raleigh.ibm.com> > In the pTLA review announcement the requesting email from Christian (see > below) was included. It states an experimental /32. Oops, I didn't see that part of the mail. Thanks. > I believe that Teredo, as a transition mechanism candidate for standards > track, is a good candidate for a 6bone prefix for testing/experimentation. > I also believe that, like all other 3FFE::/16 address space users, it must > be prepared to stop using this address space when the community decides to > terminate 3FFE::/16 usage in general. This seems like a different kind of experiment then just providing basic IPv6 connectivity (which is what pTLAs are normally assigned for). Thus, it would be good to understand how/when *this* particular experiment ends, as opposed to just the generic "it must end when all of the 3FEE::/16 experimentation ends. Thomas From michel@arneill-py.sacramento.ca.us Thu Jul 25 16:17:36 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 25 Jul 2002 08:17:36 -0700 Subject: [6bone] pTLA for Teredo testing - review closes 7 August 2002 Message-ID: <2B81403386729140A3A899A8B39B046405E20B@server2000.arneill-py.sacramento.ca.us> 6boner, > Bob Fink wrote: > Christian Huitema has requested a pTLA allocation for > Teredo ("Tunneling IPv6 over UDP through NATs") service. > I believe this request should be reviewed and discussed > for approval. I am favorable to allocating a 6bone /32 for Teredo testing. > Thomas Narten wrote: > This seems like a different kind of experiment then just > providing basic IPv6 connectivity (which is what pTLAs are > normally assigned for). Thus, it would be good to understand > how/when *this* particular experiment ends, as opposed to > just the generic "it must end when all of the 3FEE::/16 > experimentation ends. I also agree with Thomas. As a matter of fact, I think that "special purpose" (read, not pTLAs in the conventional use) 6bone assignments should be renewed regularly. I will be requesting a 6bone testing block soon myself, my idea was a block renewed every year or every other year. The sunset of an experiment should be either when there has been enough experience acquired through the 6bone to request a block from IANA, or when the experiment has stopped. Michel. From tvo@ENTERZONE.NET Thu Jul 25 16:57:25 2002 From: tvo@ENTERZONE.NET (John Fraizer) Date: Thu, 25 Jul 2002 11:57:25 -0400 (EDT) Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: <3D4002BD.7000708@ipv6.inictel.gob.pe> Message-ID: On Thu, 25 Jul 2002, Gino Francisco Alania Hurtado wrote: > The rule podria to be segun your version DNS that you use, I use bind > 9,2 and this she is for the inverse one: > > zone "xxx.xxx.xxx.in-addr.arpa" { > type master; > file "xxx.xxx.xxx.in-addr.arpa.zone"; > > That sure looks like an IPv4 in-addr.arpa zone to me. I think we're going to wind up with something like this: zone "0.f.4.0.1.0.0.2.ip6.int" { type master; file "ipv6/0.f.4.0.1.0.0.2.ip6.int"; }; zone "0.f.4.0.1.0.0.2.ip6.arpa" { type master; file "ipv6/0.f.4.0.1.0.0.2.ip6.arpa"; }; I'm just wondering folks. Since we have perfectly good ip6.int, why do we even WANT/NEED ip6.arpa? Also, I didn't quite follow Kims example but, does anyone have a tool that can be used to generate one zone type from another? Note: I ALSO use $ORIGIN lines in my zone files. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From bmanning@ISI.EDU Thu Jul 25 17:02:21 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 25 Jul 2002 09:02:21 -0700 (PDT) Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: from John Fraizer at "Jul 25, 2 11:57:25 am" Message-ID: <200207251602.g6PG2LA07428@boreas.isi.edu> % I'm just wondering folks. Since we have perfectly good ip6.int, why do we % even WANT/NEED ip6.arpa? It was a strictly political play that did not need to happen. --bill From richardj@arin.net Thu Jul 25 17:19:20 2002 From: richardj@arin.net (Richard Jimmerson) Date: Thu, 25 Jul 2002 12:19:20 -0400 Subject: [6bone] Reverse Delegations for ARIN IPv6 Registrations Message-ID: <00d101c233f7$07f0de80$ebfc95c0@cobalt> When ARIN begin allocating IPv6 address space in 1999, reverse delegations were being made under the ip6.int domain. Since that time, the ip6.arpa domain was established, and ARIN began the process of transitioning reverse DNS for IPv6 address space from the ip6.int to ip6.arpa on a request basis. In December 2001, existing registrants were contacted about this matter, and several delegations were added to ARIN's ip6.arpa sub-domain. At that time, we decided against replicating all the ip6.int delegations in ip6.arpa as default behavior to prevent lame delegations. Sufficient time has passed to allow registrants the opportunity to make this transition. There has also been some confusion about when delegations are made in ip6.arpa as opposed to ip6.int. Therefore, beginning today, ARIN will begin making the appropriate delegations for its IPv6 address space registrations in both domains. We hope this clarifies the situation, and we would be happy to address any concerns this might raise. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) From todd@FRIES.NET Thu Jul 25 17:30:42 2002 From: todd@FRIES.NET (Todd T. Fries) Date: Thu, 25 Jul 2002 11:30:42 -0500 Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: References: <3D4002BD.7000708@ipv6.inictel.gob.pe> Message-ID: <20020725163042.GA31310@fries.net> You want ip6.arpa because at some point in the future ip6.int is going away and ip6.arpa will be active (in reverse order, though). Something very basic like: sed 's/ip6.int/ip6.arpa/g' zone.ip6.int > zone.ip6.arpa Should work fine. Probably not for everyone, but here is my solution: http://todd.fries.net/dns/fries/ Files of interest: Makefile (generate output, verify, update) *.m4 (m4 source files) ip6.inc.m4 (contains my reverse subnets and EUID's) 3ffe:b00:4004.arpa.m4 (ip6.arpa specifics) 3ffe:b00:4004.int.m4 (ip6.int specifics) General concept: I use m4 to expand the addresses of all my euid's across all my subnets when generating both ip6.int and ip6.arpa zones. (yes, it generates not small zones, but I got tired of laptops and other devices that shift subnets having to update dns for each shift). I know that freenet6 (aka viagenie) where I have my tunnel does not delegate ip6.arpa yet, but I am ready for when they do! Most likely some of you will not be happy with my choice to do this: todd:27$ host 3ffe:b00:4004::1 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.4.0.0.b.0.e.f.f.3.ip6.int is an alias for 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.4.0.0.b.0.e.f.f.3.pt.fries.net. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.4.0.0.b.0.e.f.f.3.pt.fries.net domain name pointer shadow.fries.net. todd:28$ But it ends up allowing forward and reverse in the same zone, which I like for my own reasons (forced consistency among them). -- Todd Fries .. todd@fries.net (last updated $ToddFries: signature.p,v 1.2 2002/03/19 15:10:18 todd Exp $) Penned by John Fraizer on Thu, Jul 25, 2002 at 11:57:25AM -0400, we have: | | | On Thu, 25 Jul 2002, Gino Francisco Alania Hurtado wrote: | | > The rule podria to be segun your version DNS that you use, I use bind | > 9,2 and this she is for the inverse one: | > | > zone "xxx.xxx.xxx.in-addr.arpa" { | > type master; | > file "xxx.xxx.xxx.in-addr.arpa.zone"; | > | > | | That sure looks like an IPv4 in-addr.arpa zone to me. | | I think we're going to wind up with something like this: | | zone "0.f.4.0.1.0.0.2.ip6.int" { | type master; | file "ipv6/0.f.4.0.1.0.0.2.ip6.int"; | }; | | zone "0.f.4.0.1.0.0.2.ip6.arpa" { | type master; | file "ipv6/0.f.4.0.1.0.0.2.ip6.arpa"; | }; | | | | I'm just wondering folks. Since we have perfectly good ip6.int, why do we | even WANT/NEED ip6.arpa? | | Also, I didn't quite follow Kims example but, does anyone have a tool that | can be used to generate one zone type from another? Note: I ALSO use | $ORIGIN lines in my zone files. | | | | --- | John Fraizer | High-Security Datacenter Services | | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | | | | _______________________________________________ | 6bone mailing list | 6bone@mailman.isi.edu | http://mailman.isi.edu/mailman/listinfo/6bone From kim@tac.nyc.ny.us Thu Jul 25 17:44:11 2002 From: kim@tac.nyc.ny.us (Kimmo Suominen) Date: Thu, 25 Jul 2002 12:44:11 -0400 Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: from John Fraizer on Thu, 25 Jul 2002 11:57:25 -0400 References: Message-ID: <20020725164412.11CA87E04@beowulf.gw.com> The example just runs sed on the files, storing the results in a separate file. It looks a bit complex because I was using BSD-make to derive the name of the generated (sed output) file from the original (replacing all colons with underscores). Basically I just do sed -e 's/\.ip6\.arpa/.ip6.int/g' x.x.x.ip6.arpa > x.x.x.ip6.int for each x.x.x that I have. Regards, + Kim | From: John Fraizer | Date: Thu, 25 Jul 2002 11:57:25 -0400 | | | | On Thu, 25 Jul 2002, Gino Francisco Alania Hurtado wrote: | | > The rule podria to be segun your version DNS that you use, I use bind | > 9,2 and this she is for the inverse one: | > | > zone "xxx.xxx.xxx.in-addr.arpa" { | > type master; | > file "xxx.xxx.xxx.in-addr.arpa.zone"; | > | > | | That sure looks like an IPv4 in-addr.arpa zone to me. | | I think we're going to wind up with something like this: | | zone "0.f.4.0.1.0.0.2.ip6.int" { | type master; | file "ipv6/0.f.4.0.1.0.0.2.ip6.int"; | }; | | zone "0.f.4.0.1.0.0.2.ip6.arpa" { | type master; | file "ipv6/0.f.4.0.1.0.0.2.ip6.arpa"; | }; | | | | I'm just wondering folks. Since we have perfectly good ip6.int, why do we | even WANT/NEED ip6.arpa? | | Also, I didn't quite follow Kims example but, does anyone have a tool that | can be used to generate one zone type from another? Note: I ALSO use | $ORIGIN lines in my zone files. | | | | --- | John Fraizer | High-Security Datacenter Services | | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | | | | _______________________________________________ | 6bone mailing list | 6bone@mailman.isi.edu | http://mailman.isi.edu/mailman/listinfo/6bone | From narten@us.ibm.com Thu Jul 25 18:03:05 2002 From: narten@us.ibm.com (Thomas Narten) Date: Thu, 25 Jul 2002 13:03:05 -0400 Subject: [6bone] pTLA for Teredo testing - review closes 7 August 2002 In-Reply-To: Message from "Thu, 25 Jul 2002 09:16:01 PDT." Message-ID: <200207251703.g6PH35Z01624@rotala.raleigh.ibm.com> Hi Christian. > We would like to start by experimentation, as in beta software, and I > would rather not use an illegal prefix. Obviously, hardcoding is always > a bad idea. In fact, using a "perishable" prefix would fit the bill for > Teredo, which is expected to be a perishable short term fix. I don't quite follow what you are saying. Are you expecting Teredo to be perishable in the sense that after a fixed amount of time (say 1 year), it will no longer be needed and the allocation can be returned? Or is this a more open-ended "when IPv6 is widely deployed, teredo won't be needed anymore because everyone will be using native IPv6 techniques"? (which doesn't have a predictable end date.) I'd like to understand if there is a clear timetable for when the experiment ends and if there is a definitie way to end the experiment once it starts. Thomas From tvo@EnterZone.Net Thu Jul 25 18:04:47 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 25 Jul 2002 13:04:47 -0400 (EDT) Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: <20020725164412.11CA87E04@beowulf.gw.com> Message-ID: On Thu, 25 Jul 2002, Kimmo Suominen wrote: > The example just runs sed on the files, storing the results in a separate > file. It looks a bit complex because I was using BSD-make to derive the > name of the generated (sed output) file from the original (replacing all > colons with underscores). > > Basically I just do > > sed -e 's/\.ip6\.arpa/.ip6.int/g' x.x.x.ip6.arpa > x.x.x.ip6.int > > for each x.x.x that I have. > > Regards, > + Kim Cool beans. We're all set now with dual zones. Now we just wait for the ip6.arpa zone to update. I got a phone call from Richard Jimmerson @ ARIN this morning. I about fell out of my chair. He called to assure me that we would be added to the ip6.arpa and apologise for the confusion. I assured him that the v6 allocation has gone much smoother than our v4 stuff to date. Anyway, thanks for all of the help folks. I just want to make sure we're doing this right! --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From jeroen@unfix.org Thu Jul 25 18:10:06 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 25 Jul 2002 19:10:06 +0200 Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: Message-ID: <000801c233fe$209439d0$420d640a@unfix.org> John Fraizer wrote: > zone "0.f.4.0.1.0.0.2.ip6.int" { > type master; > file "ipv6/0.f.4.0.1.0.0.2.ip6.int"; > }; > > zone "0.f.4.0.1.0.0.2.ip6.arpa" { > type master; > file "ipv6/0.f.4.0.1.0.0.2.ip6.arpa"; > }; > Also, I didn't quite follow Kims example but, does anyone > have a tool that > can be used to generate one zone type from another? Note: I ALSO use $ORIGIN lines in my zone files. I played unfair and removed the ORIGIN's, then again I do reverses for myself per /64. One could consider using database generation ;) Easiest way out for everyone is prolly: cat ipv6/0.f.4.0.1.0.0.2.ip6.int | sed "s/ip6\.int/ip6\.arpa/g" And don't forget trailing dots ;) Greets, Jeroen From tony@lava.net Thu Jul 25 20:29:37 2002 From: tony@lava.net (Antonio Querubin) Date: Thu, 25 Jul 2002 09:29:37 -1000 (HST) Subject: [6bone] Reverse Delegations for ARIN IPv6 Registrations In-Reply-To: <00d101c233f7$07f0de80$ebfc95c0@cobalt> Message-ID: On Thu, 25 Jul 2002, Richard Jimmerson wrote: > Sufficient time has passed to allow registrants the opportunity > to make this transition. There has also been some confusion about > when delegations are made in ip6.arpa as opposed to ip6.int. > Therefore, beginning today, ARIN will begin making the appropriate > delegations for its IPv6 address space registrations in both > domains. > > We hope this clarifies the situation, and we would be happy to > address any concerns this might raise. This applies only to 2001 prefixes assigned from ARIN but not 6bone (3ffe) space? From richardj@arin.net Thu Jul 25 22:08:35 2002 From: richardj@arin.net (Richard Jimmerson) Date: Thu, 25 Jul 2002 17:08:35 -0400 Subject: [6bone] Reverse Delegations for ARIN IPv6 Registrations In-Reply-To: Message-ID: <000401c2341f$70aad6b0$ebfc95c0@cobalt> Hello Antonio, > > Therefore, beginning today, ARIN will begin making the appropriate > > delegations for its IPv6 address space registrations in both > > domains. > This applies only to 2001 prefixes assigned from ARIN but not > 6bone (3ffe) space? Yes. The message below only applies to 2001 prefixes assigned by ARIN. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: Antonio Querubin [mailto:tony@lava.net] > Sent: Thursday, July 25, 2002 3:30 PM > To: Richard Jimmerson > Cc: 6bone@mailman.isi.edu > Subject: Re: [6bone] Reverse Delegations for ARIN IPv6 Registrations > > > On Thu, 25 Jul 2002, Richard Jimmerson wrote: > > > Sufficient time has passed to allow registrants the opportunity > > to make this transition. There has also been some confusion about > > when delegations are made in ip6.arpa as opposed to ip6.int. > > Therefore, beginning today, ARIN will begin making the appropriate > > delegations for its IPv6 address space registrations in both > > domains. > > > > We hope this clarifies the situation, and we would be happy to > > address any concerns this might raise. > > This applies only to 2001 prefixes assigned from ARIN but not > 6bone (3ffe) > space? > From fink@es.net Fri Jul 26 03:12:47 2002 From: fink@es.net (Bob Fink) Date: Thu, 25 Jul 2002 19:12:47 -0700 Subject: [6bone] Reverse Delegations for ARIN IPv6 Registrations In-Reply-To: <000401c2341f$70aad6b0$ebfc95c0@cobalt> References: Message-ID: <5.1.0.14.0.20020725190951.0220c480@imap2.es.net> At 05:08 PM 7/25/2002 -0400, Richard Jimmerson wrote: >Hello Antonio, > > > > Therefore, beginning today, ARIN will begin making the appropriate > > > delegations for its IPv6 address space registrations in both > > > domains. > > > This applies only to 2001 prefixes assigned from ARIN but not > > 6bone (3ffe) space? > >Yes. The message below only applies to 2001 prefixes assigned >by ARIN. There are also talks underway with the RIRs about bringing the 6bone registry into the RIR fold so to speak, one part of which would provide reverse registry for the 3FFE prefixes as well. I talked about this at the Yokohama IETF last week, but haven't had the time to circulate the draft to the list yet as I just got back from Japan. Stay tuned to the 6bone list. Bob From michel@arneill-py.sacramento.ca.us Fri Jul 26 05:57:57 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 25 Jul 2002 21:57:57 -0700 Subject: [6bone] Summer cleanup time for IPv6 aggregation! Message-ID: <2B81403386729140A3A899A8B39B046405E20E@server2000.arneill-py.sacramento.ca.us> > Jeroen Massar wrote: > Boo, Nice try, but I'm not scared. > Okay, let's take a looky at this nice long filthy list of > today (07/24/02 6Bone Routing Report). I just wanted to publicly state my support to Jeroen's efforts to keep our collective routing table clean. It does take some special individual to put his nose in the crap to figure out if it really stinks. And, at the risk of being percept as the one seeing the incarnation of evil all over the place again, I will take the opportunity to remind those of who that have reached a reasonable amount of maturity: - What we are seeing here are futile attempts to dissimulate the fact that we still don't have a multihoming solution for v6. As I mentioned many times before, each attempt to break PA aggregation diminishes the chances of a correct v6 mh solution. - We will not have the "clean start" IPv6 opportunity again for a long time (unless you believe in IPv8 ;-) Kudos to Jeroen. Michel. From pekkas@netcore.fi Fri Jul 26 06:22:40 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Fri, 26 Jul 2002 08:22:40 +0300 (EEST) Subject: [6bone] pTLA request UACH - review closes 7 August 2002 In-Reply-To: <5.1.0.14.0.20020724221208.025c37d8@imap2.es.net> Message-ID: Should uach.cl not inf.uach.cl be the "official" applier? The AS number of the applicant has been hijacked: Search results for: 45333 Internet Assigned Numbers Authority (ASN-IANA-RSVD-ASNBLOCK) Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6695 US Autonomous System Name: IANA-RSVD Autonomous System Block: 32768 - 64511 Coordinator: Internet Corporation for Assigned Names and Numbers (IANA-ARIN) res-ip@iana.org (310) 823-9358 Record last updated on 14-Oct-1999. Database last updated on 25-Jul-2002 20:00:35 EDT. On Wed, 24 Jul 2002, Bob Fink wrote: > 6bone Folk, > > UACH has requested a pTLA allocation and I find their request fully > compliant with RFC2772. The open review period for this will close 7 August > 2002. Please send your comments to me or the list. > > > > > > > Also note that UACH has permission to use REUNA's ASN (AS11340) for 6bone > pTLA purposes. > > > Thanks, > > Bob > > === > >From: "Christian Lazo R." > >To: > >Subject: request for pTLA > >Date: Mon, 24 Jun 2002 12:12:29 -0700 > > > >Hello, > > > >As a SPTLA, I'm very much interested to be a PTLA. > > > >Therefore I'm sending my application in the order that you require: > > > > 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: > > > > I have esperience from june 2001 > > > > > > 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: UACH > >origin: AS45333 > >descr: Universidad Austral de Chile > > Instituto de Informatica > >country: CL > >prefix: 3FFE:8070:100C::/48 > >application: ping routerv6.ipv6.cl > >tunnel: IPv6 in IPv4 routerv6.inf.uach.cl -> > >ipv6-gw.compendium.com.ar COMPENDIUM-AR BGP4+ > >tunnel: IPv6 in IPv4 routerv6.inf.uach.cl -> > >unam-ipv6-1.ipv6.unam.mx UNAM BGP4+ > >tunnel: IPv6 in IPv4 routerv6.inf.uach.cl -> gwipv6.ipv6.itesm.mx > >ITESM BGP4+ > >tunnel: IPv6 in IPv4 routerv6.inf.uach.cl -> gw6.nic.mx NIC-MX BGP4+ > >contact: CLR1-6BONE > >url: http://ipv6.inf.uach.cl/ > >notify: clazo@inf.uach.cl > >mnt-by: MNT-UACH > >changed: clazo@inf.uach.cl 20010626 > >changed: clazo@inf.uach.cl 20010629 > >changed: clazo@inf.uach.cl 20020618 > >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. > > > > > > > > > > > > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > > entries for the Applicant's router(s) and at least one host > > system. > > > >[clazo@antillanca clazo]$ dig www.ipv6.cl > > > >; <<>> DiG 8.2 <<>> www.ipv6.cl > >;; res options: init recurs defnam dnsrch > >;; got answer: > >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 > >;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4 > >;; QUERY SECTION: > >;; www.ipv6.cl, type = A, class = IN > > > >;; ANSWER SECTION: > >www.ipv6.cl. 14h41m4s IN A 146.83.248.3 > > > >;; AUTHORITY SECTION: > >ipv6.cl. 14h41m4s IN NS ns.ipv6.cl. > >ipv6.cl. 14h41m4s IN NS secundario.nic.cl. > > > >;; ADDITIONAL SECTION: > >ns.ipv6.cl. 10h51m50s IN A 146.83.248.2 > >ns.ipv6.cl. 14h23m6s IN AAAA 3ffe:8070:100c:2c01::a > >secundario.nic.cl. 11h7m54s IN A 216.72.164.136 > >secundario.nic.cl. 11h7m54s IN A 200.27.126.131 > > > >;; Total query time: 6 msec > >;; FROM: antillanca.inf.uach.cl to SERVER: default -- 146.83.216.201 > >;; WHEN: Mon Jun 17 21:25:35 2002 > >;; MSG SIZE sent: 29 rcvd: 174 > > > > > > 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. > > > >www.ipv6.cl > > > > > > > > 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. > > > > > > > > > > > > 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@inf.uach.cl > > > > > > 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. > > > >The potential group that we are available to give this service is the > >following: > > > >All the chilean universities counting with Internet and interested in > >working with ipv6. > > > >There are also some other big Chileans firms such as Internet Service > >Provider > > > >Nowadays, we are working with other Latin American universities in order > >to grow up the interest to use IPv6 > > > >As you can see, our purpose is to become the IPv6 in Chile. > > > > 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. > > > > 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>. > > > > > >greeting > > > >(sorry , but my Inglish is very bad) > > > >Christian > >________________ > >Christian Lazo R. > >Instituto de Informatica > >fono 56-63-221812 > >Fac Cs de la Ingenieria > >Universidad Austral de Chile > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > -- 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 jeroen@unfix.org Fri Jul 26 11:12:28 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Fri, 26 Jul 2002 12:12:28 +0200 Subject: [6bone] Summer cleanup time for IPv6 aggregation! In-Reply-To: <2B81403386729140A3A899A8B39B046405E20E@server2000.arneill-py.sacramento.ca.us> Message-ID: <001501c2348c$f26d2460$534510ac@cyan> Michel Py [mailto:michel@arneill-py.sacramento.ca.us] wrote: > > Jeroen Massar wrote: > > Boo, > > Nice try, but I'm not scared. Everybody is used to it I think ;) > > Okay, let's take a looky at this nice long filthy list of > > today (07/24/02 6Bone Routing Report). > - We will not have the "clean start" IPv6 opportunity again for a long > time (unless you believe in IPv8 ;-) Fortunatly everything is archived all over the world so that the people/companies doing the wrongs now will have to live with it forever when they don't clean it up and it all goes sour... http://www.merit.edu/mail.archives/html/6bone-routing-report/ And ofcourse Gert Doerings work: http://www.space.net/~gert/RIPE/ And as mentioned a couple of times already by various people: 3ffe::/18 ge 24 le 24 3ffe:4000::/18 ge 32 le 32 3ffe:8000::/20 ge 28 le 28 2000::/3 ge 16 le 16 2001::/16 ge 29 le 35 2002::/16 ge 16 le 48 or as seen on 6bone.net: 3ffe:0000::/24 thru 3ffe:3f00::/24 /24 3ffe:4000::/32 thru 3ffe:7fff::/32 /32 3ffe:8000::/24 thru 3ffe:83f0::/24 /28 3ffe:8400::/32 thru 3ffe:ffff::/32 can be filtered out completely as it will be unassigned for a long time to come. RIR space (2001::/16) will become /32 only in the long run. As for the "where does it really come from" question: http://dmoz.org/Computers/Internet/Protocols/IP/IPng/IPv6_Route_Views/ Lot's of viewpoints ;) Greets, Jeroen From rohan.pandit@wipro.com Fri Jul 26 14:26:37 2002 From: rohan.pandit@wipro.com (Rohan P Pandit) Date: Fri, 26 Jul 2002 18:56:37 +0530 Subject: [6bone] request to become an End-site ... Message-ID: <001601c234a8$11bec420$9f16a8c0@m2alc109156> This is a multi-part message in MIME format. ------=_NextPartTM-000-9770be65-cbd7-43eb-969d-df000684b931 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C234D6.2B770020" ------=_NextPart_000_0017_01C234D6.2B770020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hello all ... I am interested in becoming an end-site of the existing pTLAs. I have gone through the information on the 6bone.net site and contacted Viagenie. But did not receive any reply from them. I would like to know what I need to do from my side and may be what the pTLA will do for me so that i can get connection to 6bone. Please help ! thanx in advance. Regards, Rohan. ------=_NextPart_000_0017_01C234D6.2B770020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello all ...
 
I am=20 interested in becoming an end-site of the existing pTLAs. = I have gone=20 through
the=20 information on the 6bone.net site and contacted Viagenie. But=20 did not receive
any reply from them. I would like to=20 know what I need to do from my side and may
be=20 what the pTLA will do for me so that=20 i can get connection to 6bone.
 
Please help !
 
thanx in advance.
 
Regards,
Rohan.
------=_NextPart_000_0017_01C234D6.2B770020-- ------=_NextPartTM-000-9770be65-cbd7-43eb-969d-df000684b931 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" **************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. **************************************************************************************** ------=_NextPartTM-000-9770be65-cbd7-43eb-969d-df000684b931-- From rjorgensen@upctechnology.com Fri Jul 26 15:50:19 2002 From: rjorgensen@upctechnology.com (Roger Jorgensen) Date: Fri, 26 Jul 2002 16:50:19 +0200 Subject: [6bone] Summer cleanup time for IPv6 aggregation! In-Reply-To: <001401c233cc$de39cc70$534510ac@cyan> Message-ID: <5.1.0.14.0.20020726164611.0309d610@213.46.233.213> Someone out there has now recently opened up their filters and are passing on /48's and lots of other things. Check older stats and you'll see that much of this crap wasn't there before. My point of view on this can be put this way: 1) If you want to have strict aggregation (after the RFC) you filter incoming AND outgoing 2) If you want less strict aggregation it's okay to allow upto /48's both incoming and outgoing (I assume people do filter away not wanted announcment if they follow the RFC letter by letter) and incoming. Anything smaller than /48's are not accepted under any circumstances) At 01:17 PM 7/25/2002 +0200, Jeroen Massar wrote: since I'm part of the IPv6 team here at chello (UPC Technology is more correct) I'll comment on this part. >8<--------- >CHELLO (AS6830) announced 16 route(s) > 3ffe:2501:100::/48 path 10566 6939 6830 8733 (TVD -- 52%) > 3ffe:8070:1010::/48 path 12199 145 11537 786 109 4618 (INET-TH -- >4%) > 3ffe:8070:1010::/48 path 10566 6939 6830 (CHELLO -- 52%) > 3ffe:2900:2004::/48 path 12199 145 11537 786 109 4618 (INET-TH -- >4%) > 3ffe:2900:2004::/48 path 10566 6939 6830 (CHELLO -- 52%) > 3ffe:1300:7::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > 3ffe:1300:7::/48 path 10566 6939 6830 (CHELLO -- 52%) > 3ffe:327e:1::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > 3ffe:327e:1::/48 path 10566 6939 6830 (CHELLO -- 52%) > 3ffe:4005:a::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > 3ffe:4005:a::/48 path 10566 6939 6830 (CHELLO -- 52%) > 3ffe:80ee:556::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > 3ffe:80ee:556::/48 path 10566 6939 6830 (CHELLO -- 52%) > 3ffe:200:c::/48 path 10566 6939 6830 2847 ( -- 52%) > 3ffe:80b0:1002::/48 path 10566 6939 6830 8733 (TVD -- 52%) > 2001:6e0:202::/48 path 12199 145 11537 786 109 5539 1853 6830 8209 ( >-- 4%) > 3ffe:400b:6002::/48 path 12199 145 11537 786 109 4618 (INET-TH -- >4%) > 3ffe:400b:6002::/48 path 10566 6939 6830 (CHELLO -- 100%) > 3ffe:81a0:1012::/48 path 12199 145 11537 786 109 4618 (INET-TH -- >4%) > 3ffe:81a0:1012::/48 path 10566 6939 6830 (CHELLO -- 52%) > 3ffe:2500:322::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > 3ffe:2500:322::/48 path 10566 6939 6830 (CHELLO -- 52%) > 3ffe:8271:a080::/44 path 12199 145 11537 786 109 4618 (INET-TH -- >4%) > 3ffe:8271:a080::/44 path 10566 6939 6830 (CHELLO -- 52%) > 3ffe:82bf::/32 path 10566 6939 6830 24643 (NEXTGEN-LAB -- 52%) > 3ffe:2640::/32 path 10566 6939 6830 790 6793 (TELIAFI -- 51%) >--------->8 >And even more /48's, /44's and /32's and even double entries, great to >spread those. > >inet6num: 3FFE:82B0::/28 >netname: WEBONLINE-NET >descr: WebOnline AS > >Keep those peerings private... 3ffe:82bf::/32 is delegated to AS24643, also us. It's been in the list forever. AS8209 is also us, think I maybe should create a 6bone entry for it. and a general comment: What's wrong with letting through 3ffe::/16 le /32 ? (know it break the current RFC), but wouldn't it be an idea to let both 2001 and 3ffe space be aggregated upto /32 ? (2001 are, but 3ffe aren't) And on a later stage, maybe we should change the RFC and allow even something bigger than /32 be let through, /40 ? (/48's are too big to be let through on a RFC base) --- Roger Jorgensen (rjorgensen@chello.com) System Engineer @ UPC Technology / IP engineering handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID From jeroen@unfix.org Fri Jul 26 17:59:35 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Fri, 26 Jul 2002 18:59:35 +0200 Subject: [6bone] Summer cleanup time for IPv6 aggregation! In-Reply-To: <5.1.0.14.0.20020726164611.0309d610@213.46.233.213> Message-ID: <000901c234c5$d56df4f0$420d640a@unfix.org> Roger Jorgensen [mailto:rjorgensen@upctechnology.com] wrote: > Someone out there has now recently opened up their filters and are > passing on /48's and lots of other things. Check older stats > and you'll > see that much of this crap wasn't there before. > > > My point of view on this can be put this way: > > 1) If you want to have strict aggregation (after the RFC) you > filter incoming AND outgoing One could be "nice" to incoming peers ofcourse, that doesn't put anything in the global routing table which should belong there. > 2) If you want less strict aggregation it's okay to allow upto /48's > both incoming and outgoing (I assume people do filter away not wanted > announcment if they follow the RFC letter by letter) and incoming. > Anything smaller than /48's are not accepted under any circumstances) That's your point of view, there will probably be some smaller parties then who will have a point of view that /128's are okay, or people who will have point of view that ddossing people is normal etc.... It's the GLOBAL routing table we are talking about. Not that peering session between some friends. If we would start announcing everything there wouldn't be a need for RIR's to exist now was there? "I'll take that small /48 from you and announce it myself, saves me from going through the RIR's" And then everybody will be a RIR-alike entity and it _will_ become a huge mess. > At 01:17 PM 7/25/2002 +0200, Jeroen Massar wrote: > > > since I'm part of the IPv6 team here at chello (UPC Technology is more correct) > I'll comment on this part. > > >8<--------- > >CHELLO (AS6830) announced 16 route(s) > > 3ffe:2501:100::/48 path 10566 6939 6830 8733 (TVD -- 52%) > > 3ffe:8070:1010::/48 path 12199 145 11537 786 109 4618 (INET-TH -- > >4%) > > 3ffe:8070:1010::/48 path 10566 6939 6830 (CHELLO -- 52%) > > 3ffe:2900:2004::/48 path 12199 145 11537 786 109 4618 (INET-TH -- > >4%) > > 3ffe:2900:2004::/48 path 10566 6939 6830 (CHELLO -- 52%) > > 3ffe:1300:7::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > > 3ffe:1300:7::/48 path 10566 6939 6830 (CHELLO -- 52%) > > 3ffe:327e:1::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > > 3ffe:327e:1::/48 path 10566 6939 6830 (CHELLO -- 52%) > > 3ffe:4005:a::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > > 3ffe:4005:a::/48 path 10566 6939 6830 (CHELLO -- 52%) > > 3ffe:80ee:556::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > > 3ffe:80ee:556::/48 path 10566 6939 6830 (CHELLO -- 52%) > > 3ffe:200:c::/48 path 10566 6939 6830 2847 ( -- 52%) > > 3ffe:80b0:1002::/48 path 10566 6939 6830 8733 (TVD -- 52%) > > 2001:6e0:202::/48 path 12199 145 11537 786 109 5539 1853 6830 8209 ( -- 4%) > > 3ffe:400b:6002::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > > 3ffe:400b:6002::/48 path 10566 6939 6830 (CHELLO -- 100%) > > 3ffe:81a0:1012::/48 path 12199 145 11537 786 109 4618 (INET-TH --4%) > > 3ffe:81a0:1012::/48 path 10566 6939 6830 (CHELLO -- 52%) > > 3ffe:2500:322::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > > 3ffe:2500:322::/48 path 10566 6939 6830 (CHELLO -- 52%) > > 3ffe:8271:a080::/44 path 12199 145 11537 786 109 4618 (INET-TH -- 4%) > > 3ffe:8271:a080::/44 path 10566 6939 6830 (CHELLO -- 52%) > > 3ffe:82bf::/32 path 10566 6939 6830 24643 (NEXTGEN-LAB -- 52%) > > 3ffe:2640::/32 path 10566 6939 6830 790 6793 (TELIAFI -- 51%) > >--------->8 > >And even more /48's, /44's and /32's and even double entries, great to > >spread those. > > > >inet6num: 3FFE:82B0::/28 > >netname: WEBONLINE-NET > >descr: WebOnline AS > > > >Keep those peerings private... > > 3ffe:82bf::/32 is delegated to AS24643, also us. It's been in the list forever. > AS8209 is also us, think I maybe should create a 6bone entry for it. "It's been in the list forever" translates to "we never took care of cleaning it up" Maybe one could consider merging them into one AS ? Also as this is a /28 entry only the /28 should pop up in the global routing table, nothing else. Btw... you didn't cover the Thailand prefixes ;) > and a general comment: > > What's wrong with letting through 3ffe::/16 le /32 ? (know it break the current > RFC), but wouldn't it be an idea to let both 2001 and 3ffe > space be aggregated upto /32 ? (2001 are, but 3ffe aren't) Because it breaks the "RIR dealt out the prefix" rule. eg TLA's having a /24 could then do the "I am a RIR too" game if you specify it that way. Which in effect mostly will lead to the "everybody is a RIR" effect again. Another way would be revoking all the non /32's from the sixbone space and let people keep only one /32, but that won't work as they are (at least some people say) in active use. So those 3 extra lines is something we will have to cope with for the time being. 6bone will go away in the long run. It's a testbed and it should be tightly policed to make sure it doesn't make any problems for the productional IPv6 space. Btw... enterzone for example just requested a pTLA for "testing", they are using their RIR space for production. Which is good. And then those filters can go too... > And on a later stage, maybe we should change the RFC and > allow even something > bigger than /32 be let through, /40 ? (/48's are too big to > be let through > on a RFC base) You want to creat PI space, and there *IS* none. You can send *ANYTHING* you want to your peers as long as it doesn't popup in the global routing table. Repeat after me: Multihoming is currently not possible with IPv6 untill ipv6mh work is done. Check: http://arneill-py.sacramento.ca.us/ipv6mh/ Number one in the charter: 8<---------- - Develop IPv6 multihoming solutions that can be deployed in a reasonable amount of time (before aggregation is broken). No IPv6 multihoming, no IPv6. ---------->8 And if all the people/companies/organisations keep announcing all kinds of wierd things they won't make that "before aggregation is broken" part. It's coming along just fine, ofcourse any help is appreciated! IPv6 - Just keep it clean. Greets, Jeroen From narten@us.ibm.com Fri Jul 26 18:53:08 2002 From: narten@us.ibm.com (Thomas Narten) Date: Fri, 26 Jul 2002 13:53:08 -0400 Subject: [6bone] pTLA for Teredo testing - review closes 7 August 2002 In-Reply-To: Message from "Thu, 25 Jul 2002 12:52:37 PDT." Message-ID: <200207261753.g6QHr8D09998@rotala.raleigh.ibm.com> Christian, > Both, kind of. I am ready to sign off for something that says "Teredo > servers will be turned of at some predictable date". We could debate the > date; if I had to choose one, I would say 12/31/2006. That's a rather long-running experiment, IMO. Hard to see how this is different than just "deployment". > There are two ways to stop the experiment once it starts: stop the > servers, and junk the prefix so nobody routes these packets. And if clients are still using it, they will just be left hanging? What assurances are there that there won't be significant numbers of clients still wanting/trying to use the prefix? Let me step back a bit and summarize my general concern. draft-ietf-ngtrans-shipworm-05.txt was forwarded to the IESG, and there was quite a lot of strong concern fed back about particulars of the technology. It is unclear what has changed in the document to address that feedback or whether those who raised the concerns agree that their concerns have been adequately dealt with. (I am aware of no followup discussion on the revised draft.) One issue I spoke about (and it was just one of the issues, and one I chose to expand on in email at the time) concerned use of anycast addresses for source addresses. My understanding from an earlier note is that this sort of usage has been reduced in the latest draft, but has not been eliminated. So I can't say that that specific concern has been adequately addressed. (I haven't re-reviewed the document to fully understand what the current restrictions are.) As a general statement, I don't believe the community should be blessing open-ended experiments in which significant concerns about the technology behind the proposed experiment/usage have been raised. If the experiment were designed to better understand some aspects that can only be determined through actual testing (while folks were generally in agreement that the testing itself poses no dangers), that would be one thing. But I don't sense that this is the case here. In particular: - there is no clear description of what the experiment is intended to determine, how it will be terminated in a reasonable time frame, what the criteria is for deciding whether the experiment is a success or failure, how the scope of the experiment will be limited to some known size, and how we can ensure that the experiment doesn't just become actual deployment even if the experiment produces negative results. - more importantly, there are oustanding technical concerns with the shipworm/teredo work. I assume an attempt at addressing those concerns has been made in the revised draft. But until the draft has received adequate review and there is consensus that the work should go forward, I do not believe we (either IANA and 6bone) should be giving out a prefix for testing. To do so would short-circuit the community review process. I might add, a cynic might read the request for a 6bone allocation as an attempted end run around the fact the IESG has not approved the document, and hence, IANA won't yet allocate a prefix. General comment. Don't take the above as a statement that I believe that the problem is unimportant. I believe it is, as a solution to the general problem could significantly help IPv6 deployment. At the same time, however, a flawed solution could well be a disaster in-the-making for IPv6 and set back deployment efforts overall. It is precisely this concern that has prompted the pushback on the document so far from myself and others. Thus, I believe it would be most constructive to focus on the issue that have been raised and what can be done about them. Folks should also look at the IAB's draft-iab-unsaf-considerations-02.txt. It provides some very relevant discussion of some of the issues. Thomas From mcr@sandelman.ottawa.on.ca Fri Jul 26 23:52:58 2002 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 26 Jul 2002 18:52:58 -0400 Subject: [6bone] pTLA for Teredo testing - review closes 7 August 2002 In-Reply-To: Your message of "Fri, 26 Jul 2002 13:53:08 EDT." <200207261753.g6QHr8D09998@rotala.raleigh.ibm.com> Message-ID: <200207262253.g6QMqxhf005335@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Let me just say that I do not think that we should consider Teredo an "experiment". So, the questions that Thomas properly raises ("when is the experiment over? how do we know if it succeeded?") It will continue to be used as long as there are IPv4 NATs out there that do not offer any IPv6 service. Christian, 2007? I doubt it. Do not think that this is the lifecycle of technology the first world - I predict that the evil boxes that cause this problem will be rescued from dumpsters here and will show up in huts in the middle of the sub-Sahara (cf. _The Gods must be crazy_ s/coke bottle/IPv4 NAT/). Teredo is as important as 6to4, perhaps more so. I had more or less assumed that it would be the 2003:: prefix or something. I believe that this is a worthwhile thing to do with 1/65536s of our address space. I understand the concerns about the technology - I hope that they can be fixed. {I personally can not imagine ever being in such a place where I would be able to effectively use an anycast address to reach a Teredo relay, while being unable to do either at least 6to4, or IPv6 natively. } ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUHSx4qHRg3pndX9AQGQMAP/eTsBMKr9/HvsPDenWKGKALLCRWvF5To7 PpWOxucBPu7PMf13WoyVf+S0g2njkR8WcJeU+MdaOnmmAcMczPs9h/IQG1sQEaEC mFLjRhMb+t+qYWTG9M2dOztm6utK+qAFO5P+5EeK1ykzPGri8YhyMKwA/uXW26Ha WoQTQsHS+TQ= =jRXp -----END PGP SIGNATURE----- From tvo@EnterZone.Net Sat Jul 27 00:35:50 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Fri, 26 Jul 2002 19:35:50 -0400 (EDT) Subject: [6bone] Summer cleanup time for IPv6 aggregation! In-Reply-To: <5.1.0.14.0.20020726164611.0309d610@213.46.233.213> Message-ID: On Fri, 26 Jul 2002, Roger Jorgensen wrote: > > What's wrong with letting through 3ffe::/16 le /32 ? (know it break the current > RFC), but wouldn't it be an idea to let both 2001 and 3ffe space be aggregated > upto /32 ? (2001 are, but 3ffe aren't) It's all about aggregation. Since not all of 3ffe://16 is allocated as /32's, not all of it should be accepted as /32's. We should only accept this address space up to the bit boundry that is allocated. Beyond that, when you requested your pTLA, you should recall this part of the application: "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." Note this portion of RFC2772: "All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA delegation (currently /24 or /28) to other 6bone pTLAs unless special peering arrangements are implemented. When such special peering aggreements are in place between any two or more 6bone pTLAs, care MUST be taken not to leak the more specifics to other 6bone pTLAs not participating in the peering aggreement. 6bone pTLAs which have such agreements in place MUST NOT advertise other 6bone pTLA more specifics to downstream 6bone pNLAs or leaf sites, as this will break the best-path routing decision." Somehow, I don't remember entering into a peering agreement that included the following: 2001:6c0:1fff:ffd0::/60 2001:7f8:1::/64 3ffe:1200:3028:88a0::/64 3ffe:8090:4800:4e20::/64 3ffe:8090:4800:c000::/64 > And on a later stage, maybe we should change the RFC and allow even something > bigger than /32 be let through, /40 ? (/48's are too big to be let through > on a RFC base) Why? There is no reason to do this. Let the /35, /32, /28, /24 (whatever the RIR or 6bone allocation is) through the filters. Anything more specific is reachable by the aggregate and we don't end up with a v6 global routing table that is messed up like the current v4 table. Folks, the "redistribute connected" is *NOT* your friend here. There is no reason for a /64 or /128 to be in the routing table. That is what your IGP is for. There are so many EASY ways to keep the global table clean. (1) aggregate-address X:X::X:X/M summary-only It's simple, it's elegant, it works. (2) prefix-list filter your peers. If you're not already doing this, you should be! If you have a downstream BGP peer who is going to be sending you a /40 or /48 announcement, set up a route-map for this peer like so: ipv6 prefix-list DOWNSTREAM permit XX::XX/48 ipv6 prefix-list subTLA-only seq 5 deny 2001::/16 ge 36 ipv6 prefix-list subTLA-only seq 10 deny 3ffe::/18 ge 25 ipv6 prefix-list subTLA-only seq 15 deny 3ffe:4000::/18 ge 33 ipv6 prefix-list subTLA-only seq 20 deny 3ffe:8000::/22 ge 29 ipv6 prefix-list subTLA-only seq 25 permit ::/0 ge 1 ! route-map DOWNSTREAM permit 10 match ipv6 address prefix-list DOWNSTREAM set community no-export additive ! route-map DOWNSTREAM permit 20 match ipv6 address prefix-list subTLA-only ! You will see the /48 (or whatever it is) in YOUR routing table but, you are doing the responsible thing and marking it as no-export and not polluting the GLOBAL table with that garbage. (3) Apply a prefix list, like the above subTLA-only both inbound and outbound to your transit peer connections. This truely is not that difficult. I don't understand the overwhelming resistance to doing things right. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From michel@arneill-py.sacramento.ca.us Sat Jul 27 03:51:25 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 26 Jul 2002 19:51:25 -0700 Subject: [6bone] pTLA for Teredo testing - review closes 7 August 2002 Message-ID: <2B81403386729140A3A899A8B39B046406C9C2@server2000.arneill-py.sacramento.ca.us> > Michael Richardson wrote: > I had more or less assumed that it would be the 2003:: > prefix or something. Maybe there is something to be learned here about hijacking prefixes before they are assigned, no matter how big one is. > Let me just say that I do not think that we should consider > Teredo an "experiment". So, the questions that Thomas properly > raises ("when is the experiment over? how do we know if it > succeeded?") In the light of Christian's answer, I concur. > It will continue to be used as long as there are IPv4 NATs out > there that do not offer any IPv6 service. Christian, 2007? I > doubt it. So do I. Michel. From michel@arneill-py.sacramento.ca.us Sat Jul 27 03:52:29 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 26 Jul 2002 19:52:29 -0700 Subject: [6bone] pTLA for Teredo testing - review closes 7 August 2002 Message-ID: <2B81403386729140A3A899A8B39B046405E216@server2000.arneill-py.sacramento.ca.us> Thomas, > Thomas Narten wrote: > Let me step back a bit and summarize my general concern. > [SNIP] I generally agree with your posting, save for the following, to be placed in the context of generic 6bone testing prefixes, _not_ of the Teredo case. > But until the draft has received adequate review and there > is consensus that the work should go forward, I do not believe > we (either IANA and 6bone) should be giving out a prefix for > testing I would make a difference between the 6bone and the IANA here. The 6bone is for experimental purposes, and experimental means testing things that we don't know if they are working or not. More specifically, there are things such as new operational practices or new ways to allocate addresses that are extremely difficult or impossible to simulate in a lab environment and require larger scale testing. > If the experiment were designed to better understand some > aspects that can only be determined through actual testing > (while folks were generally in agreement that the testing > itself poses no dangers), that would be one thing. This is what I mean by testing, and I fully agree with attaching strings to test prefixes, such as the ones you mentioned: > how it will be terminated in a reasonable time frame, > what the criteria is for deciding whether the experiment is a success or failure, > how the scope of the experiment will be limited to some known size > how we can ensure that the experiment doesn't just become actual deployment even if the experiment produces negative results. And I would add that: - Milestones, deadlines and/or periodic reviews/reassessments are reasonable requirements to me. - Depending on the consequences of the experiment on the global routing table (or on the percept danger of testing), the experiment can be made optional, which means that it would be OK for anyone to block the experimental/test prefix. - The experiment can't be considered a success if it does not end up with IANA allocating a permanent prefix to replace the 6bone test prefix. In other words, there is a lot of unknown in front of us at this time, and it would be a shame to miss something that never succeeded because it was not possible to test it. It is in line with the 6bone spirit, and there is value in a fast track to perishable prefixes for testing purposes, if the testing occurs in a controlled fashion, and if in the end the decision to allocate a permanent prefix and therefore the success of the test/experiment is in the hands of the IANA. Michel. From pekkas@netcore.fi Sat Jul 27 14:52:58 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Sat, 27 Jul 2002 16:52:58 +0300 (EEST) Subject: [6bone] pTLA for Teredo testing - review closes 7 August 2002 In-Reply-To: <2B81403386729140A3A899A8B39B046405E216@server2000.arneill-py.sacramento.ca.us> Message-ID: On Fri, 26 Jul 2002, Michel Py wrote: > - The experiment can't be considered a success if it does not end up > with IANA allocating a permanent prefix to replace the 6bone test > prefix. Does this also apply to 3ffe::/16? (It was a rhetoric question.. :-) -- 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 pasky@pasky.ji.cz Mon Jul 29 10:08:04 2002 From: pasky@pasky.ji.cz (Petr Baudis) Date: Mon, 29 Jul 2002 11:08:04 +0200 Subject: [6bone] Re: request to become an End-site ... In-Reply-To: <001601c234a8$11bec420$9f16a8c0@m2alc109156> References: <001601c234a8$11bec420$9f16a8c0@m2alc109156> Message-ID: <20020729090804.GC27646@pasky.ji.cz> Dear diary, on Fri, Jul 26, 2002 at 03:26:37PM CEST, I got a letter, where Rohan P Pandit told me, that... > I am interested in becoming an end-site of the existing pTLAs. I have gone > through the information on the 6bone.net site and contacted Viagenie. But did > not receive any reply from them. I would like to know what I need to do from > my side and may be what the pTLA will do for me so that i can get connection > to 6bone. You probably want to start from requesting a tunnel and some IPv6 zone (/64 or /48 or whatever..) from some so-called "tunnel broker". You will just enter all relevant information thru web form, and then setup your gateway accordingly to informations they will send you withing few minutes or display directly on their web site. The most known ones include Access to Six (http://www.xs26.net/), IPng (http://www.ipng.nl) or Freenet6 (http://www.freenet6.net/), hopefully full list is at http://www.hs247.com/. > **************************Disclaimer************************************************** > > Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' > and 'confidential' and intended for use only by the individual or entity to which it is > addressed. You are notified that any use, copying or dissemination of the information > contained in the E-MAIL in any manner whatsoever is strictly prohibited. > > **************************************************************************************** Oh, I violated this by copying of the information to my reply! -- Petr "Pasky" Baudis * ELinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI occassional hacker . You can get much further with a kind word and a gun than you can with a kind word alone. -- Al Capone . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From pasky@pasky.ji.cz Mon Jul 29 10:20:38 2002 From: pasky@pasky.ji.cz (Petr Baudis) Date: Mon, 29 Jul 2002 11:20:38 +0200 Subject: [6bone] ip6.int or ip6.arpa or BOTH? In-Reply-To: References: <20020725005333.DB36B7E04@beowulf.gw.com> Message-ID: <20020729092038.GE27646@pasky.ji.cz> Dear diary, on Thu, Jul 25, 2002 at 03:19:24AM CEST, I got a letter, where John Fraizer told me, that... > > OK. > > (1) What is nibble format? > (2) Why would the glibc maintainers drop looking in ip6.int when there is > no ip6.arpa for 3ffe::/16? Dunno. I filled a report in glibc bugs tracking system (gnats, iirc), and they told me to write a patch for it to first try ip6.arpa and then ip6.int, however I have no time to do that now. FYI, the bug id is 3957. -- Petr "Pasky" Baudis * ELinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI occassional hacker . You can get much further with a kind word and a gun than you can with a kind word alone. -- Al Capone . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From todd@fries.net Mon Jul 29 15:34:19 2002 From: todd@fries.net (Todd T. Fries) Date: Mon, 29 Jul 2002 09:34:19 -0500 Subject: [6bone] glibc fix -> here <- Message-ID: <20020729143418.GA13170@fries.net> Home net is down, apoligies for mailing the list, but here's your glibc fix adapted from KAME/NetBSD/OpenBSD applied against the latest tarball of glibc I could find (2.2.5): --- ChangeLog.orig Mon Jul 29 09:32:36 2002 +++ ChangeLog Mon Jul 29 09:34:07 2002 @@ -1,3 +1,8 @@ +2002-06-29 Todd Fries + + * resolv/gethnamaddr.c: try ip6.int if ip6.arpa fails; code adapted + from KAME/NetBSD/OpenBSD libc. + 2002-01-18 Andreas Schwab * sysdeps/unix/sysv/linux/configure.in --- gethnamaddr.c.orig Fri Oct 26 18:49:48 2001 +++ gethnamaddr.c Mon Jul 29 09:28:10 2002 @@ -696,6 +696,11 @@ abort(); } n = res_nquery(&_res, qbuf, C_IN, T_PTR, (u_char *)buf.buf, sizeof buf.buf); + if (n < 0 && af == AF_INET6) { + strcpy(qp, "ip6.int"); + n = res_nquery(&_res, qbuf, C_IN, T_PTR, (u_char *)buf.buf, sizeof buf.buf); + } + if (n < 0) { dprintf("res_nquery failed (%d)\n", n); if (errno == ECONNREFUSED) -- Todd Fries .. todd@fries.net (last updated $ToddFries: signature.p,v 1.2 2002/03/19 15:10:18 todd Exp $) From bmanning@karoshi.com Mon Jul 29 23:14:40 2002 From: bmanning@karoshi.com (bmanning@karoshi.com) Date: Mon, 29 Jul 2002 22:14:40 +0000 (UCT) Subject: [6bone] Re: routing concern Message-ID: <200207292214.WAA08385@vacation.karoshi.com> > > > But AS6175 (SPRINT) is announcing 2001:400::/24. > > > > > Hello, > > it wasn't a typo, they are announcing a /24, which include your space. > > > > Thats antisocial, esp since we have no relationship with > them. > > --bill Could the folks injecting the /24 here -PLEASE- adjust it accordingly. Since ARIN is delegating /35 and /32 prefixes, this is (to put it nicely) overly agressive aggregation. Either that, or please provide me with the rest of the transit that is being annouced to the rest of the 6bone. I'll be happy to have you provision circuits to my POP. --bill From jds@smerdon.livonia.mi.us Tue Jul 30 03:48:17 2002 From: jds@smerdon.livonia.mi.us (John D Smerdon) Date: Mon, 29 Jul 2002 22:48:17 -0400 (EDT) Subject: [6bone] 6to4 anycast in US instead of Switzerland? Message-ID: <200207300248.g6U2mH900869@pm73a.smerdon.livonia.mi.us> I have a SDSL connection at home and have been using 6to4. My provider is Concentric/XO and when using the 6to4 anycast address, my first hop on ipv6 is switch.ch. Is anyone offering 6to4 anycast in the US, preferably in the midwest, or by a peer of XO in Chicago IL? If there is a closer 6to4 anycast network, would it be reasonable for me to request XO to preference a different AS in their BGP for the 6to4 anycast network? Thanks! $traceroute 192.88.99.1 traceroute to 192.88.99.1 (192.88.99.1), 30 hops max, 40 byte packets 2 w001.z208176108.det-mi.dsl.cnc.net (208.176.108.1) 11.760 ms 12.268 ms 13.096 ms 3 206.83.95.9 (206.83.95.9) 16.011 ms 14.884 ms 14.297 ms 4 216.112.137.9 (216.112.137.9) 14.947 ms 13.741 ms 14.182 ms 5 Southfield2.NextlinkNCO.DS3.WAN.daf.concentric.net (216.112.137.98) 16.551 ms 16.697 ms 15.698 ms 6 ge5-0-0.MAR1.Southfield-MI.us.xo.net (207.88.84.113) 14.157 ms 15.335 ms 14.842 ms 7 p5-1-0-1.RAR1.Chicago-IL.us.xo.net (65.106.6.173) 20.964 ms 20.319 ms 21.056 ms 8 ge1-0.edge1.chi-il.us.xo.net (64.220.0.181) 21.468 ms 21.625 ms 21.607 ms 9 207.88.50.242 (207.88.50.242) 22.591 ms 22.756 ms 31.107 ms 10 pos6-0-2488M.cr1.CHI1.gblx.net (208.49.59.205) 22.026 ms 22.060 ms 20.936 ms 11 pos0-0-2488M.cr1.CDG2.gblx.net (62.24.34.42) 123.448 ms 123.233 ms 123.329 ms 12 so0-0-0-622M.ar2.CDG2.gblx.net (62.24.34.74) 123.272 ms 125.076 ms 122.880 ms 13 Dante-Switch.so-0-1-0.ar2.CDG2.gblx.net (64.212.70.62) 134.051 ms 133.715 ms 132.359 ms 14 swiEZ2-G2-2.switch.ch (130.59.36.42) 140.177 ms 138.569 ms 137.986 ms 15 swiCS3-G3-2.switch.ch (130.59.36.17) 136.230 ms 138.664 ms 137.236 ms 16 * swi6T1-F0-1.switch.ch (130.59.20.6) 136.450 ms * -- John D. Smerdon; Livonia, Michigan, USA; Contents are my opinion. Home: jds@smerdon.livonia.mi.us http://www.smerdon.org/ From michel@arneill-py.sacramento.ca.us Tue Jul 30 06:37:27 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 29 Jul 2002 22:37:27 -0700 Subject: [6bone] Re: routing concern Message-ID: <2B81403386729140A3A899A8B39B046406C9D7@server2000.arneill-py.sacramento.ca.us> Bill, > Thats antisocial, esp since we have no relationship > with them. With all due respect, do you feel the power of the incarnation of evil now? Michel. From bmanning@ISI.EDU Tue Jul 30 07:09:00 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 29 Jul 2002 23:09:00 -0700 (PDT) Subject: [6bone] Re: routing concern Message-ID: <200207300609.g6U690A17399@boreas.isi.edu> > > Bill, > > > Thats antisocial, esp since we have no relationship > > with them. > > With all due respect, do you feel the power of the incarnation of evil > now? > > Michel. > What are you talking about Michel? You mean the completely asinine practice of proxy aggregation? Or the more inane practice of locally aggregating things you have zero knowledge of or business relationship with? Or the sheep-like "aggregation is good" mantra that has been coming out of the IETF for a while? People should not aggregate things that are not part of their delegation. End of Discussion. questions about "power" and "incarnation of evil" are better raised in the context of movie reviews of "Goldmember" or "PowerPuff Girls" -- "When in doubt, Twirl..." -anon From rrockell@sprint.net Tue Jul 30 13:41:21 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Tue, 30 Jul 2002 08:41:21 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: <200207292214.WAA08385@vacation.karoshi.com> Message-ID: Fixed. Explanation: We redistribute static (with route-map) in order to aggregate, so we keep Null0 static routes on each core router, to make sure that we inject the aggregate. When building new routers, at some point recently one of the IPv6 team here must have fat-fingered the mask for our 6bone delegation, and applied it to our ARIN delegation. This is now corrected: sl-bb1v6-rly#sho bgp ipv 2001:400::/24 BGP routing table entry for 2001:400::/24, version 56 Paths: (2 available, best #2) Advertised to non peer-group peers: 2001:440:6175:3::1 3FFE:900:0:1C::1 3FFE:A00:2:2::9 3FFE:B00:C18::E 3FFE:C00:8023:29::1 3FFE:1CFF:0:EC::1 3FFE:28FF:FFFF:1::114 3FFE:2900:1::2D 3FFE:2900:1:4::2 3FFE:2900:1:5::2 3FFE:2900:1:9::2 3FFE:2900:1:F::2 3FFE:2900:1:10::2 3FFE:2900:5:5::2 3FFE:2900:A:1::2 3FFE:2900:A:4::2 3FFE:2900:A:6::2 3FFE:2900:A:7::2 3FFE:2900:A:A::2 3FFE:2900:A:B::2 3FFE:2900:B:7::2 3FFE:2900:B:B::2 3FFE:2900:B:E::2 3FFE:2900:C:3::2 3FFE:2900:C:5::2 3FFE:2900:C:7::2 3FFE:2900:C:C::2 3FFE:2900:C:F::2 3FFE:2900:D:6::2 3FFE:2900:D:E::2 3FFE:2900:E:2::2 3FFE:2900:E:3::2 3FFE:2900:E:C::2 3FFE:2900:F:C::2 3FFE:2900:F:E::2 3FFE:2D00:1::F 3FFE:3600::3 3FFE:8000:FFFF:29::1 Local 2001:440:6175:4::1 (metric 63) from 2001:440:6175:4::1 (144.228.240.145) Origin IGP, localpref 100, valid, internal Local 2001:440:6175:2::1 (metric 20) from 2001:440:6175:2::1 (208.11.232.40) Origin IGP, localpref 100, valid, internal, best and null routes removed: sl-bb1v6-rly#sho bgp ipv 2001:400::/24 BGP routing table entry for 2001:400::/24, version 3963 Paths: (0 available, no best path) Flag: 0x820 Not advertised to any peer apologies for attempted assimilation of other people's ARIN delegations :) We'll tighten 'er down a bit today. Bill, if you aren't getting enough routes from us, send me personal mail, and we'll fix for you. Thanks Rob Rockell SprintLink International (+1) 703-689-6322 Sprint IP Services ----------------------------------------------------------------------- On Mon, 29 Jul 2002 bmanning@karoshi.com wrote: ->> > > But AS6175 (SPRINT) is announcing 2001:400::/24. ->> > > ->> > Hello, ->> > it wasn't a typo, they are announcing a /24, which include your space. ->> > ->> ->> Thats antisocial, esp since we have no relationship with ->> them. ->> ->> --bill -> -> -> Could the folks injecting the /24 here -PLEASE- adjust it -> accordingly. Since ARIN is delegating /35 and /32 prefixes, -> this is (to put it nicely) overly agressive aggregation. -> Either that, or please provide me with the rest of the transit -> that is being annouced to the rest of the 6bone. I'll -> be happy to have you provision circuits to my POP. -> ->--bill ->_______________________________________________ ->6bone mailing list ->6bone@mailman.isi.edu ->http://mailman.isi.edu/mailman/listinfo/6bone -> From rfurda@best.ca Tue Jul 30 13:43:34 2002 From: rfurda@best.ca (Richard Furda) Date: Tue, 30 Jul 2002 14:43:34 +0200 Subject: [6bone] 6to4 anycast in US instead of Switzerland? Message-ID: <5.1.1.6.0.20020730143431.00a7b130@riso.sk> Hello, On Mon, 29 Jul 2002, John D Smerdon wrote: > I have a SDSL connection at home and have been using 6to4. My > provider is Concentric/XO and when using the 6to4 anycast address, > my first hop on ipv6 is switch.ch. > > Is anyone offering 6to4 anycast in the US, preferably in the midwest, > or by a peer of XO in Chicago IL? I am on the west coast, yet, your DSL gw is father in terms of hops than switch.ch. > If there is a closer 6to4 anycast network, would it be reasonable > for me to request XO to preference a different AS in their BGP for > the 6to4 anycast network? Try 6to4.ipv6.fubar.ca [24.80.32.252] Richard From rrockell@sprint.net Tue Jul 30 13:58:11 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Tue, 30 Jul 2002 08:58:11 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: <200207300609.g6U690A17399@boreas.isi.edu> Message-ID: For the record, I agree with Bill's statement on proxy-aggregation. While I think Aggregation IS good, I would scope "IS" to prefixes that one owns, and has authority over. The Sprint example was not over-aggressive aggregation... It was over agressive subnet mask, via fat-finger, with under-aggresive redistribution route-map :) Thanks Rob Rockell SprintLink International (+1) 703-689-6322 Sprint IP Services ----------------------------------------------------------------------- On Mon, 29 Jul 2002, Bill Manning wrote: -> ->> ->> Bill, ->> ->> > Thats antisocial, esp since we have no relationship ->> > with them. ->> ->> With all due respect, do you feel the power of the incarnation of evil ->> now? ->> ->> Michel. ->> -> ->What are you talking about Michel? -> ->You mean the completely asinine practice of proxy aggregation? ->Or the more inane practice of locally aggregating things you have ->zero knowledge of or business relationship with? ->Or the sheep-like "aggregation is good" mantra that has been coming ->out of the IETF for a while? -> ->People should not aggregate things that are not part of their delegation. ->End of Discussion. -> ->questions about "power" and "incarnation of evil" are better raised ->in the context of movie reviews of "Goldmember" or "PowerPuff Girls" -> -> -> ->-- ->"When in doubt, Twirl..." -anon ->_______________________________________________ ->6bone mailing list ->6bone@mailman.isi.edu ->http://mailman.isi.edu/mailman/listinfo/6bone -> From bmanning@ISI.EDU Tue Jul 30 14:21:09 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Tue, 30 Jul 2002 06:21:09 -0700 (PDT) Subject: [6bone] Re: routing concern In-Reply-To: from "Robert J. Rockell" at "Jul 30, 2 08:58:11 am" Message-ID: <200207301321.g6UDL9720767@boreas.isi.edu> I appologise for my outburst and appreciate your prompt response. -- --bill From tvo@EnterZone.Net Tue Jul 30 15:21:29 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Tue, 30 Jul 2002 10:21:29 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: Message-ID: > sl-bb1v6-rly#sho bgp ipv 2001:400::/24 > BGP routing table entry for 2001:400::/24, version 3963 > Paths: (0 available, no best path) > Flag: 0x820 > Not advertised to any peer > Looks like someone out there (?513? ?3265? ?4538?) is running broken a BGP implementation. I don't see the route direct from 6175 and I trust from the output above that 6175 isn't announcing it but, (?513? ?3265? ?4538?) is holding on to the prefix (and redistributing it) for dear life! Border2-BGP> sh ipv6 bgp 2001:400::/24 BGP routing table entry for 2001:400::/24 Paths: (4 available, best #3, table Default-IP-Routing-Table) Advertised to non peer-group peers: 2001:4f0::1 2001:630:0:f001::1 3ffe:1ced:ff02::2 3ffe:1ced:ff06::2 3ffe:1ced:ff07::2 3ffe:1ced:ff0a::2 3ffe:2900:d:e::1 3ffe:31ff:0:ffff::50 3ffe:4005:0:1::26 3ffe:80c0:200:5::36 3ffe:8160:0:1::c 3ffe:81d0:ffff:2::44 6435 2549 513 3265 4538 6175 3ffe:8160:0:1::c from 3ffe:8160:0:1::c (64.65.64.152) (fe80::4041:4098) Origin IGP, localpref 100, valid, external Last update: Tue Jul 30 08:38:19 2002 4554 109 513 3265 4538 6175 3ffe:1ced:ff06::2 from 3ffe:1ced:ff06::2 (192.0.1.1) (fe80::c620:401) Origin IGP, metric 1, localpref 100, valid, external Last update: Tue Jul 30 08:38:37 2002 109 513 3265 4538 6175 3ffe:c00:8023:4::1 from 3ffe:c00:8023:4::1 (128.107.240.254) Origin IGP, localpref 100, valid, external, best Last update: Tue Jul 30 08:38:35 2002 22 109 513 3265 4538 6175 3ffe:1ced:ff05::2 from 3ffe:1ced:ff05::2 (198.253.28.59) (fe80::c6fd:1c3b) Origin IGP, localpref 100, valid, external Last update: Tue Jul 30 08:38:42 2002 --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From michel@arneill-py.sacramento.ca.us Tue Jul 30 15:52:56 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 30 Jul 2002 07:52:56 -0700 Subject: [6bone] Re: routing concern Message-ID: <2B81403386729140A3A899A8B39B046406C9D8@server2000.arneill-py.sacramento.ca.us> > Looks like someone out there (?513? ?3265? ?4538?) is running broken > a BGP implementation. I don't see the route direct from 6175 and I > trust from the output above that 6175 isn't announcing it but, > (?513? ?3265? ?4538?) is holding on to the prefix (and redistributing > it) for dear life! If it was not for the fact that the AS-PATH is not a mile long it would look much like the MRTd withdraw bug again. A variant? Michel. From pim@ipng.nl Tue Jul 30 15:59:32 2002 From: pim@ipng.nl (Pim van Pelt) Date: Tue, 30 Jul 2002 16:59:32 +0200 Subject: [6bone] Re: routing concern In-Reply-To: References: Message-ID: <20020730145932.GA15483@bfib.colo.bit.nl> On Tue, Jul 30, 2002 at 10:21:29AM -0400, John Fraizer wrote: | > sl-bb1v6-rly#sho bgp ipv 2001:400::/24 | > BGP routing table entry for 2001:400::/24, version 3963 | > Paths: (0 available, no best path) | > Flag: 0x820 | > Not advertised to any peer | > | | Looks like someone out there (?513? ?3265? ?4538?) is running broken a BGP | implementation. I don't see the route direct from 6175 and I trust from | the output above that 6175 isn't announcing it but, (?513? ?3265? ?4538?) | is holding on to the prefix (and redistributing it) for dear life! Just to be sure. AS3265 are junipers at AMS-IX (nl.xs4all) and there are no current known issues with IPv6/BGP on this platform. I can't say for sure if there are problems with CERN (AS513) and I've never even heard of CERNET-BKB (AS4538). I myself don't see 2001:400::/24 anymore in my tables (AS8954, AS12859) -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From michel@arneill-py.sacramento.ca.us Tue Jul 30 16:16:16 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 30 Jul 2002 08:16:16 -0700 Subject: [6bone] Re: routing concern Message-ID: <2B81403386729140A3A899A8B39B046405E222@server2000.arneill-py.sacramento.ca.us> Bill, > questions about "power" and "incarnation of evil" are better > raised in the context of movie reviews of "Goldmember" or > "PowerPuff Girls" Ahem, is it why you posted the following text here last week? > Bill Manning wrote: > Some ISPs beleive that this is evil incarnate and agressivly > filter. Others are more pragmatic and will adjust as their needs > dictate. I see double standard here. You can use "evil incarnate", but I can't use "incarnation of evil". You can bitch about seing a /24 you don't like in the routing table but we can't bitch when we see some /48 we don't like. Bill, you are a respected member of this community, but it is not enough to tell ISPs what they should do, especially when they lobby to respect RFCs. And, if you don't want this mailing list to have movie reviews in it, don't begin by using them yourself. Michel. From erik@xs4all.net Tue Jul 30 16:16:25 2002 From: erik@xs4all.net (Erik Bos) Date: Tue, 30 Jul 2002 17:16:25 +0200 Subject: [6bone] Re: routing concern In-Reply-To: References: Message-ID: <20020730151625.GE197@xs4all.nl> On Tue, Jul 30, 2002 at 10:21:29AM -0400, John Fraizer wrote: > > sl-bb1v6-rly#sho bgp ipv 2001:400::/24 > > BGP routing table entry for 2001:400::/24, version 3963 > > Paths: (0 available, no best path) > > Flag: 0x820 > > Not advertised to any peer > > > > Looks like someone out there (?513? ?3265? ?4538?) is running broken a BGP > implementation. I don't see the route direct from 6175 and I trust from > the output above that 6175 isn't announcing it but, (?513? ?3265? ?4538?) > is holding on to the prefix (and redistributing it) for dear life! We, AS3265, receive it from from AS1275: sh bgp ipv6 2001:400::/24 BGP routing table entry for 2001:400::/24, version 799862 Paths: (1 available, best #1) Advertised to peer-groups: XS4ALL-IPv6 1275 5623 9044 10566 6175, (received & used) 3FFE:401:0:1::27:1 from 3FFE:401:0:1::27:1 (128.176.191.66) Origin IGP, localpref 100, valid, external, best sh bgp ipv6 neighbors 3FFE:401:0:1::27:1 received-routes | begin 2001:400::/24 *> 2001:400::/24 3FFE:401:0:1::27:1 0 1275 5623 9044 10566 6175 i The box is running Cisco ios 12.2(8)T2. > Border2-BGP> sh ipv6 bgp 2001:400::/24 > BGP routing table entry for 2001:400::/24 > Paths: (4 available, best #3, table Default-IP-Routing-Table) > Advertised to non peer-group peers: > 2001:4f0::1 2001:630:0:f001::1 3ffe:1ced:ff02::2 3ffe:1ced:ff06::2 > 3ffe:1ced:ff07::2 3ffe:1ced:ff0a::2 3ffe:2900:d:e::1 > 3ffe:31ff:0:ffff::50 3ffe:4005:0:1::26 3ffe:80c0:200:5::36 > 3ffe:8160:0:1::c 3ffe:81d0:ffff:2::44 > 6435 2549 513 3265 4538 6175 > 3ffe:8160:0:1::c from 3ffe:8160:0:1::c (64.65.64.152) > (fe80::4041:4098) > Origin IGP, localpref 100, valid, external > Last update: Tue Jul 30 08:38:19 2002 > > 4554 109 513 3265 4538 6175 > 3ffe:1ced:ff06::2 from 3ffe:1ced:ff06::2 (192.0.1.1) > (fe80::c620:401) > Origin IGP, metric 1, localpref 100, valid, external > Last update: Tue Jul 30 08:38:37 2002 > > 109 513 3265 4538 6175 > 3ffe:c00:8023:4::1 from 3ffe:c00:8023:4::1 (128.107.240.254) > Origin IGP, localpref 100, valid, external, best > Last update: Tue Jul 30 08:38:35 2002 > > 22 109 513 3265 4538 6175 > 3ffe:1ced:ff05::2 from 3ffe:1ced:ff05::2 (198.253.28.59) > (fe80::c6fd:1c3b) > Origin IGP, localpref 100, valid, external > Last update: Tue Jul 30 08:38:42 2002 > > > > --- > John Fraizer | High-Security Datacenter Services | > EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | > http://www.enterzone.net/ | Virtual, Dedicated, Colocation | > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From Joop Joosten Tue Jul 30 17:50:17 2002 From: Joop Joosten (Joop Joosten) Date: Tue, 30 Jul 2002 18:50:17 +0200 (MET DST) Subject: [6bone] Re: routing concern In-Reply-To: <20020730151625.GE197@xs4all.nl> Message-ID: Folks, I received 2001:400::/24 from a number of places and I announced it to some peers, because of an old filter (shame on me). I think it is fixed now. Joop.. On Tue, 30 Jul 2002, Erik Bos wrote: > On Tue, Jul 30, 2002 at 10:21:29AM -0400, John Fraizer wrote: > > > sl-bb1v6-rly#sho bgp ipv 2001:400::/24 > > > BGP routing table entry for 2001:400::/24, version 3963 > > > Paths: (0 available, no best path) > > > Flag: 0x820 > > > Not advertised to any peer > > > > > > > Looks like someone out there (?513? ?3265? ?4538?) is running broken a BGP > > implementation. I don't see the route direct from 6175 and I trust from > > the output above that 6175 isn't announcing it but, (?513? ?3265? ?4538?) > > is holding on to the prefix (and redistributing it) for dear life! > > We, AS3265, receive it from from AS1275: > > sh bgp ipv6 2001:400::/24 > BGP routing table entry for 2001:400::/24, version 799862 > Paths: (1 available, best #1) > Advertised to peer-groups: > XS4ALL-IPv6 > 1275 5623 9044 10566 6175, (received & used) > 3FFE:401:0:1::27:1 from 3FFE:401:0:1::27:1 (128.176.191.66) > Origin IGP, localpref 100, valid, external, best > > sh bgp ipv6 neighbors 3FFE:401:0:1::27:1 received-routes | begin 2001:400::/24 > *> 2001:400::/24 3FFE:401:0:1::27:1 > 0 1275 5623 9044 10566 6175 i > > The box is running Cisco ios 12.2(8)T2. > > > Border2-BGP> sh ipv6 bgp 2001:400::/24 > > BGP routing table entry for 2001:400::/24 > > Paths: (4 available, best #3, table Default-IP-Routing-Table) > > Advertised to non peer-group peers: > > 2001:4f0::1 2001:630:0:f001::1 3ffe:1ced:ff02::2 3ffe:1ced:ff06::2 > > 3ffe:1ced:ff07::2 3ffe:1ced:ff0a::2 3ffe:2900:d:e::1 > > 3ffe:31ff:0:ffff::50 3ffe:4005:0:1::26 3ffe:80c0:200:5::36 > > 3ffe:8160:0:1::c 3ffe:81d0:ffff:2::44 > > 6435 2549 513 3265 4538 6175 > > 3ffe:8160:0:1::c from 3ffe:8160:0:1::c (64.65.64.152) > > (fe80::4041:4098) > > Origin IGP, localpref 100, valid, external > > Last update: Tue Jul 30 08:38:19 2002 > > > > 4554 109 513 3265 4538 6175 > > 3ffe:1ced:ff06::2 from 3ffe:1ced:ff06::2 (192.0.1.1) > > (fe80::c620:401) > > Origin IGP, metric 1, localpref 100, valid, external > > Last update: Tue Jul 30 08:38:37 2002 > > > > 109 513 3265 4538 6175 > > 3ffe:c00:8023:4::1 from 3ffe:c00:8023:4::1 (128.107.240.254) > > Origin IGP, localpref 100, valid, external, best > > Last update: Tue Jul 30 08:38:35 2002 > > > > 22 109 513 3265 4538 6175 > > 3ffe:1ced:ff05::2 from 3ffe:1ced:ff05::2 (198.253.28.59) > > (fe80::c6fd:1c3b) > > Origin IGP, localpref 100, valid, external > > Last update: Tue Jul 30 08:38:42 2002 > > > > > > > > --- > > John Fraizer | High-Security Datacenter Services | > > EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | > > http://www.enterzone.net/ | Virtual, Dedicated, Colocation | > > > > > > _______________________________________________ > > 6bone mailing list > > 6bone@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/6bone > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > +-----------------------------------------------------------------------+ | Joop Joosten, IT Division, CERN, 1211 Geneva 23, Switzerland | |Tel: +4122 767 3361; Fax: +4122 767 7155; Email: Joop.Joosten@cern.ch| +-----------------------------------------------------------------------+ From rrockell@sprint.net Tue Jul 30 18:30:01 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Tue, 30 Jul 2002 13:30:01 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: Message-ID: So being that this was our fault, perhaps I can find some silver lining? -sprint messed up their configs -most of 6bone was still loose enough to see it. While I take full responsibility for this, this is a good learning experience. If you saw this bad route, you were not filtering correctly (as sprint was not). Perhaps a testiment to the work that still needs to be done, if only to provide a baseline from which we can actually address the issues with multi-homing, aggregation, etc.. (i.e. we haven't even been sufficiently responsible to properly show how broken ipv6 is at this point). Thanks Rob Rockell SprintLink International (+1) 703-689-6322 Sprint IP Services ----------------------------------------------------------------------- On Tue, 30 Jul 2002, Joop Joosten wrote: ->Folks, -> ->I received 2001:400::/24 from a number of places and I announced it to ->some peers, because of an old filter (shame on me). I think it is fixed ->now. -> ->Joop.. -> ->On Tue, 30 Jul 2002, Erik Bos wrote: -> ->> On Tue, Jul 30, 2002 at 10:21:29AM -0400, John Fraizer wrote: ->> > > sl-bb1v6-rly#sho bgp ipv 2001:400::/24 ->> > > BGP routing table entry for 2001:400::/24, version 3963 ->> > > Paths: (0 available, no best path) ->> > > Flag: 0x820 ->> > > Not advertised to any peer ->> > > ->> > ->> > Looks like someone out there (?513? ?3265? ?4538?) is running broken a BGP ->> > implementation. I don't see the route direct from 6175 and I trust from ->> > the output above that 6175 isn't announcing it but, (?513? ?3265? ?4538?) ->> > is holding on to the prefix (and redistributing it) for dear life! ->> ->> We, AS3265, receive it from from AS1275: ->> ->> sh bgp ipv6 2001:400::/24 ->> BGP routing table entry for 2001:400::/24, version 799862 ->> Paths: (1 available, best #1) ->> Advertised to peer-groups: ->> XS4ALL-IPv6 ->> 1275 5623 9044 10566 6175, (received & used) ->> 3FFE:401:0:1::27:1 from 3FFE:401:0:1::27:1 (128.176.191.66) ->> Origin IGP, localpref 100, valid, external, best ->> ->> sh bgp ipv6 neighbors 3FFE:401:0:1::27:1 received-routes | begin 2001:400::/24 ->> *> 2001:400::/24 3FFE:401:0:1::27:1 ->> 0 1275 5623 9044 10566 6175 i ->> ->> The box is running Cisco ios 12.2(8)T2. ->> ->> > Border2-BGP> sh ipv6 bgp 2001:400::/24 ->> > BGP routing table entry for 2001:400::/24 ->> > Paths: (4 available, best #3, table Default-IP-Routing-Table) ->> > Advertised to non peer-group peers: ->> > 2001:4f0::1 2001:630:0:f001::1 3ffe:1ced:ff02::2 3ffe:1ced:ff06::2 ->> > 3ffe:1ced:ff07::2 3ffe:1ced:ff0a::2 3ffe:2900:d:e::1 ->> > 3ffe:31ff:0:ffff::50 3ffe:4005:0:1::26 3ffe:80c0:200:5::36 ->> > 3ffe:8160:0:1::c 3ffe:81d0:ffff:2::44 ->> > 6435 2549 513 3265 4538 6175 ->> > 3ffe:8160:0:1::c from 3ffe:8160:0:1::c (64.65.64.152) ->> > (fe80::4041:4098) ->> > Origin IGP, localpref 100, valid, external ->> > Last update: Tue Jul 30 08:38:19 2002 ->> > ->> > 4554 109 513 3265 4538 6175 ->> > 3ffe:1ced:ff06::2 from 3ffe:1ced:ff06::2 (192.0.1.1) ->> > (fe80::c620:401) ->> > Origin IGP, metric 1, localpref 100, valid, external ->> > Last update: Tue Jul 30 08:38:37 2002 ->> > ->> > 109 513 3265 4538 6175 ->> > 3ffe:c00:8023:4::1 from 3ffe:c00:8023:4::1 (128.107.240.254) ->> > Origin IGP, localpref 100, valid, external, best ->> > Last update: Tue Jul 30 08:38:35 2002 ->> > ->> > 22 109 513 3265 4538 6175 ->> > 3ffe:1ced:ff05::2 from 3ffe:1ced:ff05::2 (198.253.28.59) ->> > (fe80::c6fd:1c3b) ->> > Origin IGP, localpref 100, valid, external ->> > Last update: Tue Jul 30 08:38:42 2002 ->> > ->> > ->> > ->> > --- ->> > John Fraizer | High-Security Datacenter Services | ->> > EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | ->> > http://www.enterzone.net/ | Virtual, Dedicated, Colocation | ->> > ->> > ->> > _______________________________________________ ->> > 6bone mailing list ->> > 6bone@mailman.isi.edu ->> > http://mailman.isi.edu/mailman/listinfo/6bone ->> > ->> _______________________________________________ ->> 6bone mailing list ->> 6bone@mailman.isi.edu ->> http://mailman.isi.edu/mailman/listinfo/6bone ->> -> -> -> +-----------------------------------------------------------------------+ -> | Joop Joosten, IT Division, CERN, 1211 Geneva 23, Switzerland | -> |Tel: +4122 767 3361; Fax: +4122 767 7155; Email: Joop.Joosten@cern.ch| -> +-----------------------------------------------------------------------+ -> -> ->_______________________________________________ ->6bone mailing list ->6bone@mailman.isi.edu ->http://mailman.isi.edu/mailman/listinfo/6bone -> From bmanning@ISI.EDU Tue Jul 30 18:57:29 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Tue, 30 Jul 2002 10:57:29 -0700 (PDT) Subject: [6bone] Re: routing concern In-Reply-To: from "Robert J. Rockell" at "Jul 30, 2 01:30:01 pm" Message-ID: <200207301757.g6UHvTF07380@boreas.isi.edu> Good plans for moving forward. % So being that this was our fault, perhaps I can find some silver lining? % % -sprint messed up their configs % -most of 6bone was still loose enough to see it. % % While I take full responsibility for this, this is a good learning % experience. If you saw this bad route, you were not filtering correctly (as % sprint was not). % % Perhaps a testiment to the work that still needs to be done, if only to % provide a baseline from which we can actually address the issues with % multi-homing, aggregation, etc.. (i.e. we haven't even been sufficiently % responsible to properly show how broken ipv6 is at this point). % % % % % Thanks % Rob Rockell % SprintLink International % (+1) 703-689-6322 % Sprint IP Services % ----------------------------------------------------------------------- % % On Tue, 30 Jul 2002, Joop Joosten wrote: % % ->Folks, % -> % ->I received 2001:400::/24 from a number of places and I announced it to % ->some peers, because of an old filter (shame on me). I think it is fixed % ->now. % -> % ->Joop.. % -> % ->On Tue, 30 Jul 2002, Erik Bos wrote: % -> % ->> On Tue, Jul 30, 2002 at 10:21:29AM -0400, John Fraizer wrote: % ->> > > sl-bb1v6-rly#sho bgp ipv 2001:400::/24 % ->> > > BGP routing table entry for 2001:400::/24, version 3963 % ->> > > Paths: (0 available, no best path) % ->> > > Flag: 0x820 % ->> > > Not advertised to any peer % ->> > > % ->> > % ->> > Looks like someone out there (?513? ?3265? ?4538?) is running broken a BGP % ->> > implementation. I don't see the route direct from 6175 and I trust from % ->> > the output above that 6175 isn't announcing it but, (?513? ?3265? ?4538?) % ->> > is holding on to the prefix (and redistributing it) for dear life! % ->> % ->> We, AS3265, receive it from from AS1275: % ->> % ->> sh bgp ipv6 2001:400::/24 % ->> BGP routing table entry for 2001:400::/24, version 799862 % ->> Paths: (1 available, best #1) % ->> Advertised to peer-groups: % ->> XS4ALL-IPv6 % ->> 1275 5623 9044 10566 6175, (received & used) % ->> 3FFE:401:0:1::27:1 from 3FFE:401:0:1::27:1 (128.176.191.66) % ->> Origin IGP, localpref 100, valid, external, best % ->> % ->> sh bgp ipv6 neighbors 3FFE:401:0:1::27:1 received-routes | begin 2001:400::/24 % ->> *> 2001:400::/24 3FFE:401:0:1::27:1 % ->> 0 1275 5623 9044 10566 6175 i % ->> % ->> The box is running Cisco ios 12.2(8)T2. % ->> % ->> > Border2-BGP> sh ipv6 bgp 2001:400::/24 % ->> > BGP routing table entry for 2001:400::/24 % ->> > Paths: (4 available, best #3, table Default-IP-Routing-Table) % ->> > Advertised to non peer-group peers: % ->> > 2001:4f0::1 2001:630:0:f001::1 3ffe:1ced:ff02::2 3ffe:1ced:ff06::2 % ->> > 3ffe:1ced:ff07::2 3ffe:1ced:ff0a::2 3ffe:2900:d:e::1 % ->> > 3ffe:31ff:0:ffff::50 3ffe:4005:0:1::26 3ffe:80c0:200:5::36 % ->> > 3ffe:8160:0:1::c 3ffe:81d0:ffff:2::44 % ->> > 6435 2549 513 3265 4538 6175 % ->> > 3ffe:8160:0:1::c from 3ffe:8160:0:1::c (64.65.64.152) % ->> > (fe80::4041:4098) % ->> > Origin IGP, localpref 100, valid, external % ->> > Last update: Tue Jul 30 08:38:19 2002 % ->> > % ->> > 4554 109 513 3265 4538 6175 % ->> > 3ffe:1ced:ff06::2 from 3ffe:1ced:ff06::2 (192.0.1.1) % ->> > (fe80::c620:401) % ->> > Origin IGP, metric 1, localpref 100, valid, external % ->> > Last update: Tue Jul 30 08:38:37 2002 % ->> > % ->> > 109 513 3265 4538 6175 % ->> > 3ffe:c00:8023:4::1 from 3ffe:c00:8023:4::1 (128.107.240.254) % ->> > Origin IGP, localpref 100, valid, external, best % ->> > Last update: Tue Jul 30 08:38:35 2002 % ->> > % ->> > 22 109 513 3265 4538 6175 % ->> > 3ffe:1ced:ff05::2 from 3ffe:1ced:ff05::2 (198.253.28.59) % ->> > (fe80::c6fd:1c3b) % ->> > Origin IGP, localpref 100, valid, external % ->> > Last update: Tue Jul 30 08:38:42 2002 % ->> > % ->> > % ->> > % ->> > --- % ->> > John Fraizer | High-Security Datacenter Services | % ->> > EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | % ->> > http://www.enterzone.net/ | Virtual, Dedicated, Colocation | % ->> > % ->> > % ->> > _______________________________________________ % ->> > 6bone mailing list % ->> > 6bone@mailman.isi.edu % ->> > http://mailman.isi.edu/mailman/listinfo/6bone % ->> > % ->> _______________________________________________ % ->> 6bone mailing list % ->> 6bone@mailman.isi.edu % ->> http://mailman.isi.edu/mailman/listinfo/6bone % ->> % -> % -> % -> +-----------------------------------------------------------------------+ % -> | Joop Joosten, IT Division, CERN, 1211 Geneva 23, Switzerland | % -> |Tel: +4122 767 3361; Fax: +4122 767 7155; Email: Joop.Joosten@cern.ch| % -> +-----------------------------------------------------------------------+ % -> % -> % ->_______________________________________________ % ->6bone mailing list % ->6bone@mailman.isi.edu % ->http://mailman.isi.edu/mailman/listinfo/6bone % -> % % _______________________________________________ % 6bone mailing list % 6bone@mailman.isi.edu % http://mailman.isi.edu/mailman/listinfo/6bone % -- --bill From michel@arneill-py.sacramento.ca.us Tue Jul 30 19:13:36 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 30 Jul 2002 11:13:36 -0700 Subject: [6bone] Re: routing concern Message-ID: <2B81403386729140A3A899A8B39B046405E225@server2000.arneill-py.sacramento.ca.us> > Robert J. Rockell wrote: > -sprint messed up their configs As I said before, the 6bone is the right place for this. Has anyone been hurt? Anyone lost money? The lessons we collectively learn each time someone messes up a route are far more valuable than the consequences of messing up the route. Can anyone here say they never messed up a config anyway? > -most of 6bone was still loose enough to see it. > While I take full responsibility for this, this is a good > learning experience. If you saw this bad route, you were not > filtering correctly (as sprint was not). There is a phenomenon that we should not ignore here: I saw the route. The reason I did not filter it is not because I don't know how to, but because it is more interesting to me to actually see that kind of thing rather than filtering it. I don't think I'm the only one. As long as the curiosity / learning factor is more important than occasional problems, it is unfortunate to say that we might continue to see loose filtering. > Perhaps a testiment to the work that still needs to be done, if > only to provide a baseline from which we can actually address the > issues with multi-homing, aggregation, etc.. (i.e. we haven't even > been sufficiently responsible to properly show how broken ipv6 is > at this point). Concur. As this appears to be a genuine "fat fingers" mistake, my take on it is as follows: I know exactly what I'm doing when I don't filter the route. If *my* IPv6 routing goes down because Rob made a mistake, it's my fault (because I did not filter) and not Rob's (because mistakes do happen). Michel. From rrockell@sprint.net Tue Jul 30 19:34:22 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Tue, 30 Jul 2002 14:34:22 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: <2B81403386729140A3A899A8B39B046405E225@server2000.arneill-py.sacramento.ca.us> Message-ID: ->As this appears to be a genuine "fat fingers" mistake, my take on it is ->as follows: ->I know exactly what I'm doing when I don't filter the route. If *my* ->IPv6 routing goes down because Rob made a mistake, it's my fault ->(because I did not filter) and not Rob's (because mistakes do happen). agree, and disagree, This was one objection to 2772 when it was first brought it up way back in (Orlando?) IETF. I disagree. One can have fun with their own network, or with networks that collectively agree to have fun. You having fun, and then passing on your 'fun' to another network who is not interested, is bad mojo. For this reason, you will notice the 2772 uses MUST in places, with a backdoor of something to the effect of "unless otherwise agreed upon by your connection partner". so, I don't want to have fun with any of my peers/customers (or more correctly, I am not at the current time engaged in any organized learning initiative with any entity outside of AS6175) so please filter me strictly. Having fun at the expense of others is not cool... Notice that the bad aggregate we announced won't hurt anyone who is receiving a full table, but tomorrow, when I inject at /48 prefix inside 2001:400::/35 by mistake, it could... The 6bone is a learning network. However, keep your learning site-local, unless people agree that they want to learn too, please. -> ->Michel. -> -> From michel@arneill-py.sacramento.ca.us Tue Jul 30 19:57:12 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 30 Jul 2002 11:57:12 -0700 Subject: [6bone] Re: routing concern Message-ID: <2B81403386729140A3A899A8B39B046405E227@server2000.arneill-py.sacramento.ca.us> > Robert J. Rockell > The 6bone is a learning network. However, keep your learning > site-local, unless people agree that they want to learn too, > please. Agree. I should have mentioned that I do not filter ingress, but I do filter egress routes. However, I don't have a problem with my peers feeding me unfiltered routes. I *do* agree with your posting, but the reason that route was broadly seen is because lots of 6bone participants are still in the "learn" mode. So, it might be that there is an unspoken consensus about the 6bone still being a big learning tool, and the "unless otherwise agreed upon by your connection partner" might be considered a default by many. Following the logic, the ones to blame are people that peer directly with you because they should have filtered the route. Well, I will not be the one to throw the first stone at them. Michel. From rrockell@sprint.net Tue Jul 30 20:03:35 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Tue, 30 Jul 2002 15:03:35 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: <2B81403386729140A3A899A8B39B046405E227@server2000.arneill-py.sacramento.ca.us> Message-ID: As always, Sprint loves all of it's peers and customers, but asks that they help make sure that love remains bi-directional, by filtering appropriately :) Thanks Rob Rockell SprintLink International (+1) 703-689-6322 Sprint IP Services ----------------------------------------------------------------------- On Tue, 30 Jul 2002, Michel Py wrote: ->> Robert J. Rockell ->> The 6bone is a learning network. However, keep your learning ->> site-local, unless people agree that they want to learn too, ->> please. -> ->Agree. I should have mentioned that I do not filter ingress, but I do ->filter egress routes. -> ->However, I don't have a problem with my peers feeding me unfiltered ->routes. -> ->I *do* agree with your posting, but the reason that route was broadly ->seen is because lots of 6bone participants are still in the "learn" ->mode. -> ->So, it might be that there is an unspoken consensus about the 6bone ->still being a big learning tool, and the "unless otherwise agreed upon ->by your connection partner" might be considered a default by many. -> ->Following the logic, the ones to blame are people that peer directly ->with you because they should have filtered the route. Well, I will not ->be the one to throw the first stone at them. -> ->Michel. -> -> From riel@conectiva.com.br Tue Jul 30 20:08:04 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Tue, 30 Jul 2002 16:08:04 -0300 (BRT) Subject: [6bone] Re: routing concern In-Reply-To: Message-ID: On Tue, 30 Jul 2002, Robert J. Rockell wrote: > While I take full responsibility for this, this is a good learning > experience. If you saw this bad route, you were not filtering correctly > (as sprint was not). It would be good to have the currently recommended filter rules published on the web somewhere. While seeing a message go by on the 6bone list that a new can of prefixes has been opened is nice, but people can be away from their computer for a week and decide not to check all of their email backlog. Of course, it's likely somebody has already thought of this and I just don't know where the prefix filter rules are published. In that case, where could I find the "official" list ? ;) cheers, Rik -- http://www.linuxsymposium.org/2002/ "You're one of those condescending OLS attendants" "Here's a nickle kid. Go buy yourself a real t-shirt" http://www.surriel.com/ http://distro.conectiva.com/ From Robert.Kiessling@de.easynet.net Tue Jul 30 20:33:07 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 30 Jul 2002 20:33:07 +0100 Subject: [6bone] Re: routing concern In-Reply-To: References: Message-ID: "Robert J. Rockell" writes: > So being that this was our fault, perhaps I can find some silver lining? > > -sprint messed up their configs > -most of 6bone was still loose enough to see it. > > While I take full responsibility for this, this is a good learning > experience. If you saw this bad route, you were not filtering correctly (as > sprint was not). What filtering would you suggest to fix such an event in future? Of course right now you could filter on /32, but in future this will not be the maximum allocation. To justify a /24 in the current allocation guidelines, you need around 600000 prospective assignments, which is days of DSL is not unrealistic. So actually we can expect to see assignments of that size, and consequently a general filter on "allow only smaller equal /32" is way too aggressive. Robert From andy@ipng.org.uk Tue Jul 30 20:36:25 2002 From: andy@ipng.org.uk (Andy Furnell) Date: Tue, 30 Jul 2002 20:36:25 +0100 Subject: [6bone] Re: routing concern In-Reply-To: References: Message-ID: <20020730193625.GE4459@penfold.noc.clara.net> On Tue, Jul 30, 2002 at 04:08:04PM -0300, Rik van Riel wrote: > > On Tue, 30 Jul 2002, Robert J. Rockell wrote: > > > While I take full responsibility for this, this is a good learning > > experience. If you saw this bad route, you were not filtering correctly > > (as sprint was not). > > It would be good to have the currently recommended > filter rules published on the web somewhere. > > While seeing a message go by on the 6bone list that > a new can of prefixes has been opened is nice, but > people can be away from their computer for a week > and decide not to check all of their email backlog. > > Of course, it's likely somebody has already thought > of this and I just don't know where the prefix filter > rules are published. > > In that case, where could I find the "official" list ? ;) > > cheers, > > Rik Or at least something to build filters from. icbw but there doesn't seem to be sufficient administrative architecture in place to build ingress filters properly. Some kind of radb-style RPSL route objects might not go amiss? A -- Andy Furnell andy@ipng.org.uk From tvo@EnterZone.Net Tue Jul 30 22:25:27 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Tue, 30 Jul 2002 17:25:27 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: Message-ID: OK. Lets address a couple of things. If you continued to see 2001:400::/24 with an ORIGIN of 6175 after 8:38AM EST 30JUL2002, either: (1) You have a broken BGP implementation. (2) One or more of your peers have a broken BGP implementation. (3) Both 1 and 2. XS4ALL: You show a path of 1275_5623_9044_10566_6175 below but, the route we saw was 109_513_3265_4538_6175. I am at this very moment still seeing it (with XS4ALL in the path): 109 15180 3265 4538 6175 3ffe:c00:8023:4::1 from 3ffe:c00:8023:4::1 (128.107.240.254) (fe80::806b:f0fe) Origin IGP, localpref 100, valid, external, best Last update: Tue Jul 30 12:13:38 2002 Again, if you continue to see this route with 6175 as the ORIGIN, start contacting the peers you're seeing it from. It *ISN'T* being originated by 6175 any longer. Your peers (and perhaps you) have broken BGP implementations. If you're running a broken BGP implementation, I submit that you owe it to the REST of the DFZ operators to depeer until such time as you replace your broken implementation with something that is not going to pollute the DFZ. This is one prefix that we know about. Who knows how much other garbage your BGP implementation is spewing. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On Tue, 30 Jul 2002, Joop Joosten wrote: > Folks, > > I received 2001:400::/24 from a number of places and I announced it to > some peers, because of an old filter (shame on me). I think it is fixed > now. > > Joop.. > > On Tue, 30 Jul 2002, Erik Bos wrote: > > > On Tue, Jul 30, 2002 at 10:21:29AM -0400, John Fraizer wrote: > > > > sl-bb1v6-rly#sho bgp ipv 2001:400::/24 > > > > BGP routing table entry for 2001:400::/24, version 3963 > > > > Paths: (0 available, no best path) > > > > Flag: 0x820 > > > > Not advertised to any peer > > > > > > > > > > Looks like someone out there (?513? ?3265? ?4538?) is running broken a BGP > > > implementation. I don't see the route direct from 6175 and I trust from > > > the output above that 6175 isn't announcing it but, (?513? ?3265? ?4538?) > > > is holding on to the prefix (and redistributing it) for dear life! > > > > We, AS3265, receive it from from AS1275: > > > > sh bgp ipv6 2001:400::/24 > > BGP routing table entry for 2001:400::/24, version 799862 > > Paths: (1 available, best #1) > > Advertised to peer-groups: > > XS4ALL-IPv6 > > 1275 5623 9044 10566 6175, (received & used) > > 3FFE:401:0:1::27:1 from 3FFE:401:0:1::27:1 (128.176.191.66) > > Origin IGP, localpref 100, valid, external, best > > > > sh bgp ipv6 neighbors 3FFE:401:0:1::27:1 received-routes | begin 2001:400::/24 > > *> 2001:400::/24 3FFE:401:0:1::27:1 > > 0 1275 5623 9044 10566 6175 i > > > > The box is running Cisco ios 12.2(8)T2. > > > > > Border2-BGP> sh ipv6 bgp 2001:400::/24 > > > BGP routing table entry for 2001:400::/24 > > > Paths: (4 available, best #3, table Default-IP-Routing-Table) > > > Advertised to non peer-group peers: > > > 2001:4f0::1 2001:630:0:f001::1 3ffe:1ced:ff02::2 3ffe:1ced:ff06::2 > > > 3ffe:1ced:ff07::2 3ffe:1ced:ff0a::2 3ffe:2900:d:e::1 > > > 3ffe:31ff:0:ffff::50 3ffe:4005:0:1::26 3ffe:80c0:200:5::36 > > > 3ffe:8160:0:1::c 3ffe:81d0:ffff:2::44 > > > 6435 2549 513 3265 4538 6175 > > > 3ffe:8160:0:1::c from 3ffe:8160:0:1::c (64.65.64.152) > > > (fe80::4041:4098) > > > Origin IGP, localpref 100, valid, external > > > Last update: Tue Jul 30 08:38:19 2002 > > > > > > 4554 109 513 3265 4538 6175 > > > 3ffe:1ced:ff06::2 from 3ffe:1ced:ff06::2 (192.0.1.1) > > > (fe80::c620:401) > > > Origin IGP, metric 1, localpref 100, valid, external > > > Last update: Tue Jul 30 08:38:37 2002 > > > > > > 109 513 3265 4538 6175 > > > 3ffe:c00:8023:4::1 from 3ffe:c00:8023:4::1 (128.107.240.254) > > > Origin IGP, localpref 100, valid, external, best > > > Last update: Tue Jul 30 08:38:35 2002 > > > > > > 22 109 513 3265 4538 6175 > > > 3ffe:1ced:ff05::2 from 3ffe:1ced:ff05::2 (198.253.28.59) > > > (fe80::c6fd:1c3b) > > > Origin IGP, localpref 100, valid, external > > > Last update: Tue Jul 30 08:38:42 2002 > > > > > > > > > > > > --- > > > John Fraizer | High-Security Datacenter Services | > > > EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | > > > http://www.enterzone.net/ | Virtual, Dedicated, Colocation | > > > > > > > > > _______________________________________________ > > > 6bone mailing list > > > 6bone@mailman.isi.edu > > > http://mailman.isi.edu/mailman/listinfo/6bone > > > > > _______________________________________________ > > 6bone mailing list > > 6bone@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/6bone > > > > > +-----------------------------------------------------------------------+ > | Joop Joosten, IT Division, CERN, 1211 Geneva 23, Switzerland | > |Tel: +4122 767 3361; Fax: +4122 767 7155; Email: Joop.Joosten@cern.ch| > +-----------------------------------------------------------------------+ > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From tvo@EnterZone.Net Tue Jul 30 22:40:36 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Tue, 30 Jul 2002 17:40:36 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: <2B81403386729140A3A899A8B39B046405E225@server2000.arneill-py.sacramento.ca.us> Message-ID: On Tue, 30 Jul 2002, Michel Py wrote: > > Robert J. Rockell wrote: > > -sprint messed up their configs > > As I said before, the 6bone is the right place for this. Has anyone been > hurt? Anyone lost money? The lessons we collectively learn each time > someone messes up a route are far more valuable than the consequences of > messing up the route. > > Can anyone here say they never messed up a config anyway? > I doubt that many can say they have never messed up a config. What I am more interested in is: 1) How many people continue to participate in the BGP DFZ with what is KNOWN to be a broken BGP implementation. 2) Why? 3) Why are their peers *STILL* their peers? If I *KNOW FOR FACT* that someone, even one of our v4 transit customers, is going to spew crap into the routing tables because their either too cheap or too lazy to upgrade their BGP implementation, I'll depeer them. It's that simple. Config issues are something that will happen. BUGS in software are something that will happen. People *IGNORING* these bugs in the software they run should *NOT* happen. Why is it? > > -most of 6bone was still loose enough to see it. > > While I take full responsibility for this, this is a good > > learning experience. If you saw this bad route, you were not > > filtering correctly (as sprint was not). Does someone care to modify this prefix list to allow current 6bone and RIR allocations through only? ipv6 prefix-list subTLA-only seq 5 deny 2001::/16 ge 36 ipv6 prefix-list subTLA-only seq 10 deny 3ffe::/18 ge 25 ipv6 prefix-list subTLA-only seq 15 deny 3ffe:4000::/18 ge 33 ipv6 prefix-list subTLA-only seq 20 deny 3ffe:8000::/22 ge 29 ipv6 prefix-list subTLA-only seq 25 permit ::/0 ge 1 I can't for the life of me figure it out for some reason. I tried ipv6 prefix-list subTLA-only seq 5 deny 2001::/16 ge 36 le 33 but it wouldn't take it. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From erik@xs4all.net Tue Jul 30 23:00:49 2002 From: erik@xs4all.net (Erik Bos) Date: Wed, 31 Jul 2002 00:00:49 +0200 Subject: [6bone] Re: routing concern In-Reply-To: References: Message-ID: <20020730220049.GK197@xs4all.nl> On Tue, Jul 30, 2002 at 05:25:27PM -0400, John Fraizer wrote: > > OK. Lets address a couple of things. > > If you continued to see 2001:400::/24 with an ORIGIN of 6175 after > 8:38AM EST 30JUL2002, either: > > (1) You have a broken BGP implementation. > > (2) One or more of your peers have a broken BGP implementation. > > (3) Both 1 and 2. > > > XS4ALL: You show a path of 1275_5623_9044_10566_6175 below but, the route > we saw was 109_513_3265_4538_6175. > > I am at this very moment still seeing it (with XS4ALL in the path): > > 109 15180 3265 4538 6175 > 3ffe:c00:8023:4::1 from 3ffe:c00:8023:4::1 (128.107.240.254) > (fe80::806b:f0fe) > Origin IGP, localpref 100, valid, external, best > Last update: Tue Jul 30 12:13:38 2002 > > > Again, if you continue to see this route with 6175 as the ORIGIN, start > contacting the peers you're seeing it from. It *ISN'T* being originated > by 6175 any longer. Your peers (and perhaps you) have broken BGP > implementations. > I don't see 2001:400::/24 anymore, I guess AS15180 and/or AS109 have to check what they currently see. I've CC'ed contacts for both ASes, hopefully they can still see it so we'll be able to find what's happening. From mcr@sandelman.ottawa.on.ca Tue Jul 30 23:46:59 2002 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 30 Jul 2002 18:46:59 -0400 Subject: [6bone] Re: routing concern In-Reply-To: Your message of "Tue, 30 Jul 2002 17:25:27 EDT." Message-ID: <200207302247.g6UMl0eu028230@marajade.sandelman.ottawa.on.ca> >>>>> "John" == John Fraizer writes: John> If you're running a broken BGP implementation, I submit that you owe it to John> the REST of the DFZ operators to depeer until such time as you replace John> your broken implementation with something that is not going to pollute the John> DFZ. It would also be nice if you let people know what you did to fix things! Or at least, "stay away from FOO-BAR Message-ID: On Wed, 31 Jul 2002, Erik Bos wrote: > > I don't see 2001:400::/24 anymore, I guess AS15180 and/or AS109 have to > check what they currently see. > > I've CC'ed contacts for both ASes, hopefully they can still see it so we'll > be able to find what's happening. >From http://nitrous.ipv6.enterzone.net/ BGP routing table entry for 2001:400::/24 Paths: (4 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 2001:4f0::1 2001:630:0:f001::1 3ffe:1ced:ff02::2 3ffe:1ced:ff06::2 3ffe:1ced:ff07::2 3ffe:1ced:ff09::2 3ffe:1ced:ff0a::2 3ffe:2900:d:e::1 3ffe:31ff:0:ffff::50 3ffe:4005:0:1::26 3ffe:80c0:200:5::36 3ffe:8160:0:1::c 3ffe:81d0:ffff:2::44 4554 109 15180 3265 4538 6175 3ffe:1ced:ff06::2 from 3ffe:1ced:ff06::2 (192.0.1.1) (fe80::c620:401) Origin IGP, metric 1, localpref 100, valid, external Last update: Tue Jul 30 12:52:00 2002 109 15180 3265 4538 6175 3ffe:c00:8023:4::1 from 3ffe:c00:8023:4::1 (128.107.240.254) (fe80::806b:f0fe) Origin IGP, localpref 100, valid, external, best Last update: Tue Jul 30 12:13:38 2002 6435 109 15180 3265 4538 6175 3ffe:8160:0:1::c from 3ffe:8160:0:1::c (64.65.64.152) (fe80::4041:4098) Origin IGP, localpref 100, valid, external Last update: Tue Jul 30 12:52:22 2002 22 109 15180 3265 4538 6175 3ffe:1ced:ff05::2 from 3ffe:1ced:ff05::2 (198.253.28.59) (fe80::c6fd:1c3b) Origin IGP, localpref 100, valid, external Last update: Tue Jul 30 12:13:43 2002 Kewlio.net http://router.ipv6.kewlio.net/cgi-bin/index.cgi sees the following: BGP routing table entry for 2001:400::/24 Paths: (5 available, best #4, table Default-IP-Routing-Table) Advertised to non peer-group peers: 3ffe:4005::10 3ffe:4005:0:1::14 8758 6830 3292 109 15180 3265 4538 6175 3ffe:4006:0:3::15 from 3ffe:4006:0:3::15 (212.25.27.46) (fe80::d419:1542) Origin IGP, localpref 100, valid, external Community: 6830:60003 6830:60011 24765:100 24765:2300 24765:6007 Last update: Tue Jul 30 17:52:48 2002 109 109 15180 3265 4538 6175 3ffe:c00:8023:45::1 from 3ffe:c00:8023:45::1 (128.107.240.254) (fe80::806b:f0fe) Origin IGP, metric 500, localpref 100, valid, external Community: 24765:100 24765:1200 24765:6003 Last update: Tue Jul 30 17:13:35 2002 8973 6830 3292 109 15180 3265 4538 6175 3ffe:4008:1::1 from 3ffe:4008:1::1 (192.16.124.2) (fe80::c010:7c02) Origin IGP, localpref 100, valid, external Community: 24765:100 24765:2200 24765:6008 Last update: Tue Jul 30 17:52:28 2002 3265 4538 6175 3ffe:8280:0:2000::c from 3ffe:8280:0:2000::c (194.109.5.254) (fe80::c26d:5fe) Origin IGP, localpref 100, valid, external, best Community: 24765:100 24765:1800 24765:6010 Last update: Thu Jul 25 20:25:00 2002 1849 1890 2549 109 15180 3265 4538 6175 2001:600:4:8de::1 from 2001:600:4:8de::1 (158.43.131.66) (fe80::2d0:c0ff:feb9:1c) Origin IGP, localpref 100, valid, external Community: 24765:100 24765:1200 24765:6001 Last update: Tue Jul 30 17:49:44 2002 LAVA.NET http://www.ipv6.lava.net/cgi-bin/lg.pl sees: slimemold.creativedynamo.com> show ipv6 bgp 2001:400::/24 BGP routing table entry for 2001:400::/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 109 15180 3265 4538 6175 3ffe:c00:8023::2 from 3ffe:8160:0:3::2 (64.65.64.152) Origin IGP, localpref 100, valid, internal, best Last update: Tue Jul 30 13:14:33 2002 EURONET.BE http://www.ipv6.euronet.be/cgi-bin/ipv6_lg.pl sees: Router: gate.ipv6.euronet.be Query: bgp Addr: 2001:400::/24 BGP routing table entry for 2001:400::/24, version 89215 Paths: (3 available, best #1) Advertised to non peer-group peers: 2001:6E0::2 2001:768:E:5::1 3FFE:80B0:100:8000::3 3FFE:8100:200:2FFF::9 3FFE:8170:1:10::1 195.74.212.38 5594 13193 109 15180 3265 4538 6175, (received & used) 3FFE:8100:102::1:9 from 3FFE:8100:102::1:9 (195.154.1.6) Origin IGP, localpref 100, valid, external, best 1849 1890 2549 109 15180 3265 4538 6175, (received & used) 2001:600:4:1F1::1 from 2001:600:4:1F1::1 (158.43.131.66) Origin IGP, localpref 100, valid, external 15589 109 109 15180 3265 4538 6175, (received & used) 3FFE:8170:1:10::1 from 3FFE:8170:1:10::1 (192.168.1.12) Origin IGP, localpref 100, valid, external STBEN.BE http://www.stben.be/cgi-bin/lg sees: show ipv6 bgp 2001:400::24 BGP routing table entry for 2001:400::/35 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer 8277 15589 293, (aggregated by 293 198.128.2.27) 3ffe:80b0:100:8000::2 from 3ffe:80b0:100:8000::2 (195.74.217.145) (fe80::c34a:d991) Origin IGP, localpref 100, valid, external, atomic-aggregate Last update: Tue Jul 30 21:05:56 2002 10566 6939 293, (aggregated by 293 198.128.2.27) 3ffe:b00:c18::68 from 3ffe:b00:c18::68 (206.123.31.101) Origin IGP, localpref 100, valid, external, atomic-aggregate, best Last update: Tue Jul 30 21:04:55 2002 *** Note this looking glass is broken. I requested "sh ipv6 bgp 2001:400::/24" and it stripped the "/" from the query. I then requested "show ipv6 bgp 2001:400:ffff::" and we get: show ipv6 bgp 2001:400:ffff:: BGP routing table entry for 2001:400::/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 8277 5594 13193 109 15180 3265 4538 6175 3ffe:80b0:100:8000::2 from 3ffe:80b0:100:8000::2 (195.74.217.145) (fe80::c34a:d991) Origin IGP, localpref 100, valid, external, best Last update: Tue Jul 30 18:47:23 2002 I don't think that Cisco has broken BGP4+ implementation in use so, my bets are that it's most likely 15180. Note: Kewlio.net does see the route via XS4ALL though: 3265 4538 6175 3ffe:8280:0:2000::c from 3ffe:8280:0:2000::c (194.109.5.254) (fe80::c26d:5fe) Origin IGP, localpref 100, valid, external, best Community: 24765:100 24765:1800 24765:6010 Last update: Thu Jul 25 20:25:00 2002 Kewlio is running: Zebra 0.93 (i386-unknown-freebsd4.4). Copyright 1996-2002, Kunihiro Ishiguro. I'm not aware of any "keep v6 routes when they go away" problem with Zebra but, there is a newer version of Zebra available. We're running it at EnterZone. I am VERY interested to know what 15180 is running though since everything else is pointing to them. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From Jan Oravec Wed Jul 31 10:00:44 2002 From: Jan Oravec (Jan Oravec) Date: Wed, 31 Jul 2002 11:00:44 +0200 Subject: [6bone] Re: routing concern In-Reply-To: References: Message-ID: <20020731090044.GA5518@hades.xs26.net> Hello, We at XS26 see 2001:400::/24 with the following AS-PATH: 13110 4554 109 15180 3265 4538 6175, (Received from a RR-client) 3ffe:80ef:901:1::2 (metric 87) from 3ffe:80ef:201:: (153.19.178.101) Origin IGP, localpref 100, valid, internal Originator: 153.19.178.101, Cluster list: 80.84.236.164 62.89.127.130 Last update: Wed Jul 31 10:11:41 2002 Best Regards, -- Jan Oravec 6COM Ltd. jan.oravec@6com.sk From Ronald.vanderPol@rvdp.org Wed Jul 31 11:10:35 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Wed, 31 Jul 2002 12:10:35 +0200 Subject: [6bone] Re: routing concern In-Reply-To: <2B81403386729140A3A899A8B39B046405E225@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E225@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020731101035.GA12460@rvdp.org> On Tue, Jul 30, 2002 at 11:13:36 -0700, Michel Py wrote: > As I said before, the 6bone is the right place for this. Has anyone been > hurt? Anyone lost money? The lessons we collectively learn each time > someone messes up a route are far more valuable than the consequences of > messing up the route. Is it time to start making a clear distinction between IPv6 production and IPv6 experimentation/learning? I think today the 6bone is used for both. Many use IPv6 for their daily work *). We *need* a stable network for that. If we don't do that we risk scaring people away from IPv6. Most OSes support IPv6 nowadays. When an enduser starts using IPv6 for the first time and she notices all kinds of networking problems, many will think: "OK, let's turn off IPv6. It does not work." The RIR prefixes are meant for IPv6 production. So, I think they should not be used on the 6bone. The 6bone should only be used for experiments and possibly learning. And on the other hand, I think production services should not use 6bone prefixes, but RIR prefixes. rvdp *) I frequently use ftp, cvs and http over IPv6 to sites far away in the internet. Too often, there are routing problems and IPv6 traffic is blackholed (routing loops, etc). Most application time out and try IPv4. But this means annoying delays. Many of these problems occur because people are running production services over the 6bone. From Nick Kraal Wed Jul 24 12:34:11 2002 From: Nick Kraal (Nick Kraal) Date: Wed, 24 Jul 2002 19:34:11 +0800 Subject: [6bone] semi-newbie Q on IPv6 address planning Message-ID: <012301c23306$082ecb60$53e173cb@arc.net.my> I heard that this mailing-list holds the most experienced IPv6 prefix and IP address allocation planners. I am in the middle of deploying our IPv6 network and in some mental block when it comes to IP address prefix planning. Basically we have been allocated a /32 from APNIC and need some advice/pointers in further allocating IPv6 addresses and prefixes. Have read RFC2373/2374/3177 on this. Basically we plan to allocate /48 for end-customers and /40 for our pNLA customers. So basically for a /48 allocation I have the full 16 bits to play around with and for a /40 allocation only 8 bits leaving the last 8 bits in this field for the pNLA to assign to their end customers. The end customers in both cases allocate further networks in the SLA field. Reading on the web there are many methods or allocating these bits ranging from allocating some bits: a. differentiate core from customer networks e.g. between /40, /48, /64 b. geographical PoP sites and further bits to do point a. above Have looked at the websites on this for SLAC, Stanford and Internet2, Abilene. Are there any BCPs out there advising on this or are we on our own. I have worked something out based on the information from the Internet -but looks quite dodgy. Do we have to stick to allocating in lots of 8 bits? Is a /44 allocation valid? And what is a /126 allocation for a point-to-point link? I thought the last /64 is reserved for the EUI-64 interface ID. Would appreciate any pointers/hints/websites/etc on this. -nick/ From erik@xs4all.net Wed Jul 31 13:42:36 2002 From: erik@xs4all.net (Erik Bos) Date: Wed, 31 Jul 2002 14:42:36 +0200 Subject: [6bone] Re: routing concern In-Reply-To: References: <20020730220049.GK197@xs4all.nl> Message-ID: <20020731124235.GR197@xs4all.nl> On Tue, Jul 30, 2002 at 09:02:34PM -0400, John Fraizer wrote: > > On Wed, 31 Jul 2002, Erik Bos wrote: > > > > > I don't see 2001:400::/24 anymore, I guess AS15180 and/or AS109 have to > > check what they currently see. > > > > I've CC'ed contacts for both ASes, hopefully they can still see it so we'll > > be able to find what's happening. [ .... ] > I don't think that Cisco has broken BGP4+ implementation in use so, my > bets are that it's most likely 15180. > > Note: Kewlio.net does see the route via XS4ALL though: > > 3265 4538 6175 > 3ffe:8280:0:2000::c from 3ffe:8280:0:2000::c (194.109.5.254) > (fe80::c26d:5fe) > Origin IGP, localpref 100, valid, external, best > Community: 24765:100 24765:1800 24765:6010 > Last update: Thu Jul 25 20:25:00 2002 > > Kewlio is running: > > Zebra 0.93 (i386-unknown-freebsd4.4). > Copyright 1996-2002, Kunihiro Ishiguro. > > I'm not aware of any "keep v6 routes when they go away" problem with Zebra > but, there is a newer version of Zebra available. We're running it at > EnterZone. > > I am VERY interested to know what 15180 is running though since everything > else is pointing to them. According to my emailarchive 15180 was running Zebra when the tunnel was setup, I don't what they are currently using. From ipng@uni-muenster.de Wed Jul 31 14:12:23 2002 From: ipng@uni-muenster.de (Christian Schild) Date: Wed, 31 Jul 2002 15:12:23 +0200 Subject: [6bone] Re: routing concern In-Reply-To: <20020731101035.GA12460@rvdp.org> References: <2B81403386729140A3A899A8B39B046405E225@server2000.arneill-py.sacramento.ca.us> <20020731101035.GA12460@rvdp.org> Message-ID: <20020731131221.0BA12312A9@zivlnx01.uni-muenster.de> Am Mittwoch, 31. Juli 2002 12:10 schrieben Sie: > On Tue, Jul 30, 2002 at 11:13:36 -0700, Michel Py wrote: > > As I said before, the 6bone is the right place for this. Has anyone been > > hurt? Anyone lost money? The lessons we collectively learn each time > > someone messes up a route are far more valuable than the consequences of > > messing up the route. > > Is it time to start making a clear distinction between IPv6 production > and IPv6 experimentation/learning? I think today the 6bone is used for > both. > > Many use IPv6 for their daily work *). We *need* a stable network for > that. If we don't do that we risk scaring people away from IPv6. Most > OSes support IPv6 nowadays. When an enduser starts using IPv6 for the > first time and she notices all kinds of networking problems, many will > think: "OK, let's turn off IPv6. It does not work." > > The RIR prefixes are meant for IPv6 production. So, I think they should > not be used on the 6bone. The 6bone should only be used for experiments > and possibly learning. And on the other hand, I think production services > should not use 6bone prefixes, but RIR prefixes. > > rvdp > > *) I frequently use ftp, cvs and http over IPv6 to sites far away in > the internet. Too often, there are routing problems and IPv6 traffic > is blackholed (routing loops, etc). Most application time out and try > IPv4. But this means annoying delays. Many of these problems occur > because people are running production services over the 6bone. I completely support this view. I would go that far to say, that today's 6bone is hindering IPv6 deployment, as the IPv6 network is rated unreliable and slow. This is mainly caused by the 6bone, having tunnels over long IPv4 distances and having unreliable and playful pTLA's. What was good before (to get started with IPv6) is evil now, because people don't differentiate between 6bone and the productive network we are trying to build. In my opinion, the best solution to solve this problem, is to seperate the 3ffe:: from the 2001:: network. There are a few ways to do so, maybe someone will come up with a draft for that, maybe as an enhancement for RFC2772? I believe it is very important for everyone to understand that 6bone is not 'the' IPv6 network. So long, Christian -- JOIN - IP Version 6 in the WiN Christian Schild A DFN project Westfaelische Wilhelms-Universitaet Muenster Project Team email: Zentrum fuer Informationsverarbeitung join@uni-muenster.de Roentgenstrasse 9-13 http://www.join.uni-muenster.de D-48149 Muenster / Germany email: schild@uni-muenster.de,phone: +49 251 83 31638, fax: +49 251 83 31653 From tvo@EnterZone.Net Wed Jul 31 14:28:11 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 31 Jul 2002 09:28:11 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: <20020731101035.GA12460@rvdp.org> Message-ID: On Wed, 31 Jul 2002, Ronald van der Pol wrote: > On Tue, Jul 30, 2002 at 11:13:36 -0700, Michel Py wrote: > > > As I said before, the 6bone is the right place for this. Has anyone been > > hurt? Anyone lost money? The lessons we collectively learn each time > > someone messes up a route are far more valuable than the consequences of > > messing up the route. > > Is it time to start making a clear distinction between IPv6 production > and IPv6 experimentation/learning? I think today the 6bone is used for > both. > > Many use IPv6 for their daily work *). We *need* a stable network for > that. If we don't do that we risk scaring people away from IPv6. Most > OSes support IPv6 nowadays. When an enduser starts using IPv6 for the > first time and she notices all kinds of networking problems, many will > think: "OK, let's turn off IPv6. It does not work." > > The RIR prefixes are meant for IPv6 production. So, I think they should > not be used on the 6bone. The 6bone should only be used for experiments > and possibly learning. And on the other hand, I think production services > should not use 6bone prefixes, but RIR prefixes. > > rvdp If you don't want to see RIR space on your router Ronald, you can filter it. I _strongly_ disagree with having a hard seperation of production v6 and 6bone though. There already exists seperation. Production services on production prefixes. 6bone experiments on 6bone prefixes. Do you really want to create an island out of the production v6 network? Do you want folks on production v6 address space to not be able to reach 6bone prefixes? We're not asking people to stop experimenting. We're asking them to do so wisely. As for scaring people away from v6, I don't see it. As confounded as it is, the 6bone is more robust then the initial v4 network. > *) I frequently use ftp, cvs and http over IPv6 to sites far away in > the internet. Too often, there are routing problems and IPv6 traffic > is blackholed (routing loops, etc). Most application time out and try > IPv4. But this means annoying delays. Many of these problems occur > because people are running production services over the 6bone. The last time I checked, the 6bone was an adhock network of folks running (mostly) v6-in-v4 tunnels between each other to establish v6 (notice I don't make distinction between 3ffe::/16 and 2001::/16 here) connectivity in the absence of NATIVE v6 connections. Granted, there are some native v6 links. That is great. The *majority* of links are v6-in-v4 tunnels though. If you're complaining about people running production services on 6bone PREFIXES, perhaps they haven't gotten around to getting their RIR space yet. Perhaps they haven't made the obvious distinction between their v6 and v4 webservers. (Hint: www.[domain].com = v4, www.ipv6.[domain[.com = v6) This gives the USER the choice, based on the URL they type in. I honestly don't see a problem with the two (6bone and production) being interweaved. Had the aggregation mistake been made on a 3ffe::/16 prefix, it wouldn't have been as big of a deal. The fact that it aggregated the entire ARIN RIR *production* v6 space was the problem. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From rrockell@sprint.net Wed Jul 31 14:38:59 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Wed, 31 Jul 2002 09:38:59 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: Message-ID: perhaps a good compromise here is to take steps towards at least base-lining the 6bone with decent inter-domain routing rules? The first two things that stick out that hinder the 6bone from being a viable testbed (assuming a sutiable definition for Testbed is: A network that emulates what the real world (might) look like, so tests can be performed): -filtering (popular one on this mailing list) -less transit Right now, it seems like the default for pTLA's is to give transit to each other. In the ipv4 world (and I don't see how this changes in IPv6) normally, big networks have one or a few transit providers, but then only peer with non-transit to all other networks. Today, it looks like transit is the de-factor for pTLA---pTLA peering. If we cut this down, it allows us to: 1. better optimize routing, because we can work out who has the best/widest-reaching pTLA network, and get transit from that network (avoid long tunnels, not following geographic topology, etc..). 2. filters more strongly (if you only receive one prefix from a peer, it is much easier to filter strongly than if you filter the whole table explicitly). The concept of 'less transit' I don't think has been addressed here yet, but I think it is a suitable pursuit for current pTLA network operators to look at, as I think it would help with scaling, filtering, etc... I don't need 20 paths to every pTLA, especially if I'm directly peered with that pTLA. Thanks Rob Rockell SprintLink International (+1) 703-689-6322 Sprint IP Services ----------------------------------------------------------------------- On Wed, 31 Jul 2002, John Fraizer wrote: -> ->On Wed, 31 Jul 2002, Ronald van der Pol wrote: -> ->> On Tue, Jul 30, 2002 at 11:13:36 -0700, Michel Py wrote: ->> ->> > As I said before, the 6bone is the right place for this. Has anyone been ->> > hurt? Anyone lost money? The lessons we collectively learn each time ->> > someone messes up a route are far more valuable than the consequences of ->> > messing up the route. ->> ->> Is it time to start making a clear distinction between IPv6 production ->> and IPv6 experimentation/learning? I think today the 6bone is used for ->> both. ->> ->> Many use IPv6 for their daily work *). We *need* a stable network for ->> that. If we don't do that we risk scaring people away from IPv6. Most ->> OSes support IPv6 nowadays. When an enduser starts using IPv6 for the ->> first time and she notices all kinds of networking problems, many will ->> think: "OK, let's turn off IPv6. It does not work." ->> ->> The RIR prefixes are meant for IPv6 production. So, I think they should ->> not be used on the 6bone. The 6bone should only be used for experiments ->> and possibly learning. And on the other hand, I think production services ->> should not use 6bone prefixes, but RIR prefixes. ->> ->> rvdp -> ->If you don't want to see RIR space on your router Ronald, you can filter ->it. I _strongly_ disagree with having a hard seperation of production v6 ->and 6bone though. There already exists seperation. Production services ->on production prefixes. 6bone experiments on 6bone prefixes. -> ->Do you really want to create an island out of the production v6 ->network? Do you want folks on production v6 address space to not be able ->to reach 6bone prefixes? -> ->We're not asking people to stop experimenting. We're asking them to do so ->wisely. As for scaring people away from v6, I don't see it. As ->confounded as it is, the 6bone is more robust then the initial v4 ->network. -> ->> *) I frequently use ftp, cvs and http over IPv6 to sites far away in ->> the internet. Too often, there are routing problems and IPv6 traffic ->> is blackholed (routing loops, etc). Most application time out and try ->> IPv4. But this means annoying delays. Many of these problems occur ->> because people are running production services over the 6bone. -> ->The last time I checked, the 6bone was an adhock network of folks running ->(mostly) v6-in-v4 tunnels between each other to establish v6 (notice I ->don't make distinction between 3ffe::/16 and 2001::/16 here) connectivity ->in the absence of NATIVE v6 connections. Granted, there are some native ->v6 links. That is great. The *majority* of links are v6-in-v4 tunnels ->though. -> ->If you're complaining about people running production services on 6bone ->PREFIXES, perhaps they haven't gotten around to getting their RIR space ->yet. Perhaps they haven't made the obvious distinction between their v6 ->and v4 webservers. (Hint: www.[domain].com = v4, www.ipv6.[domain[.com = ->v6) This gives the USER the choice, based on the URL they type in. -> ->I honestly don't see a problem with the two (6bone and production) being ->interweaved. Had the aggregation mistake been made on a 3ffe::/16 prefix, ->it wouldn't have been as big of a deal. The fact that it aggregated the ->entire ARIN RIR *production* v6 space was the problem. -> -> -> ->--- ->John Fraizer | High-Security Datacenter Services | ->EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | ->http://www.enterzone.net/ | Virtual, Dedicated, Colocation | -> -> From bmanning@ISI.EDU Wed Jul 31 14:39:34 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 31 Jul 2002 06:39:34 -0700 (PDT) Subject: [6bone] fork In-Reply-To: <20020731101035.GA12460@rvdp.org> from Ronald van der Pol at "Jul 31, 2 12:10:35 pm" Message-ID: <200207311339.g6VDdYX13665@boreas.isi.edu> % Is it time to start making a clear distinction between IPv6 production % and IPv6 experimentation/learning? I think today the 6bone is used for % both. can't be done. people still experiment/learn on the v4 network and its also used for "production" (what ever that means :) Same w/ v6. the 6bone, as an overlay ontop of the v4 network will eventually disolve as native v6 transport is put into place. The 6bone address space won't go away when folks run native infrastructure -unless- they take overt action to deprecate the use of those prefixes. And since the bits and pieces of the overlay won't/can't convert at the same time, we can't have a flag day for everyone. 3ffe::/16 may be around a very long time. --bill From Ronald.vanderPol@rvdp.org Wed Jul 31 14:47:50 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Wed, 31 Jul 2002 15:47:50 +0200 Subject: [6bone] Re: routing concern In-Reply-To: References: <20020731101035.GA12460@rvdp.org> Message-ID: <20020731134750.GF12460@rvdp.org> On Wed, Jul 31, 2002 at 09:28:11 -0400, John Fraizer wrote: > If you don't want to see RIR space on your router Ronald, you can filter > it. I _strongly_ disagree with having a hard seperation of production v6 > and 6bone though. There already exists seperation. Production services > on production prefixes. 6bone experiments on 6bone prefixes. There is a problem when production services are being reached via a network which is not stable (like 6bone is today). I am not saying it is bad that 6bone is not stable. I just think 6bone should become a network for doing IPv6 related experiments only, no production. > Do you really want to create an island out of the production v6 > network? Do you want folks on production v6 address space to not be able > to reach 6bone prefixes? No, and these are not related. There can be connections to and from the 6bone. But the routing must be setup in a way that you never reach production prefixes via the 6bone (when your origin is not the 6bone). > We're not asking people to stop experimenting. We're asking them to do so > wisely. As for scaring people away from v6, I don't see it. As > confounded as it is, the 6bone is more robust then the initial v4 > network. I want an IPv6 network which is *at least* as reliable as the IPv4 network is *today*. > If you're complaining about people running production services on 6bone > PREFIXES, perhaps they haven't gotten around to getting their RIR space > yet. I am not complaining. I am just asking the question if the time has come to seperate experiment from production. rvdp From itojun@iijlab.net Wed Jul 31 14:53:56 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Wed, 31 Jul 2002 22:53:56 +0900 Subject: [6bone] Re: routing concern In-Reply-To: Ronald.vanderPol's message of Wed, 31 Jul 2002 12:10:35 +0200. <20020731101035.GA12460@rvdp.org> Message-ID: <20020731135356.C21564B22@coconut.itojun.org> >> As I said before, the 6bone is the right place for this. Has anyone been >> hurt? Anyone lost money? The lessons we collectively learn each time >> someone messes up a route are far more valuable than the consequences of >> messing up the route. > >Is it time to start making a clear distinction between IPv6 production >and IPv6 experimentation/learning? I think today the 6bone is used for >both. > >Many use IPv6 for their daily work *). We *need* a stable network for >that. If we don't do that we risk scaring people away from IPv6. Most >OSes support IPv6 nowadays. When an enduser starts using IPv6 for the >first time and she notices all kinds of networking problems, many will >think: "OK, let's turn off IPv6. It does not work." i completely agree with the above. many of the Japanese ISPs are now selling IPv6 traffic commercially (yes, we do charge money), and people do depend on us. therefore, we (IIJ) need to provide stable network to our customers. our policy is to never peer over tunnels (i still have a couple of tunnels which will be shut down soon). we use tunnels within our AS, but not toward other ASes. from my experience, peers over tunnels are not reliable, as - they usually do not enforce enough route filters - they usually are not serious enough about IPv6 (if they are serious, they should have been paying for IPv6 circuit) - they (the network itself, or the contact person) disappear without notice - tunnel itself is not stable enough due to IPv4 troubles so my suggestion to sTLA holders are, (1) install RFC2772-based filters to all of your EBGP routers, and (2) shut down tunnels. itojun From tvo@EnterZone.Net Wed Jul 31 15:03:54 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 31 Jul 2002 10:03:54 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: <20020731124235.GR197@xs4all.nl> Message-ID: On Wed, 31 Jul 2002, Erik Bos wrote: > On Tue, Jul 30, 2002 at 09:02:34PM -0400, John Fraizer wrote: > > > > I am VERY interested to know what 15180 is running though since everything > > else is pointing to them. > > According to my emailarchive 15180 was running Zebra when the tunnel was > setup, I don't what they are currently using. Something to remember folks. This isn't plug-n-play. When new revisions of code come out, there is generally a reason. You need to upgrade! This is yet another reason why I don't understand people still running MRTd. The last revision to the code was Aug 14, 2000 according to the sourceforge page. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From tvo@EnterZone.Net Wed Jul 31 15:27:49 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 31 Jul 2002 10:27:49 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: <20020731134750.GF12460@rvdp.org> Message-ID: On Wed, 31 Jul 2002, Ronald van der Pol wrote: > On Wed, Jul 31, 2002 at 09:28:11 -0400, John Fraizer wrote: > > > If you don't want to see RIR space on your router Ronald, you can filter > > it. I _strongly_ disagree with having a hard seperation of production v6 > > and 6bone though. There already exists seperation. Production services > > on production prefixes. 6bone experiments on 6bone prefixes. > > There is a problem when production services are being reached via > a network which is not stable (like 6bone is today). I am not saying > it is bad that 6bone is not stable. I just think 6bone should become > a network for doing IPv6 related experiments only, no production. Um, it sounds like you need to get better peering, either native v6 or better tunnel peering. I don't see this as any different than v4. If your peering is $h!t, your experience is $h!t. I am all for the 6bone as a while being more stable. Having contacts that actually MONITOR the 6bone list (I thought this was a requirement BTW) and notice when people are talking about their network and REACT to this by fixing their problems, blah blah blah. Until that happens, if a peer is unresponsive and crappy, depeer. Again, just like v4. If transit to site X is better via A_B_C_X than via D_X, set up a route-map to pref the A_B_C_X route. Again, just like v4. > > Do you really want to create an island out of the production v6 > > network? Do you want folks on production v6 address space to not be able > > to reach 6bone prefixes? > > No, and these are not related. There can be connections to and from > the 6bone. But the routing must be setup in a way that you never > reach production prefixes via the 6bone (when your origin is not the > 6bone). You're going to be hard pressed to do this. As Bill pointed out, there are 3ffe::/16 prefixes being routes over native v6 links and there are 2001::/16 prefixes being routes over v6-in-v4 tunnels. Just because a connection between two peers is in a v4-in-v4 tunnel does NOT make that connection a "6bone" connection vs "production" connection and native v6 peering does not mean that that particular connection is not a "6bone" connection. > > We're not asking people to stop experimenting. We're asking them to do so > > wisely. As for scaring people away from v6, I don't see it. As > > confounded as it is, the 6bone is more robust then the initial v4 > > network. > > I want an IPv6 network which is *at least* as reliable as the IPv4 > network is *today*. Choose your peering partners wisely then. No different than IPv4. Rob from Sprint hit on something that I don't quite agree with. He wants to limit transit. Coming from Sprint (no offense Rob), that makes perfect sense. I live on the other end of the spectrum. The more transit possibilities you have to a network you don't DIRECTLY peer with, the more likely you will be able to reach that network. Even if you DO have direct peering with that network, having a backup route(s) to them doesn't hurt a thing. If people don't want backup-transit, that is their decision. I don't think there needs to be any broad policy change and especially not among pTLAs. Unless we're all going to establish direct peering between each other (that scales just wonderful, doesn't it?) it is wise for us to provide transit to each other (pTLA to pTLA). --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From tvo@EnterZone.Net Wed Jul 31 15:47:16 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 31 Jul 2002 10:47:16 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: <20020731135356.C21564B22@coconut.itojun.org> Message-ID: On Wed, 31 Jul 2002 itojun@iijlab.net wrote: > from my experience, peers over tunnels are not reliable, as > - they usually do not enforce enough route filters > - they usually are not serious enough about IPv6 (if they are serious, > they should have been paying for IPv6 circuit) > - they (the network itself, or the contact person) disappear without > notice > - tunnel itself is not stable enough due to IPv4 troubles Talk about overgeneralization. Do you always paint with that broad of brush itojun? "they usually do not enforce enough route filters" - Filters belong on both INGRESS and EGRESS. You are just as responsible for filtering as they are. "they usually are not serious enough about IPv6 (if they are serious, they should have been paying for IPv6 circuit)" - It must be nice to receive funding from 9 different organizations. Some of us don't have that luxury. "they (the network itself, or the contact person) disappear without notice" - Contact disappears, depeer. Network disappears, automatic depeering. "tunnel itself is not stable enough due to IPv4 troubles" - v4 connectivity in Japan that bad eh? Ya know, if you were SERIOUS, you'd have OC-192 from *your* edge into MULTIPLE peering points in the US and UK. I guess it's time for all of your v4 peers to drop you, huh? > so my suggestion to sTLA holders are, (1) install RFC2772-based filters > to all of your EBGP routers, and (2) shut down tunnels. Damn. And I thought that the elitists were all v4 based. >From RFC2772: "The organizations receiving prefixes under these newer TLAs would be expected to want to establish peering and connectivity relationships with other IPv6 networks, both in the newer TLA space and in the 6bone pTLA space. Peering between new TLA's and the current 6Bone pTLA's MAY occur, and details such as transit, and what routes are received by each, are outside of general peering rules as stated in this memo, and are left up to the members of those TLA's and pTLA's that are establishing said peerings. However, it is expected that most of the rules discussed here are equally applicable to new TLAs." --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From riel@conectiva.com.br Wed Jul 31 15:52:00 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Wed, 31 Jul 2002 11:52:00 -0300 (BRT) Subject: [6bone] Re: routing concern In-Reply-To: <20020731134750.GF12460@rvdp.org> Message-ID: On Wed, 31 Jul 2002, Ronald van der Pol wrote: > On Wed, Jul 31, 2002 at 09:28:11 -0400, John Fraizer wrote: > > > If you don't want to see RIR space on your router Ronald, you can filter > > it. I _strongly_ disagree with having a hard seperation of production v6 > > and 6bone though. There already exists seperation. Production services > > on production prefixes. 6bone experiments on 6bone prefixes. > > There is a problem when production services are being reached via > a network which is not stable (like 6bone is today). Maybe that means the 2001::/16 production TLAs need to give preference to routes via other 2001::/16 sites instead of routing production traffic over 3ffe::/16 links ? regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From itojun@iijlab.net Wed Jul 31 15:53:33 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Wed, 31 Jul 2002 23:53:33 +0900 Subject: [6bone] Re: routing concern In-Reply-To: tvo's message of Wed, 31 Jul 2002 10:47:16 -0400. Message-ID: <20020731145333.DB0A34B22@coconut.itojun.org> >"they usually do not enforce enough route filters" >- Filters belong on both INGRESS and EGRESS. You are just as responsible >for filtering as they are. of course we do filter bogus routes. >"they usually are not serious enough about IPv6 (if they are serious, >they should have been paying for IPv6 circuit)" >- It must be nice to receive funding from 9 different organizations. Some >of us don't have that luxury. i have many hats. i'm not wearing my KAME hat now. >"tunnel itself is not stable enough due to IPv4 troubles" >- v4 connectivity in Japan that bad eh? Ya know, if you were SERIOUS, >you'd have OC-192 from *your* edge into MULTIPLE peering points in the US >and UK. I guess it's time for all of your v4 peers to drop you, huh? yes, we are serious and have direct connectivity to multiple IXes in the US. unfortunately we don't have any presense in Europe (yet). itojun From Ronald.vanderPol@rvdp.org Wed Jul 31 15:54:43 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Wed, 31 Jul 2002 16:54:43 +0200 Subject: [6bone] Re: routing concern In-Reply-To: References: <20020731134750.GF12460@rvdp.org> Message-ID: <20020731145443.GJ12460@rvdp.org> On Wed, Jul 31, 2002 at 10:27:49 -0400, John Fraizer wrote: > Until that happens, if a peer is > unresponsive and crappy, depeer. Again, just like v4. If transit to site > X is better via A_B_C_X than via D_X, set up a route-map to pref the > A_B_C_X route. Again, just like v4. This is not the problem. The problem is A_B_C_X is looping between B and C and D_E_F_B_C_X is also looping between B and C. Changing peers from A to D does not help. > Just because a connection between two peers is in a v4-in-v4 tunnel does > NOT make that connection a "6bone" connection vs "production" connection > and native v6 peering does not mean that that particular connection is not > a "6bone" connection. True. Did I say otherwise? > > I want an IPv6 network which is *at least* as reliable as the IPv4 > > network is *today*. > > Choose your peering partners wisely then. No different than IPv4. > > Rob from Sprint hit on something that I don't quite agree with. He wants > to limit transit. As indicated above the problem is not with the peering. It has a lot to do with tunnels all over the world and transit by everyone. > Unless we're all going to establish direct peering between > each other (that scales just wonderful, doesn't it?) it is wise for us to > provide transit to each other (pTLA to pTLA). How does that compare to v4? rvdp From michel@arneill-py.sacramento.ca.us Wed Jul 31 16:00:10 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 31 Jul 2002 08:00:10 -0700 Subject: [6bone] semi-newbie Q on IPv6 address planning Message-ID: <2B81403386729140A3A899A8B39B046405E22B@server2000.arneill-py.sacramento.ca.us> Nick, > Do we have to stick to allocating in lots of 8 bits? No. Same is v4, any bit boundary is valid. > Is a /44 allocation valid? Absolutely. In your case, you could use any prefix you want between /33 and /48. The prefixes from /48 to /64 are the customer's responsibility, not yours (except for your infrastructure). > And what is a /126 allocation for a point-to-point link? Not good, it violates RFC2373. You should use a /64 for point-to-point links. It is typical to allocate a /48 for your ptp links. Michel. From michel@arneill-py.sacramento.ca.us Wed Jul 31 16:12:55 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 31 Jul 2002 08:12:55 -0700 Subject: [6bone] Re: routing concern Message-ID: <2B81403386729140A3A899A8B39B046405E22C@server2000.arneill-py.sacramento.ca.us> > Ronald van der Pol wrote: > There is a problem when production services are being > reached via a network which is not stable (like 6bone is > today). I am not saying it is bad that 6bone is not > stable. I just think 6bone should become a network for > doing IPv6 related experiments only, no production. This is the way it's supposed to be already. The 6bone should *not* be used for production. The problem is that people actually use it for production. >> Do you really want to create an island out of the >> production v6 network? Do you want folks on production >> v6 address space to not be able to reach 6bone prefixes? > No, and these are not related. There can be connections > to and from the 6bone. But the routing must be setup in > a way that you never reach production prefixes via the > 6bone (when your origin is not the 6bone). Problem is, the infrastructure does not exist yet for this. To some extent, if the tunneling system did not exist there will be no IPv6 production because there will be too many isolated IPv6 islands. > I want an IPv6 network which is *at least* as reliable as the > IPv4 network is *today*. Simple. Build it. Michel. From tvo@EnterZone.Net Wed Jul 31 16:22:58 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 31 Jul 2002 11:22:58 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: <20020731145443.GJ12460@rvdp.org> Message-ID: On Wed, 31 Jul 2002, Ronald van der Pol wrote: > On Wed, Jul 31, 2002 at 10:27:49 -0400, John Fraizer wrote: > > > Until that happens, if a peer is > > unresponsive and crappy, depeer. Again, just like v4. If transit to site > > X is better via A_B_C_X than via D_X, set up a route-map to pref the > > A_B_C_X route. Again, just like v4. > > This is not the problem. The problem is A_B_C_X is looping between B and C > and D_E_F_B_C_X is also looping between B and C. Changing peers from A to D > does not help. > Ia a routing loop exists, it's because someone is misconfigured or has a broken BGP implementation. It is NOT because the peering session is over a tunnel vs a native V6 connection. If B and C are looping, contact B and C. If they don't respond, call them out on the 6bone list. > > Just because a connection between two peers is in a v4-in-v4 tunnel does > > NOT make that connection a "6bone" connection vs "production" connection > > and native v6 peering does not mean that that particular connection is not > > a "6bone" connection. > > True. Did I say otherwise? You are trying to make distinction between the 6bone and production v6 at the NETWORK layer. There *is* no distinction and as Bill pointed out, there probably won't be. The distinction is in the network PREFIXES. > > > I want an IPv6 network which is *at least* as reliable as the IPv4 > > > network is *today*. > > > > Choose your peering partners wisely then. No different than IPv4. > > > > Rob from Sprint hit on something that I don't quite agree with. He wants > > to limit transit. > > As indicated above the problem is not with the peering. It has a lot to do > with tunnels all over the world and transit by everyone. Nobody is forcing anyone to accept or provide transit to anyone else. The fact of the matter is that right now, we have connectivity because it DOES exist. > > > Unless we're all going to establish direct peering between > > each other (that scales just wonderful, doesn't it?) it is wise for us to > > provide transit to each other (pTLA to pTLA). > > How does that compare to v4? > > rvdp TRANSIT-AS's peer with TRANSIT-AS's. They exchange customer routes. Some TRANSIT-AS's are CUSTOMERS of other TRANSIT-AS's. Granted, the world would be a better place if we ALL peered with EVERYONE else over native layer2 (4v + v6). Until that happens, transit is a fact of life. Since all pTLAs don't peer with all other pTLAs (native or otherwise) there must be transit involved to establish connectivity. If you don't want to provide transit to other pTLAs, you don't have to. If you don't want to accept transit from other pTLAs, prefix-list filter them based on their pTLA assignment. If you don't like the connectivity between you and site-X because it goes over an unreliable transit path, establish your own native/tunnel peering with that site or their pTLA. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From tvo@EnterZone.Net Wed Jul 31 16:25:24 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 31 Jul 2002 11:25:24 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: Message-ID: On Wed, 31 Jul 2002, Rik van Riel wrote: > > Maybe that means the 2001::/16 production TLAs need to give > preference to routes via other 2001::/16 sites instead of > routing production traffic over 3ffe::/16 links ? Now THAT makes perfect sense. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From michel@arneill-py.sacramento.ca.us Wed Jul 31 16:28:58 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 31 Jul 2002 08:28:58 -0700 Subject: [6bone] Re: routing concern Message-ID: <2B81403386729140A3A899A8B39B046405E22D@server2000.arneill-py.sacramento.ca.us> > John Fraizer wrote: > Rob from Sprint hit on something that I don't quite agree with. > He wants to limit transit. Coming from Sprint (no offense Rob), > that makes perfect sense. I live on the other end of the > spectrum. The more transit possibilities you have to a network > you don't DIRECTLY peer with, the more likely you will be able > to reach that network. Even if you DO have direct peering with > that network, having a backup route(s) to them doesn't hurt a > thing. If people don't want backup-transit, that is their > decision. I don't think there needs to be any broad policy > change and especially not among pTLAs. Unless we're all going > to establish direct peering between each other (that scales > just wonderful, doesn't it?) it is wise for us to provide > transit to each other (pTLA to pTLA). During the last 6bone meeting in Minneapolis I presented something related to this issue: http://arneill-py.sacramento.ca.us/ipv6mh/ietf53.ppt The point that Rob makes is perfectly valid. This system where everyone provides transit to everyone has problems. In the discussions I had with many people, there seems to be a consensus that the current v4 tiered structure will apply to IPv6 as well at some point, because the current v6 peering / transit model is economically flawed. In other words, this works because of tunnels. Tunnels are fine for experiments, but not for production. When production-quality is required, people will have to find native links, and this will change the picture. Note that I am not taking sides on the issue. There will be some peering between pTLAs, but the general consensus is that transit will go back to tier-1s the way it is today in v4 (comments on the slides welcomed). Michel. From Robert.Kiessling@de.easynet.net Wed Jul 31 16:56:11 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 31 Jul 2002 16:56:11 +0100 Subject: [6bone] Re: routing concern In-Reply-To: References: Message-ID: John Fraizer writes: > Rob from Sprint hit on something that I don't quite agree with. He wants > to limit transit. Coming from Sprint (no offense Rob), that makes perfect > sense. I live on the other end of the spectrum. The more transit > possibilities you have to a network you don't DIRECTLY peer with, the more > likely you will be able to reach that network. Actually this is not true, and limiting transit does make much sense, for purely technical reasons. More transit in the sense of BGP advertisements does NOT automatically give you better connectivity. In practice, we saw a number of cases where someone provides IPv6 transit (e.g. advertises full BGP table to everyone), but in fact fails to route packets because of some misconfiguration. Such this "transit" caused a blackhole for you. On a performance issue, a transit provider with lots of tunnels across the world will give you short BGP paths, but not good actual paths for the packets. The lesson learned from this should be: look carefully at your transit providers. For good connectivity, your transit provider should be dedicated to providing this service (as opposed to just running it experimentally and not caring), have cluefull staff for IPv6, and should care to have good connectivity itself (as opposed to collecting as many tunnels as possible). A handful of providers fulfulling this will give you much better connectivity than dozends of full BGP peerings. Robert From tvo@EnterZone.Net Wed Jul 31 16:43:07 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 31 Jul 2002 11:43:07 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: <2B81403386729140A3A899A8B39B046405E22C@server2000.arneill-py.sacramento.ca.us> Message-ID: On Wed, 31 Jul 2002, Michel Py wrote: > > Ronald van der Pol wrote: > > There is a problem when production services are being > > reached via a network which is not stable (like 6bone is > > today). I am not saying it is bad that 6bone is not > > stable. I just think 6bone should become a network for > > doing IPv6 related experiments only, no production. > > This is the way it's supposed to be already. The 6bone should *not* be > used for production. The problem is that people actually use it for > production. "12 January 2000 The 6bone is an IPv6 Testbed that is an outgrowth of the IETF IPng project that created the IPv6 protocols intended to eventually replace the current Internet network layer protocols known as IPv4. The 6bone is currently a world wide informal collaborative project, informally operated with oversight from the "NGtrans" (IPv6 Transition) Working Group of the IETF. The 6bone started as a virtual network (using IPv6 over IPv4 tunneling/encapsulation) operating over the IPv4-based Internet to support IPv6 transport, and is slowly migrating to native links for IPv6 transport. The initial 6bone focus was on testing of standards and implementations, while the current focus is more on testing of transition and operational procedures. The 6bone operates under the IPv6 Testing Address Allocation." What I gather from the above, is that the 6bone, for all intents and purposes, is 3ffe::/16. No production services living on 3ffe::/16, no problem. "Production" in my book is COMMERCIAL. If you define "6bone" otherwise, please explain. If you define production otherwise (in the context of 6bone vs production) please explain. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From joao@ripe.net Wed Jul 31 16:56:27 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Wed, 31 Jul 2002 17:56:27 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <2B81403386729140A3A899A8B39B046405E22B@server2000.arneill-py.sacramento.c a.us> References: <2B81403386729140A3A899A8B39B046405E22B@server2000.arneill-py.sacramento.c a.us> Message-ID: At 8:00 -0700 31/7/02, Michel Py wrote: >Nick, > >> Do we have to stick to allocating in lots of 8 bits? >No. Same is v4, any bit boundary is valid. > >> Is a /44 allocation valid? >Absolutely. In your case, you could use any prefix you want between /33 >and /48. The prefixes from /48 to /64 are the customer's responsibility, >not yours (except for your infrastructure). > >> And what is a /126 allocation for a point-to-point link? > >Not good, it violates RFC2373. Why? > You should use a /64 for point-to-point >links. Why? > It is typical to allocate a /48 for your ptp links. It is convenient, yes. Joao From pim@ipng.nl Wed Jul 31 17:27:25 2002 From: pim@ipng.nl (Pim van Pelt) Date: Wed, 31 Jul 2002 18:27:25 +0200 Subject: [6bone] Re: routing concern In-Reply-To: References: Message-ID: <20020731162725.GA24116@bfib.colo.bit.nl> On Wed, Jul 31, 2002 at 11:25:24AM -0400, John Fraizer wrote: | On Wed, 31 Jul 2002, Rik van Riel wrote: | | > | > Maybe that means the 2001::/16 production TLAs need to give | > preference to routes via other 2001::/16 sites instead of | > routing production traffic over 3ffe::/16 links ? | | Now THAT makes perfect sense. I can give you examples of RIR-allocated TLAs that do a lousy job in routing. I can also give you examples of 6BONE-allocated TLAs that do an outstanding job (even over more than one IXP). I don't think routing stability has much to do with the prefix one uses... groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From Francis.Dupont@enst-bretagne.fr Wed Jul 31 17:35:59 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Wed, 31 Jul 2002 18:35:59 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: Your message of Wed, 31 Jul 2002 17:56:27 +0200. Message-ID: <200207311635.g6VGZx6o021198@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: >> And what is a /126 allocation for a point-to-point link? > >Not good, it violates RFC2373. Why? => if the first three bits of an unicast address are not 000 then the interface ID has 64 bits, etc. > You should use a /64 for point-to-point links. Why? => same, and this is true for any link which doesn't use a special format for unicast addresses (i.e., for any physical link at least!) > It is typical to allocate a /48 for your ptp links. It is convenient, yes. => for the set of p2p links (not a /48 for each :-). Regards Francis.Dupont@enst-bretagne.fr PS: the equivalent of "unnumbered" p2p links is p2p links with only link-local addresses. They use of course no global addresses. Look at the Itojun's draft about dialup access for p2p links out of the backbone (where global addressing is necessary for easy management). From aservin@campus.mty.itesm.mx Wed Jul 31 17:52:38 2002 From: aservin@campus.mty.itesm.mx (aservin@campus.mty.itesm.mx) Date: Wed, 31 Jul 2002 11:52:38 -0500 Subject: [6bone] Cisco Question Message-ID: <3B82436C0002C73A@campus.mty.itesm.mx> May be this is not the rigth place but I do not know any Cisco mailing list relative to IPv6. So, the question is: Is any command similar to "sh ip bgp summary" but for the use with IPv6? I need to see the sumary status of all our BGP+ neighbors. The last command only give me the status of BGP IPv4 neighbors. Thank in advance, -as From bmanning@ISI.EDU Wed Jul 31 18:16:13 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 31 Jul 2002 10:16:13 -0700 (PDT) Subject: [6bone] Cisco Question In-Reply-To: <3B82436C0002C73A@campus.mty.itesm.mx> from "aservin@campus.mty.itesm.mx" at "Jul 31, 2 11:52:38 am" Message-ID: <200207311716.g6VHGDM26364@boreas.isi.edu> % May be this is not the rigth place but I do not know any Cisco mailing % list relative to IPv6. % % So, the question is: % % Is any command similar to "sh ip bgp summary" but for the use with IPv6? % % I need to see the sumary status of all our BGP+ neighbors. The last command % only give me the status of BGP IPv4 neighbors. % % Thank in advance, % -as % neubah>sh bgp ipv sum BGP router identifier 192.0.1.1, local AS number 4554 BGP table version is 8710, main routing table version 8710 380 network entries and 2705 paths using 224040 bytes of memory 28064 BGP path attribute entries using 1572424 bytes of memory 25480 BGP AS-PATH entries using 721502 bytes of memory 63 BGP community entries using 1608 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 23336 BGP filter-list cache entries using 280032 bytes of memory Dampening enabled. 19 history paths, 26 dampened paths BGP activity 147257/475234 prefixes, 350551/211461 paths, scan interval 15 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd .... works for me. neubah>sh ver Cisco Internetwork Operating System Software IOS (tm) GS Software (GSR-P-M), Version 12.0(19)ST1, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) ... will need to upgrade soon... :) -- --bill From pekkas@netcore.fi Wed Jul 31 18:51:54 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Wed, 31 Jul 2002 20:51:54 +0300 (EEST) Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: Message-ID: Check out http://search.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-04.txt, it should answer most of your questions. The draft is in process (hopefully near the end) in getting into an Informational RFC. On Wed, 31 Jul 2002, Joao Luis Silva Damas wrote: > At 8:00 -0700 31/7/02, Michel Py wrote: > >Nick, > > > >> Do we have to stick to allocating in lots of 8 bits? > >No. Same is v4, any bit boundary is valid. > > > >> Is a /44 allocation valid? > >Absolutely. In your case, you could use any prefix you want between /33 > >and /48. The prefixes from /48 to /64 are the customer's responsibility, > >not yours (except for your infrastructure). > > > >> And what is a /126 allocation for a point-to-point link? > > > >Not good, it violates RFC2373. > > Why? > > > You should use a /64 for point-to-point > >links. > > Why? > > > It is typical to allocate a /48 for your ptp links. > > It is convenient, yes. > > Joao > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > -- 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 tvo@EnterZone.Net Wed Jul 31 20:04:22 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 31 Jul 2002 15:04:22 -0400 (EDT) Subject: [6bone] Re: routing concern In-Reply-To: Message-ID: On 31 Jul 2002, Robert Kiessling wrote: > John Fraizer writes: > > Actually this is not true, and limiting transit does make much sense, > for purely technical reasons. More transit in the sense of BGP > advertisements does NOT automatically give you better connectivity. > > In practice, we saw a number of cases where someone provides IPv6 > transit (e.g. advertises full BGP table to everyone), but in fact > fails to route packets because of some misconfiguration. Such this > "transit" caused a blackhole for you. Um, that's not transit. That's a misconfigured peer. Leaking a prefix and providing TRANSIT to a prefix are two different things folks. When I refer to transit, I am referring to working paths. > On a performance issue, a transit provider with lots of tunnels across > the world will give you short BGP paths, but not good actual paths for > the packets. Again, the broad brush is being used. Each path is unique. Granted, if someone just blindly builds tunnels to anyone and everyone, they may very well end up with short AS paths and lousy end-to-end performance. There are cases where a tunnel direct to the peer will provide better performance. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From craig_latzke@hp.com Wed Jul 31 20:43:22 2002 From: craig_latzke@hp.com (LATZKE,CRAIG (HP-FtCollins,ex1)) Date: Wed, 31 Jul 2002 15:43:22 -0400 Subject: [6bone] Cisco Question Message-ID: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122 t/122t2/ipv6/ftipv6r.htm#xtocid0 ...is a great place to find all the IPv6 CISCO commands. Many CISCO IPv6 commands (like your example) reverse fields or just have a slightly different syntax. With commands like "sh bgp ipv6 sum", you'll soon find yourself typing "sh bgp ip sum" and "sh ipv6 bgp sum" and other variations that don't work. Another that got me was "ipv6 traffic-filter". - Craig ----- Craig Latzke Network Research Engineer 970.898.2399 Hewlett-Packard -----Original Message----- From: aservin@campus.mty.itesm.mx [mailto:aservin@campus.mty.itesm.mx] Sent: Wednesday, July 31, 2002 10:53 AM To: 6bone@ISI.EDU Subject: [6bone] Cisco Question May be this is not the rigth place but I do not know any Cisco mailing list relative to IPv6. So, the question is: Is any command similar to "sh ip bgp summary" but for the use with IPv6? I need to see the sumary status of all our BGP+ neighbors. The last command only give me the status of BGP IPv4 neighbors. Thank in advance, -as _______________________________________________ 6bone mailing list 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone From pasky@pasky.ji.cz Wed Jul 31 21:01:07 2002 From: pasky@pasky.ji.cz (Petr Baudis) Date: Wed, 31 Jul 2002 22:01:07 +0200 Subject: [6bone] Re: routing concern In-Reply-To: <20020731101035.GA12460@rvdp.org> References: <2B81403386729140A3A899A8B39B046405E225@server2000.arneill-py.sacramento.ca.us> <20020731101035.GA12460@rvdp.org> Message-ID: <20020731200106.GB4117@pasky.ji.cz> Dear diary, on Wed, Jul 31, 2002 at 12:10:35PM CEST, I got a letter, where Ronald van der Pol told me, that... > On Tue, Jul 30, 2002 at 11:13:36 -0700, Michel Py wrote: > > > As I said before, the 6bone is the right place for this. Has anyone been > > hurt? Anyone lost money? The lessons we collectively learn each time > > someone messes up a route are far more valuable than the consequences of > > messing up the route. > > Is it time to start making a clear distinction between IPv6 production > and IPv6 experimentation/learning? I think today the 6bone is used for > both. > > Many use IPv6 for their daily work *). We *need* a stable network for > that. If we don't do that we risk scaring people away from IPv6. Most > OSes support IPv6 nowadays. When an enduser starts using IPv6 for the > first time and she notices all kinds of networking problems, many will > think: "OK, let's turn off IPv6. It does not work." > > The RIR prefixes are meant for IPv6 production. So, I think they should > not be used on the 6bone. The 6bone should only be used for experiments > and possibly learning. And on the other hand, I think production services > should not use 6bone prefixes, but RIR prefixes. > > rvdp > > *) I frequently use ftp, cvs and http over IPv6 to sites far away in > the internet. Too often, there are routing problems and IPv6 traffic > is blackholed (routing loops, etc). Most application time out and try > IPv4. But this means annoying delays. Many of these problems occur > because people are running production services over the 6bone. This is wild world and natural processes mostly rule this world. Basically, I believe that unreliability of the IPv6 internet is generally caused by the fact that it does not run native, but tunnelled through IPv4. And people tend to create peerings through tunnels even with peers they have poor latency to etc. It's not the 2001::/16 what saves you, it's the unwritten (?) rule that native links usually live inside 2001::/16 and tunnels inside 3ffe::/16. As people continue with establishing of native IPv6 links and peerings, the situation improves and the native peering usually tends to be much more stable and reliable than the peering through tunnels, especially when driven on some official base (and this is also another difference between IPv4 and IPv6, IPv4 peerings are protected by various contracts and agreements, being ran on commercial base; IPv6 usually aren't [altough there are obviously exceptions already]). And as the time goes on, people obviously tend to sacrifice the tunnel peerings for native ones and the reliability improves. The natural process. You can obviously push it a lot by preferring native peerings before the tunneled ones, and this should probably become another written unwritten rule. This has been said before already in few mails undirectly, this mail is meant generally as a summary of that view (not the only one here, obviously, just the one I agree with). -- Petr "Pasky" Baudis * ELinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI occassional hacker . You can get much further with a kind word and a gun than you can with a kind word alone. -- Al Capone . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From sp@iphh.net Wed Jul 31 21:06:25 2002 From: sp@iphh.net (Sascha E. Pollok) Date: Wed, 31 Jul 2002 22:06:25 +0200 (CEST) Subject: [6bone] Cisco Question In-Reply-To: Message-ID: Folks, may I just hop in here and ask what kind of IOS version is currently most preferred on non-12k boxes? Someone suggested 12.2(2)T1 while someone else said that 12.2(8)T5 is a good thing. Anyone else? Thanks a lot Sascha On Wed, 31 Jul 2002, LATZKE,CRAIG (HP-FtCollins,ex1) wrote: > http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122 > t/122t2/ipv6/ftipv6r.htm#xtocid0 > > ...is a great place to find all the IPv6 CISCO commands. Many CISCO IPv6 > commands (like your example) reverse fields or just have a slightly > different syntax. With commands like "sh bgp ipv6 sum", you'll soon find > yourself typing "sh bgp ip sum" and "sh ipv6 bgp sum" and other variations > that don't work. Another that got me was "ipv6 traffic-filter". > > - Craig > > ----- > Craig Latzke > Network Research Engineer > 970.898.2399 > Hewlett-Packard > > -----Original Message----- > From: aservin@campus.mty.itesm.mx [mailto:aservin@campus.mty.itesm.mx] > Sent: Wednesday, July 31, 2002 10:53 AM > To: 6bone@ISI.EDU > Subject: [6bone] Cisco Question > > > May be this is not the rigth place but I do not know any Cisco > mailing > list relative to IPv6. > > So, the question is: > > Is any command similar to "sh ip bgp summary" but for the use with IPv6? > > I need to see the sumary status of all our BGP+ neighbors. The last > command > only give me the status of BGP IPv4 neighbors. > > Thank in advance, > -as > > > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From michel@arneill-py.sacramento.ca.us Wed Jul 31 21:21:53 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 31 Jul 2002 13:21:53 -0700 Subject: [6bone] Cisco Question Message-ID: <2B81403386729140A3A899A8B39B046406C9F1@server2000.arneill-py.sacramento.ca.us> I run 12.2(4)T3 back from 12.2(8)T1 that had AM issues. -----Original Message----- From: Sascha E. Pollok [mailto:sp@iphh.net] Sent: Wednesday, July 31, 2002 1:06 PM To: LATZKE,CRAIG (HP-FtCollins,ex1) Cc: 6bone@ISI.EDU Subject: RE: [6bone] Cisco Question Folks, may I just hop in here and ask what kind of IOS version is currently most preferred on non-12k boxes? Someone suggested 12.2(2)T1 while someone else said that 12.2(8)T5 is a good thing. Anyone else? Thanks a lot Sascha On Wed, 31 Jul 2002, LATZKE,CRAIG (HP-FtCollins,ex1) wrote: > http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft /122 > t/122t2/ipv6/ftipv6r.htm#xtocid0 > > ...is a great place to find all the IPv6 CISCO commands. Many CISCO IPv6 > commands (like your example) reverse fields or just have a slightly > different syntax. With commands like "sh bgp ipv6 sum", you'll soon find > yourself typing "sh bgp ip sum" and "sh ipv6 bgp sum" and other variations > that don't work. Another that got me was "ipv6 traffic-filter". > > - Craig > > ----- > Craig Latzke > Network Research Engineer > 970.898.2399 > Hewlett-Packard > > -----Original Message----- > From: aservin@campus.mty.itesm.mx [mailto:aservin@campus.mty.itesm.mx] > Sent: Wednesday, July 31, 2002 10:53 AM > To: 6bone@ISI.EDU > Subject: [6bone] Cisco Question > > > May be this is not the rigth place but I do not know any Cisco > mailing > list relative to IPv6. > > So, the question is: > > Is any command similar to "sh ip bgp summary" but for the use with IPv6? > > I need to see the sumary status of all our BGP+ neighbors. The last > command > only give me the status of BGP IPv4 neighbors. > > Thank in advance, > -as > > > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > _______________________________________________ 6bone mailing list 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone From rain@bluecherry.net Wed Jul 31 21:54:55 2002 From: rain@bluecherry.net (Ben Winslow) Date: 31 Jul 2002 15:54:55 -0500 Subject: [6bone] Cisco Question In-Reply-To: References: Message-ID: <1028148895.24396.7.camel@halcyon> --=-968t/N0Q8bAVXfQaYZ/W Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2002-07-31 at 15:06, Sascha E. Pollok wrote: > Folks, >=20 > may I just hop in here and ask what kind of > IOS version is currently most preferred on non-12k boxes? > Someone suggested 12.2(2)T1 while someone else said that 12.2(8)T5 is a > good thing. Anyone else? I was having some stability problems with 12.2(8)T5, but they seem to have gone away (perhaps the router was still running 12.2(8)T when it last crashed, I don't remember.) >=20 > Thanks a lot > Sascha >=20 --=20 Ben Winslow (rain@bluecherry.net) : When you are in it up to your System Administrator : ears, keep your mouth shut. =20 Bluecherry Internet Services :=20 http://www.bluecherry.net/ :=20 (573) 592-0800 :=20 --=-968t/N0Q8bAVXfQaYZ/W Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9SE6f2/SfDQAyrVERArvoAKCAFr309Ab1LiankQT/khu/VsQDUwCgq/Mm ChYnfZwYsz+iyjgaqLGw4xs= =cDlY -----END PGP SIGNATURE----- --=-968t/N0Q8bAVXfQaYZ/W-- From Ronald.vanderPol@rvdp.org Wed Jul 31 22:03:55 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Wed, 31 Jul 2002 23:03:55 +0200 Subject: [6bone] Re: routing concern In-Reply-To: <20020731200106.GB4117@pasky.ji.cz> References: <2B81403386729140A3A899A8B39B046405E225@server2000.arneill-py.sacramento.ca.us> <20020731101035.GA12460@rvdp.org> <20020731200106.GB4117@pasky.ji.cz> Message-ID: <20020731210355.GA17658@rvdp.org> On Wed, Jul 31, 2002 at 22:01:07 +0200, Petr Baudis wrote: > And as the time goes on, people obviously tend to sacrifice the > tunnel peerings for native ones and the reliability improves. The natural > process. This is what we have been trying to do for the last couple of years, but without much success. The 6bone is still too unstable. Look at the OS mailing lists. End users are disabling IPv6 in their OS because it does not work. We don't need a stable IPv6 network tomorrow. We need it today. I doubt if we can make the 6bone stable very soon. Their is also the question what the current 6bone is supposed to be. Is it an IPv6 network that evolves in a globally production/ commercial stable IPv6 network? Or is it becoming a network for doing IPv6 related experiments? We may need such a network in the next few years for doing (possibly disruptive) testing (multihoming, completely new addressing and/or routing, etc.) rvdp From bmanning@ISI.EDU Wed Jul 31 22:15:45 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 31 Jul 2002 14:15:45 -0700 (PDT) Subject: [6bone] Re: routing concern In-Reply-To: <20020731210355.GA17658@rvdp.org> from Ronald van der Pol at "Jul 31, 2 11:03:55 pm" Message-ID: <200207312115.g6VLFjs27933@boreas.isi.edu> % On Wed, Jul 31, 2002 at 22:01:07 +0200, Petr Baudis wrote: % % > And as the time goes on, people obviously tend to sacrifice the % > tunnel peerings for native ones and the reliability improves. The natural % > process. % % This is what we have been trying to do for the last couple of % years, but without much success. The 6bone is still too unstable. % Look at the OS mailing lists. End users are disabling IPv6 in % their OS because it does not work. % % We don't need a stable IPv6 network tomorrow. We need it today. % I doubt if we can make the 6bone stable very soon. For me, I have three peers that transit native v4 for me. Due to a variety of conditions, none of them will run native v6 with me in a merged v4/v6 connection. They are -all- tunnels. Go figure... why do/will commercial providers do this? (hint... SLA's and problems with "converged" networks come to my mind... :) To borrow a line from the v6 panel at the last IETF, "what can you do with v6 that you can't do with v4?" Finding that thing for (many/most) users will drive v6 deployment/stability. Or it could be that v6 is not something that will boost quarterly profits... this quarter. It may take several more years to mature. --bill From paitken@cisco.com Wed Jul 31 22:22:34 2002 From: paitken@cisco.com (Paul Aitken) Date: Wed, 31 Jul 2002 22:22:34 +0100 Subject: [6bone] Cisco Question References: <3B82436C0002C73A@campus.mty.itesm.mx> Message-ID: <3D48551A.9080303@cisco.com> > May be this is not the rigth place but I do not know any Cisco mailing > list relative to IPv6. If you're running an image from CCO, you should contact cisco's Technical Assistance Centre -> tac@cisco.com, http://www.cisco.com/tac. If you're running an IPv6 EFT image (or have very specific IPv6 questions, or 6bone issues) you can contact us at ipv6-support@cisco.com. Also visit http://www.cisco.com/ipv6 and follow the links, especially the "View Cisco IOS IPv6 Technical Documents" link. Cheers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From paitken@cisco.com Wed Jul 31 22:27:22 2002 From: paitken@cisco.com (Paul Aitken) Date: Wed, 31 Jul 2002 22:27:22 +0100 Subject: [6bone] Cisco Question References: Message-ID: <3D48563A.6030502@cisco.com> CRAIG LATZKE wrote: > Many CISCO IPv6 commands (like your example) reverse fields or just > have a slightly different syntax. With commands like "sh bgp ipv6 > sum", you'll soon find yourself typing "sh bgp ip sum" and "sh ipv6 > bgp sum" and other variations that don't work. Sorry if you find this confusing, but the choice was made after consultation with our IPv6 EFT customers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From paitken@cisco.com Wed Jul 31 22:35:18 2002 From: paitken@cisco.com (Paul Aitken) Date: Wed, 31 Jul 2002 22:35:18 +0100 Subject: [6bone] Cisco Question References: Message-ID: <3D485816.8020201@cisco.com> Sascha E. Pollok wrote: > > may I just hop in here and ask what kind of > IOS version is currently most preferred on non-12k boxes? > Someone suggested 12.2(2)T1 while someone else said that 12.2(8)T5 is a > good thing. Anyone else? 12.2(2)T1 is older than 12.2(8)T5 and has less IPv6 features and less bug fixes. If "someone" had meant to say "12.2(2)T" (ie, not T1) then they were telling you the *minimum* IOS version for IPv6 functionality, not the best. Whereas 12.2(8)T5 is one of the latest IOS versions. At http://www.cisco.com/ipv6 we say: "We highly recommended selecting the latest available Cisco IOS T release". So generally it'd be good to choose a 12.2(8)T release over a 12.2(2)T release. Cheers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From randy@psg.com Wed Jul 31 22:37:17 2002 From: randy@psg.com (Randy Bush) Date: Wed, 31 Jul 2002 14:37:17 -0700 Subject: [6bone] Re: routing concern References: <2B81403386729140A3A899A8B39B046405E225@server2000.arneill-py.sacramento.ca.us> <20020731101035.GA12460@rvdp.org> <20020731200106.GB4117@pasky.ji.cz> <20020731210355.GA17658@rvdp.org> Message-ID: > The 6bone is still too unstable. Look at the OS mailing > lists. End users are disabling IPv6 in their OS because it does > not work. it has cost me days! > We don't need a stable IPv6 network tomorrow. We need it today. > I doubt if we can make the 6bone stable very soon. ever. tunneling may be good for a very tentative experiment. and it can be politically useful. but for anything production-like, it simply does not have anything like the reliability and scale needed for real use by folk just wanting their packets to be delivered. > Their is also the question what the current 6bone is supposed to > be. Is it an IPv6 network that evolves in a globally production/ > commercial stable IPv6 network? i hope not, as it just can't technically and operationally do so. to learn the difference between a router as a forwarding engine, and a router as a tcp stack, just run a tcp stack tester against a cisco on a local lan. and this is why multi-hop ebgp sessions break so easily. randy From pasky@pasky.ji.cz Wed Jul 31 22:39:41 2002 From: pasky@pasky.ji.cz (Petr Baudis) Date: Wed, 31 Jul 2002 23:39:41 +0200 Subject: [6bone] Re: routing concern In-Reply-To: <20020731210355.GA17658@rvdp.org> References: <2B81403386729140A3A899A8B39B046405E225@server2000.arneill-py.sacramento.ca.us> <20020731101035.GA12460@rvdp.org> <20020731200106.GB4117@pasky.ji.cz> <20020731210355.GA17658@rvdp.org> Message-ID: <20020731213941.GC4117@pasky.ji.cz> Dear diary, on Wed, Jul 31, 2002 at 11:03:55PM CEST, I got a letter, where Ronald van der Pol told me, that... > On Wed, Jul 31, 2002 at 22:01:07 +0200, Petr Baudis wrote: > > > And as the time goes on, people obviously tend to sacrifice the > > tunnel peerings for native ones and the reliability improves. The natural > > process. > > This is what we have been trying to do for the last couple of > years, but without much success. The 6bone is still too unstable. > Look at the OS mailing lists. End users are disabling IPv6 in > their OS because it does not work. > > We don't need a stable IPv6 network tomorrow. We need it today. > I doubt if we can make the 6bone stable very soon. Again, this is not problem of 6bone, but problem of its users. They must move from tunnel peerings to native peerings, and then they will also move from 6bone. When you will cut out 6bone, you will just force them to move all their tunnelled links etc to 2001::/16 space, polluting it terribly, making it impossible to distinguish Bad Peers and Good Peers easily. And you will just make situation worse in another part of IPv6 internet. > Their is also the question what the current 6bone is supposed to > be. Is it an IPv6 network that evolves in a globally production/ > commercial stable IPv6 network? Or is it becoming a network for > doing IPv6 related experiments? We may need such a network in > the next few years for doing (possibly disruptive) testing > (multihoming, completely new addressing and/or routing, etc.) I believe that it's both. It evolves in a globally production IPv6 network as much as its members will evolve in commercial stable IPv6 providers, however as they will evolve, they will move to native links and to 2001::/16. And then 6bone will be left free for those strange geeks playing with sci-fi technologies ;-). And _then_ the 6bone delegation and routing policy should be changed, and peering with newly delegated 6bone delegations (the old ones will hopefully just devolve by time) should be crafted carefully, and generally no transit should be routed through them. -- Petr "Pasky" Baudis * ELinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI occassional hacker . You can get much further with a kind word and a gun than you can with a kind word alone. -- Al Capone . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From pfs@cisco.com Wed Jul 31 22:43:08 2002 From: pfs@cisco.com (Philip Smith) Date: Thu, 01 Aug 2002 07:43:08 +1000 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <012301c23306$082ecb60$53e173cb@arc.net.my> Message-ID: <5.1.0.14.2.20020801073331.03a3ea60@lint.cisco.com> Nick, In addition to the other answers: rfc2374 is basically out of date - the terminology and boundaries referring to TLA, NLA etc are not applicable any more. So, your /32 is yours to subdivide as you wish - the minimum amount you give to any site is a /48, you use /64 for point-to-point links (and as Michel said, pick a /48 block to number your p-t-p links out of - which gives you 65k p-t-ps). Why pick a /40 for your ISP customers - just give them what they require and can justify, as you do with IPv4 - you are announcing only your /32 aggregate to the Internet, the subprefixes won't ordinarily be visible, so it's up to you how you want things to appear within your own backbone. Note that when you "run out" of your /32 and need more address space, I'd imagine that the registries would require a similar documentation effort to what you are currently doing for your IPv4 allocation, so it is highly advisable to be prudent in how you distribute. As for case studies, well, networks are all different - as for IPv4, doing a case study for address space distribution depends so much on local circumstance. (Note that RFC2374 expected ISPs to be shoe-horned into one particular model, a model which many operators couldn't work with.) philip -- At 19:34 24/07/2002 +0800, Nick Kraal wrote: >I heard that this mailing-list holds the most experienced IPv6 prefix and IP >address allocation planners. I am in the middle of deploying our IPv6 >network and in some mental block when it comes to IP address prefix >planning. Basically we have been allocated a /32 from APNIC and need some >advice/pointers in further allocating IPv6 addresses and prefixes. > >Have read RFC2373/2374/3177 on this. Basically we plan to allocate /48 for >end-customers and /40 for our pNLA customers. So basically for a /48 >allocation I have the full 16 bits to play around with and for a /40 >allocation only 8 bits leaving the last 8 bits in this field for the pNLA to >assign to their end customers. The end customers in both cases allocate >further networks in the SLA field. Reading on the web there are many methods >or allocating these bits ranging from allocating some bits: > >a. differentiate core from customer networks e.g. between /40, /48, /64 >b. geographical PoP sites and further bits to do point a. above > >Have looked at the websites on this for SLAC, Stanford and Internet2, >Abilene. Are there any BCPs out there advising on this or are we on our own. >I have worked something out based on the information from the Internet -but >looks quite dodgy. > >Do we have to stick to allocating in lots of 8 bits? Is a /44 allocation >valid? And what is a /126 allocation for a point-to-point link? I thought >the last /64 is reserved for the EUI-64 interface ID. > >Would appreciate any pointers/hints/websites/etc on this. > >-nick/ > >_______________________________________________ >6bone mailing list >6bone@mailman.isi.edu >http://mailman.isi.edu/mailman/listinfo/6bone From itojun@iijlab.net Wed Jul 31 23:33:18 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Thu, 01 Aug 2002 07:33:18 +0900 Subject: [6bone] Re: routing concern In-Reply-To: tvo's message of Wed, 31 Jul 2002 11:43:07 -0400. Message-ID: <20020731223318.53D484B22@coconut.itojun.org> >> This is the way it's supposed to be already. The 6bone should *not* be >> used for production. The problem is that people actually use it for >> production. >What I gather from the above, is that the 6bone, for all intents and >purposes, is 3ffe::/16. No production services living on 3ffe::/16, no >problem. "Production" in my book is COMMERCIAL. > >If you define "6bone" otherwise, please explain. If you define production >otherwise (in the context of 6bone vs production) please explain. the problem is that there's no distinction between sTLA cloud and pTLA cloud - they are overwrapped, and most of sTLA sites do hold pTLA address with them too. if we could split these two clouds into two (interconnected via few routers), it would be very nice, but i don't think it is going to be possible. so we need to harden 6bone (= pTLA cloud). itojun From pfs@cisco.com Wed Jul 31 23:33:09 2002 From: pfs@cisco.com (Philip Smith) Date: Thu, 01 Aug 2002 08:33:09 +1000 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <20020731221825.GJ28593@login.ecs.soton.ac.uk> References: <5.1.0.14.2.20020801073331.03a3ea60@lint.cisco.com> <012301c23306$082ecb60$53e173cb@arc.net.my> <5.1.0.14.2.20020801073331.03a3ea60@lint.cisco.com> Message-ID: <5.1.0.14.2.20020801082813.03a3ed78@lint.cisco.com> At 23:18 31/07/2002 +0100, Tim Chown wrote: >Under the old /35 regime, a /29 was actually reserved for you to grow >into, for aggregation sake. Is the /32 still growable to an aggregated >/29 now, or /26, or what? The reserved /29 is no more. So if you got a /35 under the old scheme, you can grow it to a /32 (as many folks are doing now) on application to the RIR. When you require more address space after the initial /32, you return to the registries. Pretty much as we do in IPv4-land... BTW, ftp://ftp.cs.duke.edu/pub/narten/ietf/global-ipv6-assign-2002-06-26.txt describes the IPv6 address assignment and allocation policy of the three registries... So what's gone before is no more, afaik. philip --