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

Tore Anderson <tore@fud.no> Mon, 23 January 2017 14:15 UTC

Return-Path: <tore@fud.no>
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 ECF8F12960A for <ipv6@ietfa.amsl.com>; Mon, 23 Jan 2017 06:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=unavailable 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 rxKHaMqAFkiN for <ipv6@ietfa.amsl.com>; Mon, 23 Jan 2017 06:15:44 -0800 (PST)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF47A12960C for <ipv6@ietf.org>; Mon, 23 Jan 2017 06:07:45 -0800 (PST)
Received: from [2a02:fe0:c420:6ae::c68] (port=58554 helo=envy.e1.y.home) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <tore@fud.no>) id 1cVfHc-0005Tb-3y; Mon, 23 Jan 2017 15:07:44 +0100
Date: Mon, 23 Jan 2017 15:07:43 +0100
From: Tore Anderson <tore@fud.no>
To: Lorenzo Colitti <lorenzo@google.com>
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
Message-ID: <20170123150743.6960611b@envy.e1.y.home>
In-Reply-To: <CAKD1Yr2jFf=OFiCJLWV48FRZF1iuWK1mLJ9+kQiuFBxujgCOBQ@mail.gmail.com>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.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> <CAN-Dau36r2UgXPfdcdEAJ914QqvVvjGJK+=mgE9Y2tpBiDSRig@mail.gmail.com> <CAKD1Yr3RpUaNKkyTPHPWWew80cyGkiT1p7vYwfejESP4tQw31A@mail.gmail.com> <20170123124954.13329c33@echo.ms.redpill-linpro.com> <CAKD1Yr2jFf=OFiCJLWV48FRZF1iuWK1mLJ9+kQiuFBxujgCOBQ@mail.gmail.com>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1HM43W62EHYhPmNQ-q7elvfr8IY>
Cc: Erik Kline <ek@google.com>, 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: Mon, 23 Jan 2017 14:15:45 -0000

* Lorenzo Colitti

> On Mon, Jan 23, 2017 at 8:49 PM, Tore Anderson <tore@fud.no> wrote:
> 
> > Isn't there a conflict with RFC 6052, though?
> >
> > E.g., if you're using an RFC 6052 NSP such as 2001:db8:6052::/96,
> > the IPv4-translatable representation of an IPv4 subnet such as
> > 192.0.2.0/24 would be 2001:db8:6052::192.0.2.0/120
> > (2001:db8:6052::c000:200/120) and nodes in this subnet/link would
> > necessarily have 8 bit long IIDs. Right?
> 
> I'm not sure it makes sense to draw that conclusion.
> 
> If you follow that reasoning, /96 might make sense, but all the other
> RFC 6052 prefix lengths don't really make sense. For example, if the
> NSP is 64 bits, how long would the IID be? If you say 8 bits, then
> that means there are 2^40 addresses routed to the same host, which
> means that the prefix length (88) plus the IID length (8) does not
> add up to 128. And if you say 48 bits, then that means that a host
> has 2^40 interface IDs for the same interface

So with an NSP of 2001:db8:6052::/64, the IPv4 link subnet of
192.0.2.0/24 would be as I understand it be represented as
2001:db8:6052:0:c0:2::/96.

In the «vanilla» RFC7915 operational mode, the default gateway on that
link (a.k.a. 192.0.2.1 from the IPv4 point of view) would be configured
with 2001:db8:6052:0:c0:2:100:0/96, the node reachable at 192.0.2.10
would have 2001:db8:6052:0:c0:2:a00:0/96, 192.0.2.254 would be
2001:db8:6052:0:c0:2:fe00:0/96, and so on.

The IPv6 addresses you actually need to configure on the routers and
the nodes on this link will have an IPv6 prefix length of /96, so
wouldn't that mean that the IIDs in question are 32 bits long?

> the interface ID isn't really an ID any more.

I suppose you can look at it that way too...but wouldn't that then mean
that you're essentially saying that you can have whatever amount of
suffix/node/host bits in an IPv6 address you'd like, but you're only
allowed to call it an «IID» if it just so happens to be exactly 64 of
them? :-)

Tore