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

Roque Gagliano (rogaglia) rogaglia at cisco.com
Mon Jul 29 06:03:40 BRT 2013


Carlos,

On Jul 29, 2013, at 10:51 AM, "Carlos M. martinez" <carlosm3011 at gmail.com>
 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.
> 
> Entiendo que la preocupación de Antonio es doble, tanto los documentos
> como los labs.

Hace algunos años, trabajando en un operador me llamaron de la operación de otra red que tenían un problema con la interconexión con otra red (hasta ahora estaba en aislamiento).  Fui a ver qué pasaba y me pareció raro que toda la red tenía direcciones públicas que no eran de ellos. Les pregunté a qué se debía esto y me pasaron el manual de los equipos que estaba escrito todo con direcciones públicas…ese fue el argumento para tener direcciones de documentación que no funcionen en equipos de verdad.

r.


> s2
> 
> C.
> 
> On 7/29/13 10:46 AM, Roque Gagliano (rogaglia) wrote:
>> Carlos,
>>> 
>>> La otra pregunta que puede surgir, es porque no utilizar ULAs para este
>>> propósito.
>> 
>> Es como la diferencia entre 192.168.1.0/24 y 127.0.0.0/8. 
>> 
>> Las direcciones de documentación sólo viven en documentos y no deberían estar "en el cable", mientras las ULA sí. En el caso de Antonio el problema es con la documentación (AFAIK), para la práctica del LAB puede user ULA.
>> 
>> r.
>> 
>> 
>>> s2
>>> 
>>> Carlos
>>> 
>>> On 7/29/13 10:26 AM, Roque Gagliano (rogaglia) wrote:
>>>> Antonio,
>>>> 
>>>> Muita boa idéia.
>>>> 
>>>> Eu ofereço mia ajuda si vc quer na escritura. Penso que tem que ser
>>>> chamada RFC3849bis.
>>>> 
>>>> Abraco!
>>>> Roque
>>>> 
>>>> On Jul 28, 2013, at 7:45 PM, Antonio M. Moreiras <moreiras at nic.br
>>>> <mailto:moreiras at nic.br>> wrote:
>>>> 
>>>>> Un problema que tenemos con frecuencia es que el /32 para documentación
>>>>> (el 2001:0db8::/32, reservado por APNIC, RFC 3849) no es suficiente para
>>>>> la documentación y clases IPv6.
>>>>> 
>>>>> Por ejemplo, en nuestros laboratorios didácticos, dividimos a los
>>>>> estudiantes en varios grupos. Cada uno configura un Sistema Autónomo (de
>>>>> un ISP). Para ser más real, hemos optado por delegar un /32 para cada
>>>>> grupo.
>>>>> 
>>>>> Otro ejemplo es con 6rd. La manera fácil de configurar es elegir un
>>>>> prefijo /32 para usar con 6rd, y utilizando los 32 bits de la dirección
>>>>> IPv4 del usuario, delegar uno IPv6 /64 para ello. Pero si elegimos un
>>>>> /32 para 6rd, es supuesto que el ISP tiene un prefijo más corto, tal
>>>>> como un /31, o aún más corto.
>>>>> 
>>>>> Resolvemos facilmente el problema com el uso de direcciones fuera del
>>>>> 2001:0db8::/32 para los documentos, ejemplos, ejercicios, etc.
>>>>> 
>>>>> ¿Creen ustedes que una propuesta para IANA reservar un prefijo adicional
>>>>> para documentación, más corto que /32, tal como un /20, podría ser algo
>>>>> aceptable? Ciertamente no habría impacto negativo sobre el numero de
>>>>> direcciones IPv6 libres...
>>>>> 
>>>>> El 2001:db8::/32 no es suficiente para lo que es propuesto en la RFC
>>>>> 3849. Mi equipo discutió iso algunas veces. Pero con tantos problemas
>>>>> graves que deben abordarse, pensamos que tal propuesta podría no ser
>>>>> bien aceptada, por decir lo mínimo.
>>>>> 
>>>>> Lo siento por el portuñol.
>>>>> 
>>>>> []s
>>>>> Moreiras.
>>>>> _____________________________________________
>>>>> Ietf-lac mailing list
>>>>> Ietf-lac at lacnog.org <mailto: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
>>>> 
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4459 bytes
Desc: not available
URL: <https://mail.lacnic.net/pipermail/ietf-lac/attachments/20130729/2dbdf553/attachment.bin>


More information about the Ietf-lac mailing list