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

[Carlos M. martinez]

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
>