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

Christopher Morrow <morrowc.lists@gmail.com> Tue, 21 February 2017 22:57 UTC

Return-Path: <christopher.morrow@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 59619120725; Tue, 21 Feb 2017 14:57:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 8eKkDOvYa6_S; Tue, 21 Feb 2017 14:56:54 -0800 (PST)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 87E26120724; Tue, 21 Feb 2017 14:56:54 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id k15so124723508qtg.3; Tue, 21 Feb 2017 14:56:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EKtdDgo2o0kv4Os+X5jbPEXHxUYL91L64+Ty6j8nrPQ=; b=TEw1Mo4+8N1Gb/1u929dFpKIJbjcM+wpzB4LaIew30b/byU5LgioTUWTK4xxKTLbI7 uNyIVdSSgq4JnOu93xCDXAA87Ieb02Pp9M1fGsWYCh2niWuJXKn9goPu78W45txfQgDB 83d8u3oOtZfpLmJdaPE+KMBnelilygvReqzduncQNHkJ8xq38seK1dpAsROj9zVwJiEP B410gQPBfhge4Wvk6sf458QGow3GjpDkXtHmO+sWbfSm8Dhnm/IOkxPpvxbCk4hDhyI2 rnj/lpMlsztxrJBklgoE6euGgk1bpHm7BzqJip1PxkhiV1IV3izQIM1eWnt4eJEGZ7dX m5SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EKtdDgo2o0kv4Os+X5jbPEXHxUYL91L64+Ty6j8nrPQ=; b=DyrYv6gMcXMGSjMAPFZCFcLFRrRNEHCVISGPYJ+PvQaRwlvAGcV0htZBx67ppo5Cxj lwPZ1FOw407yf1mnKk0R3RHzns4RzvQBbiaAI8vrYd2bGinm6OCya7gvOF1csaZreq+F DIV73he01l8q7nSO8uSo4J7dcZCvemXAD+2OGahE/yA/Eff/gspBfHSIynsjPb/F3D3q SL34m7HDMHgMZ1b+ekBfzsvilZvF371uKDw86AsAaiEZHYVh0oQFv57RGNjp8GCvsNyJ 0fk+AcGlPBr5irGMe8RCTo4SmJdbOX/VqGJ88A7Bl8wAsq5zwviEwVjSuvTLojnGVtda XuSQ==
X-Gm-Message-State: AMke39mswCWXUqAqxqHVcgtaXLnN8OwXdq6iBfb/UxYltIdzuP2RMpwZ/RktDnSIa0CIbjw8gT7x4pRLGZsj3w==
X-Received: by 10.237.44.7 with SMTP id f7mr20969767qtd.214.1487717813699; Tue, 21 Feb 2017 14:56:53 -0800 (PST)
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.140.91.71 with HTTP; Tue, 21 Feb 2017 14:56:52 -0800 (PST)
In-Reply-To: <047994c3-9cce-12ce-55bb-bf3ae3369b57@gmail.com>
References: <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> <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>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Tue, 21 Feb 2017 17:56:52 -0500
X-Google-Sender-Auth: 9AzFSFbWrniimgFb8v8Nlw4Kwic
Message-ID: <CAL9jLaYy_=d+MePOpL4bfnENTuos-QD07Teme+TUVo3RghzMXA@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c05df90cfcd490549124ba3
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0fZuSFTEEMsNgFghVT7WSP19AY4>
Cc: draft-ietf-6man-rfc4291bis@ietf.org, 6man-chairs@ietf.org, 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@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:57:03 -0000

On Tue, Feb 21, 2017 at 5:44 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com>; 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 think one of the points the thread has brought out is that: "just because
we have always been at war with elbonia, does not mean we have to keep
being at war with elbonia"

We don't have to keep promulgating advice that we don't actually use in
practice... If we set the "Internet Standard" today we can move forward to
a better world in the time it takes to age out old 'broken'
gear/software... (yes, that's a while but eventually :) )


> ...
> > 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?
>
> 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.
>
>
specifying the 128 here seems wrong... or I'm using it wrong in my
interpretation :)
I would have said:
  "The IID length requirement does not apply to interfaces that are
explicitly configured."

all ipv6 interfaces have 128 addresses, they may have a subnet
configuration which is shorter though. right?