Consensus? (was Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux)

Wilco Baan Hofman <> Thu, 02 March 2017 11:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D22F12986B for <>; Thu, 2 Mar 2017 03:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ndUfRv341Xhd for <>; Thu, 2 Mar 2017 03:38:01 -0800 (PST)
Received: from ( [IPv6:2001:41d0:52:300::107c]) by (Postfix) with ESMTP id 53F411294A1 for <>; Thu, 2 Mar 2017 03:38:01 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 6F56F1041AD2 for <>; Thu, 2 Mar 2017 12:38:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pn9k1oDdziyv for <>; Thu, 2 Mar 2017 12:37:58 +0100 (CET)
Received: from [IPv6:2a07:8500:120:e03a::1001] (unknown [IPv6:2a07:8500:120:e03a::1001]) (Authenticated sender: wilco) by (Postfix) with ESMTPSA id F38C21041A88 for <>; Thu, 2 Mar 2017 12:37:57 +0100 (CET)
Subject: Consensus? (was Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux)
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Wilco Baan Hofman <>
Message-ID: <>
Date: Thu, 2 Mar 2017 12:37:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gd7gaHq0LEm9Kuik1xXGG5NPirdooAwq0"
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: Thu, 02 Mar 2017 11:38:03 -0000

On 02/03/17 12:06, Alexandre Petrescu wrote:
> Le 02/03/2017 à 10:31, Mikael Abrahamsson a écrit :
>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote:
>>> perfectly fine to use that plen==65 to have an entry in the rt
>>> table, and use a manually configured address in that plen.
>> Linux does the right thing in not autoconfiguring itself address(es)
>> when plen isn't 64.
> Whereas it is the right thing if on Ethernet (RFC2464) it is wrong on
> cellular links for which we have no RFC IPv6-over-foo.  Same with USB
> and to a certain extent on WiFi.
It is undefined on non-IEEE802 networks and /64 is the one thing that
works for SLAAC, operationally.
>> However, what does it do when it receives an PIO with plen of 65 and
>> M=1 and then it gets an IA_NA and configures that on the interface?
> I dont know.  But I guess it still calls that 65 plen "illegal".
Which would be correct in the IEEE802 case, undefined in other cases,
still not incorrect behaviour from Linux in this case.
>> Doesn't it install the /65 in the routing table?
> Dont know, but there is a need to check.
> How about the /63 case?  Do you think it is normal that linux kernel
> does not configure an IP address on Ethernet when receiving a plen==63?
I would actually consider that normal, because the standard basically
mandates /64 and configuring on /63 is undefined at this time. As
implementer I would also reject such prefixes, because the code for
generating the EUI-64 and the privacy extension address all (correctly)
assume 64-bits of space, not 63, not 65.


I think we can get consensus on:
- Making a recommendation of /64 for end-user networks
- Keep it required for things that depend on /64 (SLAAC, DHCPv6, ILNP,
NPT66, etc)
- Allow things like v4mapped address to use different subnet sizes, they
don't configure via SLAAC or similar methods. This makes sure SIIT keeps
- Make prefixes of /65-/126 allowed on fully statically configured
interfaces, such as on routers


I don't think we're going to get consensus on dropping /64 boundary
entirely or on requiring the /64 boundary for everything.

We can't drop it entirely, because it would break deployments at end
user devices. And it is still a good recommendation to use /64 subnets
on those networks.

Conversely, we can't completely keep it, because it does not match the
operational reality in point-to-point links between routers. Configuring
/127 does not always work yet and does not cover the PTMP case (VRRP,
multiple BGP sessions). Configuring /64 on those links would make the
routers vulnerable to ND exhaustion.

Kind regards,

Wilco Baan Hofman