Subject: Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

From: Ronald Bonica <[email-masked]>
Date: Thu, 4 Dec 2014 17:05:50 +0000

Fred,

Inline......

                  Ron

> 
> I have some questions on text in Section 4 of this document:
> 
> >    However, the IPv6 Destination Options Header MUST
> >    NOT be inserted between the GRE delivery header and the GRE header.
> 
> Why can't an IPv6 DO header be inserted?
[RPB] 
The DO messages will make it to the GRE egress and no farther. What DO messages would you like to send to the GRE egress?

> 
> >    However, a GRE ingress node MAY simply restrict itself to sending
> >    packets no larger than 1280 octets, and omit implementation of PMTUD.
> 
> That is incorrect. The GRE ingress MUST accommodate payload packets up to
> 1280 bytes in length. That means that the delivery packet will be up to
> 1280 bytes plus the length of the GRE header plus the length of the IPv6
> header plus any extension headers. So, a minimal delivery packet to
> accommodate an 1280 byte payload packet would be 1324 bytes.
> 
[RPB] 
The GRE ingress in an IPv6 source. As per RFC 2460, an IPv6 source MUST either execute PMTUD procedures or restrict itself to sending packets no longer than 1280 octets. How can you argue with that?

You might say:

- the PMTU between the GRE ingress and egress might be greater than or equal to 1280 but less than 1324
- In that case, if the GRE ingress is incapable of fragmenting the delivery header, the PMTU between the payload source and payload destination is less than 1280 and things break

However:
- Nobody said that the GRE ingress is incapable of fragmenting the delivery header
- We are talking about a corner case, anyway. The number 1280 was chosen to give us some headroom below the default 1500 byte Ethernet MTU.

Let's not boggle this document down in a fragmentation discussion. We can discuss fragmentation in the two documents that specifically address fragmentation.

                                                                                                                              Ron

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Dec 2014 10:41:54 -0800

On 12/4/2014 9:05 AM, Ronald Bonica wrote:
...
> [RPB] 
> The GRE ingress in an IPv6 source. As per RFC 2460, an IPv6 source
> MUST either execute PMTUD procedures or restrict itself to sending
> packets no longer than 1280 octets. How can you argue with that?

RFC2460 includes sending IPv6 packets up to 1500 bytes that are
reassembled at the destination IP address - in the case of a tunnel,
that's the egress.

Each *fragment* must be no larger than 1280, agreed.

