Subject: [Int-area] Last Call: <draft-ietf-intarea-gre-mtu-02.txt> (A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem) to Informational RFC

From: The IESG <[email-masked]>
Date: Thu, 09 Apr 2015 15:10:14 -0700

The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document:
- 'A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE)
   Fragmentation Problem'
  <draft-ietf-intarea-gre-mtu-02.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2015-04-23. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This memo describes how many vendors have solved the Generic Routing
   Encapsulation (GRE) fragmentation problem.  The solution described
   herein is configurable.  It is widely deployed on the Internet in its
   default configuration.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-intarea-gre-mtu/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-intarea-gre-mtu/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Apr 2015 09:00:16 +0100

I have read this document and consider it a useful addition to the 
material on GRE that will help new implementations arrive at an
interoperable solution.

Trivially I wondered whether there was a need for 
  3.3.2.3.  Tunneling GRE Over MPLS

Thanks,
Adrian

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 10 Apr 2015 21:26:08 +0900

As the draft says;

   o  When the GRE ingress node receives a non-fragmentable packet with
      length greater than the GMTU, it discards the packet and send an
      ICMP PTB message to the packet's source.

the draft should clearly state that, if GMTU<1280B, it is a violation
of the following requirement of RFC2460:

   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.

and that 1280B IPv6 packets can not be carried over IPv6 with the
default GRE configuration.

It is especially so, because, according to the draft:

   Typically, GRE ingress nodes further refine their GMTU estimate by
   executing PMTUD procedures.  However, if an implementation supports
   PMTUD for GRE tunnels, it also includes a configuration option that
   disables PMTUD.  This configuration option is required to mitigate
   certain denial of service attacks (see Section 5).

PMTUD is often turned off and, then, RFC2460 requires GMTU<1280B.

Also, I think the paragraph above is not very honest on the reason
why PMTUD is often turned off.

						Masataka Ohta

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Apr 2015 14:41:13 +0000

Hi,

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Masataka Ohta
> Sent: Friday, April 10, 2015 5:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Last Call: <draft-ietf-intarea-gre-mtu-02.txt> (A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE)
> Fragmentation Problem) to Informational RFC
> 
> As the draft says;
> 

We have been through this already. They want to say that widely deployed
implementations already ignore this requirement and so they want to
document the behavior to make it all OK. The non-robustness principle
in action.

Thanks - Fred
[email-masked]

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 10 Apr 2015 17:31:08 +0000

Masataka,

Thanks for your thoughtful review. Would your concern be addressed if we added the text below?

                                                                  Ron

TEXT
====

2.2.1. RFC 2460 Compliance

OLD>
The solution described above is widely-deployed on the Internet in its default configuration.
<OLD

NEW>
The solution described above is widely-deployed on the Internet in its default configuration. However, the default configuration is not always appropriate for GRE tunnels that carry IPv6.

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.  

Therefore, the default configuration is appropriate for tunnels that carry IPv6 only if the network is engineered so that the GMTU is guaranteed to be 1280-bytes or greater. In all other scenarios, a non-default configuration is required. 

In the non-default configuration, when the GRE ingress router receives a packet lager than the GMTU, the GRE ingress router encapsulates the entire packet in a single GRE and delivery header. It then fragments the delivery header and sends the resulting fragments to the GRE egress, where they are reassembled.

<NEW

> Sent: Friday, April 10, 2015 8:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Last Call: <draft-ietf-intarea-gre-mtu-02.txt> (A Widely-
> Deployed Solution To The Generic Routing Encapsulation (GRE)
> the draft should clearly state that, if GMTU<1280B, it is a violation of the
> following requirement of RFC2460:
> 
> and that 1280B IPv6 packets can not be carried over IPv6 with the default GRE
> configuration.
> 
> Also, I think the paragraph above is not very honest on the reason why
> PMTUD is often turned off.
> 
> 						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 11 Apr 2015 09:31:07 +0900

Hi,

> implementations already ignore this requirement

How the requirement is ignored? Is GMTU<1280B or are GRE gateways
sending >1280B  packets without PMTUD?

> and so they want to document the behavior to make it all OK.

Then, the document should be on standard track updating RFC2460.

That's how the "running code" principle works, or, why implementations
and operational experiences are required for draft and full standards.

Let feedback from the real world work to fix poor specifications.

> The non-robustness principle in action.

For the robustness,  IPv6 capable hosts should not send, e.g., >1200B
packets without PMTUD, while links are still required to have
MTU of >=1280B.

Or,  IPv6 capable hosts should not send,  >1280B packets without
PMTUD, while links are required to have MTU of, e.g., >=1400B.

						Masataka Ohta