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

[Carlos M. martinez]

Son todos excelentes argumentos. Debemos tenerlos presentes cuando haya
que concretar el pedido.

s2

Carlos

On 7/29/13 5:49 PM, Antonio M. Moreiras wrote:
> 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
>>
> _____________________________________________
> Ietf-lac mailing list
> Ietf-lac at lacnog.org
> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
>