I have no issue with your list of steps, other than it leaves out
significant cost factors related to the exhaustion of the IPv4 Free Pool,
and implies that each requires completion of the previous before it can
A) has been true for what people call 'computers' for a long time now (~5-6
years). The place that is lacking and being corrected during the 4G rollouts
is in the mobile handset space.
B) is not strictly required, because most of them already tunnel IPv4 over
foo, so tunneling IPv6 over foo works fine and still means that the
transport network has no clue about what the clients are really doing.
C) is the real problem child in the story here. Until someone in the LTE
space stands up and publicly says that the mobile eyeballs are going to be
connected IPv6-only, they have no motivation because they refuse to see the
costs of IPv4 rising. This is also where your list falls flat. As the pool
of freely available space is exhausted, the source of IPv4 addresses will be
eBay. The open market will decide what block sizes get traded, and all
historical controls over routing table size will vaporize. While the
engineering side of the house will whine about table growth and try to
maintain filters on prefix lengths, we saw in the CIDR deployment that the
business side of the house will win every time and engineering will be told
to "make it work". As the routing table grows at an unconstrained rate,
every major content provider will also have to deal with the costs to
upgrade their public facing routers. At the same time, to avoid paying
market price for IPv4 addresses, every ISP will be deploying multiple layers
of nat, increasing their cost and complexity, while breaking what few apps
their customers have that are able to work today by signaling the local cpe
based nat. This rising cost of maintaining IPv4 will be passed on to all
existing customers because doing otherwise would distort the pricing models
and drive potential customers away.
D-F) are irrelevant, because it doesn't matter if a device/protocol/... can
speak IPv4 if it is not being provisioned that way due to cost constraints.
The LTE community as a whole has collectively decided that the economics of
provisioning IPv4 makes no sense, even though the handsets and
infrastructure could do it.
While I agree there will be IPv4-only device around in 20 years (embedded
controllers die slowly), the majority of the world won't care because they
will live at the edge where local economics make different decisions. In the
public space, pricing will drive out IPv4 fairly quickly, and that only
accelerates as the end systems prefer IPv6 whenever it works. We have
already seen several instances of 5% traffic shift between the versions
overnight as AAAA records are added to DNS, and that is while it is still
fairly difficult to get ISPs to get out of the way and just let IPv6 work
even when they aren't actively supporting it.
As the costs issues for maintaining IPv4 become widely understood, the
demand for fully functional IPv6 products will pick up, and the parity
issues you refer to will be resolved. It is unfortunate that most of the
world has chosen to be 'next-quarter' focused, so they won't see the problem
until it is acute, and then will be reacting in a panic. There was no need
for interworking gateways if the world has deployed dual-stack in parallel,
and moved the apps gracefully long before the ability to maintain IPv4
became costly. Unfortunately that didn't happen, so now the world is looking
for IPv6-only to IPv4-only solutions to deal with the results of their
shortsightedness, and it will be the most costly confusing mess of a
deployment one could possibly imagine.
Either way, it is appropriate for the IETF to declare IPv4 to be historic,
and given how long it will take to decide what that means, we should start
now. I seriously doubt we could get consensus on that before 2015, but
waiting until then to start means it will be 2021 before we get past IPv4,
and the world will have long forgotten what the debate was about. IPv4 was a
fine experiment that escaped the lab, and now it is time to stand up and
tell the world that we need to move to a production version.
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Sent: Thursday, September 17, 2009 6:30 AM
To: Olivier MJ Crepin-Leblond
Cc: IETF Discussion
Subject: Re: IPv6 standard?
There are hundreds of millions of IPv4 computers and perhaps millions of
individual IPv4 transport networks, large and small.
Here are some useful points along the way from pure IPv4 to pure IPv6.
A. Every new computer is able to talk IPv6
B. Every transport is able to talk IPv6, i.e. every network from tier 1 ISPs
down through wifi hot spots and every internal corporate network
C. Every major service, e.g. Google, CNN, Amazon, is reachable via IPv6
D. Every new computer is not able to talk IPv4
E. A substantial number of transports are unable to talk IPv4
F. A substantial number of major services are not directly accessible via
IPv4 (but, of course, will be accessible via gateways)
I haven't included supporting details like DNS and gateways between IPv4 and
We're basically at A. Give some thought to the dates you'd assign to B
through F. Feel free to disagree that these are significant steps along the
path, but if you do disagree, please propose other reasonable and measurable
I didn't include the bitter end of this process, i.e. the complete
disappearances of IPv4. If we get through steps A through F, the rest won't
I have trouble believing this will all happen in less than 20 years. I do
not have trouble imagining it might take much longer.
I don't have any stake in the outcome. It's fine with me if it happens
faster. However, the mechanisms for interoperability between IPv4 and IPv6
are still being worked out and the products to do the work, i.e. application
gateways, are not yet plentiful. Moreover, even when the first products
appear, there's a long maturation cycle. As one example, two years ago the
ICANN Security and Stability Advisory Committee (SSAC) looked at the
products in the security area -- firewalls, etc. -- to see whether the
feature sets for IPv6 were the same as for IPv4. The good news was the
products did actually support IPv6. The bad news was the feature sets were
Our report, SAC 021, http://www.icann.org/committees/security/sac021.pdf ,
IP version 6 (IPv6) transport is not broadly supported by commercial
firewalls. On average,
less than one in three products support IPv6 transport and security
features. Support among
the firewall market share leaders improves this figure somewhat.
Support for IPv6 transport and security services is available from
commercial firewalls for
all market segments, however, availability of advanced security features is
SOHO and SMB segments and strongest in the LE/SP segment.
Overall, relatively little support for IPv6 transport and security features
some form of traffic inspection, event logging, and IP Security (IPsecv6)
available among products that support IPv6 transport and security services.
Internet firewalls are the most widely employed infrastructure security
With nearly two decades of deployment and evolution, firewalls are also the
security technology used in the Internet. They are, however, one of many
technologies commonly used by Internet-enabled and security-aware
mitigate Internet attacks and threats. This survey cannot definitively
answer the question,
"Can an organization that uses IPv6 transport enforce a security policy at a
firewall that is
commensurate to a policy currently supported when IPv4 transport is used?"
results do suggest that an organization that adopts IPv6 today may not be
IPv4 security feature and policy support.
The observations and conclusions in this report are based on collected
Future studies should consider additional and deeper analyses of security
availability for IPv6. Such analyses are best performed by certification
security assessment teams. Before attempting further testing and analysis,
must alter the perception among technology vendors in general (and security
specifically) that the market is too small to justify IPv6 product
The situation is probably better now, but I would guess there's still some
distance to go.
Imagine the decision process for the CIO or network architect of a medium or
large company. A security policy exists and it's implemented with a
collection of commercial products -- firewalls, routers, intrusion detection
systems, etc. -- all configured and managed to support the company's
security policy. Further imagine the both the transport and the individual
devices are all capable of supporting and using IPv6. How quickly will the
CIO or network architect decide that it's time to switch everyone over to
IPv6? Among other things, he will likely want to make sure he can continue
to implement the company's security policy. As of two years ago, he
couldn't buy products that would function at the same level.
IPv6 is definitely necessary and we should all do everything we can to move
in that direction. I'm just noting that even when IPv6 is widely available
and in broad use, there will be a long tail before IPv4 fades from the
On Sep 17, 2009, at 2:36 AM, Olivier MJ Crepin-Leblond wrote:
"Steve Crocker" <steve(_at_)shinkuro(_dot_)com> wrote:
We're some distance away from deprecating IPv4. Maybe 20 years, maybe 50
years. For a very long time, IPv6 and IPv4 will co-exist.
I know you wrote those figures to be provocative, Steve. :-)
I mean, 50 years? That's like saying "computers will still run on valves in
50 years' time" in 1950.
Of course this is a matter of appreciation, and frankly, does it really
matter how long IPv4 will be around?
Let's worry at the future, not the past.
Olivier MJ Crépin-Leblond, PhD
Ietf mailing list