|
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@xxxxxxxxxxxx] 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf