Re: [v6ops] Last Call: <draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt> (Unique IPv6 Prefix Per Host) to Best Current Practice

Lorenzo Colitti <lorenzo@google.com> Mon, 26 June 2017 13:37 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C95129BF0 for <v6ops@ietfa.amsl.com>; Mon, 26 Jun 2017 06:37:49 -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=unavailable 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 I6KP1-0t3_Dg for <v6ops@ietfa.amsl.com>; Mon, 26 Jun 2017 06:37:41 -0700 (PDT)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 A4D1F129BA4 for <v6ops@ietf.org>; Mon, 26 Jun 2017 06:37:35 -0700 (PDT)
Received: by mail-vk0-x22f.google.com with SMTP id r126so881019vkg.0 for <v6ops@ietf.org>; Mon, 26 Jun 2017 06:37:35 -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 :cc; bh=uMmfDXX+GQRRHsSEilXlWx3l6NC3X6IIMG192ih7+vo=; b=UTwWPFdOr2o+Kh+qfSGZSm2CDP5VdgRMI4Jm1DUC7TYGmUU7QqxMvE9EA4G4Lr/uhj x5+NJHq90eJX+DAB8xSscbzc6GW+ds7CO1PWLMFmZLDOsIZkraZ5IJbMr/BjeBedQ4Y5 cD3KCBMk5QEXHaL2trEaj9qXM2uRAHR7JhMSxu8lvTg0hr2KyXKkHJ9KDI9dGeFdyOyp 5kc9iXzjEMefBWVdLu2Z+19xlcEvHk737dBYe8FUtLBdi5FXh3OCe4J1PWGknFbauYRY AhRChCbmIjU1Yt/3UPdZo0mIXN6mKdt6leWwFsTEqIfR/LkTz1/lBFSKRQzItHcQjgaJ OCgw==
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:cc; bh=uMmfDXX+GQRRHsSEilXlWx3l6NC3X6IIMG192ih7+vo=; b=B5/tV8GpEOm/Nzr0+pyfhW/px5XRwiR+1mmcuQmQ7DSkj5Wt9dymfmnkHLQ9iui9iG M5cDKy/axVhVYf91hQjpC+WjEUvCH9rLshESapP/dVvAkn6Hh6EL5rHA4z7XJ0D28t99 uD5zcSfk7tc8LFFOP5RzN3E4nrI+Cmtglcu/nxOjfGrQGoFV0JyUQMCG8jp+l9nJKnfu s632sr8fUWvqztxmh0HgCzd0ZbM6HGypunYhMuxqtJVtwFQVm3mMKyplEK1MTdBfE4/W OuvIUwpNpBZNFel7XqSN74HqxXco/thZWOVT8UR+9jDumKPth9yJXXPOTmxqv0kFWvlJ yVRg==
X-Gm-Message-State: AKS2vOz6iD2SYMQst9AidCaFEvvOt2BuqWE7zlCcWj9UkmMB3YSeEtt7 2WaitdVv5Y6iun8eybgcc4qZ+EfVvCSk
X-Received: by 10.31.170.22 with SMTP id t22mr132429vke.100.1498484254403; Mon, 26 Jun 2017 06:37:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.167.150 with HTTP; Mon, 26 Jun 2017 06:37:13 -0700 (PDT)
In-Reply-To: <7C2A93A5-F01E-4474-AED3-D01FB9B2F34A@nokia.com>
References: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> <fa82ceef-7cd6-ab37-aee6-f386266b5c56@gmail.com> <7C2A93A5-F01E-4474-AED3-D01FB9B2F34A@nokia.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 26 Jun 2017 22:37:13 +0900
Message-ID: <CAKD1Yr34WEJrHoTLrpW6oBS7tT1TamjztK-a40oXyBkiAp+xEg@mail.gmail.com>
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" <draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org>, "v6ops-chairs@ietf.org" <v6ops-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="001a11415c3eaff5110552dd0d16"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ocYC06Lva21wlRcnWTGBfPxFBfg>
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt> (Unique IPv6 Prefix Per Host) to Best Current Practice
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jun 2017 13:37:50 -0000

