<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>Fernando, Muchas gracias <br>
<br>
<div class="x_acompli_signature">Saludos<br>
Julio César Balderrama<br>
(+54 911) 3271-2639<br>
Enviado desde un dispositivo móvil</div>
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Seguridad <seguridad-bounces@lacnic.net> on behalf of Fernando Gont <fgont@si6networks.com><br>
<b>Sent:</b> Monday, January 16, 2017 7:41:27 PM<br>
<b>To:</b> lactf@lac.ipv6tf.org<br>
<b>Cc:</b> Lista para discusión de seguridad en redes y sistemas informaticos de la región<br>
<b>Subject:</b> [LACNIC/Seguridad] Sobre la longitud de los IIDs (Fwd: Re: IID length text)</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Quienes estén dando cursos de IPv6, puede que quieran leer el thread.<br>
<br>
En resumen: como una decision arbitraria ha afectado la seguridad y<br>
privacidad de despliegues IPv6.<br>
<br>
<br>
<br>
-------- Forwarded Message --------<br>
Subject: Re: IID length text<br>
Date: Tue, 17 Jan 2017 11:23:47 +1300<br>
From: Brian E Carpenter <brian.e.carpenter@gmail.com><br>
Organization: University of Auckland<br>
To: sarikaya@ieee.org, Alexandre Petrescu <alexandru.petrescu@gmail.com><br>
CC: 6man <ipv6@ietf.org><br>
<br>
On 17/01/2017 09:42, Behcet Sarikaya wrote:<br>
> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu<br>
> <alexandru.petrescu@gmail.com> wrote:<br>
>> Le 14/01/2017 à 20:49, Brian E Carpenter a écrit :<br>
>>><br>
>>> A modest suggestion:<br>
>>><br>
>>> OLD<br>
>>> For all unicast addresses, except those that start with the binary<br>
>>> value 000, Interface IDs are required to be 64 bits long. Background<br>
>>> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].<br>
>>><br>
>>> NEW<br>
>>> IPv6 routing is based on prefixes of any valid length up to 128<br>
>>> [BCP198].<br>
>>> For example, [RFC6164] standardises 127 bit prefixes on point-to-point<br>
>>> links. However, consistent use of Stateless Address Autoconfiguration<br>
>>> (SLAAC)[RFC4862] requires that all interfaces on a link use the same<br>
>>> length<br>
>>> of Interface ID. In practice, this means that to guarantee<br>
>>> interoperability<br>
>>> of SLAAC, a fixed length of Interface ID is necessary. For all<br>
>>> currently<br>
>>> allocated unicast addresses, except those that start with the binary<br>
>>> value 000, that length is 64 bits. Note that this value is an arbitrary<br>
>>> choice and might be changed for some future allocation of unicast<br>
>>> address<br>
>>> space. Background on the 64 bit boundary in IPv6 addresses can be found<br>
>>> in [RFC7421].<br>
>><br>
>><br>
>> I agree with the change suggestion. The new text and references are enough<br>
>> motivation to clarify that that 64bit limit is an arbitrary choice and might<br>
>> change in the future.<br>
>><br>
> <br>
> 3GPP assigns 64 bit prefixes to each UE.<br>
> Extended Unique Identifiers defined are EUI-48 and EUI-64.<br>
> I don't think 64 bit limit is that arbitrary?<br>
<br>
It's a parameter, which we happened to set initially to 48<br>
and then changed to 64 because of FireWire. I don't know<br>
why 3GPP chose the same value. But indeed we (the IETF) chose<br>
it because of our now old-fashioned decision to copy Novell<br>
Netware by embedding layer 2 addresses in layer 3. A bad<br>
choice, as it turned out.<br>
<br>
The first two definitions of "arbitrary" in Merriam-Webster seem<br>
to fit, especially the second.<br>
<br>
"existing or coming about seemingly at random or by chance<br>
or as a capricious and unreasonable act of will"<br>
"based on or determined by individual preference or convenience<br>
rather than by necessity or the intrinsic nature of something"<br>
<br>
Regards<br>
Brian<br>
<br>
> <br>
> Behcet<br>
> <br>
>> Alex<br>
>><br>
>>><br>
>>> Regards<br>
>>> Brian<br>
>>><br>
>>> --------------------------------------------------------------------<br>
>>> IETF IPv6 working group mailing list<br>
>>> ipv6@ietf.org<br>
>>> Administrative Requests: <a href="https://www.ietf.org/mailman/listinfo/ipv6">
https://www.ietf.org/mailman/listinfo/ipv6</a><br>
>>> --------------------------------------------------------------------<br>
>>><br>
>><br>
>> --------------------------------------------------------------------<br>
>> IETF IPv6 working group mailing list<br>
>> ipv6@ietf.org<br>
>> Administrative Requests: <a href="https://www.ietf.org/mailman/listinfo/ipv6">
https://www.ietf.org/mailman/listinfo/ipv6</a><br>
>> --------------------------------------------------------------------<br>
>><br>
> .<br>
> <br>
<br>
--------------------------------------------------------------------<br>
IETF IPv6 working group mailing list<br>
ipv6@ietf.org<br>
Administrative Requests: <a href="https://www.ietf.org/mailman/listinfo/ipv6">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
--------------------------------------------------------------------<br>
_______________________________________________<br>
Seguridad mailing list<br>
Seguridad@lacnic.net<br>
<a href="https://mail.lacnic.net/mailman/listinfo/seguridad">https://mail.lacnic.net/mailman/listinfo/seguridad</a><br>
</div>
</span></font>
</body>
</html>