From mleber at he.net Sun Mar 1 21:34:51 2009 From: mleber at he.net (Mike Leber) Date: Sun, 01 Mar 2009 12:34:51 -0800 Subject: SWIPnet relay handling most U.S. east coast 6to4 traffic? In-Reply-To: <20090209171801.GA19113@panix.com> References: <20090209171801.GA19113@panix.com> Message-ID: <49AAF16B.60708@he.net> Thor Lancelot Simon wrote: >>From almost anywhere in the Eastern U.S. I test from, traceroutes to > the 6to4 anycast address seem to land at SWIPnet in Amsterdam. This > is because SWIPnet seems to peer with several major U.S. providers in > New York City, giving a short path from many networks in the U.S. to > their Amsterdam relay -- notably, from the networks of the major U.S. > residential cable providers, Time Warner and Cablevision. > > It looks like most public-relay traffic from a large chunk of the U.S. > could stop tromboning through Europe (and wasting SWIPnet's link > bandwidth across the Atlantic) if a 6to4 relay were added to one of > SWIPnet's NYC core routers. Is there any chance of this? We deployed 6to4 relays in the US, Europe, Asia to help fix exactly this problem, and we announce the 192.88.99.0/24 and 2002::/16 anycast prefixes globally at all locations to all peers and customers. However, there's no way for any specific peer to know that any one network announcing 6to4 anycast prefixes does or does not have more than one relay, or that they have a relay thats right there next to them that they should be using for better performance (instead of tromboning). I guess that's a matter of choice between the network that announces the prefixes being used and the network that is listening to those prefixes and using them. Mike. -- +---------------- H U R R I C A N E - E L E C T R I C ----------------+ | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric AS6939 | | mleber at he.net Internet Backbone & Colocation http://he.net | +---------------------------------------------------------------------+ From md at Linux.IT Sun Mar 1 22:31:03 2009 From: md at Linux.IT (Marco d'Itri) Date: Sun, 1 Mar 2009 22:31:03 +0100 Subject: SWIPnet relay handling most U.S. east coast 6to4 traffic? In-Reply-To: <49AAF16B.60708@he.net> References: <20090209171801.GA19113@panix.com> <49AAF16B.60708@he.net> Message-ID: <20090301213103.GA29743@bongo.bofh.it> On Mar 01, Mike Leber wrote: > I guess that's a matter of choice between the network that announces the > prefixes being used and the network that is listening to those prefixes > and using them. IOW, some careful application of the cluebat is needed to enlighten the staff of networks which choose a scenic route to the relays. -- ciao, Marco From hank at efes.iucc.ac.il Thu Mar 26 06:29:27 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 26 Mar 2009 07:29:27 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: References: <462D4706.4000504@spaghetti.zurich.ibm.com> <20070424132652.GD73965@Space.Net> <5.1.0.14.2.20070425091655.00b2fe88@efes.iucc.ac.il> <20070430152601.GA30632@data.fire-world.de> <20070430153017.GU73965@Space.Net>

Message-ID: <5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> -Hank From stevewilcox at google.com Thu Mar 26 16:51:17 2009 From: stevewilcox at google.com (Steve Wilcox) Date: Thu, 26 Mar 2009 15:51:17 +0000 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <5.1.0.14.2.20070425091655.00b2fe88@efes.iucc.ac.il> <20070430152601.GA30632@data.fire-world.de> <20070430153017.GU73965@Space.Net>

<5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> Message-ID: <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> Well, it was designed 15 years ago with the intention that it would be rolled out in less than aforementioned time period, without a sudden urgency brought on by slow adoption! So to be fair, the design probably could have been better but I guess they were still living in a time period when widescale protocol changes were do-able and taken seriously... Steve On Thu, Mar 26, 2009 at 5:29 AM, Hank Nussbacher wrote: > < > http://www.networkworld.com/news/2009/032509-ipv6-mistake.html?netht=ts_032509&nladname=032509dailynewspmal > > > > -Hank > > -- Network Operations - Standards & Design Google Inc. E: stevewilcox at google.com M: +44 7920 041930 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090326/c3b8a16d/attachment.html From jacob at internet24.de Thu Mar 26 17:55:14 2009 From: jacob at internet24.de (Thomas Jacob) Date: Thu, 26 Mar 2009 17:55:14 +0100 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <5.1.0.14.2.20070425091655.00b2fe88@efes.iucc.ac.il> <20070430152601.GA30632@data.fire-world.de> <20070430153017.GU73965@Space.Net>

<5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> Message-ID: <1238086514.1619.21.camel@enterprise.ims-firmen.de> On Thu, 2009-03-26 at 15:51 +0000, Steve Wilcox wrote: > Well, it was designed 15 years ago with the intention that it would be > rolled out in less than aforementioned time period, without a sudden > urgency brought on by slow adoption! So to be fair, the design > probably could have been better but I guess they were still living in > a time period when widescale protocol changes were do-able and taken > seriously... > > Steve I am sure some people here have already read DJBs abrasive views on the matter but if you compare the IPv4/IPv6 switch to the introduction MX records in the 80s, as he does, it seems already at that time some people were aware of workable methods for making such protocol changes be adopted quickly. http://cr.yp.to/djbdns/ipv6mess.html The introduction of support for CIDR routes into the BGP protocol in 94 might be considered another example of prior art. Sure those things are less fundamental then the layer 3 protocol. On the other hand, this last statement might equally well be used in support for the opposite thesis. But being wise after the fact is always easy ;) Thomas From stevewilcox at google.com Thu Mar 26 18:34:11 2009 From: stevewilcox at google.com (Steve Wilcox) Date: Thu, 26 Mar 2009 17:34:11 +0000 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <1238086514.1619.21.camel@enterprise.ims-firmen.de> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <20070430152601.GA30632@data.fire-world.de> <20070430153017.GU73965@Space.Net>

<5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> Message-ID: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> On Thu, Mar 26, 2009 at 4:55 PM, Thomas Jacob wrote: > On Thu, 2009-03-26 at 15:51 +0000, Steve Wilcox wrote: > > Well, it was designed 15 years ago with the intention that it would be > > rolled out in less than aforementioned time period, without a sudden > > urgency brought on by slow adoption! So to be fair, the design > > probably could have been better but I guess they were still living in > > a time period when widescale protocol changes were do-able and taken > > seriously... > > > > Steve > > I am sure some people here have already read DJBs abrasive views on the > matter but if you compare the IPv4/IPv6 switch to the introduction > MX records in the 80s, as he does, it seems already at that > time some people were aware of workable methods for making > such protocol changes be adopted quickly. > > http://cr.yp.to/djbdns/ipv6mess.html > > The introduction of support for CIDR routes into the BGP protocol in 94 > might be considered another example of prior art. > > Sure those things are less fundamental then the layer 3 protocol. I think thats part of it - they are less fundemental. Also, none of them required a complete change end to end.. in v6 you need to have user apps, user OS, access layer, backbone layer, content all enabled .. its affects all components at most layers. > > > On the other hand, this last statement might equally well be used in > support for the opposite thesis. > > But being wise after the fact is always easy ;) > > Thomas > > -- Network Operations - Standards & Design Google Inc. E: stevewilcox at google.com M: +44 7920 041930 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090326/de9bbe76/attachment.html From brandon at bogons.net Thu Mar 26 19:29:07 2009 From: brandon at bogons.net (Brandon Butterworth) Date: Thu, 26 Mar 2009 18:29:07 +0000 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> References: <20070430152601.GA30632@data.fire-world.de> <20070430153017.GU73965@Space.Net>

<5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com><20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> Message-ID: <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> > > I don't see the point of raking over history. > > The value would be in recognizing the mistakes that were made and > learning from them in order to avoid making them again. Unfortunately > I don't see any willingness to take an honest look at the mistakes > that were made, so you're right, there is no value in rehashing the > history. Furthermore, I think it's highly debatable whether the big mistake was technical (a lack of backwards compatibility), or business (the industries lack of timely action). Or both. It seems to be fashionable this month to point the finger at IPv6 for having failed us, but dual-stack could have been a solid transition mechanism if started earlier. But, you know, something about leading a horse to water and then he doesn't drink. - Scott Beuker From fred at cisco.com Fri Mar 27 02:53:50 2009 From: fred at cisco.com (Fred Baker) Date: Thu, 26 Mar 2009 18:53:50 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> References: <20070430152601.GA30632@data.fire-world.de> <20070430153017.GU73965@Space.Net>

<5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com><20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> Message-ID: <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> Also, I think it is only fair to point out that they didn't have the option of making it backwards compatible with IPv4; it's not that they didn't, it's that they couldn't. How, precisely, would you make an IPv4 packet that has longer addresses? IPv4 forces any change to the header to become a new protocol. I could imagine making a protocol (IPv17 if you like) that was a different protocol than IPv4 but had a variable length address: for example, it might be a tuple that contained the length of the tuple, the length of the network part, the length of the host part, the network part, and the host part. If the other fields were the same as IPv4, one could imagine deploying the new protocol in such a way that a translator could go between them, and put IPv17 in the backbone. We would be in a position much like we are now, however; from 1995 until now nobody would see a business justification for deployment, and folks who deployed would find that they had a hard time talking with folks who had not. It would be essentially the same issue we face now. On Mar 26, 2009, at 2:07 PM, Scott Beuker wrote: >>> I don't see the point of raking over history. >> >> The value would be in recognizing the mistakes that were made and >> learning from them in order to avoid making them again. Unfortunately >> I don't see any willingness to take an honest look at the mistakes >> that were made, so you're right, there is no value in rehashing the >> history. > > > Furthermore, I think it's highly debatable whether the big mistake > was technical (a lack of backwards compatibility), or business (the > industries lack of timely action). Or both. > > It seems to be fashionable this month to point the finger at IPv6 for > having failed us, but dual-stack could have been a solid transition > mechanism if started earlier. But, you know, something about leading > a horse to water and then he doesn't drink. > > - Scott Beuker From ek at google.com Sat Mar 28 03:21:44 2009 From: ek at google.com (Erik Kline) Date: Fri, 27 Mar 2009 19:21:44 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> References: <20070430152601.GA30632@data.fire-world.de> <5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> Message-ID: <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> Agreed. I think also that the time for retrospection is not yet upon us. The IPv6 transition has recently been gaining steam. I think once we see some more successful transitions and deployment experiences *then* we'll be able to see some of the things that made the successes possible. After all, having a pile of miscellaneous, possibly incomplete, car parts on the floor does not really tell me how I should have built a car. Having at least one working car to examine gives me at least one reference point for what parts are needed and how they might go together. And the more working cars to examine the easier it is to analyze the commons elements to successful automotive manufacturing. 2009/3/26 Fred Baker > Also, I think it is only fair to point out that they didn't have the option > of making it backwards compatible with IPv4; it's not that they didn't, it's > that they couldn't. How, precisely, would you make an IPv4 packet that has > longer addresses? IPv4 forces any change to the header to become a new > protocol. > > I could imagine making a protocol (IPv17 if you like) that was a different > protocol than IPv4 but had a variable length address: for example, it might > be a tuple that contained the length of the tuple, the length of the network > part, the length of the host part, the network part, and the host part. If > the other fields were the same as IPv4, one could imagine deploying the new > protocol in such a way that a translator could go between them, and put > IPv17 in the backbone. We would be in a position much like we are now, > however; from 1995 until now nobody would see a business justification for > deployment, and folks who deployed would find that they had a hard time > talking with folks who had not. It would be essentially the same issue we > face now. > > > On Mar 26, 2009, at 2:07 PM, Scott Beuker wrote: > > I don't see the point of raking over history. >>>> >>> >>> The value would be in recognizing the mistakes that were made and >>> learning from them in order to avoid making them again. Unfortunately >>> I don't see any willingness to take an honest look at the mistakes >>> that were made, so you're right, there is no value in rehashing the >>> history. >>> >> >> >> Furthermore, I think it's highly debatable whether the big mistake >> was technical (a lack of backwards compatibility), or business (the >> industries lack of timely action). Or both. >> >> It seems to be fashionable this month to point the finger at IPv6 for >> having failed us, but dual-stack could have been a solid transition >> mechanism if started earlier. But, you know, something about leading >> a horse to water and then he doesn't drink. >> >> - Scott Beuker >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090327/ca637691/attachment.html From fred at cisco.com Sat Mar 28 04:57:49 2009 From: fred at cisco.com (Fred Baker) Date: Fri, 27 Mar 2009 20:57:49 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> References: <462D4706.4000504@spaghetti.zurich.ibm.com> <20070430152601.GA30632@data.fire-world.de> <20070430153017.GU73965@Space.Net>

<5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> Message-ID: <9744576F-F6A9-4933-AC7C-22205C64A676@cisco.com> On Mar 26, 2009, at 10:34 AM, Steve Wilcox wrote: > Also, none of them required a complete change end to end.. in v6 you > need to have user apps, user OS, access layer, backbone layer, > content all enabled .. its affects all components at most layers. Also, in 1994, it was fairly common to run multiple protocols. Not in the ISPs, but in the more important 95% of the network, the part that wasn't "just transit". IPv4 was not even the dominant seat - IPX was. In 1995, the presumption was "so you do what we all do - IPv4, IPX, DECNET IV and V, Appletalk, and now IPv6". From jabley at hopcount.ca Mon Mar 30 18:27:31 2009 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 30 Mar 2009 12:27:31 -0400 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> References: <20070430152601.GA30632@data.fire-world.de> <5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> Message-ID: On 27-Mar-2009, at 22:21, Erik Kline wrote: > I think also that the time for retrospection is not yet upon us. > The IPv6 transition has recently been gaining steam. I think it would be great if people could stop talking about the "IPv6 transition", and in doing so help spread the message that the IPv4 Internet is not going away any time soon. Common perception is that IPv6 is a drop-in replacement for IPv4, hence incredulous news stories such as that quoted at the head of this thread. Whatever was imagined in the past, this is surely not the current operational reality. What is required is not for people (service architects, content providers, access providers, users) to turn off IPv4 and turn on IPv6, but instead to add IPv6 capability *in addition to* IPv4. If IPv6 has a future in our lifetimes (and I think it does) it is in an overwhelmingly dual-stack world, not a world of v6-only clients. I think this is an important distinction. Transition implies that people should wait "until IPv6 is ready" before "switching". Those people will be waiting a long time. Joe From fred at cisco.com Mon Mar 30 18:37:44 2009 From: fred at cisco.com (Fred Baker) Date: Mon, 30 Mar 2009 09:37:44 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: References: <20070430152601.GA30632@data.fire-world.de> <5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> Message-ID: <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> On Mar 30, 2009, at 9:27 AM, Joe Abley wrote: > What is required is not for people (service architects, content > providers, access providers, users) to turn off IPv4 and turn on > IPv6, but instead to add IPv6 capability *in addition to* IPv4. If > IPv6 has a future in our lifetimes (and I think it does) it is in an > overwhelmingly dual-stack world, not a world of v6-only clients. I agree with you, with one exceptional point. At some point, IPv6 deployment will be widespread enough that most people are running it. If that does not eventually become true, we never had a real problem in the first place - and I will argue that the only reason that IPv6 is at all an issue is that there is a problem. At the point where most folks have deployed IPv6, just as happened with DECNET, IPX, and others, IPv4 will become non-essential. From merike at doubleshotsecurity.com Mon Mar 30 18:44:11 2009 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Mon, 30 Mar 2009 09:44:11 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: References: <20070430152601.GA30632@data.fire-world.de> <5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> Message-ID: <0D8A2E18-A4FC-417C-96DB-D78ECEF25465@doubleshotsecurity.com> Good point Joe. In some environments where I've been involved with v6 deployments we did actually start talking about 'adding IPv6 capabilities' and deliberately stopped using the word 'transition'. It made a difference in perception (much to my surprise - but I suppose when I think of IPv6 transition I know it's not replacing IPv4........to others it's not so transparent) - merike On Mar 30, 2009, at 9:27 AM, Joe Abley wrote: > > On 27-Mar-2009, at 22:21, Erik Kline wrote: > >> I think also that the time for retrospection is not yet upon us. >> The IPv6 transition has recently been gaining steam. > > I think it would be great if people could stop talking about the > "IPv6 transition", and in doing so help spread the message that the > IPv4 Internet is not going away any time soon. Common perception is > that IPv6 is a drop-in replacement for IPv4, hence incredulous news > stories such as that quoted at the head of this thread. Whatever > was imagined in the past, this is surely not the current > operational reality. > > What is required is not for people (service architects, content > providers, access providers, users) to turn off IPv4 and turn on > IPv6, but instead to add IPv6 capability *in addition to* IPv4. If > IPv6 has a future in our lifetimes (and I think it does) it is in > an overwhelmingly dual-stack world, not a world of v6-only clients. > > I think this is an important distinction. Transition implies that > people should wait "until IPv6 is ready" before "switching". Those > people will be waiting a long time. > > > Joe > From udo at stueberl.de Mon Mar 30 18:49:27 2009 From: udo at stueberl.de (Udo Steinegger) Date: Mon, 30 Mar 2009 18:49:27 +0200 Subject: Fwd: Biggest mistake for IPv6: It's not backwards compatible, developers admit References: Message-ID: <227D6484-927F-4234-A14B-F838E876E109@stueberl.de> Anfang der weitergeleiteten E-Mail: > Von: Udo Steinegger > Datum: 30. M?rz 2009 18:48:01 MESZ > An: Fred Baker > Betreff: Re: Biggest mistake for IPv6: It's not backwards > compatible, developers admit > > > Am 30.03.2009 um 18:37 schrieb Fred Baker: > > Guys, > > all the arguments to this discussion are well and fine. > But for the commercial non-ISP world, at least in old Europe, one of > the bigger Problems is to get > the same level of provider independence in IPv6 (read: PI address > space), that they are used to in the IPv4 world. > > As long as this is not properly addressed, then people are very > reluctant to move towards IPv6 and stick with > IPv4 until the last day. > > I know that this has to be discussed with other entities/bodies and > some folks do what they can to solve that issue, > but in any case, I find that more important to solve rather than > discussing if we name the beast IPv6-"transition" or > anything similar else. > > cheers > > Udo > > From nick-lists at netability.ie Mon Mar 30 18:53:22 2009 From: nick-lists at netability.ie (Nick Hilliard) Date: Mon, 30 Mar 2009 17:53:22 +0100 Subject: Fwd: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <227D6484-927F-4234-A14B-F838E876E109@stueberl.de> References: <227D6484-927F-4234-A14B-F838E876E109@stueberl.de> Message-ID: <49D0F902.9090300@netability.ie> On 30/03/2009 17:49, Udo Steinegger wrote: >> all the arguments to this discussion are well and fine. >> But for the commercial non-ISP world, at least in old Europe, one of >> the bigger Problems is to get >> the same level of provider independence in IPv6 (read: PI address >> space), that they are used to in the IPv4 world. >> >> As long as this is not properly addressed, then people are very >> reluctant to move towards IPv6 Indeed, and this should be sorted on April 13: http://www.ripe.net/ripe/policies/proposals/2006-01.html >> and stick with >> IPv4 until the last day. This is an entirely different issue. Nick From tvest at pch.net Mon Mar 30 18:55:21 2009 From: tvest at pch.net (Tom Vest) Date: Mon, 30 Mar 2009 12:55:21 -0400 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> References: <20070430152601.GA30632@data.fire-world.de> <5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> Message-ID: <4B00C3A7-5874-41B2-9B55-F6CC2AE1B43B@pch.net> On Mar 30, 2009, at 12:37 PM, Fred Baker wrote: > On Mar 30, 2009, at 9:27 AM, Joe Abley wrote: > >> What is required is not for people (service architects, content >> providers, access providers, users) to turn off IPv4 and turn on >> IPv6, but instead to add IPv6 capability *in addition to* IPv4. If >> IPv6 has a future in our lifetimes (and I think it does) it is in >> an overwhelmingly dual-stack world, not a world of v6-only clients. > > I agree with you, with one exceptional point. At some point, IPv6 > deployment will be widespread enough that most people are running > it. If that does not eventually become true, we never had a real > problem in the first place - and I will argue that the only reason > that IPv6 is at all an issue is that there is a problem. At the > point where most folks have deployed IPv6, just as happened with > DECNET, IPX, and others, IPv4 will become non-essential. Hi Fred, Does this mean that you completely discount the possibility that the perpetuation of IPv4 might represent a "local maximum," as someone put it in San Francisco -- i.e., an attractive short-term but inferior long-term solution, but one that once adopted could be very difficult or impossible to escape? It seems to be that rejecting the very idea of a "local maximum" like this would entail a sort of Panglossian view of the world, i.e., that the status quo always represents the best of all possible worlds, by definition. Since the status quo is rarely homogenous, however, and we can almost always imagine better/worse outcomes, I don't think this is a internally coherent position... I don't necessarily attribute it to you, just trying to understand the comment... Thanks, Tom From merike at doubleshotsecurity.com Mon Mar 30 18:57:50 2009 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Mon, 30 Mar 2009 09:57:50 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> References: <20070430152601.GA30632@data.fire-world.de> <5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> Message-ID: The important part is to get more people deploying v6 along with their current infrastructures and yes, possibly at some point some of the v4 will eventually go away. But my gut feeling is that this may be a different 'transition' than that from IPX, DECnet, etc. The 'IPv4 will become non-essential' depends a lot on what applications will evolve to in terms of what transports they use. I am always mildly amused when I see appletalk is still configurable on my MAC although not on by default. And luckily it's a non- essential protocol :) - merike On Mar 30, 2009, at 9:37 AM, Fred Baker wrote: > > On Mar 30, 2009, at 9:27 AM, Joe Abley wrote: > >> What is required is not for people (service architects, content >> providers, access providers, users) to turn off IPv4 and turn on >> IPv6, but instead to add IPv6 capability *in addition to* IPv4. If >> IPv6 has a future in our lifetimes (and I think it does) it is in >> an overwhelmingly dual-stack world, not a world of v6-only clients. > > I agree with you, with one exceptional point. At some point, IPv6 > deployment will be widespread enough that most people are running > it. If that does not eventually become true, we never had a real > problem in the first place - and I will argue that the only reason > that IPv6 is at all an issue is that there is a problem. At the > point where most folks have deployed IPv6, just as happened with > DECNET, IPX, and others, IPv4 will become non-essential. > From fred at cisco.com Mon Mar 30 19:02:45 2009 From: fred at cisco.com (Fred Baker) Date: Mon, 30 Mar 2009 10:02:45 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: References: <20070430152601.GA30632@data.fire-world.de> <5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> Message-ID: <5ACF4184-642E-4314-B943-5F9A7E2AEFF4@cisco.com> On Mar 30, 2009, at 9:27 AM, Joe Abley wrote: > I think this is an important distinction. Transition implies that > people should wait "until IPv6 is ready" before "switching". Those > people will be waiting a long time. Yes. I was amused not too long ago with a journalist's question. She wanted to know why, if IPv6 was ready for deployment, we were working so hard on it. I pointed out that in 1983 IPv4 was not only "ready for deployment" but "widely deployed" - we turned NCP off (mostly) and turned IPv4 on. At that point, the IETF, NANOG, and so on had not yet been formed; in a very real sense, the hard work had not even started. What have the IETF and the RIR communities been doing since? Yes, we are working on issues with the ongoing deployment of IPv6, and yes, people are turning it on in their existing IPv4 networks. Both of those are important at this point. From fred at cisco.com Mon Mar 30 19:32:58 2009 From: fred at cisco.com (Fred Baker) Date: Mon, 30 Mar 2009 10:32:58 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: References: <20070430152601.GA30632@data.fire-world.de> <5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> Message-ID: <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> This is a place where I find myself banging my head against the wall. As I see it, there are six major proposals on the table. - provider-independent addressing (aka PI) - provider-dependent addressing (aka PA) - provider-dependent addressing with multiple prefix overlays in multihomed networks (shim6) - private addressing with NAT, converting to provider-dependent addressing at a DMZ - private addressing with Network Prefix Translation (GSE) - exchange-based addressing (aka Metropolitan addressing) Each of those except straight PA give you ISP independence. Each of them has issues; folks don't like shim6 because it transfers the complexity to the edge networks, they don't like exchange-based addressing because it forces the transit contracts to be inverted to sender-pays, IPv6 was designed to solve a lot of the ills caused by NAT so re-introducing NAT is a step back into the mire, folks don't like GSE because they confuse it with NAT, and so on. The issue with straight PI addressing is the issue that causes people to wonder about the size of the route table. If you have never heard the observation that "routing doesn't scale", I'm amazed. The thing that makes routing "not scale", and so drives memory volumes and their implied costs, both capex and opex, is that PI places a prefix on every thing that can be routed to (now on the order of 10^6, within the decade on the order of 10^7, per Marshall Eubanks' analysis at NANOG) as opposed to the number of entities that require routing to (autonomous systems or something like them, O(10^5)). They say that insanity can be identified when someone applies the same algorithm to the same data and expects a different result. If we go PI - and yes, the RIRs appear to be headed down that path - I don't want to hear any complaints about the size of the route table or the costs it implies. And I have to say that your assertion, that ways to provide ISP independence have not been provided, is problematic. Ways have indeed been provided, some of them (GSE) by the operator community. All of them with the exception of the one that got us into the current mess have been rejected out of hand without operational testing and without much thought as near as I can tell. That doesn't leave me very motivated to come up with yet another. On Mar 30, 2009, at 9:48 AM, Udo Steinegger wrote: > > Am 30.03.2009 um 18:37 schrieb Fred Baker: > > Guys, > > all the arguments to this discussion are well and fine. > But for the commercial non-ISP world, at least in old Europe, one of > the bigger Problems is to get > the same level of provider independence in IPv6 (read: PI address > space), that they are used to in the IPv4 world. > > As long as this is not properly addressed, then people are very > reluctant to move towards IPv6 and stick with > IPv4 until the last day. > > I know that this has to be discussed with other entities/bodies and > some folks do what they can to solve that issue, > but in any case, I find that more important to solve rather than > discussing if we name the beast IPv6-"transition" or > anything similar else. > > cheers > > Udo > > From fred at cisco.com Mon Mar 30 19:47:59 2009 From: fred at cisco.com (Fred Baker) Date: Mon, 30 Mar 2009 10:47:59 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <4B00C3A7-5874-41B2-9B55-F6CC2AE1B43B@pch.net> References: <20070430152601.GA30632@data.fire-world.de> <5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <4B00C3A7-5874-41B2-9B55-F6CC2AE1B43B@pch.net> Message-ID: On Mar 30, 2009, at 9:55 AM, Tom Vest wrote: > On Mar 30, 2009, at 12:37 PM, Fred Baker wrote: >> On Mar 30, 2009, at 9:27 AM, Joe Abley wrote: >>> What is required is not for people (service architects, content >>> providers, access providers, users) to turn off IPv4 and turn on >>> IPv6, but instead to add IPv6 capability *in addition to* IPv4. If >>> IPv6 has a future in our lifetimes (and I think it does) it is in >>> an overwhelmingly dual-stack world, not a world of v6-only clients. >> >> I agree with you, with one exceptional point. At some point, IPv6 >> deployment will be widespread enough that most people are running >> it. If that does not eventually become true, we never had a real >> problem in the first place - and I will argue that the only reason >> that IPv6 is at all an issue is that there is a problem. At the >> point where most folks have deployed IPv6, just as happened with >> DECNET, IPX, and others, IPv4 will become non-essential. > > Hi Fred, > > Does this mean that you completely discount the possibility that the > perpetuation of IPv4 might represent a "local maximum," as someone > put it in San Francisco -- i.e., an attractive short-term but > inferior long-term solution, but one that once adopted could be very > difficult or impossible to escape? I don't. There are a number of things I don't discount. However, as your further comment details, the local maximum is not a rational model. As I just said in an email to Udo, I am frustrated with people's irrationality, but I none-the-less hope that business rationality will eventually force an outcome that makes sense. Color me insane. From spz at serpens.de Tue Mar 31 08:47:44 2009 From: spz at serpens.de (S.P.Zeidler) Date: Tue, 31 Mar 2009 08:47:44 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> Message-ID: <20090331064744.GE17392@serpens.de> Hi, Thus wrote Fred Baker (fred at cisco.com): > The issue with straight PI addressing is the issue that causes people to > wonder about the size of the route table. If you have never heard the > observation that "routing doesn't scale", I'm amazed. The thing that > makes routing "not scale", and so drives memory volumes and their > implied costs, both capex and opex, is that PI places a prefix on every > thing that can be routed to (now on the order of 10^6, within the decade > on the order of 10^7, per Marshall Eubanks' analysis at NANOG) as opposed > to the number of entities that require routing to (autonomous systems or > something like them, O(10^5)). I don't see that following, at least not with a sane PI assignment policy. PI space being available does not mean that there would be no more PA at all. What I -do- see following is that an entity can be/have an autonomous system without being an ISP (and without needing a /32), many of them being autonomous systems already in v4, and not willing to give up their routing independence to add v6. Also, most ASs would only announce one prefix instead of the zoo most keep today. regards, spz -- spz at serpens.de (S.P.Zeidler) From fred at cisco.com Tue Mar 31 09:09:03 2009 From: fred at cisco.com (Fred Baker) Date: Tue, 31 Mar 2009 00:09:03 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <20090331064744.GE17392@serpens.de> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> Message-ID: <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> On Mar 30, 2009, at 11:47 PM, S.P.Zeidler wrote: > Hi, > > Thus wrote Fred Baker (fred at cisco.com): > >> The issue with straight PI addressing is the issue that causes >> people to >> wonder about the size of the route table. If you have never heard the >> observation that "routing doesn't scale", I'm amazed. The thing that >> makes routing "not scale", and so drives memory volumes and their >> implied costs, both capex and opex, is that PI places a prefix on >> every >> thing that can be routed to (now on the order of 10^6, within the >> decade >> on the order of 10^7, per Marshall Eubanks' analysis at NANOG) as >> opposed >> to the number of entities that require routing to (autonomous >> systems or >> something like them, O(10^5)). > > I don't see that following, at least not with a sane PI assignment > policy. > PI space being available does not mean that there would be no more > PA at all. See, on that you and I agree. There is a place for PI addressing. I might even hazard a guess that it is similar to today's place for AS numbers. Problem is, folks in that range are getting PI addressing now, and we're still hearing statements like On Mar 30, 2009, at 9:48 AM, Udo Steinegger wrote: > But for the commercial non-ISP world, at least in old Europe, one of > the bigger Problems is to get > the same level of provider independence in IPv6 (read: PI address > space), that they are used to in the IPv4 world. > > As long as this is not properly addressed, then people are very > reluctant to move towards IPv6 and stick with IPv4 until the last day. The alternatives are fine for "someone else", but ask anyone, and they want their PI. Give them that, and the IPv6 route table very quickly mirrors the IPv4 route table for complexity. And hence I raise my question. There are a number of alternatives on the table today that give one both multihoming and ISP independence. Who has given them five minutes though before rejecting them out of hand? And what is the outcome of that? From martin at airwire.ie Tue Mar 31 11:45:02 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 31 Mar 2009 10:45:02 +0100 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <20090331064744.GE17392@serpens.de> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> Message-ID: <49D1E61E.1050405@airwire.ie> S.P.Zeidler wrote: > I don't see that following, at least not with a sane PI assignment policy. > PI space being available does not mean that there would be no more PA at all. Which means spacing, so that if an increase is needed, the prefix is increased, but not a second one allocated. > What I -do- see following is that an entity can be/have an autonomous system > without being an ISP (and without needing a /32), many of them being > autonomous systems already in v4, and not willing to give up their routing > independence to add v6. I agree entirely here. > Also, most ASs would only announce one prefix instead of the zoo most > keep today. And on this one two. We'll have one prefix per AS (more or less). That will be less prefixes than are announced today for the current autonomous systems. The only problem is, that we're also allocating 4-byte ASN's now which gives potential for a bigger routing table than the one we have. On the other side, that's just progression for you and would have happened anyhow, IPv6 or not. Sl?n, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From he at nordu.net Tue Mar 31 13:44:28 2009 From: he at nordu.net (Havard Eidnes) Date: Tue, 31 Mar 2009 13:44:28 +0200 (CEST) Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <49D1E61E.1050405@airwire.ie> References: <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <49D1E61E.1050405@airwire.ie> Message-ID: <20090331.134428.238903156.he@uninett.no> > > Also, most ASs would only announce one prefix instead of the > > zoo most keep today. > > And on this one two. We'll have one prefix per AS (more or > less). That will be less prefixes than are announced today for > the current autonomous systems. Except the desire to do traffic engineering to spread the incoming load among multiple upstreams will tend to push people into doing de-aggregation of their single prefix, and since we have no good tools to limit the distribution of a given prefix beyond the first AS hop, the de-aggregated prefixes will tend to be visible globally (it's not a given that an "as hop limit" would help much either). ...which puts us at least more in the direction of the situation we have with IPv4 today. Combine this with a reckless disregard for the common good (controlling the global routing table size), and perhaps a healthy dose of cluelessness (there seems to be plenty to go around), and it pushes us further in the direction of a non- scaleable routing system. Best regards, - H?vard (slightly pessimistic) From john at sackheads.org Tue Mar 31 14:05:00 2009 From: john at sackheads.org (John Payne) Date: Tue, 31 Mar 2009 08:05:00 -0400 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> Message-ID: <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> On Mar 31, 2009, at 3:09 AM, Fred Baker wrote: > The alternatives are fine for "someone else", but ask anyone, and > they want their PI. Give them that, and the IPv6 route table very > quickly mirrors the IPv4 route table for complexity. > > And hence I raise my question. There are a number of alternatives on > the table today that give one both multihoming and ISP independence. > Who has given them five minutes though before rejecting them out of > hand? What alternative gives you multi-homing and leaves the traffic engineering[*] in the hands of the network team and not the end-users or server folk? [*] even if that's "primary/backup" rather than anything more complex... but people will want to try to get to 60/40 or 50/50 for political or cost reasons From ik5pvx at gmail.com Tue Mar 31 14:20:16 2009 From: ik5pvx at gmail.com (Pierfrancesco Caci) Date: Tue, 31 Mar 2009 14:20:16 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> Message-ID: <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> On Tue, Mar 31, 2009 at 14:05, John Payne wrote: > [*] ?even if that's "primary/backup" rather than anything more complex... > but people will want to try to get to 60/40 or 50/50 for political or cost > reasons > and people denying/not acknowledging the need of political/economical traffic engineering are kindly asked to get their head outside of the cozy cave that their educational lab network is. ktnxby -- Pierfrancesco Caci, ik5pvx From jeroen at unfix.org Tue Mar 31 14:30:50 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 31 Mar 2009 14:30:50 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> Message-ID: <49D20CFA.2030101@spaghetti.zurich.ibm.com> Pierfrancesco Caci wrote: > On Tue, Mar 31, 2009 at 14:05, John Payne wrote: > >> [*] even if that's "primary/backup" rather than anything more complex... >> but people will want to try to get to 60/40 or 50/50 for political or cost >> reasons >> > > and people denying/not acknowledging the need of political/economical > traffic engineering are kindly asked to get their head outside of the > cozy cave that their educational lab network is. ktnxby Please then propose a "total solution" to this problem that solves it for everybody. A requirements document would already be a great start for that matter. You can come out of your cozy cave when you have done that. NEXT! Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090331/65ae3ad6/attachment.bin From ik5pvx at gmail.com Tue Mar 31 14:43:52 2009 From: ik5pvx at gmail.com (Pierfrancesco Caci) Date: Tue, 31 Mar 2009 14:43:52 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <49D20CFA.2030101@spaghetti.zurich.ibm.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> Message-ID: <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> On Tue, Mar 31, 2009 at 14:30, Jeroen Massar wrote: > Please then propose a "total solution" to this problem that solves it > for everybody. A requirements document would already be a great start > for that matter. > Let's start a list of requirements, just to summarize this thread. I'll write down what comes to my mind, others please add theirs: - keep the routing table reasonably compact - allow multihoming the way v4 PI does for small players - allow 'political' traffic engineering, in addition to whatever technical reason you may have already > You can come out of your cozy cave when you have done that. believe me, it's all but cozy in here... :-) -- Pierfrancesco Caci, ik5pvx From stevewilcox at google.com Tue Mar 31 14:55:43 2009 From: stevewilcox at google.com (Steve Wilcox) Date: Tue, 31 Mar 2009 13:55:43 +0100 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> Message-ID: <922f6670903310555o5e0e4fffi3978c323bbd921df@mail.gmail.com> On Tue, Mar 31, 2009 at 1:05 PM, John Payne wrote: > > On Mar 31, 2009, at 3:09 AM, Fred Baker wrote: > > The alternatives are fine for "someone else", but ask anyone, and they >> want their PI. Give them that, and the IPv6 route table very quickly mirrors >> the IPv4 route table for complexity. >> >> And hence I raise my question. There are a number of alternatives on the >> table today that give one both multihoming and ISP independence. Who has >> given them five minutes though before rejecting them out of hand? >> > > What alternative gives you multi-homing and leaves the traffic > engineering[*] in the hands of the network team and not the end-users or > server folk? None.. quite frankly I'm not clear why we're pushing v6 policy to try to make it hard to get PI space. Lets stick to the v4 style policy where anyone with BGP and an ASN can get address space and gives them a v6 /32 and we'll make this transition much easier. Steve > > > > [*] even if that's "primary/backup" rather than anything more complex... > but people will want to try to get to 60/40 or 50/50 for political or cost > reasons > -- Network Operations - Standards & Design Google Inc. E: stevewilcox at google.com M: +44 7920 041930 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090331/18b0ca06/attachment.html From jeroen at unfix.org Tue Mar 31 14:56:08 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 31 Mar 2009 14:56:08 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> Message-ID: <49D212E8.4070007@spaghetti.zurich.ibm.com> Pierfrancesco Caci wrote: > On Tue, Mar 31, 2009 at 14:30, Jeroen Massar wrote: > >> Please then propose a "total solution" to this problem that solves it >> for everybody. A requirements document would already be a great start >> for that matter. >> > > Let's start a list of requirements, just to summarize this thread. > I'll write down what comes to my mind, others please add theirs: > > - keep the routing table reasonably compact > - allow multihoming the way v4 PI does for small players That voids your first rule. NEXT. > - allow 'political' traffic engineering, in addition to whatever > technical reason you may have already That also voids the first rule. NEXT. Write a full draft. And keep in mind that there are other people that have different requirements which they want satisfied. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090331/12f9c85a/attachment.bin From ik5pvx at gmail.com Tue Mar 31 15:09:26 2009 From: ik5pvx at gmail.com (Pierfrancesco Caci) Date: Tue, 31 Mar 2009 15:09:26 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <49D212E8.4070007@spaghetti.zurich.ibm.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> <49D212E8.4070007@spaghetti.zurich.ibm.com> Message-ID: <4013b2300903310609q631eb72bnceabe2da21eeb527@mail.gmail.com> On Tue, Mar 31, 2009 at 14:56, Jeroen Massar wrote: > Pierfrancesco Caci wrote: >> - keep the routing table reasonably compact >> - allow multihoming the way v4 PI does for small players > > That voids your first rule. NEXT. > >> - allow 'political' traffic engineering, in addition to whatever >> technical reason you may have already > > That also voids the first rule. NEXT. > > Write a full draft. And keep in mind that there are other people that > have different requirements which they want satisfied. My idea was to get a full list of requirements, and then discuss the conflicting ones. But you managed to expose 2 conflicts with just 3 requirements so this is probably why v6 deployement has stalled so long and nobody writes that full draft. Are we trying to address too many things at once ? -- Pierfrancesco Caci, ik5pvx From john at sackheads.org Tue Mar 31 15:11:32 2009 From: john at sackheads.org (John Payne) Date: Tue, 31 Mar 2009 09:11:32 -0400 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <49D20CFA.2030101@spaghetti.zurich.ibm.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> Message-ID: <186D2E03-07F3-4BF9-84F4-20500E84BF0B@sackheads.org> On Mar 31, 2009, at 8:30 AM, Jeroen Massar wrote: > Pierfrancesco Caci wrote: >> On Tue, Mar 31, 2009 at 14:05, John Payne wrote: >> >>> [*] even if that's "primary/backup" rather than anything more >>> complex... >>> but people will want to try to get to 60/40 or 50/50 for political >>> or cost >>> reasons >>> >> >> and people denying/not acknowledging the need of political/economical >> traffic engineering are kindly asked to get their head outside of the >> cozy cave that their educational lab network is. ktnxby > > Please then propose a "total solution" to this problem that solves it > for everybody. A requirements document would already be a great start > for that matter. > > You can come out of your cozy cave when you have done that. > > NEXT! *sigh* I was asking Fred a question in order to better answer his. Anyhow, this is starting to feel like 2006 (see thread starting at: http://www.ops.ietf.org/lists/shim6/msg00987.html) After a call for operator input to shim6 from NANOG, the shim6 mailing list received operator input, including a decent size set of requirements. Perhaps not a formal requirements document, but pain points and needs and wants were expressed. Of course, none of those would fit into shim6, and since it had already been decided that shim6 was the direction of multihoming, "buzz off pesky operators". And then IPv6 PI space started to appear.... "yay". -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090331/cd669084/attachment-0001.html From jabley at hopcount.ca Tue Mar 31 15:15:15 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 31 Mar 2009 09:15:15 -0400 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> Message-ID: <1117F8F1-47B4-4745-A81D-1DBC63AA2B15@hopcount.ca> On 31-Mar-2009, at 08:43, Pierfrancesco Caci wrote: > On Tue, Mar 31, 2009 at 14:30, Jeroen Massar wrote: > >> Please then propose a "total solution" to this problem that solves it >> for everybody. A requirements document would already be a great start >> for that matter. > > Let's start a list of requirements, just to summarize this thread. Been there, done that, five and a half years ago. http://tools.ietf.org/rfc/rfc3582.txt Joe From jeroen at unfix.org Tue Mar 31 15:17:40 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 31 Mar 2009 15:17:40 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <4013b2300903310609q631eb72bnceabe2da21eeb527@mail.gmail.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> <49D212E8.4070007@spaghetti.zurich.ibm.com> <4013b2300903310609q631eb72bnceabe2da21eeb527@mail.gmail.com> Message-ID: <49D217F4.2060801@spaghetti.zurich.ibm.com> Pierfrancesco Caci wrote: > On Tue, Mar 31, 2009 at 14:56, Jeroen Massar wrote: >> Pierfrancesco Caci wrote: >>> - keep the routing table reasonably compact >>> - allow multihoming the way v4 PI does for small players >> That voids your first rule. NEXT. >> >>> - allow 'political' traffic engineering, in addition to whatever >>> technical reason you may have already >> That also voids the first rule. NEXT. >> >> Write a full draft. And keep in mind that there are other people that >> have different requirements which they want satisfied. > > My idea was to get a full list of requirements, and then discuss the > conflicting ones. > But you managed to expose 2 conflicts with just 3 requirements so this > is probably why v6 deployement has stalled so long and nobody writes > that full draft. Are we trying to address too many things at once ? The internet is this big thing with a lot of people. Not everybody will be able to eat the full cake when it comes to routing and then also being able to keep it able to route to everybody. There are a *LOT* of proposals being worked on, the most prominent one at the moment most likely being LISP. see the RRG group at the IRTF for various other proposals. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090331/787ca555/attachment.bin From ik5pvx at gmail.com Tue Mar 31 16:12:44 2009 From: ik5pvx at gmail.com (Pierfrancesco Caci) Date: Tue, 31 Mar 2009 16:12:44 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <49D217F4.2060801@spaghetti.zurich.ibm.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> <49D212E8.4070007@spaghetti.zurich.ibm.com> <4013b2300903310609q631eb72bnceabe2da21eeb527@mail.gmail.com> <49D217F4.2060801@spaghetti.zurich.ibm.com> Message-ID: <4013b2300903310712m1c17afa5jf0913b3364601275@mail.gmail.com> On Tue, Mar 31, 2009 at 15:17, Jeroen Massar wrote: > The internet is this big thing with a lot of people. Not everybody will > be able to eat the full cake when it comes to routing and then also > being able to keep it able to route to everybody. I'm sure I don't know a lot of things about mobility, or datacenter connectivity issues and so on. What I know is that in a backbone provider network, you'll have lots of external constraints. Availability of transmission capacity, cost of interconnection with other operators, endless delays in the delivery of hardware and so on. Traffic engineering is a day to day task. In addition to that, if given the possibility, customers will always try to deaggregate to the smallest block possible for a variety of reasons, of which the one that bothers me most is "so others won't be able to hijack my block". So anything we do to allow for TE will likely give way to the wild deaggregations that we see in the v4 table. I understand the desire to avoid this. The goals exposed in rfc3582 seem to me all valid and current, and maybe the point made about the meshed interconnection is even more evident that in 2003, with lots and lots of providers and even enterprises who do their own peering at IXPs. To all these operators, probably v6 PI seems like a reasonable way to maintain the status quo in term of market, independence, knowledge of their own personnel, possibility to continue to do what they do without having to overhaul their net completely. -- Pierfrancesco Caci, ik5pvx From mohacsi at niif.hu Tue Mar 31 16:14:28 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 31 Mar 2009 16:14:28 +0200 (CEST) Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> Message-ID: On Tue, 31 Mar 2009, Pierfrancesco Caci wrote: > On Tue, Mar 31, 2009 at 14:30, Jeroen Massar wrote: > >> Please then propose a "total solution" to this problem that solves it >> for everybody. A requirements document would already be a great start >> for that matter. >> > > Let's start a list of requirements, just to summarize this thread. > I'll write down what comes to my mind, others please add theirs: > > - keep the routing table reasonably compact ok. > - allow multihoming the way v4 PI does for small players What do you mean by this? Have more than one upstream provider for resiliency? > - allow 'political' traffic engineering, in addition to whatever > technical reason you may have already Are you willing to pay for poluting DFZ routing table? Best Regards, Janos Mohacsi From ik5pvx at gmail.com Tue Mar 31 16:26:50 2009 From: ik5pvx at gmail.com (Pierfrancesco Caci) Date: Tue, 31 Mar 2009 16:26:50 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> Message-ID: <4013b2300903310726u7937f4a1wfda69b460e3bed60@mail.gmail.com> On Tue, Mar 31, 2009 at 16:14, Mohacsi Janos wrote: > > > > On Tue, 31 Mar 2009, Pierfrancesco Caci wrote: > >> - allow multihoming the way v4 PI does for small players > > What do you mean by this? Have more than one upstream provider for > resiliency? think about the small-ish operator that has a couple of transits (for costs and resiliency reasons) and peers at the local exchange with other networks. This is a quite common scenario, and they won't give away the ability to do that quite easily, unless the market changes in a way that I honestly can't imagine. > >> - allow 'political' traffic engineering, in addition to whatever >> technical reason you may have already > > > Are you willing to pay for poluting DFZ routing table? > Are you willing to explain to your colleague in finances why you let your traffic with $big_provider_A go over commit at premium price, while traffic with $big_provider_B was under commit? Please note that the colleague in finances is the same that will deny you the upgrades of your router memories at budget time. -- Pierfrancesco Caci, ik5pvx From martin at airwire.ie Tue Mar 31 16:39:55 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 31 Mar 2009 15:39:55 +0100 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <20090331.134428.238903156.he@uninett.no> References: <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <49D1E61E.1050405@airwire.ie> <20090331.134428.238903156.he@uninett.no> Message-ID: <49D22B3B.9010908@airwire.ie> Havard Eidnes wrote: > Except the desire to do traffic engineering to spread the > incoming load among multiple upstreams will tend to push people > into doing de-aggregation of their single prefix, and since we > have no good tools to limit the distribution of a given prefix > beyond the first AS hop, the de-aggregated prefixes will tend to > be visible globally (it's not a given that an "as hop limit" > would help much either). No. you can always reject de-aggregated prefixes based on LIR allocations with filters. That's entirely up to yourself. Any sane network person will send both the allocated full prefix on top of the de-aggregated prefixes. The choice of table-size is yours. Don't prohibit others from diversity and redundancy. Sl?n, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From mohacsi at niif.hu Tue Mar 31 16:52:38 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 31 Mar 2009 16:52:38 +0200 (CEST) Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <4013b2300903310726u7937f4a1wfda69b460e3bed60@mail.gmail.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> <4013b2300903310726u7937f4a1wfda69b460e3bed60@mail.gmail.com> Message-ID: On Tue, 31 Mar 2009, Pierfrancesco Caci wrote: > On Tue, Mar 31, 2009 at 16:14, Mohacsi Janos wrote: >> >> >> >> On Tue, 31 Mar 2009, Pierfrancesco Caci wrote: > >> >>> - allow multihoming the way v4 PI does for small players >> >> What do you mean by this? Have more than one upstream provider for >> resiliency? > > > think about the small-ish operator that has a couple of transits (for > costs and resiliency reasons) and peers at the local exchange with > other networks. This is a quite common scenario, and they won't give > away the ability to do that quite easily, unless the market changes in > a way that I honestly can't imagine. > > >> >>> - allow 'political' traffic engineering, in addition to whatever >>> technical reason you may have already >> >> >> Are you willing to pay for poluting DFZ routing table? >> > > Are you willing to explain to your colleague in finances why you let > your traffic with $big_provider_A go over commit at premium price, > while traffic with $big_provider_B was under commit? Please note that > the colleague in finances is the same that will deny you the upgrades > of your router memories at budget time. okay it seems to me, that shim6 is a good candidate for your problem with some extension allowing specifing amount of outgoing traffic going on paralel links. Best Regards, Janos Mohacsi From john at sackheads.org Tue Mar 31 17:47:22 2009 From: john at sackheads.org (John Payne) Date: Tue, 31 Mar 2009 11:47:22 -0400 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> <4013b2300903310726u7937f4a1wfda69b460e3bed60@mail.gmail.com> Message-ID: On Mar 31, 2009, at 10:52 AM, Mohacsi Janos wrote: > > > On Tue, 31 Mar 2009, Pierfrancesco Caci wrote: >> Are you willing to explain to your colleague in finances why you let >> your traffic with $big_provider_A go over commit at premium price, >> while traffic with $big_provider_B was under commit? Please note that >> the colleague in finances is the same that will deny you the upgrades >> of your router memories at budget time. > > okay it seems to me, that shim6 is a good candidate for your problem > with some extension allowing specifing amount of outgoing traffic > going on paralel links. How do you then stop all your users configuring their shim6 stacks to prefer $big_provider_A because it's "better performing" ? From fred at cisco.com Tue Mar 31 18:22:07 2009 From: fred at cisco.com (Fred Baker) Date: Tue, 31 Mar 2009 09:22:07 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> Message-ID: <181DC3E8-9ED6-41D6-8F46-93791145A3C6@cisco.com> On Mar 31, 2009, at 5:05 AM, John Payne wrote: >> And hence I raise my question. There are a number of alternatives >> on the table today that give one both multihoming and ISP >> independence. Who has given them five minutes though before >> rejecting them out of hand? > > What alternative gives you multi-homing and leaves the traffic > engineering[*] in the hands of the network team and not the end- > users or server folk? On Mar 30, 2009, at 10:32 AM, Fred Baker wrote: > As I see it, there are six major proposals on the table. > - provider-independent addressing (aka PI) > - provider-dependent addressing (aka PA) > - provider-dependent addressing with multiple prefix overlays in > multihomed networks (shim6) > - private addressing with NAT, converting to provider-dependent > addressing at a DMZ > - private addressing with Network Prefix Translation (GSE) > - exchange-based addressing (aka Metropolitan addressing) With PI, you can do what you do today with PI. With PA, you can do what you do today with provider-allocated addresses. With shim6, you can do what you do today with provider-allocated addresses. It, however, depends on the end system's choice of a source and destination address (they are provider-allocated, but the end system may have multiple addresses from multiple providers) to determine which ISPs the traffic will transit, which is I think what you are concerned about. With NAT, you can do what you do today. With GSE, the edge network (not the host, the administration of the network the host is using) is in control of the edge network routing, and to the ISP that the edge network chooses it looks/works just like PA, because it is. Exchange-based addressing is something where the routing issues are not all worked out, so I have to insert a caveat here in that regard. But one would expect it to work much like today's routing with the exception that the sender's contracts in effect select the transit ISP. Your complaint, as I understand it, is with shim6, and speaking for myself I agree with your concern. From the perspective of the network, the rest devolve to PA, and you can manage routing the way you do with PA. Not that I am asking you to be happy with today's routing protocols, but I view them as a separate question. Traffic engineering can be improved, no doubt. Personally, I would like to see that handled via a new routing protocol, one that explicitly addresses the issue. Why? Because it is a routing problem. But coming back to the question I have been responding to in this thread, the solutions on the table all address the issue of the allocation of addresses for multihoming, with the exception of PI. From ik5pvx at gmail.com Tue Mar 31 18:33:54 2009 From: ik5pvx at gmail.com (Pierfrancesco Caci) Date: Tue, 31 Mar 2009 18:33:54 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> <4013b2300903310726u7937f4a1wfda69b460e3bed60@mail.gmail.com> Message-ID: <4013b2300903310933g35ee6425sf7a6bb202a291e1f@mail.gmail.com> On Tue, Mar 31, 2009 at 16:52, Mohacsi Janos wrote: > okay it seems to me, that shim6 is a good candidate for your problem with > some extension allowing specifing amount of outgoing traffic going on > paralel links. And incoming. Eyeball-prevalent networks will need to do more TE on the incoming traffic. You can't always expect the other side to be fully cooperative, unfortunately. -- Pierfrancesco Caci, ik5pvx From brandon at bogons.net Tue Mar 31 18:35:54 2009 From: brandon at bogons.net (Brandon Butterworth) Date: Tue, 31 Mar 2009 17:35:54 +0100 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <49D22B3B.9010908@airwire.ie> References: <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <49D1E61E.1050405@airwire.ie> <20090331.134428.238903156.he@uninett.no> <49D22B3B.9010908@airwire.ie> Message-ID: <20090331163554.GX28050@virtual.bogons.net> > you can always reject de-aggregated prefixes based on LIR > allocations with filters. That's entirely up to yourself. I've seen this done with v4, it doesn't work. The deaggregators often won't advertise an aggregate. Customers complain and you end up making exceptions or the customers go away. Loads of hassle either way > Any sane > network person will send both the allocated full prefix on top of the > de-aggregated prefixes. The ones that cause the problem aren't sane, they make it your problem > The choice of table-size is yours. Don't prohibit others from diversity > and redundancy. That is the problem, while most accept the insane routes you have to accept them too. The only way to have sanity is for there either to be no way for it to happen or everyone agrees to not let it happen. With the latter there's always someone willing to accept insanity to make more money at everyone elses expense. I think, more so with v6 PI now possible, the loss of deagg TE may be a price we have to pay. If you make a game people will play it brandon From john at sackheads.org Tue Mar 31 18:52:17 2009 From: john at sackheads.org (John Payne) Date: Tue, 31 Mar 2009 12:52:17 -0400 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <181DC3E8-9ED6-41D6-8F46-93791145A3C6@cisco.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <181DC3E8-9ED6-41D6-8F46-93791145A3C6@cisco.com> Message-ID: <3B6E607F-3E8A-47F2-BFE3-5E3A363DCF28@sackheads.org> On Mar 31, 2009, at 12:22 PM, Fred Baker wrote: > > On Mar 31, 2009, at 5:05 AM, John Payne wrote: > >>> And hence I raise my question. There are a number of alternatives >>> on the table today that give one both multihoming and ISP >>> independence. Who has given them five minutes though before >>> rejecting them out of hand? >> >> What alternative gives you multi-homing and leaves the traffic >> engineering[*] in the hands of the network team and not the end- >> users or server folk? > > > On Mar 30, 2009, at 10:32 AM, Fred Baker wrote: >> As I see it, there are six major proposals on the table. >> - provider-independent addressing (aka PI) >> - provider-dependent addressing (aka PA) >> - provider-dependent addressing with multiple prefix overlays in >> multihomed networks (shim6) >> - private addressing with NAT, converting to provider-dependent >> addressing at a DMZ >> - private addressing with Network Prefix Translation (GSE) >> - exchange-based addressing (aka Metropolitan addressing) > > > With PI, you can do what you do today with PI. Yup, except you have to listen to the shim6 proponents screaming about the size of the routing table. > With PA, you can do what you do today with provider-allocated > addresses. Not really.... in IPv4 land, people can and do deaggregate PA space, treating it as PI. Whether that's the right thing or not doesn't matter. First hit issues. > With shim6, you can do what you do today with provider-allocated > addresses. It, however, depends on the end system's choice of a > source and destination address (they are provider-allocated, but the > end system may have multiple addresses from multiple providers) to > determine which ISPs the traffic will transit, which is I think what > you are concerned about. That's part of it.... the end system is not the place to be making routing decisions. Other issues surround the first hit. > With NAT, you can do what you do today. First hit issues > With GSE, the edge network (not the host, the administration of the > network the host is using) is in control of the edge network > routing, and to the ISP that the edge network chooses it looks/works > just like PA, because it is. GSE I haven't paid much attention to because I was told it was dead :) LISP is somewhat interesting > Exchange-based addressing is something where the routing issues are > not all worked out, so I have to insert a caveat here in that > regard. But one would expect it to work much like today's routing > with the exception that the sender's contracts in effect select the > transit ISP. > > Your complaint, as I understand it, is with shim6, and speaking for > myself I agree with your concern. From the perspective of the > network, the rest devolve to PA, and you can manage routing the way > you do with PA. Not that I am asking you to be happy with today's > routing protocols, but I view them as a separate question. > > Traffic engineering can be improved, no doubt. Personally, I would > like to see that handled via a new routing protocol, one that > explicitly addresses the issue. Why? Because it is a routing > problem. But coming back to the question I have been responding to > in this thread, the solutions on the table all address the issue of > the allocation of addresses for multihoming, with the exception of PI. I multihome 2 different sets of sites. 1) User-centric 2) Server-centric My argument that the path selection must be done at the site level and not at the host applies to both. NAT is an option for the user-centric sites for sure. However, neither NAT, nor shim6, nor PA (non-deagg'd) deal well with the server- centric sites when one of the links is down. Waiting for TCP timeouts on the first SYN isn't an acceptable model. From spz at serpens.de Tue Mar 31 19:00:15 2009 From: spz at serpens.de (S.P.Zeidler) Date: Tue, 31 Mar 2009 19:00:15 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> References: <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> Message-ID: <20090331170015.GF17392@serpens.de> Hi, Thus wrote Fred Baker (fred at cisco.com): > On Mar 30, 2009, at 11:47 PM, S.P.Zeidler wrote: > >> I don't see that following, at least not with a sane PI assignment >> policy. >> PI space being available does not mean that there would be no more PA >> at all. > > See, on that you and I agree. There is a place for PI addressing. I > might even hazard a guess that it is similar to today's place for AS > numbers. > > Problem is, folks in that range are getting PI addressing now, and we're > still hearing statements like > > On Mar 30, 2009, at 9:48 AM, Udo Steinegger wrote: >> But for the commercial non-ISP world, at least in old Europe, one of >> the bigger Problems is to get >> the same level of provider independence in IPv6 (read: PI address >> space), that they are used to in the IPv4 world. Traditionally, in the RIPE region (not counting historical PI from before PA was invented), the way to get PI space in v4 is to get an AS first (or mostly, to get an AS and the PI space to route with it as a bundle). I would expect that the requirements to get IPv6 PI that gets nodded off include that you are having or asking in the bundle for an AS, and you don't get that unless you also show that you have a contract for more than one upstream (the current proposal for IPv6 PI in the RIPE region contains all these requirements, and also that either a LIR or the RIR is getting a yearly fee that more or less makes sure that when the PI holder goes belly-up, the address space can get collected). >> As long as this is not properly addressed, then people are very >> reluctant to move towards IPv6 and stick with IPv4 until the last day. > > The alternatives are fine for "someone else", but ask anyone, and they > want their PI. > > And hence I raise my question. There are a number of alternatives on the > table today that give one both multihoming and ISP independence. Who has > given them five minutes though before rejecting them out of hand? I hate to disappoint you, but, no. When the cost of PI is that you are a BGP speaker even companies like my current employer who does have people already who can handle BGP fine (if I may say so myself) look at the effort involved compared to the gain, and just take several uplinks and a distribution of favoured routes by script that can easily be flipped when one uplink fails. Sessions terminating in such a case are annoying for us, but not critical; in IPv6 we're ideal candidates for more of this kind of multihoming. Just because there is PI does not mean the alternate multihoming solutions won't get used. They are often lots cheaper. It is not every baker shop who is going to ask for PI, starting with the simple reason they never heard about it and don't bother enough to do that ever. It's mostly only companies that offer service via the Internet as their purpose of being that will bother. If what you need is control over your routing, if there is no PI and the need is pressing enough you'll just become an enterprise LIR (it's not that expensive a yearly fee to be a deterrent). Where is the advantage to the whole in forcing that? regards, spz -- spz at serpens.de (S.P.Zeidler) From fred at cisco.com Tue Mar 31 19:09:45 2009 From: fred at cisco.com (Fred Baker) Date: Tue, 31 Mar 2009 10:09:45 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <3B6E607F-3E8A-47F2-BFE3-5E3A363DCF28@sackheads.org> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <181DC3E8-9ED6-41D6-8F46-93791145A3C6@cisco.com> <3B6E607F-3E8A-47F2-BFE3-5E3A363DCF28@sackheads.org> Message-ID: <1A1BEB30-1151-4064-AA66-AAD1B23FBD8B@cisco.com> On Mar 31, 2009, at 9:52 AM, John Payne wrote: > However, neither NAT, nor shim6, nor PA (non-deagg'd) deal well with > the server-centric sites when one of the links is down. Waiting for > TCP timeouts on the first SYN isn't an acceptable model. OK, so you're looking for fast re-route, and that primarily for servers. I said there was a case for PI, and that is one summarization of the case. That doesn't mean that all sites everywhere should have PI addresses. How many servers are in hosting facilities? It means that the servers need them. From spz at serpens.de Tue Mar 31 19:34:47 2009 From: spz at serpens.de (S.P.Zeidler) Date: Tue, 31 Mar 2009 19:34:47 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <20090331.134428.238903156.he@uninett.no> References: <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <49D1E61E.1050405@airwire.ie> <20090331.134428.238903156.he@uninett.no> Message-ID: <20090331173447.GH17392@serpens.de> Hi Havard, Thus wrote Havard Eidnes (he at nordu.net): > > > Also, most ASs would only announce one prefix instead of the > > > zoo most keep today. > > > > And on this one two. We'll have one prefix per AS (more or > > less). That will be less prefixes than are announced today for > > the current autonomous systems. > > Except the desire to do traffic engineering to spread the > incoming load among multiple upstreams will tend to push people > into doing de-aggregation of their single prefix, and since we > have no good tools to limit the distribution of a given prefix I kind of like Gerds filter :-) I like even more tightly tailored filters even better, btw, and think they ought to be used more. :) Besides, we don't have routable space in v4 below /24 unless by special agreement, either, do we? regards, spz -- spz at serpens.de (S.P.Zeidler) From martin at airwire.ie Tue Mar 31 19:52:42 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 31 Mar 2009 18:52:42 +0100 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <20090331163554.GX28050@virtual.bogons.net> References: <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <49D1E61E.1050405@airwire.ie> <20090331.134428.238903156.he@uninett.no> <49D22B3B.9010908@airwire.ie> <20090331163554.GX28050@virtual.bogons.net> Message-ID: <49D2586A.3050709@airwire.ie> Brandon Butterworth wrote: >> you can always reject de-aggregated prefixes based on LIR >> allocations with filters. That's entirely up to yourself. > > I've seen this done with v4, it doesn't work. The deaggregators > often won't advertise an aggregate. Customers complain and you > end up making exceptions or the customers go away. Loads of hassle > either way It's simple. We're very much straight up with our customers and engage people doing things like that. If they don't fix it, we'll advise our customers not to deal with'em :) >> Any sane >> network person will send both the allocated full prefix on top of the >> de-aggregated prefixes. > > The ones that cause the problem aren't sane, they make it your problem They just can't get to us then. Their choice. We'll approach them on it though. >> The choice of table-size is yours. Don't prohibit others from diversity >> and redundancy. > > That is the problem, while most accept the insane routes you have to > accept them too. The only way to have sanity is for there either to be > no way for it to happen or everyone agrees to not let it happen. With > the latter there's always someone willing to accept insanity to make more > money at everyone elses expense. > > I think, more so with v6 PI now possible, the loss of deagg TE may > be a price we have to pay. The more networks, that start doing IRR based filtering, the more we'll be getting rid of insanity like that. It's because autonomous networks don't challenge it often enough, that we've got to live with the insanity. Hey, I know of a tier1 carrier that doesn't route anything smaller than a v6 /32, be it allocated by a RIR or not. Their table definatly won't see too much of a growth due to de-aggregation. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From john at sackheads.org Tue Mar 31 20:05:32 2009 From: john at sackheads.org (John Payne) Date: Tue, 31 Mar 2009 14:05:32 -0400 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <1A1BEB30-1151-4064-AA66-AAD1B23FBD8B@cisco.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <181DC3E8-9ED6-41D6-8F46-93791145A3C6@cisco.com> <3B6E607F-3E8A-47F2-BFE3-5E3A363DCF28@sackheads.org> <1A1BEB30-1151-4064-AA66-AAD1B23FBD8B@cisco.com> Message-ID: <2A8E089D-993A-4170-94F6-CD96E44C4C00@sackheads.org> On Mar 31, 2009, at 1:09 PM, Fred Baker wrote: > > On Mar 31, 2009, at 9:52 AM, John Payne wrote: > >> However, neither NAT, nor shim6, nor PA (non-deagg'd) deal well >> with the server-centric sites when one of the links is down. >> Waiting for TCP timeouts on the first SYN isn't an acceptable model. > > OK, so you're looking for fast re-route, and that primarily for > servers. I said there was a case for PI, and that is one > summarization of the case. > > That doesn't mean that all sites everywhere should have PI > addresses. How many servers are in hosting facilities? It means that > the servers need them. TCP timeouts on the SYN/ACK are also unacceptable :) That's a little easier to control with NAT... not so much with the other options though.... From jabley at hopcount.ca Tue Mar 31 21:18:22 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 31 Mar 2009 15:18:22 -0400 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> <4013b2300903310726u7937f4a1wfda69b460e3bed60@mail.gmail.com> Message-ID: On 31-Mar-2009, at 10:52, Mohacsi Janos wrote: > okay it seems to me, that shim6 is a good candidate for your problem > with some extension allowing specifing amount of outgoing traffic > going on paralel links. It seemed to a lot of people that shim6 was the best answer to this general problem space. Unfortunately, many operators thought otherwise, and said so loudly. Joe From leo.vegoda at icann.org Tue Mar 31 22:08:37 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 31 Mar 2009 13:08:37 -0700 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <20090331170015.GF17392@serpens.de> Message-ID: On 31/03/2009 10:00, "S.P.Zeidler" wrote: [...] > Traditionally, in the RIPE region (not counting historical PI from before > PA was invented), the way to get PI space in v4 is to get an AS first > (or mostly, to get an AS and the PI space to route with it as a bundle). I recall networks qualifying for exactly as much IPv4 PI space as they would qualify for PA space without a multi-homing requirement. So very small networks might well only get a /29 of PI space. This high granularity of PI assignments was a possibly a disincentive to an excessive number of requests. Or it might have encouraged people to inflate the interface count to something more than 128, ensuring a /24 assignment. In any case, it looks like the number of PI assignments exceeded the number of PA allocations back in 2003: http://ripe.net/ripe/meetings/ripe-54/presentations/RIPE_NCC_Statistics.pdf (slide 9) I note that RIPE policy proposal 2006-05 would set the minimum assignment size to /24 in some multi-homing cases. On the other hand, things seem to be changing in a way that assigns a higher ongoing cost to PI assignments, which might balance out the equation somewhat. Time will tell. Regards, Leo From benny+usenet at amorsen.dk Fri Mar 27 15:01:13 2009 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Fri, 27 Mar 2009 15:01:13 +0100 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> (Fred Baker's message of "Thu\, 26 Mar 2009 18\:53\:50 -0700") References: <20070430152601.GA30632@data.fire-world.de> <20070430153017.GU73965@Space.Net>

<5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> Message-ID: Fred Baker writes: > Also, I think it is only fair to point out that they didn't have the > option of making it backwards compatible with IPv4; it's not that they > didn't, it's that they couldn't. How, precisely, would you make an > IPv4 packet that has longer addresses? IPv4 forces any change to the > header to become a new protocol. It doesn't, in hindsight. You could have added extra, optional fields to the IP header, containing extra source or destination IP addresses. NAT devices would then move the original IP address into the new src ip address header and put the NAT-address into the src ip address. If the host at the remote end understood the extra header, it would copy it into the extra dst ip address header of the return packet, and the NAT would know where to send the packet without connection tracking. This mechanism would also make it possible to directly address hosts behind NAT. If a particular host doesn't understand the new header fields, it should simply ignore it, and the NAT then has to handle the packet using connection tracking. Advantages: Routers don't need to be upgraded at all, except for NAT routers (and those are commonly upgraded already, unlike core routers). Host IP stacks would need upgrading, but most services would still work between old hosts and new hosts (and host IPv6 stacks have turned out to be ready way ahead of everything else). Applications would need a few tweaks for full functionality, but legacy applications would still work. It would be a lot uglier than the shiny IPv6 future, but it could be done, and it would mean that there would always be more content available for an upgraded host/network than for the legacy hosts/networks. /Benny