Please don't cite RFC 7608. It has nothing to do with IP addressing, only
forwarding, and the topic here is host addressing.

On Mon, Jun 26, 2017 at 9:12 PM, Van De Velde, Gunter (Nokia - BE/Antwerp) <
gunter.van_de_velde@nokia.com> wrote:

> Hi Brian,
>
> Thanks for the review.
>
> I modified the reference to /64 IPv6 prefix length and suggested instead
> consistency with RFC7608 and that currently this likely means a /64 in the
> -04 version.
>
> All the best,
> G/
>
> On 26/05/2017, 22:24, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
> wrote:
>
>     Hi,
>
>     I should have noticed this during the v6ops discussions, but I didn't,
>     sorry.
>
>     This draft cites RFC4862 (SLAAC) and mentions Router Advertisements
>     (without also citing RFC4861, which is possibly a mistake). Those
>     documents do not specify the subnet prefix length. So the draft
>     shouldn't assume a particular prefix length either. We all know that
>     it's usually 64 today, but that doesn't affect the argument made by
>     the draft. We need consistency with RFC 7608 (BCP 198).
>
>     Regards
>        Brian Carpenter
>
>     On 24/05/2017 07:41, The IESG wrote:
>     >
>     > The IESG has received a request from the IPv6 Operations WG (v6ops)
>     > to consider the following document: - 'Unique IPv6 Prefix Per Host'
>     > <draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt> as Best
>     > Current Practice
>     >
>     > The IESG plans to make a decision in the next few weeks, and
>     > solicits final comments on this action. Please send substantive
>     > comments to the ietf@ietf.org mailing lists by 2017-06-06.
>     > Exceptionally, comments may be sent to iesg@ietf.org instead. In
>     > either case, please retain the beginning of the Subject line to allow
>     > automated sorting.
>     >
>     > Abstract
>     >
>     >
>     > In some IPv6 environments, the need has arisen for hosts to be able
>     > to utilize a unique IPv6 prefix, even though the link or media may
>     > be shared.  Typically hosts (subscribers) on a shared network,
>     > either wired or wireless, such as Ethernet, WiFi, etc., will acquire
>     > unique IPv6 addresses from a common IPv6 prefix that is allocated or
>     > assigned for use on a specific link.
>     >
>     > In most deployments today, IPv6 address assignment from a single
>     > IPv6 prefix on a shared network is done by either using IPv6
>     > stateless address auto-configuration (SLAAC) and/or stateful DHCPv6.
>     > While this is still viable and operates as designed, there are some
>     > large scale environments where this concept introduces significant
>     > performance challenges and implications, specifically related to
>     > IPv6 router and neighbor discovery.
>     >
>     > This document outlines an approach utilising existing IPv6 protocols
>     > to allow hosts to be assigned a unique IPv6 prefix (instead of a
>     > unique IPv6 address from a shared IPv6 prefix).  Benefits of unique
>     > IPv6 prefix over a unique IPv6 address from the service provider
>     > include improved subscriber isolation and enhanced subscriber
>     > management.
>     >
>     >
>     > The file can be obtained via
>     > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv
> 6-prefix-per-host/
>     >
>     >  IESG discussion can be tracked via
>     > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv
> 6-prefix-per-host/ballot/
>     >
>     >
>     >
>     > No IPR declarations have been submitted directly on this I-D.
>     >
>     >
>     > The document contains these normative downward references. See RFC
>     > 3967 for additional information: rfc6106: IPv6 Router Advertisement
>     > Options for DNS Configuration (Proposed Standard - IETF stream)
>     > rfc4941: Privacy Extensions for Stateless Address Autoconfiguration
>     > in IPv6 (Draft Standard - IETF stream) rfc4862: IPv6 Stateless
>     > Address Autoconfiguration (Draft Standard - IETF stream) rfc3315:
>     > Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed
>     > Standard - IETF stream)
>     >
>     >
>     >
>     > _______________________________________________ v6ops mailing list
>     > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops .
>     >
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>