OpenWrt does not support SLAAC on the WAN interface

Installing and Using OpenWrt Network and Wireless Configuration
1

So far as I can make out from what I've tried, OpenWRT cannot auto-configure a WAN interface via SLAAC in the absence of a DHCPv6 server.

We're a small business and had to switch our fiber provider. The new provider came and installed what appears to be a terminating gateway/router (a Cisco Catalyst 3650). We received an email detailing an IPv4 range (/29( and an "IPv6 subnet" (a /56), each with a gateway.

I connected the single active port from the Cisco to the WAN port on our WRT3200ACM.

IPv4 was a breeze:

  • Set WAN to static address
  • configure the gateway address from the IPv4 range as gateway
  • configure a static IPv4 from the IPv4 range
  • IPv4 works
  • clients on the LAN side receive DHCPv4 addresses, have NATed connectivity etc.

The issue is IPv6.
The only thing that gateway sends out for IPv6 is a single ICMPv6 Router Advertisement packet, which contains a prefix:

09:18:55.920887 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::bee7:12ff:fe59:f056 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 64
        hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
          source link-address option (1), length 8 (1): bc:e7:xx:xx:xx:56
            0x0000:  bce7 xxxx xx56
          mtu option (5), length 8 (1):  1500
            0x0000:  0000 0000 05dc
          prefix info option (3), length 32 (4): 2001:xxxx:xxxx:3500::/56, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
            0x0000:  38c0 0027 8d00 0009 3a80 0000 0000 2001
            0x0010:  xxxx xxxx 3500 0000 0000 0000 0000

No matter what I do, how I configure the WAN interface, it never auto-configures a SLAAC address or requests a (partial) prefix.
Tried:

  • configure WAN6 interface as DHCPv6 -> no address or prefix configured on either WAN or LAN interfaces
  • configured WAN6 and LAN in relay mode as per https://openwrt.org/docs/guide-user/network/ipv6/start#ipv6_relay -> no address or prefix configured on either WAN or LAN interfaces, clients in LAN do not auto-configure addresses
  • manually configured the /56 prefix + IPv6 address from subnet on WAN interface, prefix assignment length on LAN -> WAN interface can now be pinged from outside, LAN interface now has an IPv6 from a smaller subnet, but cannot be pinged from outside, presumably because the fiber gateway doesn't know how to route the address (as inferred from tcpdump showing ND solicitations but no answers)
  • set "reqprefix" to "no" and "noslaaconly" to "0" explicitely as per https://openwrt.org/docs/guide-user/network/ipv6/start#protocol_dhcpv6 -> no address configured

I've sifted through countless forum topics and stackoverflow topics, but have not found any information on this scenario, which leads me to the conclusion that this scenario is either not supported by OpenWRT or the IPv6 implementation is somehow partially broken?

Any help or pointers to the contrary would be greatly appreciated. Perhaps I've simply overlook or misunderstood something.

2

No wonder it is not working, they have messed up what they do with IPv4 with IPv6. You are not supposed to advertise in the RA the whole /56, only a /64 and delegate the /56. If they are not willing to do that, the only solution I can think of is to advertise a /64 in the RA, you'll configure a static IP on the wan, fill in the /56 in the "Custom delegated prefix", and they will add a static route for the /56 via the wan6 IPv6.
Relay should work, but it is a workaround and not a clean solution.

1 Like
3

Sorry for the late reply, somehow the notification email for your reply didn't come through.

Thanks for your answer. In the end I resorted to pestering them until they reconfigured their switch. They were reluctant and kept going on about "untested cutting-edge technologies" until I sent them some RFCs concerning IPv6/DHCPv6 as well as the manual pages for their own switch describing how to setup DHCPv6-PD.
At first they delegated /64s only, until we complained about that, after which they reconfigured to delegate /60s. Far from optimal, but at least we're getting a prefix.

Now everything works just fine. I'm still confused as to why the WAN interface wouldn't autoconfigure using SLAAC or why the relay didn't work, but I'll take what we have now.

Again, thanks for your reply!

4

LOL

Maybe there is a misunderstanding on what SLAAC can autoconfigure. Prefix delegation is achieved by dhcp.

Generally it works, but the /56 is not a prefix one would use for a network. I can imagine a lot of devices would be confused with that.
Well done for convincing them!

5

Yes, that much is clear - what I meant was: given that the ISP's switch was at least sending out RAs, I would have hoped that the WAN interface (connected to the switch) would do SLAAC and obtain an IP. But it never worked, I had to manually configure an IP from the subnet.
One reason I hoped that would work was the noslaaconly option documented for the DHCPv6 protocol here: https://openwrt.org/docs/guide-user/network/ipv6/start#protocol_dhcpv6.
So either that option does not, in fact, work, or doesn't work for WAN ports, or - like you said - perhaps it just didn't like the /56 because it is so unexpected (instead of a /64).

But anyway - it works now.

1 Like
6

SLAAC is normally disabled on routers. So Linux defaults to disabled if forwarding is enabled. I have no idea what OpenWrt does.

See the docs for the different accept_ra* settings on https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html as well as the autoconf and the per-interface IPv6 forwarding settings. The traditional way to have SLAAC on WAN of a Linux router was to enable IPv6 forwarding globally but disable it on the WAN interface itself (which magically works anyway) But I believe you now can tune the accept_ra setting too.

I certainly agree that DHCPv6 is a much better alternative for the ISP, but disagree that there is anything wrong with announcing a /56 in an RA. The prefix length byte is there fore a reason. Any value between 0 and 128 is allowed. See https://datatracker.ietf.org/doc/html/rfc4861#section-4.6.2

This only tells you which prefix(es) should be considered on-link. Whether they are useful for autoconf is another question, answered by https://datatracker.ietf.org/doc/html/rfc4862#section-5.5.3

Which also discusses the point of using prefix lengths different from 128-N where N is the length of the interface identifier (typically 64):

  It is the responsibility of the system administrator to ensure
  that the lengths of prefixes contained in Router Advertisements
  are consistent with the length of interface identifiers for that
  link type.  It should be noted, however, that this does not mean
  the advertised prefix length is meaningless.  In fact, the
  advertised length has non-trivial meaning for on-link
  determination in [RFC4861] where the sum of the prefix length and
  the interface identifier length may not be equal to 128.  Thus, it
  should be safe to validate the advertised prefix length here, in
  order to detect and avoid a configuration error specifying an
  invalid prefix length in the context of address autoconfiguration.

I do share the concern that many implementations probably ignore these finer details though....