Protocolo de Internet Versión 8 (IPv8)

Resumen

El Protocolo de Internet Versión 8 (IPv8) es una suite de protocolos de red gestionada que transforma cómo se operan, aseguran y monitorizan las redes de cualquier escala — desde redes domésticas hasta la internet global. Cada elemento gestionable de una red IPv8 se autoriza mediante tokens OAuth2 JWT servidos desde una caché local. Cada servicio que un dispositivo necesita se entrega en una única respuesta de concesión DHCP8. Cada paquete que transita hacia internet se valida en egreso contra una consulta DNS8 y una ruta activa registrada en WHOIS8. Telemetría de red, autenticación, resolución de nombres, sincronización horaria, control de acceso y traducción se unifican en una plataforma coherente: el Zone Server.

IPv4 es un subconjunto estricto de IPv8. Una dirección IPv8 con el campo de prefijo de enrutamiento a cero es una dirección IPv4. Ningún dispositivo, aplicación o red existente requiere modificación. La suite es 100% retrocompatible. No hay flag day ni migración forzada en ninguna capa.

IPv8 también resuelve el agotamiento de direcciones IPv4. Cada titular de un Número de Sistema Autónomo (ASN) recibe 4.294.967.296 direcciones de host. La tabla de enrutamiento BGP8 global queda estructuralmente acotada por el número de ASNs en lugar del número de prefijos. WHOIS8 es un servicio de infraestructura crítica que soporta este modelo.

Este documento es una de las especificaciones complementarias:

• draft-thain-ipv8-02 Protocolo núcleo (este documento)
• draft-thain-routing-protocols-00 BGP8, IBGP8, OSPF8, IS-IS8, CF
• draft-thain-rine-00 Regional Inter-Network Exchange
• draft-thain-zoneserver-00 Arquitectura del Zone Server
• draft-thain-whois8-00 Protocolo WHOIS8
• draft-thain-netlog8-00 Protocolo NetLog8
• draft-thain-support8-00 ARP8, ICMPv8, Route8
• draft-thain-ipv8-mib-00 MIB de IPv8 y SNMPv8
• draft-thain-wifi8-00 Protocolo WiFi8
• draft-thain-update8-00 Update8 y certificación de NICs

Estado de este memorándum

Este Internet-Draft se presenta en plena conformidad con las disposiciones de BCP 78 y BCP 79.

Los Internet-Drafts son documentos de trabajo del Internet Engineering Task Force (IETF). Obsérvese que otros grupos también pueden distribuir documentos de trabajo como Internet-Drafts. La lista de Internet-Drafts vigentes está en https://datatracker.ietf.org/drafts/current/.

Los Internet-Drafts son documentos borrador válidos por un máximo de seis meses y pueden ser actualizados, reemplazados o retirados por otros documentos en cualquier momento. No es apropiado usar Internet-Drafts como material de referencia o citarlos de forma distinta a "trabajo en curso".

Este Internet-Draft caducará el 19 de octubre de 2026.

Nota de copyright

Copyright (c) 2026 IETF Trust y las personas identificadas como autores del documento. Todos los derechos reservados.

