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

Brian E Carpenter <> Fri, 10 February 2017 03:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A2BC129551; Thu, 9 Feb 2017 19:25:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 ALuGlDn1513o; Thu, 9 Feb 2017 19:25:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74B04129562; Thu, 9 Feb 2017 19:25:41 -0800 (PST)
Received: by with SMTP id 204so1932190pge.2; Thu, 09 Feb 2017 19:25:41 -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=89bACYfdmEgrzwwGqzFQd3SxqiJopAme6V1HW2kHR44=; b=mVjv3EyVupQlq20a1Xd9fSLGEhmLmsibWdm1DMZgUEYh5Fefypuwbhp47tbQTIEgFp nqGp0wOgQpmExKymVKnOb+GgNBg3evy1caSzuoIYwPlnVDfLAJmb8/MqZUTVYc03uyUP UGMpm33AqxLHowgLXN0nTaf2JjVvC9oNKKFPqKJjtD6xSoZLhZzxTmOqd9ZHwp6Kvddx Hd7bS5Zl1irpz4101HC1m49T1lCx5fXoagVG3iIgrJuWv4SG0RCo0iJJsqDRLV0ajK78 D41wg1RDuFE9AKPO1jbXcJFsWJLedPLjXunf0sAXrkZFBq9KSdvTIYqMSB40QmN1fONd C0sg==
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=89bACYfdmEgrzwwGqzFQd3SxqiJopAme6V1HW2kHR44=; b=tJhbVzVujApFtelBW3PJjWq4lx8o/wue5gZrHkd/Sr/Ie/AwbttO8M08zl/N8tpCNY 1KzFaohLxB0pHGkPgscja4J7nTD41bEwQTu4FWnm+kS43AyyLLDANaaioLp1fuWogz5z Us4YmuL7rJu1HFIUyT1GEUL1RpL9gmfWCMFductkP+6ZAAFH4Atyoms4kAd/O0lEn1t6 hMkLdv7rWj6Rk4favHAO1u0kEKTFjKTZqQyYrjzujrmzYWPtP5dy9yoz+LdR5qP4KGXk GqlgvpYszNPmCewDYjSlVVS7l1LvXutj0w26+hS93/6hWlJRnxDqefP644x0xeMRjO8t EX6A==
X-Gm-Message-State: AMke39nOPOoODV+f+nFt4zGWesN0NjB7AkFZr/xJH4uRWgUKlG9SOWfrDzqw3ykOAN1xZg==
X-Received: by with SMTP id 17mr7590435pft.26.1486697140821; Thu, 09 Feb 2017 19:25:40 -0800 (PST)
Received: from ?IPv6:2406:e007:7ac3:1:28cc:dc4c:9703:6781? ([2406:e007:7ac3:1:28cc:dc4c:9703:6781]) by with ESMTPSA id k184sm521569pgc.23.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 19:25:40 -0800 (PST)
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: Stewart Bryant <>,
References: <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 10 Feb 2017 16:25:44 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
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 03:25:42 -0000


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.

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

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

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

I think your other comments are all valuable.