Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Re: ascend-users-digest V96 #875
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: <http://www.nealis.net/ascend/faq>