Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

Xing Li <xing@cernet.edu.cn> Sun, 26 February 2017 00:14 UTC

Return-Path: <xing@cernet.edu.cn>
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 40AE1129541; Sat, 25 Feb 2017 16:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 5oy4uL6PEg4Z; Sat, 25 Feb 2017 16:14:50 -0800 (PST)
Received: from tsinghua.edu.cn (smtp36.tsinghua.edu.cn [166.111.204.60]) by ietfa.amsl.com (Postfix) with ESMTP id DB0BE129488; Sat, 25 Feb 2017 16:14:49 -0800 (PST)
Received: from [192.168.1.100] (unknown [114.254.44.112]) by app3 (Coremail) with SMTP id DMxvpgCXn4fdHbJYIgLqAQ--.5942S2; Sun, 26 Feb 2017 08:14:21 +0800 (CST)
Message-ID: <58B21DDD.7070201@cernet.edu.cn>
Date: Sun, 26 Feb 2017 08:14:21 +0800
From: Xing Li <xing@cernet.edu.cn>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Pierre Pfister <pierre.pfister@darou.fr>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
References: <148599306190.18700.14784486605754128729.idtracker@ietfa.amsl.com> <CAN-Dau0kDiSNXsyq9-xEdS5mzLt-K+MYHqoV8aC8jDVREw8OPQ@mail.gmail.com> <8e5c950a-0957-4323-670f-f3d07f40b4df@gmail.com> <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <m2y3x6eutl.wl-randy@psg.com> <B76B6864-5827-4AC1-9BF7-8FFF069C10F1@employees.org> <m2lgt6ed7j.wl-randy@psg.com> <4514E052-25C1-4C85-AB1D-0B53FD9DA0E1@employees.org> <CAN-Dau3VriYNUf96yZEFMMV+-4WCxBz94Lkqfg3OsCUAbVYhaw@mail.gmail.com> <660929B4-158B-453F-9B5F-6C029F9699FA@employees.org> <E093E86F-41F5-4485-A8D3-761831F9AAF8@google.com> <ECF27195-4A6B-4AFC-8950-83876F333BD4@employees.org> <A1F60D51-C39E-45DC-B3D5-960D92C186E4@darou.fr>
In-Reply-To: <A1F60D51-C39E-45DC-B3D5-960D92C186E4@darou.fr>
Content-Type: multipart/alternative; boundary="------------010505070608010702010302"
X-CM-TRANSID: DMxvpgCXn4fdHbJYIgLqAQ--.5942S2
X-Coremail-Antispam: 1UD129KBjvJXoW7Ww13tFW5AF1xXF47urWUXFb_yoW8Zw48pa 13tr47ZF4DJF18Ars7G3y8ur15A3ykGw45W3Wrtry8Jr1qkF18Gr1qkr18ZayxJr97JF17 XrW8KryfGF1kZ3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqGb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr0_Gr 1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAqjxCE14ACF2xKxwAv7VC0I7IYx2IY 67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y4 8IcVAKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCF04k20xvY0x0EwIxGrwC20s026c02F40E 14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIx kGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAF wI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r 1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x0UUj RaDUUUUU=
X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-TZPm-jotTFYMAtVO9fhe500Ifg>
Cc: james woodyatt <jhw@google.com>, 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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, 26 Feb 2017 00:14:52 -0000

Pierre Pfister ??:
> Hello all,
>
>   
>> Proposal:
>>  IPv6 unicast routing is based on prefixes of any valid length up to
>> 128 bits [BCP198]. However, as explained in [RFC7421], the Interface ID
>>  of unicast addresses is generally required to be 64 bits in length, with
>>  exceptions only provided in special cases where expressly recognised
>>  in IETF standards track documents.
>>
>>     
>
> The only place in IPv6 standards where the 64 boundary is mandated is on the 2000::/3 rule.
> There is not a single implementation or deployment of that rule. There is no instance where 
> trying to configure a prefix of length different than 64 will work when the prefix is within 2000::/3, and fail when it is not.
> That is a sufficient reason to not include this rule as part of the standard track.
>
> Nevertheless, SLAAC over Ethernet links indeed requires prefix length of 64.
> As documented in the RFC7421, there are a few examples of protocols which require 64 bits long interface identifiers.
>
> SLAAC is not the only way to configure IPv6 hosts though.
> Manual configuration, automated configuration, and DHCP are all IETF approved ways of configuring IPv6 hosts. 
> They all work with prefixes of various lengths. 
> Does 'special cases' in the proposed text covers manual/automated configuration or DHCP ? If so, it is far from being clear.
>
> You obviously should use /64s if you want SLAAC to work, as well as other protocols which are documented in RFC7421,
> but /64 is not the rule, it is an architectural consideration that you have to take into account when you design your network depending on the protocols that you want to run there.
>
> Therefore, as far as this discussion is concerned, there is no reason to mandate 64 bits boundaries as part of the IPv6 specification.
>   

+1, xing

> - Pierre
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>