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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 21 February 2017 23:24 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 7611D1293DB; Tue, 21 Feb 2017 15:24:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 yVS3q6VQ5g1D; Tue, 21 Feb 2017 15:23:59 -0800 (PST)
Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 36490126D73; Tue, 21 Feb 2017 15:23:59 -0800 (PST)
Received: by mail-pg0-x243.google.com with SMTP id 5so20453931pgj.0; Tue, 21 Feb 2017 15:23:59 -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=xx9Z2zRGlsJCdszOpYV7sNZIUZ6y5TYLSlhUNs/HNcE=; b=VwI51e1W3ibf2PoDEYI0uXsmu1KcTYSv8STNz7nSTUAlzVIEnU6Xp3hgebgkX30v52 HNhtzXrrWb3nuvxhSPu5PQdyzFUWd326oq2KNtsCkH0qZuPboB+MsZkf/H34eGqOFRtY ANA96aEhIZKumpp/BT7PtVOgw7UGbeYflk9kSlwys/TseSlvZmu9jXpfEaykuzh9Scwt 5YyyIYMZPbK8HFwXq7CKbcfVZqFCGsywwk4TwCMzkN/ZiY8XCVoNagYWc1hCbhvqt4sy KxlO21zdGtWNLF6asBQkHrJO9LRruBsXaTf++DhNz9+ENMI5j6mVBj+BfRJMZSUmIKpb Q6hw==
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=xx9Z2zRGlsJCdszOpYV7sNZIUZ6y5TYLSlhUNs/HNcE=; b=XHm0uvw4V8I4kug+C7ZdOPy5mw1Y2L1FFXvu2xcE82/qyJVqC943hunWUCghFxtnH1 OjcbCH32aUQn5N//ozjSGma1ko+oHgFrbLF2LxwoA9PwK5d16YQyaa0e7bfR2ttrouif 2X7ut6fMCaJkda4mkg4vkJChVt1y/2p/xLS3EmrBSM6WxDlTSL8XOB5a8qcWP7hiHY8N LsQmzdLR5xzpSpxAD19LfI6GrkWRLS/5zld15QNqk8EX3vGWPLsto/0MlhWi92G7g1VT cgVLzz38NcUOhbh9nXxmAxpz58+iQ9MLdqZSo3YfTBPYx/nH0fHU8Cr+uT3ld9hjGzWI 49mg==
X-Gm-Message-State: AMke39n/3Ci8xhOLrRk51u2RmVHuQqKExgS4CC5FOn3MtnM+d0q+LJwicOKEmLMR/Zt/pg==
X-Received: by 10.98.223.214 with SMTP id d83mr1856868pfl.147.1487719438560; Tue, 21 Feb 2017 15:23:58 -0800 (PST)
Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id 128sm21148593pfe.23.2017.02.21.15.23.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 15:23:57 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Job Snijders <job@ntt.net>
References: <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <75196cfa-5476-0c7b-7612-ea2e446fc6f1@gmail.com> <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org> <m2wpcqeuot.wl-randy@psg.com> <44F7BEDA-CF11-4E1E-BA6F-88794DEC1AF7@employees.org> <20170221001940.GB84656@Vurt.local> <068ce975-8b1e-a7c5-abba-2bfc1d904d70@gmail.com> <20170221101339.GC84656@Vurt.local> <047994c3-9cce-12ce-55bb-bf3ae3369b57@gmail.com> <20170221225857.GE32367@Vurt.local>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <f84828c0-7d37-6c56-b1a6-6260227b4f44@gmail.com>
Date: Wed, 22 Feb 2017 12:23:17 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20170221225857.GE32367@Vurt.local>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/cqEKEUcJ1zfGB8gycbdsw1SwC0g>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, IETF-Discussion Discussion <ietf@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: Tue, 21 Feb 2017 23:24:00 -0000

