Subject: <draft-hinden-6man-rfc1981bis-00.txt>

From: Bob Hinden <[email-masked]>
Date: Sat, 7 Nov 2015 17:12:11 +0900

Hi,

Based on the discussion at the 6man session in Yokohama I created a bis version of RFC1981 " Path MTU Discovery for IP version 6”.  The links to this draft are at the end of this email.

The purpose of this version is to establish a baseline from RF1981.  The only intended changes are formatting (XML is slightly different from .nroff), differences between an RFC and Internet Draft, fixing a few ID Nits, updating references, and updates to the authors information.  There should not be any content changes to the specification.

A diff from RFC1981 can be found at:

https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc1981bis-00.txt

The plan is to do a small series of new versions, each addressing a single update to allow the changes to be tracked very carefully.  Please review this draft to verify there are no content changes.

This is part of the project to move the core IPv6 specifications to Internet Standard.

Thanks,
Bob

> I-D Action: draft-hinden-6man-rfc1981bis-00.txt
> [email-masked] Sat, 07 November 2015 07:54 UTCShow header
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Path MTU Discovery for IP version 6
>         Authors         : Jack McCann
>                           Jeffrey Mogul
> 	Filename        : draft-hinden-6man-rfc1981bis-00.txt
> 	Pages           : 15
> 	Date            : 2015-11-06
> 
> Abstract:
>    This document describes Path MTU Discovery for IP version 6.  It is
>    largely derived from RFC 1191, which describes Path MTU Discovery for
>    IP version 4.  It obsoletes RFC1981.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hinden-6man-rfc1981bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-hinden-6man-rfc1981bis-00
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Nov 2015 16:35:35 +0000

Hi Bob,

What about adding an informative reference to RFC4821?

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Saturday, November 07, 2015 12:12 AM
> To: IPv6 List
> Cc: Bob Hinden
> Subject: <draft-hinden-6man-rfc1981bis-00.txt>
> 
> Hi,
> 
> Based on the discussion at the 6man session in Yokohama I created a bis version of RFC1981 " Path MTU Discovery for IP version 6”.
> The links to this draft are at the end of this email.
> 
> The purpose of this version is to establish a baseline from RF1981.  The only intended changes are formatting (XML is slightly different
> from .nroff), differences between an RFC and Internet Draft, fixing a few ID Nits, updating references, and updates to the authors
> information.  There should not be any content changes to the specification.
> 
> The plan is to do a small series of new versions, each addressing a single update to allow the changes to be tracked very carefully.
> Please review this draft to verify there are no content changes.
>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 10 Nov 2015 17:21:02 -0200

Fred,

> On Nov 10, 2015, at 2:35 PM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Bob,
> 
> What about adding an informative reference to RFC482

I think Christian Heuitema also made that suggestion in Yokohama.  I was planning to include that in the next version.  The -00 version did not include any changes.

Bob

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 17 Nov 2015 07:49:41 +0000

> On Nov 7, 2015, at 9:12 PM, Bob Hinden <[email-masked]> wrote:
> 

Do you have a list of the changes you think need to be made?

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 17 Nov 2015 07:49:56 +0000

---

From: Tore Anderson <[email-masked]>
Date: Tue, 17 Nov 2015 09:39:48 +0100

* Bob Hinden <[email-masked]>

> Based on the discussion at the 6man session in Yokohama I created a
> bis version of RFC1981 " Path MTU Discovery for IP version 6”.  The
> links to this draft are at the end of this email.
> 
> The purpose of this version is to establish a baseline from RF1981.
> The only intended changes are formatting (XML is slightly different
> from .nroff), differences between an RFC and Internet Draft, fixing a
> few ID Nits, updating references, and updates to the authors
> The plan is to do a small series of new versions, each addressing a
> single update to allow the changes to be tracked very carefully.

