Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Apr 2015 14:13:20 +0000

Hi David,

> -----Original Message-----
> From: Black, David [mailto:[email-masked]]
> Sent: Tuesday, March 31, 2015 7:06 PM
> To: Templin, Fred L; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; Black, David
> Subject: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration
> 
> So, I talked to Ron off-list and it looks like something is missing from
> this discussion.
> 
> The "alternative configuration" is not motivated by a desire to allow
> implementation flexibility or bless broken implementations.  It's motivated
> by consideration of networks with operational practices wherein a GMTU of
> less than 1280 octets is evidence that something is seriously wrong.  That
> something might be misconfiguration (quoting RFC 5706, "Anything that
> can be configured can be misconfigured."), or an attack on the GRE
> ingress's PMTU estimation.
> 
> So, in the situation of interest (GMTU < 1280) something is wrong, and
> the operator may be faced with a Hobson's choice: either blackhole the
> traffic that can no longer be sent without fragmentation, or fragment a
> lot of traffic, causing problems at the GRE egress by overwhelming its
> reassembly code - there may be good operational and/or security reasons
> to not want to do the latter.  All of this ought to be explained in the
> draft.

No, that's is not right. GMTU < 1280 is not necessarily an indication
that something is wrong, as explained in Section 7 of RFC2473. The
same considerations apply here.

Thanks - Fred
[email-masked]

> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Int-area [mailto:[email-masked]] On Behalf Of Templin, Fred L
> > Sent: Tuesday, March 31, 2015 6:39 PM
> > To: Ronald Bonica; [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6
> >
> > Hi Ron,
> >
> > > -----Original Message-----
> > > From: Ronald Bonica [mailto:[email-masked]]
> > > Sent: Tuesday, March 31, 2015 3:12 PM
> > > To: Templin, Fred L; [email-masked]; [email-masked]
> > > Cc: Zuniga, Juan Carlos; [email-masked];
> > [email-masked]
> > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6
> > >
> > > Fred,
> > >
> > > It appears that we disagree and have taken to repeating ourselves.
> >
> > This is not a disagreement; this is a case in which the text is actually
> > broken
> > which you have more or less acknowledged. You can fix the text in question
> > as follows:
> >
> > OLD:
> > ****
> >    In its default configuration, the GRE ingress router MUST:
> >
> >    o  encapsulate the entire IPv6 packet in a single GRE header and IP
> >       delivery header
> >
> >    o  fragment the delivery header, so that it can be reassembled by the
> >       GRE egress
> >
> >    However, in an alternative configuration, the GRE ingress MAY:
> >
> >    o  discard the IPv6 packet
> >
> >    o  send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6
> >       packet source.  The MTU field in the ICMPv6 PTB message is set to
> >       the GMTU.
> >
> > NEW:
> > ****
> >    The GRE ingress router MUST:
> >
> >    o  if the IPv6 payload packet includes a fragment header, fragment the
> >        payload packet into fragments no larger than the GMTU and encapsulate
> >       each fragment in a single GRE header and IP delivery header. Otherwise:
> >
> >       o encapsulate the entire IPv6 packet in a single GRE header and IP
> >           delivery header
> >
> >       o fragment the delivery packet, so that it can be reassembled by the
> >           GRE egress
> >
> >      o  send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6
> >          packet source, subject to rate limiting.  The MTU field in the ICMPv6
> > PTB
> >         message is set to the GMTU.
> >
> > > So, why don't we solicit opinions from the rest of the WG and defer to their
> > will.
> >
> > We can't do that for broken text. Ram-rodding broken text through the
> > process based on popular opinion does not make it good.
> >
> > Thanks - Fred
> > [email-masked]
> >
> > >
> > >                                                         Ron
> > >
> > >
> > > > -----Original Message-----
> > > > From: Templin, Fred L [mailto:[email-masked]]
> > > > Sent: Tuesday, March 31, 2015 4:38 PM
> > > > To: Ronald Bonica; [email-masked]; [email-masked]
> > > > Cc: Zuniga, Juan Carlos; [email-masked];
> > intarea-
> > > > [email-masked]
> > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6
> > > >
> > > > Hi Ron,
> > > >
> > > > I will say again that the minimum IPv6 link MTU is 1280 bytes and so the
> > > > design must account for tunnel paths that include links with such a small
> > > > MTU. The design must also account for nested tunnels-within-tunnels,
> > > > where the MTU seen by the first tunnel ingress may be reduced by
> > > > potentially many layers of additional encapsulation.
> > > >
> > > > But again, the point is that the tunnel ingress cannot legitimately send
> > PTBs
> > > > that report a size smaller than 1280 *and* perpetually drop packets
> > smaller
> > > > than 1280 which is exactly the behavior your text is permitting.
> > > >
> > > > Thanks - Fred
> > > > [email-masked]
> > > >
> > > > > -----Original Message-----
> > > > > From: Ronald Bonica [mailto:[email-masked]]
> > > > > Sent: Tuesday, March 31, 2015 1:21 PM
> > > > > To: Templin, Fred L; [email-masked]; [email-masked]
> > > > > Cc: Zuniga, Juan Carlos; [email-masked];
> > > > > [email-masked]
> > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6
> > > > >
> > > > > Fred,
> > > > >
> > > > > In the last network that I operated, all interior links had MTU
> > > > > greater than 9k. If I configured a GRE tunnel between two points in that
> > > > network and detected a GMTU less than 1280, it would have indicated one of
> > > > the following:
> > > > >
> > > > > - Phenomenal brokenness
> > > > > - An ICMP PTB-based attack in progress
> > > > >
> > > > > In such cases, operators need some flexibility in how their networks
> > > > > would behave. Why deny them this flexibility by taking away the
> > > > configuration option?
> > > > >
> > > > > Isn't it an operator's prerogative to discard any packet that might
> > degrade
> > > > network performance?
> > > > >
> > > > >
> > > > > Ron
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Templin, Fred L [mailto:[email-masked]]
> > > > > > Sent: Tuesday, March 31, 2015 3:01 PM
> > > > > > To: Ronald Bonica; [email-masked]; [email-masked]
> > > > > > Cc: Zuniga, Juan Carlos; [email-masked];
> > > > > > intarea- [email-masked]
> > > > > > Subject: RE: [Int-area] Start of WGLC for
> > > > > > draft-ietf-intarea-gre-ipv6
> > > > > >
> > > > > > Hi Ron,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ronald Bonica [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, March 31, 2015 11:38 AM
> > > > > > > To: Templin, Fred L; [email-masked]; [email-masked]
> > > > > > > Cc: Zuniga, Juan Carlos;
> > > > > > > [email-masked];
> > > > > > > [email-masked]
> > > > > > > Subject: RE: [Int-area] Start of WGLC for
> > > > > > > draft-ietf-intarea-gre-ipv6
> > > > > > >
> > > > > > > Fred,
> > > > > > >
> > > > > > > Some (if not most) operators maintain networks in which all links
> > > > > > > have MTU greater than or equal to 1500. In those networks, the
> > > > > > > very detection of a GMTU smaller than 1280 indicates brokenness.
> > > > > > > Those
> > > > > > operators, the alternative behavior may be preferable to the default.
> > > > > >
> > > > > > The minimum IPv6 MTU is 1280 bytes; that is how much the link must
> > > > > > deliver no matter what. A GMTU smaller than 1280 does not indicate
> > > > > > brokennesss; it can naturally happen if 1) there is a link with a
> > > > > > small MTU in the path, or
> > > > > > 2) there are multiple tunnel nesting levels, or both.
> > > > > >
> > > > > > As such, sustained dropping of packets less than 1280 is a no-no,
> > > > > > and cannot be specified in a document like this.
> > > > > >
> > > > > > Thanks - Fred
> > > > > > [email-masked]
> > > > > >
> > > > > > >
> > > > > > > Ron
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Templin, Fred L [mailto:[email-masked]]
> > > > > > > > Sent: Tuesday, March 31, 2015 1:30 PM
> > > > > > > > To: Ronald Bonica; [email-masked]; [email-masked]
> > > > > > > > Cc: Zuniga, Juan Carlos;
> > > > > > > > [email-masked];
> > > > > > > > intarea- [email-masked]
> > > > > > > > Subject: RE: [Int-area] Start of WGLC for
> > > > > > > > draft-ietf-intarea-gre-ipv6
> > > > > > > >
> > > > > > > > Hi Ron,
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Ronald Bonica [mailto:[email-masked]]
> > > > > > > > > Sent: Tuesday, March 31, 2015 10:18 AM
> > > > > > > > > To: [email-masked]; [email-masked]
> > > > > > > > > Cc: Zuniga, Juan Carlos; Templin, Fred L;
> > > > > > > > > [email-masked];
> > > > > > > > > [email-masked]
> > > > > > > > > Subject: Re: [Int-area] Start of WGLC for
> > > > > > > > > draft-ietf-intarea-gre-ipv6
> > > > > > > > >
> > > > > > > > > Hi Fred,
> > > > > > > > >
> > > > > > > > >      Inline.....
> > > > > > > > >
> > > > > > > > >                Ron
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Hi Juan Carlos,
> > > > > > > > > >
> > > > > > > > > > Final passage of Section 3.1 says:
> > > > > > > > > >
> > > > > > > > > >    ?However, in an alternative configuration, the GRE ingress
> > MAY:
> > > > > > > > > >
> > > > > > > > > >    o  discard the IPv6 packet
> > > > > > > > > >
> > > > > > > > > >    o  send an ICMPv6 Packet Too Big (PTB) [RFC4443] message
> > > > > > > > > > to the
> > > > > > IPv6
> > > > > > > > > >       packet source.  The MTU field in the ICMPv6 PTB message
> > is set
> > > > to
> > > > > > > > > >       the GMTU.?
> > > > > > > > > >
> > > > > > > > > > This means that there may be circumstances when the GRE
> > > > > > > > > > ingress sends a PTB reporting a size less than 1280.
> > > > > > > > > > According to RFC2460, Section 5, the standard behavior for a
> > > > > > > > > > host that receives
> > > > > > such a PTB is:
> > > > > > > > > >
> > > > > > > > > >    ?In that case, the IPv6 node
> > > > > > > > > >   is not required to reduce the size of subsequent packets to
> > less
> > > > than
> > > > > > > > > >    1280, but must include a Fragment header in those packets?
> > > > > > > > > >
> > > > > > > > > > So, hosts that obey RFC2460 Section 5 will see a perpetual
> > > > > > > > > > black hole if the GMTU is smaller than 1280 which is
> > > > > > > > > > probably not what we
> > > > > > > > want.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > [RPB]
> > > > > > > > > All true. This is why the WG decided to make this the
> > > > > > > > > alternative behavior
> > > > > > > > and not the default behavior.
> > > > > > > >
> > > > > > > > Behavior that is broken is still broken regardless of whether it
> > > > > > > > is alternative or default.
> > > > > > > >
> > > > > > > > > > ?draft-templin-6man-linkadapt? attempts to provide guidance
> > > > > > > > > > to hosts on how to react to PTB messages that report a small
> > size.
> > > > > > > > > > But, as of right now,
> > > > > > > > > > RFC2460 Section 5 is the normative behavior.
> > > > > > > > > [RPB]
> > > > > > > > >
> > > > > > > > > Absolutely correct. The procedures described in Section 5 or
> > > > > > > > > RFC
> > > > > > > > > 246 are
> > > > > > > > normative.
> > > > > > > > >
> > > > > > > > > I don't how this impacts the WG's LC decision regarding the
> > > > > > > > > current
> > > > > > draft.
> > > > > > > >
> > > > > > > > Broken behavior should not be specified, whether alternative or
> > > > default.
> > > > > > > >
> > > > > > > > Thanks - Fred
> > > > > > > > [email-masked]
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Ron
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Thanks ? Fred
> > > > > > > > > > [email-masked]
> > > > > > > > > >
> > > > > > > > >
> >
> > _______________________________________________
> > Int-area mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/int-area

---

From: "Black, David" <[email-masked]>
Date: Wed, 1 Apr 2015 15:43:19 +0000

Fred,

> same considerations apply here.

I agree with the text quoted above, but what I'm observing is that there
are networks for which GMTU is an indication that something is wrong
(this is a consequence of operator decisions that are specific to such
a network).  The alternative configuration is intended for such networks,
but is not intended for all networks, and would need to be qualified
with words making it applicable primarily or only (or suggest some
other words) to such networks.

Upshot: the use of "necessarily" in the text quoted above is correct, but
misses the point.

Thanks,
--David

> Sent: Wednesday, April 01, 2015 10:13 AM
> To: Black, David; [email-masked]; [email-masked]
> Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration
> 
> Hi David,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Apr 2015 16:11:40 +0000

Hi David,

> Sent: Wednesday, April 01, 2015 8:43 AM
> I agree with the text quoted above,

OK, then this document should cite Section 7 of RFC2473 normatively.

> but what I'm observing is that there

If there is operational assurance that all links in the tunnel path configure
a sufficiently large MTU, and there will never be a nesting of tunnels that
would result in a too-small MTU, then tunnel fragmentation would not
need to be invoked and there is no need to talk about sending PTBs with
GMTU less than 1280. Or, if you did want to include text that would tell
what to do in the case of misconfigurations, then this document would
need to update RFC2473 since the same considerations apply to generic
encapsulation over IPv6 and not just GRE encapsulation over IPv6.

Thanks - Fred

---

From: "Black, David" <[email-masked]>
Date: Wed, 1 Apr 2015 20:26:00 +0000

Fred,

> > I agree with the text quoted above,

Adding the rest of the sentence ...

> > a network).

