<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hola jordi Gracias por la respuesta.<br>
Algunos comentarios debajo<br>
</p>
<div class="moz-cite-prefix">On 12/11/2019 06:45, JORDI PALET
MARTINEZ via LACNOG wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DF6A52CD-4905-478D-B365-C6D287AB25CB@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;}
/* 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;}
span.TextosinformatoCar
{mso-style-name:"Texto sin formato Car";
mso-style-priority:99;
mso-style-link:"Texto sin formato";
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style>
<div class="WordSection1"><clip><span lang="ES-TRAD"><o:p></o:p></span>
<p class="MsoPlainText"><span style="color:black" lang="ES-TRAD"><o:p> </o:p></span></p>
<p class="MsoPlainText"><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>
</div>
</blockquote>
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.<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>
<blockquote type="cite"
cite="mid:DF6A52CD-4905-478D-B365-C6D287AB25CB@consulintel.es">
<div class="WordSection1">
<p class="MsoPlainText"><span style="color:black" lang="ES-TRAD"><o:p></o:p></span></p>
<p class="MsoPlainText"><span style="color:black" lang="ES-TRAD"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="color:black" lang="EN-US">
<clip><o:p></o:p></span></p>
<p class="MsoPlainText"><span style="color:black" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><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>
</div>
</blockquote>
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>
<blockquote type="cite"
cite="mid:DF6A52CD-4905-478D-B365-C6D287AB25CB@consulintel.es">
<div class="WordSection1">
<p class="MsoPlainText"><span style="color:black" lang="ES-TRAD"><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> <clip><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"><o:p> </o:p></span></p>
<p class="MsoPlainText"><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).<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"><o:p> </o:p></span></p>
<p class="MsoPlainText"><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>
</div>
</blockquote>
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>
<blockquote type="cite"
cite="mid:DF6A52CD-4905-478D-B365-C6D287AB25CB@consulintel.es">
<div class="WordSection1">
<p class="MsoPlainText"><span lang="ES-TRAD"><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"><o:p> </o:p></span></p>
<p class="MsoPlainText"><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.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"><o:p> </o:p></span></p>
<p class="MsoPlainText"><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>
</div>
</blockquote>
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>
<blockquote type="cite"
cite="mid:DF6A52CD-4905-478D-B365-C6D287AB25CB@consulintel.es">
<div class="WordSection1">
<p class="MsoPlainText"><span lang="ES-TRAD"><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"><o:p> </o:p></span></p>
<clip><span lang="ES-TRAD"><o:p></o:p></span>
<p class="MsoPlainText"><span lang="ES-TRAD"><o:p> </o:p> <br>
</span></p>
<p class="MsoPlainText"><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>
</div>
</blockquote>
<p>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>Gracias<br>
Fernando<br>
</p>
<blockquote type="cite"
cite="mid:DF6A52CD-4905-478D-B365-C6D287AB25CB@consulintel.es">
<div class="WordSection1">
<p class="MsoPlainText"><span style="color:black" lang="ES-TRAD"><o:p></o:p></span></p>
<p class="MsoPlainText"><span style="color:black" lang="ES-TRAD"><o:p> </o:p></span></p>
<p class="MsoPlainText"><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.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> De todos modos,
un punto en el que creo que todos estamos de acuerdo es <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> que es
incorrecto entregar solo uno /64 en conexiones residenciales
de <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> banda ancha,
¿verdad?<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"><o:p> </o:p></span></p>
<p class="MsoPlainText"><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.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> Agradezco a
quienes están involucrados en el tema y pueden expresar sus
<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> puntos de
vista.<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> Saludos
cordiales<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> Fernando
Frediani<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> _______________________________________________<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> LACNOG mailing
list<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD">
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD">
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> 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></span></p>
<p class="MsoPlainText"><span lang="ES-TRAD"> <o:p></o:p></span></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>