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

[Antonio M. Moreiras]

Podemos utilizar direcciones ULA en los laboratorios, o podemos utilizar
cualquier bloque de direcciones globais no asignadas. Incluso que
podemos utilizar direcciones asignadas, si es un lab isolado de la
Internet. Yo elegiría la segunda alternativa (direcciones aún no
asignadas). De hecho, lo hacemos en NIC.br. Pero creo que sería mejor
tener un bloque de "documentation", o una "test-net" para esta finalidad.

Recuerden que estamos enseñando IPv6. Recuerden que estos diversos tipos
de direcciones son una parte difícil de enseñar del IPv6. No me gustaria
confundir a los estudiantes en su primer contacto con IPv6, utilizando
direcciones ULA y diciendo: por favor, no se olvide de pretender que
estamos utilizando direcciones globais. ULA tiene su función propia.

En la misma línea, el uso de un /32 para un ISP simulado, en el
laboratorio, es lo mejor para enseñar el plan de direccionamiento. No me
gustaría utilizar un /48 y decir a los estudiantes: por favor, vamos
pretender que este /48 es un /32...

Quiero los estudiantes bien de sus facultades mentales ao fin de las
clases. O, al menos, (cuase) tan bien cuante llegaran.

Para nosotros, los laboratorios y la documentación son básicamente la
misma cosa, ya que hacemos publicar apostilas, guías paso a paso,
videos, etc, con los laboratorios.

La RFC 5737 llama los bloques de documentation IPv4 de "test-nets". Iso
es sugestivo. La RFC 3849 recomienda el despliegue de filtros.
No hay porque non utilizar estas direcciones en testes. Si hay un
accidente, es más seguro, porque ya se filtran.

Podríamos preguntar a APNIC si podían reservar 2001:0db8::/29. No está
asignada. Contudo, en nuestros laboratorios, necesitaríamos un /27, por
lo menos. Para estar en el límite de "4 bits" podríamos pensar en un
/24. No creo que un /20 sería algo que temer.

[]s
Moreiras.

On 29/07/13 06:09, Carlos M. martinez 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
>