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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 26 June 2017 20:52 UTC

Return-Path: <brian.e.carpenter@gmail.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 41C5112EB67; Mon, 26 Jun 2017 13:52:26 -0700 (PDT)
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 Ghsr3G_akiiQ; Mon, 26 Jun 2017 13:52:23 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 DB60912EB73; Mon, 26 Jun 2017 13:52:23 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id u62so5422842pgb.3; Mon, 26 Jun 2017 13:52:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cFv15AefSQef1cHUPzQVWCl7whrhKwIyXgaUawiMxPE=; b=ieGZ+RxKPXg55BW7AU9ambu6KMntRiLqwAR0EFw/L/nKvORShMU1Cj0d0WV5SEGQzX oTFvsZTTAxnmsyZ8AtGU/eLS24DfiCwaAKDoGAzXn4TeOjeUDU8uG05P9UiaFGLKKwvR Tiu2IdNlyl4CwmEhlsSixD3IXeX6fJfl3V+ZhwYUDNBZRObFFugLaPLe82JAsk2/NKw1 pdK8lIsdehqlpWy1qoAROFp7JPTb3NrjEIiWitlDJzRCxobXPT7SW84fodZeSGDxo54v E+KzCzNm47kzQryEk3ihuscGrVuULcV73lib3MRQxjXvfiLDtXCwUFfMg8R8D8h5s9io wfHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cFv15AefSQef1cHUPzQVWCl7whrhKwIyXgaUawiMxPE=; b=qU14JRyeJ+qLqtu1dZNcZEhZamF7CGGYvvh9cGz65eI5Qke8Gn2dsm6BIv4+ZUZTs/ 07G2ApssG1ipCX9OKFHLhzH67CdhFmPheWWSXNENVB8fPFfUpQSGJebCQh8gGoEKBHp6 kXBgB8oApMzGtrlLTqCsU/AIV4XIQ80pWucYiNigHqQbjQdFxkdz5r9tIfvWalaHxB00 FFjAwpKDDxvsJXY+CNzmO+d9tqvnMD+aRVwdugPSFNKPaKEpJlPappV3bGv+ls3URA5b OepadbNtkrh3f5PFKliUxVDsd0e9MxW8HL4h2G0/4/Vf9LdrxZDPEitmvvDmAf7cYZV8 aaZA==
X-Gm-Message-State: AKS2vOysuealy6PgBlRkvzPcTOm9WJTk037cN0yT60BAKEU806Ieiw2s ez3fR8Ox4o/A38hL
X-Received: by 10.84.129.111 with SMTP id 102mr2085781plb.221.1498510343294; Mon, 26 Jun 2017 13:52:23 -0700 (PDT)
Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id 66sm1641797pgh.59.2017.06.26.13.52.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 13:52:22 -0700 (PDT)
To: Lorenzo Colitti <lorenzo@google.com>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
Cc: "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>
References: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> <fa82ceef-7cd6-ab37-aee6-f386266b5c56@gmail.com> <7C2A93A5-F01E-4474-AED3-D01FB9B2F34A@nokia.com> <CAKD1Yr34WEJrHoTLrpW6oBS7tT1TamjztK-a40oXyBkiAp+xEg@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <6c7cf450-d48e-94f4-f705-e24e83d52a44@gmail.com>
Date: Tue, 27 Jun 2017 08:52:22 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr34WEJrHoTLrpW6oBS7tT1TamjztK-a40oXyBkiAp+xEg@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/v6ops/Ic6garB_ysint33puhTMrP37d2M>
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 20:52:26 -0000

On 27/06/2017 01:37, Lorenzo Colitti wrote:
> Please don't cite RFC 7608. It has nothing to do with IP addressing, only
> forwarding, and the topic here is host addressing.

True. I agree that simply stating that it's currently /64 is appropriate.
The point is that /64 isn't an essential property of this solution; it's
an externally determined parameter.

   Brian

> 
> 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
>>
>