> OK, then this document should cite Section 7 of RFC2473 normatively.

I think it would be better to directly explain the GRE situation here, and
add an informative citation of RFC 2473 as providing additional explanation,
particularly for situations in which different operational practices are used.

> GMTU less than 1280.

Never say "never" ... quoting RFC 5706, "Anything that can be configured can
be misconfigured." ;-).

I'll leave the rationale for sending PTBs to Ron, but keep in mind that
"running code" (i.e., existing implementations) is(are) an important
consideration - see the second sentence in the Introduction.

> Or, if you did want to include text that would tell

It's more than misconfigurations - attacks on PMTU monitoring can have
similar effects.

Beyond that, if an update to RFC 2473 is desired, this GRE-scoped draft
seems like a poor vehicle for that purpose (e.g., as RFC 2784 does not
cite RFC 2473); I think a separate draft would be more appropriate.

Thanks,
--David

> Sent: Wednesday, April 01, 2015 12:12 PM
> > > > > From: Int-area [mailto:[email-masked]] On Behalf Of
> Templin,
> > > Fred L
> > > > >          packet source, subject to rate limiting.  The MTU field in
> the
> > > ICMPv6
> > > > > PTB
> > > > > > So, why don't we solicit opinions from the rest of the WG and defer
> to
> > > their
> > > > > will.
> > > > >
> > > > > > > I will say again that the minimum IPv6 link MTU is 1280 bytes and
> so
> > > the
> > > > > > > design must account for tunnel paths that include links with such
> a
> > > small
> > > > > > > But again, the point is that the tunnel ingress cannot
> legitimately
> > > send
> > > > > PTBs
> > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-
> gre-
> > > ipv6
> > > > > > > >
> > > > > > > > Fred,
> > > > > > > >
> > > > > > > > greater than 9k. If I configured a GRE tunnel between two points
> in
> > > that
> > > > > > > network and detected a GMTU less than 1280, it would have
> indicated
> > > one of
> > > > > > > the following:
> > > > > > > >
> > > > > > > > - Phenomenal brokenness
> > > > > > > > > > > > > According to RFC2460, Section 5, the standard behavior
> for
> > > a
> > > > > > > > > > > > > host that receives
> > > > > > > > > such a PTB is:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   is not required to reduce the size of subsequent
> packets
> > > to
> > > > > less
> > > > > > > than
> > > > > > > > > > > Behavior that is broken is still broken regardless of
> whether
> > > it
> > > > > > > > > > > Broken behavior should not be specified, whether
> alternative
> > > or
> > > > > > > default.
> > > > > > > > > > >
> > > > > > > > > > > Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Apr 2015 21:33:34 +0000

