How misconfigured IPv6 in some providers network

cause

In short,
Providers, please unset autonomous address configuration flag in router advertisement if you do not want to assign the entire prefix to a customer.
Provide IPv6 gateway and on-link network information to reduce support tickets.

---

Some providers here claim native IPv6 support but failed to configure router advertisement, or do not provide necessary information to configure IPv6 on the customer side.
If you are one of providers who offer IPv6, please take some time to check your network configuration.

Background:

Unlike IPv4 only have DHCP as a de fact, there are several options to configure IPv6 network and that require not only assigned IP address.

• Assign /64 prefix or an address (/128) to a customer.
• Configure statically, via router advertisement (RA), or dhcpv6 (stateful).

By design, IPv6 addresses are assigned in /64 range for a customer, or a VM. RA provides on-link prefix but does not specify which address in the prefix should be used.
If the router was configured to announce assigned /64 prefix for respective VM interface, no need to configure on the customer side. The prefix and router information provided in the RA will be used in SLAAC without infringing each other.
It seems Vultr uses RA in this way.

The problem: misconfigured RA

If RA was configured to announce a large prefix (say /32) for all VMs/customers as a shared subnet, although this is not recommended and vulnerable to DoS, providers have to tell customers which is assigned prefix range.

In this case, prefix information in the RA, that is different from assigned range, must unset its autonomous address configuration flag. Otherwise, VMs receiving the RA will use any address in the entire large prefix.

You can check this in rdisc6 command from VM side.

$ sudo rdisc6 ens3

...
Autonomous address conf.: No
...

For Cisco routers, the prefix should be configured with no-autoconfig flag.

Some providers here mistakenly configure their RA to send prefix with the AAC flag on. It will force VMs to use unusable SLAAC generated address instead statically configured address, then break IPv6 reachability.

For customers, do not forget to check RA and its autonomous address configuration flag. If misconfigured, disable accept-ra to ignore the false information and use static config. Misconfigured RA periodically sent from the router will break your reachability randomly...

I found Racknerd (seems not responding to solicitation), Virtno, sent RA with the AAC flag set (should be unset).

The problem 2: Missing info

Some providers here disabled RA and use static IPv6 address assignment.
In this case, network information should be sent to the customer in some way. However, widely used management panels provide assigned address only.

Basically, IPv6 needs following info.

• Assigned address prefix (or an address)
• On-link network prefix (= local subnet in IPv4)
• Default gateway address

I have several times to submit ticket to know just a gateway address not responding to solicitation. Why not to add the network information in VM creation notice or somewhere?

I could find only Hosthatch provides gateway IP and on-link subnet mask in their custom panel.

For customers side, if your provider did not provide network information, ping ff02::2%ens3 (multicast for routers) or rdisc6 -w 1800000 ens3 (wait periodic advertisement) might retrieve router address from network.

I hope this post will help better IPv6 deployments.

Thanks.

alilet

Thanks. As a customer I faced issues a couple of times when VPS had IPv6. This post will come in handy.