Subject: RE: "Deprecate"

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Aug 2013 22:40:51 +0000

Hi Ran,

> Discussion:
>    Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-mode,
>    or some other IETF specified technology, are NOT going away.

Yes, this is the same as I and others have been saying all along.

> If the physical MTU is 1280, then the tunnel MTU will be smaller.

Not allowed; the tunnel MUST be able to do a minimum 1280.

>   Nested tunnels are not unusual and can be difficult to detect
>   absent a working PMTUD mechanism (whatever that might be).

Agree that nested tunnels are not unusual and are in fact in
common widespread deployment. But, there is no need to "detect"
them from the source host's perspective as long as they honor
the IPv6 1280 minMTU. That means that tunnels MUST be prepared
to do a small amount of fragmentation and reassembly when
necessary.

Thanks - Fred
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 02 Aug 2013 10:35:47 +1000

In message <[email-masked]
> to do a small amount of fragmentation and reassembly when

And if we generate appoximately equal sized fragments rather than
1280 byte fragments + a runt fragment tunnels would need to fragment
less often.  Your 1500 byte UDP payloads become 2 x 750 byte fragments
which can be encapulated multiple times.

It doesn't take a lot of math to work out what size to fragment at to
produce optimal fragment sizes for a given MTU.

Mark

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Fri, 02 Aug 2013 12:55:03 +0200

>  which can be encapulated multiple times.

=> I did this for the ISC AFTR code (the partner asked for).

>  produce optimal fragment sizes for a given MTU.

=> yes, it is not hard even the alignment constraints are not too
easy to handle (I coded it in two parts, first compute an ideal
fragment size, second integrate alignment constraints to produce
fragments with the same size at the exception of the last one).
I didn't see a huge difference but it looks better on the wire,
no tiny last fragement for instance...

Regards

[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 2 Aug 2013 08:05:49 -0400

> Not allowed; the tunnel MUST be able to do a minimum 1280.

A number of nested tunnel deployments that I'm aware of
simply do not support that 1280 MTU inside the innermost
tunnel -- because of accumulated tunnel encapsulation 
overhead.  

Those nested tunnel deployments are just as real as the PMTUD 
operational issues.  Each is applicable to some environments,
but not necessarily to all paths and all deployments.

If this document is to be reality-based, we need to acknowledge
all of the operational realities that have an impact on this topic, 
not just acknowledge some of the operational realities.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 2 Aug 2013 08:11:52 -0400

On 01  Aug 2013, at 20:35 , Mark Andrews wrote:
> And if we generate appoximately equal sized fragments
> rather than 1280 byte fragments + a runt fragment,
> tunnels would need to fragment less often.  Your 1500 byte
> UDP payloads become 2 x 750 byte fragments which can be
> encapsulated multiple times.
> 
> It doesn't take a lot of math to work out what size
> to fragment at to produce optimal fragment sizes
> for a given MTU.

All of the above seems like practical advice that 
should be considered for inclusion in this document.

(NB: I still would like to see C. M. Heard's ideas
explored in more detail by the IETF as they remain
interesting and possibly very useful even if the
above suggestions are implemented and deployed. :-)

Yours,

Ran

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Aug 2013 14:54:20 +0000

Hi Mark,

> -----Original Message-----
> From: Mark Andrews [mailto:[email-masked]]
> Sent: Thursday, August 01, 2013 5:36 PM
> To: Templin, Fred L
> Cc: RJ Atkinson; [email-masked]
> Subject: Re: "Deprecate"
> 
> 

Yes, SEAL covers this in earlier document versions. "Approximately equal
length is what it used to say; now it says:

" breaks the inner packet into N non-overlapping segments (where N is
  minimized and each segment is significantly smaller than (MINMTU-HLEN)
  to allow for additional encapsulations in the path)."

but I can modify this to say: "in N approximately equal length
non-overlapping segments" to bring back what I had in earlier
versions.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Aug 2013 15:04:52 +0000

Hi Ran,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> RJ Atkinson
> Sent: Friday, August 02, 2013 5:06 AM
> To: [email-masked]
> Subject: Re: "Deprecate"
> 
> 

If you mean an innermost IPv4 tunnel, I have certainly seen that
with IPv4 GRE within IPsec. If you mean an innermost IPv6 tunnel,
that is broken as far as the specs are concerned. The innermost
tunnel is not allowed to send a PTB reporting an MTU size smaller
than 1280.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Aug 2013 15:41:13 +0000

Hi,

Up to now, the SEAL spec has focused on "tunnel mode", and had the
singular statement:

  "(A transport-mode of operation is also possible, but out of scope
   for this document.)"

in the introduction. (Indeed, the first edition of SEAL (RFC5320)
did specify a transport mode of operation, but that document will
be obsolete by the second edition.) So, in light of these discussions
I decided that now might be a good time to bring transport mode back
into scope and as such have added the following new section to the
document. Please send comments and suggestions. I will post a new
draft version by the end of the day that will include both tunnel
and transport modes.

Thanks - Fred

6.  SEAL Transport Mode Specification

   SEAL is also used for transport-mode operation.  Transport mode
   refers to a SEAL encapsulation in which a layer-4 header appears
   immediately following the SEAL header.  The type of layer-4 header is
   indicated in the "NEXTHDR" field the same as for tunnel mode.  The
   SEAL header is identical to the version used for tunnel mode, except
   that the "LINK_ID" and "LEVEL" fields are omitted, and the transport
   layer port numbers are included in each non-initial segment (see:
   Figure 6).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    NEXTHDR    |VER|C|P|I|V|R|M|     Offset    |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Source Port (when Offset!=0)  |   Dest Port (when Offset!=0)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Identification (optional)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Integrity Check Vector (optional)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ...

                       Figure 6: SEAL Header Format

   The "Source Port" and "Dest Port" are taken from the corresponding
   fields in the transport layer next header that appears immediately
   following the SEAL header in the initial segment.  For example, for
   UDP [RFC0768] the transport layer source/dest ports are 16 bits in
   length and are copied from the transport layer header.  All
   segmentation is exactly as specified in SEAL tunnel mode, and the
   SEAL Control Message Protocol (SCMP) operates the same as for tunnel
   mode.  For example, the source node can probe the path MTU to the
   destination by setting the P bit in a probe packet and waiting for an
   acknowledgement from the destination.

   SEAL transport mode is useful for transport layer protocols that have
   no way to segment the large packets they send.  It is a universal
   format that can be applied to any such transport.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Aug 2013 15:59:33 +0000

One other thing to add:

   "SEAL transport mode implementations SHOULD configure reassembly buffers
    that are large enough to accommodate a maximum-sized SEAL packet, i.e.,
    they SHOULD configure a 64KB reassembly buffer size."

Thanks - Fred

> Templin, Fred L
> Sent: Friday, August 02, 2013 8:41 AM
> To: [email-masked]
> Subject: RE: "Deprecate"
> 
> Hi,
>

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 2 Aug 2013 10:35:07 -0700 (PDT)

Thanks for adding transport mode ... it's essential for addressing 
the issues under discussion on this thread.

//cmh