UDP+Fragmentation (was: "Deprecate")

[Ronald Bonica <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>