Subject: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01

From: [email-masked]
Date: Wed, 3 Feb 2016 21:25:50 +0100

This message starts a two week 6MAN call on adopting:

Name:	draft-hinden-6man-rfc1981bis-01
Title:	Path MTU Discovery for IP version 6
Document date:	2015-12-01
Pages:	16
URL:         https://datatracker.ietf.org/doc/draft-hinden-6man-rfc1981bis/
Htmlized:  https://tools.ietf.org/html/draft-hinden-6man-rfc1981bis-01
Diff:          https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc1981bis-01.txt

as a working group item. Substantive comments and statements of support
for adopting this document should be directed to the mailing
list. Editorial suggestions can be sent to the authors.

This document is part of the working group’s ongoing work on advancing the
 core IPv6 standards to Internet Standard.

This adoption call will end on February 17th, 2016.

Regards,

Bob Hinden & Ole Trøan

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 3 Feb 2016 20:54:15 +0000

Hi Ole,

One question on the authorship - I can say with some certainty that Jack McCann
and Jeff Mogul are no longer with Digital Equipment Corporation. Would they  be
actively involved in this work if it is accepted as a working group item?

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, February 03, 2016 12:26 PM
> To: 6man WG
> Cc: [email-masked]
> Subject: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01
>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 3 Feb 2016 13:32:43 -0800

Fred,

> On Feb 3, 2016, at 12:54 PM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Ole,
> 

I have emailed Jack and he is happy keeping his Digital Equipment Corporation affiliation on the draft as that is where he is when he did the work (and not including an email address).  I am still waiting to hear from Jeff Mogul.

I was planning to add myself as an editor because I found out the data tracker get’s can’t deal with the case of not having any current email addresses in the draft.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Feb 2016 11:13:14 +1300

Yes, we should adopt this.

Regards
   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 3 Feb 2016 22:17:52 +0000

Thanks Bob,

Have you given any further thought to my proposal from back in December?

https://mailarchive.ietf.org/arch/msg/ipv6/sH6K7F4cga5sX_T3hgoZzdjzSSA

Thanks - Fred
[email-masked]

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Wednesday, February 03, 2016 1:33 PM
> To: Templin, Fred L
> Cc: Bob Hinden; Ole Trøan; IPv6 List
> Subject: Re: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01
> 
> Fred,
> 
> I have emailed Jack and he is happy keeping his Digital Equipment Corporation affiliation on the draft as that is where he is when he
> did the work (and not including an email address).  I am still waiting to hear from Jeff Mogul.
>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 3 Feb 2016 14:20:05 -0800

Fred,

> On Feb 3, 2016, at 2:17 PM, Templin, Fred L <[email-masked]> wrote:
> 
> Thanks Bob,
> 

I am still not sure it is necessary (and prefer to keep this update very simple), but would like to hear more from the w.g.

Thanks,
Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 3 Feb 2016 22:46:21 +0000

Hi Bob,

> Sent: Wednesday, February 03, 2016 2:20 PM
> To: Templin, Fred L

Yes, I agree that we should hear from the working group. I would like to
note however that the PMTUD issue has been under investigation for
decades and IMHO we now have an opportunity to put it to rest in just
two sentences added to this document. So, I think it would be worth it.

Thanks - Fred
[email-masked]

> >> I was planning to add myself as an editor because I found out the data tracker get’s can’t deal with the case of not having any
> current
> >> email addresses in the draft.
> >>
> >> Bob
> >>
> >>
> >>
> >>>
> >>> Thanks - Fred
> >>>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 08:32:28 -0300

> This adoption call will end on February 17th, 2016.

I support adoption of this document as a wg item.

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

---

From: Tim Chown <[email-masked]>
Date: Thu, 4 Feb 2016 12:40:44 +0000

> On 3 Feb 2016, at 20:25, [email-masked] wrote:
> 

I support adoption.

Tim

---

From: Timothy Winters <[email-masked]>
Date: Thu, 4 Feb 2016 08:16:16 -0500

I support adoption.

~Tim

On Thu, Feb 4, 2016 at 7:40 AM, Tim Chown <[email-masked]> wrote:

> > URL:
> https://datatracker.ietf.org/doc/draft-hinden-6man-rfc1981bis/
> > Diff:
> https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc1981bis-01.txt
> >
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 

