From jeroen@unfix.org Thu Aug 1 00:15:12 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 1 Aug 2002 01:15:12 +0200 Subject: [6bone] Re: routing concern In-Reply-To: <20020731223318.53D484B22@coconut.itojun.org> Message-ID: <005301c238e8$1f31a2f0$420d640a@unfix.org> itojun@iijlab.net wrote: > 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). And today it's another thursday, so I am going to make another summer cleanup email when the routing report comes in. Only this time I am going to yell a bit harder, especially to those who didn't clean up their stuff. Greets, Jeroen From riel@conectiva.com.br Thu Aug 1 02:23:19 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Wed, 31 Jul 2002 22:23:19 -0300 (BRT) Subject: [6bone] Re: routing concern In-Reply-To: <20020731223318.53D484B22@coconut.itojun.org> Message-ID: On Thu, 1 Aug 2002 itojun@iijlab.net wrote: > 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). One thing possible to make 6bone traffic more reliable is BGP confederations. Inside the COMPENDIUM pTLA we have multiple ipv6 islands in a BGP confederation, advertising the same BGP AS number to external peers and non-confed islands in the pTLA. If routing to one of the central ipv6 islands is lost, the packets will be routed via one of the others. Of course, performance is bad in a pTLA as geographically dispersed as COMPENDIUM, but ipv6 has proven to be much more reliable for me than ipv4 has ever been. This idea could be used by organisations who are close to each other geographically and by hop count ... something vaguely like multihoming, without violating RFC 2772. Having 4 well-connected (to each other) sites participate in the same pTLA and same BGP confederation could make the 6bone traffic more reliable for both the sites themselves and the peers they transit for. Performance can be regained later when the sites move to native ipv6 links. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From pekkas@netcore.fi Thu Aug 1 03:45:18 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 1 Aug 2002 05:45:18 +0300 (EEST) Subject: [6bone] Cisco Question In-Reply-To: Message-ID: On Wed, 31 Jul 2002, 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? If you run in "production", you want 12.0(22)S if you use GSR. If not, upcoming 12.2(11)S will also work in some other architectures. In test environments, the latest T-series 12.2(8)T5 is a good choice, or the latest EFT (beta) image. > 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 > -- 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 pekkas@netcore.fi Thu Aug 1 03:48:59 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 1 Aug 2002 05:48:59 +0300 (EEST) Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <5.1.0.14.2.20020801082813.03a3ed78@lint.cisco.com> Message-ID: On Thu, 1 Aug 2002, Philip Smith wrote: > 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. Practically, it still is, until there are assignments from that /29.. > When you require more address space after the initial /32, you return > to the registries. Pretty much as we do in IPv4-land... Right... -- 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 Thu Aug 1 07:25:55 2002 From: pasky@pasky.ji.cz (Petr Baudis) Date: Thu, 1 Aug 2002 08:25:55 +0200 Subject: [6bone] Re: routing concern In-Reply-To: References: <20020731223318.53D484B22@coconut.itojun.org> Message-ID: <20020801062555.GE4117@pasky.ji.cz> Dear diary, on Thu, Aug 01, 2002 at 03:23:19AM CEST, I got a letter, where Rik van Riel told me, that... > On Thu, 1 Aug 2002 itojun@iijlab.net wrote: > > > 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). > > One thing possible to make 6bone traffic more reliable is > BGP confederations. Inside the COMPENDIUM pTLA we have > multiple ipv6 islands in a BGP confederation, advertising > the same BGP AS number to external peers and non-confed > islands in the pTLA. > > If routing to one of the central ipv6 islands is lost, > the packets will be routed via one of the others. > > Of course, performance is bad in a pTLA as geographically > dispersed as COMPENDIUM, but ipv6 has proven to be much > more reliable for me than ipv4 has ever been. > > This idea could be used by organisations who are close to > each other geographically and by hop count ... something > vaguely like multihoming, without violating RFC 2772. > > Having 4 well-connected (to each other) sites participate > in the same pTLA and same BGP confederation could make the > 6bone traffic more reliable for both the sites themselves > and the peers they transit for. > > Performance can be regained later when the sites move to > native ipv6 links. Well, this concept is already tested on 6bone - it's exactly what we do inside XS26 (now almost even with the last paragraph :). -- 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 michel@arneill-py.sacramento.ca.us Thu Aug 1 08:02:53 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 1 Aug 2002 00:02:53 -0700 Subject: [6bone] Re: routing concern Message-ID: <2B81403386729140A3A899A8B39B046405E231@server2000.arneill-py.sacramento.ca.us> > Petr Baudis wrote: I think that Petr's post is a very good summary. > 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. It's not the only reason, though. The fact that the 6bone is free does not help, and I have to say that I am not going to get up in the middle of the night to troubleshoot a 6bone problem. > 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. This is very true. Michel. > 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). From michel@arneill-py.sacramento.ca.us Thu Aug 1 08:07:46 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 1 Aug 2002 00:07:46 -0700 Subject: [6bone] Re: routing concern Message-ID: <2B81403386729140A3A899A8B39B046405E232@server2000.arneill-py.sacramento.ca.us> > John Fraizier wrote: > 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. In mine too. > If you define "6bone" otherwise, please explain. If you > define production otherwise (in the context of 6bone vs > production) please explain. I think that the 6bone is a little more than 3ffe::/16. What exactly I;m not completely sure. BTW, I was curious about the 6bone meeting in Yokohama, as there have been talks with the RIRs. Did I miss the minutes? Michel. From michel@arneill-py.sacramento.ca.us Thu Aug 1 08:24:47 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 1 Aug 2002 00:24:47 -0700 Subject: [6bone] Re: routing concern Message-ID: <2B81403386729140A3A899A8B39B046405E233@server2000.arneill-py.sacramento.ca.us> > Ronald van der Pol wrote: > Look at the OS mailing lists. End users are disabling > IPv6 in their OS because it does not work. It does not work because there is no killer app, and no money to make it work. Especially in the US, the common thinking is "why bother with IPv6?" It does not bring money, and does not solve much of the v4 issues. > We don't need a stable IPv6 network tomorrow. We need it today. Your $10 Billion donation to build it is appreciated. > Or is it becoming a network for doing IPv6 related > experiments? It has always been, IMHO. > We may need such a network in the next few years for doing > (possibly disruptive) testing (multihoming, completely new > addressing and/or routing, etc.) And we *will* need these experiments. How do you expect IPv6 to be stable without a multihoming solution? A significant part of the crap we see in the routing table is the direct consequence of the lack of a multihoming solution. It all comes down to money. No operator is going to build an IPv6 infrastructure without knowing the outcome of the multihoming solution, as they don't want to do the job twice, especially when there is no money to pay for it. Michel. From joao@ripe.net Thu Aug 1 09:14:37 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Thu, 1 Aug 2002 10:14:37 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <5.1.0.14.2.20020801073331.03a3ea60@lint.cisco.com> References: <5.1.0.14.2.20020801073331.03a3ea60@lint.cisco.com> Message-ID: At 7:43 +1000 1/8/02, Philip Smith wrote: >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). Indeed, and that is my concern. The experts are referring people to outdated documents describing features that in some cases the WG has dropped *years* ago (TLA, NLA, the 8 bit reserved field). Why not point people to draft-ietf-ipngwg-addr-arch-v3-08.txt and have the WG get that doc to be an RFC as soon as possible. And by the way, a /126 is perfect for Point-to-point and yes, we also reserve a /48 to carve bits and pieces for these purposes. We use a /48 because that way things are kept consistent and operational errors are minimised (and keeping my netowrk operational is far more important than any other consideration). Joao From Nick Kraal Thu Aug 1 10:41:42 2002 From: Nick Kraal (Nick Kraal) Date: Thu, 01 Aug 2002 17:41:42 +0800 Subject: [6bone] semi-newbie Q on IPv6 address planning References: <012301c23306$082ecb60$53e173cb@arc.net.my> Message-ID: <01ba01c2393f$a4d2da80$53e173cb@arc.net.my> Many thanks to all for valuable advice given on this area. Basically it seems that the NLA boundary, the RES field, etc have depreciated and we are kinda free to allocate prefix lengths in these fields - RFC2374 Section 3.4 says it nicely. The design of an NLA ID allocation plan is a tradeoff between routing aggregation efficiency and flexibility. Creating hierarchies allows for greater amount of aggregation and results in smaller routing tables. Flat NLA ID assignment provides for easier allocation and attachment flexibility, but results in larger routing tables. So here I am design a network plan either incorporating hierarchical information (e.g. core, geographical PoP, customer type, etc) or simply designing a 'whack-flat' network assigning addresses as the customer or core design requirements arise. So more thinking needs to be done here on this. It is a 50-50% decision, but we don't want to take left when later on signs later on show that we should have taken right -sigh. -nick/ ----- Original Message ----- From: "Nick Kraal" To: <6bone@mailman.isi.edu> Sent: Wednesday, July 24, 2002 7:34 PM Subject: [6bone] semi-newbie Q on IPv6 address planning > 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 schild@uni-muenster.de Thu Aug 1 10:48:50 2002 From: schild@uni-muenster.de (Christian Schild) Date: Thu, 1 Aug 2002 11:48:50 +0200 Subject: [6bone] Re: routing concern In-Reply-To: <20020731213941.GC4117@pasky.ji.cz> References: <2B81403386729140A3A899A8B39B046405E225@server2000.arneill-py.sacramento.ca.us> <20020731210355.GA17658@rvdp.org> <20020731213941.GC4117@pasky.ji.cz> Message-ID: <20020801094847.2C6A4312AF@zivlnx01.uni-muenster.de> Am Mittwoch, 31. Juli 2002 23:39 schrieb Petr Baudis: > 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. As others pointed out, stability has nothing to do with native or tunneled connections. The point I want to make is, that we have no time to wait for the 6bone to become stable, be it either by evolving native peerings or by educating it's users how to filter and to route. In fact, I don't believe it is possible at all to stabilize the 6bone. It is marked 'experimental'. People come and go in the 6bone, new players will do nasty stuff as 'it is only experimental'. Black holes will never go away, because new people want to 'learn' in the 6bone, how to run an IPv6 network. Learning implies making mistakes. Thinking of this, I believe it is vital to detach the production network from the 6bone _now_, and it is also vital to show everyone whats the difference. 'You have an 3ffe:: prefix? well, then don't expect anything.' 'Yes, 2001:: should be better, but we can't guarantee that our (production) peering partners, won't use routes through the 6bone.' The second sentence _should_ say 'Yes, 2001:: is better, it's production'. To achieve this I would like to urge every ISP not to mix up their 2001:: prefix with 3ffe::, and to encourage them to detach it from the 6bone. If this would become a general rule how to play in the 6bone, I believe a stable production network is possible. Their is one drawback. Todays IPv6 network _is_ the 6bone. If I want to reach someone, I often have to traverse the 6bone. So most times I like to consider the 6bone as the 'IPv6 backbone'. I want to use a 'productive' route, but sometimes only a route through the 6bone is possible. It's a kind of last resort for reachability. Complete detachment of the 6bone is not possible today, as we lack of productive connectivity. But we could use the 6bone as seldom as possible. Considering an ISP with a 6bone node and one or more peerings to a 2001__ neighbor, that would require some preferences set for a productive route from the productive neighbor, or a lower preference for routes coming from the 6bone. Then the ISP shouldn't accept or announce 3ffe:: routes to its peering partners and should only use his own 6bone node for 6bone connectivity. This way the ISP could reach every possible IPv6 network and if possible I will use a route through my productive peerings. Ok, my peering partners still could route through the 6bone, but if he uses the same rules like me, that won't happen. This method may only be a starting point for discussion. I'm sure there are other ways to detach the 6bone (partly) from the productive network. 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 Ronald.vanderPol@rvdp.org Thu Aug 1 11:17:46 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Thu, 1 Aug 2002 12:17:46 +0200 Subject: [6bone] Re: routing concern In-Reply-To: <200207312115.g6VLFjs27933@boreas.isi.edu> References: <20020731210355.GA17658@rvdp.org> <200207312115.g6VLFjs27933@boreas.isi.edu> Message-ID: <20020801101746.GA582@rvdp.org> On Wed, Jul 31, 2002 at 14:15:45 -0700, Bill Manning wrote: > 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?" I can give all my computers at home a globally unique address. If I can choose between two providers, one of which offers v6, I choose the one that offers v6. Even when it costs more. It's up to the marketing people to figure out how many there are like me and how much we want to pay extra. rvdp From sp@iphh.net Thu Aug 1 11:38:06 2002 From: sp@iphh.net (Sascha E. Pollok) Date: Thu, 1 Aug 2002 12:38:06 +0200 (CEST) Subject: [6bone] native field in ipv6site object? Message-ID: Hi there, the Nokia 6Bone-DB says, that there is (or should be) a native: field in the ipv6site object. Viagenie's tool says there is not and the DB does not accept any native: field either. >From my point of view it would be good to be able to document native links beside the tunnel links in the ipv6site-object, too. Is there any story behind this or any further information on how to document native links? We do not think that it is currently a good and convenient choice to document IPv6 native peerings in the appropriate RADBs aut-num objects. Anyone? Thanks Sascha --- Sascha E. Pollok AS12731 sp@iphh.net From jeroen@unfix.org Thu Aug 1 12:44:23 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 1 Aug 2002 13:44:23 +0200 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? Message-ID: <021101c23950$c87c6e40$534510ac@cyan> It's thursday again, so on with the Summer Cleaning, the rain is pouring down here luckily so that should wash some thing away; 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/31/02, peering with VIAGENIE (AS10566) UUNET-US (AS12199) CICNET (AS1225) (AS13676) UNAM (AS278) MIT-SIPB (AS3) TELEBIT (AS3263) ETRI (AS3748) CERNET (AS4538) SPRINT (AS6175) STEALTH (AS8002) INTEC (AS9612) --------------------------------------------- Size of 6Bone Routing Table: Max = 292, Min = 283, Average = 290 117 pTLAs (in 3ffe::/16), 134 sTLAs (in 2001::/16) 220 Unique Autonomous System (AS) numbers BGP4+ Traffic Summary: Announcements = 4717 Withdraws = 1091 Unique Routes = 306 ----->8 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 -------------------------------- UUNET-US (AS12199) announced 22 route(s) 3ffe:28ff:ffff:4::103/127 path 12199 (UUNET-US -- 58%) 3ffe:28ff:ffff:4::100/127 path 12199 (UUNET-US -- 58%) 3ffe:28ff:ffff:4::101/127 path 12199 (UUNET-US -- 100%) 3ffe:28ff:ffff:4::102/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::10: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:8090:4800:cfff::9:0/112 path 12199 (UUNET-US -- 100%) 3ffe:3800::11: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 -- 100%) * 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 Hello, Earth to UUNET... anybody there? /127, /112, /64, /60... great guys, now back to the aggregation school. They account for the first 5 CC's. 8<---------- CERNET (AS4538) announced 3 route(s) 3ffe:80b0:100::/48 path 4538 13226 (STBEN-BE -- 100%) 3ffe:1200:3028::/48 path 4538 6939 (LJOSA/HURRICANE -- 100%) 3ffe:2b00:1003::/48 path 4538 15180 (DIVEO-BR -- 99%) CHELLO (AS6830) announced 2 route(s) 3ffe:8034::/34 path 12199 145 4554 5609 6830 1853 (COSY -- 13%) 3ffe:82bf::/32 path 12199 145 4554 6939 6830 24643 (NEXTGEN-LAB -- 93%) 8<----------- That's better, but still no cigar: inet6num: 3FFE:8030::/28 netname: QTPVSIX descr: pTLA delegation for the 6bone country: DK inet6num: 3FFE:82B0::/28 netname: WEBONLINE-NET descr: WebOnline AS country: NO ----------->8 INR (AS2895) announced 2 route(s) * 3ffe:2406::/32 path 12199 145 11537 786 109 109 2895 20515 ( -- 93%) * 3ffe:240b::/32 path 12199 145 11537 786 109 109 2895 13032 (KUN-6 -- 93%) --------->8 inet6num: 3FFE:2400::/24 netname: INR descr: pTLA delegation for the 6bone One could aggregate those _easily_, they are even from your own block, no excuse. 8<-------- UUNET-NL (AS1890) announced 1 route(s) 2001:600:8::/48 path 4538 1890 (UUNET-NL -- 99%) --------->8 UUNet from the Netherlands, naughty... CC'd. 8<-------- ISI-LAP (AS4554) announced 1 route(s) 3ffe:2c03::/32 path 12199 145 4554 6939 2012 (ELTE-INF/MADNET/RIEB/PSZFB-NET/KOMJATA-KOLL/NEXCOM/DUNE/JGYTF/T-NET/STA JI/PR -- 85%) --------->8 Nice long path we got there... inet6num: 3FFE:2C00::/24 netname: BT-LABS descr: pTLA delegation for the 6bone country: GB No cigar either 8<--------- ENTERZONE (AS13944) announced 1 route(s) * 3ffe:1ced::/32 path 12199 145 4554 13944 (ENTERZONE -- 93%) ---------->8 At least we know the reason of this one. 8<-------- ASNET (AS9264) announced 1 route(s) 3ffe:3600:18::/48 path 3263 1275 5623 786 109 109 4618 9264 (ASNET -- 99%) -------->8 inet6num: 3FFE:3600::/24 netname: CHTTL-TW descr: pTLA delegation for the 6bone country: TW Thou shalt not spam thou /48's to me. 8<-------- SPACENET-DE (AS5539) announced 1 route(s) 3ffe:2640::/32 path 12199 145 4554 5539 3561 790 6793 (TELIAFI -- 93%) FUNET (AS1741) announced 1 route(s) 3ffe:2620::/32 path 12199 145 4554 5539 3561 790 1741 (FUNET -- 93%) --------->8 inet6num: 3FFE:2600::/24 netname: SMS descr: pTLA delegation for the 6bone country: FI These should be a /24... 8<--------- JOIN (AS1275) announced 1 route(s) 3ffe:2100:1:17::/64 path 4538 1275 (JOIN -- 97%) --------->8 inet6num: 3FFE:2100::/24 netname: JANET descr: pTLA delegation for the 6bone country: GB Leaking JANET routes.... I think there was some less disturbance in the force than last week which is good. The thing that's not good is the fact that UUNET didn't even reply, so more CC:'s for them. Next week, when they won't reply, I'll start the daily campaign just for them ;) Just to make sure everybody gets it again: 8<-------------------- 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. -------------------->8 IPv6 - Just keep it clean, filter. Greets, Jeroen From jeroen@unfix.org Thu Aug 1 13:11:12 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 1 Aug 2002 14:11:12 +0200 Subject: [6bone] RE: In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <021101c23950$c87c6e40$534510ac@cyan> Message-ID: <021901c23954$8760f670$534510ac@cyan> UUNet is not home? inet6num: 3FFE:8090::/28 netname: UUNET-US descr: pTLA delegation for the 6bone country: US admin-c: UIO1-6BONE tech-c: UIO1-6BONE remarks: This object is automatically converted from the RIPE181 registry notify: ipv6ops@eng.us.uu.net notify: cross@eng.us.uu.net mnt-by: MNT-UUNET-US changed: cross@eng.us.uu.net 20000427 changed: auto-dbm@whois.6bone.net 20010117 source: 6BONE person: Chris P. Ross address: UUNET Technologies, Inc. phone: +1 703 206 5600 fax-no: +1 703 206 5601 e-mail: cross@eng.us.uu.net e-mail: cross@uu.net nic-hdl: CR487 remarks: This object is automatically converted from the RIPE181 registry notify: cross@eng.us.uu.net changed: cross@eng.us.uu.net 19990113 changed: auto-dbm@whois.6bone.net 20010117 source: 6BONE But: 8<---------- The original message was received at Thu, 1 Aug 2002 11:46:51 GMT from localhost [127.0.0.1] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to imr2.ash.ops.us.uu.net. [153.39.43.15]: >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown ---------->8 That kinda explains.... Now hope that somebody else is reading the ivp6ops@eng.us.uu.net mailbox. 8<------------------------------------- role: UUNET IPv6 Operations address: UUNET Technologies, Inc. 22001 Loudoun County Parkway Ashburn, VA 20147 e-mail: ipv6ops@eng.us.uu.net admin-c: CR487 tech-c: CR487 nic-hdl: UIO1-6BONE remarks: Email address for administration of the UUNET-US 6bone connection remarks: This object is automatically converted from the RIPE181 registry url: http://wwwwww.eng.us.uu.net/ notify: ipv6ops@eng.us.uu.net changed: cross@eng.us.uu.net 20000330 changed: auto-dbm@whois.6bone.net 20010117 source: 6BONE ------------------------------------->8 wwwwww.eng.us.uu.net AAAA 3FFE:8090:4800:C005:0:0:0:5 wwwwww.eng.us.uu.net A record currently not present jeroen@purgatory:~$ telnet wwwwww.eng.us.uu.net 80 Trying 3ffe:8090:4800:c005::5... telnet: Unable to connect to remote host: Network is unreachable jeroen@purgatory:~$ traceroute6 3FFE:8090:4800:C005:0:0:0:5 traceroute to 3FFE:8090:4800:C005:0:0:0:5 (3ffe:8090:4800:c005::5) from 3ffe:8114:1000::27, 30 hops max, 16 byte packets 1 tunnel-026.ipng.nl (3ffe:8114:1000::26) 20.601 ms 22.503 ms 22.858 ms 2 Amsterdam.core.ipv6.intouch.net (2001:6e0::2) 23.611 ms 21.237 ms 20.251 ms 3 3ffe:80a0:0:f001::2 (3ffe:80a0:0:f001::2) 111.014 ms 104.275 ms 103.597 ms 4 3ffe:80c0:200:5::7 (3ffe:80c0:200:5::7) 158.897 ms 163.591 ms 158.522 ms 5 wwwwww.eng.us.uu.net (3ffe:8090:4800:c005::5) 194.54 ms 3ffe:1cff:0:ee::2 (3ffe:1cff:0:ee::2) 193.433 ms wwwwww.eng.us.uu.net (3ffe:8090:4800:c005::5) 206.382 ms 6 wwwwww.eng.us.uu.net (3ffe:8090:4800:c005::5) 199.338 ms 199.018 ms 194.855 ms www.eng.us.uu.net A 208.228.2.110 Trying 208.228.2.110... telnet: Unable to connect to remote host: Connection refused Way to go... Anybody with a sign of life of UUNET-US ? Greets, Jeroen From jeroen@unfix.org Thu Aug 1 14:11:24 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 1 Aug 2002 15:11:24 +0200 Subject: Yokohama Minutes (Was: RE: [6bone] Re: routing concern) In-Reply-To: <2B81403386729140A3A899A8B39B046405E232@server2000.arneill-py.sacramento.ca.us> Message-ID: <021d01c2395c$f0ad9f40$534510ac@cyan> Michel Py wrote: > BTW, I was curious about the 6bone meeting in Yokohama, as there have > been talks with the RIRs. Did I miss the minutes? I picked up the following from the ietf list; Nothing more afaik though... Greets, Jeroen -----Original Message----- From: owner-ietf@ietf.org [mailto:owner-ietf@ietf.org] On Behalf Of Randy Bush Sent: Wednesday, 31 July 2002 06:22 To: ietf Subject: yokohame iesg plenary ipv6 panel presentations the ipv6 panel presentations are available in pdf at of course we hope they will be in the proceedings as well. i have bcc:d minutes@ietf.org. randy From jeroen@unfix.org Thu Aug 1 14:15:01 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 1 Aug 2002 15:15:01 +0200 Subject: [6bone] native field in ipv6site object? In-Reply-To: Message-ID: <021e01c2395d$7171cb60$534510ac@cyan> Sascha E. Pollok wrote: > the Nokia 6Bone-DB says, that there is (or should be) > a native: field in the ipv6site object. Viagenie's > tool says there is not and the DB does not accept > any native: field either. > > From my point of view it would be good to be > able to document native links beside the tunnel > links in the ipv6site-object, too. Is there > any story behind this or any further information > on how to document native links? $ whois 3ffe:8114::/32 inet6num: 3FFE:8114::/32 netname: INTOUCH-V6-IPNG descr: IPng IPv6 deployment. Amsterdam Internet Exchange. tunnel: IPv6 in IPv6 amsix-nikhef.ipv6.intouch.net -> ir4.Amsterdam.surf.net SURFNET BGP4+ tunnel: IPv6 in IPv6 amsix-nikhef.ipv6.intouch.net -> rtr6.ams-ix.net AMSIX BGP4+ tunnel: IPv6 in IPv6 amsix-nikhef.ipv6.intouch.net -> ams-ix.ipv6.ebone.net EBONE BGP4+ tunnel: IPv6 in IPv6 amsix-nikhef.ipv6.intouch.net -> 6b1.ams7.nl.uu.net UUNET-NL BGP4+ tunnel: IPv6 in IPv6 amsix-nikhef.ipv6.intouch.net -> ams-ix.xr1.sara.xs4all.net XS4ALL-NL BGP4+ tunnel: IPv6 in IPv6 amsix-nikhef.ipv6.intouch.net -> Amsterdamv6.ripe.net RIPE-NCC BGP4+ tunnel: IPv6 in IPv6 amsix-nikhef.ipv6.intouch.net -> ams-ix.ntt6.net AS4697 BGP4+ tunnel: IPv6 in IPv6 amsix-nikhef.ipv6.intouch.net -> telecity.ams-ix.ipv6.network.bit.nl NL-BIT6 BGP4+ remarks: The 'tunnels' above are actually native IPv6 peering at the AMS-v6-IX. That's the way it works, no other way afaik is possible atm. > We do not think that it is currently a good and > convenient choice to document IPv6 native peerings > in the appropriate RADBs aut-num objects. RIPE is working on RPSL extension support for IPv6. Afaik it's nearing completion. Greets, Jeroen From tvo@EnterZone.Net Thu Aug 1 14:40:18 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 1 Aug 2002 09:40:18 -0400 (EDT) Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <021101c23950$c87c6e40$534510ac@cyan> Message-ID: > Just to make sure everybody gets it again: > 8<-------------------- > 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 > I'll gladly tighten up/replace our filters: 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 With these: ipv6 prefix-list test1 seq 5 permit 3ffe::/18 ge 24 le 24 ipv6 prefix-list test1 seq 10 permit 3ffe:4000::/18 ge 32 le 32 ipv6 prefix-list test1 seq 15 permit 3ffe:8000::/20 ge 28 le 28 ipv6 prefix-list test1 seq 20 permit 2000::/3 ge 16 le 16 ipv6 prefix-list test1 seq 25 permit 2001::/16 ge 29 le 35 ipv6 prefix-list test1 seq 500 deny any ...if someone can tell me what to do here: Border2-BGP(config)# ipv6 prefix-list test1 seq 30 permit 2002::/16 ge 16 le 48 % Invalid prefix range for 2002::/16, make sure: len < ge-value <= le-value Any suggestions are greatly appreciated! --- 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 Aug 1 14:56:23 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 1 Aug 2002 15:56:23 +0200 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: Message-ID: <022001c23963$39578de0$534510ac@cyan> John Fraizer [mailto:tvo@EnterZone.Net] wrote: > Border2-BGP(config)# ipv6 prefix-list test1 seq 30 permit > 2002::/16 ge 16 le 48 > % Invalid prefix range for 2002::/16, make sure: len < ge-value <= le-value You could interpret that message as: "PrefixLen" should be smaller than the greatest which should be smaller/equal the smallest. In this case: 16 < 16 <= 48 Your router bugs, it should do: 16 <= 16 <= 48 other-way-around logic: le <= prefixlen <= ge or in this case: 16 <= 16 <= ge Greets, Jeroen From pekkas@netcore.fi Thu Aug 1 14:57:51 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 1 Aug 2002 16:57:51 +0300 (EEST) Subject: [6bone] Re: routing concern In-Reply-To: <2B81403386729140A3A899A8B39B046405E233@server2000.arneill-py.sacramento.ca.us> Message-ID: On Thu, 1 Aug 2002, Michel Py wrote: > It all comes down to money. No operator is going to build an IPv6 > infrastructure without knowing the outcome of the multihoming solution, > as they don't want to do the job twice, especially when there is no > money to pay for it. Network operators don't really care about multihoming; they already have it by becoming "pTLA/sTLA". Getting customers is another issue, though. However, enterprises not going for IPv6 "because" of a lack of multihoming solutions is, in most cases, just a good excuse. If not for multihoming, there would be something else; usually only rather big corporations multihome using BGP + multiple advertisements, or similar other techniques like more specific routes. Many don't even (need to) know what multihoming means. -- 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 itojun@iijlab.net Thu Aug 1 15:09:49 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Thu, 01 Aug 2002 23:09:49 +0900 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: tvo's message of Thu, 01 Aug 2002 09:40:18 -0400. Message-ID: <20020801140949.EA6D44B24@coconut.itojun.org> >...if someone can tell me what to do here: >Border2-BGP(config)# ipv6 prefix-list test1 seq 30 permit 2002::/16 ge 16 le 48 >% Invalid prefix range for 2002::/16, make sure: len < ge-value <= le-value >Any suggestions are greatly appreciated! you wouldn't want to allow 2002::/16 le 48. there should be 2002::/16, nothing else. see 6to4 RFC. itojun From itojun@iijlab.net Thu Aug 1 15:15:00 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Thu, 01 Aug 2002 23:15:00 +0900 Subject: Yokohama Minutes (Was: RE: [6bone] Re: routing concern) In-Reply-To: jeroen's message of Thu, 01 Aug 2002 15:11:24 +0200. <021d01c2395c$f0ad9f40$534510ac@cyan> Message-ID: <20020801141500.97C004B22@coconut.itojun.org> >> BTW, I was curious about the 6bone meeting in Yokohama, as there have >> been talks with the RIRs. Did I miss the minutes? >I picked up the following from the ietf list; >Nothing more afaik though... >the ipv6 panel presentations are available in pdf at > this one is totally separate from 6bone meeting. Bob, do you have you slides online? itojun From tvo@EnterZone.Net Thu Aug 1 15:20:18 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 1 Aug 2002 10:20:18 -0400 (EDT) Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <20020801140949.EA6D44B24@coconut.itojun.org> Message-ID: On Thu, 1 Aug 2002 itojun@iijlab.net wrote: > >...if someone can tell me what to do here: > >Border2-BGP(config)# ipv6 prefix-list test1 seq 30 permit 2002::/16 ge 16 le 48 > >% Invalid prefix range for 2002::/16, make sure: len < ge-value <= le-value > >Any suggestions are greatly appreciated! > > you wouldn't want to allow 2002::/16 le 48. there should be 2002::/16, > nothing else. see 6to4 RFC. > > itojun > That just solved that problem then. ipv6 prefix-list subTLA-only seq 5 permit 3ffe::/18 ge 24 le 24 ipv6 prefix-list subTLA-only seq 10 permit 3ffe:4000::/18 ge 32 le 32 ipv6 prefix-list subTLA-only seq 15 permit 3ffe:8000::/20 ge 28 le 28 ipv6 prefix-list subTLA-only seq 20 permit 2000::/3 ge 16 le 16 ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35 ipv6 prefix-list subTLA-only seq 30 permit 2002::/16 ipv6 prefix-list subTLA-only seq 500 deny any Does anyone see any problems with the above prefix list or will it do the proper filtering now? --- 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 Thu Aug 1 16:04:09 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 1 Aug 2002 08:04:09 -0700 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? Message-ID: <2B81403386729140A3A899A8B39B046405E234@server2000.arneill-py.sacramento.ca.us> >> John Fraizier wrote: >> Border2-BGP(config)# ipv6 prefix-list test1 seq 30 permit >> 2002::/16 ge 16 le 48 >> % Invalid prefix range for 2002::/16, make sure: len >> < ge-value <= le-value >> Any suggestions are greatly appreciated! > Itojun wrote: > you wouldn't want to allow 2002::/16 le 48. there should be > 2002::/16, nothing else. see 6to4 RFC. I tend to agree. John, what are you trying to achieve here? Load-balance between more than one 6to4 relay? Besides, I would highly recommend to be your own 6to4 relay if this router has IPv4 connectivity, which still is the case for most. Michel. From michel@arneill-py.sacramento.ca.us Thu Aug 1 16:26:35 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 1 Aug 2002 08:26:35 -0700 Subject: [6bone] semi-newbie Q on IPv6 address planning Message-ID: <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.ca.us> Jao, > 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). > Jao wrote: > Indeed, and that is my concern. The experts are referring > people to outdated documents describing features that in > some cases the WG has dropped *years* ago (TLA, NLA, the > 8 bit reserved field). The fact of the matter is that the RFC has not been obsoleted yet. I agree that there is a consensus that it's going away, but this is not official yet. Two more precisions: - As far as the 6bone is concerned, there is no replacement for "pTLA" as of today I know of. In this context, the use of "sTLA" is perfectly fine as far as I am concerned too. - There is no replacement I know for "SLA bits" either. In the lack of a better term, I'll continue to use it. If officially there is no fixed /48 boundary, it is the recommendation of RIRs that all sites are given a /48, and I have not seen any examples of ISPs assigning anything else than a /48 to a site and a /64 for a single subnet. > And by the way, a /126 is perfect for Point-to-point No, it is as illegal with draft-ietf-ipngwg-addr-arch-v3-08.txt than it is with RFC2374, read draft-ietf-ipngwg-addr-arch-v3-08.txt again. Michel. From kre@munnari.OZ.AU Thu Aug 1 16:44:44 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Thu, 01 Aug 2002 22:44:44 +0700 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <2B81403386729140A3A899A8B39B046405E22B@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E22B@server2000.arneill-py.sacramento.ca.us> Message-ID: <14544.1028216684@munnari.OZ.AU> Date: Wed, 31 Jul 2002 08:00:10 -0700 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405E22B@server2000.arneill-py.sacramento.ca.us> | > And what is a /126 allocation for a point-to-point link? | | Not good, it violates RFC2373. which is totally harmless. | You should use a /64 for point-to-point links. That is an option. | It is typical to allocate a /48 for your ptp links. If you have a /32 (or similar), that's nice (and I appreciate that was the context of the question). But most users will have just one /48, allocating that to p2p links would be a bit drastic... Personally, I use /112's for p2p links. Works just fine. Scales wonderfully. kre From michel@arneill-py.sacramento.ca.us Thu Aug 1 16:46:52 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 1 Aug 2002 08:46:52 -0700 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? Message-ID: <2B81403386729140A3A899A8B39B046405E236@server2000.arneill-py.sacramento.ca.us> > John Fraizier wrote: > ipv6 prefix-list subTLA-only seq 5 permit 3ffe::/18 ge 24 le 24 > ipv6 prefix-list subTLA-only seq 10 permit 3ffe:4000::/18 ge 32 le 32 > ipv6 prefix-list subTLA-only seq 15 permit 3ffe:8000::/20 ge 28 le 28 > ipv6 prefix-list subTLA-only seq 20 permit 2000::/3 ge 16 le 16 > ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35 > ipv6 prefix-list subTLA-only seq 30 permit 2002::/16 > ipv6 prefix-list subTLA-only seq 500 deny any > Does anyone see any problems with the above prefix list or will it > do the proper filtering now? Remarks on this: - I think that seq 30 (6to4) could be optional. I don't think we want this route floating on the 6bone. - If we keep seq 20, seq 30 is useless anyway as it will match seq 20. Besides, can someone explain me the reason for seq 20? I am not sure we want to see 2001::/16 or 3ffe::/16 as aggregates in the routing table, there are issues with source address selection doing this. Michel. From tony@lava.net Thu Aug 1 18:06:47 2002 From: tony@lava.net (Antonio Querubin) Date: Thu, 1 Aug 2002 07:06:47 -1000 (HST) Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <14544.1028216684@munnari.OZ.AU> Message-ID: On Thu, 1 Aug 2002, Robert Elz wrote: > Date: Wed, 31 Jul 2002 08:00:10 -0700 > From: "Michel Py" > Message-ID: <2B81403386729140A3A899A8B39B046405E22B@server2000.arneill-py.sacramento.ca.us> > > | > And what is a /126 allocation for a point-to-point link? > | > | Not good, it violates RFC2373. > > which is totally harmless. > > | You should use a /64 for point-to-point links. > > That is an option. > > | It is typical to allocate a /48 for your ptp links. > > If you have a /32 (or similar), that's nice (and I appreciate that was the > context of the question). But most users will have just one /48, allocating > that to p2p links would be a bit drastic... > > Personally, I use /112's for p2p links. Works just fine. Scales wonderfully. For us, assigning on nibble boundaries for multiple-subnet sites scales much better too than the one-size-fits-all /48. From bmanning@ISI.EDU Thu Aug 1 18:14:04 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 1 Aug 2002 10:14:04 -0700 (PDT) Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: from John Fraizer at "Aug 1, 2 10:20:18 am" Message-ID: <200208011714.g71HE4o08845@boreas.isi.edu> % ipv6 prefix-list subTLA-only seq 5 permit 3ffe::/18 ge 24 le 24 % ipv6 prefix-list subTLA-only seq 10 permit 3ffe:4000::/18 ge 32 le 32 % ipv6 prefix-list subTLA-only seq 15 permit 3ffe:8000::/20 ge 28 le 28 % ipv6 prefix-list subTLA-only seq 20 permit 2000::/3 ge 16 le 16 % ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35 % ipv6 prefix-list subTLA-only seq 30 permit 2002::/16 % ipv6 prefix-list subTLA-only seq 500 deny any % % Does anyone see any problems with the above prefix list or will it do the % proper filtering now? % Well, there are the few prefixes in 2001::/16 space that should -not- be aggregated that were covered earlier in this thread. Depending on what you want to do wrt exchanges and criticial infrastructure pieces, you may wish to adjust your filters to allow /48s from the respective /32's. --bill From tvo@EnterZone.Net Thu Aug 1 18:18:06 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 1 Aug 2002 13:18:06 -0400 (EDT) Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <2B81403386729140A3A899A8B39B046405E234@server2000.arneill-py.sacramento.ca.us> Message-ID: On Thu, 1 Aug 2002, Michel Py wrote: > >> John Fraizier wrote: > >> Border2-BGP(config)# ipv6 prefix-list test1 seq 30 permit > >> 2002::/16 ge 16 le 48 > >> % Invalid prefix range for 2002::/16, make sure: len > >> < ge-value <= le-value > >> Any suggestions are greatly appreciated! > > > Itojun wrote: > > you wouldn't want to allow 2002::/16 le 48. there should be > > 2002::/16, nothing else. see 6to4 RFC. > > I tend to agree. John, what are you trying to achieve here? Load-balance > between more than one 6to4 relay? > > Besides, I would highly recommend to be your own 6to4 relay if this > router has IPv4 connectivity, which still is the case for most. > > Michel. I was simply building filters based on the following quote from Jeroen: =======BEGIN QUOTE======= Just to make sure everybody gets it again: 8<-------------------- 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. -------------------->8 IPv6 - Just keep it clean, filter. Greets, Jeroen =======END QUOTE======= Notice the line that says "2002::/16 ge 16 le 48"... That's why I was trying to build the filter that way. I've since updated our filters on peers as follows: (We'll use your peering session as an example Michel) router bgp 13944 neighbor 3ffe:1ced:ff02::2 remote-as 23169 neighbor 3ffe:1ced:ff02::2 description ARNEILLPY no neighbor 3ffe:1ced:ff02::2 activate ! address-family ipv6 neighbor 3ffe:1ced:ff02::2 activate neighbor 3ffe:1ced:ff02::2 next-hop-self neighbor 3ffe:1ced:ff02::2 prefix-list AS-ARNEILLPY in neighbor 3ffe:1ced:ff02::2 prefix-list subTLA-only out neighbor 3ffe:1ced:ff02::2 route-map AS-ARNEILLPY in exit-address-family ! ipv6 prefix-list AS-ARNEILLPY seq 10 permit 3ffe:1ced:a002::/48 ipv6 prefix-list subTLA-only seq 1 permit 3ffe:1ced::/32 ipv6 prefix-list subTLA-only seq 5 permit 3ffe::/18 ge 24 le 24 ipv6 prefix-list subTLA-only seq 10 permit 3ffe:4000::/18 ge 32 le 32 ipv6 prefix-list subTLA-only seq 15 permit 3ffe:8000::/20 ge 28 le 28 ipv6 prefix-list subTLA-only seq 20 permit 2000::/3 ge 16 le 16 ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35 ipv6 prefix-list subTLA-only seq 30 permit 2002::/16 ipv6 prefix-list subTLA-only seq 500 deny any ! route-map AS-ARNEILLPY permit 10 match ipv6 address prefix-list subTLA-only ! route-map AS-ARNEILLPY permit 20 match ipv6 address prefix-list AS-ARNEILLPY set community no-export additive ! Basically, on YOUR peering session, I'm prefix-list filtering you based on ipv6 prefix-list AS-ARNEILLPY. The route-map is a "stock" route-map that is applied to EVERY peer. If the peer isn't being prefix-list filtered on the way in, and they show us VALID prefixes that pass ipv6 prefix-list subTLA-only, we accept them and will redistribute them. If they are showing us more-specifics (unaggregated) that I have allowed in ipv6 prefix-list AS-[PEERNAME] we accept them but tag them with the no-export community and don't redistribute them. After applying the new filters, we had one peer go from WELL over 300 prefixes to 253 prefixes. So, in summary, we'll accept more-specifics, by arrangement, but will not redistribute them outside of our AS. Everything else has to be within the aggregation guidelines or we don't accept it at all and with the exception of 3ffe:1ced::/32 (and we all know the story behind that) we shouldn't be showing anyone any prefixes that are outside of the aggregation guidelines. Does anyone see any flaw in the above policy? I've thought about how to do this correctly for the past week or so and finally implemented the new policy a few minutes ago. It looks like we're showing peers 254 prefixes right now INCLUDING the 3ffe:1ced::/32 specific. Any comments appreciated. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From Daniel Austin" Message-ID: <000901c2397f$cfd27020$611c08d9@kewlio.net> Those would be from the following... 2001:478::/32 2001:7f8::/32 For any lazy people out there ;-) With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. ----- Original Message ----- From: "Bill Manning" To: "John Fraizer" Cc: ; ; <6bone@ISI.EDU> Sent: Thursday, August 01, 2002 6:14 PM Subject: Re: [6bone] In the summer time, we got cleaning to do... Where is UUNET? > % ipv6 prefix-list subTLA-only seq 5 permit 3ffe::/18 ge 24 le 24 > % ipv6 prefix-list subTLA-only seq 10 permit 3ffe:4000::/18 ge 32 le 32 > % ipv6 prefix-list subTLA-only seq 15 permit 3ffe:8000::/20 ge 28 le 28 > % ipv6 prefix-list subTLA-only seq 20 permit 2000::/3 ge 16 le 16 > % ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35 > % ipv6 prefix-list subTLA-only seq 30 permit 2002::/16 > % ipv6 prefix-list subTLA-only seq 500 deny any > % > % Does anyone see any problems with the above prefix list or will it do the > % proper filtering now? > % > > Well, there are the few prefixes in 2001::/16 space that > should -not- be aggregated that were covered earlier > in this thread. Depending on what you want to do wrt > exchanges and criticial infrastructure pieces, you > may wish to adjust your filters to allow /48s from the > respective /32's. > > --bill > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From bmanning@ISI.EDU Thu Aug 1 18:26:18 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 1 Aug 2002 10:26:18 -0700 (PDT) Subject: [6bone] New IPv6 Policies in the ARIN Region Message-ID: <200208011726.g71HQII17794@boreas.isi.edu> This flopped into the inbox this AM. So, if one were to adjust filtering policies, one might want to accept /35s in the range delegated thus far in the ARIN space and /32s from here on out. ------------- Date: Thu, 1 Aug 2002 11:54:37 -0400 (EDT) Hello, Beginning today, August 1, 2002, new IPv6 policies have been implemented in the ARIN region. Information about these new policies can be found at: http://www.arin.net/registration/ipv6/index.html One of the most significant changes in policy is that the minimum allocation size issued by ARIN has moved from a /35 to a /32. ... --------------- -- bill From tvo@EnterZone.Net Thu Aug 1 18:47:38 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 1 Aug 2002 13:47:38 -0400 (EDT) Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <200208011714.g71HE4o08845@boreas.isi.edu> Message-ID: On Thu, 1 Aug 2002, Bill Manning wrote: > % ipv6 prefix-list subTLA-only seq 5 permit 3ffe::/18 ge 24 le 24 > % ipv6 prefix-list subTLA-only seq 10 permit 3ffe:4000::/18 ge 32 le 32 > % ipv6 prefix-list subTLA-only seq 15 permit 3ffe:8000::/20 ge 28 le 28 > % ipv6 prefix-list subTLA-only seq 20 permit 2000::/3 ge 16 le 16 > % ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35 > % ipv6 prefix-list subTLA-only seq 30 permit 2002::/16 > % ipv6 prefix-list subTLA-only seq 500 deny any > % > % Does anyone see any problems with the above prefix list or will it do the > % proper filtering now? > % > > Well, there are the few prefixes in 2001::/16 space that > should -not- be aggregated that were covered earlier > in this thread. Depending on what you want to do wrt > exchanges and criticial infrastructure pieces, you > may wish to adjust your filters to allow /48s from the > respective /32's. > > --bill > I've got ya covered Bill: Border2-BGP# sh ipv6 prefix-list AS-ISI-LAP ipv6 prefix-list AS-ISI-LAP: 5 entries seq 10 permit 3ffe::/24 seq 20 permit 3ffe:800::/24 seq 30 permit 2001:478:2::/48 seq 40 permit 2001:478:4::/48 seq 50 permit 2001:478:6::/48 --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From tvo@EnterZone.Net Thu Aug 1 18:51:54 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 1 Aug 2002 13:51:54 -0400 (EDT) Subject: [6bone] New IPv6 Policies in the ARIN Region In-Reply-To: <200208011726.g71HQII17794@boreas.isi.edu> Message-ID: I don't know why anyone would opt not to upgrade to the /32. There is no additional justification or fees required. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On Thu, 1 Aug 2002, Bill Manning wrote: > > This flopped into the inbox this AM. > > So, if one were to adjust filtering policies, one might > want to accept /35s in the range delegated thus far in > the ARIN space and /32s from here on out. > > > ------------- > Date: Thu, 1 Aug 2002 11:54:37 -0400 (EDT) > > Hello, > > Beginning today, August 1, 2002, new IPv6 policies have been implemented > in the ARIN region. Information about these new policies can be found > at: > > http://www.arin.net/registration/ipv6/index.html > > One of the most significant changes in policy is that the minimum > allocation size issued by ARIN has moved from a /35 to a /32. > ... > --------------- > > > -- bill > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From bmanning@ISI.EDU Thu Aug 1 18:59:05 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 1 Aug 2002 10:59:05 -0700 (PDT) Subject: [6bone] New IPv6 Policies in the ARIN Region In-Reply-To: from John Fraizer at "Aug 1, 2 01:51:54 pm" Message-ID: <200208011759.g71Hx5R13947@boreas.isi.edu> I can't either, -BUT- apparently the delegee must request the change... ARIN will not do it unless requested. % % I don't know why anyone would opt not to upgrade to the /32. There is no % additional justification or fees required. % % % % --- % John Fraizer | High-Security Datacenter Services | % EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | % http://www.enterzone.net/ | Virtual, Dedicated, Colocation | % % % On Thu, 1 Aug 2002, Bill Manning wrote: % % > % > This flopped into the inbox this AM. % > % > So, if one were to adjust filtering policies, one might % > want to accept /35s in the range delegated thus far in % > the ARIN space and /32s from here on out. % > % > % > ------------- % > Date: Thu, 1 Aug 2002 11:54:37 -0400 (EDT) % > % > Hello, % > % > Beginning today, August 1, 2002, new IPv6 policies have been implemented % > in the ARIN region. Information about these new policies can be found % > at: % > % > http://www.arin.net/registration/ipv6/index.html % > % > One of the most significant changes in policy is that the minimum % > allocation size issued by ARIN has moved from a /35 to a /32. % > ... % > --------------- % > % > % > -- bill % > _______________________________________________ % > 6bone mailing list % > 6bone@mailman.isi.edu % > http://mailman.isi.edu/mailman/listinfo/6bone % > % -- --bill From jeroen@unfix.org Thu Aug 1 20:32:29 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 1 Aug 2002 21:32:29 +0200 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: Message-ID: <000f01c23992$2ced68c0$420d640a@unfix.org> John Fraizer wrote: > On Thu, 1 Aug 2002, Michel Py wrote: > > > >> John Fraizier wrote: > > >> Border2-BGP(config)# ipv6 prefix-list test1 seq 30 permit > > >> 2002::/16 ge 16 le 48 > > >> % Invalid prefix range for 2002::/16, make sure: len > > >> < ge-value <= le-value > > >> Any suggestions are greatly appreciated! > > > > > Itojun wrote: > > > you wouldn't want to allow 2002::/16 le 48. there should be > > > 2002::/16, nothing else. see 6to4 RFC. > > > > I tend to agree. John, what are you trying to achieve here? Load-balance > > between more than one 6to4 relay? > > > > Besides, I would highly recommend to be your own 6to4 relay if this > > router has IPv4 connectivity, which still is the case for most. > > > > Michel. > > > I was simply building filters based on the following quote > from Jeroen: Juppers, I thought that it was being nice to do 6to4 on /48's but I was wrong ofcourse ;) So the list becomes: 8<-------------------- 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 16 -------------------->8 Greets, Jeroen From tvo@EnterZone.Net Thu Aug 1 21:08:48 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 1 Aug 2002 16:08:48 -0400 (EDT) Subject: [6bone] Instability incarnate Message-ID: Serious flappage going on here...(and it ain't us!) BGP routing table entry for 3FFE:1CED::/32, version 90420 Paths: (2 available, best #2) Advertised to non peer-group peers: 2001:6E0::2 2001:768:E:5::1 3FFE:80B0:100:8000::3 3FFE:8100:102::1:9 3FFE:8100:200:2FFF::9 195.74.212.38 45328 2042 24765 13944 (history entry) 3FFE:8100:200:2FFF::9 from 3FFE:8100:200:2FFF::9 (131.211.28.48) Origin IGP, localpref 100, external Dampinfo: penalty 7047, flapped 126 times in 07:28:28 15589 24765 13944, (received & used) 3FFE:8170:1:10::1 from 3FFE:8170:1:10::1 (192.168.1.12) Origin IGP, localpref 100, valid, external, best BGP routing table entry for 2001:4F0::/35, version 89613 Paths: (5 available, best #5) Advertised to non peer-group peers: 2001:6E0::2 2001:768:E:5::1 3FFE:80B0:100:8000::3 3FFE:8100:102::1:9 3FFE:8100:200:2FFF::9 195.74.212.38 45328 2042 24765 13944, (suppressed due to dampening), (received & used) 3FFE:8100:200:2FFF::9 from 3FFE:8100:200:2FFF::9 (131.211.28.48) Origin IGP, localpref 100, valid, external Dampinfo: penalty 6134, flapped 128 times in 07:31:31, reuse in 00:45:30 8379 24765 13944, (received & used) 2001:768:E:5::1 from 2001:768:E:5::1 (195.143.108.166) Origin IGP, localpref 100, valid, external 5594 13193 109 13944, (received & used) 3FFE:8100:102::1:9 from 3FFE:8100:102::1:9 (195.154.1.6) Origin IGP, localpref 100, valid, external 1849 24765 13944, (received & used) 2001:600:4:1F1::1 from 2001:600:4:1F1::1 (158.43.131.66) Origin IGP, localpref 100, valid, external 15589 24765 13944, (received & used) 3FFE:8170:1:10::1 from 3FFE:8170:1:10::1 (192.168.1.12) Origin IGP, localpref 100, valid, external, best I don't know who is flapping in the breeze in this path "45328 2042 24765" but, I'll tell ya folks right now, if you have peers like that, it's in your best interest to de-peer. If this is prominant on the 6bone, I now understand what the fuss is about. I won't keep a peer like that, period, the end. We have one flapper right now. I don't know what their problem is as they haven't replied to my emails. It's "customer-routes:customer-routes" peering though so, the damage is at least limited to our peering session. If they don't reply with a satisfactory answer as in "We found a problem and are (contacting the vendor | replacing the hardware | firing the fool who kept unplugging the router | upgrading the software)" I'll have no choice but to admin-shutdown the session until they get their end fixed. So, in summary: If your peers flap in the breeze like the above example, find out why and fix it or drop the peering. It's not worth it. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From gert@space.net Thu Aug 1 21:16:45 2002 From: gert@space.net (Gert Doering) Date: Thu, 1 Aug 2002 22:16:45 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Thu, Aug 01, 2002 at 08:26:35AM -0700 References: <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020801221645.I27015@Space.Net> Hi, On Thu, Aug 01, 2002 at 08:26:35AM -0700, Michel Py wrote: > > And by the way, a /126 is perfect for Point-to-point > > No, it is as illegal with draft-ietf-ipngwg-addr-arch-v3-08.txt than it > is with RFC2374, read draft-ietf-ipngwg-addr-arch-v3-08.txt again. Whether the standard says it's illegal or not, /127s works fine (yes, even /127). Why create ambiguities by assigning more than 2 IPs to something that needs exactly 2? We run /127 transit networks on all our tunnel and serial ptp interfaces, it works fine, and by looking at one end you immediately know which IP the other end will have. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46284 (46191) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Daniel Austin" Message-ID: <00a201c23999$059f4a20$611c08d9@kewlio.net> This is a multi-part message in MIME format. ------=_NextPart_000_009E_01C239A1.66FEFCE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, 3ffe:80d0:fffc:10::40 4 2042 5096 5609 0 0 0 1d03h13m 230 AS24765 <--> AS2042 no flaps between us and mimos... With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. ----- Original Message ----- From: "John Fraizer" To: <6bone@ISI.EDU> Sent: Thursday, August 01, 2002 9:08 PM Subject: [6bone] Instability incarnate > > Serious flappage going on here...(and it ain't us!) > > BGP routing table entry for 3FFE:1CED::/32, version 90420 > Paths: (2 available, best #2) > Advertised to non peer-group peers: > 2001:6E0::2 2001:768:E:5::1 3FFE:80B0:100:8000::3 3FFE:8100:102::1:9 > 3FFE:8100:200:2FFF::9 195.74.212.38 > 45328 2042 24765 13944 (history entry) > 3FFE:8100:200:2FFF::9 from 3FFE:8100:200:2FFF::9 (131.211.28.48) > Origin IGP, localpref 100, external > Dampinfo: penalty 7047, flapped 126 times in 07:28:28 > 15589 24765 13944, (received & used) > 3FFE:8170:1:10::1 from 3FFE:8170:1:10::1 (192.168.1.12) > Origin IGP, localpref 100, valid, external, best > > > BGP routing table entry for 2001:4F0::/35, version 89613 > Paths: (5 available, best #5) > Advertised to non peer-group peers: > 2001:6E0::2 2001:768:E:5::1 3FFE:80B0:100:8000::3 3FFE:8100:102::1:9 > 3FFE:8100:200:2FFF::9 195.74.212.38 > 45328 2042 24765 13944, (suppressed due to dampening), (received & used) > 3FFE:8100:200:2FFF::9 from 3FFE:8100:200:2FFF::9 (131.211.28.48) > Origin IGP, localpref 100, valid, external > Dampinfo: penalty 6134, flapped 128 times in 07:31:31, reuse in 00:45:30 > 8379 24765 13944, (received & used) > 2001:768:E:5::1 from 2001:768:E:5::1 (195.143.108.166) > Origin IGP, localpref 100, valid, external > 5594 13193 109 13944, (received & used) > 3FFE:8100:102::1:9 from 3FFE:8100:102::1:9 (195.154.1.6) > Origin IGP, localpref 100, valid, external > 1849 24765 13944, (received & used) > 2001:600:4:1F1::1 from 2001:600:4:1F1::1 (158.43.131.66) > Origin IGP, localpref 100, valid, external > 15589 24765 13944, (received & used) > 3FFE:8170:1:10::1 from 3FFE:8170:1:10::1 (192.168.1.12) > Origin IGP, localpref 100, valid, external, best > > > I don't know who is flapping in the breeze in this path "45328 2042 > 24765" but, I'll tell ya folks right now, if you have peers like that, > it's in your best interest to de-peer. > > If this is prominant on the 6bone, I now understand what the fuss is > about. I won't keep a peer like that, period, the end. We have one > flapper right now. I don't know what their problem is as they haven't > replied to my emails. It's "customer-routes:customer-routes" peering > though so, the damage is at least limited to our peering session. If they > don't reply with a satisfactory answer as in "We found a problem and are > (contacting the vendor | replacing the hardware | firing the fool who kept > unplugging the router | upgrading the software)" I'll have no choice but > to admin-shutdown the session until they get their end fixed. > > So, in summary: If your peers flap in the breeze like the above example, > find out why and fix it or drop the peering. It's not worth it. > > > > --- > 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 > ------=_NextPart_000_009E_01C239A1.66FEFCE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIYzCCAnow ggHjoAMCAQICARcwDQYJKoZIhvcNAQEFBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTAyMDQxODE1MjkzN1oXDTIwMDQxMzE1MjkzN1owTjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdl b1RydXN0IEluYy4xJzAlBgNVBAMTHkdlb1RydXN0IFRydWUgQ3JlZGVudGlhbHMgQ0EgMjCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAspcspZISpYX/aJqWoYcSyyGqFby3OvsepRzLRU0ENDJR wJo7DwFpirRFOUQkTkKXsY6BQzX/CeCRrn9i4ny5gcXuI2JSyrSmDwobbwl52n5cPEbHGcebybWd KfAf8vvkxYUnTmDZPtt2ob5RNpJTeTiq9MpNCB/5G7Ocr1hEljcCAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgHGMB0GA1UdDgQWBBQig0tNIAIMMfR8WrAaTRXIeF0RSTAPBgNVHRMBAf8EBTADAQH/MB8G A1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA0GCSqGSIb3DQEBBQUAA4GBACmw3z+sLsLS fAfdECQJPfiZFzJzSPQKLwY7vHnNWH2lAKYECbtAFHBpdyhSPkrj3KghXeIJnKyMFjsK6xd1k1Yu wMXrauUH+HIDuZUg4okBwQbhBTqjjEdo/cCHILQsaLeU2kM+n5KKrpb0uvrHrocGffRMrWhz9zYB lxoq0/EEMIICgjCCAeugAwIBAgIBBDANBgkqhkiG9w0BAQQFADBTMQswCQYDVQQGEwJVUzEcMBoG A1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1c2lu ZXNzIENBLTEwHhcNOTkwNjIxMDQwMDAwWhcNMjAwNjIxMDQwMDAwWjBTMQswCQYDVQQGEwJVUzEc MBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1 c2luZXNzIENBLTEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM4vGbwXt3fek6lfWg0XTzQa DJj0ItlZ1MRoRvC0NcWFAyDGr0WlIVFFQesWWDYyb+JQYmT5/VGcqiTZ9J2DKocKIdMSODRsjQBu WqDZQu4aIZX5UkxVWsUPOE9G+m34LjXWHXzr4vCwdYDIqROsvojvOm6rXyo4YgKwEnv+j6YDAgMB AAGjZjBkMBEGCWCGSAGG+EIBAQQEAwIABzAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFEp4 MlIR21kWNl7fwRQ2QGpHfEyhMB0GA1UdDgQWBBRKeDJSEdtZFjZe38EUNkBqR3xMoTANBgkqhkiG 9w0BAQQFAAOBgQB1W6ibAxHm6VZMzfmpTMANmvPMZWnmJXbMWbfWVMMdzZmsGd20hdXgPfxiIKeE S1hl8eL5lSE/9dR+WB5Hh1Q+WKG1tfgq73HnvMP2sUlG4tega+VWeponmHxGYhTnyfxuAxJ5gDgd SIKN/Bf+KpYrtWKmpj29f5JZzVoqgrI3eTCCA1swggLEoAMCAQICAxAAazANBgkqhkiG9w0BAQQF ADBOMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1 c3QgVHJ1ZSBDcmVkZW50aWFscyBDQSAyMB4XDTAyMDgwMTE4MjYzOVoXDTAzMDgxNTE4MjYzOVow ggERMT8wPQYDVQQLEzZDUFMgdGVybXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZSBsaWFiaWxp dHkgbGltaXRlZC4xPjA8BgNVBAsTNVNlZSBQdWJsaWMgUy9NSU1FIENQUyB3d3cuZ2VvdHJ1c3Qu Y29tL3Jlc291cmNlcy9DUFMuMSowKAYDVQQLEyFQaG9uZSBWYWxpZGF0aW9uIC0gNDQgNzk3MC02 MzMzMzMxKDAmBgNVBAsTH0VtYWlsIGFuZCBwaG9uZSB2YWxpZGF0ZWQgb25seS4xFjAUBgNVBAMT DURhbmllbCBBdXN0aW4xIDAeBgkqhkiG9w0BCQEWEWRhbmllbEBrZXdsaW8ubmV0MIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCnZ7IrV88D55wCg31dENNY6z1/ehvUcOxWC4sh5hJMgMXNefiR mXQiDD6iRESdk5UJ5usgZZr40ICYwlpjBUY6xBTe4LNLiC1UPVZ9uF3Z05CVgvgXEhvqC3p8WM3O sKYfGXL7k49xmBU9TvpkExdxSEYJoK4rK77qRFC5HuKcMwIDAQABo4GBMH8wEQYJYIZIAYb4QgEB BAQDAgWgMA4GA1UdDwEB/wQEAwIF4DA5BgNVHR8EMjAwMC6gLKAqhihodHRwOi8vY3JsLmdlb3Ry dXN0LmNvbS9jcmxzL2d0dGNjYTIuY3JsMB8GA1UdIwQYMBaAFCKDS00gAgwx9HxasBpNFch4XRFJ MA0GCSqGSIb3DQEBBAUAA4GBABslhvo5nWHvXY0xcGwSdigKcnAIgRiH8zlmbKYyWCf0+qwjEVbc 7wccsKNWNr3D007R66JZtCiktuuc6CBsuxBzsBVS4uEA8YUXM3XNJM4mgTFdUfG+SOQaN30E4xtF vgGqDTSea6Q0tz2TbA8Xb+YUhEO3tbU8ulXdWLX7TI4YMYIBuDCCAbQCAQEwVTBOMQswCQYDVQQG EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1c3QgVHJ1ZSBDcmVk ZW50aWFscyBDQSAyAgMQAGswCQYFKw4DAhoFAKCBujAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wMjA4MDEyMDIxMjlaMCMGCSqGSIb3DQEJBDEWBBQB8FODghiCG/ld KBkehnNjvVC1lTBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCHTANBgkqhkiG9w0B AQEFAASBgCdCynwcro8NpH1RKpzLy2NZPviryIYAgLvrj93l06Ad4S61jyM2em7svy/qUZSmtSgb HPUokGHN3KzMUJ+YkL1Gl6gYRJOzknpMiXer9NBg3Ct7EB68fliWb6hHIPv+aBhUe+hd/NNyCj5d y6AAKOScYr8XDd7N5hy1Oo4RIlCcAAAAAAAA ------=_NextPart_000_009E_01C239A1.66FEFCE0-- From tvo@EnterZone.Net Thu Aug 1 21:29:17 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 1 Aug 2002 16:29:17 -0400 (EDT) Subject: [6bone] Instability incarnate In-Reply-To: <00a201c23999$059f4a20$611c08d9@kewlio.net> Message-ID: It figures it is someone without a real ASN that is flapping. humbolt.nl.linux.org (131.211.28.48) tunnel: IPv6 in IPv4 m6.ipv6.euronet.be -> humbolt.nl.linux.org COMPENDIUM BGP4+ So, the flapper is COMPENDIUM. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On Thu, 1 Aug 2002, Daniel Austin wrote: > Hello, > > 3ffe:80d0:fffc:10::40 > 4 2042 5096 5609 0 0 0 1d03h13m 230 > > AS24765 <--> AS2042 no flaps between us and mimos... > > > With Thanks, > > Daniel Austin, > Managing Director, > kewlio.net Limited. > > > 45328 2042 24765 13944, (suppressed due to dampening), (received & used) > > 3FFE:8100:200:2FFF::9 from 3FFE:8100:200:2FFF::9 (131.211.28.48) > > Origin IGP, localpref 100, valid, external > > Dampinfo: penalty 6134, flapped 128 times in 07:31:31, reuse in 00:45:30 From Daniel Austin" Message-ID: <00ca01c2399b$0d785820$611c08d9@kewlio.net> This is a multi-part message in MIME format. ------=_NextPart_000_00C6_01C239A3.6ED80AE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ah... Well, we only accept private peers with ASN's in the correct ranges. Maybe i'll start using 45678 as my ASN from now on ;-) With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. ----- Original Message ----- From: "John Fraizer" To: "Daniel Austin" Cc: <6bone@ISI.EDU> Sent: Thursday, August 01, 2002 9:29 PM Subject: Re: [6bone] Instability incarnate > > > It figures it is someone without a real ASN that is flapping. > > > humbolt.nl.linux.org (131.211.28.48) > > tunnel: IPv6 in IPv4 m6.ipv6.euronet.be -> humbolt.nl.linux.org COMPENDIUM BGP4+ > > So, the flapper is COMPENDIUM. > > --- > John Fraizer | High-Security Datacenter Services | > EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | > http://www.enterzone.net/ | Virtual, Dedicated, Colocation | > > > On Thu, 1 Aug 2002, Daniel Austin wrote: > > > Hello, > > > > 3ffe:80d0:fffc:10::40 > > 4 2042 5096 5609 0 0 0 1d03h13m 230 > > > > AS24765 <--> AS2042 no flaps between us and mimos... > > > > > > With Thanks, > > > > Daniel Austin, > > Managing Director, > > kewlio.net Limited. > > > > > > 45328 2042 24765 13944, (suppressed due to dampening), (received & used) > > > 3FFE:8100:200:2FFF::9 from 3FFE:8100:200:2FFF::9 (131.211.28.48) > > > Origin IGP, localpref 100, valid, external > > > Dampinfo: penalty 6134, flapped 128 times in 07:31:31, reuse in 00:45:30 > > ------=_NextPart_000_00C6_01C239A3.6ED80AE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIYzCCAnow ggHjoAMCAQICARcwDQYJKoZIhvcNAQEFBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTAyMDQxODE1MjkzN1oXDTIwMDQxMzE1MjkzN1owTjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdl b1RydXN0IEluYy4xJzAlBgNVBAMTHkdlb1RydXN0IFRydWUgQ3JlZGVudGlhbHMgQ0EgMjCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAspcspZISpYX/aJqWoYcSyyGqFby3OvsepRzLRU0ENDJR wJo7DwFpirRFOUQkTkKXsY6BQzX/CeCRrn9i4ny5gcXuI2JSyrSmDwobbwl52n5cPEbHGcebybWd KfAf8vvkxYUnTmDZPtt2ob5RNpJTeTiq9MpNCB/5G7Ocr1hEljcCAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgHGMB0GA1UdDgQWBBQig0tNIAIMMfR8WrAaTRXIeF0RSTAPBgNVHRMBAf8EBTADAQH/MB8G A1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA0GCSqGSIb3DQEBBQUAA4GBACmw3z+sLsLS fAfdECQJPfiZFzJzSPQKLwY7vHnNWH2lAKYECbtAFHBpdyhSPkrj3KghXeIJnKyMFjsK6xd1k1Yu wMXrauUH+HIDuZUg4okBwQbhBTqjjEdo/cCHILQsaLeU2kM+n5KKrpb0uvrHrocGffRMrWhz9zYB lxoq0/EEMIICgjCCAeugAwIBAgIBBDANBgkqhkiG9w0BAQQFADBTMQswCQYDVQQGEwJVUzEcMBoG A1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1c2lu ZXNzIENBLTEwHhcNOTkwNjIxMDQwMDAwWhcNMjAwNjIxMDQwMDAwWjBTMQswCQYDVQQGEwJVUzEc MBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1 c2luZXNzIENBLTEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM4vGbwXt3fek6lfWg0XTzQa DJj0ItlZ1MRoRvC0NcWFAyDGr0WlIVFFQesWWDYyb+JQYmT5/VGcqiTZ9J2DKocKIdMSODRsjQBu WqDZQu4aIZX5UkxVWsUPOE9G+m34LjXWHXzr4vCwdYDIqROsvojvOm6rXyo4YgKwEnv+j6YDAgMB AAGjZjBkMBEGCWCGSAGG+EIBAQQEAwIABzAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFEp4 MlIR21kWNl7fwRQ2QGpHfEyhMB0GA1UdDgQWBBRKeDJSEdtZFjZe38EUNkBqR3xMoTANBgkqhkiG 9w0BAQQFAAOBgQB1W6ibAxHm6VZMzfmpTMANmvPMZWnmJXbMWbfWVMMdzZmsGd20hdXgPfxiIKeE S1hl8eL5lSE/9dR+WB5Hh1Q+WKG1tfgq73HnvMP2sUlG4tega+VWeponmHxGYhTnyfxuAxJ5gDgd SIKN/Bf+KpYrtWKmpj29f5JZzVoqgrI3eTCCA1swggLEoAMCAQICAxAAazANBgkqhkiG9w0BAQQF ADBOMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1 c3QgVHJ1ZSBDcmVkZW50aWFscyBDQSAyMB4XDTAyMDgwMTE4MjYzOVoXDTAzMDgxNTE4MjYzOVow ggERMT8wPQYDVQQLEzZDUFMgdGVybXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZSBsaWFiaWxp dHkgbGltaXRlZC4xPjA8BgNVBAsTNVNlZSBQdWJsaWMgUy9NSU1FIENQUyB3d3cuZ2VvdHJ1c3Qu Y29tL3Jlc291cmNlcy9DUFMuMSowKAYDVQQLEyFQaG9uZSBWYWxpZGF0aW9uIC0gNDQgNzk3MC02 MzMzMzMxKDAmBgNVBAsTH0VtYWlsIGFuZCBwaG9uZSB2YWxpZGF0ZWQgb25seS4xFjAUBgNVBAMT DURhbmllbCBBdXN0aW4xIDAeBgkqhkiG9w0BCQEWEWRhbmllbEBrZXdsaW8ubmV0MIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCnZ7IrV88D55wCg31dENNY6z1/ehvUcOxWC4sh5hJMgMXNefiR mXQiDD6iRESdk5UJ5usgZZr40ICYwlpjBUY6xBTe4LNLiC1UPVZ9uF3Z05CVgvgXEhvqC3p8WM3O sKYfGXL7k49xmBU9TvpkExdxSEYJoK4rK77qRFC5HuKcMwIDAQABo4GBMH8wEQYJYIZIAYb4QgEB BAQDAgWgMA4GA1UdDwEB/wQEAwIF4DA5BgNVHR8EMjAwMC6gLKAqhihodHRwOi8vY3JsLmdlb3Ry dXN0LmNvbS9jcmxzL2d0dGNjYTIuY3JsMB8GA1UdIwQYMBaAFCKDS00gAgwx9HxasBpNFch4XRFJ MA0GCSqGSIb3DQEBBAUAA4GBABslhvo5nWHvXY0xcGwSdigKcnAIgRiH8zlmbKYyWCf0+qwjEVbc 7wccsKNWNr3D007R66JZtCiktuuc6CBsuxBzsBVS4uEA8YUXM3XNJM4mgTFdUfG+SOQaN30E4xtF vgGqDTSea6Q0tz2TbA8Xb+YUhEO3tbU8ulXdWLX7TI4YMYIBuDCCAbQCAQEwVTBOMQswCQYDVQQG EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1c3QgVHJ1ZSBDcmVk ZW50aWFscyBDQSAyAgMQAGswCQYFKw4DAhoFAKCBujAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wMjA4MDEyMDM2MDJaMCMGCSqGSIb3DQEJBDEWBBRdWKOMrSeFw/aG jm284tzQfTjD2DBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCHTANBgkqhkiG9w0B AQEFAASBgIsXzh1DNYdk3jwKRqGwOUMSgVqbe6oD7kqy2bnigt8wcc5/WHmHujOuN98FJ+/cZuSZ +1sgKAT3VPNm9LHJpFW6z/PbJqHmzN0DNFB6gorZLRWIoP1cxTVav8NjUwrgh5sDM1h2AdLOmqZo /93MvaKAU+Ast2qo/3/Mv9PCMjhmAAAAAAAA ------=_NextPart_000_00C6_01C239A3.6ED80AE0-- From jeroen@unfix.org Thu Aug 1 22:22:46 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 1 Aug 2002 23:22:46 +0200 Subject: [6bone] Instability incarnate In-Reply-To: <00ca01c2399b$0d785820$611c08d9@kewlio.net> Message-ID: <003b01c239a1$951da0e0$420d640a@unfix.org> Daniel Austin wrote: > Well, we only accept private peers with ASN's in the correct ranges. > Maybe i'll start using 45678 as my ASN from now on ;-) IMHO, those private ASN's shouldn't be seen in the global routing table *AT ALL* That's why they are private, just like RFC1918 space shouldn't be seen on the public internet. Greets, Jeroen From Daniel Austin" Message-ID: <003b01c239a2$338785c0$611c08d9@kewlio.net> This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C239AA.94F98800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jeroen Massar" To: "'Daniel Austin'" ; "'John Fraizer'" Cc: <6bone@ISI.EDU> Sent: Thursday, August 01, 2002 10:22 PM Subject: RE: [6bone] Instability incarnate > Daniel Austin wrote: > > > Well, we only accept private peers with ASN's in the correct ranges. > > Maybe i'll start using 45678 as my ASN from now on ;-) > > IMHO, those private ASN's shouldn't be seen in the global routing table > *AT ALL* > That's why they are private, just like RFC1918 space shouldn't be seen > on the public internet. I agree... I allow BGP connections from private ASN's, but i wont re-distribute them to other peers. With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. > Greets, > Jeroen > > ------=_NextPart_000_0037_01C239AA.94F98800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIYzCCAnow ggHjoAMCAQICARcwDQYJKoZIhvcNAQEFBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTAyMDQxODE1MjkzN1oXDTIwMDQxMzE1MjkzN1owTjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdl b1RydXN0IEluYy4xJzAlBgNVBAMTHkdlb1RydXN0IFRydWUgQ3JlZGVudGlhbHMgQ0EgMjCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAspcspZISpYX/aJqWoYcSyyGqFby3OvsepRzLRU0ENDJR wJo7DwFpirRFOUQkTkKXsY6BQzX/CeCRrn9i4ny5gcXuI2JSyrSmDwobbwl52n5cPEbHGcebybWd KfAf8vvkxYUnTmDZPtt2ob5RNpJTeTiq9MpNCB/5G7Ocr1hEljcCAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgHGMB0GA1UdDgQWBBQig0tNIAIMMfR8WrAaTRXIeF0RSTAPBgNVHRMBAf8EBTADAQH/MB8G A1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA0GCSqGSIb3DQEBBQUAA4GBACmw3z+sLsLS fAfdECQJPfiZFzJzSPQKLwY7vHnNWH2lAKYECbtAFHBpdyhSPkrj3KghXeIJnKyMFjsK6xd1k1Yu wMXrauUH+HIDuZUg4okBwQbhBTqjjEdo/cCHILQsaLeU2kM+n5KKrpb0uvrHrocGffRMrWhz9zYB lxoq0/EEMIICgjCCAeugAwIBAgIBBDANBgkqhkiG9w0BAQQFADBTMQswCQYDVQQGEwJVUzEcMBoG A1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1c2lu ZXNzIENBLTEwHhcNOTkwNjIxMDQwMDAwWhcNMjAwNjIxMDQwMDAwWjBTMQswCQYDVQQGEwJVUzEc MBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1 c2luZXNzIENBLTEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM4vGbwXt3fek6lfWg0XTzQa DJj0ItlZ1MRoRvC0NcWFAyDGr0WlIVFFQesWWDYyb+JQYmT5/VGcqiTZ9J2DKocKIdMSODRsjQBu WqDZQu4aIZX5UkxVWsUPOE9G+m34LjXWHXzr4vCwdYDIqROsvojvOm6rXyo4YgKwEnv+j6YDAgMB AAGjZjBkMBEGCWCGSAGG+EIBAQQEAwIABzAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFEp4 MlIR21kWNl7fwRQ2QGpHfEyhMB0GA1UdDgQWBBRKeDJSEdtZFjZe38EUNkBqR3xMoTANBgkqhkiG 9w0BAQQFAAOBgQB1W6ibAxHm6VZMzfmpTMANmvPMZWnmJXbMWbfWVMMdzZmsGd20hdXgPfxiIKeE S1hl8eL5lSE/9dR+WB5Hh1Q+WKG1tfgq73HnvMP2sUlG4tega+VWeponmHxGYhTnyfxuAxJ5gDgd SIKN/Bf+KpYrtWKmpj29f5JZzVoqgrI3eTCCA1swggLEoAMCAQICAxAAazANBgkqhkiG9w0BAQQF ADBOMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1 c3QgVHJ1ZSBDcmVkZW50aWFscyBDQSAyMB4XDTAyMDgwMTE4MjYzOVoXDTAzMDgxNTE4MjYzOVow ggERMT8wPQYDVQQLEzZDUFMgdGVybXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZSBsaWFiaWxp dHkgbGltaXRlZC4xPjA8BgNVBAsTNVNlZSBQdWJsaWMgUy9NSU1FIENQUyB3d3cuZ2VvdHJ1c3Qu Y29tL3Jlc291cmNlcy9DUFMuMSowKAYDVQQLEyFQaG9uZSBWYWxpZGF0aW9uIC0gNDQgNzk3MC02 MzMzMzMxKDAmBgNVBAsTH0VtYWlsIGFuZCBwaG9uZSB2YWxpZGF0ZWQgb25seS4xFjAUBgNVBAMT DURhbmllbCBBdXN0aW4xIDAeBgkqhkiG9w0BCQEWEWRhbmllbEBrZXdsaW8ubmV0MIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCnZ7IrV88D55wCg31dENNY6z1/ehvUcOxWC4sh5hJMgMXNefiR mXQiDD6iRESdk5UJ5usgZZr40ICYwlpjBUY6xBTe4LNLiC1UPVZ9uF3Z05CVgvgXEhvqC3p8WM3O sKYfGXL7k49xmBU9TvpkExdxSEYJoK4rK77qRFC5HuKcMwIDAQABo4GBMH8wEQYJYIZIAYb4QgEB BAQDAgWgMA4GA1UdDwEB/wQEAwIF4DA5BgNVHR8EMjAwMC6gLKAqhihodHRwOi8vY3JsLmdlb3Ry dXN0LmNvbS9jcmxzL2d0dGNjYTIuY3JsMB8GA1UdIwQYMBaAFCKDS00gAgwx9HxasBpNFch4XRFJ MA0GCSqGSIb3DQEBBAUAA4GBABslhvo5nWHvXY0xcGwSdigKcnAIgRiH8zlmbKYyWCf0+qwjEVbc 7wccsKNWNr3D007R66JZtCiktuuc6CBsuxBzsBVS4uEA8YUXM3XNJM4mgTFdUfG+SOQaN30E4xtF vgGqDTSea6Q0tz2TbA8Xb+YUhEO3tbU8ulXdWLX7TI4YMYIBuDCCAbQCAQEwVTBOMQswCQYDVQQG EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1c3QgVHJ1ZSBDcmVk ZW50aWFscyBDQSAyAgMQAGswCQYFKw4DAhoFAKCBujAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wMjA4MDEyMTI3MTJaMCMGCSqGSIb3DQEJBDEWBBQb67oQGgkQjwBl mRozXwm77OripTBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCHTANBgkqhkiG9w0B AQEFAASBgCfcMX0XouEGx2aweYyI75FAjCj4Io2kCem2E2Dbsmx85tv+9SGYb367Iixl16ihg0oz WJGk/MqHnEOvZknB9VDxT05SnAOvnbeByZvO4QRJ+ZWLqLkhLidrMb1kEoQRYMeCiDFAE7lqC10b 74e5OiwhNzoHpwmCXHN8ZI250VpyAAAAAAAA ------=_NextPart_000_0037_01C239AA.94F98800-- From itojun@iijlab.net Fri Aug 2 00:43:18 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Fri, 02 Aug 2002 08:43:18 +0900 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: gert's message of Thu, 01 Aug 2002 22:16:45 +0200. <20020801221645.I27015@Space.Net> Message-ID: <20020801234318.4D9FA4B22@coconut.itojun.org> >On Thu, Aug 01, 2002 at 08:26:35AM -0700, Michel Py wrote: >> > And by the way, a /126 is perfect for Point-to-point >> No, it is as illegal with draft-ietf-ipngwg-addr-arch-v3-08.txt than it >> is with RFC2374, read draft-ietf-ipngwg-addr-arch-v3-08.txt again. >Whether the standard says it's illegal or not, /127s works fine (yes, >even /127). Why create ambiguities by assigning more than 2 IPs to >something that needs exactly 2? because "0" is reserved for subnet router anycast address, you shouldn't use blah:0/127 for your nodes as unicsat address. go read the draft on this topic. itojun From riel@conectiva.com.br Fri Aug 2 02:11:49 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Thu, 1 Aug 2002 22:11:49 -0300 (BRT) Subject: [6bone] Instability incarnate In-Reply-To: Message-ID: On Thu, 1 Aug 2002, John Fraizer wrote: > It figures it is someone without a real ASN that is flapping. I'm one of the admins of nl.linux.org, but I'll have to note that COMPENDIUM has used this ASN since before I joined. I've now contacted the maintainer of COMPENDIUM and am looking at a way to get a real ASN. Preferably without paying $500/year to ARIN ;) > humbolt.nl.linux.org (131.211.28.48) > > tunnel: IPv6 in IPv4 m6.ipv6.euronet.be -> humbolt.nl.linux.org COMPENDIUM BGP4+ > > So, the flapper is COMPENDIUM. I've had problems reaching this host over ipv4 too, today. Could it be possible the flapping has occured because ipv4 routing for the tunnels got disrupted ? kind regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From tvo@EnterZone.Net Fri Aug 2 02:16:33 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 1 Aug 2002 21:16:33 -0400 (EDT) Subject: [6bone] Instability incarnate In-Reply-To: <003b01c239a1$951da0e0$420d640a@unfix.org> Message-ID: neighbor xx:xx::x remove-private-AS This command is YOUR FRIEND! --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On Thu, 1 Aug 2002, Jeroen Massar wrote: > Daniel Austin wrote: > > > Well, we only accept private peers with ASN's in the correct ranges. > > Maybe i'll start using 45678 as my ASN from now on ;-) > > IMHO, those private ASN's shouldn't be seen in the global routing table > *AT ALL* > That's why they are private, just like RFC1918 space shouldn't be seen > on the public internet. > > Greets, > Jeroen > From michel@arneill-py.sacramento.ca.us Fri Aug 2 02:47:22 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 1 Aug 2002 18:47:22 -0700 Subject: [6bone] semi-newbie Q on IPv6 address planning Message-ID: <2B81403386729140A3A899A8B39B046406C9FC@server2000.arneill-py.sacramento.ca.us> Gert, > Gert Doering wrote: > Whether the standard says it's illegal or not, /127s works > fine (yes, even /127). Why create ambiguities by assigning > more than 2 IPs to something that needs exactly 2? Read draft-savola-ipv6-127-prefixlen-04.txt http://search.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-0 4.txt Michel. From tvo@EnterZone.Net Fri Aug 2 02:52:55 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 1 Aug 2002 21:52:55 -0400 (EDT) Subject: [6bone] Instability incarnate In-Reply-To: Message-ID: On Thu, 1 Aug 2002, Rik van Riel wrote: > On Thu, 1 Aug 2002, John Fraizer wrote: > > > It figures it is someone without a real ASN that is flapping. > > I'm one of the admins of nl.linux.org, but I'll have to note that > COMPENDIUM has used this ASN since before I joined. I've now > contacted the maintainer of COMPENDIUM and am looking at a way > to get a real ASN. Preferably without paying $500/year to ARIN ;) > > > humbolt.nl.linux.org (131.211.28.48) > > > > tunnel: IPv6 in IPv4 m6.ipv6.euronet.be -> humbolt.nl.linux.org COMPENDIUM BGP4+ > > > > So, the flapper is COMPENDIUM. > > I've had problems reaching this host over ipv4 too, today. > Could it be possible the flapping has occured because ipv4 > routing for the tunnels got disrupted ? > > kind regards, > > Rik That is completely possible. I contend that this is *ALL* possible to monotor via SNMP. (If you're running anything *close* to production quality code that is. If you're not, don't bother requesting a BGP session with ENTERZONE!) If you're not monitoring this, can I ask why not? I'm not jumping anyones case here. I just tend to expect my peers to take things as seriously as I do and take the same precautions. --- 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 Fri Aug 2 02:58:47 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Thu, 1 Aug 2002 22:58:47 -0300 (BRT) Subject: [6bone] Instability incarnate In-Reply-To: Message-ID: [enterzone snipped from cc list, it's refusing my mail anyway] On Thu, 1 Aug 2002, John Fraizer wrote: > quality code that is. If you're not, don't bother requesting a BGP > session with ENTERZONE!) The tunnel you're complaining about was requested by your side of the tunnel, not by mine. You're also blocking my email, which makes it kind of hard to exchange information on problems. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From fink@es.net Fri Aug 2 03:11:39 2002 From: fink@es.net (Bob Fink) Date: Thu, 01 Aug 2002 19:11:39 -0700 Subject: Yokohama Minutes (Was: RE: [6bone] Re: routing concern) In-Reply-To: <20020801141500.97C004B22@coconut.itojun.org> References: Message-ID: <5.1.0.14.0.20020801180742.020f7530@imap2.es.net> At 11:15 PM 8/1/2002 +0900, itojun@iijlab.net wrote: > >> BTW, I was curious about the 6bone meeting in Yokohama, as there have > >> been talks with the RIRs. Did I miss the minutes? > >I picked up the following from the ietf list; > >Nothing more afaik though... > >the ipv6 panel presentations are available in pdf at > > > > this one is totally separate from 6bone meeting. Bob, do you have > you slides online? Sorry to be slow getting this up. It is online now. Minutes and the written proposal will follow soon. just below the ngtrans prstns. Bob From michel@arneill-py.sacramento.ca.us Fri Aug 2 04:25:40 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 1 Aug 2002 20:25:40 -0700 Subject: Yokohama Minutes (Was: RE: [6bone] Re: routing concern) Message-ID: <2B81403386729140A3A899A8B39B046405E23D@server2000.arneill-py.sacramento.ca.us> Bob and sixboners, > Being perceived as part of the solution, not > part of the problem, Given the current thread going on the mailing list, I hope it has become clear to everyone that the 6bone is indeed part of the solution. > remembering that to do nothing, or to not reach > agreement, runs the risk of other events > overtaking the 6bone That would be a shame, wouldn't it? As far as I am concerned, I will do every thing in my power to prevent this from happening and I call for each and every member of this community to rally behind Bob and bring our 6bone to the next step in its evolution. > In order to receive 6bone address services from an > RIR as described here, each 6bone member must "join" > that RIR, that is, enter into the appropriate membership > or services agreement with the RIR. Would this include end-sites? That would not be a problem for end-sites such as mine, but what about pTLAs that have large pools of completely automated tunnel brokers? > There will be exceptions for unusual and new proposals > per joint RIR and 6bone review and approval. A relevant > example of this is one or more new strategies such as > geographic or metro addressing. Allow me to re-assert my support to the issue that was discussed before and that Thomas Narten brought up recently here that unusual and new proposals might be subject to unusual and new restrictions, especially in terms of shelf life. > joint RIR and 6bone review I could use suggestions WRT cross-posting on several mailing lists when sending my request. > Allocations will be made on the clear and stated > understanding that the prefix 3ffe::/16 has a limited > lifetime. The expiration date of the prefix and the 6bone > allocation made from this prefix is yet to be determined > but will not be done by the RIR Completely agree. Michel. From fink@es.net Fri Aug 2 04:50:37 2002 From: fink@es.net (Bob Fink) Date: Thu, 01 Aug 2002 20:50:37 -0700 Subject: Yokohama Minutes (Was: RE: [6bone] Re: routing concern) In-Reply-To: <2B81403386729140A3A899A8B39B046405E23D@server2000.arneill- py.sacramento.ca.us> Message-ID: <5.1.0.14.0.20020801204148.022ade30@imap2.es.net> Michel, At 08:25 PM 8/1/2002 -0700, Michel Py wrote: >Bob and sixboners, > > > Being perceived as part of the solution, not > > part of the problem, > >Given the current thread going on the mailing list, I hope it has become >clear to everyone that the 6bone is indeed part of the solution. I hope so. We will need to develop a system soon with the help of the IETF community to determine the reasonable lifetime of the 6bone. > > remembering that to do nothing, or to not reach > > agreement, runs the risk of other events > > overtaking the 6bone > >That would be a shame, wouldn't it? As far as I am concerned, I will do >every thing in my power to prevent this from happening and I call for >each and every member of this community to rally behind Bob and bring >our 6bone to the next step in its evolution. Well, this is not a hand wave. As I mentioned above, we need to work out a mutual process with the IETF community to decide the 6bone's future. The RIRs were clear to me that it isn't their place to ever try to determine this. > > In order to receive 6bone address services from an > > RIR as described here, each 6bone member must "join" > > that RIR, that is, enter into the appropriate membership > > or services agreement with the RIR. > >Would this include end-sites? That would not be a problem for end-sites >such as mine, but what about pTLAs that have large pools of completely >automated tunnel brokers? I believe this only applies to the pTLA level as they would get their allocation from the RIR. Nets and end-sites below the pTLAs get their services from the pTLA (or pNLA). > > There will be exceptions for unusual and new proposals > > per joint RIR and 6bone review and approval. A relevant > > example of this is one or more new strategies such as > > geographic or metro addressing. > >Allow me to re-assert my support to the issue that was discussed before >and that Thomas Narten brought up recently here that unusual and new >proposals might be subject to unusual and new restrictions, especially >in terms of shelf life. These will always need very special review and understanding as well as strong support from the IETF that it is responsible, relevant and useful (at a minimum). > > joint RIR and 6bone review > >I could use suggestions WRT cross-posting on several mailing lists when >sending my request. > > > > Allocations will be made on the clear and stated > > understanding that the prefix 3ffe::/16 has a limited > > lifetime. The expiration date of the prefix and the 6bone > > allocation made from this prefix is yet to be determined > > but will not be done by the RIR > >Completely agree. > >Michel. Thanks for your comments. Hopefully I can get the written proposal I used to prepare the presentation, and some minutes from the lunchtime meeting in Yokohama, out soon. Bob From michel@arneill-py.sacramento.ca.us Fri Aug 2 05:29:37 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 1 Aug 2002 21:29:37 -0700 Subject: Yokohama Minutes (Was: RE: [6bone] Re: routing concern) Message-ID: <2B81403386729140A3A899A8B39B046406CA02@server2000.arneill-py.sacramento.ca.us> > Bob Fink wrote: > We will need to develop a system soon > with the help of the IETF community to determine > the reasonable lifetime of the 6bone. What about this: "As long as it is needed." Michel. From pim@ipng.nl Fri Aug 2 07:55:42 2002 From: pim@ipng.nl (Pim van Pelt) Date: Fri, 2 Aug 2002 08:55:42 +0200 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: References: <20020801140949.EA6D44B24@coconut.itojun.org> Message-ID: <20020802065542.GA13936@bfib.colo.bit.nl> | That just solved that problem then. | | ipv6 prefix-list subTLA-only seq 5 permit 3ffe::/18 ge 24 le 24 | ipv6 prefix-list subTLA-only seq 10 permit 3ffe:4000::/18 ge 32 le 32 | ipv6 prefix-list subTLA-only seq 15 permit 3ffe:8000::/20 ge 28 le 28 | ipv6 prefix-list subTLA-only seq 20 permit 2000::/3 ge 16 le 16 | ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35 | ipv6 prefix-list subTLA-only seq 30 permit 2002::/16 | ipv6 prefix-list subTLA-only seq 500 deny any I would disallow seq 20 because there are no other allocations yet in the 2000::/3 scope, other than the ones you have already explicitly specified. The name is also flawed: These are no longer subTLAs. If I were to chose a name for this filter, I would call it 'strict' where-as a 'sloppy' filter in my definition would allow /48 and smaller prefixes in the 6BONE networks and ALLOCATED-RIR networks. Also, it's just a matter of time before some company (in Japan?) will start announcing a prefix smaller than /29, so I do hope this information gets loudly broadcasted so law-obiding citizens can adjust their filters. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From gert@space.net Fri Aug 2 08:40:10 2002 From: gert@space.net (Gert Doering) Date: Fri, 2 Aug 2002 09:40:10 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <2B81403386729140A3A899A8B39B046406C9FC@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Thu, Aug 01, 2002 at 06:47:22PM -0700 References: <2B81403386729140A3A899A8B39B046406C9FC@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020802094010.L27015@Space.Net> Hi, On Thu, Aug 01, 2002 at 06:47:22PM -0700, Michel Py wrote: > > Gert Doering wrote: > > Whether the standard says it's illegal or not, /127s works > > fine (yes, even /127). Why create ambiguities by assigning > > more than 2 IPs to something that needs exactly 2? > > Read draft-savola-ipv6-127-prefixlen-04.txt > > http://search.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-0 > 4.txt Done. I don't agree with many of the conclusions - why would it be "the best" solution to assign /64s to ptp links? There is nothing "good" about /64s. If /127s are not used, what is the benefit of a /112? Who needs 64k addresses on a ptp link? The general issue of anycast addresses on ptp links doesn't sound very useful either, but this seems to be an unavoidable issue - so thanks for pointing it out, we'll consider moving to /126s. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46284 (46191) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert@space.net Fri Aug 2 08:42:25 2002 From: gert@space.net (Gert Doering) Date: Fri, 2 Aug 2002 09:42:25 +0200 Subject: [6bone] Instability incarnate In-Reply-To: ; from tvo@EnterZone.Net on Thu, Aug 01, 2002 at 09:16:33PM -0400 References: <003b01c239a1$951da0e0$420d640a@unfix.org> Message-ID: <20020802094225.M27015@Space.Net> Hi, On Thu, Aug 01, 2002 at 09:16:33PM -0400, John Fraizer wrote: > neighbor xx:xx::x remove-private-AS > > This command is YOUR FRIEND! Not really. It means that you see instabilities and don't even know which AS was causing them. A much better approach would be to immediately stop running BGP with anything that uses a private or illegal AS number. If they want connectivity, statically route them a /48. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46284 (46191) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From kre@munnari.OZ.AU Fri Aug 2 08:59:50 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 02 Aug 2002 14:59:50 +0700 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <20020801234318.4D9FA4B22@coconut.itojun.org> References: <20020801234318.4D9FA4B22@coconut.itojun.org> Message-ID: <17459.1028275190@munnari.OZ.AU> Date: Fri, 02 Aug 2002 08:43:18 +0900 From: itojun@iijlab.net Message-ID: <20020801234318.4D9FA4B22@coconut.itojun.org> | because "0" is reserved for subnet router anycast address, you shouldn't | use blah:0/127 for your nodes as unicsat address. go read the draft | on this topic. But you don't need a subnet router anycast address on a p2p link. If you are a router then ::1 will work just fine to reach the nearest router... If you're not, then "the other guy" on the p2p link must be it (or there is no router at all, in which case it doesn't matter what address you use). It can't be used from outside the link, as there's no way for outside nodes to discover the 'n' that applies to the figure at the top of page 14 of the draft (if you configure that on some node, you may as well just configure the router address - anycast or unicast - that it would reach). [Aside: do notice that 'n' is used, not "64"] Unless someone can come up with some kind of technical reason why every subnet in the universe must be forced to use a /64 prefix, people are just going to go on using whatever they like. And "the doc says" is not a technical reason (nor does the doc contain one). No question, if the prefix length is > 64 then autoconfiguration isn't going to work, but on p2p links (and some eothers) that's usually irrelevant, and in any case, whether autoconfig gets used is always for the local site to decide. kre From kre@munnari.OZ.AU Fri Aug 2 09:07:51 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 02 Aug 2002 15:07:51 +0700 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: References: Message-ID: <17479.1028275671@munnari.OZ.AU> Date: Thu, 1 Aug 2002 07:06:47 -1000 (HST) From: Antonio Querubin Message-ID: | For us, assigning on nibble boundaries for multiple-subnet sites scales | much better too than the one-size-fits-all /48. If you are assigning nets to sites, then /48 (or /47 or similar in perhaps some very rare cases) is what you should be assigning. There's a reason for that one, unlike the "every subnet must be exactly /64" that some people advocate. The reason is so that the assignment size from one assigning organisation will be the same as that from another, preventing a client org from being captured because no-one else will give them the address space they (feel they) need. That's a legitimate concern, and one that should be accounted for, when one organisation is assigning addresses to others, it should always assign /48. But when an organisation is dividing up the space assigned to it, for its own purposes, it is for that organisation to decide how the divisions should be done (it is all an internal matter, affecting no-one else). Always assigning /64 (even for p2p) is a perfectly valid choice, and most likely has a whole bunch of benefits (for the organisation, it matters nothing to anyone else), but there's no reason to compel that. kre From joao@ripe.net Fri Aug 2 09:39:40 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Fri, 2 Aug 2002 10:39:40 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.c a.us> References: <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.c a.us> Message-ID: At 8:26 -0700 1/8/02, Michel Py wrote: > > And by the way, a /126 is perfect for Point-to-point > >No, it is as illegal with draft-ietf-ipngwg-addr-arch-v3-08.txt than it >is with RFC2374, read draft-ietf-ipngwg-addr-arch-v3-08.txt again. I geuss you refer to section 2.5.1 where it says For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. which is used together with: (for the first 3 octets) 0 0 0 1 1 2 |0 7 8 5 6 3| +----+----+----+----+----+----+ |cccc|ccug|cccc|cccc|cccc|cccc| +----+----+----+----+----+----+ and The motivation for inverting the "u" bit when forming an interface identifier is to make it easy for system administrators to hand configure non-global identifiers when hardware tokens are not available. This is expected to be case for serial links, tunnel end- points, etc. The alternative would have been for these to be of the form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2, etc. Fine, and I will normally use 1 and 2 as the last 64 bits of the address for poi nt-to-point but I will also use a /126 mask for this stuff because it reduces the potential for mistakes, because if someone makes a mistake and types something inside the same /64 I am using for this interface, if it is also inside the /126 it will be easy to detect and if it is outside at least it won't screw my routing in a way that is hard to debug because some router starts thinking it has a direct connection to another one when it doesn't. I chose a /126 (instead of a /127, even before reading Pekka's draft) also because that's what a lot of network engineers are used to in IPv4 (a /31) and it minimises human error (which is far more frequent than a hardware failure). And I wish protocol design wasn't a game of designing nice bit templates and took operational practice into account as a starting point. Joao From gert@space.net Fri Aug 2 10:11:14 2002 From: gert@space.net (Gert Doering) Date: Fri, 2 Aug 2002 11:11:14 +0200 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: ; from tvo@EnterZone.Net on Thu, Aug 01, 2002 at 10:20:18AM -0400 References: <20020801140949.EA6D44B24@coconut.itojun.org> Message-ID: <20020802111114.N27015@Space.Net> Hi, On Thu, Aug 01, 2002 at 10:20:18AM -0400, John Fraizer wrote: > ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35 This will fit today's needs, but the global IPv6 policy does not forbid assignment of a /24 or even a /20 to a Really Big ISP. So maybe that should be: ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 20 le 35 (but as I said, *today*, nothing bigger than a /32 has been assigned) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46284 (46191) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Ronald.vanderPol@rvdp.org Fri Aug 2 10:11:40 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Fri, 2 Aug 2002 11:11:40 +0200 Subject: Yokohama Minutes (Was: RE: [6bone] Re: routing concern) In-Reply-To: <5.1.0.14.0.20020801180742.020f7530@imap2.es.net> References: <021d01c2395c$f0ad9f40$534510ac@cyan> <5.1.0.14.0.20020801180742.020f7530@imap2.es.net> Message-ID: <20020802091140.GB4353@rvdp.org> On Thu, Aug 01, 2002 at 19:11:39 -0700, Bob Fink wrote: > just below the ngtrans > prstns. Ahhrgh, http://[3ffe:b00:c18:1::10]/ngtrans/minutes/default.htm != http://131.243.129.43/ngtrans/minutes/default.htm And unfortunately, the v4 version has the 6bone information :-( rvdp From gert@space.net Fri Aug 2 10:37:16 2002 From: gert@space.net (Gert Doering) Date: Fri, 2 Aug 2002 11:37:16 +0200 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <2B81403386729140A3A899A8B39B046405E236@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Thu, Aug 01, 2002 at 08:46:52AM -0700 References: <2B81403386729140A3A899A8B39B046405E236@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020802113716.O27015@Space.Net> Hi, On Thu, Aug 01, 2002 at 08:46:52AM -0700, Michel Py wrote: > > ipv6 prefix-list subTLA-only seq 30 permit 2002::/16 > > Remarks on this: > - I think that seq 30 (6to4) could be optional. I don't think we want > this route floating on the 6bone. This would mean "not having connectivity to people using 6to4 IPv6". Why is this a desireable goal? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46284 (46191) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert@space.net Fri Aug 2 14:02:14 2002 From: gert@space.net (Gert Doering) Date: Fri, 2 Aug 2002 15:02:14 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: ; from joao@ripe.net on Fri, Aug 02, 2002 at 10:39:40AM +0200 References: <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.c <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.c a.us> Message-ID: <20020802150214.W27015@Space.Net> Hi, On Fri, Aug 02, 2002 at 10:39:40AM +0200, Joao Luis Silva Damas wrote: > I chose a /126 (instead of a /127, even before reading Pekka's draft) > also because that's what a lot of network engineers are used to in > IPv4 (a /31) and it minimises human error (which is far more frequent > than a hardware failure). Ummm. I assume a typo here, but the equivalent of a /31 in IPv4 world is a */127*, not a /126... > And I wish protocol design wasn't a game of designing nice bit > templates and took operational practice into account as a starting > point. Seconded. EUI-64 sucks big time (using MAC addresses and such is a nice idea, but why on earth can't they map 48 bits to 64 in a somewhat more straightforward way than "distribute them over all the 64bits"?) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46631 (46284) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From joao@ripe.net Fri Aug 2 14:06:09 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Fri, 2 Aug 2002 15:06:09 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <20020802150214.W27015@Space.Net> References: <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.c <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.c a.us> <20020802150214.W27015@Space.Net> Message-ID: At 15:02 +0200 2/8/02, Gert Doering wrote: >Hi, > >On Fri, Aug 02, 2002 at 10:39:40AM +0200, Joao Luis Silva Damas wrote: >> I chose a /126 (instead of a /127, even before reading Pekka's draft) >> also because that's what a lot of network engineers are used to in >> IPv4 (a /31) and it minimises human error (which is far more frequent >> than a hardware failure). > >Ummm. I assume a typo here, but the equivalent of a /31 in IPv4 world >is a */127*, not a /126... Typo indeed, make it /30 :-) > > And I wish protocol design wasn't a game of designing nice bit >> templates and took operational practice into account as a starting >> point. > >Seconded. EUI-64 sucks big time (using MAC addresses and such is a nice >idea, but why on earth can't they map 48 bits to 64 in a somewhat more >straightforward way than "distribute them over all the 64bits"?) And, would you use your router interface's mac address ever to configure the interface IP? Joao From fink@es.net Fri Aug 2 14:41:29 2002 From: fink@es.net (Bob Fink) Date: Fri, 02 Aug 2002 06:41:29 -0700 Subject: Yokohama Minutes (Was: RE: [6bone] Re: routing concern) In-Reply-To: <20020802091140.GB4353@rvdp.org> References: <5.1.0.14.0.20020801180742.020f7530@imap2.es.net> <021d01c2395c$f0ad9f40$534510ac@cyan> <5.1.0.14.0.20020801180742.020f7530@imap2.es.net> Message-ID: <5.1.0.14.0.20020802063911.022969c0@imap2.es.net> At 11:11 AM 8/2/2002 +0200, Ronald van der Pol wrote: >On Thu, Aug 01, 2002 at 19:11:39 -0700, Bob Fink wrote: > > > just below the ngtrans > > prstns. > >Ahhrgh, http://[3ffe:b00:c18:1::10]/ngtrans/minutes/default.htm != >http://131.243.129.43/ngtrans/minutes/default.htm > >And unfortunately, the v4 version has the 6bone information :-( It takes a while for the info to mirror to the v6 version. Bob From gert@space.net Fri Aug 2 15:26:36 2002 From: gert@space.net (Gert Doering) Date: Fri, 2 Aug 2002 16:26:36 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: ; from joao@ripe.net on Fri, Aug 02, 2002 at 03:06:09PM +0200 References: <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.c <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.c <20020802150214.W27015@Space.Net> Message-ID: <20020802162636.A27015@Space.Net> Hi, On Fri, Aug 02, 2002 at 03:06:09PM +0200, Joao Luis Silva Damas wrote: > >> I chose a /126 (instead of a /127, even before reading Pekka's draft) > >> also because that's what a lot of network engineers are used to in > >> IPv4 (a /31) and it minimises human error (which is far more frequent > >> than a hardware failure). > > > >Ummm. I assume a typo here, but the equivalent of a /31 in IPv4 world > >is a */127*, not a /126... > Typo indeed, make it /30 :-) On the other hand, we *do* use /31s on IPv4 ptp links. It's a recent change, but works well. > > > And I wish protocol design wasn't a game of designing nice bit > >> templates and took operational practice into account as a starting > >> point. > > > >Seconded. EUI-64 sucks big time (using MAC addresses and such is a nice > >idea, but why on earth can't they map 48 bits to 64 in a somewhat more > >straightforward way than "distribute them over all the 64bits"?) > > And, would you use your router interface's mac address ever to > configure the interface IP? Definitely not for the routers, nor for servers. For client-only hosts, it's a nice idea for smallish networks that don't want to setup DHCP. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46631 (46284) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert@space.net Fri Aug 2 15:28:45 2002 From: gert@space.net (Gert Doering) Date: Fri, 2 Aug 2002 16:28:45 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <20020802132456.GI5356@Burk.hax.SE>; from nils@naqua.se on Fri, Aug 02, 2002 at 03:24:57PM +0200 References: <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.ca.us> <20020802150214.W27015@Space.Net> <20020802132456.GI5356@Burk.hax.SE> Message-ID: <20020802162845.B27015@Space.Net> Hi, On Fri, Aug 02, 2002 at 03:24:57PM +0200, Nils Höglund wrote: > > Seconded. EUI-64 sucks big time (using MAC addresses and such is a nice > > idea, but why on earth can't they map 48 bits to 64 in a somewhat more > > straightforward way than "distribute them over all the 64bits"?) > > Probobly beacause there are more media-types and link layer protocols in the > world than ethernet. So? For those media types you need other rules anyway. No need to uglify things for the most common multiaccess network type. A decent approach could have been "put control stuff in the first 16 bits, map the MAC address 1:1 to the next 48 bits". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46631 (46284) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From michel@arneill-py.sacramento.ca.us Fri Aug 2 15:35:27 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 2 Aug 2002 07:35:27 -0700 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? Message-ID: <2B81403386729140A3A899A8B39B046406CA03@server2000.arneill-py.sacramento.ca.us> > Pim van Pelt wrote: | ipv6 prefix-list subTLA-only seq 5 permit 3ffe::/18 ge 24 le 24 | ipv6 prefix-list subTLA-only seq 10 permit 3ffe:4000::/18 ge 32 le 32 | ipv6 prefix-list subTLA-only seq 15 permit 3ffe:8000::/20 ge 28 le 28 | ipv6 prefix-list subTLA-only seq 20 permit 2000::/3 ge 16 le 16 | ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35 | ipv6 prefix-list subTLA-only seq 30 permit 2002::/16 | ipv6 prefix-list subTLA-only seq 500 deny any > I would disallow seq 20 because there are no other allocations yet > in the 2000::/3 scope, other than the ones you have already > explicitly specified. That's exactly the reason I had in mind. Let's drop 20. Michel. From michel@arneill-py.sacramento.ca.us Fri Aug 2 15:53:42 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 2 Aug 2002 07:53:42 -0700 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? Message-ID: <2B81403386729140A3A899A8B39B046405E23F@server2000.arneill-py.sacramento.ca.us> >> Michel Py wrote: >> Remarks on this: >> - I think that seq 30 (6to4) could be optional. I don't >> think we want this route floating on the 6bone. > Gert Doering wrote: > This would mean "not having connectivity to people using > 6to4 IPv6". Not at all. People providing 6to4 relay services can still feed that route to their downstreams. > Why is this a desireable goal? Because by announcing 2002::/16 on the 6bone, we create another form of anycast. Not only there already is an anycast mechanism, it is very seldom used. I do not see any reason to re-create another one. Let's make seq 30 optional. Michel. From gert@space.net Fri Aug 2 16:20:19 2002 From: gert@space.net (Gert Doering) Date: Fri, 2 Aug 2002 17:20:19 +0200 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <2B81403386729140A3A899A8B39B046405E23F@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Fri, Aug 02, 2002 at 07:53:42AM -0700 References: <2B81403386729140A3A899A8B39B046405E23F@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020802172019.C27015@Space.Net> Hi, On Fri, Aug 02, 2002 at 07:53:42AM -0700, Michel Py wrote: > >> Michel Py wrote: > >> Remarks on this: > >> - I think that seq 30 (6to4) could be optional. I don't > >> think we want this route floating on the 6bone. > > > Gert Doering wrote: > > This would mean "not having connectivity to people using > > 6to4 IPv6". > > Not at all. People providing 6to4 relay services can still feed that > route to their downstreams. But that means "not having connectivity to people using 6to4 IPv6" - most of the networks participating in the 6bone today are not usually considered "downstream" by their peers, and thus wouldn't have 2002::/16 unless they run their own 6to4 gateway. > > Why is this a desireable goal? > > Because by announcing 2002::/16 on the 6bone, we create another form of > anycast. Not only there already is an anycast mechanism, it is very > seldom used. I do not see any reason to re-create another one. The anycast mechanism for 6to4 (both on the v4 and v6 side) is already well-defined in the corresponding RFCs. We do not "create" anything, it's already there. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46631 (46284) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From michel@arneill-py.sacramento.ca.us Fri Aug 2 16:47:57 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 2 Aug 2002 08:47:57 -0700 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? Message-ID: <2B81403386729140A3A899A8B39B046405E240@server2000.arneill-py.sacramento.ca.us> John, > John Fraizier wrote: > (We'll use your peering session as an example Michel) > Any comments appreciated. - I am happy to see the addition of "set community no-export additive". - I think you should drop seq 20 2000::/3 ge 16 le 16 - As someone else mentioned, the "subTLA-only" name might not be appropriate. - There is overlap in the following two lines: neighbor 3ffe:1ced:ff02::2 prefix-list AS-ARNEILLPY in neighbor 3ffe:1ced:ff02::2 route-map AS-ARNEILLPY in The prefix-list is useless as the route-map uses it IMHO. This is the way I would have done it, comments welcomed. router bgp 13944 neighbor 3ffe:1ced:ff02::2 remote-as 23169 neighbor 3ffe:1ced:ff02::2 description ARNEILLPY no neighbor 3ffe:1ced:ff02::2 activate ! address-family ipv6 neighbor 3ffe:1ced:ff02::2 activate neighbor 3ffe:1ced:ff02::2 next-hop-self neighbor 3ffe:1ced:ff02::2 route-map AS-ARNEILLPY-IN in neighbor 3ffe:1ced:ff02::2 route-map AS-ARNEILLPY-OUT out exit-address-family ! ipv6 prefix-list AS-ARNEILLPY seq 5 permit 3ffe:1ced:a002::/48 ! ipv6 prefix-list MYPREFIX seq 5 permit 3ffe:1ced::/32 ! ipv6 prefix-list STRICT seq 5 permit 3ffe::/18 ge 24 le 24 ipv6 prefix-list STRICT seq 10 permit 3ffe:4000::/18 ge 32 le 32 ipv6 prefix-list STRICT seq 15 permit 3ffe:8000::/20 ge 28 le 28 ipv6 prefix-list STRICT seq 20 permit 2001::/16 ge 29 le 35 ipv6 prefix-list STRICT seq 500 deny any ! ipv6 prefix-list SIXTOFOUR seq 5 permit 2002::/16 ! route-map AS-ARNEILLPY-IN deny 10 description deny the peer feeding me my own prefix match ipv6 address prefix-list MYPREFIX ! route-map AS-ARNEILLPY-IN permit 20 description generic filter match ipv6 address prefix-list STRICT ! route-map AS-ARNEILLPY-IN permit 30 description accept other prefixes, don't redistribute match ipv6 address prefix-list AS-ARNEILLPY set community no-export additive ! ! route-map AS-ARNEILLPY-OUT permit 10 description generic filter match ipv6 address prefix-list STRICT ! route-map AS-ARNEILLPY-OUT permit 20 description feed _my_ 6to4 route only to the peer match ipv6 address prefix-list SIXTOFOUR match ** whatever condition that says the 6to4 route is yours ** set community no-export additive ! Michel. From michel@arneill-py.sacramento.ca.us Fri Aug 2 17:25:31 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 2 Aug 2002 09:25:31 -0700 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? Message-ID: <2B81403386729140A3A899A8B39B046406CA07@server2000.arneill-py.sacramento.ca.us> Oops copy/paste casualty this is missing at the end route-map AS-ARNEILLPY-OUT permit 30 description feed my prefix match ipv6 address prefix-list MYPREFIX ! From tvo@EnterZone.Net Fri Aug 2 18:12:47 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Fri, 2 Aug 2002 13:12:47 -0400 (EDT) Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <2B81403386729140A3A899A8B39B046405E240@server2000.arneill-py.sacramento.ca.us> Message-ID: On Fri, 2 Aug 2002, Michel Py wrote: > John, > > > John Fraizier wrote: > > (We'll use your peering session as an example Michel) > > Any comments appreciated. > > - I am happy to see the addition of "set community no-export additive". > > - I think you should drop seq 20 2000::/3 ge 16 le 16 > > - As someone else mentioned, the "subTLA-only" name might not be > appropriate. > > - There is overlap in the following two lines: > neighbor 3ffe:1ced:ff02::2 prefix-list AS-ARNEILLPY in > neighbor 3ffe:1ced:ff02::2 route-map AS-ARNEILLPY in > The prefix-list is useless as the route-map uses it IMHO. > Michel, actually, if you look at our config for your peering session, the prefix-list actually does do something. Since I use a "canned" route-map for all peers, I have to use the neighbor 3ffe:1ced:ff02::2 prefix-list AS-ARNEILLPY in on your peering session. Notice in the route-map below, it would accept ANY prefix from you and redistribute it as long as it passed prefix-list subTLA-only. route-map AS-ARNEILLPY permit 10 match ipv6 address prefix-list subTLA-only ! route-map AS-ARNEILLPY permit 20 match ipv6 address prefix-list AS-ARNEILLPY set community no-export additive Since I'm prefix-list filtering you in the neighbor statement, we will only allow prefixes from you that pass prefix-list AS-ARNEILLPY to pass on to the route-map. Once there, the match in stanza 20 sets the no-export (in your case.) This is simply to prevent you from accidently leaking transit routes to me. For peers that we do transit:transit peering with, they don't have a "prefix-list [peername] in" filter and the prefix-list [peername] is simply used to allow "more specifics" that won't pass the subTLA-only filter. Those more specifics are tagged no-export then. Do you see the reasoning now? This way, every "transit:transit" peer is configured the same and every "customer:customer" peer is configured the same way. The route-map is the same for every peer, period. It makes life more simple. > > router bgp 13944 > neighbor 3ffe:1ced:ff02::2 remote-as 23169 > neighbor 3ffe:1ced:ff02::2 description ARNEILLPY > no neighbor 3ffe:1ced:ff02::2 activate > ! > address-family ipv6 > neighbor 3ffe:1ced:ff02::2 activate > neighbor 3ffe:1ced:ff02::2 next-hop-self > neighbor 3ffe:1ced:ff02::2 route-map AS-ARNEILLPY-IN in > neighbor 3ffe:1ced:ff02::2 route-map AS-ARNEILLPY-OUT out > exit-address-family > ! > ipv6 prefix-list AS-ARNEILLPY seq 5 permit 3ffe:1ced:a002::/48 > ! > ipv6 prefix-list MYPREFIX seq 5 permit 3ffe:1ced::/32 > ! > ipv6 prefix-list STRICT seq 5 permit 3ffe::/18 ge 24 le 24 > ipv6 prefix-list STRICT seq 10 permit 3ffe:4000::/18 ge 32 le 32 > ipv6 prefix-list STRICT seq 15 permit 3ffe:8000::/20 ge 28 le 28 > ipv6 prefix-list STRICT seq 20 permit 2001::/16 ge 29 le 35 > ipv6 prefix-list STRICT seq 500 deny any > ! > ipv6 prefix-list SIXTOFOUR seq 5 permit 2002::/16 > ! > route-map AS-ARNEILLPY-IN deny 10 > description deny the peer feeding me my own prefix > match ipv6 address prefix-list MYPREFIX > ! > route-map AS-ARNEILLPY-IN permit 20 > description generic filter > match ipv6 address prefix-list STRICT > ! > route-map AS-ARNEILLPY-IN permit 30 > description accept other prefixes, don't redistribute > match ipv6 address prefix-list AS-ARNEILLPY > set community no-export additive > ! > ! > route-map AS-ARNEILLPY-OUT permit 10 > description generic filter > match ipv6 address prefix-list STRICT > ! > route-map AS-ARNEILLPY-OUT permit 20 > description feed _my_ 6to4 route only to the peer > match ipv6 address prefix-list SIXTOFOUR > match ** whatever condition that says the 6to4 route is yours ** > set community no-export additive > ! > > > Michel. That works fine except that it doesn't prevent you from accidently leaking transit to us. We'd gladly accept any route you sent us that passed prefix-list STRICT. The one thing I noticed is the deny stanza, something that I forgot in mine. I don't know how. I always do that on our v4 stuff. I'll have to modify the route-maps to add that. Thanks for reminding me! --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From tvo@EnterZone.Net Fri Aug 2 18:50:20 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Fri, 2 Aug 2002 13:50:20 -0400 (EDT) Subject: [6bone] Instability incarnate In-Reply-To: Message-ID: On Thu, 1 Aug 2002, Rik van Riel wrote: > [enterzone snipped from cc list, it's refusing my mail anyway] > Enterzone isn't the only place blocking your email. It's nothing personal. Our bounce message explains exactly why your mail was blocked and directs you to the spam blacklist site in question. > > The tunnel you're complaining about was requested by your > side of the tunnel, not by mine. Um, I didn't request a tunnel between two points on your side of the world. > > You're also blocking my email, which makes it kind of > hard to exchange information on problems. > You mail is being blocked because your mailserver is listed in several spamsource lists. See the bounce messages regarding this. We don't do spam and don't accept mail from sites that do, period. --- 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 Fri Aug 2 20:33:21 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Fri, 2 Aug 2002 16:33:21 -0300 (BRT) Subject: [6bone] Instability incarnate In-Reply-To: Message-ID: On Fri, 2 Aug 2002, John Fraizer wrote: > On Thu, 1 Aug 2002, Rik van Riel wrote: > > You're also blocking my email, which makes it kind of > > hard to exchange information on problems. > > You mail is being blocked because your mailserver is listed in several > spamsource lists. See the bounce messages regarding this. We don't do > spam and don't accept mail from sites that do, period. One list according to http://openrbl.org/ and one more list which you are apparently using. Unfortunately that list doesn't seem to state its listing policies online, nor evidence of the message that caused my ISP's server to be listed. Note that I'm not against blacklisting, I'm even running one (dsbl.org) ... regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From pekkas@netcore.fi Fri Aug 2 22:05:10 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Sat, 3 Aug 2002 00:05:10 +0300 (EEST) Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <2B81403386729140A3A899A8B39B046405E23F@server2000.arneill-py.sacramento.ca.us> Message-ID: On Fri, 2 Aug 2002, Michel Py wrote: > > Why is this a desireable goal? > > Because by announcing 2002::/16 on the 6bone, we create another form of > anycast. Not only there already is an anycast mechanism, it is very > seldom used. I do not see any reason to re-create another one. > > Let's make seq 30 optional. By that you'd implicitly require that every pTLA who wants to communicate with 6to4 nodes must also have a 6to4 relay. That's definitely not something that can be required. -- 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 pekkas@netcore.fi Fri Aug 2 22:10:15 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Sat, 3 Aug 2002 00:10:15 +0300 (EEST) Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <20020802094010.L27015@Space.Net> Message-ID: On Fri, 2 Aug 2002, Gert Doering wrote: > > http://search.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-0 > > 4.txt > > Done. > > I don't agree with many of the conclusions - why would it be "the best" > solution to assign /64s to ptp links? There is nothing "good" about /64s. The "good" about /64's is that this is what protocol's address architecture requires. That's something that future extensions (e.g. address based keying for IPSEC) may require. Therefore it should be the first recommendation. > If /127s are not used, what is the benefit of a /112? Who needs 64k > addresses on a ptp link? To cope with the fact that 128 values have been reserved for anycast (see RFC2526), we'd "need" at least /120. /112 is on the hex boundary so the numbers after the last ":" are always the nodes. There is enough space in a /64 to do enough /112's. It just seems best, if you don't want to use e.g. /126 or /64. > The general issue of anycast addresses on ptp links doesn't sound very > useful either, but this seems to be an unavoidable issue - so thanks > for pointing it out, we'll consider moving to /126s. Once it gets implemented (and especially if it's automatically enabled), it could very hairy.. -- 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 Sat Aug 3 04:48:57 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 2 Aug 2002 20:48:57 -0700 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? Message-ID: <2B81403386729140A3A899A8B39B046405E242@server2000.arneill-py.sacramento.ca.us> >> Michel Py wrote: >> Because by announcing 2002::/16 on the 6bone, we create another form of >> anycast. Not only there already is an anycast mechanism, it is very >> seldom used. I do not see any reason to re-create another one. >> Let's make seq 30 optional. > Pekka Savola wrote: > By that you'd implicitly require that every pTLA who wants > to communicate with 6to4 nodes must also have a 6to4 relay. I think that a good thing. There are no pTLAs that have no v4 connectivity, are there? I would go even further than this: why should we see 6to4 traffic crossing tunnels half of the world, finally reach an anycast 6to4 relay somewhere and travel another distance to reach their v4 target? I think each site that has ipv4 connectivity should have their own 6to4 relay. It would be much better to have a 6to4 relay close to the source. I was hoping that by making the 2002::/16 route optional, it would force people to have their own 6to4 relay. It does not take much: interface Tunnel6 description for ipv6 6to4 tunnels no ip address no ip redirects ipv6 address 2002:D1E9:7E41::1/64 ipv6 traffic-filter IPV6-ACL-OUTSIDE-IN in tunnel source BVI35 tunnel mode ipv6ip 6to4 tunnel path-mtu-discovery ! ipv6 route 2002::/16 Tunnel6 Michel. From tvo@EnterZone.Net Sat Aug 3 07:04:07 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Sat, 3 Aug 2002 02:04:07 -0400 (EDT) Subject: [6bone] no-export community not being honored Message-ID: People not honoring "no-export" when redistributing routes: 109 announces 2002::/16 tagged with the "no-export" well-known community. 109 3ffe:c00:8023:4::1 from 3ffe:c00:8023:4::1 (128.107.240.254) (fe80::806b:f0fe) Origin IGP, metric 0, localpref 100, valid, external, best Community: no-export Last update: Fri Aug 2 23:13:51 2002 The problem is, it appears that many people wipe this out, probably with "set community none" or "set community nnnn:nnnn" without the "additive" modifier. Here are a few examples of folks redistributing 109's "no-export" tagged route: 6175 109 3ffe:2900:d:e::1 from 3ffe:2900:d:e::1 (208.19.223.30) (fe80::d013:df1e) Origin IGP, metric 0, localpref 100, valid, external Last update: Sat Aug 3 00:10:51 2002 6342 109 (history entry) 2001:750:E::5 from 2001:750:E::5 (200.33.111.6) Origin IGP, localpref 100, external Dampinfo: penalty 10785, flapped 459 times in 15:32:04 33 109 3FFE:1200:1002:1::81 from 3FFE:1200:1002:1::81 (204.123.18.254) Origin IGP, localpref 100, valid, external I know... Someone is going to say "This is the 6bone. We're experimenting. We're learning." OK. Here is a lesson: When you receive a prefix that has no-export tagged, you don't export it. If you're running a route-map that clears communities, it might be a good idea to NOT clear the (local-AS|no-advertise|no-export) community. It's being set by the origin AS for a reason. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From nhua@biigroup.com Sat Aug 3 07:09:24 2002 From: nhua@biigroup.com (Hua Ning) Date: Sat, 3 Aug 2002 14:09:24 +0800 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? References: Message-ID: <017401c23ab4$539eb730$6ef696d3@huaning> > ipv6 prefix-list test1 seq 15 permit 3ffe:8000::/20 ge 28 le 28 >From http://www.6bone.net/6bone_pTLA_list.html 28 Bit pTLA Assignments: [3FFE:8000::/24 thru 3FFE:83F0::/24] then , I presume that it should be " ipv6 prefix-list test1 seq 15 permit 3ffe:8000::/22 ge 28 le 28". Hua Ning From bmanning@ISI.EDU Sat Aug 3 14:00:38 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Sat, 3 Aug 2002 06:00:38 -0700 (PDT) Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <2B81403386729140A3A899A8B39B046405E242@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Aug 2, 2 08:48:57 pm" Message-ID: <200208031300.g73D0cQ17902@boreas.isi.edu> % I think each site that has ipv4 connectivity should have their own 6to4 % relay. It would be much better to have a 6to4 relay close to the source. % I was hoping that by making the 2002::/16 route optional, it would force % people to have their own 6to4 relay. It does not take much: Glad you have these thoughts. I don;t think the same way. Please provide technical justification for trying to impose your operational world view on others. IMHO, 6to4 is an egregious hack that delays v6 migration. If folks want v6, they should use v6, not be deluded into thinking they still have v4. -- --bill From jean-marie@technologist.com Sat Aug 3 16:40:33 2002 From: jean-marie@technologist.com (Hugues Jean-Marie) Date: Sat, 03 Aug 2002 10:40:33 -0500 Subject: [6bone] remov Message-ID: <20020803154033.23355.qmail@iname.com> -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Get 4 DVDs for $.49 cents! plus shipping & processing. Click to join. http://adfarm.mediaplex.com/ad/ck/990-1736-3566-59 From nicolas.deffayet@ndsoftware.net Sat Aug 3 17:20:12 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 03 Aug 2002 18:20:12 +0200 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <017401c23ab4$539eb730$6ef696d3@huaning> References: <017401c23ab4$539eb730$6ef696d3@huaning> Message-ID: <1028391612.15372.132.camel@wks1-1.corp.ndsoftware.com> On Sat, 2002-08-03 at 08:09, Hua Ning wrote: > > > > ipv6 prefix-list test1 seq 15 permit 3ffe:8000::/20 ge 28 le 28 > > >From http://www.6bone.net/6bone_pTLA_list.html > 28 Bit pTLA Assignments: [3FFE:8000::/24 thru 3FFE:83F0::/24] > > then , > I presume that it should be " ipv6 prefix-list test1 seq 15 permit > 3ffe:8000::/22 ge 28 le 28". Yes. ipv6 prefix-list ipv6-ebgp-full-in permit 3ffe::/18 ge 24 le 24 ipv6 prefix-list ipv6-ebgp-full-in permit 3ffe:4000::/18 ge 32 le 32 ipv6 prefix-list ipv6-ebgp-full-in permit 3ffe:8000::/22 ge 28 le 28 ipv6 prefix-list ipv6-ebgp-full-in permit 2001::/16 ge 29 le 35 ipv6 prefix-list ipv6-ebgp-full-in permit 2002::/16 ipv6 prefix-list ipv6-ebgp-full-in deny 0::/0 You can deny your prefix too. From gert@space.net Mon Aug 5 22:19:06 2002 From: gert@space.net (Gert Doering) Date: Mon, 5 Aug 2002 23:19:06 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: ; from ahltorp@nada.kth.se on Mon, Aug 05, 2002 at 09:05:39PM +0200 References: <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.ca.us> <20020802150214.W27015@Space.Net> <20020802132456.GI5356@Burk.hax.SE> <20020802162845.B27015@Space.Net> Message-ID: <20020805231906.H27015@Space.Net> Hi, On Mon, Aug 05, 2002 at 09:05:39PM +0200, Magnus Ahltorp wrote: > > So? For those media types you need other rules anyway. No need to uglify > > things for the most common multiaccess network type. > > > > A decent approach could have been "put control stuff in the first 16 bits, > > map the MAC address 1:1 to the next 48 bits". > > EUI-64 happens to be an IEEE standard, and not something that the > ipngwg has invented. The existance of non-useful standards in other areas doesn't mean one has to use them for everything else needing 64-bit identifiers. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46631 (46284) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert@space.net Tue Aug 6 08:14:34 2002 From: gert@space.net (Gert Doering) Date: Tue, 6 Aug 2002 09:14:34 +0200 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: ; from ahltorp@nada.kth.se on Tue, Aug 06, 2002 at 01:42:49AM +0200 References: <2B81403386729140A3A899A8B39B046405E235@server2000.arneill-py.sacramento.ca.us> <20020802150214.W27015@Space.Net> <20020802132456.GI5356@Burk.hax.SE> <20020802162845.B27015@Space.Net> <20020805231906.H27015@Space.Net> Message-ID: <20020806091434.M27015@Space.Net> Hi, On Tue, Aug 06, 2002 at 01:42:49AM +0200, Magnus Ahltorp wrote: > > > EUI-64 happens to be an IEEE standard, and not something that the > > > ipngwg has invented. > > > > The existance of non-useful standards in other areas doesn't mean one > > has to use them for everything else needing 64-bit identifiers. > > When going from EUI-48 to something that is 64-bit, isn't it natural > to use the 64-bit variant, i.e. the EUI-64? I don't see how that is an > arbitrary decision. Well - using EUI-48 was arbitrary as well, and experimental to that. So when redesigning the whole addressing architecture anyway, I can't see any need to stay in a family of addressing standards if the "new" one isn't useful. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46631 (46284) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From kre@munnari.OZ.AU Tue Aug 6 15:11:54 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Tue, 06 Aug 2002 21:11:54 +0700 Subject: [6bone] semi-newbie Q on IPv6 address planning In-Reply-To: <20020802094010.L27015@Space.Net> References: <20020802094010.L27015@Space.Net> <2B81403386729140A3A899A8B39B046406C9FC@server2000.arneill-py.sacramento.ca.us> Message-ID: <26669.1028643114@munnari.OZ.AU> Date: Fri, 2 Aug 2002 09:40:10 +0200 From: Gert Doering Message-ID: <20020802094010.L27015@Space.Net> | If /127s are not used, what is the benefit of a /112? Who needs 64k | addresses on a ptp link? No-one, but when written textually, /112 starts looking attractive to use, and the other 48 bite between /64 and /112 are plenty for any site to use to number its different p2p's. The "we need 128 anycast addresses" argument that Pekka made isn't really very important for this, on a p2p we don't actually need any. But /112 is nice to use anyway, and if it keeps people believing that those anycast addresses are there available, just in case they're needed, then fine... | EUI-64 sucks big time (using MAC addresses and such is a nice idea, | but why on earth can't they map 48 bits to 64 in a somewhat more | straightforward way than "distribute them over all the 64bits"?) As someone else pointed out, it is the way that IEEE defined the mapping for ease of allocation purposes. I have the impression that we actually had it right when it was first proposed, when FFFF was inserted instead of FFFE, when I read the IEEE stuff about this, but it is way too late to worry about that now. | The existance of non-useful standards in other areas doesn't mean one | has to use them for everything else needing 64-bit identifiers. No, in geneneral, you're right. However, here the risk is, as these are all IEEE assigned numbers, that some new net technology using 64 bit addresses will be developed, and then some manufacturer will build an ethernet to X bridge/switch, which converts the addresses on the fly according to the IEEE rules. Things would break big time if we'd invented some other way of doing the same conversion in that scenario. So, as it is all just bits, and the mapping doesn't actually matter (we most certainly don't want "control information" in the middle of addresses), there's nothing to be lost by doing it the IEEE way (for which there are good reasons in their world) other than the cost of explaining the reasons over and over again. kre From fink@es.net Wed Aug 7 15:05:18 2002 From: fink@es.net (Bob Fink) Date: Wed, 07 Aug 2002 07:05:18 -0700 Subject: [6bone] 6bone pTLA 3FFE:4010::/32 allocated to ENTERZONE Message-ID: <5.1.0.14.0.20020807070400.02325c90@imap2.es.net> ENTERZONE has been allocated pTLA 3FFE:4010::/32 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to hostmaster@ep.net.] Thanks, Bob From fink@es.net Wed Aug 7 15:02:02 2002 From: fink@es.net (Bob Fink) Date: Wed, 07 Aug 2002 07:02:02 -0700 Subject: [6bone] 6bone pTLA 3FFE:400F::/32 allocated to UACH Message-ID: <5.1.0.14.0.20020807070044.01f9ac58@imap2.es.net> UACH has been allocated pTLA 3FFE:400F::/32 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to hostmaster@ep.net.] Thanks, Bob From fink@es.net Wed Aug 7 15:40:07 2002 From: fink@es.net (Bob Fink) Date: Wed, 07 Aug 2002 07:40:07 -0700 Subject: [6bone] pTLA for Teredo testing Message-ID: <5.1.0.14.0.20020807070757.0232d1c8@imap2.es.net> 6bone Folk, Trying to gauge consensus on allocating a pTLA to Teredo has been difficult. There has been little support for it from the 6bone list, and none against it, while most remain silent (unfortunately all too typical). On the other hand, IESG comments have come from three members (Thomas, Randy and Allison) that during the IESG review of Teredo at the end of 2001, it was determined that there were security concerns, and that they think experimental deployment would be inadvisable until the newest Teredo specification has been released and given a careful review by the IESG. Given that the IESG is the senior technical review body of the IETF, I feel that I have no prudent choice other than to go along with its wishes and not allocate a pTLA for Teredo experimental deployment. I try to be neutral in the pTLA review oversight role and simply try to understand if there is a consensus. In this case, there was not much comment one way or another, except for the IESG comments. I hope that after the new Teredo draft (soon to be published by Christian) has been reviewed by the IESG, and is found to no longer raise serious technical concerns, that we can reconsider another request for a pTLA. Thanks, Bob From michel@arneill-py.sacramento.ca.us Wed Aug 7 22:16:28 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 7 Aug 2002 14:16:28 -0700 Subject: [6bone] 6bone pTLA 3FFE:4010::/32 allocated to ENTERZONE Message-ID: <2B81403386729140A3A899A8B39B046406CA19@server2000.arneill-py.sacramento.ca.us> John, Are you going to keep your sTLA from Merit or transfer everyone to your new pTLA? Michel. From tvo@EnterZone.Net Wed Aug 7 22:33:29 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 7 Aug 2002 17:33:29 -0400 (EDT) Subject: [6bone] 6bone pTLA 3FFE:4010::/32 allocated to ENTERZONE Message-ID: On Wed, 7 Aug 2002, Michel Py wrote: > John, > > Are you going to keep your sTLA from Merit or transfer everyone to your > new pTLA? > > Michel. I was unaware that merit was in the sTLA business. I thought that only RIRs did that. If you're talking about 3ffe:1ced::/32, I haven't decided. If you would like to move into 3ffe:4010::/32, I will gladly do that. I will be moving all tunnel addresses into the pTLA. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From nicolas.deffayet@ndsoftware.net Wed Aug 7 23:43:16 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 08 Aug 2002 00:43:16 +0200 Subject: [6bone] Build a tunnel with modem/router that filter IP protocol 41 Message-ID: <1028760196.15383.785.camel@wks1-1.corp.ndsoftware.com> Hello, A lot of stupid modem/router filter all traffic that aren't ICMP, TCP, UDP or GRE. I will take for example the Eicon ADSL modem because i know 2 peoples who have this modem and try to have a IPv6 over IPv4 tunnel with it. This modem work like this: ISP <-ADSL-> MODEM <-LAN-> COMPUTER Public IPv4 address is on the modem and all ports are forwarded and NAT enabled to the computer. You can read on the eicon website (http://www.eicon.com/support/helpweb/adsl/vpn.asp): "The NAT Router built-in to the 24xx series allows only TCP, UDP, GRE, and ICMP protocols through. Any other protocols are silently dropped for security reasons." I did many tests with this 2 peoples and this modem filter the IP protocol 41 and the IPv6 over IPv4 tunnel don't work. I wait a reply of Eicon for this. => What's the possibility for build a IPv6 over IPv4 with this modem/router ? I wait your comments about that. Best Regards, Nicolas DEFFAYET From nicolas.deffayet@ndsoftware.net Wed Aug 7 23:55:34 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 08 Aug 2002 00:55:34 +0200 Subject: [6bone] IPv6 route server Message-ID: <1028760934.15548.799.camel@wks1-1.corp.ndsoftware.com> Hello, I opened a public IPv6 route server. You can try it: telnet route-server.ndsoftwarenet.net (IPv6 only) Anyone know another IPv6 route server ? I can do a how-to if someone want setup a route server with zebra. Best Regards, Nicolas DEFFAYET From tvo@EnterZone.Net Thu Aug 8 00:54:34 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 7 Aug 2002 19:54:34 -0400 (EDT) Subject: [6bone] IPv6 route server In-Reply-To: <1028760934.15548.799.camel@wks1-1.corp.ndsoftware.com> Message-ID: Nicolas, This would be slick if it acted like a route-server. It only shows your selected best path from your border router(s) though. route-server.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 BGP routing table entry for 2001:4f0::/35 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 13944 3ffe:81f1:0:2::1 from 3ffe:81f1:0:2::1 (62.4.18.114) (fe80::260:97ff:fe0c:9803) Origin IGP, metric 800, localpref 100, valid, internal, best Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 01:43:08 2002 I really appreciate your taking the time to modify the zebra code and would like to see a patch against the latest CVS posted to the Zebra list. I know that you peer with multiple other people that you should be seeing alternate paths to the above route via but, the route-server doesn't know about them. If you want to see what I mean about the typical route-server showing multiple paths, telnet to route-views.oregon-ix.net and look up the ipv4 prefix of your choice. I don't know of anyone else running a telnet accessable route-server for v6 but, there are several people running my MRLG code with public access. You can see an example at http://nitrous.ipv6.enterzone.net/ --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On 8 Aug 2002, Nicolas DEFFAYET wrote: > Hello, > > I opened a public IPv6 route server. > > You can try it: > > telnet route-server.ndsoftwarenet.net (IPv6 only) > > Anyone know another IPv6 route server ? > I can do a how-to if someone want setup a route server with zebra. > > Best Regards, > > Nicolas DEFFAYET > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From tvo@EnterZone.Net Thu Aug 8 01:27:35 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 7 Aug 2002 20:27:35 -0400 (EDT) Subject: [6bone] IPv6 route server In-Reply-To: Message-ID: On Wed, 7 Aug 2002, John Fraizer wrote: > You can see an example at http://nitrous.ipv6.enterzone.net/ I almost forgot, it's accessable via v4 and v6. Something that I feel is important for a diagnostic tool. If someone feels the need to look at our view of the v6 planet, it may very well be because they are having v6 connectivity issues. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From Daniel Austin" Message-ID: <011001c23e73$b213d300$611c08d9@kewlio.net> This is a multi-part message in MIME format. ------=_NextPart_000_010C_01C23E7C.13951780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I also have http://www.ipv6.kewlio.net/ a small collection of V6 tools including a copy of John's LG and a peering matrix. (reachable by v4/v6) With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. ----- Original Message ----- From: "John Fraizer" To: "Nicolas DEFFAYET" Cc: <6bone@mailman.isi.edu> Sent: Thursday, August 08, 2002 1:27 AM Subject: Re: [6bone] IPv6 route server > > > > On Wed, 7 Aug 2002, John Fraizer wrote: > > > You can see an example at http://nitrous.ipv6.enterzone.net/ > > I almost forgot, it's accessable via v4 and v6. Something that I feel is > important for a diagnostic tool. If someone feels the need to look at our > view of the v6 planet, it may very well be because they are having v6 > connectivity issues. > > --- > 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 > ------=_NextPart_000_010C_01C23E7C.13951780 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIYzCCAnow ggHjoAMCAQICARcwDQYJKoZIhvcNAQEFBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTAyMDQxODE1MjkzN1oXDTIwMDQxMzE1MjkzN1owTjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdl b1RydXN0IEluYy4xJzAlBgNVBAMTHkdlb1RydXN0IFRydWUgQ3JlZGVudGlhbHMgQ0EgMjCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAspcspZISpYX/aJqWoYcSyyGqFby3OvsepRzLRU0ENDJR wJo7DwFpirRFOUQkTkKXsY6BQzX/CeCRrn9i4ny5gcXuI2JSyrSmDwobbwl52n5cPEbHGcebybWd KfAf8vvkxYUnTmDZPtt2ob5RNpJTeTiq9MpNCB/5G7Ocr1hEljcCAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgHGMB0GA1UdDgQWBBQig0tNIAIMMfR8WrAaTRXIeF0RSTAPBgNVHRMBAf8EBTADAQH/MB8G A1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA0GCSqGSIb3DQEBBQUAA4GBACmw3z+sLsLS fAfdECQJPfiZFzJzSPQKLwY7vHnNWH2lAKYECbtAFHBpdyhSPkrj3KghXeIJnKyMFjsK6xd1k1Yu wMXrauUH+HIDuZUg4okBwQbhBTqjjEdo/cCHILQsaLeU2kM+n5KKrpb0uvrHrocGffRMrWhz9zYB lxoq0/EEMIICgjCCAeugAwIBAgIBBDANBgkqhkiG9w0BAQQFADBTMQswCQYDVQQGEwJVUzEcMBoG A1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1c2lu ZXNzIENBLTEwHhcNOTkwNjIxMDQwMDAwWhcNMjAwNjIxMDQwMDAwWjBTMQswCQYDVQQGEwJVUzEc MBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1 c2luZXNzIENBLTEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM4vGbwXt3fek6lfWg0XTzQa DJj0ItlZ1MRoRvC0NcWFAyDGr0WlIVFFQesWWDYyb+JQYmT5/VGcqiTZ9J2DKocKIdMSODRsjQBu WqDZQu4aIZX5UkxVWsUPOE9G+m34LjXWHXzr4vCwdYDIqROsvojvOm6rXyo4YgKwEnv+j6YDAgMB AAGjZjBkMBEGCWCGSAGG+EIBAQQEAwIABzAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFEp4 MlIR21kWNl7fwRQ2QGpHfEyhMB0GA1UdDgQWBBRKeDJSEdtZFjZe38EUNkBqR3xMoTANBgkqhkiG 9w0BAQQFAAOBgQB1W6ibAxHm6VZMzfmpTMANmvPMZWnmJXbMWbfWVMMdzZmsGd20hdXgPfxiIKeE S1hl8eL5lSE/9dR+WB5Hh1Q+WKG1tfgq73HnvMP2sUlG4tega+VWeponmHxGYhTnyfxuAxJ5gDgd SIKN/Bf+KpYrtWKmpj29f5JZzVoqgrI3eTCCA1swggLEoAMCAQICAxAAazANBgkqhkiG9w0BAQQF ADBOMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1 c3QgVHJ1ZSBDcmVkZW50aWFscyBDQSAyMB4XDTAyMDgwMTE4MjYzOVoXDTAzMDgxNTE4MjYzOVow ggERMT8wPQYDVQQLEzZDUFMgdGVybXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZSBsaWFiaWxp dHkgbGltaXRlZC4xPjA8BgNVBAsTNVNlZSBQdWJsaWMgUy9NSU1FIENQUyB3d3cuZ2VvdHJ1c3Qu Y29tL3Jlc291cmNlcy9DUFMuMSowKAYDVQQLEyFQaG9uZSBWYWxpZGF0aW9uIC0gNDQgNzk3MC02 MzMzMzMxKDAmBgNVBAsTH0VtYWlsIGFuZCBwaG9uZSB2YWxpZGF0ZWQgb25seS4xFjAUBgNVBAMT DURhbmllbCBBdXN0aW4xIDAeBgkqhkiG9w0BCQEWEWRhbmllbEBrZXdsaW8ubmV0MIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCnZ7IrV88D55wCg31dENNY6z1/ehvUcOxWC4sh5hJMgMXNefiR mXQiDD6iRESdk5UJ5usgZZr40ICYwlpjBUY6xBTe4LNLiC1UPVZ9uF3Z05CVgvgXEhvqC3p8WM3O sKYfGXL7k49xmBU9TvpkExdxSEYJoK4rK77qRFC5HuKcMwIDAQABo4GBMH8wEQYJYIZIAYb4QgEB BAQDAgWgMA4GA1UdDwEB/wQEAwIF4DA5BgNVHR8EMjAwMC6gLKAqhihodHRwOi8vY3JsLmdlb3Ry dXN0LmNvbS9jcmxzL2d0dGNjYTIuY3JsMB8GA1UdIwQYMBaAFCKDS00gAgwx9HxasBpNFch4XRFJ MA0GCSqGSIb3DQEBBAUAA4GBABslhvo5nWHvXY0xcGwSdigKcnAIgRiH8zlmbKYyWCf0+qwjEVbc 7wccsKNWNr3D007R66JZtCiktuuc6CBsuxBzsBVS4uEA8YUXM3XNJM4mgTFdUfG+SOQaN30E4xtF vgGqDTSea6Q0tz2TbA8Xb+YUhEO3tbU8ulXdWLX7TI4YMYIBuDCCAbQCAQEwVTBOMQswCQYDVQQG EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1c3QgVHJ1ZSBDcmVk ZW50aWFscyBDQSAyAgMQAGswCQYFKw4DAhoFAKCBujAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wMjA4MDgwMDM2NTRaMCMGCSqGSIb3DQEJBDEWBBQj0SrQIPaWfbnQ kBZiHiVNmQzIFjBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCHTANBgkqhkiG9w0B AQEFAASBgGeDiYTSCvTu1auUuDFFDPb5MTjch8Rb6zj/st7fiEp0HMeyvwLtoy/igpK+vQysQ4FF gWN3D+r7hyBjekOz1/LXKqN9cAGdh5SN3VU6uJtLatH7zBVNHdWvII2Xq383KRMslR99Hwxd5AvB ZIpWdY6rlsHynPdMXvqJuvp5W7wQAAAAAAAA ------=_NextPart_000_010C_01C23E7C.13951780-- From Daniel Austin" Message-ID: <012001c23e74$2d33e7a0$611c08d9@kewlio.net> This is a multi-part message in MIME format. ------=_NextPart_000_011C_01C23E7C.8EAD8B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi John, I think there's mixed feelings about route servers... BBNplanet's also only shows best paths - ner-routes.bbnplanet.net (v4 only) I guess each has its advantages. Personally, i prefer one that shows all routes as i have multiple providers and i quite frequently like to check that both of them are advertising my ip ranges ;-) I've found a couple of times that 1 of my providers have stopped advertising my prefixes onto major IX's which i wouldnt be able to see from, for example, BBNplanet's route server. With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. ----- Original Message ----- From: "John Fraizer" To: "Nicolas DEFFAYET" Cc: <6bone@mailman.isi.edu> Sent: Thursday, August 08, 2002 12:54 AM Subject: Re: [6bone] IPv6 route server > > Nicolas, > > This would be slick if it acted like a route-server. It only shows your > selected best path from your border router(s) though. > > route-server.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 > BGP routing table entry for 2001:4f0::/35 > Paths: (1 available, best #1, table Default-IP-Routing-Table) > Not advertised to any peer > 13944 > 3ffe:81f1:0:2::1 from 3ffe:81f1:0:2::1 (62.4.18.114) > (fe80::260:97ff:fe0c:9803) > Origin IGP, metric 800, localpref 100, valid, internal, best > Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 > Last update: Thu Aug 8 01:43:08 2002 > > I really appreciate your taking the time to modify the zebra code and > would like to see a patch against the latest CVS posted to the Zebra > list. > > I know that you peer with multiple other people that you should be seeing > alternate paths to the above route via but, the route-server doesn't know > about them. > > If you want to see what I mean about the typical route-server showing > multiple paths, telnet to route-views.oregon-ix.net and look up the ipv4 > prefix of your choice. > > I don't know of anyone else running a telnet accessable route-server for > v6 but, there are several people running my MRLG code with public access. > > You can see an example at http://nitrous.ipv6.enterzone.net/ > > > --- > John Fraizer | High-Security Datacenter Services | > EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | > http://www.enterzone.net/ | Virtual, Dedicated, Colocation | > > > On 8 Aug 2002, Nicolas DEFFAYET wrote: > > > Hello, > > > > I opened a public IPv6 route server. > > > > You can try it: > > > > telnet route-server.ndsoftwarenet.net (IPv6 only) > > > > Anyone know another IPv6 route server ? > > I can do a how-to if someone want setup a route server with zebra. > > > > Best Regards, > > > > Nicolas DEFFAYET > > > > > > _______________________________________________ > > 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 > ------=_NextPart_000_011C_01C23E7C.8EAD8B00 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIYzCCAnow ggHjoAMCAQICARcwDQYJKoZIhvcNAQEFBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTAyMDQxODE1MjkzN1oXDTIwMDQxMzE1MjkzN1owTjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdl b1RydXN0IEluYy4xJzAlBgNVBAMTHkdlb1RydXN0IFRydWUgQ3JlZGVudGlhbHMgQ0EgMjCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAspcspZISpYX/aJqWoYcSyyGqFby3OvsepRzLRU0ENDJR wJo7DwFpirRFOUQkTkKXsY6BQzX/CeCRrn9i4ny5gcXuI2JSyrSmDwobbwl52n5cPEbHGcebybWd KfAf8vvkxYUnTmDZPtt2ob5RNpJTeTiq9MpNCB/5G7Ocr1hEljcCAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgHGMB0GA1UdDgQWBBQig0tNIAIMMfR8WrAaTRXIeF0RSTAPBgNVHRMBAf8EBTADAQH/MB8G A1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA0GCSqGSIb3DQEBBQUAA4GBACmw3z+sLsLS fAfdECQJPfiZFzJzSPQKLwY7vHnNWH2lAKYECbtAFHBpdyhSPkrj3KghXeIJnKyMFjsK6xd1k1Yu wMXrauUH+HIDuZUg4okBwQbhBTqjjEdo/cCHILQsaLeU2kM+n5KKrpb0uvrHrocGffRMrWhz9zYB lxoq0/EEMIICgjCCAeugAwIBAgIBBDANBgkqhkiG9w0BAQQFADBTMQswCQYDVQQGEwJVUzEcMBoG A1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1c2lu ZXNzIENBLTEwHhcNOTkwNjIxMDQwMDAwWhcNMjAwNjIxMDQwMDAwWjBTMQswCQYDVQQGEwJVUzEc MBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1 c2luZXNzIENBLTEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM4vGbwXt3fek6lfWg0XTzQa DJj0ItlZ1MRoRvC0NcWFAyDGr0WlIVFFQesWWDYyb+JQYmT5/VGcqiTZ9J2DKocKIdMSODRsjQBu WqDZQu4aIZX5UkxVWsUPOE9G+m34LjXWHXzr4vCwdYDIqROsvojvOm6rXyo4YgKwEnv+j6YDAgMB AAGjZjBkMBEGCWCGSAGG+EIBAQQEAwIABzAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFEp4 MlIR21kWNl7fwRQ2QGpHfEyhMB0GA1UdDgQWBBRKeDJSEdtZFjZe38EUNkBqR3xMoTANBgkqhkiG 9w0BAQQFAAOBgQB1W6ibAxHm6VZMzfmpTMANmvPMZWnmJXbMWbfWVMMdzZmsGd20hdXgPfxiIKeE S1hl8eL5lSE/9dR+WB5Hh1Q+WKG1tfgq73HnvMP2sUlG4tega+VWeponmHxGYhTnyfxuAxJ5gDgd SIKN/Bf+KpYrtWKmpj29f5JZzVoqgrI3eTCCA1swggLEoAMCAQICAxAAazANBgkqhkiG9w0BAQQF ADBOMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1 c3QgVHJ1ZSBDcmVkZW50aWFscyBDQSAyMB4XDTAyMDgwMTE4MjYzOVoXDTAzMDgxNTE4MjYzOVow ggERMT8wPQYDVQQLEzZDUFMgdGVybXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZSBsaWFiaWxp dHkgbGltaXRlZC4xPjA8BgNVBAsTNVNlZSBQdWJsaWMgUy9NSU1FIENQUyB3d3cuZ2VvdHJ1c3Qu Y29tL3Jlc291cmNlcy9DUFMuMSowKAYDVQQLEyFQaG9uZSBWYWxpZGF0aW9uIC0gNDQgNzk3MC02 MzMzMzMxKDAmBgNVBAsTH0VtYWlsIGFuZCBwaG9uZSB2YWxpZGF0ZWQgb25seS4xFjAUBgNVBAMT DURhbmllbCBBdXN0aW4xIDAeBgkqhkiG9w0BCQEWEWRhbmllbEBrZXdsaW8ubmV0MIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCnZ7IrV88D55wCg31dENNY6z1/ehvUcOxWC4sh5hJMgMXNefiR mXQiDD6iRESdk5UJ5usgZZr40ICYwlpjBUY6xBTe4LNLiC1UPVZ9uF3Z05CVgvgXEhvqC3p8WM3O sKYfGXL7k49xmBU9TvpkExdxSEYJoK4rK77qRFC5HuKcMwIDAQABo4GBMH8wEQYJYIZIAYb4QgEB BAQDAgWgMA4GA1UdDwEB/wQEAwIF4DA5BgNVHR8EMjAwMC6gLKAqhihodHRwOi8vY3JsLmdlb3Ry dXN0LmNvbS9jcmxzL2d0dGNjYTIuY3JsMB8GA1UdIwQYMBaAFCKDS00gAgwx9HxasBpNFch4XRFJ MA0GCSqGSIb3DQEBBAUAA4GBABslhvo5nWHvXY0xcGwSdigKcnAIgRiH8zlmbKYyWCf0+qwjEVbc 7wccsKNWNr3D007R66JZtCiktuuc6CBsuxBzsBVS4uEA8YUXM3XNJM4mgTFdUfG+SOQaN30E4xtF vgGqDTSea6Q0tz2TbA8Xb+YUhEO3tbU8ulXdWLX7TI4YMYIBuDCCAbQCAQEwVTBOMQswCQYDVQQG EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1c3QgVHJ1ZSBDcmVk ZW50aWFscyBDQSAyAgMQAGswCQYFKw4DAhoFAKCBujAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wMjA4MDgwMDQwMjFaMCMGCSqGSIb3DQEJBDEWBBRoqm+ucozxLZiW 58uM6xU//cHIFjBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCHTANBgkqhkiG9w0B AQEFAASBgIAUuRq6tXzbGEQLZY896CM/8Jce4HFwi+6nFBJJv5oYi6MV1Re5cdk7GDU2TU2mOEsF umNdT2L2HQ7yvaCjpmVk5pVKzBsJ5sopqS8bzzsl/oUlJSqeP/00KSVGrrZrFPHTRkByUOL1Mnxh aA+10fwj9KmfiJC/FdKj/OsAQF5qAAAAAAAA ------=_NextPart_000_011C_01C23E7C.8EAD8B00-- From tvo@EnterZone.Net Thu Aug 8 02:06:30 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 7 Aug 2002 21:06:30 -0400 (EDT) Subject: [6bone] IPv6 route server In-Reply-To: <012001c23e74$2d33e7a0$611c08d9@kewlio.net> Message-ID: On Thu, 8 Aug 2002, Daniel Austin wrote: > Hi John, > > I think there's mixed feelings about route servers... > > BBNplanet's also only shows best paths - ner-routes.bbnplanet.net (v4 only) > > I guess each has its advantages. Personally, i prefer one that shows all > routes as i have multiple providers and i quite frequently like to check > that both of them are advertising my ip ranges ;-) > I've found a couple of times that 1 of my providers have stopped advertising > my prefixes onto major IX's which i wouldnt be able to see from, for > example, BBNplanet's route server. > I think it has to do with naming symantics. To me, "route-server" means, it shows all routes. "route-views" means it shows the view from within a particular network core. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From nicolas.deffayet@ndsoftware.net Thu Aug 8 02:06:58 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 08 Aug 2002 03:06:58 +0200 Subject: [6bone] IPv6 route server In-Reply-To: References: Message-ID: <1028768818.15379.832.camel@wks1-1.corp.ndsoftware.com> On Thu, 2002-08-08 at 01:54, John Fraizer wrote: John, > This would be slick if it acted like a route-server. It only shows your > selected best path from your border router(s) though. > > route-server.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 > BGP routing table entry for 2001:4f0::/35 > Paths: (1 available, best #1, table Default-IP-Routing-Table) > Not advertised to any peer > 13944 > 3ffe:81f1:0:2::1 from 3ffe:81f1:0:2::1 (62.4.18.114) > (fe80::260:97ff:fe0c:9803) > Origin IGP, metric 800, localpref 100, valid, internal, best > Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 > Last update: Thu Aug 8 01:43:08 2002 route-server.ndsoftwarenet.net> show ipv6 bgp 3ffe:300:: BGP routing table entry for 3ffe:300::/24 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 2602 2200 3ffe:81f1:0:2::1 from 3ffe:81f1:0:2::1 (62.4.18.114) (fe80::260:97ff:fe0c:9803) Origin IGP, metric 600, localpref 100, valid, internal, best Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 02:54:56 2002 513 2200 3ffe:81f1:0:1::1 from 3ffe:81f1:0:1::1 (213.91.4.3) Origin IGP, metric 600, localpref 100, valid, internal Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 02:54:22 2002 route-server.ndsoftwarenet.net> I don't understand why the 2nd router (62.4.18.114) don't send all routes: route-server.ndsoftwarenet.net> show ipv6 bgp summary BGP router identifier 10.0.1.2, local AS number 65526 242 BGP AS-PATH entries 4 BGP community entries Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 3ffe:81f1:0:1::1 4 65526 22013 8778 0 0 0 00:01:23 268 3ffe:81f1:0:2::1 4 65526 18386 8810 0 0 0 00:00:49 39 Total number of neighbors 2 route-server.ndsoftwarenet.net> I have in the both router (213.91.4.3 and 62.4.18.114): neighbor 3ffe:81f1:0:2::2 route-server-client neighbor 3ffe:81f1:0:2::2 transparent-as neighbor 3ffe:81f1:0:2::2 transparent-nexthop > > I really appreciate your taking the time to modify the zebra code and > would like to see a patch against the latest CVS posted to the Zebra > list. > > I know that you peer with multiple other people that you should be seeing > alternate paths to the above route via but, the route-server doesn't know > about them. > > If you want to see what I mean about the typical route-server showing > multiple paths, telnet to route-views.oregon-ix.net and look up the ipv4 > prefix of your choice. > > I don't know of anyone else running a telnet accessable route-server for > v6 but, there are several people running my MRLG code with public access. > > You can see an example at http://nitrous.ipv6.enterzone.net/ > Thanks for the link but a looking-glass is limited. Best Regards, Nicolas DEFFAYET From tvo@EnterZone.Net Thu Aug 8 02:17:23 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 7 Aug 2002 21:17:23 -0400 (EDT) Subject: [6bone] IPv6 route server In-Reply-To: <1028768818.15379.832.camel@wks1-1.corp.ndsoftware.com> Message-ID: On 8 Aug 2002, Nicolas DEFFAYET wrote: > I don't understand why the 2nd router (62.4.18.114) don't send all > routes: > > route-server.ndsoftwarenet.net> show ipv6 bgp summary > BGP router identifier 10.0.1.2, local AS number 65526 > 242 BGP AS-PATH entries > 4 BGP community entries > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > State/PfxRcd > 3ffe:81f1:0:1::1 > 4 65526 22013 8778 0 0 0 00:01:23 > 268 > 3ffe:81f1:0:2::1 > 4 65526 18386 8810 0 0 0 > 00:00:49 39 > > Total number of neighbors 2 > route-server.ndsoftwarenet.net> > > I have in the both router (213.91.4.3 and 62.4.18.114): > neighbor 3ffe:81f1:0:2::2 route-server-client > neighbor 3ffe:81f1:0:2::2 transparent-as > neighbor 3ffe:81f1:0:2::2 transparent-nexthop You might want to try route-reflector client. I can't remember off the top of my head what the behavior differences between the two are. Also, make sure that the route-server is NOT sending any routes to the other routers. > > > > You can see an example at http://nitrous.ipv6.enterzone.net/ > > > > Thanks for the link but a looking-glass is limited. > In what way? I can send any command to a router from MRLG that I want to. The looking-glass is only as limited as the person who sets it up wants it to be. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From pekkas@netcore.fi Thu Aug 8 06:44:13 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 8 Aug 2002 08:44:13 +0300 (EEST) Subject: [6bone] IPv6 route server In-Reply-To: Message-ID: On Wed, 7 Aug 2002, John Fraizer wrote: > This would be slick if it acted like a route-server. It only shows your > selected best path from your border router(s) though. > > route-server.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 > BGP routing table entry for 2001:4f0::/35 > Paths: (1 available, best #1, table Default-IP-Routing-Table) > Not advertised to any peer > 13944 > 3ffe:81f1:0:2::1 from 3ffe:81f1:0:2::1 (62.4.18.114) > (fe80::260:97ff:fe0c:9803) > Origin IGP, metric 800, localpref 100, valid, internal, best > Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 > Last update: Thu Aug 8 01:43:08 2002 > > I really appreciate your taking the time to modify the zebra code and > would like to see a patch against the latest CVS posted to the Zebra > list. [...] 'soft-reconfiguration inbound' on the server's configuration should fix that. -- 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 Thu Aug 8 07:01:09 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 7 Aug 2002 23:01:09 -0700 Subject: [6bone] 6bone pTLA 3FFE:4010::/32 allocated to ENTERZONE Message-ID: <2B81403386729140A3A899A8B39B046405E253@server2000.arneill-py.sacramento.ca.us> > John Fraizier wrote: > If you're talking about 3ffe:1ced::/32, Yes. > I haven't decided. If you would like to move into > 3ffe:4010::/32, I will gladly do that. I will be > moving all tunnel addresses into the pTLA. In all fairness, 3ffe:1ced::/32 has no place in the routing table; the reason we see it today are know, exceptional, and valid short term but not forever. Therefore, I suggest you dump it and use 3ffe:4010::/32. Although we have disagreed on some topics, this is the right thing to do and a good example to show. Note to everyone that intends to whine about John renumbering: The irony is that I established peering with John a few days ago. Soon, I will have to reconfigure because John is going to renumber. Am I upset about it? No. This is the 6bone. Anyone not happy about it? Instead of getting IPv6 addresses for free, go *buy* some 2001:: ones. Michel. From gert@space.net Thu Aug 8 08:19:15 2002 From: gert@space.net (Gert Doering) Date: Thu, 8 Aug 2002 09:19:15 +0200 Subject: [6bone] Build a tunnel with modem/router that filter IP protocol 41 In-Reply-To: <1028760196.15383.785.camel@wks1-1.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Thu, Aug 08, 2002 at 12:43:16AM +0200 References: <1028760196.15383.785.camel@wks1-1.corp.ndsoftware.com> Message-ID: <20020808091915.J27015@Space.Net> Hi, On Thu, Aug 08, 2002 at 12:43:16AM +0200, Nicolas DEFFAYET wrote: [..] > You can read on the eicon website > (http://www.eicon.com/support/helpweb/adsl/vpn.asp): > "The NAT Router built-in to the 24xx series allows only TCP, UDP, GRE, > and ICMP protocols through. Any other protocols are silently dropped for > security reasons." [..] > => What's the possibility for build a IPv6 over IPv4 with this > modem/router ? Depending on your IPv6 router's capabilities, you could do IPv6 over GRE - this might work. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46631 (46284) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From nicolas.deffayet@ndsoftware.net Thu Aug 8 10:49:37 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 08 Aug 2002 11:49:37 +0200 Subject: [6bone] IPv6 route server In-Reply-To: References: Message-ID: <1028800177.15380.840.camel@wks1-1.corp.ndsoftware.com> On Thu, 2002-08-08 at 07:44, Pekka Savola wrote: > On Wed, 7 Aug 2002, John Fraizer wrote: > > This would be slick if it acted like a route-server. It only shows your > > selected best path from your border router(s) though. > > > > route-server.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 > > BGP routing table entry for 2001:4f0::/35 > > Paths: (1 available, best #1, table Default-IP-Routing-Table) > > Not advertised to any peer > > 13944 > > 3ffe:81f1:0:2::1 from 3ffe:81f1:0:2::1 (62.4.18.114) > > (fe80::260:97ff:fe0c:9803) > > Origin IGP, metric 800, localpref 100, valid, internal, best > > Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 > > Last update: Thu Aug 8 01:43:08 2002 > > > > I really appreciate your taking the time to modify the zebra code and > > would like to see a patch against the latest CVS posted to the Zebra > > list. > [...] > > 'soft-reconfiguration inbound' on the server's configuration should fix > that. > I have this for all neighbors in all my routers. Best Regards, Nicolas DEFFAYET From nicolas.deffayet@ndsoftware.net Thu Aug 8 13:48:26 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 08 Aug 2002 14:48:26 +0200 Subject: [6bone] IPv6 route server In-Reply-To: References: Message-ID: <1028810907.15372.854.camel@wks1-1.corp.ndsoftware.com> On Thu, 2002-08-08 at 03:17, John Fraizer wrote: > > On 8 Aug 2002, Nicolas DEFFAYET wrote: > > > I don't understand why the 2nd router (62.4.18.114) don't send all > > routes: > > > > route-server.ndsoftwarenet.net> show ipv6 bgp summary > > BGP router identifier 10.0.1.2, local AS number 65526 > > 242 BGP AS-PATH entries > > 4 BGP community entries > > > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > > State/PfxRcd > > 3ffe:81f1:0:1::1 > > 4 65526 22013 8778 0 0 0 00:01:23 > > 268 > > 3ffe:81f1:0:2::1 > > 4 65526 18386 8810 0 0 0 > > 00:00:49 39 > > > > Total number of neighbors 2 > > route-server.ndsoftwarenet.net> > > > > I have in the both router (213.91.4.3 and 62.4.18.114): > > neighbor 3ffe:81f1:0:2::2 route-server-client > > neighbor 3ffe:81f1:0:2::2 transparent-as > > neighbor 3ffe:81f1:0:2::2 transparent-nexthop > > You might want to try route-reflector client. I can't remember off the top > of my head what the behavior differences between the two are. Also, make > sure that the route-server is NOT sending any routes to the other > routers. route-server.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 BGP routing table entry for 2001:4f0::/35 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer 13944 3ffe:81f1:0:1::2 from 3ffe:81f1:0:1::1 (62.4.18.114) Origin IGP, metric 800, localpref 100, valid, internal Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Originator: 62.4.18.114, Cluster list: 213.91.4.3 Last update: Thu Aug 8 14:40:27 2002 13944 3ffe:81f1:0:2::1 from 3ffe:81f1:0:2::1 (62.4.18.114) (fe80::260:97ff:fe0c:9803) Origin IGP, metric 800, localpref 100, valid, internal, best Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 13:49:16 2002 route-server.ndsoftwarenet.net> show ipv6 bgp summary BGP router identifier 10.0.1.2, local AS number 65526 243 BGP AS-PATH entries 4 BGP community entries Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 3ffe:81f1:0:1::1 4 65526 831 69 0 0 0 00:03:48 289 3ffe:81f1:0:2::1 4 65526 1235 120 0 0 0 00:54:49 289 Total number of neighbors 2 route-server.ndsoftwarenet.net> route-reflector client work fine. I use neighbor 3ffe:81f1:0:2::2 route-reflector-client in the router 213.91.4.3 and 62.4.18.114. Yes of course, i filter all announces of the route server. Best Regards, Nicolas DEFFAYET From bmanning@ISI.EDU Thu Aug 8 13:27:33 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 8 Aug 2002 05:27:33 -0700 (PDT) Subject: [6bone] ...buy... In-Reply-To: <2B81403386729140A3A899A8B39B046405E253@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Aug 7, 2 11:01:09 pm" Message-ID: <200208081227.g78CRXh27213@boreas.isi.edu> % This is the 6bone. Anyone not happy about it? Instead of getting IPv6 % addresses for free, go *buy* some 2001:: ones. % % Michel. % One does not -buy- addresses. One is -delegated- a stewardship over a portion of the addressing resources with the expectation that they will be used in a prudent and reasonable manner. Holds true for 3ffe:: as well as 2001:0:: Nothing majik about either prefix. -- --bill From tvo@EnterZone.Net Thu Aug 8 14:01:27 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 8 Aug 2002 09:01:27 -0400 (EDT) Subject: [6bone] IPv6 route server In-Reply-To: Message-ID: Pekka, I am currious what soft-reconfiguration has to do with bestpath selection and redistribution? --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On Thu, 8 Aug 2002, Pekka Savola wrote: > On Wed, 7 Aug 2002, John Fraizer wrote: > > This would be slick if it acted like a route-server. It only shows your > > selected best path from your border router(s) though. > > > > route-server.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 > > BGP routing table entry for 2001:4f0::/35 > > Paths: (1 available, best #1, table Default-IP-Routing-Table) > > Not advertised to any peer > > 13944 > > 3ffe:81f1:0:2::1 from 3ffe:81f1:0:2::1 (62.4.18.114) > > (fe80::260:97ff:fe0c:9803) > > Origin IGP, metric 800, localpref 100, valid, internal, best > > Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 > > Last update: Thu Aug 8 01:43:08 2002 > > > > I really appreciate your taking the time to modify the zebra code and > > would like to see a patch against the latest CVS posted to the Zebra > > list. > [...] > > 'soft-reconfiguration inbound' on the server's configuration should fix > that. > > -- > 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 Thu Aug 8 14:07:03 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 8 Aug 2002 09:07:03 -0400 (EDT) Subject: [6bone] IPv6 route server In-Reply-To: <1028810907.15372.854.camel@wks1-1.corp.ndsoftware.com> Message-ID: On 8 Aug 2002, Nicolas DEFFAYET wrote: > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > State/PfxRcd > 3ffe:81f1:0:1::1 > 4 65526 831 69 0 0 0 00:03:48 > 289 > 3ffe:81f1:0:2::1 > 4 65526 1235 120 0 0 0 00:54:49 > 289 > > Total number of neighbors 2 > route-server.ndsoftwarenet.net> > > route-reflector client work fine. > I use neighbor 3ffe:81f1:0:2::2 route-reflector-client in the router > 213.91.4.3 and 62.4.18.114. > > Yes of course, i filter all announces of the route server. > > Best Regards, > > Nicolas DEFFAYET That shows two views now. So, route-reflector-client worked better than route-server-client? Cool. I'm currious. If you do a sh ip bgp 2001:4f0::1 on your borders, how many paths do you see? John From pekkas@netcore.fi Thu Aug 8 14:18:20 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 8 Aug 2002 16:18:20 +0300 (EEST) Subject: [6bone] IPv6 route server In-Reply-To: Message-ID: On Thu, 8 Aug 2002, John Fraizer wrote: > I am currious what soft-reconfiguration has to do with bestpath selection > and redistribution? There is a feature/bug [in Cisco (noticed on GSR 12.0(22)S) at least] that unless you have soft-reconfiguration inbound, 'sh bgp ipv6 xxx' shows only the best path. Looked quite similar to me, but perhaps I was taking conclusions too far :-) > On Thu, 8 Aug 2002, Pekka Savola wrote: > > > On Wed, 7 Aug 2002, John Fraizer wrote: > > > This would be slick if it acted like a route-server. It only shows your > > > selected best path from your border router(s) though. > > > > > > route-server.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 > > > BGP routing table entry for 2001:4f0::/35 > > > Paths: (1 available, best #1, table Default-IP-Routing-Table) > > > Not advertised to any peer > > > 13944 > > > 3ffe:81f1:0:2::1 from 3ffe:81f1:0:2::1 (62.4.18.114) > > > (fe80::260:97ff:fe0c:9803) > > > Origin IGP, metric 800, localpref 100, valid, internal, best > > > Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 > > > Last update: Thu Aug 8 01:43:08 2002 > > > > > > I really appreciate your taking the time to modify the zebra code and > > > would like to see a patch against the latest CVS posted to the Zebra > > > list. > > [...] > > > > 'soft-reconfiguration inbound' on the server's configuration should fix > > that. > > > > -- > > 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 > > > -- 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 nicolas.deffayet@ndsoftware.net Thu Aug 8 14:25:59 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 08 Aug 2002 15:25:59 +0200 Subject: [6bone] IPv6 route server In-Reply-To: References: Message-ID: <1028813159.834.864.camel@wks1-1.corp.ndsoftware.com> On Thu, 2002-08-08 at 15:07, John Fraizer wrote: > > On 8 Aug 2002, Nicolas DEFFAYET wrote: > > > That shows two views now. So, route-reflector-client worked better than > route-server-client? Cool. I'm currious. If you do a sh ip bgp > 2001:4f0::1 on your borders, how many paths do you see? route-server-client don't work for me, when i try it i get a Idle state. Cisco routers don't have route-server-client command... parcr1.fr.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 BGP routing table entry for 2001:4f0::/35 Paths: (37 available, best #7, table Default-IP-Routing-Table) Advertised to non peer-group peers: 3ffe:81f1:0:2::2 3ffe:81f1:1:2002::2 3ffe:81f1:1:2006::2 3ffe:81f1:1:2007::2 3 ffe:81f1:1:2009::2 3ffe:81f1:1:200a::2 3ffe:81f1:1:200b::2 3ffe:81f1:1:200c::2 3 ffe:81f1:1:2010::2 3ffe:81f1:1:2013::2 3ffe:81f1:1:2014::2 3ffe:81f1:1:2016::2 3 ffe:81f1:1:201f::2 3ffe:81f1:1:2020::2 3ffe:81f1:1:2023::2 3ffe:81f1:1:2027::2 3 ffe:81f1:1:2029::2 3ffe:81f1:1:202b::2 3ffe:81f1:1:202c::2 3ffe:81f1:1:202d::2 3 ffe:81f1:1:202e::2 3ffe:81f1:1:2034::2 3ffe:81f1:1:2036::2 3ffe:81f1:1:2042::2 3 ffe:81f1:1:2044::2 3ffe:81f1:1:2047::2 3ffe:81f1:1:2048::2 3ffe:81f1:1:2051::2 3 ffe:81f1:1:2056::2 15671 5539 1930 13944 2001:7b0:1ff::c from 2001:7b0:1ff::c (195.226.160.196) (fe80::c3e2:a0c4) Origin IGP, metric 700, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:38:00 2002 6939 13944 3ffe:81f1:1:2008::2 from 3ffe:81f1:1:2008::2 (64.71.128.26) (fe80::4047:801a) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:49 2002 1849 24765 13944 3ffe:81f1:1:2028::2 from 3ffe:81f1:1:2028::2 (158.43.131.66) (fe80::2d0:c0ff:feb9:1c) Origin IGP, metric 500, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:45 2002 1251 109 109 13944 3ffe:81f1:1:2041::2 from 3ffe:81f1:1:2041::2 (200.136.100.163) (fe80::c888:648d) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:44 2002 5609 22 13944 3ffe:1001:1:f021::1 from 3ffe:1001:1:f021::1 (163.162.170.132) (fe80::a3a2:aa84) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:40 2002 5408 6939 13944 3ffe:2d00:1::2c from 3ffe:2d00:1::2c (194.177.210.38) (fe80::c2b1:d226) Origin IGP, metric 700, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:38 2002 13944 3ffe:81f1:0:1::2 from 3ffe:81f1:0:1::2 (62.4.18.114) (fe80::3e04:16d4) Origin IGP, metric 800, localpref 100, valid, internal, best Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:37 2002 15897 24765 13944 3ffe:81f1:1:2038::2 from 3ffe:81f1:1:2038::2 (217.31.228.62) (fe80::d91f:e43e) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:35 2002 2042 6435 13944 3ffe:81f1:1:2012::2 from 3ffe:81f1:1:2012::2 (202.187.22.65) (fe80::cabb:1602) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:34 2002 17715 6939 13944 3ffe:81f1:1:2021::2 from 3ffe:81f1:1:2021::2 (203.66.90.5) (fe80::ca27:8e91) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:34 2002 3265 8954 10566 13944 3ffe:81f1:1:2035::2 from 3ffe:81f1:1:2035::2 (194.109.5.254) (fe80::c26d:5fe) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:33 2002 8627 5539 1930 13944 3ffe:81f1:1:2025::2 from 3ffe:81f1:1:2025::2 (194.139.3.28) (fe80::c28b:31c) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:32 2002 8733 6830 6939 13944 2001:730:2::1:2 from 2001:730:2::1:2 (213.46.162.251) (fe80::d52e:a2fb) Origin IGP, metric 500, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:29 2002 15589 24765 13944 3ffe:81f1:1:2017::2 from 3ffe:81f1:1:2017::2 (192.168.1.12) (fe80::3e5e:2e69) Origin IGP, metric 700, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:29 2002 6830 6939 13944 3ffe:81f1:1:2022::2 from 3ffe:81f1:1:2022::2 (213.46.232.250) (fe80::d52e:e7f3) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:29 2002 13110 6939 13944 3ffe:400c:feed::2 from 3ffe:400c:feed::2 (62.21.98.6) (fe80::3e15:6206) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:28 2002 513 6939 13944 3ffe:81f1:1:2011::2 from 3ffe:81f1:1:2011::2 (192.65.184.7) (fe80::c041:b907) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:28 2002 5430 13285 6939 13944 2001:748:100:a0::8 from 2001:748:100:a0::8 (62.104.191.66) (fe80::3e68:bf42) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:27 2002 22 13944 3ffe:81f1:1:2039::2 from 3ffe:81f1:1:2039::2 (198.253.28.59) (fe80::c6fd:1c3b) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:27 2002 15982 6939 13944 3ffe:81f1:1:2029::2 from 3ffe:81f1:1:2029::2 (217.26.64.34) (fe80::d91a:40a0) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:500 65526:502 65526:511 65526:521 65526:900 65526:1000 65 526:1500 Last update: Thu Aug 8 14:37:26 2002 278 6939 13944 3ffe:81f1:1:2031::2 from 3ffe:81f1:1:2031::2 (192.100.200.226) (fe80::84f8:6cfe) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:25 2002 4618 6435 13944 3ffe:400b:400b:: from 3ffe:400b:400b:: (203.150.16.66) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:23 2002 1654 24765 13944 3ffe:200:1:45::1 from 3ffe:200:1:45::1 (193.10.66.219) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:23 2002 9112 4554 13944 3ffe:81f1:1:2018::2 from 3ffe:81f1:1:2018::2 (150.254.166.157) (fe80::96fe:a69d) Origin IGP, metric 700, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:23 2002 6175 13944 3ffe:2900:1:9::1 from 3ffe:2900:1:9::1 (208.19.223.30) (fe80::d013:df1e) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:21 2002 3748 6939 13944 3ffe:81f1:1:2033::2 from 3ffe:81f1:1:2033::2 (179.16.254.3) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:20 2002 6342 6435 13944 3ffe:81f1:1:2005::2 from 3ffe:81f1:1:2005::2 (131.178.107.1) (fe80::83b2:6408) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:20 2002 2549 6435 13944 3ffe:81f1:1:2032::2 from 3ffe:81f1:1:2032::2 (148.202.15.8) (fe80::94ca:f08) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:20 2002 8379 6435 13944 2001:768:e:9::1 from 2001:768:e:9::1 (195.143.108.134) (fe80::c38f:6c86) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:19 2002 10566 13944 3ffe:81f1:1:2004::2 from 3ffe:81f1:1:2004::2 (206.123.31.101) (fe80::290:27ff:fe17:fc0f) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:18 2002 1752 1930 13944 2001:7f8:2:c01d::2 from 2001:7f8:2:c01d::2 (213.121.24.91) (fe80::d579:185b) Origin IGP, metric 500, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:17 2002 20834 10566 13944 3ffe:8270:0:1::30 from 3ffe:8270:0:1::30 (80.71.0.50) (fe80::5047:32) Origin IGP, metric 500, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:16 2002 16186 24765 13944 3ffe:81f1:1:2019::2 from 3ffe:81f1:1:2019::2 (213.179.39.66) (fe80::d5b3:2742) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:16 2002 13129 1752 1930 13944 3ffe:8340::1:6 from 3ffe:8340::1:6 (212.20.133.123) Origin IGP, metric 500, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:14 2002 6435 13944 3ffe:81f1:1:2015::2 from 3ffe:81f1:1:2015::2 (64.65.64.152) (fe80::4041:4098) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:12 2002 20745 20745 20745 20745 20745 20745 20745 10566 13944 3ffe:830f::6 from 3ffe:830f::6 (217.9.66.21) (fe80::d909:420a) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:12 2002 3320 680 5539 1930 13944 3ffe:81f1:1:2003::2 from 3ffe:81f1:1:2003::2 (141.39.66.3) (fe80::8d27:4203) Origin IGP, metric 700, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 14:37:10 2002 parcr1.fr.ndsoftwarenet.net> parcr2.fr.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 BGP routing table entry for 2001:4f0::/35 Paths: (8 available, best #5, table Default-IP-Routing-Table) Advertised to non peer-group peers: 3ffe:81f1:0:1::1 3ffe:81f1:0:2::2 9044 10566 13944 3ffe:81f1:1:2104::2 from 3ffe:81f1:1:2104::2 (212.101.8.19) (fe80::d465:813) Origin IGP, metric 700, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 13:48:12 2002 762 6175 13944 3ffe:1300:1:e::1 from 3ffe:1300:1:e::1 (199.242.42.3) (fe80::260:97ff:fe29:75e5) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 13:48:06 2002 24765 13944 3ffe:4005:0:2:: from 3ffe:4005:0:2:: (62.24.229.120) Origin IGP, metric 500, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 13:48:05 2002 8379 6435 13944 2001:768:e:11::1 from 2001:768:e:11::1 (195.143.108.166) (fe80::2d0:79ff:fee2:7800) Origin IGP, metric 1000, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 13:48:05 2002 13944 3ffe:1ced:ff09::1 from 3ffe:1ced:ff09::1 (66.35.95.2) (fe80::4223:5f1e) Origin IGP, metric 800, localpref 100, valid, external, best Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 13:48:03 2002 1752 1930 13944 3ffe:81f1:1:2101::2 from 3ffe:81f1:1:2101::2 (193.113.58.80) (fe80::c171:3a50) Origin IGP, metric 1000, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 13:48:03 2002 2602 2200 1930 13944 3ffe:81f1:1:2106::2 from 3ffe:81f1:1:2106::2 (158.64.16.21) (fe80::9e40:1015) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 13:48:00 2002 8973 24765 13944 3ffe:4008:1::11 from 3ffe:4008:1::11 (192.16.124.2) (fe80::c010:7c02) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Thu Aug 8 13:47:59 2002 parcr2.fr.ndsoftwarenet.net> Best Regards, Nicolas DEFFAYET From tvo@EnterZone.Net Thu Aug 8 14:57:59 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 8 Aug 2002 09:57:59 -0400 (EDT) Subject: [6bone] IPv6 route server In-Reply-To: Message-ID: On Thu, 8 Aug 2002, Pekka Savola wrote: > On Thu, 8 Aug 2002, John Fraizer wrote: > > I am currious what soft-reconfiguration has to do with bestpath selection > > and redistribution? > > There is a feature/bug [in Cisco (noticed on GSR 12.0(22)S) at least] that > unless you have soft-reconfiguration inbound, 'sh bgp ipv6 xxx' shows only > the best path. > Ahhh... Well, with Zebra, we try very hard not to emulate the BUGS in IOS while still maintaining the look/feel. ;-) The only advantage to running soft-reconfiguration inbound on a peer with zebra is that you can do a "sh ip bgp nei [x.x.x.x | xx::xx] received-routes" and display all prefixes that the peer sent you, INCLUDING prefixes that were filtered by any inbound policy you may have established on the peer. Most people running Zebra that I know use soft-reconfiguration to achieve the ability to do "clear bgp [neighbor] soft in" on peers that don't support route-refresh. It is not needed if your peer supports route-refresh and will save memory if you disable it (on peers that support route-refresh). > Looked quite similar to me, but perhaps I was taking conclusions too far > :-) Hehehe. It is pretty close, isn't it? I think the root cause of it only showing one prefix originally in this case was that it was configured as an iBGP peer, on top of the fact that bestpath selection on the two border routers is preventing them from sending all paths they see to the route-server. I have thought about this a bit and may have come up with a solution that will give the route-server a "full" view of what the borders have. On the borders, if Nicholas were to do like this: !This is the MAIN view, the one for bestpath selection that will be used !by the border router. router bgp 65501 neighbor a::a remote-as AAAA no neighbor a::a activate neighbor b::b remote-as BBBB no neighbor b::b activate neighbor c::c remote-as CCCC no neighbor c::c activate ! address-family ipv6 network [announce your networks here] neighbor a::a activate neighbor b::b activate neighbor c::c activate exit-address-family ! !This is the AAAA view for the route-server router bgp 65501 view AAAA neighbor a::a remote-as AAAA no neighbor a::a activate neighbor route::server remote-as 65501 no neighbor route::server activate ! address-family ipv6 neighbor a::a activate neighbor a::a filter-list 2 out neighbor route::server activate neighbor route::server attribute-unchanged ! !This is the BBBB view for the route-server router bgp 65501 view BBBB neighbor b::b remote-as BBBB no neighbor b::b activate neighbor route::server remote-as 65501 no neighbor route::server activate ! address-family ipv6 neighbor b::b activate neighbor b::b filter-list 2 out neighbor route::server activate neighbor route::server attribute-unchanged ! !This is the CCCC view for the route-server router bgp 65501 view CCCC neighbor c::c remote-as CCCC no neighbor c::c activate neighbor route::server remote-as 65501 no neighbor route::server activate ! address-family ipv6 neighbor c::c activate neighbor c::c filter-list 2 out neighbor route::server activate neighbor route::server attribute-unchanged ! ip as-path access-list 2 deny .* We're simply creating a "view" for each of our eBGP peers. Since it is the only peer (besides the route-server) in that view, it will always be the bestpath to any prefixes it sends us. Since the route-server is peered in all "views" but, not in the MAIN (bestpath) view, it will get everything that the border router(s) get. We use filter-list 2 (deny *) outbound on the peers within our special views because we are already announcing our routes to them in our MAIN view. This *should* give the route-server *full* views of all your eBGP peers (at least the ones you set up views for). IMHO, this makes it a much more useful utility to the general community since they will then get to see ALL of the paths you see to a particular path vs just the selected bestpath on each border router. Note: You shouldn't have to change ANY of the configuration on the route-server itself. Simply remove the route-server from the MAIN view on the border routers and create a view for each peer you want to appear in route-server queries with [peer] and [route-server] being the only configured neighbors in that view. I've really got to cut back on the caffine! --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From tvo@EnterZone.Net Thu Aug 8 15:02:05 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 8 Aug 2002 10:02:05 -0400 (EDT) Subject: [6bone] IPv6 route server In-Reply-To: <1028813159.834.864.camel@wks1-1.corp.ndsoftware.com> Message-ID: On 8 Aug 2002, Nicolas DEFFAYET wrote: > On Thu, 2002-08-08 at 15:07, John Fraizer wrote: > > > > On 8 Aug 2002, Nicolas DEFFAYET wrote: > > > > > > That shows two views now. So, route-reflector-client worked better than > > route-server-client? Cool. I'm currious. If you do a sh ip bgp > > 2001:4f0::1 on your borders, how many paths do you see? > > route-server-client don't work for me, when i try it i get a Idle state. > Cisco routers don't have route-server-client command... > > parcr1.fr.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 > BGP routing table entry for 2001:4f0::/35 > Paths: (37 available, best #7, table Default-IP-Routing-Table) > parcr2.fr.ndsoftwarenet.net> sh ipv6 bgp 2001:4f0::1 > BGP routing table entry for 2001:4f0::/35 > Paths: (8 available, best #5, table Default-IP-Routing-Table) Take a look at the multiview config I sent in my last email. From what I see above, it will cause the route-server to see 45 paths to that prefix. It's just a suggesion. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From odysseus@soa.co.nz Wed Aug 7 16:03:24 2002 From: odysseus@soa.co.nz (Chris Hellberg) Date: Thu, 08 Aug 2002 03:03:24 +1200 Subject: [6bone] peering Message-ID: <20020807150324.9247.qmail@telemacchus.soa.co.nz> Hi, I've got a ::/48 allocation from a tunnel broker which has been working well for getting connectivity to and from the 6bone. However, I'd now like to get in to some peering and exchanging of prefixes with others. However, under ipv6 it's a lot harder due to strict aggregation rules. Therefore, are the only people I can peer with are others who also have similar ::/48's which are part of the same larger ::/28? If not, then is the only way to be able to peer with others is expect your upstream pTLA people to peer with the other pTLAs? Is the intention of an allocation from a tunnel provider just a temporary thing before getting a prefix from my upstream provider, so they're not really my addresses per se to annouce to others? What's a generally accepted practice for this sort of thing? The main problems is that it'll be many Christmases before many immediate upstreams offer anything in the way of ipv6 allocations. Also I'd be interested if anyone would be prepared to offer just a passive 6bone route feed? We've got a mini-ix here in NZ peering with several other similar tunnel allocations, but connecting these up to other tunnels would be ideal - there's not much fueling the v6 growth in New Zealand. Cheers, Chris From Tom@blazing.de Thu Aug 8 15:24:28 2002 From: Tom@blazing.de (Tom Spier) Date: Thu, 8 Aug 2002 16:24:28 +0200 Subject: [6bone] Build a tunnel with modem/router that filter IP protocol 41 References: <1028760196.15383.785.camel@wks1-1.corp.ndsoftware.com> <20020808091915.J27015@Space.Net> Message-ID: <006901c23ee7$4dee3720$0c00000a@ts> An other Solution could is a VPN like tunnel (between 2 linux boxes vtund works perfect) and to set up an IPv6-in-IPv4 tunnel which will be established over an IPv4 tunnel. (: In this case, it is possible to tunnel IPv6 behind a NAT-Gateway. Tom Spier ----- Original Message ----- Sent: Thursday, August 08, 2002 9:19 AM > Hi, > > On Thu, Aug 08, 2002 at 12:43:16AM +0200, Nicolas DEFFAYET wrote: > [..] > > You can read on the eicon website > > (http://www.eicon.com/support/helpweb/adsl/vpn.asp): > > "The NAT Router built-in to the 24xx series allows only TCP, UDP, GRE, > > and ICMP protocols through. Any other protocols are silently dropped for > > security reasons." > [..] > > => What's the possibility for build a IPv6 over IPv4 with this > > modem/router ? > > Depending on your IPv6 router's capabilities, you could do IPv6 over GRE - > this might work. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 46631 (46284) > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From nicolas.deffayet@ndsoftware.net Thu Aug 8 15:30:12 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 08 Aug 2002 16:30:12 +0200 Subject: [6bone] IPv6 route server In-Reply-To: References: Message-ID: <1028817012.15378.893.camel@wks1-1.corp.ndsoftware.com> On Thu, 2002-08-08 at 15:57, John Fraizer wrote: > > I think the root cause of it only showing one prefix originally in this > case was that it was configured as an iBGP peer, on top of the fact that > bestpath selection on the two border routers is preventing them from > sending all paths they see to the route-server. > > I have thought about this a bit and may have come up with a solution that > will give the route-server a "full" view of what the borders have. > > On the borders, if Nicholas were to do like this: > > > !This is the MAIN view, the one for bestpath selection that will be used > !by the border router. > router bgp 65501 > neighbor a::a remote-as AAAA > no neighbor a::a activate > neighbor b::b remote-as BBBB > no neighbor b::b activate > neighbor c::c remote-as CCCC > no neighbor c::c activate > ! > address-family ipv6 > network [announce your networks here] > neighbor a::a activate > neighbor b::b activate > neighbor c::c activate > exit-address-family > ! > !This is the AAAA view for the route-server > router bgp 65501 view AAAA > neighbor a::a remote-as AAAA > no neighbor a::a activate > neighbor route::server remote-as 65501 > no neighbor route::server activate > ! > address-family ipv6 > neighbor a::a activate > neighbor a::a filter-list 2 out > neighbor route::server activate > neighbor route::server attribute-unchanged > ! > !This is the BBBB view for the route-server > router bgp 65501 view BBBB > neighbor b::b remote-as BBBB > no neighbor b::b activate > neighbor route::server remote-as 65501 > no neighbor route::server activate > ! > address-family ipv6 > neighbor b::b activate > neighbor b::b filter-list 2 out > neighbor route::server activate > neighbor route::server attribute-unchanged > ! > !This is the CCCC view for the route-server > router bgp 65501 view CCCC > neighbor c::c remote-as CCCC > no neighbor c::c activate > neighbor route::server remote-as 65501 > no neighbor route::server activate > ! > address-family ipv6 > neighbor c::c activate > neighbor c::c filter-list 2 out > neighbor route::server activate > neighbor route::server attribute-unchanged > ! > ip as-path access-list 2 deny .* > > > We're simply creating a "view" for each of our eBGP peers. Since it is > the only peer (besides the route-server) in that view, it will always be > the bestpath to any prefixes it sends us. Since the route-server is > peered in all "views" but, not in the MAIN (bestpath) view, it will get > everything that the border router(s) get. We use filter-list 2 (deny > *) outbound on the peers within our special views because we are already > announcing our routes to them in our MAIN view. > > This *should* give the route-server *full* views of all your eBGP peers > (at least the ones you set up views for). IMHO, this makes it a much more > useful utility to the general community since they will then get to see > ALL of the paths you see to a particular path vs just the selected > bestpath on each border router. > > Note: You shouldn't have to change ANY of the configuration on the > route-server itself. Simply remove the route-server from the MAIN view on > the border routers and create a view for each peer you want to appear in > route-server queries with [peer] and [route-server] being the only > configured neighbors in that view. > I can't do that for more than 50 neighbors... If you check route servers on http://www.traceroute.org/#Route%20Servers, the route server display only best-paths of the remote routers or the best path from the route-server... Best Regards, Nicolas DEFFAYET From tvo@EnterZone.Net Thu Aug 8 15:40:33 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 8 Aug 2002 10:40:33 -0400 (EDT) Subject: [6bone] peering In-Reply-To: <20020807150324.9247.qmail@telemacchus.soa.co.nz> Message-ID: Chris, Others may feel differently about this but, here is how EnterZone operates when peering with people who want to announce "more specifics" or deaggregated prefixes: We will accept your more-specific (providing that you are the one shown for that prefix in the 6bone database) but tag it as no-export. We will use this direct path to you but, we won't export the route to our other eBGP peers. So, you get a direct path to us, we get a direct path to you and nobody else is any the wiser. No global table pollution. I posted a config a week or so ago that shows how we're doing this. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From andy@ipng.org.uk Thu Aug 8 15:43:45 2002 From: andy@ipng.org.uk (Andy Furnell) Date: Thu, 8 Aug 2002 15:43:45 +0100 Subject: [6bone] IPv6 route server In-Reply-To: <1028817012.15378.893.camel@wks1-1.corp.ndsoftware.com> References: <1028817012.15378.893.camel@wks1-1.corp.ndsoftware.com> Message-ID: <20020808144344.GG32065@penfold.noc.clara.net> On Thu, Aug 08, 2002 at 04:30:12PM +0200, Nicolas DEFFAYET wrote: > > On Thu, 2002-08-08 at 15:57, John Fraizer wrote: > > > > I think the root cause of it only showing one prefix originally in this > > case was that it was configured as an iBGP peer, on top of the fact that > > bestpath selection on the two border routers is preventing them from > > sending all paths they see to the route-server. > > > > I have thought about this a bit and may have come up with a solution that > > will give the route-server a "full" view of what the borders have. > > > > On the borders, if Nicholas were to do like this: > > > > > > !This is the MAIN view, the one for bestpath selection that will be used > > !by the border router. > > router bgp 65501 > > neighbor a::a remote-as AAAA > > no neighbor a::a activate > > neighbor b::b remote-as BBBB > > no neighbor b::b activate > > neighbor c::c remote-as CCCC > > no neighbor c::c activate > > ! > > address-family ipv6 > > network [announce your networks here] > > neighbor a::a activate > > neighbor b::b activate > > neighbor c::c activate > > exit-address-family > > ! > > !This is the AAAA view for the route-server > > router bgp 65501 view AAAA > > neighbor a::a remote-as AAAA > > no neighbor a::a activate > > neighbor route::server remote-as 65501 > > no neighbor route::server activate > > ! > > address-family ipv6 > > neighbor a::a activate > > neighbor a::a filter-list 2 out > > neighbor route::server activate > > neighbor route::server attribute-unchanged > > ! > > !This is the BBBB view for the route-server > > router bgp 65501 view BBBB > > neighbor b::b remote-as BBBB > > no neighbor b::b activate > > neighbor route::server remote-as 65501 > > no neighbor route::server activate > > ! > > address-family ipv6 > > neighbor b::b activate > > neighbor b::b filter-list 2 out > > neighbor route::server activate > > neighbor route::server attribute-unchanged > > ! > > !This is the CCCC view for the route-server > > router bgp 65501 view CCCC > > neighbor c::c remote-as CCCC > > no neighbor c::c activate > > neighbor route::server remote-as 65501 > > no neighbor route::server activate > > ! > > address-family ipv6 > > neighbor c::c activate > > neighbor c::c filter-list 2 out > > neighbor route::server activate > > neighbor route::server attribute-unchanged > > ! > > ip as-path access-list 2 deny .* > > > > > > We're simply creating a "view" for each of our eBGP peers. Since it is > > the only peer (besides the route-server) in that view, it will always be > > the bestpath to any prefixes it sends us. Since the route-server is > > peered in all "views" but, not in the MAIN (bestpath) view, it will get > > everything that the border router(s) get. We use filter-list 2 (deny > > *) outbound on the peers within our special views because we are already > > announcing our routes to them in our MAIN view. > > > > This *should* give the route-server *full* views of all your eBGP peers > > (at least the ones you set up views for). IMHO, this makes it a much more > > useful utility to the general community since they will then get to see > > ALL of the paths you see to a particular path vs just the selected > > bestpath on each border router. > > > > Note: You shouldn't have to change ANY of the configuration on the > > route-server itself. Simply remove the route-server from the MAIN view on > > the border routers and create a view for each peer you want to appear in > > route-server queries with [peer] and [route-server] being the only > > configured neighbors in that view. > > > > I can't do that for more than 50 neighbors... > > If you check route servers on > http://www.traceroute.org/#Route%20Servers, the route server display > only best-paths of the remote routers or the best path from the > route-server... > > Best Regards, > > Nicolas DEFFAYET > Maybe it's time to 'man peer-group'? *g* A -- Andy Furnell andy@ipng.org.uk From tvo@EnterZone.Net Thu Aug 8 15:44:03 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 8 Aug 2002 10:44:03 -0400 (EDT) Subject: [6bone] IPv6 route server In-Reply-To: <1028817012.15378.893.camel@wks1-1.corp.ndsoftware.com> Message-ID: On 8 Aug 2002, Nicolas DEFFAYET wrote: > > I can't do that for more than 50 neighbors... > > If you check route servers on > http://www.traceroute.org/#Route%20Servers, the route server display > only best-paths of the remote routers or the best path from the > route-server... > > Best Regards, > > Nicolas DEFFAYET Have you found some hard limit in Zebra that prevents you from doing this or do you just not want to configure views for 50 peers? I'm just currious. Again, this is what makes the MRLG such a useful tool. You can look at multiple border (or core) routers to see what THEIR best path is, etc. It's completely up to you. I'm just making suggestions. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From tvo@EnterZone.Net Thu Aug 8 16:00:47 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 8 Aug 2002 11:00:47 -0400 (EDT) Subject: [6bone] IPv6 route server In-Reply-To: <20020808144344.GG32065@penfold.noc.clara.net> Message-ID: On Thu, 8 Aug 2002, Andy Furnell wrote: > On Thu, Aug 08, 2002 at 04:30:12PM +0200, Nicolas DEFFAYET wrote: > > > > > > > > This *should* give the route-server *full* views of all your eBGP peers > > > (at least the ones you set up views for). IMHO, this makes it a much more > > > useful utility to the general community since they will then get to see > > > ALL of the paths you see to a particular path vs just the selected > > > bestpath on each border router. > > > > > > Note: You shouldn't have to change ANY of the configuration on the > > > route-server itself. Simply remove the route-server from the MAIN view on > > > the border routers and create a view for each peer you want to appear in > > > route-server queries with [peer] and [route-server] being the only > > > configured neighbors in that view. > > > > > > > I can't do that for more than 50 neighbors... > > > > If you check route servers on > > http://www.traceroute.org/#Route%20Servers, the route server display > > only best-paths of the remote routers or the best path from the > > route-server... > > > > Best Regards, > > > > Nicolas DEFFAYET > > > > Maybe it's time to 'man peer-group'? *g* > > A > > -- > Andy Furnell > andy@ipng.org.uk Border2-BGP# man peer-group % Unknown command. I am very familiar with peer-groups and use them to great extent. They would NOT work in this situation though. Peer-groups are view specific. Since to achieve the ultimate goal (full views of each peer on the route-server), we have to create individual views for each eBGP peer that contain just that peer and the route-server, the use of the peer-group statement would simply add additional config statements. I realize that configuring individual views for each eBGP peer is a pain in the behind and uses more memory than having a single "bestpath" main view. The memory issue shouldn't be a problem though. We're under 500 prefixes in the v6 tables so, for 50 peers, that would be 25500 (25000 in individual views and 500 selected in the MAIN view) for Zebra to keep track of. Compared to 115K prefixes for each v4 view, this is nothing! Additionally, adding a view and inserting a peer into that view is a non-destructive task - IE; the peer will never know it happened, no peering session bounce, blah blah blah. So, it's a matter of config hassle. If you're "collecting tunnels" I guess this could be a daunting task. If you peer with some disgression, it shouldn't be too bad. It's a one-time task to convert existing peers and a few extra lines of config to add a view for each new peer from that point forward. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From nicolas.deffayet@ndsoftware.net Thu Aug 8 16:56:49 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 08 Aug 2002 17:56:49 +0200 Subject: [6bone] peering In-Reply-To: <20020807150324.9247.qmail@telemacchus.soa.co.nz> References: <20020807150324.9247.qmail@telemacchus.soa.co.nz> Message-ID: <1028822209.15386.990.camel@wks1-1.corp.ndsoftware.com> On Wed, 2002-08-07 at 17:03, Chris Hellberg wrote: Hi, > > I've got a ::/48 allocation from a tunnel broker which has been working well > for getting connectivity to and from the 6bone. However, I'd now like to get > in to some peering and exchanging of prefixes with others. However, under > ipv6 it's a lot harder due to strict aggregation rules. > > Therefore, are the only people I can peer with are others who also have > similar ::/48's which are part of the same larger ::/28? If not, then is the > only way to be able to peer with others is expect your upstream pTLA people > to peer with the other pTLAs? Is the intention of an allocation from a > tunnel provider just a temporary thing before getting a prefix from my > upstream provider, so they're not really my addresses per se to annouce to > others? What's a generally accepted practice for this sort of thing? The > main problems is that it'll be many Christmases before many immediate > upstreams offer anything in the way of ipv6 allocations. > > Also I'd be interested if anyone would be prepared to offer just a passive > 6bone route feed? I can offer you a full BGP table, but i filter your /48; for information i use temporary a private ASN (i will very soon (at the end of this month if i solve the problem of the 2nd official peer) send my request to the RIPE) Best Regards, Nicolas DEFFAYET From michel@arneill-py.sacramento.ca.us Thu Aug 8 17:33:18 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 8 Aug 2002 09:33:18 -0700 Subject: [6bone] peering Message-ID: <2B81403386729140A3A899A8B39B046405E256@server2000.arneill-py.sacramento.ca.us> > John Fraizier wrote: > Others may feel differently about this but, here is how > EnterZone operates when peering with people who want to > announce "more specifics" or deaggregated prefixes: > We will accept your more-specific (providing that you > are the one shown for that prefix in the 6bone database) > but tag it as no-export. We will use this direct path to > you but, we won't export the route to our other eBGP peers. > So, you get a direct path to us, we get a direct path to > you and nobody else is any the wiser. No global table > pollution. The way John does it looks good to me. > I posted a config a week or so ago that shows how we're > doing this. About the config itself: >> - There is overlap in the following two lines: >> neighbor 3ffe:1ced:ff02::2 prefix-list AS-ARNEILLPY in neighbor >> 3ffe:1ced:ff02::2 route-map AS-ARNEILLPY in The prefix-list is useless >> as the route-map uses it IMHO. > Michel, actually, if you look at our config for your peering > session, the prefix-list actually does do something. Since I > use a "canned" route-map for all peers, I have to use the > neighbor 3ffe:1ced:ff02::2 prefix-list AS-ARNEILLPY in on your > peering session. Now I understand why you do it this way. I'm curious about one thing, though. Can't you use a peer-group for transit? You could probably have a common route-map for transit (just match the STRICT) and reserve the canned route-map with people that require special handling. Michel. From tvo@EnterZone.Net Thu Aug 8 21:55:08 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 8 Aug 2002 16:55:08 -0400 (EDT) Subject: [6bone] peering In-Reply-To: <2B81403386729140A3A899A8B39B046405E256@server2000.arneill-py.sacramento.ca.us> Message-ID: On Thu, 8 Aug 2002, Michel Py wrote: > About the config itself: > > >> - There is overlap in the following two lines: > >> neighbor 3ffe:1ced:ff02::2 prefix-list AS-ARNEILLPY in neighbor > >> 3ffe:1ced:ff02::2 route-map AS-ARNEILLPY in The prefix-list is > useless > >> as the route-map uses it IMHO. > > > Michel, actually, if you look at our config for your peering > > session, the prefix-list actually does do something. Since I > > use a "canned" route-map for all peers, I have to use the > > neighbor 3ffe:1ced:ff02::2 prefix-list AS-ARNEILLPY in on your > > peering session. > > Now I understand why you do it this way. I'm curious about one thing, > though. Can't you use a peer-group for transit? You could probably have > a common route-map for transit (just match the STRICT) and reserve the > canned route-map with people that require special handling. > > Michel. Well, yes. I could use a peer-group and use the route-map [blah] in statement as part of the peer-group. I choose to use a seperate route-map for each peer so we can do traffic engineering. Some peers are weighted differently than others. I'll also pref some as-paths (up/downstream of a peer) differently. For example, you can reach C via both A and B but, the actual goodput is much better via B. I use the peer specific route-maps to pref B_C over(or under as the case may be - I generally depref bad routes vs adding to the localpref value of good ones) A_C. Do you see the reasoning behind the individual route-maps? I know it's a pain in the behind in some ways to do things like this. I have learned though: Right Way Easy Way Best way for the long run Pick any two... --- 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 Aug 10 05:06:59 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 9 Aug 2002 21:06:59 -0700 Subject: [6bone] peering Message-ID: <2B81403386729140A3A899A8B39B04640BCFB8@server2000.arneill-py.sacramento.ca.us> > John Fraizier wrote: > Well, yes. I could use a peer-group and use the route-map > [blah] in statement as part of the peer-group. I choose to > use a seperate route-map for each peer so we can do traffic > engineering. Some peers are weighted differently than others. > I'll also pref some as-paths (up/downstream of a peer) > differently. For example, you can reach C via both A and B > but, the actual goodput is much better via B. I use the peer > specific route-maps to pref B_C over(or under as the case may > be - I generally depref bad routes vs adding to the localprefs > value of good ones) A_C. Do you see the reasoning behind the > individual route-maps? I do, I do the same myself. I was just trying to probe if someone had found a config that achieved all of the three criteria below.... > I know it's a pain in the behind in some ways to do things > like this. I have learned though: > Right Way > Easy Way > Best way for the long run > Pick any two... Yep. Michel. From fink@es.net Sat Aug 10 16:14:37 2002 From: fink@es.net (Bob Fink) Date: Sat, 10 Aug 2002 08:14:37 -0700 Subject: [6bone] pTLA request by Euro6IX project for exchange experimentation - review closes 3 Sep 2002 Message-ID: <5.1.0.14.0.20020810080820.02182280@imap2.es.net> 6bone Folk, The Euro6IX Project has requested a pTLA allocation and I find their request consistent with 6bone goals and with merit. In specific, it is the first attempt to try the new type of exchange-based aggregation talked about in RFC2374, "An IPv6 Aggregatable Global Unicast Address Format". Please see their request below. There is to date no specific Euro6IX entity operational on the 6bone as the partners and participants in the Euro6IX project have all the IPv6 experience from their own entities. I don't view this as a shortcoming as the Euro6IX folk are highly IPv6 experienced. I would hope that this project would result in clearer understanding of the issues and practices involved with exchange-based aggregation for the future use in the IPv6-based Internet. I would also appreciate discussion of any considerations that we should be aware of as a 6bone test project. The open review period for this will close 3 September 2002. Please send your comments to me or the list. Thanks, Bob === From: "JORDI PALET MARTINEZ" Subject: pTLA request by Euro6IX project for exchange experimentation ... Euro6IX is working on two IX scenarios, and is requesting a 6Bone pTLA in order to carry out the second scenario below: The first scenario would be very similar to the classical conception of the IX where the providers' routers are directly connected to the second layer infrastructure. In this scenario, the router linking the IXs between each other belongs to the domain administratively managed by the Telco owning that IX. So an intra-domain routing protocol could be run on this router to exchange reachability information with those IX routers belonging to the same administrative domain. In this case, for our scopes, a /48 IPv6 prefix per IX could be enough to number the devices in each IX. The Telco owning the IX will manage the its pTLA or sTLA to number the IX devices. The second scenario considers on a new conception of the IX based on the so-called "layer 3 mediation function". This new role is based on the possibility, from the IX to assign IPv6 prefixes independent of the provider. In this case, each customer accessing the IX chooses the provider (one or more) and the IX assigns them the IPv6 prefixes. If a customer decides to change the provider, it does not have to change IPv6 prefixes, because they are provider independent and are assigned by that particular IX. In this scenario, the router linking the IXs between each other can belong to a different administrative domain than that managed by Telco owning the IX. So an inter-domain routing protocol could run on this router to exchange routing information with the IX routers belonging to other administrative domains. In this scenario, the Euro6IX is the owner of the pTLA used to assign prefixes to each IX user. -end From Ronald.vanderPol@rvdp.org Mon Aug 12 09:31:44 2002 From: Ronald.vanderPol@rvdp.org (Ronald.vanderPol@rvdp.org) Date: Mon, 12 Aug 2002 10:31:44 +0200 Subject: [6bone] routing problem Message-ID: <20020812083144.GA23039@einstein.nlnetlabs.nl> This morning, 6bone routing is working great again :-( My packets go all around the world, except where they are supposed to go, a couple of kilometers away. $ traceroute6 kirk.rvdp.org traceroute6 to kirk.rvdp.org (2001:610:508:1001::1) from 2001:6e0:206:1:220:edff :fe19:4862, 30 hops max, 12 byte packets 1 sixgate 0.465 ms 0.241 ms 0.201 ms 2 Matrix1.core.ipv6.intouch.net 0.337 ms 0.32 ms 0.297 ms 3 ams-cust.core.ipv6.intouch.net 0.719 ms 0.685 ms 0.662 ms 4 edt-intouch.ipv6.edisontel.it 56.626 ms 57.222 ms 57.296 ms 5 3ffe:8120::19:1 77.743 ms 77.648 ms 78.07 ms 6 ::128.107.240.254 208.484 ms 208.147 ms 208.297 ms 7 tunnel-stealth-lavanoc.lava.net 283.503 ms 3ffe:81d0:ffff:2::22 220.401 ms 219.823 ms 8 edt-hurricane.ipv6.edisontel.it 241.509 ms 2001:288:3b0::1e 410.271 ms 41 1.955 ms 9 2001:288:3b0::1b 410.547 ms 411.804 ms 411.807 ms 10 3ffe:8120::19:1 338.267 ms 337.184 ms 336.319 ms 11 3ffe:8120::8:2 546.298 ms * 545.426 ms 12 3ffe:c00:8023:2f::1 540.567 ms 540.827 ms ipv6-gw.ipv6.man.poznan.pl 276. 96 ms 13 3ffe:8320:1:: 438.038 ms 437.34 ms 436.39 ms 14 3ffe:200:1:61::2 301.057 ms 2001:288:3b0::1e 686.372 ms 2001:7f8:2:8016::3 466.067 ms 15 fe-tu0.pao.ipv6.he.net 592.915 ms 660.317 ms 635.527 ms 16 3ffe:81d0:ffff:2::22 523.884 ms 473.015 ms 460.349 ms 17 edt-hurricane.ipv6.edisontel.it 540.591 ms 484.15 ms 484.438 ms 18 3ffe:8120::19:1 503.904 ms 503.959 ms 504.063 ms 19 2001:288:3b0::2 836.366 ms 904.766 ms 944.527 ms 20 2001:288:3b0::1f 835.769 ms 836.396 ms 837.633 ms 21 2001:288:3b0::1e 999.56 ms 1006.61 ms 1003.31 ms 22 2001:288:3b0::1b 836.865 ms 931.304 ms 836.235 ms 23 3ffe:8140:101:5::3 835.866 ms 836.066 ms 837.62 ms 24 pc6.otemachi.wide.ad.jp 836.719 ms 835.717 ms 835.182 ms 25 * KOTsre01-101.nw.v6.odn.ne.jp 888.587 ms 891.257 ms 26 STOsre01-201.nw.v6.odn.ne.jp 890.308 ms 964.177 ms 889.769 ms 27 2001:7f8:2:8016::3 889.739 ms 889.598 ms 889.922 ms 28 fe-tu0.pao.ipv6.he.net 887.98 ms 889.919 ms 886.22 ms 29 3ffe:81d0:ffff:2::22 887.853 ms 885.344 ms 885.198 ms 30 edt-hurricane.ipv6.edisontel.it 958.517 ms 909.741 ms 907.426 ms $ rvdp From Wim.Biemolt@surfnet.nl Mon Aug 12 14:05:34 2002 From: Wim.Biemolt@surfnet.nl (Wim Biemolt) Date: Mon, 12 Aug 2002 15:05:34 +0200 Subject: [6bone] routing problem In-Reply-To: Your message of "Mon, 12 Aug 2002 10:31:44 +0200." <20020812083144.GA23039@einstein.nlnetlabs.nl> Message-ID: <57898.1029157534@gigant.surfnet.nl> ==> From: Ronald.vanderPol@rvdp.org > This morning, 6bone routing is working great again :-( > > My packets go all around the world, except where they are supposed to > go, a couple of kilometers away. We are trying hard to get rid of the advertisements for our /35 after migrating to /32. Seems more difficult that expected. But after that your routing problem should probably be gone. -Wim -/- SURFnet From nicolas.deffayet@ndsoftware.net Mon Aug 12 14:48:00 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 12 Aug 2002 15:48:00 +0200 Subject: [6bone] routing problem In-Reply-To: <20020812083144.GA23039@einstein.nlnetlabs.nl> References: <20020812083144.GA23039@einstein.nlnetlabs.nl> Message-ID: <1029160080.1354.76.camel@wks1-1.corp.ndsoftware.com> On Mon, 2002-08-12 at 10:31, Ronald.vanderPol@rvdp.org wrote: > This morning, 6bone routing is working great again :-( > > My packets go all around the world, except where they are supposed to > go, a couple of kilometers away. > > $ traceroute6 kirk.rvdp.org > traceroute6 to kirk.rvdp.org (2001:610:508:1001::1) from 2001:6e0:206:1:220:edff > :fe19:4862, 30 hops max, 12 byte packets The announce of 2001:610::/35 is bad but 2001:610::/32 is good. You can check: telnet route-server.ndsoftwarenet.net (IPv6 only) route-server.ndsoftwarenet.net> show ipv6 bgp 2001:610:508:1001::1 BGP routing table entry for 2001:610::/35 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 3ffe:81f1:0:1::1 from 3ffe:81f1:0:1::1 (213.91.4.3) Origin IGP, metric 600, localpref 100, valid, internal, atomic-aggregate, best Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 12 15:17:03 2002 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 3ffe:81f1:0:1::1 from 3ffe:81f1:0:2::1 (213.91.4.3) Origin IGP, metric 600, localpref 100, valid, internal, atomic-aggregate Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Originator: 213.91.4.3, Cluster list: 62.4.18.114 Last update: Mon Aug 12 15:17:07 2002 route-server.ndsoftwarenet.net> show ipv6 bgp 2001:610::/32 BGP routing table entry for 2001:610::/32 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer 2602 1103, (aggregated by 1103 145.145.255.42) 3ffe:81f1:0:1::2 from 3ffe:81f1:0:1::1 (62.4.18.114) Origin IGP, metric 600, localpref 100, valid, internal, atomic-aggregate Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Originator: 62.4.18.114, Cluster list: 213.91.4.3 Last update: Mon Aug 12 13:43:51 2002 2602 1103, (aggregated by 1103 145.145.255.42) 3ffe:81f1:0:2::1 from 3ffe:81f1:0:2::1 (62.4.18.114) (fe80::260:97ff:fe0c:9803) Origin IGP, metric 600, localpref 100, valid, internal, atomic-aggregate, best Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 12 13:43:48 2002 route-server.ndsoftwarenet.net> Many routers keep in cache and reannonce 2001:610::/35 that Surfnet don't announce. Same problem for a lot of pTLA/sTLA: http://noc.ndsoftwarenet.com/stats/aspath-tree/history/AMS-IX.html http://noc.ndsoftwarenet.com/stats/aspath-tree/history/UNI-C.html http://noc.ndsoftwarenet.com/stats/aspath-tree/history/BME-FSZ.html http://noc.ndsoftwarenet.com/stats/aspath-tree/history/UUNET-UK.html http://noc.ndsoftwarenet.com/stats/aspath-tree/history/UL.html http://noc.ndsoftwarenet.com/stats/aspath-tree/history/NETCOM-UK.html http://noc.ndsoftwarenet.com/stats/aspath-tree/history/CAIRN.html http://noc.ndsoftwarenet.com/stats/aspath-tree/history/35-INTEROP-JP-20020617.html http://noc.ndsoftwarenet.com/stats/aspath-tree/history/SWISSCOM.html Best Regards, Nicolas DEFFAYET From gert@space.net Mon Aug 12 14:59:30 2002 From: gert@space.net (Gert Doering) Date: Mon, 12 Aug 2002 15:59:30 +0200 Subject: [6bone] routing problem In-Reply-To: <57898.1029157534@gigant.surfnet.nl>; from Wim.Biemolt@surfnet.nl on Mon, Aug 12, 2002 at 03:05:34PM +0200 References: <20020812083144.GA23039@einstein.nlnetlabs.nl> <57898.1029157534@gigant.surfnet.nl> Message-ID: <20020812155930.C27015@Space.Net> hi, On Mon, Aug 12, 2002 at 03:05:34PM +0200, Wim Biemolt wrote: > ==> From: Ronald.vanderPol@rvdp.org > > > This morning, 6bone routing is working great again :-( > > > > My packets go all around the world, except where they are supposed to > > go, a couple of kilometers away. > > We are trying hard to get rid of the advertisements for our /35 > after migrating to /32. Seems more difficult that expected. But > after that your routing problem should probably be gone. Ghosts again. This time the announcement seems to be stuck in AS7660 (someone in Japan) and in AS6830 (Chello). All paths that I see end in 7660 or 6830 . Those are the paths that I see: 3274 6175 10109 7660 2500 4725 1752 6939 3425 1103 1853 1853 1853 1853 1853 786 11537 22388 7660 2500 4725 1752 6939 3425 1103 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103 3292 109 6435 9264 7660 2500 4725 1752 6939 3425 1103 15671 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103 1752 8627 6830 6939 2549 109 6435 15982 15589 513 2200 1103 517 4589 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103 3561 145 11537 22388 7660 2500 4725 1752 6939 3425 1103 8627 6830 6939 2549 109 6435 15982 15589 513 2200 1103 9044 513 9264 7660 2500 4725 1752 6939 3425 1103 1752 8627 6830 6939 2549 109 6435 15982 15589 513 2200 1103 517 4589 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103 3561 145 11537 22388 7660 2500 4725 1752 6939 3425 1103 8627 6830 6939 2549 109 6435 15982 15589 513 2200 1103 9044 513 9264 7660 2500 4725 1752 6939 3425 1103 680 2200 513 9264 7660 2500 4725 1752 6939 3425 1103 3320 680 1275 5609 9264 7660 2500 4725 1752 6939 3425 1103 5430 13285 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103 12337 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103 1930 2200 513 9264 7660 2500 4725 1752 6939 3425 1103 1849 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103 4554 5609 9264 7660 2500 4725 1752 6939 3425 1103 109 109 6435 9264 7660 2500 4725 1752 6939 3425 1103 Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert@space.net Mon Aug 12 15:30:32 2002 From: gert@space.net (Gert Doering) Date: Mon, 12 Aug 2002 16:30:32 +0200 Subject: [6bone] routing problem In-Reply-To: <1029160080.1354.76.camel@wks1-1.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Mon, Aug 12, 2002 at 03:48:00PM +0200 References: <20020812083144.GA23039@einstein.nlnetlabs.nl> <1029160080.1354.76.camel@wks1-1.corp.ndsoftware.com> Message-ID: <20020812163032.E27015@Space.Net> Hi, On Mon, Aug 12, 2002 at 03:48:00PM +0200, Nicolas DEFFAYET wrote: > [ Ghost /35s ] > Many routers keep in cache and reannonce 2001:610::/35 that Surfnet > don't announce. To clarify this: this is not an effect of "caching" of any sort. It's just plain buggy router implementations that don't handle withdrawals correctly. One well-known cause for this was Viagenie (using MRTd), but they seem to have fixed their routers - at least they don't show up this time. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From michel@arneill-py.sacramento.ca.us Mon Aug 12 19:27:14 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 12 Aug 2002 11:27:14 -0700 Subject: [6bone] pTLA request by Euro6IX project for exchange experimentation - review closes 3 Sep 2002 Message-ID: <2B81403386729140A3A899A8B39B046405E26A@server2000.arneill-py.sacramento.ca.us> Jordi / Bob / 6boner, I have some specific questions about this: 1. Question regarding allocations/assignments within the Euro6IX pTLA: My understanding is that this pTLA would be used for IX infrastructure, which means routers physically present in one of the IXes, links between them, router loopbacks, common peering subnets, that kind of thing. Am I correct? The question is: what block size are you planning on allocating to whom? For example, are your planning on allocating a /48 to each IX, and let the IX assign subnets to participants? Are you planning multiple levels of aggregation (such as a /40 per country)? 2. Question about the consequences on the global IPv6 routing table. What will we see in the global routing table WRT the Euro6IX pTLA? The question is actually more like what are the consequences if everyone (except Euro6IX IXes peering between themselves) is applying the "STRICT" route map that has been discussed recently. If all we shall see in the global routing table is the Euro6IX pTLA aggregate, I am curious to know who will announce it, and if you plan to have each IX announce it as a proxy/pseudo anycast route. Thanks Michel. From Wim.Biemolt@surfnet.nl Mon Aug 12 19:56:09 2002 From: Wim.Biemolt@surfnet.nl (Wim Biemolt) Date: Mon, 12 Aug 2002 20:56:09 +0200 Subject: [6bone] routing problem In-Reply-To: Your message of "Mon, 12 Aug 2002 16:30:32 +0200." <20020812163032.E27015@Space.Net> Message-ID: <58898.1029178569@gigant.surfnet.nl> ==> From: Gert Doering > To clarify this: this is not an effect of "caching" of any sort. It's > just plain buggy router implementations that don't handle withdrawals > correctly. So I can only hope that a buggy router implementation also means a memory leak or something like that causing them to reboot in the real near future? The only other option I see is switch back to our /35. We are using IPv6 as production. Being without any decent IPv6 connectivity for too long won't do our case for IPv6 any good I'm afraid. -Wim -/- SURFnet From Ronald.vanderPol@rvdp.org Mon Aug 12 20:11:10 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Mon, 12 Aug 2002 21:11:10 +0200 Subject: Fwd: Re: [6bone] routing problem Message-ID: <20020812191110.GA3524@rvdp.org> APAN, Chello, Can you please check your 6bone routing tables for bogus 2001:610::/35 entries (see below)? rvdp ----- Forwarded message from Gert Doering ----- From: Gert Doering To: Wim Biemolt Cc: Ronald.vanderPol@rvdp.org, 6bone@ISI.EDU Subject: Re: [6bone] routing problem Date: Mon, 12 Aug 2002 15:59:30 +0200 hi, On Mon, Aug 12, 2002 at 03:05:34PM +0200, Wim Biemolt wrote: > ==> From: Ronald.vanderPol@rvdp.org > > > This morning, 6bone routing is working great again :-( > > > > My packets go all around the world, except where they are supposed to > > go, a couple of kilometers away. > > We are trying hard to get rid of the advertisements for our /35 > after migrating to /32. Seems more difficult that expected. But > after that your routing problem should probably be gone. Ghosts again. This time the announcement seems to be stuck in AS7660 (someone in Japan) and in AS6830 (Chello). All paths that I see end in 7660 or 6830 . Those are the paths that I see: 3274 6175 10109 7660 2500 4725 1752 6939 3425 1103 1853 1853 1853 1853 1853 786 11537 22388 7660 2500 4725 1752 6939 3425 1103 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103 3292 109 6435 9264 7660 2500 4725 1752 6939 3425 1103 15671 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103 1752 8627 6830 6939 2549 109 6435 15982 15589 513 2200 1103 517 4589 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103 3561 145 11537 22388 7660 2500 4725 1752 6939 3425 1103 8627 6830 6939 2549 109 6435 15982 15589 513 2200 1103 9044 513 9264 7660 2500 4725 1752 6939 3425 1103 1752 8627 6830 6939 2549 109 6435 15982 15589 513 2200 1103 517 4589 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103 3561 145 11537 22388 7660 2500 4725 1752 6939 3425 1103 8627 6830 6939 2549 109 6435 15982 15589 513 2200 1103 9044 513 9264 7660 2500 4725 1752 6939 3425 1103 680 2200 513 9264 7660 2500 4725 1752 6939 3425 1103 3320 680 1275 5609 9264 7660 2500 4725 1752 6939 3425 1103 5430 13285 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103 12337 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103 1930 2200 513 9264 7660 2500 4725 1752 6939 3425 1103 1849 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103 4554 5609 9264 7660 2500 4725 1752 6939 3425 1103 109 109 6435 9264 7660 2500 4725 1752 6939 3425 1103 Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 _______________________________________________ 6bone mailing list 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone ----- End forwarded message ----- From gert@space.net Mon Aug 12 20:20:02 2002 From: gert@space.net (Gert Doering) Date: Mon, 12 Aug 2002 21:20:02 +0200 Subject: [6bone] routing problem In-Reply-To: <58898.1029178569@gigant.surfnet.nl>; from Wim.Biemolt@surfnet.nl on Mon, Aug 12, 2002 at 08:56:09PM +0200 References: <20020812163032.E27015@Space.Net> <58898.1029178569@gigant.surfnet.nl> Message-ID: <20020812212002.R27015@Space.Net> Hi, (I am copying the 6bone mailing list back in, as I think this is a pretty generic problem - I hope you don't mind) On Mon, Aug 12, 2002 at 08:56:09PM +0200, Wim Biemolt wrote: > ==> From: Gert Doering > > > To clarify this: this is not an effect of "caching" of any sort. It's > > just plain buggy router implementations that don't handle withdrawals > > correctly. > > So I can only hope that a buggy router implementation also means a memory > leak or something like that causing them to reboot in the real near future? No. In our case, the /35 staid in the table until I finally managed to reach someone at Viagenie who cleared some sessions... the BT /35 got stuck at Chello, and after clearing their sessions, at Viagenie. > The only other option I see is switch back to our /35. We are using IPv6 > as production. So are we... > Being without any decent IPv6 connectivity for too long > won't do our case for IPv6 any good I'm afraid. No :-(( My recommendation would be to contact all your peers and check the different paths seen everywhere for "common tails". Then contact the AS(es) that you see in the first hop of the "common tail" (in your case, as far as I could see, Chello and this Japanese AS) and ask them to check their tables for the prefix, and preferably clear some BGP sessions (upstream and/or downstream). In the last case, clearing session at Chello and yelling at Viagenie helped... but as I said, this time, Viagenie hasn't been in the paths (yet?), but a new japanese AS that I haven't seen before. This takes some time, though (1-2 days). If you can't spend that time, you'll have to announce both the /32 and the /35, establish contact to the suspect ASes, withdraw the /35 again, and hope that you got the right ones. Feel free to contact me to get an "show bgp ipv6 ..." output from here. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From nicolas.deffayet@ndsoftware.net Mon Aug 12 20:31:56 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 12 Aug 2002 21:31:56 +0200 Subject: [6bone] pTLA request by Euro6IX project for exchange experimentation - review closes 3 Sep 2002 In-Reply-To: <2B81403386729140A3A899A8B39B046405E26A@server2000.arneill-py.sacramento.ca. us> References: <2B81403386729140A3A899A8B39B046405E26A@server2000.arneill-py.sacramento.ca. us> Message-ID: <1029180716.1358.263.camel@wks1-1.corp.ndsoftware.com> On Mon, 2002-08-12 at 20:27, Michel Py wrote: Michel / Jordi / Bob / 6boner, > I have some specific questions about this: > > 1. Question regarding allocations/assignments within the Euro6IX pTLA: > > My understanding is that this pTLA would be used for IX infrastructure, > which means routers physically present in one of the IXes, links between > them, router loopbacks, common peering subnets, that kind of thing. Am I > correct? > > The question is: what block size are you planning on allocating to whom? > For example, are your planning on allocating a /48 to each IX, and let > the IX assign subnets to participants? Are you planning multiple levels > of aggregation (such as a /40 per country)? Why IX don't use the Global IPv6 Internet Exchange Points Assignments made by the RIR ? > > 2. Question about the consequences on the global IPv6 routing table. > > What will we see in the global routing table WRT the Euro6IX pTLA? The > question is actually more like what are the consequences if everyone > (except Euro6IX IXes peering between themselves) is applying the > "STRICT" route map that has been discussed recently. > > If all we shall see in the global routing table is the Euro6IX pTLA > aggregate, I am curious to know who will announce it, and if you plan to > have each IX announce it as a proxy/pseudo anycast route. > I think that it will be like the AMS-IX pTLA (http://whois.6bone.net/cgi-bin/whois?ams-ix). Best regards, Nicolas DEFFAYET From RJorgensen@upctechnology.com Mon Aug 12 20:42:16 2002 From: RJorgensen@upctechnology.com (Jorgensen, Roger) Date: Mon, 12 Aug 2002 21:42:16 +0200 Subject: [6bone] routing problem Message-ID: <7CEA40C0E10C7D4FBE076AE7C3EFB78D88F253@nlcbbms03> Hi, We're geting the 2001:610::/35 from many of our peers, and we're also seing the 2001:610::/32 from even more peers. Seems like the ghost bug is out there again... this is what we see, and there are some common as path's in all of them, BGP routing table entry for 2001:610::/35, version 95785 Paths: (26 available, best #21, table Global-IPv6-Table) Advertised to non peer-group peers: 2001:6C8:0:FFFD::12 2001:730::1:1 2001:730::1:3 2001:730::1:5 2001:730::1:7 2001:730::1:F 2001:730::1:15 2001:730::1:19 2001:730::1:1D 2001:730::1:21 2001:730::1:23 2001:730::1:29 2001:730::1:2F 2001:730::1:31 2001:730::1:33 2001:730::1:35 2001:730::1:37 2001:730::1:39 2001:730::1:3B 2001:730::1:3F 2001:730::1:41 2001:730:0:2::AAE2 2001:740:0:102::1:0 2001:768:E:24::1 2001:778:11:4::2 2001:7F8:2:800F::2 3FFE:2000:0:40F::22F 3FFE:2501:100::21 3FFE:2900:1:5::1 3FFE:4006:0:3::11 3FFE:4008:1::D 3FFE:81F1:1:2022::1 3FFE:8270:0:1::52 2012 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 2001:730::1:33 from 2001:730::1:33 (193.224.190.128) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 2012:200 2012:513 6830:60003 6830:60011 2012 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 2001:730::1:33 from 2001:730::1:33 (193.224.190.128) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 2012:200 2012:513 790 3274 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 2001:730::1:7 from 2001:730::1:7 (193.94.250.58) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 6830:60003 6830:60011 790 3274 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 2001:730::1:7 from 2001:730::1:7 (193.94.250.58) Origin IGP, localpref 100, valid, external, atomic-aggregate 559 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 3FFE:2000:0:40F::22F from 3FFE:2000:0:40F::22F (130.59.32.38) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 6830:60003 6830:60011 559 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 3FFE:2000:0:40F::22F from 3FFE:2000:0:40F::22F (130.59.32.38) Origin IGP, localpref 100, valid, external, atomic-aggregate 3292 109 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 2001:6C8:0:FFFD::12 from 2001:6C8:0:FFFD::12 (195.249.8.172) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 6830:60003 6830:60011 3292 109 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 2001:6C8:0:FFFD::12 from 2001:6C8:0:FFFD::12 (195.249.8.172) Origin IGP, localpref 100, valid, external, atomic-aggregate 6726 24765 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 2001:730::1:19 from 2001:730::1:19 (80.84.236.164) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 6830:60003 6830:60011 6726 24765 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 2001:730::1:19 from 2001:730::1:19 (80.84.236.164) Origin IGP, localpref 100, valid, external, atomic-aggregate 8758 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 3FFE:4006:0:3::11 from 3FFE:4006:0:3::11 (212.25.27.46) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 6830:60003 6830:60011 24765:200 24765:800 24765:3500 24765:7005 8758 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 3FFE:4006:0:3::11 from 3FFE:4006:0:3::11 (212.25.27.46) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 24765:200 24765:800 24765:3500 24765:7005 8973 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 3FFE:4008:1::D from 3FFE:4008:1::D (192.16.124.2) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 6830:60003 6830:60011 8973 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 3FFE:4008:1::D from 3FFE:4008:1::D (192.16.124.2) Origin IGP, localpref 100, valid, external, atomic-aggregate 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 3FFE:2900:1:5::1 from 3FFE:2900:1:5::1 (208.19.223.30) Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate Community: 6830:60003 6830:60011 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 3FFE:2900:1:5::1 from 3FFE:2900:1:5::1 (208.19.223.30) Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate 20834 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 3FFE:8270:0:1::52 from 3FFE:8270:0:1::52 (80.71.0.50) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 6830:60003 6830:60011 20834 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 3FFE:8270:0:1::52 from 3FFE:8270:0:1::52 (80.71.0.50) Origin IGP, localpref 100, valid, external, atomic-aggregate 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 2001:730::1:F from 2001:730::1:F (192.168.1.12) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 6830:60003 6830:60011 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 2001:730::1:F from 2001:730::1:F (192.168.1.12) Origin IGP, localpref 100, valid, external, atomic-aggregate 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 2001:730::1:9 from 2001:730::1:9 (163.162.170.129) Origin IGP, localpref 100, valid, external, atomic-aggregate, best Community: 6830:60003 6830:60011 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 2001:730::1:9 from 2001:730::1:9 (163.162.170.129) Origin IGP, localpref 100, valid, external, atomic-aggregate 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 2001:768:E:24::1 from 2001:768:E:24::1 (195.143.108.166) Origin IGP, localpref 100, valid, external, atomic-aggregate Community: 6830:60003 6830:60011 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 2001:768:E:24::1 from 2001:768:E:24::1 (195.143.108.166) Origin IGP, localpref 100, valid, external, atomic-aggregate 12337 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242) 2001:730::1:31 from 2001:730::1:31 (62.128.0.14) Origin IGP, metric 10, localpref 100, valid, external, atomic-aggregate Community: 6830:60003 6830:60011 12337:6004 12337 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 145.145.249.242), (received-only) 2001:730::1:31 from 2001:730::1:31 (62.128.0.14) Origin IGP, metric 10, localpref 100, valid, external, atomic-aggregate Community: 12337:6004 --- Roger Jorgensen (rjorgensen@upctechnology.com) System Engineer @ engineering - UPC Technology handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, August 12, 2002 9:20 PM > To: Wim Biemolt > Cc: 6bone@ISI.EDU > Subject: Re: [6bone] routing problem > > > Hi, > > (I am copying the 6bone mailing list back in, as I think this > is a pretty > generic problem - I hope you don't mind) > > On Mon, Aug 12, 2002 at 08:56:09PM +0200, Wim Biemolt wrote: > > ==> From: Gert Doering > > > > > To clarify this: this is not an effect of "caching" of > any sort. It's > > > just plain buggy router implementations that don't handle > withdrawals > > > correctly. > > > > So I can only hope that a buggy router implementation also > means a memory > > leak or something like that causing them to reboot in the > real near future? > > No. In our case, the /35 staid in the table until I finally > managed to > reach someone at Viagenie who cleared some sessions... the BT /35 got > stuck at Chello, and after clearing their sessions, at Viagenie. > > > The only other option I see is switch back to our /35. We > are using IPv6 > > as production. > > So are we... > > > Being without any decent IPv6 connectivity for too long > > won't do our case for IPv6 any good I'm afraid. > > No :-(( > > My recommendation would be to contact all your peers and > check the different > paths seen everywhere for "common tails". Then contact the > AS(es) that you > see in the first hop of the "common tail" (in your case, as > far as I could > see, Chello and this Japanese AS) and ask them to check their > tables for > the prefix, and preferably clear some BGP sessions (upstream and/or > downstream). > > In the last case, clearing session at Chello and yelling at Viagenie > helped... but as I said, this time, Viagenie hasn't been in > the paths > (yet?), but a new japanese AS that I haven't seen before. > > This takes some time, though (1-2 days). If you can't spend > that time, > you'll have to announce both the /32 and the /35, establish contact to > the suspect ASes, withdraw the /35 again, and hope that you got the > right ones. > > Feel free to contact me to get an "show bgp ipv6 ..." output > from here. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: > 46871 (46631) > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From jeroen@unfix.org Mon Aug 12 20:50:55 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Mon, 12 Aug 2002 21:50:55 +0200 Subject: [6bone] routing problem In-Reply-To: <58898.1029178569@gigant.surfnet.nl> Message-ID: <002401c24239$930654f0$420d640a@unfix.org> Wim Biemolt wrote: > ==> From: Gert Doering > > > To clarify this: this is not an effect of "caching" of any sort. It's > > just plain buggy router implementations that don't handle withdrawals > > correctly. > > So I can only hope that a buggy router implementation also > means a memory > leak or something like that causing them to reboot in the > real near future? > > The only other option I see is switch back to our /35. We are > using IPv6 > as production. Being without any decent IPv6 connectivity for too long > won't do our case for IPv6 any good I'm afraid. > > -Wim -/- SURFnet There is one good way: find out the AS's who are 'bad' and depeer them if they don't respond in x time. This is just the same as for IPv4... PS: Gert.. did you put an extra page in your presentation saying TLA's are moving to /32's? PS2: Gert, don't get a sunburn in Rhodos ;) Greets, Jeroen From Daniel Austin" Message-ID: <00ee01c2423b$bdd12820$611c08d9@kewlio.net> This is a multi-part message in MIME format. ------=_NextPart_000_00EA_01C24244.1F2939C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, 2001:610::/35 is not in our routing table from any peer. We're seeing 2001:610::/32 from the following: --cut-- BGP routing table entry for 2001:610::/32 Paths: (3 available, best #3, table Default-IP-Routing-Table) Advertised to non peer-group peers: 3ffe:200:1:81::1 3ffe:1200:1002:1::f1 3ffe:4005:0:1::d 3ffe:4005:0:1::19 3ffe:4005:0:1::23 3ffe:4005:0:1::27 1654 8954 1103 3ffe:200:1:81::1 from 3ffe:200:1:81::1 (193.10.66.219) Origin IGP, localpref 100, valid, external Community: 24765:200 24765:2200 24765:7000 Last update: Mon Aug 12 13:44:10 2002 6726 1103 3ffe:4005:0:1::16 from 3ffe:4005:0:1::16 (80.71.6.94) Origin IGP, localpref 100, valid, internal Community: 24765:300 24765:1800 24765:8009 Last update: Sat Aug 10 18:18:25 2002 3265 1103 3ffe:4005::1 from 3ffe:4005::1 (62.24.229.120) (fe80::2d0:b7ff:fe49:b3cc) Origin IGP, localpref 100, valid, internal, best Community: 24765:100 24765:1800 24765:6010 Last update: Fri Aug 9 21:34:49 2002 --cut-- With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. ----- Original Message ----- From: "Jorgensen, Roger" To: "'Gert Doering'" ; "Wim Biemolt" Cc: <6bone@ISI.EDU> Sent: Monday, August 12, 2002 8:42 PM Subject: RE: [6bone] routing problem > Hi, > > We're geting the 2001:610::/35 from many of our peers, and > we're also seing the 2001:610::/32 from even more peers. > > Seems like the ghost bug is out there again... this is what > we see, and there are some common as path's in all of them, > > > BGP routing table entry for 2001:610::/35, version 95785 > Paths: (26 available, best #21, table Global-IPv6-Table) > Advertised to non peer-group peers: > 2001:6C8:0:FFFD::12 2001:730::1:1 2001:730::1:3 2001:730::1:5 > 2001:730::1:7 > 2001:730::1:F 2001:730::1:15 2001:730::1:19 2001:730::1:1D > 2001:730::1:21 > 2001:730::1:23 2001:730::1:29 2001:730::1:2F 2001:730::1:31 > 2001:730::1:33 > 2001:730::1:35 2001:730::1:37 2001:730::1:39 2001:730::1:3B > 2001:730::1:3F > 2001:730::1:41 2001:730:0:2::AAE2 2001:740:0:102::1:0 2001:768:E:24::1 > 2001:778:11:4::2 2001:7F8:2:800F::2 3FFE:2000:0:40F::22F > 3FFE:2501:100::21 > 3FFE:2900:1:5::1 3FFE:4006:0:3::11 3FFE:4008:1::D 3FFE:81F1:1:2022::1 > 3FFE:8270:0:1::52 > 2012 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242) > 2001:730::1:33 from 2001:730::1:33 (193.224.190.128) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 2012:200 2012:513 6830:60003 6830:60011 > 2012 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242), (received-only) > 2001:730::1:33 from 2001:730::1:33 (193.224.190.128) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 2012:200 2012:513 > 790 3274 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242) > 2001:730::1:7 from 2001:730::1:7 (193.94.250.58) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 6830:60003 6830:60011 > 790 3274 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242), (received-only) > 2001:730::1:7 from 2001:730::1:7 (193.94.250.58) > Origin IGP, localpref 100, valid, external, atomic-aggregate > 559 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242) > 3FFE:2000:0:40F::22F from 3FFE:2000:0:40F::22F (130.59.32.38) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 6830:60003 6830:60011 > 559 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242), (received-only) > 3FFE:2000:0:40F::22F from 3FFE:2000:0:40F::22F (130.59.32.38) > Origin IGP, localpref 100, valid, external, atomic-aggregate > 3292 109 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242) > 2001:6C8:0:FFFD::12 from 2001:6C8:0:FFFD::12 (195.249.8.172) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 6830:60003 6830:60011 > 3292 109 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242), (received-only) > 2001:6C8:0:FFFD::12 from 2001:6C8:0:FFFD::12 (195.249.8.172) > Origin IGP, localpref 100, valid, external, atomic-aggregate > 6726 24765 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242) > 2001:730::1:19 from 2001:730::1:19 (80.84.236.164) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 6830:60003 6830:60011 > 6726 24765 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242), (received-only) > 2001:730::1:19 from 2001:730::1:19 (80.84.236.164) > Origin IGP, localpref 100, valid, external, atomic-aggregate > 8758 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242) > 3FFE:4006:0:3::11 from 3FFE:4006:0:3::11 (212.25.27.46) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 6830:60003 6830:60011 24765:200 24765:800 24765:3500 > 24765:7005 > 8758 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242), (received-only) > 3FFE:4006:0:3::11 from 3FFE:4006:0:3::11 (212.25.27.46) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 24765:200 24765:800 24765:3500 24765:7005 > 8973 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242) > 3FFE:4008:1::D from 3FFE:4008:1::D (192.16.124.2) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 6830:60003 6830:60011 > 8973 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242), (received-only) > 3FFE:4008:1::D from 3FFE:4008:1::D (192.16.124.2) > Origin IGP, localpref 100, valid, external, atomic-aggregate > 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242) > 3FFE:2900:1:5::1 from 3FFE:2900:1:5::1 (208.19.223.30) > Origin IGP, metric 0, localpref 100, valid, external, > atomic-aggregate > Community: 6830:60003 6830:60011 > 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242), (received-only) 3FFE:2900:1:5::1 from > 3FFE:2900:1:5::1 (208.19.223.30) > Origin IGP, metric 0, localpref 100, valid, external, > atomic-aggregate > 20834 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242) > 3FFE:8270:0:1::52 from 3FFE:8270:0:1::52 (80.71.0.50) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 6830:60003 6830:60011 > 20834 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242), (received-only) > 3FFE:8270:0:1::52 from 3FFE:8270:0:1::52 (80.71.0.50) > Origin IGP, localpref 100, valid, external, atomic-aggregate > 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242) > 2001:730::1:F from 2001:730::1:F (192.168.1.12) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 6830:60003 6830:60011 > 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242), (received-only) > 2001:730::1:F from 2001:730::1:F (192.168.1.12) > Origin IGP, localpref 100, valid, external, atomic-aggregate > 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242) > 2001:730::1:9 from 2001:730::1:9 (163.162.170.129) > Origin IGP, localpref 100, valid, external, atomic-aggregate, best > Community: 6830:60003 6830:60011 > 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242), (received-only) > 2001:730::1:9 from 2001:730::1:9 (163.162.170.129) > Origin IGP, localpref 100, valid, external, atomic-aggregate > 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242) > 2001:768:E:24::1 from 2001:768:E:24::1 (195.143.108.166) > Origin IGP, localpref 100, valid, external, atomic-aggregate > Community: 6830:60003 6830:60011 > 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > 145.145.249.242), (received-only) > 2001:768:E:24::1 from 2001:768:E:24::1 (195.143.108.166) > Origin IGP, localpref 100, valid, external, atomic-aggregate > 12337 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242) > 2001:730::1:31 from 2001:730::1:31 (62.128.0.14) > Origin IGP, metric 10, localpref 100, valid, external, > atomic-aggregate > Community: 6830:60003 6830:60011 12337:6004 > 12337 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 145.145.249.242), (received-only) > 2001:730::1:31 from 2001:730::1:31 (62.128.0.14) > Origin IGP, metric 10, localpref 100, valid, external, > atomic-aggregate > Community: 12337:6004 > > > > --- > Roger Jorgensen (rjorgensen@upctechnology.com) > System Engineer @ engineering - UPC Technology > handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID > > > > -----Original Message----- > > From: Gert Doering [mailto:gert@space.net] > > Sent: Monday, August 12, 2002 9:20 PM > > To: Wim Biemolt > > Cc: 6bone@ISI.EDU > > Subject: Re: [6bone] routing problem > > > > > > Hi, > > > > (I am copying the 6bone mailing list back in, as I think this > > is a pretty > > generic problem - I hope you don't mind) > > > > On Mon, Aug 12, 2002 at 08:56:09PM +0200, Wim Biemolt wrote: > > > ==> From: Gert Doering > > > > > > > To clarify this: this is not an effect of "caching" of > > any sort. It's > > > > just plain buggy router implementations that don't handle > > withdrawals > > > > correctly. > > > > > > So I can only hope that a buggy router implementation also > > means a memory > > > leak or something like that causing them to reboot in the > > real near future? > > > > No. In our case, the /35 staid in the table until I finally > > managed to > > reach someone at Viagenie who cleared some sessions... the BT /35 got > > stuck at Chello, and after clearing their sessions, at Viagenie. > > > > > The only other option I see is switch back to our /35. We > > are using IPv6 > > > as production. > > > > So are we... > > > > > Being without any decent IPv6 connectivity for too long > > > won't do our case for IPv6 any good I'm afraid. > > > > No :-(( > > > > My recommendation would be to contact all your peers and > > check the different > > paths seen everywhere for "common tails". Then contact the > > AS(es) that you > > see in the first hop of the "common tail" (in your case, as > > far as I could > > see, Chello and this Japanese AS) and ask them to check their > > tables for > > the prefix, and preferably clear some BGP sessions (upstream and/or > > downstream). > > > > In the last case, clearing session at Chello and yelling at Viagenie > > helped... but as I said, this time, Viagenie hasn't been in > > the paths > > (yet?), but a new japanese AS that I haven't seen before. > > > > This takes some time, though (1-2 days). If you can't spend > > that time, > > you'll have to announce both the /32 and the /35, establish contact to > > the suspect ASes, withdraw the /35 again, and hope that you got the > > right ones. > > > > Feel free to contact me to get an "show bgp ipv6 ..." output > > from here. > > > > Gert Doering > > -- NetMaster > > -- > > Total number of prefixes smaller than registry allocations: > > 46871 (46631) > > > > SpaceNet AG Mail: netmaster@Space.Net > > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > > 80807 Muenchen Fax : +49-89-32356-299 > > > > _______________________________________________ > > 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 > ------=_NextPart_000_00EA_01C24244.1F2939C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIYzCCAnow ggHjoAMCAQICARcwDQYJKoZIhvcNAQEFBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTAyMDQxODE1MjkzN1oXDTIwMDQxMzE1MjkzN1owTjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdl b1RydXN0IEluYy4xJzAlBgNVBAMTHkdlb1RydXN0IFRydWUgQ3JlZGVudGlhbHMgQ0EgMjCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAspcspZISpYX/aJqWoYcSyyGqFby3OvsepRzLRU0ENDJR wJo7DwFpirRFOUQkTkKXsY6BQzX/CeCRrn9i4ny5gcXuI2JSyrSmDwobbwl52n5cPEbHGcebybWd KfAf8vvkxYUnTmDZPtt2ob5RNpJTeTiq9MpNCB/5G7Ocr1hEljcCAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgHGMB0GA1UdDgQWBBQig0tNIAIMMfR8WrAaTRXIeF0RSTAPBgNVHRMBAf8EBTADAQH/MB8G A1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA0GCSqGSIb3DQEBBQUAA4GBACmw3z+sLsLS fAfdECQJPfiZFzJzSPQKLwY7vHnNWH2lAKYECbtAFHBpdyhSPkrj3KghXeIJnKyMFjsK6xd1k1Yu wMXrauUH+HIDuZUg4okBwQbhBTqjjEdo/cCHILQsaLeU2kM+n5KKrpb0uvrHrocGffRMrWhz9zYB lxoq0/EEMIICgjCCAeugAwIBAgIBBDANBgkqhkiG9w0BAQQFADBTMQswCQYDVQQGEwJVUzEcMBoG A1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1c2lu ZXNzIENBLTEwHhcNOTkwNjIxMDQwMDAwWhcNMjAwNjIxMDQwMDAwWjBTMQswCQYDVQQGEwJVUzEc MBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1cmUgZUJ1 c2luZXNzIENBLTEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM4vGbwXt3fek6lfWg0XTzQa DJj0ItlZ1MRoRvC0NcWFAyDGr0WlIVFFQesWWDYyb+JQYmT5/VGcqiTZ9J2DKocKIdMSODRsjQBu WqDZQu4aIZX5UkxVWsUPOE9G+m34LjXWHXzr4vCwdYDIqROsvojvOm6rXyo4YgKwEnv+j6YDAgMB AAGjZjBkMBEGCWCGSAGG+EIBAQQEAwIABzAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFEp4 MlIR21kWNl7fwRQ2QGpHfEyhMB0GA1UdDgQWBBRKeDJSEdtZFjZe38EUNkBqR3xMoTANBgkqhkiG 9w0BAQQFAAOBgQB1W6ibAxHm6VZMzfmpTMANmvPMZWnmJXbMWbfWVMMdzZmsGd20hdXgPfxiIKeE S1hl8eL5lSE/9dR+WB5Hh1Q+WKG1tfgq73HnvMP2sUlG4tega+VWeponmHxGYhTnyfxuAxJ5gDgd SIKN/Bf+KpYrtWKmpj29f5JZzVoqgrI3eTCCA1swggLEoAMCAQICAxAAazANBgkqhkiG9w0BAQQF ADBOMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1 c3QgVHJ1ZSBDcmVkZW50aWFscyBDQSAyMB4XDTAyMDgwMTE4MjYzOVoXDTAzMDgxNTE4MjYzOVow ggERMT8wPQYDVQQLEzZDUFMgdGVybXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZSBsaWFiaWxp dHkgbGltaXRlZC4xPjA8BgNVBAsTNVNlZSBQdWJsaWMgUy9NSU1FIENQUyB3d3cuZ2VvdHJ1c3Qu Y29tL3Jlc291cmNlcy9DUFMuMSowKAYDVQQLEyFQaG9uZSBWYWxpZGF0aW9uIC0gNDQgNzk3MC02 MzMzMzMxKDAmBgNVBAsTH0VtYWlsIGFuZCBwaG9uZSB2YWxpZGF0ZWQgb25seS4xFjAUBgNVBAMT DURhbmllbCBBdXN0aW4xIDAeBgkqhkiG9w0BCQEWEWRhbmllbEBrZXdsaW8ubmV0MIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCnZ7IrV88D55wCg31dENNY6z1/ehvUcOxWC4sh5hJMgMXNefiR mXQiDD6iRESdk5UJ5usgZZr40ICYwlpjBUY6xBTe4LNLiC1UPVZ9uF3Z05CVgvgXEhvqC3p8WM3O sKYfGXL7k49xmBU9TvpkExdxSEYJoK4rK77qRFC5HuKcMwIDAQABo4GBMH8wEQYJYIZIAYb4QgEB BAQDAgWgMA4GA1UdDwEB/wQEAwIF4DA5BgNVHR8EMjAwMC6gLKAqhihodHRwOi8vY3JsLmdlb3Ry dXN0LmNvbS9jcmxzL2d0dGNjYTIuY3JsMB8GA1UdIwQYMBaAFCKDS00gAgwx9HxasBpNFch4XRFJ MA0GCSqGSIb3DQEBBAUAA4GBABslhvo5nWHvXY0xcGwSdigKcnAIgRiH8zlmbKYyWCf0+qwjEVbc 7wccsKNWNr3D007R66JZtCiktuuc6CBsuxBzsBVS4uEA8YUXM3XNJM4mgTFdUfG+SOQaN30E4xtF vgGqDTSea6Q0tz2TbA8Xb+YUhEO3tbU8ulXdWLX7TI4YMYIBuDCCAbQCAQEwVTBOMQswCQYDVQQG EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1c3QgVHJ1ZSBDcmVk ZW50aWFscyBDQSAyAgMQAGswCQYFKw4DAhoFAKCBujAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wMjA4MTIyMDA2MjZaMCMGCSqGSIb3DQEJBDEWBBShKJZttJnrk+01 Tpq+IR2+odDM9zBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCHTANBgkqhkiG9w0B AQEFAASBgI5R55knvSMlyjjTaK6671Xx0rStL7Re3rScLs8pjmNN0p7/gRiYdBsLYVVt1Ot16z+R uyNPP3/HIbh2gb74B30iuZ7hkZBBtB6cdnWxbrx2R5ZvyUUoPWYU/DU7/7xF4lchbSdS/XNUJUQE BHfSsjyjzZ1wbOsSYi4D7VrAFG5FAAAAAAAA ------=_NextPart_000_00EA_01C24244.1F2939C0-- From gert@space.net Mon Aug 12 21:16:08 2002 From: gert@space.net (Gert Doering) Date: Mon, 12 Aug 2002 22:16:08 +0200 Subject: [6bone] routing problem In-Reply-To: <002401c24239$930654f0$420d640a@unfix.org>; from jeroen@unfix.org on Mon, Aug 12, 2002 at 09:50:55PM +0200 References: <58898.1029178569@gigant.surfnet.nl> <002401c24239$930654f0$420d640a@unfix.org> Message-ID: <20020812221608.S27015@Space.Net> Hi, On Mon, Aug 12, 2002 at 09:50:55PM +0200, Jeroen Massar wrote: > There is one good way: find out the AS's who are 'bad' and depeer them > if they don't respond in x time. > This is just the same as for IPv4... Yes, peer pressure should help. Right now, I'm observing the following two paths (only two left - so things are moving): cisco25>sh bgp ipv6 2001:610::/35 | inc aggregated 3561 5511 2611 2200 2602 559 513 9264 7660 2500 4697 3748 1275 762 20834 1654 6342 45589 278 6939 3274 790 8627 517 8472 6830 6726 24765 13285 786 11537 145 293, (aggregated by 1103 145.145.249.242) 1930 13944 15982 3265 8954 13193 5410 5594 2200 9112 3320 680 1275 762 20834 1654 6342 45589 278 6939 3274 790 8627 517 8472 6830 6726 24765 13285 786 11537 145 293, (aggregated by 1103 145.145.249.242) it would be a good start if people stopped peering with 45589 - this AS number is unassigned and thould NEVER be used. Oh. Watching this - right this moment, the paths are changing rapidly, so I think some achievement has been made... Some minutes later... bingo: cisco25>sh bgp ipv6 2001:610::/35 % Network not in table cisco25> gone. Does anybody know more about *who* did something which got rid of this ghost? > PS: Gert.. did you put an extra page in your presentation saying TLA's > are moving to /32's? Not yet, but it's on the TODO list. It definitely belongs in there. > PS2: Gert, don't get a sunburn in Rhodos ;) I'll try to ;-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From sp@iphh.net Mon Aug 12 21:26:56 2002 From: sp@iphh.net (Sascha E. Pollok) Date: Mon, 12 Aug 2002 22:26:56 +0200 (CEST) Subject: [6bone] routing problem In-Reply-To: <00ee01c2423b$bdd12820$611c08d9@kewlio.net> Message-ID: Hey folks, while this is definitely funny: cr4.hamburg1#sh bgp ipv6 2001:610::/35 BGP routing table entry for 2001:610::/35, version 201014 Paths: (0 available, no best path) Flag: 0x820 Advertised to peer-groups: PEERS Isn't it? As you see, the cisco knows the path but does not know any paths towards the destination :-) -Sascha On Mon, 12 Aug 2002, Daniel Austin wrote: > Hi, > > 2001:610::/35 is not in our routing table from any peer. > We're seeing 2001:610::/32 from the following: > > --cut-- > BGP routing table entry for 2001:610::/32 > Paths: (3 available, best #3, table Default-IP-Routing-Table) > Advertised to non peer-group peers: > 3ffe:200:1:81::1 3ffe:1200:1002:1::f1 3ffe:4005:0:1::d 3ffe:4005:0:1::19 > 3ffe:4005:0:1::23 3ffe:4005:0:1::27 > 1654 8954 1103 > 3ffe:200:1:81::1 from 3ffe:200:1:81::1 (193.10.66.219) > Origin IGP, localpref 100, valid, external > Community: 24765:200 24765:2200 24765:7000 > Last update: Mon Aug 12 13:44:10 2002 > > 6726 1103 > 3ffe:4005:0:1::16 from 3ffe:4005:0:1::16 (80.71.6.94) > Origin IGP, localpref 100, valid, internal > Community: 24765:300 24765:1800 24765:8009 > Last update: Sat Aug 10 18:18:25 2002 > > 3265 1103 > 3ffe:4005::1 from 3ffe:4005::1 (62.24.229.120) > (fe80::2d0:b7ff:fe49:b3cc) > Origin IGP, localpref 100, valid, internal, best > Community: 24765:100 24765:1800 24765:6010 > Last update: Fri Aug 9 21:34:49 2002 > --cut-- > > > With Thanks, > > Daniel Austin, > Managing Director, > kewlio.net Limited. > > > ----- Original Message ----- > From: "Jorgensen, Roger" > To: "'Gert Doering'" ; "Wim Biemolt" > > Cc: <6bone@ISI.EDU> > Sent: Monday, August 12, 2002 8:42 PM > Subject: RE: [6bone] routing problem > > > > Hi, > > > > We're geting the 2001:610::/35 from many of our peers, and > > we're also seing the 2001:610::/32 from even more peers. > > > > Seems like the ghost bug is out there again... this is what > > we see, and there are some common as path's in all of them, > > > > > > BGP routing table entry for 2001:610::/35, version 95785 > > Paths: (26 available, best #21, table Global-IPv6-Table) > > Advertised to non peer-group peers: > > 2001:6C8:0:FFFD::12 2001:730::1:1 2001:730::1:3 2001:730::1:5 > > 2001:730::1:7 > > 2001:730::1:F 2001:730::1:15 2001:730::1:19 2001:730::1:1D > > 2001:730::1:21 > > 2001:730::1:23 2001:730::1:29 2001:730::1:2F 2001:730::1:31 > > 2001:730::1:33 > > 2001:730::1:35 2001:730::1:37 2001:730::1:39 2001:730::1:3B > > 2001:730::1:3F > > 2001:730::1:41 2001:730:0:2::AAE2 2001:740:0:102::1:0 2001:768:E:24::1 > > 2001:778:11:4::2 2001:7F8:2:800F::2 3FFE:2000:0:40F::22F > > 3FFE:2501:100::21 > > 3FFE:2900:1:5::1 3FFE:4006:0:3::11 3FFE:4008:1::D 3FFE:81F1:1:2022::1 > > 3FFE:8270:0:1::52 > > 2012 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242) > > 2001:730::1:33 from 2001:730::1:33 (193.224.190.128) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 2012:200 2012:513 6830:60003 6830:60011 > > 2012 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242), (received-only) > > 2001:730::1:33 from 2001:730::1:33 (193.224.190.128) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 2012:200 2012:513 > > 790 3274 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242) > > 2001:730::1:7 from 2001:730::1:7 (193.94.250.58) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 790 3274 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242), (received-only) > > 2001:730::1:7 from 2001:730::1:7 (193.94.250.58) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 559 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242) > > 3FFE:2000:0:40F::22F from 3FFE:2000:0:40F::22F (130.59.32.38) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 559 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242), (received-only) > > 3FFE:2000:0:40F::22F from 3FFE:2000:0:40F::22F (130.59.32.38) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 3292 109 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242) > > 2001:6C8:0:FFFD::12 from 2001:6C8:0:FFFD::12 (195.249.8.172) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 3292 109 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242), (received-only) > > 2001:6C8:0:FFFD::12 from 2001:6C8:0:FFFD::12 (195.249.8.172) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 6726 24765 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242) > > 2001:730::1:19 from 2001:730::1:19 (80.84.236.164) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 6726 24765 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242), (received-only) > > 2001:730::1:19 from 2001:730::1:19 (80.84.236.164) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 8758 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242) > > 3FFE:4006:0:3::11 from 3FFE:4006:0:3::11 (212.25.27.46) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 24765:200 24765:800 24765:3500 > > 24765:7005 > > 8758 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242), (received-only) > > 3FFE:4006:0:3::11 from 3FFE:4006:0:3::11 (212.25.27.46) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 24765:200 24765:800 24765:3500 24765:7005 > > 8973 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242) > > 3FFE:4008:1::D from 3FFE:4008:1::D (192.16.124.2) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 8973 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242), (received-only) > > 3FFE:4008:1::D from 3FFE:4008:1::D (192.16.124.2) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242) > > 3FFE:2900:1:5::1 from 3FFE:2900:1:5::1 (208.19.223.30) > > Origin IGP, metric 0, localpref 100, valid, external, > > atomic-aggregate > > Community: 6830:60003 6830:60011 > > 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242), (received-only) 3FFE:2900:1:5::1 from > > 3FFE:2900:1:5::1 (208.19.223.30) > > Origin IGP, metric 0, localpref 100, valid, external, > > atomic-aggregate > > 20834 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242) > > 3FFE:8270:0:1::52 from 3FFE:8270:0:1::52 (80.71.0.50) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 20834 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242), (received-only) > > 3FFE:8270:0:1::52 from 3FFE:8270:0:1::52 (80.71.0.50) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242) > > 2001:730::1:F from 2001:730::1:F (192.168.1.12) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242), (received-only) > > 2001:730::1:F from 2001:730::1:F (192.168.1.12) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242) > > 2001:730::1:9 from 2001:730::1:9 (163.162.170.129) > > Origin IGP, localpref 100, valid, external, atomic-aggregate, best > > Community: 6830:60003 6830:60011 > > 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242), (received-only) > > 2001:730::1:9 from 2001:730::1:9 (163.162.170.129) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242) > > 2001:768:E:24::1 from 2001:768:E:24::1 (195.143.108.166) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242), (received-only) > > 2001:768:E:24::1 from 2001:768:E:24::1 (195.143.108.166) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 12337 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242) > > 2001:730::1:31 from 2001:730::1:31 (62.128.0.14) > > Origin IGP, metric 10, localpref 100, valid, external, > > atomic-aggregate > > Community: 6830:60003 6830:60011 12337:6004 > > 12337 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > > 1103 145.145.249.242), (received-only) > > 2001:730::1:31 from 2001:730::1:31 (62.128.0.14) > > Origin IGP, metric 10, localpref 100, valid, external, > > atomic-aggregate > > Community: 12337:6004 > > > > > > > > --- > > Roger Jorgensen (rjorgensen@upctechnology.com) > > System Engineer @ engineering - UPC Technology > > handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID > > > > > > > -----Original Message----- > > > From: Gert Doering [mailto:gert@space.net] > > > Sent: Monday, August 12, 2002 9:20 PM > > > To: Wim Biemolt > > > Cc: 6bone@ISI.EDU > > > Subject: Re: [6bone] routing problem > > > > > > > > > Hi, > > > > > > (I am copying the 6bone mailing list back in, as I think this > > > is a pretty > > > generic problem - I hope you don't mind) > > > > > > On Mon, Aug 12, 2002 at 08:56:09PM +0200, Wim Biemolt wrote: > > > > ==> From: Gert Doering > > > > > > > > > To clarify this: this is not an effect of "caching" of > > > any sort. It's > > > > > just plain buggy router implementations that don't handle > > > withdrawals > > > > > correctly. > > > > > > > > So I can only hope that a buggy router implementation also > > > means a memory > > > > leak or something like that causing them to reboot in the > > > real near future? > > > > > > No. In our case, the /35 staid in the table until I finally > > > managed to > > > reach someone at Viagenie who cleared some sessions... the BT /35 got > > > stuck at Chello, and after clearing their sessions, at Viagenie. > > > > > > > The only other option I see is switch back to our /35. We > > > are using IPv6 > > > > as production. > > > > > > So are we... > > > > > > > Being without any decent IPv6 connectivity for too long > > > > won't do our case for IPv6 any good I'm afraid. > > > > > > No :-(( > > > > > > My recommendation would be to contact all your peers and > > > check the different > > > paths seen everywhere for "common tails". Then contact the > > > AS(es) that you > > > see in the first hop of the "common tail" (in your case, as > > > far as I could > > > see, Chello and this Japanese AS) and ask them to check their > > > tables for > > > the prefix, and preferably clear some BGP sessions (upstream and/or > > > downstream). > > > > > > In the last case, clearing session at Chello and yelling at Viagenie > > > helped... but as I said, this time, Viagenie hasn't been in > > > the paths > > > (yet?), but a new japanese AS that I haven't seen before. > > > > > > This takes some time, though (1-2 days). If you can't spend > > > that time, > > > you'll have to announce both the /32 and the /35, establish contact to > > > the suspect ASes, withdraw the /35 again, and hope that you got the > > > right ones. > > > > > > Feel free to contact me to get an "show bgp ipv6 ..." output > > > from here. > > > > > > Gert Doering > > > -- NetMaster > > > -- > > > Total number of prefixes smaller than registry allocations: > > > 46871 (46631) > > > > > > SpaceNet AG Mail: netmaster@Space.Net > > > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > > > 80807 Muenchen Fax : +49-89-32356-299 > > > > > > _______________________________________________ > > > 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 rfurda@best.ca Mon Aug 12 21:48:23 2002 From: rfurda@best.ca (rfurda@best.ca) Date: Mon, 12 Aug 2002 13:48:23 -0700 (PDT) Subject: [6bone] routing problem In-Reply-To: <00ee01c2423b$bdd12820$611c08d9@kewlio.net> References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D88F253@nlcbbms03> <00ee01c2423b$bdd12820$611c08d9@kewlio.net> Message-ID: <1029185303.3d581f173ff70@mail.best.ca> Hello, FUBAR sees 2001:610::/32 like this: Query:daemon.fubar.ca> show ipv6 bgp 2001:610::/32 BGP routing table entry for 2001:610::/32 Paths: (4 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 3ffe:c00:8023:10::1 3ffe:81a0:1000::11 3ffe:81a0:1000::37 24765 6726 1103 3ffe:81a0:1000::11 from 3ffe:81a0:1000::11 (80.71.6.94) Origin IGP, localpref 100, valid, external Community: 24765:300 24765:800 24765:1800 24765:8009 Last update: Sun Aug 11 08:17:44 2002 6939 3265 1103 3ffe:81a0:1000::15 from 3ffe:81a0:1000::15 (64.71.128.26) (fe80::4047:801a) Origin IGP, localpref 100, valid, external, best Last update: Sun Aug 11 08:17:43 2002 6435 6175 3549 1103 3ffe:81a0:1000::37 from 3ffe:81a0:1000::37 (64.65.64.152) (fe80::4041:4098) Origin IGP, localpref 100, valid, external Last update: Sun Aug 11 08:17:40 2002 109 6939 3265 1103 3ffe:c00:8023:10::1 from 3ffe:c00:8023:10::1 (128.107.240.254) (fe80::806b:f0fe) Origin IGP, localpref 100, valid, external Last update: Sun Aug 11 08:17:39 2002 Query:daemon.fubar.ca> show ipv6 bgp 2001:610::/35 % Network not in table a slightly modified zebra looking glass can be found @ http://6bone.best.ca/looking-glass to show FUBAR's view of the 6Bone. Richard > ----- Original Message ----- > From: "Jorgensen, Roger" > To: "'Gert Doering'" ; "Wim Biemolt" > > Cc: <6bone@ISI.EDU> > Sent: Monday, August 12, 2002 8:42 PM > Subject: RE: [6bone] routing problem > > > > Hi, > > > > We're geting the 2001:610::/35 from many of our peers, and > > we're also seing the 2001:610::/32 from even more peers. > > > > Seems like the ghost bug is out there again... this is what > > we see, and there are some common as path's in all of them, > > > > > > BGP routing table entry for 2001:610::/35, version 95785 > > Paths: (26 available, best #21, table Global-IPv6-Table) > > Advertised to non peer-group peers: > > 2001:6C8:0:FFFD::12 2001:730::1:1 2001:730::1:3 2001:730::1:5 > > 2001:730::1:7 > > 2001:730::1:F 2001:730::1:15 2001:730::1:19 2001:730::1:1D > > 2001:730::1:21 > > 2001:730::1:23 2001:730::1:29 2001:730::1:2F 2001:730::1:31 > > 2001:730::1:33 > > 2001:730::1:35 2001:730::1:37 2001:730::1:39 2001:730::1:3B > > 2001:730::1:3F > > 2001:730::1:41 2001:730:0:2::AAE2 2001:740:0:102::1:0 > 2001:768:E:24::1 > > 2001:778:11:4::2 2001:7F8:2:800F::2 3FFE:2000:0:40F::22F > > 3FFE:2501:100::21 > > 3FFE:2900:1:5::1 3FFE:4006:0:3::11 3FFE:4008:1::D > 3FFE:81F1:1:2022::1 > > 3FFE:8270:0:1::52 > > 2012 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 > > 145.145.249.242) > > 2001:730::1:33 from 2001:730::1:33 (193.224.190.128) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 2012:200 2012:513 6830:60003 6830:60011 > > 2012 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 > > 145.145.249.242), (received-only) > > 2001:730::1:33 from 2001:730::1:33 (193.224.190.128) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 2012:200 2012:513 > > 790 3274 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated > by > > 1103 145.145.249.242) > > 2001:730::1:7 from 2001:730::1:7 (193.94.250.58) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 790 3274 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated > by > > 1103 145.145.249.242), (received-only) > > 2001:730::1:7 from 2001:730::1:7 (193.94.250.58) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 559 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 > > 145.145.249.242) > > 3FFE:2000:0:40F::22F from 3FFE:2000:0:40F::22F (130.59.32.38) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 559 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 > > 145.145.249.242), (received-only) > > 3FFE:2000:0:40F::22F from 3FFE:2000:0:40F::22F (130.59.32.38) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 3292 109 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated > by > > 1103 145.145.249.242) > > 2001:6C8:0:FFFD::12 from 2001:6C8:0:FFFD::12 (195.249.8.172) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 3292 109 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated > by > > 1103 145.145.249.242), (received-only) > > 2001:6C8:0:FFFD::12 from 2001:6C8:0:FFFD::12 (195.249.8.172) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 6726 24765 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated > by > > 1103 145.145.249.242) > > 2001:730::1:19 from 2001:730::1:19 (80.84.236.164) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 6726 24765 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated > by > > 1103 145.145.249.242), (received-only) > > 2001:730::1:19 from 2001:730::1:19 (80.84.236.164) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 8758 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated > by > > 1103 145.145.249.242) > > 3FFE:4006:0:3::11 from 3FFE:4006:0:3::11 (212.25.27.46) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 24765:200 24765:800 24765:3500 > > 24765:7005 > > 8758 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated > by > > 1103 145.145.249.242), (received-only) > > 3FFE:4006:0:3::11 from 3FFE:4006:0:3::11 (212.25.27.46) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 24765:200 24765:800 24765:3500 24765:7005 > > 8973 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated > by > > 1103 145.145.249.242) > > 3FFE:4008:1::D from 3FFE:4008:1::D (192.16.124.2) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 8973 24765 4618 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated > by > > 1103 145.145.249.242), (received-only) > > 3FFE:4008:1::D from 3FFE:4008:1::D (192.16.124.2) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242) > > 3FFE:2900:1:5::1 from 3FFE:2900:1:5::1 (208.19.223.30) > > Origin IGP, metric 0, localpref 100, valid, external, > > atomic-aggregate > > Community: 6830:60003 6830:60011 > > 6175 10109 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242), (received-only) 3FFE:2900:1:5::1 from > > 3FFE:2900:1:5::1 (208.19.223.30) > > Origin IGP, metric 0, localpref 100, valid, external, > > atomic-aggregate > > 20834 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 > > 145.145.249.242) > > 3FFE:8270:0:1::52 from 3FFE:8270:0:1::52 (80.71.0.50) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 20834 513 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 > > 145.145.249.242), (received-only) > > 3FFE:8270:0:1::52 from 3FFE:8270:0:1::52 (80.71.0.50) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 > > 145.145.249.242) > > 2001:730::1:F from 2001:730::1:F (192.168.1.12) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 > > 145.145.249.242), (received-only) > > 2001:730::1:F from 2001:730::1:F (192.168.1.12) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242) > > 2001:730::1:9 from 2001:730::1:9 (163.162.170.129) > > Origin IGP, localpref 100, valid, external, atomic-aggregate, > best > > Community: 6830:60003 6830:60011 > > 5609 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by 1103 > > 145.145.249.242), (received-only) > > 2001:730::1:9 from 2001:730::1:9 (163.162.170.129) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 > > 145.145.249.242) > > 2001:768:E:24::1 from 2001:768:E:24::1 (195.143.108.166) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > Community: 6830:60003 6830:60011 > > 8379 6435 9264 7660 2500 4725 1752 6939 3425 1103, (aggregated by > 1103 > > 145.145.249.242), (received-only) > > 2001:768:E:24::1 from 2001:768:E:24::1 (195.143.108.166) > > Origin IGP, localpref 100, valid, external, atomic-aggregate > > 12337 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, > (aggregated by > > 1103 145.145.249.242) > > 2001:730::1:31 from 2001:730::1:31 (62.128.0.14) > > Origin IGP, metric 10, localpref 100, valid, external, > > atomic-aggregate > > Community: 6830:60003 6830:60011 12337:6004 > > 12337 15589 5609 9264 7660 2500 4725 1752 6939 3425 1103, > (aggregated by > > 1103 145.145.249.242), (received-only) > > 2001:730::1:31 from 2001:730::1:31 (62.128.0.14) > > Origin IGP, metric 10, localpref 100, valid, external, > > atomic-aggregate > > Community: 12337:6004 > > > > > > > > --- > > Roger Jorgensen (rjorgensen@upctechnology.com) > > System Engineer @ engineering - UPC Technology > > handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID > > > > > > > -----Original Message----- > > > From: Gert Doering [mailto:gert@space.net] > > > Sent: Monday, August 12, 2002 9:20 PM > > > To: Wim Biemolt > > > Cc: 6bone@ISI.EDU > > > Subject: Re: [6bone] routing problem > > > > > > > > > Hi, > > > > > > (I am copying the 6bone mailing list back in, as I think this > > > is a pretty > > > generic problem - I hope you don't mind) > > > > > > On Mon, Aug 12, 2002 at 08:56:09PM +0200, Wim Biemolt wrote: > > > > ==> From: Gert Doering > > > > > > > > > To clarify this: this is not an effect of "caching" of > > > any sort. It's > > > > > just plain buggy router implementations that don't handle > > > withdrawals > > > > > correctly. > > > > > > > > So I can only hope that a buggy router implementation also > > > means a memory > > > > leak or something like that causing them to reboot in the > > > real near future? > > > > > > No. In our case, the /35 staid in the table until I finally > > > managed to > > > reach someone at Viagenie who cleared some sessions... the BT /35 > got > > > stuck at Chello, and after clearing their sessions, at Viagenie. > > > > > > > The only other option I see is switch back to our /35. We > > > are using IPv6 > > > > as production. > > > > > > So are we... > > > > > > > Being without any decent IPv6 connectivity for too long > > > > won't do our case for IPv6 any good I'm afraid. > > > > > > No :-(( > > > > > > My recommendation would be to contact all your peers and > > > check the different > > > paths seen everywhere for "common tails". Then contact the > > > AS(es) that you > > > see in the first hop of the "common tail" (in your case, as > > > far as I could > > > see, Chello and this Japanese AS) and ask them to check their > > > tables for > > > the prefix, and preferably clear some BGP sessions (upstream and/or > > > downstream). > > > > > > In the last case, clearing session at Chello and yelling at > Viagenie > > > helped... but as I said, this time, Viagenie hasn't been in > > > the paths > > > (yet?), but a new japanese AS that I haven't seen before. > > > > > > This takes some time, though (1-2 days). If you can't spend > > > that time, > > > you'll have to announce both the /32 and the /35, establish contact > to > > > the suspect ASes, withdraw the /35 again, and hope that you got the > > > right ones. > > > > > > Feel free to contact me to get an "show bgp ipv6 ..." output > > > from here. > > > > > > Gert Doering > > > -- NetMaster > > > -- > > > Total number of prefixes smaller than registry allocations: > > > 46871 (46631) > > > > > > SpaceNet AG Mail: netmaster@Space.Net > > > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > > > 80807 Muenchen Fax : +49-89-32356-299 > > > > > > _______________________________________________ > > > 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 paitken@cisco.com Mon Aug 12 21:57:33 2002 From: paitken@cisco.com (Paul Aitken) Date: Mon, 12 Aug 2002 21:57:33 +0100 Subject: [6bone] routing problem References: Message-ID: <3D58213D.9070207@cisco.com> Sascha, > while this is definitely funny: > > cr4.hamburg1#sh bgp ipv6 2001:610::/35 > BGP routing table entry for 2001:610::/35, version 201014 > Paths: (0 available, no best path) > Flag: 0x820 > Advertised to peer-groups: > PEERS > > Isn't it? As you see, the cisco knows the path > but does not know any paths towards the destination :-) Then the clever thing to do would be to email some details to ipv6-support@cisco.com so we can check it out, eh? Gosh, it's a good thing some of us subscribe to this list, and of course we know exactly what sort of router you're using and what software version, right? Sigh. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From sp@iphh.net Mon Aug 12 22:06:10 2002 From: sp@iphh.net (Sascha E. Pollok) Date: Mon, 12 Aug 2002 23:06:10 +0200 (CEST) Subject: [6bone] routing problem In-Reply-To: <3D58213D.9070207@cisco.com> Message-ID: Hi Paul, after I checked again 5 minutes later the entry is gone. I believe this was just some strange sort of history entry right after the real evil geniuses fixed their ghost announcements. Anyway, this is a 7204 NPE-200 running 12.2(8)T5 (IP Plus) with 128megs of Ram. Just running BGP v6 neighbors and OSPF. Nothing special. Strange anyway, since withdrawn routes should immediately disappear and should not show up like this, eh? Good to know Cisco is actively reading users mailing-lists :-) Thanks Sascha > > cr4.hamburg1#sh bgp ipv6 2001:610::/35 > > BGP routing table entry for 2001:610::/35, version 201014 > > Paths: (0 available, no best path) > > Flag: 0x820 > > Advertised to peer-groups: > > PEERS > > > > Isn't it? As you see, the cisco knows the path > > but does not know any paths towards the destination :-) > > Then the clever thing to do would be to email some details to > ipv6-support@cisco.com so we can check it out, eh? > > Gosh, it's a good thing some of us subscribe to this list, and of course > we know exactly what sort of router you're using and what software > version, right? > > Sigh. > -- > Paul Aitken > IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX > > From michel@arneill-py.sacramento.ca.us Mon Aug 12 22:13:25 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 12 Aug 2002 14:13:25 -0700 Subject: [6bone] routing problem Message-ID: <2B81403386729140A3A899A8B39B046405E26D@server2000.arneill-py.sacramento.ca.us> > Paul Aitken > Then the clever thing to do would be to email some > details to ipv6-support@cisco.com so we can check > it out, eh? Gosh, it's a good thing some of us > subscribe to this list, and of course we know > exactly what sort of router you're using and what > software version, right? And maybe the clever thing to do for Cisco would be to understand that the reason people come here asking Cisco questions is because they are tired of dealing with Cisco support, or the lack of it thereof. Michel. From tvo@EnterZone.Net Mon Aug 12 22:31:19 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 12 Aug 2002 17:31:19 -0400 (EDT) Subject: [6bone] routing problem In-Reply-To: <20020812083144.GA23039@einstein.nlnetlabs.nl> Message-ID: Um, have you tried looking at the BGP paths perhaps to determine what the problem may be perhaps? This looks like a classic routing loop. (When will people stop using inferior BGP code?!) Beyond that, (hopefully the maintainers are listening) *ANY* traceroute that doesn't show the actual ADDRESS for a hop, and not just the ip6.int/ip6.arpa record is useless. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On Mon, 12 Aug 2002 Ronald.vanderPol@rvdp.org wrote: > This morning, 6bone routing is working great again :-( > > My packets go all around the world, except where they are supposed to > go, a couple of kilometers away. > > $ traceroute6 kirk.rvdp.org > traceroute6 to kirk.rvdp.org (2001:610:508:1001::1) from 2001:6e0:206:1:220:edff > :fe19:4862, 30 hops max, 12 byte packets > 1 sixgate 0.465 ms 0.241 ms 0.201 ms > 2 Matrix1.core.ipv6.intouch.net 0.337 ms 0.32 ms 0.297 ms > 3 ams-cust.core.ipv6.intouch.net 0.719 ms 0.685 ms 0.662 ms > 4 edt-intouch.ipv6.edisontel.it 56.626 ms 57.222 ms 57.296 ms > 5 3ffe:8120::19:1 77.743 ms 77.648 ms 78.07 ms > 6 ::128.107.240.254 208.484 ms 208.147 ms 208.297 ms > 7 tunnel-stealth-lavanoc.lava.net 283.503 ms 3ffe:81d0:ffff:2::22 220.401 ms > 219.823 ms > 8 edt-hurricane.ipv6.edisontel.it 241.509 ms 2001:288:3b0::1e 410.271 ms 41 > 1.955 ms > 9 2001:288:3b0::1b 410.547 ms 411.804 ms 411.807 ms > 10 3ffe:8120::19:1 338.267 ms 337.184 ms 336.319 ms > 11 3ffe:8120::8:2 546.298 ms * 545.426 ms > 12 3ffe:c00:8023:2f::1 540.567 ms 540.827 ms ipv6-gw.ipv6.man.poznan.pl 276. > 96 ms > 13 3ffe:8320:1:: 438.038 ms 437.34 ms 436.39 ms > 14 3ffe:200:1:61::2 301.057 ms 2001:288:3b0::1e 686.372 ms 2001:7f8:2:8016::3 > 466.067 ms > 15 fe-tu0.pao.ipv6.he.net 592.915 ms 660.317 ms 635.527 ms > 16 3ffe:81d0:ffff:2::22 523.884 ms 473.015 ms 460.349 ms > 17 edt-hurricane.ipv6.edisontel.it 540.591 ms 484.15 ms 484.438 ms > 18 3ffe:8120::19:1 503.904 ms 503.959 ms 504.063 ms > 19 2001:288:3b0::2 836.366 ms 904.766 ms 944.527 ms > 20 2001:288:3b0::1f 835.769 ms 836.396 ms 837.633 ms > 21 2001:288:3b0::1e 999.56 ms 1006.61 ms 1003.31 ms > 22 2001:288:3b0::1b 836.865 ms 931.304 ms 836.235 ms > 23 3ffe:8140:101:5::3 835.866 ms 836.066 ms 837.62 ms > 24 pc6.otemachi.wide.ad.jp 836.719 ms 835.717 ms 835.182 ms > 25 * KOTsre01-101.nw.v6.odn.ne.jp 888.587 ms 891.257 ms > 26 STOsre01-201.nw.v6.odn.ne.jp 890.308 ms 964.177 ms 889.769 ms > 27 2001:7f8:2:8016::3 889.739 ms 889.598 ms 889.922 ms > 28 fe-tu0.pao.ipv6.he.net 887.98 ms 889.919 ms 886.22 ms > 29 3ffe:81d0:ffff:2::22 887.853 ms 885.344 ms 885.198 ms > 30 edt-hurricane.ipv6.edisontel.it 958.517 ms 909.741 ms 907.426 ms > $ > > rvdp > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From tvo@EnterZone.Net Mon Aug 12 22:34:22 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 12 Aug 2002 17:34:22 -0400 (EDT) Subject: [6bone] routing problem In-Reply-To: <57898.1029157534@gigant.surfnet.nl> Message-ID: This is real simple. If someone is running a BGP daemon that has problems, and refuses to replace it, refuse to peer/drop peering with them. Problem solved. Many of you are probably screaming, "But that breaks my peering to ZZZ!!!" Well, which is more broken? No peer or a peer who sends you (and all of it's other peers) invalid routes and causes routing loops? --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On Mon, 12 Aug 2002, Wim Biemolt wrote: > > > ==> From: Ronald.vanderPol@rvdp.org > > > This morning, 6bone routing is working great again :-( > > > > My packets go all around the world, except where they are supposed to > > go, a couple of kilometers away. > > We are trying hard to get rid of the advertisements for our /35 > after migrating to /32. Seems more difficult that expected. But > after that your routing problem should probably be gone. > > -Wim -/- SURFnet > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From tvo@EnterZone.Net Mon Aug 12 22:38:58 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 12 Aug 2002 17:38:58 -0400 (EDT) Subject: [6bone] routing problem In-Reply-To: <1029160080.1354.76.camel@wks1-1.corp.ndsoftware.com> Message-ID: On 12 Aug 2002, Nicolas DEFFAYET wrote: > Many routers keep in cache and reannonce 2001:610::/35 that Surfnet > don't announce. Bull$hit! Too many people are running inferior BGP implementations is more lime it. There is NO SUCH THING as "cache" in the BGP specification. If someone is running broken code, it should be fixed/replaced. If they don't, their peers should filter them, period the end. If not, they (and their peers) should not be surprised to find themselfs filtered by those of us who *do* care about routing stability. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From paitken@cisco.com Mon Aug 12 22:43:28 2002 From: paitken@cisco.com (Paul Aitken) Date: Mon, 12 Aug 2002 22:43:28 +0100 Subject: [6bone] routing problem References: Message-ID: <3D582C00.7090609@cisco.com> Sascha, > Anyway, this is a 7204 NPE-200 running 12.2(8)T5 (IP Plus) > with 128megs of Ram. Just running BGP v6 neighbors > and OSPF. Nothing special. I'll just write that down in my little black book just in case you report another oddity to the list without telling us... > Strange anyway, since withdrawn routes should immediately > disappear and should not show up like this, eh? Yup. > Good to know Cisco is actively reading users > mailing-lists :-) Well, I am :-) -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From Robert.Kiessling@de.easynet.net Mon Aug 12 23:30:32 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 12 Aug 2002 23:30:32 +0100 Subject: [6bone] routing problem In-Reply-To: <002401c24239$930654f0$420d640a@unfix.org> References: <002401c24239$930654f0$420d640a@unfix.org> Message-ID: "Jeroen Massar" writes: > There is one good way: find out the AS's who are 'bad' and depeer them > if they don't respond in x time. This is easier said than done. How do you find this out definitively? Depeering is a big hammer, and you should be sure before you ask for this. I'm currently trying to collect information about this, but I'm not in a position to point fingers to a sinner. Robert From paitken@cisco.com Mon Aug 12 23:33:35 2002 From: paitken@cisco.com (Paul Aitken) Date: Mon, 12 Aug 2002 23:33:35 +0100 Subject: [6bone] routing problem References: <2B81403386729140A3A899A8B39B046405E26D@server2000.arneill-py.sacramento.ca.us> Message-ID: <3D5837BF.8000906@cisco.com> Michel, > And maybe the clever thing to do for Cisco would be to understand that > the reason people come here asking Cisco questions is because they are > tired of dealing with Cisco support, or the lack of it thereof. Well I'm sorry if at any time you've felt let down by Cisco Support. While I can't speak for Cisco TAC, I believe that we, ipv6-support@cisco.com, do a very good job of trying to understand each individual user's unique situation and work with them to resolve whatever issues they're facing. ipv6-support typically receives around 25 customer emails a week, including requests for information, tunnel requests, feature requests and bug reports. Considering that we're not Cisco TAC, we're not a call centre, we (allegedly) don't work 24 x 7 (although it's 11.30pm here in Scotland), we're a small team and we actually have real development work to do, I think it's amazing that we somehow find the time to help customers individually. I don't know many other companies that offer direct access to their development engineers. In fact, I know some who charge a lot of money for that sort of service. So please, read the signature below carefully. I'm not a TAC engineer, I'm a software engineer working on IPv6 development. Cisco ipv6-support is not Cisco TAC. We're a small group of engineers who are enthusiastic about developing IPv6 solutions, and we'll do our very best to help you with any IPv6 problems. Cheers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From tvo@EnterZone.Net Mon Aug 12 23:48:46 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 12 Aug 2002 18:48:46 -0400 (EDT) Subject: [6bone] routing problem In-Reply-To: Message-ID: You contact the peering contacts in the AS-PATH. A simple "soft clear" on their router will show if THEY are the problem or if it is upstream from them. You move upstream until you find the problem AS(s). If they don't respond or refuse to correct the issue, you depeer them or request that their peers do so. If the peer in question is running unsupported, OLD, OLD, OLD bgp code, please let the list know. Save the rest of us the problem of peering with someone who refuses to step into the present and continues to run code that is known to cause problems. Speaking of which, EnterZone is getting ready to de-peer a few folks if they don't respond to our MULTIPLE emails to their peering contacts. If you're a peer of EnterZone and you have received an email/responded to an email from us in the past week, it is in your best (peering) interest to contact us, otherwise, you'll feel kinda silly when our NOC tells you ther reason the peering session is down is because you failed to respond to our contact attempts and we depeered you for that reason. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On 12 Aug 2002, Robert Kiessling wrote: > "Jeroen Massar" writes: > > > There is one good way: find out the AS's who are 'bad' and depeer them > > if they don't respond in x time. > > This is easier said than done. How do you find this out definitively? > > Depeering is a big hammer, and you should be sure before you ask for > this. > > I'm currently trying to collect information about this, but I'm not in > a position to point fingers to a sinner. > > Robert > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From jeroen@unfix.org Tue Aug 13 00:03:52 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Tue, 13 Aug 2002 01:03:52 +0200 Subject: [6bone] routing problem In-Reply-To: Message-ID: <003501c24254$8698eb90$420d640a@unfix.org> Robert Kiessling wrote: > "Jeroen Massar" writes: > > > There is one good way: find out the AS's who are 'bad' and depeer them > > if they don't respond in x time. > > This is easier said than done. How do you find this out definitively? > > Depeering is a big hammer, and you should be sure before you ask for this. True true. But the fact remains; if one doesn't reply to mail to the contact addresses specified in the whois. And one doesn't reply to phone calls, and/or doesn't even take the time to look into the issue they simply don't have any reason to be connected at all -> depeer. > I'm currently trying to collect information about this, but I'm not in > a position to point fingers to a sinner. http://dmoz.org/Computers/Internet/Protocols/IP/IPng/IPv6_Route_Views/ .... find the sinner ;) 8<--- There are now 8 mortal sins: - pride - covetousness - lust - wrath - gluttony - envy - sloth - announcing bogus routes not belonging in the global routing table --->8 Greets, Jeroen From Wim.Biemolt@surfnet.nl Tue Aug 13 00:19:50 2002 From: Wim.Biemolt@surfnet.nl (Wim Biemolt) Date: Tue, 13 Aug 2002 01:19:50 +0200 Subject: [6bone] routing problem In-Reply-To: Your message of "Tue, 13 Aug 2002 01:03:52 +0200." <003501c24254$8698eb90$420d640a@unfix.org> Message-ID: <59496.1029194390@gigant.surfnet.nl> ==> From: "Jeroen Massar" > http://dmoz.org/Computers/Internet/Protocols/IP/IPng/IPv6_Route_Views/ > .... find the sinner ;) You probably will not find it under the link to SURFnet. It is out of order since we moved IPv6 connectivity from old Cisco 4500 left overs to our Cisco 12k routers. Probably should try to fix this. Will do. -Wim -/- SURFnet From jeroen@unfix.org Tue Aug 13 00:20:29 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Tue, 13 Aug 2002 01:20:29 +0200 Subject: [6bone] routing problem In-Reply-To: Message-ID: <003601c24256$d90acea0$420d640a@unfix.org> John Fraizer wrote: > Beyond that, (hopefully the maintainers are listening) *ANY* > traceroute > that doesn't show the actual ADDRESS for a hop, and not just the > ip6.int/ip6.arpa record is useless. At least Ronald will be able to reach his box now: jeroen@purgatory:~$ traceroute6 kirk.rvdp.org traceroute to kirk.rvdp.org (2001:610:508:1001::1) from 3ffe:8114:1000::27, 30 hops max, 16 byte packets 1 tunnel-026.ipng.nl (3ffe:8114:1000::26) 20.202 ms 19.486 ms 19.206 ms 2 Amsterdam.core.ipv6.intouch.net (2001:6e0::2) 19.753 ms 19.835 ms 20.22 ms 3 Gi1-2.BR1.Amsterdam1.surf.net (2001:7f8:1::a500:1103:1) 125.067 ms * 125.295 ms 4 PO12-0.CR1.Amsterdam1.surf.net (2001:610:16:6000::1) 125.293 ms * 125.795 ms 5 PO1-0.CR2.Amsterdam1.surf.net (2001:610:16::2) 124.887 ms * 127.649 ms 6 PO0-0.AR5.Utrecht1.surf.net (2001:610:16:3048::50) 126.705 ms * 203.777 ms 7 sursix.surfnet.nl (2001:610:1:6008::10) 127.48 ms 127.205 ms 126.575 ms 8 surrogate.ipv6.surfnet.nl (2001:610:508:110:200:cff:fe58:8522) 127.604 ms 128.475 ms 128.277 ms 9 kirk.rvdp.org (2001:610:508:1000::2) 162.757 ms 136.29 ms 145.077 ms 10 kirk.rvdp.org (2001:610:508:1001::1) 189.606 ms 138.011 ms 137.936 ms He uses the same uplink so the problem is gone for him. On 2001:6e0::2 we currently see: B>* 2001:610::/32 [20/0] via fe80::204:28ff:fe90:5c82, fxp1, 10:25:48 B>* 2001:610:240::/42 [20/0] via fe80::203:e3ff:fe58:63e1, fxp1, 3d15h11m That /42 is RIPE-NCC-IPv6. Also comparing this to the traceroute below, apparently our box received it from edison at that moment. I really like hop 6 though ;) jeroen@purgatory:~$ whois 128.107.240.254 Cisco Systems, Inc. (NET-LEWIS-PRNET1) 170 W. Tasman Dr. San Jose, CA 95134 US The path was: rvdp -> intouch -> intouch(1) -> edisontel -> cern -> cisco -> lavanet -> hurricane(1) -> tanic-tw -> wide-jp -> odn-jp(2) -> hurricane (1) Some boxes use the last assigned address as it's source. (2) hmmmm... We had some channel takeovers on IRCNet this weekend from there, those where v4 socks proxys though. Greets, Jeroen > On Mon, 12 Aug 2002 Ronald.vanderPol@rvdp.org wrote: > > > This morning, 6bone routing is working great again :-( > > > > My packets go all around the world, except where they are > supposed to > > go, a couple of kilometers away. > > > > $ traceroute6 kirk.rvdp.org > > traceroute6 to kirk.rvdp.org (2001:610:508:1001::1) from > 2001:6e0:206:1:220:edff > > :fe19:4862, 30 hops max, 12 byte packets > > 1 sixgate 0.465 ms 0.241 ms 0.201 ms > > 2 Matrix1.core.ipv6.intouch.net 0.337 ms 0.32 ms 0.297 ms > > 3 ams-cust.core.ipv6.intouch.net 0.719 ms 0.685 ms 0.662 ms > > 4 edt-intouch.ipv6.edisontel.it 56.626 ms 57.222 ms 57.296 ms > > 5 3ffe:8120::19:1 77.743 ms 77.648 ms 78.07 ms > > 6 ::128.107.240.254 208.484 ms 208.147 ms 208.297 ms > > 7 tunnel-stealth-lavanoc.lava.net 283.503 ms > 3ffe:81d0:ffff:2::22 220.401 ms > > 219.823 ms > > 8 edt-hurricane.ipv6.edisontel.it 241.509 ms > 2001:288:3b0::1e 410.271 ms 41 > > 1.955 ms > > 9 2001:288:3b0::1b 410.547 ms 411.804 ms 411.807 ms > > 10 3ffe:8120::19:1 338.267 ms 337.184 ms 336.319 ms > > 11 3ffe:8120::8:2 546.298 ms * 545.426 ms > > 12 3ffe:c00:8023:2f::1 540.567 ms 540.827 ms > ipv6-gw.ipv6.man.poznan.pl 276. > > 96 ms > > 13 3ffe:8320:1:: 438.038 ms 437.34 ms 436.39 ms > > 14 3ffe:200:1:61::2 301.057 ms 2001:288:3b0::1e 686.372 > ms 2001:7f8:2:8016::3 > > 466.067 ms > > 15 fe-tu0.pao.ipv6.he.net 592.915 ms 660.317 ms 635.527 ms > > 16 3ffe:81d0:ffff:2::22 523.884 ms 473.015 ms 460.349 ms > > 17 edt-hurricane.ipv6.edisontel.it 540.591 ms 484.15 ms > 484.438 ms > > 18 3ffe:8120::19:1 503.904 ms 503.959 ms 504.063 ms > > 19 2001:288:3b0::2 836.366 ms 904.766 ms 944.527 ms > > 20 2001:288:3b0::1f 835.769 ms 836.396 ms 837.633 ms > > 21 2001:288:3b0::1e 999.56 ms 1006.61 ms 1003.31 ms > > 22 2001:288:3b0::1b 836.865 ms 931.304 ms 836.235 ms > > 23 3ffe:8140:101:5::3 835.866 ms 836.066 ms 837.62 ms > > 24 pc6.otemachi.wide.ad.jp 836.719 ms 835.717 ms 835.182 ms > > 25 * KOTsre01-101.nw.v6.odn.ne.jp 888.587 ms 891.257 ms > > 26 STOsre01-201.nw.v6.odn.ne.jp 890.308 ms 964.177 ms 889.769 ms > > 27 2001:7f8:2:8016::3 889.739 ms 889.598 ms 889.922 ms > > 28 fe-tu0.pao.ipv6.he.net 887.98 ms 889.919 ms 886.22 ms > > 29 3ffe:81d0:ffff:2::22 887.853 ms 885.344 ms 885.198 ms > > 30 edt-hurricane.ipv6.edisontel.it 958.517 ms 909.741 ms > 907.426 ms > > $ From michel@arneill-py.sacramento.ca.us Tue Aug 13 03:45:14 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 12 Aug 2002 19:45:14 -0700 Subject: [6bone] routing problem Message-ID: <2B81403386729140A3A899A8B39B046405E270@server2000.arneill-py.sacramento.ca.us> Paul, You have no business coming on the 6bone mailing list or any IETF or public mailing list with the typical Cisco attitude that says "you should have asked us first". A good half of the 6bone mailing has more operational experience with Cisco routers than most of your team. I am sorry that you have to pay the consequences of TAC's incompetence, but I deal with one company (Cisco) not with individuals. Look at the email archives. Cisco is the only vendor with this attitude on public mailing lists. I warn you not to do this too often as I have a huge pile of documented dirty laundry with Cisco support that nor you neither your management wants to see washed publicly. Michel Py CCIE #6673. -----Original Message----- From: Paul Aitken [mailto:paitken@cisco.com] Sent: Monday, August 12, 2002 3:34 PM To: Michel Py Cc: 6bone@ISI.EDU Subject: Re: [6bone] routing problem Michel, > And maybe the clever thing to do for Cisco would be to understand that > the reason people come here asking Cisco questions is because they are > tired of dealing with Cisco support, or the lack of it thereof. Well I'm sorry if at any time you've felt let down by Cisco Support. While I can't speak for Cisco TAC, I believe that we, ipv6-support@cisco.com, do a very good job of trying to understand each individual user's unique situation and work with them to resolve whatever issues they're facing. ipv6-support typically receives around 25 customer emails a week, including requests for information, tunnel requests, feature requests and bug reports. Considering that we're not Cisco TAC, we're not a call centre, we (allegedly) don't work 24 x 7 (although it's 11.30pm here in Scotland), we're a small team and we actually have real development work to do, I think it's amazing that we somehow find the time to help customers individually. I don't know many other companies that offer direct access to their development engineers. In fact, I know some who charge a lot of money for that sort of service. So please, read the signature below carefully. I'm not a TAC engineer, I'm a software engineer working on IPv6 development. Cisco ipv6-support is not Cisco TAC. We're a small group of engineers who are enthusiastic about developing IPv6 solutions, and we'll do our very best to help you with any IPv6 problems. Cheers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From gert@space.net Tue Aug 13 08:03:56 2002 From: gert@space.net (Gert Doering) Date: Tue, 13 Aug 2002 09:03:56 +0200 Subject: [6bone] routing problem In-Reply-To: ; from Robert.Kiessling@de.easynet.net on Mon, Aug 12, 2002 at 11:30:32PM +0100 References: <002401c24239$930654f0$420d640a@unfix.org> Message-ID: <20020813090355.X27015@Space.Net> Hi, On Mon, Aug 12, 2002 at 11:30:32PM +0100, Robert Kiessling wrote: > "Jeroen Massar" writes: > > There is one good way: find out the AS's who are 'bad' and depeer them > > if they don't respond in x time. > > This is easier said than done. How do you find this out definitively? > > Depeering is a big hammer, and you should be sure before you ask for > this. > > I'm currently trying to collect information about this, but I'm not in > a position to point fingers to a sinner. Seconded. I haven't fully understood yet what really happens in these cases, and it's not always the same AS, which makes tracing harder. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From paitken@cisco.com Tue Aug 13 09:59:25 2002 From: paitken@cisco.com (Paul Aitken) Date: Tue, 13 Aug 2002 09:59:25 +0100 Subject: Cisco support (was [6bone] routing problem) References: <2B81403386729140A3A899A8B39B046405E270@server2000.arneill-py.sacramento.ca.us> Message-ID: <3D58CA6D.5080708@cisco.com> Michel, > You have no business coming on the 6bone mailing list or any IETF or > public mailing list with the typical Cisco attitude that says "you > should have asked us first". I didn't (and wouldn't!) say such a thing. What I did say was: » Then the clever thing to do would be to email some details to » ipv6-support@cisco.com so we can check it out, eh? which means that if anyone finds a problem or a bug in cisco kit, but doesn't tell cisco about it, there's no way we can help you so it's unlikely the bug will be fixed unless we find it during our own testing. By all means report it to your favourite mailing lists and ask whether anyone else has seen this issue, knows a workaround or has a solution - but certainly for IPv6 issues, the folks most likely to know about it and be able to test and fix it for you are cisco ipv6-support, don't you think? > A good half of the 6bone mailing has more operational experience with > Cisco routers than most of your team. I don't doubt that you folks have more operational experience. But we did write the software that you're using. > I am sorry that you have to pay the consequences of TAC's > incompetence, but I deal with one company (Cisco) not with > individuals. I understand that, and appologise if you feel let down by Cisco TAC. I'm sure they're doing their best, sometimes in difficult circumstances. > Look at the email archives. Cisco is the only vendor with this > attitude on public mailing lists. "Cisco" means thousands of individual people. It's regretable that any of them exhibit this unfortunate attitude, but I'm sure no company likes negative publicity. I can only speak for our IPv6 implementation, but for what it's worth, if you think cisco IPv6 sucks, if you have a problem with it, then by all means tell folks in public forums. But you know, we (cisco) can't do anything to help you unless and until you send us complete details. That's why I suggest that contacting us directly would be the best thing to do in the first place, as it would with any vendor. > I warn you not to do this too often Never have, never will. Please re-examine my original posting. It was an encouragement (to Sascha E. Pollok) to send details to us rather than a chastisement for posting publically as a first resort. > as I have a huge pile of documented dirty laundry with Cisco support > that nor you neither your management wants to see washed publicly. I'm sorry to hear that. Let me know whether you'd like to take this up with senior management and I'll see what I can do for you. Cheers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From JORDI PALET MARTINEZ" Message-ID: <007001c242b6$b6648fc0$8700000a@consulintel.es> Hi all, See my replies below. Regards, Jordi ----- Original Message ----- From: "Michel Py" To: "Bob Fink" ; "6BONE List" <6bone@mailman.isi.edu> Cc: "Jordi Palet Martinez" Sent: Monday, August 12, 2002 8:27 PM Subject: RE: [6bone] pTLA request by Euro6IX project for exchange experimentation - review closes 3 Sep 2002 > Jordi / Bob / 6boner, > > I have some specific questions about this: > > 1. Question regarding allocations/assignments within the Euro6IX pTLA: > > My understanding is that this pTLA would be used for IX infrastructure, > which means routers physically present in one of the IXes, links between > them, router loopbacks, common peering subnets, that kind of thing. Am I > correct? Not only for infrastructure, it will be used also to experiment the address delegation from IX to ISP's and direct attached customers. > > The question is: what block size are you planning on allocating to whom? > For example, are your planning on allocating a /48 to each IX, and let > the IX assign subnets to participants? Are you planning multiple levels > of aggregation (such as a /40 per country)? We will do some experimentation, but in principle we could follow /40 per country (nevertheless right now there is only a single IX per country in our project), and /48 for each IX, and so on for ISP's (including the project participants), customers, ... But in general, of course, we will like to plan multiples levels as much structured/hierarchical as possible. > > 2. Question about the consequences on the global IPv6 routing table. > > What will we see in the global routing table WRT the Euro6IX pTLA? The > question is actually more like what are the consequences if everyone > (except Euro6IX IXes peering between themselves) is applying the > "STRICT" route map that has been discussed recently. > > If all we shall see in the global routing table is the Euro6IX pTLA > aggregate, I am curious to know who will announce it, and if you plan to > have each IX announce it as a proxy/pseudo anycast route. We plan to announce only the pTLA from a single entity, as the project behaves as a single "entity" (or network or whatever you want to call it). The pTLA will be announced by the entity who receives it in behalf of the complete project. Anyway, in general, remember that this is a R&D project and we could try several approaches during the project life time, if it make sense. > > Thanks > Michel. > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From tvo@EnterZone.Net Tue Aug 13 15:54:21 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Tue, 13 Aug 2002 10:54:21 -0400 (EDT) Subject: [6bone] Problems at AS8002? Message-ID: Is Stealth having problems today? I notice that our peering session is down and "sh ipv6 bgp regexp 8002" shows all paths to 8002 as about 16 AS's long! It would appear that 8002's main peering router(s) are down and what I'm seeing are ghosts. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From JORDI PALET MARTINEZ" <1029180716.1358.263.camel@wks1-1.corp.ndsoftware.com> Message-ID: <00ec01c242db$a9106450$8700000a@consulintel.es> Hi Nicolas, See below. Regards, Jordi ----- Original Message ----- From: "Nicolas DEFFAYET" To: "Michel Py" Cc: "Bob Fink" ; "6BONE List" <6bone@mailman.isi.edu>; "Jordi PaletMartinez" Sent: Monday, August 12, 2002 9:31 PM Subject: RE: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 > On Mon, 2002-08-12 at 20:27, Michel Py wrote: > Michel / Jordi / Bob / 6boner, > > > I have some specific questions about this: > > > > 1. Question regarding allocations/assignments within the Euro6IX pTLA: > > > > My understanding is that this pTLA would be used for IX infrastructure, > > which means routers physically present in one of the IXes, links between > > them, router loopbacks, common peering subnets, that kind of thing. Am I > > correct? > > > > The question is: what block size are you planning on allocating to whom? > > For example, are your planning on allocating a /48 to each IX, and let > > the IX assign subnets to participants? Are you planning multiple levels > > of aggregation (such as a /40 per country)? > > Why IX don't use the Global IPv6 Internet Exchange Points Assignments > made by the RIR ? The main reason is that the Euro6IX project hasn't a legal entity, so can't receive from the RIR (RIPE) the prefix. The only way will be one of the Telcos to get it and provide to the project, and this has some commercial drawbacks. But there are some additional reasons. 1st, this is an R&D project, so it make sense to apply in the 6Bone. Also, it doesn't make sense to have a /48 from the complete network, while a single IX can already receive a /48 from the RIRs. The solution will be to ask for one /48 for each IX, but then we lose the "complete network" prefix concept, and couldn't be aggregated in a single one. > > > > > 2. Question about the consequences on the global IPv6 routing table. > > > > What will we see in the global routing table WRT the Euro6IX pTLA? The > > question is actually more like what are the consequences if everyone > > (except Euro6IX IXes peering between themselves) is applying the > > "STRICT" route map that has been discussed recently. > > > > If all we shall see in the global routing table is the Euro6IX pTLA > > aggregate, I am curious to know who will announce it, and if you plan to > > have each IX announce it as a proxy/pseudo anycast route. > > > > I think that it will be like the AMS-IX pTLA > (http://whois.6bone.net/cgi-bin/whois?ams-ix). More or less, but with the main difference that Euro6IX is not a single IX, but a network of IX's. > > Best regards, > > Nicolas DEFFAYET > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From joao@ripe.net Tue Aug 13 16:32:28 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Tue, 13 Aug 2002 17:32:28 +0200 Subject: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 In-Reply-To: <00ec01c242db$a9106450$8700000a@consulintel.es> References: <2B81403386729140A3A899A8B39B046405E26A@server2000.arneill-py.sacramento.c a.us> <1029180716.1358.263.camel@wks1-1.corp.ndsoftware.com> <00ec01c242db$a9106450$8700000a@consulintel.es> Message-ID: Hi 6bone'rs, a bit of this message got me thinking and I would really like some input from this group on the exact meaning and intention of R&D in the context of the 6bone. Is R&D in the context of the 6bone: A) R&D in new IPv6 protocol or transition mechanism features? B) R&D as experimentation in the context of deployment within an ISP or other network operator? C) R&D un-related to IPv6, such as work done at an R&D institution (University or corporate research center, for instance)? D) R&D related to applications which might benefit from using IPv6 as transport? Note: With these questions I am not questioning this particular case, just looking for clarification in the context of the 6Bone. At 17:11 +0200 13/8/02, JORDI PALET MARTINEZ wrote: ... >But there are some additional reasons. 1st, this is an R&D project, >so it make sense to apply in the 6Bone. Also, it doesn't make ... Regards, Joao From michel@arneill-py.sacramento.ca.us Tue Aug 13 16:48:57 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 13 Aug 2002 08:48:57 -0700 Subject: [6bone] pTLA request by Euro6IX project for exchange experimentation - review closes 3 Sep 2002 Message-ID: <2B81403386729140A3A899A8B39B046405E271@server2000.arneill-py.sacramento.ca.us> Bob /Jordi / 6boner, In the light of Jordi's reply, I am favorable to the request. However, I am not sure I read Bob correctly. > Bob Fink wrote: > I would also appreciate discussion of any considerations > that we should be aware of as a 6bone test project. Bob, do you consider Euro6IX to be a "special" pTLA? The point I am trying to make here is related to the Teredo request and the points that Thomas and myself brought back then. I was wondering if Euro6IX should be placed in the same situation. My line of thinking is that "special" requests need to have a "special" consequence on 6bone routing, which certainly applies to Teredo and geo addresses. However, in Euro6IX' case, I don't see what granting them a pTLA changes for my view of the routing table. Reading Joao's post that just came in, I think that it might be a good time to clarify/change the definition of pTLA and write the definition of "special purpose" 6bone block. Please keep this in mind when finishing the RIR proposal. Michel. From JORDI PALET MARTINEZ" <1029180716.1358.263.camel@wks1-1.corp.ndsoftware.com> <00ec01c242db$a9106450$8700000a@consulintel.es> Message-ID: <011a01c242e2$b86dc940$8700000a@consulintel.es> Hi Joao, all, The answer is A, B and D :-) Please, see some slides about the project and the IX concept at http://www.ipv6.or.kr/summit/presentation/III-2.pdf. Regards, Jordi ----- Original Message ----- From: "Joao Luis Silva Damas" To: <6bone@ISI.EDU> Sent: Tuesday, August 13, 2002 5:32 PM Subject: Re: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 > Hi 6bone'rs, > > a bit of this message got me thinking and I would really like some > input from this group on the exact meaning and intention of R&D in > the context of the 6bone. > > Is R&D in the context of the 6bone: > > A) R&D in new IPv6 protocol or transition mechanism features? > B) R&D as experimentation in the context of deployment within an ISP > or other network operator? > C) R&D un-related to IPv6, such as work done at an R&D institution > (University or corporate research center, for instance)? > D) R&D related to applications which might benefit from using IPv6 as > transport? > > Note: With these questions I am not questioning this particular case, > just looking for clarification in the context of the 6Bone. > > > At 17:11 +0200 13/8/02, JORDI PALET MARTINEZ wrote: > ... > > >But there are some additional reasons. 1st, this is an R&D project, > >so it make sense to apply in the 6Bone. Also, it doesn't make > ... > > Regards, > Joao > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From JORDI PALET MARTINEZ" Message-ID: <001e01c242e7$9b370cb0$8700000a@consulintel.es> Hi, Yes, this is one of the points that we consider. In our project, new business models will be developed, including new services in the IX. Of course, as you say, we see a model where the IX network can purchase/sell upstream, and this is not accepted by all the project partners, because the commercial implications. I believe the new services that can be offered, will compensate it, commercially speaking. But fortunately in the project the commercial issues are apart. Regards, Jordi ----- Original Message ----- From: "Arien Vijn" To: "JORDI PALET MARTINEZ" ; <6bone@ISI.EDU> Sent: Tuesday, August 13, 2002 6:25 PM Subject: Re: [6bone] pTLA request by Euro6IX project forexchangeexperimentation - review closes 3 Sep 2002 > Hi Jordi, > > On 13-08-2002 17:11PM, "JORDI PALET MARTINEZ" > wrote: > > [..] > > > > > More or less, but with the main difference that Euro6IX is not a single IX, > > but a network of IX's. > > Apart from the R&D and IPv6 aspects. What is the difference between Euro6IX > and a carrier? > > Exchange-based aggregation as described in RFC2374 does not work unless the > IXP provides (buys) upstream for all it's members. Which might not be > acceptable for many upstream providers. They might (will, I think) see this > as competition. Did you consider the competition aspects? > > Kind regards, Arien > > > -- > > Arien Vijn > Amsterdam Internet Exchange > http://www.ams-ix.net > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From arien+6bone@ams-ix.net Tue Aug 13 17:35:38 2002 From: arien+6bone@ams-ix.net (Arien Vijn) Date: Tue, 13 Aug 2002 18:35:38 +0200 Subject: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 In-Reply-To: <00ec01c242db$a9106450$8700000a@consulintel.es> Message-ID: Hi Jordi, On 13-08-2002 17:11PM, "JORDI PALET MARTINEZ" wrote: [..] > > More or less, but with the main difference that Euro6IX is not a single IX, > but a network of IX's. Apart from the R&D and IPv6 aspects. What is the difference between Euro6IX and a carrier? Exchange-based aggregation as described in RFC2374 does not work unless the IXP provides (buys) upstream for all it's members. Which might not be acceptable for many upstream providers. They might (will, I think) see this as competition. Did you consider the competition aspects? Kind regards, Arien -- Arien Vijn Amsterdam Internet Exchange http://www.ams-ix.net From fink@es.net Tue Aug 13 17:42:48 2002 From: fink@es.net (Bob Fink) Date: Tue, 13 Aug 2002 09:42:48 -0700 Subject: [6bone] pTLA request by Euro6IX project for exchange experimentation - review closes 3 Sep 2002 In-Reply-To: <2B81403386729140A3A899A8B39B046405E271@server2000.arneill- py.sacramento.ca.us> Message-ID: <5.1.0.14.0.20020813094047.0331afa0@imap2.es.net> Michel, At 08:48 AM 8/13/2002 -0700, Michel Py wrote: >Bob /Jordi / 6boner, > >In the light of Jordi's reply, I am favorable to the request. However, I >am not sure I read Bob correctly. > > > Bob Fink wrote: > > I would also appreciate discussion of any considerations > > that we should be aware of as a 6bone test project. > >Bob, do you consider Euro6IX to be a "special" pTLA? I don't, but someone else might see something we need to consider. >The point I am trying to make here is related to the Teredo request and >the points that Thomas and myself brought back then. I was wondering if >Euro6IX should be placed in the same situation. Again, I don't thinks so, but would like folks to have a chance to comment. >My line of thinking is that "special" requests need to have a "special" >consequence on 6bone routing, which certainly applies to Teredo and geo >addresses. > >However, in Euro6IX' case, I don't see what granting them a pTLA changes >for my view of the routing table. Agree. >Reading Joao's post that just came in, I think that it might be a good >time to clarify/change the definition of pTLA and write the definition >of "special purpose" 6bone block. Please keep this in mind when >finishing the RIR proposal. Don't understand what you have in mind here. Thanks, Bob From fink@es.net Tue Aug 13 17:43:55 2002 From: fink@es.net (Bob Fink) Date: Tue, 13 Aug 2002 09:43:55 -0700 Subject: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 In-Reply-To: References: <00ec01c242db$a9106450$8700000a@consulintel.es> <2B81403386729140A3A899A8B39B046405E26A@server2000.arneill-py.sacramento.c a.us> <1029180716.1358.263.camel@wks1-1.corp.ndsoftware.com> <00ec01c242db$a9106450$8700000a@consulintel.es> Message-ID: <5.1.0.14.0.20020813094253.0331abe8@imap2.es.net> At 05:32 PM 8/13/2002 +0200, Joao Luis Silva Damas wrote: >Hi 6bone'rs, > >a bit of this message got me thinking and I would really like some input >from this group on the exact meaning and intention of R&D in the context >of the 6bone. > >Is R&D in the context of the 6bone: > >A) R&D in new IPv6 protocol or transition mechanism features? Yes, both. >B) R&D as experimentation in the context of deployment within an ISP or >other network operator? Yes. >C) R&D un-related to IPv6, such as work done at an R&D institution >(University or corporate research center, for instance)? Nope. >D) R&D related to applications which might benefit from using IPv6 as >transport? Yes. >Note: With these questions I am not questioning this particular case, just >looking for clarification in the context of the 6Bone. Thanks, Bob From michel@arneill-py.sacramento.ca.us Tue Aug 13 18:14:18 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 13 Aug 2002 10:14:18 -0700 Subject: [6bone] pTLA request by Euro6IX project for exchange experimentation - review closes 3 Sep 2002 Message-ID: <2B81403386729140A3A899A8B39B046405E276@server2000.arneill-py.sacramento.ca.us> Bob, >> Michel Py wrote: >> The point I am trying to make here is related to the Teredo >> request and the points that Thomas and myself brought back >> then. I was wondering if Euro6IX should be placed in the same >> situation. > Bob Fink wrote: > Again, I don't thinks so, but would like folks to have a > chance to comment. Thanks for asking. In this specific case, I do not think that Euro6IX should be treated differently than any other pTLA as there are no consequences on the global routing table. >> Reading Joao's post that just came in, I think that it might >> be a good time to clarify/change the definition of pTLA and >> write the definition of "special purpose" 6bone block. Please >> keep this in mind when finishing the RIR proposal. > Don't understand what you have in mind here. As Jordi mentioned before (answering Nicolas' question), the reason Euro6IX did not get a prefix from their RIR is because they don't have a legal entity. This might become an issue when the 6bone goes into RIR's hands. Just my brain spinning freely, you might want to consider at least three categories of requests for the future 6bone/RIR: - pTLAs as we know them today. - Works like a pTLA (read: only one route in the global routing table) but without a legal entity, such as Euro6IX. - "Special purpose" such as geo addresses that need to be studied on a per-case basis. Note that one of the reasons I bring this legal entity issue is self-serving: I don't know what I would do if I needed one to send you the request for geo addresses that I am preparing ;-) Michel. From michel@arneill-py.sacramento.ca.us Tue Aug 13 18:46:37 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 13 Aug 2002 10:46:37 -0700 Subject: Cisco support (was [6bone] routing problem) Message-ID: <2B81403386729140A3A899A8B39B04640BCFE4@server2000.arneill-py.sacramento.ca.us> > Paul Aitken wrote: > "Cisco" means thousands of individual people. It's regrettable > that any of them exhibit this unfortunate attitude, but I'm > sure no company likes negative publicity. You don't get it, do you. What if individuals that happen to work for Microsoft came posting each time someone said "Microsoft sucks" on a public forum? Fortunately, Microsoft employees don't. This is not a place for vendors to try to convince the audience that they do not suck, and this applies to Cisco as well as everyone else. People that post here typically know what Cisco's IPv6 support email address is; if they feel like contacting Cisco support they will do it on their own and I say again that you have no business reminding it publicly to the list. Michel. From paitken@cisco.com Tue Aug 13 19:22:22 2002 From: paitken@cisco.com (Paul Aitken) Date: Tue, 13 Aug 2002 19:22:22 +0100 Subject: [6bone] Re: Cisco support References: <2B81403386729140A3A899A8B39B04640BCFE4@server2000.arneill-py.sacramento.ca.us> Message-ID: <3D594E5E.3010808@cisco.com> Michel, > You don't get it, do you. What if individuals that happen to work for > Microsoft came posting each time someone said "Microsoft sucks" on a > public forum? Sure, it'd be a pain. But if Microsoft had an email address for reporting IPv6 bugs that perhaps folks didn't know about, then I for one would sure like to know so I could send my report there in the hope that someone would look at it and maybe do something about it. (Well, I would if I used Windows). But, as far as I know - and I stand ready to be corrected here - Microsoft doesn't offer you the same level of direct access to their developers that Cisco does. Good for them if they do; I'd like to hear about it because sometimes folks as us (cisco) whether we know how to configure IPv6 stuff on a windows box. > People that post here typically know what Cisco's IPv6 support email > address is Possibly true, but interestingly enough we just received a few emails (some to me, some to ipv6-support) in the vein "well now I know who to ask, let me ask you this..." - which I think is great because instead of sitting out there completely stuck, folks now know a place they can ask their question and (I hope) receive a sensible answer. > if they feel like contacting Cisco support they will do it > on their own and I say again that you have no business reminding it > publicly to the list. Well, hopefully next time someone finds their cisco router doing something unusual IPv6 wise and posts here, some non-cisco person will say "hey, you know you can get right in touch with the guys that wrote that stuff and ask them about it". Cheers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From michel@arneill-py.sacramento.ca.us Tue Aug 13 20:03:27 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 13 Aug 2002 12:03:27 -0700 Subject: Cisco support (was [6bone] routing problem) Message-ID: <2B81403386729140A3A899A8B39B046405E277@server2000.arneill-py.sacramento.ca.us> > What kind of an attitude is this? Someone has a problem, > an employee of the vendor jumps in and offers to help them, > and you COMPLAIN? Employees of vendors have the same right > to participate on a mailing list as the rest of the world... > If someone offers to help, you should be glad! We have a word for this kind of people: Trolls. And they troll not to help, but because someone said something about their precious product being less than perfect, heaven forbid. > Hey folks, > while this is definitely funny: > cr4.hamburg1#sh bgp ipv6 2001:610::/35 > BGP routing table entry for 2001:610::/35, version 201014 > Paths: (0 available, no best path) > Flag: 0x820 > Advertised to peer-groups: > PEERS > Isn't it? As you see, the cisco knows the path > but does not know any paths towards the destination :-) > -Sascha Note that Sascha never asked for help. The only reason Cisco jumped in is to try to diffuse the consequences of a Cisco bug being posted to a public list. Just added to my personal troll list: paitken@cisco.com (No match for Jim Fleming, though). My, I hope they don't develop IPv8 together. Scary thought. Michel. From gert@space.net Tue Aug 13 20:50:44 2002 From: gert@space.net (Gert Doering) Date: Tue, 13 Aug 2002 21:50:44 +0200 Subject: Cisco support (was [6bone] routing problem) In-Reply-To: <2B81403386729140A3A899A8B39B04640BCFE4@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Tue, Aug 13, 2002 at 10:46:37AM -0700 References: <2B81403386729140A3A899A8B39B04640BCFE4@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020813215044.A27015@Space.Net> Hi, On Tue, Aug 13, 2002 at 10:46:37AM -0700, Michel Py wrote: > > Paul Aitken wrote: > > "Cisco" means thousands of individual people. It's regrettable > > that any of them exhibit this unfortunate attitude, but I'm > > sure no company likes negative publicity. > > You don't get it, do you. What if individuals that happen to work for > Microsoft came posting each time someone said "Microsoft sucks" on a > public forum? If those individuals offer technical advertise, and offer to actually work with you to *fix* those issues that are appearing, I will warmly welcome those Microsoft individuals. > Fortunately, Microsoft employees don't. This is not a place for vendors > to try to convince the audience that they do not suck, and this applies > to Cisco as well as everyone else. > > People that post here typically know what Cisco's IPv6 support email > address is; if they feel like contacting Cisco support they will do it > on their own and I say again that you have no business reminding it > publicly to the list. I disagree. The ipv6-support address is *not* well-known, unless you happen to be one of the Cisco IPv6 EFT beta testers (which I am, so I know about it) - I am sure that Sascha will appreciate the direct contact into Cisco IPv6 development. The fact that *you* seem to have a big problem with Cisco in general and every single person that works for Cisco doesn't mean everybody else agrees with you. I *want* vendor contacts that actually care about fixing things in their software or hardware. And I *want* vendor contacts to read *and write* on public mailing lists that happen to see problem reports about their stuff here and then. Be it Cisco, Juniper, everybody else. (Well, in this place "... as long as it is IPv6 related"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From vaxzilla@jarai.org Tue Aug 13 20:58:41 2002 From: vaxzilla@jarai.org (Brian Chase) Date: Tue, 13 Aug 2002 12:58:41 -0700 (PST) Subject: Cisco support (was [6bone] routing problem) In-Reply-To: <2B81403386729140A3A899A8B39B046405E277@server2000.arneill-py.sacramento.ca.us> Message-ID: Does using IPv6 often have a tendency to cause people to foam copiously at the mouth? As only a casual observer, with an interest in learning more about IPv6, my impression from recent list mailings is that its use causes an acute form madness, one which involves unnecessary ranting and verbal hostility. -brian. From pekkas@netcore.fi Tue Aug 13 22:10:48 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Wed, 14 Aug 2002 00:10:48 +0300 (EEST) Subject: Cisco support (was [6bone] routing problem) In-Reply-To: <2B81403386729140A3A899A8B39B046405E277@server2000.arneill-py.sacramento.ca.us> Message-ID: On Tue, 13 Aug 2002, Michel Py wrote: > Just added to my personal troll list: paitken@cisco.com > (No match for Jim Fleming, though). Some may have an entirely different opinion who was productive and who was not. -- 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 Tue Aug 13 23:52:59 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Wed, 14 Aug 2002 00:52:59 +0200 Subject: [6bone] Re: Cisco support In-Reply-To: <3D594E5E.3010808@cisco.com> Message-ID: <000d01c2431c$2c7537e0$850d640a@unfix.org> Paul Aitken wrote: > But, as far as I know - and I stand ready to be corrected here - > Microsoft doesn't offer you the same level of direct access to their > developers that Cisco does. Good for them if they do; I'd > like to hear about it because sometimes folks as us (cisco) whether we know how to > configure IPv6 stuff on a windows box. http://www.microsoft.com/ipv6/ http://research.microsoft.com/msripv6/ http://research.microsoft.com/msripv6/msripv6.htm Mailing List: We have a mailing list, msripv6-users@list.research.microsoft.com, for discussion among interested users of our implementation. To join the list, send mail to listserv@list.research.microsoft.com with the command subscribe msripv6-users yourfirstname yourlastname We also have an alias for bug reports: msripv6-bugs@list.research.microsoft.com. And that list works perfectly well http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp "Windows .NET Server and beyond - The next version of Windows will include the first fully-supported release of the Microsoft IPv6 stack." msripv6@microsoft.com All found on hs247.com ofcourse. BTW: Linux doesn't have a working IPsec6 by default, Windows has... so stop moaning all ;) And will everybody please stop throwing the bully ball over and concentrate on IPv6 again ? Greets, Jeroen From anarchyz@op3r.net Tue Aug 13 23:49:24 2002 From: anarchyz@op3r.net (temp) Date: Tue, 13 Aug 2002 15:49:24 -0700 Subject: [6bone] ipv6 question Message-ID: <5.1.0.14.0.20020813154534.00a9a880@k2.synapseglobal.com> I have a quick quesion, i setup tsp from (Freenet6) and ran it, then i got this . gif0: flags=8051 mtu 1280 tunnel inet my.wan.ip.bla (x.x.x.x) --> 206.123.31.114 inet6 fe80::250:daff:fe66:503b%gif0 prefixlen 64 scopeid 0x3 inet6 3ffe:b80:2:be15::2 --> 3ffe:b80:2:be15::1 prefixlen 128 so i assume that it was setup correctly, but i cannot ping my ipv6 addy above, so im not sure if its config'd properly or not. I think my router is blocking requests, because i am behind a rouer w/ NAT. And i think i can go into my router and edit the "static routing setup", something about a static route would fix this problem. Anyone got any easy solutions? I hope i made sense...... heres my routing setup that i believe i can edit to make this work Menu 12.1 - Edit IP Static Route Route #: 1 Route Name= ? Active= No Destination IP Address= ? IP Subnet Mask= ? Gateway IP Address= ? Metric= 2 Private= No From jon@jons.org Wed Aug 14 01:23:58 2002 From: jon@jons.org (Jon Christopherson) Date: Tue, 13 Aug 2002 17:23:58 -0700 Subject: Cisco support (was [6bone] routing problem) In-Reply-To: <20020813215044.A27015@Space.Net> Message-ID: <000801c24328$e2c947f0$19a14fc7@vile.com> Hello, On Tue, Aug 13, 2002 at 10:46:37AM -0700, Michel Py wrote: > > Paul Aitken wrote: > > "Cisco" means thousands of individual people. It's regrettable > > that any of them exhibit this unfortunate attitude, but I'm > > sure no company likes negative publicity. > > You don't get it, do you. What if individuals that happen to work for > Microsoft came posting each time someone said "Microsoft sucks" on a > public forum? [snip] ->I disagree. The ipv6-support address is *not* well-known, unless you ->happen to be one of the Cisco IPv6 EFT beta testers (which I am, so ->I know about it) - I am sure that Sascha will appreciate the direct ->contact into Cisco IPv6 development. I agree with your statements Gert. ->The fact that *you* seem to have a big problem with Cisco in general ->and every single person that works for Cisco doesn't mean everybody ->else agrees with you. ->I *want* vendor contacts that actually care about fixing things in their ->software or hardware. And I *want* vendor contacts to read *and write* ->on public mailing lists that happen to see problem reports about their ->stuff here and then. Be it Cisco, Juniper, everybody else. (Well, in ->this place "... as long as it is IPv6 related"). I am actually on the 6bone right now because of comments made by Paul on this list. I for one appreciate his input, even if it might have a Cisco ring to it. I have not seen much opposition to his input, but have seen it help at least a few people (that I know of). That is good enough for me. ->Gert Doering -> -- NetMaster ->-- Regards, -- Jon Christopherson 1526 580C 7D3F 1672 2290 9607 BE71 F972 8D03 1977 From michel@arneill-py.sacramento.ca.us Wed Aug 14 04:00:45 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 13 Aug 2002 20:00:45 -0700 Subject: Cisco support (was [6bone] routing problem) Message-ID: <2B81403386729140A3A899A8B39B046405E279@server2000.arneill-py.sacramento.ca.us> >> Paul Aitken wrote: >> Then the clever thing to do would be to email some details to >> ipv6-support@cisco.com so we can check it out, eh? >> Gosh, it's a good thing some of us subscribe to this list, >> and of course we know exactly what sort of router you're >> using and what software version, right? >> Sigh. > Gert Doering wrote: > And I *want* vendor contacts to read *and write* on > public mailing lists Oh I see. That must be the politically correct way to say that you want vendors that write shitty code to come trolling the mailing list and sarcastically explain that if their shitty code has bugs it's because of the users that did not report the bugs. I have news for you: when code has bugs, it's typically the result of the people that wrote that code and not the user's fault. Michel. From tvo@EnterZone.Net Wed Aug 14 05:45:29 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 00:45:29 -0400 (EDT) Subject: Cisco support (was [6bone] routing problem) In-Reply-To: <2B81403386729140A3A899A8B39B04640BCFE4@server2000.arneill-py.sacramento.ca.us> Message-ID: On Tue, 13 Aug 2002, Michel Py wrote: > > Paul Aitken wrote: > > "Cisco" means thousands of individual people. It's regrettable > > that any of them exhibit this unfortunate attitude, but I'm > > sure no company likes negative publicity. > > You don't get it, do you. What if individuals that happen to work for > Microsoft came posting each time someone said "Microsoft sucks" on a > public forum? > > Fortunately, Microsoft employees don't. This is not a place for vendors > to try to convince the audience that they do not suck, and this applies > to Cisco as well as everyone else. > > People that post here typically know what Cisco's IPv6 support email > address is; if they feel like contacting Cisco support they will do it > on their own and I say again that you have no business reminding it > publicly to the list. > > Michel. Michel, In every instance that I have had the pleasure of communicating with you prior to this, you have conducted yourself as a well mannered, intellectual individual. What makes this case different? In my opinion, Paul simply posted information in an attempt to help someone. Perhaps you have had some bad experience with Cisco in the past that has left you jaded against anyone with an @cisco.com email address. Please refrain from venting this against someone who was obviously simply trying to help. You state that that Paul "has no business publicly reminding it to the list" referring to his posting the cisco IPv6 support email address. I beg to differ. I think that it is refreshing to see someone from [insert ANY router vendor here] who is active and attentive in a public mailing list. Since Paul works in the Cisco IPv6 world, and obviously felt that he could help, he posted as such. I can't count the number of times that I've seen prople from Vendor C, F and J go running for cover on NANOG when someone posted a problem that might be a bug in their code. Again, you have in all previous cases, presented yourself as a professional, curtious, intellectual individual. What about Paul offering assistance prompted you to make an ass of yourself this time? If you don't like Cisco, that's just fine. The rest of the 6bone community doesn't need to see you vent at Paul over that. I know that I for one am both disappointed and tired of it. Grow up. --- 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 Aug 14 06:04:35 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 01:04:35 -0400 (EDT) Subject: Cisco support (was [6bone] routing problem) In-Reply-To: <2B81403386729140A3A899A8B39B046405E277@server2000.arneill-py.sacramento.ca.us> Message-ID: On Tue, 13 Aug 2002, Michel Py wrote: > > What kind of an attitude is this? Someone has a problem, > > an employee of the vendor jumps in and offers to help them, > > and you COMPLAIN? Employees of vendors have the same right > > to participate on a mailing list as the rest of the world... > > If someone offers to help, you should be glad! > > We have a word for this kind of people: Trolls. And they troll not to > help, but because someone said something about their precious product > being less than perfect, heaven forbid. Watch using that word "we" Michel. Someone who reads this thread in the archive might very well group *me* into that pronoun. I believe you're being a a bit pretentious here. > > > Hey folks, > > while this is definitely funny: > > cr4.hamburg1#sh bgp ipv6 2001:610::/35 > > BGP routing table entry for 2001:610::/35, version 201014 > > Paths: (0 available, no best path) > > Flag: 0x820 > > Advertised to peer-groups: > > PEERS > > Isn't it? As you see, the cisco knows the path > > but does not know any paths towards the destination :-) > > -Sascha > > Note that Sascha never asked for help. The only reason Cisco jumped in > is to try to diffuse the consequences of a Cisco bug being posted to a > public list. > Oh good friggin' grief! If they hadn't jumped in and offered to help, you would complain about their lack of support. They jump in (and I commend them for doing so) and you jump their $h!t? Good God, man. Get a life. > Just added to my personal troll list: paitken@cisco.com Just added to my dropped peers list: AS23169 I want no direct or perceived association with anyone so asinine. > (No match for Jim Fleming, though). Actually, I think you're quite the equal of Jim, perhaps even more of a kook based on todays rantings. Happy blackholes, --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From gert@space.net Wed Aug 14 07:54:42 2002 From: gert@space.net (Gert Doering) Date: Wed, 14 Aug 2002 08:54:42 +0200 Subject: Cisco support (was [6bone] routing problem) In-Reply-To: <2B81403386729140A3A899A8B39B046405E279@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Tue, Aug 13, 2002 at 08:00:45PM -0700 References: <2B81403386729140A3A899A8B39B046405E279@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020814085442.M27015@Space.Net> Hi, On Tue, Aug 13, 2002 at 08:00:45PM -0700, Michel Py wrote: > Oh I see. That must be the politically correct way to say that you want > vendors that write shitty code to come trolling the mailing list and > sarcastically explain that if their shitty code has bugs it's because of > the users that did not report the bugs. > > I have news for you: when code has bugs, it's typically the result of > the people that wrote that code and not the user's fault. Maybe it's time to learn some facts of life: all software has bugs. The difference is how the people that are responsible for them handle bug reports and go fixing them. What was the major software package that you wrote recently that has no single bug? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From joao@ripe.net Wed Aug 14 08:23:33 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Wed, 14 Aug 2002 09:23:33 +0200 Subject: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 In-Reply-To: <5.1.0.14.0.20020813094253.0331abe8@imap2.es.net> References: <00ec01c242db$a9106450$8700000a@consulintel.es> <2B81403386729140A3A899A8B39B046405E26A@server2000.arneill-py.sacramento.c a.us> <1029180716.1358.263.camel@wks1-1.corp.ndsoftware.com> <00ec01c242db$a9106450$8700000a@consulintel.es> <5.1.0.14.0.20020813094253.0331abe8@imap2.es.net> Message-ID: I see, in that case I guess we better start creating the 4Bone, for newvie ISPs in IPv4 and people developing new applications that benefit from IPv4 transport. Come on, these two cases were OK up to the point where people could not get any other type of IPv6 addresses but now they are just normal businness. Only case A really merits 6Bone addresses, because items in that category would have the potential to disrupt an operating Internet using IPv6 in some of its areas. I hope this group will be able to move on and take the step of declaring IPv6 usable. Joao At 9:43 -0700 13/8/02, Bob Fink wrote: >At 05:32 PM 8/13/2002 +0200, Joao Luis Silva Damas wrote: >>Hi 6bone'rs, >> >>a bit of this message got me thinking and I would really like some >>input from this group on the exact meaning and intention of R&D in >>the context of the 6bone. >> >>Is R&D in the context of the 6bone: >> >>A) R&D in new IPv6 protocol or transition mechanism features? > >Yes, both. > >>B) R&D as experimentation in the context of deployment within an >>ISP or other network operator? > >Yes. > >>C) R&D un-related to IPv6, such as work done at an R&D institution >>(University or corporate research center, for instance)? > >Nope. > >>D) R&D related to applications which might benefit from using IPv6 >>as transport? > >Yes. > >>Note: With these questions I am not questioning this particular >>case, just looking for clarification in the context of the 6Bone. > > >Thanks, > >Bob From ejb@sdf.lonestar.org Wed Aug 14 13:38:59 2002 From: ejb@sdf.lonestar.org (Edward Brocklesby) Date: Wed, 14 Aug 2002 13:38:59 +0100 Subject: [6bone] 2001:470::/35 ghost routes. Message-ID: <200208141216.40070.nighthawk@unrealircd.com> [Apologies to the list manager, I sent this mail earlier from the wrong From-address. Please disregard that.] Good morning, I hope this is correct forum to pose this question, if not please ignore ;-). So. It seems some people are having problems reaching 2001:470::/32, owned by he.net. Let's see bgp info for this block: BGP routing table entry for 2001:470::/32 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer 6939 2001:470:1f00:ffff::1f6 from 2001:470:1f00:ffff::1f6 (64.71.128.82) (fe80::4047:8052) Origin IGP, localpref 100, valid, external Last update: Wed Aug 14 10:48:33 2002 24643 6830 6939 2001:730:5::1:4 from 2001:730:5::1:4 (213.46.231.151) (fe80::d52e:e797) Origin IGP, localpref 100, weight 2, valid, external, best Community: 6830:60003 6830:60011 Last update: Wed Aug 14 10:48:28 2002 Well, that seems reasonable. But look at traceroute: traceroute6 to 2001:470:1f00:ffff::1f4 (2001:470:1f00:ffff::1f4) from 2001:730:5::1:5, 30 hops max, 12 byte packets 1 nextgen-nl-gw1-ext.ipv6.hades.skumler.net 33.369 ms 31.422 ms 32 ms 2 nl-ams-re-02-fe-2-0.ipv6.aorta.net 31.812 ms 31.67 ms 30.005 ms 3 freestone-upctech.tun.ipv6.as8758.net.3.0.0.0.0.0.0.0.6.0.0.4.e.f.f.3.ip6.int 81.58 ms 88.527 ms 86.772 ms 4 * * * 5 enterzone-viagenie-gw.cyqb.ipv6.enterzone.net 274.055 ms 224.74 ms 229.084 ms 6 3ffe:8000:ffff:29::1 500.028 ms * 576.364 ms 7 cs-v6-atm0-2.hay.vbns.net 529.574 ms 522.357 ms 520.166 ms 8 3ffe:2900:a:4::2 501.968 ms 496.5 ms 515.963 ms 9 6bone-gw2.ipv6.cselt.it 576.516 ms 556.655 ms 556.584 ms 10 chello-gw1.ipv6.tilab.it 600.664 ms 564.488 ms 567.033 ms 11 3ffe:1d00:2:25::1 729.294 ms * 720.111 ms 12 * * * 13 enterzone-viagenie-gw.cyqb.ipv6.enterzone.net 792.195 ms 846.14 ms 761.983 ms 14 3ffe:8000:ffff:29::1 1001.92 ms 1081.14 ms 1066.2 ms 15 cs-v6-atm0-2.hay.vbns.net 1064.45 ms 1042.58 ms 1113.2 ms 16 3ffe:2900:a:4::2 1071.17 ms 1012.31 ms 1212.54 ms So.. I think there is a problem ;-). Let's see output of another bgp route: BGP routing table entry for 2001:470::/35 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 24643 6830 8758 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 2001:730:5::1:4 from 2001:730:5::1:4 (213.46.231.151) (fe80::d52e:e797) Origin IGP, localpref 100, weight 2, valid, external, best Community: 6830:60003 6830:60011 Last update: Wed Aug 14 10:48:28 2002 Hm, what a strange AS-path this is. Despite our peering with AS 6939, they don't advertise this route. This is probably because their /35 has changed recently to a /32, so in fact this route should not exist -- probably it is a ghost route? Let's assume three possible sources; AS9044, AS10566 and AS7660. I am inclined to point some blame at AS7660; why? Well, let's see what fubar looking glass has to say about this route: daemon.fubar.ca> show ipv6 bgp 2001:470::/35 BGP routing table entry for 2001:470::/35 Paths: (3 available, best #3, table Default-IP-Routing-Table) Advertised to non peer-group peers: 3ffe:c00:8023:10::1 3ffe:81a0:1000::15 3ffe:81a0:1000::37 6435 6175 7580 145 11537 22388 7660 2500 2497 3549 8002 278 6939 ^^^^ 3ffe:81a0:1000::37 from 3ffe:81a0:1000::37 (64.65.64.152) (fe80::4041:4098) Origin IGP, localpref 100, valid, external Last update: Wed Aug 14 01:20:47 2002 109 6175 7580 145 11537 22388 7660 2500 2497 3549 8002 278 6939 ^^^^ 3ffe:c00:8023:10::1 from 3ffe:c00:8023:10::1 (128.107.240.254) (fe80::806b:f0fe) Origin IGP, localpref 100, valid, external Last update: Wed Aug 14 01:20:42 2002 24765 8758 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 ^^^^ ^^^^^ ^^^^ 3ffe:81a0:1000::11 from 3ffe:81a0:1000::11 (80.71.6.94) Origin IGP, localpref 100, valid, external, best Community: 24765:100 24765:800 24765:2300 24765:6007 Last update: Wed Aug 14 01:20:16 2002 I see that of the three routes, the only common entry is AS7660. Hm, who is this?... root@firedrake:~# whois -h whois.ripe.net AS7660 [...] remarks: For more information on APNIC assigned blocks, connect remarks: to APNIC's whois database, whois.apnic.net. OK, so: root@firedrake:~# whois -h whois.apnic.net AS7660 [...] % ----------------- % No entries found. % ----------------- % % Search tips: % % 1. To search for an AS number, include "AS" in front of the number. % Example: AS4808 Well, it seems that this APNIC ASN does not have an entry in APNIC's whois database. Hmmm. AS10566 is Viagenie, of course; without making any comment myself, I'm told by others they have had problems with advertising ghost routes in the past, So maybe it's them. AS9044 appears to be owned by solnet.ch. I haven't heard of any problems from them.. Would anyone like to comment on this problem? (or else-- tell me to go away ;-) sorry if this is not an appropriate question for this list, but maybe it affects 6bone community too..) (Maybe too if anyone knows the contact for AS7660 it's useful.) Regards, -larne. From bmanning@ISI.EDU Wed Aug 14 13:41:54 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 14 Aug 2002 05:41:54 -0700 (PDT) Subject: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 In-Reply-To: from Joao Luis Silva Damas at "Aug 14, 2 09:23:33 am" Message-ID: <200208141241.g7ECfsi09777@boreas.isi.edu> using "metro-based" addressing is a novel spin on traditional delegation techniques. to some degree, it is an outgrowth of "normal" exchange point delegations, in that the prefix is bound to a geographic region. Such techniques have been proposed in both the v4 and v6 communities. This looks to be a serious attempt to try it with v6. that said, I don't see why this request -requires- 6bone space, but then again, its more in the spirit of testing new address management techniques than some of the 6bone delegations have presented for justification. IPv4 space has been delegated for similar addressing experiments in the past and may be in future. Some ended cleanly (net 39) and some have taken more time (net 24). Given the nature of the experiment in addressing on a metro-scale, and that the 6bone is clearly experimental in nature, I'm in favor of letting these folks get a delegation to see if the social/engineering aspects will work. If so, they should end up renumbering into production space, just like the rest of the experiments, when they wrap up. % I see, % in that case I guess we better start creating the 4Bone, for newvie % ISPs in IPv4 and people developing new applications that benefit % from IPv4 transport. % % Come on, these two cases were OK up to the point where people could % not get any other type of IPv6 addresses but now they are just normal % businness. % % Only case A really merits 6Bone addresses, because items in that % category would have the potential to disrupt an operating Internet % using IPv6 in some of its areas. % % I hope this group will be able to move on and take the step of % declaring IPv6 usable. % % Joao % % At 9:43 -0700 13/8/02, Bob Fink wrote: % >At 05:32 PM 8/13/2002 +0200, Joao Luis Silva Damas wrote: % >>Hi 6bone'rs, % >> % >>a bit of this message got me thinking and I would really like some % >>input from this group on the exact meaning and intention of R&D in % >>the context of the 6bone. % >> % >>Is R&D in the context of the 6bone: % >> % >>A) R&D in new IPv6 protocol or transition mechanism features? % > % >Yes, both. % > % >>B) R&D as experimentation in the context of deployment within an % >>ISP or other network operator? % > % >Yes. % > % >>C) R&D un-related to IPv6, such as work done at an R&D institution % >>(University or corporate research center, for instance)? % > % >Nope. % > % >>D) R&D related to applications which might benefit from using IPv6 % >>as transport? % > % >Yes. % > % >>Note: With these questions I am not questioning this particular % >>case, just looking for clarification in the context of the 6Bone. % > % > % >Thanks, % > % >Bob % % _______________________________________________ % 6bone mailing list % 6bone@mailman.isi.edu % http://mailman.isi.edu/mailman/listinfo/6bone % -- --bill From joao@ripe.net Wed Aug 14 14:11:42 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Wed, 14 Aug 2002 15:11:42 +0200 Subject: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 In-Reply-To: <200208141241.g7ECfsi09777@boreas.isi.edu> References: <200208141241.g7ECfsi09777@boreas.isi.edu> Message-ID: Bill, in my first mail I said: % >>Note: With these questions I am not questioning this particular % >>case, just looking for clarification in the context of the 6Bone. If people think this falls under A, by all means do allocate. What I am looking for is a general view and a clarified definition of R&D in the context of the 6Bone, and my last mail expresses my opinion, one which I feel strongly about. Cheers, Joao At 5:41 -0700 14/8/02, Bill Manning wrote: > using "metro-based" addressing is a novel spin on traditional > delegation techniques. to some degree, it is an outgrowth of > "normal" exchange point delegations, in that the prefix is > bound to a geographic region. Such techniques have been proposed > in both the v4 and v6 communities. This looks to be a serious > attempt to try it with v6. > > that said, I don't see why this request -requires- 6bone space, > but then again, its more in the spirit of testing new address > management techniques than some of the 6bone delegations have > presented for justification. > > IPv4 space has been delegated for similar addressing experiments > in the past and may be in future. Some ended cleanly (net 39) > and some have taken more time (net 24). > > Given the nature of the experiment in addressing on a metro-scale, > and that the 6bone is clearly experimental in nature, I'm in > favor of letting these folks get a delegation to see if the > social/engineering aspects will work. If so, they should end > up renumbering into production space, just like the rest of the > experiments, when they wrap up. > > > >% I see, >% in that case I guess we better start creating the 4Bone, for newvie >% ISPs in IPv4 and people developing new applications that benefit >% from IPv4 transport. >% >% Come on, these two cases were OK up to the point where people could >% not get any other type of IPv6 addresses but now they are just normal >% businness. >% >% Only case A really merits 6Bone addresses, because items in that >% category would have the potential to disrupt an operating Internet >% using IPv6 in some of its areas. >% >% I hope this group will be able to move on and take the step of >% declaring IPv6 usable. >% >% Joao >% >% At 9:43 -0700 13/8/02, Bob Fink wrote: >% >At 05:32 PM 8/13/2002 +0200, Joao Luis Silva Damas wrote: >% >>Hi 6bone'rs, >% >> >% >>a bit of this message got me thinking and I would really like some >% >>input from this group on the exact meaning and intention of R&D in >% >>the context of the 6bone. >% >> >% >>Is R&D in the context of the 6bone: >% >> >% >>A) R&D in new IPv6 protocol or transition mechanism features? >% > >% >Yes, both. >% > >% >>B) R&D as experimentation in the context of deployment within an >% >>ISP or other network operator? >% > >% >Yes. >% > >% >>C) R&D un-related to IPv6, such as work done at an R&D institution >% >>(University or corporate research center, for instance)? >% > >% >Nope. >% > >% >>D) R&D related to applications which might benefit from using IPv6 >% >>as transport? >% > >% >Yes. >% > >% >>Note: With these questions I am not questioning this particular >% >>case, just looking for clarification in the context of the 6Bone. >% > >% > >% >Thanks, >% > >% >Bob >% >% _______________________________________________ >% 6bone mailing list >% 6bone@mailman.isi.edu >% http://mailman.isi.edu/mailman/listinfo/6bone >% > > >-- >--bill >_______________________________________________ >6bone mailing list >6bone@mailman.isi.edu >http://mailman.isi.edu/mailman/listinfo/6bone From paitken@cisco.com Wed Aug 14 14:25:53 2002 From: paitken@cisco.com (Paul Aitken) Date: Wed, 14 Aug 2002 14:25:53 +0100 Subject: [6bone] routing problem References: <20020812083144.GA23039@einstein.nlnetlabs.nl> <57898.1029157534@gigant.surfnet.nl> <20020812155930.C27015@Space.Net> Message-ID: <3D5A5A61.6050502@cisco.com> Gert Doering wrote: > This time the announcement seems to be stuck in AS7660 (someone in Japan) Edward Brocklesby wrote: > I see that of the three routes, the only common entry is AS7660. > Hm, who is this?... > [...] > (Maybe too if anyone knows the contact for AS7660 it's useful.) AS7660 as listed as being APAN JP Network Operations Center, 1-8-1 Otemachi Chiyoda-ku, Tokyo, contacts are listed by name, no e-mail addresses. But go to http://whois.nic.ad.jp/cgi-bin/whois_gw and ask it for 7660 - you'll get what you are looking for. Cheers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From gert@space.net Wed Aug 14 14:38:20 2002 From: gert@space.net (Gert Doering) Date: Wed, 14 Aug 2002 15:38:20 +0200 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: <200208141216.40070.nighthawk@unrealircd.com>; from ejb@sdf.lonestar.org on Wed, Aug 14, 2002 at 01:38:59PM +0100 References: <200208141216.40070.nighthawk@unrealircd.com> Message-ID: <20020814153820.U27015@Space.Net> hi, On Wed, Aug 14, 2002 at 01:38:59PM +0100, Edward Brocklesby wrote: > So.. I think there is a problem ;-). > > Let's see output of another bgp route: > > BGP routing table entry for 2001:470::/35 Ghosts again. Here is what I have for this prefix: 1930 1916 11537 786 5623 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 3292 6830 8758 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 4554 5609 5623 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 1752 6830 8758 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 3274 6175 7580 145 11537 22388 7660 2500 2497 3549 8002 278 6939 109 109 6175 7580 145 11537 22388 7660 2500 2497 3549 8002 278 6939 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 > Hm, what a strange AS-path this is. Despite our peering with AS 6939, they > don't advertise this route. This is probably because their /35 has changed > recently to a /32, so in fact this route should not exist -- probably it is a > ghost route? Yep, looks like it. > Let's assume three possible sources; AS9044, AS10566 and AS7660. > I am inclined to point some blame at AS7660; why? Well, let's see what > fubar looking glass has to say about this route: >From what I have, I'd also tend to blaim 7660. They're the only common element in all the path tails, while 90444 and 10566 don't even appear in two of the paths. > I see that of the three routes, the only common entry is AS7660. > Hm, who is this?... Some AS in Japan, which seems to have been responsible for one of the last ghosts as well. [..] > Well, it seems that this APNIC ASN does not have an entry in APNIC's > whois database. Hmmm. Interesting. Last time I checked, they were visible... Anyway, whois.ra.net still has them...: aut-num: AS7660 as-name: UNSPECIFIED descr: APAN JP Network Operations Center 1-8-1 Otemachi Chiyoda-ku Tokyo, JAPAN I have no direct contacts there. > AS10566 is Viagenie, of course; without making any comment myself, > I'm told by others they have had problems with advertising ghost > routes in the past, So maybe it's them. I don't think so. I see a path that has no 10566 in it, which implies that they have fixed their end (even though nobody has heard anything from them recently, which is a pity). > Would anyone like to comment on this problem? (or else-- tell me > to go away ;-) sorry if this is not an appropriate question for > this list, but maybe it affects 6bone community too..) > > (Maybe too if anyone knows the contact for AS7660 it's useful.) That would be helpful, yes. Especially if someone has a good personal contact and could work with AS7660 to figure out what's going on (some specific recent software change, or some new product, or whatnot). AS7660 is a new player in this "ghost game"... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From ejb@sdf.lonestar.org Wed Aug 14 14:45:37 2002 From: ejb@sdf.lonestar.org (Edward Brocklesby) Date: Wed, 14 Aug 2002 14:45:37 +0100 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: <20020814153820.U27015@Space.Net> References: <200208141216.40070.nighthawk@unrealircd.com> <20020814153820.U27015@Space.Net> Message-ID: <200208141445.37029.ejb@sdf.lonestar.org> Gert Doering: > That would be helpful, yes. Especially if someone has a good personal > contact and could work with AS7660 to figure out what's going on (some > specific recent software change, or some new product, or whatnot). Well, extracted from the db (thanks to Paul Aitken), we have Administrative contact: a. [JPNIC Handle] SG001JP c. [Last, First] Goto, Shigeki d. [E-Mail] goto@goto.info.waseda.ac.jp g. [Organization] Waseda University l. [Division] Department of Info. and Comp. Sci.,School of Science and Engineering n. [Title] Professor and three technical contacts: a. [JPNIC Handle] KK007JP c. [Last, First] Konishi, Kazunori d. [E-Mail] konish@kddlabs.co.jp g. [Organization] KDDI R&D Laboratories INC. l. [Division] n. [Title] Principal Research Engineer a. [JPNIC Handle] AK003JP c. [Last, First] Kato, Akira d. [E-Mail] kato@wide.ad.jp g. [Organization] The University of Tokyo l. [Division] Information Technology Center n. [Title] Research Associate a. [JPNIC Handle] MF030JP c. [Last, First] Fujinaga, Masahiko d. [E-Mail] mf-fujinaga@kddi.com g. [Organization] KDDI CORPORATION I don't really want to take this up myself, but maybe someone wants to have a word.. > Gert Doering > -- NetMaster Regards, -larne. From Wim.Biemolt@surfnet.nl Wed Aug 14 15:02:24 2002 From: Wim.Biemolt@surfnet.nl (Wim Biemolt) Date: Wed, 14 Aug 2002 16:02:24 +0200 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: Your message of "Wed, 14 Aug 2002 15:38:20 +0200." <20020814153820.U27015@Space.Net> Message-ID: <64328.1029333744@gigant.surfnet.nl> ==> From: Gert Doering > Interesting. Last time I checked, they were visible... Funny you mention this. Since the same AS7660 also appeared when we were having problems I looked in the 6bone whois and found an e-mail address (@kddlabs.co.jp). Didn't receive a reply. But now it seems to have vanished from the 6bone whois. -Wim -/- SURFnet From riel@conectiva.com.br Wed Aug 14 15:16:52 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Wed, 14 Aug 2002 11:16:52 -0300 (BRT) Subject: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 In-Reply-To: Message-ID: On Wed, 14 Aug 2002, Joao Luis Silva Damas wrote: > Come on, these two cases were OK up to the point where people could not > get any other type of IPv6 addresses but now they are just normal > businness. Yeah right. I doubt ipv6 is that widely available already. > Only case A really merits 6Bone addresses, because items in that > category would have the potential to disrupt an operating Internet > using IPv6 in some of its areas. The fact that you use "an operating internet" instead of "the internet" is telling. IPv6 just isn't commonplace yet. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From nicolas.deffayet@ndsoftware.net Wed Aug 14 15:17:57 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 14 Aug 2002 16:17:57 +0200 Subject: [6bone] routing problem In-Reply-To: <3D5A5A61.6050502@cisco.com> References: <20020812083144.GA23039@einstein.nlnetlabs.nl> <57898.1029157534@gigant.surfnet.nl> <20020812155930.C27015@Space.Net> <3D5A5A61.6050502@cisco.com> Message-ID: <1029334677.675.17.camel@wks1-1.corp.ndsoftware.com> On Wed, 2002-08-14 at 15:25, Paul Aitken wrote: > Gert Doering wrote: > > > This time the announcement seems to be stuck in AS7660 (someone in Japan) > > > Edward Brocklesby wrote: > > > I see that of the three routes, the only common entry is AS7660. > > Hm, who is this?... > > [...] > > (Maybe too if anyone knows the contact for AS7660 it's useful.) > > > AS7660 as listed as being APAN JP Network Operations Center, 1-8-1 > Otemachi Chiyoda-ku, Tokyo, contacts are listed by name, no e-mail > addresses. > > But go to http://whois.nic.ad.jp/cgi-bin/whois_gw and ask it for 7660 - > you'll get what you are looking for. > APAN-JP (http://www.jp.apan.net/v6/index.html) Looking Glass: http://www.jp.apan.net/cgi-bin/ipv6/mrlg ASPath-tree: http://www.jp.apan.net/ASpath-tree/bgp.html Ping: http://www.jp.apan.net/cgi-bin/ipv6/ping6 Traceroute: http://www.jp.apan.net/cgi-bin/ipv6/traceroute6 Best Regards, Nicolas DEFFAYET From nicolas.deffayet@ndsoftware.net Wed Aug 14 15:23:50 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 14 Aug 2002 16:23:50 +0200 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: <20020814153820.U27015@Space.Net> References: <200208141216.40070.nighthawk@unrealircd.com> <20020814153820.U27015@Space.Net> Message-ID: <1029335030.674.21.camel@wks1-1.corp.ndsoftware.com> On Wed, 2002-08-14 at 15:38, Gert Doering wrote: hi, > > On Wed, Aug 14, 2002 at 01:38:59PM +0100, Edward Brocklesby wrote: > > So.. I think there is a problem ;-). > > > > Let's see output of another bgp route: > > > > BGP routing table entry for 2001:470::/35 > > Ghosts again. Here is what I have for this prefix: > > 1930 1916 11537 786 5623 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 > 3292 6830 8758 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 > 4554 5609 5623 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 > 1752 6830 8758 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 > 3274 6175 7580 145 11537 22388 7660 2500 2497 3549 8002 278 6939 > 109 109 6175 7580 145 11537 22388 7660 2500 2497 3549 8002 278 6939 > 9044 10566 10109 7660 2500 2497 3549 8002 278 6939 > > > > I see that of the three routes, the only common entry is AS7660. > > Hm, who is this?... > > Some AS in Japan, which seems to have been responsible for one of the last > ghosts as well. > > [..] > > Well, it seems that this APNIC ASN does not have an entry in APNIC's > > whois database. Hmmm. > > Interesting. Last time I checked, they were visible... > > Anyway, whois.ra.net still has them...: > > aut-num: AS7660 > as-name: UNSPECIFIED > descr: APAN JP Network Operations Center > 1-8-1 Otemachi Chiyoda-ku > Tokyo, JAPAN > > I have no direct contacts there. > > > > Would anyone like to comment on this problem? (or else-- tell me > > to go away ;-) sorry if this is not an appropriate question for > > this list, but maybe it affects 6bone community too..) > > > > (Maybe too if anyone knows the contact for AS7660 it's useful.) > > That would be helpful, yes. Especially if someone has a good personal > contact and could work with AS7660 to figure out what's going on (some > specific recent software change, or some new product, or whatnot). > > AS7660 is a new player in this "ghost game"... http://www.jp.apan.net/cgi-bin/ipv6/mrlg show bgp ipv6 2001:470::/35 % Network not in table show bgp ipv6 2001:470::/32 BGP routing table entry for 2001:470::/32, version 1245624 Paths: (1 available, best #1) Not advertised to any peer 9264 6939 2001:288:3B0::1D (metric 2) from 3FFE:8140:101:3::3 (203.181.248.4) Origin IGP, localpref 100, valid, internal, best Best Regards, Nicolas DEFFAYET From gert@space.net Wed Aug 14 15:24:58 2002 From: gert@space.net (Gert Doering) Date: Wed, 14 Aug 2002 16:24:58 +0200 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: <1029335030.674.21.camel@wks1-1.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Wed, Aug 14, 2002 at 04:23:50PM +0200 References: <200208141216.40070.nighthawk@unrealircd.com> <20020814153820.U27015@Space.Net> <1029335030.674.21.camel@wks1-1.corp.ndsoftware.com> Message-ID: <20020814162457.Z27015@Space.Net> Hi, On Wed, Aug 14, 2002 at 04:23:50PM +0200, Nicolas DEFFAYET wrote: > > AS7660 is a new player in this "ghost game"... > > http://www.jp.apan.net/cgi-bin/ipv6/mrlg > > show bgp ipv6 2001:470::/35 > % Network not in table Interesting indeed. So *they* don't have it anymore, but they didn't withdraw it... I still see the prefix over various paths, all with 7660 in them. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From nicolas.deffayet@ndsoftware.net Wed Aug 14 15:27:27 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 14 Aug 2002 16:27:27 +0200 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: <200208141445.37029.ejb@sdf.lonestar.org> References: <200208141216.40070.nighthawk@unrealircd.com> <20020814153820.U27015@Space.Net> <200208141445.37029.ejb@sdf.lonestar.org> Message-ID: <1029335247.642.26.camel@wks1-1.corp.ndsoftware.com> On Wed, 2002-08-14 at 15:45, Edward Brocklesby wrote: > Gert Doering: > > That would be helpful, yes. Especially if someone has a good personal > > contact and could work with AS7660 to figure out what's going on (some > > specific recent software change, or some new product, or whatnot). > > Well, extracted from the db (thanks to Paul Aitken), we have > Administrative contact: > > a. [JPNIC Handle] SG001JP > c. [Last, First] Goto, Shigeki > d. [E-Mail] goto@goto.info.waseda.ac.jp > g. [Organization] Waseda University > l. [Division] Department of Info. and Comp. Sci.,School of > Science and > Engineering > n. [Title] Professor > > and three technical contacts: > > a. [JPNIC Handle] KK007JP > c. [Last, First] Konishi, Kazunori > d. [E-Mail] konish@kddlabs.co.jp > g. [Organization] KDDI R&D Laboratories INC. > l. [Division] > n. [Title] Principal Research Engineer > > a. [JPNIC Handle] AK003JP > c. [Last, First] Kato, Akira > d. [E-Mail] kato@wide.ad.jp > g. [Organization] The University of Tokyo > l. [Division] Information Technology Center > n. [Title] Research Associate > > a. [JPNIC Handle] MF030JP > c. [Last, First] Fujinaga, Masahiko > d. [E-Mail] mf-fujinaga@kddi.com > g. [Organization] KDDI CORPORATION > > I don't really want to take this up myself, but maybe someone wants to have a > word.. You have too: ops@jp.apan.net NOC Director Kazunori Konishi konish@kddlabs.jp +81-492-78-7313 IPv6 Support Akira Kato kato@wide.ad.jp Yoshinori Kitatsuji kitaji@kddlabs.jp mobile +81-492-78-7362 +81-70-666-43841 Yuichiro Hei hei@kddlabs.jp mobile +81-492-78-7891 +81-70-666-40994 Operator Otemachi Technical Center otc@jp.apan.net Best Regards, Nicolas DEFFAYET From joao@ripe.net Wed Aug 14 15:41:09 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Wed, 14 Aug 2002 16:41:09 +0200 (CEST) Subject: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 In-Reply-To: Message-ID: On Wed, 14 Aug 2002, Rik van Riel wrote: > On Wed, 14 Aug 2002, Joao Luis Silva Damas wrote: > > > Come on, these two cases were OK up to the point where people could not > > get any other type of IPv6 addresses but now they are just normal > > businness. > > Yeah right. I doubt ipv6 is that widely available already. That is not the point. It doesn't matter whether it is deployed or not, what matters is whether it is deployable or not. Insisting in calling addresses that are being used to provide plain services, just like in IPv4, "experimental" is quite the same as calling IPv6 itself experimental. In the same way, giving out "special" addresses to developers of applications which use IPv6 to get packets accross is quite the same as giving a sofwtare company special IPv4 addresses to test their new web browser. Come on... > > > Only case A really merits 6Bone addresses, because items in that > > category would have the potential to disrupt an operating Internet > > using IPv6 in some of its areas. > > The fact that you use "an operating internet" instead of > "the internet" is telling. IPv6 just isn't commonplace yet. > Read the sentence again. That is not what it implies. IPv6 machines are much better off than the poor people seating behind NATs. Regards, Joao From fink@es.net Wed Aug 14 16:51:26 2002 From: fink@es.net (Bob Fink) Date: Wed, 14 Aug 2002 08:51:26 -0700 Subject: [6bone] pTLA request by Euro6IX project for In-Reply-To: References: <5.1.0.14.0.20020813094253.0331abe8@imap2.es.net> <00ec01c242db$a9106450$8700000a@consulintel.es> <2B81403386729140A3A899A8B39B046405E26A@server2000.arneill-py.sacramento.c a.us> <1029180716.1358.263.camel@wks1-1.corp.ndsoftware.com> <00ec01c242db$a9106450$8700000a@consulintel.es> <5.1.0.14.0.20020813094253.0331abe8@imap2.es.net> Message-ID: <5.1.0.14.0.20020814082139.033a96a8@imap2.es.net> Joao, At 09:23 AM 8/14/2002 +0200, Joao Luis Silva Damas wrote: >I see, > in that case I guess we better start creating the 4Bone, for newvie ISPs > in IPv4 and people developing new applications that benefit from IPv4 > transport. >Come on, these two cases were OK up to the point where people could not >get any other type of IPv6 addresses but now they are just normal businness. The problem is that those wanting to experiment with, test or try IPv6 cannot do so today as IPv6 service is not even remotely as available as IPv4 service is. I am routinely asked by networks and sites (and even individuals) how to get involved with IPv6 and where to connect. The current list of sTLA holders is so small, and in most cases for profit (yes, some are not for profit, but aren't in the business of providing service outside of their own community) that sites and networks trying v6 mostly have no alternatives for connectivity. So they turn to pTLAs and many of them aren't willing to provide general tunneling to all comers either as they generally try to serve a community of their own interest. Freenet6 helps, but can't be expected to handle all the demand. Then there is 6to4, which is not really ready for many of these folks as it is evolving and requires knowledge to get it going that many don't have. Hopefully it will eventually take up the slack. So we continue to provide 6bone pTLAs in the hope that we will get sufficient deployment that IPv6 will be widely available. Anyway, just having production IPv6 addresses available from RIRs does not make IPv6 widely available, and affordable. Also, having a 6bone does not make IPv6 not usable, rather it enables it. >Only case A really merits 6Bone addresses, because items in that category >would have the potential to disrupt an operating Internet using IPv6 in >some of its areas. I haven't seen many cases where an experiment might disable the operating IPv6 Internet, tho Teredo might be one (I don't really know). If there are experiments that should not connect to the IPv6 Internet they don't really need the 6bone as they should probably be tested in a completely isolated manner. The 6bone has been used, and continues to be used, to test and try many things by folks that otherwise can not get production address space and often don't really want it yet. >I hope this group will be able to move on and take the step of declaring >IPv6 usable. I don't believe that this group (presuming you mean the 6bone community) feels that IPv6 is not usable, rather the collective 6bone community is continually trying to enable IPv6 and make it more widely available. Thanks, Bob From tvo@EnterZone.Net Wed Aug 14 17:29:00 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 12:29:00 -0400 (EDT) Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: <20020814153820.U27015@Space.Net> Message-ID: Looking from AS7660's point of view at http://www.jp.apan.net/cgi-bin/ipv6/mrlg (Note to the guys at AS7660: That is an OLD, OLD, OLD copy of the MRLG. New and improved code is available at ftp://ftp.enterzone.net/looking-glass/CURRENT/ ) Executing command = show bgp ipv6 2001:470::/35 % Network not in table Executing command = show bgp ipv6 2001:470::/32 BGP routing table entry for 2001:470::/32, version 1245624 Paths: (1 available, best #1) Not advertised to any peer 9264 6939 2001:288:3B0::1D (metric 2) from 3FFE:8140:101:3::3 (203.181.248.4) Origin IGP, localpref 100, valid, internal, best tp6r2-tokyo Uh-Oh! It looks like it may be time for them to contact ipv6-support@cisco.com (And no, I don't work for Cisco - I'm just trying to be helpful.) Executing command = show version Cisco Internetwork Operating System Software IOS (tm) RSP Software (RSP-PV-M), Experimental Version 12.2(20010708:224052) [otroan-bastille 276] Copyright (c) 1986-2001 by cisco Systems, Inc. Compiled Wed 25-Jul-01 00:00 by otroan Image text-base: 0x60010968, data-base: 0x614CC000 ROM: System Bootstrap, Version 5.3.2(3.2) [kmac 3.2], MAINTENANCE INTERIM SOFTWARE BOOTLDR: RSP Software (RSP-BOOT-M), Version 12.0(9)S, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) tp6r2-tokyo uptime is 26 weeks, 7 hours, 46 minutes System returned to ROM by power-on System image file is "slot0:rsp-pv-mz.20010724" cisco RSP1 (R4600) processor with 65536K/2072K bytes of memory. R4600 CPU at 100Mhz, Implementation 32, Rev 2.0 Last reset from power-on G.703/E1 software, Version 1.0. G.703/JT2 software, Version 1.0. X.25 software, Version 3.0.0. Chassis Interface. 1 EIP controller (2 Ethernet). 2 AIP controllers (2 ATM). 1 FEIP controller (1 FastEthernet). 2 Ethernet/IEEE 802.3 interface(s) 1 FastEthernet/IEEE 802.3 interface(s) 2 ATM network interface(s) 125K bytes of non-volatile configuration memory. 16384K bytes of Flash PCMCIA card at slot 0 (Sector size 128K). 8192K bytes of Flash internal SIMM (Sector size 256K). Configuration register is 0x102 tp6r2-tokyo --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From gert@space.net Wed Aug 14 17:34:25 2002 From: gert@space.net (Gert Doering) Date: Wed, 14 Aug 2002 18:34:25 +0200 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: ; from tvo@EnterZone.Net on Wed, Aug 14, 2002 at 12:29:00PM -0400 References: <20020814153820.U27015@Space.Net> Message-ID: <20020814183425.F27015@Space.Net> Hi, On Wed, Aug 14, 2002 at 12:29:00PM -0400, John Fraizer wrote: > Looking from AS7660's point of view at > http://www.jp.apan.net/cgi-bin/ipv6/mrlg [..] > Uh-Oh! It looks like it may be time for them to contact ipv6-support@cisco.com Indeed, as... > Cisco Internetwork Operating System Software > IOS (tm) RSP Software (RSP-PV-M), Experimental Version 12.2(20010708:224052) [otroan-bastille 276] ... this software version is old, but not *that* old - I thought all BGP withdraw bugs had long been extinguished... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jeroen@unfix.org Wed Aug 14 17:42:50 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Wed, 14 Aug 2002 18:42:50 +0200 Subject: XXX support (was [6bone] routing problem) In-Reply-To: <20020814085442.M27015@Space.Net> Message-ID: <000801c243b1$a100c5d0$850d640a@unfix.org> Gert Doering wrote: > Maybe it's time to learn some facts of life: all software has bugs. Everything has bugs, even live itself, and then the bugs sting ;) > The difference is how the people that are responsible for them handle > bug reports and go fixing them. In short: Politics. > What was the major software package that you wrote recently > that has no single bug? Has been some time I wrote Hello World, though it bugs tremendously: no IPv6 support ;) Greets, Jeroen From jorgen@hovland.cx Wed Aug 14 18:14:11 2002 From: jorgen@hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 14 Aug 2002 19:14:11 +0200 Subject: [6bone] SUNET announcing ALL IPv6 routes References: <200208141216.40070.nighthawk@unrealircd.com><20020814153820.U27015@Space.Net> <200208141445.37029.ejb@sdf.lonestar.org> <1029335247.642.26.camel@wks1-1.corp.ndsoftware.com> Message-ID: <000901c243b6$02e7a6c0$0200000a@hera> Anybody alive from sunet here? You are announcing every route with your AS as last-hop. It is causing us CRITICAL downtime, and probably more than half of all the other STLA/pTLA's too. Anybody peering with SUNET: please fix this. ...snip... * 2001:750:E::A 0 15589 1654 i * i3FFE:1D00::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i Network Next Hop Metric LocPrf Weight Path * i3FFE:1E00::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 2001:750:E::A 0 15589 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * i3FFE:1F00::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:2000::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:2100::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:2200::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:2400::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:2500::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i * 3FFE:82B0:0:1:1::19 0 15982 1654 i * i3FFE:2600::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 Network Next Hop Metric LocPrf Weight Path 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i *>i3FFE:2610:2::/48 3FFE:82B0:0:1:1::5 100 0 6830 1654 3274 8432 i *>i3FFE:2610:10::/48 3FFE:82B0:0:1:1::5 100 0 6830 1654 3274 1342 i *>i3FFE:2650:1::/48 3FFE:82B0:0:1:1::5 100 0 6830 1654 3274 8812 i *>i3FFE:26FF:8::/48 3FFE:82B0:0:1:1::5 100 0 6830 1654 3274 24751 i *>i3FFE:26FF:A::/48 3FFE:82B0:0:1:1::5 100 0 6830 1654 3274 16023 i *>i3FFE:26FF:10::/48 3FFE:82B0:0:1:1::5 100 0 6830 1654 3274 8145 i * i3FFE:2800::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:2900::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 2001:750:E::A 0 15589 1654 i *>i3FFE:2900:2004::/48 3FFE:82B0:0:1:1::5 100 0 6830 1654 8002 4538 65272 i * 3FFE:2A00::/24 3FFE:82B0:0:1:1::15 0 24765 1654 i * 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:2B00::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:2C00::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:2F00::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i Network Next Hop Metric LocPrf Weight Path * i3FFE:3100::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:3200::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i *>i3FFE:327E:1::/48 3FFE:82B0:0:1:1::5 100 0 6830 1654 8002 4538 65272 i * i3FFE:3300::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:3400::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:3500::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:3600::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:3700::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:3800::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i Network Next Hop Metric LocPrf Weight Path *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:3900::/24 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:4000::/32 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:4003::/32 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::19 0 15982 1654 i * i3FFE:4004::/32 3FFE:82B0:0:1:1::5 100 0 6830 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i * 2001:750:E::A 0 15589 1654 i * 3FFE:4005::/32 3FFE:82B0:0:1:1::19 0 15982 1654 i *>i3FFE:4005:A::/48 3FFE:82B0:0:1:1::5 100 0 6830 1654 8002 4538 65272 i * i3FFE:4006::/32 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * i3FFE:4007::/32 3FFE:82B0:0:1:1::5 100 0 6830 1654 i * 3FFE:82B0:0:1:1::15 0 24765 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 1654 i * 2001:750:E::A 0 15589 1654 i * 3FFE:4008::/32 3FFE:82B0:0:1:1::15 0 24765 1654 i * 2001:750:E::A 0 15589 1654 i * 3FFE:4009::/32 3FFE:82B0:0:1:1::15 0 24765 1654 i * i3FFE:400A::/32 3FFE:82B0:0:1:1::5 100 0 6830 1654 i Joergen Hovland WebOnline AS From michel@arneill-py.sacramento.ca.us Wed Aug 14 18:24:41 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 14 Aug 2002 10:24:41 -0700 Subject: [6bone] the end of ngtrans Message-ID: <2B81403386729140A3A899A8B39B046405E27B@server2000.arneill-py.sacramento.ca.us> 6boners, > Randy Bush wrote: > hence it is planned for ngtrans be closed and a new > group, v6ops, be chartered This creates an interesting situation as the 6bone was informally operated with oversight from the "NGtrans" (IPv6 Transition) Working Group of the IETF. Thoughts, anyone? Michel. From Wim.Biemolt@surfnet.nl Wed Aug 14 18:26:33 2002 From: Wim.Biemolt@surfnet.nl (Wim Biemolt) Date: Wed, 14 Aug 2002 19:26:33 +0200 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: Your message of "Wed, 14 Aug 2002 12:29:00 EDT." Message-ID: <65411.1029345993@gigant.surfnet.nl> ==> From: John Fraizer > New and improved code is available at > ftp://ftp.enterzone.net/looking-glass/CURRENT/ ) Feature request: handle routers who need username + password. (And fastping.c doesn't seem to compile on my 4.6-STABLE box.) -Wim -/- SURFnet From tvo@EnterZone.Net Wed Aug 14 18:36:12 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 13:36:12 -0400 (EDT) Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: <65411.1029345993@gigant.surfnet.nl> Message-ID: On Wed, 14 Aug 2002, Wim Biemolt wrote: > > > ==> From: John Fraizer > > > New and improved code is available at > > ftp://ftp.enterzone.net/looking-glass/CURRENT/ ) > > Feature request: handle routers who need username + password. > (And fastping.c doesn't seem to compile on my 4.6-STABLE box.) > > -Wim -/- SURFnet > Wim, Look in sub execute_command. Prior to: $t->cmd ($login_pass); do a $t->cmd ($login_username); You'll have to pass that information to the program of course and put in some logic to not try to send a username to routers that don't require it but, it should be simple enough to do. As for fastping, I didn't write the code. I just use it and make it available in the tarball for folks who want to use it. --- 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 Aug 14 18:38:25 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 14 Aug 2002 10:38:25 -0700 (PDT) Subject: [6bone] the end of ngtrans In-Reply-To: <2B81403386729140A3A899A8B39B046405E27B@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Aug 14, 2 10:24:41 am" Message-ID: <200208141738.g7EHcPA02976@boreas.isi.edu> % 6boners, % % > Randy Bush wrote: % > hence it is planned for ngtrans be closed and a new % > group, v6ops, be chartered % % This creates an interesting situation as the 6bone was informally % operated with oversight from the "NGtrans" (IPv6 Transition) Working % Group of the IETF. % % Thoughts, anyone? % % Michel. % % _______________________________________________ % 6bone mailing list % 6bone@mailman.isi.edu % http://mailman.isi.edu/mailman/listinfo/6bone There are no plans to depricate the mailing list. -- --bill From tvo@EnterZone.Net Wed Aug 14 18:40:41 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 13:40:41 -0400 (EDT) Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: <000901c243b6$02e7a6c0$0200000a@hera> Message-ID: On Wed, 14 Aug 2002, [iso-8859-1] Jørgen Hovland wrote: > Anybody alive from sunet here? You are announcing every route with > your AS as last-hop. It is causing us CRITICAL downtime, and probably > more than half of all the other STLA/pTLA's too. > > Anybody peering with SUNET: please fix this. > > ...snip... > * 2001:750:E::A 0 15589 1654 i > * i3FFE:1D00::/24 3FFE:82B0:0:1:1::5 > 100 0 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 15982 1654 i > * 2001:750:E::A 0 15589 1654 i > Network Next Hop Metric LocPrf Weight Path > * i3FFE:1E00::/24 3FFE:82B0:0:1:1::5 > 100 0 6830 1654 i Cute. SUNET (ASN-SWEDEN) SUNET/KTH SE Autonomous System Name: SWEDEN Autonomous System Number: 1654 Record last updated on 30-Dec-1991. Database last updated on 13-Aug-2002 20:01:19 EDT. That should be illegal. No contact information, what-so-ever. May I make the humble request that anyone who peers with SUNET admin-down the sessions until such time as the clue delivery can be made to them? --- 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 Wed Aug 14 18:49:02 2002 From: kim@tac.nyc.ny.us (Kimmo Suominen) Date: Wed, 14 Aug 2002 13:49:02 -0400 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: <65411.1029345993@gigant.surfnet.nl> from Wim Biemolt on Wed, 14 Aug 2002 19:26:33 +0200 References: <65411.1029345993@gigant.surfnet.nl> Message-ID: <20020814174902.3E0C37E33@beowulf.gw.com> There's also a simple zebra/cisco looking glass at http://www.gw.com/sw/stripes/ It is written Perl, and can handle username + password. Regards, + Kim | From: Wim Biemolt | Date: Wed, 14 Aug 2002 19:26:33 +0200 | | | | ==> From: John Fraizer | | > New and improved code is available at | > ftp://ftp.enterzone.net/looking-glass/CURRENT/ ) | | Feature request: handle routers who need username + password. | (And fastping.c doesn't seem to compile on my 4.6-STABLE box.) | | -Wim -/- SURFnet | | _______________________________________________ | 6bone mailing list | 6bone@mailman.isi.edu | http://mailman.isi.edu/mailman/listinfo/6bone | From gert@space.net Wed Aug 14 18:50:54 2002 From: gert@space.net (Gert Doering) Date: Wed, 14 Aug 2002 19:50:54 +0200 Subject: [6bone] Could someone filter AS1654, please? Message-ID: <20020814195054.I27015@Space.Net> Hi, I have no idea what they are doing, but I don't like the result - 1654 seems to re-announce all current IPv6 routes under their own AS as origin: cisco25#sh bgp ipv6 reg 1654$ BGP table version is 2014133, local router ID is 193.149.44.35 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i2001:208::/32 2001:608:0:3::1 9 100 0 8379 15982 1654 i *>i 2001:608:0:3::5 9 100 0 8379 15982 1654 i * 3FFE:2A00:100:7FF3::1 30 0 2603 1275 5609 1654 i * 2001:658:0:1::1 30 0 8627 6830 8973 1654 i * 2001:608:0:3::B 30 0 3292 6830 8973 1654 i * 2001:780::4 30 0 12337 6830 8973 1654 i * 2001:680:0:1::4 30 0 517 790 6830 8973 1654 i * 3FFE:8150:0:1::17 200 0 9044 8002 5609 1654 i * i2001:210::/35 2001:608:0:3::1 9 100 0 8379 15982 1654 i *>i 2001:608:0:3::5 9 100 0 8379 15982 1654 i [truncated] * i2001:238::/35 2001:608:0:3::1 9 100 0 8379 15982 1654 i *>i 2001:608:0:3::5 9 100 0 8379 15982 1654 i * 2001:240::/35 2001:658:0:1::1 30 0 8627 6830 1654 i * 2001:240::/32 2001:658:0:1::1 30 0 8627 6830 1654 i * 2001:680:0:1::4 30 0 517 790 8627 6830 1654 i * 2001:248::/35 2001:608:0:3::B 30 0 3292 6830 8973 1654 i * i2001:250::/35 2001:608:0:3::1 9 100 0 8379 15982 1654 i *>i 2001:608:0:3::5 9 100 0 8379 15982 1654 i * 2001:260::/35 2001:608:0:3::B 30 0 3292 6830 8973 1654 i * 2001:780::4 30 0 12337 6830 8973 1654 i * 2001:680:0:1::4 30 0 517 8472 6830 1654 i * 2001:268::/32 2001:680:0:1::4 30 0 517 790 8627 6830 1654 i * 2001:658:0:1::1 30 0 8627 6830 1654 i * 2001:270::/35 2001:600:4:1D1::1 * i2001:288::/35 2001:608:0:3::1 9 100 0 8379 15982 1654 i *>i 2001:608:0:3::5 9 100 0 8379 15982 1654 i (and so on). I'd appreciate if some of their peers could apply some gracious filtering... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert@space.net Wed Aug 14 18:52:39 2002 From: gert@space.net (Gert Doering) Date: Wed, 14 Aug 2002 19:52:39 +0200 Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: <000901c243b6$02e7a6c0$0200000a@hera>; from jorgen@hovland.cx on Wed, Aug 14, 2002 at 07:14:11PM +0200 References: <200208141216.40070.nighthawk@unrealircd.com><20020814153820.U27015@Space.Net> <200208141445.37029.ejb@sdf.lonestar.org> <1029335247.642.26.camel@wks1-1.corp.ndsoftware.com> <000901c243b6$02e7a6c0$0200000a@hera> Message-ID: <20020814195239.J27015@Space.Net> Hi, On Wed, Aug 14, 2002 at 07:14:11PM +0200, Jørgen Hovland wrote: > * 2001:750:E::A 0 15589 1654 i > * i3FFE:1D00::/24 3FFE:82B0:0:1:1::5 > 100 0 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 15982 1654 i > * 2001:750:E::A 0 15589 1654 i Not only 6bone, but RIR space as well. We have no direct peering, so can't really filter them. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From RJorgensen@upctechnology.com Wed Aug 14 18:49:40 2002 From: RJorgensen@upctechnology.com (Jorgensen, Roger) Date: Wed, 14 Aug 2002 19:49:40 +0200 Subject: [6bone] SUNET announcing ALL IPv6 routes Message-ID: <7CEA40C0E10C7D4FBE076AE7C3EFB78D88F261@nlcbbms03> Jorgen, It's not sunet, it's sics that use that ASN. www.sics.se. Check sics@whois.6bone.net. Probably just borrowing the ASN from sunet. Here is what we saw before I shut down the peering: http://www2.ipv6.chello.com/bogus/file0035.html Pretty bad?:) But this is not the first time one ASN is announcing the entire sTLA/pTLA list. It has happend before and would probably happend again. Question is really, how are we suppose to filter this kind of things on a transit peering? Limited amount of prefixes we can accept from an AS? --- Roger Jorgensen (rjorgensen@upctechnology.com) System Engineer @ engineering - UPC Technology handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID > -----Original Message----- > From: Jørgen Hovland [mailto:jorgen@hovland.cx] > Sent: Wednesday, August 14, 2002 7:14 PM > To: 6bone@mailman.isi.edu > Cc: abuse@sunet.se > Subject: [6bone] SUNET announcing ALL IPv6 routes > Importance: High > > > Anybody alive from sunet here? You are announcing every route > with your AS as last-hop. > It is causing us CRITICAL downtime, and probably more than > half of all the other STLA/pTLA's too. > > Anybody peering with SUNET: please fix this. > > ...snip... > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:1D00::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > Network Next Hop Metric LocPrf Weight Path > * i3FFE:1E00::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * i3FFE:1F00::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:2000::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:2100::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:2200::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:2400::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:2500::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > * 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * i3FFE:2600::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > Network Next Hop Metric LocPrf Weight Path > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > *>i3FFE:2610:2::/48 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 3274 8432 i > *>i3FFE:2610:10::/48 > 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 3274 1342 i > *>i3FFE:2650:1::/48 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 3274 8812 i > *>i3FFE:26FF:8::/48 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 3274 24751 i > *>i3FFE:26FF:A::/48 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 3274 16023 i > *>i3FFE:26FF:10::/48 > 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 3274 8145 i > * i3FFE:2800::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:2900::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 2001:750:E::A 0 > 15589 1654 i > *>i3FFE:2900:2004::/48 > 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 8002 4538 65272 i > * 3FFE:2A00::/24 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > * 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:2B00::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:2C00::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:2F00::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > Network Next Hop Metric LocPrf Weight Path > * i3FFE:3100::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:3200::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > *>i3FFE:327E:1::/48 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 8002 4538 65272 i > * i3FFE:3300::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:3400::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:3500::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:3600::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:3700::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:3800::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > Network Next Hop Metric LocPrf Weight Path > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:3900::/24 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:4000::/32 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:4003::/32 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * i3FFE:4004::/32 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * 3FFE:4005::/32 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > *>i3FFE:4005:A::/48 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 8002 4538 65272 i > * i3FFE:4006::/32 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * i3FFE:4007::/32 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > * 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > *> 3FFE:82B0:0:1:1::19 > 0 > 15982 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * 3FFE:4008::/32 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > * 2001:750:E::A 0 > 15589 1654 i > * 3FFE:4009::/32 3FFE:82B0:0:1:1::15 > 0 > 24765 1654 i > * i3FFE:400A::/32 3FFE:82B0:0:1:1::5 > 100 0 > 6830 1654 i > > > Joergen Hovland > WebOnline AS > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From nicolas.deffayet@ndsoftware.net Wed Aug 14 18:59:31 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 14 Aug 2002 19:59:31 +0200 Subject: [6bone] Problem with AS1654 Message-ID: <1029347971.674.85.camel@wks1-1.corp.ndsoftware.com> Hi all, Problem with AS1654: they announce all prefix originate from their AS. route-server.ndsoftwarenet.net> show ipv6 bgp regexp 1654 BGP table version is 0, local router ID is 10.0.1.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i2001:200::/35 3ffe:81f1:0:1::1 600 100 0 1654 i * i 3ffe:81f1:0:1::1 600 100 0 1654 i *>i2001:208::/32 3ffe:81f1:0:1::1 600 100 0 1654 i * i 3ffe:81f1:0:1::1 600 100 0 1654 i *>i2001:210::/35 3ffe:81f1:0:1::1 600 100 0 1654 i * i 3ffe:81f1:0:1::1 600 100 0 1654 i *>i2001:218::/35 3ffe:81f1:0:1::1 600 100 0 1654 i * i 3ffe:81f1:0:1::1 600 100 0 1654 i *>i2001:220::/35 3ffe:81f1:0:1::1 600 100 0 1654 i * i 3ffe:81f1:0:1::1 600 100 0 1654 i *>i2001:228::/35 3ffe:81f1:0:1::1 600 100 0 1654 i * i 3ffe:81f1:0:1::1 600 100 0 1654 i *>i2001:230::/35 3ffe:81f1:0:1::1 600 100 0 1654 i * i 3ffe:81f1:0:1::1 600 100 0 1654 i *>i2001:238::/35 3ffe:81f1:0:1::1 600 100 0 1654 i * i 3ffe:81f1:0:1::1 600 100 0 1654 i *>i2001:240::/32 3ffe:81f1:0:1::1 600 100 0 1654 i * i 3ffe:81f1:0:1::1 600 100 0 1654 i *>i2001:240::/35 3ffe:81f1:0:1::1 600 100 0 1654 i * i 3ffe:81f1:0:1::1 600 100 0 1654 i *>i2001:248::/35 3ffe:81f1:0:1::1 600 100 0 1654 i * i 3ffe:81f1:0:1::1 600 100 0 1654 i Total number of prefixes 252 route-server.ndsoftwarenet.net> telnet route-server.ndsoftwarenet.net for complete list. Best Regards, Nicolas DEFFAYET From tvo@EnterZone.Net Wed Aug 14 19:00:52 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 14:00:52 -0400 (EDT) Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: Message-ID: On Wed, 14 Aug 2002, Fredrik Widell wrote: > On Wed, 14 Aug 2002, John Fraizer wrote: > > > > > May I make the humble request that anyone who peers with SUNET admin-down > > the sessions until such time as the clue delivery can be made to them? > > > Well, actually, this is not sunet doing this, this is a customer of > sunet who is borrowing an as from us having not one of their own, > hopefully we will make them stop quite soon. > > OK. ipv6-site: SICS origin: AS1654 descr: Swedish Institute of Computer Science Kista, SWEDEN country: SE prefix: 3FFE:200::/24 person: Lars Albertsson address: SICS (Swedish Institute of Computer Science) phone: +46 8 633 15 51 e-mail: lalle@sics.se nic-hdl: LAL1-6BONE remarks: Nickname Lalle notify: lalle@sics.se changed: lalle@sics.se 20010119 source: 6BONE person: Mikael Nehlsen address: SICS (Swedish Institute of Computer Science) phone: +46 8 633 1553 e-mail: joyride@sics.se nic-hdl: JOY1-6BONE notify: joyride@sics.se changed: joyride@sics.se 20010626 source: 6BONE Will anyone who peers with SICS please admin down the peering session until the clue delivery is completed? SICS: You're announcing everything with 1654 as the origin AS. It is causing problems for many people on the v6 network. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From jesper@skriver.dk Wed Aug 14 19:08:47 2002 From: jesper@skriver.dk (Jesper Skriver) Date: Wed, 14 Aug 2002 20:08:47 +0200 Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: References: <000901c243b6$02e7a6c0$0200000a@hera> Message-ID: <20020814180847.GA9473@skriver.dk> On Wed, Aug 14, 2002 at 01:40:41PM -0400, John Fraizer wrote: > > > On Wed, 14 Aug 2002, [iso-8859-1] Jørgen Hovland wrote: > > > Anybody alive from sunet here? You are announcing every route with > > your AS as last-hop. It is causing us CRITICAL downtime, and probably > > more than half of all the other STLA/pTLA's too. > > > > Anybody peering with SUNET: please fix this. > > > > ...snip... > > * 2001:750:E::A 0 15589 1654 i > > * i3FFE:1D00::/24 3FFE:82B0:0:1:1::5 > > 100 0 6830 1654 i > > * 3FFE:82B0:0:1:1::15 > > 0 24765 1654 i > > *> 3FFE:82B0:0:1:1::19 > > 0 15982 1654 i > > * 2001:750:E::A 0 15589 1654 i > > Network Next Hop Metric LocPrf Weight Path > > * i3FFE:1E00::/24 3FFE:82B0:0:1:1::5 > > 100 0 6830 1654 i > > > Cute. > > SUNET (ASN-SWEDEN) > SUNET/KTH > SE > > Autonomous System Name: SWEDEN > Autonomous System Number: 1654 > > Record last updated on 30-Dec-1991. > Database last updated on 13-Aug-2002 20:01:19 EDT. > > > That should be illegal. No contact information, what-so-ever. > > May I make the humble request that anyone who peers with SUNET admin-down > the sessions until such time as the clue delivery can be made to them? AS1653 is their production AS the contact details is: role: KTHNOC Royal Institute of Technology Network Operating Centre address: Royal Institute of Technology address: KTHNOC address: S-100 44 STOCKHOLM address: Sweden phone: +46 8 790 6000 fax-no: +46 8 24 11 79 e-mail: kthnoc@sunet.se trouble: ----------------------------------------------------- trouble: For operational problems contact kthnoc@sunet.se trouble: in case of abuse originating from AS1653 or customers trouble: thereof, please contact abuse@sunet.se, otherwise trouble: atleast do a traceroute and contact the correct ISP. trouble: ----------------------------------------------------- admin-c: FW526-RIPE tech-c: FW526-RIPE tech-c: BEGO1-RIPE tech-c: MAT17-RIPE tech-c: JOG4-RIPE tech-c: MN1334-RIPE tech-c: BJRH1-RIPE tech-c: PNI2-RIPE tech-c: HAFI1-RIPE tech-c: JONI3-RIPE tech-c: BE10 nic-hdl: NOC34-RIPE remarks: We run SUNET and NORDUnet notify: kthnoc@sunet.se mnt-by: SUNET-MNT changed: fredrik@sunet.se 20020417 changed: fredrik@sunet.se 20020606 source: RIPE /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Senior network engineer @ AS3292, TDC Tele Danmark One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. From jeroen@unfix.org Wed Aug 14 19:07:44 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Wed, 14 Aug 2002 20:07:44 +0200 Subject: [6bone] pTLA request by Euro6IX project for In-Reply-To: <5.1.0.14.0.20020814082139.033a96a8@imap2.es.net> Message-ID: <001101c243bd$7d226040$850d640a@unfix.org> Bob Fink wrote: > Freenet6 helps, but can't be expected to handle all the demand. Fortunatly there are MANY others; check out http://hs247.com and not to forget http://dmoz.org/Computers/Internet/Protocols/IP/IPng/ Also, IPv6 is a *lot* bigger out side of the US ;) Greets, Jeroen From gert@space.net Wed Aug 14 19:22:52 2002 From: gert@space.net (Gert Doering) Date: Wed, 14 Aug 2002 20:22:52 +0200 Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: ; from tvo@EnterZone.Net on Wed, Aug 14, 2002 at 01:40:41PM -0400 References: <000901c243b6$02e7a6c0$0200000a@hera> Message-ID: <20020814202252.L27015@Space.Net> Hi, On Wed, Aug 14, 2002 at 01:40:41PM -0400, John Fraizer wrote: > Cute. > > SUNET (ASN-SWEDEN) > SUNET/KTH > SE > > Autonomous System Name: SWEDEN > Autonomous System Number: 1654 > > Record last updated on 30-Dec-1991. > Database last updated on 13-Aug-2002 20:01:19 EDT. > > > That should be illegal. No contact information, what-so-ever. The RA-DB has contact information, but I have some doubts that it's correct - BC is known to have some in-depth BGP understanding... $ whois -h whois.ra.net AS1654 aut-num: AS1654 as-name: UNSPECIFIED descr: Test AS import: from AS2603 action pref=100; accept ANY import: from AS1653 action pref=100; accept ANY import: from AS12381 action pref=100; accept ANY export: to AS2603 announce AS1654 export: to AS1653 announce AS1654 export: to AS12381 announce AS1654 admin-c: BC83-RIPE tech-c: BC83-RIPE mnt-by: BC-MNT changed: bc@sunet.se 20010321 source: RIPE person: Bjorn Carlsson address: EBONE address: Parkvagen 2A address: S-16935 Solna address: Sweden phone: +46 (0)8 7906601 fax-no: +46 (0)8 241179 e-mail: bc@ebone.net nic-hdl: BC83-RIPE mnt-by: BC-MNT changed: bc@ebone.net 20010412 source: RIPE Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From tvo@EnterZone.Net Wed Aug 14 19:33:02 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 14:33:02 -0400 (EDT) Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: <7CEA40C0E10C7D4FBE076AE7C3EFB78D88F261@nlcbbms03> Message-ID: On Wed, 14 Aug 2002, Jorgensen, Roger wrote: > Jorgen, > > It's not sunet, it's sics that use that ASN. www.sics.se. > Check sics@whois.6bone.net. > > Probably just borrowing the ASN from sunet. Here is what we > saw before I shut down the peering: > http://www2.ipv6.chello.com/bogus/file0035.html > Pretty bad?:) OK. I'm not trying to sound elitist here but, if an organization doesn't have their OWN ASN, and the associated clue, why on earth would you risk an open, no filtering, peering session with them? I'm not saying that an organization having an ASN (their own) is equal to an organization having clue but, it is more likely than not. > But this is not the first time one ASN is announcing the entire sTLA/pTLA > list. It has happend before and would probably happend again. > Question is really, how are we suppose to filter this kind of things on > a transit peering? Limited amount of prefixes we can accept from an AS? If they don't have their own ASN, filter tightly. If they screw up like this, filter even more tightly. If you accept transit from someone, prefix-list filter them like so: neighbor 3ffe:xxxx:xxxx:x::x activate neighbor 3ffe:xxxx:xxxx:x::x next-hop-self neighbor 3ffe:xxxx:xxxx:x::x prefix-list subTLA-only out neighbor 3ffe:xxxx:xxxx:x::x route-map AS-SOMEPEER in ! ipv6 prefix-list AS-SOMEPEER seq 10 permit 3ffe:xxxx::/32 ipv6 prefix-list AS-SOMEPEER seq 20 permit 2001:xxxx::/32 ipv6 prefix-list subTLA-only seq 1 permit 3ffe:1ced::/32 ipv6 prefix-list subTLA-only seq 5 permit 3ffe::/18 ge 24 le 24 ipv6 prefix-list subTLA-only seq 10 permit 3ffe:4000::/18 ge 32 le 32 ipv6 prefix-list subTLA-only seq 15 permit 3ffe:8000::/20 ge 28 le 28 ipv6 prefix-list subTLA-only seq 20 permit 2000::/3 ge 16 le 16 ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35 ipv6 prefix-list subTLA-only seq 30 permit 2002::/16 ipv6 prefix-list subTLA-only seq 500 deny any ! ip as-path access-list AS-SOMEPEER permit ^(_NNNNN)+$ ! route-map AS-SOMEPEER permit 10 match ipv6 address prefix-list AS-SOMEPEER match ipv6 address prefix-list subTLA-only match as-path AS-SOMEPEER ! route-map AS-SOMEPEER permit 20 match ipv6 address prefix-list AS-SOMEPEER match as-path AS-SOMEPEER set community no-export additive ! route-map AS-SOMEPEER deny 30 match as-path AS-SOMEPEER ! route-map AS-SOMEPEER permit 40 match ipv6 address prefix-list subTLA-only ! In the first route-map stanza, we accept their prefixes that are not more specific than the allocation boundries, as long as they show their ASN as the origin. In the second route-map stanza, we accept any "more specifics" that we might have put in their prefix-list, as long as they show their ASN as the origin but, since we don't want to leak these more specifics to the global tables, we tag them as no-export. In the third route-map stanza, we deny anything else that they send us that shows THEM as the origin. This keeps them from announcing every prefix on the planet with them as the origin (like the case we're discussing). In the fourth route-map stanza, we accept anything that has not been denied (didn't match their prefix-list but, did match their origin) as long as it is within the allocation boundries. This will allow you to accept transit from them (within the allocation boundries) but, won't allow them to screw up like they did today. Simple, huh? I love problem solving! Filter, filter, filter on both ingress and egress. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From dios-vol@telecom.noc.udg.mx Wed Aug 14 19:28:39 2002 From: dios-vol@telecom.noc.udg.mx (Harold de Dios Tovar Volunt) Date: Wed, 14 Aug 2002 13:28:39 -0500 (CDT) Subject: [6bone] Could someone filter AS1654, please? In-Reply-To: <20020814195054.I27015@Space.Net> Message-ID: We have this result from our side about AS1654 and seems to be ok... sh bgp ipv6 regexp 1654 BGP table version is 130902, local router ID is 148.202.15.8 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 2001:618:B::/48 3FFE:C00:8023:2F::1 0 109 8002 1654 64633 i *> 2001:658:217::/48 3FFE:C00:8023:2F::1 0 109 15180 6939 9044 1654 64633 i *> 2001:768:1800::/40 3FFE:C00:8023:2F::1 0 109 15180 6939 9044 1654 64633 i ** Texto sin acentos ,,, /'^'\ ( o o ) N.O.C & IPv6 staff working Group --oOOo--(_)--oOOo--------------------------------- |___|___|___|___|___|___|___|___|___|___|___|___|__ |___|___|___|___| Harold de Dios, harold@noc.udg.mx |__ __|_.oooO_|___|___| UdeG, Network Operation Center |__ ____( )___Oooo.___| Work: 011(52)3331342232 ext.2220 | -----\ (----( )---------------------------------------- \ On Wed, 14 Aug 2002, Gert Doering wrote: > Hi, > > I have no idea what they are doing, but I don't like the result - 1654 > seems to re-announce all current IPv6 routes under their own AS as origin: > > cisco25#sh bgp ipv6 reg 1654$ > BGP table version is 2014133, local router ID is 193.149.44.35 > Status codes: s suppressed, d damped, h history, * valid, > best, i - internal > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > * i2001:208::/32 2001:608:0:3::1 9 100 0 8379 15982 1654 i > *>i 2001:608:0:3::5 9 100 0 8379 15982 1654 i > * 3FFE:2A00:100:7FF3::1 > 30 0 2603 1275 5609 1654 i > * 2001:658:0:1::1 30 0 8627 6830 8973 1654 i > * 2001:608:0:3::B 30 0 3292 6830 8973 1654 i > * 2001:780::4 30 0 12337 6830 8973 1654 i > * 2001:680:0:1::4 30 0 517 790 6830 8973 1654 i > * 3FFE:8150:0:1::17 > 200 0 9044 8002 5609 1654 i > * i2001:210::/35 2001:608:0:3::1 9 100 0 8379 15982 1654 i > *>i 2001:608:0:3::5 9 100 0 8379 15982 1654 i > [truncated] > * i2001:238::/35 2001:608:0:3::1 9 100 0 8379 15982 1654 i > *>i 2001:608:0:3::5 9 100 0 8379 15982 1654 i > * 2001:240::/35 2001:658:0:1::1 30 0 8627 6830 1654 i > * 2001:240::/32 2001:658:0:1::1 30 0 8627 6830 1654 i > * 2001:680:0:1::4 30 0 517 790 8627 6830 1654 i > * 2001:248::/35 2001:608:0:3::B 30 0 3292 6830 8973 1654 i > * i2001:250::/35 2001:608:0:3::1 9 100 0 8379 15982 1654 i > *>i 2001:608:0:3::5 9 100 0 8379 15982 1654 i > * 2001:260::/35 2001:608:0:3::B 30 0 3292 6830 8973 1654 i > * 2001:780::4 30 0 12337 6830 8973 1654 i > * 2001:680:0:1::4 30 0 517 8472 6830 1654 i > * 2001:268::/32 2001:680:0:1::4 30 0 517 790 8627 6830 1654 i > * 2001:658:0:1::1 30 0 8627 6830 1654 i > * 2001:270::/35 2001:600:4:1D1::1 > * i2001:288::/35 2001:608:0:3::1 9 100 0 8379 15982 1654 i > *>i 2001:608:0:3::5 9 100 0 8379 15982 1654 i > > (and so on). > > I'd appreciate if some of their peers could apply some gracious filtering... > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 46871 (46631) > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From Robert.Kiessling@de.easynet.net Wed Aug 14 19:56:07 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 14 Aug 2002 19:56:07 +0100 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: References: Message-ID: John Fraizer writes: > Looking from AS7660's point of view at > http://www.jp.apan.net/cgi-bin/ipv6/mrlg Well, this is one of their routers. Though not that one peering with the ASes which show up before 7660 in the ghost paths (10109 and 22388). Robert From michel@arneill-py.sacramento.ca.us Wed Aug 14 19:47:24 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 14 Aug 2002 11:47:24 -0700 Subject: [6bone] the end of ngtrans Message-ID: <2B81403386729140A3A899A8B39B046405E27C@server2000.arneill-py.sacramento.ca.us> > Bill Manning wrote: > There are no plans to depricate the mailing list. Forgive me if I ask dumb questions, but have you heard anything about the informal oversight being transferred to v6ops, or to Bob Fink (which I believe is the de-facto situation)? What else do we know? Michel. From tvo@EnterZone.Net Wed Aug 14 19:49:58 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 14:49:58 -0400 (EDT) Subject: [6bone] Could someone filter AS1654, please? In-Reply-To: Message-ID: On Wed, 14 Aug 2002, Harold de Dios Tovar Volunt wrote: > We have this result from our side about AS1654 and seems to be ok... > sh bgp ipv6 regexp 1654 > BGP table version is 130902, local router ID is 148.202.15.8 > Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > *> 2001:618:B::/48 3FFE:C00:8023:2F::1 > 0 109 8002 1654 > 64633 i > *> 2001:658:217::/48 > 3FFE:C00:8023:2F::1 > 0 109 15180 > 6939 9044 1654 64633 i > *> 2001:768:1800::/40 > 3FFE:C00:8023:2F::1 > 0 109 15180 > 6939 9044 1654 64633 i > > I still show them as the origin for 63 prefixes from both 6bone and RIR space. It's down from what it was previously but, I'd bet that is the result of folks filtering/downing peering sessions vs them actually fixing their problem. --- 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 Aug 14 20:14:45 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 14 Aug 2002 12:14:45 -0700 Subject: [6bone] pTLA request by Euro6IX project for exchange experimentation - review closes 3 Sep 2002 Message-ID: <2B81403386729140A3A899A8B39B046405E27D@server2000.arneill-py.sacramento.ca.us> Rik, >> Joao Luis Silva Damas wrote: >> Come on, these two cases were OK up to the point where >> people could not get any other type of IPv6 addresses >> but now they are just normal businness. >> Rik van Riel wrote: >> Yeah right. I doubt ipv6 is that widely >> available already. You might want to read the following thread on the v6ops and/or ngtrans mailing list, started this morning: (ngtrans) v6 considered operational http://ops.ietf.org/lists/v6ops/v6ops.2002/msg00000.html Michel. From admin@euroshells.dk Wed Aug 14 20:17:02 2002 From: admin@euroshells.dk (EuroShells.dk) Date: Wed, 14 Aug 2002 21:17:02 +0200 Subject: [6bone] Just a few newbie questions Message-ID: <008501c243c7$2bf3dc30$0402a050@druidlaptop> This is a multi-part message in MIME format. ------=_NextPart_000_0082_01C243D7.EF31E790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey all! Interested in trying to peer with someone how do I proceed? I am mostly interested in knowing what kind of equipment/software is = needed. Like Cisco routers (I have a 1605 and a 806 here) and/or Linux box... = which of those would be preferred? Med venlig hilsen // Best Regards =20 Rasmus Haslund System Administrator EuroShells.dk =20 Phone: +45 86 - 19 19 34=20 Direct: +45 26 - 80 60 13=20 E-mail: admin@euroshells.dk Web: http://www.euroshells.dk ------=_NextPart_000_0082_01C243D7.EF31E790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hey all!
 
Interested in trying to peer with = someone how do I=20 proceed?
 
I am mostly interested in knowing what = kind of=20 equipment/software is needed.
Like Cisco routers (I have a 1605 and a = 806 here)=20 and/or Linux box... which of those would be preferred?
 
Med venlig hilsen // Best=20 Regards
 
Rasmus Haslund

System Administrator
EuroShells.dk
 
Phone: +45 = 86 - 19=20 19 34
Direct: +45 26 - 80 60 13
E-mail: admin@euroshells.dk
Web: http://www.euroshells.dk ------=_NextPart_000_0082_01C243D7.EF31E790-- From tvo@EnterZone.Net Wed Aug 14 20:18:17 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 15:18:17 -0400 (EDT) Subject: [6bone] 3ffe:1ced::/32 is being returned to MERIT Message-ID: As indicated in our application for pTLA space, EnterZone has now completely renumbered out of 3ffe:1ced::/32 and into our new RIR and pTLA space. We now officially relinquish this prefix back to MERIT. I would like to thank all the operators who made modifications to your filters to allow our announcement of this deaggregated prefix during the interim. AS13944 just retracted all announcements for 3ffe:1ced::/32. You may now tighten your filters back up. MERIT: Um, our tunnel is still down. You did make the modification of the v4 endpoint but, must have missed the part about the v6 addresses for each end of the tunnel. If you would like to maintain a BGP peering session with EnterZone, please contact us and we will assign new v6 addresses for the tunnel and configure a BGP peering session. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From dios-vol@telecom.noc.udg.mx Wed Aug 14 20:21:24 2002 From: dios-vol@telecom.noc.udg.mx (Harold de Dios Tovar Volunt) Date: Wed, 14 Aug 2002 14:21:24 -0500 (CDT) Subject: [6bone] Just a few newbie questions In-Reply-To: <008501c243c7$2bf3dc30$0402a050@druidlaptop> Message-ID: Hi Rasmus, if you want to know about cisco IPv6 implementations check this web page http://www.cisco.com/warp/public/732/Tech/ipv6/ about linux and others implementations visit www.ipv6.org best regards.. ** Texto sin acentos ,,, /'^'\ ( o o ) N.O.C & IPv6 staff working Group --oOOo--(_)--oOOo--------------------------------- |___|___|___|___|___|___|___|___|___|___|___|___|__ |___|___|___|___| Harold de Dios, harold@noc.udg.mx |__ __|_.oooO_|___|___| UdeG, Network Operation Center |__ ____( )___Oooo.___| Work: 011(52)3331342232 ext.2220 | -----\ (----( )---------------------------------------- \ On Wed, 14 Aug 2002, EuroShells.dk wrote: > > Hey all! > > Interested in trying to peer with someone how do I proceed? > > I am mostly interested in knowing what kind of equipment/software is needed. > Like Cisco routers (I have a 1605 and a 806 here) and/or Linux box... which of those would be preferred? > > Med venlig hilsen // Best Regards > > Rasmus Haslund > > System Administrator > EuroShells.dk > > Phone: +45 86 - 19 19 34 > Direct: +45 26 - 80 60 13 > E-mail: admin@euroshells.dk > Web: http://www.euroshells.dk > From tvo@EnterZone.Net Wed Aug 14 20:27:37 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 15:27:37 -0400 (EDT) Subject: [6bone] MRLG patch In-Reply-To: Message-ID: Jeff, What version is that patch against? Just so we get the right results. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On Wed, 14 Aug 2002, Jeff Barrow wrote: > > Try this patch... and in the cfg file, add > login_user => 'username', > to the $::Routers entry for hosts that need a username. > > I don't have any routers that need usernames to test this with, so > feedback is welcome. :) > > Can't help you on the fastping tho; it never did compile on my Slackware > 7.0 box either; I just configured it to use the normal system /bin/ping > instead. Doesn't seem to hurt anything. > > btw, great program, John! > > --Jeff Barrow, Internet Connections, Inc. > > On Wed, 14 Aug 2002, Wim Biemolt wrote: > > > > > > > ==> From: John Fraizer > > > > > New and improved code is available at > > > ftp://ftp.enterzone.net/looking-glass/CURRENT/ ) > > > > Feature request: handle routers who need username + password. > > (And fastping.c doesn't seem to compile on my 4.6-STABLE box.) > > > > -Wim -/- SURFnet > > > > _______________________________________________ > > 6bone mailing list > > 6bone@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/6bone > > > From RJorgensen@upctechnology.com Wed Aug 14 20:23:46 2002 From: RJorgensen@upctechnology.com (Jorgensen, Roger) Date: Wed, 14 Aug 2002 21:23:46 +0200 Subject: [6bone] SUNET announcing ALL IPv6 routes Message-ID: <7CEA40C0E10C7D4FBE076AE7C3EFB78D88F263@nlcbbms03> Hi, Got some feedback from sunet about this and seems like they've /dev/null'ed the IPv4 IP for their endpoint as a temporarly workaround for now. Thanks for the help SUNET!:) Next issue, now I think we have alot of ghost routes to fight... --- Roger Jorgensen (rjorgensen@upctechnology.com) System Engineer @ engineering - UPC Technology handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Wednesday, August 14, 2002 7:53 PM > To: Jørgen Hovland > Cc: 6bone@mailman.isi.edu; abuse@sunet.se > Subject: Re: [6bone] SUNET announcing ALL IPv6 routes > > > Hi, > > On Wed, Aug 14, 2002 at 07:14:11PM +0200, Jørgen Hovland wrote: > > * 2001:750:E::A > 0 15589 1654 i > > * i3FFE:1D00::/24 3FFE:82B0:0:1:1::5 > > 100 > 0 6830 1654 i > > * 3FFE:82B0:0:1:1::15 > > > 0 24765 1654 i > > *> 3FFE:82B0:0:1:1::19 > > > 0 15982 1654 i > > * 2001:750:E::A > 0 15589 1654 i > > Not only 6bone, but RIR space as well. > > We have no direct peering, so can't really filter them. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: > 46871 (46631) > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From ejb@sdf.lonestar.org Wed Aug 14 20:37:57 2002 From: ejb@sdf.lonestar.org (Edward Brocklesby) Date: Wed, 14 Aug 2002 20:37:57 +0100 Subject: [6bone] Routing artifacts after today's AS1654 problems. Message-ID: <200208142037.57113.ejb@sdf.lonestar.org> Well, let's look at AS paths to a sample network, 3ffe:1400::/24. us: 24643 6830 2012 6939 2497 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 us: 6939 2497 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 fubar lg: 6939 2497 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 fubar lg: 24765 3320 293 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 ndsoftware route-server: 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 Now, let's align these at point of origin: (hope you have good fixed-width font) 24643 6830 2012 6939 2497 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 6939 2497 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 6939 2497 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 24765 3320 293 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 ===^^ Interesting? ;-) Several other netblock have the exact same as-path[1], with the same alignment at AS33, which appears to be DEC. Looks to me like some more ghosted routes, but maybe someone with more experience likes to comment? (Sorry this mail isn't quite as thorough as the last one, but I'm really quite knackered. If I've missed anything vital, feel free to ask ;-) Regards, -larne. [1] At the time of writing: 3ffe:1400::/24, 3ffe:1b00::/24, 3ffe:1e00::/24, 3ffe:1f00::/24, 3ffe:2f00::/24, 3ffe:3400::/24, 3ffe:8060::/28. From admin@euroshells.dk Wed Aug 14 20:58:58 2002 From: admin@euroshells.dk (EuroShells.dk) Date: Wed, 14 Aug 2002 21:58:58 +0200 Subject: [6bone] Just a few newbie questions References: Message-ID: <00d901c243cd$07717d30$0402a050@druidlaptop> > Hi Rasmus, if you want to know about cisco IPv6 implementations check this > web page http://www.cisco.com/warp/public/732/Tech/ipv6/ > about linux and others implementations visit www.ipv6.org Hey Harold! I was having a look at www.ipv6.org, but I cant seem to find any information on what to do if I wanted to start peering... at the moment I have a /64 tunnel trough tele.dk //Rasmus Haslund From tvo@EnterZone.Net Wed Aug 14 21:00:56 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 16:00:56 -0400 (EDT) Subject: [6bone] Just a few newbie questions In-Reply-To: <008501c243c7$2bf3dc30$0402a050@druidlaptop> Message-ID: On Wed, 14 Aug 2002, EuroShells.dk wrote: > > Hey all! > > Interested in trying to peer with someone how do I proceed? > > I am mostly interested in knowing what kind of equipment/software is > needed. Like Cisco routers (I have a 1605 and a 806 here) and/or Linux > box... which of those would be preferred? > > Med venlig hilsen // Best Regards > > Rasmus Haslund > Hi there Rasmus, Well, you came to the right place. I'm not sure about the v6 capabilities of the 1605 or the 806, perhaps Paul can answer that. You can contact him at Paul Aitken or ipv6-support@cisco.com (sorry, couldn't resist!) On the Linux front, Zebra ( http://www.zebra.org/ ) and iproute are your friends. There are many v6 networks running on this platform, including mine. I can help you out there. It looks like its about a 136ms RTT from our network to your laptop. --- 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 Aug 14 21:01:56 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Wed, 14 Aug 2002 17:01:56 -0300 (BRT) Subject: [6bone] pTLA request by Euro6IX project for exchange experimentation - review closes 3 Sep 2002 In-Reply-To: <2B81403386729140A3A899A8B39B046405E27D@server2000.arneill-py.sacramento.ca.us> Message-ID: On Wed, 14 Aug 2002, Michel Py wrote: > >> Joao Luis Silva Damas wrote: > >> Come on, these two cases were OK up to the point where > >> people could not get any other type of IPv6 addresses > >> but now they are just normal businness. > > >> Rik van Riel wrote: > >> Yeah right. I doubt ipv6 is that widely > >> available already. > > You might want to read the following thread on the v6ops and/or ngtrans > mailing list, started this morning: (ngtrans) v6 considered operational > > http://ops.ietf.org/lists/v6ops/v6ops.2002/msg00000.html That's nice and all, but I'd hate it if that would mean a bunch of IX folks would declare the 6bone obsolete and I'd be without ipv6 connectivity until my ISP starts offering it, some undetermined time into the future. 6bone is here to stay for quite a while more... kind regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From tvo@EnterZone.Net Wed Aug 14 21:08:45 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 16:08:45 -0400 (EDT) Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: <7CEA40C0E10C7D4FBE076AE7C3EFB78D88F263@nlcbbms03> Message-ID: On Wed, 14 Aug 2002, Jorgensen, Roger wrote: > Hi, > > Got some feedback from sunet about this and seems like they've /dev/null'ed > the IPv4 IP for their endpoint as a temporarly workaround for now. > Thanks for the help SUNET!:) > > > Next issue, now I think we have alot of ghost routes to fight... > > > --- > Roger Jorgensen (rjorgensen@upctechnology.com) Cool. That we can do but, in the process, we need to document what router platform/code version the people sending the ghost routes are running. This is a very important operational issue, more important that actually getting the original announcements to stop. If you are an operator who peers with someone that is found to be ORIGINATING the ghost routes, please, find out what code they're running and let the list know. This "bug" has bitten us too many times already and needs to be squashed. If we compile a list of "bad code", folks will know to avoid using that code and/or peering with folks using that code. The root problem will never get fixed until we take measures to document it. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From paitken@cisco.com Wed Aug 14 21:08:40 2002 From: paitken@cisco.com (Paul Aitken) Date: Wed, 14 Aug 2002 21:08:40 +0100 Subject: [6bone] Just a few newbie questions References: Message-ID: <3D5AB8C8.8080902@cisco.com> > Hi Rasmus, if you want to know about cisco IPv6 implementations check this > web page http://www.cisco.com/warp/public/732/Tech/ipv6/ or more simply, http://www.cisco.com/ipv6 - it's a redirect to the same URL as above, but it's a lot eaasier to remember! > Like Cisco routers (I have a 1605 and a 806 here) and/or Linux box You can run IPv6 on any of these platforms. You can find relevant IOS images using either Cisco Feature Navigator at http://www.cisco.com/go/fn or Cisco Software Advisor at http://www.cisco.com/go/swadvisor. > which of those would be preferred? Without more info, I'd say they're probably all equally as good. But if the routers don't have enough FLASH to load an IPv6 IOS image then you'll have to use the linux box. But again, if the linux box is running on low-end hardware then maybe one of the cisco routers is a good choice? Cheers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From jorgen@hovland.cx Wed Aug 14 21:12:20 2002 From: jorgen@hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 14 Aug 2002 22:12:20 +0200 Subject: [6bone] SUNET announcing ALL IPv6 routes References: Message-ID: <011e01c243ce$e5fde1a0$0200000a@hera> Since SICS have shut down their router now, it might help us to be able to traceback the ASN(s) who are making all the zombie-routes. There are still a lot of prefixes in the routing table with origin as1654. For i2001:2F8::/35 there must be one of these three 6939 14277 8002 We know its not 6830, right Roger? And most likely not Edisontel, right Edisontel? 6969 HE.NET 14277 NOKIA 8002 STEALTH The other route-paths are long. They all end with STEALTH before they reach SICS. I dont believe the ones we peer with are generating these routes so I have skipped those (but you never know). 33 DEC.com 10318 LACNIC.net 12199 <- Nonexisting, who is using this? 145 MCI 7580 TRUMPET.com.au 10566 Viagenie 5408 GRNET.gr 2549 LACNIC.net 109 CISCO 5539 SPACE.net 8379 EUROCYBER.net 1275 C&W ecrc.de Its probably not Viagenie, nor Cisco (god forbid), nor Space, nor MCI, nor Eurocyber? DEC, LACNIC, GRNET, C&W, TRUMPET and as12199 is left. As you say John, OS and version if you are announcing ghost-routes please. Network Next Hop Metric LocPrf Weight Path * i2001:2F8::/35 3FFE:82B0:0:1:1::5 100 0 6830 6939 14277 8002 1654 i * 2001:750:E::A 0 15589 6939 14277 8002 1654 i * i2001:388::/35 3FFE:82B0:0:1:1::5 100 0 6830 6939 14277 8002 1654 i * 2001:750:E::A 0 15589 6939 14277 8002 1654 i * i2001:388::/32 3FFE:82B0:0:1:1::5 100 0 6830 6939 14277 8002 1654 i * 2001:750:E::A 0 15589 6939 14277 8002 1654 i * i2001:4E0::/32 3FFE:82B0:0:1:1::5 100 0 6830 6939 14277 8002 1654 i * 2001:750:E::A 0 15589 6939 14277 8002 1654 i * i2001:6F0::/35 3FFE:82B0:0:1:1::5 100 0 6830 12337 8319 3561 3748 8002 5609 1275 20834 3274 1654 i *> 3FFE:82B0:0:1:1::19 0 15982 8379 8319 3561 3748 8002 5609 1275 20834 3274 1654 i * 3FFE:82B0:0:1:1::15 0 24765 8379 8319 3561 3748 8002 5609 1275 20834 3274 1654 i * 2001:750:E::A 0 15589 12337 8319 3561 3748 8002 5609 1275 20834 3274 1654 i *> 3FFE:200::/24 2001:750:E::A 0 15589 33 10318 12199 237 3748 3786 10566 1930 2200 1916 11537 22 109 5539 8379 1275 8002 1654 i * i 3FFE:82B0:0:1:1::5 100 0 6830 6175 10318 33 5609 6939 4716 2497 4697 2914 1916 11537 22 109 5539 8379 1275 8002 1654 i * 3FFE:82B0:0:1:1::19 0 15982 6830 6175 10318 33 5609 6939 4716 2497 4697 2914 1916 11537 22 109 5539 8379 1275 8002 1654 i * 3FFE:82B0:0:1:1::15 0 24765 6435 6175 10318 33 5609 6939 4716 2497 4697 2914 1916 11537 22 109 5539 8379 1275 8002 1654 i * 3FFE:1100::/24 3FFE:82B0:0:1:1::19 0 15982 15589 33 10318 12199 237 3748 3786 10566 13193 109 5539 8379 1275 8002 1654 i * 3FFE:82B0:0:1:1::15 0 24765 15589 33 10318 12199 237 3748 3786 10566 13193 109 5539 8379 1275 8002 1654 i *> 2001:750:E::A 0 15589 33 10318 12199 237 3748 3786 10566 13193 109 5539 8379 1275 8002 1654 i * 3FFE:1400::/24 3FFE:82B0:0:1:1::19 0 15982 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:82B0:0:1:1::15 0 24765 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i *> 2001:750:E::A 0 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:1A00::/24 3FFE:82B0:0:1:1::19 Network Next Hop Metric LocPrf Weight Path 0 15982 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:82B0:0:1:1::15 0 24765 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i *> 2001:750:E::A 0 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:1B00::/24 3FFE:82B0:0:1:1::19 0 15982 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:82B0:0:1:1::15 0 24765 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i *> 2001:750:E::A 0 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:1E00::/24 3FFE:82B0:0:1:1::19 0 15982 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:82B0:0:1:1::15 0 24765 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i *> 2001:750:E::A 0 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:1F00::/24 3FFE:82B0:0:1:1::19 0 15982 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:82B0:0:1:1::15 0 24765 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i *> 2001:750:E::A 0 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:2F00::/24 3FFE:82B0:0:1:1::19 0 15982 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:82B0:0:1:1::15 0 24765 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i *> 2001:750:E::A 0 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:3400::/24 3FFE:82B0:0:1:1::19 0 15982 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:82B0:0:1:1::15 0 24765 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i *> 2001:750:E::A 0 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:8060::/28 3FFE:82B0:0:1:1::19 0 15982 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i * 3FFE:82B0:0:1:1::15 0 24765 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i Network Next Hop Metric LocPrf Weight Path *> 2001:750:E::A 0 15589 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 i -joergen hovland ----- Original Message ----- From: "John Fraizer" To: "Jorgensen, Roger" Cc: "'Gert Doering'" ; "Jørgen Hovland" ; <6bone@mailman.isi.edu>; Sent: Wednesday, August 14, 2002 10:08 PM Subject: RE: [6bone] SUNET announcing ALL IPv6 routes > > On Wed, 14 Aug 2002, Jorgensen, Roger wrote: > > > Hi, > > > > Got some feedback from sunet about this and seems like they've /dev/null'ed > > the IPv4 IP for their endpoint as a temporarly workaround for now. > > Thanks for the help SUNET!:) > > > > > > Next issue, now I think we have alot of ghost routes to fight... > > > > > > --- > > Roger Jorgensen (rjorgensen@upctechnology.com) > > > Cool. That we can do but, in the process, we need to document what router > platform/code version the people sending the ghost routes are > running. This is a very important operational issue, more important that > actually getting the original announcements to stop. > > If you are an operator who peers with someone that is found to be > ORIGINATING the ghost routes, please, find out what code they're running > and let the list know. This "bug" has bitten us too many times already > and needs to be squashed. > > If we compile a list of "bad code", folks will know to avoid using that > code and/or peering with folks using that code. > > The root problem will never get fixed until we take measures to document > it. > > > > --- > 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 Aug 14 21:21:58 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 14 Aug 2002 13:21:58 -0700 (PDT) Subject: [6bone] the end of ngtrans In-Reply-To: <2B81403386729140A3A899A8B39B046405E27C@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Aug 14, 2 11:47:24 am" Message-ID: <200208142021.g7EKLwM20901@boreas.isi.edu> v6ops is a newly started group w/ its own list. Bob Fink (currently) manages the 3ffe:: prefix under the perview of the IETF as the 6bone. the 6bone mailing list is independent of either of these two and is run by me. % > Bill Manning wrote: % > There are no plans to depricate the mailing list. % % Forgive me if I ask dumb questions, but have you heard anything about % the informal oversight being transferred to v6ops, or to Bob Fink (which % I believe is the de-facto situation)? What else do we know? % % Michel. % % -- --bill From nicolas.deffayet@ndsoftware.net Wed Aug 14 21:24:40 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 14 Aug 2002 22:24:40 +0200 Subject: [6bone] Just a few newbie questions In-Reply-To: <008501c243c7$2bf3dc30$0402a050@druidlaptop> References: <008501c243c7$2bf3dc30$0402a050@druidlaptop> Message-ID: <1029356680.677.93.camel@wks1-1.corp.ndsoftware.com> On Wed, 2002-08-14 at 21:17, EuroShells.dk wrote: > > Hey all! > > Interested in trying to peer with someone how do I proceed? You need a ASN (you can use private ASN if your peer accept it) and a router for do BGP4+. After ask to a 6bone site for a peering. > > I am mostly interested in knowing what kind of equipment/software is needed. > Like Cisco routers (I have a 1605 and a 806 here) and/or Linux box... which of those would be preferred? For your Cisco routers, you need a IOS with BGP and IPv6 support. For your linux box, you can install Zebra (http://www.zebra.org) Best Regards, Nicolas DEFFAYET From tvo@EnterZone.Net Wed Aug 14 21:42:37 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 16:42:37 -0400 (EDT) Subject: [6bone] SUCCEEDED: delete all 3ffe:1ced::/32 and longer allocations (fwd) Message-ID: All gone, bye bye. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | ---------- Forwarded message ---------- Date: Wed, 14 Aug 2002 13:34:52 -0700 (PDT) From: 6BONE Database Management To: John Fraizer Subject: SUCCEEDED: delete all 3ffe:1ced::/32 and longer allocations Your update was SUCCESSFUL > From: John Fraizer > Subject: delete all 3ffe:1ced::/32 and longer allocations > Date: Wed, 14 Aug 2002 16:34:51 -0400 (EDT) > Msg-Id: The following objects were processed: Delete OK: [inet6num] 3FFE:1CED::/32 Delete OK: [inet6num] 3FFE:1CED:A001::/48 Delete OK: [inet6num] 3FFE:1CED:A002::/48 Delete OK: [inet6num] 3FFE:1CED:A003::/48 Delete OK: [inet6num] 3FFE:1CED:A004::/48 Delete OK: [inet6num] 3FFE:1CED:A005::/48 Delete OK: [inet6num] 3FFE:1CED:A006::/48 Delete OK: [inet6num] 3FFE:1CED:A007::/48 Delete OK: [inet6num] 3FFE:1CED:A008::/48 Delete OK: [inet6num] 3FFE:1CED:A009::/48 Delete OK: [inet6num] 3FFE:1CED:A00B::/48 Delete OK: [inet6num] 3FFE:1CED:A00A::/48 From ejb@sdf.lonestar.org Wed Aug 14 22:12:29 2002 From: ejb@sdf.lonestar.org (Edward Brocklesby) Date: Wed, 14 Aug 2002 22:12:29 +0100 Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: <011e01c243ce$e5fde1a0$0200000a@hera> References: <011e01c243ce$e5fde1a0$0200000a@hera> Message-ID: <200208142212.29745.ejb@sdf.lonestar.org> Jørgen Hovland: > 33 DEC.com I propose DEC as source of ghost routes, mainly due to reasons explained in my earlier mail to the list. Of course, maybe other routers having this problem too; this is why router version information is important (see below.) > 12199 <- Nonexisting, who is using this? Hmm! Are you sure? UUNET Global Research & Development (ASN-UUNET-RD-AS) 3060 Williams Drive Fairfax, VA 22031 US Autonomous System Name: UUNET-RD-AS Autonomous System Number: 12199 Coordinator: Operations, Network (NO37-ARIN) netops@ENG.US.UU.NET +1-800-488-6384 Record last updated on 22-Apr-1999. Database last updated on 13-Aug-2002 20:01:19 EDT. >From http://www.arin.net. -- rest of this route is certainly bogus IMHO -- look, it matches the routes I have. > 145 MCI > 7580 TRUMPET.com.au > 10566 Viagenie > 5408 GRNET.gr > 2549 LACNIC.net > 109 CISCO > 5539 SPACE.net > 8379 EUROCYBER.net > 1275 C&W ecrc.de > As you say John, OS and version if you are announcing ghost-routes please. It would be nice if someone would set about collecting this information from ASs (who might not be reading the list.) I would be happy too (this problem annoys me greatly), but if someone else in a more official position feels they would rather do it, that is probably better ;-) Regards, -larne. From tvo@EnterZone.Net Wed Aug 14 22:27:34 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 17:27:34 -0400 (EDT) Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: <1029359931.677.104.camel@wks1-1.corp.ndsoftware.com> Message-ID: On 14 Aug 2002, Nicolas DEFFAYET wrote: > On Wed, 2002-08-14 at 22:08, John Fraizer wrote: > > > > If you are an operator who peers with someone that is found to be > > ORIGINATING the ghost routes, please, find out what code they're running > > and let the list know. This "bug" has bitten us too many times already > > and needs to be squashed. > > > > If we compile a list of "bad code", folks will know to avoid using that > > code and/or peering with folks using that code. > > > > SICS use Zebra 0.88 on FreeBSD 4.2 > > Their configurations files: http://alt.sics.se/6bone_config/ > > Best Regards, > > Nicolas DEFFAYET > Oh-muh-gawd! I didn't think you could find 0.88 running outside of the Smithsonian! ipv6-site: SICS origin: AS1654 descr: Swedish Institute of Computer Science Kista, SWEDEN country: SE OK SICS, lets get with the program and upgrade! I would think that you probably have some clue floating around the Institute somewhere... Lets put it to use, shall we? Zebra is at 0.93a the current current and there have been MANY, MANY, MANY bug-fixes in addition to the tons of feature additions. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From nicolas.deffayet@ndsoftware.net Wed Aug 14 22:28:25 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 14 Aug 2002 23:28:25 +0200 Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: <011e01c243ce$e5fde1a0$0200000a@hera> References: <011e01c243ce$e5fde1a0$0200000a@hera> Message-ID: <1029360506.3740.113.camel@wks1-1.corp.ndsoftware.com> On Wed, 2002-08-14 at 22:12, Jørgen Hovland wrote: > Since SICS have shut down their router now, it might help us to be able to traceback the ASN(s) who are making all the > zombie-routes. There are still a lot of prefixes in the routing table with origin as1654. > > For i2001:2F8::/35 there must be one of these three 6939 14277 8002 > We know its not 6830, right Roger? And most likely not Edisontel, right Edisontel? > > 6969 HE.NET > 14277 NOKIA > 8002 STEALTH > > The other route-paths are long. > They all end with STEALTH before they reach SICS. > I dont believe the ones we peer with are generating these routes so I have skipped those (but you never know). > > 33 DEC.com > 10318 LACNIC.net > 12199 <- Nonexisting, who is using this? 6bone whois: ---- ipv6-site: UUNET-US origin: AS12199 ---- ARIN whois: ---- UUNET Global Research & Development (ASN-UUNET-RD-AS) 3060 Williams Drive Fairfax, VA 22031 US Autonomous System Name: UUNET-RD-AS Autonomous System Number: 12199 ---- > 145 MCI > 7580 TRUMPET.com.au > 10566 Viagenie > 5408 GRNET.gr > 2549 LACNIC.net > 109 CISCO > 5539 SPACE.net > 8379 EUROCYBER.net > 1275 C&W ecrc.de > > Its probably not Viagenie, nor Cisco (god forbid), nor Space, nor MCI, nor Eurocyber? > DEC, LACNIC, GRNET, C&W, TRUMPET and as12199 is left. > > As you say John, OS and version if you are announcing ghost-routes please. > > > Network Next Hop Metric LocPrf Weight Path > * i2001:2F8::/35 3FFE:82B0:0:1:1::5 > 100 0 6830 6939 14277 8002 1654 i > * 2001:750:E::A 0 15589 6939 14277 8002 1654 i route-server.ndsoftwarenet.net> show ipv6 bgp 2001:2F8::/35 BGP routing table entry for 2001:2f8::/35 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer 5408 8002 1654 3ffe:81f1:0:1::1 from 3ffe:81f1:0:1::1 (213.91.4.3) Origin IGP, metric 700, localpref 100, valid, internal Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Wed Aug 14 20:45:52 2002 9044 8002 1654 3ffe:81f1:0:2::1 from 3ffe:81f1:0:2::1 (62.4.18.114) (fe80::260:97ff:fe0c:9803) Origin IGP, metric 700, localpref 100, valid, internal, best Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Wed Aug 14 20:45:52 2002 route-server.ndsoftwarenet.net> Best Regards, Nicolas DEFFAYET > ----- Original Message ----- > From: "John Fraizer" > To: "Jorgensen, Roger" > Cc: "'Gert Doering'" ; "Jørgen Hovland" ; <6bone@mailman.isi.edu>; > Sent: Wednesday, August 14, 2002 10:08 PM > Subject: RE: [6bone] SUNET announcing ALL IPv6 routes > > > > > > On Wed, 14 Aug 2002, Jorgensen, Roger wrote: > > > > > Hi, > > > > > > Got some feedback from sunet about this and seems like they've /dev/null'ed > > > the IPv4 IP for their endpoint as a temporarly workaround for now. > > > Thanks for the help SUNET!:) > > > > > > > > > Next issue, now I think we have alot of ghost routes to fight... > > > > > > > > > --- > > > Roger Jorgensen (rjorgensen@upctechnology.com) > > > > > > Cool. That we can do but, in the process, we need to document what router > > platform/code version the people sending the ghost routes are > > running. This is a very important operational issue, more important that > > actually getting the original announcements to stop. > > > > If you are an operator who peers with someone that is found to be > > ORIGINATING the ghost routes, please, find out what code they're running > > and let the list know. This "bug" has bitten us too many times already > > and needs to be squashed. > > > > If we compile a list of "bad code", folks will know to avoid using that > > code and/or peering with folks using that code. > > > > The root problem will never get fixed until we take measures to document > > it. > > > > > > > > --- > > 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 Wim.Biemolt@surfnet.nl Wed Aug 14 22:33:40 2002 From: Wim.Biemolt@surfnet.nl (Wim Biemolt) Date: Wed, 14 Aug 2002 23:33:40 +0200 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: Your message of "Wed, 14 Aug 2002 14:18:11 CDT." Message-ID: <65930.1029360820@gigant.surfnet.nl> ==> From: Jeff Barrow > Try this patch... and in the cfg file, add > login_user => 'username', > to the $::Routers entry for hosts that need a username. > > I don't have any routers that need usernames to test this with, so > feedback is welcome. :) Thanks for the patch. Tried it, but it didn't work. However using your patch I was able to get it to work. While looking at the man page of Net::Telnet I noticed there was the login command. Using that instead of cmd did the trick for me. So I now have the following (4.2.1 Beta): $t->open ($server); if (defined $login_user) { $t->login ($login_user, $login_pass); } else { $t->cmd ($login_pass); } > Can't help you on the fastping tho; it never did compile on my Slackware > 7.0 box either; I just configured it to use the normal system /bin/ping > instead. Doesn't seem to hurt anything. Will give it I try. Already though it wasn't a crucial part for the lg. > btw, great program, John! What would be even cooler (for me at least) is the following. Starting with IOS 12.0(22)S we have ssh support over IPv6. And you can supply a simple command. Just tested it, and it seems to work fine. So you could replace the Net::Telnet by open (ROUTER, "ssh my-router somecommand"); -Wim -/- SURFnet From tvo@EnterZone.Net Wed Aug 14 22:42:14 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 17:42:14 -0400 (EDT) Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: <200208142212.29745.ejb@sdf.lonestar.org> Message-ID: On Wed, 14 Aug 2002, Edward Brocklesby wrote: > > > As you say John, OS and version if you are announcing ghost-routes please. > > It would be nice if someone would set about collecting this information from > ASs (who might not be reading the list.) I would be happy too (this problem > annoys me greatly), but if someone else in a more official position feels > they would rather do it, that is probably better ;-) > > Regards, > -larne. I propose that if they're not reading this list, that is a problem. The 6bone list is the defacto world-wide v6 equivilent of NANOG, etc. If I'm mistaken, someone please direct me to the appropriate list. --- 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 Aug 14 22:45:48 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 17:45:48 -0400 (EDT) Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: <65930.1029360820@gigant.surfnet.nl> Message-ID: On Wed, 14 Aug 2002, Wim Biemolt wrote: > > btw, great program, John! > > What would be even cooler (for me at least) is the following. Starting > with IOS 12.0(22)S we have ssh support over IPv6. And you can supply a > simple command. Just tested it, and it seems to work fine. So you could > replace the Net::Telnet by open (ROUTER, "ssh my-router somecommand"); > Write the patch to check if someone has set the "ssh" flag in the config file for a particular router and then use ssh to connect to it. I'll include this in the next release. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From ejb@sdf.lonestar.org Wed Aug 14 23:00:08 2002 From: ejb@sdf.lonestar.org (Edward Brocklesby) Date: Wed, 14 Aug 2002 23:00:08 +0100 Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: References: Message-ID: <200208142300.08640.ejb@sdf.lonestar.org> John Fraizer: > I propose that if they're not reading this list, that is a problem. Well, maybe I am overly cynical for perfectly-organised internet community. If you prefer, let's see who answer these questions without any prodding. I try only to find the most efficient way to find these answers with least reliance on assumptions, however true they may be. Hopefully this method does work, because obviously there is some problem. I would think it is in the interests of 6bone community to attempt to correct problems, and so this is there suggestions come from. Feel free to point out the flaws you see in these suggestions, and I shall not suggest them any longer ;-). Regards, -larne. (PS. Please understand I am only trying to solve problem, if you think that I don't have the solution then do say, otherwise it wastes everyone's time.) From tvo@EnterZone.Net Wed Aug 14 23:47:53 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Wed, 14 Aug 2002 18:47:53 -0400 (EDT) Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: <200208142300.08640.ejb@sdf.lonestar.org> Message-ID: On Wed, 14 Aug 2002, Edward Brocklesby wrote: > John Fraizer: > > I propose that if they're not reading this list, that is a problem. > > Well, maybe I am overly cynical for perfectly-organised internet community. > If you prefer, let's see who answer these questions without any prodding. > I try only to find the most efficient way to find these answers with least > reliance on assumptions, however true they may be. > > Hopefully this method does work, because obviously there is some problem. I > would think it is in the interests of 6bone community to attempt to correct > problems, and so this is there suggestions come from. Feel free to point out > the flaws you see in these suggestions, and I shall not suggest them any > longer ;-). > > Regards, > -larne. > > (PS. Please understand I am only trying to solve problem, if you think that I > don't have the solution then do say, otherwise it wastes everyone's time.) Oh, no! I wasn't faulting anything you're doing! I want to see the list as much as anyone else. I was simply adding that IMHO, if someone is running in the v6 default-free-zone, they should be monitoring the 6bone mailing list. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From ejb@sdf.lonestar.org Thu Aug 15 00:18:41 2002 From: ejb@sdf.lonestar.org (Edward Brocklesby) Date: Thu, 15 Aug 2002 00:18:41 +0100 Subject: Strange/ghost routes from AS 33? (Was: Re: [6bone] SUNET announcing ALL IPv6 routes) In-Reply-To: References: Message-ID: <200208150018.41906.ejb@sdf.lonestar.org> John Fraizer: > [...] they should be monitoring the 6bone > mailing list. Well, all I think of is that if there's one problem, it's best not to take chances with other problems. They "should" be at least keeping up with the list, but they also "should" not be running an ancient version of zebra .. if you can see where I'm coming from here ;-) (I'm not trying to implicate anyone with that, just taking an example.) Anyway. I'd simply suggest to Cc: listed contact for the ASN when sending mail to the list regarding it- that way one can be sure that it's being seen. (Well, maybe mail to that address isn't being read, but.. maybe world will explode tomorrow, you can only have so much fault-tolerance ;-) -- Having said that, I am Cc'ing this mail to the listed contact for AS33 (DEC-WRL-ASN, Digital Equipment Corporation.) It seems we have a lot of ghost routes in our bgp table, which seem to originate from AS33: 24643 6830 2012 6939 2497 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 6939 2497 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 6939 2497 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 24765 3320 293 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 33 10318 12199 145 7580 10566 5408 2549 109 5539 8379 1275 8002 1654 Can you possibly shed any light on this, given today's discussion about it on the list (particularly with reference to router software in use at this speaker)? They seem to have appeared after the invalid routes from AS 1654 were withdrawn earlier. Regards, -larne. From fink@es.net Thu Aug 15 02:30:58 2002 From: fink@es.net (Bob Fink) Date: Wed, 14 Aug 2002 18:30:58 -0700 Subject: [6bone] pTLA request by Euro6IX project for exchange experimentation - review closes 3 Sep 2002 In-Reply-To: References: <2B81403386729140A3A899A8B39B046405E27D@server2000.arneill-py.sacramento.ca.us> Message-ID: <5.1.0.14.0.20020814182056.033a6060@imap2.es.net> Rik, At 05:01 PM 8/14/2002 -0300, Rik van Riel wrote: >On Wed, 14 Aug 2002, Michel Py wrote: > > >> Joao Luis Silva Damas wrote: > > >> Come on, these two cases were OK up to the point where > > >> people could not get any other type of IPv6 addresses > > >> but now they are just normal businness. > > > > >> Rik van Riel wrote: > > >> Yeah right. I doubt ipv6 is that widely > > >> available already. > > > > You might want to read the following thread on the v6ops and/or ngtrans > > mailing list, started this morning: (ngtrans) v6 considered operational > > > > http://ops.ietf.org/lists/v6ops/v6ops.2002/msg00000.html > >That's nice and all, but I'd hate it if that would mean >a bunch of IX folks would declare the 6bone obsolete and >I'd be without ipv6 connectivity until my ISP starts >offering it, some undetermined time into the future. > >6bone is here to stay for quite a while more... The original charge for the 6bone came through ngtrans and RFC2471. When we started a re-chartering of ngtrans Randy did not want it there anymore. Subsequently the RIR heads told me it was not their job to ever set a sunset on the 6bone, rather it was the IETF. This makes sense to me. Anwyay, stay tuned as all these things evolve. I'm glad you think that the 6bone still has a place; so do I. Bob From joao@ripe.net Thu Aug 15 08:44:17 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Thu, 15 Aug 2002 09:44:17 +0200 (CEST) Subject: [6bone] the end of ngtrans In-Reply-To: <2B81403386729140A3A899A8B39B046405E27B@server2000.arneill-py.sacramento.ca.us> Message-ID: Hi, On Wed, 14 Aug 2002, Michel Py wrote: > 6boners, > > > Randy Bush wrote: > > hence it is planned for ngtrans be closed and a new > > group, v6ops, be chartered > > This creates an interesting situation as the 6bone was informally > operated with oversight from the "NGtrans" (IPv6 Transition) Working > Group of the IETF. > > Thoughts, anyone? > Honestly, I believe it is a good thing. It clearly sets a new step. Note that neither this nor my previous mails suggest that the 6Bone should stop existing now. There is definitely a role for networks which are currently already using IPv6 addresses in creating a certain core network. What I don't think makes sense anymore is to allocate new 6Bone blocks for purposes that are just plain natural deployment. Bob, from your message I had the feeling you are mixing address blocks with connectivity. They are not the same. No one is going to be able to tell anyone else that they should stop exchanging traffic. The peering and transit relationships will and should remain and their evolution should only be dictated by normal network evolution (new or bigger ISPs, some old ones going away, etc) The important point here is that IPv6 is now deployable and it is time to stop allocating new blocks of addresses for plain operational purposes. Just in the same way you are approached by people interested in using IPv6, I talk to people in companies who just can't justify looking at it seriously while it has the "experimental" tag attached to it. The 6Bone list should definitely stay, it is a very valuable resource for coordination and education. I don't think anyone will question that. And finally, I am glad to have been able to change the subject as I have nothing against the Euro6 people and it I would hate to have misunderstandings. Cheers, Joao From old_mc_donald@hotmail.com Thu Aug 15 19:58:39 2002 From: old_mc_donald@hotmail.com (Gav) Date: Thu, 15 Aug 2002 19:58:39 +0100 Subject: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 In-Reply-To: Message-ID: <000001c2448d$c46eabe0$0100a8c0@comp1> -----Original Message----- From: 6bone-admin@mailman.isi.edu [mailto:6bone-admin@mailman.isi.edu] On Behalf Of Rik van Riel RvR says >Yeah right. I doubt ipv6 is that widely available already. True, and I'm having difficulty explaining to so called computer/network 'eXperts' That ipv6 is going to happen (I say happen because it hasn't for them), and that it is important. 'You have an ipv6 address, yeah right' - is there answer too! - [The whole truth I neglected to mention (and therefore a plus in your argument)is that being green to this I don't really know what to do with it, Freenet6 supplies me with it, it runs out a week later, I renew it. Microsoft supplied me the stack. I can't even ping6 anyone for god sake, ooh, another reason maybe why its not so popular at the moment. RvR says >IPv6 just isn't commonplace yet. No, but if I can (sort of) get it, who can't. regards, Gav... _______________________________________________ 6bone mailing list 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone --- Outgoing mail is certified Virus Free.Gavin.. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/02 From riel@conectiva.com.br Thu Aug 15 20:08:15 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Thu, 15 Aug 2002 16:08:15 -0300 (BRT) Subject: [6bone] pTLA request by Euro6IX project for exchangeexperimentation - review closes 3 Sep 2002 In-Reply-To: <000001c2448d$c46eabe0$0100a8c0@comp1> Message-ID: On Thu, 15 Aug 2002, Gav wrote: > RvR says >IPv6 just isn't commonplace yet. > > No, but if I can (sort of) get it, who can't. I agree with this. At the moment pretty much everybody can get their ipv6 addresses via 6bone. My point is that for many people, 6bone is the only way to get ipv6 addresses, so the "ipv6 is available, 6bone is obsolete" statement I think I've seen couldn't be further from the truth. kind regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From jeffb@netc.com Thu Aug 15 21:10:52 2002 From: jeffb@netc.com (Jeff Barrow) Date: Thu, 15 Aug 2002 15:10:52 -0500 (CDT) Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: <65930.1029360820@gigant.surfnet.nl> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1580397906-2138162354-1029442252=:4851 Content-Type: TEXT/PLAIN; charset=US-ASCII Ok... updated patch file included (oops, my previous posting didn't go through) This is the patch against mrlg-4.2.1 to add login/username capability to mrlg. Any server that requires a username, you just add the login_user => 'username' field to the record in the config file. John, might I suggest you either place this patch file in your ftp directory or go ahead and patch your copy? On Wed, 14 Aug 2002, Wim Biemolt wrote: > What would be even cooler (for me at least) is the following. Starting > with IOS 12.0(22)S we have ssh support over IPv6. And you can supply a > simple command. Just tested it, and it seems to work fine. So you could > replace the Net::Telnet by open (ROUTER, "ssh my-router somecommand"); This exercise left up to someone who uses ssh in perl more than I do. :) --Jeff Barrow, Internet Connections, Inc. ---1580397906-2138162354-1029442252=:4851 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mrlg-421-login-user.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: mrlg 4.2.1 login+username patch Content-Disposition: attachment; filename="mrlg-421-login-user.patch" LS0tIG1ybGctNC4yLjEvaW5kZXguY2dpLm9yaWcJV2VkIEF1ZyAxNCAxNDow NDoxNiAyMDAyDQorKysgbXJsZy00LjIuMS9pbmRleC5jZ2kJVGh1IEF1ZyAx NSAxNTowNjoxNCAyMDAyDQpAQCAtNDYsNyArNDYsNyBAQA0KIA0KICRFTlZ7 J1BBVEgnfSA9ICIiOw0KIA0KLW15ICgkc2VydmVyLCAkbG9naW5fcGFzcywg JHBhc3MsICRiZ3BkLCAkemVicmEsICRvc3BmZCwgJHJpcGQsICRmdWxsX3Rh YmxlcywgJGNpc2NvKTsNCitteSAoJHNlcnZlciwgJGxvZ2luX3Bhc3MsICRs b2dpbl91c2VyLCAkcGFzcywgJGJncGQsICR6ZWJyYSwgJG9zcGZkLCAkcmlw ZCwgJGZ1bGxfdGFibGVzLCAkY2lzY28pOw0KIA0KICMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj Iw0KIHN1YiBzZXRfcm91dGVyDQpAQCAtNjEsNiArNjEsNyBAQA0KICAgICBp ZiAoISAkc2VydmVyKSB7DQogCWRpZSAiTm8gJ3NlcnZlcicga25vd24gZm9y IHJvdXRlciAkOjpGb3Jteydyb3V0ZXInfSI7DQogICAgIH0NCisgICAgJGxv Z2luX3VzZXIgPSAkOjpSb3V0ZXJzeyQ6OkZvcm17J3JvdXRlcid9fXsnbG9n aW5fdXNlcid9Ow0KICAgICAkbG9naW5fcGFzcyA9ICQ6OlJvdXRlcnN7JDo6 Rm9ybXsncm91dGVyJ319eydsb2dpbl9wYXNzJ307DQogICAgIGlmICghICRs b2dpbl9wYXNzKSB7DQogCWRpZSAiTm8gJ2xvZ2luX3Bhc3MnIGtub3duIGZv ciByb3V0ZXIgJDo6Rm9ybXsncm91dGVyJ30iOw0KQEAgLTY3Nyw3ICs2Nzgs MTEgQEANCiANCiAgICR0LT5vcGVuICgkc2VydmVyKTsNCiANCi0gICR0LT5j bWQgKCRsb2dpbl9wYXNzKTsNCisgIGlmIChkZWZpbmVkICRsb2dpbl91c2Vy KSB7DQorCSR0LT5sb2dpbiAoJGxvZ2luX3VzZXIsICRsb2dpbl9wYXNzKTsN CisgIH0gZWxzZSB7DQorCSR0LT5jbWQgKCRsb2dpbl9wYXNzKTsNCisgIH0N CiANCiAkdC0+Y21kKCJ0ZXJtaW5hbCBsZW5ndGggJHRlcm1sZW5ndGgiKTsN CiANCg== ---1580397906-2138162354-1029442252=:4851-- From michel@arneill-py.sacramento.ca.us Fri Aug 16 16:23:29 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 16 Aug 2002 08:23:29 -0700 Subject: [6bone] the end of ngtrans Message-ID: <2B81403386729140A3A899A8B39B04640BCFF8@server2000.arneill-py.sacramento.ca.us> > Joao Luis Silva Damas wrote: > And finally, I am glad to have been able to change the > subject as I have nothing against the Euro6 people and > it I would hate to have misunderstandings. I don't think there are any misunderstandings about Euro6IX' request. I have not heard anything but positive comments, and it has generated a lot more interest than the typical apathy associated with pTLA requests. Michel. From joao@ripe.net Fri Aug 16 16:24:54 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Fri, 16 Aug 2002 17:24:54 +0200 Subject: [6bone] the end of ngtrans In-Reply-To: <2B81403386729140A3A899A8B39B04640BCFF8@server2000.arneill-py.sacramento.c a.us> References: <2B81403386729140A3A899A8B39B04640BCFF8@server2000.arneill-py.sacramento.c a.us> Message-ID: Good Joao At 8:23 -0700 16/8/02, Michel Py wrote: > > Joao Luis Silva Damas wrote: >> And finally, I am glad to have been able to change the >> subject as I have nothing against the Euro6 people and >> it I would hate to have misunderstandings. > >I don't think there are any misunderstandings about Euro6IX' request. I >have not heard anything but positive comments, and it has generated a >lot more interest than the typical apathy associated with pTLA requests. > >Michel. From paul@clubi.ie Sat Aug 17 19:41:07 2002 From: paul@clubi.ie (Paul Jakma) Date: Sat, 17 Aug 2002 19:41:07 +0100 (IST) Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: Message-ID: while we're doing feature requests for MRLG, can you have it do the traceroutes on the router listed in the drop down list, rather than the machine MRLG is running on? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare From dr@cluenet.de Sun Aug 18 02:11:47 2002 From: dr@cluenet.de (Daniel Roesen) Date: Sun, 18 Aug 2002 03:11:47 +0200 Subject: [6bone] SUNET announcing ALL IPv6 routes In-Reply-To: <011e01c243ce$e5fde1a0$0200000a@hera>; from jorgen@hovland.cx on Wed, Aug 14, 2002 at 10:12:20PM +0200 References: <011e01c243ce$e5fde1a0$0200000a@hera> Message-ID: <20020818031147.A1307@homebase.cluenet.de> On Wed, Aug 14, 2002 at 10:12:20PM +0200, Jørgen Hovland wrote: > 1275 C&W ecrc.de 1275 is _not_ C&W. $ arin as 1275 Cable & Wireless ECRC (ASNBLK-CW-ECRC) Autonomous System Name: CW-ECRC Autonomous System Block: 1270 - 1275 ARIN's database is broken although multiple attempts have been made to have them fix that. C&W Germany (former ECRC) is AS1273. AS1270 was formerly used by UUnet Germany. You have to ask RIPE for accurate info on the 1270-1275 range: aut-num: AS1275 as-name: UNSPECIFIED descr: DFN-IP service and DFN customer networks Best regards, Daniel From tvo@EnterZone.Net Sun Aug 18 04:54:04 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Sat, 17 Aug 2002 23:54:04 -0400 (EDT) Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: Message-ID: If you specify cisco => '1' for the router specified, it DOES do the traceroute from the router listed in the drop down list. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | On Sat, 17 Aug 2002, Paul Jakma wrote: > while we're doing feature requests for MRLG, can you have it do the > traceroutes on the router listed in the drop down list, rather than > the machine MRLG is running on? > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > warning: do not ever send email to spam@dishone.st > Fortune: > As you will see, I told them, in no uncertain terms, to see Figure one. > -- Dave "First Strike" Pare > From dragon@tdoi.org Sun Aug 18 12:07:52 2002 From: dragon@tdoi.org (Christian Nickel) Date: Sun, 18 Aug 2002 13:07:52 +0200 Subject: [6bone] SUNET announcing ALL IPv6 routes References: <011e01c243ce$e5fde1a0$0200000a@hera> <20020818031147.A1307@homebase.cluenet.de> Message-ID: <000a01c246a7$7f11c930$fd04a80a@alpha> ----- Original Message ----- From: "Daniel Roesen" To: <6bone@mailman.isi.edu> Sent: Sunday, August 18, 2002 3:11 AM Subject: Re: [6bone] SUNET announcing ALL IPv6 routes > On Wed, Aug 14, 2002 at 10:12:20PM +0200, Jørgen Hovland wrote: > > 1275 C&W ecrc.de > > 1275 is _not_ C&W. > > $ arin as 1275 > Cable & Wireless ECRC (ASNBLK-CW-ECRC) > Autonomous System Name: CW-ECRC > Autonomous System Block: 1270 - 1275 > > ARIN's database is broken although multiple attempts have been made > to have them fix that. > > C&W Germany (former ECRC) is AS1273. AS1270 was formerly used by UUnet > Germany. You have to ask RIPE for accurate info on the 1270-1275 range: > > aut-num: AS1275 > as-name: UNSPECIFIED > descr: DFN-IP service and DFN customer networks > AS1275 is used for the 6bone pTLA of JOIN Project http://www.join.uni-muenster.de/ contact: join@uni-muenster.de AS680 is the production ASN of DFN http://www.6win.dfn.de/ > > Best regards, > Daniel > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > > From nicolas.deffayet@ndsoftware.net Sun Aug 18 22:05:28 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 18 Aug 2002 23:05:28 +0200 Subject: [6bone] IPv6 Newsfeed Message-ID: <1029704728.20431.144.camel@wks1.fr.corp.ndsoftware.com> Hello, I search IPv6 feed for my server: --- Path: fr.ndsoftwarenet.com Server: newsfeed.fr.ndsoftwarenet.com Accept from: ns3.ndsoftware.net (3ffe:81f1:12:1::3) Feed to: newsfeed.fr.ndsoftwarenet.com (3ffe:81f1:12:3:8::2) Contact: newsmaster@ndsoftwarenet.com Hierarchies: fr.*,uk.*,de.*,comp.*,be.*,news.* --- If anyone want to set up a peering with newsfeed.fr.ndsoftwarenet.com, please contact me. My server is open in read only to all IPv6 users. Thanks Best Regards, Nicolas DEFFAYET From paul@clubi.ie Sun Aug 18 22:57:35 2002 From: paul@clubi.ie (Paul Jakma) Date: Sun, 18 Aug 2002 22:57:35 +0100 (IST) Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: Message-ID: On Sat, 17 Aug 2002, John Fraizer wrote: > > If you specify cisco => '1' for the router specified, it DOES do the > traceroute from the router listed in the drop down list. but what if the remote router is zebra? :( regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: George Orwell 1984. Northwestern 0. -- Chicago Reader 10/15/82 From nicolas.deffayet@ndsoftware.net Sun Aug 18 23:19:01 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 19 Aug 2002 00:19:01 +0200 Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: References: Message-ID: <1029709141.20413.149.camel@wks1.fr.corp.ndsoftware.com> On Sun, 2002-08-18 at 23:57, Paul Jakma wrote: > On Sat, 17 Aug 2002, John Fraizer wrote: > > > > > If you specify cisco => '1' for the router specified, it DOES do the > > traceroute from the router listed in the drop down list. > > but what if the remote router is zebra? :( You can't. The only way with zebra is create a user zebra with for shell vtysh. And login with telnet with this user. Best Regards, Nicolas DEFFAYET From tvo@EnterZone.Net Mon Aug 19 06:14:43 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 19 Aug 2002 01:14:43 -0400 (EDT) Subject: [6bone] 2001:470::/35 ghost routes. In-Reply-To: Message-ID: On Sun, 18 Aug 2002, Paul Jakma wrote: > On Sat, 17 Aug 2002, John Fraizer wrote: > > > > > If you specify cisco => '1' for the router specified, it DOES do the > > traceroute from the router listed in the drop down list. > > but what if the remote router is zebra? :( > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A If the remote router is Zebra, there is NOT any "built-in" traceroute function for traceroute. If you want to set up something SPECIFIC to your site, the source for MRLG is very well commented and you can build a site specific MRLG that will do what you wish though. --- 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 Aug 19 16:47:59 2002 From: fink@es.net (Bob Fink) Date: Mon, 19 Aug 2002 08:47:59 -0700 Subject: [6bone] pTLA request BUI - review closes 3 September 2002 Message-ID: <5.1.0.14.0.20020819084047.02a41c98@imap2.es.net> 6bone Folk, BUI has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 3 September 2002. Please send your comments to me or the list. BUI has received formal permission from ModenaOnLine to use their ASN for 6bone purposes. Thanks, Bob === >Date: Fri, 02 Aug 2002 14:11:53 +0200 >To: Bob Fink >From: Giacomo Cariello >Subject: pTLA allocation request (reprise) > >I hope this looks better. I have modified the request to reflect the >actual separation between ModenaOnLine and BUI. >They offer us free IPv4 connectivity, but we manage IPv6 network >indipendently. >I have also moved description of our services to a separate page. > >The following rules apply to qualify for a 6Bone pTLA allocation. It >should be recognized that holders of 6Bone pTLA allocations are >expected to provide production quality backbone network services for >the 6Bone. >1. The pTLA Applicant must have a minimum of three (3) months >qualifying experience as a 6Bone end-site or pNLA transit. During >the entire qualifying period the Applicant must be operationally >providing the following: > >We have been online on 6bone since July, 25th 2000. >We have recently completed the necessary steps to complete registry >information. > >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: > >inet6num: 3FFE:1001:220::/48 >netname: BUI >descr: BSD Users Group Italia testing network >country: IT >admin-c: GC4-6BONE >tech-c: GC4-6BONE >mnt-by: BUI >changed: jwk@bug.it 20020705 >source: 6BONE > >mntner: BUI >descr: BSD Users Group Italia >admin-c: GC4-6BONE >tech-c: GC4-6BONE >upd-to: jwk@bug.it >auth: CRYPT-PW * >mnt-by: BUI >changed: jwk@bug.it 20020722 >source: 6BONE > >ipv6-site: BUI >origin: AS21394 >descr: BSD Users Group Italia test network >prefix: 3FFE:1001:220::/48 >application: ping hero.bug.it >application: www www.ipv6.bug.it >tunnel: IPv6 in IPv4 hero.bug.it -> 6bone-gw3.cselt.it TILAB BGP4+ >contact: GC4-6BONE >contact: MIC1-6BONE >url: http://www.ipv6.bug.it >notify: noc@bug.it >mnt-by: BUI >changed: jwk@bug.it 20020722 >changed: jwk@bug.it 20020731 >changed: jwk@bug.it 20020802 >source: 6BONE > >person: Giacomo Cariello >address: via d'Acquapendente, 65 >address: 35100 - Padova >address: Italy >phone: +39 348 3043150 >fax-no: +39 348 3043150 >e-mail: jwk@bug.it >nic-hdl: GC4-6BONE >notify: jwk@bug.it >changed: jwk@bug.it 20020129 >source: 6BONE > >person: Michele Gandolfi >address: via delle Carmelitane Scalze, 7 >address: 41100 - Modena >address: Italy >phone: +39 059 222328 >fax-no: +39 059 4391174 >e-mail: mic@datas.it >nic-hdl: MIC1-6BONE >notify: mic@datas.it >changed: mic@datas.it 20020703 >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. > >Our router to the backbone has proper BGP4+ link with TILAB. >Our workgroup has been connected through TILAB (formerly CSELT) for over >two years now. > >c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) >entries for the Applicant's router(s) and at least one host >system. > >Router system: > ># host -t AAAA hero.bug.it >hero.bug.it AAAA 3FFE:1001:220:0:0:0:0:1 ># host -t PTR >1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.2.0.1.0.0.1.e.f.f.3.ip6.int >1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.2.0.1.0.0.1.e.f.f.3.ip6.int >PTR hero.bug.it > >Host system: > ># host -t AAAA glock.bug.it >glock.bug.it AAAA 3FFE:1001:220:1:0:0:0:E ># host -t PTR >e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.2.2.0.1.0.0.1.e.f.f.3.ip6.int >e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.2.2.0.1.0.0.1.e.f.f.3.ip6.int >PTR glock.bug.it > >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. > >We have a IPv6-aware webserver running, it is pingable, and it hosts a >descriptive webpage at http://www.ipv6.bug.it/. > >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. > >Currently GC4-6BONE and MIC1-6BONE. More to come. > >I (GC4-BONE) am the technical and administrative coordinator of BUI. I >will coordinate IPv6 network operations. >Our network partner for IPv4 connectivity is DATAS-NOC (AS21394). They are >currently hosting our equipment for free. >MIC1-6BONE is also technical director at DATAS-NOC, so he provides us with >support for what regards IPv4. > >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. > >noc@bug.it > >3. The pTLA Applicant MUST have a potential "user community" that >would be served by its becoming a pTLA, e.g., the Applicant is a >major provider of Internet service in a region, country, or focus >of interest. Applicant must provide a statement and information in >support this claim. > >BUI offers free hosting and shell access services to BSD coders developing >open source IPv6-aware projects in Italy. >I have described those services in detail at http://www.bug.it/. > > >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. > >We abide. > >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>. > >I have been subscribed to 6bone mailing list since 23 sept 2000. > > > >Giacomo Cariello, jwk@bug.it -end From pekkas@netcore.fi Mon Aug 19 18:13:09 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 19 Aug 2002 20:13:09 +0300 (EEST) Subject: [6bone] pTLA request BUI - review closes 3 September 2002 In-Reply-To: <5.1.0.14.0.20020819084047.02a41c98@imap2.es.net> Message-ID: Hi, I'm all for giving developers full access to IPv6, but I don't think the criteria are met: > >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. > > > >BUI offers free hosting and shell access services to BSD coders developing > >open source IPv6-aware projects in Italy. > >I have described those services in detail at http://www.bug.it/. Notably "user community that would be served by *its becoming a pTLA*. It appears to me that BUG does not qualify as a major provider of Internet service, and these functions can be carried out quite well with a /48 assignment. On Mon, 19 Aug 2002, Bob Fink wrote: > 6bone Folk, > > BUI has requested a pTLA allocation and I find their request fully > compliant with RFC2772. The open review period for this will close 3 > September 2002. Please send your comments to me or the list. > > > > > > > BUI has received formal permission from ModenaOnLine to use their ASN for > 6bone purposes. > > > Thanks, > > Bob > > === > >Date: Fri, 02 Aug 2002 14:11:53 +0200 > >To: Bob Fink > >From: Giacomo Cariello > >Subject: pTLA allocation request (reprise) > > > >I hope this looks better. I have modified the request to reflect the > >actual separation between ModenaOnLine and BUI. > >They offer us free IPv4 connectivity, but we manage IPv6 network > >indipendently. > >I have also moved description of our services to a separate page. > > > >The following rules apply to qualify for a 6Bone pTLA allocation. It > >should be recognized that holders of 6Bone pTLA allocations are > >expected to provide production quality backbone network services for > >the 6Bone. > >1. The pTLA Applicant must have a minimum of three (3) months > >qualifying experience as a 6Bone end-site or pNLA transit. During > >the entire qualifying period the Applicant must be operationally > >providing the following: > > > >We have been online on 6bone since July, 25th 2000. > >We have recently completed the necessary steps to complete registry > >information. > > > >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: > > > >inet6num: 3FFE:1001:220::/48 > >netname: BUI > >descr: BSD Users Group Italia testing network > >country: IT > >admin-c: GC4-6BONE > >tech-c: GC4-6BONE > >mnt-by: BUI > >changed: jwk@bug.it 20020705 > >source: 6BONE > > > >mntner: BUI > >descr: BSD Users Group Italia > >admin-c: GC4-6BONE > >tech-c: GC4-6BONE > >upd-to: jwk@bug.it > >auth: CRYPT-PW * > >mnt-by: BUI > >changed: jwk@bug.it 20020722 > >source: 6BONE > > > >ipv6-site: BUI > >origin: AS21394 > >descr: BSD Users Group Italia test network > >prefix: 3FFE:1001:220::/48 > >application: ping hero.bug.it > >application: www www.ipv6.bug.it > >tunnel: IPv6 in IPv4 hero.bug.it -> 6bone-gw3.cselt.it TILAB BGP4+ > >contact: GC4-6BONE > >contact: MIC1-6BONE > >url: http://www.ipv6.bug.it > >notify: noc@bug.it > >mnt-by: BUI > >changed: jwk@bug.it 20020722 > >changed: jwk@bug.it 20020731 > >changed: jwk@bug.it 20020802 > >source: 6BONE > > > >person: Giacomo Cariello > >address: via d'Acquapendente, 65 > >address: 35100 - Padova > >address: Italy > >phone: +39 348 3043150 > >fax-no: +39 348 3043150 > >e-mail: jwk@bug.it > >nic-hdl: GC4-6BONE > >notify: jwk@bug.it > >changed: jwk@bug.it 20020129 > >source: 6BONE > > > >person: Michele Gandolfi > >address: via delle Carmelitane Scalze, 7 > >address: 41100 - Modena > >address: Italy > >phone: +39 059 222328 > >fax-no: +39 059 4391174 > >e-mail: mic@datas.it > >nic-hdl: MIC1-6BONE > >notify: mic@datas.it > >changed: mic@datas.it 20020703 > >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. > > > >Our router to the backbone has proper BGP4+ link with TILAB. > >Our workgroup has been connected through TILAB (formerly CSELT) for over > >two years now. > > > >c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > >entries for the Applicant's router(s) and at least one host > >system. > > > >Router system: > > > ># host -t AAAA hero.bug.it > >hero.bug.it AAAA 3FFE:1001:220:0:0:0:0:1 > ># host -t PTR > >1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.2.0.1.0.0.1.e.f.f.3.ip6.int > >1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.2.0.1.0.0.1.e.f.f.3.ip6.int > >PTR hero.bug.it > > > >Host system: > > > ># host -t AAAA glock.bug.it > >glock.bug.it AAAA 3FFE:1001:220:1:0:0:0:E > ># host -t PTR > >e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.2.2.0.1.0.0.1.e.f.f.3.ip6.int > >e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.2.2.0.1.0.0.1.e.f.f.3.ip6.int > >PTR glock.bug.it > > > >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. > > > >We have a IPv6-aware webserver running, it is pingable, and it hosts a > >descriptive webpage at http://www.ipv6.bug.it/. > > > >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. > > > >Currently GC4-6BONE and MIC1-6BONE. More to come. > > > >I (GC4-BONE) am the technical and administrative coordinator of BUI. I > >will coordinate IPv6 network operations. > >Our network partner for IPv4 connectivity is DATAS-NOC (AS21394). They are > >currently hosting our equipment for free. > >MIC1-6BONE is also technical director at DATAS-NOC, so he provides us with > >support for what regards IPv4. > > > >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. > > > >noc@bug.it > > > >3. The pTLA Applicant MUST have a potential "user community" that > >would be served by its becoming a pTLA, e.g., the Applicant is a > >major provider of Internet service in a region, country, or focus > >of interest. Applicant must provide a statement and information in > >support this claim. > > > >BUI offers free hosting and shell access services to BSD coders developing > >open source IPv6-aware projects in Italy. > >I have described those services in detail at http://www.bug.it/. > > > > > >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. > > > >We abide. > > > >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>. > > > >I have been subscribed to 6bone mailing list since 23 sept 2000. > > > > > > > >Giacomo Cariello, jwk@bug.it > -end > > _______________________________________________ > 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 jwk@bug.it Mon Aug 19 20:44:26 2002 From: jwk@bug.it (Giacomo Cariello) Date: Mon, 19 Aug 2002 21:44:26 +0200 Subject: [6bone] pTLA request BUI - review closes 3 September 2002 In-Reply-To: References: <5.1.0.14.0.20020819084047.02a41c98@imap2.es.net> Message-ID: <5.1.1.6.2.20020819212009.02aeb6c0@mail.energy.local> At 20.13 19/08/2002 +0300, you wrote: >It appears to me that BUG does not qualify as a major provider of Internet >service, and these functions can be carried out quite well with a /48 >assignment. Our major need for a pTLA is determined by our routing software projects. Some of our efforts require testing our implementations with multiple BGP peers, in various conditions. Our actual status of sub-pTLA doesn't allow us such freedom and we believe that requesting a direct allocation to this "IPv6 testbed" is the way to go. Giacomo Cariello, jwk@bug.it KeyID: 3072/1024/0x409C9044 Fingerprint: 7984 10FD 0460 4202 BF90 3881 CDE4 D78E 409C 9044 "Put that mic in my hand and let me kick out the jams!" - MC5 From tvo@EnterZone.Net Tue Aug 20 00:23:34 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 19 Aug 2002 19:23:34 -0400 (EDT) Subject: [6bone] pTLA request BUI - review closes 3 September 2002 In-Reply-To: <5.1.1.6.2.20020819212009.02aeb6c0@mail.energy.local> Message-ID: On Mon, 19 Aug 2002, Giacomo Cariello wrote: > At 20.13 19/08/2002 +0300, you wrote: > >It appears to me that BUG does not qualify as a major provider of Internet > >service, and these functions can be carried out quite well with a /48 > >assignment. > > Our major need for a pTLA is determined by our routing software projects. > Some of our efforts require testing our implementations with multiple BGP > peers, in various conditions. > Our actual status of sub-pTLA doesn't allow us such freedom and we believe > that requesting a direct allocation to this "IPv6 testbed" is the way to go. > I don't see where testing routing routing softare requires a /32. There is no reason why you can't have multiple BGP peers, take full routes from them all and announce your /48 to them tagged with "no-export". I recently posted a configuration example that addresses just this very thing. What part of your testbed requires that your testing show up as an announcement in the routing table of every IPv6 BGP speaker operating in the Default Free Zone? --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From jwk@bug.it Tue Aug 20 01:10:02 2002 From: jwk@bug.it (Giacomo Cariello) Date: Tue, 20 Aug 2002 02:10:02 +0200 Subject: [6bone] pTLA request BUI - review closes 3 September 2002 Message-ID: <5.1.1.6.2.20020820020956.02b0e008@mail.energy.local> At 19.23 19/08/2002 -0400, you wrote: >On Mon, 19 Aug 2002, Giacomo Cariello wrote: > > > At 20.13 19/08/2002 +0300, you wrote: > > >It appears to me that BUG does not qualify as a major provider of Internet > > >service, and these functions can be carried out quite well with a /48 > > >assignment. > > > > Our major need for a pTLA is determined by our routing software projects. > > Some of our efforts require testing our implementations with multiple BGP > > peers, in various conditions. > > Our actual status of sub-pTLA doesn't allow us such freedom and we believe > > that requesting a direct allocation to this "IPv6 testbed" is the way > to go. > > > >I don't see where testing routing routing softare requires a /32. There >is no reason why you can't have multiple BGP peers, take full routes from >them all and announce your /48 to them tagged with "no-export". I >recently posted a configuration example that addresses just this very >thing. It appears that our neighbour pTLA do not allow us to announce our /48 through other pTLAs, so we're looking into obtaining a provider-indipendent address space and request peering with major IPv6 italian/european pTLAs. In our testing environment, we specifically need our annunce to reach the backbone through multiple paths (2 or possibly more). Giacomo Cariello, jwk@bug.it KeyID: 3072/1024/0x409C9044 Fingerprint: 7984 10FD 0460 4202 BF90 3881 CDE4 D78E 409C 9044 "Put that mic in my hand and let me kick out the jams!" - MC5 From tvo@EnterZone.Net Tue Aug 20 03:20:07 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 19 Aug 2002 22:20:07 -0400 (EDT) Subject: [6bone] pTLA request BUI - review closes 3 September 2002 In-Reply-To: <5.1.1.6.2.20020820020040.02b0cd88@mail.energy.local> Message-ID: On Tue, 20 Aug 2002, Giacomo Cariello wrote: > At 19.23 19/08/2002 -0400, you wrote: > > > >I don't see where testing routing routing softare requires a /32. There > >is no reason why you can't have multiple BGP peers, take full routes from > >them all and announce your /48 to them tagged with "no-export". I > >recently posted a configuration example that addresses just this very > >thing. > > It appears that our neighbour pTLA do not allow us to announce our /48 > through other pTLAs, so we're looking into obtaining a provider-indipendent > address space and request peering with major IPv6 italian/european pTLAs. > In our testing environment, we specifically need our annunce to reach the > backbone through multiple paths (2 or possibly more). > > > > Giacomo Cariello, jwk@bug.it TILAB won't allow you to announce your 48 (as no-export) to other BGP peers? I can understand them not wanting it in the DFZ but, what you and your peers do, that remains isolated to the routing tables of you and your peers is, IMHO, your business. I still don't understand why your testing requires your announcement to make it into the DFZ. You said that you are testing routing software. It's easy to look at your peers looking glass and see if your announcement is making it to that peer. If you take full views from multiple peers, you can verify that your best-path-selection process works and test various methods of influencing that process. "Experimenting" in the DFZ that involves injecting/retracting a prefix/prefixes with any frequency at all (something that I would expect if you're testing routing software as you say) will have a negative impact on your reachability because you'll be dampened. Getting PI space from your RIR is a good idea, if you qualify. I still don't agree wanting to participate (in a testing capacity) in the DFZ is justification for a pTLA. Perhaps if TILAB won't allow you to experiment with your /48 from them, you need to look for another pTLA that will. In addition, TILAB needs to update their ipv6-site object. It has not been updated since 20010702 and it does not reflect their tunnel/bgp session with your site. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From jwk@bug.it Tue Aug 20 09:41:52 2002 From: jwk@bug.it (Giacomo Cariello) Date: Tue, 20 Aug 2002 10:41:52 +0200 Subject: [6bone] pTLA request BUI - review closes 3 September 2002 In-Reply-To: References: <5.1.1.6.2.20020820020040.02b0cd88@mail.energy.local> Message-ID: <5.1.1.6.2.20020820094534.02aec490@mail.energy.local> At 22.20 19/08/2002 -0400, you wrote: >Getting PI space from your RIR is a good idea, if you qualify. I still >don't agree wanting to participate (in a testing capacity) in the DFZ is >justification for a pTLA. Perhaps if TILAB won't allow you to experiment >with your /48 from them, you need to look for another pTLA that will. I've had a talk with CEO of Data Service, our IPv4 connectivity partner and I agreed with him to anticipate IPv6 deployment schedule for their organization. Data Service would be interested in requesting a pTLA status for IPv6 deployment reasons, which would be well justified, considering they are an ISP serving hundreds end-sites and regional organizations and offering various types of connectivity services. Meanwhile, we could obtain a sub-pTLA directly from them with a less-restrictive policy on what we can do with our assignment. Our plan is to pass our current IPv6 structure to Data Service, in order to speed up their startup period. Some of their tech employees have collaborated with us to create our current IPv6 network, therefore I suppose there will be no problem with that. If it sounds reasonable, I'll contact Data Service and have them start an IPv6 allocation plan and the request procedures for a 6bone pTLA. Giacomo Cariello, jwk@bug.it KeyID: 3072/1024/0x409C9044 Fingerprint: 7984 10FD 0460 4202 BF90 3881 CDE4 D78E 409C 9044 "Put that mic in my hand and let me kick out the jams!" - MC5 From galania@ipv6.inictel.gob.pe Tue Aug 20 15:08:09 2002 From: galania@ipv6.inictel.gob.pe (Gino Francisco Alania Hurtado) Date: Tue, 20 Aug 2002 09:08:09 -0500 Subject: [6bone] two address Message-ID: <3D624D49.1090004@ipv6.inictel.gob.pe> Consultations friends, using linux-usagi I have a particularitity, when I do ifconfig appears ipv6 global two-way traffic: [root@ipv6 gino]# ifconfig compendiu Link encap:IPv6-in-IPv4 inet6 addr: fe80::c83c:ac84/128 Scope:Link inet6 addr: 3ffe:8260:200e:fffd::2/48 Scope:Global UP POINTOPOINT RUNNING NOARP MTU:1420 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:162 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:18823 (18.3 Kb) eth0 Link encap:Ethernet HWaddr 00:01:02:2A:72:85 inet addr:200.60.172.132 Bcast:200.60.172.159 Mask:255.255.255.224 inet6 addr: 3ffe:8260:200e:1001:846a:bebb:5040:f4cd/64 Scope:Global inet6 addr: fe80::201:2ff:fe2a:7285/64 Scope:Link inet6 addr: 3ffe:8260:200e:1001:201:2ff:fe2a:7285/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7875 errors:0 dropped:0 overruns:0 frame:0 TX packets:2313 errors:0 dropped:0 overruns:0 carrier:0 collisions:3 txqueuelen:100 RX bytes:2890904 (2.7 Mb) TX bytes:225912 (220.6 Kb) Interrupt:10 Base address:0xd880 Some suggestion, of like modifying it? From yoshfuji@linux-ipv6.org Tue Aug 20 15:29:55 2002 From: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Tue, 20 Aug 2002 23:29:55 +0900 (JST) Subject: [6bone] Re: (usagi-users 01749) two address In-Reply-To: <3D624D49.1090004@ipv6.inictel.gob.pe> References: <3D624D49.1090004@ipv6.inictel.gob.pe> Message-ID: <20020820.232955.53308759.yoshfuji@linux-ipv6.org> In article <3D624D49.1090004@ipv6.inictel.gob.pe> (at Tue, 20 Aug 2002 09:08:09 -0500), Gino Francisco Alania Hurtado says: > Consultations friends, using linux-usagi I have a particularitity, when > I do ifconfig appears ipv6 global two-way traffic: > [root@ipv6 gino]# ifconfig : > eth0 Link encap:Ethernet HWaddr 00:01:02:2A:72:85 > inet addr:200.60.172.132 Bcast:200.60.172.159 > Mask:255.255.255.224 > inet6 addr: 3ffe:8260:200e:1001:846a:bebb:5040:f4cd/64 > Scope:Global > inet6 addr: fe80::201:2ff:fe2a:7285/64 Scope:Link > inet6 addr: 3ffe:8260:200e:1001:201:2ff:fe2a:7285/64 Scope:Global > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 : I wonder I don't understand your question / problem. Could you explain further details, please? --yoshfuji From nicolas.deffayet@ndsoftware.net Tue Aug 20 15:40:52 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 20 Aug 2002 16:40:52 +0200 Subject: [6bone] Ghost routes Message-ID: <1029854452.2501.87.camel@wks1.fr.corp.ndsoftware.com> Hello, First sorry for this very long email. In this email, i will try to solve the problem of ghost routes on 6bone. I have a lot of peers (new peers are welcome), it's more easy for me to find the router of the ghost routes. I take 3ffe:200::/24 (SICS, one of ghost route) for my analysis and i do show ipv6 bgp 3ffe:200::/24 on all routers of my network. My looking-glass: http://noc.ndsoftwarenet.com/lg/ Look for: ->10318 parcr1.fr.ndsoftwarenet.net: BGP routing table entry for 3ffe:200::/24 Paths: (23 available, best #13, table Default-IP-Routing-Table) Advertised to non peer-group peers: 3ffe:81f1:0:1::2 3ffe:81f1:0:2::2 3ffe:81f1:1:2002::2 3ffe:81f1:1:2007::2 3ffe:81f1:1:200a::2 3ffe:81f1:1:200b::2 3ffe:81f1:1:200c::2 3ffe:81f1:1:2010::2 3ffe:81f1:1:2016::2 3ffe:81f1:1:201e::2 3ffe:81f1:1:201f::2 3ffe:81f1:1:2020::2 3ffe:81f1:1:2023::2 3ffe:81f1:1:2027::2 3ffe:81f1:1:2029::2 3ffe:81f1:1:202c::2 3ffe:81f1:1:202d::2 3ffe:81f1:1:202e::2 3ffe:81f1:1:2034::2 3ffe:81f1:1:2036::2 3ffe:81f1:1:2042::2 3ffe:81f1:1:2044::2 3ffe:81f1:1:2047::2 3ffe:81f1:1:2048::2 3ffe:81f1:1:2051::2 3ffe:81f1:1:2056::2 45328 8277 15589 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:202f::2 from 3ffe:81f1:1:202f::2 (131.211.28.48) (fe80::83d3:1c30) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Tue Aug 20 11:34:52 2002 9112 4554 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2018::2 from 3ffe:81f1:1:2018::2 (150.254.166.157) (fe80::96fe:a69d) Origin IGP, metric 700, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Tue Aug 20 10:53:51 2002 6342 6435 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2005::2 from 3ffe:81f1:1:2005::2 (131.178.107.1) (fe80::83b2:6408) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Tue Aug 20 00:43:41 2002 2607 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:2200:0:8012::1 from 3ffe:2200:0:8012::1 (147.175.111.61) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 22:20:27 2002 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2008::2 from 3ffe:81f1:1:2008::2 (64.71.128.26) (fe80::4047:801a) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 22:20:13 2002 5430 13285 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 2001:748:100:a0::8 from 2001:748:100:a0::8 (62.104.191.66) (fe80::3e68:bf42) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 19:44:30 2002 13110 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:400c:feed::2 from 3ffe:400c:feed::2 (62.21.98.6) (fe80::3e15:6206) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 11:14:57 2002 7521 4697 2914 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2016::2 from 3ffe:81f1:1:2016::2 (210.173.160.68) (fe80::d2ad:a044) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:500 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 21:14:53 2002 13129 1752 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:8340::1:6 from 3ffe:8340::1:6 (212.20.133.123) Origin IGP, metric 500, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 04:49:06 2002 1752 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 2001:7f8:2:c01d::2 from 2001:7f8:2:c01d::2 (213.121.24.91) (fe80::d579:185b) Origin IGP, metric 500, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 04:48:50 2002 15671 8379 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 2001:7b0:1ff::c from 2001:7b0:1ff::c (195.226.160.196) (fe80::c3e2:a0c4) Origin IGP, metric 700, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 21:14:53 2002 8379 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 2001:768:e:9::1 from 2001:768:e:9::1 (195.143.108.134) (fe80::c38f:6c86) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 21:14:26 2002 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:2900:1:9::1 from 3ffe:2900:1:9::1 (208.19.223.30) (fe80::d013:df1e) Origin IGP, metric 800, localpref 100, valid, external, best Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 04:48:26 2002 6435 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2015::2 from 3ffe:81f1:1:2015::2 (64.65.64.152) (fe80::4041:4098) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 21:21:03 2002 15589 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2017::2 from 3ffe:81f1:1:2017::2 (192.168.1.12) (fe80::3e5e:2e69) Origin IGP, metric 700, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 21:14:26 2002 12731 8379 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2037::2 from 3ffe:81f1:1:2037::2 (213.128.128.12) (fe80::d580:800c) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 21:14:45 2002 5408 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:2d00:1::2c from 3ffe:2d00:1::2c (194.177.210.38) (fe80::c2b1:d226) Origin IGP, metric 700, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 04:48:46 2002 3748 237 12199 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2033::2 from 3ffe:81f1:1:2033::2 (179.16.254.3) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 04:08:14 2002 20745 20745 20745 20745 20745 20745 20745 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:830f::6 from 3ffe:830f::6 (217.9.66.21) (fe80::d909:420a) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 21:14:53 2002 278 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2031::2 from 3ffe:81f1:1:2031::2 (192.100.200.226) (fe80::84f8:6cfe) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 21:14:33 2002 4618 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:400b:400b:: from 3ffe:400b:400b:: (203.150.16.66) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Tue Aug 20 01:44:17 2002 2042 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2012::2 from 3ffe:81f1:1:2012::2 (202.187.22.65) (fe80::cabb:1602) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 21:14:26 2002 17715 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2021::2 from 3ffe:81f1:1:2021::2 (203.66.90.5) (fe80::ca27:8e91) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 21:14:26 2002 parcr2.fr.ndsoftwarenet.net: BGP routing table entry for 3ffe:200::/24 Paths: (5 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 3ffe:81f1:0:2::2 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:0:1::1 from 3ffe:81f1:0:1::1 (213.91.4.3) (fe80::d55b:403) Origin IGP, metric 800, localpref 100, valid, internal, best Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Tue Aug 20 09:58:26 2002 762 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:1300:1:e::1 from 3ffe:1300:1:e::1 (199.242.42.3) (fe80::260:97ff:fe29:75e5) Origin IGP, metric 800, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Tue Aug 20 03:00:02 2002 8973 8664 13110 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:4008:1::11 from 3ffe:4008:1::11 (192.16.124.2) (fe80::c010:7c02) Origin IGP, metric 600, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 11:23:34 2002 1752 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 3ffe:81f1:1:2101::2 from 3ffe:81f1:1:2101::2 (193.113.58.80) (fe80::c171:3a50) Origin IGP, metric 1000, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 04:57:12 2002 8379 6939 6175 ->10318 33 22 11537 786 1849 5539 517 8472 6830 5609 1275 20834 2549 3320 24765 1930 2200 5511 8733 2611 8002 13944 15982 3265 513 559 9044 10566 7580 145 293 2001:768:e:11::1 from 2001:768:e:11::1 (195.143.108.166) (fe80::2d0:79ff:fee2:7800) Origin IGP, metric 1000, localpref 100, valid, external Community: 65526:502 65526:511 65526:521 65526:900 65526:1000 65526:1500 Last update: Mon Aug 19 21:24:07 2002 => The router of ghost routes is in AS10318 (FIBERTEL). http://www.sprintv6.net/aspath/bgp-page-complete.html confirm that (see FIBERTEL's branch). If the whois of FIBERTEL (http://whois.6bone.net/cgi-bin/whois?FIBERTEL) is update the router of FIBERTEL is cisco-ipv4.ipv6.fibertel.com.ar, a Cisco 2600. $ whois AS10318 Latin American and Caribbean IP address Regional Registry (ASN-LACNIC-10318) Chucarro 1110 ap. 5 Montevideo, 11300 UY Autonomous System Name: LACNIC-10318 Autonomous System Number: 10318 Coordinator: Latin American and Caribbean IP address Regional Registry (LACNIC-ARIN) hostmaster@lacnic.net (+55) 11 5509-3525 Record last updated on 27-Jul-2002. Database last updated on 19-Aug-2002 21:20:16 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and whois.nic.mil for NIPRNET Information. $ whois -h whois.lacnic.net AS10318 % Copyright LACNIC lacnic.net % The data below is provided for information purposes % and to assist persons in obtaining information about or % related to AS and IP numbers registrations % By submitting a whois query, you agree to use this data % only for lawful purposes. % 2002-08-20 11:21:46 (BRT -03:00) aut-num: AS10318 owner: CABLEVISION S.A. ownerid: AR-CASA8-LACNIC address: Bonpland 1745 address: Buenos Aires, 1026 country: AR owner-c: DN1372-ARIN created: 19970625 changed: 19970625 source: ARIN-LACNIC-TRANSITION nic-hdl: DN1372-ARIN person: Daniel Nofal e-mail: dnofal@CVTCI.COM.AR address: Bonpland 1745 address: 1414 Buenos Aires address: ARGENTINA country: AR phone: +541-778-6393 source: ARIN-LACNIC-TRANSITION % whois.lacnic.net accepts only direct match queries. % Types of queries are: POCs, ownerid, CIDR blocks, IP % and AS numbers. The ghost routes are: 3ffe:200::/24 http://noc.ndsoftwarenet.com/stats/aspath-tree/history/SICS.php 3ffe:1400::/24 http://noc.ndsoftwarenet.com/stats/aspath-tree/history/UNI-C.php 3ffe:1a00::/24 http://noc.ndsoftwarenet.com/stats/aspath-tree/history/CAIRN.php 3ffe:1b00::/24 http://noc.ndsoftwarenet.com/stats/aspath-tree/history/UL.php 3ffe:1e00::/24 http://noc.ndsoftwarenet.com/stats/aspath-tree/history/SWISSCOM.php 3ffe:3400::/24 No report in my ASpath-tree 3ffe:8060::/28 http://noc.ndsoftwarenet.com/stats/aspath-tree/history/ATNET-AT.php I wait your comments. Best Regards, Nicolas DEFFAYET From joao@ripe.net Tue Aug 20 15:47:12 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Tue, 20 Aug 2002 16:47:12 +0200 Subject: [6bone] pTLA request BUI - review closes 3 September 2002 In-Reply-To: <5.1.1.6.2.20020820094534.02aec490@mail.energy.local> References: <5.1.1.6.2.20020820020040.02b0cd88@mail.energy.local> <5.1.1.6.2.20020820094534.02aec490@mail.energy.local> Message-ID: Get real address space, from 2001::/3. There is nothing special about this project. Joao At 10:41 +0200 20/8/02, Giacomo Cariello wrote: >At 22.20 19/08/2002 -0400, you wrote: >>Getting PI space from your RIR is a good idea, if you qualify. I still >>don't agree wanting to participate (in a testing capacity) in the DFZ is >>justification for a pTLA. Perhaps if TILAB won't allow you to experiment >>with your /48 from them, you need to look for another pTLA that will. > >I've had a talk with CEO of Data Service, our IPv4 connectivity >partner and I agreed with him to anticipate IPv6 deployment schedule >for their organization. >Data Service would be interested in requesting a pTLA status for >IPv6 deployment reasons, which would be well justified, considering >they are an ISP serving hundreds end-sites and regional >organizations and offering various types of connectivity services. >Meanwhile, we could obtain a sub-pTLA directly from them with a >less-restrictive policy on what we can do with our assignment. >Our plan is to pass our current IPv6 structure to Data Service, in >order to speed up their startup period. Some of their tech employees >have collaborated with us to create our current IPv6 network, >therefore I suppose there will be no problem with that. >If it sounds reasonable, I'll contact Data Service and have them >start an IPv6 allocation plan and the request procedures for a 6bone >pTLA. > > > >Giacomo Cariello, jwk@bug.it >KeyID: 3072/1024/0x409C9044 >Fingerprint: 7984 10FD 0460 4202 BF90 3881 CDE4 D78E 409C 9044 > >"Put that mic in my hand and let me kick out the jams!" - MC5 > > >_______________________________________________ >6bone mailing list >6bone@mailman.isi.edu >http://mailman.isi.edu/mailman/listinfo/6bone From galania@ipv6.inictel.gob.pe Tue Aug 20 15:50:20 2002 From: galania@ipv6.inictel.gob.pe (Gino Francisco Alania Hurtado) Date: Tue, 20 Aug 2002 09:50:20 -0500 Subject: [6bone] Re: (usagi-users 01749) two address References: <3D624D49.1090004@ipv6.inictel.gob.pe> <20020820.232955.53308759.yoshfuji@linux-ipv6.org> Message-ID: <3D62572C.6020006@ipv6.inictel.gob.pe> Good, it compiles kernel with the USAGI, the version it is of the 2,4,18, indeed with this the normal thing is that aparesca a global direction ipv6 but adds a direction to me but, knowledge treatment that or who generates that new direction. Somebody quizas I solve east problem? YOSHIFUJI Hideaki / ???? wrote: >In article <3D624D49.1090004@ipv6.inictel.gob.pe> (at Tue, 20 Aug 2002 09:08:09 -0500), Gino Francisco Alania Hurtado says: > >>Consultations friends, using linux-usagi I have a particularitity, when >>I do ifconfig appears ipv6 global two-way traffic: >>[root@ipv6 gino]# ifconfig >> >: > >>eth0 Link encap:Ethernet HWaddr 00:01:02:2A:72:85 >> inet addr:200.60.172.132 Bcast:200.60.172.159 >>Mask:255.255.255.224 >> inet6 addr: 3ffe:8260:200e:1001:846a:bebb:5040:f4cd/64 >>Scope:Global >> inet6 addr: fe80::201:2ff:fe2a:7285/64 Scope:Link >> inet6 addr: 3ffe:8260:200e:1001:201:2ff:fe2a:7285/64 Scope:Global >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> >: > >I wonder I don't understand your question / problem. >Could you explain further details, please? > >--yoshfuji > From gert@space.net Tue Aug 20 16:38:51 2002 From: gert@space.net (Gert Doering) Date: Tue, 20 Aug 2002 17:38:51 +0200 Subject: [6bone] Ghost routes In-Reply-To: <1029854452.2501.87.camel@wks1.fr.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Tue, Aug 20, 2002 at 04:40:52PM +0200 References: <1029854452.2501.87.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20020820173851.J27015@Space.Net> Hi, On Tue, Aug 20, 2002 at 04:40:52PM +0200, Nicolas DEFFAYET wrote: > The ghost routes are: > 3ffe:200::/24 > http://noc.ndsoftwarenet.com/stats/aspath-tree/history/SICS.php > > 3ffe:1400::/24 > http://noc.ndsoftwarenet.com/stats/aspath-tree/history/UNI-C.php > > 3ffe:1a00::/24 > http://noc.ndsoftwarenet.com/stats/aspath-tree/history/CAIRN.php Interesting enough, those routes are not in the table at all over here. > 3ffe:1b00::/24 > http://noc.ndsoftwarenet.com/stats/aspath-tree/history/UL.php This prefix is seen, common element in all paths is "33 10318" (while your paths for 3ffe:200::/24 have 10318 33). So the culprit could be 33 (as someone else suspected) or 10318. > 3ffe:1e00::/24 > http://noc.ndsoftwarenet.com/stats/aspath-tree/history/SWISSCOM.php This one has a common tail that starts with "10318 33". Weird. > 3ffe:3400::/24 > No report in my ASpath-tree This one is interesting, as the common tail is ... 1275 8319 13129 1752 8472 3561 3748 237 12199 10318 33 6939 6175 7580 145 293 5609 6830 8379 15982 3320 33 and 10318 are involved, but I have no other paths to 10318 than over this very long chain. > 3ffe:8060::/28 > http://noc.ndsoftwarenet.com/stats/aspath-tree/history/ATNET-AT.php Not in table. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45583 (46871) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From yoshfuji@linux-ipv6.org Tue Aug 20 17:30:55 2002 From: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Wed, 21 Aug 2002 01:30:55 +0900 (JST) Subject: [6bone] Re: (usagi-users 01752) Re: two address In-Reply-To: <3D62572C.6020006@ipv6.inictel.gob.pe> References: <3D624D49.1090004@ipv6.inictel.gob.pe> <20020820.232955.53308759.yoshfuji@linux-ipv6.org> <3D62572C.6020006@ipv6.inictel.gob.pe> Message-ID: <20020821.013055.14473757.yoshfuji@linux-ipv6.org> In article <3D62572C.6020006@ipv6.inictel.gob.pe> (at Tue, 20 Aug 2002 09:50:20 -0500), Gino Francisco Alania Hurtado says: > Good, it compiles kernel with the USAGI, the version it is of the > 2,4,18, indeed with this the normal thing is that aparesca a global > direction ipv6 but adds a direction to me but, knowledge treatment that > or who generates that new direction. Somebody quizas I solve east problem? ... I don't understand ... What do you mean by "aparesca", "quizas", "new direction" and "east problem"??? If you are talking about "link" scope addresses, see RFC2373. If your are talking about additional "global" scope addresses, see RFC3041. --yoshfuji From fink@es.net Tue Aug 20 17:49:45 2002 From: fink@es.net (Bob Fink) Date: Tue, 20 Aug 2002 09:49:45 -0700 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs Message-ID: <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> 6bone Folk, As mentioned previously, and presented at the Yokohama IETF 6bone meeting, I have been discussing with the management of the three Regional Internet Registries (APNIC, ARIN, and RIPE) the transfer of 6bone 3FFE::/16 address space management to the RIRs. These discussions have been successful in that I believe we are in agreement enough that it is the time to move the discussion to the 6bone list and the RIR communities. I believe that it is time for such a transfer due to the evolution of IPv6 address allocation policies and procedures, by the RIRs, to a place of wide acceptance by the Internet community such that the 6bone should no longer be considered an address registry outside of the RIR process. Also, it is not in the best interest of the evolution and integration of IPv6 into the Internet to be relying on an individual for most of the 6bone allocation process (me :-); However, I am more than willing to give advice and assistance during a transfer as needed. I'm including the text below of the "Policies for transfer of 6bone address management responsibilities to RIRs", that was the basis of the presentation I made in Yokohama. For the presentation, see: under the 2nd heading, in either pdf or ppt. Please send your comments to the 6bone list. The RIRs will be doing a similar review within their communities and we will do our best to correlate and summarize the collective responses, issues, concerns and changes made by the 6bone and RIR communities. I would expect the rough timeline for this review process to be until the end of the calendar year. Thanks, Bob === Policies for transfer of 6bone address management responsibilities to RIRs Version: 20 August 2002 1. Introduction 6bone was established in 1996 as a continuing IPv6 test bed with the original purpose of testing of standards and implementations, and the more current focus on testing of transition and operational procedures, as well as application conversion. It provides an opportunity for those wanting early experience and/or needing to experiment with IPv6, with a minimum of startup complexity, particularly in terms of address management policies, and at minimal cost. It also provides an open peer process for information, hookup help, and support, with strong ties to the IETF process as well as to the operational community. To date, 6bone address space has been allocated and registered in an informal process quite separate from the existing Regional Internet Registry system. The purpose of this proposal is to establish a long term model that provides for a more "official" home for 6bone address space management within the established Internet administrative structures. At the same time, the proposal recognizes that 6bone's most important functions as an accessible and informal test bed network must be maintained. This document proposes the transfer of responsibility for administration of 6bone address space (3ffe::/16) to the Regional Internet Address Registries (RIRs). It describes a set of policies and procedures for this transfer, and for the ongoing administration of 6bone address space within the RIR framework. It should be noted that the ongoing operation of the 6bone, and policies related to it, are still the purview of the 6bone community itself. For example, 6bone network compliance with the 6bone routing guidelines is a matter for the community itself to resolve, typically by mail lists. It is also important to continue the strongly volunteer efforts of the 6bone, both to make it as easy and friendly as possible for individuals, sites and networks to experiment and learn about IPv6, but also to keep the process streamlined and cost-effective. 2. Definitions a) "6bone" and "6bone community", as it appears in section 3 below, means 6bone organizations and individuals including the RIRs, "6bone members" (see below), and those participating in the 6bone mail list. b) 6bone members are defined as entities which are approved for address space allocation by the 6bone community in accordance with 6bone policies, and who agree to be bound by those policies and the policies stated below. c) 6bone allocations are allocations of 6bone address space which are held by 6bone members, or made to 6bone members in accordance with these policies. d) 6bone address space is defined as IPv6 address space within the 3ffe::/16 address block. 3. Policies 3.1 General a) In consultation with 6bone, RIRs will implement a common set of policies applying specifically to 6bone allocations. This will follow the current RFC2772, "6Bone Backbone Routing Guidelines" and/or successor documents resulting as an evolution of conversations in the 6bone community and the RIRs.; b) 6bone members will be served by respective RIR in their region, for "6bone Address Services" including 6bone address allocation, database registration and maintenance, and ip6.arpa registration (as described below); c) In order to receive 6bone address services from an RIR as described here, each 6bone member must "join" that RIR, that is, enter into the appropriate membership or services agreement with the RIR. d) RIR fees will be waived for 6bone address services provided by RIRs to 6bone members (but not for other services 6bone members may require), until 1 year after this agreement starts. After this time each RIR may charge an administration fee to cover each allocation made. This fee simply covers registration and maintenance, rather than the full allocation process for standard RIR members. This administration fee should be as low as possible as these requests do not have to undergo the same evaluation process as those requested in the normal policy environment. e) Organizations may receive 6bone address services from the RIR only on approval by 6bone, and in accordance with these policies; f) 6bone members will have the option to receive other services from an RIR (including allocation of production IPv6 address space), by following the policy, process and procedures in place at the time of application for those services. g) Continuing compliance with 6bone policies, and with the policies defined here, will be verified by 6bone at least every 2 years; 3.2 6bone Address Services a) 6bone Address Services include allocation of 6bone address space, registration and maintenance of database records relating to that address space, and registration of ip6.arpa records; b) 6bone address space allocations will be made from 3ffe::/16 and only /32 prefixes will be allocated. There will be exceptions for unusual and new proposals per joint RIR and 6bone review and approval. A relevant example of this is one or more new strategies such as geographic or metro addressing; c) No additional 6-bone address space will be allocated to any 6bone member (therefore no provision will be made for aggregation of multiple allocations, reservations etc); d) 6bone address services will be provided strictly for experimental, non-commercial use; e) Allocations will be made on the clear and stated understanding that the prefix 3ffe::/16 has a limited lifetime. The dates for the termination of allocation from the prefix and the expiration of the prefix will be determined at a future date. The RIRs will not participate in these determinations. f) 6bone address space will be returned to the RIR when no longer in use, when reclaimed due to non-compliance with 6bone or RIR policies, or when 3ffe: space is finally withdrawn. g) Registration of 6bone address space within the ip6.int zone is not covered by this policy, and is at option of 6bone member; h) Registration of 6bone sites, maintainers, persons and address space within the existing consolidated 6bone registry is not covered by this policy, and is at option of 6bone and its current policies. 3.3 Transfer of existing 6bone members a) Responsibility for existing 6bone members in respect of services described here will be transferred from 6bone to the respective RIR, at the option of those members individually, on entering into the appropriate agreement with the RIR; b) On joining the RIR, 6bone address registration records for the member concerned will be transferred from 6bone registry to the respective RIR database,; c) On joining the RIR, 6bone members may establish ip6.arpa delegation records in accordance with applicable RIR procedures; d) Legacy holders will use RIR administrative procedures for management of their records; e) There will be a sunset (2 years?) on existing 6bone members not transferring to RIR administrative procedures, after which their address allocation will be revoked. -end From nicolas.deffayet@ndsoftware.net Tue Aug 20 20:03:43 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 20 Aug 2002 21:03:43 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> References: <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> Message-ID: <1029870223.2530.133.camel@wks1.fr.corp.ndsoftware.com> On Tue, 2002-08-20 at 18:49, Bob Fink wrote: > > c) In order to receive 6bone address services from an RIR as described > here, each 6bone member must "join" that RIR, that is, enter into the > appropriate membership or services agreement with the RIR. I'm not agree with that. appropriate membership = LIR ? If yes, it's very bad; a lot of pTLA aren't LIR and a LIR can request a sTLA, why a LIR will request a 6bone address space ? 6bone must be open, free and independent. A pTLA request must be free and without membership. > > d) RIR fees will be waived for 6bone address services provided by RIRs to > 6bone members (but not for other services 6bone members may require), until > 1 year after this agreement starts. After this time each RIR may charge an > administration fee to cover each allocation made. This fee simply covers > registration and maintenance, rather than the full allocation process for > standard RIR members. This administration fee should be as low as possible > as these requests do not have to undergo the same evaluation process as > those requested in the normal policy environment. 6bone address services must be free. Since 1996 it's free and it's workfine ! Best Regards, Nicolas DEFFAYET From riel@conectiva.com.br Tue Aug 20 21:57:33 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Tue, 20 Aug 2002 17:57:33 -0300 (BRT) Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <1029870223.2530.133.camel@wks1.fr.corp.ndsoftware.com> Message-ID: On 20 Aug 2002, Nicolas DEFFAYET wrote: > On Tue, 2002-08-20 at 18:49, Bob Fink wrote: > > > > c) In order to receive 6bone address services from an RIR as described > > here, each 6bone member must "join" that RIR, that is, enter into the > > appropriate membership or services agreement with the RIR. > > I'm not agree with that. > > appropriate membership = LIR ? > If yes, it's very bad; a lot of pTLA aren't LIR and a LIR can request a > sTLA, why a LIR will request a 6bone address space ? > > 6bone must be open, free and independent. > A pTLA request must be free and without membership. Agreed. 6bone is essential for those areas of the internet where the "normal" providers do not offer ipv6 yet. It would be a shame if the ipv6 community would kick it's current user community out the door... regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From galania@ipv6.inictel.gob.pe Tue Aug 20 22:28:33 2002 From: galania@ipv6.inictel.gob.pe (Gino Francisco Alania Hurtado) Date: Tue, 20 Aug 2002 16:28:33 -0500 Subject: [6bone] help me : routing References: <3D624D49.1090004@ipv6.inictel.gob.pe> <20020820.232955.53308759.yoshfuji@linux-ipv6.org> <3D62572C.6020006@ipv6.inictel.gob.pe> <20020821.013055.14473757.yoshfuji@linux-ipv6.org> Message-ID: <3D62B481.2040305@ipv6.inictel.gob.pe> a consultation from my router with zebra I do: [root@inter2 root]# traceroute6 www.6bone.net traceroute to 6bone.net (3ffe:b00:c18:1::10) from 3ffe:8070:101a::2, 30 hops max, 16 byte packets 1 3ffe:8070:101a::1 (3ffe:8070:101a::1) 663.244 ms 496.432 ms 726.74 ms 2 3ffe:1cff:0:f4::1 (3ffe:1cff:0:f4::1) 831.959 ms 914.281 ms 904.641 ms 3 3ffe:b00:c18:1:290:27ff:fe17:fc0f (3ffe:b00:c18:1:290:27ff:fe17:fc0f) 974.307 ms 797.269 ms * 4 3ffe:b00:c18:1::10 (3ffe:b00:c18:1::10) 1003.09 ms * * But from host I cannot do it, is evident that my zebra-bgpd not this formed good, I have the following configuration: [root@host root]# traceroute6 3ffe:8260:200e:fffd::1 traceroute to 3ffe:8260:200e:fffd::1 (3ffe:8260:200e:fffd::1) from 3ffe:8070:101a:1001:260:8ff:fecb:7e84, 30 hops max, 16 byte packets 1 3ffe:8070:101a:1001:201:2ff:fe7c:ef79 (3ffe:8070:101a:1001:201:2ff:fe7c:ef79) 1.199 ms 1.219 ms 1.144 ms 2 * * * * 3 * * * * vi /usr/local/zebra/etc/zebra.conf : ----------------------------------------------------- hostname inter2 password ********* enable password ******** log file /var/log/zebra/zebra.log service advanced-vty ! interface eth0 ipv6 nd send-ra ipv6 nd prefix-advertisement 3ffe:8070:101a:1001::/64 ! interface inter2 ! line vty ! -------------------------------------------------------- vi /usr/local/zebra/etc/bgpd.conf : -------------------------------------------------------- hostname inter2 password ************* enable password ********** log file /var/log/zebra/bgpd.log service advanced-vty ! ! You are free to add extra tunnels to other sites in 3ffe:8260::2000/40, ! but make sure you really understand RFC 2772 before trying to make ! private peering agreements with anybody else... ! router bgp 46014 ipv6 bgp network 3ffe:8070:101a::/48 !nuevo tunnel itesm ipv6 bgp neighbor 3ffe:8070:101a::1 remote-as 278 ipv6 bgp neighbor 3ffe:8070:101a::1 interface inter2 ipv6 bgp neighbor 3ffe:8070:101a::1 description UNAM mexico 6bone ipv6 bgp neighbor 3ffe:8070:101a::1 next-hop-self ! access-list all permit any ! line vty ! ---------------------------------------------------- vi /etc/radvd : ---------------------------------------------------- interface eth0 { AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; prefix 3ffe:8070:101a:1001::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; }; -------------------------------------------------------- somebody can help me, that this failing, please thanks !! From nicolas.deffayet@ndsoftware.net Tue Aug 20 23:10:54 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 21 Aug 2002 00:10:54 +0200 Subject: [6bone] Re: (usagi-users 01757) help me : routing In-Reply-To: <3D62B481.2040305@ipv6.inictel.gob.pe> References: <3D624D49.1090004@ipv6.inictel.gob.pe> <20020820.232955.53308759.yoshfuji@li nux-ipv6.org> <3D62572C.6020006@ipv6.inictel.gob.pe> <20020821.013055.14473757.yoshfuji@linux-ipv6.org> <3D62B481.2040305@ipv6.inictel.gob.pe> Message-ID: <1029881454.2493.149.camel@wks1.fr.corp.ndsoftware.com> On Tue, 2002-08-20 at 23:28, Gino Francisco Alania Hurtado wrote: > a consultation from my router with zebra I do: > [root@inter2 root]# traceroute6 www.6bone.net > traceroute to 6bone.net (3ffe:b00:c18:1::10) from 3ffe:8070:101a::2, 30 > hops max, 16 byte packets > 1 3ffe:8070:101a::1 (3ffe:8070:101a::1) 663.244 ms 496.432 ms 726.74 ms > 2 3ffe:1cff:0:f4::1 (3ffe:1cff:0:f4::1) 831.959 ms 914.281 ms > 904.641 ms > 3 3ffe:b00:c18:1:290:27ff:fe17:fc0f > (3ffe:b00:c18:1:290:27ff:fe17:fc0f) 974.307 ms 797.269 ms * > 4 3ffe:b00:c18:1::10 (3ffe:b00:c18:1::10) 1003.09 ms * * > You can trace because your router use the tunnel's IPs. > > But from host I cannot do it, is evident that my zebra-bgpd not this > formed good, I have the following configuration: > > [root@host root]# traceroute6 3ffe:8260:200e:fffd::1 > traceroute to 3ffe:8260:200e:fffd::1 (3ffe:8260:200e:fffd::1) from > 3ffe:8070:101a:1001:260:8ff:fecb:7e84, 30 hops max, 16 byte packets > 1 3ffe:8070:101a:1001:201:2ff:fe7c:ef79 > (3ffe:8070:101a:1001:201:2ff:fe7c:ef79) 1.199 ms 1.219 ms 1.144 ms > 2 * * * * > 3 * * * * > ~$ traceroute6 3ffe:8260:200e:fffd::1 traceroute to 3ffe:8260:200e:fffd::1 (3ffe:8260:200e:fffd::1) from 3ffe:81f1:21:1::5, 30 hops max, 16 byte packets 1 feth1-0-levgw1.fr.corp.ndsoftware.net (3ffe:81f1:21:1::1) 0.216 ms 0.178 ms 0.223 ms 2 eth1-0-parcr2.fr.ndsoftwarenet.net (3ffe:81f1:12:1::1) 1.03 ms 1.942 ms 1.683 ms 3 feth0-1-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:0:1::1) 132.792 ms 193.106 ms 69.717 ms 4 * compendium-ar-gw-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:1:202f::2) 94.523 ms !H 98.792 ms !H Route missing on COMPENDIUM-AR router. ~$ traceroute6 3ffe:8070:101a:1001:260:8ff:fecb:7e84 traceroute to 3ffe:8070:101a:1001:260:8ff:fecb:7e84 (3ffe:8070:101a:1001:260:8ff:fecb:7e84) from 3ffe:81f1:21:1::5, 30 hops max, 16 byte packets 1 feth1-0-levgw1.fr.corp.ndsoftware.net (3ffe:81f1:21:1::1) 0.216 ms 0.164 ms 0.13 ms 2 eth1-0-parcr2.fr.ndsoftwarenet.net (3ffe:81f1:12:1::1) 1.444 ms 1.046 ms 0.973 ms 3 feth0-1-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:0:1::1) 68.132 ms 77.848 ms 76.148 ms 4 unam-gw-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:1:2031::2) 304.114 ms * 293.776 ms 5 * unam-gw-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:1:2031::2) 3321.15 ms !H 3306.1 ms !H Route missing on UNAM router. $ traceroute6 3ffe:8070:101a::2 traceroute to 3ffe:8070:101a::2 (3ffe:8070:101a::2) from 3ffe:81f1:21:1::5, 30 hops max, 16 byte packets 1 feth1-0-levgw1.fr.corp.ndsoftware.net (3ffe:81f1:21:1::1) 0.206 ms 0.167 ms 0.13 ms 2 eth1-0-parcr2.fr.ndsoftwarenet.net (3ffe:81f1:12:1::1) 1.104 ms 1.025 ms 1.001 ms 3 feth0-1-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:0:1::1) 97.304 ms 101.802 ms 73.949 ms 4 unam-gw-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:1:2031::2) 298.556 ms * 294.819 ms 5 3ffe:8070:101a::2 (3ffe:8070:101a::2) 1174 ms 1175.89 ms * Your tunnel work. Best Regards, Nicolas DEFFAYET From galania@ipv6.inictel.gob.pe Tue Aug 20 23:19:49 2002 From: galania@ipv6.inictel.gob.pe (Gino Francisco Alania Hurtado) Date: Tue, 20 Aug 2002 17:19:49 -0500 Subject: [6bone] Re: (usagi-users 01757) help me : routing References: <3D624D49.1090004@ipv6.inictel.gob.pe> <20020820.232955.53308759.yoshfuji@li nux-ipv6.org> <3D62572C.6020006@ipv6.inictel.gob.pe> <20020821.013055.14473757.yoshfuji@linux-ipv6.org> <3D62B481.2040305@ipv6.inictel.gob.pe> <1029881454.2493.149.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <3D62C085.6070203@ipv6.inictel.gob.pe> sorry , my host have : [root@host root]# ifconfig eth0 Link encap:Ethernet HWaddr 00:60:08:CB:7E:84 inet addr:200.60.172.137 Bcast:200.60.172.159 Mask:255.255.255.224 inet6 addr: fe80::260:8ff:fecb:7e84/10 Scope:Link *inet6 addr: 3ffe:8070:101a:1001:260:8ff:fecb:7e84/64 Scope:Global* UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:44762 errors:0 dropped:0 overruns:0 frame:0 TX packets:1038 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:18330936 (17.4 Mb) TX bytes:127363 (124.3 Kb) Interrupt:10 Base address:0xdc00 my router : [root@inter2 root]# ifconfig eth0 Link encap:Ethernet HWaddr 00:01:02:7C:EF:79 inet addr:200.60.172.144 Bcast:200.60.172.159 Mask:255.255.255.224 inet6 addr: fe80::201:2ff:fe7c:ef79/64 Scope:Link *inet6 addr: 3ffe:8260:200e:1001:201:2ff:fe7c:ef79/64 Scope:Global* UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8776 errors:0 dropped:0 overruns:0 frame:0 TX packets:583 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:3688569 (3.5 Mb) TX bytes:64044 (62.5 Kb) Interrupt:11 Base address:0xc000 inter2 Link encap:IPv6-in-IPv4 inet6 addr: fe80::c83c:ac90/128 Scope:Link i*net6 addr: 3ffe:8070:101a::2/64 Scope:Global* UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1 RX packets:171 errors:0 dropped:0 overruns:0 frame:0 TX packets:214 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11508 (11.2 Kb) TX bytes:19200 (18.7 Kb) then : [root@host root]# traceroute6 www.6bone.net traceroute to 6bone.net (3ffe:b00:c18:1::10) from *3ffe:8070:101a:1001:260:8ff:fecb:7e84* , 30 hops max, 16 byte packets 1 3ffe:8070:101a:1001:201:2ff:fe7c:ef79 (3ffe:8070:101a:1001:201:2ff:fe7c:ef79) 5.46 ms 1.245 ms 1.136 ms 2 * * * * 3 * * * * etc .. the configurations of zebra and radvd previously... that estara failing? Nicolas DEFFAYET wrote: >On Tue, 2002-08-20 at 23:28, Gino Francisco Alania Hurtado wrote: > >>a consultation from my router with zebra I do: >>[root@inter2 root]# traceroute6 www.6bone.net >>traceroute to 6bone.net (3ffe:b00:c18:1::10) from 3ffe:8070:101a::2, 30 >>hops max, 16 byte packets >> 1 3ffe:8070:101a::1 (3ffe:8070:101a::1) 663.244 ms 496.432 ms 726.74 ms >> 2 3ffe:1cff:0:f4::1 (3ffe:1cff:0:f4::1) 831.959 ms 914.281 ms >>904.641 ms >> 3 3ffe:b00:c18:1:290:27ff:fe17:fc0f >>(3ffe:b00:c18:1:290:27ff:fe17:fc0f) 974.307 ms 797.269 ms * >> 4 3ffe:b00:c18:1::10 (3ffe:b00:c18:1::10) 1003.09 ms * * >> > >You can trace because your router use the tunnel's IPs. > >>But from host I cannot do it, is evident that my zebra-bgpd not this >>formed good, I have the following configuration: >> >>[root@host root]# traceroute6 3ffe:8260:200e:fffd::1 >>traceroute to 3ffe:8260:200e:fffd::1 (3ffe:8260:200e:fffd::1) from >>3ffe:8070:101a:1001:260:8ff:fecb:7e84, 30 hops max, 16 byte packets >> 1 3ffe:8070:101a:1001:201:2ff:fe7c:ef79 >>(3ffe:8070:101a:1001:201:2ff:fe7c:ef79) 1.199 ms 1.219 ms 1.144 ms >> 2 * * * * >> 3 * * * * >> > >~$ traceroute6 3ffe:8260:200e:fffd::1 >traceroute to 3ffe:8260:200e:fffd::1 (3ffe:8260:200e:fffd::1) from >3ffe:81f1:21:1::5, 30 hops max, 16 byte packets > 1 feth1-0-levgw1.fr.corp.ndsoftware.net (3ffe:81f1:21:1::1) 0.216 ms >0.178 ms 0.223 ms > 2 eth1-0-parcr2.fr.ndsoftwarenet.net (3ffe:81f1:12:1::1) 1.03 ms >1.942 ms 1.683 ms > 3 feth0-1-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:0:1::1) 132.792 ms >193.106 ms 69.717 ms > 4 * compendium-ar-gw-parcr1.fr.ndsoftwarenet.net >(3ffe:81f1:1:202f::2) 94.523 ms !H 98.792 ms !H > >Route missing on COMPENDIUM-AR router. > >~$ traceroute6 3ffe:8070:101a:1001:260:8ff:fecb:7e84 >traceroute to 3ffe:8070:101a:1001:260:8ff:fecb:7e84 >(3ffe:8070:101a:1001:260:8ff:fecb:7e84) from 3ffe:81f1:21:1::5, 30 hops >max, 16 byte packets > 1 feth1-0-levgw1.fr.corp.ndsoftware.net (3ffe:81f1:21:1::1) 0.216 ms >0.164 ms 0.13 ms > 2 eth1-0-parcr2.fr.ndsoftwarenet.net (3ffe:81f1:12:1::1) 1.444 ms >1.046 ms 0.973 ms > 3 feth0-1-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:0:1::1) 68.132 ms >77.848 ms 76.148 ms > 4 unam-gw-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:1:2031::2) 304.114 >ms * 293.776 ms > 5 * unam-gw-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:1:2031::2) 3321.15 >ms !H 3306.1 ms !H > >Route missing on UNAM router. > >$ traceroute6 3ffe:8070:101a::2 >traceroute to 3ffe:8070:101a::2 (3ffe:8070:101a::2) from >3ffe:81f1:21:1::5, 30 hops max, 16 byte packets > 1 feth1-0-levgw1.fr.corp.ndsoftware.net (3ffe:81f1:21:1::1) 0.206 ms >0.167 ms 0.13 ms > 2 eth1-0-parcr2.fr.ndsoftwarenet.net (3ffe:81f1:12:1::1) 1.104 ms >1.025 ms 1.001 ms > 3 feth0-1-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:0:1::1) 97.304 ms >101.802 ms 73.949 ms > 4 unam-gw-parcr1.fr.ndsoftwarenet.net (3ffe:81f1:1:2031::2) 298.556 >ms * 294.819 ms > 5 3ffe:8070:101a::2 (3ffe:8070:101a::2) 1174 ms 1175.89 ms * > >Your tunnel work. > >Best Regards, > >Nicolas DEFFAYET > From nicolas.deffayet@ndsoftware.net Tue Aug 20 23:34:49 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 21 Aug 2002 00:34:49 +0200 Subject: [6bone] Re: (usagi-users 01757) help me : routing In-Reply-To: <3D62C085.6070203@ipv6.inictel.gob.pe> References: <3D624D49.1090004@ipv6.inictel.gob.pe> <20020820.232955.53308759.yoshfuji@li nux-ipv6.org> <3D62572C.6020006@ipv6.inictel.gob.pe> <20020821.013055.144737 57.yoshfuji@linux-ipv6.org> <3D62B481.2040305@ipv6.inictel.gob.pe> <1029881454.2493.149.camel@wks1.fr.corp.ndsoftware.com> <3D62C085.6070203@ipv6.inictel.gob.pe> Message-ID: <1029882889.2530.152.camel@wks1.fr.corp.ndsoftware.com> On Wed, 2002-08-21 at 00:19, Gino Francisco Alania Hurtado wrote: > > the configurations of zebra and radvd previously... that estara failing? > You must ask UNAM and COMPENDIUM-AR for check routing to you. Best Regards, Nicolas DEFFAYET From rmk@arm.linux.org.uk Wed Aug 21 00:17:52 2002 From: rmk@arm.linux.org.uk (Russell King) Date: Wed, 21 Aug 2002 00:17:52 +0100 Subject: [6bone] Re: (usagi-users 01757) help me : routing In-Reply-To: <1029882889.2530.152.camel@wks1.fr.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Wed, Aug 21, 2002 at 12:34:49AM +0200 References: <3D624D49.1090004@ipv6.inictel.gob.pe> <20020820.232955.53308759.yoshfuji@li <3D62572C.6020006@ipv6.inictel.gob.pe> <20020821.013055.144737 <3D62B481.2040305@ipv6.inictel.gob.pe> <1029881454.2493.149.camel@wks1.fr.corp.ndsoftware.com> <3D62C085.6070203@ipv6.inictel.gob.pe> <1029882889.2530.152.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20020821001752.D31614@flint.arm.linux.org.uk> On Wed, Aug 21, 2002 at 12:34:49AM +0200, Nicolas DEFFAYET wrote: > On Wed, 2002-08-21 at 00:19, Gino Francisco Alania Hurtado wrote: > > > > the configurations of zebra and radvd previously... that estara failing? > You must ask UNAM and COMPENDIUM-AR for check routing to you. Here's a couple of traceroutes from within COMPENDIUM-AR pTLA to both: 3ffe:8070:101a::2 3ffe:8070:101a:1001:260:8ff:fecb:7e84 Note that the second one stops at 3ffe:8070:1:13::1 (ICMP errors indicate "Address unreachable".) I suspect 3ffe:8070:1:13::1 doesn't know to forward the your other addresses to you. traceroute to 3ffe:8070:101a::2 (3ffe:8070:101a::2) from 3ffe:8260:2002:fffe::2, 30 hops max, 16 byte packets 1 nlo-gw.remote (3ffe:8260:2002:fffe::1) 36.818 ms 38.026 ms 37.981 ms 2 3ffe:8100:200:2fff::8 (3ffe:8100:200:2fff::8) 49.71 ms * 47.955 ms 3 edt-euronet.ipv6.edisontel.it (3ffe:8170:1:10::1) 91.766 ms 94.117 ms 92.057 ms 4 3ffe:80c0:200:5::22 (3ffe:80c0:200:5::22) 238.028 ms 240.992 ms 239.277 ms 5 3ffe:8070:1:13::1 (3ffe:8070:1:13::1) 433.069 ms * 431.097 ms 6 3ffe:8070:101a::2 (3ffe:8070:101a::2) 990.993 ms 1015.05 ms 1217.12 ms traceroute to 3ffe:8070:101a:1001:260:8ff:fecb:7e84 (3ffe:8070:101a:1001:260:8ff:fecb:7e84) from 3ffe:8260:2002:fffe::2, 30 hops max, 16 byte packets 1 nlo-gw.remote (3ffe:8260:2002:fffe::1) 37.3 ms 37.617 ms 34.967 ms 2 3ffe:8100:200:2fff::8 (3ffe:8100:200:2fff::8) 48.978 ms * 47.501 ms 3 edt-euronet.ipv6.edisontel.it (3ffe:8170:1:10::1) 91.166 ms 90.711 ms 92.088 ms 4 3ffe:80c0:200:5::22 (3ffe:80c0:200:5::22) 241.358 ms 239.839 ms 239.061 ms 5 3ffe:8070:1:13::1 (3ffe:8070:1:13::1) 433.106 ms * 430.6 ms 6 3ffe:8070:1:13::1 (3ffe:8070:1:13::1) 3434.07 ms !H 3515.56 ms !H 3491.21 ms !H -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html From Robert.Kiessling@de.easynet.net Wed Aug 21 00:51:14 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 21 Aug 2002 00:51:14 +0100 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: References: Message-ID: Rik van Riel writes: > Agreed. 6bone is essential for those areas of the internet > where the "normal" providers do not offer ipv6 yet. 6bone is a major source of instability for the production IPv6 network and thus hinders deployment of IPv6. You cannot seriously recomment anyone to trust production services to a network in which a single faulty BGP implementation can and does repeatedly bring down half the network (as recenty seen by AS1654). > It would be a shame if the ipv6 community would kick it's > current user community out the door... There's now a lot of production IPv6 connectivity available, and I'm pretty sure that the backbone which now deploy IPv6 natively can agree to provide sufficient IPv6 connecticity, in return for a stable network. I don't see much need for an integrated extensively tunneled experimental-software IPv6 network any more. Well-controlled end sites and address allocation to them for experimental purposes is a different story, but them must be isolated so they cannot wreak havoc to the rest of the world. Robert From riel@conectiva.com.br Wed Aug 21 00:42:26 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Tue, 20 Aug 2002 20:42:26 -0300 (BRT) Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: Message-ID: On 21 Aug 2002, Robert Kiessling wrote: > Rik van Riel writes: > > > Agreed. 6bone is essential for those areas of the internet > > where the "normal" providers do not offer ipv6 yet. > > 6bone is a major source of instability for the production IPv6 network > and thus hinders deployment of IPv6. [snip] > Well-controlled end sites and address allocation to them for > experimental purposes is a different story, but them must be isolated > so they cannot wreak havoc to the rest of the world. Agreed. We want to isolate the production and experimental ipv6 networks somewhat, to make sure the production network stays stable and won't be affected by instabilities in the exerimental network. I just hope this will be done in a way that doesn't cut any of the current ipv6 users from the ipv6 internet. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From nicolas.deffayet@ndsoftware.net Wed Aug 21 00:55:22 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 21 Aug 2002 01:55:22 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: References: Message-ID: <1029887722.2493.162.camel@wks1.fr.corp.ndsoftware.com> On Wed, 2002-08-21 at 01:51, Robert Kiessling wrote: > Rik van Riel writes: > > > Agreed. 6bone is essential for those areas of the internet > > where the "normal" providers do not offer ipv6 yet. > > 6bone is a major source of instability for the production IPv6 network > and thus hinders deployment of IPv6. Not fully agree. The problem of instability can be do by sTLA. > > You cannot seriously recomment anyone to trust production services to > a network in which a single faulty BGP implementation can and does > repeatedly bring down half the network (as recenty seen by AS1654). The problem of AS1654 can be too on production network... > > > It would be a shame if the ipv6 community would kick it's > > current user community out the door... > > There's now a lot of production IPv6 connectivity available, and I'm > pretty sure that the backbone which now deploy IPv6 natively can agree > to provide sufficient IPv6 connecticity, in return for a stable > network. Not in all city and in all country... Regards, Nicolas DEFFAYET From nicolas.deffayet@ndsoftware.net Wed Aug 21 00:57:21 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 21 Aug 2002 01:57:21 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: References: Message-ID: <1029887841.2530.167.camel@wks1.fr.corp.ndsoftware.com> On Wed, 2002-08-21 at 01:42, Rik van Riel wrote: > > Agreed. We want to isolate the production and experimental > ipv6 networks somewhat, to make sure the production network > stays stable and won't be affected by instabilities in the > exerimental network. > > I just hope this will be done in a way that doesn't cut any > of the current ipv6 users from the ipv6 internet. > Not easy to isolate the production and experimental ipv6 networks. A lot of ISP use the same routers for 6bone and production activities. Best Regards, Nicolas DEFFAYET From bmanning@ISI.EDU Wed Aug 21 01:26:46 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Tue, 20 Aug 2002 17:26:46 -0700 (PDT) Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: from Robert Kiessling at "Aug 21, 2 00:51:14 am" Message-ID: <200208210026.g7L0QlW19203@boreas.isi.edu> % 6bone is a major source of instability for the production IPv6 network % and thus hinders deployment of IPv6. Nope. % You cannot seriously recomment anyone to trust production services to % a network in which a single faulty BGP implementation can and does % repeatedly bring down half the network (as recenty seen by AS1654). What does a faulty BGP implementation have to do with a prefix? % There's now a lot of production IPv6 connectivity available, and I'm % pretty sure that the backbone which now deploy IPv6 natively can agree % to provide sufficient IPv6 connecticity, in return for a stable % network. Please back your assertions. % Robert -- --bill From pfs@cisco.com Wed Aug 21 02:54:29 2002 From: pfs@cisco.com (Philip Smith) Date: Wed, 21 Aug 2002 11:54:29 +1000 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <1029870223.2530.133.camel@wks1.fr.corp.ndsoftware.com> References: <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> Message-ID: <5.1.0.14.2.20020821114328.03bd2cf8@localhost> At 21:03 20/08/2002 +0200, Nicolas DEFFAYET wrote: >On Tue, 2002-08-20 at 18:49, Bob Fink wrote: > > > > c) In order to receive 6bone address services from an RIR as described > > here, each 6bone member must "join" that RIR, that is, enter into the > > appropriate membership or services agreement with the RIR. > >I'm not agree with that. > >appropriate membership = LIR ? >If yes, it's very bad; a lot of pTLA aren't LIR and a LIR can request a >sTLA, why a LIR will request a 6bone address space ? This is one discussion point. Bob says "appropriate membership" - it would be useful if you'd give opinions as to what that membership might be. Would certainly help the registries and Bob. >6bone must be open, free and independent. >A pTLA request must be free and without membership. Independent of what? Why would having someone apart from Bob run the address registry suddenly make the 6bone closed, non-free, and non-independent? Even the IPv4 Internet is open, non-free and independent, so please explain the problem you see. Bob has run the registry for free for the last many years. He could have charged money for it, simply to cover the costs he has undoubtedly accrued. It's not unreasonable, is it? >6bone address services must be free. This isn't an argument. Why? >Since 1996 it's free and it's workfine ! What, the 6bone, or the 6bone registry? There is a difference. I'm only trying to encourage people to express reasons with justifications - assertions that "life must go on without any changes" aren't too useful given that Bob is proposing a change. philip -- From michel@arneill-py.sacramento.ca.us Wed Aug 21 04:28:20 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 20 Aug 2002 20:28:20 -0700 Subject: [6bone] Re: proposal for transfer of 6bone address management responsibilities to RIRs Message-ID: <2B81403386729140A3A899A8B39B046405E296@server2000> 6boners, Please keep in mind that the choice that we are facing is *not* between keeping the 6bone as-is and transferring it to RIRs. The choice we are facing is between transferring it to RIRs transferring it to v6ops. Michel. From rjorgensen@upctechnology.com Wed Aug 21 08:30:13 2002 From: rjorgensen@upctechnology.com (Roger Jorgensen) Date: Wed, 21 Aug 2002 09:30:13 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: References: Message-ID: <5.1.0.14.0.20020821092653.0466b7b8@213.46.233.213> At 08:42 PM 8/20/2002 -0300, Rik van Riel wrote: >On 21 Aug 2002, Robert Kiessling wrote: > > Rik van Riel writes: > > > > > Agreed. 6bone is essential for those areas of the internet > > > where the "normal" providers do not offer ipv6 yet. > > > > 6bone is a major source of instability for the production IPv6 network > > and thus hinders deployment of IPv6. > >[snip] > > > Well-controlled end sites and address allocation to them for > > experimental purposes is a different story, but them must be isolated > > so they cannot wreak havoc to the rest of the world. > >Agreed. We want to isolate the production and experimental >ipv6 networks somewhat, to make sure the production network >stays stable and won't be affected by instabilities in the >exerimental network. > >I just hope this will be done in a way that doesn't cut any >of the current ipv6 users from the ipv6 internet. If we can assume that 6bone will not be used for production site any provider that don't want to have a connection to 6bone can put filter on who they allow 3ffe::/16 from, possible remove them. It allow ISP's to decide if they want to provide access to 6bone or not. Of course we can't assume that all production sites only will be runned of RIR space so the solution isn't good, but it might be one way to divide 6bone a bit from the rest. But, seperation of 6bone from RIR will not garanty stability in the network, let's use the recent AS1654 episode as example again, how can we avoid that one singel AS announce all sTLA? In IPv4 you filter very strict on what you allow and what you aggregate, is this one way to go for IPv6? Or should we try to come up with another solution to avoid one singel AS to announce ALL sTLA's? (no AS should announce more than one sTLA normaly...) --- Roger Jorgensen (rjorgensen@chello.com) System Engineer @ UPC Technology / IP engineering handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID From Ronald.vanderPol@rvdp.org Wed Aug 21 08:50:48 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Wed, 21 Aug 2002 09:50:48 +0200 Subject: [6bone] pTLA request BUI - review closes 3 September 2002 In-Reply-To: <5.1.1.6.2.20020820094534.02aec490@mail.energy.local> References: <5.1.1.6.2.20020820020040.02b0cd88@mail.energy.local> <5.1.1.6.2.20020820094534.02aec490@mail.energy.local> Message-ID: <20020821075048.GB15554@rvdp.org> On Tue, Aug 20, 2002 at 10:41:52 +0200, Giacomo Cariello wrote: > I've had a talk with CEO of Data Service, our IPv4 connectivity partner and > I agreed with him to anticipate IPv6 deployment schedule for their > organization. > Data Service would be interested in requesting a pTLA status for IPv6 > deployment reasons, which would be well justified, considering they are an > ISP serving hundreds end-sites and regional organizations and offering > various types of connectivity services. You can request RIR IPv6 address just like you do for IPv4. Have Data Service ask for an IPv6 allocation from RIPE NCC. See: http://www.ripe.net/ripe/docs/ipv6-initial.html For background about the policy see: http://www.ripe.net/ripe/docs/ipv6policy.html And for general information about IPv6 see: http://www.ripe.net/ipv6/ rvdp From nicolas.deffayet@ndsoftware.net Wed Aug 21 10:32:08 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 21 Aug 2002 11:32:08 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <5.1.0.14.2.20020821114328.03bd2cf8@localhost> References: <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> <5.1.0.14.2.20020821114328.03bd2cf8@localhost> Message-ID: <1029922328.2530.241.camel@wks1.fr.corp.ndsoftware.com> On Wed, 2002-08-21 at 03:54, Philip Smith wrote: > At 21:03 20/08/2002 +0200, Nicolas DEFFAYET wrote: > >On Tue, 2002-08-20 at 18:49, Bob Fink wrote: > > > > > > c) In order to receive 6bone address services from an RIR as described > > > here, each 6bone member must "join" that RIR, that is, enter into the > > > appropriate membership or services agreement with the RIR. > > > >I'm not agree with that. > > > >appropriate membership = LIR ? > >If yes, it's very bad; a lot of pTLA aren't LIR and a LIR can request a > >sTLA, why a LIR will request a 6bone address space ? > > This is one discussion point. Bob says "appropriate membership" - it would > be useful if you'd give opinions as to what that membership might be. Would > certainly help the registries and Bob. If i must pay for get a IP address space, i will do for a sTLA, not a pTLA. > > >6bone must be open, free and independent. > >A pTLA request must be free and without membership. > > Independent of what? Why would having someone apart from Bob run the > address registry suddenly make the 6bone closed, non-free, and > non-independent? Even the IPv4 Internet is open, non-free and independent, > so please explain the problem you see. Independent of RIR. > > Bob has run the registry for free for the last many years. He could have > charged money for it, simply to cover the costs he has undoubtedly accrued. > It's not unreasonable, is it? I provide free IPv6 services to a lot of users on 6bone, if i must pay for a IP address space, i can't provide this service free. Nothing cover my cost of bandwitch and time, i do this free services for the community. 6bone must be free, if not why keep 6bone ? You want kill the 6bone ? > > >6bone address services must be free. > > This isn't an argument. Why? A lot of project/ISP don't have a budget for that. > > >Since 1996 it's free and it's workfine ! > > What, the 6bone, or the 6bone registry? There is a difference. The both (pTLA + registry). Best Regards, Nicolas DEFFAYET From pfs@cisco.com Wed Aug 21 11:44:44 2002 From: pfs@cisco.com (Philip Smith) Date: Wed, 21 Aug 2002 20:44:44 +1000 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <1029922328.2530.241.camel@wks1.fr.corp.ndsoftware.com> References: <5.1.0.14.2.20020821114328.03bd2cf8@localhost> <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> <5.1.0.14.2.20020821114328.03bd2cf8@localhost> Message-ID: <5.1.0.14.2.20020821203142.03bab210@localhost> At 11:32 21/08/2002 +0200, Nicolas DEFFAYET wrote: >If i must pay for get a IP address space, i will do for a sTLA, not a >pTLA. You have to pay to get IPv4, you have to pay for IPv6 global space. I guess there could be an option not to pay for 3ffe::/16 space. > > Independent of what? Why would having someone apart from Bob run the > > address registry suddenly make the 6bone closed, non-free, and > > non-independent? Even the IPv4 Internet is open, non-free and independent, > > so please explain the problem you see. > >Independent of RIR. Why? >I provide free IPv6 services to a lot of users on 6bone, if i must pay >for a IP address space, i can't provide this service free. >Nothing cover my cost of bandwitch and time, i do this free services for >the community. This is similar to the infancy of the IPv4 Internet. I guess one option is to simply keep the IPv6 network as a free play thing, and tell the people who want to make money out of it to carry on using IPv4? >6bone must be free, if not why keep 6bone ? >You want kill the 6bone ? I'm not clear how the proposed transition of the 6bone registry to the RIRs has any relationship with the actual test network called the 6bone. Maybe you can explain? I didn't see anything in the proposal that says "kill 6bone". >A lot of project/ISP don't have a budget for that. That's useful feedback for Bob and the RIRs, I think. > > > > >Since 1996 it's free and it's workfine ! > > > > What, the 6bone, or the 6bone registry? There is a difference. > >The both (pTLA + registry). I didn't see any mention of the pTLA being withdrawn - there are quite a few people who'd argue that it should be, but then as many argue that there is still sufficient experimental work to be done. But we are basically talking about whether potential 6bone candidates send e-mail to Bob Fink, or send e-mail to the RIRs to get their /32 from 3ffe::/16 space? Aren't we? cheers, philip -- From ashok.kum@wipro.com Wed Aug 21 13:20:50 2002 From: ashok.kum@wipro.com (Ashok Kumar) Date: Wed, 21 Aug 2002 17:50:50 +0530 Subject: [6bone] Please unsubscribe me from the list Message-ID: This is a multi-part message in MIME format. ------=_NextPartTM-000-b1614e09-b4d9-11d6-84a6-0000e2293f7c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have tried sending unsubscribe request to majordomo, but that does not work, I dont know why. Please remove my email id from the list. Thank you. BR, Ashok ------=_NextPartTM-000-b1614e09-b4d9-11d6-84a6-0000e2293f7c 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-b1614e09-b4d9-11d6-84a6-0000e2293f7c-- From riel@conectiva.com.br Wed Aug 21 14:34:21 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Wed, 21 Aug 2002 10:34:21 -0300 (BRT) Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <1029922328.2530.241.camel@wks1.fr.corp.ndsoftware.com> Message-ID: On Wed, 2002-08-21 at 03:54, Philip Smith wrote: > At 21:03 20/08/2002 +0200, Nicolas DEFFAYET wrote: > >6bone address services must be free. > > This isn't an argument. Why? Because ipv6 address space is not yet available from all ISPs, it would be very useful if groups of individuals had an alternative way of getting ipv6 connectivity, until ipv6 is so widespread that everybody can just get it from their ISP. If we want ipv6 to become widely available, I think the last thing we want to do at this point is reduce its availability. kind regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From Ronald.vanderPol@rvdp.org Wed Aug 21 14:41:25 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Wed, 21 Aug 2002 15:41:25 +0200 Subject: [6bone] separating IPv6 experimental from production traffic Message-ID: <20020821134125.GG15554@rvdp.org> As you know I am increasingly worried about the quality of IPv6 transport. I have far more problems reaching IPv6 destinations than I have reaching IPv4 destinations. This is not because I have a bad provider, but because my traffic is blackholed somewhere far away in the 'Net. It's becoming so bad that almost every week I have a major IPv6 connectivity problem which prevents me from doing my daily work. I run dual stack and my applications try IPv6 first. When IPv6 traffic is blackholed somewhere I have a problem. When I am lucky, the application times out and tries IPv4. If not, I just don't get a connection. I have to manually type in an IPv4 address. We are at a stage now that in parts of the world IPv6 is used on a daily basis. In Japan it's a commercial service for a long time now. People are paying for IPv6 transport and expect to have a good IPv6 connectivity. The current situation is that we have one network, the 6bone (although it is hard to define what it is exactly). The current 6bone is used for all kinds of experiments (even with old or alpha routing software) and is used as a playground for people new to IPv6 (no problem, it's very good, as long as it doesn't interfere with my production traffic). I think we should work towards separating experiment and playing from production. Experimenting needs to be done, but it should have minimal impact on production. This is what most :-) do in the IPv4 world. However, I do not propose to disconnect one from the other. On the contrary, there should be good connectivity between them. But I think we should stop the current situation where production traffic is routed *via* an experimental network. What I want is IPv6 transport that is treated similar to IPv4 transport. In the current situation this is hard to accomplish by individual ISPs because of the tunnels all over the world and transit to everyone. So I guess we first have to reach concensus whether we want this separation or not. BTW, in my opinion "IPv6_production == native_IPv6, per definition" is *not* true. I think you can do IPv6 production service partly with tunnels, as long as you are very, very careful about choosing the paths of the tunnels and the peerings are monitored closely. On the other hand, accidents will happen on the production IPv6 network, just as in the IPv4 network. But these should be exceptions, just as in the IPv4 world and not the daily routine from the current 6bone. At this stage I am only asking for separation of experiment from production. I am not saying anything yet about what prefixes to use where. I am also not saying yet what the experimental network (the 6bone) should be used for. I guess all I am saying is: don't use the 6bone for production traffic. In my view in the new situation a site can have two kinds of peerings: 6bone peering or production peering. What should be prevented is traffic coming from the production network, going via the experimental network to a production destination. Comments? rvdp From gert@space.net Wed Aug 21 15:25:16 2002 From: gert@space.net (Gert Doering) Date: Wed, 21 Aug 2002 16:25:16 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <1029870223.2530.133.camel@wks1.fr.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Tue, Aug 20, 2002 at 09:03:43PM +0200 References: <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> <1029870223.2530.133.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20020821162516.D27015@Space.Net> Hi, On Tue, Aug 20, 2002 at 09:03:43PM +0200, Nicolas DEFFAYET wrote: > 6bone address services must be free. > Since 1996 it's free and it's workfine ! It's free because some people donate time and effort for free. You don't have a "Right" to get that for free for ever. Get real. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45583 (46871) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pekkas@netcore.fi Wed Aug 21 16:16:09 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Wed, 21 Aug 2002 18:16:09 +0300 (EEST) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <20020821134125.GG15554@rvdp.org> Message-ID: On Wed, 21 Aug 2002, Ronald van der Pol wrote: > Comments? These have been my worries, as I've been experiencing the same problems for some time now. I've been trying to advocate two things: 1) "don't do transit" -- yeah it's cool to give transit to everyone, but you really shouldn't on your rotten Cisco 2600 or 4500 behind a 2 Mbit/s line! 2) "not everybody needs a pTLA" -- if we give pTLA to everyone that asks, the number of folks that are (practically) able to do 1) increases. Also, this will lead to people filtering whole 6bone space if we want to enforce strict aggregation. The most important thing for stability is starting to unentangle the tunnel mess, or at least preventing it from getting worse. Major _real_ transit providers or major ISP's could be in key position here (I'm not sure how much they're currently), by providing either tunneled or native v6 transits (traffic which would mostly run through their lines anyway). But it's a huge task.. -- 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 fink@es.net Wed Aug 21 16:23:27 2002 From: fink@es.net (Bob Fink) Date: Wed, 21 Aug 2002 08:23:27 -0700 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <2B81403386729140A3A899A8B39B046405E296@server2000> Message-ID: <5.1.0.14.0.20020821072701.02c32318@imap2.es.net> Michel, and all 6bone Folk, At 08:28 PM 8/20/2002 -0700, Michel Py wrote: >6boners, > >Please keep in mind that the choice that we are facing is *not* between >keeping the 6bone as-is and transferring it to RIRs. > >The choice we are facing is between transferring it to RIRs transferring >it to v6ops. Not so. Sorry I didn't clear that up earlier. I'll try to do so here. The 6bone has been under the operational and policy oversight of ngtrans since a few months after it was formed in 1996 until recently. During the last year that oversight has diminished due to pressures of the primary work of ngtrans. When the ngtrans chairs started to re-charter ngtrans, Randy Bush (the ngtrans IESG AD) made it clear that he didn't think the 6bone belonged in a new ngtrans charter. Note there was no discussion of where it might sit. Then just recently discussions started about a new v6ops working group. There was no intention to include the 6bone oversight function in its charter. Independent of 6bone operational policy oversight was the issue of the 6bone being an address registry outside of the now agreed IPv6 address management and registry that the RIRs have developed (with very wide participation from the Internet community). This causes problems for two reasons: One is that if the 6bone is allowed to be a high-level address registry not under the scrutiny and agreements of the Internet community registry processes (i.e., those of the RIRs), others can make the case that they should be as well. This will become more and more of a problem as time goes on and will likely cause the 6bone's address authority (over 3FFE://16) to be withdrawn earlier than might otherwise be appropriate. Second is that the RIRs have oversight over the ip6.arpa reverse DNS registry. As IPv6 deployment evolves it becomes increasingly more important that 6bone networks can register in the ip6.arpa path. Note that this does not mean that you can't use ip6.int, just that ip6.arpa will become prevalent in usage and the 6bone must have access to it. It seems unlikely that the 6bone will be able to use ip6.arpa without some form of agreement with the RIRs. A few other issues. In the proposal there is emphasis on keeping the cost of getting 6bone prefixes from the RIRs as low as possible. The RIRs, as I, are sensitive to the fact that many are unable to spend much (or possibly anything) to participate. I would still like to see a way that those claiming they can't afford even a nominal/low fee be able to qualify for some special aid. This had been discussed briefly but there was no resolution on how it might happen. The future of the 6bone 3FFE::/16 address block authority and its continuance will not be in RIR hands. Where it will be is not obvious yet, but I assume somewhere at the IETF policy level. This will be explored in the coming months. Where operational and policy oversight will come from is an interesting issue. Although in theory it came, for a while, from ngtrans (as mentioned above), this wasn't really true in practice. It really came from the collective 6bone community and its own consensus about what worked and what didn't. I expect this will continue. The RIRs also expect that the 6bone community will continue to make decisions about its operations and policies. On keeping the 6bone separate from the production IPv6 Internet, I believe that to be seldom if ever necessary, and that the decision to do so is a local one for any network based on what is being done. The 6bone is part of the greater IPv4 and IPv6 integrated Internet and must be for it to be of value. Just as we have poorly managed IPv4 networks that cause trouble for the greater whole, the 6bone has no monopoly on poor or perfect service among IPv6 networks. When we have problems with any IPv6 network we should all take steps to get them fixed or isolate them. This is not a 6bone-specific issue. We (me and RIRs) appreciate your comments as they do help us understand the issues. Keep them coming! Thanks, Bob From Ronald.vanderPol@rvdp.org Wed Aug 21 16:32:33 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Wed, 21 Aug 2002 17:32:33 +0200 Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: References: <20020821134125.GG15554@rvdp.org> Message-ID: <20020821153233.GA16515@rvdp.org> On Wed, Aug 21, 2002 at 18:16:09 +0300, Pekka Savola wrote: > The most important thing for stability is starting to unentangle the > tunnel mess, or at least preventing it from getting worse. Major _real_ > transit providers or major ISP's could be in key position here (I'm not > sure how much they're currently), by providing either tunneled or native > v6 transits (traffic which would mostly run through their lines anyway). > > But it's a huge task.. I agree with you that the tunnel mess (why do people have dozens of transit peerings?) and transit to everyone are the major problems. I think we have two options: 1) clean up the 6bone 2) separate experimental from production It looks like you propose 1). I propose 2), because experiment and production don't go well together. But both need the cooperation of the whole 6bone community. Let's try to reach consensus soon which way to go. rvdp From Christopher.Malayter@tdstelecom.com Wed Aug 21 16:54:55 2002 From: Christopher.Malayter@tdstelecom.com (Malayter, Christopher) Date: Wed, 21 Aug 2002 10:54:55 -0500 Subject: [6bone] proposal for transfer of 6bone address management res ponsibilities to RIRs Message-ID: <7F14AEA6809DD511BA1B00508BBE584E01800209@msg017.teldta.com> >But we are basically talking about whether potential 6bone candidates send >e-mail to Bob Fink, or send e-mail to the RIRs to get their /32 from >3ffe::/16 space? Aren't we? Is there any reason to do this? Bob has done a fantastic job for forever. Why would we want to move to a pay system from the RIR's who have no incentive to dish out 3ffe::/16 space for a possible reduced price? when they have production space. I think Bob is the way to go here. -Chris From Ronald.vanderPol@rvdp.org Wed Aug 21 17:21:08 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Wed, 21 Aug 2002 18:21:08 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <5.1.0.14.0.20020821072701.02c32318@imap2.es.net> References: <2B81403386729140A3A899A8B39B046405E296@server2000> <5.1.0.14.0.20020821072701.02c32318@imap2.es.net> Message-ID: <20020821162108.GB16515@rvdp.org> On Wed, Aug 21, 2002 at 08:23:27 -0700, Bob Fink wrote: > On keeping the 6bone separate from the production IPv6 Internet, I believe > that to be seldom if ever necessary, and that the decision to do so is a > local one for any network based on what is being done. No, it is not a local decision. That is the problem. When I choose to serarate them, I can. But my packets travel via several AS-es over production links until somewhere, far away, it's routed over an experimental service and gets blackholed. I have a problem when the policy in that place far away is: well, we are just experimenting with IPv6. This can only be solved when we all agree on a minimal quality. I think we have a very big problem. Some people say: current IPv6 transport is bad. Other people say: there is no problem. rvdp From itojun@iijlab.net Wed Aug 21 17:35:12 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Thu, 22 Aug 2002 01:35:12 +0900 Subject: [6bone] proposal for transfer of 6bone address management res ponsibilities to RIRs In-Reply-To: Christopher.Malayter's message of Wed, 21 Aug 2002 10:54:55 EST. <7F14AEA6809DD511BA1B00508BBE584E01800209@msg017.teldta.com> Message-ID: <20020821163512.1D2404B22@coconut.itojun.org> >Is there any reason to do this? Bob has done a fantastic job for forever. >Why would we want to move to a pay system from the RIR's who have no >incentive to dish out 3ffe::/16 space for a possible reduced price? when >they have production space. I think Bob is the way to go here. Bob can't serve people forever. in fact, he is a bit older than my dad (IIRC), so he should have some plans on retirement and such. i consider a system broken when everyone depends on single person. (for instance, what happens if Bob experiences a car accident?) i really hope major ISPs outside of Japan to roll out IPv6 services based on sTLA address, and remove the needs for volunteer-based 6bone. itojun From Robert.Kiessling@de.easynet.net Wed Aug 21 17:51:02 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 21 Aug 2002 17:51:02 +0100 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> References: <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> Message-ID: One point to bear in mind: RIRs (at least RIPE) will NOT be flexible. If they are told to implement 2772, they will do exactly this, and e.g. immediately reject Euro6IX's application because they have no prior 6bone experience. Robert From michel@arneill-py.sacramento.ca.us Wed Aug 21 17:44:18 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 21 Aug 2002 09:44:18 -0700 Subject: [6bone] Re: proposal for transfer of 6bone address management responsibilities to RIRs Message-ID: <2B81403386729140A3A899A8B39B046405E298@server2000> Bob, >> Michel Py wrote: >> Please keep in mind that the choice that we are facing is *not* >> between keeping the 6bone as-is and transferring it to RIRs. >> The choice we are facing is between transferring it to RIRs >> transferring it to v6ops. > Bob Fink wrote: > Not so. Sorry I didn't clear that up earlier. I'll try to > do so here. > Then just recently discussions started about a new v6ops > working group. There was no intention to include the 6bone > oversight function in its charter. My point, precisely. Assuming (reasonable likeliness) that v6ops will be created and ngtrans will indeed conclude my understanding was that the 6bone oversight will be (short-term) either: - By default transferred to v6ops, who does not care about it and could dump the 6bone concept as a whole. - Be transferred into a void. (none of which is good, IMHO) > The future of the 6bone 3FFE::/16 address block authority > and its continuance will not be in RIR hands. Where it will > be is not obvious yet, but I assume somewhere at the IETF > policy level. This will be explored in the coming months. WRT what I wrote above, I think the "where it will be" is one of the important parts that is missing as of today, IMHO. If you prefer, the lack of a "home" for the 6bone has "catastrophe" written all over it. In other words, I don't think we have much of a choice but make this transfer of address management to the RIRs work. > Where operational and policy oversight will come from is > an interesting issue. Although in theory it came, for a > while, from ngtrans (as mentioned above), this wasn't > really true in practice. I think it was true in the sense that you were co-chair of ngtrans at the time. > It really came from the collective 6bone community and its > own consensus about what worked and what didn't. I expect > this will continue. The RIRs also expect that the 6bone > community will continue to make decisions about its > operations and policies. Bob, have you thought about the 6bone being a WG of its own (possibly outside the O&M area) or something similar? There are things such as the much discussed "STRICT" prefix-list and related topics that could be done more formally. > On keeping the 6bone separate from the production IPv6 Internet, > I believe that to be seldom if ever necessary, and that the > decision to do so is a local one for any network based on what > is being done. The 6bone is part of the greater IPv4 and IPv6 > integrated Internet and must be for it to be of value. Just as > we have poorly managed IPv4 networks that cause trouble for > the greater whole, the 6bone has no monopoly on poor or perfect > service among IPv6 networks. When we have problems with any > IPv6 network we should all take steps to get them fixed or > isolate them. This is not a 6bone-specific issue. Strongly agree. Michel. From JORDI PALET MARTINEZ" Message-ID: <063b01c24933$7222fad0$8700000a@consulintel.es> I agree, Bob is doing a very good job, and we need to support him. I wish he is with us a long time, as much as possible !, but unfortunately life is as we all know ;-) Regards, Jordi PS: Itojun, he is not so older, ok ? You can't say somebody is getting older when he still has more energy than most of us ;-) ----- Original Message ----- From: To: "Malayter, Christopher" Cc: "'Philip Smith'" ; "6BONE List" <6bone@ISI.EDU>; "Bob Fink" Sent: Wednesday, August 21, 2002 6:35 PM Subject: Re: [6bone] proposal for transfer of 6bone address management res ponsibilities to RIRs > >Is there any reason to do this? Bob has done a fantastic job for forever. > >Why would we want to move to a pay system from the RIR's who have no > >incentive to dish out 3ffe::/16 space for a possible reduced price? when > >they have production space. I think Bob is the way to go here. > > Bob can't serve people forever. in fact, he is a bit older than my dad > (IIRC), so he should have some plans on retirement and such. > i consider a system broken when everyone depends on single person. > (for instance, what happens if Bob experiences a car accident?) > > i really hope major ISPs outside of Japan to roll out IPv6 services > based on sTLA address, and remove the needs for volunteer-based 6bone. > > itojun > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From wizard@italiansky.com Wed Aug 21 18:05:18 2002 From: wizard@italiansky.com (Matteo Tescione) Date: Wed, 21 Aug 2002 19:05:18 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs References: <5.1.0.14.0.20020821072701.02c32318@imap2.es.net> Message-ID: <008701c24934$ed91af30$8cf51150@local.comv6.com> Hi to all, according to me pay even a few membership to Rirs means that noone will ask for 6bone space, only for production space. Moving 6bone address under rirs means closing 6bone, I don't think ipv6 is so widely deployed yet, I'm running a TB, if I have to pay for address space I had to be paid from my customers. Definitely I don't think it's time to think closing 6bone. Best regards, Matteo Tescione Ipv6 Dept. COMV6 - Italy ----- Original Message ----- From: "Bob Fink" To: "6BONE List" <6bone@mailman.isi.edu> Sent: Wednesday, August 21, 2002 5:23 PM Subject: Re: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs > Michel, and all 6bone Folk, > > At 08:28 PM 8/20/2002 -0700, Michel Py wrote: > >6boners, > > > >Please keep in mind that the choice that we are facing is *not* between > >keeping the 6bone as-is and transferring it to RIRs. > > > >The choice we are facing is between transferring it to RIRs transferring > >it to v6ops. > > Not so. Sorry I didn't clear that up earlier. I'll try to do so here. > > The 6bone has been under the operational and policy oversight of ngtrans > since a few months after it was formed in 1996 until recently. During the > last year that oversight has diminished due to pressures of the primary > work of ngtrans. When the ngtrans chairs started to re-charter ngtrans, > Randy Bush (the ngtrans IESG AD) made it clear that he didn't think the > 6bone belonged in a new ngtrans charter. Note there was no discussion of > where it might sit. > > Then just recently discussions started about a new v6ops working group. > There was no intention to include the 6bone oversight function in its charter. > > Independent of 6bone operational policy oversight was the issue of the > 6bone being an address registry outside of the now agreed IPv6 address > management and registry that the RIRs have developed (with very wide > participation from the Internet community). This causes problems for two > reasons: > > One is that if the 6bone is allowed to be a high-level address registry not > under the scrutiny and agreements of the Internet community registry > processes (i.e., those of the RIRs), others can make the case that they > should be as well. This will become more and more of a problem as time goes > on and will likely cause the 6bone's address authority (over 3FFE://16) to > be withdrawn earlier than might otherwise be appropriate. > > Second is that the RIRs have oversight over the ip6.arpa reverse DNS > registry. As IPv6 deployment evolves it becomes increasingly more important > that 6bone networks can register in the ip6.arpa path. Note that this does > not mean that you can't use ip6.int, just that ip6.arpa will become > prevalent in usage and the 6bone must have access to it. It seems unlikely > that the 6bone will be able to use ip6.arpa without some form of agreement > with the RIRs. > > A few other issues. > > In the proposal there is emphasis on keeping the cost of getting 6bone > prefixes from the RIRs as low as possible. The RIRs, as I, are sensitive to > the fact that many are unable to spend much (or possibly anything) to > participate. I would still like to see a way that those claiming they can't > afford even a nominal/low fee be able to qualify for some special aid. This > had been discussed briefly but there was no resolution on how it might happen. > > The future of the 6bone 3FFE::/16 address block authority and its > continuance will not be in RIR hands. Where it will be is not obvious yet, > but I assume somewhere at the IETF policy level. This will be explored in > the coming months. > > Where operational and policy oversight will come from is an interesting > issue. Although in theory it came, for a while, from ngtrans (as mentioned > above), this wasn't really true in practice. It really came from the > collective 6bone community and its own consensus about what worked and what > didn't. I expect this will continue. The RIRs also expect that the 6bone > community will continue to make decisions about its operations and policies. > > On keeping the 6bone separate from the production IPv6 Internet, I believe > that to be seldom if ever necessary, and that the decision to do so is a > local one for any network based on what is being done. The 6bone is part of > the greater IPv4 and IPv6 integrated Internet and must be for it to be of > value. Just as we have poorly managed IPv4 networks that cause trouble for > the greater whole, the 6bone has no monopoly on poor or perfect service > among IPv6 networks. When we have problems with any IPv6 network we should > all take steps to get them fixed or isolate them. This is not a > 6bone-specific issue. > > > We (me and RIRs) appreciate your comments as they do help us understand the > issues. Keep them coming! > > > Thanks, > > Bob > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone From fink@es.net Wed Aug 21 18:03:23 2002 From: fink@es.net (Bob Fink) Date: Wed, 21 Aug 2002 10:03:23 -0700 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <20020821162108.GB16515@rvdp.org> References: <5.1.0.14.0.20020821072701.02c32318@imap2.es.net> <2B81403386729140A3A899A8B39B046405E296@server2000> <5.1.0.14.0.20020821072701.02c32318@imap2.es.net> Message-ID: <5.1.0.14.0.20020821095034.02bd8c50@imap2.es.net> Ronald, At 06:21 PM 8/21/2002 +0200, Ronald van der Pol wrote: >On Wed, Aug 21, 2002 at 08:23:27 -0700, Bob Fink wrote: > > > On keeping the 6bone separate from the production IPv6 Internet, I believe > > that to be seldom if ever necessary, and that the decision to do so is a > > local one for any network based on what is being done. > >No, it is not a local decision. That is the problem. When I choose to >serarate them, I can. But my packets travel via several AS-es over >production links until somewhere, far away, it's routed over an >experimental service and gets blackholed. I have a problem when >the policy in that place far away is: well, we are just experimenting >with IPv6. This can only be solved when we all agree on a minimal >quality. I don't disagree that other's casual or irresponsible behavior can hurt someone else far away, but it can only be their local decision to decide what their behavior will be. The rest of us then can decide if we like that behavior and try to filter, block, or whatever to avoid the problems caused for the rest of us. The IPv4 Internet has definitely had this problem and the collective efforts of other operators has dealt with this, as well as the market place deciding what to support or not. Unfortunately it isn't (and likely will never be) a perfect process. Many of us have had to live with very unacceptable behavior from supposedly very professionally operated large ISPs. However, I stray. Your next comment is the important one here. >I think we have a very big problem. Some people say: current IPv6 >transport is bad. Other people say: there is no problem. I agree that we need to do more to police ourselves. Myself, I've come to be in favor of revoking pTLAs from unresponsive and poorly managed pTLA holders. However, we need a good process as well as strong 6bone community support to do this. I would very much like to hear proposals, as well as newer versions of RFC2772, that address this. To state the obvious, the RIRs won't do this for us (nor should they) and if we don't do it the life of the 6bone is likely to be shortened considerably. Thanks, Bob From fink@es.net Wed Aug 21 18:05:25 2002 From: fink@es.net (Bob Fink) Date: Wed, 21 Aug 2002 10:05:25 -0700 Subject: [6bone] Re: proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <2B81403386729140A3A899A8B39B046405E298@server2000> Message-ID: <5.1.0.14.0.20020821100411.02a7cb60@imap2.es.net> Michel, At 09:44 AM 8/21/2002 -0700, Michel Py wrote: >Bob, > > >> Michel Py wrote: > >> Please keep in mind that the choice that we are facing is *not* > >> between keeping the 6bone as-is and transferring it to RIRs. > >> The choice we are facing is between transferring it to RIRs > >> transferring it to v6ops. > > > Bob Fink wrote: > > Not so. Sorry I didn't clear that up earlier. I'll try to > > do so here. > > > Then just recently discussions started about a new v6ops > > working group. There was no intention to include the 6bone > > oversight function in its charter. > >My point, precisely. > >Assuming (reasonable likeliness) that v6ops will be created and ngtrans >will indeed conclude my understanding was that the 6bone oversight will >be (short-term) either: >- By default transferred to v6ops, who does not care about it and could >dump the 6bone concept as a whole. >- Be transferred into a void. >(none of which is good, IMHO) > > > The future of the 6bone 3FFE::/16 address block authority > > and its continuance will not be in RIR hands. Where it will > > be is not obvious yet, but I assume somewhere at the IETF > > policy level. This will be explored in the coming months. > >WRT what I wrote above, I think the "where it will be" is one of the >important parts that is missing as of today, IMHO. If you prefer, the >lack of a "home" for the 6bone has "catastrophe" written all over it. > >In other words, I don't think we have much of a choice but make this >transfer of address management to the RIRs work. > > > Where operational and policy oversight will come from is > > an interesting issue. Although in theory it came, for a > > while, from ngtrans (as mentioned above), this wasn't > > really true in practice. > >I think it was true in the sense that you were co-chair of ngtrans at >the time. > > > It really came from the collective 6bone community and its > > own consensus about what worked and what didn't. I expect > > this will continue. The RIRs also expect that the 6bone > > community will continue to make decisions about its > > operations and policies. > >Bob, have you thought about the 6bone being a WG of its own (possibly >outside the O&M area) or something similar? There are things such as the >much discussed "STRICT" prefix-list and related topics that could be >done more formally. When I tried to do this in '96 it was placed into ngtrans by the then responsible ADs. I'm not sure what is really acceptable now, but intend to pursue it. Thanks, Bob > > On keeping the 6bone separate from the production IPv6 Internet, > > I believe that to be seldom if ever necessary, and that the > > decision to do so is a local one for any network based on what > > is being done. The 6bone is part of the greater IPv4 and IPv6 > > integrated Internet and must be for it to be of value. Just as > > we have poorly managed IPv4 networks that cause trouble for > > the greater whole, the 6bone has no monopoly on poor or perfect > > service among IPv6 networks. When we have problems with any > > IPv6 network we should all take steps to get them fixed or > > isolate them. This is not a 6bone-specific issue. > >Strongly agree. > >Michel. From bmanning@ISI.EDU Wed Aug 21 18:29:15 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 21 Aug 2002 10:29:15 -0700 (PDT) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <20020821134125.GG15554@rvdp.org> from Ronald van der Pol at "Aug 21, 2 03:41:25 pm" Message-ID: <200208211729.g7LHTFe27289@boreas.isi.edu> % At this stage I am only asking for separation of experiment from % production. I am not saying anything yet about what prefixes to % use where. I am also not saying yet what the experimental network % (the 6bone) should be used for. I guess all I am saying is: don't % use the 6bone for production traffic. In my view in the new situation % a site can have two kinds of peerings: 6bone peering or production % peering. What should be prevented is traffic coming from the % production network, going via the experimental network to a production % destination. % % Comments? % % rvdp % _______________________________________________ Tell me how you propose to do this? If we want things to work, we need to use them. For myself, I find that the term "production" is vague at best. I don't think we (as users of v6 protocols) can dictate such a change. A majority of my v6 peering/transit providers are -UNWILLING- to run infrastructure in dual-stack mode due to code/feature stability. So there is a v4 suite of routers and a separate v6 suite of routers. Until vendor code is -MUCH- more stable and the features are integrated, we will have this appearence of a "production" v4 network and an "experiemental" v6 network, at least as seen by a significant portion of the IP community (save JP). If we don't use(and fix) what we create, it will never be used. -- --bill From chuck+6bone@snew.com Wed Aug 21 18:36:04 2002 From: chuck+6bone@snew.com (Chuck Yerkes) Date: Wed, 21 Aug 2002 10:36:04 -0700 Subject: [6bone] 6bone transition Message-ID: <20020821103604.A30808@snew.com> I'm catching up on mail and all of this thread. I'm also seeing some terms being tossed around perhaps incorrectly. I want to make some definitions and then draw the differences if it's not clear. 6bone: An experimental backbone made up of tunnels through IPv4 space, direct connects and held together with chewing gum in some places. Its purpose is to allow early adopters a place to PLAY with and experiment with IPv6 protocols and programs. IPv6 backbone: A set of networks running IPv6 (at least on the part exposed to the "backbone" that must be of production quality. Like the IPv4 network and VPNs, there may be tunnels from one part to another across either IPv4 or IPv6. There may be more than one, but address really should never clash. For example, my office might have a production IPv6 network; it MIGHT have a connection to the experimental 6bone; strong filtering MUST be in place to protect the production side from flakiness of the 6bone. To me, the term "production 6bone" is contradictory. The goal of the 6bone (indicated by 3FFE) is that it is experimental by nature. If BGP erros bring everything to a stop, that's a risk of being on the playground. If you lose production quality services, then that was YOUR mistake. My use of IPv6 is entirely non-production for learning and "getting familiar" with the tools and protocols. With OS X10.2's release, I'll be able to drop IPv4 entirely (except for a printer and an Annex ;), but that's the insane home LAN. Not production. My expectations that my tunnel be up 24x7 are far lower than my (shattered) expectations that my PBI DSL always be there. Routes to sites 500 miles away are insane on the 6bone. I do understand that, after 6 years and some solid implementations in OS's by default, we're ready to start rolling out some production services. Many of us have been working with the protocols for years. Many of us can recognize the value it can present on production networks. We're just about at the point where we could start to have segments with no IPv4 at all - and that can just spread virally from segment to segment until IPv4 is remaining for some older things and tunnelled through an IPv6 backbone. I'd LOVE IT if some of the larger ISPs and backbones started to feel that IPv6 was a good core transit mechanism - even if that IPv6 part never reached the edges where the customers join (see also OSPF use in the mid 90s). The only way that can happen is to prepare the infrastructures necessary to start allocating non-6bone addresses, to set up production peering resources, etc. While Bob's time and efforts have been invaluable to making this experiment work and give useful information, perhaps we might ponder giving him a rest. I won't go wit the car accident. I will wonder what happens when he wins the lottery and flys off with several supermodel/masseuses/chefs, never to be seen again. I also don't want to see the inevitable legal wrangling that might take place with peering fall on one person's head. (reference please Alternet's $10,000 peering fees of 1995). The nightmare scenario, of course, is something like [i think] ICANN. By the time this is all worked out, other IPv6 missing bits may be fixed (widely available NFSv6 jumps to mind). So I view this proposal as groundwork. Starting to clear the lot to build new production networks that are separate from the playgrounds that we've been using. Not a replacement, but an enhancement. okay, cost: Costs will stop a lot of this from happening well. On one hand, my site with 350 machines doesn't need and shouldn't get a /80. We have one connection to the (IPv4) network. Our collective experience is that changing prefixes is fairly painless (change the advertised prefix, change DNS, rebind the machines). Certainly easier to manage than changing IPv4 addresses was in 1992. I learned to love bootp really well back then. On the other hand, my previous site came THIS close to getting a Class A, with help from Dr Cerf and nixing from Dr Postel. We did a lot of work due to not having that. What factors let these folks get a larger network space? Does someone take address space away from Worldcom when they are reduced to having 4 POPs and 2 DNS servers? Or does their pTLA have a commodity value (as the Class B does from a very previous employer - now with 15 employees). Whose commodity is it and how might it be taken away from someone? When the king of Europe is deposed and he absconds with 4FFE, by what means can that be denied him? But we've seen bumps here of providers disappearing, or tunnel brokers being eaten by big companies (HP ate Compaq ate DEC). And if one of the RIR's goes all NSI on us and gets greedy is there recourse? Is there an overlord who is no ICANN that can yank their chain back? Once the masses show up, greed and self-destruction are soon to follow. We've seen peering problems in the last couple months that bring into question peer based addresses. Even continent based addressing is questionable. Our asian offices are mostly attached via VPN (or PN) to our US offices. So our US IPv6 address might appear in the middle of Japan or Hong Kong. Should we have separate networks (prefixes) for each office? Or am I entirely overinflating the significance of this turning point? chuck From RJorgensen@upctechnology.com Wed Aug 21 18:33:08 2002 From: RJorgensen@upctechnology.com (Jorgensen, Roger) Date: Wed, 21 Aug 2002 19:33:08 +0200 Subject: [6bone] proposal for transfer of 6bone address management res ponsibilities to RIRs Message-ID: <7CEA40C0E10C7D4FBE076AE7C3EFB78D88F28C@nlcbbms03> Think Euro6IX's application would come under section 3.2.b) where it says that special application will there be made exceptions from. Correct me if I'm wrong, but that's how I understand that paragraph. But, will it be the RIR alone that make the decision on who should get addresses or is it the 6bone comunity (like today where it has a review periode before it's decided)? Or a joint effort from both? --- Roger Jorgensen (rjorgensen@upctechnology.com) System Engineer @ engineering - UPC Technology handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID > -----Original Message----- > From: Robert Kiessling [mailto:Robert.Kiessling@de.easynet.net] > Sent: Wednesday, August 21, 2002 6:51 PM > To: Bob Fink > Cc: 6BONE List > Subject: Re: [6bone] proposal for transfer of 6bone address management > responsibilities to RIRs > > > One point to bear in mind: RIRs (at least RIPE) will NOT be > flexible. If they are told to implement 2772, they will do exactly > this, and e.g. immediately reject Euro6IX's application because they > have no prior 6bone experience. > > Robert > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From JORDI PALET MARTINEZ" Message-ID: <002301c2493d$51b19360$8700000a@consulintel.es> Well, isn't true the lack of experience. If you see the list of participants on the project (http://www.euro6ix.org/ingles/partners/partners.php), almost all of them have a LOT of 6Bone and IPv6 experience. From 17 partners, if I'm not wrong, 16 are connected to the 6Bone (1 of the partners is a lawyer firm investigating IPv6 and privacy concerns). Euro6IX, as a project, has no legal entity, and obviously, as such, "no experience" at all in anything ;-) Regards, Jordi ----- Original Message ----- From: "Jorgensen, Roger" To: "'Robert Kiessling'" ; "Bob Fink" Cc: "6BONE List" <6bone@mailman.isi.edu> Sent: Wednesday, August 21, 2002 7:33 PM Subject: RE: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs > Think Euro6IX's application would come under section 3.2.b) where it > says that special application will there be made exceptions from. > Correct me if I'm wrong, but that's how I understand that paragraph. > > > But, will it be the RIR alone that make the decision on who should get > addresses or is it the 6bone comunity (like today where it has a review > periode before it's decided)? Or a joint effort from both? > > > > --- > Roger Jorgensen (rjorgensen@upctechnology.com) > System Engineer @ engineering - UPC Technology > handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID > > > > -----Original Message----- > > From: Robert Kiessling [mailto:Robert.Kiessling@de.easynet.net] > > Sent: Wednesday, August 21, 2002 6:51 PM > > To: Bob Fink > > Cc: 6BONE List > > Subject: Re: [6bone] proposal for transfer of 6bone address management > > responsibilities to RIRs > > > > > > One point to bear in mind: RIRs (at least RIPE) will NOT be > > flexible. If they are told to implement 2772, they will do exactly > > this, and e.g. immediately reject Euro6IX's application because they > > have no prior 6bone experience. > > > > 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 > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From Ronald.vanderPol@rvdp.org Wed Aug 21 19:02:57 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Wed, 21 Aug 2002 20:02:57 +0200 Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <200208211729.g7LHTFe27289@boreas.isi.edu> References: <20020821134125.GG15554@rvdp.org> <200208211729.g7LHTFe27289@boreas.isi.edu> Message-ID: <20020821180257.GA16927@rvdp.org> On Wed, Aug 21, 2002 at 10:29:15 -0700, Bill Manning wrote: > Tell me how you propose to do this? I think we first have to decide what to do: cleanup or separation. > If we want things to work, we need to use them. Most of my traffic goes over v6. > For myself, I find that the term "production" > is vague at best. I don't think we (as users > of v6 protocols) can dictate such a change. > A majority of my v6 peering/transit providers > are -UNWILLING- to run infrastructure in dual-stack > mode due to code/feature stability. Why should they? If I understand correctly, IIJ is offering commercial IPv6 service over a separate infrastructure. I agree "production" is vague. For me it means something like: recent software, no dozens of tunnels all over the world, no transit by small sites/ISPs, about the same number of transit upstreams as you have for v4, monitoring and management similar to v4. > So there is > a v4 suite of routers and a separate v6 suite of > routers. Until vendor code is -MUCH- more stable > and the features are integrated, we will have > this appearence of a "production" v4 network and > an "experiemental" v6 network, at least as seen > by a significant portion of the IP community (save JP). At my previous job at SURFnet in the Netherlands we build a 10 Gbps dual stack network with GSR routers. As of October last year it's used daily by the Dutch research and university community. Although most traffic is v4, the network supports both v4 and v6. Both v4 and v6 are "production". > If we don't use(and fix) what we create, it will never > be used. More and more OSes run IPv6 out of the box. End users start using IPv6 and notice problems because there are too many routing problems on the 6bone. So they switch off IPv6 again. We are scaring people away from IPv6 because of the tunnel mess, old router software and sites that don't monitor the transit they are giving to everyone. rvdp From bmanning@ISI.EDU Wed Aug 21 19:21:49 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 21 Aug 2002 11:21:49 -0700 (PDT) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <20020821180257.GA16927@rvdp.org> from Ronald van der Pol at "Aug 21, 2 08:02:57 pm" Message-ID: <200208211821.g7LILnB29241@boreas.isi.edu> % > If we want things to work, we need to use them. % Most of my traffic goes over v6. Hence you (and I) feel the pain of a system that works in a less robust mannor than the one we "left". % > For myself, I find that the term "production" % > is vague at best. I don't think we (as users % > of v6 protocols) can dictate such a change. % > A majority of my v6 peering/transit providers % > are -UNWILLING- to run infrastructure in dual-stack % > mode due to code/feature stability. % % Why should they? If I understand correctly, IIJ is offering % commercial IPv6 service over a separate infrastructure. Not everyone can afford to pay IIJ rates. IIJ services are not available in my area. One of the promises of v6 was that -AS A TRANSITION- folks could run dual stack. Not to pick, but the router vendors I've looked at do not have similar code quality or feature sets between v4 and v6. I'm doing my part to leverage vendors to syncronize the feature sets and merge v4/v6 support. % I agree "production" is vague. For me it means something like: % recent software, no dozens of tunnels all over the world, no % transit by small sites/ISPs, about the same number of transit % upstreams as you have for v4, monitoring and management % similar to v4. means different things to different people. so does "experimental" % At my previous job at SURFnet in the Netherlands we build a 10 Gbps % dual stack network with GSR routers. As of October last year it's % used daily by the Dutch research and university community. Although % most traffic is v4, the network supports both v4 and v6. Both v4 % and v6 are "production". Ok, JP and SURFnet. And now the I2 network. Waiting on (telco/ISPs) in the US to join the party. As for me, I've been running dual-stack GSR code for about the same period of time. Don't use alot of the nifty bells/whistles since I'm a low-frills, bit-pipe only kind of shop. I don't have to deal w/ accounting, VPNs, QoS, RED... ad.nausa. that commercial providers do. R&E use is distinctly different than commercial providers. They need to be able tosupport AUP/SLA crap that we don't. % > If we don't use(and fix) what we create, it will never % > be used. % % More and more OSes run IPv6 out of the box. End users start using % IPv6 and notice problems because there are too many routing problems % on the 6bone. So they switch off IPv6 again. We are scaring people % away from IPv6 because of the tunnel mess, old router software % and sites that don't monitor the transit they are giving to everyone. Same was true with inital IPv4 deployment. % % rvdp % -- --bill From michel@arneill-py.sacramento.ca.us Wed Aug 21 19:38:58 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 21 Aug 2002 11:38:58 -0700 Subject: [6bone] Re: proposal for transfer of 6bone address management responsibilities to RIRs Message-ID: <2B81403386729140A3A899A8B39B046405E299@server2000> Bob, >> Michel Py wrote: >> Bob, have you thought about the 6bone being a WG of its own >> (possibly outside the O&M area) or something similar? There >> are things such as the much discussed "STRICT" prefix-list >> and related topics that could be done more formally. > When I tried to do this in '96 it was placed into ngtrans by > the then responsible ADs. I'm not sure what is really > acceptable now, but intend to pursue it. I looks fair to me that that someone (possibly the IESG) addresses this situation; I was reading a minute ago the proposed agenda for the interim v6ops meeting and there is no mention of the 6bone. The conclusion of ngtrans (for reasons unrelated to the 6bone) does create a situation that the 6bone community has not initiated. I hope this is not boring but the reason I am commenting on the oversight issue is more a "devil's advocate" thing: If I was a RIR, I would certainly like to know clearly who oversees this /16 block that I am supposed to manage. RIRs generally don't like voids. Michel. From Ronald.vanderPol@rvdp.org Wed Aug 21 20:07:12 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Wed, 21 Aug 2002 21:07:12 +0200 Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <200208211821.g7LILnB29241@boreas.isi.edu> References: <20020821180257.GA16927@rvdp.org> <200208211821.g7LILnB29241@boreas.isi.edu> Message-ID: <20020821190712.GB16927@rvdp.org> On Wed, Aug 21, 2002 at 11:21:49 -0700, Bill Manning wrote: > only kind of shop. I don't have to deal w/ accounting, > VPNs, QoS, RED... ad.nausa. that commercial providers > do. R&E use is distinctly different than commercial > providers. They need to be able tosupport AUP/SLA > crap that we don't. The SURFnet network does have SLAs with its customers. Maybe the difference is that it was designed with KISS as an important design principle. Telcos seem to think that it all should be as complex as possible. We did have problems with the combination of several features. So we looked at which features could be scrapped and done simpler. > Same was true with inital IPv4 deployment. Are you saying it's no problem to make the same mistake twice :-) rvdp From bmanning@ISI.EDU Wed Aug 21 21:22:01 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 21 Aug 2002 13:22:01 -0700 (PDT) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <20020821190712.GB16927@rvdp.org> from Ronald van der Pol at "Aug 21, 2 09:07:12 pm" Message-ID: <200208212022.g7LKM1F14927@boreas.isi.edu> % > Same was true with inital IPv4 deployment. % % Are you saying it's no problem to make the same mistake twice :-) % % rvdp I'm saying that its an endemic problem with early adopters. It does not matter what technology you look at. -- --bill From riel@conectiva.com.br Wed Aug 21 21:52:25 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Wed, 21 Aug 2002 17:52:25 -0300 (BRT) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <20020821180257.GA16927@rvdp.org> Message-ID: On Wed, 21 Aug 2002, Ronald van der Pol wrote: > On Wed, Aug 21, 2002 at 10:29:15 -0700, Bill Manning wrote: > > > Tell me how you propose to do this? > > I think we first have to decide what to do: cleanup or separation. This shouldn't be too hard, actually. The main (only) complaint I've seen is bad routing over the experimental network, to be more precise, bad routing of _production_ packets over the 6bone. Here is my naive proposal: 1) everybody can still have ipv6-over-ipv4 tunnels like today 2) peers notify each other whether their network is production or experimental 3) experimental (3ffe::/16) pTLAs announce only 3ffe:: prefixes to their production (2001::/16) peers 4) experimental pTLAs announce all prefixes to their 3ffe::/16 peers 5) production networks announce all prefixes to everybody This means that packets from one production network to another production network will only get routed over production networks and NOT over potentially unstable experimental networks. It also means that the production and experimental parts of the ipv6 space still have full connectivity to each other, ie the reachability of either 3ffe::/16 or 2001::/16 space hasn't gotten any worse. The only change is that traffic between production networks is travelling through production networks only and doesn't depend on possible failures in the experimental network. This also gives an incentive for ISPs to migrate from experimental to production prefixes, since that will potentially give them better ipv6 connectivity. Any flaw in my reasoning ? Would this idea be non-intrusive enough that it can be implemented by the roughly 300 pTLAs and sTLAs out there today ? kind regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From jeffb@netc.com Wed Aug 21 22:57:40 2002 From: jeffb@netc.com (Jeff Barrow) Date: Wed, 21 Aug 2002 16:57:40 -0500 (CDT) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: Message-ID: > This shouldn't be too hard, actually. The main (only) complaint > I've seen is bad routing over the experimental network, to be > more precise, bad routing of _production_ packets over the 6bone. > > Here is my naive proposal: Here's my even more naive proposal.... > 1) everybody can still have ipv6-over-ipv4 tunnels like today > 2) peers notify each other whether their network is production > or experimental > 3) experimental (3ffe::/16) pTLAs announce only 3ffe:: prefixes > to their production (2001::/16) peers > > 4) experimental pTLAs announce all prefixes to their 3ffe::/16 > peers Even better, change 3) and 4) to: 3) experimental pTLAs announce whatever they want to, but the production peers all filter out incoming 2001::/16 prefixes from them. This way, even if an experimental pTLA messes up and starts announcing all prefixes with their own ASN, or gets hit by that dreaded withdrawal bug, the 2001::/16 network will still be operational to itself--just the 3ffe://16 prefix may be bad. Production pTLAs announce all prefixes to everyone, and listen from other production pTLAs without the 2001::/16 filter. This will, of course, require all production networks to be interconnected by way of production networks only. However, this method should be much easier to accomplish, as only production pTLAs need to make configuration changes to set this in place by adding a simple filter, instead of relying on the experimental pTLAs to filter outgoing announcements (and trying to contact them all); we just have to deal with the production-level pTLAs. > 5) production networks announce all prefixes to everybody From nicolas.deffayet@ndsoftware.net Wed Aug 21 23:06:55 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 22 Aug 2002 00:06:55 +0200 Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: References: Message-ID: <1029967615.25444.187.camel@wks1.fr.corp.ndsoftware.com> On Wed, 2002-08-21 at 22:52, Rik van Riel wrote: > On Wed, 21 Aug 2002, Ronald van der Pol wrote: > > On Wed, Aug 21, 2002 at 10:29:15 -0700, Bill Manning wrote: > > > > > Tell me how you propose to do this? > > > > I think we first have to decide what to do: cleanup or separation. > > This shouldn't be too hard, actually. The main (only) complaint > I've seen is bad routing over the experimental network, to be > more precise, bad routing of _production_ packets over the 6bone. > > Here is my naive proposal: > > 1) everybody can still have ipv6-over-ipv4 tunnels like today > > 2) peers notify each other whether their network is production > or experimental > > 3) experimental (3ffe::/16) pTLAs announce only 3ffe:: prefixes > to their production (2001::/16) peers > > 4) experimental pTLAs announce all prefixes to their 3ffe::/16 > peers > > 5) production networks announce all prefixes to everybody I add: 6) Don't provide by default full transit to peers, provide full transit only if peer request it. It will be very difficult to apply a policy on 6bone without a big clean. > > This means that packets from one production network to another > production network will only get routed over production networks > and NOT over potentially unstable experimental networks. > > It also means that the production and experimental parts of the > ipv6 space still have full connectivity to each other, ie the > reachability of either 3ffe::/16 or 2001::/16 space hasn't > gotten any worse. > > The only change is that traffic between production networks is > travelling through production networks only and doesn't depend > on possible failures in the experimental network. > > This also gives an incentive for ISPs to migrate from experimental > to production prefixes, since that will potentially give them better > ipv6 connectivity. > > Any flaw in my reasoning ? > I think that it's the best way. Best Regards, Nicolas DEFFAYET From riel@conectiva.com.br Wed Aug 21 23:06:26 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Wed, 21 Aug 2002 19:06:26 -0300 (BRT) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: Message-ID: On Wed, 21 Aug 2002, Jeff Barrow wrote: > Even better, change 3) and 4) to: > > 3) experimental pTLAs announce whatever they want to, but the production > peers all filter out incoming 2001::/16 prefixes from them. This way, > even if an experimental pTLA messes up and starts announcing all prefixes > with their own ASN, or gets hit by that dreaded withdrawal bug, the > 2001::/16 network will still be operational to itself--just the 3ffe://16 > prefix may be bad. > > Production pTLAs announce all prefixes to everyone, and listen from > other production pTLAs without the 2001::/16 filter. > > This will, of course, require all production networks to be interconnected > by way of production networks only. However, this method should be much > easier to accomplish, as only production pTLAs need to make configuration > changes to set this in place by adding a simple filter, instead of relying > on the experimental pTLAs to filter outgoing announcements (and trying to > contact them all); we just have to deal with the production-level pTLAs. This sounds like a _much_ better idea, since the ones having to implement this idea (the production sTLAs) are the exact same ones who will benefit from it. A proposal like this barely needs peer pressure, pure self interest is enough to get this thing implemented by everybody. kind regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From riel@conectiva.com.br Wed Aug 21 23:13:38 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Wed, 21 Aug 2002 19:13:38 -0300 (BRT) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <1029967615.25444.187.camel@wks1.fr.corp.ndsoftware.com> Message-ID: On 22 Aug 2002, Nicolas DEFFAYET wrote: > I add: > > 6) Don't provide by default full transit to peers, provide full > transit only if peer request it. This is a good idea, but I doubt it can be achieved in one step. I think it would be a good next step to take after the production sites have implemented Jeff Barrow's better version of my idea. I'm not sure whether the experimental 6bone sites need to participate in such schemes, however. On one hand pure self interest makes me want to have better routing too, but on the other hand I think it would be useful to give people an extra reason to migrate to production prefixes ;) regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ From Ronald.vanderPol@rvdp.org Wed Aug 21 23:47:14 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Thu, 22 Aug 2002 00:47:14 +0200 Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: References: <20020821180257.GA16927@rvdp.org> Message-ID: <20020821224714.GE16927@rvdp.org> On Wed, Aug 21, 2002 at 17:52:25 -0300, Rik van Riel wrote: > 2) peers notify each other whether their network is production > or experimental I think I agree with Bill that production and experimental means different things to different people. But this is a key question. We want to get rid of the many routing problems. For this, I think we have to look at transit providers only. So I guess we as the 6bone community have to come up with a list of *minimal* requirements for 6bone transit sites. Let me kickoff: - respond to problems within 18 hours (24 hours? how about weekend?) - peerings with topologically close neighbours (transit or peer sites) only - actively cleanup current peering mess - apply stringent prefix/AS filtering on peerings maybe: - active monitoring of peerings? rvdp From Robert.Kiessling@de.easynet.net Thu Aug 22 00:43:44 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 22 Aug 2002 00:43:44 +0100 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <200208210026.g7L0QlW19203@boreas.isi.edu> References: <200208210026.g7L0QlW19203@boreas.isi.edu> Message-ID: Bill Manning writes: > % You cannot seriously recomment anyone to trust production services to > % a network in which a single faulty BGP implementation can and does > % repeatedly bring down half the network (as recenty seen by AS1654). > > What does a faulty BGP implementation have to do with > a prefix? As you perfectly know, 6bone is more than address allocation. It also describes the network of 6bone sites connected by tunnels, with the general philosophy of generously allowing tunnels between any two 6bone sites, and exchanging full routing tables. It's symptomatic that the 6bone whois does not even have a syntax to describe native connections. In the resulting BGP topology such errors as mentioned have a rather long lasting and global effect. We were lucky enough that AS1654's IPv4 upstream had a 24h NOC and reacted quick to turn them off, but you cannot take that for granted. Or take the ghost routes as an example. It's extremely hard to debug this problem and isolate its root cause, due to the high ratio of interconnections, and I believe (without being able to prove it) this highly amplifies the problem. You could argue that this could also happen without 6bone, i.e. with sites having RIR allocations. However, we don't see this today, and it's unlikely that those operators will show the same attitude. The only way I see to permanently solve these problems is to have a core of responsible and responsive operators with sensible network interconnections, and apply route filters to other parties connecting to this core. > % There's now a lot of production IPv6 connectivity available, and I'm > % pretty sure that the backbone which now deploy IPv6 natively can agree > % to provide sufficient IPv6 connecticity, in return for a stable > % network. > > Please back your assertions. Please ask for specific connectivity requirement that you think cannot be provided without 6bone in its current form. What is your proposal how we can move to a stable network without the above mentioned problems? Robert From Robert.Kiessling@de.easynet.net Thu Aug 22 00:44:38 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 22 Aug 2002 00:44:38 +0100 Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <200208211821.g7LILnB29241@boreas.isi.edu> References: <200208211821.g7LILnB29241@boreas.isi.edu> Message-ID: Bill Manning writes: > One of the promises of v6 was that -AS A TRANSITION- > folks could run dual stack. Not to pick, but > the router vendors I've looked at do not have > similar code quality or feature sets between v4 and v6. Juniper does have very high code quality for IPv6. In fact we haven't experienced any operational problem with running it in parallel to IPv4, in contrast to The Router Vendor on dedicated routers. > Ok, JP and SURFnet. And now the I2 network. Waiting > on (telco/ISPs) in the US to join the party. Non-availability of high-quality IPv6 connectivity in US is not a good reason to mess up European and Asian progress in this area. > % More and more OSes run IPv6 out of the box. End users start using > % IPv6 and notice problems because there are too many routing problems > % on the 6bone. So they switch off IPv6 again. We are scaring people > % away from IPv6 because of the tunnel mess, old router software > % and sites that don't monitor the transit they are giving to everyone. > > Same was true with inital IPv4 deployment. You are really implying that today's user community has similar requirements to that at those times? Today you cannot tell the users "use IPv6, and by the way, don't worry if you don't have connectivity, it will propably come back in a couple of days". Robert From fink@es.net Thu Aug 22 03:21:39 2002 From: fink@es.net (Bob Fink) Date: Wed, 21 Aug 2002 19:21:39 -0700 Subject: [6bone] proposal for transfer of 6bone address management res ponsibilities to RIRs In-Reply-To: <7CEA40C0E10C7D4FBE076AE7C3EFB78D88F28C@nlcbbms03> Message-ID: <5.1.0.14.0.20020821192048.024e8fe0@imap2.es.net> Roger, At 07:33 PM 8/21/2002 +0200, Jorgensen, Roger wrote: >Think Euro6IX's application would come under section 3.2.b) where it >says that special application will there be made exceptions from. >Correct me if I'm wrong, but that's how I understand that paragraph. > > >But, will it be the RIR alone that make the decision on who should get >addresses or is it the 6bone comunity (like today where it has a review >periode before it's decided)? Or a joint effort from both? I believe the RIRs want the 6bone community to make those decisions, with possible input from them. Bob From fink@es.net Thu Aug 22 03:22:47 2002 From: fink@es.net (Bob Fink) Date: Wed, 21 Aug 2002 19:22:47 -0700 Subject: [6bone] Re: proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <2B81403386729140A3A899A8B39B046405E299@server2000> Message-ID: <5.1.0.14.0.20020821192145.02c65e80@imap2.es.net> Michel, At 11:38 AM 8/21/2002 -0700, Michel Py wrote: >Bob, > > >> Michel Py wrote: > >> Bob, have you thought about the 6bone being a WG of its own > >> (possibly outside the O&M area) or something similar? There > >> are things such as the much discussed "STRICT" prefix-list > >> and related topics that could be done more formally. > > > When I tried to do this in '96 it was placed into ngtrans by > > the then responsible ADs. I'm not sure what is really > > acceptable now, but intend to pursue it. > >I looks fair to me that that someone (possibly the IESG) addresses this >situation; I was reading a minute ago the proposed agenda for the >interim v6ops meeting and there is no mention of the 6bone. The >conclusion of ngtrans (for reasons unrelated to the 6bone) does create a >situation that the 6bone community has not initiated. > >I hope this is not boring but the reason I am commenting on the >oversight issue is more a "devil's advocate" thing: If I was a RIR, I >would certainly like to know clearly who oversees this /16 block that I >am supposed to manage. RIRs generally don't like voids. I believe that the RIRs think the IETF is responsible for the 3FFE block. Bob From bmanning@ISI.EDU Thu Aug 22 03:56:22 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 21 Aug 2002 19:56:22 -0700 (PDT) Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: from Robert Kiessling at "Aug 22, 2 00:43:44 am" Message-ID: <200208220256.g7M2uMw29411@boreas.isi.edu> % > What does a faulty BGP implementation have to do with % > a prefix? % % As you perfectly know, 6bone is more than address allocation. It also % describes the network of 6bone sites connected by tunnels, with the % general philosophy of generously allowing tunnels between any two % 6bone sites, and exchanging full routing tables. It's symptomatic that % the 6bone whois does not even have a syntax to describe native % connections. Whois is never authoritative. Remove 3ffe:: and we still have a "network of (ipv6) sites connected by tunnels". your assertion of the "general philsophy" does not seem to hold. % You could argue that this could also happen without 6bone, i.e. with % sites having RIR allocations. However, we don't see this today, and % it's unlikely that those operators will show the same attitude. Hogwash. Route Churn is a serious problem in the v4 world and is/will be in the v6 world, regardless of prefix. % The only way I see to permanently solve these problems is to have a % core of responsible and responsive operators with sensible network % interconnections, and apply route filters to other parties connecting % to this core. That will only "work" if you reduce the network to a single operator with zero interconnections and then you only eliminate the BGP problems. IGPs have their own issues w/ convergence. Your "solution" is a red herring. % > Please back your assertions. % % Please ask for specific connectivity requirement that you think cannot % be provided without 6bone in its current form. I would like to get native IPv6 service from 30% of the existing ISPs that have Los Angeles in their coverage footprint. Thats been a standing offer for two years. Have had two takers, one backhauling from Japan. Not what most would call production quality transit service. :) W/O 6bone (tunnels) there would be no viable v6 service in my region. (this has been true since we started working w/ IPv6, with the 5f:: prefix, predating 6bone (3ffe::), since IPv6 capability was possible. % What is your proposal how we can move to a stable network without the % above mentioned problems? Fundamentally its a social/cash issue. Persuading ISPs that v6 is required and backing those assertions with cash will allow ISPs to presure vendors to integrate v6 into mainstream support. Now, with many ISPs "supporting" v6 on independent hardware which increases their OPEX, most can do this with "spare" hardware but are unable/unwilling to pay for the cost of independent v6 native circuits. So we end up with distinct v4 and v6 hardware and the v6 is tunneled through the v4 circuits to other v6 endpoints. And with the v6 stuff on non-production hardware, it gets much less visability than the v4 stuff, on which their cash flow depends. That said, perhaps the best way forward is to revise RFC 2770 (or what ever Robs document is) to describe what the existing community thinks is currently the set of practices which promotes stable routing in the v6 world, regardless of prefix. % % Robert % -- --bill From michel@arneill-py.sacramento.ca.us Thu Aug 22 03:57:06 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 21 Aug 2002 19:57:06 -0700 Subject: [6bone] RE: proposal for transfer of 6bone address management responsibilities to RIRs Message-ID: <2B81403386729140A3A899A8B39B046405E29B@server2000> Bob, > I believe that the RIRs think the IETF is responsible > for the 3FFE block. This is the way I read it too, the IETF responsible for the block and RIRs managing it. The point I was trying to make is that "the IETF" is awfully vague, especially if it becomes "a concluded working group of the IETF". It would be much better to have something like "The {IESG|IAB} oversees the 6bone {WG|?} chaired by Bob Fink that has the responsibility for the 3ffe::/16 block". Michel. From bmanning@ISI.EDU Thu Aug 22 04:03:00 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Wed, 21 Aug 2002 20:03:00 -0700 (PDT) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: from Robert Kiessling at "Aug 22, 2 00:44:38 am" Message-ID: <200208220303.g7M330I02799@boreas.isi.edu> % Bill Manning writes: % % > One of the promises of v6 was that -AS A TRANSITION- % > folks could run dual stack. Not to pick, but % > the router vendors I've looked at do not have % > similar code quality or feature sets between v4 and v6. % % Juniper does have very high code quality for IPv6. In fact we haven't % experienced any operational problem with running it in parallel to % IPv4, in contrast to The Router Vendor on dedicated routers. If only they would have told me about it before I made the last purchase of hardware. They refused to even ack. v6 support until after I had taken delivery of ~USD500k of routing gear. Two weeks later they announced v6 support. No Juniper in our shop for another 24 months. Thats a -LONG- time for code to mature. % Non-availability of high-quality IPv6 connectivity in US is not a good % reason to mess up European and Asian progress in this area. No reason to. Route as you see fit. Just don't dictate routing policy to me unless/until we directly peer and then we can have a discussion. % > Same was true with inital IPv4 deployment. % % You are really implying that today's user community has similar % requirements to that at those times? Nope. I'm saying that code stability/interoperability was as bad or worse than in todays environment and circuit stability was much worse. However the clue density of network users was -MUCH- higher. % Today you cannot tell the users "use IPv6, and by the way, don't worry % if you don't have connectivity, it will propably come back in a couple % of days". Sure you can. What is your business model? % Robert --bill From tvo@EnterZone.Net Thu Aug 22 08:02:41 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 22 Aug 2002 03:02:41 -0400 (EDT) Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <20020821162516.D27015@Space.Net> Message-ID: On Wed, 21 Aug 2002, Gert Doering wrote: > Hi, > > On Tue, Aug 20, 2002 at 09:03:43PM +0200, Nicolas DEFFAYET wrote: > > 6bone address services must be free. > > Since 1996 it's free and it's workfine ! > > It's free because some people donate time and effort for free. You > don't have a "Right" to get that for free for ever. Get real. > I agree whole-heartedly. I do think that there should be some consolation to early adoptors though - the same as in v4 land. Something along the lines of "if you had space allocated prior to [date] you will not be required to pay fees for [space allocated prior to date]." --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From gert@space.net Thu Aug 22 08:35:21 2002 From: gert@space.net (Gert Doering) Date: Thu, 22 Aug 2002 09:35:21 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: ; from tvo@EnterZone.Net on Thu, Aug 22, 2002 at 03:02:41AM -0400 References: <20020821162516.D27015@Space.Net> Message-ID: <20020822093521.M27015@Space.Net> Hi, On Thu, Aug 22, 2002 at 03:02:41AM -0400, John Fraizer wrote: > I agree whole-heartedly. I do think that there should be some consolation > to early adoptors though - the same as in v4 land. Something along the > lines of "if you had space allocated prior to [date] you will not be > required to pay fees for [space allocated prior to date]." That's about what I read in Bob's proposal - significantly reduced RIR fees for "6bone sites". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45583 (46871) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pekkas@netcore.fi Thu Aug 22 08:52:28 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 22 Aug 2002 10:52:28 +0300 (EEST) Subject: [6bone] 6bone transition In-Reply-To: <20020821103604.A30808@snew.com> Message-ID: On Wed, 21 Aug 2002, Chuck Yerkes wrote: [...] > I will wonder what happens when [Bob] wins the lottery and flys > off with several supermodel/masseuses/chefs, never to be seen again. Some people feel 'responsible' for their works or creations. Perhaps you don't if you consider this as a possibility worth mentioning. -- 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 pekkas@netcore.fi Thu Aug 22 08:55:01 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 22 Aug 2002 10:55:01 +0300 (EEST) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <1029967615.25444.187.camel@wks1.fr.corp.ndsoftware.com> Message-ID: On 22 Aug 2002, Nicolas DEFFAYET wrote: > > 5) production networks announce all prefixes to everybody > > I add: > > 6) Don't provide by default full transit to peers, provide full > transit only if peer request it. Automatic full transit per request is a road to disaster, *especially* if said peer will also give transit to others. -- 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 pekkas@netcore.fi Thu Aug 22 09:06:02 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 22 Aug 2002 11:06:02 +0300 (EEST) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <20020821224714.GE16927@rvdp.org> Message-ID: On Thu, 22 Aug 2002, Ronald van der Pol wrote: > On Wed, Aug 21, 2002 at 17:52:25 -0300, Rik van Riel wrote: > > > 2) peers notify each other whether their network is production > > or experimental > > I think I agree with Bill that production and experimental means > different things to different people. But this is a key question. > We want to get rid of the many routing problems. For this, I think > we have to look at transit providers only. So I guess we as the > 6bone community have to come up with a list of *minimal* requirements > for 6bone transit sites. > > Let me kickoff: > - respond to problems within 18 hours (24 hours? how about weekend?) > - peerings with topologically close neighbours (transit or peer > sites) only > - actively cleanup current peering mess > - apply stringent prefix/AS filtering on peerings > > maybe: > - active monitoring of peerings? Maybe section. - have sufficient available bandwidth (e.g. 10+ Mbit/s), with hardware that can manage that, with a recent enough software which has no major problems. In any case, I don't think it's really possible to define unambiguously what a good transit is.. and what use is it, anyway? Those folks probably don't care or think they're good. Forgive my skepticism :-) -- 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 gert@space.net Thu Aug 22 14:12:42 2002 From: gert@space.net (Gert Doering) Date: Thu, 22 Aug 2002 15:12:42 +0200 Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: ; from pekkas@netcore.fi on Thu, Aug 22, 2002 at 10:55:01AM +0300 References: <1029967615.25444.187.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20020822151242.Z27015@Space.Net> Hi, On Thu, Aug 22, 2002 at 10:55:01AM +0300, Pekka Savola wrote: > On 22 Aug 2002, Nicolas DEFFAYET wrote: > > > 5) production networks announce all prefixes to everybody > > > > I add: > > > > 6) Don't provide by default full transit to peers, provide full > > transit only if peer request it. > > Automatic full transit per request is a road to disaster, *especially* if > said peer will also give transit to others. "Full transit to everybody" was a good idea to get a pretty tightly meshed IPv6 network into place, which is *good* because it means that you have (typically) only few AS hops to traverse - and thus fewer networks in between that can mess up your routing. Won't help against Ghosts, of course, but there is nothing besides establishment of a clear upstream/downstream structure and strong filtering on the downstream BGP sessions to fix *that*. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45583 (46871) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pekkas@netcore.fi Thu Aug 22 14:17:46 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 22 Aug 2002 16:17:46 +0300 (EEST) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <20020822151242.Z27015@Space.Net> Message-ID: On Thu, 22 Aug 2002, Gert Doering wrote: > "Full transit to everybody" was a good idea to get a pretty tightly > meshed IPv6 network into place, which is *good* because it means that > you have (typically) only few AS hops to traverse - and thus fewer > networks in between that can mess up your routing. And quality (or lack thereof) is equally indeterminate everywhere; as-path length tells *nothing* about optimal paths, ... Hierarchy is good. > Won't help against Ghosts, of course, but there is nothing besides > establishment of a clear upstream/downstream structure and strong > filtering on the downstream BGP sessions to fix *that*. Yep. The question is whether we want to evolve 6bone network (very difficult, but only if some transits would step up, *some* process might evolve..) or let it rot on purpose. I'm starting to think voting for b). -- 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 gert@space.net Thu Aug 22 14:27:56 2002 From: gert@space.net (Gert Doering) Date: Thu, 22 Aug 2002 15:27:56 +0200 Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: ; from pekkas@netcore.fi on Thu, Aug 22, 2002 at 04:17:46PM +0300 References: <20020822151242.Z27015@Space.Net> Message-ID: <20020822152756.A27015@Space.Net> Hi, On Thu, Aug 22, 2002 at 04:17:46PM +0300, Pekka Savola wrote: > On Thu, 22 Aug 2002, Gert Doering wrote: > > "Full transit to everybody" was a good idea to get a pretty tightly > > meshed IPv6 network into place, which is *good* because it means that > > you have (typically) only few AS hops to traverse - and thus fewer > > networks in between that can mess up your routing. > > And quality (or lack thereof) is equally indeterminate everywhere; as-path > length tells *nothing* about optimal paths, ... Of course. But if you have *enough* peerings, you'll be able to reach most networks in a maximum of 2 hops - and if you then apply some MED fiddling to mark "slow" tunnels, you can achieve pretty good results. (Of course it's helpful if you tag your routes accordingly, so your peers can filter accordingly). This works amazingly well :-) > Hierarchy is good. Hierarchy isn't too bad *iff* there are major differences between participants. As long as none of my upstream ISPs *offer* IPv6 connectivity, I don't see any reason why some of the ASes out there should be "further up" or "further down" in the hierarchy than we are. They are *peers*, more or less. [..] > The question is whether we want to evolve 6bone network (very difficult, > but only if some transits would step up, *some* process might evolve..) > or let it rot on purpose. I'm starting to think voting for b). I see this as a market issue. As soon as someone is actually willing to spend money on *good* IPv6 connectivity, there is an incentive to avoid routing over trans-continental (or even international) tunnels, and things will unravel on their own. Of course I'm all for adding native peerings, dropping tunnels to non-responsive peers (or to some that have a dendency to blackhole things), and so on. But I don't expect a change to a hierarchically organized network of purely native links "really soon now". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45583 (46871) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From itojun@itojun.org Thu Aug 22 01:45:10 2002 From: itojun@itojun.org (Jun-ichiro itojun Hagino) Date: Thu, 22 Aug 2002 09:45:10 +0900 (JST) Subject: [6bone] Fw: [sig-ipv6] RE: [sig-policy] FW: Proposal for Transfer of 6bone Address ManagementResponsibilities to RIRs Message-ID: <20020822004510.ECD584B22@coconut.itojun.org> --NextPart-20020822094507-0669400 --NextPart-20020822094507-0669400 Content-Type: Message/Rfc822 Return-Path: owner-sig-ipv6@lists.apnic.net Delivery-Date: Thu Aug 22 09:42:44 2002 Return-Path: Delivered-To: itojun@itojun.org X-Authentication-Warning: data.staff.apnic.net: majordom set sender to owner-sig-ipv6@lists.apnic.net using -f From: "Paul Wilson" To: , Subject: [sig-ipv6] RE: [sig-policy] FW: Proposal for Transfer of 6bone Address ManagementResponsibilities to RIRs Date: Thu, 22 Aug 2002 10:36:42 +1000 Organization: APNIC Message-ID: <63B9746D4A92BF498D78584958F537E302AE88@lotus.exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-AP-Spam-Status: No, hits=-103.7 required=7 X-AP-Spam-Status: No, hits=-103 required=7 X-AP-Spam-Score: -103.7 (notspam) IN_REP_TO,X_AUTH_WARNING,DEAR_SOMEBODY,DOUBLE_CAPSWORD,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-sig-ipv6@lists.apnic.net Precedence: bulk X-Filter: mailagent [version 3.0 PL73] for itojun@itojun.org For those attending the coming APNIC Open Policy Meeting: Please note that Ray Plzak, President and CEO of ARIN, will be presenting this proposal on behalf of the RIRs during the Address Policy SIG on 4/5 September. Fur further details of the Open Policy Meeting programme, please see: http://www.apnic.net/meetings/14/programme Best regards, ________________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net ph/fx +61 7 3858 3100/99 ------------------------------------------------------------------------ See you at the 14th APNIC Open Policy Meeting Kitakyushu, Japan http://www.apnic.net/meetings/ 3-6 September 2002 ------------------------------------------------------------------------ > -----Original Message----- > From: owner-sig-policy@lists.apnic.net > [mailto:owner-sig-policy@lists.apnic.net] On Behalf Of APNIC > Secretariat > Sent: Wednesday, August 21, 2002 6:10 PM > To: apnic-announce@apnic.net; sig-policy@apnic.net; sig-ipv6@apnic.net > Subject: [sig-policy] FW: Proposal for Transfer of 6bone > Address ManagementResponsibilities to RIRs > > > Dear Colleagues, > > It has been proposed that the management of the 6bone > 3FFE::/16 address > space be transferred to the Regional Internet Registries (RIRs). More > information about the 6bone can be obtained at http://www.6bone.net/. > > At a recent 6bone meeting, Bob Fink made a proposal for this > management > transfer. A copy of the presentation slides are available at > > http://www.6bone.net/ngtrans/minutes/default.htm > or at > http://www.apnic.net/meetings/14/sigs/policy/index.html > > These presentation slides were based on the text, "Policies > for transfer of > 6bone address management responsibilities to RIRs," provided below. > > Please send your comments about this proposal to the APNIC > Address Policy > SIG mailing list (sig-policy@apnic.net). The 6bone and other > RIRs will be > conducting similar reviews within their communities and APNIC will > summarise the collective responses, issues, and concerns, > made in regard to > this proposal. This review process will end on December 31, 2002. > > Regards > - APNIC Secretariat > > > ******************* > > Policies for transfer of 6bone address management > responsibilities to RIR > > Version: 20 August 2002 > > 1. Introduction > > 6bone was established in 1996 as a continuing IPv6 test bed with the > original purpose of testing of standards and implementations, > and the more > current focus on testing of transition and operational > procedures, as well > as application conversion. It provides an opportunity for > those wanting > early experience and/or needing to experiment with IPv6, with > a minimum of > startup complexity, particularly in terms of address > management policies, > and at minimal cost. It also provides an open peer process for > information, hookup help, and support, with strong ties to > the IETF process > as well as to the operational community. > > To date, 6bone address space has been allocated and registered in an > informal process quite separate from the existing Regional Internet > Registry system. The purpose of this proposal is to establish > a long term > model that provides for a more "official" home for 6bone address space > management within the established Internet administrative > structures. At > the same time, the proposal recognizes that 6bone's most important > functions as an accessible and informal test bed network must > be maintained. > > This document proposes the transfer of responsibility for > administration of > 6bone address space (3ffe::/16) to the Regional Internet > Address Registries > (RIRs). It describes a set of policies and procedures for > this transfer, > and for the ongoing administration of 6bone address space > within the RIR > framework. > > It should be noted that the ongoing operation of the 6bone, > and policies > related to it, are still the purview of the 6bone community > itself. For > example, 6bone network compliance with the 6bone routing > guidelines is a > matter for the community itself to resolve, typically by mail lists. > > It is also important to continue the strongly volunteer efforts of the > 6bone, both to make it as easy and friendly as possible for > individuals, > sites and networks to experiment and learn about IPv6, but > also to keep the > process streamlined and cost-effective. > > 2. Definitions > > a) "6bone" and "6bone community", as it appears in section 3 > below, means > 6bone organizations and individuals including the RIRs, > "6bone members" > (see below), and those participating in the 6bone mail list. > > b) 6bone members are defined as entities which are approved > for address > space allocation by the 6bone community in accordance with > 6bone policies, > and who agree to be bound by those policies and the policies > stated below. > > c) 6bone allocations are allocations of 6bone address space > which are held > by 6bone members, or made to 6bone members in accordance with these > policies. > > d) 6bone address space is defined as IPv6 address space within the > 3ffe::/16 address block. > > 3. Policies > > 3.1 General > > a) In consultation with 6bone, RIRs will implement a common > set of policies > applying specifically to 6bone allocations. This will follow > the current > RFC2772, "6Bone Backbone Routing Guidelines" and/or successor > documents > resulting as an evolution of conversations in the 6bone > community and the > RIRs.; > > b) 6bone members will be served by respective RIR in their region, for > "6bone Address Services" including 6bone address allocation, database > registration and maintenance, and ip6.arpa registration (as described > below); > > c) In order to receive 6bone address services from an RIR as described > here, each 6bone member must "join" that RIR, that is, enter into the > appropriate membership or services agreement with the RIR. > > d) RIR fees will be waived for 6bone address services > provided by RIRs to > 6bone members (but not for other services 6bone members may > require), until > 1 year after this agreement starts. After this time each RIR > may charge an > administration fee to cover each allocation made. This fee > simply covers > registration and maintenance, rather than the full allocation > process for > standard RIR members. This administration fee should be as > low as possible > as these requests do not have to undergo the same evaluation > process as > those requested in the normal policy environment. > > e) Organizations may receive 6bone address services from the > RIR only on > approval by 6bone, and in accordance with these policies; > > f) 6bone members will have the option to receive other > services from an RIR > (including allocation of production IPv6 address space), by > following the > policy, process and procedures in place at the time of application for > those services. > > g) Continuing compliance with 6bone policies, and with the > policies defined > here, will be verified by 6bone at least every 2 years; > > 3.2 6bone Address Services > > a) 6bone Address Services include allocation of 6bone address space, > registration and maintenance of database records relating to > that address > space, and registration of ip6.arpa records; > > b) 6bone address space allocations will be made from > 3ffe::/16 and only /32 > prefixes will be allocated. There will be exceptions for > unusual and new > proposals per joint RIR and 6bone review and approval. A > relevant example > of this is one or more new strategies such as geographic or metro > addressing; > > c) No additional 6-bone address space will be allocated to > any 6bone member > (therefore no provision will be made for aggregation of multiple > allocations, reservations etc); > > d) 6bone address services will be provided strictly for experimental, > non-commercial use; > > e) Allocations will be made on the clear and stated > understanding that the > prefix 3ffe::/16 has a limited lifetime. The dates for the > termination of > allocation from the prefix and the expiration of the prefix will be > determined at a future date. The RIRs will not participate in these > determinations. > > f) 6bone address space will be returned to the RIR when no > longer in use, > when reclaimed due to non-compliance with 6bone or RIR > policies, or when > 3ffe: space is finally withdrawn; > > g) Registration of 6bone address space within the ip6.int zone is not > covered by this policy, and is at option of 6bone member; > > h) Registration of 6bone sites, maintainers, persons and address space > within the existing consolidated 6bone registry is not covered by this > policy, and is at option of 6bone and its current policies. > > 3.3 Transfer of existing 6bone members > > a) Responsibility for existing 6bone members in respect of services > described here will be transferred from 6bone to the > respective RIR, at the > option of those members individually, on entering into the appropriate > agreement with the RIR; > > b) On joining the RIR, 6bone address registration records for > the member > concerned will be transferred from 6bone registry to the > respective RIR > database; > > c) On joining the RIR, 6bone members may establish ip6.arpa delegation > records in accordance with applicable RIR procedures; > > d) Legacy holders will use RIR administrative procedures for > management of > their records; > > e) There will be a sunset (2 years?) on existing 6bone members not > transferring to RIR administrative procedures, after which > their address > allocation will be revoked. > > > -- > ______________________________________________________________________ > APNIC Secretariat > Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 > PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 > ---------------------------------------------------------------------- > See you at the 14th APNIC Open Policy Meeting Kitakyushu, Japan > http://www.apnic.net/meetings/ 3-6 September 2002 > ---------------------------------------------------------------------- > > > > > * sig-policy: APNIC SIG on resource management > policy * > * To unsubscribe: send "unsubscribe" to sig-policy-request@apnic.net * > * sig-ipv6: APNIC SIG on IPv6 technology and policy issues * * To unsubscribe: send "unsubscribe" to sig-ipv6-request@lists.apnic.net * --NextPart-20020822094507-0669400-- From Francis.Dupont@enst-bretagne.fr Thu Aug 22 20:01:33 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Thu, 22 Aug 2002 21:01:33 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: Your message of Tue, 20 Aug 2002 09:49:45 PDT. <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> Message-ID: <200208221901.g7MJ1X6o009527@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: As mentioned previously, and presented at the Yokohama IETF 6bone meeting, I have been discussing with the management of the three Regional Internet Registries (APNIC, ARIN, and RIPE) the transfer of 6bone 3FFE::/16 address space management to the RIRs. => IMHO this is not a good idea because this will put the whole control of address allocation in few hands. c) In order to receive 6bone address services from an RIR as described here, each 6bone member must "join" that RIR, that is, enter into the appropriate membership or services agreement with the RIR. => I strongly object to this if the "join" can't be done for a price of zero (of course in this case RIRs will complain :-). d) RIR fees will be waived for 6bone address services provided by RIRs to 6bone members (but not for other services 6bone members may require), until 1 year after this agreement starts. After this time each RIR may charge an administration fee to cover each allocation made. This fee simply covers registration and maintenance, rather than the full allocation process for standard RIR members. This administration fee should be as low as possible as these requests do not have to undergo the same evaluation process as those requested in the normal policy environment. => one of the interest of IPv6 is to finish with this system of fees for addresses. I am afraid that the current RIR monopoly will give at the end something even nastier than ICANN. Regards Francis.Dupont@enst-bretagne.fr From old_mc_donald@hotmail.com Thu Aug 22 21:07:21 2002 From: old_mc_donald@hotmail.com (Gav) Date: Thu, 22 Aug 2002 21:07:21 +0100 Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <20020821180257.GA16927@rvdp.org> Message-ID: <000301c24a17$864d47b0$0100a8c0@lap1> -----Original Message----- From: 6bone-admin@mailman.isi.edu [mailto:6bone-admin@mailman.isi.edu] On Behalf Of Ronald van der Pol Sent: 21 August 2002 19:03 To: Bill Manning Cc: 6bone@ISI.EDU More and more OSes run IPv6 out of the box. End users start using IPv6 and notice problems because there are too many routing problems on the 6bone. So they switch off IPv6 again. We are scaring people away from IPv6 because of the tunnel mess, old router software and sites that don't monitor the transit they are giving to everyone. Rvdp Hi All , (Sorry another long posting) At the moment my own brief experience is that of Microsoft's IPv6 offering. IPv6 stack can be downloaded, installed and configured for Windows 2000 (possibly 9x and NT also). Windows XP does provide IPv6 'out of the box' though turned off by default. Typing in 'ipv6 install' into a DOS session is not exactly brain surgery to enable it. The problem I (and I presume others like me, just one person trying to experiment with a view to having a secure future (and network) involving IPv6) is not with the availability of the protocol, but with configuring it for use afterwards. I have an account with Freenet6 (How many more providers like them are there, and is there a definitive list), I download and configure their Tunnel Broker and .conf file. I get 4 replies when I do ping6 ::1 as expected. Using 'ipv6 if' I get :- Interface 4: Ethernet: Local Area Connection uses Neighbor Discovery uses Router Discovery link-layer address: 00-40-d0-2a-af-71 preferred link-local fe80::240:d0ff:fe2a:af71, life infinite multicast interface-local ff01::1, 1 refs, not reportable multicast link-local ff02::1, 1 refs, not reportable multicast link-local ff02::1:ff2a:af71, 1 refs, last reporter link MTU 1500 (true link MTU 1500) current hop limit 128 reachable time 27000ms (base 30000ms) retransmission interval 1000ms DAD transmits 1 Interface 3: 6to4 Tunneling Pseudo-Interface does not use Neighbor Discovery does not use Router Discovery preferred global 2002:3eff:c534::3eff:c534, life infinite link MTU 1280 (true link MTU 65515) current hop limit 128 reachable time 26000ms (base 30000ms) retransmission interval 1000ms DAD transmits 0 Interface 2: Automatic Tunneling Pseudo-Interface does not use Neighbor Discovery does not use Router Discovery router link-layer address: 0.0.0.0 EUI-64 embedded IPv4 address: 0.0.0.0 preferred link-local fe80::5efe:62.255.197.52, life infinite preferred global ::62.255.197.52, life infinite preferred link-local fe80::5efe:192.168.0.1, life infinite link MTU 1280 (true link MTU 65515) current hop limit 128 reachable time 37000ms (base 30000ms) retransmission interval 1000ms DAD transmits 0 Interface 1: Loopback Pseudo-Interface does not use Neighbor Discovery does not use Router Discovery link-layer address: preferred link-local ::1, life infinite preferred link-local fe80::1, life infinite link MTU 1500 (true link MTU 4294967295) current hop limit 128 reachable time 33500ms (base 30000ms) retransmission interval 1000ms DAD transmits 0 I have no idea what should and shouldn't be in the above data, I just know that I can NOT do a damn thing - can't ping6 any address whatsoever outside my LAN , no tracert6 , no access to ipv6 only websites, etc...(I am doing it wrong, should I be connecting another way? - There is a lot of RFC's about sure, but I sometimes get overloaded with stuff I don't really need to know just yet. Apart from hopefully someone pointing me in the right direction (no luck with Freenet6 yet!) , the above was really a demonstration to back up ideas that it is not easy to get IPv6 connectivity for people like me (I'm guessing the whole point of the 6bone is to reach out to people like me?) I am moving to Australia from England in about 3 weeks now, so maybe I'll get a better deal there but using my current situation as an example - My current ISP and connection to the internet is NTL , if I successfully connected to Freenet6 (for example) using IPv6 , am I really seeing a benefit routing wise? I see no mention anywhere from NTL about providing a through route to IPv6 networks. I'm surely therefore bottlenecked before I even start. Thanks for listening, I think I've just confused myself even more. However, I promise not to leave this list until I'm fully IPv6 connected, aware, and have my own IPv6 only website. I may be here sometime:) --- Outgoing mail is certified Virus Free. - Gavin.. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002 From gert@space.net Thu Aug 22 22:14:28 2002 From: gert@space.net (Gert Doering) Date: Thu, 22 Aug 2002 23:14:28 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <200208221901.g7MJ1X6o009527@givry.rennes.enst-bretagne.fr>; from Francis.Dupont@enst-bretagne.fr on Thu, Aug 22, 2002 at 09:01:33PM +0200 References: <5.1.0.14.0.20020820090936.02a21040@imap2.es.net> <200208221901.g7MJ1X6o009527@givry.rennes.enst-bretagne.fr> Message-ID: <20020822231428.I27015@Space.Net> Hi, On Thu, Aug 22, 2002 at 09:01:33PM +0200, Francis Dupont wrote: > => one of the interest of IPv6 is to finish with this system of fees for > addresses. I am afraid that the current RIR monopoly will give at the end > something even nastier than ICANN. How do you propose to handle address management, reverse DNS management etc. without someone to take care of it (and get paid for it)? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45583 (46871) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Francis.Dupont@enst-bretagne.fr Thu Aug 22 23:04:37 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Fri, 23 Aug 2002 00:04:37 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: Your message of Thu, 22 Aug 2002 23:14:28 +0200. <20020822231428.I27015@Space.Net> Message-ID: <200208222204.g7MM4b6o009945@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: > => one of the interest of IPv6 is to finish with this system of fees for > addresses. I am afraid that the current RIR monopoly will give at the end > something even nastier than ICANN. How do you propose to handle address management, reverse DNS management etc. without someone to take care of it (and get paid for it)? => I didn't say I have the "solution" but the Internet was here for enough time to show what things are not good solutions. And the current system, the RIR monopoly, can only give a disaster in the long term, and something even worse than ICANN because the IPv4 address space is really limited. Unfortunately it seems that only this system is proposed for IPv6 and we already got some bad consequences: can you really argue that RIRs pushed for IPv6 last years? To come back to the 6bone (and to stay in the list charter), the case of inviduals and sites interested in IPv6 (/64, /48, ...) is handled by small organizations without money or resources to collect money (this is a key point, I'll come back to it), not by ISPs (i.e., RIR members) because the number of ISPs supporting IPv6 is too small. The proposed transfer will remove the 6bone choice to these organizations and their "clients" and throw everybody to worse solutions like 6to4 (worse because the 6to4-relay issue is far to be solved). About collecting small fees: this is something very hard and very expensive. Only a large organization can easily collect small fees and in general these fees are at 99% used to keep the organization running. Just ask if RIRs are ready to run pTLAs in the framework of Bob's proposal (if current small organizations stop running them, we'll need to transfer this too to someone). Regards Francis.Dupont@enst-bretagne.fr (SIGCOMM'02 laptop bar is closing, I'll continue after) From bmanning@ISI.EDU Thu Aug 22 23:14:11 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 22 Aug 2002 15:14:11 -0700 (PDT) Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <20020822231428.I27015@Space.Net> from Gert Doering at "Aug 22, 2 11:14:28 pm" Message-ID: <200208222214.g7MMEBU15001@boreas.isi.edu> % Hi, % % On Thu, Aug 22, 2002 at 09:01:33PM +0200, Francis Dupont wrote: % > => one of the interest of IPv6 is to finish with this system of fees for % > addresses. I am afraid that the current RIR monopoly will give at the end % > something even nastier than ICANN. % % How do you propose to handle address management, reverse DNS management % etc. without someone to take care of it (and get paid for it)? % % Gert Doering % -- NetMaster Not, perhaps a fair question. Some of use are being paid to look after this stuff now. -- --bill From tvo@EnterZone.Net Fri Aug 23 00:18:50 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Thu, 22 Aug 2002 19:18:50 -0400 (EDT) Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <20020822231428.I27015@Space.Net> Message-ID: On Thu, 22 Aug 2002, Gert Doering wrote: > Hi, > > On Thu, Aug 22, 2002 at 09:01:33PM +0200, Francis Dupont wrote: > > => one of the interest of IPv6 is to finish with this system of fees for > > addresses. I am afraid that the current RIR monopoly will give at the end > > something even nastier than ICANN. > > How do you propose to handle address management, reverse DNS management > etc. without someone to take care of it (and get paid for it)? > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 45583 (46871) > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > >From the ARIN website: "Organizations approved for receiving the standard /35 initial IPv6 allocation will be charged an annual fee of $2,500 (US). For larger amounts of addresses, a fee of $20,000 (US) will be assessed. These fees are payable prior to receiving the addresses and thereafter on the anniversary date of the initial allocation. However, IPv6 fees will not be charged to organizations that are current ARIN IPv4 subscription holders." As long as the current "if you're already paying us for v4 allocation(s), you don't pay more" holds true, I don't have a problem. I find it hard to swallow that there is $20,000USD worth of work involved with maintaining the whois database and two ip6.arpa records for each and every /32 v6 allocation. $10K USD for each /16 of v4 space seems a bit steep as well but such is life. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From pekkas@netcore.fi Fri Aug 23 08:03:20 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Fri, 23 Aug 2002 10:03:20 +0300 (EEST) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: <20020822152756.A27015@Space.Net> Message-ID: On Thu, 22 Aug 2002, Gert Doering wrote: > On Thu, Aug 22, 2002 at 04:17:46PM +0300, Pekka Savola wrote: > > On Thu, 22 Aug 2002, Gert Doering wrote: > > > "Full transit to everybody" was a good idea to get a pretty tightly > > > meshed IPv6 network into place, which is *good* because it means that > > > you have (typically) only few AS hops to traverse - and thus fewer > > > networks in between that can mess up your routing. > > > > And quality (or lack thereof) is equally indeterminate everywhere; as-path > > length tells *nothing* about optimal paths, ... > > Of course. But if you have *enough* peerings, you'll be able to reach > most networks in a maximum of 2 hops - and if you then apply some > MED fiddling to mark "slow" tunnels, you can achieve pretty good results. This leads to an "arms race"; everyone will need to get even more tunnels, leading to even tighter spaghetti. I don't think having to do manual fiddling should be necessary, but that's life I suppose. > > Hierarchy is good. > > Hierarchy isn't too bad *iff* there are major differences between > participants. True, that helps in organization. > As long as none of my upstream ISPs *offer* IPv6 connectivity, I don't > see any reason why some of the ASes out there should be "further up" > or "further down" in the hierarchy than we are. Have you asked them from IPv6 connectivity? Have others, also customers in that upstream, asked for that? Perhaps IPv6 availability should be given as one decisive factor when evaluating proposals (we certainly do that). Native is not necessary, tunneling would work just fine too. > I see this as a market issue. As soon as someone is actually willing to > spend money on *good* IPv6 connectivity, there is an incentive to avoid > routing over trans-continental (or even international) tunnels, and things > will unravel on their own. Well, not necessarily spending money, but *NOT* spending money on upstreams that do not offer anything wrt. IPv6. That'll send just the right kind of signal to ISP's: that they should offer basic IPv6 services if they want customers. > Of course I'm all for adding native peerings, dropping tunnels to > non-responsive peers (or to some that have a dendency to blackhole > things), and so on. But I don't expect a change to a hierarchically > organized network of purely native links "really soon now". Well, I'm a doubtful "6bone" as such will ever evolve into that. People who have native links & v6-enabled transits etc. will just start operating "production" networks. And then they either shut down connections to 6bone completely (to avoid problems), or give the routes learned from there the least preference. -- 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 gert@space.net Fri Aug 23 08:24:22 2002 From: gert@space.net (Gert Doering) Date: Fri, 23 Aug 2002 09:24:22 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <200208222204.g7MM4b6o009945@givry.rennes.enst-bretagne.fr>; from Francis.Dupont@enst-bretagne.fr on Fri, Aug 23, 2002 at 12:04:37AM +0200 References: <20020822231428.I27015@Space.Net> <200208222204.g7MM4b6o009945@givry.rennes.enst-bretagne.fr> Message-ID: <20020823092422.K27015@Space.Net> Hi, On Fri, Aug 23, 2002 at 12:04:37AM +0200, Francis Dupont wrote: > In your previous mail you wrote: > > > => one of the interest of IPv6 is to finish with this system of fees for > > addresses. I am afraid that the current RIR monopoly will give at the end > > something even nastier than ICANN. > > How do you propose to handle address management, reverse DNS management > etc. without someone to take care of it (and get paid for it)? > > => I didn't say I have the "solution" but the Internet was here for enough > time to show what things are not good solutions. And the current system, > the RIR monopoly, can only give a disaster in the long term, and something > even worse than ICANN because the IPv4 address space is really limited. If IPv4 runs out, so be it. This is why we're doing IPv6. > Unfortunately it seems that only this system is proposed for IPv6 and > we already got some bad consequences: can you really argue that RIRs pushed > for IPv6 last years? I agree that the RIRs have been slow in adopting IPv6, and not very proactive either. On the other hand, in the last round of policy discussions, the restrictive attitude came from the ARIN *community*, not from the RIRs. I don't think, though, that the RIRs have slowed down IPv6 deployment - the 6bone was there, and still the big breakthrough isn't happening. > To come back to the 6bone (and to stay in the list charter), the case > of inviduals and sites interested in IPv6 (/64, /48, ...) is handled by > small organizations without money or resources to collect money (this is > a key point, I'll come back to it), not by ISPs (i.e., RIR members) because > the number of ISPs supporting IPv6 is too small. I honour voluntary efforts. Over time, and if we want to be IPv6 something that's available everywhere, this will have to change, because volunteers burn out eventually, or get bored. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45583 (46871) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert@space.net Fri Aug 23 08:27:29 2002 From: gert@space.net (Gert Doering) Date: Fri, 23 Aug 2002 09:27:29 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: ; from tvo@EnterZone.Net on Thu, Aug 22, 2002 at 07:18:50PM -0400 References: <20020822231428.I27015@Space.Net> Message-ID: <20020823092729.L27015@Space.Net> Hi, On Thu, Aug 22, 2002 at 07:18:50PM -0400, John Fraizer wrote: > >From the ARIN website: > > "Organizations approved for receiving the standard /35 initial IPv6 > allocation will be charged an annual fee of $2,500 (US). For larger > amounts of addresses, a fee of $20,000 (US) will be assessed. So go and tell ARIN that you don't like that. In RIPE land, this is not the case. You pay annual fees for all services altogether (which go up a bit if you have very much IPv4 space, which *does* create extra work) and - right now - no extra costs for IPv6. [..] > As long as the current "if you're already paying us for v4 allocation(s), > you don't pay more" holds true, I don't have a problem. This is true in RIPE land. > I find it hard to swallow that there is $20,000USD worth of work involved > with maintaining the whois database and two ip6.arpa records for each and > every /32 v6 allocation. This is very much indeed, and I would not like that either. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45583 (46871) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From tjc@ecs.soton.ac.uk Fri Aug 23 08:33:42 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Fri, 23 Aug 2002 08:33:42 +0100 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: References: <20020822231428.I27015@Space.Net> Message-ID: <20020823073342.GA5040@login.ecs.soton.ac.uk> On Thu, Aug 22, 2002 at 07:18:50PM -0400, John Fraizer wrote: > > >From the ARIN website: > > "Organizations approved for receiving the standard /35 initial IPv6 > allocation will be charged an annual fee of $2,500 (US). For larger > amounts of addresses, a fee of $20,000 (US) will be assessed. These fees > are payable prior to receiving the addresses and thereafter on the > anniversary date of the initial allocation. However, IPv6 fees will not be > charged to organizations that are current ARIN IPv4 subscription holders." > > As long as the current "if you're already paying us for v4 allocation(s), > you don't pay more" holds true, I don't have a problem. > > I find it hard to swallow that there is $20,000USD worth of work involved > with maintaining the whois database and two ip6.arpa records for each and > every /32 v6 allocation. I assume the above text should say "standard /32 initial IPv6 allocation" and thus the "only" fees applicable for a new IPv6-only registrat would be $2,500 US. It would not be good for the 6bone to be liable to $2,500 per allocation, given the finances behind an organistaion asking for production space as opposed to one asking for 6bone space may well be very different. Or perhaps a deterrent to keep the "amateurs" away is good. What's also interesting is where the SubTLA growth is happening. From snapshots I noticed: Jul-01 May-02 Aug-02 Last 3 months RIPE 41 58 87 29 APNIC 31 56 76 20 ARIN 21 28 32 4 That's a 150% growth in APNIC in a year. Does anyone have a monthly status? Tim From rfurda@best.ca Fri Aug 23 09:44:20 2002 From: rfurda@best.ca (Richard Furda) Date: Fri, 23 Aug 2002 10:44:20 +0200 Subject: [6bone] Spam Message-ID: <5.1.1.6.0.20020823103756.00a981d8@riso.sk> Hello, I must say, I am amazed that spammers know what 6Bone and 6bone whois database is. I have not posted anywhere the ipv6-support@best.ca contact mailbox, except the whois database. I have contacted the appropriate people to make this crap stop. Richard ---------- Forwarded message ---------- Date: Fri, 23 Aug 2002 12:41:15 +0800 From: Sarah Williams Reply-To: Sarah Williams To: "ipv6-support@best.ca" Subject: 6BONE.BEST.CA Hi I visited 6BONE.BEST.CA, and noticed that you're not listed on some search engines! I think we can offer you a service which can help you increase traffic and the number of visitors to your website. I would like to introduce you to TrafficMagnet.com. We offer a unique technology that will submit your website to over 300,000 search engines and directories every month. [img_tm.gif] [ess.jpg] [img_signup.gif] You'll be surprised by the low cost, and by how effective this website promotion method can be. To find out more about TrafficMagnet and the cost for submitting your website to over 300,000 search engines and directories, visit www.TrafficMagnet.com. I would love to hear from you. Best Regards, Sarah Williams Sales and Marketing E-mail: sarah_williams@trafficmagnet.com http://www.TrafficMagnet.com From galania@ipv6.inictel.gob.pe Fri Aug 23 15:35:07 2002 From: galania@ipv6.inictel.gob.pe (Gino Francisco Alania Hurtado) Date: Fri, 23 Aug 2002 09:35:07 -0500 Subject: [6bone] ping6 Message-ID: <3D66481B.3090601@ipv6.inictel.gob.pe> Desire to do ping6 from host of my LAN Ipv6 to www.6bone.net , analyzing zebra I observe this: inter2> show bgp summary BGP router identifier 200.60.172.144, local AS number 46014 1 BGP AS-PATH entries 0 BGP community entries Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/* PfxRcd* 3ffe:8070:101a::1 4 278 7 7 0 0 0 00:01:53 *Idle * Total number of neighbors 1 The problem where is in my end or the remote end? I have the following configuration of zebra ------------------------------------------------------------------------------------------------------------------------- interface eth0 ipv6 nd send-ra ipv6 nd prefix-advertisement 3ffe:8070:101a:1001::/64 ! interface inter2 -------------------------------------------------------------------------------------------------------------------------- and in the BGP he is the following one. -------------------------------------------------------------------------------------------------------------- router bgp 46014 !! bgp router-id 6342 ipv6 bgp network 3ffe:8070:101a::/48 !nuevo tunnel unam ipv6 bgp neighbor 3ffe:8070:101a::1 remote-as 278 ipv6 bgp neighbor 3ffe:8070:101a::1 interface inter2 ipv6 bgp neighbor 3ffe:8070:101a::1 description UNAM mexico 6bone ipv6 bgp neighbor 3ffe:8070:101a::1 next-hop-self ! access-list all permit any ! line vty ----------------------------------------------------------------------------------------------------------------- thanks From galania@ipv6.inictel.gob.pe Fri Aug 23 15:35:07 2002 From: galania@ipv6.inictel.gob.pe (Gino Francisco Alania Hurtado) Date: Fri, 23 Aug 2002 09:35:07 -0500 Subject: [6bone] ping6 Message-ID: <3D66481B.3090601@ipv6.inictel.gob.pe> Desire to do ping6 from host of my LAN Ipv6 to www.6bone.net , analyzing zebra I observe this: inter2> show bgp summary BGP router identifier 200.60.172.144, local AS number 46014 1 BGP AS-PATH entries 0 BGP community entries Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/* PfxRcd* 3ffe:8070:101a::1 4 278 7 7 0 0 0 00:01:53 *Idle * Total number of neighbors 1 The problem where is in my end or the remote end? I have the following configuration of zebra ------------------------------------------------------------------------------------------------------------------------- interface eth0 ipv6 nd send-ra ipv6 nd prefix-advertisement 3ffe:8070:101a:1001::/64 ! interface inter2 -------------------------------------------------------------------------------------------------------------------------- and in the BGP he is the following one. -------------------------------------------------------------------------------------------------------------- router bgp 46014 !! bgp router-id 6342 ipv6 bgp network 3ffe:8070:101a::/48 !nuevo tunnel unam ipv6 bgp neighbor 3ffe:8070:101a::1 remote-as 278 ipv6 bgp neighbor 3ffe:8070:101a::1 interface inter2 ipv6 bgp neighbor 3ffe:8070:101a::1 description UNAM mexico 6bone ipv6 bgp neighbor 3ffe:8070:101a::1 next-hop-self ! access-list all permit any ! line vty ----------------------------------------------------------------------------------------------------------------- thanks From richardj@arin.net Fri Aug 23 15:59:49 2002 From: richardj@arin.net (Richard Jimmerson) Date: Fri, 23 Aug 2002 10:59:49 -0400 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: Message-ID: <002401c24ab5$ba8c2d40$4a8888c0@arin.net> Hello John, > As long as the current "if you're already paying us > for v4 allocation(s), you don't pay more" holds true, > I don't have a problem. It is currently the case that ARIN does not collect fees from current ARIN IPv4 subscribers who request and qualify for IPv6 address space. A note from the ARIN web site: ** "ARIN will not collect subscription fees for current ARIN IPv4 subscribers who request and qualify for IPv6 address space. This will be effective from January 1, 2001 to December 31, 2002 unless terminated earlier by the ARIN Board. This change in fee policy was enacted by the ARIN Board of Trustees at their December 14, 2000 meeting." ** The IPv6 fee schedule is currently being evaluated. Included below is a statement from the minutes of the ARIN Board of Trustees meeting, July 9, 2002. This has been added as a note to the fee schedule page of the ARIN website. ** "The ARIN Board of Trustees notes that the recent change to the IPv6 minimum allocation size has an impact on the fee schedule. While a new fee schedule is being evaluated, the Board waives any additional fees that would otherwise be assessed based on the larger initial amount of address space. This waiver is effective August 1, 2002 until such time as the Board publishes a new fee schedule. The current waiver of assessment of fees for IPv4 subscribers who request IPv6 space will remain in effect until December 31, 2002." ** Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: 6bone-admin@mailman.isi.edu > [mailto:6bone-admin@mailman.isi.edu] On Behalf Of John Fraizer > Sent: Thursday, August 22, 2002 7:19 PM > To: Gert Doering > Cc: Francis Dupont; Bob Fink; 6BONE List > Subject: Re: [6bone] proposal for transfer of 6bone address > management responsibilities to RIRs > > > > On Thu, 22 Aug 2002, Gert Doering wrote: > > > Hi, > > > > On Thu, Aug 22, 2002 at 09:01:33PM +0200, Francis Dupont wrote: > > > => one of the interest of IPv6 is to finish with this > system of fees for > > > addresses. I am afraid that the current RIR monopoly will > give at the end > > > something even nastier than ICANN. > > > > How do you propose to handle address management, reverse > DNS management > > etc. without someone to take care of it (and get paid for it)? > > > > Gert Doering > > -- NetMaster > > -- > > Total number of prefixes smaller than registry allocations: > 45583 (46871) > > > > SpaceNet AG Mail: netmaster@Space.Net > > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > > 80807 Muenchen Fax : +49-89-32356-299 > > > > > >From the ARIN website: > > "Organizations approved for receiving the standard /35 initial IPv6 > allocation will be charged an annual fee of $2,500 (US). For larger > amounts of addresses, a fee of $20,000 (US) will be assessed. > These fees > are payable prior to receiving the addresses and thereafter on the > anniversary date of the initial allocation. However, IPv6 > fees will not be > charged to organizations that are current ARIN IPv4 > subscription holders." > > As long as the current "if you're already paying us for v4 > allocation(s), > you don't pay more" holds true, I don't have a problem. > > I find it hard to swallow that there is $20,000USD worth of > work involved > with maintaining the whois database and two ip6.arpa records > for each and > every /32 v6 allocation. > > $10K USD for each /16 of v4 space seems a bit steep as well > but such is > life. > > > --- > 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 nicolas.deffayet@ndsoftware.net Fri Aug 23 16:45:13 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 23 Aug 2002 17:45:13 +0200 Subject: [6bone] ping6 In-Reply-To: <3D66481B.3090601@ipv6.inictel.gob.pe> References: <3D66481B.3090601@ipv6.inictel.gob.pe> Message-ID: <1030117513.679.195.camel@wks1.fr.corp.ndsoftware.com> On Fri, 2002-08-23 at 16:35, Gino Francisco Alania Hurtado wrote: > Desire to do ping6 from host of my LAN Ipv6 to www.6bone.net , analyzing > zebra I observe this: > > > inter2> show bgp summary > BGP router identifier 200.60.172.144, local AS number 46014 > 1 BGP AS-PATH entries > 0 BGP community entries > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > State/* PfxRcd* > 3ffe:8070:101a::1 > 4 278 7 7 0 0 0 00:01:53 > *Idle * > > Total number of neighbors 1 Autonomous System Name: IANA-RSVD Autonomous System Block: 32768 - 64511 First don't use reserved AS, if you don't have your AS, use a private ASN. > > The problem where is in my end or the remote end? Ask UNAM for check, UNAM must have: neighbor 3ffe:8070:101a::2 remote-as 46014 > I have the following configuration of zebra > ------------------------------------------------------------------------------------------------------------------------- > interface eth0 > ipv6 nd send-ra > ipv6 nd prefix-advertisement 3ffe:8070:101a:1001::/64 > ! > interface inter2 > -------------------------------------------------------------------------------------------------------------------------- > > and in the BGP he is the following one. > > -------------------------------------------------------------------------------------------------------------- > router bgp 46014 > !! bgp router-id 6342 > ipv6 bgp network 3ffe:8070:101a::/48 > !nuevo tunnel unam > ipv6 bgp neighbor 3ffe:8070:101a::1 remote-as 278 > ipv6 bgp neighbor 3ffe:8070:101a::1 interface inter2 > ipv6 bgp neighbor 3ffe:8070:101a::1 description UNAM mexico 6bone > ipv6 bgp neighbor 3ffe:8070:101a::1 next-hop-self > ! > access-list all permit any > ! > line vty > ----------------------------------------------------------------------------------------------------------------- Configuration not very good. Install Zebra 0.93a and use: ! ! Zebra configuration saved from vty ! 2001/08/11 12:37:58 ! hostname !!!-your-hostname-!!! password !!!-password-!!!! enable password !!!-password-!!! ! log file /var/log/bgpd.log ! debug bgp events ! router bgp 46014 bgp router-id 200.60.172.144 ! neighbor 3ffe:8070:101a::1 remote-as 278 neighbor 3ffe:8070:101a::1 next-hop-self neighbor 3ffe:8070:101a::1 interface inter2 neighbor 3ffe:8070:101a::1 description UNAM ! address-family ipv6 network 3ffe:8070:101a::/48 neighbor 3ffe:8070:101a::1 activate neighbor 3ffe:8070:101a::1 soft-reconfiguration inbound neighbor 3ffe:8070:101a::1 route-map unam-out out exit-address-family ! ipv6 access-list all permit any ! route-map unam-out permit 10 match ipv6 address all set ipv6 next-hop global 3ffe:8070:101a::2 ! line vty exec-timeout 60 0 ! end You can add after filter for accept only pTLA and sTLA from your peer. Best Regards, Nicolas DEFFAYET From joao@ripe.net Fri Aug 23 16:56:49 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Fri, 23 Aug 2002 17:56:49 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <20020823092729.L27015@Space.Net> References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> Message-ID: At 9:27 +0200 23/8/02, Gert Doering wrote: >Hi, > >On Thu, Aug 22, 2002 at 07:18:50PM -0400, John Fraizer wrote: >> >From the ARIN website: >> >> "Organizations approved for receiving the standard /35 initial IPv6 >> allocation will be charged an annual fee of $2,500 (US). For larger >> amounts of addresses, a fee of $20,000 (US) will be assessed. > >So go and tell ARIN that you don't like that. > >In RIPE land, this is not the case. You pay annual fees for all services >altogether (which go up a bit if you have very much IPv4 space, which >*does* create extra work) and - right now - no extra costs for IPv6. True, and the membership fees are purely based on cost recovery for the services as the RIPE NCC is non-profit organisation. One of the things that troubles me in Bob proposal is the mention of "minimal cost", unless that means the usual membership fee of course. Joao From fink@es.net Fri Aug 23 17:23:43 2002 From: fink@es.net (Bob Fink) Date: Fri, 23 Aug 2002 09:23:43 -0700 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: References: <20020823092729.L27015@Space.Net> <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> Message-ID: <5.1.0.14.0.20020823091857.00b5b5f8@imap2.es.net> Joao, At 05:56 PM 8/23/2002 +0200, Joao Luis Silva Damas wrote: >At 9:27 +0200 23/8/02, Gert Doering wrote: >>Hi, >> >>On Thu, Aug 22, 2002 at 07:18:50PM -0400, John Fraizer wrote: >>> >From the ARIN website: >>> >>> "Organizations approved for receiving the standard /35 initial IPv6 >>> allocation will be charged an annual fee of $2,500 (US). For larger >>> amounts of addresses, a fee of $20,000 (US) will be assessed. >> >>So go and tell ARIN that you don't like that. >> >>In RIPE land, this is not the case. You pay annual fees for all services >>altogether (which go up a bit if you have very much IPv4 space, which >>*does* create extra work) and - right now - no extra costs for IPv6. > >True, and the membership fees are purely based on cost recovery for the >services as the RIPE NCC is non-profit organisation. One of the things >that troubles me in Bob proposal is the mention of "minimal cost", unless >that means the usual membership fee of course. It means keeping the cost low to reflect actual cost of the service provided, which for the 6bone would be less than normal IPv4 allocation activity. However, the fee would have to be specific to the RIR as all the RIRs have their different rules/policies/procedures/culture/... Bob From JORDI PALET MARTINEZ" <20020823092729.L27015@Space.Net> Message-ID: <08cd01c24ac3$4f547b50$8700000a@consulintel.es> Joao, I know this is hard to say, but I fully agree with Francis. We already had this discussion some time ago (12th September in Barcelona Task Force meeting). One of the ways to promote IPv6 will be getting the address for free or for a REAL cost. I'm sure we can look alternative ways to delegate address space not involving so high memberships. And I'm ABSOLUTELY convinced it can be DONE with a lower price. I will prefer to be charged by each of the services provided by the RIR (that I need to pay nevertheless I use or not), instead of a single annual fee, with has only two levels. That is causing the ISPs making REAL business with the address space (and I know you can say they charge for the services, but we can force them to provide this free of charge and charge for OTHER real services). The IPv6 address space MUST be a global resource, available for FREE. I always say IPv6 is FREEDOM, and following the same rule as in IPv4, it WILL NOT BE. If there is any proposal to delegate the IPv6 address space in some other way, to avoid this situation, I will volunteer to work in that. Regards, Jordi ----- Original Message ----- From: "Joao Luis Silva Damas" To: "Gert Doering" ; "John Fraizer" Cc: "Gert Doering" ; "Francis Dupont" ; "Bob Fink" ; "6BONE List" <6bone@mailman.isi.edu> Sent: Friday, August 23, 2002 5:56 PM Subject: Re: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs > At 9:27 +0200 23/8/02, Gert Doering wrote: > >Hi, > > > >On Thu, Aug 22, 2002 at 07:18:50PM -0400, John Fraizer wrote: > >> >From the ARIN website: > >> > >> "Organizations approved for receiving the standard /35 initial IPv6 > >> allocation will be charged an annual fee of $2,500 (US). For larger > >> amounts of addresses, a fee of $20,000 (US) will be assessed. > > > >So go and tell ARIN that you don't like that. > > > >In RIPE land, this is not the case. You pay annual fees for all services > >altogether (which go up a bit if you have very much IPv4 space, which > >*does* create extra work) and - right now - no extra costs for IPv6. > > True, and the membership fees are purely based on cost recovery for > the services as the RIPE NCC is non-profit organisation. One of the > things that troubles me in Bob proposal is the mention of "minimal > cost", unless that means the usual membership fee of course. > > Joao > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From joao@ripe.net Fri Aug 23 17:48:11 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Fri, 23 Aug 2002 18:48:11 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <08cd01c24ac3$4f547b50$8700000a@consulintel.es> References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> Message-ID: At 18:37 +0200 23/8/02, JORDI PALET MARTINEZ wrote: >Joao, > >I know this is hard to say, but I fully agree with Francis. > >We already had this discussion some time ago (12th September in >Barcelona Task Force meeting). Yes, I remember some "interesting" proposals in that meeting. >One of the ways to promote IPv6 will be getting the address for free >or for a REAL cost. Interesting concept. I never thought of address space as having a price tag. >I'm sure we can look alternative ways to delegate address space not >involving so high memberships. High as in: it is less than the Cisco 2500 in which you want to do the tests? >And I'm ABSOLUTELY convinced it can be DONE with a lower price. I >will prefer to be charged by each of the services provided by the >RIR (that I need to pay nevertheless I use or not), instead of a >single annual fee, with has only two levels. Ok, I think I will leave that one for the members of the RIRs. >That is causing the ISPs making REAL business with the address space >(and I know you can say they charge for the services, but we >can force them to provide this free of charge and charge for OTHER >real services). The IPv6 address space MUST be a global resource, >available for FREE. IPv4 address space is available for free. You pay for the cost of registration, DNS, whois, et,c not for the addresses. >I always say IPv6 is FREEDOM, and following the same rule as in >IPv4, it WILL NOT BE. Not quite sure what you mean by this. >If there is any proposal to delegate the IPv6 address space in some >other way, to avoid this situation, I will volunteer to work in >that. I beg your pardon. Have you attended the lir-wg at the RIPE meetings recently (or read the mailing list)? Joao From JORDI PALET MARTINEZ" <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> Message-ID: <094201c24ac7$97349c30$8700000a@consulintel.es> Joao, My point is competition. Next is an example, don't take me wrong. We are, in the case of Europe, mandated to get our prefix allocated by RIPE. That means that I'm subjected, I like it or not, to the RIPE rules, that not always are good for ALL the people. For example, may be I don't need some of the services, but I need to pay the same fee as a bigger ISP. My idea is to separate all these services from the REAL cost of the address delegation. For example, consider a world where you have more competition and you can pay for this "delegation service" (not the address space) from a number of entities, like in the case of a domain registration. I'm sure the competition will keep the price down ! About the freedom, having address space for everyone means freedom, not subjected to NATs, and so on. But if this is not really going to happen, the situation will be the same as today with IPv4. May be is a too much personal view ;-) Regards, Jordi PS: I don't follow all the RIPE mailing list, not enough time for doing all what I will like to do ! If there is anything specific on this subject, can you point me to the message thread, please ? ----- Original Message ----- From: "Joao Luis Silva Damas" To: "JORDI PALET MARTINEZ" ; <6bone@ISI.EDU> Sent: Friday, August 23, 2002 6:48 PM Subject: Re: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs > At 18:37 +0200 23/8/02, JORDI PALET MARTINEZ wrote: > >Joao, > > > >I know this is hard to say, but I fully agree with Francis. > > > >We already had this discussion some time ago (12th September in > >Barcelona Task Force meeting). > > Yes, I remember some "interesting" proposals in that meeting. > > >One of the ways to promote IPv6 will be getting the address for free > >or for a REAL cost. > > Interesting concept. I never thought of address space as having a price tag. > > >I'm sure we can look alternative ways to delegate address space not > >involving so high memberships. > > High as in: it is less than the Cisco 2500 in which you want to do the tests? > > >And I'm ABSOLUTELY convinced it can be DONE with a lower price. I > >will prefer to be charged by each of the services provided by the > >RIR (that I need to pay nevertheless I use or not), instead of a > >single annual fee, with has only two levels. > > Ok, I think I will leave that one for the members of the RIRs. > > >That is causing the ISPs making REAL business with the address space > >(and I know you can say they charge for the services, but we > >can force them to provide this free of charge and charge for OTHER > >real services). The IPv6 address space MUST be a global resource, > >available for FREE. > > IPv4 address space is available for free. You pay for the cost of > registration, DNS, whois, et,c not for the addresses. > > >I always say IPv6 is FREEDOM, and following the same rule as in > >IPv4, it WILL NOT BE. > > Not quite sure what you mean by this. > > >If there is any proposal to delegate the IPv6 address space in some > >other way, to avoid this situation, I will volunteer to work in > >that. > > I beg your pardon. Have you attended the lir-wg at the RIPE meetings > recently (or read the mailing list)? > > Joao > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From Francis.Dupont@enst-bretagne.fr Fri Aug 23 18:16:22 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Fri, 23 Aug 2002 19:16:22 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: Your message of Fri, 23 Aug 2002 09:23:43 PDT. <5.1.0.14.0.20020823091857.00b5b5f8@imap2.es.net> Message-ID: <200208231716.g7NHGM6o012219@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: >>> "Organizations approved for receiving the standard /35 initial IPv6 >>> allocation will be charged an annual fee of $2,500 (US). For larger >>> amounts of addresses, a fee of $20,000 (US) will be assessed. => unfortunately this is not true (or still false). >True, and the membership fees are purely based on cost recovery for the >services as the RIPE NCC is non-profit organisation. One of the things >that troubles me in Bob proposal is the mention of "minimal cost", unless >that means the usual membership fee of course. It means keeping the cost low to reflect actual cost of the service provided, which for the 6bone would be less than normal IPv4 allocation activity. However, the fee would have to be specific to the RIR as all the RIRs have their different rules/policies/procedures/culture/... => I believe you (Bob and Joao) are not talking about the same thing and we (6bone community) shall fall into the "low fee" problem if we agree to apply the transfer proposal. BTW the enterprise/small LIR fees at 1800 euros per year (far more than for a DNS entry for instance, i.e., far too much for the 6bone community). Regards Francis.Dupont@enst-bretagne.fr From Francis.Dupont@enst-bretagne.fr Fri Aug 23 18:22:44 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Fri, 23 Aug 2002 19:22:44 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: Your message of Fri, 23 Aug 2002 18:37:01 +0200. <08cd01c24ac3$4f547b50$8700000a@consulintel.es> Message-ID: <200208231722.g7NHMi6o012235@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: One of the ways to promote IPv6 will be getting the address for free or for a REAL cost. => but we still need a good solution to the tiny fee issue: to reverse the common "if this is free then this will cost nothing" statement, to collect tiny fees is so expensive that a large part of fees is for the collecting process. instead of a single annual fee, with has only two levels. => three if member == LIR. Thanks Francis.Dupont@enst-bretagne.fr From joao@ripe.net Fri Aug 23 18:26:12 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Fri, 23 Aug 2002 19:26:12 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <094201c24ac7$97349c30$8700000a@consulintel.es> References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <094201c24ac7$97349c30$8700000a@consulintel.es> Message-ID: Jordi, At 19:07 +0200 23/8/02, JORDI PALET MARTINEZ wrote: ... >About the freedom, having address space for everyone means freedom, >not subjected to NATs, and so on. Hey, I agree with this! :-) ... >Regards, >Jordi > >PS: I don't follow all the RIPE mailing list, not enough time for >doing all what I will like to do ! If there is anything specific >on this subject, can you point me to the message thread, please ? Oh, just the discussion out in the open about the IPv6 allocation policy. I think agreement was reached in May, so pick that thread from the archives. It went on for some time. From nicolas.deffayet@ndsoftware.net Fri Aug 23 18:44:32 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 23 Aug 2002 19:44:32 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <08cd01c24ac3$4f547b50$8700000a@consulintel.es> References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> Message-ID: <1030124672.672.236.camel@wks1.fr.corp.ndsoftware.com> On Fri, 2002-08-23 at 18:37, JORDI PALET MARTINEZ wrote: > One of the ways to promote IPv6 will be getting the address for free or for a REAL cost. Agree. > I'm sure we can look alternative ways to delegate address space not involving so high memberships. > > And I'm ABSOLUTELY convinced it can be DONE with a lower price. I will prefer to be charged by each of the services provided by the > RIR (that I need to pay nevertheless I use or not), instead of a single annual fee, with has only two levels. It can be done with NO charges. > That is causing the ISPs making REAL business with the address space (and I know you can say they charge for the services, but we > can force them to provide this free of charge and charge for OTHER real services). The IPv6 address space MUST be a global resource, > available for FREE. > I always say IPv6 is FREEDOM, and following the same rule as in IPv4, it WILL NOT BE. > I think that it can be a good idea to not allow the business of IPs. Best Regards, Nicolas DEFFAYET From joao@ripe.net Fri Aug 23 18:50:58 2002 From: joao@ripe.net (Joao Luis Silva Damas) Date: Fri, 23 Aug 2002 19:50:58 +0200 Subject: [6bone] Where I stand In-Reply-To: References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <094201c24ac7$97349c30$8700000a@consulintel.es> Message-ID: Just to clarify my position: I *DO* want IPv6 to suceed. I *DO* believe the RIR communities, with the RIRs as secretariats, are the way to go in address allocation. The coordination performed in this context over the last years has proved this beyond any doubt IPv6 is deployable right now. While our last exchange of mails was going on I have been using my time to put together a name server at 2001:610:240::193:0:0:193. Some of you will notice the coincidence of some parts of this address with other nameserver's address. This is just a quick provisional thing (for today, as it is getting late here in Europe). This stuff is running on an Apple Xserve running stock Mac OS X 10.2 using bind 9.2.1. IPv6 is deployable. have a good night Joao From randy@psg.com Fri Aug 23 18:56:39 2002 From: randy@psg.com (Randy Bush) Date: Fri, 23 Aug 2002 10:56:39 -0700 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <1030124672.672.236.camel@wks1.fr.corp.ndsoftware.com> Message-ID: > One of the ways to promote IPv6 will be getting the address for > free or for a REAL cost. i think i understand now. the 6bone is a marketing network too, and address space should be given for r&e and marketing efforts? randy From bmanning@ISI.EDU Fri Aug 23 19:09:09 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Fri, 23 Aug 2002 11:09:09 -0700 (PDT) Subject: [6bone] Where I stand In-Reply-To: from Joao Luis Silva Damas at "Aug 23, 2 07:50:58 pm" Message-ID: <200208231809.g7NI99H05778@boreas.isi.edu> % While our last exchange of mails was going on I have been using my % time to put together a name server at 2001:610:240::193:0:0:193. Some % of you will notice the coincidence of some parts of this address with % other nameserver's address. % % This is just a quick provisional thing (for today, as it is getting % late here in Europe). This stuff is running on an Apple Xserve % running stock Mac OS X 10.2 using bind 9.2.1. Yeah! will this be a functional replacement for ::ffff:193.0.0.193 (for the latecomers, the above may have been the first nameserver with a published v6 address (yes, its a mapped address and we know now that sticking mapped addresses in the DNS is a recipe for disaster)) I've been waiting for a bit over a year for RIPE to put a v6 server back online. Thanks again. -- --bill From nicolas.deffayet@ndsoftware.net Fri Aug 23 19:13:11 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 23 Aug 2002 20:13:11 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> Message-ID: <1030126391.674.263.camel@wks1.fr.corp.ndsoftware.com> On Fri, 2002-08-23 at 18:48, Joao Luis Silva Damas wrote: > At 18:37 +0200 23/8/02, JORDI PALET MARTINEZ wrote: > > >I'm sure we can look alternative ways to delegate address space not > >involving so high memberships. > > High as in: it is less than the Cisco 2500 in which you want to do the tests? I know many LIR who use only PC with Zebra... Be LIR is not easy with the hight setup fees the first year. Don't forgot that the first year a ISP have a lot of setup fees (IP transit, hosting,...) I think that RIPE can do this: 6bone EUR 50 / year - Start-up fee EUR 50 Very small EUR 1000 / year - Start-up fee EUR 1000 Small EUR 1800 / year - Start-up fee EUR 1800 Medium EUR 2500 / year - Start-up fee EUR 2500 Large EUR 3400 / year - Start-up fee EUR 3400 I think that the fee of EUR 1000 / year for be LIR is good for a very small ISP or non-profit organization. Best Regards, Nicolas DEFFAYET From JORDI PALET MARTINEZ" <20020823092729.L27015@Space.Net><08cd01c24ac3$4f547b50$8700000a@consulintel.es><1030124672.672.236.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <0a7701c24ad1$e4702410$8700000a@consulintel.es> It was not my point. I'm talking in general about the RIRs, not 6Bone. The discussion started because the transfer of 6bone address to RIRs, and in principle I'm in favor of that, but only if the correct strategy for the right IPv6 deployment is adopted by the RIRs ;-) Regards, Jordi ----- Original Message ----- From: "Randy Bush" To: "JORDI PALET MARTINEZ" Cc: <6bone@ISI.EDU> Sent: Friday, August 23, 2002 7:56 PM Subject: Re: [6bone] proposal for transfer of 6bone address managementresponsibilities to RIRs > > One of the ways to promote IPv6 will be getting the address for > > free or for a REAL cost. > > i think i understand now. the 6bone is a marketing network too, > and address space should be given for r&e and marketing efforts? > > randy > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From randy@psg.com Fri Aug 23 20:01:38 2002 From: randy@psg.com (Randy Bush) Date: Fri, 23 Aug 2002 12:01:38 -0700 Subject: [6bone] proposal for transfer of 6bone address managementresponsibilities to RIRs References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <1030124672.672.236.camel@wks1.fr.corp.ndsoftware.com> <0a7701c24ad1$e4702410$8700000a@consulintel.es> Message-ID: >> i think i understand now. the 6bone is a marketing network too, >> and address space should be given for r&e and marketing efforts? > The discussion started because the transfer of 6bone address to RIRs, and in > principle I'm in favor of that, but only if the correct strategy for the > right IPv6 deployment is adopted by the RIRs ;-) ahh, now i understand even better. the 6bone is for r&e, marketing, and internet politics to fix everything we don't like about everything. a noble set of goals for just having more address bits. i am impressed but not optimistic. randy From gert@space.net Fri Aug 23 20:22:58 2002 From: gert@space.net (Gert Doering) Date: Fri, 23 Aug 2002 21:22:58 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <08cd01c24ac3$4f547b50$8700000a@consulintel.es>; from jordi.palet@consulintel.es on Fri, Aug 23, 2002 at 06:37:01PM +0200 References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> Message-ID: <20020823212258.E27015@Space.Net> hi, On Fri, Aug 23, 2002 at 06:37:01PM +0200, JORDI PALET MARTINEZ wrote: > IPv6 address space MUST be a global resource, > available for FREE. While this is a nice idea - from the global *routing* perspective, you do certainly *NOT* want "everybody and their friends" to be able to get their own globally visible address block. Right now, it's important to push IPv6, but in the long run, I *want* restrictions on "who can get IPv6 blocks from the RIR". > I always say IPv6 is FREEDOM, and following the same rule as in IPv4, > it WILL NOT BE. There are certain technical constraints that you can't argue away. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46611 (45583) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pekkas@netcore.fi Fri Aug 23 20:44:15 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Fri, 23 Aug 2002 22:44:15 +0300 (EEST) Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <1030126391.674.263.camel@wks1.fr.corp.ndsoftware.com> Message-ID: I think it would be interesting to make an analysis: 1) how many 6bone pTLA's are already members of ARIN/RIPE/APNIC 1.a) already have a production allocation, or 1.b) would be eligible for production allocation by the new rules So is this problem only with a few pTLA's which really shouldn't be pTLA's in the first place or a real problem. On 23 Aug 2002, Nicolas DEFFAYET wrote: > On Fri, 2002-08-23 at 18:48, Joao Luis Silva Damas wrote: > > At 18:37 +0200 23/8/02, JORDI PALET MARTINEZ wrote: > > > > >I'm sure we can look alternative ways to delegate address space not > > >involving so high memberships. > > > > High as in: it is less than the Cisco 2500 in which you want to do the tests? > > I know many LIR who use only PC with Zebra... > > Be LIR is not easy with the hight setup fees the first year. > Don't forgot that the first year a ISP have a lot of setup fees (IP > transit, hosting,...) > > I think that RIPE can do this: > > 6bone EUR 50 / year - Start-up fee EUR 50 > Very small EUR 1000 / year - Start-up fee EUR 1000 > Small EUR 1800 / year - Start-up fee EUR 1800 > Medium EUR 2500 / year - Start-up fee EUR 2500 > Large EUR 3400 / year - Start-up fee EUR 3400 > > > I think that the fee of EUR 1000 / year for be LIR is good for a very > small ISP or non-profit organization. > > Best Regards, > > Nicolas DEFFAYET > > _______________________________________________ > 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 czmok@gatel.net Fri Aug 23 21:03:56 2002 From: czmok@gatel.net (Jan Czmok) Date: Fri, 23 Aug 2002 22:03:56 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <1030124672.672.236.camel@wks1.fr.corp.ndsoftware.com> References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <1030124672.672.236.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20020823200356.GA3857@gollum.gatel.net> Nicolas DEFFAYET (nicolas.deffayet@ndsoftware.net) wrote: > On Fri, 2002-08-23 at 18:37, JORDI PALET MARTINEZ wrote: > > > One of the ways to promote IPv6 will be getting the address for free or for a REAL cost. > > Agree. Also i strongly agree. The original idea from RIPE (the "old" requirements for getting RIR IPv6 Allocations) was really good. To outline it: to get real address space IPV6-blocks , you have to have 6bone address space first and also a decent amount of time. Some slight modification of this applied with the current policy WOULD be better than the _now active_ policy. (but that's my opinion, anyway). Another point on the whole discussion about productive systems + r&d (e.g. 6bone). Why not follow up on the following idea: - setup production networks - interconnect them to 6bone, but set the local-pref for the routes lower than the production addresses. - apply strong filter towards the 6bone peers. I am using this scenario at my ISP and i didn't have a single problem with it. > > And I'm ABSOLUTELY convinced it can be DONE with a lower price. I will prefer to be charged by each of the services provided by the > > RIR (that I need to pay nevertheless I use or not), instead of a single annual fee, with has only two levels. > > It can be done with NO charges. NO charges is too low. either raise the cost for ipv4 and lower these for ipv6. Money must be involved - otherwise it would not work, because otherwise there is no real _need_ (from the view of the big company bozos) to change addresses or ipv4 to ipv6. > > can force them to provide this free of charge and charge for OTHER real services). The IPv6 address space MUST be a global resource, agree on this. > > I always say IPv6 is FREEDOM, and following the same rule as in IPv4, it WILL NOT BE. Well - the market will regulate. But we should be aware that the market may go in other directions we want to. We ("the ISPS") are mainly having it in our own hands. > I think that it can be a good idea to not allow the business of IPs. Also Agree on this ! --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de From JORDI PALET MARTINEZ" <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <20020823212258.E27015@Space.Net> Message-ID: <0b1101c24ae4$0fdc4d10$8700000a@consulintel.es> Hi Gert, No this wasn't my point. Sorry not to make it clear before. I'm not talking about a "regular" individual, as they will get it from the ISP, and the market is plenty of a good competition to regulate it. Nevertheless, this is IPv4 world, and I'm not quite sure if we will get the same case with IPv6 ;-) I'm talking about an SME or corporate, that may not need to work with an ISP, because they can need direct connectivity to a Telco. They may qualify for a prefix, but they don't want to become a LIR, why they don't have the right to get a prefix. The case is difficult to see now, because the IPv4 restrictions, but I'm sure it will happen more and more with IPv6. Regards, Jordi ----- Original Message ----- From: "Gert Doering" To: "JORDI PALET MARTINEZ" Cc: <6bone@ISI.EDU> Sent: Friday, August 23, 2002 9:22 PM Subject: Re: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs > hi, > > On Fri, Aug 23, 2002 at 06:37:01PM +0200, JORDI PALET MARTINEZ wrote: > > IPv6 address space MUST be a global resource, > > available for FREE. > > While this is a nice idea - from the global *routing* perspective, you do > certainly *NOT* want "everybody and their friends" to be able to get > their own globally visible address block. > > Right now, it's important to push IPv6, but in the long run, I *want* > restrictions on "who can get IPv6 blocks from the RIR". > > > I always say IPv6 is FREEDOM, and following the same rule as in IPv4, > > it WILL NOT BE. > > There are certain technical constraints that you can't argue away. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 46611 (45583) > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > *********************************************************** Madrid 2002 Global IPv6 Summit See all the documents on line at: www.ipv6-es.com From tjc@ecs.soton.ac.uk Fri Aug 23 21:28:44 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Fri, 23 Aug 2002 21:28:44 +0100 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <20020823212258.E27015@Space.Net> References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <20020823212258.E27015@Space.Net> Message-ID: <20020823202844.GD11149@login.ecs.soton.ac.uk> On Fri, Aug 23, 2002 at 09:22:58PM +0200, Gert Doering wrote: > > While this is a nice idea - from the global *routing* perspective, you do > certainly *NOT* want "everybody and their friends" to be able to get > their own globally visible address block. > > Right now, it's important to push IPv6, but in the long run, I *want* > restrictions on "who can get IPv6 blocks from the RIR". I think this is true. Another question is what the smaller ISPs and end usrs end up paying, at the bottom of the food chain. At present a static IPv4 address for DSL can be of the order of 15 Euros, for those who don't want to use DDNS. What price a static IPv6 /48 prefix to the home? Tim From gert@space.net Fri Aug 23 21:40:59 2002 From: gert@space.net (Gert Doering) Date: Fri, 23 Aug 2002 22:40:59 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <20020823200356.GA3857@gollum.gatel.net>; from czmok@gatel.net on Fri, Aug 23, 2002 at 10:03:56PM +0200 References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <1030124672.672.236.camel@wks1.fr.corp.ndsoftware.com> <20020823200356.GA3857@gollum.gatel.net> Message-ID: <20020823224059.H27015@Space.Net> Hi, On Fri, Aug 23, 2002 at 10:03:56PM +0200, Jan Czmok wrote: > Why not follow up on the following idea: > > - setup production networks > - interconnect them to 6bone, but set the local-pref for the > routes lower than the production addresses. > - apply strong filter towards the 6bone peers. > > I am using this scenario at my ISP and i didn't have a single problem > with it. So you were not affected by the lingering /35s that stayed around after people withdrew them and announced their /32? Amazing, will have to look into this more closely. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46611 (45583) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From randy@psg.com Fri Aug 23 21:45:55 2002 From: randy@psg.com (Randy Bush) Date: Fri, 23 Aug 2002 13:45:55 -0700 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <20020823212258.E27015@Space.Net> <0b1101c24ae4$0fdc4d10$8700000a@consulintel.es> Message-ID: i thought the 6bone was an ietf experimental network to test v6. i did not think it was an ietf effort to tell rirs, telcos, isps, enterprises, end users, etc. how to run their business or lives. that way lies lawyers. randy From nicolas.deffayet@ndsoftware.net Fri Aug 23 22:07:38 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 23 Aug 2002 23:07:38 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <20020823202844.GD11149@login.ecs.soton.ac.uk> References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <20020823212258.E27015@Space.Net> <20020823202844.GD11149@login.ecs.soton.ac.uk> Message-ID: <1030136858.671.274.camel@wks1.fr.corp.ndsoftware.com> On Fri, 2002-08-23 at 22:28, Tim Chown wrote: > On Fri, Aug 23, 2002 at 09:22:58PM +0200, Gert Doering wrote: > > > > While this is a nice idea - from the global *routing* perspective, you do > > certainly *NOT* want "everybody and their friends" to be able to get > > their own globally visible address block. > > > > Right now, it's important to push IPv6, but in the long run, I *want* > > restrictions on "who can get IPv6 blocks from the RIR". > > I think this is true. Another question is what the smaller ISPs and end > usrs end up paying, at the bottom of the food chain. At present a static > IPv4 address for DSL can be of the order of 15 Euros, for those who don't > want to use DDNS. What price a static IPv6 /48 prefix to the home? > At home i have a DSL connexion, with it i have a free static IPv4 address and a free IPv6 /48.... Best Regards, Nicolas DEFFAYET From tvo@EnterZone.Net Fri Aug 23 23:43:04 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Fri, 23 Aug 2002 18:43:04 -0400 (EDT) Subject: [6bone] separating IPv6 experimental from production traffic In-Reply-To: Message-ID: On Fri, 23 Aug 2002, Pekka Savola wrote: > > Of course. But if you have *enough* peerings, you'll be able to reach > > most networks in a maximum of 2 hops - and if you then apply some > > MED fiddling to mark "slow" tunnels, you can achieve pretty good results. > > This leads to an "arms race"; everyone will need to get even more tunnels, > leading to even tighter spaghetti. No. People who want tighter peering will seek it. People who don't will settle for what they have. High peer counts does NOT mean bad connectivity. Peering with some joker on a 56K modem who then leaks a full table to you (and you accept it) leads to bad connectivity. > > I don't think having to do manual fiddling should be necessary, but that's > life I suppose. I guess you're not the v4 peering person for your network then. In v4 land, manual tuning is rather commonplace. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From chuck+6bone@snew.com Sat Aug 24 01:29:58 2002 From: chuck+6bone@snew.com (Chuck Yerkes) Date: Fri, 23 Aug 2002 17:29:58 -0700 Subject: [6bone] tighter mesh and accelerating IPv6 In-Reply-To: ; from tvo@EnterZone.Net on Fri, Aug 23, 2002 at 06:43:04PM -0400 References: Message-ID: <20020823172958.L18281@snew.com> Quoting John Fraizer (tvo@EnterZone.Net): > On Fri, 23 Aug 2002, Pekka Savola wrote: > > > Of course. But if you have *enough* peerings, you'll be able to reach > > > most networks in a maximum of 2 hops - and if you then apply some > > > MED fiddling to mark "slow" tunnels, you can achieve pretty good results. > > > > This leads to an "arms race"; everyone will need to get even more tunnels, > > leading to even tighter spaghetti. > > No. People who want tighter peering will seek it. People who don't will > settle for what they have. High peer counts does NOT mean bad > connectivity. Peering with some joker on a 56K modem who then leaks a > full table to you (and you accept it) leads to bad connectivity. "People." You mean "people" like me who want my rather large telco monopoly ISP to offer IPv6 (or hell, consistent service). No, "people" do not have a lot of influence. ISPs and large business do. When Ford requires IPv6 access to their partners and contractors, ISPs will leap to fill that need. When PacBell starts offering IPv6 on their backbone, customers can start to ask for it. The customers aren't going to cause PBI to start offering it. Who else? When SMS/WAP2/PalmTop-based Web providers start doing direct connections via IPv6 and there's a clear advantage to talking to these folks via IPv6, we'll start to see it deployed quicker. If we see a disruptive technology that demands it, it will get here quicker. My thoughts are that cell phones and their palmtop computer equivalents may be that. Verizon isn't going to give out 2,000,000 IP addresses. NATTING and gatewaying become a burden. Also IP aware appliances jump in - set top boxes, etc. Until then, it will come out slowly. Trading floors will start to roll it out on their backbones and maybe some segments, cause it's a little quicker and it offers advantages they want. It will appear is small isolated spots. Hey! If my backbone has it and the folks I'm subcontracting web development to also do, then we can join our nets together. In the non-US part of the world, I see adoption happening more quickly because there's more demand. There's a LOT of network space in the US. There's a LOT less in other parts of the world (and a lot more need in the next 10 years). It could all change if the big backbones started offering it native. I think they are busy trying to not to disappear, here in the US technology nuclear winter. From tvo@EnterZone.Net Sat Aug 24 02:18:02 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Fri, 23 Aug 2002 21:18:02 -0400 (EDT) Subject: [6bone] tighter mesh and accelerating IPv6 In-Reply-To: <20020823172958.L18281@snew.com> Message-ID: On Fri, 23 Aug 2002, Chuck Yerkes wrote: > Quoting John Fraizer (tvo@EnterZone.Net): > > On Fri, 23 Aug 2002, Pekka Savola wrote: > > > > Of course. But if you have *enough* peerings, you'll be able to reach > > > > most networks in a maximum of 2 hops - and if you then apply some > > > > MED fiddling to mark "slow" tunnels, you can achieve pretty good results. > > > > > > This leads to an "arms race"; everyone will need to get even more tunnels, > > > leading to even tighter spaghetti. > > > > No. People who want tighter peering will seek it. People who don't will > > settle for what they have. High peer counts does NOT mean bad > > connectivity. Peering with some joker on a 56K modem who then leaks a > > full table to you (and you accept it) leads to bad connectivity. > > "People." > > You mean "people" like me who want my rather large telco monopoly > ISP to offer IPv6 (or hell, consistent service). No, "people" do > not have a lot of influence. ISPs and large business do. When > Ford requires IPv6 access to their partners and contractors, ISPs > will leap to fill that need. When PacBell starts offering IPv6 on > their backbone, customers can start to ask for it. The customers > aren't going to cause PBI to start offering it. No. I mean "people" like those in charge of peering for ANY site. If a site wants to have tight peering (tunnels or native), they will seek it. Otherwise, they will settle for the peers (or static routing) that they have. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc | Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation | From Christopher.Malayter@tdstelecom.com Sat Aug 24 07:15:11 2002 From: Christopher.Malayter@tdstelecom.com (Malayter, Christopher) Date: Sat, 24 Aug 2002 01:15:11 -0500 Subject: [6bone] tighter mesh and accelerating IPv6 Message-ID: <7F14AEA6809DD511BA1B00508BBE584E01800220@msg017.teldta.com> >No. I mean "people" like those in charge of peering for ANY site. If a >site wants to have tight peering (tunnels or native), they will seek >it. Otherwise, they will settle for the peers (or static routing) that >they have. Many of us try to gain closer peering relationships with other carriers. Even in relation to ipv6 peering with larger Tier2 providers is next to impossible. Most of them have prohibitive barriers keeping smaller carriers, such as the one that employes me, from peering with them. It would be ideal if everyone could peer with everyone, but then, why would the Tier1's need to exist? :) -Chris --- 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 gert@space.net Sat Aug 24 08:23:30 2002 From: gert@space.net (Gert Doering) Date: Sat, 24 Aug 2002 09:23:30 +0200 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <20020823202844.GD11149@login.ecs.soton.ac.uk>; from tjc@ecs.soton.ac.uk on Fri, Aug 23, 2002 at 09:28:44PM +0100 References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <20020823212258.E27015@Space.Net> <20020823202844.GD11149@login.ecs.soton.ac.uk> Message-ID: <20020824092329.K27015@Space.Net> Hi, On Fri, Aug 23, 2002 at 09:28:44PM +0100, Tim Chown wrote: > On Fri, Aug 23, 2002 at 09:22:58PM +0200, Gert Doering wrote: > > While this is a nice idea - from the global *routing* perspective, you do > > certainly *NOT* want "everybody and their friends" to be able to get > > their own globally visible address block. > > > > Right now, it's important to push IPv6, but in the long run, I *want* > > restrictions on "who can get IPv6 blocks from the RIR". > > I think this is true. Another question is what the smaller ISPs and end > usrs end up paying, at the bottom of the food chain. At present a static > IPv4 address for DSL can be of the order of 15 Euros, for those who don't > want to use DDNS. What price a static IPv6 /48 prefix to the home? At least over here, the pricing for static IPv4 addresses does *not* come from "the small ISP has to pay the price to the larger ISP" (our customers are *not* billed by the number of IP addresses, and I know that other LIRs do it the same way). The extra price comes from distinguishing "ultra-low commodity products" and "product that requires some customer-specific configuration" - the latter should be less effort for IPv6... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46611 (45583) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From tjc@ecs.soton.ac.uk Sat Aug 24 15:57:42 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Sat, 24 Aug 2002 15:57:42 +0100 Subject: [6bone] proposal for transfer of 6bone address management responsibilities to RIRs In-Reply-To: <20020824092329.K27015@Space.Net> References: <20020822231428.I27015@Space.Net> <20020823092729.L27015@Space.Net> <08cd01c24ac3$4f547b50$8700000a@consulintel.es> <20020823212258.E27015@Space.Net> <20020823202844.GD11149@login.ecs.soton.ac.uk> <20020824092329.K27015@Space.Net> Message-ID: <20020824145742.GA18874@login.ecs.soton.ac.uk> On Sat, Aug 24, 2002 at 09:23:30AM +0200, Gert Doering wrote: > Hi, > > The extra price comes from distinguishing "ultra-low commodity products" > and "product that requires some customer-specific configuration" - the > latter should be less effort for IPv6... Agreed, the question is single static IPv4 IP cost vs static /48 assignment cost. Both have "some customer-specific configuration". Also, I'm not sure the prefix delegation mechanisms have been fully agreed yet? (it was being discussed in IETF in March, but I haven't tracked this specific topic since then). If you compare /48's (the future :) with single IPv4 addresses allocated by ISPs now, an ISP getting a /32 is going to have (if you ignore the HD ratio) 65K customer prefixes, which in essence lets them serve as many customers as a provider with (in old money) a Class B v4 allocation. It's not a *lot* of space so while the provider can go back to get the /32 made bigger, they may be more tempted to assign the /48's from a pool. The difference being with v6 it is much easier to run services into the customer network, so the demand for static addresses (or a very scalable DDNS :) would appear higher. If everyone offers it, I guess there won't be a premium. Tim From pasky@pasky.ji.cz Sun Aug 25 20:42:26 2002 From: pasky@pasky.ji.cz (Petr Baudis) Date: Sun, 25 Aug 2002 21:42:26 +0200 Subject: [6bone] Re: separating IPv6 experimental from production traffic In-Reply-To: <20020821134125.GG15554@rvdp.org> References: <20020821134125.GG15554@rvdp.org> Message-ID: <20020825194226.GN4719@pasky.ji.cz> Dear diary, on Wed, Aug 21, 2002 at 03:41:25PM CEST, I got a letter, where Ronald van der Pol told me, that... > As you know I am increasingly worried about the quality of IPv6 > transport. I have far more problems reaching IPv6 destinations than > I have reaching IPv4 destinations. This is not because I have a > bad provider, but because my traffic is blackholed somewhere far > away in the 'Net. ..snip.. > The current situation is that we have one network, the 6bone > (although it is hard to define what it is exactly). The current > 6bone is used for all kinds of experiments (even with old or alpha > routing software) and is used as a playground for people new to > IPv6 (no problem, it's very good, as long as it doesn't interfere > with my production traffic). > > I think we should work towards separating experiment and playing > from production. Experimenting needs to be done, but it should > have minimal impact on production. This is what most :-) do in the > IPv4 world. However, I do not propose to disconnect one from the > other. On the contrary, there should be good connectivity between > them. But I think we should stop the current situation where > production traffic is routed *via* an experimental network. What I > want is IPv6 transport that is treated similar to IPv4 transport. > > In the current situation this is hard to accomplish by individual > ISPs because of the tunnels all over the world and transit to > everyone. So I guess we first have to reach concensus whether we > want this separation or not. As I already expressed few times before, let this be a natural process. Any administrative decision and forced moves and peering terminations etc won't be followed by the whole community anyway and they will only create big mess. As I understand term "productional", it's basically about money ;-) - so, if you want it stable and.. hmh, productional, why do you do transit through 6bone people? Do it through productional networks and you should do fine - do your productional peers do transit through 6bone people? Ask them not to - if they will refuse and their 6bone peers are unstable, they probably don't care about stability and production a lot - are they right people to peer with? Or, can't you filter 6bone prefix propagations from them if they let unstable 6bone people do transit for them? Are people with RIR ("productional") allocations making you problems? Then efforts to separate 6bone from productional networks are irrelevant. If your peers will hear your calling and do same as you, you will reach technical and *effective* consensus, and the real IPv6 community "voted" about solution of this problem. If they won't hear you, they probably don't care about IPv6 much enough yet, and your efforts are useless yet anyway. > At this stage I am only asking for separation of experiment from > production. I am not saying anything yet about what prefixes to > use where. I am also not saying yet what the experimental network > (the 6bone) should be used for. I guess all I am saying is: don't > use the 6bone for production traffic. In my view in the new situation > a site can have two kinds of peerings: 6bone peering or production > peering. What should be prevented is traffic coming from the > production network, going via the experimental network to a production > destination. Sure, if you want separation of productional and experimental network, first thing you probably want to do is separation of allocations (pushing experimental allocations to 3ffe::/16 and productional allocations out of that), so that you can *identify* subjects you want to separate from ;-). -- Petr "Pasky" Baudis * ELinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI occassional hacker . > Girls are like internet domain names, the ones I like are already taken. Well, you can still get one from a strange country :-P . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From gert@space.net Tue Aug 27 13:42:49 2002 From: gert@space.net (Gert Doering) Date: Tue, 27 Aug 2002 14:42:49 +0200 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <1028391612.15372.132.camel@wks1-1.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Sat, Aug 03, 2002 at 06:20:12PM +0200 References: <017401c23ab4$539eb730$6ef696d3@huaning> <1028391612.15372.132.camel@wks1-1.corp.ndsoftware.com> Message-ID: <20020827144249.N27015@Space.Net> Hi, On Sat, Aug 03, 2002 at 06:20:12PM +0200, Nicolas DEFFAYET wrote: > ipv6 prefix-list ipv6-ebgp-full-in permit 3ffe::/18 ge 24 le 24 > ipv6 prefix-list ipv6-ebgp-full-in permit 3ffe:4000::/18 ge 32 le 32 > ipv6 prefix-list ipv6-ebgp-full-in permit 3ffe:8000::/22 ge 28 le 28 > ipv6 prefix-list ipv6-ebgp-full-in permit 2001::/16 ge 29 le 35 > ipv6 prefix-list ipv6-ebgp-full-in permit 2002::/16 > ipv6 prefix-list ipv6-ebgp-full-in deny 0::/0 > > You can deny your prefix too. Just want to add a detail here - your "deny 0::0/0" line is actually only denying an exact match on the default route. All other routes are denied implicitely (by falling off the end of the list). To deny everything explicitely, you can use: ipv6 prefix-list ipv6-ebgp-full-in deny 0::/0 le 128 I've also started collecting example filter lists that people could use as a starting point on http://www.space.net/~gert/RIPE/ipv6-filters.html - if you see anything that's blatantly wrong, or just missing, please point it out to me. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46611 (45583) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From nicolas.deffayet@ndsoftware.net Tue Aug 27 15:25:57 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 27 Aug 2002 16:25:57 +0200 Subject: [6bone] In the summer time, we got cleaning to do... Where is UUNET? In-Reply-To: <20020827144249.N27015@Space.Net> References: <017401c23ab4$539eb730$6ef696d3@huaning> <1028391612.15372.132.camel@wks1-1.corp.ndsoftware.com> <20020827144249.N27015@Space.Net> Message-ID: <1030458357.677.411.camel@wks1.fr.corp.ndsoftware.com> On Tue, 2002-08-27 at 14:42, Gert Doering wrote: Hi, > On Sat, Aug 03, 2002 at 06:20:12PM +0200, Nicolas DEFFAYET wrote: > > ipv6 prefix-list ipv6-ebgp-full-in permit 3ffe::/18 ge 24 le 24 > > ipv6 prefix-list ipv6-ebgp-full-in permit 3ffe:4000::/18 ge 32 le 32 > > ipv6 prefix-list ipv6-ebgp-full-in permit 3ffe:8000::/22 ge 28 le 28 > > ipv6 prefix-list ipv6-ebgp-full-in permit 2001::/16 ge 29 le 35 > > ipv6 prefix-list ipv6-ebgp-full-in permit 2002::/16 > > ipv6 prefix-list ipv6-ebgp-full-in deny 0::/0 > > > > You can deny your prefix too. > > Just want to add a detail here - your "deny 0::0/0" line is actually only > denying an exact match on the default route. All other routes are denied > implicitely (by falling off the end of the list). > > To deny everything explicitely, you can use: > > ipv6 prefix-list ipv6-ebgp-full-in deny 0::/0 le 128 Thanks for your remark. I update my prefix-list. > > > I've also started collecting example filter lists that people could use > as a starting point on http://www.space.net/~gert/RIPE/ipv6-filters.html > - if you see anything that's blatantly wrong, or just missing, please > point it out to me. > For Juniper (JunOS): policy-statement ipv6_ebgp { term a { from { protocol bgp; route-filter 3ffe::/18 upto /24; route-filter 3ffe:4000::/18 upto /32; route-filter 3ffe:8000::/22 upto /28; route-filter 2001::/16 upto /35; route-filter 2002::/16 exact; } then { accept; } } term b { then { reject; } } } Please correct my policy-statement if it's wrong. Best Regards, Nicolas DEFFAYET From Raffaele.Dalbenzio@TILAB.COM Wed Aug 28 18:08:37 2002 From: Raffaele.Dalbenzio@TILAB.COM (D'Albenzio Raffaele) Date: Wed, 28 Aug 2002 19:08:37 +0200 Subject: [6bone] pTLA request BUI - review closes 3 September 2002 Message-ID: <6ECEC1E214F2E342814ABB1ED10E79558F5F34@EXC2K01B.cselt.it> Hi all, TILAB allow you to announce our /48 to other peers. The important thing is that these other peers don't announce the /48 assigned to you from TILAB will in the DFZ. Regards, Raffaele D'Albenzio. > > Giacomo Cariello, jwk@bug.it > > TILAB won't allow you to announce your 48 (as no-export) to other BGP > peers? I can understand them not wanting it in the DFZ but, > what you and > your peers do, that remains isolated to the routing tables of > you and your > peers is, IMHO, your business. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== From galania@ipv6.inictel.gob.pe Wed Aug 28 19:54:54 2002 From: galania@ipv6.inictel.gob.pe (Gino Francisco Alania Hurtado) Date: Wed, 28 Aug 2002 13:54:54 -0500 Subject: [6bone] ping6 References: <3D66481B.3090601@ipv6.inictel.gob.pe> <1030117513.679.195.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <3D6D1C7E.2050809@ipv6.inictel.gob.pe> a consultation, use bind 9 and I have the following configuration in my named.conf zone "\[x3FFE82408018/48].ip6.arpa" { type master; file "named.3ffex824"; }; now in/var/named/named.3ffex824 I have this: @ IN NS ipv6.inictel.gob.pe. \[x100102012fffe2a7285/80] IN PTR ipv6.inictel.gob.pe. nslookup > 3ffe:8240:8018:1001:201:2ff:fe2a:7285 Server: 200.60.172.132 Address: 200.60.172.132#53 ** server can't find \[x3FFE824080181001020102FFFE2A7285/128].ip6.arpa: SERVFAIL help me !! :) From itojun@iijlab.net Thu Aug 29 00:02:36 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Thu, 29 Aug 2002 08:02:36 +0900 Subject: [6bone] ping6 In-Reply-To: galania's message of Wed, 28 Aug 2002 13:54:54 EST. <3D6D1C7E.2050809@ipv6.inictel.gob.pe> Message-ID: <20020828230236.A3A3C4B23@coconut.itojun.org> >a consultation, use bind 9 and I have the following configuration in my >named.conf >zone "\[x3FFE82408018/48].ip6.arpa" { you no longer need to use bit string labels. use nibbles (4 bit per label, like "a.b.c.d.1.2.3.4" for ip6.arpa as well, just like ip6.int. itojun From sridhar_narini@hotmail.com Fri Aug 30 09:34:59 2002 From: sridhar_narini@hotmail.com (sridhar narini) Date: Fri, 30 Aug 2002 08:34:59 +0000 Subject: [6bone] unsubsribe Message-ID: >From: itojun@iijlab.net >To: Gino Francisco Alania Hurtado >CC: usagi-users@linux-ipv6.org, 6bone@mailman.isi.edu >Subject: Re: [6bone] ping6 Date: Thu, 29 Aug 2002 08:02:36 +0900 > > >a consultation, use bind 9 and I have the following configuration in my > >named.conf > >zone "\[x3FFE82408018/48].ip6.arpa" { > > you no longer need to use bit string labels. use nibbles (4 bit per > label, like "a.b.c.d.1.2.3.4" for ip6.arpa as well, just like ip6.int. > >itojun >_______________________________________________ >6bone mailing list >6bone@mailman.isi.edu >http://mailman.isi.edu/mailman/listinfo/6bone _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com