Not sure if this is the kind of feedback you're looking for at this
point, but one of the reference updates leaves the draft in an
inconsistent state:

      Note: A node may receive a Packet Too Big message reporting a
      next-hop MTU that is less than the IPv6 minimum link MTU.  In that
      case, the node is not required to reduce the size of subsequent
      packets sent on the path to less than the IPv6 minimun link MTU,
      but rather must include a Fragment header in those packets
      [I-D.ietf-6man-rfc2460bis].

However, the quoted text is not present in I-D.ietf-6man-rfc2460bis
(it was removed in -01). So this updated reference does not make sense.

I assume that this will be dealt with by simply removing this
paragraph in question, as was done in 2460bis. I'd like to preemptively
point out that doing so would mean that the draft will no longer
clearly specify what should happen if a node receives a PTB that
indicates a Path MTU lower than 1280 bytes. I see two possible
interpretations:

1) The PTB should be ignored as invalid, the Path MTU is not lowered
2) The Path MTU should be lowered to exactly 1280

Some new text will likely be necessary to point out which is the
correct behaviour (I'm favoring #2, for what's it worth).

Tore

---

From: Bob Hinden <[email-masked]>
Date: Tue, 17 Nov 2015 08:10:47 -0800

Fred,

> On Nov 16, 2015, at 11:49 PM, Fred Baker (fred) <[email-masked]> wrote:
> 
> 

Yes, two changes:

First, removing the Note on page 6, that starts with:

      Note: A node may receive a Packet Too Big message reporting a
      next-hop MTU that is less than the IPv6 minimum link MTU.

This was obsoleted by incorporating the update to rfc2460bis made by <draft-ietf-6man-deprecate-atomfrag-generation-03>.

Second, adding a reference to RFC4821 with some text describing the differences between the two.

Thanks,
Bob

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 17 Nov 2015 16:17:07 +0000

> On Nov 18, 2015, at 5:10 AM, Bob Hinden <[email-masked]> wrote:
> 
> Fred,
> 

That makes sense. It would be nice to recommend 4821, as it solves the problem without having to convince operators to trust ICMP enough to not drop it. However, that would probably not be something we could take to full standard.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 17 Nov 2015 08:22:29 -0800

Tore,

> On Nov 17, 2015, at 12:39 AM, Tore Anderson <[email-masked]> wrote:
> 

You are right, that should have kept a reference to rfc2460.

> paragraph in question, as was done in 2460bis.

Correct.

> I'd like to preemptively

The sentence right above the Note says:

     A node MUST NOT reduce its estimate of the Path MTU below the IPv6
     minimum link MTU.

I think this provides the right guidance in this case.

Thank,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Tue, 17 Nov 2015 08:28:16 -0800

Fred,

> That makes sense. It would be nice to recommend 4821, as it solves the problem without having to convince operators to trust ICMP enough to not drop it. However, that would probably not be somethin…

I am not so sure we should accept that operators drop ICMPv6 Packet Too Big messages.

While I am not sure it should go in rfc1981bis, it might be good to have a separate draft contrasting the two approaches and say that Packet Too Big messages must not be dropped.

Your thoughts?

Bob

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 Nov 2015 17:46:16 +0100

>While I am not sure it should go in rfc1981bis, it might be good to have 
>a separate draft contrasting the two approaches and say that Packet Too 
>Big messages must not be dropped.
>
>Your thoughts?

We can write that operators must not drop ICMPv6 packet too big on every page,
but in reality there will be some percentage of misconfigured systems. (I do
think that operators must not drop ICMPv6 packet too big)

Most of the time the only people who notice are on those on links with less
than 1500 and without MSS clamping. I don't think we want CPEs doing 
MSS clamping for IPv6.

I have seen some pretty weird bugs in this area, and until they are resolved
you basically have a broken internet connection.

So I think we should strongly suggest (as in SHOULD) that all hosts implement
some kind of PMTU backhole avoidance. Even if it is a very stupid "after a
couple of timeouts you retry with 1280".

In my experience, PMTU problems are also very hard to debug. If you can see
a remote system retrying with a smaller MTU then that is a good hint that there 
is PMTU problem. If you don't see anything, it is hard to draw a conclusion.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 17 Nov 2015 16:57:44 +0000

