Re: Updated IID length text

Bob Hinden <bob.hinden@gmail.com> Mon, 23 January 2017 22:41 UTC

Return-Path: <bob.hinden@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 E4C7E1298A1 for <ipv6@ietfa.amsl.com>; Mon, 23 Jan 2017 14:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 P_Mr2VrG5uhF for <ipv6@ietfa.amsl.com>; Mon, 23 Jan 2017 14:41:18 -0800 (PST)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 464D81299B2 for <ipv6@ietf.org>; Mon, 23 Jan 2017 14:41:08 -0800 (PST)
Received: by mail-qt0-x22d.google.com with SMTP id l7so151062879qtd.1 for <ipv6@ietf.org>; Mon, 23 Jan 2017 14:41:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H88iYfWlvQU+nJl3HJ8agG6/iJ/U89Rtjg7BmGPzI0Y=; b=dhg7j3MOFwFU4pfO+VgXn+ywoW7Rlvktb6Q//jg4kyMwi1oLdcFA+bppXfek4s8gFh ue02KXlmbbv1z/3ryd/ktCGSJBHAxb6ImvtItKNzUcLu4p4jGXa10/UjrPRUs0CDUbO3 AYHg49DzZqAdVJJqmkR6UJAEPawx6ov4YuwygBFVkK0VrwdlyoqNkuVtNp0TFWhXOsE6 8yitDWT8jZozH4+zgWE5eGHBuHVqDhDZFogt5zUeLasrEiND0fQp+lDq1y7a28Wu/PlQ 6M3/cJoGiI4cGpe4GoKXySSG4jrYgzbai9Zv3qtCIFaDXq/Mi49KAi73RX72b1wQo05c XlPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H88iYfWlvQU+nJl3HJ8agG6/iJ/U89Rtjg7BmGPzI0Y=; b=YUhC0qWqLw9kd1H5Ox1r0wnlU04FT8o9fhLyijDHUbkhUmWM3fIHg6p78UE/C9STkX muNXTAa+c//r9/qgIRyVfw2imrXiS5Zs98VSbXPkFq+F1bw+VyyFbvcVvlPv1FMcw7L1 0qG5AjiKdOmdrk100A4q+7UkkpwU+2Yt+PajYwhoUXBWlqPsCxKKXWp4VG75qa5YKQ9t LpwKoIE7Wpl4YRgQgCNbV37mI2++a2glg6LepGew1Z0lHC6lZEIKpRqQoI3it7RdU574 22j/CR+y8Pk113wRZsyN/ln57Jp9w8BsV9EbeU34yDJjDvq/QWUac4mvS13ySzNaL+nM Ka7g==
X-Gm-Message-State: AIkVDXLstZaCpB3AyImSkLR1aq0GFLLS+XMXbKv9Jiz/FHi3bJLTdaELOJ9xmcno1RKm/g==
X-Received: by 10.237.50.229 with SMTP id z92mr25181607qtd.182.1485211267400; Mon, 23 Jan 2017 14:41:07 -0800 (PST)
Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id h56sm14272704qte.24.2017.01.23.14.41.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 14:41:06 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Updated IID length text
From: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <5a804889-9c28-3787-a7d8-4f6bd9661c15@gmail.com>
Date: Mon, 23 Jan 2017 14:41:04 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <1070FE68-62A2-4655-B66A-F0F74D58876C@gmail.com>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <m2lguffnco.wl-randy@psg.com> <CAKD1Yr1TrTiPRdyutobmb_77XJ7guNzLrg=H_p7qi4BfQ8V=GA@mail.gmail.com> <m2d1frfm6m.wl-randy@psg.com> <CAKD1Yr2Njjd8_Mr+6TRFF6C5pdcX4yFgpFVyEkykDuytu2B8mg@mail.gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <CAN-Dau06R3iYRpYLADhvHox4C9qdsJCuxFsJapRhOQcWT4qk_g@mail.gmail.com> <CAO42Z2weZcoHiBzN94QAQ9WGhWR16PmMMFNg=5YLmr_dhPjjpA@mail.gmail.com> <fcc7f136-b5da-527e-b495-5a2d7f7a3ce8@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <bb79ce41f2cc465dab0a7f26466be26f@XCH15-06-11.nw.nos.boeing.com> <ed9fe2df-0dce-0ddc-bdee-561217d089bb@gmail.com> <e8b4d426-55b4-bd2e-ea4f-f8e56e831d44@gmail.com> <CAKD1Yr1no52iZ2NwfKse6tXi0QpOP+Qe-vU68M4g1ZhmsgQadg@mail.gmail.com> <c2776d7a-0656-a30d-88a1-bd2b11b08035@gmail.com> <32A2D0A3-0FA4-40E8-B563-D1F90504E916@gmail.com> <5a804889-9c28-3787-a7d8-4f6bd9661c15@gmail.com>
To: Brian Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/404kuGInBQoahi0iprAwT13L3Sk>
Cc: IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
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: Mon, 23 Jan 2017 22:41:20 -0000

