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

From: Bob Hinden <[email-masked]>
Date: Tue, 1 Dec 2015 16:24:04 -0800

Hi,

I published a new version of draft-hinden-6man-rfc1981bis-01.txt.   The links to this draft are at the end of this email.

The version has the changes that were discussed at the Yokohama 6MAN session.  The changes include:

  - Remove Note about a Packet Too Big message reporting a next-hop MTU
    that is less than the IPv6 minimum link MTU.  This was removed from
    [I-D.ietf-6man-rfc2460bis].

  - Include a link to RFC4821 along with a short summary of what it does.

  - Assigned references to informative and normative.

  - A few editorial changes.

A diff from the previous version can be found at:

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

With this draft, I think the w.g. should consider adopting this draft as a 6MAN w.g. document.

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

Thanks,
Bob

> I-D Action: draft-hinden-6man-rfc1981bis-01.txt
> [email-masked] Tue, 01 December 2015 22:29 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
>                           Stephen E. Deering
>                           Jeffrey Mogul
> 	Filename        : draft-hinden-6man-rfc1981bis-01.txt
> 	Pages           : 16
> 	Date            : 2015-12-01
> 
> 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-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc1981bis-01
>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 1 Dec 2015 16:25:48 -0800

Hi,

One other thing I wanted to mention regarding draft-hinden-6man-rfc1981bis-01.txt:

As part of adding a link to RFC4821, I only described what it did, it currently says:

   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.

This is based on text in the Introduction in RFC4821.

I didn’t not make any recommendations on the use of PMTUD or PLPMTUD.  A few people have said we should say more.  If you think we should add something else, please say why and propose text on the mailing list.

Thanks,
Bob

> On Dec 1, 2015, at 4:24 PM, Bob Hinden <[email-masked]> wrote:
> 
> Hi,
>

---

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

Hi Bob,

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Tuesday, December 01, 2015 4:26 PM
> To: IPv6 List
> Cc: Bob Hinden
> Subject: Re: <draft-hinden-6man-rfc1981bis-01.txt>
> 
> Hi,
> 

I am fine with this.

> I didn’t not make any recommendations on the use of PMTUD or PLPMTUD.  A few people have said we should say more.  If you think
> we should add something else, please say why and propose text on the mailing list.

To the above, I recommend adding:

  "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. This is especially true for packets larger than 1500 bytes.”

Reason:
  - "Internet destinations" are located outside of the source node's administrative
    domain and therefore any ICMP PTB messages resulting from a size restriction
    in the Internet may be lost on the reverse path. Hence the recommendation
    for PLPMTUD.

- "1500 bytes" is the predominant "Internet cell size", meaning that packets
   no larger than that size already have a very good chance of traversing the
   path from the source to the destination without being dropped due to a
   size restriction. This is not generally true for packets larger than 1500 bytes
   hence an even stronger recommendation for packets in that size range.

Thanks - Fred
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Thu, 3 Dec 2015 15:36:06 -0800

Fred,

>>   "Packetization Protocol" that is responsible for determining packet

Thanks.

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

I am not sure this is the right place to put this kind of requirements in.  Overall, I think some serious measurement needs to be done for us to understand what causes IMCP Packet too Big to be not returned.  Is it firewall/middle-box filtering, ICMP rate limiting, hosts dropping them, specific packet size, etc?  Or some combination?  We already have several RFCs saying they should be dropped and to use RFC4821 addresses the case if they are dropped.  I am not sure we understand the problem that well.

Regarding your specific suggestion, I think it would be a mistake to put in recommendations with specific packet sizes.  This is a moving target and anything we put in a document that is going to become an Internet Standard will be wrong in the future.  Perhaps some sort of BCP would be better.

>    in the Internet may be lost on the reverse path. Hence the recommendation

This is described in RFC4821.

>   hence an even stronger recommendation for packets in that size range.

Perhaps true today, who knows what it will be in the future.  As I wrote, I think we need some real data before we starting more proposing rules and solutions.  Having more data would give us more leverage to change behavior where needed.

Thanks,
Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 4 Dec 2015 20:17:29 +0000