Hi David,

> Sent: Wednesday, April 01, 2015 1:26 PM

How is the GRE situation any different than for any generic encapsulation
in IPv6 situation (RFC2473)? Are you meaning to say "GRE in specific use
cases"? Section 7 of RFC2473 already provides guidance that applies also
to GRE in any use case. 

> Never say "never" ... quoting RFC 5706, "Anything that can be configured can

Right, that's what I said (having used that phrase many times in
the past myself).

> consideration - see the second sentence in the Introduction.

Sending PTB with MTU<1280 is supposed to have an effect as described
in Section 5 of RFC. Namely, the original source is supposed to start
including IPv6 fragment headers in subsequent packets and the network
is supposed to find some way to get them through. What Ron's text
is suggesting is that the original source lives up to its part of the bargain
but then the network dumps the packets into a black hole.

> It's more than misconfigurations - attacks on PMTU monitoring can have

If you want to start talking about PTB forgery, then we should also talk
about  PTB filtering and how the mechanisms work when PTBs are lost.
RFC2473 itself is imperfect in that regard, and this draft is not proposing
anything different than RFC2473.

> cite RFC 2473); I think a separate draft would be more appropriate.

OK, then have this draft simply cite RFC2473, Section 7 normatively
and break the exception cases out into a separate document like
intarea-tunnels. The exception cases are not limited to GRE in
particular, and apply also to any generic tunneling in IPv6.

