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

Lorenzo Colitti <> Mon, 16 January 2017 09:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21FA91293F2 for <>; Mon, 16 Jan 2017 01:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6LfYoQYGg5Fq for <>; Mon, 16 Jan 2017 01:37:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F22AC126D73 for <>; Mon, 16 Jan 2017 01:37:11 -0800 (PST)
Received: by with SMTP id k127so24161971vke.0 for <>; Mon, 16 Jan 2017 01:37:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pMLvawMOL6w7uwwXwcN3cv7fFQcR+yl0U9vjm7vD+gQ=; b=CaIY6Fajh2rj33yyQyM3YgxfwaPIAKuw4BvHZVacXisDXDiAeaINjQvYfyKFw/kGew q8211lP6BJCA0dNvaotWSp7yRqG4bx+gKc9487vIjZTbV3mHMUOxiPVJJ/zDBMuM+EEO EfJPEvd1IjX/j3rxn0uWV+ekQpeKLbgmkvebAAJxgH/hExr9ekJdMtHIqysZX1AyDwsd gB/+hHjP8AHAGNaiE4hJfy8WYiwxmA3m3SlYnlw0H7rBRgOjcUefalE6RcfoXGtYbofX LhjxTS+P8eYkVyQajgKFHprXpACaKzcI2jVpdaetB9ePt6KG0wTsYW1dHqcmujn3ZfSo mIug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pMLvawMOL6w7uwwXwcN3cv7fFQcR+yl0U9vjm7vD+gQ=; b=i4mf/GgjTAfL8GDfMjNdncQbnIIVWSQDcVvBxdvJPgQACUEnSIIK7B1nNKkYal9glY GQsfTPjwf0QU84NjqVs0mXxNWaFzToZZMimlRYpN+ZEzDGVbPnJIJ2bDEKf5eelGFkP8 DeTCOvi22ROxs+xfuHOJimaKNiHNmNeT9ko4VurjgzmR4efX0HfhPuSF3ONfQUSAZHsE BLf7mpNEsc5rB1C2ZvZZNKXZ+RXfpy0+fJ9dKOqqYVI23lef3zTI6WIj8lTz8t6WNxeW or6NDEhvyoTU0h05SP8AwMz9ll7+v51XaL5XSfAbS2CQKIaNgVFLHqSJ/Y1KnDrnELoi UvhA==
X-Gm-Message-State: AIkVDXK13UJ+KpXtkZG3hxV7SYVQnGKylrREab3bYMgUy2HsYGDd8c8B4Sus0JDLXTibFUHD8p1Y1FQBSOcC6DQo
X-Received: by with SMTP id y128mr13298545vkd.102.1484559430868; Mon, 16 Jan 2017 01:37:10 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 16 Jan 2017 01:36:50 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <>
From: Lorenzo Colitti <>
Date: Mon, 16 Jan 2017 18:36:50 +0900
Message-ID: <>
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
To: Brian E Carpenter <>
Content-Type: multipart/alternative; boundary=001a1141d60086b945054632ed71
Archived-At: <>
Cc: 6man <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jan 2017 09:37:14 -0000


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 "interface identifiers are 64 bits" long text in RFC 4291 goes back all
the way to 1998 and the text below would be a major change to text that has
likely been baked into implementations for almost two decades years. I
don't see why we would change that now.

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. In general, IPv6 addresses are
aggregatable on all bit lengths. But global unicast addresses (other than
::/3) have a 64-bit IID, so links in that space are assigned 64-bit prefix
lengths. These two properties can coexist even in global unicast space. For
example, you could load-balance traffic to a given global unicast /64 by
announcing it to the backbone as two /65s. The "addresses are aggregatable
on all bit lengths" text means that the /65 are valid prefixes that can be
routed by routers.


On Sun, Jan 15, 2017 at 4:49 AM, Brian E Carpenter <> wrote:

>    IPv6 routing is based on prefixes of any valid length up to 128
> [BCP198].
>    For example, [RFC6164] standardises 127 bit  prefixes on point-to-point
>    links. However, consistent use of Stateless Address Autoconfiguration
>    (SLAAC)[RFC4862] requires that all interfaces on a link use the same
> length
>    of Interface ID. In practice, this means that to guarantee
> interoperability
>    of SLAAC, a fixed length of Interface ID is necessary. For all currently
>    allocated unicast addresses, except those that start with the binary
>    value 000, that length is 64 bits. Note that this value is an arbitrary
>    choice and might be changed for some future allocation of unicast
> address
>    space. Background on the 64 bit boundary in IPv6 addresses can be found
>    in [RFC7421].
> Regards
>    Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------