Timothy Winters
UNH-IOL Senior Executive, Software and IP Networking
*Please note we've moved!*
21 Madbury Rd, Suite 100, Durham, NH 03824
603-421-4987

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 4 Feb 2016 14:27:24 +0000

>  core IPv6 standards to Internet Standard.

I have read the draft and I support its adoption as a 6man wg item.

Thanks
Suresh

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 4 Feb 2016 16:44:33 +0000

> On Feb 3, 2016, at 12:25 PM, [email-masked] wrote:
> 

I am in favor of adoption.

I have read through the diffs against RFC 1981 and the thread. I agree with the removal of the paragraph regarding reducing the MTU below a certain bound, and laud the mention of RFC 4821. I tend to think that, in a world that has issues with ICMP, RFC 4821 is an excellent suggestion. I do have one quibble with the wording, which seems to suggest that the host has to make a choice - it first, perhaps, tries traditional PMTU, and then "in the absence of ICMP messages" (the session is not making progress but it is getting no ICMP messages, perhaps?) does something different. I would rather simply say that RFC 4821 suggests an approach for use in environments in which administrative policy or other factors prevents the delivery of ICMP to the host. Perhaps:

OLD:
   An extension to Path MTU Discovery defined in this document can be
   found in [RFC4821].  It defines a method for Packetization Layer Path
   MTU Discovery (PLPMTUD).  In the absence of ICMP messages, the proper
   MTU is determined by starting with small packets and probing with
   successively larger packets.  The bulk of the algorithm is
   implemented above IP, in the transport layer (e.g., TCP) or other
   "Packetization Protocol" that is responsible for determining packet
   boundaries.
NEW:
   An extension to Path MTU Discovery defined in this document can be
   found in [RFC4821].  It defines a method for Packetization Layer Path
   MTU Discovery (PLPMTUD) designed for use in environments in which
   delivery of ICMP messages to a host are not assured.  In this algorithm,
   the proper
   MTU is determined by starting with small packets and probing with
   successively larger packets.  The bulk of the algorithm is
   implemented above IP, in the transport layer (e.g., TCP) or other
   "Packetization Protocol" that is responsible for determining packet
   boundaries.

Most of the diffs seem to have to do with the bibliography or details of the definitions. I'm not sure what the changes in definitions actually added, but saw nothing pernicious in that.

Regarding the point Fred Templin has raised (a stronger recommendation for RFC 4821), I worry just a bit about the level of experience we have with it. Like Fred, I really like the concept. I know it is implemented in Linux, but its use by an application in optional, and AFAIK no applications actually use it. The authors might have more to say, but I don't think we're ready for a recommendation.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 4 Feb 2016 08:57:31 -0800

Fred,

> On Feb 4, 2016, at 8:44 AM, Fred Baker (fred) <[email-masked]> wrote:
> 
> 

The “OLD” text above was taken almost exactly from the Introduction from RFC4821.  I think you “NEW” text is fine and unless some objects I will included this in the next version of the draft.

> Regarding the point Fred Templin has raised (a stronger recommendation for RFC 4821), I worry just a bit about the level of experience we have with it. Like Fred, I really like the concept. I know…

I agree, especially for going to Internet Standard.

Thanks,
Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Feb 2016 17:53:43 +0000

Hi Fred B.,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
> Sent: Thursday, February 04, 2016 8:45 AM
> To: Bob Hinden
> Cc: 6man WG
> I have read through the diffs against RFC 1981 and the thread. I agree with the removal of the paragraph regarding reducing the MTU
> below a certain bound, and laud the mention of RFC 4821. I tend to think that, in a world that has issues with ICMP, RFC 4821 is an
> excellent suggestion. I do have one quibble with the wording, which seems to suggest that the host has to make a choice - it first,
> perhaps, tries traditional PMTU, and then "in the absence of ICMP messages" (the session is not making progress but it is getting no
> ICMP messages, perhaps?) does something different. I would rather simply say that RFC 4821 suggests an approach for use in
> environments in which administrative policy or other factors prevents the delivery of ICMP to the host. Perhaps:
> 
> OLD:

That is essentially what I was saying when I said that:

    "It is recommended that IPv6 nodes that send packets larger than 1280 bytes
    to Internet destinations use PLPMTUD to overcome silent failures of standard
    Path MTU discovery."

where "Internet destinations" refers to destinations outside of the source
node's administrative domain since standard PMTUD presumably works
within a well-managed administrative domain.

We need to also make it clear that standard PMTUD per ICMP messaging
is the preferred option when it can be trusted - otherwise, we should be
deprecating RFC1981 instead of making it a standard.

Thanks - Fred

> Most of the diffs seem to have to do with the bibliography or details of the definitions. I'm not sure what the changes in definitions
> actually added, but saw nothing pernicious in that.
> 
> Regarding the point Fred Templin has raised (a stronger recommendation for RFC 4821), I worry just a bit about the level of
> experience we have with it. Like Fred, I really like the concept. I know it is implemented in Linux, but its use by an application in
> optional, and AFAIK no applications actually use it. The authors might have more to say, but I don't think we're ready for a
> recommendation.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Feb 2016 18:37:13 +0000

Hi Fred B.,

One other thing that both your and my text fails to capture is that there
are two failure modes to consider:

  1) loss of necessary ICMP PTBs
  2) receipt of bogus ICMP PTBs

You and I have talked about case 1), but the text needs to be modified
to address case 2). My text could be modified by simply deleting the
word "silent" as follows:

  "It is recommended that IPv6 nodes that send packets larger than 1280 bytes
   to Internet destinations use PLPMTUD to overcome failures of standard
   Path MTU discovery."

Your text could be modified by simply adding the word "accurate" as follows:

  "It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD)
    designed for use in environments in which delivery of accurate ICMP messages
    to a host are not assured."

Thanks - Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Thursday, February 04, 2016 9:54 AM
> To: Fred Baker (fred); Bob Hinden
> Cc: 6man WG
> Subject: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01
> 
> Hi Fred B.,
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 4 Feb 2016 18:49:48 +0000

> On Feb 4, 2016, at 10:37 AM, Templin, Fred L <[email-masked]> wrote:
> 

So you added the word "accurate". Anything else?

My question would be what makes an ICMP "accurate", and how the host might or might not determine accuracy. As near as I can tell, RFC 1981 says that if a host receives an ICMP Packet Too Big, it should make the packet smaller. If the ICMP has been spoofed, unless the spoofer has done something really egregious, I don't know how the receiving host would know that.

Given that, I don't think the wording change helps.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Feb 2016 18:58:38 +0000

Hi Fred,

> From: Fred Baker (fred) [mailto:[email-masked]]
> Sent: Thursday, February 04, 2016 10:50 AM
> To: Templin, Fred L
> Cc: Bob Hinden; 6man WG
> My question would be what makes an ICMP "accurate", and how the host might or might not determine accuracy. As near as I can tell,
> RFC 1981 says that if a host receives an ICMP Packet Too Big, it should make the packet smaller. If the ICMP has been spoofed, unless
> the spoofer has done something really egregious, I don't know how the receiving host would know that.

ICMP spoofing is exactly the point. But, it is not up to the host to determine
whether an ICMP is accurate - it is up to the host to determine whether it is
in an environment in which delivery of accurate ICMP messages is not assured.

> Given that, I don't think the wording change helps.

Without "accurate", the text does not address failure mode 2).

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Feb 2016 19:02:39 +0000

I will make one other change recommendation:

OLD:
It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD)
designed for use in environments in which delivery of accurate ICMP messages
to a host are not assured.

NEW:
It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD)
designed for use over paths for which delivery of accurate ICMP messages
to a host are not assured.

Fred

> Sent: Thursday, February 04, 2016 10:59 AM
> To: Fred Baker (fred)
> Cc: 6man WG; Bob Hinden

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 16:02:58 -0300

On 02/04/2016 01:44 PM, Fred Baker (fred) wrote:
> 
> Regarding the point Fred Templin has raised (a stronger
> recommendation for RFC 4821), I worry just a bit about the level of
> experience we have with it. Like Fred, I really like the concept. I
> know it is implemented in Linux, but its use by an application in
> optional, and AFAIK no applications actually use it. The authors
> might have more to say, but I don't think we're ready for a
> recommendation.

My recollection of discussing this with Linux devs at the time was that
they'd use RFC4821 mostly for blackhole detection than as a complete
ICMP-less PMTUD. The reason? -- convergence time.

Thanks,

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Feb 2016 19:07:14 +0000

Hi Fernando,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Thursday, February 04, 2016 11:03 AM

Right, that is why RFC1981(bis) PMTUD should be preferred for use over
paths for which delivery of accurate ICMP messages to a host *is* assured.

Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Thu, 4 Feb 2016 11:16:12 -0800

Fred,

