Jason Eggleston <jason@jet.net> writes: [snip] > David P. Reed wrote: [snip] > > I fail to understand how you can read the phrase you quote from RFC 768, > > "may be assumed to be the port to which a reply should be addressed in > > the absence of any other information," > > as _requiring_ that additional traffic be sent to that port, or as > > _requiring_ that addresses not be sent in the data portion of a UDP > > datagram or in other places not accessible to the NAT translator. Where > > else would 'other information' be provided? > > I read it the following way: > > You didn't quote the whole paragraph in the STD: > > > Source Port is an optional field, when meaningful, it indicates the port > > of the sending process, and may be assumed to be the port to which a > > reply should be addressed in the absence of any other information. If > > not used, a value of zero is inserted. > > To me, and many others, this means that to write a non-zero value in the > UDP header, and to copy that value in the UDP datagram is > > 1. A waste of 16 bits. > 2. Completely pointless. > 3. Against the last sentence of the quoted paragraph "If not used, a > value of zero is inserted." Quake packets have non-zero source ports, > but at the same time, clearly do not use that field. > 4. A quick way to break any NAT scheme, which I realize you're in favor > of. [snip] > My point is that UDP does support a mode of operation where it > essentially works like TCP, only there is no guaranteed packet delivery > or packet order. But yes, there is a "connection." You may say "but > UDP is a connectionless protocol, it says so in the STD." As soon as > you set the source port in the UDP datagram, you've made what, in this > argument, is effectively a "connection" (but not a stream as in TCP). > The client expects packets back to the port specified in the UDP header. I think you are reading more into the standard than is actually there. Several points. 1. The standard says, "Source port is an optional field, when meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information." The key part of the sentence reads, "... when meaningful, it indicates the port of the sending process ..." Thus, the meaning of the source port field is the port of the sending process, and nothing more. The rest of the sentence is merely a design suggestion for protocols that operate on top of UDP (it starts with the word "may"). A process receiving a UDP datagram is under absolutely no obligation to address its reply to the source port simply because the source port is non-zero. Your statement above, "As soon as you set the source port in the UDP datagram...the client expects packets back to the port specified in the UDP header" is not supported by the standard. All the standard says is that the receiver *may* choose to address the reply (if there is one) to the indicated source port (if there is one) if that seems like a reasonable thing to do (e.g., there is no other information available). A non-zero source port means only that the indicated source port is somehow associated with the sending process. 2. In your point 3 above, you say, "Quake packets have non-zero source ports, but at the same time, clearly do not use that field." As the standard says, the use of the source port is to indicate the port of the sending process. That in itself constitutes "use of the source port field." Just because Quake doesn't address its reply to the indicated source port doesn't mean the source port isn't being used. If the source port field is filled in with a valid port number associated with the sending process, it has been used. (That might be helpful in order to find out who owns the process which sent the datagram, for example.) You might argue that the Quake protocol is poorly designed, or that perhaps it would be useful to revise it in order to accomodate NAT, but your evidence does not indicate that it violates RFC 768. Regards, Steve Ihde sihde@cs.stanford.edu ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.nealis.net/ascend/faq">http://www.nealis.net/ascend/faq</A>> </PRE> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <HR> <UL> <LI>Prev by Date: <STRONG><A HREF="msg10445.html">(ASCEND) Radius Filter</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg10451.html">(ASCEND) Multi-Max's...</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg10440.html">(ASCEND) Re: ascend-users-digest V96 #875</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg10441.html">(ASCEND) Downloading Problems!!!!</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="maillist.html#10448"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd230.html#10448"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>