RE: IPv6 standard?

Steve Crocker wrote:

Tony,

Thanks for your comments.  I guess I don't understand the nominal
criteria for declaring something to be historic.  I assumed it was
when it was no longer in common use, but I gather from your comments
and others that it's sometimes used as a leading edge, i.e. to lead
people toward tapering off the usage.


I have no expectation that anything the IETF says will in any way impact
usage. What I would hope is that we can stop wasting IESG time on new warts
to keep IPv4 running, when it should be clear that just creates a bigger
mess to clean up, besides being more expensive than just moving on.


Re the metrics and milestones I listed, even though I used a lettered
sequence, I did not mean to imply they had to happen in that order.
Each could have its own date, and the dates might not be strictly
increasing.

Nor would I insist on those specific metrics, even though they seem
good to me.


They are certainly the metrics I frequently get asked about, along with 'how
much IPv6 traffic is there?', but people are fundamentally resistant to
change, and readily take the position of 'I will wait until metric X has
been passed before starting'. We have been stuck in that mode for 10 years,
and the only way to get out is for people to recognize that the change is
imminent and inevitable so they will stop waiting for others to go first.


The main point I wanted to make is that bringing IPv6 into full use
and advancing the associated specifications along the standards track
did not, at least for me, imply deprecating IPv4 standards.


I agree those are separable events, and the only reason they have come
together in time is that the IPv6 to full standard event has been delayed to
the end of useful IPv4.

In
practice, the two technologies are going to co-exist for quite a
while.


At the edge absolutely... In the core, economics would argue otherwise.

Today, one can pretty much count on IPv4 connectivity around
the world, and one can also count on being to reach almost any service
(Google, Amazon, CNN, etc.) via IPv4.  What's the estimated date when
those two statements stop being true?


Well depending on how you define 'reach a service', it stopped being true
when 1918 was published, and has only gotten worse over time. As a simple
example, at a hotel in Sydney I was unable to get to the IPv4 address for
the IPv6-over-IPv4 tunnel service because the hotel was blocking UDP for one
mode, and I was only being offered a private IPv4 address which prevented
the other mode. Yes I could get to cnn.com over IPv4, but as I told the help
desk when they said I didn't need IPv6; "I get my email via IPv6, and
preventing access to specific IPv4 services while actively avoiding IPv6
deployment is a denial of service attack by the ISP". 

When will the major content providers stop offering IPv4 access? As soon as
the traffic level drops below the nominal value relative to the cost of
continuing to support it. As ISPs offer native IPv6 to their customers,
OS-X, W7, current *nix will just use it and stop using IPv4 for sites that
offer both. This will result in a substantial and rapid shift, so economics
would argue for a relatively short timeframe where both are offered. This is
not an issue of how long it will take for users to choose to move, because
they should never know it happened. As soon as a AAAA shows up, the IPv4
traffic should stop from every IPv6 capable client. Native connectivity
makes that service better, but should not be required as long as the ISP is
not getting in the way of the tunneling functionality.

Even if you tighten the
criterion to using native IPv4 transport, i.e. not tunneled via IPv6,
I believe it will be many, many years before the general IPv4 fabric
starts showing any significant rips and tears.


We can agree to disagree over this point, as it has been steadily chipped
away at by nat at the edge, and will be seriously shattered as the
currently-in-high-demand CarrierGradeNat devices get rolled out over the
coming 12 months. Yes the core of BGP will still exist for many years to
come, and I believe we will see a working routing system at > 1M entries in
the DFZ, so you could declare the 'IPv4 fabric' intact, but from a 'service
viability' perspective we are long past the point of no return.

Tony


Steve



On Sep 17, 2009, at 6:37 PM, Tony Hain wrote:

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(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)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(_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.

Kindest regards,

Olivier

--
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf