Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 17 January 2017 03:39 UTC

Return-Path: <brian.e.carpenter@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 8DC7E1298D5 for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 19:39:37 -0800 (PST)
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 QeowJeAqFBdd for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 19:39:36 -0800 (PST)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 E7F54129466 for <ipv6@ietf.org>; Mon, 16 Jan 2017 19:39:35 -0800 (PST)
Received: by mail-pg0-x231.google.com with SMTP id t6so15456837pgt.3 for <ipv6@ietf.org>; Mon, 16 Jan 2017 19:39:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZkQTQqP12d6L5QOLrv2+Uyb3tAQ+ScG6S+HJP6rYA6I=; b=B2fdbaKATVGR9BX+pwXoSFF7qfQs7ntuWRQDTAPBXXl39lJ0Icgqvmh9kVYw+hjF4W zOXCu7/wrrV1qJ812utI81hU/bP9j7mDDjmxYTfg1Yq8W2eLb2szCTk7qFbBrNuasK6k sZq956O21DazxoUlXcTDVdhJsPaJLIy2D1LwUHjIhgO6Elo2oGx3W5tajrGSiBAzoCKY 2U5rV7mX+b4Z+HQo1W3N2njPfYgirhyqKnLaAVYP1CY3AS9KfuOXrTdiOHfI5A/INElB Cr3viq0RvjYf5WjNkzavztowGx9DRC6tthKf2n8cAVIBHXe19GN/ReiUGKXv3H2zxvoC KKoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ZkQTQqP12d6L5QOLrv2+Uyb3tAQ+ScG6S+HJP6rYA6I=; b=F9eNq+tzj/lKcFXqi//LtyB/wa0dX5+dh/ZSOJvx7h/TdSb0YSCbFxowrZCCrLjD9j EbZwakrIaYGasfeU0QJKN5/SrES8HzpqM/MMZBWLgt7gm0wlOiCXQ38voUKChvrYqVcE btnZH5yOlCQhUjNIdLTN1pS6dq2tkzZ5PF48aNp2AiwwJS0vsKVv7fgxvHywUcxkPOB0 vhLHg9N+Ue7eDZlWlchXzgvb4+NaixF+y2ktbLQE9ROnSzjumD8PynqbaGQulMhzNMBS f7K9zfnEHPrk7hnw6/t0AUTDzev52j3bWYkM9Ox5koP9GzS48UsngbDXK64vwckmnb4x Sa0g==
X-Gm-Message-State: AIkVDXJaJ+4oyzimg20dqc8spPeM1+fqmRJnqbotQ2vRIrtqphazEVyNusqTdWQp0AueDw==
X-Received: by 10.99.54.79 with SMTP id d76mr43173963pga.91.1484624375313; Mon, 16 Jan 2017 19:39:35 -0800 (PST)
Received: from ?IPv6:2406:e007:4961:1:28cc:dc4c:9703:6781? ([2406:e007:4961:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w2sm8298167pfi.65.2017.01.16.19.39.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 19:39:34 -0800 (PST)
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
To: Erik Kline <ek@google.com>, Lorenzo Colitti <lorenzo@google.com>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <CAKD1Yr1cvZ8Y3+bHeML=Xwqr+YgDspZGnZi=jqQj4qe2kMc4zw@mail.gmail.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> <fcf580ec-3617-ca5f-5337-37acb6e928ba@gmail.com> <CAKD1Yr25zNeQGvNJa=WzCjKMd9LaYrSwG=o4tUWn1Zc2ASZjrA@mail.gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <CAKD1Yr3wyza0_enWErMhmKKkA1ZOXPv5GG8dMT8HUQZsB5--UQ@mail.gmail.com> <CAAedzxppi5g_S05-m+B2jKMYePapPM0_wMA4XioYgwipwbKVHQ@mail.gmail.com> <CAAedzxoY6MGyvzDvUcZ44ka=5RcGwQ16fzRp29445Pa7mQYNHA@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <f6c9288c-4f67-6b4a-3e56-ae2861f2d120@gmail.com>
Date: Tue, 17 Jan 2017 16:39:32 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <CAAedzxoY6MGyvzDvUcZ44ka=5RcGwQ16fzRp29445Pa7mQYNHA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/A1yom_QpXC20pNevhORFA0VF10s>
Cc: 6man <ipv6@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: Tue, 17 Jan 2017 03:39:37 -0000

Erik,

On 17/01/2017 15:36, Erik Kline wrote:
> On 17 January 2017 at 11:18, Erik Kline <ek@google.com> wrote:
>> On 17 January 2017 at 10:08, Lorenzo Colitti <lorenzo@google.com> wrote:
>>> On Tue, Jan 17, 2017 at 4:57 AM, Brian E Carpenter
>>> <brian.e.carpenter@gmail.com> wrote:
>>>>
>>>>> what's the specific rationale for this change? Is it a bug in 4291 which
>>>>> you're proposing that we resolve in 4291 bis? If so, what is the bug?
>>>>
>>>> The bug is that in SLAAC, the IID length is a parameter, not a constant,
>>>> and that in routing protocols, the prefix length is a parameter, not
>>>> a constant. The addressing architecture needs to recognise that.
>>>
>>>
>>> There is no bug here.
>>>
>>> What that text in 4291 says is that if you run SLAAC on a Global Unicast
>>> address not starting with ::/3, then the length of the IID is 64. But when
>>> running SLAAC on non-Global Unicast addresses, or Global Unicast addresses
>>> in ::/3, then the length of the IID is not specified in RFC 4291 (and
>>> presumably left up to the IPv6-over-foo documents).
>>>
>>> That is why, for example, RFC 2464 has to say that on Ethernet, the
>>> link-local address "is formed by appending the Interface Identifier [...] to
>>> the prefix FE80::/64". It also says that the IID length is always 64 bits
>>> and SLAAC prefixes must be /64. If IPv6 all addresses were classful and the
>>> IID length were always 64 bits there would be no need to say that.
>>>
>>> Also, I'd argue that SLAAC exists to generate IPv6 addresses that conform to
>>> the addressing architecture, not the other way around. But that is not in
>>> any way necessary to resolve a conflict between the two documents, because
>>> there is no conflict.
>>>
>>>>> BTW: if the reason for the text is a perceived contradiction between the
>>>>> fact that "IIDs are 64 bits" and "IPv6 addresses are aggregatable on all
>>>>> bit lengths" - I don't see a contradiction.
>>>>
>>>> I suggest discussing that with Randy Bush.
>>>
>>>
>>> While Randy's "I want to use smaller subnets than /64 because classful
>>> addressing is stupid" is a valid position, that does not mean that there is
>>> a contradiction between the two specifications.
>>>
>>> So again - what is the text trying to accomplish? I don't see a bug in the
>>> specs. Therefore, it seems to me that the proposed text is changing the IPv6
>>> architecture in a pretty fundamental way, and I don't think it's reasonable
>>> to do that at the same time that we elevate it to full standard.
>>
>> I would tend to agree.
> 
> Actually, I think the NEW text is pretty reasonable if we could
> restore the word "required" for the currently allocated unicast status
> quo:
> 
> From:
> 
>    ... For all currently
>    allocated unicast addresses, except those that start with the binary
>    value 000, that length is 64 bits.
> 
> To:
> 
>    ...  For all currently
>    allocated unicast addresses, except those that start with the binary
>    value 000, that length is required to be 64 bits.

I could live with that. The "currently allocated" is the point.

    Brian

> 
> We can always produce a document that updates 4291bis for 4::/3 or
> whatever we want, and the new text states so explicitly.
> 
> But I'm not convinced we should change to text that could be read to
> weaken the current situation.
>