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

From: Ronald Bonica <[email-masked]>
Date: Thu, 1 Aug 2013 08:37:32 +0000

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Aug 2013 15:37:41 +0000

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
[email-masked]

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

---

From: Bob Hinden <[email-masked]>
Date: Thu, 1 Aug 2013 23:14:59 +0200

Ron,

> 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. Howev…

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

---

From: Arturo Servin <[email-masked]>
Date: Fri, 02 Aug 2013 11:01:41 +0200

They aren't.

	There are still many places where I come from where operators do not
support native IPv6 and people need to rely in tunnels to start trying IPv6.

Regards,
as

On 7/30/13 11:55 PM, Ronald Bonica wrote:
> Fred,
> 
> I was thinking of tunnels as legacy applications, but we may need to make this explicit.
> 
>                            Ron

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Aug 2013 11:10:12 +0200

> support native IPv6 and people need to rely in tunnels to start trying

in this case.  ipv6 is *inside* the tunnel

so, unless you are one of the sickies who think ipv4 inside mpls inside
ipv6 inside ipv4 inside gre inside a chocolate bar is rational, this is
a bit of a non sequitur

randy