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