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

[Iljitsch van Beijnum]

On 17-apr-2006, at 7:10, Christopher Morrow wrote:

> 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...

I wasn't there, but I gather that an important consideration was not  
to change too much in one go. This meant keeping the structure of the  
socket API the same (I'll spare you my opinion on this issue) and  
also keeping routing the same as it was/is in IPv4. (The fact that no  
obvious solutions for the problem presented themselves didn't help,  
of course.)

>> Of course any vendor will love the idea of having to do another IP
>> version of course, bring in the cash ;)

> because ipv6 was so profitable for them so far? most don't even do v6
> correctly today, after 10 years of development! We are in a very bad
> position on all fronts here, shim6 isn't making it better, PI v6 isn't
> making it better and vendor's doing half-baked product deployments
> aren't either.

> 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.

I very much disagree with your assessment of the state of IPv6. Yes,  
everything is taking its sweet time, but that works both ways: we  
still have 1400 million unused IPv4 addresses (the equivalent of 84 / 
8s), so we don't have to jump the gun now.

The reasonable path forward that I see:

At least until now, it has been customary in IPv6 to do address  
configuration for hosts, especially non-servers, with stateless  
address autoconfiguration. This allows for very easy renumbering. In  
order for stateless autoconfig to work, routers must still know  
address prefixes, but with DHCPv6 prefix delegation (PD) it's not  
necessary to put these in the actual router configuration. So with  
stateless autoconf and DHCPv6 PD you can effectively renumber an  
entire network (without any user interruption) by changing some info  
in a DHCP server.

But even in IPv4, that's the easy part. The hard part is keeping the  
DNS in sync and maintaining address based access controls. But in  
IPv6 it's hard to populate the DNS anyway (you can't pre-populate an  
entire address block), and because during the renumbering operation  
the host maintains both the old and the new address for some time, a  
good way to handle this is dynamic DNS updates. So the host itself  
sends updates to the DNS server when it changes addresses rather  
than  having some administrator handle this.

Last but not least: the firewalls and so on. There are no solutions  
for doing this in a way that allows for easy renumbering today, but  
it's not hard to imagine that a firewall could monitor stateless  
autoconfig, DHCPv6 PD and DDNS information and adjust its filtering  
rules accordingly.

So we're really close to a situation where it's actually possible to  
renumber a non-trivial network automatically without user impact.  
This would negate most of the need for portable address space. With  
shim6, multihoming doesn't require portable address space either.

It is of course possible to argue that all of this, or at least an  
important ingredient, isn't going to work. That's certainly a  
possibility. However, as I said before: we still have time, there is  
no need to jump the gun now. In IPv4, the only tool we have for both  
multihoming and provider independence is PI addressing. In IPv6,  
there is a real possibility that we'll have more, so we should try to  
move away from the mindset where every problem looks like a nail that  
should be hit with a PI hammer. If in two or three years it turns out  
that the combination of renumbering and shim6 really don't address  
the provider independence and/or multihoming problems to a reasonable  
degre, we can always adopt PI at that point in time.

Some people argue that IPv6 deployment is low because there is no PI  
in IPv6 today. There is simply no evidence of that. More than half  
the ASes in the IPv4 BGP table are transit ASes (i.e., ISPs, not  
multihomers) and only a few percent of those are present in the IPv6  
BGP table. Also, Google, not a company that rejects new technology by  
any stretch of the imagination, has through unknown means managed to  
obtain an IPv6 block (2001:4860::/32) a year ago, but as far as I can  
tell, they aren't offering any services over IPv6 at this point.

So making PI available in IPv6 now is a bad idea as it frustrates  
more future proof ways to obtain the same results, without any  
immediate beneficial results. Any good that can come out of IPv6 PI  
can also be had some years down the road, if at that point, the  
alternatives haven't panned out.

>> That is in the long run, most likely in the coming 10-20 years the  
>> IPv6
>> routing tables will not have 'exploded' yet, but the folks selling

> you have some basis for this? I don't have that same faith...

Remember that this isn't about accurately predicting the future, it's  
about minimizing the potential for catastrophes. It's entirely  
possible that for various reasons such as the complexity of BGP etc  
PI never gets out of hand relative to router capabilities, the  
problem is that we can't know for sure that it won't.