Este documento está sujeto a BCP 78 y a las Legal Provisions del IETF Trust relativas a los documentos IETF (https://trustee.ietf.org/license-info) en vigor en la fecha de publicación de este documento. Revise esos documentos cuidadosamente, ya que describen sus derechos y restricciones respecto a este documento. Los componentes de código extraídos de este documento deben incluir el texto de la Revised BSD License descrito en la Sección 4.e de las Trust Legal Provisions y se proporcionan sin garantía como se describe en la Revised BSD License.

1. Introducción

1.1. Lenguaje de requisitos

Las palabras clave "DEBE" ("MUST"), "NO DEBE" ("MUST NOT"), "REQUERIDO" ("REQUIRED"), "HA DE" ("SHALL"), "NO HA DE" ("SHALL NOT"), "DEBERÍA" ("SHOULD"), "NO DEBERÍA" ("SHOULD NOT"), "RECOMENDADO" ("RECOMMENDED"), "NO RECOMENDADO" ("NOT RECOMMENDED"), "PUEDE" ("MAY") y "OPCIONAL" ("OPTIONAL") en este documento deben interpretarse como se describe en BCP 14 [RFC2119] [RFC8174] cuando, y solo cuando, aparecen en mayúsculas, como se muestra aquí.

1.2. El problema de la gestión de redes

La gestión de redes moderna se caracteriza por la fragmentación. DHCP, DNS, NTP, registro de eventos, monitorización y autenticación son productos separados, licenciados por separado, configurados por separado y mantenidos por separado, sin conciencia compartida del estado de la red. Un dispositivo que se conecta a una red puede requerir configuración manual de una docena de servicios independientes antes de ser operativo. La seguridad es inconsistente: algunos servicios están autenticados, otros no. Los fallos requieren correlacionar datos a través de sistemas que nunca fueron diseñados para trabajar juntos.

Esta fragmentación escala con cada dispositivo añadido. Las redes pequeñas no pueden permitirse la complejidad operativa. Las redes grandes no pueden permitirse la inconsistencia. La internet global no tiene un mecanismo coherente para validar que las rutas anunciadas están legítimamente en manos de quien las anuncia, o que los paquetes que transitan a destinos externos han sido validados contra cualquier registro de rutas activas.

IPv6 [RFC8200] abordó el agotamiento de direcciones pero no abordó la fragmentación de la gestión. Tras 25 años de esfuerzo de despliegue, IPv6 transporta una minoría del tráfico global de internet. El coste operativo del modelo de transición de doble pila, combinado con la ausencia de mejoras en la gestión, resultó comercialmente inaceptable.

IPv8 aborda ambos problemas simultáneamente.

1.3. Filosofía de gestión de IPv8

El concepto operativo central de IPv8 es el Zone Server: una plataforma emparejada activo/activo que ejecuta todos los servicios que un segmento de red requiere: asignación de direcciones (DHCP8), resolución de nombres (DNS8), sincronización horaria (NTP8), recolección de telemetría (NetLog8), caché de autenticación (OAuth8), validación de rutas (resolutor WHOIS8), aplicación de control de acceso (ACL8) y traducción IPv4/IPv8 (XLATE8).

Un dispositivo que se conecta a una red IPv8 envía un único DHCP8 Discover y recibe una única respuesta que contiene cada punto de servicio que necesita. No se requiere configuración manual posterior para ningún servicio. El dispositivo queda plenamente operativo — autenticado, registrado, sincronizado en tiempo y sujeto a política de zona — antes de su primera interacción de usuario.

Cada elemento gestionable de una red IPv8 se autoriza mediante tokens OAuth2 JWT [RFC7519]. Los tokens se validan localmente por la caché OAuth8 en el Zone Server sin viajes de ida y vuelta a proveedores externos de identidad. Un dispositivo en una ubicación remota con un proveedor de identidad en la nube temporalmente inalcanzable sigue autenticándose normalmente: la caché OAuth8 contiene todas las claves públicas y valida firmas localmente en tiempos sub-milisegundo. Los tokens JWT pueden ser servidos por una autoridad OAuth2 local (un router doméstico operando en modo autoridad local) o por un proveedor OAuth2 empresarial cacheado. La autenticación es universal, consistente y no requiere gestión de credenciales por servicio.

Las actualizaciones de firmware y software para componentes de pila L1–L4 se gestionan mediante el protocolo Update8 [UPDATE8]. Update8 define un formato estándar de feed de fabricante, un proxy validado por el Zone Server, caché local opcional, planificación basada en la criticidad del dispositivo y prevención de rollback aplicada en hardware de la NIC. Los dispositivos reciben actualizaciones solo de orígenes nombrados por DNS validados por el Zone Server. La conexión a una fuente de actualización identificada por dirección IP se bloquea por defecto.

El rango 127.0.0.0/8 de r.r.r.r está permanentemente reservado como espacio de prefijo de zona interna IPv8. Las organizaciones asignan prefijos de zona internos (127.1.0.0, 127.2.0.0, etc.) a zonas y regiones de red. Las direcciones de zona interna nunca se enrutan externamente. No es posible ningún conflicto de direcciones entre zonas. Una organización puede construir una red de escala geográfica y organizativa arbitraria — con docenas de zonas regionales, cada una con miles de dispositivos — usando protocolos de enrutamiento familiares sin coordinación de direcciones externa.

1.4. Redundancia de Zone Server y direccionamiento par/impar

Cada segmento de red IPv8 opera con dos Zone Servers, asignados a las dos direcciones más altas de la subred: .254 (par) y .253 (impar). Estas son las dos pasarelas por defecto entregadas a cada dispositivo en la respuesta de concesión DHCP8.

El tráfico IPv8 sigue un modelo de afinidad par/impar: los hosts con direcciones pares enrutan vía el Zone Server par (.254) y los hosts con direcciones impares enrutan vía el Zone Server impar (.253). Cada Zone Server es la raíz PVRST de sus respectivas VLANs. Bajo operación normal, la carga se distribuye entre ambos Zone Servers sin un único punto de fallo. En caso de fallo de un Zone Server, el tráfico conmuta automáticamente a la pasarela superviviente.

Los hosts DEBERÍAN recibir direcciones que coincidan con su ruta de tráfico primaria. Los hosts con doble NIC DEBERÍAN recibir por DHCP8 una dirección par y una impar — una por NIC — permitiendo el uso simultáneo de ambas rutas de pasarela y ambos enlaces físicos. Se consigue redundancia completa sin configuración adicional: la pérdida de cualquiera de las NICs o de cualquiera de los Zone Servers resulta en conmutación automática por la ruta superviviente. Los administradores PUEDEN desviarse de la asignación par/impar donde los requisitos operativos lo justifiquen.

1.5. Seguridad este-oeste y norte-sur

IPv8 aborda dos problemas distintos de seguridad de tráfico:

Seguridad este-oeste — tráfico entre dispositivos dentro de una red — se aplica por aislamiento de zona ACL8. Los dispositivos se comunican únicamente con su pasarela de servicio designada. La pasarela de servicio se comunica únicamente con el servicio en nube designado. El movimiento lateral entre dispositivos o zonas se evita arquitectónicamente por la ausencia de cualquier ruta permitida hacia cualquier otro destino. Tres capas de enforcement independientes proveen defensa en profundidad: ACL8 en el firmware de la NIC, ACL8 en la pasarela del Zone Server y enforcement VLAN por OAuth2 en el hardware del puerto del switch.

Seguridad norte-sur — tráfico desde dispositivos internos hacia internet — se aplica en el egreso del Zone Server mediante dos pasos obligatorios de validación. Primero, cada conexión saliente debe tener una consulta DNS8 correspondiente: sin consulta DNS, no hay entrada en la tabla de estado XLATE8, y la conexión se bloquea. Segundo, el ASN de destino se valida contra el registro WHOIS8: si el prefijo de destino no está registrado como ruta activa por un titular de ASN legítimamente registrado, el paquete se descarta. Estos dos pasos juntos eliminan el canal primario de comando y control del malware: conexión a direcciones IP codificadas a mano sin resolución DNS.

A nivel de enrutamiento global, los anuncios de ruta BGP8 se validan contra WHOIS8 antes de su instalación en la tabla de enrutamiento. Una ruta que no puede validarse no se instala. Se elimina el mantenimiento manual de listas de bogons. El secuestro de prefijos resulta arquitectónicamente difícil: un atacante tendría que comprometer tanto una entrada en el registro RIR como producir un registro WHOIS8 firmado válidamente.

1.6. Agotamiento de direcciones

IANA completó la asignación del espacio unicast IPv4 en febrero de 2011. CGNAT ha extendido la vida de IPv4 pero introduce latencia, rompe protocolos P2P y complica la resolución de problemas. El problema del agotamiento de direcciones es arquitectónico y no puede resolverse dentro del espacio de 32 bits de IPv4.

IPv8 resuelve el agotamiento de direcciones como consecuencia de su arquitectura de direccionamiento, no como objetivo primario de diseño. El espacio de direcciones IPv8 de 64 bits proporciona 2⁶⁴ direcciones únicas. Cada titular de un ASN recibe 2³² direcciones de host — 4.294.967.296 direcciones — suficientes para cualquier organización a cualquier escala sin agotamiento de direcciones, sin CGNAT y sin renumeración.

IPv4 es un subconjunto estricto de IPv8. Una dirección IPv8 con r.r.r.r = 0.0.0.0 es una dirección IPv4, procesada por reglas IPv4 estándar. Ningún dispositivo, aplicación o red existente requiere modificación para participar en una red IPv8. La suite es 100% retrocompatible. No hay flag day ni migración forzada en ninguna capa.

La tabla de enrutamiento BGP8 global queda estructuralmente acotada por el número de ASNs. La regla del prefijo mínimo inyectable /16 impide la desagregación — un ASN puede anunciar múltiples prefijos /16 pero nunca más específicos. La aceptación de rutas se valida contra WHOIS8, que actúa como servicio de infraestructura crítica para el sistema de enrutamiento global. La tabla de enrutamiento BGP4 superó los 900.000 prefijos sin cota arquitectónica. La tabla BGP8 queda acotada por el número de prefijos /16 en manos de todos los ASNs — un conjunto estructuralmente finito y manejable.

1.7. Mejoras en los protocolos de enrutamiento

IPv8 extiende OSPF8 [RFC2328], BGP8 [RFC4271] (tanto iBGP8 como eBGP8) e IS-IS8 con una métrica unificada de calidad de ruta: el Cost Factor (CF).

CF es una métrica acumulada de 32 bits derivada de siete componentes medidos desde telemetría de sesión TCP: tiempo de ida y vuelta, pérdida de paquetes, estado de ventana de congestión, estabilidad de la sesión, capacidad del enlace, política económica, y distancia geográfica como suelo físico. CF se acumula a través de cada salto BGP8 desde origen hasta destino. Cada router selecciona independientemente el camino con menor CF acumulado sin coordinación.

CF combina la calidad de ruta compuesta dinámica de EIGRP, el modelo de coste acumulado de OSPF y el balanceo proporcional de carga entre múltiples rutas, en un único algoritmo abierto y versionado que opera extremo a extremo cruzando fronteras entre ASes. OSPF y EIGRP se detienen en la frontera entre ASes. CF no.

El componente geográfico de CF establece un suelo físico: ninguna ruta puede parecer mejor de lo que permite la velocidad de la luz sobre la distancia del gran círculo. Una ruta que se mide más rápida de lo que la física permite es marcada inmediatamente como anomalía CF.

CF es un algoritmo abierto y versionado. CFv1 es la línea base obligatoria. Las versiones futuras podrán añadir coste de carbono, jitter, hora del día y señales de latencia a nivel de aplicación mediante el proceso del IETF.

La contribución CF de un salto solo-IPv4 es cero — ni peso positivo ni negativo — salvo que un operador asigne explícitamente un peso CF de política a ese salto. Por defecto, los saltos IPv4 son invisibles a la optimización de ruta CF. Esto asegura que las rutas de tránsito IPv4 no son ni preferidas ni penalizadas en la selección de ruta CF únicamente por su versión de protocolo.

1.8. Retrocompatibilidad y transición

IPv4 es un subconjunto estricto de IPv8:

• Dirección IPv8 con r.r.r.r = 0.0.0.0 = dirección IPv4
• Procesada por las reglas IPv4 estándar
• No se requiere modificación de dispositivos IPv4
• No se requiere modificación de aplicaciones IPv4
• No se requiere modificación de redes internas IPv4

IPv8 no requiere operación de doble pila. No hay flag day. La tunelización 8to4 permite que islas IPv8 separadas por redes de tránsito solo-IPv4 se comuniquen inmediatamente. CF naturalmente incentiva a los ASes de tránsito IPv4 a actualizar midiendo mayor latencia en rutas 8to4 — una señal económica automática sin mandato alguno.

Las fases de transición son independientes. Los ISPs Tier 1, proveedores de nube, empresas e ISPs de consumo pueden adoptar IPv8 en cualquier orden y a cualquier ritmo. 8to4 asegura la interoperabilidad durante todo el proceso.

2. Selección de versión guiada por ARP8

2.1. La regla fundacional

Un host o router IPv8 que transmita a un vecino en un segmento compartido DEBE usar la versión de protocolo IP que coincida con la capacidad de ese vecino tal como está registrada en la caché ARP8. La capacidad se descubre en el primer contacto vía sonda dual ARP8 y se registra de forma permanente durante la vida de la entrada en caché.

2.2. Descubrimiento de capacidad del vecino

En el primer contacto con un vecino, un host IPv8 emite dos sondas en paralelo:

t=0 ms    Sonda ARP8  (vecino IPv8-capaz esperado)
t=50 ms   Sonda ARP4  (respaldo IPv4 si no hay respuesta ARP8)

La primera respuesta recibida determina la capacidad registrada del vecino. Una vez registrada, la entrada de capacidad persiste durante la vida de la entrada en la caché ARP8. No se requiere sondeo por paquete.

2.3. Selección de versión al transmitir

La regla clave de la retrocompatibilidad IPv8: un dispositivo IPv8 HA DE transmitir únicamente paquetes IPv4 a dispositivos IPv4. No hay excepciones. Un dispositivo IPv4 en cualquier segmento con dispositivos IPv8 nunca recibirá un paquete que no pueda procesar.

Para un vecino registrado como IPv8-capaz, el emisor construye un paquete IPv8 completo:

Campo Version:         8
Dirección origen:      r.r.r.r.n.n.n.n  (64 bits, prefijo completo)
Dirección destino:     r.r.r.r.n.n.n.n  (64 bits, prefijo completo)

Para un vecino registrado como solo-IPv4, el emisor construye un paquete IPv4 estándar:

Campo Version:         4
Dirección origen:      n.n.n.n  (32 bits, solo parte host)
Dirección destino:     n.n.n.n  (32 bits, solo parte host)

El prefijo r.r.r.r no está presente en el cable para ese salto. El vecino IPv4 recibe un paquete indistinguible del IPv4 normal. Un dispositivo solo-IPv4 en un segmento compartido con dispositivos IPv8-capaces nunca recibe un paquete con versión 8 en la cabecera IP. El caso de descarte por versión discordante nunca surge porque el emisor IPv8 construye el paquete en la versión que el vecino entiende.

2.4. Reenvío en router

Un router IPv8 que reenvía a un siguiente salto vecino solo-IPv4 aplica la misma regla. Si un paquete llegó como IPv8 en la interfaz de entrada y el siguiente salto está registrado como solo-IPv4, el router DEBE degradarlo en la interfaz de salida:

Entrada: versión 8, origen y destino r.r.r.r.n.n.n.n
Salida:  versión 4, origen y destino n.n.n.n

El prefijo r.r.r.r se elimina de la dirección de origen. El estado de sesión se preserva vía XLATE8 en el Zone Server para la reconstrucción del tráfico de retorno. El dispositivo IPv4 en el segmento de salida recibe un paquete IPv4 estándar y no tiene conocimiento de IPv8 aguas arriba.

Un único router IPv8 PUEDE servir dispositivos IPv8-capaces y solo-IPv4 en diferentes interfaces simultáneamente, aplicando selección de versión independientemente por interfaz de salida según la capacidad registrada en ARP8 de cada vecino siguiente salto.

2.5. Atribución en saltos IPv4

Cuando un paquete se transmite como IPv4 — bien host-a-vecino-IPv4 o bien router-degradado en una frontera IPv4 — el prefijo r.r.r.r no está en el cable para ese salto. La atribución por ASN y la validación WHOIS8 solo aplican a saltos donde ambos extremos son IPv8-capaces. Esta es una propiedad aceptada y correcta del modelo de transición: las comunicaciones IPv4 no llevan propiedades IPv8, del mismo modo que hoy las comunicaciones IPv4 no llevan validación RPKI salvo que ambos extremos la soporten.

2.6. Propiedades de transición

Este modelo produce las siguientes propiedades de transición:

• Los extremos solo-IPv4 nunca requieren modificación.
• Los dispositivos IPv4 en un segmento compartido con dispositivos IPv8 continúan operando sin cambios de configuración.
• Los dispositivos IPv4 detrás de routers IPv8 continúan operando porque el router degrada en la frontera.
• Las aplicaciones IPv4 en hosts IPv8 continúan operando porque XLATE8 maneja la traducción de versión en su nombre.
• Ningún dispositivo IPv4 recibe jamás un paquete con versión 8 en la cabecera IP.
• La transición es por dispositivo y por router, en el calendario propio de cada operador, sin flag day y sin requisito de coordinación entre operadores.

Cuatro líneas de configuración habilitan IPv8 en un router. Ningún dispositivo, aplicación o red IPv4 existente requiere modificación alguna.

3. Motivación y planteamiento del problema

3.1. Fragmentación de la gestión

La gestión de redes IPv4 no tiene un modelo integrado coherente. Los protocolos que operan una red — DHCP, DNS, NTP, syslog, SNMP, autenticación — fueron especificados de forma independiente a lo largo de cuatro décadas, no comparten modelo de identidad común, mecanismo de autenticación común, ni formato de telemetría común.

Las consecuencias son operativas: las redes requieren conocimiento especializado de cada protocolo por separado. La seguridad es inconsistente — algunos servicios requieren autenticación, otros aceptan peticiones no autenticadas desde cualquier origen. Los fallos requieren correlacionar logs entre sistemas con formatos de timestamp diferentes, modelos de severidad diferentes y representaciones de identidad diferentes. La gestión escala con la carga operativa, no con el tamaño de la red.

IPv8 aborda esto definiendo una suite de gestión coherente en la cual cada servicio comparte un modelo de identidad común (OAuth2 JWT), un mecanismo de entrega común (DHCP8), un formato de telemetría común (NetLog8) y una caché de autenticación común (OAuth8).

3.2. Agotamiento de direcciones

IANA completó la asignación del espacio unicast IPv4 en febrero de 2011. Los Regional Internet Registries agotaron sus asignaciones entre 2011 y 2020. CGNAT extendió la vida de IPv4 al coste de latencia, rotura de protocolos P2P y complejidad de resolución de problemas.

IPv6 [RFC8200] se desarrolló para abordar el agotamiento. Tras 25 años de esfuerzo de estandarización y despliegue, IPv6 transporta una minoría del tráfico global. El modelo de transición de doble pila — que requiere que cada dispositivo, aplicación y red soporten ambos protocolos simultáneamente — resultó comercialmente inaceptable. La ausencia de una función forzante permitió a las organizaciones continuar con CGNAT indefinidamente.

IPv8 resuelve el agotamiento de direcciones sin operación de doble pila. IPv4 es un subconjunto estricto de IPv8. La transición no requiere flag day y no crea discontinuidad operativa.

3.3. Crecimiento de la tabla de enrutamiento

La tabla de enrutamiento BGP4 global superó los 900.000 prefijos en 2024 y crece sin cota arquitectónica. La desagregación de prefijos — anunciar prefijos más específicos para influir en la ingeniería de tráfico — es el principal motor del crecimiento. Ningún mecanismo de protocolo lo impide.

BGP4 no tiene relación vinculante entre lo que un ASN anuncia y lo que está autorizado a anunciar. El secuestro de prefijos, las fugas de rutas y la inyección de bogons son posibles porque no hay un registro de propiedad de rutas que los routers de frontera apliquen como condición para aceptar rutas.

IPv8 aborda ambos problemas. La regla de prefijo mínimo inyectable /16 impide la desagregación en las fronteras entre ASes. La validación obligatoria de rutas WHOIS8 crea una relación vinculante entre los anuncios BGP8 y la propiedad de ruta registrada — WHOIS8 es un servicio de infraestructura crítica para el sistema de enrutamiento global. La tabla BGP8 global queda acotada por el número de prefijos /16 en manos de todos los ASNs activos, un conjunto estructuralmente finito.

3.4. Requisitos para un sucesor viable

• R1. Gestión integrada — identidad común, autenticación, telemetría y entrega de servicios a través de todos los servicios de red.
• R2. Operación de una sola pila — sin requisito de doble pila.
• R3. Retrocompatibilidad completa — aplicaciones IPv4 existentes sin cambios. IPv4 es un subconjunto estricto de IPv8.
• R4. Retrocompatibilidad completa — redes internas RFC 1918 sin cambios.
• R5. Retrocompatibilidad completa — despliegues CGNAT sin cambios.
• R6. Espacio de direcciones enormemente ampliado.
• R7. Implementable como actualización de software sin reemplazo de hardware.
• R8. Direccionamiento legible por humanos, consistente con la familiaridad del operador IPv4.
• R9. Seguridad de tráfico este-oeste y norte-sur aplicada por protocolo, no por configuración manual.
• R10. Tabla de enrutamiento global estructuralmente acotada.

IPv8 satisface los diez requisitos.

4. Formato de dirección IPv8

4.1. Estructura

Una dirección IPv8 es un valor de 64 bits:

r.r.r.r.n.n.n.n

• r.r.r.r — Prefijo de enrutamiento ASN de 32 bits
• n.n.n.n — Dirección de host de 32 bits (semántica idéntica a IPv4)

4.2. Espacio de direcciones

2⁶⁴ = 18.446.744.073.709.551.616 direcciones únicas.

2³² prefijos ASN × 2³² direcciones de host por ASN.

4.3. Representación IPv4 en IPv8

0.0.0.0.n.n.n.n

Los paquetes con r.r.r.r = 0.0.0.0 DEBEN enrutarse usando las reglas IPv4 estándar aplicadas al campo n.n.n.n. IPv4 es un subconjunto estricto de IPv8. No se requiere modificación de dispositivos, aplicaciones o redes IPv4.

4.4. Codificación del ASN en r.r.r.r

El ASN de 32 bits se codifica directamente en r.r.r.r como un entero sin signo de 32 bits en orden de bytes de red:

ASN 64496 (Example-A)   = 0.0.251.240
ASN 64497 (Example-B)   = 0.0.251.241
ASN 64498 (Example-C)   = 0.0.251.242

4.5. Prefijo de zona interna (127.0.0.0/8)

El rango 127.0.0.0/8 del campo r.r.r.r está permanentemente reservado para prefijos internos de zona IPv8. Los prefijos de zona interna identifican zonas de red dentro del espacio de direccionamiento privado de una organización.

127.x.x.x.n.n.n.n

Donde x.x.x identifica la zona interna. Ejemplos:

127.1.0.0.n.n.n.n   Zona interna 1 (p.ej. Américas)
127.2.0.0.n.n.n.n   Zona interna 2 (p.ej. Europa)
127.3.0.0.n.n.n.n   Zona interna 3 (p.ej. Asia-Pacífico)

Reglas del prefijo de zona interna:

• NO DEBE enrutarse externamente más allá de la frontera AS de la organización.
• NO DEBE aparecer en interfaces WAN ni en enlaces a internet pública.
• NO DEBE usarse en anuncios eBGP8.
• PUEDE usarse libremente dentro de la infraestructura de enrutamiento interna de una organización vía OSPF8, IS-IS8 e IBGP8.
• Proporciona 2⁵⁶ direcciones internas efectivas a lo largo de todos los prefijos de zona. No es posible ningún conflicto de direcciones internas entre zonas.
• Permite a las organizaciones construir redes privadas distribuidas geográficamente, enrutadas por región, de escala arbitraria, sin coordinación de direcciones externa.

Los números ASN que se codifican al rango 127.0.0.0/8 en el campo r.r.r.r (ASN 2130706432 a ASN 2147483647) están reservados para uso de zona interna y NO DEBEN ser asignados por IANA para enrutamiento público en internet.

4.6. Prefijo de interoperación entre empresas (127.127.0.0)

El prefijo 127.127.0.0 está reservado como la DMZ de interoperación estándar entre empresas. Cuando dos organizaciones necesitan interconectarse sin exponer su direccionamiento de zona interna, ambas despliegan motores XLATE8 frente a un espacio de direcciones 127.127.0.0 compartido. Especificación completa en [ZONESERVER] Sección 16.9.

4.7. Modelo de interoperación con dos XLATE8

Empresa A                          Empresa B
---------                          ---------
127.1.0.0.x   XLATE8-A  127.127.0.0  XLATE8-B  127.2.0.0.x

Propiedades:

• La empresa A nunca ve las direcciones 127.2.0.0 de la empresa B.
• La empresa B nunca ve las direcciones 127.1.0.0 de la empresa A.
• Cada empresa controla exactamente qué expone.
• No es posible solapamiento de direcciones. Sin complejidad NAT.
• Tiempo de puesta en marcha: minutos por servicio expuesto.

4.8. ASN privado de interoperación (ASN 65534)

El ASN 65534 está reservado para peering BGP8 privado entre empresas, consistente con [RFC6996]:

0.0.255.254.x.x.x.x

El ASN 65533 (0.0.255.253.x.x.x.x) está reservado para documentación y pruebas.

4.9. Prefijo de peering RINE (100.0.0.0/8)

El rango 100.0.0.0/8 del campo r.r.r.r está permanentemente reservado para el tejido de peering Regional Inter-Network Exchange (RINE). Las direcciones RINE se usan exclusivamente para direccionamiento de enlaces de peering AS-a-AS en IXPs y facilidades de interconexión privada. Especificación completa en [RINE].

Las direcciones RINE:

• NO DEBEN anunciarse en la tabla de enrutamiento BGP8 global.
• NO DEBEN asignarse a dispositivos finales.
• DEBEN ser filtradas en todos los routers de frontera eBGP8.

4.10. Convención de enlaces interiores (222.0.0.0/8)

El rango 222.0.0.0/8 de n.n.n.n es la convención bien conocida de direcciones de enlace interior IPv8. Cada AS PUEDE usar <propio-asn>.222.x.x.x para direccionamiento de enlaces interiores entre routers dentro de su AS.

Esta convención es análoga a RFC 1918 [RFC1918] para IPv4 — universalmente reconocida, universalmente filtrada, nunca enrutada externamente, nunca extremo.

4.11. Modelo de uso de direcciones

La mayoría de los dispositivos en la mayoría de las redes usan direccionamiento interno 127.x.x.x. Las direcciones de ASN público se usan únicamente para servicios explícitamente de cara al público.

5. Clases de direcciones

El rango 222.0.0.0/8 de n.n.n.n está reservado por convención para direccionamiento de enlaces interiores según la Sección 4.10.

5.1. Anycast

Anycast no es una clase de dirección separada en IPv8. Anycast es una propiedad de enrutamiento implementada vía eBGP8. La métrica Cost Factor (CF) definida en [ROUTING-PROTOCOLS] enruta cada paquete a la instancia BGP8 más cercana por coste medido automáticamente.

6. Cabecera del paquete IPv8

6.1. Formato de cabecera

IPv8 usa el número de versión IP 8 en el campo Version. La cabecera extiende IPv4 reemplazando los campos de dirección de origen/destino de 32 bits por equivalentes de 64 bits.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Source ASN Prefix (r.r.r.r)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Source Host Address (n.n.n.n)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Destination ASN Prefix (r.r.r.r)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Destination Host Address (n.n.n.n)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

La cabecera IPv8 es 8 octetos más larga que la cabecera IPv4.

6.2. Compatibilidad con la API de sockets

Las aplicaciones IPv4 existentes usan la API de sockets BSD estándar con AF_INET y sockaddr_in. La capa de compatibilidad IPv8 intercepta las llamadas a sockets de forma transparente — la aplicación no tiene consciencia alguna de IPv8. Las nuevas aplicaciones PUEDEN usar AF_INET8 con sockaddr_in8:

struct sockaddr_in8 {
    sa_family_t    sin8_family;   /* AF_INET8 */
    in_port_t      sin8_port;     /* número de puerto */
    uint32_t       sin8_asn;      /* prefijo ASN r.r.r.r */
    struct in_addr sin8_addr;     /* dirección de host n.n.n.n */
};

7. Notación ASN con puntos

Formato: <ASN>.<n>.<n>.<n>.<n>

Donde ASN es el número de sistema autónomo y n.n.n.n es la dirección de host. Los ASNs ejemplo 64496-64511 están reservados para documentación según [RFC5398].

64496.192.0.2.1  = 0.0.251.240.192.0.2.1  (Example-A)
64497.192.0.2.1  = 0.0.251.241.192.0.2.1  (Example-B)

Todas las implementaciones conformes con IPv8 DEBEN aceptar notación ASN con puntos en todos los contextos donde se acepte una dirección IPv8.

8. Tipo de registro DNS A8

• Tipo: A8 (asignación IANA pendiente)
• Formato: dirección IPv8 de 64 bits en orden de bytes de red
• Las direcciones RFC 1918 NO DEBEN publicarse como registros A8 en DNS público.
• Un resolutor IPv8 DEBERÍA solicitar ambos registros A y A8.
• Para aplicaciones IPv4 en hosts IPv8, el resolutor devuelve la porción n.n.n.n; la pila antepone r.r.r.r de forma transparente.
• Las respuestas A8 DEBERÍAN ser un par par/impar — una dirección par y una impar. Las direcciones pares se sirven vía la pasarela Zone Server par (.254) y las impares vía la pasarela Zone Server impar (.253). Esto permite a los clientes abrir streams paralelos al mismo host a través de rutas de pasarela independientes, proporcionando distribución de carga y redundancia sin infraestructura de balanceador con estado. Los administradores PUEDEN desviarse de esta convención donde los requisitos operativos lo justifiquen.

Registros de ejemplo:

ns1.example.com.  IN  A8  0.0.59.65.192.0.2.1
ns1.example.com.  IN  A8  0.0.59.65.192.0.2.2

9. Comportamiento de los protocolos de enrutamiento

9.1. Protocolos de enrutamiento obligatorios

9.2. Protocolos de enrutamiento obsoletos

9.3. eBGP8 — Protocolo de pasarela exterior obligatorio

eBGP8 es el protocolo de pasarela exterior obligatorio. Todos los dispositivos L3 DEBEN implementar eBGP8. eBGP8 es 100% retrocompatible con BGP4 [RFC4271]. Especificación completa en [ROUTING-PROTOCOLS].

El prefijo mínimo inyectable en fronteras entre ASes es /16. Los prefijos más específicos que /16 NO DEBEN anunciarse cruzando fronteras AS.

9.4. IBGP8 — Enrutamiento entre zonas

IBGP8 distribuye rutas externas validadas por WHOIS8 a lo largo de un sistema autónomo con plena conciencia de métrica CF.

CF_total = CF_externo + CF_intrazona

9.5. OSPF8 — Enrutamiento intra-zona

OSPF8 es OSPFv2 [RFC2328] extendido con una interfaz de exportación CF. Todos los dispositivos L3 DEBEN implementar OSPF8. Especificación completa en [ROUTING-PROTOCOLS] Sección 10.3.

9.6. IS-IS8 — Protocolo de pasarela interior opcional

IS-IS8 DEBE estar disponible en todas las pilas de enrutamiento L3 IPv8. Los operadores y carriers PUEDEN desplegar IS-IS8 a su discreción. IPv8 no hace recomendación alguna sobre la selección de IGP. Especificación completa en [ROUTING-PROTOCOLS] Sección 10.4.

9.7. Tabla de enrutamiento de dos niveles

Cuando r.r.r.r = 0.0.0.0 la consulta de Nivel 1 se omite.

9.8. VRF — Virtual Routing and Forwarding

VRF es obligatorio en todos los dispositivos L3 IPv8. El VRF de gestión (VLAN 4090) y el VRF OOB (VLAN 4091) DEBEN implementarse en todos los dispositivos conformes con IPv8. El aislamiento VRF es una propiedad de tabla de enrutamiento que no puede saltarse por mala configuración de software.

10. ICMPv8

ICMPv8 extiende ICMP [RFC792] para soportar direcciones IPv8 de 64 bits. ICMPv8 es retrocompatible con ICMPv4. Ambas versiones DEBEN soportarse simultáneamente. ICMPv8 transporta direcciones IPv8 completas de 64 bits en los mensajes Echo, Destination Unreachable, Time Exceeded, Redirect y Parameter Problem. Path MTU Discovery se extiende para la cabecera IPv8 más grande.

La selección de versión ICMPv8 sigue la regla ARP8 definida en la Sección 2: los mensajes ICMPv8 transmitidos a un vecino solo-IPv4 DEBEN construirse como ICMPv4 con direcciones de 32 bits. Un dispositivo solo-IPv4 nunca recibe un mensaje ICMPv8. Especificación completa en [SUPPORT8].

11. Multicast

11.1. Multicast intra-ASN

0.0.0.0.224.0.0.0/4   Todo multicast intra-ASN
0.0.0.0.239.0.0.0/8   Intra-ASN con alcance administrativo

Los paquetes con r.r.r.r = 0.0.0.0 y n.n.n.n en el rango multicast NO DEBEN reenviarse más allá de la frontera AS local.

11.2. Multicast entre ASes

ff.ff.00.00.n.n.n.n   Multicast entre ASes general
ff.ff.00.01.n.n.n.n   Tráfico del protocolo OSPF8
ff.ff.00.02.n.n.n.n   Descubrimiento de peers BGP8
ff.ff.00.03.n.n.n.n   EIGRP (reservado, obsoleto)
ff.ff.00.04.n.n.n.n   RIP (reservado, obsoleto)
ff.ff.00.05.n.n.n.n   IS-IS8 (reservado, extensión de fabricante)

11.3. Asignaciones de grupos multicast entre ASes

ff.ff.00.00.224.0.0.1    Todos los routers IPv8
ff.ff.00.00.224.0.0.2    Todos los Zone Servers IPv8
ff.ff.00.00.224.0.0.5    OSPF8 todos los routers
ff.ff.00.00.224.0.0.6    OSPF8 routers designados
ff.ff.00.00.224.0.0.10   Descubrimiento de peers IBGP8
ff.ff.00.00.239.0.0.0/8  Con alcance administrativo

12. Anycast

Anycast en IPv8 es una propiedad de enrutamiento implementada vía eBGP8 y la métrica Cost Factor (CF). No se requiere un prefijo r.r.r.r especial. CF enruta cada paquete a la instancia más cercana por coste medido.

13. Broadcast

El valor r.r.r.r = ff.ff.ff.ff está permanentemente reservado para broadcast y se mapea a la dirección de broadcast de Capa 2. Los paquetes con r.r.r.r = ff.ff.ff.ff NO DEBEN enrutarse más allá del segmento de red local.

14. Compatibilidad y transición

14.1. Operación de una sola pila

IPv8 no requiere operación de doble pila. IPv4 es un subconjunto estricto de IPv8 con r.r.r.r = 0.0.0.0. No hay flag day ni migración forzada.

14.2. Compatibilidad con redes IPv4

Las redes que no han desplegado IPv8 continúan operando sin cambios. Los routers de frontera IPv8 aplican selección de versión guiada por ARP8 en cada interfaz de salida: el prefijo r.r.r.r se elimina y el paquete se degrada a IPv4 para cualquier vecino siguiente salto registrado como solo-IPv4 en la caché ARP8. No se requiere configuración en el lado IPv4.

14.3. 8to4 — IPv8 a través de redes solo-IPv4

IPv8 atraviesa redes solo-IPv4 sin túneles preconfigurados. Un gran proveedor de servicios PUEDE dejar su núcleo IPv4 completo sin cambios durante 20 años. El tráfico IPv8 lo atraviesa automáticamente usando encapsulación anycast por salto.

Cada ASN publica una dirección anycast IPv4 en su registro WHOIS8. Todos los routers de frontera BGP8 en ese ASN anuncian esta dirección en el tejido BGP4 circundante como una ruta IPv4 normal. La tabla BGP4 global la transporta sin modificación alguna. Cuando un router BGP8 necesita alcanzar un ASN de destino a través de saltos solo-IPv4, busca el ASN de destino en su caché WHOIS8, obtiene la dirección anycast, encapsula el paquete IPv8 en una envoltura IPv4 estándar dirigida a esa dirección anycast, y lo reenvía. Los routers solo-IPv4 del núcleo reenvían el paquete IPv4 exterior usando enrutamiento normal. El router de frontera BGP8 más cercano al ASN de destino lo decapsula y entrega.

Este modelo requiere cero configuración de túneles en ningún dispositivo. Todos los caminos disponibles a través del núcleo IPv4 se usan por la selección de ruta BGP4 normal. Una red que habría requerido 100.000 túneles preconfigurados bajo el modelo de túnel requiere cero bajo el modelo anycast.

Especificación completa en [ROUTING-PROTOCOLS] Sección 11.

14.4. Secuencia de transición

• Fase 1: los routers de ISPs Tier 1/2 despliegan IPv8 vía actualización de software.
• Fase 2: los proveedores de nube despliegan IPv8 internamente.
• Fase 3: las redes empresariales adoptan opcionalmente prefijos ASN.
• Fase 4: los ISPs de consumo despliegan IPv8.

La tunelización 8to4 permite que cada fase interopere con fases aún no completadas. No hay dependencia entre fases.

15. Comportamiento de CGNAT

Los dispositivos CGNAT no requieren modificación. CGNAT consciente de IPv8 NO DEBE modificar el campo r.r.r.r durante la traducción. Solo el campo n.n.n.n está sujeto a traducción NAT. Los operadores CGNAT sin ASN DEBEN usar r.r.r.r = 0.0.0.0.

15.1. Balanceo par/impar en XLATE8

Cuando un cliente IPv4 se conecta a un host IPv8 vía una pasarela XLATE8, el host destino puede tener dirección A8 par e impar. La pasarela XLATE8 DEBERÍA pasar ambas direcciones al cliente IPv4 cuando el cliente sea capaz de usar ambas. Cuando el cliente IPv4 no sea capaz, la pasarela XLATE8 PUEDE realizar balanceo de carga internamente, distribuyendo las conexiones entre las direcciones par e impar del host destino. Esto proporciona a los clientes IPv4 el beneficio de la distribución de carga par/impar de IPv8 de forma transparente.

16. Compatibilidad de aplicaciones

Las aplicaciones IPv4 existentes no requieren modificación. La capa de compatibilidad de sockets IPv8 gestiona r.r.r.r de forma transparente mediante interceptación DNS8 y XLATE8. Las aplicaciones nuevas PUEDEN usar AF_INET8 y sockaddr_in8 según se define en la Sección 5.2.

17. Aplicabilidad en proveedores de nube

IPv8 resuelve el solapamiento de direcciones entre VPCs, la complejidad del peering VPC y el enrutamiento multi-nube mediante desambiguación basada en ASN. El prefijo de zona interno 127.x.x.x permite a los proveedores de nube asignar prefijos de zona únicos a las VPCs de sus clientes sin renumeración. Cada VPC de cliente recibe un prefijo de zona 127.x.x.x único — dos redes de clientes no pueden solaparse independientemente de la reutilización de direcciones RFC 1918 dentro de cada VPC.

18. Niveles de conformidad de dispositivos

18.1. Tier 1 — Dispositivo final

Los dispositivos finales DEBEN implementar: tabla de enrutamiento unificada Route8, rutas estáticas, VRF (plano de gestión), dos pasarelas por defecto (Zone Server par .254, Zone Server impar .253), cliente DHCP8, ARP8, ICMPv8, conexión TCP/443 persistente al Zone Server, cliente NetLog8, enforcement ACL8 en el lado cliente, VRF de gestión (VLAN 4090), VRF OOB (VLAN 4091), ARP8 gratuito al arrancar.

Los dispositivos finales DEBERÍAN usar la pasarela par para tráfico con direcciones pares y la pasarela impar para tráfico con direcciones impares, conmutando a la pasarela superviviente en caso de fallo. Los dispositivos finales con doble NIC DEBERÍAN pedir una dirección par y una impar al DHCP8.

Los dispositivos finales PUEDEN implementar: OSPF8, IS-IS8, eBGP8, IBGP8.

Los dispositivos finales NO requieren ningún protocolo de enrutamiento para alcanzar su pasarela por defecto.

18.2. Tier 2 — Dispositivo de red L2

Los dispositivos L2 DEBEN implementar: trunking 802.1Q, auto-creación de VLAN en tráfico etiquetado, VRF de gestión (VLAN 4090), VRF OOB (VLAN 4091), enlazado OAuth2 por puerto de switch, LLDP, cliente NetLog8, ARP8 (solo plano de gestión), ICMPv8 (solo plano de gestión), PVRST, capacidad Zone Server como raíz PVRST, vinculación MAC persistente (sticky MAC), notificación MAC al Zone Server.

18.3. Tier 3 — Dispositivo de red L3

Los dispositivos L3 DEBEN implementar: todos los requisitos de Tier 1, eBGP8, IBGP8, OSPF8, IS-IS8 (disponible), rutas estáticas, VRF (completo), XLATE8 (obligatorio en dispositivos de borde), resolutor WHOIS8, enforcement ACL8 de pasarela, servicios Zone Server (si el rol es Zone Server), capacidad de raíz PVRST, soporte de enlazado OAuth2 por puerto de switch.

18.4. Spanning Tree — PVRST obligatorio

PVRST es obligatorio para todos los dispositivos L2 y L3 IPv8. MST no se recomienda. Los Zone Servers son raíces PVRST por defecto:

• Zone Server primario (.254): raíz PVRST para VLANs pares, prioridad 4096.
• Zone Server secundario (.253): raíz PVRST para VLANs impares, prioridad 4096.

18.5. Límites de velocidad broadcast en NIC

El firmware de NIC certificado IPv8 aplica límites de velocidad de broadcast y de paquetes de control que no pueden ser sobrescritos por software. Estos límites se aplican únicamente al tráfico broadcast y no autenticado, y no limitan el throughput unicast de datos:

Broadcasts:              máximo 10 por segundo
Usuario no autenticado:  10 por segundo, máximo 30 por minuto
Usuario autenticado:     100 por segundo, máximo 300 por minuto

El Zone Server DHCP8 es la única autoridad para elevar el límite de velocidad. Especificación completa de certificación de NIC en [UPDATE8].

19. Consideraciones de seguridad

19.1. Spoofing de prefijo ASN

Los routers de frontera IPv8 DEBEN implementar filtrado en ingreso que valide que el r.r.r.r de origen de los paquetes recibidos coincide con el ASN del peer BGP8. Consistente con BCP 38 [RFC2827].

19.2. Protección del prefijo de zona interna

El prefijo de zona interna 127.x.x.x NO DEBE aparecer en interfaces WAN. Los routers de frontera DEBEN descartar paquetes con origen o destino r.r.r.r en 127.x.x.x en interfaces externas. DEBE generarse una SEC-ALERT de NetLog8 por cada violación.

19.3. Protección del prefijo RINE

El prefijo RINE 100.x.x.x NO DEBE aparecer en anuncios eBGP8 ni en interfaces no-peering. DEBE generarse una SEC-ALERT de NetLog8 por cada violación.

19.4. Protección de la convención de enlaces interiores

Los routers de frontera DEBEN filtrar los anuncios BGP8 recibidos que contengan direcciones n.n.n.n en el rango 222.0.0.0/8. DEBE generarse un trap E3 de NetLog8 por cada violación.

19.5. Privacidad de direcciones RFC 1918

Las direcciones privadas RFC 1918 en n.n.n.n permanecen no enrutables en la internet pública de forma consistente con el comportamiento IPv4.

19.6. Filtrado de multicast entre ASes

Los prefijos reservados del protocolo de enrutamiento ff.ff.00.01 a ff.ff.00.05 DEBEN filtrarse en todos los routers de frontera.

19.7. Aplicación del prefijo mínimo /16

Los prefijos más específicos que /16 NO DEBEN aceptarse de peers BGP8 externos. Tales anuncios DEBEN ser rechazados y registrados vía NetLog8 como SEC-ALERT.

20. Consideraciones IANA

20.1. Número de versión IP

Se solicita a IANA asignar el número de versión 8 en el registro de IP Version Number al Protocolo de Internet Versión 8.

20.2. Reserva del prefijo de zona interna

Se solicita a IANA reservar el rango r.r.r.r de 127.0.0.0 a 127.255.255.255 como el espacio de prefijo de zona interna IPv8. Los números ASN de 2130706432 a 2147483647 NO DEBEN asignarse para enrutamiento público en internet.

20.3. Reserva del prefijo RINE

Se solicita a IANA reservar el rango r.r.r.r de 100.0.0.0 a 100.255.255.255 como el rango del tejido de peering RINE IPv8. Los números ASN de 1677721600 a 1694498815 NO DEBEN asignarse para enrutamiento público en internet.

20.4. Convención de enlaces interiores

Se solicita a IANA documentar el rango n.n.n.n 222.0.0.0/8 como la convención de direcciones de enlaces interiores IPv8.

20.5. Rango multicast entre ASes

Se solicita a IANA establecer un registro para prefijos multicast entre ASes IPv8 dentro del rango ff.ff.00.00 a ff.ff.ef.ff.

20.6. Reserva de broadcast

Se solicita a IANA reservar el valor r.r.r.r = ff.ff.ff.ff como la dirección de broadcast IPv8.

20.7. Tipo de registro DNS A8

Se solicita a IANA asignar un número de tipo de registro DNS de recurso para el tipo de registro A8 definido en la Sección 7.

20.8. Asignaciones de grupos multicast

Se solicita a IANA asignar grupos multicast dentro de ff.ff.00.00.224.0.0.0/24 según se define en la Sección 10.3.

20.9. Reservas de ASN privados

Se solicita a IANA reservar el ASN 65534 para peering BGP8 privado entre empresas y el ASN 65533 para documentación y pruebas, consistente con [RFC6996].

21. Referencias informativas

• [RFC1918] Rekhter, Y., "Address Allocation for Private Internets", BCP 5, RFC 1918, febrero 1996, rfc-editor.org/info/rfc1918.
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, marzo 1997, rfc-editor.org/info/rfc2119.
• [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, abril 1998, rfc-editor.org/info/rfc2328.
• [RFC2827] Ferguson, P. y D. Senie, "Network Ingress Filtering", BCP 38, RFC 2827, mayo 2000, rfc-editor.org/info/rfc2827.
• [RFC4271] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, enero 2006, rfc-editor.org/info/rfc4271.
• [RFC5398] Huston, G., "Autonomous System (AS) Numbers Reserved for Documentation Use", RFC 5398, diciembre 2008, rfc-editor.org/info/rfc5398.
• [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, julio 2013, rfc-editor.org/info/rfc6996.
• [RFC7519] Jones, M., "JSON Web Token (JWT)", RFC 7519, mayo 2015, rfc-editor.org/info/rfc7519.
• [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, septiembre 1981, rfc-editor.org/info/rfc792.
• [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, mayo 2017, rfc-editor.org/info/rfc8174.
• [RFC8200] Deering, S. y R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, julio 2017, rfc-editor.org/info/rfc8200.
• [RINE] Thain, J., "Regional Inter-Network Exchange", Work in Progress, Internet-Draft, draft-thain-rine-00, abril 2026.
• [ROUTING-PROTOCOLS] Thain, J., "IPv8 Routing Protocols", Work in Progress, Internet-Draft, draft-thain-routing-protocols-00, abril 2026.
• [SUPPORT8] Thain, J., "IPv8 Support Protocols — ARP8, ICMPv8, and Route8", Work in Progress, Internet-Draft, draft-thain-support8-00, abril 2026.
• [UPDATE8] Thain, J., "Update8 and NIC Certification", Work in Progress, Internet-Draft, draft-thain-update8-00, abril 2026.
• [ZONESERVER] Thain, J., "IPv8 Zone Server Architecture", Work in Progress, Internet-Draft, draft-thain-zoneserver-00, abril 2026.

Dirección del autor