¿Por qué las direcciones locales únicas de IPv6 tienen que tener un prefijo / 48?


8

De acuerdo con RFC 4193, las direcciones locales únicas siempre tendrán un prefijo de FD00::/8... pero de acuerdo con Wikipedia:

El bloque fd00 :: / 8 se define para los prefijos / 48, formados configurando los cuarenta bits menos significativos del prefijo en una cadena de bits generada aleatoriamente.

¿Se aplica esto y, de ser así, por qué? ¿Qué me impide tener un prefijo de /32o /16etc.?


2
Recuerde que la "U" en ULA significa "único".
Ron Maupin

Respuestas:


12

El requisito existe para evitar colisiones. Esto es un poco más importante de lo que la mayoría de la gente reconoce.

Incluso si tiene sistemas que actualmente no se comunican con otros sistemas a través de Internet, todavía necesita que sus direcciones sean globalmente únicas. Es posible que ahora o en el futuro necesite agregar un host que pueda comunicarse tanto con su red interna como con Internet. Y para que la comunicación con ese host funcione, las direcciones IP con las que se comunicará deberán ser únicas.

Si existen dos redes internas con el mismo rango local, existe la posibilidad de que un host eventualmente necesite comunicarse con ambas y en ese punto deberá renumerar una de las redes. Es probable que se necesite este tipo de comunicación si está utilizando una conexión VPN y tanto el cliente como el servidor están en redes que utilizan el espacio de direcciones RFC 4193.

Otra forma en que podría terminar necesitando comunicarse con otras redes internas en el futuro es en caso de que su compañía se fusione con otra compañía que también usa redes internas.

40 bits aleatorios son suficientes para garantizar que un host que necesita comunicarse con múltiples redes internas puede esperar alcanzar aproximadamente un millón de redes diferentes antes de ver la primera colisión.

El requisito de 40 bits aleatorios no se aplica de ninguna manera, pero si no lo cumple, se está preparando para problemas en el futuro cuando se produce una colisión.


Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .
Ron Maupin

10

Cuando las empresas se fusionan o configuran una extranet para comunicarse, ha resultado difícil con el direccionamiento privado de IPv4 porque las empresas a menudo usan el mismo espacio de direcciones o superpuesto, y eso requiere el feo truco de NAT para moverse, y eso puede causar problemas y fallas muchos protocolos

Esto se identificó como un problema cuando se estaba desarrollando IPv6 ULA, y el objetivo era permitir que las empresas tuvieran espacio de direcciones que no fueran de Internet, pero que tuvieran una probabilidad muy alta de que el espacio utilizado fuera único. Esto es para tratar de evitar el problema de fusión o comunicación entre compañías que usan direcciones que no son de Internet. IPv6 no tiene NAT, y el objetivo de IPv6 es restaurar la conectividad IP de extremo a extremo que se perdió cuando NAT se hizo necesaria debido a la cantidad limitada de direcciones IPv4.

La primera mitad del espacio IPv6 ULA ( fc00::/8) está reservada para la asignación por parte de una autoridad global (aún por nombrar), mientras que la segunda mitad del espacio IPv6 ULA ( fd00::/8) se configuró para que las empresas puedan asignar su propio direccionamiento con un alto probabilidad de unicidad.


De acuerdo con RFC 4193, las direcciones locales únicas siempre tendrán un prefijo de FD00::/8

Eso es simplemente incorrecto. Ese RFC define el espacio ULA como fc00::/7, pero hay dos partes en el espacio que están definidas por el octavo bit (bit "L").

Desde el RFC:

3.1. Formato

Las direcciones IPv6 locales se crean utilizando una ID global asignada seudoaleatoriamente. Tienen el siguiente formato:

| 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID  | Subnet ID |        Interface ID        |
+--------+-+------------+-----------+----------------------------+

Esto divide el espacio ULA en dos /8espacios: fc00::/8para el direccionamiento asignado globalmente y fd00::/8para el direccionamiento asignado localmente. Observe que el formato en el RFC requiere " una identificación global asignada seudoaleatoriamente " . Esto se explica con más detalle:

3.2. ID global

La asignación de ID globales es pseudoaleatoria [ RANDOM ]. NO DEBEN asignarse secuencialmente o con números conocidos. Esto es para garantizar que no haya ninguna relación entre las asignaciones y para ayudar a aclarar que estos prefijos no están destinados a enrutarse globalmente. Específicamente, estos prefijos no están diseñados para agregarse.

Este documento define un método local específico para asignar ID globales, indicado al establecer el bit L en 1. Otro método, indicado al borrar el bit L, se puede definir más adelante. Además del método de asignación, todas las direcciones IPv6 locales se comportan y se tratan de manera idéntica.

Las asignaciones locales son autogeneradas y no necesitan ninguna coordinación o asignación central, pero tienen una probabilidad extremadamente alta de ser únicas.

Como puede ver, la premisa de su pregunta de que el RFC dice que las direcciones ULA siempre tendrán un prefijo fd00::/8es incorrecta.

¿Se aplica esto y, de ser así, por qué? ¿Qué me impide tener un prefijo de / 32 o / 16, etc.?

No existe una aplicación real, de la misma manera que si intentara utilizar el direccionamiento en Internet público. Su empresa simplemente podría usar cualquier direccionamiento en ese espacio, en los bloques que quiera. Lo que hace su empresa para abordar en su propia red depende completamente de él, pero a la larga podría resultar tonto y costoso no seguir los estándares.

Por ejemplo, sé de algunas compañías que usaron el espacio de direcciones IPv4 "oscuro" dentro de sus redes, pero luego el espacio de direcciones oscuras comenzó a usarse en Internet público, y las compañías no pudieron conectarse con clientes o proveedores usando el direccionamiento en ese espacio de direcciones, y se necesitaron algunas soluciones feas para solucionarlo en el corto plazo, hasta que todas las redes internas que usaban ese espacio de direcciones fueran direccionadas. Tomó algunos años y mucho dinero solucionar los problemas.


RFC 4193, Direcciones locales únicas de unidifusión IPv6 es la definición de IPv6 ULA, y debe consultarla para obtener más detalles:

1. Introducción

Este documento define un formato de dirección de unidifusión IPv6 que es globalmente único y está destinado a las comunicaciones locales [ IPV6 ]. Estas direcciones se denominan Direcciones de unidifusión IPv6 locales únicas y se abrevian en este documento como direcciones IPv6 locales. No se espera que sean enrutables en Internet global. Son enrutables dentro de un área más limitada, como un sitio. También pueden enrutarse entre un conjunto limitado de sitios.

Las direcciones de unidifusión IPv6 locales tienen las siguientes características:

  • Prefijo globalmente único (con alta probabilidad de unicidad).

  • Prefijo bien conocido para permitir un filtrado fácil en los límites del sitio.

  • Permita que los sitios se combinen o se interconecten de forma privada sin crear conflictos de direcciones ni requerir la renumeración de interfaces que usan estos prefijos.

  • El proveedor de servicios de Internet es independiente y se puede utilizar para las comunicaciones dentro de un sitio sin tener una conexión a Internet permanente o intermitente.

  • Si se filtró accidentalmente fuera de un sitio a través de enrutamiento o DNS, no hay conflicto con ninguna otra dirección.

  • En la práctica, las aplicaciones pueden tratar estas direcciones como direcciones de ámbito global.

Este documento define el formato de las direcciones IPv6 locales, cómo asignarlas y consideraciones de uso que incluyen enrutamiento, enrutadores de borde del sitio, DNS, soporte de aplicaciones, uso de VPN y pautas sobre cómo usar para la comunicación local dentro de un sitio.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.