Hi Alain,
The IETF thinking for the last 10+ years (and I include myself in this) had been that dual stack was the answer and most things would be converted to dual stack before we ran out of v4.
Well, it has not happen.
There is still very little v6 deployment and we will be running out of v4 space soon (instantiate soon by your particular prediction of the day you won't be able to get space from your RIR, either because there is no more or because you do not qualify any longer).
I don't think it has happened because in the past there hasn't been a
compelling reason to. End-users haven't seen any benefit, so they
haven't asked for it, and service providers (who of course provide
services to those end-users) haven't been able to justify the investment,
because their end-users/customers haven't been asking for it.
If IPv4 addressing runs out, and the only way to grow the Internet is
to implement IPv6, then the service providers who've made the IPv6
investment provide access to more services i.e. both IPv4 + IPv6 based,
will win customers from their competing service providers.
I think the loss of customers to competitors would create a compelling
reason for service providers to introduce and migrate to IPv6, and I
think a "better Internet experience" (I've been around Internet
marketing people too long) i.e IPv4+IPv6 visible content would be the
compelling reason for customers to move to service providers who're
providing access to both protocols.
Given the above, it is clear that we are gong to see devices (which might be dual stack *capable*) that will be deployed and provisionned with *v6-only*...
At the edge of the network, where we have devices by the millions and where address space is a critical issue and dual-stack is a non starter, this is already under way...
It is also becoming apparent that:
- the "core internet" (ie the web and any infrastructure server) will take a long time to move to v6 and/or dual stack.
- new v6-only edges will have to communicate with it. So we need v6->v4 translation in the core
MPLS as well as the IETF softwires techniques (the MPLS
model without using MPLS i.e. tunnel from ingress to egress via
automated setup tunnels - gre, l2tp, or native IPv4 or IPv6) can or
will shortly be able to be used to tunnel IPv6 over IPv4 or vice versa.
softwires in effect treats the non-native core infrastructure as an
NBMA layer 2.
The advantage of these techniques verses dual stack is that they push
the complexity of dual stack to the network ingress and egress devices.
Dual stack isn't all that complicated, however when you think about
running two forwarded protocols, two routing protocols or an integrated
one supporting two forwarded protocols, having two forwarding
topologies that may not match in the case of dual routing protocols,
and having two sets of troubleshooing methods and tools, I think the
simplicity of having a single core network forwarding protocol and
tunnelling everyting else over it becomes really attractive. The price is
the tunnel overhead of course, however, processing wise that price is only paid
at the edges, making it scalable, and in the core, the bandwidth cost
of the tunnel overhead is minimal, because the network core typically
has all the high bandwidth links.
- legacy v4 PCs (think win95 up to win XP) using RFC1918 addresses behind a home gateway will never be able to upgrade to an IPv6-only environment. So if we provision the home gateway with v6-only (because there will be a point where we do not have any global v4 addresses left for it) those legacy PCs are going to need a double translation, v4->v6 in the home gateway and then v6 back to v4 in the core. Note: a double private v4->private v4->global v4 translation would work too, but if you are running out of private space as well, this is also a non-starter...
While it probably won't be a huge amount, getting rid of forwarding
based on end-node IPv4 destination address out of the core will help
with this a bit. I wonder if anybody has done a study as to how much
public IPv4 address space is consumed by infrastructure addressing.
- there are a number of internal deployment cases where net 10 is just not big enough, thus the idea to use v6 to glue several instances of private space together as a 'super net 10'. For this to work, legacy devices that cannot upgrade to v6 need to go through a translation v4->v6.
I'm guessing you might be in part talking about your cable modem
management problem that I've seen an IPv6 presentation of yours about.
Is it really necessary to have global reachability to all your
customer's CPE for management purposes across the whole of your
network? Would it be possible to have e.g. 3 large management regions,
each with their own instance of network 10, and then make the
infrastructure robust enough that there'd be much bigger problems with
your network if the need to remotely manage one group of CPE from
another management region became necessary?
So, no, NAT v4->v6 or v6-v4 does not solve world hunger but solve very real operational problems.
I suppose we have to weigh up whether the NAT can of worms is worth
openning again with IPv6 to solve operational problems, and losing the
chance to have the benefits of end-to-end principle back again for all
the end-users of the Internet. I've experienced and seen too many cases
where the hidden costs of NAT became unhidden. In those instances,
"throwing" public address space at the problem would have instantly
destoyed the problem NAT was causing. In IPv4 we have to be a bit
careful doing that these days, in the future, with IPv6, we don't.
Regards,
Mark.