[lacnog] Announcing Windows CLAT Public Preview

[jordi.palet en consulintel.es]

> El 30 jul 2026, a las 23:52, Fernando Gont <fgont en si6networks.com> escribió:
> 
> On 30/07/2026 06:23, jordi.palet--- vía LACNOG wrote:
>>> La premisa es simple:
>>> * Usar GUAs en los endpoints, cuando no lo necesitas, termina
>>> siendo en muchos casos una mala idea: + problemas de multihoming +
>>> problemas si tu operador renumera tu CPE, + y tambien hace
>>> (obviamente) que esos dispositivos sean direccionables desde
>>> Internet.
>> Si estamos diciendo que los prefijos deben ser persistentes, el
>> operador no esta haciendo al 100% correctamente su trabajo. Están
>> con mentalidad IPv4.
> 
> Dos cuestiones:
> 1. Hay multiples motivos por los cuales podes terminar en
>   flash-renumbering -- no hay un solo motivo.
> 
> 2. A quien le importa el motivo?  Si sos el host que se conecta a la
>   red, y eso es algo que no controlas, la cuestion de si el operador
>   esta haciendo bien su trabajo o no, si "esta con mentalidad IPv4",
>   etc., es irrelevante.
> 
>   Imaginate el caso de una empresa que opera en multiples
>   regiones/paises. Tenes que tener una solucion al respecto,
>   o deshabilitas IPv6. -- Nadie va a salir a perseguir ISPs,
>   analizar que mentalidad tienen, o inclusive leer mis RFCs.
> 
>   En el gran contexto de las cosas, las cosas funcionan bien,
>   o no lo hacen.
> 
> 

Así es, tu mismo lo has dicho. O se hacen bien o mejor no hacerlas, y eso es cuestión del ISP.

Si me pasa con un ISP y no con otro, podré decidir cambiar de ISP, mas si es una multinacional. Cada vez los usuarios son mas “expertos” en decidir si un ISP le conviene o no, así que es al propio ISP al que le compensa hacerlo de la forma mas apropiada y no necesariamente “a la antigua usanza”.

> 
> 
>> El tema de que los endpoints sean direccionales depende de que en el
>> CPE tengas activado por defecto un firewall, como debe ser. Si no
>> tienes un firewal, aun cuando estuvieras haciendo NAT/NPT, serian
>> direccionables.
>> Es evidente el problema de multihoming, porque en IPv4 lo hemos
>> resuelto con trampas como NAT,
> 
> Y a quien le importa eso?
> 
> El NAT es una solucione de ingenieria. Punto. Estamos hablando de
> ingenieria, no de filosofia.  Si algo soluciona un problema lo
> suficientemente bien, de forma cost-effective, es valido.
> 
> Tampoco pretendamos que IPv6 tiene un diseño limpio -- porque con solo
> mirar la configuracion automatica en IPv6, uno se da cuenta que no es el
> caso.
> 

Discrepamos, no se que % del IETF, o de los ingenieros, o del mundo estaría de acuerdo con tu forma de verlo o con la mía, así que nos podemos ahorrar las divagaciones.

> 
> 
>> pero la realidad es que aunque esa es la tendencia, esto no es un problema *por el momento* en usuarios residenciales.
> 
> 1. Depende para quien. Para todo aquel que al menos en tiempos de
>   pandemia quiso ahcer quick-and-dirty multihoming en la casa, fue un
>   problema -- concreto y real.
> 
> 2. Esto es definitivamente un problema real en entornos enterprise.
> 
> 3. Y es un problema real para cualquier organizacion que opere, por
> ejemplo, cosas autonomas -- IoT, robots, y similares.
> 
> 

Cualquier organización puede tener PI.

En LACNIC el staff entiende que si cuando se es también cuenta-propista o no es un ISP, aunque el manual de políticas dice que *solo se entregan recursos a organizaciones*.

