[Ietf-lac] 2001:0db8::/32 - RFC 3849

[Jorge Villa]

En efecto Antonio, creo que has tocado muy buen tema.

Ciertamente se pudieran usar las ULAs en algunos casos; pero considero que 
la propuesta ademas de buscar extender el 2001:db8::/32 a un prefijo que 
brinde mas posibilidades (/24, /20, /16), debe extender su alcance no solo a 
documentacion, sino tambien a practicas de laboratorio/entrenamiento. De 
esta manera (si en todos lados aparecen los mismos prefijos en todos los 
ejemplos) reducimos las opciones de que si alguien con poco conocimiento, 
transcribe literalmente cualquier ejemplo (de un laboratorio o libro) a su 
red, pueda crear alguna situacion no deseable.

Saludos,
Jorge

-----Mensaje original----- 
From: Alejandro Acosta
Sent: Monday, July 29, 2013 7:43 AM
To: Carlos M. martinez
Cc: ietf-lac at lacnog.org
Subject: Re: [Ietf-lac] 2001:0db8::/32 - RFC 3849

Hola Antonio,
  Creo que tuviste consenso.
  Cuenta con mi apoyo también si necesitas algo en el documento.

Saludos,

Alejandro,



On 7/29/13, Carlos M. martinez <carlosm3011 at gmail.com> wrote:
> Creo que tiene que ver con el scope de los documentos. Si uno documenta
> su propia red o su plan de direccionamiento, de hecho termina
> escribiendo direcciones global unicast en documentos.
>
> Por eso, en el caso de un documento cuyo scope es un lab, y que se
> *supone* que uno lo va a implementar en un simulador o en unos routers,
> alguien podría argumentar que utilizar ULAs es aceptable.
>
> Si uno va a escribir un libro para publicar, que no tiene p.ej. aspectos
> directamente que deban ser implementados, ahi si tiene mas sentido usar
> un prefijo unicamente de documentación.
>
> (De nuevo, acuérdense que estoy jugando a ser el abogado del diablo)
>
> s2
>
> C.
>
>
> On 7/29/13 10:54 AM, Arturo Servin wrote:
>>
>>
>> On 7/29/13 10:51 AM, Carlos M. martinez wrote:
>>> Me cuesta ver porque las ULAs no pueden estar en documentos, sabiendo
>>> que son ULAs :-) Ojo, en realidad no lo dije como que esa fuera mi
>>> posición, sino mas bien tratando de prever un posible contra-argumento
>>> que podría surgir.
>>>
>>
>> RFC4193
>>
>> 3.2.1.  Locally Assigned Global IDs
>>
>>    Locally assigned Global IDs MUST be generated with a pseudo-random
>>    algorithm consistent with [RANDOM].  Section 3.2.2 describes a
>>    suggested algorithm.  It is important that all sites generating
>>    Global IDs use a functionally similar algorithm to ensure there is a
>>    high probability of uniqueness.
>>
>>    The use of a pseudo-random algorithm to generate Global IDs in the
>>    locally assigned prefix gives an assurance that any network numbered
>>    using such a prefix is highly unlikely to have that address space
>>    clash with any other network that has another locally assigned prefix
>>    allocated to it.  This is a particularly useful property when
>>    considering a number of scenarios including networks that merge,
>>    overlapping VPN address space, or hosts mobile between such networks.
>>
>>
>>> Entiendo que la preocupación de Antonio es doble, tanto los documentos
>>> como los labs.
>>>
>>> s2
>>>
>>
>> Slds
>> as
>>
>> _____________________________________________
>> Ietf-lac mailing list
>> Ietf-lac at lacnog.org
>> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
>>
> _____________________________________________
> Ietf-lac mailing list
> Ietf-lac at lacnog.org
> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
>
>


-- 
=====
^A.......o$
_____________________________________________
Ietf-lac mailing list
Ietf-lac at lacnog.org
Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org



Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu




Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu