Hi Ron, SEAL already handles the segmentation/reassembly such that it would not be necessary to define a new UDP. Plus, SEAL can be used independently of any transport layer, e.g., for IP-in-IP tunneling. If you are looking for a replacement for IPv6 fragmentation (which you should be) IMHO SEAL is the more versatile alternative.
Thanks - Fred fred.l.temp...@boeing.com > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Ronald Bonica > Sent: Thursday, August 01, 2013 1:38 AM > To: C. M. Heard; IPv6 > Subject: UDP+Fragmentation (was: "Deprecate") > > Cmh, > > When I read this message, my first reaction was to scream "that such a > thing could not possibly be deployed, because operators will filter > anything that they don't know or have an immediate use for." But after > a few hallway discussions, I am starting to think that the idea might > be viable. > > When the adrenaline and endorphin rush of IETF week has subsided, we > should a) discuss whether this is a viable option and b) if so, define > the replacement protocol in the Transport Area. > > Chairs, > > The conversation proposed above may not be within the charter of 6man. > If/when you think that there is a need to move this conversation, I can > ask the transport Ads for a non-WG mailing list. However, if you are > happy for at least the first part of this conversation to occur on this > mailing list, we can continue here. > > Ron > > > > > -----Original Message----- > > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf > Of > > C. M. Heard > > Sent: Wednesday, July 31, 2013 12:40 AM > > To: IPv6 > > Subject: RE: "Deprecate" > > > > On Tue, 30 Jul 2013, Ronald Bonica wrote: > > > Thinking a little more about it, RTP and UDP aren't the real > > culprits. > > > The culprits are the applications that run over them. > > > So, we should limit our statement to applications, and not > > > "applications and transport layer protocols". > > > > I don't agree, at least not if the principal reason why IP fragments > > get dropped is that they lack the L4 header (or at least that the > non- > > initial fragments do) and thereby break stateless ACLs. The problem > is > > that UDP and its kin such as UDP-lite and DCCP lack transport-layer > > segmentation, such as is present in TCP, and are thereby force their > > clients to rely on IP fragmentation to provide this service. So yes, > > these transport protocols are the culprits. > > > > The idea that immediately comes to mind is to design _replacements_ > > transport protocols for UDP and kin that contain a transport layer > > segmentation mechanism. These would be for use by applications that > > can't get by without such a mechanism; existing applications that > don't > > need to rely on IP fragmentation can continue to use UDP and kin. > The > > replacement for UDP might have a header that looks something like > this: > > > > 0 15 16 31 > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Source Port | Destination Port | > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Length | Segment Offset |Res|M| > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Identification | > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | Checksum | > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+ > > | data octets ... > > +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-| ... > > > > (Other and perhaps better possibilities exist, of course.) > > > > Having said that, I immediately imagine screaming that such a thing > > could not possibly be deployed, because operators will filter > anything > > that they don't know or have an immediate use for, and so it would > > never get any traction. > > > > Well, maybe so, but something has to give. The operations folks have > > complained that IP fragmentation is awful, they have to filter > > fragments because it defeats their stateless ACLs. OK; let's agree > > that's a defect that needs to be fixed. But if you don't want the > fix > > to break other important stuff (e.g., DNSSEC, as metioned in Section > > 3.1 of draft-bonica-6man-frag-deprecate-02), you need a replacement > for > > IP fragmentation (or an augmentation, such as in > > http://www.ietf.org/mail-archive/web/ipv6/current/msg18389.html by > Mark > > Andrews). Maybe I just lack imagination, but I can't see any fix > that > > does not involve SOME change in operator behavior. > > > > //cmh > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
