RE: [AVT] RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00

Randell Jesup:

> "Dan Wing" <dwing@cisco.com> writes:
> >To your first point, I believe we resolved this, in a positive
> way, on the
> >list; -00 doesn't yet reflect those changes.  We decided to require NATs
> >to preserve even and odd port numbers when they create their UDP
> bindings,
> >as this provides the best interoperability for RTP applications that
> >don't/can't provide explicit signaling of their RTCP port.
>
>         Ummm...
>
>         And how will you "require" NATs to do this?  This would mean that
> all NATs would need to map all UDP traffic to the same oddness
> (even->even,
> odd->odd).  While sure, the NAT vendors _could_ write code this
> way (though
> it may well break some current NAT-traversal code that tries to do
> predictive mapping), there are millions of NATs out there that will never
> implement this, and nothing to force new releases to do so.
>
>         The even/odd port thing was (IMHO) a Bad Idea (in hindsight), I
> assume meant to avoid having to figure out how to signal the
> number for the
> second port - and even for that even/odd wasn't really needed, all you
> needed was contiguous.  Other TCP/UDP protocols don't do these sorts of
> things with port numbers (even/odd, or implied relationships between port
> numbers) - it's much better to actually signal the ports to be used.
>
>         We shouldn't compound it by "requiring" NATs maintain oddness
> (after the horse is not only out of the barn, but 12 miles down the road).
> We're apparently trying to avoid breaking "RTP applications that
> don't/can't provide explicit signaling of their RTCP port" by putting a
> requirement on NATs that will at best be phased in over years,
> and at worst
> totally ignored, instead of requiring RTP applications to specify both RTP
> and RTCP ports.  The effect will be that RTP applications that attempt to
> rely on this NAT requirement will end up breaking in many situations, and
> quite probably in unpredictable ways.  (For example, many NATs try to
> maintain port numbers inside->outside, but if the port is in use will then
> allocate other non-contiguous port numbers of different oddness.)
>
>         The original idea (even/odd pairs) wasn't a good one, and was
> somewhat at odds with normal techniques in TCP/UDP, and certainly at odds
> with any sort of NAT concept.  (Note: just my opinion, of course)
>
>         Of course, having a NAT preserve oddness (and contiguity!) will
> improve the odds of an older RTP application working from behind it, so it
> might be a *nice* thing to do in the NAT - but no one should be
> counting on
> it, and it's yet another complication in NAT design and limitation that
> could cause it to run out of ports (in a large corporate-style NAT).

I'll leave the draft-ietf-behave-nat authors to comment on the specific
text they're considering; it's my understanding they are adding text which
hits on your points above.

> >To your second, a reference to RFC3605 will be added to the 'application
> >behavior' document, which will describe how applications should behave.
> >The current BEHAVE document just describes how NATs should behave.
>
>         If BEHAVE is how they "should" behave, then my objections are
> lessened - though we need to make sure that people don't use this document
> as an excuse not to specify the RTCP port.

Application behavior will be in the application document (not in
draft-ietf-behave-nat); Francois and I are going to take a first cut at
the application document in the next month or two.  The application
document is described as "Produce a BCP that discusses protocol design
techniques for using the existing set of NAT traversal approaches" in
the BEHAVE charter
<http://www.ietf.org/html.charters/behave-charter.html>.

-d

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt