[ppml] [narten at us.ibm.com: PI addressing in IPv6 advances in ARIN]
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
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 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
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
>> 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.