Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

Brian E Carpenter <> Fri, 10 February 2017 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DE3B1295A2; Fri, 10 Feb 2017 11:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MOxZ3dYvUwbD; Fri, 10 Feb 2017 11:45:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E7E5129540; Fri, 10 Feb 2017 11:45:37 -0800 (PST)
Received: by with SMTP id 19so3069934pfo.3; Fri, 10 Feb 2017 11:45:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=swUDx54phvfF0lOJ8hCltKAaJz4Je2hRCpTLONbFpxE=; b=lZ9rxZpcxBgBycFYjYudiE8smtLoEKuo6uJhdWncUj/jY9FvtZw6xMUyYHVkBFB5wN WmITLo/bmNhptJKVrNYYpyse9pHvJo3/hfXRY/3FnnOa14cRHYqb6B7fAftGxEvb81t3 jm92G8ndxKQmjm7yXa3F7hNw4xiAjqw5iQomRGcjGm5WkzloTZiY3eGMSdVVM0Z4pMUx j3Cu6vUGU4ttPIbmrnIcYg+9yKqJpXCOwfoSSsVlV4O8BEVrVQpJFVBn4zeEQ7CNbhMs ObPnlEloaM10GI8y0ERq/7m4lw+IOIcADRscnbA8oSJ71Dr/wQrkPweoQIA7ubMSpVFM qibg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=swUDx54phvfF0lOJ8hCltKAaJz4Je2hRCpTLONbFpxE=; b=Rdm/4tHvDHgDGlet7UAb8LXOK728NTmvWqdLXMgoCFWi2fI0dbkVu2/vzJiX+W5uHU e84Gfpl5ebz2862DZoH9LPEV5YelHCZSgc/0m9E8G8pBOf1fNVx8J3eTUWHMYqaUZwPM vhdYqir2Bvh1OmzwGVc/oodKRNUkiHgRCmvo1sDPgkxkmbq/k5Ic+qOEaxbpOTjIdWod sQt72/GTL+tl+tMZ9Nj9JLXoFloIgOuHt3vupm0XFT51C/d8j1K0TroY21PzbUUA2/cb qyILRpBQwb3+TcE/T6Szv0aVbSQR3XHnt2JxZITs9Drmy+fA2NVlG51HUMkA/qtrfFeu 5cmQ==
X-Gm-Message-State: AMke39nbKoqJl/w80yPTzdf2nru48VoswBBke/MHKhfCEsZhsKIh+9ozCvU8xEgxgyX63w==
X-Received: by with SMTP id i137mr12712107pgc.11.1486755936371; Fri, 10 Feb 2017 11:45:36 -0800 (PST)
Received: from ?IPv6:2406:e007:769c:1:28cc:dc4c:9703:6781? ([2406:e007:769c:1:28cc:dc4c:9703:6781]) by with ESMTPSA id g70sm7160051pfb.50.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 11:45:35 -0800 (PST)
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: Stewart Bryant <>, Stewart Bryant <>,
References: <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Sat, 11 Feb 2017 08:45:41 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Feb 2017 19:45:38 -0000

On 10/02/2017 23:20, Stewart Bryant wrote:
> On 10/02/2017 03:25, Brian E Carpenter wrote:
>> Stewart,
>> On 10/02/2017 04:19, Stewart Bryant wrote:
>> ...
>>> I wonder if we would best serve both our future and our heritage
>>> if we declared RFC1981 as historic, and either left the idea there,
>>> or declared it as historic and wrote a new text from a clean start?
>> I don't see that. It's a stable, widely deployed, interoperable
>> mechanism. That is rather orthogonal to the issue that has been raised,
>> which is that faulty ICMPv6 filtering blocks it on many, many paths
>> across the Internet.
> I will not debate whether it is faulty or not, but it seems that in 

It's faulty by the standard of RFC4890 (which is Informational).

> practice the
> Internet breaks the mechanism. However it breaks it is a way that seems
> disruptive to some user traffic. The document is really guidance
> one how hosts might use  ICMP for optimization, and arguable need
> not be a standard at all.

I think that's a mischaracterisation of the mechanism (and the draft).
PMTUD is not an optimisation. Without it, you get black holes.

> My remark about heritage is that this vintage draft is very much a 
> product of
> its time, and really needs modernizing, and after modernizing ought to
> look quite different, and thus maybe we should employ a procedure
> other than a simple replacement.

It's proposed for Internet Standard. That means it must replace the
PS document and must specify the same thing, plus corrections, minus
unused features.

>> ...
>>> It is concerning that the draft does not talk in any detail about
>>> how modern ECMP works, i.e. using the five tuple, and noting that
>>> the PMTU may be different depending on the transport layer port
>>> numbers.
>> Has this problem been analysed for, say, IPv4? And does the real world
>> contain ECMP setups with different MTUs on different paths?
> I don't know if anyone has looked. Since the mechanism is 
> self-correcting albeit
> with some disruption to user traffic it looks to the application and the 
> application
> user, just like the Internet not working for a few moments.
> In a well managed SP network there should not be, but neither should there
> be asymmetric path costs, but there are. The less well manage private
> networks are less well managed.
>>> Given that a very large fraction of packets will traverse an MPLS
>>> network at some point, I am surprised that there is no text talking
>>> about the importance of providing support for this feature in the
>>> MPLS domain. RFC3988 talks to this point, but is only experimental.
>> I don't understand. How does the fact that there might be some MPLS
>> segments along the path affect end-to-end PMTUD?
> The point that RFC3988 makes is that MPLS looks like a single hop to IP 
> and the
> PE has to fragment or has to reply with an ICMP error message to support
> PMTUD. MPLS has ICMP extensions, but I don't know if they integrate to 
> result
> in the right response at the end node.
> My point is that the draft is silent on the subject, and perhaps it 
> should not be.

Well, in general it's silent on tunnels. They have to emulate links,
as stated in section 2. I still don't see why an MPLS tunnel is a special case.

> However your question make me ask a further question. The draft is also 
> silent
> on NATs. Is there any advice needed for people designing and configuring 
> NATs?

Yes, for NAT64/NAT46 - in RFC6145. For NAT66, the advice is "don't".

>>> ======
>>>     If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation
>>>     could use the flow id as the local representation of a path. Packets
>>>     sent to a particular destination but belonging to different flows may
>>>     use different paths, with the choice of path depending on the flow
>>>     id.  This approach will result in the use of optimally sized packets
>>>     on a per-flow basis, providing finer granularity than PMTU values
>>>     maintained on a per-destination basis.
>>> SB> How widely is flow-id supported in networks? I thought that the
>>> SB> current position was that it was unreliable as an ECMP indicator
>>> SB> and thus routers tended to glean information from the packet themselves.
>> This is future-proofing. Agreed, usage today is limited.
>> (But it would be better to call it the Flow Label for consistency with other
>> recent RFCs.)
> Well the question is whether it is simply limited today, or broken today 
> in a manner that
> is irrecoverable? 

Nothing's broken. It's just underused.

> I don't know, but I do know that the mainstream ECMP
> approach is the five-tuple.

Sure, but see RFC6438 for some of the difficulties that
causes with IPv6.

> There is something akin to the flow label being
> deployed in MPLS. However
> what distinguishes the MPLS Entropy Label is that it is inserted (and 
> removed) by the
> service provider and is therefore trusted by the service provider.

Exactly the same for ECMP tunnels, in RFC6438. Guess what, my co-author
was from a provider.


>> I think your other comments are all valuable.
> Thank you.
> Stewart
> .