RE: UDP+Fragmentation (was: "Deprecate")

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.templin@boeing.com

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@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-bounces@ietf.org [mailto:ipv6-bounces@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
> --------------------------------------------------------------------