Thanks - Fred

---

From: "Black, David" <[email-masked]>
Date: Wed, 1 Apr 2015 23:07:43 +0000

> cases"?

Yes, specifically networks where a GMTU < 1280 always indicates a problem.

> Section 7 of RFC2473 already provides guidance that applies also
> to GRE in any use case.

Ok, as previously noted - the text here is specific to GRE and certain
networks.

> particular, and apply also to any generic tunneling in IPv6.

Right now, the exception case is proposed as GRE-only, and hence is
appropriate for this draft.  I hesitate to generalize it to all IPv6
tunnels or have the GRE provisions await that being done.

Thanks,
--David

> Sent: Wednesday, April 01, 2015 5:34 PM
> > > > > > Cc: [email-masked]; intarea-
> [email-masked];
> > > > > Black, David
> > > > > > by consideration of networks with operational practices wherein a
> GMTU
> > > of
> > > > > > >    o  fragment the delivery header, so that it can be reassembled
> by
> > > the
> > > > > > >       GRE egress
> > > > > > >
> > > > > > >       packet source.  The MTU field in the ICMPv6 PTB message is
> set
> > > to
> > > > > > >       the GMTU.
> > > > > > >
> > > > > > > NEW:
> > > > > > > ****
> > > > > > >    o  if the IPv6 payload packet includes a fragment header,
> fragment
> > > the
> > > > > > >       o encapsulate the entire IPv6 packet in a single GRE header
> and
> > > IP
> > > > > > >           delivery header
> > > > > > >
> > > > > > >       o fragment the delivery packet, so that it can be
> reassembled by
> > > the
> > > > > > >           GRE egress
> > > > > > >
> > > > > > >      o  send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to
> the
> > > IPv6
> > > > > > > > > > Isn't it an operator's prerogative to discard any packet
> that
> > > might
> > > > > > > degrade
> > > > > > > > > network performance?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Ron
> > > > > > > > > >
> > > > > > > > > > > > Some (if not most) operators maintain networks in which
> all
> > > > > links
> > > > > > > > > > > > have MTU greater than or equal to 1500. In those
> networks,
> > > the
> > > > > > > > > > > operators, the alternative behavior may be preferable to
> the
> > > > > default.
> > > > > > > > > > >
> > > > > > > > > > > The minimum IPv6 MTU is 1280 bytes; that is how much the
> link
> > > must
> > > > > > > > > > > As such, sustained dropping of packets less than 1280 is a
> no-
> > > no,
> > > > > > > > > > > > > > >    ?However, in an alternative configuration, the
> GRE
> > > > > ingress
> > > > > > > MAY:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    o  send an ICMPv6 Packet Too Big (PTB)
> [RFC4443]
> > > > > message
> > > > > > > > > > > > > > > to the
> > > > > > > > > > > IPv6
> > > > > > > > > > > > > > >       packet source.  The MTU field in the ICMPv6
> PTB
> > > > > message
> > > > > > > is set
> > > > > > > > > to
> > > > > > > > > > > > > > >       the GMTU.?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This means that there may be circumstances when
> the
> > > GRE
> > > > > > > > > > > > > > >    1280, but must include a Fragment header in
> those
> > > > > packets?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > to hosts on how to react to PTB messages that
> report a
> > > > > small
> > > > > > > size.
> > > > > > > > > > > > > > > But, as of right now,
> > > > > > > > > > > > > > Absolutely correct. The procedures described in
> Section
> > > 5 or
> > > > > > > > > > > > > > RFC
> > > > > > > > > > > > > > 246 are
> > > > > > > > > > > > > normative.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't how this impacts the WG's LC decision
> regarding
> > > the
> > > > > > > > > > > > > > current
> > > > > > > > > > > draft.
> > > > > > > > > > > > >

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Apr 2015 23:17:27 +0000

