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

Thu Apr 19 10:10:03 BRT 2012

Buen punto, de acuerdo. Creo que mi punto va mas a que ahora
consideramos un requerimiento ('quiero un solo protocolo') algo que hace
no mucho era un lujo, o algo que uno ni siquiera se cuestionaba. Creo
que puede y debe haber un punto intermedio, siendo este 'voy a vivir con
dual stack hasta que en X años pueda quedarme solo con v6' (con X
pequeño como dicen los matematicos)

La otra gran ironía que veo en todo esto es que los CGNs a veces se
'venden' o promocionan como 'asi puedo seguir con IPv4' o 'extienden la
vida util de IPv4'. Si los administradores creemos que nuestra vida va a
ser igual que ahora en un mundo con CGNs, estamos super equivocados.

Entonces, si vamos a tener que vivir con complejidad en un sentido u
otro (CGN vs IPv6), busquemos la complejidad que de alguna manera es un
camino con futuro y no una que es tratar de sacarle jugo a una naranja
que ya se secó.

Cierto que algunas regiones no van a tener otra que vivir con los CGNs.
Yo sueño con que en la nuestra los veamos pasar de lejos, 'I have a
dream...' :-)

En una presentación de la mañana (en el evento de RIPE) alguien comentó
que un 'valor' importante que va a agregar IPv6 a su despliegue de CGN
es 'offloading', es decir, el trafico IPv6 va a salir nativamente y solo
va a hacer NAT de aquello que solo sea accesible por IPv4, de esa manera
quitandole carga al CGN.

Ahora puede parecer un grano de arena, pero en una Internet donde
Google, YouTube, Yahoo y Facebook son alcanzables nativamente en IPv6,
esto puede ser facilmente un 30-40% del trafico totoal, y si el "World
IPv6 Launch Day" es exitoso, podemos estar en esa situación en menos de
4 meses.

saludos!

Carlos

On 4/19/12 12:24 PM, Arturo Servin wrote:
> 	En parte tienes razón, pero también es cierto que los ambientes se han vuelto mucho más complejos y críticos.
>
> 	Yo bien recuerdo que en la red corríamos AppleTalk, IPv4 e IPX al mismo tiempo, en algunos lados con ethernet coaxial, en otros UTP con hubs y hasta Token Ring. El administrar la red podia ser mas complejo que ahora, pero también era mas aceptable tener tiempos de downtime mayores. Ni se diga que era más complejo que alguien te hackeara.
>
> 	De definitiva, creo que ahora nos quejamos mas y queremos las cosas mas fáciles, pero también los ambientes se han vuelto mas delicados y sobre todo competitivos, lo cual requiere exprimirle toda la eficiencia posible, lo cual incluye tratar de no correr dos stacks al mismo tiempo.
>
> Saludos,
> .as
>
>
> On 19 Apr 2012, at 05:27, Carlos Martinez-Cagnazzo wrote:
>
>> Hola!
>>
>> On 4/18/12 8:58 PM, Alejandro Acosta wrote:
>>> En estos casos traigo dos lemas a relucir:
>>>
>>> 1) Los problemas de hoy fueron las soluciones de ayer :)
>> Excelente, te voy a citar :-)
>>
>> Sin embargo (y aclaro que me gustó la presentación, y creo que es muy
>> aplicable), también creo que como operadores de redes nos hemos vuelto
>> haraganes.
>>
>> No me digan que en esta lista nadie se acuerda de cuando operábamos,
>> sobre la misma red IP, IPX/SPX y en algunos casos SNA también y (oh
>> dios) DECnet. Hace poco tiré los manuales del primer curso de Cisco que
>> hice, 1999 o algo asi,  donde uno de los topicos era justaamente como
>> operar una red multi-stack.
>>
>> No es cierto que la 'seguridad no importaba en esa epoca', uno de los
>> topicos cubria listas de acceso para IPX, justamente porque si habían
>> reparos al respecto.
>>
>> Y me atrevo a decir que IPv4 / IPv6 son lo suficientemente parecidos
>> como para p.ej. muchas de las reglas de firewall sean copy&paste (si uno
>> hace las cosas bien, claro, como definir variables para los
>> hosts/vlans). Van a haber algunas reglas residuales que son especificas
>> de c/u (DHCP vs RA p.ej.) pero la 'commonality' debería ser muy alta.
>>
>> Mucho mas que entre DECnet e IPv4 seguro.
>>
>> Nos hemos vuelto haraganes, definitivamente.
>>
>> s2
>>
>> Carlos
>>> 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
>>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> LACTF mailing list
> lactf at lac.ipv6tf.org
> https://mail.lacnic.net/mailman/listinfo/lactf