> On Feb 4, 2016, at 10:58 AM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Fred,
> 

How is a host supposed to know if it is an “accurate ICMP message”?

This is starting to read to me like creating a new specification, not advancing the one we have now.

Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Feb 2016 19:36:53 +0000

Hi Bob,

> Sent: Thursday, February 04, 2016 11:16 AM
> To: Templin, Fred L
> Cc: Bob Hinden; Fred Baker (fred); IPv6 List

Repeating what I said with a necessary correction:

  "But, it is not up to the host to determine
    whether an ICMP is accurate - it is up to the host to determine whether it is
    using a path for which delivery of accurate ICMP message is not assured."

> This is starting to read to me like creating a new specification, not advancing the one we have now.

Not at all. You were only too happy to accept Fred Baker's suggestion; I
have simply modified the aspects of his suggestion that were lacking
and/or inaccurate.

Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Thu, 4 Feb 2016 11:50:30 -0800

Fred,

> On Feb 4, 2016, at 11:36 AM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Bob,
> 
>    using a path for which delivery of accurate ICMP message is not assured.”

Same question.  How is the host supposed determine "it is using a path for which delivery of accurate ICMP message is not assured”?  Don’t you think that if are going to ask the host to validate the ICMP PTB messages, we need to provide some algorithm or approach to do that.

> have simply modified the aspects of his suggestion that were lacking

Fred Baker’s change was to replace"

  (PLPMTUD).  In the absence of ICMP messages, the proper

with:

  (PLPMTUD) designed for use in environments in which
  delivery of ICMP messages to a host are not assured.  In this algorithm,
  the proper

Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Feb 2016 20:00:37 +0000

Hi Bob,

> Sent: Thursday, February 04, 2016 11:51 AM
> To: Templin, Fred L
> >>>> My question would be what makes an ICMP "accurate", and how the host might or might not determine accuracy. As near as I
> can
> >> tell,
> Same question.  How is the host supposed determine "it is using a path for which delivery of accurate ICMP message is not assured”?
> Don’t you think that if are going to ask the host to validate the ICMP PTB messages, we need to provide some algorithm or approach
> to do that.

You keep missing the point; the host is NOT supposed to validate the ICMP PTB
message; it is simply advised to determine whether it is using a path for which
delivery of accurate ICMPP messages is not assured.

>   delivery of ICMP messages to a host are not assured.  In this algorithm,

"Environments" is inaccurate - the correct word is "path". A host could be in an
environment where ICMP-based PMTUD works perfectly for path A and fails
miserable for path B. That is why it is called "Path" MTU discovery, and not
"Environment" MTU discovery.

Thanks - Fred

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 4 Feb 2016 20:04:58 +0000

> in an environment in which delivery of accurate ICMP messages is not assured.

Well, again, what is the test? How do I *know* that I am in an environment designed by a clueless operator? I can imagine that MAYBE a host sends an MSS-sized message and gets no Ack, but sends a smaller message and gets an ack for that. If we were to actually specify that test, I'll bet we would back ourselves into RFC 4821, and the test would become that RFC 4821 came up with a smaller number than RFC 1981 did.

I'd really like to not require someone to go test something and pick a PMTU algorithm based on the test. RFC 4821 has an attribute, which is that it is designed to be independent of ICMP and otherwise achieve some approximation to RFC 1981. In the text I suggested that is as much as I felt was appropriate to say.

---

From: [email-masked]
Date: Fri, 5 Feb 2016 09:04:11 +0100

Fred,

> to a host are not assured.

I would posit that there are no such paths. "accurate" ICMP can never be guaranteed.

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Fri, 5 Feb 2016 19:08:56 +1100

I support adoption.

---

From: [email-masked]
Date: Fri, 5 Feb 2016 09:16:41 +0100

Fred,

> actively involved in this work if it is accepted as a working group item?

I don't expect them to be.
For the documents we're advancing to Internet Standard, and therefore only do very minor tweaks to, I think it makes most sense to keep the original authors. Unless they object.

Best regards,
Ole

---

From: Tim Chown <[email-masked]>
Date: Fri, 5 Feb 2016 11:39:35 +0000

> On 5 Feb 2016, at 08:04, [email-masked] wrote:
> 
> Fred,
> 
>> 

Indeed.  And perhaps for ‘accurate’ read ‘reliable and/or trustworthy’.

Tim

---

From: Brian Haberman <[email-masked]>
Date: Fri, 5 Feb 2016 08:03:05 -0500