Para particulares sin actividad económica, desafortunadamente, sólo en LACNIC la política se lo pone muy difícil, pues se queda a la merced de si la legislación de su país si puede obtener sin coste y casi sin esfuerzo un número de registro de “actividad” (aunque no sea mas que un home-lab). En ARIN es parecido, pero al parecer ese esfuerzo y coste es ridículo.

> 
>> En redes corporativas, independientemente de su tamaño, lo razonable
>> es ir al RIR correspondiente y obtener tu propia asignación directa
>> PI.
> 
> Razonable para quien?
> 
> En un sin-numero de organizaciones, esto es inviable.
> 
> 

Tendríamos que definir inviable. Económica y administrativamente es muy asequible. De hecho, puede ser algo que tramite el propio ISP o un consultor externo, no tiene porque haber conocimiento “técnico” en la organización.

> 
> 
>>> * Por ende, si no lo necesitas, no lo haces.
>> Efectivamente, por ende, si no necesitas que un dispositivo sea
>> direccionable, no abres puertos o la dirección completa en el
>> firewall. Si tienes un servidor web, para empezar tendrá un
>> dirección estable dentro del prefijo asignado, generalmente
>> manualmente configurada, y abrirás exclusivamente los puertos 80 y
>> 443 a esa dirección. Posiblemente agregarás en el firewall otras
>> reglas como rate limiting, etc.
> 
> 
> La discusion fue en el contexto de clientes. Si, en el caso de
> servidores, esta barbaro que tengas direcciones publicas + firewall.
> 
> En el caso de clientes (ejemplo workstations), los problemas pesan mas
> que las potenciales soluciones o use-cases.
> 
> 

No me queda claro si son clientes residenciales o de una organización, pero me parece negligente, en cualquiera de los casos que no haya firewall ni en el propio CPE.

> 
> 
>>> En muchos casos, riesgos y complicaciones varias, innecesarias.
>> Sólo si el operador o quien proporcione el CPE instala uno que no
>> tenga un firewall activado por defecto, ni mas ni menos exactamente
>> igual que en el caso de IPv4.
> 
> En el caso de IPv4, es diferente: El NAT resulta en un firewall por
> defecto que solo permite conexiones salientes.
> 
> 

Experimentos hace muchos años nos demostraban que no siempre era así. Por ejemplo muchos CPEs dejaban pasar “tal cual” el tráfico que no era TCP ni UDP, y por ende se podían hacer túneles 6in4 (protocolo 41), o basados en ICMP, etc. "No es oro todo lo que reluce”. Si un CPE no tiene opciones explicitas para configurar el firewall en otros protocolos … es muy poco fiable.

> 
> 
>>>>> Cuando muchísimos operadores residenciales cambian los
>>>>> prefijos IPv6 (no importa cada cuanto los cambian) muchas
>>>>> cosas se “rompen” en una red interna. Se puede resolver con
>>>>> DHCPv6 y NATv6 (o NAT66 con sus problemas) pero varios bien
>>>>> conocidos sistemas operativos no soportan algunos de esos
>>>>> protocolos.
>>>> En IPv6, lo normal sería NO cambiar los prefijos.
>>> No, no es lo normal. Hay muchos motivos: https://www.rfc-
>>> editor.org/rfc/rfc8978.pdf
>> Diría que ese documento precisamente aboga por los prefijos
>> persistentes.
> 
> No, no aboga por nada. Lo que dice basicamente es que hay multiples
> razones por las cuales podes tener prefijos efimeros, muchas de las
> cuales estan fuera de tu control. Y que por ende IPv6 deberia lidiar de
> forma "graceful" con esos escenarios.
> 
> Eso es lo que el documento dice.
> 
> 

Que conste que no he dicho en ningún momento que este en contra de todo ese trabajo, ni mucho menos.

