Mailing List Archive

1 2 3  View All
Re: IPv6 internet broken, cogent/telia/hurricane not peering [ In reply to ]
>> sure would be nice if there was a diagnosis before the lynching
> If this happened in v4, would customers care 'why' it happened?
> Obviously not.
> Why should v6 be any different? It either is or is not production
> ready. I'm interested in HE's view on that.

many of us are interested in diagnosis. few in your lynch rope.

randy
Re: IPv6 internet broken, cogent/telia/hurricane not peering [ In reply to ]
Funny enough, we've been looking at moving from 174 to HE for a large
amount of traffic, and this discussion is making the decision *a lot*
easier.

On 10/12/09, Dave Temkin <davet1@gmail.com> wrote:
> Marco Hogewoning wrote:
>>> Cogent: You are absolutely insane. You are doing nothing but
>>> alienating your customers and doing a disservice to IPv6 and the
>>> internet as a whole.
>>>
>>> You are publishing AAAA records for www.cogentco.com, which means
>>> that I CANNOT reach it to even look at your looking glass. I send my
>>> prefixes to 4436, 22822, and 6939 and you are not peering with any of
>>> them. Why not peer, for FREE, with 6939? What could you possibly
>>> gain from NOT doing this? HE is NOT going to buy transit from you
>>> (nor am I). Please fix your policy.
>>
>>
>> May I suggest to vote with your feet and take your business somewhere
>> else. They obviously are not interested in you, your traffic or your
>> money.
>>
>> MarcoH
>>
> Already done. All they are doing is continuing to provide fodder for
> engineers to tell their bosses why to NOT consider 174 transit when it's
> brought up.
>
> -Dave
>
>


--
Brandon Galbraith
Mobile: 630.400.6992
FNAL: 630.840.2141
Re: IPv6 internet broken, cogent/telia/hurricane not peering [ In reply to ]
Randy Bush wrote:
>>> sure would be nice if there was a diagnosis before the lynching
>> If this happened in v4, would customers care 'why' it happened?
>> Obviously not.
>> Why should v6 be any different? It either is or is not production
>> ready. I'm interested in HE's view on that.
>
> many of us are interested in diagnosis. few in your lynch rope.

What Randy has been *hinting* at is largely relevant...

I'm a /32 holder, with clients that have /48. I would appreciate some of
the diagnostic paperwork that has been written...

Steve

ps. I'm not choosing sides in any way, nor do I want to start a flame,
but HE has been exceptionally helpful v6-wise since I got into the game.
Re: IPv6 internet broken, Verizon route prefix length policy [ In reply to ]
In message <4AD382E4.9010901@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: marka@isc.org
Re: IPv6 internet broken, Verizon route prefix length policy [ In reply to ]
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 reply to ]
In message <1255388942.12984.1.camel@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: marka@isc.org
Re: IPv6 internet broken, Verizon route prefix length policy [ In reply to ]
Mark Andrews wrote:
> In message <4AD382E4.9010901@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 [ In reply to ]
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 [ In reply to ]
On 13/10/2009, at 8:26, Jeff McAdams <jeffm@iglou.com> 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 AAAAs for the the
IPv6 enabled root DNS servers?

--
Nathan Ward
Re: IPv6 internet broken, Verizon route prefix length policy [ In reply to ]
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 [ In reply to ]
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 AAAA record
c.root-servers.net has no AAAA record
d.root-servers.net has no AAAA record
e.root-servers.net has no AAAA record
g.root-servers.net has no AAAA record
i.root-servers.net has no AAAA 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 AAAA 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 <jeffm@iglou.com> 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 AAAAs for the the
> IPv6 enabled root DNS servers?
>
> --
> Nathan Ward
Re: IPv6 internet broken, Verizon route prefix length policy [ In reply to ]
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 [ In reply to ]
On Mon, Oct 12, 2009 at 8:16 PM, Owen DeLong <owen@delong.com> 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 [ In reply to ]
On Mon, Oct 12, 2009 at 8:40 PM, David Conrad <drc@virtualized.org> 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 [ In reply to ]
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 AAAA record
> c.root-servers.net has no AAAA record
> d.root-servers.net has no AAAA record
> e.root-servers.net has no AAAA record
> g.root-servers.net has no AAAA record
> i.root-servers.net has no AAAA 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 [ In reply to ]
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
jeffm@iglou.com
Re: IPv6 internet broken, Verizon route prefix length policy [ In reply to ]
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 reply to ]
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 - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Re: IPv6 internet broken, Verizon route prefix length policy [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
On Mon, Oct 12, 2009 at 10:13 PM, Seth Mattinen <sethm@rollernet.us> 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 v6ops@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/v6ops@ietf.

Alternately please see rrg@ietf or lisp@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 reply to ]
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 - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Re: IPv6 internet broken, Verizon route prefix length policy [ In reply to ]
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 [ In reply to ]
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.

1 2 3  View All