All,

On 2/5/16 3:16 AM, [email-masked] wrote:
> Fred,
> 
>> One question on the authorship - I can say with some certainty that
>> Jack McCann and Jeff Mogul are no longer with Digital Equipment
>> Corporation. Would they  be actively involved in this work if it is
>> accepted as a working group item?
> 
> I don't expect them to be. For the documents we're advancing to
> Internet Standard, and therefore only do very minor tweaks to, I
> think it makes most sense to keep the original authors. Unless they
> object.

Um, no. The original authors stay on the draft because they are the ones
responsible for most of the text within the document. Accurate
representation of authorship is critical for many reasons (e.g., IPR).

Regards,
Brian

> 
> Best regards, Ole
> 
>>> -----Original Message----- From: ipv6
>>> [mailto:[email-masked]] On Behalf Of [email-masked] 
>>> Sent: Wednesday, February 03, 2016 12:26 PM To: 6man WG Cc:
>>> [email-masked] Subject: 6MAN: Adoption call on
>>> draft-hinden-6man-rfc1981bis-01
>>> 
>>> Name:	draft-hinden-6man-rfc1981bis-01 Title:	Path MTU Discovery
>>> for IP version 6 Document date:	2015-12-01 Pages:	16 URL:
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-hinden-6man-rfc1981bis-01 Diff:
>>> This document is part of the working group’s ongoing work on
>>> advancing the core IPv6 standards to Internet Standard.
>>> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Tim Chown <[email-masked]>
Date: Fri, 5 Feb 2016 13:18:30 +0000

> On 5 Feb 2016, at 13:03, Brian Haberman <[email-masked]> wrote:
> 
> All,
> 

RFC 4861 is a good example, where Hesham was added to the original 
authors as the collator of edits. There’s also an Appendix listing the changes
in RFC 4861, which we should probably have here too.

Tim

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Feb 2016 15:55:13 +0000

Hi Ole,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, February 05, 2016 12:04 AM
> To: Templin, Fred L
> Cc: Fred Baker (fred); Bob Hinden; 6man WG

Forgetting the word "accurate" for the moment, it is reasonable to
expect that paths that begin and end within the same well-managed
administrative domain can be counted on to deliver the necessary
ICMPs and to not deliver bogus ICMPs. Paths that lead to Internet
destinations on the other hand cannot.

If we do not believe that there are paths for which traditional PMTUD
can still be used safely, then we should be working to deprecate
RFC1981 instead of making it a standard.

Thanks - Fred

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 5 Feb 2016 16:52:03 +0000

> RFC1981 instead of making it a standard.

As soon as I say "there is no such attack", one will materialize, so I won't assert that.  However, I am not aware of attacks in which someone creates ICMP PTBs and sends them to someone else in order to reduce their windows unnecessarily. I certainly *am* aware of firewalls and other equipment being programmed to either not originate or not allow ICMP messages, believing ICMP to be an attack vector.

As far as I know, RFC 4821 is a response to the latter issue.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Feb 2016 14:58:59 -0300

On 02/05/2016 01:52 PM, Fred Baker (fred) wrote:
>> If we do not believe that there are paths for which traditional
>> PMTUD can still be used safely, then we should be working to
>> deprecate RFC1981 instead of making it a standard.
> 
> As soon as I say "there is no such attack", one will materialize, so
> I won't assert that.  However, I am not aware of attacks in which
> someone creates ICMP PTBs and sends them to someone else in order to
> reduce their windows unnecessarily. 

Please see: <https://tools.ietf.org/html/rfc5927> (Section 7, specifically).

FWIW, in the IPv4 world, some boxes were known to crash when they
received an ICMP PTB claiming an MTU smaller than the IPv4 MTU (68 bytes).

> I certainly *am* aware of
> firewalls and other equipment being programmed to either not
> originate or not allow ICMP messages, believing ICMP to be an attack
> vector.
> 

Agreed.

FWIW, 4821 can operate completely icmp-less, or it can be employed
simply for PMTUD-balckhole detection (.e., when you detect that
connections are getting stuck because ICMP messages are being dropped).

Thanks,

---

From: [email-masked]
Date: Fri, 5 Feb 2016 19:11:21 +0100

Brian,

> representation of authorship is critical for many reasons (e.g., IPR).

my view is that it is the working group that is responsible for the document (and at a larger level the IETF).
and that we have the authors listed on the first page as a way to recognise them as the main contributors.