Hi David,

> Sent: Wednesday, April 01, 2015 4:08 PM

OK, for specific use cases then, i.e., the same as for any generic
IPv6 encapsulation in specific use cases and not only for GRE.

> Ok, as previously noted - the text here is specific to GRE and certain

Specific to certain networks, perhaps, but not specific to GRE.

> tunnels or have the GRE provisions await that being done.

This is where we differ - there is nothing in this recommendation
that is specific to GRE - the recommendation applies to any generic
IPv6 encapsulation and is appropriate to only those use cases where
shutting down the tunnel altogether is preferable to allowing the
tunnel to fragment. This is a generic IPv6 encapsulation consideration;
not a GRE consideration.

Thanks - Fred

> > and IP

---

From: "Black, David" <[email-masked]>
Date: Wed, 1 Apr 2015 23:26:42 +0000

One more inline ...

> Sent: Wednesday, April 01, 2015 7:17 PM

The "running code" involved here is GRE.  I am concerned that we lack
the foundation to update 2473 for all encapsulated protocols.

> > > > > > Upshot: the use of "necessarily" in the text quoted above is
> correct,
> > > but
> > > > > > misses the point.
> > > > > >
> > > > > > Thanks,
> > > > > > --David
> > > > > >
> > > > > > > > So, I talked to Ron off-list and it looks like something is
> missing
> > > from
> > > > > > > > this discussion.
> > > > > > > >
> > > > > > > > implementation flexibility or bless broken implementations.
> It's
> > > > > motivated
> > > > > > > > less than 1280 octets is evidence that something is seriously
> wrong.
> > > > > That
> > > > > > > > So, in the situation of interest (GMTU < 1280) something is
> wrong,
> > > and
> > > > > > > > the operator may be faced with a Hobson's choice: either
> blackhole
> > > the
> > > > > > > > lot of traffic, causing problems at the GRE egress by
> overwhelming
> > > its
> > > > > > > > to not want to do the latter.  All of this ought to be explained
> in
> > > the
> > > > > > > > draft.
> > > > > > >
> > > > > > > > > Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-
> gre-
> > > ipv6
> > > > > > > > >
> > > > > > > > > Hi Ron,
> > > > > > > > >
> > > > > > > > > This is not a disagreement; this is a case in which the text
> is
> > > > > actually
> > > > > > > > > broken
> > > > > > > > > which you have more or less acknowledged. You can fix the text
> in
> > > > > question
> > > > > > > > > as follows:
> > > > > > > > >
> > > > > > > > > OLD:
> > > > > > > > > ****
> is
> > > > > > > > >        payload packet into fragments no larger than the GMTU
> and
> > > > > > > encapsulate
> > > > > > > > >       each fragment in a single GRE header and IP delivery
> header.
> > > > > > > Otherwise:
> > > > > > > > >
> > > > > > > > >          packet source, subject to rate limiting.  The MTU
> field
> > > in
> > > > > the
> > > > > > > ICMPv6
> > > > > > > > > PTB
> > > > > > > > > > So, why don't we solicit opinions from the rest of the WG
> and
> > > defer
> > > > > to
> > > > > > > their
> > > > > > > > > will.
> > > > > > > > >
> > > > > > > > > We can't do that for broken text. Ram-rodding broken text
> through
> > > the
> > > > > > > > > > > I will say again that the minimum IPv6 link MTU is 1280
> bytes
> > > and
> > > > > so
> > > > > > > the
> > > > > > > > > > > design must account for tunnel paths that include links
> with
> > > such
> > > > > a
> > > > > > > small
> > > > > > > > > > > MTU. The design must also account for nested tunnels-
> within-
> > > > > tunnels,
> > > > > > > > > > > where the MTU seen by the first tunnel ingress may be
> reduced
> > > by
> > > > > > > > > > > that report a size smaller than 1280 *and* perpetually
> drop
> > > > > packets
> > > > > > > > > smaller
> > > > > > > > > > > > In the last network that I operated, all interior links
> had
> > > MTU
> > > > > > > > > > > > greater than 9k. If I configured a GRE tunnel between
> two
> > > points
> > > > > in
> > > > > > > that
> > > > > > > > > > > > In such cases, operators need some flexibility in how
> their
> > > > > networks
> > > > > > > > > > > > would behave. Why deny them this flexibility by taking
> away
> > > the
> > > > > > > > > > > configuration option?
> > > > > > > > > > > >
> > > > > > > > > > > > > deliver no matter what. A GMTU smaller than 1280 does
> not
> > > > > indicate
> > > > > > > > > > > > > brokennesss; it can naturally happen if 1) there is a
> link
> > > > > with a
> > > > > > > > > > > > > > > > > So, hosts that obey RFC2460 Section 5 will see
> a
> > > > > perpetual
> > > > > > > > > > > > > > > > > black hole if the GMTU is smaller than 1280
> which
> > > is
> > > > > > > > > > > > > > > > > probably not what we
> > > > > > > > > > > > > > > want.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > [RPB]
> > > > > > > > > > > > > > > > All true. This is why the WG decided to make
> this
> > > the
> > > > > > > > > > > > > > > > alternative behavior
> > > > > > > > > > > > > > > > > ?draft-templin-6man-linkadapt? attempts to
> provide
> > > > > > > guidance

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 2 Apr 2015 14:49:02 +0000