> 
>>>> Este documento ha costado muchos años, pero parece que ahora
>>>> finalmente, tiene “momentum” para que se pueda hacer el Last
>>>> Call en poco tiempo: https://datatracker.ietf.org/doc/draft-ietf-
>>>> v6ops-prefix-to-end-sites/ <https://datatracker.ietf.org/doc/
>>>> draft-ietf-v6ops-prefix-to-end-sites/>
>>> Ignorar la realidad operacional no ayuda a nadie.
>> La realidad operativa depende de la experiencia y a veces de
>> decisiones que, desafortunadamente no son operativas, sino
>> comerciales. La experiencia que hay es con IPv4, donde si o si,
>> muchos operadores se vieron abocados a utilizar prefijos no-
>> persistentes.
> 
> 
> Repito: la realidad es la que es -- por decision, por omision, por
> error, por casualidad, o por lo que sea.
> 
> 
> Si yo tengo un producto que se conecta a Internet via IPv6, mi realidad
> operacional es el servicio que obtengo de mis ISPs -- el porque lo
> hacen, me resulta bastante irrelevante.
> 
> 

Y si no estoy contento, o veo que otros lo tiene mejor resuelto, me puedo cambiar.

> 
> 
>>>> Por otro lado, dado que NAT66, NPTv6, y derivados no son
>>>> estándares, sino implementaciones propietarias de fabricantes,
>>>> no se garantiza la interoperabilidad. Son protocolos
>>>> experimentales y los RFC experimentales dicen bien claro que NO
>>>> DEBEN SER USADOS EN PRODUCCION.
>>> IETF "especifico" los NATs cuando la realidad se la habia "llevado
>>> puesta", luego de negarlos y negarlos.  Cual fue el outcome?  --
>>> NAT fue y sigue siendo una tecnologia mucho mas desplegada que el
>>> propio IPv6.
>> Los tiempos cambian, afortunadamente, aunque valga la redundancia,
>> requiere tiempo. Caer en los mismos errores y problemas me parece
>> que es poco inteligente.
> 
> Festejar un 50% de despliegue luego de 30 años excede mi concencion de
> "optimismo".
> 
> 
> 
> 
> 
>>> Y no hace falta decirlo: IPv6 NAT *se usa en produccion* -- por
>>> mas que IETF argumente lo que quiera argumentar.
>>> Te digo mas: quien sea que este usando Kubernetes con soporte IPv6
>>> (tal vez la minoria, ya que en la mayor cantidad de casos, el
>>> soporte IPv6 lo tienen deshabilitado), estan usando ULA + NAT.
>>> -- dato, no relato.
>> Podemos enumerar cientos de implementaciones con fallos, errores,
>> etc., eso no los hace una realidad que todos deban usar en el resto
>> de implementaciones, mas bien una razón para huir de ello y utilizar
>> soluciones mejores.
> 
> 
> Dejame hacerte una pregunta directa, puntual, y clara: Si huis de la
> implementacion de k8s con ULA + NAT, a donde huis? IPv4-only kubernetes?
> 
> 

Creería que hay herramientas similares para poder hacerlo con docker, LXC. Pero no he dicho que no haya que usar k8s, mas cuando hasta donde recuerdo era un problema de implementaciones anteriores a 2025 (no estoy seguro de la fecha).

> 
> 
> 
>>>> Hay que hacer un reset, desaprender IPv4 para aprender IPv6. No
>>>> podemos seguir acarreando problemas y errores, por mucho que
>>>> pensemos que era la solución mas fácil. No lo era, era un parche
>>>> porque no había otro remedio.
>>> Esta es exacamente una de las razones por la cual, 30+ años mas
>>> tarde, el despliegue de IPv6 es lo que es:
>>> * No hay que desaprender nada. Lo que se deberia haber impulsado
>>> es reutilizar la mayor cantidad de conocimiento posible. -- es una estrategia mucho mas inteligente que pedirle a cualquier persona que tire por la borda 20+ años de experiencia en redes.
>> Cuando algunas costumbres de operación son incorrectas o no
>> apropiadas para una nueva realidad, hay que cambiar la mentalidad.
>> Vuelvo a insistir, en muchos casos esas costumbres son comerciales,
>> no técnicas.
> 
> Llegado el caso, en todo caso es cuestion de "ajustar cosas puntuales",
> y no de "desaprender", u "olvidar los conocimientos que tenemos de IPv4".
> 
> Y, en lo personal, deberia decir que eso deberia ocurrir en ambos
> sentidos. La autoproclamacionde que "la forma IPv6 de hacer las cosas es
> la forma correcta" es toxica y equivocada.
> 
> 

