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 --------------------------------------------------------------------