Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

From: Ronald Bonica <[email-masked]>
Date: Tue, 31 Mar 2015 17:17:58 +0000

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.

> 
> ?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.

                                                                             Ron

> 
> Thanks ? Fred
> [email-masked]
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Mar 2015 17:29:30 +0000

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,
> >

Behavior that is broken is still broken regardless of whether it is alternative
or default.

> 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

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 31 Mar 2015 18:37:40 +0000

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.

                                                                                          Ron

> 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,
> 
> > Cc: Zuniga, Juan Carlos; Templin, Fred L;
> > [email-masked]; [email-masked]
> > > 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:
> > >
> > > 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]
> 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,

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Mar 2015 19:01:03 +0000

Hi Ron,

> Sent: Tuesday, March 31, 2015 11:38 AM
> To: Templin, Fred L; [email-masked]; [email-masked]
> Cc: Zuniga, Juan Carlos; [email-masked]; [email-masked]
> 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

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 31 Mar 2015 20:20:35 +0000

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

> Sent: Tuesday, March 31, 2015 3:01 PM
> > 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.
> 
> 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
> > > Cc: Zuniga, Juan Carlos; [email-masked];
> > > intarea- [email-masked]
> > > > > 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:
> > > > >
> > > > 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,
> > > > Absolutely correct. The procedures described in Section 5 or RFC
> > > > 246 are
> > > normative.
> > > >

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Mar 2015 20:37:48 +0000

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

> Sent: Tuesday, March 31, 2015 1:21 PM
> 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
> > > [email-masked]

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 31 Mar 2015 22:11:43 +0000

Fred,

It appears that we disagree and have taken to repeating ourselves. 

So, why don't we solicit opinions from the rest of the WG and defer to their will.
 
                                                        Ron

> Sent: Tuesday, March 31, 2015 4:38 PM
> 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
> > 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?
> >
> > > > Cc: Zuniga, Juan Carlos;
> > > > 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
> > > 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
> > > As such, sustained dropping of packets less than 1280 is a no-no,
> > > and cannot be specified in a document like this.
> > >
> > > Thanks - Fred
> > > > > Cc: Zuniga, Juan Carlos;
> > > > > [email-masked];
> > > > > intarea- [email-masked]
> > > > > > >    o  send an ICMPv6 Packet Too Big (PTB) [RFC4443] message
> > > > > > > to the
> > > IPv6
> > > > > > > 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:
> > > > > > >
> > > > > > > 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
> > > > > 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,
> > > > > > I don't how this impacts the WG's LC decision regarding the
> > > > > > current
> > > draft.
> > > > >

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Mar 2015 22:39:14 +0000

Hi Ron,

> Sent: Tuesday, March 31, 2015 3:12 PM

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:

      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