Ok. Just as long as we're agreed that STD 6 (RFC 768) is the UDP standard. > 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. > My basic point is that the requirement you cite would be contrary to the > goal of using UDP to support connectionless and multi-endpoint, > non-session-oriented protocols. If one must stretch English meaning so far > in order to argue that making the NAT kludge work is more important than > preserving design options hard fought for, I see no point in continuing the > discussion. Exactly how has what I've said broken UDP's goal to support connectionless and multi-endpoint non-session-oriented protocols? Those theoretical protocols wouldn't work under NAT anyway. You would have to get dedicated addresses. 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. But what does that have to do with Quake? How is Quake "connectionless"? Are there Quake clients talking to each other? No. Are there Quake servers probing for clients? Nope. Is there ever Quake traffic when a client does not request it? Nope. Quake is using UDP. But, like DNS client queries, it can't be claimed that Quake is connectionless. During normal, non-NAT operations, there is a connection between the server at port 26000 to the client at some random port. There are no other packets involved with the server and that client. Again, I have never claimed that this means UDP always involves connections of some sort. Nor, can I conceive of a way to interpret what I've said to mean that. In addition, NAT just won't work for connectionless UDP protocols. (none of which have been named.) You may ask why the topic always comes back to Quake, or why Quake does or doesn't work. It is the topic of this thread, and the conclusion many people have reached is there is a bug in the Quake protocol. UDP clearly accommodates protocols wishing to use connections with it's _optional_ "source port" field. I emphasize "optional" because that's what it is. By setting this field to zero, the protocol is saying that it does not use the field. Quake does not do this. As a side note, if id Software set this field to zero, their protocol wouldn't violate UDP. I'd personally consider it a bug, but would have no STD to cite against it. I am completely unconcerned about other connectionless UDP protocols you have not mentioned. If someone wants to use those protocols, they will. I don't have a problem with it, or care... but I am aware that only a very small number of people care about those protocols. In addition, I am also confident that if any of those protocols are valuable to the mass market, they will be popular when IPv6 is prevalent. As a side note, an Ascend mailing list is not a good place to argue about the merits of NAT. The InterNIC is, for all intents and purposes, forcing ISPs to use NAT (i.e. many people on this list). If we don't justify our address space utilization, the InterNIC will take the poorly used address space away. We use NAT because it validates our ip address space. We save dedicated IP addresses for those that need them. Thanks, -- Jason Eggleston SysAdmin, Jet.Net Inc. ++ 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="msg10395.html">Re: (ASCEND) Hash Codes</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg10394.html">Re: (ASCEND) Hash Codes</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg10389.html">Re: (ASCEND) Quake/QW and Pipeline 75 and NAT</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg10335.html">(ASCEND) dov bug in 5.1ap4</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="maillist.html#10396"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd226.html#10396"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>