perhaps it is time to remove author names from our documents then.
(as something the IETF should look at, not for these sets of documents obviously).

Best regards,
Ole

---

From: [email-masked]
Date: Fri, 5 Feb 2016 19:23:02 +0100

Fred,

[...]

> destinations on the other hand cannot.

how is the host supposed to determine that?
the worst thing that can happen with a bogus PMTUD message is that the host sets its MTU to 1280.
that might be bad on a 9K end to end link perhaps.

> RFC1981 instead of making it a standard.

I'd rather we looked at getting 4821 deployment and looked at other mechanisms that would work better than 1981.

you can make an argument that ICMP messages cannot be "used safely" in general.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Feb 2016 15:27:22 -0300

> that might be bad on a 9K end to end link perhaps.

Agreed. The situation is way better in the IPv6-world than in its IPv4
counterpart. In the worst case scenario, you can downgrade an IPv6 to a
1280-byte MTU. But in IPv4 you can downgrade a flow to a 68-byte MTU.

Thanks,

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Feb 2016 18:40:10 +0000

Hi Ole,

> Sent: Friday, February 05, 2016 10:23 AM
> To: Templin, Fred L

In some well managed networks, the only way to reach correspondent
nodes in the Internet is to go through a proxy that breaks the TCP
connection into an "inside" segment and an "outside" segment. And,
within any "inside" path including those that lead to a proxy, RFC1981
can be applied w/o also applying RFC4821.

> that might be bad on a 9K end to end link perhaps.

Yes, it still works but at the minimum IPv6 MTU. We want an Internet
that can robustly adapt to paths with larger MTUs without suffering
performance-degrading attacks.

> I'd rather we looked at getting 4821 deployment and looked at other mechanisms that would work better than 1981.

What do you mean by better than RFC1981? For paths over which it can be
counted on to work, RFC1981 is better than RFC4821.
 
> you can make an argument that ICMP messages cannot be "used safely" in general.

But, it depends - paths over which RFC1981 can be counted on to work (e.g.,
well-managed administrative domains) would be considered a use case where
ICMP messages can be used safely.

Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Fri, 5 Feb 2016 10:50:58 -0800

Ole,

> On Feb 5, 2016, at 10:11 AM, [email-masked] wrote:
> 
> Brian,
> 

I think this recognition is important.  The are the authors of the document that represents the working group’s consensus.

> (as something the IETF should look at, not for these sets of documents obviously).

I don’t support this notion.

Bob

---

From: Brian Haberman <[email-masked]>
Date: Fri, 5 Feb 2016 18:03:01 -0500

Hi Ole,

> and that we have the authors listed on the first page as a way to recognise them as the main contributors.

The WG is responsible for the document, but things like our IPR rules
are indexed by the document authors.

> (as something the IETF should look at, not for these sets of documents obviously).

That has been raised several times since I have been on the IESG. The
push back on that proposal naturally deals with IPR issues, publication
credit, and RFC Editor interactions.

Regards,
Brian

---

From: Tore Anderson <[email-masked]>
Date: Sat, 6 Feb 2016 13:48:31 +0100

* [email-masked]

I support adoption.

I see one issue that I would like to remind the WG about:

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

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

The lines prefixed with "-" have been removed in -01. In my opinion,
this leaves the text in an ambiguous state. What is a node conforming
to -01 expected to do, when receiving a PTB reporting a next-hop MTU
lower than 1280? I see two distinct options:

a) Reduce its PMTU estimate to exactly 1280.
b) Ignore the "invalid" PTB (retaining its previous PMTU estimate).

I think it would be preferable to replace the removed paragraph with a
clarification as to which behaviour is the correct and expected one. I
do not know which one that would be, though.

Tore

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 8 Feb 2016 08:37:37 +1300

On 07/02/2016 01:48, Tore Anderson wrote:
> The lines prefixed with "-" have been removed in -01. 

Isn't this the same change that has been made to 2460bis anyway?

>       01)  Removed paragraph in Section 5 that required including a
>            fragment header to outgoing packets if a ICMP Packet Too Big
>            message reporting a Next-Hop MTU less than 1280.  This is
>            based on the update in draft-ietf-6man-deprecate-atomfrag-
>            generation-03.

It seems to me that RFC 6145 and draft-bao-v6ops-rfc6145bis (SIIT) still
rely on this behaviour, whatever draft-ietf-6man-deprecate-atomfrag-generation
says. Or I am confused.

   Brian

