With a protocol as ossified as UDP, I have a hard time imagining all middleboxes passing the packets with what they would see as a corrupted length field.
Thanks - Fred [email protected] > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Ronald Bonica > Sent: Tuesday, August 06, 2013 11:49 AM > To: C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > Mike, > > The proposal sounds elegant. I will try to paraphrase it to make sure > that I understand. > > When originating a UDP datagram, the host always queries it underlying > IP stack to determine the PMTU for the destination. If the PMTU greater > than or equal to the size of the payload plus the UDP header plus the > IP header, plus all IP extension headers, the originating host emits a > conventional UDP packet which is characterized as follows: > > - Protocol = 17 > - Length <= L4 length from IP > > If the PMTU less than the size of the payload plus the UDP header plus > the IP header, plus all IP extension headers, the originating host > emits an unconventional UDP packet which is characterized as follows: > > - Protocol = 17 > - Length > L4 length from IP > - Segment Offset, M-bit and Identification fields added to UDP header > before the payload > > If an unconventional UDP packet arrives a destination that supports > unconventional packets, it is reassembled at the transport layer. If an > unconventional UDP packet arrives a destination that does not support > unconventional packets, it is discarded. > > Do I have this much right? > > Ron > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > Of > > C. M. Heard > > Sent: Monday, August 05, 2013 11:53 PM > > To: IPv6 > > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > > > 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 > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
