Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

Fernando Gont <fgont@si6networks.com> Mon, 13 November 2017 13:20 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 DB5E5128B91; Mon, 13 Nov 2017 05:20:37 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 vOXq-U4UtQgz; Mon, 13 Nov 2017 05:20:35 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32CC12025C; Mon, 13 Nov 2017 05:20:35 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e] (unknown [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e]) (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 5154580DF7; Mon, 13 Nov 2017 14:20:32 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Lorenzo Colitti <lorenzo@google.com>
Cc: Ole Troan <otroan@employees.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> <ea772bfd-4004-7f94-8469-b50e3aff0f29@si6networks.com> <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org> <e40697ca-8017-c9d2-c25d-89087046c9cf@gmail.com> <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <CAKD1Yr26NK2osApYZBm8Yd=0X7xcetrxojp6=JHOEAu9BB0q8A@mail.gmail.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <E67105A3-396B-403C-B741-E9E01CFB5CE7@employees.org> <e7ec4633-8d45-1cff-ce37-48dafd488e13@si6networks.com> <BBAB48C0-384B-4380-9359-7965C7C61D58@employees.org> <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com> <CAKD1Yr1NG93Jv7E6hKY4BKApwJg6uG0wAgUL74cw1Fb5VsKnUg@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>
Date: Mon, 13 Nov 2017 21:20:19 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr1NG93Jv7E6hKY4BKApwJg6uG0wAgUL74cw1Fb5VsKnUg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4zo8e0gIsaifm3M3WyYfJ6t2OGQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 13 Nov 2017 13:20:38 -0000

On 11/13/2017 07:14 PM, Lorenzo Colitti wrote:
> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont <fgont@si6networks.com
> <mailto:fgont@si6networks.com>> wrote:
> 
>     >From a operational point of view, one would wonder why pursue this path
>     as opposed to e.g. do DHCPv6
> 
> 
> As for DHCPv6 specifically, one reason is that DHCPv6-only networks are
> not recommended by the IETF. RFC 7934.

Yes, sorry: I meant DHCPv6-PD.

RFC7934:

    Due to the drawbacks imposed by requiring explicit requests for
    address space (see 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.

Therefore, why re-invent PD in SLAAC?


That aside, same RFC says:
    Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide
    multiple addresses when the host connects (e.g., the approximately 30
    addresses that can fit into a single packet) would accommodate
    current clients, but it sets a limit on the number of addresses
    available to hosts when they attach and therefore limits the
    development of future applications.

I seem to recall many systems limit the number of addresses per
interface to 16. So the limit of "30 per request" aleady gives you more
than what you typically get, in practice, with SLAAC. Also... is issuing
multiple requests forbidden?

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