Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt

Lorenzo Colitti <lorenzo@google.com> Sun, 16 July 2017 09:32 UTC

Return-Path: <lorenzo@google.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 69DB5131761 for <ipv6@ietfa.amsl.com>; Sun, 16 Jul 2017 02:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 vXeV3nv896iZ for <ipv6@ietfa.amsl.com>; Sun, 16 Jul 2017 02:32:04 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 0005F127058 for <ipv6@ietf.org>; Sun, 16 Jul 2017 02:32:03 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id r126so64430827vkg.0 for <ipv6@ietf.org>; Sun, 16 Jul 2017 02:32:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zJhtFMegWNAols9/C/nkT1OYQgbY5LqXzIrHQnmJuaI=; b=nhLRqaMfFLZVZSV0Nu6hoQ2d6Stwr/HPyJAxv0tsfvfl/pZ2yYi47NUbnVqxsnebix dQ9qeMfPrmbfAJZL80HqDI12WtN0r0agKOAuZj9wRXCJ+MTL9Ek75ubbjxFXwV/NM4a5 p5r2C8Tf/OffDYi+q74CJkrZr5HPIGS5TRRuk24CRcSKKHUKBHWpn7wrQoGzG+2lDlWu GgbWC84hR52Dz+9q+GldHqo8QYhPVEuy/0Unwe7dp0ejdTPXWw6PAYIiI9BTgvRXJfc1 T8XrUZ7ER9ppKJVtnyutn/KmEyDEqhy6iL4viNPKsYzjNlZFhhQMXzBPOptzzaZu2AWo 03OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zJhtFMegWNAols9/C/nkT1OYQgbY5LqXzIrHQnmJuaI=; b=CtvUF3hhNnnj4ONXCXfpL87dCpu4iusKnCo4Qms9pFAHmop9GQ0Th2UgnIpyVVd+wi 0T4xVG23URfMiS59ivlBwS4GK6gD+fImr29eDP6xKAVgnD17UBBqlclnjZAuAVRFvnDx 9Mr2cxHrABhBdYQLb7Fp5bIFSzCkbv8KQxfxn37yf6PawY7d6hnvhRCiwGKMba9Mx4HJ 3Vgr1ciMmG/nnJYkE/nWo2GXtJ6VxgQ75Muvdylmqkla/xRaJah1zCZ3uNwaUbO/H9Ec AkW5OBkOcJ3d/hDIZ+lnlYOtdtIBnoYShsIyJUaOiRRnMnwsR9fa6IYXAuFL/M7UGBaM j0GQ==
X-Gm-Message-State: AIVw1127zGy0HXD4GXTS+oZK1LNuxIrWNpXtGgBlEq1ynRtKBPDMOcdE Ant3eEfi1uPvf+g+8gQ5xXecTG2yEJ3oMMY=
X-Received: by 10.31.209.199 with SMTP id i190mr9656881vkg.125.1500197522578; Sun, 16 Jul 2017 02:32:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.48.129 with HTTP; Sun, 16 Jul 2017 02:31:41 -0700 (PDT)
In-Reply-To: <149909644776.22718.16227939850699261560@ietfa.amsl.com>
References: <149909644776.22718.16227939850699261560@ietfa.amsl.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Sun, 16 Jul 2017 11:31:41 +0200
Message-ID: <CAKD1Yr25jk22qTTqJ-RoxOVTu7=e=vQWWLQZnek-HGCKaZgU=w@mail.gmail.com>
Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt
To: IETF IPv6 Mailing List <ipv6@ietf.org>, draft-ietf-6man-rfc6434-bis@tools.ietf.org
Content-Type: multipart/alternative; boundary="001a114e6e186da68b05546bf486"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/DiHiDKcGNe7ln7lq7mvXXM_qKUU>
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: Sun, 16 Jul 2017 09:32:05 -0000

On Mon, Jul 3, 2017 at 5:40 PM, <internet-drafts@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 Maintenance of the IETF.
>
>         Title           : IPv6 Node Requirements
>         Authors         : Tim Chown
>                           John Loughney
>                           Timothy Winters
>         Filename        : draft-ietf-6man-rfc6434-bis-01.txt
>

I see that the document still says:

   There will be a wide
   range of IPv6 deployment models and differences in address assignment
   requirements, some of which may require DHCPv6 for stateful address
   assignment.  Consequently, all hosts SHOULD implement address
   configuration via DHCPv6.

We should abandon this documentation, for two reasons.

First, networks that require DHCPv6 assignment are explicitly NOT
RECOMMENDED by current IETF best practices. Specifically, RFC 7934 section
8 says "it is RECOMMENDED that the network give the host the ability to use
new addresses without requiring explicit requests". A DHCPv6-only network
cannot meet this recommendation, because on a DHCPv6-only network, all
addresses acquisition requires an explicit request to the network.

Second, the draft says "Where devices are likely to be carried by users and
attached to multiple visisted networks, DHCPv6 client anonymity profiles
SHOULD be supported as described in [RFC7844]".

But RFC 7844 says that hosts SHOULD prefer stateless address configuration
over DHCPv6: "hosts using the anonymity profile SHOULD use stateless
address configuration instead of stateful address configuration".

So for such devices, there is a direct conflict: this document says they
SHOULD do DHCPv6, but RFC 7844 says they SHOULD not if other addressing
modes are available.

I would propose the following text for section 6.5:

   [...] There will be a wide
   range of IPv6 deployment models and differences in address assignment
   requirements, some of which may use DHCPv6 for stateful address
   assignment in addition to other addressing modes. Using DHCPv6 as the
   only IPv6 address configuration mechanism is NOT RECOMMENDED
   [RFC 7934 section 8].

   In the absence of a router, IPv6 nodes using DHCP for address
   assignment MAY initiate DHCP to obtain IPv6 addresses and other
   configuration information, as described in Section 5.5.2 of
   [RFC4862].

   Where devices are likely to be carried by users and attached to
   multiple visisted networks, DHCPv6 client anonymity profiles SHOULD
   be supported as described in [RFC7844] to minimise the discolosure of
   identifying information. This profile recommends that the device prefer
   stateless address configuration over DHCPv6 address configuration.

   Devices that do not have particular anonymity requirements SHOULD
   implement address configuration via DHCPv6 in order to be able to
   take advantage of IPv6 addresses available only via DHCPv6.