> On Nov 18, 2015, at 5:28 AM, Bob Hinden <[email-masked]> wrote:

You mean, like section A.2 of RFC 4890? Recommendation REC-36 of RFC 6092?

I think you need it to be in *NOG BCPs, and even there I'm not convinced that enterprise operators will heed it.

I do believe that a draft contrasting the two approaches may be useful, if only as a discussion item.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Nov 2015 14:14:01 -0300

> I do believe that a draft contrasting the two approaches may be useful, if only as a discussion item.

FWIW, they are not necessarily two different approaches.

While PLPMTUD can operate without ICMPv6 messages, in practice it is
mostly used as a PMTUD-blackhole mechanism than as a replacement of
traditional PMTUD. (reason: convergence time).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tore Anderson <[email-masked]>
Date: Tue, 17 Nov 2015 18:23:07 +0100

* Bob Hinden

> > I'd like to preemptively point out that doing so would mean that
> > the draft will no longer clearly specify what should happen if a
> > node receives a PTB that indicates a Path MTU lower than 1280
> > bytes. I see two possible interpretations:
> > 

If, upon receiving an ICMPv6 PTB with MTU=1234:

- Implementation A lowers the Path MTU from 1500 to 1280
- Implementation B leaves the Path MTU unchanged at 1500

I believe both A and B would be in full compliance with the MUST NOT in
the sentence you quote. Maybe I have overlooked something, but I see no
other language that would resolve the ambiguity as to which of the two
approaches is the correct one.

Tore

---

From: Bob Hinden <[email-masked]>
Date: Tue, 17 Nov 2015 10:54:13 -0800

Tore,

> approaches is the correct one.

Is there a correct behavior?  Some node along the path thinks the MTU of it’s next hop is less than 1280.  Neither approach will fix this.

Bob

---

From: Tore Anderson <[email-masked]>
Date: Tue, 17 Nov 2015 22:40:15 +0100

* Bob Hinden

> > I believe both A and B would be in full compliance with the MUST
> > NOT in the sentence you quote. Maybe I have overlooked something,
> > but I see no other language that would resolve the ambiguity as to
> > which of the two approaches is the correct one.
> 
> Is there a correct behavior?  Some node along the path thinks the MTU
> of it’s next hop is less than 1280.  Neither approach will fix this.

Hi,

My understanding of the original RFC2460 quote is that it implies that
A (plus the generation of atomic fragments) is the expected behaviour.
The sentence «In that case, the node is not required to reduce the size
of subsequent packets sent on the path to less than the IPv6 minimun
link MTU, [...]» is what makes me think so, the implication I perceive
being that it should reduce the PMTU to the IPv6 minimun[sic] link MTU
and stop exactly there (even though the received PTB suggested that
the PMTU should be reduced further).

When the quote is removed, this implication goes away. That said, I
readily admit to not being a native English speaker; if you believe my
reading between the lines here is in the wrong, I won't argue this
point any further.

Another thing worth mentioning, though, is that implementation A will
work better than B if the IPv6->IPv4 translator complies with either
the "second approach" described in RFC6145 (cf. section 6, bullet
2(B)(a)) or RFC6145bis (whose section 4.1 mandates RFC6145's "second
approach"): When an IPv6 packet sized 1280 or smaller is translated to
IPv4, the resulting packet will have the DF flag cleared, facilitating
further fragmentation by the IPv4 router attached to link with the
small MTU, [hopefully] resulting in the successful delivery of the IP
payload.

Implementation B is the other hand guaranteed to encounter a PMTUD
blackhole (except if it also starts generating atomic fragments, which
is mandated only by the to-be-deleted RFC2460 quote).

Finally, and generally speaking I believe that such ambiguity in the
standards is best avoided. I think 1981bis is a welcome opportunity to
clarify this particular point and remove this ambiguity, but ultimately
it's your call whether or not to do so, of course.

Tore