Hi Bob,

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Thursday, December 03, 2015 3:36 PM
> To: Templin, Fred L
> Cc: Bob Hinden; IPv6 List
> I am not sure this is the right place to put this kind of requirements in.  Overall, I think some serious measurement needs to be done
> for us to understand what causes IMCP Packet too Big to be not returned.  Is it firewall/middle-box filtering, ICMP rate limiting, hosts
> dropping them, specific packet size, etc?  Or some combination?  We already have several RFCs saying they should be dropped and to
> use RFC4821 addresses the case if they are dropped.  I am not sure we understand the problem that well.

There have been many studies indicating failures of PMTUD in the Internet, which
motivated the development of RFC4821. There are two kinds of failures: 1) loss of
good PTB messages, and 2) receipt of spoofed PTB messages. The first is the more
serious issue resulting in a black hole, while the second is a potential DOS vector.
But, neither of these is a matter of concern when the source and destination are
both within the same well-managed administrative domain (e.g., a corporate
enterprise network).

Your proposed text above is appropriately characterizing PLPMTUD as
"an extension to Path MTU Discovery". That is to say, that PLPMTUD does not
obsolete standard PMTUD but rather augments it when greater MTU assurance
is necessary. Which is important, because PLPMTUD is harder to implement,
may take longer to converge, and needs to be implemented per application
(and not per-host as per standard PMTUD) since multipath may cause packets
of one application to take a different path than those of another application.

Therefore, I think it would be wise to establish a philosophy of "use standard
PMTUD when you can, and augment with PLPMTUD when you must". This
would seem to indicate the need for a recommendation in this document.

> Regarding your specific suggestion, I think it would be a mistake to put in recommendations with specific packet sizes.  This is a moving
> target and anything we put in a document that is going to become an Internet Standard will be wrong in the future.  Perhaps some
> sort of BCP would be better.
> 
> >
> > Reason:

As above, I think this document needs to recommend conditions under
which the PLPMTUD extensions need to be applied when standard PMTUD
alone is inadequate or vulnerable to attack.

> Perhaps true today, who knows what it will be in the future.

RFC2460 already has 1280 as the IPv6 minimum link MTU and 1500 as the
IPv6 minimum MRU - will this change in RFC2460(bis)? If not, then the
numbers should also be applicable to RFC1981(bis), or instead of the
actual numbers we could say "IPv6 minimum link MTU" and "IPv6
minimum MRU" for consistency with the rest of RFC1981(bis)?

Thanks - Fred

> As I wrote, I think we need some real data before we starting more
> proposing rules and solutions.  Having more data would give us more leverage to change behavior where needed.
> 
> Thanks,
> Bob
> 
> 
> > Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Mon, 14 Dec 2015 16:09:13 +0200

Fred,

> both within the same well-managed administrative domain (e.g., a corporate

Do you have pointers to these studies?

> of one application to take a different path than those of another application.

I agree.  Note the text I used largely came from RFC4821.

> alone is inadequate or vulnerable to attack.

I am still not convinced that it is useful to put something like this in rfc1981bis.  Might be better in the next version of node requirements.

> minimum MRU" for consistency with the rest of RFC1981(bis)?

My point was that, using what you wrote:

 "1500 bytes" is the predominant "Internet cell size”

This is the case for today.  This could easily change in the future as the underlying technology changes.

I don’t think we should be putting numbers like this in rfc1981bis, for the same reason rfc1981 didn’t either.

Thanks,
Bob

---

From: David Farmer <[email-masked]>
Date: Mon, 14 Dec 2015 11:56:07 -0600

Here is the problem I have with basic PMTUD, without PLPMTUD;

The fundamental purpose of PMTUD is to optimize the efficiency of 
communications by maximizing the MTU.  But basic PMTUD's primary failure 
modes doesn't result in sub-optimal communications.  To the contrary, 
basic PMTUD's primary failure mode breaks communications all together.

Basic PMTUD, without PLPMTUD, is not robust, in fact basic PMTUD makes 
IPv6 fragile, rather than optimizing IPv6.  It is arguable that IPv6 
would be more robust by simply recommending a static MTU of 1280, and 
not have basic PMTUD.

Basic PMTUD provides an unacceptable balance, it sacrifices robustness 
to provide optimization.  The combination of basic PMTUD and PLPMTUD, 
while not perfect provides a reasonable balance of robustness and 
optimization.

Therefore, I cannot in good consonance recommend basic PMTUD by itself 
for advancement to Internet Standard.  The only way I can in good 
consonance recommend basic PMTUD is if a strong recommendation for 
PLPMTUD is also included.  It probably wouldn't hurt if there was also a 
discussion of the failure modes theirs causes.

Thanks.

On 12/1/15 18:25 , Bob Hinden wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Bob Hinden <[email-masked]>
Date: Thu, 17 Dec 2015 16:17:46 +0200

David,

> On Dec 14, 2015, at 7:56 PM, David Farmer <[email-masked]> wrote:
> 
> The fundamental purpose of PMTUD is to optimize the efficiency of communications by maximizing the MTU.  But basic PMTUD's primary failure modes doesn't result in sub-optimal communications.  To the contrary, basic PMTUD's primary failure mode breaks communications all together.
> 
> Basic PMTUD, without PLPMTUD, is not robust, in fact basic PMTUD makes IPv6 fragile, rather than optimizing IPv6.  It is arguable that IPv6 would be more robust by simply recommending a static MTU of 1280, and not have basic PMTUD.
> 
> Basic PMTUD provides an unacceptable balance, it sacrifices robustness to provide optimization.  The combination of basic PMTUD and PLPMTUD, while not perfect provides a reasonable balance of robustness and optimization.
> 
> Therefore, I cannot in good consonance recommend basic PMTUD by itself for advancement to Internet Standard.  The only way I can in good consonance recommend basic PMTUD is if a strong recommendation for PLPMTUD is also included.  It probably wouldn't hurt if there was also a discussion of the failure modes theirs causes.

Please suggest text.  I would like to see what this recommendation would look like, and get feed back from others in the w.g.

Thanks,
Bob

---

From: David Farmer <[email-masked]>
Date: Thu, 17 Dec 2015 09:08:09 -0600

Bob,

> On Dec 17, 2015, at 08:17, Bob Hinden <[email-masked]> wrote:
> 
> David,
> 

I was thinking of text similar to what Fred has been kicking around and you were recommending back in November, some kind of SHOULD use PLPMTUD [RFC 4821] in addition to what you have below.  Above I was trying to add to the justification for adding this and why moving rfc1981bis forward without it is a bad idea.  

Over the holidays I'll take a poke at some text, but basically I think Fred is on the right track.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Dec 2015 14:08:40 -0300

> discussion of the failure modes theirs causes.

FWIW I agree with all the points made/raised_by David.

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Dec 2015 18:15:21 +0000

Hi Bob,

> Sent: Monday, December 14, 2015 6:09 AM
> To: Templin, Fred L

Here are a few:

TCP Problems with Path MTU Discovery
https://datatracker.ietf.org/doc/rfc2923/

Inferring and Debugging Path MTU Discovery Failures
http://conferences.sigcomm.org/imc/2005/papers/imc05efiles/luckie/luckie.pdf

Measuring Path MTU Discovery Behaviour
http://conferences.sigcomm.org/imc/2010/papers/p102.pdf

> I agree.  Note the text I used largely came from RFC4821.

OK.

> I am still not convinced that it is useful to put something like this in rfc1981bis.  Might be better in the next version of node

IMHO, for RFC1981bis to be a self-contained standard, it should not only
document the basic mechanisms and their limitations but also recommend
the conditions under which the RFC4821 extensions are advised.

> I don’t think we should be putting numbers like this in rfc1981bis, for the same reason rfc1981 didn’t either.

The reason for the 1500 is that current-day hosts that send packets no
larger than this will typically see their packets delivered without loss due
to a size restriction. In other words, we currently have operational assurance
that packets in this size range can traverse the Internet with high likelihood
and without triggering PMTUD. For packets larger than 1500, there is currently
no such operational assurance, and PMTUD may fail for Internet destinations.

So, if we say that hosts that send packets larger than 1500 bytes are
recommended to use PLPMTUD then we are setting an epoch for the
advent of jumbo frames. And, gradually, nodes that want to send large
packets will adopt the PLPMTUD extensions.

Besides, RFC2460 and RFC2460(bis) set 1500 as a key constant for the
minimum reassembly buffer size for exactly the same reason, and this
will carry forward into the future when the document becomes a full
standard. So, why can't RFC1981 do it, too?

Thanks - Fred