[LAC-TF] [v6ops] In the vein of of the icp/dc guidance

Alejandro Acosta alejandroacostaalamo at gmail.com
Wed Apr 18 15:58:16 BRT 2012


En estos casos traigo dos lemas a relucir:

1) Los problemas de hoy fueron las soluciones de ayer :)
2) Todo pro tiene sus contras


Alejandro,


On 4/18/12, Jorge Villa <villa at reduniv.edu.cu> wrote:
> Pues si, definitivamente DS es la solucion mas obvia (siguiendo un esquema
> lineal de pensamiento), o sea, si todos los dispositivos tienen que tener
> una direccion IPv4 ahora que la red es IPv4, igualmente le ponemos una IPv6
> si queremos que sea IPv6, y mientras las 2 coexisten, uso las 2 direcciones
> de forma simultanea. Claro, usar DS reduce la necesidad de NATs (si hay
> direcciones IPv4 suficientes), pero en efecto, complica la administracion,
> la gestion, la seguridad...
>
> Creo que puede ser interesante e importante, presentar algunos ejemplos de
> alternativas funcionales sin necesidad de DS. Esta presentacion de RIPE
> permite reflexionar al respecto. Creo que la que comenta Alejandro sobre
> moviles, para el evento de Quito va a estar muy interesante tambien.
>
> Saludos,
> Jorge
>
> -----Mensaje original-----
> From: Arturo Servin
> Sent: Wednesday, April 18, 2012 11:41 AM
> To: lactf at lac.ipv6tf.org
> Subject: Re: [LAC-TF] [v6ops] In the vein of of the icp/dc guidance
>
>
> Nosotros hemos empezado a pensar en mantener algún día solo un stack. Por
> ahora el tener dos te duplica las reglas en los firewalls, direccionamiento,
> etc. y al final eso es un costo.
>
> IPv6 puro en el datacenter con proxies de IPv4 pudiera ser una buena
> solución para aquellas aplicaciones que lo soportan, por ejemplo HTTP.
>
> Slds
> as
>
> On 18 Apr 2012, at 12:29, Alejandro Acosta wrote:
>
>> Muy buena!.... interesante la lámina que indica: "Why skip dual-stack?"
>>
>> Copy/Paste de la presentación:
>>
>> • DS implies lots of unwanted complexity
>> • More ACLs, monitoring, troubleshooting,
>> possible failures, training, documentation, ...
>> • Saves lots of precious IPv4 addresses
>> • 1 IPv4 per service, rather than 1+ per server
>> • Forces sysadmins to learn and use IPv6
>> • They resist change and new technologies
>> • Provision dual-stack and they'll use IPv4 only
>> • Perform a single IPv6 migration project
>>
>>  Indiscutiblemente hay muchos escenarios y los métodos de transición
>> no son iguales en todos, Yo oriento lo anterior más en aquellas
>> regiones (ej: APNIC) donde IPv4 ya es sumamente escaso y dejar
>> DualStack siempre que sea posible.
>>  Aprovecho para informar que en FLIP6 en Quito habrá una presentación
>> sobre IPv6 en redes moviles llamada: "IPv6-only services: a mobile
>> provider's perspective"
>>
>> Saludos,
>>
>> Alejandro Acosta,
>>
>>
>>
>>
>>
>>
>> On 4/17/12, Arturo Servin <aservin at lacnic.net> wrote:
>>>
>>> Se me hizo una presentación muy interesante de compartir.
>>>
>>> Slds
>>> as
>>>
>>> Sent from my mobile device
>>> (please excuse typoss and brevit.)
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: Joel jaeggli <joelja at bogus.com>
>>>> Date: 17 April 2012 14:37:34 GMT-03:00
>>>> To: IPv6 Ops WG <v6ops at ietf.org>
>>>> Subject: [v6ops] In the vein of of the icp/dc guidance
>>>>
>>>> This was presented at ripe64.
>>>>
>>>> https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> v6ops at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>> _______________________________________________
>> LACTF mailing list
>> lactf at lac.ipv6tf.org
>> https://mail.lacnic.net/mailman/listinfo/lactf
>
> _______________________________________________
> LACTF mailing list
> lactf at lac.ipv6tf.org
> https://mail.lacnic.net/mailman/listinfo/lactf
>
>
> Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
>
>
>
> Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
>
>
> _______________________________________________
> LACTF mailing list
> lactf at lac.ipv6tf.org
> https://mail.lacnic.net/mailman/listinfo/lactf
>



More information about the LACTF mailing list