Re: SLAAC vs DHCPv6 (II)

Fernando Gont <fgont@si6networks.com> Thu, 30 January 2020 18:18 UTC

Return-Path: <fgont@si6networks.com>
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 3286412011B for <ipv6@ietfa.amsl.com>; Thu, 30 Jan 2020 10:18:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 jzHd2JOAyEUb for <ipv6@ietfa.amsl.com>; Thu, 30 Jan 2020 10:18:03 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2A2120090 for <ipv6@ietf.org>; Thu, 30 Jan 2020 10:18:03 -0800 (PST)
Received: from [192.168.100.103] (unknown [186.183.50.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9A81A86BD7; Thu, 30 Jan 2020 19:17:43 +0100 (CET)
Subject: Re: SLAAC vs DHCPv6 (II)
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Lorenzo Colitti <lorenzo@google.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, 6man WG <ipv6@ietf.org>, Suresh Krishnan <Suresh@kaloom.com>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <8D5610EA-49D3-483E-BB7A-67D67BC89346@jisc.ac.uk> <DE7B0688-230F-4A5C-8E24-9EAED9FD9FEB@puck.nether.net> <AFEBAD7D-DF24-4924-8B9A-60DF22BA1953@consulintel.es> <c42affce-fbd3-23ec-c9ff-4f05cdf38630@si6networks.com> <41173152-A8E8-4241-9DE7-376AA7AFB813@consulintel.es> <c4166907-b6c9-a4ef-fd59-cf539bbe0405@si6networks.com> <43D76C96-C16B-4BEB-B9B8-C68D53BCE63F@fugue.com> <fb5b8377-892d-2777-ef9b-4f9ddefa6c93@si6networks.com> <CAKD1Yr034_tu7ZoJ1FCfDYhNSN6igm-ZQyR4u3U+UDMr=huGOw@mail.gmail.com> <1af0b06d-f9d7-5ea1-27f3-b417eb9148fa@si6networks.com> <7606A049-318D-4526-917D-F2A801BF7050@cisco.com> <CAKD1Yr1d9kORFdoOJr22J_UDJ9hLPr6AQLyWuh7=bAQKa+aXGw@mail.gmail.com> <MN2PR11MB356588FC3E8A6410B725D159D80A0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAKD1Yr35meRGh_POo_2jrHA_oazO1xUOG5G_rx43xNLFYHQsMQ@mail.gmail.com> <2ea73f99-9fed-4aa0-6f70-884896cc626a@si6networks.com> <26688.1580393657@dooku>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <b127ec24-755e-9db4-90b3-3bebcf311e67@si6networks.com>
Date: Thu, 30 Jan 2020 15:15:28 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <26688.1580393657@dooku>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/JDF9I9RM_6WqhKjBMvaujRwMea8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 30 Jan 2020 18:18:06 -0000

On 30/1/20 11:14, Michael Richardson wrote:
> 
> Fernando Gont <fgont@si6networks.com> wrote:
>      >> But it does violate the recommendation if you use it to enforce how
>      >> many addresses the host can use. The text is:
>      >>
>      >> Due to the drawbacks imposed by requiring explicit requests for
>      >> address space (seeSection 4
>      >> <https://tools.ietf.org/html/rfc7934#section-4>), it is RECOMMENDED
>      >> that the network give the host the ability to use new addresses
>      >> without requiring explicit requests.  This can be achieved either by
>      >> allowing the host to form new addresses autonomously (e.g., via SLAAC)
>      >> or by providing the host with a dedicated /64 prefix.  The prefix MAY
>      >> be provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other
>      >> means.
>      >>
>      >>
>      >> If the network is able to deny a registration, then it's not a
>      >> registration, it's a request.
> 
>      > The network always wins. Folks could run SAVI, and enforce one addrees
>      > per node, even with SLAAC. Yes, you're address wouldn't be rejected
>      > .. it just wouldn't work. The outcome is the same.
> 
> It would be impossible to debug, so the user turns off IPv6, and we all lose.

Well, if the network tries to convey policy, and a host stubbornly wants 
to violate that policy... the host will be shot down, yes.


It would seem to me that:
* We did a BCP saying "host should be able to configure as many 
addresses as possible". -- that's fine... IPv6 is all about the extra 
addresses, right?

* Vendors ship devices with a few Ks of NCE. Maybe we should do 
something in this area?

* Multicast doesn't seem to be playing so nice, either.

The two don't work well with each other. And we don't give the ops 
people the tools that could make the above bullets be nice with each other.

No wonder about the outcome.


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492