[ppml] [narten at us.ibm.com: PI addressing in IPv6 advances inARIN]

[Stephen Sprunk]

Thus spake "Christopher Morrow" <christopher.morrow at gmail.com>
> On 4/16/06, Jeroen Massar <jeroen at unfix.org> wrote:
>> The idea of IPv6 is (still not was) to have it around for quite some
>> time longer than the lifespan of IPv4. Fortunately, the PI thing is far
>> from the end of the world and will only help catch on, see below
>
> stopping the PI train is hardly a simple matter. I agree that failing
> some reasonable 'multihoming' solution in v6, v6 is dead on arrival. I
> don't see that PI space is a smart move for the long term though :(

I don't think any of us who support this proposal think it's a great 
long-term move, but so far the IETF and RIRs have yet to come up with 
something better.  If they had, we'd be supporting that instead.

In the real world, you frequently have to pick the least-bad alternative, 
not the best one.  This is what we've done here.

> If PI space gets final approval it will mean that all of the DFZ
> providers will have to carry all (or nearly all) /48 routes for
> eternity... There is no way to get back the /48's assigned under PI
> space after a multihoming solution that makes sense arrives,

Blatantly untrue.  ARIN (and any other RIRs that adopt similar policies) can 
certainly repeal the PI policy at any time and could, I assume, refuse to 
renew the existing assignments.  As someone else noted, there will probably 
be proposals to do so in every policy cycle from now until such succeeds.

Failing that, all the ISPs have to do is start filtering PI routes if/when 
they become a problem.  If they don't filter the routes, obviously it's not 
an issue worth worrying about in the first place.

> and there is, honestly, no driver to continue working on a multihoming
> solution now that there is PI space.

Yes, there is still a purpose in doing so, but it's admittedly less urgent 
now unless/until we see major ISPs refusing to route PI space.

> Perhaps the original architects of v6 thought that by not proposing a
> multihoming solution, multihoming wouldn't happen? or that someone
> would arrive at a better solution than smaller deaggregates? Who
> knows...

The original architects of IPv6 were router vendors, who wanted an 
architecture that was cheaper to make routers for, and ISPs, who wanted 
cheaper routers.  Non-ISP network operators are and have been absent from 
nearly all IETF activities.  One can debate why that is, but the result is 
undeniably "solutions" that do not track the needs of the people paying the 
bills.  Simply consider the IETF's stance against NAT in spite of nearly 
every host on the modern Internet being behind _at least_ one NAT device and 
you'll start to see the disconnect.

> it seems that backing up, restarting the 'new protocol' process is
> likely to end up with another 10 years wasted, so it's very hard to
> see a reasonable path forward at this time.

Ah, but that assumes we actually need to replace IPv6.  It might be that we 
need to replace TCP, insert a layer below it, or replace BGP.  An influx of 
"evil" PI routes may motivate the IETF to find a more attractive 
alternative; unfortunately, history shows they're more likely to bury their 
heads in the sand and pretend PI isn't happening.

There's lots of possible solutions that can obviate the need for PI space 
(or, possibly, PA space) without changing the IPv6 forwarding logic. 
Hopefully the IETF will go figure out how to make one or more of them work.

> you have some basis for this? I don't have that same faith... I think
> that quite quickly every entity that has ipv4 space will have ipv6
> space in some PI fashion (if they have ipv4 PI space) and we'll all be
> stuck routing that and more from now until eternity. That will
> effectively double the current route table, which on much of the
> deployed networks isn't such a good plan.

Hardly.  Many of the orgs that will be getting PIv6 space under this policy 
have _hundreds_ of PIv4 blocks.  If we did our job right, each org will need 
only one PIv6 block per ASN, and there are not that many non-transit ASNs 
out there.  We're talking about doubling or tripling the current v6 table, 
not adding the entire bloated, swampy v4 table to it.

Just look at the number of prefixes in the v4 table vs the number of ASNs 
and you'll see that we're making an improvement of at least one order of 
magnitude.  Pessimists, of course, will claim this will lead to an order of 
magnitude growth in ASN assignment, but given there's virtually no 
restrictions on getting an ASN and multihoming with v4, how can one propose 
that PIv6 space will grow faster than Moore's Law (and anything less than 
that is irrelevant)?

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin