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

[JORDI PALET MARTINEZ]

Hola Fernando,

 

 

 

El 12/11/19 3:53, "LACNOG en nombre de Fernando Frediani" <lacnog-bounces en lacnic.net en nombre de fhfrediani en gmail.com> escribió:

 

    Hola a todos.

    

    Me gustaría hacer una provocación aquí (una sana provocación para 

    discutir el asunto) principalmente para aquellos con quienes hablé 

    recientemente, especialmente durante el último LACNIC con respecto a qué 

    prefijo entregar a los clientes residenciales para el PD.

    

    Tengo muy claro que lo que sea /56 o /60 se ve muy bien y satisface la 

    necesidad de la gran mayoría de los casos de uso residencial o 

    comercial. Me parece absurdo grande y una exageración entregar /48 en 

    una conexión residencial.

 

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.

 

    En las discusiones que tuve uno de los argumentos para defender esto es 

    que 1) no es necesario guardar IPv6 y que si se entregan /48 las 

    direcciones no se agotarán en muchos años 2) hay situaciones específicas 

    en las que un /48 puede ser útil.

 

Respecto del tiempo de vida de IPv6, revisa esta cuenta, y me dices si crees que agotaremos IPv6 por entregar /48 es irrealista (y hablo de asignar /48 por persona, no por sitio, es por facilitar la cuenta, obviamente la realidad es que habría de dividir el número de personas por 3-4 que es la media de personas por hogar en el mundo y mas asumiendo que llegar a esa población es un poco difícil salvo que vivamos de pie todos apretados ...):

 

A /3 contains:                                     35.184.372.088.832 /48

 

50% utilization:                                              17.592.186.044.416 /48

 

32 billons population:                                    34.359.738.368 humans

 

Average life expectation:                                          100 years

 

Let’s give each human:                                  1 /48   -> 51.200 years

                                                                       4 /48   -> 12.800 years

 

Let’s use all the space:                                              8 /3 (x 8)

 

Let’s give each human:                                  1 /48   -> 409.600 years

                                                                       4 /48   -> 102.400 years

 

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.

    

    Para el primer argumento, no creo que el punto sea simplemente guardar o 

    no, sino hacer un uso racional de los recursos disponibles, incluso si 

    son abundantes. Pero si eso no es suficiente, puedo ofrecer otro 

    argumento un poco más objetivo para la realidad de LACNIC.

 

Los RIRs deben dar preferencia en IPv6, tal y como dicen los manuales de políticas, a la agregación frente a la conservación (al revés que en IPv4). Entregar prefijos mas pequeños puede implicar lo contrario, y por tanto sería contrario a las políticas.

    

    De acuerdo con las categorías de membresía de LACNIC 

    (https://www.lacnic.net/2397/1/lacnic/categorias-y-cuotas-de-asociados) 

    si la organización recibe un solo /32, puede permanecer en la misma 

    categoría que se basó en asignaciones de IPv4, pero si necesita recibir 

    mas de un /32 puede tener que ir a la categoría Medium, lo que significa 

    más del doble de lo que está pagando. Aunque se puede decir que dentro 

    de un /32 se ajustará a aproximadamente 65,000 /48, sabemos que esta no 

    es la exacto ya que partes del /32 deben usarse para fines distintos de 

    los clientes residenciales, lo que reduce en gran medida este número. E 

    incluso si RIR lo hace sparse allocation siempre existe el riesgo de un 

    aumento innecesario en el número de rutas en la tabla de enfrentamiento 

    global dependiendo de la estrategia de la organización para anunciar las 

    nuevas asignaciones recibidas.

 

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) ?

 

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:

 

He hecho un Excel para calcular el coste medio de la cuota anual de LACNIC (asumiendo 50.000 clientes para un /32) y sin contar los otros beneficios que recibe (ASN, recursos IPv4, resolución inversa, capacitación, eventos, etc., etc., etc.). En esta tabla, hay una columna suponiendo que el ISP tiene ya esos 50.000 clientes (por cada /32), o solo el 10% (5.000), o 25% (12.500), o 50% (25.000) de los mismos:

 

PrefijoCosteCoste clienteCoste clienteCoste clienteCoste cliente
USD50.00010%25%50%
322.1000,042000,420000,168000,08400
315.7000,057000,570000,228000,11400
3014.0000,070000,700000,280000,14000
2914.0000,035000,350000,140000,07000
2828.0000,035000,350000,140000,07000
2728.0000,017500,175000,070000,03500
2665.0000,020310,203130,081250,04063
2565.0000,010160,101560,040630,02031
24105.0000,008200,082030,032810,01641
23105.0000,004100,041020,016410,00820
22185.0000,003610,036130,014450,00723
21185.0000,001810,018070,007230,00361
20345.0000,001680,016850,006740,00337

 

 

Creo que queda claro que, en todo caso, el mas perjudicado es el que tiene un /32 y solo tiene 5.000 clientes (por ejemplo).

 

Si es cierto que hay desproporción en los saltos entre /32 al /31, /31 y /30, y un salto “raro” en el caso del /27 ... habría que hacer esta tabla completa para todos los casos. Pero insisto, ten en cuenta que, de esa cuota, para hacer las cuentas bien, habría que restar un "fijo" (igual en todos los casos) para el mantenimiento de la organización. Quizás eso son 1.000 USD, y hay que estudiar si es razonable que los que mas tienen "contribuyan mas" como los impuestos (le cuestan mas dinero, en una pequeña proporción, a LACNIC).

 

Creo que aun en el caso del ISP que tiene un /32 y solo tiene 5.000 clientes, es ridículo pensar que le afecta en sus cuentas pagar un /31, porque ese ISP NO necesita un /31. En el caso de un ISP que tiene 60.000 clientes y asigna /48, lo razonable sería un /31, y la diferencia de costo anual, es también irrazonable como EXCUSA para no asignar un /48.

 

    Para el segundo argumento de situaciones que pueden requerir una gran 

    cantidad de /64 dentro de una red doméstica, creo que hoy en día son 

    raras excepciones tener un ambiente residencial o incluso comercial 

    donde sea necesario. Personalmente considero que este tipo de 

    iniciativas deberían no convertirse en un estándar. Sin embargo, si 

    algún cliente residencial particular tiene una justificación para 

    recibir un /48, no veo muchos problemas para asignarlo sin mucho 

    esfuerzo, ya que habrá muy pocos casos en los que esto ocurra. Por lo 

    tanto, entregar /48 por defecto sería tratar la regla por excepción.

 

El problema es que los ISPs pretenden usar la longitud del prefijo como excusa para cobrar mas o menos y eso no es razonable, salvo que hablemos de lo que le cuesta al ISP pagar eso a LACNIC, es decir un ISP que tiene 60.000 clientes y en lugar de un /32 tiene un /31, sería razonable que le cobre al cliente la diferencia (0,057-0,042), pero más? A cuenta de que?. El coste del servicio debe estar basado en el servicio NO en los recursos de Internet que son un bien de la humanidad y no tenemos escasez de ellos.

 

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.

 

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.

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20191112/9da54cf2/attachment-0001.html>