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

Job Snijders <job@ntt.net> Tue, 21 February 2017 22:59 UTC

Return-Path: <job@ntt.net>
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 0792F126579; Tue, 21 Feb 2017 14:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 zu9lmWHqXqaW; Tue, 21 Feb 2017 14:59:28 -0800 (PST)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1291E120724; Tue, 21 Feb 2017 14:59:28 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <job@ntt.net>) id 1cgJOu-0007iy-BH (job@us.ntt.net); Tue, 21 Feb 2017 22:59:27 +0000
Date: Tue, 21 Feb 2017 23:58:57 +0100
From: Job Snijders <job@ntt.net>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Message-ID: <20170221225857.GE32367@Vurt.local>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <047994c3-9cce-12ce-55bb-bf3ae3369b57@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/pd8inHtLRZEoRRb171NvUSNlkm8>
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 22:59:29 -0000

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.

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

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

Kind regards,

Job