Subject: RFC4821 recommendation (RE: <draft-hinden-6man-rfc1981bis-00.txt>)

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Nov 2015 21:05:57 +0000

Hi, I recommend the following text regarding RFC4821 in RFC1981(bis):

  "Hosts that send packets larger than 1280 bytes to Internet destinations
   SHOULD use RFC4821 to overcome silent failures of standard Path MTU
   discovery. This is especially true for packets larger than 1500 bytes."

Thanks - Fred
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Wed, 18 Nov 2015 13:13:42 -0800

Fred,

> On Nov 18, 2015, at 1:05 PM, Templin, Fred L <[email-masked]> wrote:
> 
>   discovery. This is especially true for packets larger than 1500 bytes.”

Since we are planning to move RFC1981bis to Internet Standard, at this point I am not sure we want to be adding new requirements.  I think a reference to RFC4821 is fine along with a short summary, but I think your suggestion goes too far.

Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Nov 2015 21:18:01 +0000

Hi Bob,

> -----Original Message-----
> From: Bob Hinden [mailto:[email-masked]]
> Sent: Wednesday, November 18, 2015 1:14 PM
> To: Templin, Fred L
> Cc: Bob Hinden; IPv6 List
> Subject: Re: RFC4821 recommendation (RE: <draft-hinden-6man-rfc1981bis-00.txt>)
> 
> Fred,
> 
> Since we are planning to move RFC1981bis to Internet Standard, at this point I am not sure we want to be adding new requirements.  I
> think a reference to RFC4821 is fine along with a short summary, but I think your suggestion goes too far.

That is why I am suggesting "SHOULD", and not "MUST" (or, lowercase "should"
if you prefer). That is a recommendation; not a requirement.

Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Wed, 18 Nov 2015 14:10:48 -0800

Fred,

> On Nov 18, 2015, at 1:18 PM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Bob,
> 

Let me try again.  Current the doc does not even mention RFC4821.  You are proposing to add a requirement for implementation.  A “SHOULD” says that nodes should do it.  It’s not about the language, it about requiring something new.

Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Nov 2015 22:34:27 +0000

Hi Bob,

> Sent: Wednesday, November 18, 2015 2:11 PM
> To: Templin, Fred L
> Let me try again.  Current the doc does not even mention RFC4821.  You are proposing to add a requirement for implementation.  A
> “SHOULD” says that nodes should do it.  It’s not about the language, it about requiring something new.

We have an opportunity to guide the Internet toward eventual healing of
the broken PMTUD wound. We provide gentle guidance by saying only
SHOULD/should, which is a recommendation and not a requirement. It
stands a chance of steering the Internet toward path MTU resilience
instead of brittleness.

RFC6434 also has something to say about RFC4821. I believe what I am
suggesting is complimentary to that guidance.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Nov 2015 22:41:53 +0000

Hi Bob,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Wednesday, November 18, 2015 2:34 PM
> To: Bob Hinden
> Cc: IPv6 List
> Subject: RE: RFC4821 recommendation (RE: <draft-hinden-6man-rfc1981bis-00.txt>)
> 
> Hi Bob,
> 

Trying to understand your concern, would the following reword address
the issue:

  "It is recommended that IPv6 nodes that send packets larger than 1280 bytes
    to Internet destinations use RFC4821 to overcome silent failures of standard
   Path MTU discovery. This is especially true for packets larger than 1500 bytes.”

?

Thanks - Fred

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Wed, 18 Nov 2015 14:50:28 -0800

Fred,

>   Path MTU discovery. This is especially true for packets larger than 1500 bytes.”

Yes, something like that.  I will work on some text in the next day or two.

Note, I am very open to a new draft that compares the two approaches, says it’s important to not drop ICMPv6 Packet Too Big, contrasts the difference between RFC1981 and RFC4821, etc.  To some degree this has been done before, and might be better as a BCP in V6OPS.

Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Nov 2015 23:05:54 +0000

Hi Bob,

> Sent: Wednesday, November 18, 2015 2:50 PM
> To: Templin, Fred L

Thanks - I will look forward to reviewing the text.

> Note, I am very open to a new draft that compares the two approaches, says it’s important to not drop ICMPv6 Packet Too Big,
> contrasts the difference between RFC1981 and RFC4821, etc.  To some degree this has been done before, and might be better as a
> BCP in V6OPS.

I am not sure a comparison draft is needed if guidance like what I 
recommended is folded into RFC1981(bis). In my investigations, I
have come to the conclusion that standard path MTU discovery is
the best solution in environments where it can be relied on, such
as within well-managed administrative domains. That is why I said
that RFC4821 is recommended for *Internet* destinations, since
there is no guarantee that authentic RFC1981-required ICMP PTBs
originating in the Internet will make it back to the original source.

In short, I think 1-2 sentences in RFC1918(bis) will be all that is
necessary if we get it right.

Thanks - Fred