Entonces sigamos metiendo ratas muertas al hacer bebidas alcohólicas!

> 
>>> * En retrospectiva, es claramente un error (entendible a partir de sucesos historicos), haber cambiado tantas cosas para,
>>> basicamente, hacer lo mismo que en IPv4, solo que con direcciones
>>> mas grandes.
>> Discrepamos, lo que es un error es no querer adaptarse.
> 
> El error depende de donde lo mires.
> 
> Porque si la gran mayoria de personal con conocimeinto de redes tiene
> 20/30/40 años de experiencia de IPv4, y e Internet no puede actualmente
> prescindir de IPv4, claramente IPv6 no esta en posicion de poder para
> exigir quien debe adaptarse.
> 
> En muchos entornos donde he desplegado IPv6, justamente lo hago desde
> esa optica: causarle la menor cantidad de problemas y stress al resto
> del equipo.  Y en muchos de dichos entornos, la alternativa a eso
> hubiera sido IPv4-only.
> 
> 
> 
> 
>> Ayer de casualidad vi un programa en TV que hablaba de algunos
>> alcoholes que se hacían durante la ley seca utilizando técnicas
>> caseras, que incluso utilizaban ratas y otros animales muertos,
>> productos químicos insalubres, etc., para mejorar el sabor del
>> alcohol. Seguramente estaba buenísimo, no lo dudo, pero no era algo
>> apropiado.
> 
> La diferencia radica en que en tal caso la ciencia soporta un argumento o el otro, mientras que en el caso de IPv6 es mas bien una cuestion de preferencia personal, grupal, u "history artifact"?
> 
> Pequeña pero gran diferencia....
> 
> 

Bueno, entonces, la opción es que el que no quiera desplegar IPv6, no lo haga, nadie le obliga, que ponga decenas de niveles de CGN.

> 
> 
>> En cualquier campo de la vida o de la ingeniería, hay
>> “operatividades” que no son correctas, o que se van adecuando al
>> cambio de los tiempos y del conocimiento, y claro que cuesta mucho
>> cambiar la mentalidad, pero hay que hacerlo.
> 
> Discrepo, completamente.
> 
> Y de nuevo, un reality check: Para el publico, y una gran candidad de organizaciones, IPv6 no ocupa siquiera la prioridad numero #20.
> 
> 
> 
> 
>> La diferencia es que en todos esos campos casi siempre se termina
>> haciendo por legislación.
> 
> A fuerza de pistola, digamos? :-)
> 
> 

A fuerza de defender al consumidor con la regulación. Nos guste o no, esta para eso. Prefiero que Internet se autoregule, y siempre lo defenderé, pero siempre y cuando tras un plazo suficientemente amplio de tiempo, no perjudique al usuario por intereses que, al final de todo, son económicos.

