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

Fred Baker <fredbaker.ietf@gmail.com> Tue, 14 November 2017 00:43 UTC

Return-Path: <fredbaker.ietf@gmail.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 0D00B126CD8; Mon, 13 Nov 2017 16:43:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3hhNReDQ46yv; Mon, 13 Nov 2017 16:43:02 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D192126CD6; Mon, 13 Nov 2017 16:43:02 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id m88so5852509pfi.9; Mon, 13 Nov 2017 16:43:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EOHHCOUcx4xOJzYAc5sPkJh10EUC8BEwyZ7ohidb9r8=; b=dAE4Kyg8oP6qhWLvrm0JShoJfctvvOE1S2SFmP7UmRmy7Ppfs5YmhJfjxBltoV1YNj qjKwwDTD7Qo+2kLgyjMr7jjJyMO4MmsAOGT4WrvyI/jHalRbBF3aKMq9t13V1mFHfoHM k1jo2KU2/Fs+52/YJ1GC00OZPEJk2kXXkCpYIH5DaKy/PbGU94BToNGEpl9S3MjuObSW ie2G9VBYOKJPsa8CFmnmfCgVlYY7uKU0yGheAMhC68JXVQ3mwtszQ2JaMcYHcKvpIvUX yhQVOKaNSuk8TPhopCCsuWIpqxfuWkeriauQgtoPM0VCkGoHHzO5yACAXDYIjeAiSIn/ TdFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EOHHCOUcx4xOJzYAc5sPkJh10EUC8BEwyZ7ohidb9r8=; b=aunHylVQ+m+XM7PVmEIO8Bw1JpmZ51elQV3J3yB7Cb2XAEfo0d+dsHWCvCafXLgpkH BH4Voot7ri5ak1AJhqToapb6F04TbZinqXzAbzie5xYNHC1cbEeOuMawfYKpVXlCHFDv p7z91E6aRTUuSx1W7htVM+mH/WLsXlrMJYf7pxAf3Pdf5b/X4Eziwht020eti7x94dmO mzS/IL7Zs8qIn7JZaCtgUR/tEgvbgJmee0xBf1KSRo0DOxGBts1cUSgGenDIIfVl9eHL QnQ+XpIeEQ6JSD5bnXXzZxPruEkC4hSaA49MsjeMtIGtWSyzVui9WPu3wbOhc522Uadw +Gdw==
X-Gm-Message-State: AJaThX7HMdNi+NJJcFntzYpvMPmJvaLgRObVsjH5tLGRWjrCfIK5mZjT UQjcK+PEtLd4eN2eOTrOgrI=
X-Google-Smtp-Source: AGs4zMbC3YEiai81coMg5Vd/FFj8d6dC2fR1wEo02Q1hHYf0NjpeOlDkT2+/i9pIx71sTtiYtawEZA==
X-Received: by 10.84.133.15 with SMTP id 15mr9127548plf.367.1510620182157; Mon, 13 Nov 2017 16:43:02 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:b445:d6af:36e2:368f? ([2001:67c:370:1998:b445:d6af:36e2:368f]) by smtp.gmail.com with ESMTPSA id 70sm33034457pfv.97.2017.11.13.16.42.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 16:43:00 -0800 (PST)
From: Fred Baker <fredbaker.ietf@gmail.com>
Message-Id: <D495DABC-3513-488A-96A4-4CFE38F3712D@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_2902D3CE-E479-4FEE-B231-1977C971672B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.11\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Tue, 14 Nov 2017 08:43:03 +0800
In-Reply-To: <5A0999A4.3040807@foobar.org>
Cc: Fernando Gont <fgont@si6networks.com>, "v6ops@ietf.org WG" <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
To: Nick Hilliard <nick@foobar.org>, Lorenzo Colitti <lorenzo@google.com>
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> <5A0999A4.3040807@foobar.org>
X-Mailer: Apple Mail (2.3445.5.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QuA29tyW-bF_9fMCKRVTmKs24qM>
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: Tue, 14 Nov 2017 00:43:09 -0000

Chair hat off.

> On Nov 13, 2017, at 9:09 PM, Nick Hilliard <nick@foobar.org> 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.
> 
> reminder: there is no WG consensus that this is what RFC 7934 means.

I just went back to read it. Having an argument with the author of a document about what it means is an interesting tactic.

There are 26 references to DHCP(v6) in the document. The vast majority of them are factual - "it does this, and there are networks that use it".

The two references I found that are negative statements about DHCP are about IA_NA. Section 8, second and third paragraphs, reads

   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.

   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 think it is absolutely fair to say that the RFC doesn't recommend (recommends against) the mechanism that IA_NA uses. That said, the laptop I'm typing on (a Mac) generally keeps 2-3 addresses per interface and has several interfaces. 30 is a viable number for it. I can also report that I have worked in an environment that only uses DHCPv6, and it worked just fine for any purpose I put it to.