Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu

From: Ronald Bonica <[email-masked]>
Date: Thu, 9 Apr 2015 17:36:52 +0000

Fred,

How would you achieve backwards compatibility with legacy implementations? If backwards compatibility cannot be achieved, maybe you are talking about a new protocol, that will ultimately replace GRE?

                                                            Ron

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : GRE Tunnel Fragmentation
>         Author          : Fred L. Templin
> 	Filename        : draft-templin-intarea-grefrag-00.txt
> 	Pages           : 5
> 	Date            : 2015-04-09
> 
> Abstract:
>    GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet
>    when the delivery packet exceeds the tunnel MTU, or when otherwise
>    necessary.  This can cause problems when unmitigated IPv4
>    fragemntation ensues, or when middleboxes drop IPv6 fragments
>    unconditionally.  This document proposes GRE tunnel fragmentation
>    which avoids these pitfalls..
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Apr 2015 17:43:53 +0000

Hi Ron,

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Ronald Bonica
> Sent: Thursday, April 09, 2015 10:37 AM
> To: [email-masked]
> Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu
> 
> Fred,
> 
> How would you achieve backwards compatibility with legacy implementations? If backwards compatibility cannot be achieved, maybe
> you are talking about a new protocol, that will ultimately replace GRE?

Haven't thought about it too much, but I assume backwards compat would be
handled in the same way that it was handled when RFC2784 was updated by
RFC2890. That is why this document says "updates RFC2784 and RFC2890".

Plus, two new bits have been carved out of the Reserved0 field in the
GRE header and, if the bits are non-zero, it is a pretty good indication
that the fragment header is included.

Thanks - Fred
[email-masked]

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 9 Apr 2015 18:12:52 +0000

Fred,

What happens when a legacy device that supports 2784 and 2890 receives a packet that is fragmented as per draft-ietf-intarea-gre-mtu?

Is that behavior acceptable?

                                                                                            Ron

> From: Templin, Fred L [mailto:[email-masked]]
> Sent: Thursday, April 09, 2015 1:44 PM
> To: Ronald Bonica; [email-masked]
> Subject: RE: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu
> 
> Hi Ron,
> 
> > How would you achieve backwards compatibility with legacy
> > implementations? If backwards compatibility cannot be achieved, maybe
> Haven't thought about it too much, but I assume backwards compat would
> be handled in the same way that it was handled when RFC2784 was updated
> by RFC2890. That is why this document says "updates RFC2784 and RFC2890".
> 
> Plus, two new bits have been carved out of the Reserved0 field in the GRE
> header and, if the bits are non-zero, it is a pretty good indication that the
> fragment header is included.
> 
> Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Apr 2015 11:28:27 -0700

IMO, this doc should:

	- document existing default behavior

	- if needed, recommend SHOULD-level changes to
	that default behavior via currently-available
	configuration or deployment changes

I.e., describe where it can be used in a way consistent with existing
requirements, or indicate where that isn't the case and how it can be
detected and what to do when that happens.

I had already proposed a solution to this case, e.g., if the tunnel
cannot support the required IPv6 (or IPv4, for that matter) minimums, it
should shut itself down.

I'd like to see the updated text before jumping to conclusions, but I
don't think we need yet another new, undeployed solution.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Apr 2015 18:47:58 +0000

Hi Ron,

> From: Ronald Bonica [mailto:[email-masked]]
> Sent: Thursday, April 09, 2015 11:13 AM
> To: Templin, Fred L; [email-masked]
> What happens when a legacy device that supports 2784 and 2890 receives a packet that is fragmented

That would only happen when an augmented ingress send a fragmented
packet to a legacy egress that it knows nothing about - an unmanaged
situation. Two solutions are 1) allow the ingress to use the augmented
behavior when it knows that the egress also supports the behavior,
or 2) send the egress a little test packet for which the egress can only
respond if is supports the augmentation.

> as per draft-ietf-intarea-gre-mtu?

I think you meant per draft-templin-intarea-grefrag?

> Is that behavior acceptable?

The ingress should only use the augmented behavior when it knows
that the egress also supports the behavior - e.g., via administrative
configuration, test packet probing. etc.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Apr 2015 19:13:46 +0000

Hi Joe,

> From: Int-area [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Thursday, April 09, 2015 11:28 AM

There is lots of deployed kit out there that does not do this. Pretty much
anything that is based on RFC4213 (and there is a lot of that) just lets it
fragment. That is bad in a lot of ways (e.g., RFC4963, RFC6864, etc.) but
that is what is out there.

Shutting down tunnels over IPv6 makes no sense to me, because IPv6
frag/reass work (modulo paths that drop IPv6 fragments, I guess). Shutting
down tunnels over IPv4 sounds tempting, but can be avoided if the ingress
institutes rate limiting.

But, institution of tunnel fragmentation per draft-templin-intarea-grefrag,
draft-templin-aerolink and the others avoids these pitfalls and can keep
the tunnel up at least long enough for operators to diagnose the cause
of fragmentation if necessary.

Fragmentation is there to support the robustness principle. Shutting
down tunnels for fear of a little fragmentation is not robust.

Thanks - Fred

> > How would you achieve backwards compatibility with legacy implementations? If backwards compatibility cannot be achieved,
> maybe you are talking about a new protocol, that will ultimately replace GRE?
> >
> >                                                             Ron
> >
> >