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: [email protected] [mailto:[email protected]] 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
> [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
--------------------------------------------------------------------
