[LAC-TF] Fwd: RE: IPv6 networking: Bad news for small biz

Sat Apr 7 23:58:42 BRT 2012

2012/4/7 Luis Carlos Solano <lsolano at racsa.co.cr>:
> Lo que más me gusta de artículos como este, es la versión realista del
> asunto.
>
> De lo peor que tiene IPv6 es incorrecta divulgación en la cual se le ve como
> un gran sucesor de IPv4, que "corrige" todos los problemas de v4 y que única
> y exclusivamente trae beneficios lo cual es evidentemente falso.
>
> Yo soy un impulsor de IPv6, me encanta el tema, lo promuevo y les contaré un
> día de estos de un programa que estoy impulsando para la adopción de IPv6 en
> instituciones del sector Gobierno en Costa Rica; pero cuando damos las
> charlas y hacemos los labs, siempre trato de comunicar una versión realista.
>
> A veces es quizá decepcionante para los asistentes a las charlas de IPv6 que
> impartimos cuando al final aprenden que la verdadera razón por la que IPv6
> debe (pues efectivamente *debe*) implementarse está basada en el hecho que
> 128 > 32.
>
> Esta pregunta del NAT es una que siempre sale, y eso de renumerar con el
> cambio de proveedor resulta absurdo para cualquier empresa. Creo que el NAT
> 1:1 es la solución, a pesar que rompe que el sueño de visibilidad de
> fin-a-fin.
>
> Pensemos en esto: existen hoy equipos para uso de pequeñas empresas (que los
> venden hasta en ciertos supermercados), que permiten poner dos servicios de
> diferentes proveedores y simplemente funcionan. Si ambos proveedores están
> operando, balancea el tráfico y si uno se cae, simplemente, sigue trabajando
> por el otro. Que dirían de esta facilidad los detractores a ultranza del
> NAT?
>
> Saludos!
>
> --
> Luis Carlos.
>
>

Coincido con lo que dice Luis Carlos sobre el balanceo de cargas con
Nat, pero hay que aclarar que eso no sería necesario si una empresa
pequeña tuviera a su disposición una asn para manejar su propia zona
autónoma, tendría todas las ventajas del balanceo de cargas con nat
con la diferencia de que con ipv6 los hosts dentro de la zona no
serían solamente clientes sino también servidores. Creo que por el
momento Nat presenta ciertas soluciones muy cómodas, económicas y
fáciles de implementar pero a muy largo plazo pueden ser reemplazadas.
Saludos
Cristian
>
>
>
> On 4/6/12 9:46 PM, Alejandro Acosta wrote:
>>
>> Hola Fernando,
>>   Que bueno que sacas este tema a colacion, yo estaba a punto de hacerlo.
>>   Me recuerda el otro thread de nanog donde solo leyendo uno aprendia
>> mucho sobre redes, en este caso se aprende mucho sobre la historia de
>> IPv6, problemas actuales, que se hizo bien o mal en la IETF durante su
>> desarrollo etc. Yo estoy de acuerdo en muchas cosas y en otras no,
>> ciertamente IPv6 como esta ahora es como se va a quedar, hay
>> comentarios que parece que la gente quisiera que IPv6 solucionara
>> todos sus problemas, cosa que no es -ni sera- asi.
>>    Lo malo que haya tenido el protocolo en sus inicios ya no se puede
>> hacer nada, eran los anos 90', imposible era predecir el crecimiento
>> de Internet y si NAT iba a ser exitoso o no. Es el mismo caso con las
>> cosas "malas" de IPv4 y su realidad hoy.
>>   Sobre el articulo original que trajo todo este tema
>> (http://www.theregister.co.uk/2012/03/31/ipv6_sucks_for_smes/) dicen
>> cosas muy ciertas pero una vez mas IPv6 no puede solucionarlo todo. El
>> punto mas interesante desde mi humilde perspectiva es la parte de
>> renumbering.
>>   El link del thread en cuestion, recomendado:
>>
>> https://www.ietf.org/ibin/c5i?mid=6&rid=48&gid=0&k1=933&k3=11189&tid=1333770254
>>
>> Saludos,
>>
>> Alejandro,
>>
>>
>> On 4/5/12, Fernando Gont<fernando at gont.com.ar>  wrote:
>>>
>>> FYI.
>>>
>>> Hay un thread mas que interesante en la lista general de la IETF.
>>> ietf at ietf.org.
>>>
>>> Acá reenvío uno de los msgs posteados. Recomiendo leer los de Randy
>>> Bush, con los que seguramente se van a divertir (o no :-) ) un rato.
>>>
>>> Saludos,
>>> Fernando
>>>
>>>
>>>
>>>
>>> -------- Original Message --------
>>> Subject: RE: IPv6 networking: Bad news for small biz
>>> Date: Thu, 5 Apr 2012 01:52:33 +0000
>>> From: Christian Huitema<huitema at microsoft.com>
>>> To: Noel Chiappa<jnc at mercury.lcs.mit.edu>, "ietf at ietf.org"<ietf at ietf.org>
>>>
>>>> Part of the real problem has been that the IETF failed to carefully
>>>> study, and take to heart, the operational capabilities which NAT
>>>> provided (such as avoidance of renumbering, etc, etc), and then
>>>> _failed to exert every possible effort_ to provide those same
>>>> capabilities
>>>> in an equally 'easy to use' way.
>>>
>>> I agree with Noel on that one -- as surprising as it may sound. The IETF
>>> did recognize several problems, from privacy to renumbering to
>>> multi-homing, but the quality of the proposed solutions has been uneven.
>>> The IPV6 response to privacy protects the host with privacy addresses,
>>> but exposes internal network routes. Renumbering works fairly well in
>>> small networks, but does not provide a replacement for folks who insist
>>> in hardwiring IP addresses into filters. The response to multi-homing
>>> requires an additional layer of protocol in the hosts and is probably 15
>>> years from being deployed.
>>>
>>> Of course, NAT does not really solve multi-homing either -- it is one of
>>> the points where the brittleness is most apparent. But NAT's do hide the
>>> internals of a network, and do isolate networks from renumbering issues.
>>> NAT also break lots of applications, which is why so many of us hate
>>> them. But so do firewalls, and it seems that IPv6 firewalls are
>>> encouraged. Oh well.
>>>
>>> -- Christian Huitema
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> --
> Luis Carlos
>
>
> _______________________________________________
> LACTF mailing list
> lactf at lac.ipv6tf.org
> https://mail.lacnic.net/mailman/listinfo/lactf