<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font size="+1">Nico, Jordi, todos, una aclaración adicional.<br>
</font></p>
<p><font size="+1">Es correcto lo que menciona Nicolás sobre que los
asociados pagan de acuerdo a la categoría mayor entre el espacio
IPv4 e IPv6. Sin embargo, existe un waiver aprobado en la
asamblea de 2011 donde los asociados que están en la categoría
Micro en IPv4 pueden solicitar hasta un /32 de IPv6 sin cambiar
su categoría de membresía (este waiver se hizo extensivo también
a la categoría Nano en la asamblea de 2017). <br>
</font></p>
<p><font size="+1">O sea, los asociados que tienen hasta un /32
inclusive de IPv6 y están en las categorías Nano o Micro no
pagan por la categoría de IPv6 que sería Small, sino que se
mantienen pagando de acuerdo a la categoría que les corresponde
en IPv4 (Nano o Micro). <br>
</font></p>
<p><font size="+1">adjunto referencia a la sección de la web donde
se explican las cuotas de asociados y quedo a ls ordenes por
cualquier consulta adicional. <br>
</font></p>
<p><font size="+1"><a class="moz-txt-link-freetext" href="https://www.lacnic.net/2397/1/lacnic/categorias-y-cuotas-de-asociados">https://www.lacnic.net/2397/1/lacnic/categorias-y-cuotas-de-asociados</a>
<br>
</font></p>
<p><font size="+1">texo sobre waiver: </font><br>
<font size="+1"><em>En la Asamblea Ordinaria del 23 de mayo de
2017, celebrada en Foz de Iguazú (BR), se decidió mantener y
hacer extensivo a la nueva categoría Nano (creada en dicha
Asamblea), el waiver aprobado en la Asamblea Ordinaria del 19
de mayo de 2011 celebrada en Cancún (México) que establecía
que, los asociados que de acuerdo a los recursos IPv4
asignados se encuentren en la categoría Small/Micro (ahora
denominada solamente "Micro") y ahora también Nano, podrán
solicitar una asignación inicial de recursos IPv6 (/32) sin
cambiar su categoría de membresía.</em></font></p>
<p><font size="+1"></font><br>
</p>
<div class="moz-cite-prefix">El /1112/19 a las 13:29, Nicolas
Antoniello escribió:<br>
</div>
<blockquote type="cite"
cite="mid:CADHEbK_ZG+F_7sUZS6ZHsUM+vnXAjbbv0+v-L8en8FGOuQgbUw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>
<div dir="auto">Jordi y todos,</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Una aclaración que seguro el Staff de Lacnic puede
detallar más que yo:</div>
<div dir="auto"><br>
</div>
<div dir="auto">No es correcto decir que no se cobran las
direcciones IPv6 si tenés IPv4, entre otros porque eso sería
desventajoso para quienes tienen o tendrán solo IPv6.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Lo que sucede es que el costo de la membresía
(hablo por nuestra región) es acorde a la categoría de miembro
que depende del espacio total de direcciones que se tenga
delegado... cuanto mas espacio mas se aporta.</div>
<div dir="auto">En ese escenario, no se suman los espacios IPv4 e
IPv6 sino que la categoría corresponderá al espacio (entre IPv4
e IPv6) en el que se posean más direcciones delegadas.</div>
<div dir="auto">Es decir, si te corresponde categoría A por la
cantidad de espacio IPv4 delegado y te corresponde C (con C
mayor que A) por la cantidad de IPv6, entonces tu categoría es
la C.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Decir que son “gratis” puede dar lugar a
confusión. De todas formas yo no hablaría de costos de las
direcciones si no de aporte por la membresía, que no es lo mismo
aunque lo parezca.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Saludos,</div>
<div dir="auto">Nico</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">El El mar, 12 de nov. de
2019 a la(s) 13:19, JORDI PALET MARTINEZ via LACNOG <<a
href="mailto:lacnog@lacnic.net" moz-do-not-send="true">lacnog@lacnic.net</a>>
escribió:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="#0563C1" vlink="#954F72" lang="ES">
<div class="m_3690232870401171089WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt"
lang="ES-TRAD">Hola Fernando,</span></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:12.0pt" lang="ES-TRAD"> </span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:12.0pt;color:black"
lang="ES-TRAD">A mi se me olvido algo importante
tambien: desde hace muchos años, en al menos 3 de
los 5 RIRs (incluido LACNIC), no se cobran las
direcciones IPv6 a quienes tienen recursos IPv4.</span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:12.0pt;color:black"
lang="ES-TRAD">Es decir, de nuevo, es una excusa
no tener un prefijo mas adecuado a la necesidad
real de un ISP.</span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:12.0pt;color:black"
lang="ES-TRAD">Sigo debajo …</span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:12.0pt;color:black"
lang="ES-TRAD"> </span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt"
lang="ES-TRAD"> </span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"
lang="ES-TRAD"> </span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">El
12/11/19 16:45, "LACNOG en nombre de Fernando
Frediani" <<a
href="mailto:lacnog-bounces@lacnic.net"
target="_blank" moz-do-not-send="true">lacnog-bounces@lacnic.net</a>
en nombre de <a
href="mailto:fhfrediani@gmail.com"
target="_blank" moz-do-not-send="true">fhfrediani@gmail.com</a>>
escribió:</p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
</div>
<p style="margin-left:35.4pt">Hola Jordi<br>
<br>
Solo un breve comentario corto más. Me gustaría saber
la opinión de los demás.</p>
<p style="margin-left:0cm;text-indent:0cm"><span
style="font-size:12.0pt;font-family:Wingdings"><span>è<span
style="font:7.0pt "Times New Roman"">
</span></span></span><span
style="font-size:12.0pt">Si por favor!</span></p>
<p style="margin-left:35.4pt"><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?</p>
<p style="margin-left:0cm;text-indent:0cm"><span
style="font-size:12.0pt;font-family:Wingdings"><span>è<span
style="font:7.0pt "Times New Roman"">
</span></span></span><span
style="font-size:12.0pt">Es una cuestión de
facilidad de diseño. IPv6 “se invento” inicialmente
con 64 bits, los 64 bits adicionales son un regalo
para poder hacer todas estas cosas. Es algo que
están haciendo los fabricantes de dispositivos. No
vamos a “saber” que el dispositivo dentro tiene VMs
o cosas así.</span></p>
<p style="margin-left:35.4pt"><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. </p>
<p style="margin-left:0cm;text-indent:0cm"><span
style="font-size:12.0pt;font-family:Wingdings"><span>è<span
style="font:7.0pt "Times New Roman"">
</span></span></span><span
style="font-size:12.0pt">Si, ahí de acuerdo contigo.
Yo no me refiero a ese tipo de dispositivos.</span></p>
<p style="margin-left:35.4pt"><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.</p>
<ul type="disc">
<li><span style="font-size:12.0pt">El problema es:
Cuando los técnicos le damos a los departamentos
de marketing la opción de “vender” el /48 y
entregar el /56 por defecto … ya hemos creado el
problema! Y marketing y comercial buscará todas
las justificaciones posibles, incluso “1 céntimo
por cada usuario por año, son 1 millón de USD
porque tengo 1 millón de usuarios” … Si es así,
que le paguen ese millón de USD a LACNIC para
invertir mas en fomentar participación, NOGs,
etc., etc.</span></li>
</ul>
<p style="margin-left:35.4pt">Saludos<br>
Fernando</p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">On
12/11/2019 12:25, JORDI PALET MARTINEZ via LACNOG
wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:35.4pt"><span
class="m_3690232870401171089EstiloCorreo24"><span
style="font-size:12.0pt">Hola Fernando,</span></span><span
style="font-size:12.0pt"> </span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt" lang="ES-TRAD"> </span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:70.8pt">El
12/11/19 15:25, "LACNOG en nombre de Fernando
Frediani" <<a
href="mailto:lacnog-bounces@lacnic.net"
target="_blank" moz-do-not-send="true">lacnog-bounces@lacnic.net</a>
en nombre de <a
href="mailto:fhfrediani@gmail.com"
target="_blank" moz-do-not-send="true">fhfrediani@gmail.com</a>>
escribió:</p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:70.8pt"> </p>
</div>
<p style="margin-left:70.8pt">Hola jordi Gracias por
la respuesta.<br>
Algunos comentarios debajo</p>
<div>
<p class="MsoNormal" style="margin-left:70.8pt">On
12/11/2019 06:45, JORDI PALET MARTINEZ via LACNOG
wrote:</p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:70.8pt"><clip>
</p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span
style="color:black" lang="ES-TRAD"> </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><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></p>
</blockquote>
<p class="MsoNormal" style="margin-left:70.8pt">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.</p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt"> </span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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.</span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt"> </span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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.</span></p>
<p class="MsoNormal" style="margin-left:70.8pt"><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>
<br>
</p>
<p class="MsoNormal" style="margin-left:35.4pt"><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).</span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt"> </span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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.</span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt"> </span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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!</span></p>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span
style="color:black" lang="ES-TRAD"> </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span
style="color:black"> </span><span
style="color:black" lang="EN-US"><clip></span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span
style="color:black" lang="EN-US"> </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><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></p>
</blockquote>
<p class="MsoNormal" style="margin-left:70.8pt">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>
<br>
</p>
<p class="MsoNormal" style="margin-left:35.4pt"><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.</span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt"> </span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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.</span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt"> </span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt">Aunque mañana
decidiéramos descatalogar el uso de /48, el
proceso es el siguiente:</span></p>
<p class="m_3690232870401171089MsoListParagraph"
style="margin-left:71.4pt"><span>1)<span
style="font:7.0pt "Times New Roman"">
</span></span><span style="font-size:12.0pt">Adoptarlo
en IETF (1-2 años)</span></p>
<p class="m_3690232870401171089MsoListParagraph"
style="margin-left:71.4pt"><span>2)<span
style="font:7.0pt "Times New Roman"">
</span></span><span style="font-size:12.0pt">Que
los fabricantes que quieran lo implementen en
nuevos dispositivos (1-2 años)</span></p>
<p class="m_3690232870401171089MsoListParagraph"
style="margin-left:71.4pt"><span>3)<span
style="font:7.0pt "Times New Roman"">
</span></span><span style="font-size:12.0pt">Que
los fabricantes de dispositivos antiguos hagan
nuevas versiones de firmware (1-2 años)</span></p>
<p class="m_3690232870401171089MsoListParagraph"
style="margin-left:71.4pt"><span>4)<span
style="font:7.0pt "Times New Roman"">
</span></span><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.</span></p>
</blockquote>
</div>
</div>
<div link="#0563C1" vlink="#954F72" lang="ES">
<div class="m_3690232870401171089WordSection1">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt"> </span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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.</span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt"> </span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt">Crees que podemos pensar
que a corto-medio plazo, esto cambiaría?</span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt"> </span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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?</span></p>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
<clip></span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><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></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><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></p>
</blockquote>
<p class="MsoNormal" style="margin-left:70.8pt">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>
<br>
</p>
<p class="MsoNormal" style="margin-left:35.4pt"><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.</span></p>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><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></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><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></p>
</blockquote>
<p class="MsoNormal" style="margin-left:70.8pt">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>
<br>
</p>
<p class="MsoNormal" style="margin-left:35.4pt"><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!</span></p>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> </span></p>
<p class="MsoNormal" style="margin-left:70.8pt"><clip>
</p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><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></p>
</blockquote>
<p style="margin-left:70.8pt">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.</p>
<p style="margin-left:35.4pt"><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.</span></p>
<p style="margin-left:70.8pt">Gracias<br>
Fernando</p>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span
style="color:black" lang="ES-TRAD"> </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><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></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> De
todos modos, un punto en el que creo que todos
estamos de acuerdo es </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> que
es incorrecto entregar solo uno /64 en
conexiones residenciales de </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> banda
ancha, ¿verdad?</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><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></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> Agradezco
a quienes están involucrados en el tema y pueden
expresar sus </span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> puntos
de vista.</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
Saludos cordiales</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> Fernando
Frediani</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD"> _______________________________________________</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
LACNOG mailing list</span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
<a href="mailto:LACNOG@lacnic.net"
target="_blank" moz-do-not-send="true">LACNOG@lacnic.net</a></span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
<a
href="https://mail.lacnic.net/mailman/listinfo/lacnog"
target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a></span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a></span></p>
<p class="m_3690232870401171089MsoPlainText"
style="margin-left:70.8pt"><span lang="ES-TRAD">
</span></p>
<p class="MsoNormal" style="margin-left:70.8pt"><br>
**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a href="http://www.theipv6company.com"
target="_blank" 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>
<br>
</p>
<pre style="margin-left:70.8pt">_______________________________________________</pre>
<pre style="margin-left:70.8pt">LACNOG mailing list</pre>
<pre style="margin-left:70.8pt"><a href="mailto:LACNOG@lacnic.net" target="_blank" moz-do-not-send="true">LACNOG@lacnic.net</a></pre>
<pre style="margin-left:70.8pt"><a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a></pre>
<pre style="margin-left:70.8pt">Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a></pre>
</blockquote>
<p class="MsoNormal" style="margin-left:70.8pt">_______________________________________________
LACNOG mailing list <a
href="mailto:LACNOG@lacnic.net" target="_blank"
moz-do-not-send="true">LACNOG@lacnic.net</a> <a
href="https://mail.lacnic.net/mailman/listinfo/lacnog"
target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a>
</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"
target="_blank" 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>
</p>
<pre style="margin-left:35.4pt">_______________________________________________</pre>
<pre style="margin-left:35.4pt">LACNOG mailing list</pre>
<pre style="margin-left:35.4pt"><a href="mailto:LACNOG@lacnic.net" target="_blank" moz-do-not-send="true">LACNOG@lacnic.net</a></pre>
<pre style="margin-left:35.4pt"><a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a></pre>
<pre style="margin-left:35.4pt">Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a></pre>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt">_______________________________________________
LACNOG mailing list <a
href="mailto:LACNOG@lacnic.net" target="_blank"
moz-do-not-send="true">LACNOG@lacnic.net</a> <a
href="https://mail.lacnic.net/mailman/listinfo/lacnog"
target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a>
</p>
</div>
<br>
**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a href="http://www.theipv6company.com" target="_blank"
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>
</div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank"
moz-do-not-send="true">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote>
</div>
</div>
<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>
<div class="moz-signature">-- <br>
<h3 style="color:#009DCA;">Alfredo Verderosa</h3>
<p style="color:#8A8B8A;"><strong>Gerente de Servicios</strong><br>
Chief Services Officer</p>
<p style="color:#8A8B8A;"><em>LACNIC - <a
href="http://www.lacnic.net">www.lacnic.net</a><br>
Latin American and Caribbean Internet Addresses Registry</em></p>
</div>
</body>
</html>