Re: IPv6 internet broken, Verizon route prefix length policy
Seth Mattinen wrote: If you are interested, I don't want to spam the list with my Verizon horror story, but you can read it here: http://www.rollernet.us/wordpress/category/ipv6/ At the risk of sounding like I'm piling on, I'm in the same basically the same boat that Seth is, except that I do know who my account rep is and have been in touch with him. Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon. I've been told that Verizon is discussing this policy and whether it should be updated, but until they update their policy to be in line with the IPv6 Internet allocation/assignment policies from at least September of 2006 (when ARIN assigned their first /48 from 2620:0::/23), if your announcements are only longer than /32, you should be aware that Verizon is completely unreachable for you - even if you are a Verizon customer directly. -- Jeff McAdams
Re: IPv6 internet broken, Verizon route prefix length policy
In message <4ad382e4.9010...@iglou.com>, Jeff McAdams writes: > Seth Mattinen wrote: > > > If you are interested, I don't want to spam the list with my Verizon > > horror story, but you can read it here: > > http://www.rollernet.us/wordpress/category/ipv6/ > > At the risk of sounding like I'm piling on, I'm in the same basically > the same boat that Seth is, except that I do know who my account rep is > and have been in touch with him. > > Verizon's policy has been related to me that they will not accept or > propogate any IPv6 route advertisements with prefix lengths longer than > /32. Full stop. So that even includes those of us that have /48 PI > space from ARIN that are direct customers of Verizon. Looks like Verizon doesn't want any IPv6 customers. If a company has idiotic policies like this vote with your wallet. > I've been told that Verizon is discussing this policy and whether it > should be updated, but until they update their policy to be in line with > the IPv6 Internet allocation/assignment policies from at least September > of 2006 (when ARIN assigned their first /48 from 2620:0::/23), if your > announcements are only longer than /32, you should be aware that Verizon > is completely unreachable for you - even if you are a Verizon customer > directly. > > -- > Jeff McAdams > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 internet broken, Verizon route prefix length policy
On Tue, 2009-10-13 at 09:40 +1100, Mark Andrews wrote: > > Verizon's policy has been related to me that they will not accept > or > > propogate any IPv6 route advertisements with prefix lengths longer > than > > /32. Full stop. So that even includes those of us that have /48 > PI > > space from ARIN that are direct customers of Verizon. > > Looks like Verizon doesn't want any IPv6 customers. If a company > has idiotic policies like this vote with your wallet. Unfortunately, not everyone always has that choice.
Re: IPv6 internet broken, Verizon route prefix length policy
In message <1255388942.12984.1.ca...@acer-laptop>, Bret Clark writes: > On Tue, 2009-10-13 at 09:40 +1100, Mark Andrews wrote: > > > > Verizon's policy has been related to me that they will not accept > > or > > > propogate any IPv6 route advertisements with prefix lengths longer > > than > > > /32. Full stop. So that even includes those of us that have /48 > > PI > > > space from ARIN that are direct customers of Verizon. > > > > Looks like Verizon doesn't want any IPv6 customers. If a company > > has idiotic policies like this vote with your wallet. > > Unfortunately, not everyone always has that choice. If there isn't as choice then regulation is required. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 internet broken, Verizon route prefix length policy
Mark Andrews wrote: > In message <4ad382e4.9010...@iglou.com>, Jeff McAdams writes: >> Seth Mattinen wrote: >> >>> If you are interested, I don't want to spam the list with my Verizon >>> horror story, but you can read it here: >>> http://www.rollernet.us/wordpress/category/ipv6/ >> At the risk of sounding like I'm piling on, I'm in the same basically >> the same boat that Seth is, except that I do know who my account rep is >> and have been in touch with him. >> >> Verizon's policy has been related to me that they will not accept or >> propogate any IPv6 route advertisements with prefix lengths longer than >> /32. Full stop. So that even includes those of us that have /48 PI >> space from ARIN that are direct customers of Verizon. > > Looks like Verizon doesn't want any IPv6 customers. If a company > has idiotic policies like this vote with your wallet. > I am, sort of; I'm a new customer so they installed, but I haven't accepted it yet. Unfortunately I won't be able to get back to dealing with it until late next week at the earliest as I'm in the middle of moving to a new facility. ~Seth
Re: IPv6 internet broken, Verizon route prefix length policy
Mark, On Oct 12, 2009, at 3:40 PM, Mark Andrews wrote: >> Verizon's policy has been related to me that they will not accept or >> propogate any IPv6 route advertisements with prefix lengths longer than >> /32. Full stop. So that even includes those of us that have /48 PI >> space from ARIN that are direct customers of Verizon. > > Looks like Verizon doesn't want any IPv6 customers. If a company > has idiotic policies like this vote with your wallet. Not knowing all the details, it is difficult for me to judge, however it is worth observing that provider independent addresses, regardless of where they come from or whether they are IPv4 or IPv6 simply do not scale. In the face of everybody and their mother now being able to obtain PI prefixes from all the RIRs, any ISP that handles full routing is going to have to hope their router vendor of choice can keep buying more/bigger CAMs (passing the expense on to the ISP who will pass it on to their customers) and/or they'll start implementing the same sort of prefix length limitations that we saw back in the mid-90s. And, of course, we have IPv4 runout in the near future with the inevitable market which will almost certainly promote the use of longer prefixes. In other words, get used to it. Regards, -drc
Re: IPv6 internet broken, Verizon route prefix length policy
On 13/10/2009, at 8:26, Jeff McAdams wrote: Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have / 48 PI space from ARIN that are direct customers of Verizon. What about the small matter of all of the current s for the the IPv6 enabled root DNS servers? -- Nathan Ward
Re: IPv6 internet broken, Verizon route prefix length policy
On Oct 12, 2009, at 4:37 PM, David Conrad wrote: Mark, On Oct 12, 2009, at 3:40 PM, Mark Andrews wrote: Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon. Looks like Verizon doesn't want any IPv6 customers. If a company has idiotic policies like this vote with your wallet. Not knowing all the details, it is difficult for me to judge, however it is worth observing that provider independent addresses, regardless of where they come from or whether they are IPv4 or IPv6 simply do not scale. In the face of everybody and their mother now being able to obtain PI prefixes from all the RIRs, any ISP that handles full routing is going to have to hope their router vendor of choice can keep buying more/bigger CAMs (passing the expense on to the ISP who will pass it on to their customers) and/or they'll start implementing the same sort of prefix length limitations that we saw back in the mid-90s. I disagree. With IPv4 the bigger issue is that everyone and their mom has 9 different announcements behind their single ASN. With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come much closer. Even if the average drops to 1/2, you're talking about a 70,000 route table today, and, likely growth in the 250-300,000 route range over the next 5-10 years. CAM will probably scale faster than that. The problematic time scale is that time where we have to support dual stack for a majority of the network. That's what will really stress the CAM as the IPv6 table becomes meaningfully large (but not huge) and the IPv4 table cannot yet be retired. And, of course, we have IPv4 runout in the near future with the inevitable market which will almost certainly promote the use of longer prefixes. There is that problem, too. Personally, I think the market was a horrible idea, but, it had way too much momentum for me to be able to stop it. In other words, get used to it. Pretty much. I think eventually, we're going to have to look at moving to an ID/Locator split method in the IDR realm. Owen
Re: IPv6 internet broken, Verizon route prefix length policy
From where I sit, it looks like: a.root-servers.net has IPv6 address 2001:503:ba3e::2:30 BGP routing table entry for 2001:503:ba3e::/48 f.root-servers.net has IPv6 address 2001:500:2f::f BGP routing table entry for 2001:500:2f::/48 h.root-servers.net has IPv6 address 2001:500:1::803f:235 BGP routing table entry for 2001:500:1::/48 j.root-servers.net has IPv6 address 2001:503:c27::2:30 BGP routing table entry for 2001:503:c27::/48 k.root-servers.net has IPv6 address 2001:7fd::1 BGP routing table entry for 2001:7fd::/32 l.root-servers.net has IPv6 address 2001:500:3::42 BGP routing table entry for 2001:500:3::/48 m.root-servers.net has IPv6 address 2001:dc3::35 BGP routing table entry for 2001:dc3::/32 b.root-servers.net has no record c.root-servers.net has no record d.root-servers.net has no record e.root-servers.net has no record g.root-servers.net has no record i.root-servers.net has no record So... Likely, Verizon customers can reach k and m root servers via IPv6 and not the others. The fact that b, c, d, e, g, and i do not have records actually concerns me more than the fact that Verizon customers can only reach two. Owen On Oct 12, 2009, at 4:39 PM, Nathan Ward wrote: On 13/10/2009, at 8:26, Jeff McAdams wrote: Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon. What about the small matter of all of the current s for the the IPv6 enabled root DNS servers? -- Nathan Ward
Re: IPv6 internet broken, Verizon route prefix length policy
Owen, On Oct 12, 2009, at 5:09 PM, Owen DeLong wrote: > With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come much > closer. I wasn't aware people would be doing traffic engineering differently in IPv6 than in IPv4. > Even if the average drops to 1/2, you're talking about a 70,000 route table > today, How big are IPv6 objects in CAMs again? > and, likely growth in the 250-300,000 route range over the next 5-10 years. > CAM will probably scale faster than that. I've heard differing opinions on this (e.g., router ASICs being both some of the most complicated ASICs ever made and being non-commodity parts hence not necessarily following Moore's Law, pin density in those ASICs reaching a point where you start running into crosstalk problems, cats and dogs living together, mass hysteria, etc). I'm not a hardware guy so I'll just stare blankly. > The problematic time scale is that time where we have to support dual stack > for a majority of the network. That's what will > really stress the CAM as the IPv6 table becomes meaningfully large (but not > huge) and the IPv4 table cannot yet be > retired. Right. And when are we planning on retiring IPv4 again? Interestingly, if you're an ISP and you don't want to redeploy your insanely expensive high end routers with the huge CAMs, you might look to see which prefixes you could drop that would cause the least impact to the majority of your customers. In this light, filtering the crap out of IPv6 would appear to make business sense. > I think eventually, we're going to have to look at moving to an ID/Locator > split method in the IDR realm. The big challenge with this is backwards compatibility... Regards, -drc
Re: IPv6 internet broken, Verizon route prefix length policy
On Mon, Oct 12, 2009 at 8:16 PM, Owen DeLong wrote: > From where I sit, it looks like: ..snip.. > So... Likely, Verizon customers can reach k and m root servers via IPv6 > and not the others. or.. vzb (is now dead, it's all vz) has holes in filters to permit prefixes of certain lengths or certain prefixes exactly. I believe since I can reach k-root from my uu-connected + uu-v6'd device that'd be the case. -chris
Re: IPv6 internet broken, Verizon route prefix length policy
On Mon, Oct 12, 2009 at 8:40 PM, David Conrad wrote: > On Oct 12, 2009, at 5:09 PM, Owen DeLong wrote: >> and, likely growth in the 250-300,000 route range over the next 5-10 years. >> CAM will probably scale faster than that. > > I've heard differing opinions on this (e.g., router ASICs being both some of > the most complicated > ASICs ever made and being non-commodity parts hence not necessarily following > Moore's Law, > pin density in those ASICs reaching a point where you start running into > crosstalk problems, > cats and dogs living together, mass hysteria, etc). I'm not a hardware guy > so I'll just stare > blankly. I thought Tony's preso from RAWS was available or part of the report, no? (which seemed pretty clear to me about cam sizes and asic capabilities not going to meet the needs within the next 5-7 years) -chris
Re: IPv6 internet broken, Verizon route prefix length policy
Owen DeLong wrote: > From where I sit, it looks like: > > a.root-servers.net has IPv6 address 2001:503:ba3e::2:30 > BGP routing table entry for 2001:503:ba3e::/48 > > f.root-servers.net has IPv6 address 2001:500:2f::f > BGP routing table entry for 2001:500:2f::/48 > > h.root-servers.net has IPv6 address 2001:500:1::803f:235 > BGP routing table entry for 2001:500:1::/48 > > j.root-servers.net has IPv6 address 2001:503:c27::2:30 > BGP routing table entry for 2001:503:c27::/48 > > k.root-servers.net has IPv6 address 2001:7fd::1 > BGP routing table entry for 2001:7fd::/32 > > l.root-servers.net has IPv6 address 2001:500:3::42 > BGP routing table entry for 2001:500:3::/48 > > m.root-servers.net has IPv6 address 2001:dc3::35 > BGP routing table entry for 2001:dc3::/32 > > > b.root-servers.net has no record > c.root-servers.net has no record > d.root-servers.net has no record > e.root-servers.net has no record > g.root-servers.net has no record > i.root-servers.net has no record > > > So... Likely, Verizon customers can reach k and m root servers via IPv6 > and not the others. > I can see the /48's out of 2001 in Verizon's table. ~Seth
Re: IPv6 internet broken, Verizon route prefix length policy
Owen DeLong wrote: From where I sit, it looks like: a.root-servers.net has IPv6 address 2001:503:ba3e::2:30 BGP routing table entry for 2001:503:ba3e::/48 f.root-servers.net has IPv6 address 2001:500:2f::f BGP routing table entry for 2001:500:2f::/48 h.root-servers.net has IPv6 address 2001:500:1::803f:235 BGP routing table entry for 2001:500:1::/48 j.root-servers.net has IPv6 address 2001:503:c27::2:30 BGP routing table entry for 2001:503:c27::/48 k.root-servers.net has IPv6 address 2001:7fd::1 BGP routing table entry for 2001:7fd::/32 l.root-servers.net has IPv6 address 2001:500:3::42 BGP routing table entry for 2001:500:3::/48 m.root-servers.net has IPv6 address 2001:dc3::35 BGP routing table entry for 2001:dc3::/32 So... Likely, Verizon customers can reach k and m root servers via IPv6 and not the others. I can see all of those through Verizon, so I'm not sure of how their policy applies, or if they're making an exception for these, but they are visible through Verizon. -- Jeff McAdams je...@iglou.com
Re: IPv6 internet broken, Verizon route prefix length policy
David Conrad wrote: On Oct 12, 2009, at 3:40 PM, Mark Andrews wrote: Verizon's policy has been related to me that they will not accept or propogate any IPv6 route advertisements with prefix lengths longer than /32. Full stop. So that even includes those of us that have /48 PI space from ARIN that are direct customers of Verizon. Looks like Verizon doesn't want any IPv6 customers. If a company has idiotic policies like this vote with your wallet. Not knowing all the details, it is difficult for me to judge, however it is worth observing that provider independent addresses, regardless of where they come from or whether they are IPv4 or IPv6 simply do not scale. In the face of everybody and their mother now being able to obtain PI prefixes from all the RIRs, any ISP that handles full routing is going to have to hope their router vendor of choice can keep buying more/bigger CAMs (passing the expense on to the ISP who will pass it on to their customers) and/or they'll start implementing the same sort of prefix length limitations that we saw back in the mid-90s. And, of course, we have IPv4 runout in the near future with the inevitable market which will almost certainly promote the use of longer prefixes. And I look at the other side of it. For us "mere" end-user organization (ie, not big backbone ISPs who have dominated the discussion for so long), IPv6 without PI is an utter and complete non-starter. Despite how huge of a proponent of IPv6 deployment that I am, until PI space was available, I didn't start the work, because without PI space, its utter foolishness for a company that depends on their Internet access to move forward. I don't think its a coincidence that we've seen a big uptick in deployment of IPv6 since PI space became available. Telling end-user organizations to get a block from each upstream and multihome by putting an address from each upstream on every system is now and always has been a bad joke. In other words, get used to it. In other words, figure it out. Either we'll have PI space in IPv6, or IPv4 is going to get *crazy* fragmented as continually smaller blocks are bought and sold. If you want to keep your cam tables from blowing up, I truly think the way forward is to get people to IPv6 as quickly as possible, where they can get blocks big enough to put all of their address space in 1 or 2 blocks, rather than the 4, 7 or more, blocks that they're currently using for IPv4. And, no, not everyone deaggregates for TE purposes. No network that I've ever been in charge of has ever advertised anything but the most aggregated blocks that we could given the allocations/assignments we had. We'll have savings from that, and if you want to filter to limit deaggregating for TE purposes, I'm quite OK with that. But if you cut out PI space, you're dead in the water, we just can't have that. -- Jeff McAdams
Re: IPv6 internet broken, Verizon route prefix length policy
In a message written on Mon, Oct 12, 2009 at 05:09:41PM -0700, Owen DeLong wrote: > With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come > much closer. Even if the average drops to 1/2, you're > talking about a 70,000 route table today, and, likely growth in the > 250-300,000 route range over the next 5-10 years. > CAM will probably scale faster than that. Here's a presentation from 2007. http://www.vaf.net/~vaf/apricot-plenary.pdf On page 13, you'll find a table. It starts with numbers in November of 2006, and makes projections. The 5 year projections (Nov 2011) have already been exceeded, in both IPv4 Internet Routes and Active ASN's. The problem isn't that we have 300,000 "global routes" on the Internet (http://www.cidr-report.org/as2.0/#General_Status), but that there are other things that compete for TCAM space. It's that TCAM must hold not only the global routes, but also: - Internal routes. Your IGP routes, no-exported customer deagregations, blackhole routes, etc. - MPLS Labels, including: - MPLS Traffic Engineering - MPLS VPN Identifiers - Virtual Routing Instances for Layer 3 VPN's. - ARP Entries - Multicast Routes Unfortunately details are hard to come by as most of the folks who see this in any significant way (e.g. global "tier 1" full service ISP's) tend not to release too many specific numbers for competitive reasons. That said, even using some basic assumptions (some of which are in the preso) those 300,000 global routes might have added to them: 300,000 global routes 150,000 internal routes 20,000 MPLS labels 200,000 VPN/VRF Routes 5,000 ARP Entries 20,000 Multicast Routes 695,000 TCAM Entries Consumed That's today, right now, in major ISP's routers. All the sudden those "1 million route" core routers don't seem so large. Keep in mind we've passed the 2006 projection in this report in 3 years, not 5. So we're growing faster than we expected. Add in your 70,000 route IPv6 table, plus growth, and the 1 million route routers are probably failing sometime in 2011. Someone will likely pipe up, but Cisco has a 3 million route processor now! (I believe that is the spec of the just announced PRP3, but can't find a reference on Cisco's web site). Yes, that's a route processor that can do the job, but in these high end boxes the TCAM is distributed on the linecards. So upgrading from the 1 million route TCAM core routers to the 3 Million route TCAM means upgrading every linecard in each router you upgrade. Ouch. The picture I painted above is actually the rosy part of the picture. Many of these backbones have older equipment in the core which can't even do 1M routes. They use careful design and other techniques to limit the number of entries particular boxes have to see. > The problematic time scale is that time where we have to support dual > stack for a majority of the network. That's what will > really stress the CAM as the IPv6 table becomes meaningfully large > (but not huge) and the IPv4 table cannot yet be > retired. While I think Verizon's move is somewhat premature, I can see why they might be afraid of routing table growth. I think there is an extremely high probability that given the growth of the table due to primarily to IPv6 and the growth of MPLS VPN offerings, combined with the current economic climate which has reduced the capital available for upgrades that we will see several providers "hit the wall" of various popular bits of equipment. I think some of the engineering staff at various major providers has already realized this as well. We don't seem to have a technological solution. LISP has scaling issues of its own, and would require swapping out a huge amount of equipment. TCAM scaling is at best cost prohibitive, at worst not possible due to the physical ram speed, and both are being improved at a modest rate (the preso suggests 10% per year). Worse, the problem is being made worse at an alarming rate. MPLS VPN's are quicky replacing frame relay, ATM, and leased line circuits adding MPLS lables and VPN/VRF routes to edge routers. Various RIR's are pushing "PI for all" in IPv6 based on addressing availbility. Some networks are actually finally using multicast for IPTV services, generating much larger number of entries than the global multicast table would otherwise indicate. The next 5 years may bring internet instability problems and route filtering on a scale we haven't seen since the early 90's. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpdu7y1p8KMa.pgp Description: PGP signature
Re: IPv6 internet broken, Verizon route prefix length policy
I get asked often enough about what's in 701's IPv6 routes so I just dumped it to a plain text file for anyone interested: http://www.rollernet.us/wordpress/as701-ipv6/ ~Seth
Re: IPv6 internet broken, Verizon route prefix length policy
Leo Bicknell wrote: > > Worse, the problem is being made worse at an alarming rate. MPLS > VPN's are quicky replacing frame relay, ATM, and leased line circuits > adding MPLS lables and VPN/VRF routes to edge routers. Various > RIR's are pushing "PI for all" in IPv6 based on addressing availbility. > Some networks are actually finally using multicast for IPTV services, > generating much larger number of entries than the global multicast table > would otherwise indicate. > It's not the RIR's fault. IPv6 wasn't designed with any kind of workable site multihoming. The only goal seems to have been to limit /32's to an "ISP" but screw you if you aren't one. There was no alternative and it's been how long now? PI, multihoming, multicast, etc. is reality because the internet is now Very Serious Business for many, many people. Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a debate about them, so I'll just say that if there had been a viable alternative to multihoming as we know it I think it would have been given a go before policy got pushed to the RIR's to allow IPv6 PI. ~Seth
Re: IPv6 internet broken, Verizon route prefix length policy
On Mon, Oct 12, 2009, Seth Mattinen wrote: > It's not the RIR's fault. IPv6 wasn't designed with any kind of workable > site multihoming. The only goal seems to have been to limit /32's to an > "ISP" but screw you if you aren't one. There was no alternative and it's > been how long now? PI, multihoming, multicast, etc. is reality because > the internet is now Very Serious Business for many, many people. IPv6 -policy- wasn't initially designed for any workable site multihoming. The addressing and BGP stuff works fine for it. Its just not "different" to the issues faced with IPv4. adrian
Re: IPv6 internet broken, Verizon route prefix length policy
On Mon, Oct 12, 2009 at 10:13 PM, Seth Mattinen wrote: > Leo Bicknell wrote: >> >> Worse, the problem is being made worse at an alarming rate. MPLS >> VPN's are quicky replacing frame relay, ATM, and leased line circuits >> adding MPLS lables and VPN/VRF routes to edge routers. Various >> RIR's are pushing "PI for all" in IPv6 based on addressing availbility. >> Some networks are actually finally using multicast for IPTV services, >> generating much larger number of entries than the global multicast table >> would otherwise indicate. >> > > It's not the RIR's fault. IPv6 wasn't designed with any kind of workable > site multihoming. The only goal seems to have been to limit /32's to an here's where a pointer to this dicussion of ~4yrs ago should be (on this list no less)... that said: "Hey, this is afu, if you as operators want this to work properly, please, please, please get your butts on v6...@ietf and make some noise." I believe that'd have been from me, but marla azinger also sent out some similar emails and presented 2-3 times at past nanog meetings about multihoming options wrt ipv6. This ain't gonna get fixed by nanog-kvetching. > "ISP" but screw you if you aren't one. There was no alternative and it's > been how long now? PI, multihoming, multicast, etc. is reality because > the internet is now Very Serious Business for many, many people. v6 was designed in an era quite different than today's network. there were a large number of assumptions made, practically none of which hold water today. this can't get fixed here, please see v6man/v6...@ietf. Alternately please see r...@ietf or l...@ietf, rrg's looking to make a decision on their research 'soon', lisp is looking for active folks to provide comment/direction... > Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a there are no (save lisp) network based 'hacks' for this... shim6/hip/mip all basically do host-level multihoming, which is cool, and may be useful to some folks, but they are not useful for folks trying to do TE in the network. (which also was hashed out quite a bit on this list) > debate about them, so I'll just say that if there had been a viable > alternative to multihoming as we know it I think it would have been > given a go before policy got pushed to the RIR's to allow IPv6 PI. 100% agreement... wanna join in the discussion and offer some options/fixes/commentary? -chris
Re: IPv6 internet broken, Verizon route prefix length policy
In a message written on Mon, Oct 12, 2009 at 07:13:04PM -0700, Seth Mattinen wrote: > Leo Bicknell wrote: > > Worse, the problem is being made worse at an alarming rate. MPLS > > VPN's are quicky replacing frame relay, ATM, and leased line circuits > > adding MPLS lables and VPN/VRF routes to edge routers. Various > > RIR's are pushing "PI for all" in IPv6 based on addressing availbility. > > Some networks are actually finally using multicast for IPTV services, > > generating much larger number of entries than the global multicast table > > would otherwise indicate. > > It's not the RIR's fault. IPv6 wasn't designed with any kind of workable > site multihoming. The only goal seems to have been to limit /32's to an > "ISP" but screw you if you aren't one. There was no alternative and it's > been how long now? PI, multihoming, multicast, etc. is reality because > the internet is now Very Serious Business for many, many people. I may have editorialized in a way that was not completely clear. I agree that due to lack of an alternative "PI IPv6" is necessary and effectively the only option we have right now. Were IPv6 policy to only allow those who could get IPv4 PI to get IPv6 PI I would say the problem was "the same". However, the reason I say it is being made worse is that there is a subset of the RIR community who sees the lack of scarcity of addres space as a reason to provide IPv6 PI to people who cannot qualify for IPv4 PI. My impression of the current RIR policy trends are resulting in a situation that more folks will be able to get IPv6 PI than can currently get IPv4 PI. Hence why I put that in the list of things making it worse. > Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a > debate about them, so I'll just say that if there had been a viable > alternative to multihoming as we know it I think it would have been > given a go before policy got pushed to the RIR's to allow IPv6 PI. The only idea I have seen that holds any promise is LISP. There is working code, and the idea is sound. However, like squeezing a balloon while it makes some issues better it then puts pressure in other directions. It trades off TCAM lookups for LOC/ID lookups and caching. It's not clear to me on an Internet scale system this is better; but I do hope the folks doing that work continue on the chance that it is... -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpib5ljKVw6O.pgp Description: PGP signature
Re: IPv6 internet broken, Verizon route prefix length policy
Seth Mattinen wrote: > Leo Bicknell wrote: >> Worse, the problem is being made worse at an alarming rate. MPLS >> VPN's are quicky replacing frame relay, ATM, and leased line circuits >> adding MPLS lables and VPN/VRF routes to edge routers. Various >> RIR's are pushing "PI for all" in IPv6 based on addressing availbility. >> Some networks are actually finally using multicast for IPTV services, >> generating much larger number of entries than the global multicast table >> would otherwise indicate. >> > > It's not the RIR's fault. IPv6 wasn't designed with any kind of workable > site multihoming. Lest anyone forget it has the same non-workable site-multihoming that has allowed the internet to grow to the size it is today. by non-working we mean not-better than ipv4. We actually know how to run that network pain and all. > The only goal seems to have been to limit /32's to an > "ISP" but screw you if you aren't one. There was no alternative and it's > been how long now? PI, multihoming, multicast, etc. is reality because > the internet is now Very Serious Business for many, many people. > > Yes, I know there's hacks like SHIM6 and I don't wish to go OT into a > debate about them, so I'll just say that if there had been a viable > alternative to multihoming as we know it I think it would have been > given a go before policy got pushed to the RIR's to allow IPv6 PI. > > ~Seth >
Re: IPv6 internet broken, Verizon route prefix length policy
On Mon, 12 Oct 2009 17:40:36 PDT, David Conrad said: > On Oct 12, 2009, at 5:09 PM, Owen DeLong wrote: > > With IPv6, it probably won't be the ideal 1:1 ratio, but, it will come > much closer. > > I wasn't aware people would be doing traffic engineering differently in > IPv6 than in IPv4. You get some substantial wins for the non-TE case by being able to fix the legacy cruft. For instance, AS1312 advertises 4 prefixes: 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 but on the IPv6 side we've just got 2001:468:c80::/48. And we're currently advertising *more* address space in one /48 than we are in the 4 IPv4 prefixes - we have a large chunk of wireless network that is currently NAT'ed into the 172.31 space because we simply ran out of room in our 2 /16s - but we give those users globally routed IPv6 addresses. pgp1f9MCsdxuY.pgp Description: PGP signature
Re: IPv6 internet broken, Verizon route prefix length policy
On Tue, Oct 13, 2009, valdis.kletni...@vt.edu wrote: > You get some substantial wins for the non-TE case by being able to fix > the legacy cruft. For instance, AS1312 advertises 4 prefixes: > 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 > but on the IPv6 side we've just got 2001:468:c80::/48. > > And we're currently advertising *more* address space in one /48 than we > are in the 4 IPv4 prefixes - we have a large chunk of wireless network that > is currently NAT'ed into the 172.31 space because we simply ran out of room > in our 2 /16s - but we give those users globally routed IPv6 addresses. I suggest you're not yet doing enough IPv6 traffic to have to care about IPv6 TE. 2c, Adrian
Re: IPv6 internet broken, Verizon route prefix length policy
Adrian Chadd wrote: On Tue, Oct 13, 2009, valdis.kletni...@vt.edu wrote: You get some substantial wins for the non-TE case by being able to fix the legacy cruft. For instance, AS1312 advertises 4 prefixes: 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 but on the IPv6 side we've just got 2001:468:c80::/48. And we're currently advertising *more* address space in one /48 than we are in the 4 IPv4 prefixes - we have a large chunk of wireless network that is currently NAT'ed into the 172.31 space because we simply ran out of room in our 2 /16s - but we give those users globally routed IPv6 addresses. I suggest you're not yet doing enough IPv6 traffic to have to care about IPv6 TE. I think he was pointing out that extra routes due to "slow start" policies should not be a factor in v6. My guess is that is about half of the "extra" routes announced today, the other half being TE routes. Speaking of TE, it's going to be interesting to see how we deal with that. We can't expect everyone to accept any /48 that gets announced. I'm still waiting for the first time someone blows up the Internet by announcing all 65536 /48's in their /32. I'm amazed it hasn't happened yet. Stricter use of the IRR might help if there wasn't rampant auto proxy registering going on. RPKI may be the answer since that can't be proxy-registered. That would at least mitigate router bugs and carelessness. The issue of what intentional TE routes are seen as "acceptable" is another issue. - Kevin
Re: IPv6 internet broken, Verizon route prefix length policy
Kevin Loch wrote: > Adrian Chadd wrote: >> On Tue, Oct 13, 2009, valdis.kletni...@vt.edu wrote: >> >>> You get some substantial wins for the non-TE case by being able to fix >>> the legacy cruft. For instance, AS1312 advertises 4 prefixes: >>> 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 >>> but on the IPv6 side we've just got 2001:468:c80::/48. >>> >>> And we're currently advertising *more* address space in one /48 than we >>> are in the 4 IPv4 prefixes - we have a large chunk of wireless >>> network that >>> is currently NAT'ed into the 172.31 space because we simply ran out >>> of room >>> in our 2 /16s - but we give those users globally routed IPv6 addresses. >> >> >> I suggest you're not yet doing enough IPv6 traffic to have to care >> about IPv6 TE. > > I think he was pointing out that extra routes due to "slow start" > policies should not be a factor in v6. My guess is that is about > half of the "extra" routes announced today, the other half being > TE routes. > > Speaking of TE, it's going to be interesting to see how we deal with > that. We can't expect everyone to accept any /48 that gets announced. > I'm still waiting for the first time someone blows up the Internet > by announcing all 65536 /48's in their /32. I'm amazed it hasn't > happened yet. > > Stricter use of the IRR might help if there wasn't rampant auto > proxy registering going on. RPKI may be the answer since that > can't be proxy-registered. That would at least mitigate router > bugs and carelessness. The issue of what intentional TE routes > are seen as "acceptable" is another issue. > I would love to see TE die a painful death. Maybe someone announcing 65536 routes will bring it to a swift end. ~Seth
Re: IPv6 internet broken, Verizon route prefix length policy
On Tue, 13 Oct 2009 00:46:00 EDT, Kevin Loch said: > Adrian Chadd wrote: > > On Tue, Oct 13, 2009, valdis.kletni...@vt.edu wrote: > > > >> You get some substantial wins for the non-TE case by being able to fix > >> the legacy cruft. For instance, AS1312 advertises 4 prefixes: > >> 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 > >> but on the IPv6 side we've just got 2001:468:c80::/48. > >> > >> And we're currently advertising *more* address space in one /48 than we > >> are in the 4 IPv4 prefixes - we have a large chunk of wireless network that > >> is currently NAT'ed into the 172.31 space because we simply ran out of room > >> in our 2 /16s - but we give those users globally routed IPv6 addresses. > > > > > > I suggest you're not yet doing enough IPv6 traffic to have to care > > about IPv6 TE. > > I think he was pointing out that extra routes due to "slow start" > policies should not be a factor in v6. My guess is that is about > half of the "extra" routes announced today, the other half being > TE routes. Exactly. We have 4 prefixes only because we got slow-started and similar hysterical raisins, we don't use those for TE at all. If we wanted to do any globally visible TE that actually made a difference, we'd have to announce a more-specific out of one of the /16s anyhow, since that's where all our traffic generators/sinks are (and probably a matching more-specific out of our v6 /48). So we're always going to have 4+N on the IPv4 and 1+N on the IPv6 side. (And if we'd gotten more address space for that wireless net, we'd be at 5+N rather than 4+N). pgpHVfLZqXviF.pgp Description: PGP signature
Re: IPv6 internet broken, Verizon route prefix length policy
On 13/10/2009, at 5:46 PM, Kevin Loch wrote: I think he was pointing out that extra routes due to "slow start" policies should not be a factor in v6. My guess is that is about half of the "extra" routes announced today, the other half being TE routes. You can pretty easily figure out how many advertised prefixes are intentional de-aggregates, and you can get a fairly good idea as to how many of them are for TE as well I expect, by looking for different AS paths. Someone mentioned some slides earlier in this thread by Vince Fuller at APRICOT early '07 that from memory have pretty good data on this. -- Nathan Ward
