[LACNIC/Seguridad] Sobre la longitud de los IIDs (Fwd: Re: IID length text)

[Julio Balderrama]

Fernando, Muchas gracias

Saludos
Julio César Balderrama
(+54 911) 3271-2639
Enviado desde un dispositivo móvil

________________________________
From: Seguridad <seguridad-bounces en lacnic.net> on behalf of Fernando Gont <fgont en si6networks.com>
Sent: Monday, January 16, 2017 7:41:27 PM
To: lactf en lac.ipv6tf.org
Cc: Lista para discusión de seguridad en redes y sistemas informaticos de la región
Subject: [LACNIC/Seguridad] Sobre la longitud de los IIDs (Fwd: Re: IID length text)

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 en gmail.com>
Organization: University of Auckland
To: sarikaya en ieee.org, Alexandre Petrescu <alexandru.petrescu en gmail.com>
CC: 6man <ipv6 en ietf.org>

On 17/01/2017 09:42, Behcet Sarikaya wrote:
> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu
> <alexandru.petrescu en 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 en ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6 en ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> .
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 en ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
Seguridad mailing list
Seguridad en lacnic.net
https://mail.lacnic.net/mailman/listinfo/seguridad
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20170117/41f15d2d/attachment.html>