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/ > >