Hi David,

> the foundation to update 2473 for all encapsulated protocols.

I don't get that. Just write a 3-pager that says it is OK for any kind of
tunnel to collapse if it gets into a state where fragmentation is needed;
a halt-and-catch-fire clause. But, why would you even need an RFC for that?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Apr 2015 08:06:15 -0700

> a halt-and-catch-fire clause. But, why would you even need an RFC for that?

For the benefit of others, here's my view on this (as I posted to Fred
yesterday, which is where collapsing the tunnel comes from):

defs:
	ingress packet - what arrives at the tunnel ingress

	egress packet - what leaves at the tunnel egress

	tunnel packet - packet that traverses from the
			ingress to egress, that contains
			the ingress packet plus encapsulation

	tunnel MTU - MTU of the path between ingress and egress
		of tunneled packets

	reassembly MTU - largest tunnel packet that can be
		reassembled at the egress

General rules (which apply to more than GRE; they should apply to ANY
tunnel that carries ANY packet):

	ingress packet <= (tunnel MTU - encapsulation)
		send through the tunnel as one tunnel packet

	ingress packet > (reassembly MTU - encapsulation)
		drop and send ICMP PTB back

	(tunnel MTU - encaps) < ingress packet <= (reassy MTU - encaps)
		do one of the following:

		a) fragment at ingress and reassemble at egress

		b) drop and declare the link down to all further
		traffic until a probe of size "reassy MTU"
		succeeds to the egress

		(this is what Fred just called "halt and catch fire",
		but it has an important property:
			- stay down while the required tunnel MTU
			cannot traverse without fragmentation
			- come up when the required tunnel MTU
			is supported)

		(a) is more robust but more expensive to implement