On 22/02/2017 11:58, Job Snijders wrote:
> On Wed, Feb 22, 2017 at 11:44:42AM +1300, Brian E Carpenter wrote:
>> On 21/02/2017 23:13, Job Snijders wrote:
>>> On Tue, Feb 21, 2017 at 02:11:15PM +1300, Brian E Carpenter wrote:
>>>> On 21/02/2017 13:19, Job Snijders wrote:
>>>>> On Thu, Feb 16, 2017 at 09:40:01AM +0100, otroan@employees.org wrote:
>>>>>> There are many reasons for the 64 bit boundary.
>>>>>> - Allowing identifier locator split: 8+8 / GSE that led to ILNP and NPT66
>>>>>
>>>>> Irrelevant.
>>>>
>>>> Not really. They are both running code. You may not want them in
>>>> *your* network but that isn't the point. Some people want them.
>>>>
>>>> And there is a lot of other running code too, not just SLAAC which is
>>>> mandatory to implement in every IPv6 host. So this actually trumps all
>>>> the other arguments: it's 64 bits because it's 64 bits.
>>>
>>> When someone utters the phrase "it is X because it is X", the rhetorical
>>> imperative seems to be to dismiss further conversation (perhaps any
>>> internal dialogue as well, which may be the primary purpose). "It is
>>> what it is" therefore, there’s nothing more to be said about it...
>>>
>>> Except when it's not 64 bits?
>>
>> That wasn't quite my intention. I just wanted to underline that
>> (like it or not) it was set at 64 bits many years ago and a lot
>> has been built on that.
>>
>> ...
>>> I've looked at all configured IPv6 addresses on AS 2914 equipment.
>>> Interestingly enough, the below table is a reflection of not only NTT's
>>> own addressing, and (since AS2914's core function is to connect networks
>>> to each other) also of its peers and customers. In the end, whatever
>>> makes the thing work is the thing that will be configured.
>>>
>>> 	/127 - 22%
>>> 	/126 - 52%
>>> 	/125 - 0,9%
>>> 	/124 - 0,5%
>>> 	/120 - 0,04%
>>> 	/112 - 0,02%
>>> 	/64  - 23%
>>
>> Thanks, that's interesting. So 23% of the devices might have 
>> RFC4291-compliant IIDs. The others are configured with 128 bit
>> IPv6 addresses. Is that correct?
> 
> The percentage is not the percentage of devices, but the percentage of
> interconnections. In all instances the addresses are staticly
> configured.

OK, but from the outside I can't know that for the /64 subnets.

> Back to my example from earlier, to make sure we are on the same page,
> this is output from a standard Linux machine:
> 
>     job@tardis:~$ sudo ip -6 addr add 2001:728:1808:1::21/126 dev eth1
>     job@tardis:~$ sudo ip -6 addr show dev eth1
>     3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>         inet6 2001:728:1808:1::21/126 scope global
>            valid_lft forever preferred_lft forever
>         inet6 fe80::20d:b9ff:fe41:d4f5/64 scope link
>            valid_lft forever preferred_lft forever
>     job@tardis:~$ 
> 
> Most network engineers would call the above example "configuring a /126
> on an interface" - but am I understanding correctly that in your
> taxonomy you would call this "configuring a 128 bit IPv6 address"?

Well that does two things: configures a 128 bit address (as Chris points
out, *all* addresses are 128 bits, duh) and associates a prefix length
with it, which afaik is optional. But the interface has already
auto-configured a link-local address, with a 64 bit IID. So yes, that's
exactly what I mean.

> 
>> That being so, perhaps the words that are missing are
>> "The IID length requirement does not apply to interfaces that
>> are explicitly configured with 128 bit addresses." Because the
>> requirement is meaningless for such interfaces.
> 
> The terminology might confuse some people, as in common language when
> one configures "a /128", or 'a 128 bit address', it usually means you
> are configuring something like a loopback address.
> 
> Perhaps:
> 
>     "The IID length requirement does not apply to interfaces that are
>     explicitly configured without autoconfiguration."
> 
> (perhaps even remove the word 'explicitly')
> 
>     "The IID length requirement does not apply to interfaces that are
>     configured without autoconfiguration."

Personally I think that's right. (However, if you manually configure
an address that matches a pre-existing prefix announced by an RA,
it will be assumed to belong to that prefix. I've done that by
hand on Windows, not sure I've done it in Linux.)

   Brian