On Feb 10, 2011, at 2:58 PM, Owen DeLong wrote: >> In terms of CGN44 versus NAT444, I'd like to see evidence of something that >> breaks in NAT444 but not CGN44. People seem to have a gut expectation that >> this is the case, and I'm open to the possibility. But testing aimed at >> demonstrating that breakage hasn't been very scientific, as discussed in the >> URLs I posted with my previous message. >> > Technologies which depend on a rendezvous host that can know about both sides > of both NATs in a private->public->private > scenario will break in a private->private2->public->private2->private > scenario. There are technologies and applications which > depend on this. (I believe, among others, that's how many of the p2p systems > work, no?)
This is an oft-repeated rumor, but as I stated in my recent message: the evidence doesn't support the theory. NAT traversal architectures that leverage "public" rendezvous such as STUN, etc, should continue to work and testing demonstrates this. The tiering of NAT does mean that "neighborhood-local" traffic must traverse the CGN, which is sub-optimal but not broken. Dynamic control protocols like UPNP are the only source of problems I'm aware of. Frequently, the solution for a given app is as simple as turning off UPNP. But in the near future, PCP will replace and/or augment UPNP and is more scalable. If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it. I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this. Regardless, I think we can agree that IPv6 is the way to avoid NAT-related growing pains. We've known this for a long time. Cheers, -Benson
