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

Wilco Baan Hofman <wilco@baanhofman.nl> Thu, 02 March 2017 11:38 UTC

Return-Path: <wilco@baanhofman.nl>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D22F12986B for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 03:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndUfRv341Xhd for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 03:38:01 -0800 (PST)
Received: from vps.baanhofman.nl (vps.baanhofman.nl [IPv6:2001:41d0:52:300::107c]) by ietfa.amsl.com (Postfix) with ESMTP id 53F411294A1 for <ipv6@ietf.org>; Thu, 2 Mar 2017 03:38:01 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by vps.baanhofman.nl (Postfix) with ESMTP id 6F56F1041AD2 for <ipv6@ietf.org>; Thu, 2 Mar 2017 12:38:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at vps.baanhofman.nl
Received: from vps.baanhofman.nl ([127.0.0.1]) by localhost (vps.baanhofman.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn9k1oDdziyv for <ipv6@ietf.org>; 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 vps.baanhofman.nl (Postfix) with ESMTPSA id F38C21041A88 for <ipv6@ietf.org>; 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)
To: ipv6@ietf.org
References: <20170223134026.GI5069@gir.theapt.org> <CAN-Dau0n6oFm538XdJOcuO1yg92BCDD3mBu5YfBVm_+g-gtcKA@mail.gmail.com> <CAL9jLaYO=uYgVfSZ0SoSe0SujJ1xgwEKE8WLzo_keJHywgXTtg@mail.gmail.com> <CAN-Dau1vJV5O_Ythp6THkAu4-YZXV82Upny1V+ybbjCVZQQX=A@mail.gmail.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <de4988be-6031-08d9-84ce-21c3fa4f9bc9@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <CAO42Z2z7v4gDk91b6Of-1sczV88m3B9kzn0MeJU_VBJ416k6Ww@mail.gmail.com> <ae35b45a-0398-840f-fc0d-1f64dd2fcc58@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <alpine.DEB.2.02.1703012051590.30226@uplift.swm.pp.se> <b5784622-c24e-a531-4e68-249b03701941@gmail.com> <CAAedzxrSTFe0GgYuvtXPNE=R_ZCXotxL7HbKdj5A4-869rncmw@mail.gmail.com> <ba025be6-709d-87b4-f388-d6f143408277@gmail.com> <alpine.DEB.2.02.1703021029010.30226@uplift.swm.pp.se> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com>
From: Wilco Baan Hofman <wilco@baanhofman.nl>
Message-ID: <bead3cd8-f7f9-37b3-66f9-e76ae94056d1@baanhofman.nl>
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: <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gd7gaHq0LEm9Kuik1xXGG5NPirdooAwq0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zZ7TI7A3a_3a0MqInersriDkQRc>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=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.

==
Summarizing:

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
working.
- 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