[lacnog] Tamaño de IPv6 Prefix Delegation para conexiones residenciales

Mar Nov 12 12:25:16 -02 2019

Hola jordi Gracias por la respuesta.
Algunos comentarios debajo

On 12/11/2019 06:45, JORDI PALET MARTINEZ via LACNOG wrote:
> <clip>
>
> 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.
>
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.
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.
>
> <clip>
>
> 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.
>
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.
>
>    <clip>
>
> 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).
>
> 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) ?
>
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.
>
> 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.
>
> Aún así, crees que un ISP que tiene un /31, o /30, tiene un grave 
> impacto en sus cuentas? Yo creo que no:
>
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.
>
> <clip>
>
>
> 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.
>
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.

Gracias
Fernando

> Pero insisto es una MALA EXCUSA de marketing/comercial, no un problema 
> ni técnico ni económico.
>
>     De todos modos, un punto en el que creo que todos estamos de 
> acuerdo es
>
>     que es incorrecto entregar solo uno /64 en conexiones 
> residenciales de
>
>     banda ancha, ¿verdad?
>
> 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.
>
>     Agradezco a quienes están involucrados en el tema y pueden 
> expresar sus
>
>     puntos de vista.
>
>     Saludos cordiales
>
>     Fernando Frediani
>
>     _______________________________________________
>
>     LACNOG mailing list
>
> LACNOG en lacnic.net
>
> https://mail.lacnic.net/mailman/listinfo/lacnog
>
>     Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
> **********************************************
> 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.
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20191112/a099f414/attachment.html>