PMTUD is recommended, not required (it's not a MUST).

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Dec 2014 18:46:46 +0000

Hi Ron,

> -----Original Message-----
> From: Ronald Bonica [mailto:[email-masked]]
> Sent: Thursday, December 04, 2014 9:06 AM
> To: [email-masked]
> Cc: Templin, Fred L
> Subject: Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01
> 
> Fred,
> 
> Inline......
> 
>                   Ron
> 
> 
> >

With tunnels, the ingress is the source and the egress is the destination. So, the
ingress (source) should be able to supply any DOs it thinks the egress (destination)
might need. I can tell you that I have one specific use case in mind, but where
there is one there are likely to be many others.

> The GRE ingress in an IPv6 source. As per RFC 2460, an IPv6 source MUST either execute PMTUD procedures or restrict itself to
> sending packets no longer than 1280 octets. How can you argue with that?

The only way the ingress can restrict itself to sending packets no longer than
1280 octets is by fragmenting delivery packets that contain payload packets
that would cause the delivery packet to exceed 1280.

There is no way to talk about the ingress restricting the size of the delivery
packets it sends to 1280 without also talking about fragmentation.

Thanks - Fred
[email-masked]

> - In that case, if the GRE ingress is incapable of fragmenting the delivery header, the PMTU between the payload source and payload
> destination is less than 1280 and things break
> 
> However:

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 5 Dec 2014 16:31:18 +0000

Inline.....

> From: Templin, Fred L [mailto:[email-masked]]
> Sent: Thursday, December 04, 2014 1:47 PM
> To: Ronald Bonica; [email-masked]
> Subject: RE: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-
> 01
> 
> Hi Ron,
> 
> > The DO messages will make it to the GRE egress and no farther. What DO
> messages would you like to send to the GRE egress?
> 
> With tunnels, the ingress is the source and the egress is the destination. So,
> the ingress (source) should be able to supply any DOs it thinks the egress
> (destination) might need. I can tell you that I have one specific use case in
> mind, but where there is one there are likely to be many others.
> 
[RPB] 
Could you describe a use case?

> > > 1280 bytes plus the length of the GRE header plus the length of the
> > > IPv6 header plus any extension headers. So, a minimal delivery
> > > packet to accommodate an 1280 byte payload packet would be 1324
> bytes.
> > >
> > [RPB]
[RPB] 
Please read to the bottom of the original email! Nobody ruled out fragmenting the deliver packet!

                                                                                 Ron

> > - In that case, if the GRE ingress is incapable of fragmenting the
> > delivery header, the PMTU between the payload source and payload
> > - We are talking about a corner case, anyway. The number 1280 was
> > chosen to give us some headroom below the default 1500 byte Ethernet
> MTU.
> >
> > Let's not boggle this document down in a fragmentation discussion. We
> > can discuss fragmentation in the two documents that specifically address
> fragmentation.
> >
> >
> > Ron
> >

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 5 Dec 2014 16:38:43 +0000

Joe,

Would you agree to the following change?

OLD>
Following guidance provided in Section 5 of [RFC2460], GRE ingress nodes SHOULD implement PMTUD, in order to discover and take advantage of PMTUs greater than the IPv6 required minimum (1280 octets).  However, a GRE ingress node MAY simply restrict itself to sending  packets no larger than 1280 octets, and omit implementation of PMTUD.
<OLD

NEW>
In as much as the GRE ingress is an IPv6 node, the following guidance from RFC 2460 applies:

" It is strongly recommended that IPv6 nodes implement Path MTU
   Discovery [RFC-1981], in order to discover and take advantage of path
   MTUs greater than 1280 octets.  However, a minimal IPv6
   implementation (e.g., in a boot ROM) may simply restrict itself to
   sending packets no larger than 1280 octets, and omit implementation
   of Path MTU Discovery."

<NEW

> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, December 04, 2014 1:42 PM
> RFC2460 includes sending IPv6 packets up to 1500 bytes that are reassembled
> at the destination IP address - in the case of a tunnel, that's the egress.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Dec 2014 17:23:19 +0000

Hi Ron,

> Sent: Friday, December 05, 2014 8:31 AM
> To: Templin, Fred L; [email-masked]
> Subject: RE: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01
> 
> Inline.....
> 

Why? Your document says "MUST NOT include DOs (sic)", and I am saying
that there is no reason for disallowing DOs when someone might want to
use them. DOs are part of the IPv6 architecture, and there is no reason for
GRE tunnels to exclude them.
 
> Please read to the bottom of the original email! Nobody ruled out fragmenting the deliver packet!

Please read what I wrote above; if this document wants to say that the ingress can
limit the size of the packets it sends to 1280, then *this document* needs to explain
that fragmentation is needed.

Thanks - Fred

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 5 Dec 2014 17:53:38 +0000

> that there is no reason for disallowing DOs when someone might want to use
> them. DOs are part of the IPv6 architecture, and there is no reason for GRE
> tunnels to exclude them.
> 
[RPB] 
I will be happy to add a sentence to the draft that says something like the following:

The IPv6 deliver header MUST NOT include Destination Options because the GRE ingress has nothing to say to the GRE egress beyond "de-encapsulate this packet and forward it to the egress".

Now would you be willing to divulge your use case?

> Please read what I wrote above; if this document wants to say that the
> ingress can limit the size of the packets it sends to 1280, then *this
> document* needs to explain that fragmentation is needed.
> 

[RPB] 
That isn't the goal of this document. However, I would be glad to remove the paragraph that offends you since it isn't really needed. It is already contained by RFC 2460.

                                                                                   Ron

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Dec 2014 18:26:41 +0000

Hi Ron,

> Sent: Friday, December 05, 2014 9:54 AM
> The IPv6 deliver header MUST NOT include Destination Options because the GRE ingress has nothing to say to the GRE egress beyond
> "de-encapsulate this packet and forward it to the egress".
> 

No, because your proposed language is silly. You have no idea what future uses
of DOs might  apply to tunnel ingress/egress pairs, and so "MUST NOT include
them" is a gratuitous requirement.

> is already contained by RFC 2460.

This document is very much in the same boat as RFC2473 in terms of packet size
issues (section 7). So, for completeness your document must tell what to do if
the path MTU is insufficient, including fragmentation.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Dec 2014 07:17:05 -0800

Hi, Ron (et al.),

The proposed change highlights exactly the problem: only minimal,
presumably transient versions of IPv6 should be limited to sending
packets no larger than 1280. I.e., only those versions are supposed to
omit source fragmentation.

Later in RFC2460 support for 1500-byte fragment reassembly is required,
so it's not appropriate to quote this section in isolation as the sole
recommendation for GRE.

Joe

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 8 Dec 2014 23:07:03 +0000

Joe,

I get your point. How does the following text sound?

OLD>

NEW>

5. MTU Considerations

"IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6" [RFC 2460].

IP adjacencies formed by GRE over IPv6 share this requirement. The IP adjacency MUST have an MTU of 1280 octets or greater. This requirement is fulfilled if all permissible routes between the GRE ingress and GRE egress have PMTU greater than or equal to the sum of the following:

- 1280
- GRE header length
- GRE delivery header length

It is also satisfied if the following procedure is executed:

- the GRE ingress encapsulates the payload in a single GRE header and IPv6 delivery header
- the GRE ingress divides the IPv6 delivery packet into fragments no larger than 1280 octets
- the GRE egress reassembles the IPv6 delivery packet
- the GRE egress removes the GRE header and IPv6 delivery header
<NEW

                                                               Ron

> Sent: Monday, December 08, 2014 10:17 AM
> presumably transient versions of IPv6 should be limited to sending packets
> no larger than 1280. I.e., only those versions are supposed to omit source
> fragmentation.
> 
> Later in RFC2460 support for 1500-byte fragment reassembly is required, so
> it's not appropriate to quote this section in isolation as the sole
> recommendation for GRE.
> 
> Joe
> 
> > Following guidance provided in Section 5 of [RFC2460], GRE ingress nodes
> SHOULD implement PMTUD, in order to discover and take advantage of
> PMTUs greater than the IPv6 required minimum (1280 octets).  However, a
> GRE ingress node MAY simply restrict itself to sending  packets no larger than
> 1280 octets, and omit implementation of PMTUD.
> > <OLD
> >
> > NEW>
> >> Subject: Re: [Int-area] Call for adoption of
> >> draft-pignataro-intarea-gre-ipv6-
> >> 01
> >>
> >>
> >>
> >> reassembled at the destination IP address - in the case of a tunnel, that's
> the egress.
> >>

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 8 Dec 2014 23:15:28 +0000

Fred,

Suresh points out that Section 4.1.1 of RFC 2473 may provide a reasonable use case. So, I will remove the text regarding destination options.

                                                                                   Ron

> > > Why? Your document says "MUST NOT include DOs (sic)", and I am
> > > saying that there is no reason for disallowing DOs when someone
> > > might want to use them. DOs are part of the IPv6 architecture, and
> > > there is no reason for GRE tunnels to exclude them.
> > >
> > [RPB]
> > The IPv6 deliver header MUST NOT include Destination Options because
> > the GRE ingress has nothing to say to the GRE egress beyond "de-
> encapsulate this packet and forward it to the egress".
> >
> No, because your proposed language is silly. You have no idea what future
> uses of DOs might  apply to tunnel ingress/egress pairs, and so "MUST NOT
> include them" is a gratuitous requirement.
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Dec 2014 15:58:14 -0800

Hi, Ron,

The first - and IMO, only important - question is whether this doc is
supposed to document what SHOULD BE or what IS.

If you're documenting what IS, there should be no question that any of
us need to answer - get a few devices, see what they do and report.

If we're talking about that these devices ought to do, we have a lot
more work to do, and I don't think it's useful to evaluate any one
aspect individually until the doc has been adopted by the WG - which,
IMO, ought to include a clear agreement on the scope of the doc.

Since we don't have that, I don't agree that wordsmithing is productive yet.

So IMO this is something to put a pin in and circle back to once we know
the scope of the doc.

Joe

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 9 Dec 2014 00:11:19 +0000

Joe,

This document UPDATES RFC 2784.  As such, it can be viewed as deltas to RFC 2784.

The introduction to RFC 2784 holds the answer to your question. I include its text below. The final sentence answers your question.

                                                                                                 Ron

Introduction

   A number of different proposals [RFC1234, RFC1226] currently exist
   for the encapsulation of one protocol over another protocol. Other
   types of encapsulations [RFC1241, RFC1479] have been proposed for
   transporting IP over IP for policy purposes. This memo describes a
   protocol which is very similar to, but is more general than, the
   above proposals.  In attempting to be more general, many protocol
   specific nuances have been ignored. The result is that this proposal
   may be less suitable for a situation where a specific "X over Y"
   encapsulation has been described.  It is the attempt of this protocol
   to provide a simple, general purpose mechanism which reduces the
   problem of encapsulation from its current O(n^2) size to a more
   manageable size. This memo purposely does not address the issue of
   when a packet should be encapsulated.  This memo acknowledges, but
   does not address problems such as mutual encapsulation [RFC1326].

   In the most general case, a system has a packet that needs to be
   encapsulated and delivered to some destination.  We will call this
   the payload packet.  The payload is first encapsulated in a GRE
   packet.  The resulting GRE packet can then be encapsulated in some
   other protocol and then forwarded.  We will call this outer protocol
   the delivery protocol. The algorithms for processing this packet are
   discussed later.

   Finally this specification describes the intersection of GRE
   currently deployed by multiple vendors.

> Sent: Monday, December 08, 2014 6:58 PM
> The first - and IMO, only important - question is whether this doc is supposed
> to document what SHOULD BE or what IS.
> 
> If you're documenting what IS, there should be no question that any of us
> need to answer - get a few devices, see what they do and report.
> 
> If we're talking about that these devices ought to do, we have a lot more
> work to do, and I don't think it's useful to evaluate any one aspect
> individually until the doc has been adopted by the WG - which, IMO, ought to
> include a clear agreement on the scope of the doc.
> 
> So IMO this is something to put a pin in and circle back to once we know the
> scope of the doc.
> 
> Joe
> 
> > "IPv6 requires that every link in the internet have an MTU of 1280 octets or
> greater. On any link that cannot convey a 1280-octet packet in one piece,
> link-specific fragmentation and reassembly must be provided at a layer
> below IPv6" [RFC 2460].
> >
> > IP adjacencies formed by GRE over IPv6 share this requirement. The IP
> adjacency MUST have an MTU of 1280 octets or greater. This requirement is
> fulfilled if all permissible routes between the GRE ingress and GRE egress
> have PMTU greater than or equal to the sum of the following:
> >
> > - 1280
> > - GRE header length
> > - the GRE egress removes the GRE header and IPv6 delivery header <NEW
> >
> >                                                                Ron
> >
> >
> >
> >> packets no larger than 1280. I.e., only those versions are supposed
> >> to omit source fragmentation.
> >>
> >> Later in RFC2460 support for 1500-byte fragment reassembly is
> >> required, so it's not appropriate to quote this section in isolation
> >> as the sole recommendation for GRE.
> >>
> >> Joe
> >>
> >> PMTUs greater than the IPv6 required minimum (1280 octets).  However,
> >> a GRE ingress node MAY simply restrict itself to sending  packets no
> >> larger than
> >>> In as much as the GRE ingress is an IPv6 node, the following
> >>> guidance from
> >> RFC 2460 applies:
> >>>

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Dec 2014 06:14:16 -0800

On 12/8/2014 4:11 PM, Ronald Bonica wrote:
> The introduction to RFC 2784 holds the answer to your question. 

Can you be more specific as to where?

This abstract doesn't clearly explain whether it's documenting current
protocols - with all their associated flaws - or proposing a new
variant, some aspects of which differ from what was available when the
doc was first developed.

I need to know whether we're reporters or dancers (on the head of a pin).

Joe

> I include its text below. The final sentence answers your question.
> 
>                                                                                                  Ron
> 
> Introduction
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 Dec 2014 17:17:45 -0800

> The introduction to RFC 2784 holds the answer to your question. I include its text below. The final sentence answers your question.

AOK - in that case, this doc ought to be very clear about doing the
same, explicitly.

Which means that any question to this group about how to handle any
given environment is irrelevant. If you're documenting the intersection
of what vendors DO, then that ought not need exploration of hypothetical
and corner cases.

Joe