Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07

David Farmer <> Tue, 07 March 2017 04:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1352129AFB for <>; Mon, 6 Mar 2017 20:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.8
X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rN35DMAfxfZd for <>; Mon, 6 Mar 2017 20:56:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C03DA12941D for <>; Mon, 6 Mar 2017 20:56:22 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 13F8E646 for <>; Tue, 7 Mar 2017 04:56:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tGkG8jQ5w4-3 for <>; Mon, 6 Mar 2017 22:56:21 -0600 (CST)
Received: from ( []) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCF46283 for <>; Mon, 6 Mar 2017 22:56:21 -0600 (CST)
Received: by with SMTP id f54so119574821uaa.5 for <>; Mon, 06 Mar 2017 20:56:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=egZ6oH2APU9EwN8b9h3pgLy8BpZJIsQL3DS+RUqNZ7M=; b=ASUaa5NwIHJW5JXjIUZLyfzCRFMtPid/12lIHPOUJPEc4VdNEKSl6vDyR6VDREKRLF ZHgABKUeQf2UgtKjvq1HW+fTRiAphp6aAVWUSqoYc5yg1b8lIW48EaLqNU6JTF20gtMn AI8UXzOPp99Krel82JzNhk+eT3zg8IyB7PLWT8vEDn0xRHGfNYoG2fNdXhZa9gYkZ/nZ RzvrA0oDfj8EOpNX8IjQHAO67FQscPJcnBHcc2d9BDRgp5oLXQqCBRji9qnkVFGeqSIi EmRIVnj0xcQov6m+nlwVz38y5KfwqA5786qcKpVUroIjNnZH1oK2qBhg07IptkOtzNMQ heOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=egZ6oH2APU9EwN8b9h3pgLy8BpZJIsQL3DS+RUqNZ7M=; b=eQZTvF59AQwojKohUYrQzfqcwFrSAV93UOKhHbUFl46+nH/XfX3F/kBsBUm9nc/+XM PSOPf+PQKNBW5DLt2+6ioUv3FGVuOKp2AjZZM+AHlxezcQM/zEhR8uknsQLcuYlIyQf1 aV9rYtzilxceR6UHGou+vPUFp559HzNvAP95+1EhZfOrXCGqtakFHLTMumoMNIgISXch cNqhBvZ2DJjb+wAqEP3O6AOXfzyUuQayYCQh7HiByE4PuYoarSM5jAYIXrOIPNU3Zlbc zBskzkwqG8s5wd6ISuziIOqt3bZ8dTSSMSn3mqvUkAirQ932GPuK6XczqbxK605ltsj9 Yl+g==
X-Gm-Message-State: AMke39kiEmXqYb6WInnsM8c0Vo3wVO1yXAjlCGMQWik2UpEJOiLmXYkwoUH0rOjNt/arVP8bmCLfqwWc/Jtq3Do0R0awItQIWRrTeOxFuisXyhXD2KT2cFGSldy9jbYNuLOUQHH6Er04dxcG4zo=
X-Received: by with SMTP id a74mr8513343vki.46.1488862581258; Mon, 06 Mar 2017 20:56:21 -0800 (PST)
X-Received: by with SMTP id a74mr8513336vki.46.1488862581015; Mon, 06 Mar 2017 20:56:21 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Mar 2017 20:56:20 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: David Farmer <>
Date: Mon, 6 Mar 2017 22:56:20 -0600
Message-ID: <>
Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07
To: Lorenzo Colitti <>
Content-Type: multipart/alternative; boundary=94eb2c149b2842db95054a1cd502
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, 07 Mar 2017 04:56:24 -0000

On Mon, Mar 6, 2017 at 9:18 PM, Lorenzo Colitti <> wrote:

> On Tue, Mar 7, 2017 at 4:05 AM, David Farmer <> wrote:
>> Instead, I would suggest another approach: see what the problems with
>>> 4291 are, *write them down*, and only then write a document explaining what
>>> should be changed and why.
>> The list of 7 points are the problems that many see with 4291bis, maybe
>> overly summarized, but they are there.
> Well, but what you provided is an alternative solution, not a problem
> statement. Example of a problem statement would be, "RFC 4291 does not
> allow non-64-bit IID lengths. However, assigning smaller prefix lengths is
> necessary because [...]".

To be clear no where in the text I provided does it say that an IID other
than 64 is allow.  It say 128 bit quantities from manual configuration and
DHCPv6 can be associated with with subnet prefixes of any length.  That is
a fine distinction, but no finer that you claiming that requiring that
64-bit IIDs, and you implying 64-bit subnet prefixes too, doesn't make IPv6
classful. Are you saying that every implementation of IPv6 that allows
manual config of subnet prefixes other that /64 have it wrong?
Furthermore, if subnet prefixes other than /64 aren't allowed then how do
we have RFC6164

I contend that the whole concept of an IID is optional, please note that
RFC4291 and it's predecessor say: "At a minimum, a node may consider that
unicast addresses (including its own) have no internal structure", So I
contend that RFC4291 merely says that if you use an IID it must be 64 bits.
It doesn't directly say that 128bit IPv6 addresses can't be associated with
subnet prefixes other than /64.  In fact it also says, "IPv6 unicast
addresses are aggregatable with prefixes of arbitrary bit-length, similar
to IPv4 addresses under Classless Inter-Domain Routing."  Which to me
implies that subnets other than /64 have to be valid.  Furthermore, RAs are
allowed to be any length, especially if they don't set the "A" flag, why is
this if not to allow subnet prefixes of any length?

> I can't help fill in the [...] because I personally don't see what you can
> do with a /113 that you can't do with a /64 (other than conserve addresses,
> which has always been a non-goal), but there seem to be several
> participants who do see a problem. What I'm saying is that if we want to
> change the standard, the people who see a problem with it should articulate
> that problem in a way that it's possible to find a solution using informed
> and documented engineering trade-offs rather than opinions.

Just because you can't see it doesn't mean that other can't and don't have
valid uses.  I'm not convince it's actually making any change, SLAAC still
has 64-bit IIDs.  It is only making explicit that, manual config and DHCPv6
address can be associated with subnets of any length, and it's clear that
at least some implementors think it says that already, and I think your in
the minority of people that think's it doesn't.


David Farmer     
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>