> 
>> En Internet nos hemos dado el beneficio de
>> “ser libres de la ley y la regulación”, pero eso conlleva grandes
>> ventajas para los operadores (libertad casi absoluta) pero muchos
>> inconvenientes para los usuarios finales. Creo en la des-regulación
>> de Internet, pero también creo que la regulación, los gobiernos,
>> tienen una obligación para defender a los usuarios finales, y lo que
>> suele ocurrir, es que si se hace algo mal, con el tiempo, se termina
>> regulando para hacerlo mejor (no siempre bien, pero eso es otro
>> debate).
> 
> Nuevamente:
> 1. Impacto concreto para el usuario?
> 
> 2. Que hay de los problemas que se *intrudicen* para el usuario?
> 
> 3. Quien y porque decide el como y el cuando, y con que criterio?
> 
> 
> 
> 
> 
>>> * Si uno fuera a rediseñar IPv6 hoy en dia, poco de lo que hay en
>>> el diseño actual quedaria en el diseño final. Entonces, dejemos de vender que IPv6 es la tecnologia de networking revolucionaria o superadora, por que no lo es. -- esta bien argumentado desde hace
>>> mas de 25 años, inclusive en libros, tales como el el
>>> "Interconnections" de Perlman.
>> Creo que son discusiones filosóficas, y que cuando tomamos un
>> camino, acarreamos con lo bueno y lo malo. Otro camino pudiera haber
>> sido peor. Creo que es difícil que lleguemos a saberlo.
> 
> Muchas cosas no son filosoficas. Radia Perlman y John Day, por ejemplo, plantean cuestiones bien pragmaticas.
> 
> 
> Ejemplo: es "filosofico" el lio que tiene IPv6 en materia de configuracion automatica?
> 
> En absoluto. Es un producto que en aprte radica en sucesos historicos (DHCP se desarrollo *luego* que slaac), en no querer corrergir eso, y en un grupito de gente queriendo imponer -- cual Pinocho el dia que descubrio que estaba hecho de madera -- su forma preferida de implementar configuracion automatica.
> 
> 
> Por otro lado, cosas tales como multiples direcciones + happy eyeballs + source address selection tienen un grado de complejidad terriblemente alto -- usualmente resultando en un comportamiento erratico y no deterministico.  -- en otras palabras, algo ingnierilmente *muy malo*.
> 
> 

Por mi parte retiraría DHCPv6 (o dejaría solo DHCPv6-PD) y enriquecería SLAAC. Igualmente retiraría las ULAs, igual que hicimos con site-local.

> 
> 
>>> * Y si nos vamos a poner en "no podemos seguir acarrreando problemas"... la realidad es que, mas alla del mayor espacio de direcciones (y en consecuencia tener la posibilidad de asignar
>>> direcciones globales donde uno lo requiera), IPv6 no soluciona
>>> otros problemas... sino que en algunas atreas, inclusive introduce
>>> problemas nuevos.
>> IPv4 ha tenido y sigue teniendo muchos problemas. La diferencia es
>> que tenemos mas experiencia, pero esa experiencia no debe de ser
>> aplicada siempre de forma “literal” a nuevas tecnologías.
> 
> Lo que aprendimos en 30 años es que las direcciones deberian haber sido mas largas? :-)
> 
> 
> 
> 
>>> * No conozco una sola cosa perceptible por el usuario final que
>>> dependa del despliegue IPv6. Tampoco conozco mucha cosa
>>> "innovadora" que este dependiendo de IPv6 (pese a las historias o
>>> use-cases de ciencia-ficcion que estamos acostumbrados a
>>> escuchar). Por este motivo, muchas organizaciones terminan
>>> desplegando IPv6 de forma que "todo cambie lo menos posible" (o,
>>> inclusive, si y solo si las cosas cambian lo minimo posible). O,
>>> ante la falta de soluciones a problemas concretos, terminan
>>> postergando el despliegue. (modulo el tipo de organizaciones antes
>>> mencionado).
>> Tiempo al tiempo. Muchas tecnologías no necesariamente han
>> manifestado mejoras tangibles o al menos de forma inmediata, y sin
>> embargo, evolucionamos.
>> A mi también me gusta “no dejes para mañana lo que puedas hacer
>> hoy”, pero no siempre se puede!
> 
> Todo depende del cuando y dode:
> 
> * Si se trata de armar algo en tu casa con fines ludicos, perfecto.
> 
> * En un gobierno o institucion educativa, para bien o para mal,
>  usualmente tambien tenes ese margen.
> 
> * Ahora, en un entorno corporativo, algo que requiere muchos esfuerzo y
>  tiempo (etc., etc., etc.,) sin un impacto concreto en revenue, l
>  a cuestion no funciona. -- asi de simple.
> 
> 
> Y aclaro (por enesima): no es una cuestion si estoy de acuerdo (o no) o si me gusta (o no). Es lo que la realidad indica.
> 
> 
> 
> 
>>> * Con el tiempo, mientras muchos siguen con esa especie de
>>> "cruazada IPv6" con posturas fundamentalistas (que inclusiven
>>> obedecen a "principios" *fabricados*), IPv6 inclusive se vuelve
>>> menos interesante: sin ir mas lejos, hace años uno de los ejemplos/
>>> argumentos de momento era la limitacion en cantidad de conexiones
>>> concurrentes TCP que implicaba IPv4 -- con el ejemplo clasico de
>>> cuantas conexiones TCP eran necesarias para renderizar un mapa en
>>> Google. Que paso en el medio? -- QUIC.
>> Creo que no son cruzadas, sino irse preparando, sin prisa pero sin
>> pausa. Como he indicado antes, todo requiere tiempo e ir adquiriendo
>> experiencia. Cosas que antes podían verse como adecuadas o
>> “aceptables” no siempre lo son siempre.
> 
> No existe tal "colectivo" ("nos") apra el caso de una empresa. La empresa toma us propias decisiones, con el mismo criterio que toma muchisimas otras deciciones.
> 
> 

