[LAC-TF] Sobre la longitud de los IIDs (Fwd: Re: IID length text)

Fernando Gont fgont at si6networks.com
Mon Jan 16 20:41:27 BRST 2017


Quienes estén dando cursos de IPv6, puede que quieran leer el thread.

En resumen: como una decision arbitraria ha afectado la seguridad y
privacidad de despliegues IPv6.



-------- Forwarded Message --------
Subject: Re: IID length text
Date: Tue, 17 Jan 2017 11:23:47 +1300
From: Brian E Carpenter <brian.e.carpenter at gmail.com>
Organization: University of Auckland
To: sarikaya at ieee.org, Alexandre Petrescu <alexandru.petrescu at gmail.com>
CC: 6man <ipv6 at ietf.org>

On 17/01/2017 09:42, Behcet Sarikaya wrote:
> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu
> <alexandru.petrescu at gmail.com> wrote:
>> Le 14/01/2017 à 20:49, Brian E Carpenter a écrit :
>>>
>>> A modest suggestion:
>>>
>>> OLD
>>>    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].
>>>
>>> NEW
>>>    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].
>>
>>
>> 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.
> I don't think 64 bit limit is that arbitrary?

It's a parameter, which we happened to set initially to 48
and then changed to 64 because of FireWire. I don't know
why 3GPP chose the same value. But indeed we (the IETF) chose
it because of our now old-fashioned decision to copy Novell
Netware by embedding layer 2 addresses in layer 3. A bad
choice, as it turned out.

The first two definitions of "arbitrary" in Merriam-Webster seem
to fit, especially the second.

"existing or coming about seemingly at random or by chance
or as a capricious and unreasonable act of will"
"based on or determined by individual preference or convenience
rather than by necessity or the intrinsic nature of something"

Regards
    Brian

> 
> Behcet
> 
>> Alex
>>
>>>
>>> Regards
>>>    Brian
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6 at ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6 at ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> .
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



More information about the LACTF mailing list