Yes, as you point out the generic answer to the problem is NAT-PT which was
recently squashed after a cabal got together.
My point here is that the thinking on the transition in the IETF to date has
all been of the form 'well everyone is going to have to become like us, only
they can't possibly expect to so its a bit of a problem but not our problem'.
I received a lot of criticism when I first proposed that the IETF embrace NAT
as a transition tool rather than deprecate it. The idea that we should actively
encourage the NAT-ing of IPv4 was considered as unacceptable as Brian and
others now find my proposals for changing the way that the IETF operates and
the considerations it takes into account.
I don't see much dispute on that point today. Pretty much everyone seems to now
accept that we are going to run out of IPv4 addresses before IPv6 deployment is
complete and that some form of address sharing is therefore inevitable. What we
have failled to do so far is to act on that.
Take a look at what has happened in the film industry, the camera film industry
that is. Every manufacturer of 35mm film has understood that digital would
replace film in the consumer market shortly after 2005, that studios would have
transitioned from 35mm to digital by 2010 and that distribution of 35mm prints
will effectively cease by 2015. Virtually everyone in that business understands
exactly what the story is.
Then take a look at what those companies are doing about it. Polaroid has
already gone bankrupt and Kodak is desperately trying to re-invent itself as a
digital photography provider in time. Both companies understood what would
happen to their market and the new technologies that would come in. But neither
company ever made a serious attempt to become Sandisc.
Yes, whole industries can and do march right off a cliff in lockstep even when
they see the cliff comming.
________________________________
From: Jeroen Massar [mailto:jeroen(_at_)unfix(_dot_)org]
Sent: Thu 03/01/2008 5:44 AM
To: michael(_dot_)dillon(_at_)bt(_dot_)com
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Deployment Cases
michael(_dot_)dillon(_at_)bt(_dot_)com wrote:
Unless I've missed something recent, the IETF did not do a
lot of work
on the scenario where IPv4 islands need to communicate over an IPv6
Internet, talking to both IPv4 and IPv6 services.
It is called dual-stack.
That seems to simply ignore the issue by saying, let there be IPv4
everywhere for those who need it. But if there are not enough
addresses to grow the IPv4 infrastructure, you can't have IPv4
everywhere.
The big question of course is: what exact problem do you want
to solve?
An IPv4 island, that is blissfully unaware of the IPv4 address
crunch until far too late, wants to avoid changing their network
but still maintain connectivity to both the IPv6 and the IPv4
Internet. They may have to connect to an IPv6 ISP (for instance
if their IPv4 ISP goes bankrupt or they move an office location)
or they may connect to an IPv4 ISP who peers with a dual-stack
ISP or 6PE ISP. How do they continue to access all Internet services
from their IPv4 island, regardless of whether or not the services
are using IPv6 only?
What is so difficult in going dual-stack? IPv4 is NATted, as it already
is at a lot of places, and IPv6 comes in there using a tunnel.
Most 'services' that people use over the internet, fall under either:
- HTTP -> Use a HTTP Proxy with both IPv4 & IPv6
- SMTP -> Use a SMTP server which supports both IPv4 & IPv6
Anything else? Not really. As such, which exact services do you want to
transition?
Note that this is rather similar to the question raised regarding
the IPv4 outage at an IETF meeting. How does an IPv4 laptop user
continue to function without interruption when only IPv6 Internet
access is available at an IETF meeting?
As your source address breaks the moment your connection is interrupted
your have an interruption already. But you probably mean so that they
can continue using service X, well first start by defining service X.
The generic answer is of course NAT-PT, but there is a big reason why we
don't want that. Another trick is totd and there are a number of these
transition functions which are already in place and in use for a long
long time.
As such the sole problem left, which is going to be resolved soon, is
DNS, we will finally have AAAA in the root, next step DNSSEC :)
[..]
Stating "I want to connect from IPv4 to IPv6", can mean a lot
of things, is this HTTP? SMTP? or do you really want a
generic solution?
A generic solution that will work for all TCP and UDP protocols.
NAT-PT, but NAT doesn't understand all the protocols, if it did, then we
would not have to go to IPv6 in the first place.
I don't believe that there is an IETF solution for this scenario
which I expect to be a very common scenario specifically because
transition to IPv6 is being triggered by an IPv4 address shortage
whose effects will be felt first in the network core and ripple
outward from there.
As you clearly believe that there is no such thing, then make a list of
all the things you have tried and where they fail to meet your
requirements. Then make a list of the requirements you are missing and
propose that we solve that problem.
Greets,
Jeroen
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf