Re: SLAAC vs DHCPv6 (II)

Fernando Gont <fgont@si6networks.com> Tue, 28 January 2020 16:54 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 D7DF4120025 for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 08:54:49 -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=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 eZVob69cIHbQ for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 08:54:48 -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 02F19120019 for <ipv6@ietf.org>; Tue, 28 Jan 2020 08:54:48 -0800 (PST)
Received: from [192.168.100.103] (unknown [186.183.48.23]) (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 BF5E282B41; Tue, 28 Jan 2020 17:54:39 +0100 (CET)
Subject: Re: SLAAC vs DHCPv6 (II)
To: Lorenzo Colitti <lorenzo@google.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: 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> <80207E17-AE8E-4D19-B516-D2E6AB70721E@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>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <2ea73f99-9fed-4aa0-6f70-884896cc626a@si6networks.com>
Date: Tue, 28 Jan 2020 13:44: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: <CAKD1Yr35meRGh_POo_2jrHA_oazO1xUOG5G_rx43xNLFYHQsMQ@mail.gmail.com>
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/RYHk6SH0H5aZqMLraFUB5eIRGBo>
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: Tue, 28 Jan 2020 16:54:50 -0000

On 28/1/20 06:02, Lorenzo Colitti 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.


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