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