<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hola Jordi<br>
<br>
Solo un breve comentario corto más. Me gustaría saber la opinión
de los demás.<br>
<br>
Ejemplos como lo que ha citado de casos de máquinas virtuales que
necesitan recibir un exclusivo /64 son casos que, en mi opinión,
no deberían fomentarse, al menos no en un entorno doméstico o
empresarial simple. ¿Cuál es la necesidad real, por ejemplo, de
tener que asignar 1 x /64 a la VM si existe la posibilidad de unir
al mismo /64 que se utiliza para el resto de esa LAN en bridge?<br>
<br>
Una vez escuché de una propuesta (no recuerdo el nombre ni
siquiera convertido en estándar) que proponía entregar 1 x /64 a
cada dispositivo en la red (lámparas, dispositivos IoT, etc.), una
locura completa en mi opinión. <br>
<br>
No excluyo la posibilidad de que haya necesidades justificables,
pero no son la mayoría, lo que no justifica este sobre
dimensionamiento innecesario con la esperanza de que algún día
pueda haber más casos de este tipo.<br>
Lo que creo que puede haber es la voluntad del ISP de entregar
fácilmente un /48 al usuario que tiene justificación y uso.<br>
</p>
<p>Saludos<br>
Fernando<br>
</p>
<div class="moz-cite-prefix">On 12/11/2019 12:25, JORDI PALET
MARTINEZ via LACNOG wrote:<br>
</div>
<blockquote type="cite"
cite="mid:17B2AF78-1714-44FF-B028-2CD526C08C2C@consulintel.es">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \(Cuerpo en alfa";
panose-1:2 2 6 3 5 4 5 2 3 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Texto sin formato Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
pre
{mso-style-priority:99;
mso-style-link:"HTML con formato previo Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.TextosinformatoCar
{mso-style-name:"Texto sin formato Car";
mso-style-priority:99;
mso-style-link:"Texto sin formato";
font-family:"Calibri",sans-serif;}
span.HTMLconformatoprevioCar
{mso-style-name:"HTML con formato previo Car";
mso-style-priority:99;
mso-style-link:"HTML con formato previo";
font-family:Consolas;}
span.EstiloCorreo23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1470249954;
mso-list-type:hybrid;
mso-list-template-ids:-119910948 67764241 67764249 67764251 67764239 67764249 67764251 67764239 67764249 67764251;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style>
<div class="WordSection1">
<p class="MsoNormal"><span class="EstiloCorreo23"><span
style="font-size:12.0pt">Hola Fernando,</span></span><span
style="font-size:12.0pt;mso-fareast-language:EN-US"> <span
lang="ES-TRAD"><o:p></o:p></span></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="ES-TRAD"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">El 12/11/19
15:25, "LACNOG en nombre de Fernando Frediani" <<a
href="mailto:lacnog-bounces@lacnic.net"
moz-do-not-send="true">lacnog-bounces@lacnic.net</a> en
nombre de <a href="mailto:fhfrediani@gmail.com"
moz-do-not-send="true">fhfrediani@gmail.com</a>>
escribió:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<p style="margin-left:35.4pt">Hola jordi Gracias por la
respuesta.<br>
Algunos comentarios debajo<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">On 12/11/2019
06:45, JORDI PALET MARTINEZ via LACNOG wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:35.4pt"><clip> <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
style="color:black" lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
style="color:black" lang="ES-TRAD">Discrepo, si piensas en
asignar subredes de forma automática, en tener multiples
APs en un hogar, que a su vez pueden tener varias
subredes, etc., etc., la cuenta con /60 es ridícula,
insana, y con /56 se queda justa en seguida. Fíjate que,
en las encuestas, el % de operadores en el mundo que
entrega /48 es mucho mayor que el que entrega /56 y /60
(aunque esto es muy poco habitual) juntos. Por algo será.
Y en los países con mayor despliegue de IPv6 ese % es aún
mayor.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt">Un AP debe estar
conectado en puente no enrutado dentro de una red interna. Los
CPEs ni siquiera admiten el servidor DHCPv6-PD Server hoy.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Depende de
cada caso. Puedes tener diferente VLANs o SSIDs repartidos
en unos u otros APs. Depende incluso de cómo realizas la
conexión entre los APs. Homenet y otros protocolos intentan
resolver esto. Lo que esta claro es que no se puede tener
diferentes subredes con multiples niveles de NAT (que es lo
que se hace habitualmente en IPv4, cuando los usuarios no
saben, llegan y conectan APs). No hace falta DHCPv6-PD para
homenet.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Te recuerdo
que, además, cada vez habrá mas dispositivos que requieran
múltiples direcciones IPv6, porque tiene VMs, dockers, etc.
Y todo ello sin conocimiento del usuario, por lo tanto,
necesitas poder asignar a cada uno de esos dispositivos un
/64.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
Es legítimo separar redes distintas como LAN, Servidores,
VoIP, etc., pero no AP individuales en mi visión. Y para eso
16 o 256 redes veo que son más que suficientes para cualquier
escenario residencial o comercial estándar.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Insisto en
que 16 es muy muy escaso, una falacia. 256 podría ser en
muchos casos, pero es mejor ir a una reserva de un /48 y
entregar de momento solo un /56 si se tiene “miedo” de
agotar tus direcciones (que es una excusa, un pensamiento
“antiguo” con mentalidad de IPv4).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Todo lo que
hagamos para “reducir” el número de subredes que se les
entrega a los usuarios, implicará que las aplicaciones se
verán obligadas a “inventar” traducciones de IPv6.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Es un grave
perjuicio no solo para un ISP concreto, sino para la
humanidad. Queremos repetir los errores de IPv4 sin
necesitad de “ser tacaño” con las direcciones IPv6? Queremos
que en lugar de aprovechar la facilidad del desarrollo de
apps porque tienen direcciones suficientes, tengan que
buscar otra vez mecanismos basados en “triángulos” de
conexión (como los Skype supernodes), que lo único que hacen
es utilizar mas ancho de banda y crear problemas de
seguridad? Espero que no!<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoPlainText" style="margin-left:35.4pt"><span
style="color:black" lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
style="color:black"> </span><span style="color:black"
lang="EN-US"><clip></span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
style="color:black" lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
style="color:black" lang="ES-TRAD">Estas olvidando muchos
puntos importantes. Por ejemplo, que hay varios estándares
que tienen como tamaño de prefijo /48. Desde un simple
6to4 (no digo que se deba usar, sino que hay redes
configuradas con ello), hasta tunnel brokers, o cuando
usas ULAs (ejemplo homenet) para los casos de desconexión
de la red (interrupción del enlace, permite mantener la
conectividad interna). Si entregas un prefijo *diferente*,
todo el mapeo del plan de direccionamiento deja de
funcionar. Esta claro que por razones de seguridad
(dificultar el port scanning) y de crecimiento futuro de
la red (evitando renumeración), no es buena idea numerar
las subredes de forma consecutiva. Creo que son razones
objetivas.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt">Este es mi
punto. Esta no es la regla ni creo que lo sea (algunos de
ellos ya están en retiro) y habrá raros casos en los que un
/48 será justificable para estos usos. Sin embargo, si hay un
ISP, puede tener otra pool separada para asignar prefijos /48
solo a aquellos usuarios que lo soliciten. De lo contrario,
está tratando la regla por excepción.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Ninguno de
los mecanismos que usan /48 están descatalogados. Mucha
gente cree que 6to4 lo esta, pero no es así. Solo se ha
descatalogado el anycast de 6to4.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Sigue
habiendo tráfico peer-to-peer basado en 6to4 (y Teredo),
aunque no sea visible, precisamente de eso se trataba.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Aunque
mañana decidiéramos descatalogar el uso de /48, el proceso
es el siguiente:<o:p></o:p></span></p>
<ol style="margin-top:0cm" type="1" start="1">
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l0 level1 lfo1"><span
style="font-size:12.0pt">Adoptarlo en IETF (1-2 años)<o:p></o:p></span></li>
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l0 level1 lfo1"><span
style="font-size:12.0pt">Que los fabricantes que quieran
lo implementen en nuevos dispositivos (1-2 años)<o:p></o:p></span></li>
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l0 level1 lfo1"><span
style="font-size:12.0pt">Que los fabricantes de
dispositivos antiguos hagan nuevas versiones de firmware
(1-2 años)<o:p></o:p></span></li>
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l0 level1 lfo1"><span
style="font-size:12.0pt">Que los usuarios o ISPs
actualicen el firmware (1-2 años) o que esos equipos
“mueran” o sean reemplazados.<o:p></o:p></span></li>
</ol>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Cuando
empecé a trabajar en el RFC8585, estuve buscando muchos
documentos, estudios, etc., para entender cuanto tardaban en
actualizarse los CPEs “por inercia” (es decir, no cambios a
propósito realizados por los ISPs). La conclusión es que el
90% de los CPEs, después de 1-2 años, no es actualizado con
nuevas versiones de firmware. Y que el 80% de los CPEs
sobreviven y siguen funcionado durante unos 10 años de
media. Esto no incluye el reemplazo de CPEs cuando se cambia
la tecnología de acceso, por ejemplo, de ADSL a GPON.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Crees que
podemos pensar que a corto-medio plazo, esto cambiaría?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Lo que tu
indicas, obligaría también a cambiar las ULAs de /48 a otra
cosa. Posiblemente “inventar” diversas categorías de ULAs.
Crees que va a prosperar en IETF?<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> <clip></span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD">No entiendo esto. La sparse allocation, tal
y como la utilizan los RIRs, permite que si un ISP pidió
un /32 y ahora necesita hasta un /28, pueda, sin
renumerar, recibirlo (creo que es la reserva que aplica
LACNIC como mínimo). Si un ISP necesita mas, podrá recibir
un prefijo mas grande y se le reserva otro espacio igual
contiguo, o uno que complete la suma de lo que necesite.
Es decir, como mucho anunciaría 2 prefijos. Las políticas
le permiten "cambiar" su prefijo (lo cual solo suele ser
razonable si tenía un /32 que solo utilizó en pruebas,
hasta que empezó el despliegue de verdad).</span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD">Si es cierto que un ISP no aprovecha el
100% del /32, por eso yo siempre hago una cuenta "media"
con 50.000 posibles clientes (número que me ha dado la
experiencia de muchos casos desde el año 1999), no 65.000,
y aquí viene la pregunta clave. Cuantos ISPs tienen mas de
5.000 clientes en LACNIC ? Cuantos mas de 50.000? Cuanto
mas de 100.000 (/31) o mas de 200.000 (/30) ?</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt">Esta no es la
cuenta que hago. Si tomamos un /32 y lo dividimos en 16 x /36,
ese número ya cae a 4096 por /36 y, dependiendo del alcance y
la forma de organización de este ISP, una parte de esos /36 no
podrá usarlos todos para conexiones domésticas. Entonces el
número de 50,000 parece sobrevalorado. Como resultado, un ISP
necesitaría solicitar otro /32 (y cambiar las categorías)
mucho antes de llegar a este número de clientes.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Discrepo en
la forma de hacer ese plan de numeración. Hay que empezar
por el POP mas pequeño y que los mas grandes que ese, sean
múltiplos del mismo. He hecho muchos, muchos, muchos,
muchísimos … planes de numeración y el secreto es mínimo
común denominador, no máximo y agregar hacia arriba. Cuando
pueda terminaré el documento que estoy preparando, un BCOP
para planes de numeración. Posiblemente si no tengo que
estar trabajando en navidades será mi tarea de navidad.<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD">Creo que no hay un problema real, y de
haberlo, esto se escapa de mejores practicas o de
políticas, sería cuestión de que la membresía re-calcule,
si es apropiado cobrar 5.700 por un /31 (es mas del doble
de los 2.100 por un /32), o 14.000 por un /29 o /30, etc.</span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD">Aún así, crees que un ISP que tiene un /31,
o /30, tiene un grave impacto en sus cuentas? Yo creo que
no:</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt">Tal vez no tanto
como pueda parecer, pero no es algo que el ISP pueda
simplemente ignorar porque el tiempo para solicitar otra
asignación y cambiar la categoría ocurre mucho antes y si
entrega /48 prefijos por defecto incluso antes.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Eso es un
problema de capacitación, porque hay políticas que permiten
el cambio, etc. Como muchos de los problemas que tenemos en
cualquier despliegue de redes. Veo gente que hace
capacitaciones *<b>sin</b>* experiencia real en despliegue y
operación de IPv6. Y ahí están los resultados!<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><clip> <o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
style="color:black" lang="ES-TRAD">El otro problema es que
al entregar un /56 a todos los clientes, no reservan el
/48, y por lo tanto, no siempre el sistema de
provisionamiento les permite crear una “ruta” específica
para proveer al cliente que lo pide un /48 de otro pool.
Por eso en RIPE690 recomendamos que se haga el plan de
numeración con /48 y si solo quieres entregar un /56,
reserves el /48 completo, y evitas el problema.</span><o:p></o:p></p>
</blockquote>
<p style="margin-left:35.4pt">Nuevamente, creo que si haces eso,
estarás lidiando con la regla por excepción. Creo que esta
recomendación de RIPE690 es innecesaria y si su ISP entrega un
/56 o un /60 por defecto, puede reservar fácilmente otra pool
separada para entregar esos *pocos* prefijos /48 donde se
justifique.<o:p></o:p></p>
<p><span style="font-size:12.0pt">A vece depende del sistema de
provisionamiento. En la mayoría de los casos que he visto,
es mas fácil manejar un solo pool con clientes divididos en
varios grupos, y así agregas más y evitas renumerar al
cliente si tiene que pasar de un /56 a un /48. Creo que
además eso es lo más apropiado. Evitas multiplicar x2 totas
las rutas internas.<o:p></o:p></span></p>
<p style="margin-left:35.4pt">Gracias<br>
Fernando<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoPlainText" style="margin-left:35.4pt"><span
style="color:black" lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
style="color:black" lang="ES-TRAD">Pero insisto es una
MALA EXCUSA de marketing/comercial, no un problema ni
técnico ni económico.</span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> De todos modos, un punto en el que creo
que todos estamos de acuerdo es </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> que es incorrecto entregar solo uno /64
en conexiones residenciales de </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> banda ancha, ¿verdad?</span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD">Correcto! Y observemos que todo este
problema viene de una sola razón: Estamos pensando en IPv4
cuando desplegamos IPv6 y por ese camino no resolvemos
nada. Hay que cambiar el chip, igual que cuando hablamos
de direcciones dinámicas en IPv4, y en IPv6, lo correcto
es que sean persistentes, pero claro, con las dinámicas,
el que la quiere persistente le cobramos por ello … De
nuevo, a cuenta de que? Es una grave anomalía.</span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> Agradezco a quienes están involucrados
en el tema y pueden expresar sus </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> puntos de vista.</span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> Saludos cordiales</span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> Fernando Frediani</span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> _______________________________________________</span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> LACNOG mailing list</span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> <a href="mailto:LACNOG@lacnic.net"
moz-do-not-send="true">LACNOG@lacnic.net</a></span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> <a
href="https://mail.lacnic.net/mailman/listinfo/lacnog"
moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a></span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a></span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:35.4pt"><span
lang="ES-TRAD"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a href="http://www.theipv6company.com"
moz-do-not-send="true">http://www.theipv6company.com</a><br>
The IPv6 Company<br>
<br>
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.<br>
<br>
<br>
<br>
<o:p></o:p></p>
<pre style="margin-left:35.4pt">_______________________________________________<o:p></o:p></pre>
<pre style="margin-left:35.4pt">LACNOG mailing list<o:p></o:p></pre>
<pre style="margin-left:35.4pt"><a href="mailto:LACNOG@lacnic.net" moz-do-not-send="true">LACNOG@lacnic.net</a><o:p></o:p></pre>
<pre style="margin-left:35.4pt"><a href="https://mail.lacnic.net/mailman/listinfo/lacnog" moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a><o:p></o:p></pre>
<pre style="margin-left:35.4pt">Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt">_______________________________________________
LACNOG mailing list <a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a> Cancelar
suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a> <o:p></o:p></p>
</div>
<br>
**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com">http://www.theipv6company.com</a><br>
The IPv6 Company<br>
<br>
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.<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</body>
</html>