Agree and moreover, dual-stack works with private IPv4 addresses behind NAT,
so not an issue.
Regards,
Jordi
De: Tony Hain <alh-ietf(_at_)tndh(_dot_)net>
Responder a: <alh-ietf(_at_)tndh(_dot_)net>
Fecha: Fri, 13 Jul 2007 17:25:56 -0700
Para: "'Hallam-Baker, Phillip'" <pbaker(_at_)verisign(_dot_)com>, 'Stephen
Sprunk'
<stephen(_at_)sprunk(_dot_)org>, 'Keith Moore'
<moore(_at_)cs(_dot_)utk(_dot_)edu>, 'Jun-ichiro itojun
Hagino' <itojun(_at_)itojun(_dot_)org>
CC: 'Paul Hoffman' <paul(_dot_)hoffman(_at_)vpnc(_dot_)org>,
<ietf(_at_)ietf(_dot_)org>
Asunto: RE: IPv4 to IPv6 transition
There are two fundamental flaws with your claims.
'What we need is a transition strategy that is more effective than dual
stack.'
& 'The typical consumer does not host servers?'
There is no 'one size fits all' transition strategy, and no amount of hot
air will fix that. Dual-stack is promoted as the primary path because it
allows for an application by application graceful deployment by each
independent organization. Every other approach applies a forcing function
somewhere, and those typically come with a cost that is not localized to the
person doing the work. As you note, it assumes that IPv4 is retained to
allow that smooth transition. If people insist on waiting until there is no
more IPv4 to be had, the state will no longer be dual-stack, it will be a
panic driven deployment of hacks. For dual-stack to work, people need to use
the approach well ahead of IPv4 exhaustion. Claiming we need something more
effective is just hot-air, because 'effectiveness' will be measured
differently in every one of the millions of individual deployment
environments.
The second statement is the result of nat, not a desired situation. The
average non-geek will not intentionally host a service, but anyone that runs
skype or the like without a nat is providing a super-node service. Despite
your claim, typical consumers do this kind of hosting, and would do more of
it if there were no nat. The more we move toward p2p apps being the norm,
the more that services will be hosted on non-traditional 'servers' and at
non-traditional points in the network (ie: the home).
The real solution to your claim about the need for a more effective strategy
would be to stop allocating IPv4 to the ISPs that do not deliver IPv6 native
service to all of their customers. If the IPv6 native service existed the
dual-stack approach would work just fine. Of course the IETF can't tell the
RIRs to stop allocating IPv4, and since the RIRs are dominated by the ISPs
there is no chance of a policy change that would force deployment of IPv6 to
the edges.
In the end, the IETF did what it could do by defining a set of tools that
can be used to get IPv6 deployed. The fact that the ISPs are not taking
advantage of those and moving ahead is outside of what we can impact. If
they try and come back with complaints about tools not working, we can work
to fix those, but at the current burn rate the time for any standards fixing
has passed. Even if we modified the spec for transition tools today, by the
time the resulting products hit the streets we would be well into panic mode
from the exhaustion of IPv4.
Essentially the only thing we can do now is stand back and get ready to
roast marshmallows on the fire of the media driven panic when the pool runs
dry.
Tony
From: Hallam-Baker, Phillip [mailto:pbaker(_at_)verisign(_dot_)com]
Sent: Friday, July 13, 2007 10:57 AM
To: Stephen Sprunk; Keith Moore; Jun-ichiro itojun Hagino
Cc: Paul Hoffman; ietf(_at_)ietf(_dot_)org
Subject: IPv4 to IPv6 transition
I think we need to look beyond whether NAT is evil (or not) and whether
NATPT is the solution (or not) and look to see how we might manage a
transition to IPv6 in a way that is not predicated on holding ISP customers
hostage.
People have been there and done that, anyone remember when the anti-spam
blacklists started talking about 'collateral damage' with great glee? Within
a very short time a very large number of email admins hated the self
appointed maintainers of the blacklists more than the spammers.
We have three Internets: IPV4, IPv4+NAT and IPv6.
Clearly the IPv4 Internet is going to run out of addresses. That does not
mean that IPv4 will go away however. As far as the ISPs are concerned
IPv4+NAT works just fine for residential connections.
What we need is a transition strategy that is more effective than dual
stack. IPv6 is not going to work as a solution to the IPv4 address space
crunch if every IPv6 Internet user has to have an IPv4 address as well.
This strongly suggests to me that during the transition, a period I expect
to last until 2025, we will want the standard Internet allocation to be a
/64 of IPv6 plus a share in a pool of IPv4 addreses behind a NAT.
What I would like to get to is a situation where a consumer can 1) purchase
Internet connectivity as a commodity with a well defined SLA that assures
them that the connection will work for the purposes they wish to use it 2)
obtain a report from their Internet gateway device(s) that tells them
whether the SLA is being met or not.
From the point of view of the consumer all that matters is that their client
applications and their peer-2-peer applications work. The typical consumer
does not host servers at their home and we want the sophisticated consumer
to move to IPv6.
Most application protocols work just fine behind NAT. FTP works with an ugly
work-around. The main protocol that breaks down is SIP. I am mighty
unimpressed by the fact that when I plug the VOIP connector made by vendor X
into the wirless/NAT box made by vendor X that I have to muck about entering
port forwarding controls by hand. And even less impressed by the fact that a
good 50% of the anti-NAT sentiment on this list comes from employees of
vendor X.
STUN does not appear to me to be an architecturally principled approach, it
is a work around.
The way to fix this situation in my view is to make the NAT box SIP aware by
building a SIP proxy capability into the NAT box. The designers of NAT boxes
go to great efforts to try to work around applications. Leave approaches
such as STUN to the case where you are dealing with a legacy box.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org
This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware that
any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf