On Thu, 1 Aug 2013, C. M. Heard wrote:
> On Thu, 1 Aug 2013, RJ Atkinson wrote:
> > I agree that C.M. Heard's ideas should be explored
> > in more detail by the IETF.
The idea was essentially UDP with segmentation fields, which would
require a new protocol number.
In an offline discussion with Mark Smith and I kicked around an idea
for an alternate version not requiring a new protocol number, but
relying instead on the redundancy of the UDP Length field. The UDP
Length field is not actually needed; TCP does not have one but
rather relies on the length reported by the IP layer. Under current
standards, the UDP Length field must be at least 8 and cannot exceed
the IP payload length minus the combined length of any extension
headers -- let's call this the L4 length from IP. Existing
implementations are supposed to drop UDP datagrams that fail this
check, and all the ones I know of do so.
The question then arises whether it might reasonably be possible to
re-purpose the case UDP Length > L4 length from IP to mean a
segmented UDP datagram.
In that case 8 <= UDP Length <= L4 length from IP would be
intepreted as a standard unsegmented UDP datagram, as is it now.
That's the case pictured below. Note that if the L4 length
indicated by the IP layer exceeds the UDP Length, then the extra
octets would be discarded and are not delivered to the application;
that is the behavior of the implementations I know of.
0 15 16 31
+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
| Length <= L4 length from IP | Checksum |
+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
| data octets ...
+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ...
Now suppose that we have a long UDP datagram that we want to send in
segments. We set the Length and Checksum fields as usual, and then
cut the datagram into segments, each of which looks like this:
0 15 16 31
+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
| Length > L4 length from IP | Checksum |
+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
| (reserved = 0) | Segment Offset |Res|M|
+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
| data octets ...
+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ...
We put the same UDP header in each segment, so (if we take some care
in how we choose the length of the segments) each one will have a
UDP Length field that is greater than the IP payload length minus
the combined length of any extension headers. Implementations that
conform to the current specifications should discard these segments,
and so should not mistakenly consider the segmentation fields as
part of the application data. That should make it possible for
segmented UDP datagrams to safely coexist with conventional
unsegmented one, without getting a new protocol number.
Possible downsides: some middleboxes may filter such "erroneous"
datagrams, and some existing erroneous implementations may fail to
do the checks they should and might mistake these segments for
ordinary UDP datagrams.
Note that this idea does not work with UDP-lite, which replaces the
Length field with a Checksum Coverage field. That could easily be
too short to exceed the L4 length from IP.
Mike Heard
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
