¿Debe un enrutador usar SLAAC para la asignación de direcciones IPv6?

Estoy un poco confundido por los siguientes 2 RFC relacionados con IPv6:

• RFC 4862 (configuración automática de direcciones sin estado IPv6)
• RFC 7084 (requisitos de enrutador IPv6 CE)

RFC 4862 establece:

El proceso de autoconfiguración especificado en este documento se aplica solo a los hosts y no a los enrutadores. Dado que la configuración automática del host utiliza la información anunciada por los enrutadores, los enrutadores deberán configurarse por otros medios.

RFC 7084 enumera uno de sus requisitos de configuración del lado WAN para la asignación de direcciones como:

WAA-1: el enrutador IPv6 CE DEBE admitir la configuración automática de direcciones sin estado (SLAAC) [RFC4862].

¿Hay una contradicción aquí?

¿Debería un enrutador ser capaz de configurar automáticamente una dirección IPv6 para su interfaz WAN?

¿Por qué dice RFC 4862?

Dado que la configuración automática del host utiliza la información anunciada por los enrutadores, los enrutadores deberán configurarse por otros medios.

Si estoy usando un enrutador para conectar mi LAN a un ISP, por ejemplo, ¿no hay un enrutador en la red del ISP que esté hablando con mi enrutador?

Pensé que era perfectamente razonable tener 2 (o más) enrutadores encadenados. En ese caso, ¿por qué no usar SLAAC en la interfaz WAN del segundo enrutador?

¿Quizás el problema se reduce a la distinción artificial entre hosts y enrutadores? De RFC 4862:

nodo: un dispositivo que implementa IP.

enrutador: un nodo que reenvía paquetes IP no dirigidos explícitamente a sí mismo.

host: cualquier nodo que no sea un enrutador.

Pero, ¿no puede un host (es decir, una máquina que aloja servidores o aplicaciones) también tener una tabla de enrutamiento y funcionar como un enrutador? Y efectivamente estamos encadenando 2 enrutadores juntos de nuevo.

Editar : alguna información adicional que descubrí más tarde ...

El kernel de Linux maneja SLAAC y sigue de cerca RFC 4862. Hasta la distinción entre hosts y enrutadores. Consulte la documentación del kernel en ip-sysctl :

• Se supone el comportamiento del HOST. Lo que significa que se enviarán solicitudes de enrutador y se utilizarán anuncios de enrutador para la configuración automática de direcciones.
• Solo si el reenvío está habilitado ( /proc/sys/net/ipv6/conf/all/forwarding), el dispositivo se considera un ENRUTADOR . Lo que significa que no se enviarán solicitudes de enrutador y se ignorarán los anuncios de enrutador.

Resulta que esta distinción se remonta, anterior a IPv6. Ver el parámetro /proc/sys/net/ipv4/ip_forward:

Esta variable es especial, su cambio restablece todos los parámetros de configuración a su estado predeterminado ( RFC1122 para hosts, RFC1812 para enrutadores)

En RFC 7084, también establece:

W-1: cuando el enrutador está conectado al enlace de la interfaz WAN, DEBE actuar como un host IPv6 para propósitos de asignación de dirección de interfaz sin estado [RFC4862] o con estado [RFC3315].

En resumen, sí, un enrutador debería ser capaz de configurar automáticamente una dirección IPv6 para su interfaz WAN.

Sin embargo, en realidad, la mayoría de los ISP implementan DHCPv6 y DHCPv6-PD ( RFC3633 ) para la asignación de direcciones en sentido descendente, junto con la delegación de prefijo.

Esto garantiza que su enrutador no solo reciba una dirección en su interfaz WAN, sino que también reciba un prefijo que también puede usar en su interfaz LAN interna.

RFC 4862 realmente describe enrutadores dentro de un único control administrativo. RFC 7084 aclara cómo deben comportarse los enrutadores del cliente. Esto le da al ISP cierta libertad en la forma en que admite IPv6 a sus clientes.

Para el enrutador PE, el enrutador CE es un host. Desde la perspectiva de una LAN (dominio de capa 2, incluido el enlace de PE a CE), un enrutador realmente es solo otro host en la red. En la mayoría de los casos, las direcciones de enlace WAN se definirán estáticamente, a través de DHCP o PPP, sin usar SLAAC.

Creo que se perdió la parte en RFC 7084 que precede a lo que citó:

Requisitos del lado de WAN:

W-1: cuando el enrutador está conectado al enlace de la interfaz WAN, DEBE actuar como un host IPv6 para propósitos de asignación de dirección de interfaz sin estado [ RFC4862 ] o con estado [ RFC3315 ].

¿Por qué dice RFC 4862 "Dado que la autoconfiguración del host utiliza la información anunciada por los enrutadores, los enrutadores deberán configurarse por algún otro medio".

Las personas que escribieron ese documento (y su predecesor RFC 2462) casi seguramente tenían una visión del mundo de que había dos tipos de dispositivos. "hosts" que eran numerosos y una carga para administrar y "enrutadores" administrados por administradores de red competentes.

A principios de la década de 2000 tuvimos el aumento de las conexiones DSL / cable siempre activas y también el aumento de la cantidad de personas que tenían más de una computadora en casa que podían hacer uso de una conexión a Internet. Dado que muchos ISP solo darían una dirección IP a un cliente (al menos sin cobrar más), vimos un aumento masivo en el uso de "enrutadores domésticos" con NAT para ocultar varias computadoras detrás de dicha conexión. El NAT permitió que el "enrutador doméstico" ocultara su verdadera naturaleza al ISP, en lo que respecta al ISP, el "enrutador doméstico" era como un host.

Al principio, los ISP solo "toleraban" ese uso, pero finalmente decidieron que no era tan malo después de todo y comenzaron a dar / vender los "enrutadores domésticos" a sus clientes. Como resultado, terminamos con una gran cantidad de estos dispositivos ubicados en hogares y pequeños negocios.

Es relativamente reciente que el IETF ha comenzado a explorar adecuadamente cómo se deben comportar los "enrutadores domésticos" y los ISP que los atienden en el contexto de IPv6. La respuesta es que la interfaz del "lado WAN" debe funcionar como un host, mientras que las interfaces del "lado LAN" deben comportarse como un enrutador normal. Como no hay NAT, se necesitan algunos detalles adicionales para manejar el suministro de direcciones para el lado LAN.

Con respecto al kernel de Linux, de hecho ignora los RA cuando el enrutamiento está habilitado, pero este comportamiento puede anularse si es necesario.