Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Brian E Carpenter <> Fri, 03 February 2017 00:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94BFF129621; Thu, 2 Feb 2017 16:26:47 -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 CC2laUhjOhyB; Thu, 2 Feb 2017 16:26:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AB4412956C; Thu, 2 Feb 2017 16:26:46 -0800 (PST)
Received: by with SMTP id 75so353861pgf.3; Thu, 02 Feb 2017 16:26:46 -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=gt3dTuJyJp1XcssyPP9NRcpUJ7qdKxX+X0d4Ff+G5u4=; b=IeWftiZWkNKvSg/stAK0wFQGg4MmTaJjJ/NyOoELVHZdrqoQjQeTEixIwo/wuKcg25 fTwtTL6kX9y9J8kx1+hTBKGjtnbsWr9gYBfBe+gIHToDDafVmY9OflB3YDpzppL96WMu UVk0LIkj4HYllr+Ol7QuVCzdFtiyLooyhQDcOJTWgHMaswJJcZnkFBhAWZ/O/KevXhBQ IKIPISUd+nUombEfXKs7kygl/3Xo0VvF2GGtxmNG0YeBiEvIT0f3Xq3+3tw77ZXJwLDg iB2KWfYvyBgh+DBnOS1Zwgw+O4SZ7vwFmzYOezpWYzcUbbMycoUQ4/KDhmKAFPf28pkt hO9A==
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=gt3dTuJyJp1XcssyPP9NRcpUJ7qdKxX+X0d4Ff+G5u4=; b=dB1hXMo9zvLoQE5lLqmusm6cS57Yab3H2S/GPFr9IjcIes1NSIQYTp6Myt+CqxPfn6 4umY9ImsuR+q6eVdGpfZass/8BQzHuDIExG4XNorAqvA0Y1CxolsGoZnEf2soacrWmYY QoPYMA/JPnbvI5xcWdNqQG1wIEavdZHxtcesa8oWpZSDg0U6f1VZJ2m7HSyC/bPdgIjD NrRFnRApCf6IoSXOYPw8dbyi9hPYmOzy2Kgi/REEWwKPr0ipt47lMROKU1/R5PrOp/2g 6kPynpgUwTnCUlVEOvihGcv6+yEdngriHOY6KYHvumySxtpLi2cviUkXFzPFm9qWUzkD pa0w==
X-Gm-Message-State: AIkVDXI0e+a/ZEIj9AGkZ4bhfQZ8uUdZDwpH4xZc0nAZCevEGHd7MZA2XGxhx8bTPx3jng==
X-Received: by with SMTP id y25mr14382327pfj.162.1486081605984; Thu, 02 Feb 2017 16:26:45 -0800 (PST)
Received: from ?IPv6:2406:e007:7909:1:28cc:dc4c:9703:6781? ([2406:e007:7909:1:28cc:dc4c:9703:6781]) by with ESMTPSA id k76sm61377499pfg.42.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 16:26:45 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: Fernando Gont <>,
References: <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 3 Feb 2017 13:26:49 +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: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Feb 2017 00:26:47 -0000

Hi Fernando,

On 02/02/2017 22:14, Fernando Gont wrote:
> The current impossibility to parse an IPv6 header chain that includes
> unknown Next Header values 

Wait... you're talking about parsing by intermediate systems. The destination
node either can understand the new Next Header or transport protocol,
or it can't. That's fine, and is the intended result.

> results in concrete implications for the
> extensibility of the IPv6 protocol, and the deployability of new
> transport protocols.  Namely,
>  o  New IPv6 extension headers cannot be incrementally deployed.
>  o  New transport protocols cannot be incrementally deployed.

In both cases, add "in the presence of interfering middleboxes".

This is not new. For a document moving from PS to Standard, it is
not something we can change.

Note, I am all for coming back to this problem, after we have the
Internet Standard in place. Maybe we can fix it or maybe we can't,
but it's IMHO off topic here.