Re: Review in WGLC for draft-ietf-dccp-udpencap-02.txt.

["Phelan, Tom" <tphelan@xxxxxxxxxxxx>]

Hi Colin,

I agree with your points below.

Tom P.

> -----Original Message-----
> From: Colin Perkins [mailto:csp@xxxxxxxxxxxxx]
> Sent: Thursday, September 02, 2010 9:36 AM
> To: Gorry Fairhurst
> Cc: 'dccp' working group; Phelan, Tom
> Subject: Re:  Review in WGLC for
draft-ietf-dccp-udpencap-02.txt.
> 
> On 1 Sep 2010, at 09:17, Gorry Fairhurst wrote:
> ...
> >>> - I see the value of the IANA-specified destination port for a
> >>> client server app using a NAPT, where the NAPT changes only the
> >>> src port as it leaves the client, and does this differently for
> >>> each sender address behind the NAPT. What is the expected port
> >>> usage at the receiver? Does it listen on the IANA port bound to
> >>> any source port? Can you say more here?
> >>>
> >> [TomP] So section 3.1 says:
> >>    Source and Dest(ination) Ports: 16 bits each
> >>
> >>       These fields identify the UDP ports on which the source and
> >>       destination (respectively) of the packet are listening for
> >>       incoming DCCP-UDP packets (normally both are the default port
> >> to
> >>       be assigned by IANA).  Note that they do not identify the
DCCP
> >>       source and destination ports.
> >>
> >> I don't know that I see any necessary changes here, except it
> >> should probably mention that the port values can be changed along
> >> the way by NAPT boxes.  You say, "Does it listen on the IANA port
> >> bound to any source port?"  I assume by this you mean will it
> >> accept an incoming packet with any source port?  Do we need to open
> >> this UDP can of worms?
> >>
> > GF: We don't need to open the can of worms, but it may be wise to
> > realise that if the intention is to travserse middleboxes that the
> > ports (in particular the src port from a "client") may be updated by
> > a middlebox, e.g. NAPT, and therefore a receiver should expect that
> > one (or both) ports may be different to the IANA assigned value.
> 
> Right - the statement that "(normally both are the default port to be
> assigned by IANA)" seems unlikely to be true, since the point of this
> draft is to traverse middleboxes, which will almost certainly rewrite
> the ports to a different value.
> 
> On a related topic, Section 5.1 could do with some wording to explain
> the (limited) applicability of this new SDP attribute. Specifically,
> it's likely only useful if the offering party is on the public
> Internet, and not behind a NAT, because otherwise the port it
> advertises won't be reachable. The draft should note this, and explain
> that bi-directional NAT traversal is for future study.
> 
> Also, is the title of Section 5.1 accurate? It's not clear that
> anything in the new SDP attribute depends on the RTP-over-DCCP
> encapsulation.
> 
> Cheers,
> Colin
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
>