Steve,
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
start.
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.
Tony
From: ietf-bounces at ietf.org [mailto:ietf-bounces at ietf.org] On Behalf
Of
Steve Crocker
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
IPv6.
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
mark points.
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
matter much.
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
noticeably poorer.
Our report, SAC 021, http://www.icann.org/committees/security/sac021.pdf
,
concluded with:
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
lagging in
SOHO and SMB segments and strongest in the LE/SP segment.
Overall, relatively little support for IPv6 transport and security
features
exists. However,
some form of traffic inspection, event logging, and IP Security
(IPsecv6)
are commonly
available among products that support IPv6 transport and security
services.
Internet firewalls are the most widely employed infrastructure
security
technology today.
With nearly two decades of deployment and evolution, firewalls are
also the
most mature
security technology used in the Internet. They are, however, one of
many
security
technologies commonly used by Internet-enabled and security-aware
organizations to
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?"
The survey
results do suggest that an organization that adopts IPv6 today may
not be
able duplicate
IPv4 security feature and policy support.
The observations and conclusions in this report are based on collected
survey results.
Future studies should consider additional and deeper analyses of
security
technology
availability for IPv6. Such analyses are best performed by
certification
laboratories and
security assessment teams. Before attempting further testing and
analysis,
the community
must alter the perception among technology vendors in general (and
security
vendors
specifically) that the market is too small to justify IPv6 product
development.
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
scene.
Steve
On Sep 17, 2009, at 2:36 AM, Olivier MJ Crepin-Leblond wrote:
"Steve Crocker" <steve at shinkuro.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.
Kindest regards,
Olivier
--
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html
