Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

Fernando Gont <> Thu, 02 March 2017 05:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A927D1296F8 for <>; Wed, 1 Mar 2017 21:10:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tHXR4i5xiLgN for <>; Wed, 1 Mar 2017 21:10:04 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C88261296D3 for <>; Wed, 1 Mar 2017 21:10:02 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 0E792801F3; Thu, 2 Mar 2017 06:09:59 +0100 (CET)
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: =?UTF-8?Q?Iv=c3=a1n_Arce?= <>, 6man WG <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 2 Mar 2017 02:08:56 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <>
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: Thu, 02 Mar 2017 05:10:05 -0000

On 03/01/2017 02:03 PM, Iván Arce wrote:
> El 1/3/17 a las 6:51, Lorenzo Colitti escribió:
>>         Another thing I think we should avoid is to remove the fixed 64
>>         barrier and open the door to having this debate again and again,
>>         once for every new IPv6-over-foo document and once for every new
>>         address configuration protocol (today we have SLAAC and DHCPv6,
>>         who knows what we'll have in the future).
>>     Which is why it time to get this right and saying it is now and
>>     forever 64 isn't right.
>> Do you agree that a fixed boundary is useful or not? For 20 years the
>> standards have guaranteed that 64 bits of IIDs were available to hosts
>> that wanted to use them. If we make that barrier mobile, there will be
>> no guarantee in the standards any more. Who should be allowed to set the
>> boundary? An IPv6-over-foo document? An address configuration technology
>> such as SLAAC? 
> The last paragraph of section "2.5.1 Interface identifiers" in 4291 said:
>    The details of forming interface identifiers are defined in the
>    appropriate "IPv6 over <link>" specification, such as "IPv6 over
>    Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI].
> The corresponding paragraph in rfc4291bis is:
>    The details of forming interface identifiers are defined in other
>    specifications, such as "Privacy Extensions for Stateless Address
>    Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating
>    Semantically Opaque Interface Identifiers with IPv6 Stateless Address
>    Autoconfiguration (SLAAC)"[RFC7217].  Specific cases are described in
>    appropriate "IPv6 over <link>" specifications, such as "IPv6 over
>    Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T
>    G.9959 Networks" [RFC7428].  The security and privacy considerations
>    for IPv6 address generation is described in [RFC7721].
> Don't you agree with that?

To add to what Ivan said, the only text in the "IPv6 over <foo>"
documents that has anything to do with the 64-bit IIDs is the
description of how to come up with Modified-EUI64 identifiers. RFC7217,
the recommended algorithm for forming IIDs, does not employ Modified
EUI64 format identifiers, and formally updates all such RFCs.

For instance, RFC7217 explicitly says:

   2.  The Interface Identifier is finally obtained by taking as many
       bits from the RID value (computed in the previous step) as
       necessary, starting from the least significant bit.

          We note that [RFC4291] requires that the Interface IDs of all
          unicast addresses (except those that start with the binary
          value 000) be 64 bits long.  However, the method discussed in
          this document could be employed for generating Interface IDs
          of any arbitrary length, albeit at the expense of reduced
          entropy (when employing Interface IDs smaller than 64 bits).

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492