Re: IID length text

Suresh Krishnan <> Fri, 20 January 2017 03:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E0F6129781 for <>; Thu, 19 Jan 2017 19:30:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.356
X-Spam-Status: No, score=-5.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BxTnJY9jP-lm for <>; Thu, 19 Jan 2017 19:30:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CABDD12973A for <>; Thu, 19 Jan 2017 19:30:27 -0800 (PST)
X-AuditID: c618062d-ab7ff70000007359-da-58818b14a470
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 01.CA.29529.41B81885; Fri, 20 Jan 2017 04:59:19 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Thu, 19 Jan 2017 22:30:23 -0500
From: Suresh Krishnan <>
To: Fernando Gont <>
Subject: Re: IID length text
Thread-Topic: IID length text
Thread-Index: AQHScDcHu5IrnyDX5kaJ4tCyEtG8qqE75X8AgAABHYCAAAn3gIAADVUAgAUQfwA=
Date: Fri, 20 Jan 2017 03:30:13 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_17F049EDB1F94B18AC4C658AB93A6861ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyuXRPgq54d2OEwalXWhYz3/1gtXiy6g2b xcuz75ksZveeZnFg8dg56y67x9MJB5k8liz5yeTx4VAPewBLFJdNSmpOZllqkb5dAlfGyb0X mAq2VldsXr+WvYGxq6KLkZNDQsBE4uvHO8xdjFwcQgLrGSXO3t7EAuEsZ5SY9qGRDaSKDahq w87PTCC2iICmxNznR8BsZoFKia67B5hBbGEBGYnb/Y/YIGpkJeZc+M0CYftJ7Jv5nRHEZhFQ lTjQ+Z4dxOYVsJc4/e0p2BwhgQ0cEq/2uoLYnALOEn2n97OC2IwCYhLfT62B2iUucevJfCaI qwUkluw5zwxhi0q8fPyPFcJWkvj4ez7QfA6g+mSJ68f9IFYJSpyc+YRlAqPILCSTZiFUzUJS BRHWlFi/Sx+iWlFiSvdDdghbQ6J1zlwo21pi64WFTMhqFjByrGLkKC0uyMlNNzLYxAiMvGMS bLo7GO9P9zzEKMDBqMTDW3ClIUKINbGsuDL3EKMEB7OSCO+0hsYIId6UxMqq1KL8+KLSnNTi Q4zSHCxK4rxxq++HCwmkJ5akZqemFqQWwWSZODilGhhDvI6ZuBbdCv7GIbsh4PPN1C0sEjxq m7NmfFpxKGPX3KDiTyXrE/WbrXZs9jJZFe7NUxcYzclq9ePG1unKCVEsCqmr8n1F2S3E844w zJ278cmNM2wfzmS5zf+s2RQ6e9a9199vCy/9Fzfnwz/np+dmPCn9dvZpZ856qY8tU0Nv/Q9x rD8mMYdFiaU4I9FQi7moOBEAjoptWrgCAAA=
Archived-At: <>
Cc: 6man WG <>, Alexandre Petrescu <>
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: Fri, 20 Jan 2017 03:30:29 -0000

Hi Fernando,

On Jan 16, 2017, at 5:09 PM, Fernando Gont <<>> wrote:

On 01/16/2017 06:22 PM, Behcet Sarikaya wrote:
On Mon, Jan 16, 2017 at 2:46 PM, Fernando Gont <<>> wrote:
On 01/16/2017 05:42 PM, Behcet Sarikaya wrote:
On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu
<<>> wrote:
Le 14/01/2017 à 20:49, Brian E Carpenter a écrit :

A modest suggestion:

  For all unicast addresses, except those that start with the binary
  value 000, Interface IDs are required to be 64 bits long.  Background
  on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].

  IPv6 routing is based on prefixes of any valid length up to 128
  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
  of Interface ID. In practice, this means that to guarantee
  of SLAAC, a fixed length of Interface ID is necessary. For all
  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
  space. Background on the 64 bit boundary in IPv6 addresses can be found
  in [RFC7421].

I agree with the change suggestion.  The new text and references are enough
motivation to clarify that that 64bit limit is an arbitrary choice and might
change in the future.

3GPP assigns 64 bit prefixes to each UE.
Extended Unique Identifiers defined are EUI-48 and EUI-64.

What does a layer-2 EUI have to do with a layer-3 address?

I don't know, you tell me :-)

Answer: Nothing. The fact that we've been embedding layer-2 "addresses"
into layer-3 addresses should not be taken as a reason for the two of
them of having to do anything with each other. So, yes, the 64-bit IID
length is, in reality, arbitrary. They could have been e.g. 32-bits or
48-bits (yes, multiples or 64 or 32 tend to be nicer)

Kind of agree but not entirely. There are some protocols in the constrained space that depend on some form of relationship between an L2 address and the L3 IPv6 address to achieve compression.