Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

james woodyatt <> Tue, 28 February 2017 20:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 721981296B2 for <>; Tue, 28 Feb 2017 12:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 NxZJ0vBAmh6F for <>; Tue, 28 Feb 2017 12:09:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0D9D129698 for <>; Tue, 28 Feb 2017 12:09:25 -0800 (PST)
Received: by with SMTP id w189so5478908pfb.0 for <>; Tue, 28 Feb 2017 12:09:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=uBds4aVJinARD7nkKig0BbN7xvZGa2U5lZXDNueLAgU=; b=ourmq++vv6s/d0oXAsSBjgaZWBSDS2F2ZOMkWuBo70BGyDXIIT7ZLwTi4viZW0jEoi hlsj9zfVFbHjIlfl9X2kItS35981rsI2oNVIWlAuDaRZV4zMQwGt7PnEtVps/QgmA55I DQr51/4GShgL3IkROzDCjXMrkFugYCs+ktrKy3dAo+m+cLIuBnIDE5iGKeUdeR9VCywB PwuVODWWh7Tz+jYGWKt0g764pPoN+PhSmr9aB/hECYOxP+0mNqFMaOYwMU6sTA62JaaW EOesToa3zJ3sz/21DTZAkEwaQ3Osr9skQDRnjcu0jdTs3upObgDUqXNUyNl/mggNXjGF pzzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=uBds4aVJinARD7nkKig0BbN7xvZGa2U5lZXDNueLAgU=; b=Pqh4mYu9fp8wrH07lDpyVOCw/RSBbeB/foWrVO8cYzJxPJ24Qv6iYUTUn80bhU7kd7 rggUOb1eraWenZr+iJxAzUPT+a1N/w7zC9HYSjXPrDGlw7rG+B3EUR0BPLOWr2k1zbSb K1pAkS0TRYvsQ+CBPzU/ZyJNaQPW3A/6jMpXf11/IKPP1v8aRr4XBkxaNUw1kgjYfmAc Cfq/aojpZx89RlLFylrYs6VExYSfsNp9oiHdq7sg63LEaIKNWe1vzf/GU0Jg5ykmK0oI nBgS77hNwq61VGkKp259tZCQyQFFa1XkhAqUvZcbQ0WR0r0aouETQhk2VkhrOv/lbABC /IYQ==
X-Gm-Message-State: AMke39m8GSEwxoFLySNAJEuo9wJZhdff/WEPbGfi7imNBgNLarzIeW1+oK3FdsQagfTGZ2xo
X-Received: by with SMTP id i12mr4585883pgn.30.1488312565297; Tue, 28 Feb 2017 12:09:25 -0800 (PST)
Received: from ([]) by with ESMTPSA id j62sm5855245pgc.54.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Feb 2017 12:09:24 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_066DEC90-B95B-4D1E-95FF-5D646891C8B3"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
Date: Tue, 28 Feb 2017 12:09:23 -0800
In-Reply-To: <>
To: David Farmer <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: 6man WG <>
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: Tue, 28 Feb 2017 20:09:27 -0000

On Feb 28, 2017, at 07:46, David Farmer <> wrote:
> I think we should be saying OS MAY allow configurations other than /64, at least with manual configuration, and maybe DHCPv6 too.

This statement puzzles me because I see the distinction between subnet prefix assignment and interface address assignment as A) really important, and B) one of the ways that IPv6 improves greatly on IPv4. I really really really don’t want to lose that improvement.

p1. DHCPv6 does not assign subnet prefixes. DHCPv4 does, but that was a feature that we deliberately left out of DHCPv6. We put prefix *delegation* to routers into DHCPv6, which is a whole other discussion I don’t want to have right now, but we left subnet prefix assignment to the Router Discovery protocol, where I would say it rightly belongs.

p2. Manual configuration of IPv6 interface addresses and IPv6 subnet prefixes are separate and distinct processes. Either of them can be manually or automatically configured independently from the other in several of the host OS implementations I know about. This is not so often the case in IPv4 implementations.

In all these debates we are having about I-D.ietf-6man-rfc4291-07, I have been very careful to maintain that it is only *subnet* prefix assignment where I am insisting that /64 is a general requirement, with known exceptions for things like subnets that consist entirely of routers.

For that reason, I really don’t know how to respond when people insist that DHCPv6 is somehow involved in the discussion about subnet prefix assignment. Are they confused about how subnet prefixes are assigned in IPv6?

Yes, I recognize that Router Advertisement messages are defined with a packet format that allows routers to advertise PIO with L=1 and a Prefix Length > 64. I continue to maintain those should not be used. There are a lot of IPv6 applications, including quite a few Standards Track protocols published by IETF, that will simply truncate those prefixes to a /64 in every place where an IPv6 interface address must be mapped to a subnet prefix. And there are many SLAAC implementations that will decline to assign statelessly any interface addresses in a prefix advertised with A=1 and Prefix Length > 64. There are also a few implementations [broken ones, admittedly] kicking around that will simply ignore those PIO entirely. I think the successor to RFC 4291 needs to recognize that is reality and provide appropriate requirements language.

--james woodyatt < <>>