> In my opinion,

---

From: Tore Anderson <[email-masked]>
Date: Mon, 8 Feb 2016 07:18:46 +0100

Hello Brian,

* Brian E Carpenter <[email-masked]>

> Isn't this the same change that has been made to 2460bis anyway?

Similar text was removed from 2460bis, that is true.

That said, 2460bis contains no prohibition against a node reducing its
PMTU below 1280; this restriction only found in 1981(bis) immediately
preceding the deleted paragraph.

2460bis does not really say anything about how PMTUD should be
implemented (it just refers to 1981), so I think it makes sense to
contain this information in 1981bis.

> rely on this behaviour, whatever
> draft-ietf-6man-deprecate-atomfrag-generation says. Or I am confused.

A translator conforming to 6145bis will never emit translated ICMPv6 PTBs
indicating a PMTU < 1280. From section 4.2:

               The MTU field MUST be adjusted for the difference
               between the IPv4 and IPv6 header sizes, but MUST NOT be
               set to a value smaller than the minimum IPv6 MTU (1280
               bytes).

To the best of my knowledge, an ICMPv6 PTB with MTU<1280 can only
legitimately occur in the wild as a result from translation from an
IPv4 FN by a 6145-not-bis translator implementing the "first approach"
in section 6. (The "second approach" is basically the same as what
6145bis mandates, for what it's worth.)

Actually, this made me realise that my option a) is probably the best
choice, i.e., that an IPv6 node receiving an PTB with MTU<1280 should
interpret it as if it had MTU=1280. Doing so would increase the
likelihood of successful communication in the case where the IPv4->IPv6
translator conforms to 6145-1st-approach while the IPv6->IPv4
translator conforms to 6145bis (or 6145-2nd-approach) one.

Tore

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Feb 2016 07:52:42 +1300

OK, got it, except for a backwards compatibility issue with some 6145-not-bis boxes.
But we can't expect translation to be perfect anyway.

Thanks
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 8 Feb 2016 19:23:59 -0300

> do not know which one that would be, though.

I'd be in favor of going with the suggested option "a" above.

Thanks!

Cheers,

---

From: Bob Hinden <[email-masked]>
Date: Tue, 9 Feb 2016 15:12:21 +0200

Tore,

> On Feb 6, 2016, at 2:48 PM, Tore Anderson <[email-masked]> wrote:
> 
> * [email-masked]
> 

My take is that by removing this text from rfc2460bis we are turning a ICMP PTB with MTU < 1280 into an error condition.  All IPv6 links are required to be 1280 or larger, so there isn’t any legitimate reason to reduce the MTU to less than 1280.   Based on this, I think rfc1981bis can say they should be ignored.

Also, my understanding is that rfc6145bis no longer generates ICMP PTB with MTU < 1280.  This makes rfc2460bis, rfc1981bis, and rfc6145bis all consistent.

Bob

---

From: Tore Anderson <[email-masked]>
Date: Tue, 9 Feb 2016 14:38:23 +0100

Hi Bob,

> My take is that by removing this text from rfc2460bis we are turning
> a ICMP PTB with MTU < 1280 into an error condition.  All IPv6 links
> are required to be 1280 or larger, so there isn’t any legitimate
> reason to reduce the MTU to less than 1280.

The exception would be packets coming through a 6145-not-bis
translator, as I explained in my reply to Brian. But I doubt that many
of these will be seen in the wild anyway, so I think it is OK to just
ignore that temporary corner case and focus on the desired end state
(with three consistent bis documents).

> Based on this, I think rfc1981bis can say they should be ignored.

I'd be fine with that (as long as it is clearly and unequivocally
stated).

> Also, my understanding is that rfc6145bis no longer generates ICMP
> PTB with MTU < 1280.  This makes rfc2460bis, rfc1981bis, and
> rfc6145bis all consistent.

I concur.

Tore

---

From: Bob Hinden <[email-masked]>
Date: Tue, 9 Feb 2016 16:49:48 +0200

Tore,

> On Feb 9, 2016, at 3:38 PM, Tore Anderson <[email-masked]> wrote:
> 
> Hi Bob,
> 

Also, a translator that relies on ICMP PTB messages arriving all of the time, is going to have other problems.

>> rfc6145bis all consistent.

I will work on some text in the next version of the draft.

Thanks,
Bob