[lacnog] Tamaño de IPv6 Prefix Delegation para conexiones residenciales
Fernando Frediani
fhfrediani en gmail.com
Mar Nov 12 14:40:31 -02 2019
Correcto Jordi y Nicolas.
Lo que pasa es que en la Asamblea Ordinaria del 23 de mayo de 2017,
celebrada en Foz de Iguazú (BR), se decidió 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.
Entonces esto es válido para 1 x /32 y no 2
Fernando Frediani
On 12/11/2019 13:29, Nicolas Antoniello wrote:
> Jordi y todos,
>
> Una aclaración que seguro el Staff de Lacnic puede detallar más que yo:
>
> 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.
>
> 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.
> 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.
> 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.
>
> 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.
>
> Saludos,
> Nico
>
>
>
> El El mar, 12 de nov. de 2019 a la(s) 13:19, JORDI PALET MARTINEZ via
> LACNOG <lacnog en lacnic.net <mailto:lacnog en lacnic.net>> escribió:
>
> Hola Fernando,
>
> 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.
>
> Es decir, de nuevo, es una excusa no tener un prefijo mas adecuado
> a la necesidad real de un ISP.
>
> Sigo debajo …
>
> El 12/11/19 16:45, "LACNOG en nombre de Fernando Frediani"
> <lacnog-bounces en lacnic.net <mailto:lacnog-bounces en lacnic.net> en
> nombre de fhfrediani en gmail.com <mailto:fhfrediani en gmail.com>>
> escribió:
>
> Hola Jordi
>
> Solo un breve comentario corto más. Me gustaría saber la opinión
> de los demás.
>
> èSi por favor!
>
>
>
> 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?
>
> è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í.
>
>
>
> 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.
>
> èSi, ahí de acuerdo contigo. Yo no me refiero a ese tipo de
> dispositivos.
>
>
>
> 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.
> 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.
>
> * 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.
>
> Saludos
> Fernando
>
> On 12/11/2019 12:25, JORDI PALET MARTINEZ via LACNOG wrote:
>
> Hola Fernando,
>
> El 12/11/19 15:25, "LACNOG en nombre de Fernando Frediani"
> <lacnog-bounces en lacnic.net <mailto:lacnog-bounces en lacnic.net>
> en nombre de fhfrediani en gmail.com
> <mailto:fhfrediani en gmail.com>> escribió:
>
> 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.
>
> 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.
>
> 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.
>
>
> 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.
>
>
> 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).
>
> 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.
>
> 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!
>
> <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.
>
>
> 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.
>
> Sigue habiendo tráfico peer-to-peer basado en 6to4 (y Teredo),
> aunque no sea visible, precisamente de eso se trataba.
>
> Aunque mañana decidiéramos descatalogar el uso de /48, el
> proceso es el siguiente:
>
> 1)Adoptarlo en IETF (1-2 años)
>
> 2)Que los fabricantes que quieran lo implementen en nuevos
> dispositivos (1-2 años)
>
> 3)Que los fabricantes de dispositivos antiguos hagan nuevas
> versiones de firmware (1-2 años)
>
> 4)Que los usuarios o ISPs actualicen el firmware (1-2 años) o
> que esos equipos “mueran” o sean reemplazados.
>
> 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.
>
> Crees que podemos pensar que a corto-medio plazo, esto cambiaría?
>
> 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?
>
> <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.
>
>
> 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.
>
> 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.
>
>
> 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 **sin** experiencia real en despliegue y
> operación de IPv6. Y ahí están los resultados!
>
> <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.
>
> 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.
>
> 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 <mailto: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 <mailto:LACNOG en lacnic.net>
>
> https://mail.lacnic.net/mailman/listinfo/lacnog
>
> Cancelar suscripcion:https://mail.lacnic.net/mailman/options/lacnog
>
> _______________________________________________ LACNOG mailing
> list LACNOG en lacnic.net <mailto: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 <mailto:LACNOG en lacnic.net>
>
> https://mail.lacnic.net/mailman/listinfo/lacnog
>
> Cancelar suscripcion:https://mail.lacnic.net/mailman/options/lacnog
>
> _______________________________________________ LACNOG mailing
> list LACNOG en lacnic.net <mailto: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 <mailto:LACNOG en lacnic.net>
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
> _______________________________________________
> 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/b8440b28/attachment-0001.html>
Más información sobre la lista de distribución LACNOG