Brian,

I will work on some new text, but won’t submit anything till after I get a go ahead from Suresh.  Like the other changes from Brian Haberman’s review.

Bob

> On Jan 20, 2017, at 6:16 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> Bob,
> 
> Yes, I take your point. Maybe we can all close this thread now and you
> can decide what to put in the next draft.
> 
> Regards
>   Brian
> 
> On 21/01/2017 12:53, Bob Hinden wrote:
>> Brian,
>> 
>>> On Jan 19, 2017, at 10:11 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>> 
>>> On 20/01/2017 17:38, Lorenzo Colitti wrote:
>>>> On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter <
>>>> brian.e.carpenter@gmail.com> wrote:
>>>> 
>>>>> However, correct use of Stateless Address Autoconfiguration
>>>>>  (SLAAC)[RFC4862] requires all interfaces on a link to use the same
>>>>> length
>>>>>  of Interface ID. Furthermore, to guarantee robust interoperability of
>>>>> SLAAC,
>>>>>  a consistent length of Interface ID is desirable. For this reason,
>>>> 
>>>> 
>>>> I object to the text "for this reason", because SLAAC is not the only
>>>> reason. There are many reasons, many of which are written in 7421, and two
>>>> sentences in this paragraph are not sufficient to describe them. I propose
>>>> the following alternative, which I believe to be normatively identical:
>>>> 
>>>>  IPv6 routing is based on prefixes of any valid length up to 128 [BCP198].
>>>>  For example, [RFC6164] standardises 127 bit prefixes on point-to-point
>>>>  links. However, the Interface ID of all currently allocated unicast addresses,
>>>>  except those that start with the binary value 000, is required to be 64 bits
>>>>  long. The rationale for the 64 bit boundary in IPv6 addresses can be found in
>>>>  [RFC7421].
>>> 
>>> Yes, I'll buy 'however’.
>> 
>> I am generally OK with the text above, but wanted to point out that Section 2.4. "Unicast Addresses” there is more than one place where 64 IIDs are mentioned.  This discusion has been about the forth paragraph in 2.4.1. "Interface Identifiers”.  It is also mentioned in the second paragraph of 2.4.4. "Global Unicast Addresses”.  I assume this would have to be modified if the w.g. decides to adopt this text.
>> 
>> As Ole pointed out there is text that discusses future changes:
>> 
>> 2.3.  Address Type Identification
>>   Future specifications may redefine one or more sub-ranges of the
>>   Global Unicast space for other purposes, but unless and until that
>>   happens, implementations must treat all addresses that do not start
>>   with any of the above-listed prefixes as Global Unicast addresses.
>> 
>> 2.4.  Unicast Addresses
>>   There are several types of unicast addresses in IPv6, in particular,
>>   Global Unicast, Local unicast, and Link-Local unicast.  There are
>>   also some special-purpose subtypes of Global Unicast, such as IPv6
>>   addresses with embedded IPv4 addresses.  Additional address types or
>>   subtypes can be defined in the future.
>> 
>> I think that this makes it clear that things are allowed to change in the future.  I don’t think we have to capture this in the single paragraph in 2.4.1, and there could be other kind of changes as well.
>> 
>> Thanks,
>> Bob
>> 
>> 
>> 
>> 
>> 
>> 
>