ietf
[Top] [All Lists]

Re: Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp)

2006-05-22 15:24:23

On May 18, 2006, at 7:44 PM, Keith Moore wrote:

If we change this to "address independent", close to 100% of NATs produced will be non behave compliant. At this point applications will have nothing they can rely on and we will be at the same point we are now and the BEHAVE WG will have been reduce to an irrelevant waste of time.

what's the point of this exercise?

To try and minimize the damage NATs cause - clearly if NATs all acted like a peice of cat 5 cable, that would be optimial from some points of view but this is not likely to happen. So it was a balance to define something that was extremely useful for applications (more on that later) and yet close enough to what NATs do that some, and hopefully most, NAT vendors will do it.

to encourage predictable behavior that applications cannot use?

The functionaly here defined here allow two hosts behind two differnt NATs to be able to set up a dirrect flow of packets between them. They need an external STUN server in the public space to help them with this but they don't need to realy all the packets through a server. The two hosts use some server that is not NATed to help set up the connection, but once the connection is up, there is real e2e flow of packets and the packets don't have to be relayed by some public server. Clearly this is not as nice for applications as no NAT, but short of no NAT, this is really useful and helps provide the scaleabilyt and reliabilyt that would be achievable in a system with no NATs. VoIP, IM, and online games can all take advantage of this - and using ICE they can do it in a way that provides a smoth transition to v6 or envirnoments with no NATs. I think the behavior defined here is useful for applications.



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf