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

Tore Anderson <tore@fud.no> Sat, 06 February 2016 12:48 UTC

Return-Path: <tore@fud.no>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4801B2DBB for <ipv6@ietfa.amsl.com>; Sat, 6 Feb 2016 04:48:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.399
X-Spam-Level:
X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iHy09oh2FnL for <ipv6@ietfa.amsl.com>; Sat, 6 Feb 2016 04:48:35 -0800 (PST)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0211B2DB8 for <ipv6@ietf.org>; Sat, 6 Feb 2016 04:48:35 -0800 (PST)
Received: from [2a02:fe0:c421:2034::c68] (port=40560 helo=envy) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <tore@fud.no>) id 1aS2Hv-0006vc-II; Sat, 06 Feb 2016 13:48:31 +0100
Date: Sat, 06 Feb 2016 13:48:31 +0100
From: Tore Anderson <tore@fud.no>
To: otroan@employees.org
Subject: Re: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01
Message-ID: <20160206134831.0ef1c371@envy>
In-Reply-To: <9C0F366C-4887-4A63-8422-1C370F9CBD3E@employees.org>
References: <9C0F366C-4887-4A63-8422-1C370F9CBD3E@employees.org>
X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/W1usGcpzp4scZXsa54hfLlShgmk>
Cc: bob.hinden@gmail.com, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Feb 2016 12:48:37 -0000

* otroan@employees.org

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

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