Así es, decisiones económicas, y si afectan al usuario, al final el gobierno/regulador tendrá que entrar a defenderlo. Podemos equiparar esto a todos los cambios en salud, educación, consumo, comunicaciones, energía, etc., etc., etc., que se han venido produciendo a lo largo de los años. Como he dicho antes, todo es evolutivo y si es el interior de tu red y no afecta al usuario: haz lo que quieras, pero no en caso contrario.

> 
>>> Si para empujar el despliegue hace falta "salir a presionar fabricantes", publicar mandatos para que los gobiernos fuercen el
>>> despliegue, o "sacar del mercado a un fabricante", me atreveria a
>>> pensar que estamos por el camino equivocado, y que hay algo que no
>>> estamos leyendo.
> >> >
>> Eso siempre ha sido así. Hay fabricantes que han caído por no hacer
>> las cosas como las necesitaba el mercado. Otros tardan, pero se
>> adaptan, pero esta claro que si los consumidores (y aquí en el caso
>> de CPEs suelen ser los ISPs) no piden e insisten en lo que es de
>> recibo, sólo curre con pocos fabricantes, y por tanto la oferta
>> puede no ser tan competitiva.
> 
> Alguien presiono a alguiena adoptar TCP/IP?

Si quieres participar en concursos públicos, si quieres conectarte al resto de Internet, etc. ...

> 
> Alguien presiona a las empresas hoy en dia a adoptar IA?
> 

El mercado, la competencia? Ni mas ni menos que lo que les ocurre a los ISPs.

