Ron, On Aug 1, 2013, at 10:37 AM, Ronald Bonica <rbon...@juniper.net> wrote:
> 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. > > My personal opinion is that the conversation can start on 6man. We have some history of how to make TCP and UDP work over IPv6, so I think it's OK to start here. I am sure the ADs will decide to move it gains steam and they wish it elsewhere. Thanks, Bob > > >> -----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 --------------------------------------------------------------------