The tunnel MTU is defined by the protocols over which the tunnel is
defined as transiting.

The egress MTU is defined by the encapsulation protocol.
		
Note: the (b) case is allowed because a link can always declare itself
down. What it should never do is fail to transit packets that should fit
while allowing other smaller packets to get through - i.e., a link
should never be allowed to redefine the specs of the type of protocol
link it intends to support.

The rules are augmented a bit when the ingress packet can be re-fragmented:

	ingress packet <= (tunnel MTU - encapsulation)
		send through the tunnel as one tunnel packet

	ingress packet > (reassembly MTU - encapsulation)
		refragment the ingress packet to fit the tunnel MTU

	(tunnel MTU - encaps) < ingress packet <= (reassy MTU - encaps)
		do one of the following:
		a) fragment at ingress and reassemble at egress

		b) refragment the ingress packet to fit the tunnel MTU

		in this case, (b) is preferred
---

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 2 Apr 2015 15:34:57 +0000

Hi Joe,

It looks from your description that you have at least read Section 3.13 of
draft-templin-aerolink, because there are many similarities. However,
AERO is more comprehensive in the way it minimizes fragmentation and
turns off fragmentation when it is no longer needed. AERO also allows
larger packets through even if they are larger than the maximum size the
egress is capable of reassembling. There is no reason the egress' maximum
reassembly unit needs to be as large as the largest packet that can traverse
the tunnel in one piece.

Thanks - Fred

> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, April 02, 2015 8:06 AM
> To: Templin, Fred L; Black, David; [email-masked]; [email-masked]
> Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration
> 
> 
>