> 
> (Creo que todos conocemos la respuestas a ambas preguntas).
> 
> 
> 
>>>>> El tema del uso de ULAs interno y NATv6 uno a uno (no SLAAC)
>>>>> no está muy bien aceitado en la mayoría de los sistemas
>>>>> operativos de routers domésticos por ejemplo, entonces no se
>>>>> puede usar correctamente en muchos casos.
>>>> Claro, ni lo estará por el momento. En IETF el consenso hasta
>>>> ahora (y se ha revisado hace menos de 2 años), es que es dar un
>>>> paso a tras, y no debe dejar de ser algo experimental.
>>> Brindemos por los proximos 30+ años de "despliegue" de IPv6,
>>> entonces.
>>> Es justamente esta postura, intransigente, la que ha hecho que el
>>> despliegue de IPv6 haya distado bastante de "exitoso" -- porque
>>> convengamos que si estamos festejando un %50 de despliegue luego
>>> de 30 años, con buena cantidad de estrategias fallidas, no hay
>>> mucho por festejar.
>> A mi también me duele que vayamos tan lento, ya lo he dicho antes,
>> pero nos encontramos ante decisiones mas comerciales que técnicas, y
>> eso pasa en todos los aspectos de la vida y el trabajo.
> 
> Toda solucion de ingenieria tiene que contemplar tanto lso aspectos tecnicos como economicos.
> 
> 
> 
> 
>>>> Para eso no hubiéramos desarrollado IPv6, mantén CGN en tu red y
>>>> poco a poco desconéctate del resto del mundo que ha optado ya en
>>>> el 65-70% por IPv6.
>>> No se puede tapar el sol con la mano. Hoy dia podes deshabilitar
>>> IPv6 en el mundo empresarial, y todo sigue como si nada. Lo cual
>>> obviamente no es el caso para IPv4.
>>> Toda una cantidad de cosas que veo (y tengo que lidiar con) en el
>>> dia a dia:
>>> * GitHub sin IPv6 * AWS sin PTRs para direcciones IPv6 * GCP
>>> metadata endpoint solo disponible en IPv4 en redes dual-stack *
>>> Slack sin IPv6
>>> ... y la lista continua, incluyendo GCP fallando de maneras
>>> ridiculas, porque en distntas partes de la plataforma comparaban
>>> las direcciones en formatos de presentacion diferentes.
>> Es evidente, que falta camino por andar, nadie lo ha negado.
> 
> Es que todo se resume a lo mismo:
> * Del lado del usuario, "todo esto no me funciona... asi que.. por que
>  voy a gastar mi tiempo en esto?"
> 
> * Del lado del vendor "No necesito IPv6 para mantener mis clientes o
>  ganas nuevos".
> 
> 
> 
> Vuelvo a la cuestion de contexto: la gran mayoria de la gente y organizaciones no tienen el lujo (?) que tenemos nosotros de dedicar tanto tiempo a IPv6.
> 
> 
> 

Crees que cuando cambia la regulación de normas de construcción, de seguridad en el trabajo, de tratamiento de los alimentos, etc., alguien tiene el lujo de poder dedicar el tiempo a estudiarlo? pero se ven obligados, primero no hay regulación, pero termina habiéndola. Es totalmente comparable. Me repito: evolución.

> 
> 
>> Por eso lo estoy actualizando! Muchos documentos de IETF necesitan
>> evolucionar, es normal, y ocurre con IPv4 y con cualquier protocolo:
>> Internet evoluciona, igual que lo hace todo el mundo y hay que
>> adaptarse, no permanecer en la operatividad a la que estamos
>> acostumbrados. De nuevo y no literal “hay que desaprender”.
> 
> El problema para cuando uno toma ciertas cosas como dogma.
> 
> Cuando alguien parte de la base de "el nat es maloooooooo!", termina "rascandose con la mano izquierda".
> 
> Para determinadas coass, el NAT es puede ser una solucion simple y cost-effective. Si uno parte de la premisa que "hay que evitar NAT a toda cosa", ya se empieza mal. -- y el resultado termina siendo la no-adopcion.
> 
> 
> Yo soy partidario que, en todo caso, algun tipo de despliegue (incluyendo con NAT, donde sea conveniente) es mejor que:
> 
> * Un no-despliegue (es decir, IPv4-only)
> 
> * Tirarle millones de detalles y problemas (slaac-renum, src address
>  selection, SLAAC, y otros) a equipos que tienen otras cuestiones
>  mucho mas centrales y prioritarias que atender.
> 
> 
> (Como analogia, si el dia de mañana Ferrari quisiera ser un producto masivo, deberia tener la capacidad de amigarse con la idea de vender autos negros, grises, azules (y otros tantos) )
> 

Por eso se ofreció SLAAC y DHCPv6. buena comparación!

No se si es comparable algo “estético” con algo técnico. SLAAC frente a DHCPv6 es un cambio de chip (por no repetir lo no literal de “desaprender”).

> 
> Slds,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont en si6networks.com
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
> 


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.