Should a router use SLAAC for IPv6 address assignment?

Question

I am a little confused by the following 2 RFCs relating to IPv6:

• RFC 4862 (IPv6 Stateless Address Autoconfiguration)
• RFC 7084 (IPv6 CE Router Requirements)

RFC 4862 states:

The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means.

RFC 7084 lists one of its WAN-Side Configuration requirements for address assignment as:

WAA-1: The IPv6 CE router MUST support Stateless Address Autoconfiguration (SLAAC) [RFC4862].

Is there a contradiction here?

Should a router be able to autoconfigure an IPv6 address for its WAN interface?

---

Why does RFC 4862 say

Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means.

If I am using a router to connect my LAN to an ISP for example, isn't there a router in the ISP's network which is talking to my router?

I would have thought it was perfectly reasonable to have 2 (or more) routers chained together. In which case, why not use SLAAC on the second router's WAN interface?

---

Maybe the issue comes down to the artificial distinction between hosts and routers? From RFC 4862:

node - a device that implements IP.

router - a node that forwards IP packets not explicitly addressed to itself.

host - any node that is not a router.

But can't a host (i.e. a machine that is hosting servers or applications) also have a routing table, and function as a router? And we are effectively chaining 2 routers together again.

---

Edit: some extra information I later discovered ...

The Linux kernel handles SLAAC, and it follows RFC 4862 closely. Right down to the distinction between hosts and routers. See the kernel documentation on ip-sysctl:

• HOST behaviour is assumed. Which means Router Solicitations will be sent, and Router Advertisements will used for address autoconfiguration.
• Only if forwarding is enabled (/proc/sys/net/ipv6/conf/all/forwarding), the device is considered to be a ROUTER. Which means no Router Solicitations will be sent, and Router Advertisements will be ignored.

Turns out this distinction goes way back, pre-IPv6. See the parameter /proc/sys/net/ipv4/ip_forward:

This variable is special, its change resets all configuration parameters to their default state (RFC1122 for hosts, RFC1812 for routers)

Answer 1

In RFC 7084, it also states:

W-1: When the router is attached to the WAN interface link, it MUST act as an IPv6 host for the purposes of stateless [RFC4862] or stateful [RFC3315] interface address assignment.

So in short, yes - a router should be able to autoconfigure an IPv6 address for its WAN interface.

In reality though, most ISPs implement DHCPv6 and DHCPv6-PD (RFC3633) for downstream address allocation, along with prefix delegation.

This ensures that your router not only receives an address on it's WAN interface, but that it also receives a prefix it can use on it's internal LAN interface as well.

Answer 2

RFC 4862 really describes routers within a single administrative control. RFC 7084 clarifies how customer routers should behave. This gives an ISP some freedom in how it supports IPv6 to its customers.

To the PE router, the CE router is a host. From the perspective of a LAN (layer-2 domain, including the link from PE to CE), a router really is just another host on the network. In most cases, the WAN link addresses will be defined statically, via DHCP, or via PPP, not actually using SLAAC.

I think you missed the part in RFC 7084 that precedes what you quoted:

WAN-side requirements:

W-1: When the router is attached to the WAN interface link, it MUST act as an IPv6 host for the purposes of stateless [RFC4862] or stateful [RFC3315] interface address assignment.

Answer 3

Why does RFC 4862 say "Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means."

The people who wrote that document (and it's predecessor RFC 2462 ) almost certainly had a worldview that there were two types of devices. "hosts" that were numerous and a burden to manage and "routers" that were managed by competent network admins.

In the early 2000s we had the rise of always-on DSL/cable connections and also a rise in the number of people who had more than one computer at home that could make use of an internet connection. Since many ISPs would only give out one IP address to a customer (at least without charging extra) we saw a massive rise in the use of "home routers" with NAT to hide multiple computers behind such a connection. The NAT allowed the "home router" to hide it's true nature from the ISP, as far as the ISP was concerned the "home router" was just like a host.

Such usage was at first only "tolerated" by ISPs but eventually they decided it wasn't such a bad thing after all and started actually giving/selling the "home routers" to their customers. As a result we ended up with a huge number of these devices sitting in homes and small buisnesses.

It is only relatively recently that the IETF has started to properly explore how "home routers" and the ISPs that serve them should behave in the context of IPv6. The answer being that the "WAN side" interface should bahave much like a host while the "LAN side" interfaces should behave like a regular router. Since there is no NAT there is the need for some additional details to handle supplying addresses for the LAN side.

---

Regarding the Linux kernel it does indeed by default ignore RAs when routing is enabled, but this behaviour can be overridden if needed.