I work with a small ISP running all Mikrotik routers. We deployed IPv6 a couple years ago to our customers with very few issues. We are configured with a IPv6 DHCP server running on each customer facing router and hand out a /56 prefix to each customer from a /48 pool on each router. We use RADIUS to authenticate the prefix to the customer and build the queue (based on customer router MAC). Our billing system gets the MAC via Option 82 on the IPv4 address and then uses that same MAC to authorize the IPv6 prefix.
This worked great until we started getting calls from Google router owners that were unable to get a prefix from us. After a couple of them called Google support to see why, we were told we MUST hand out a /128 address to the Google router along with the prefix.
While annoying, I’d still like to support those routers. Using a Mikrotik test router configured as a customer router, we check the “Address” and “Prefix” option in the DHCP client and it doesn’t work. Checking just “Prefix” works fine but we are unable to get an address as well.
I have read through IPv6 documentation from Mikrotik on how to properly configure the IPv6 DHCP server to also create a address link along with a prefix and have not found any documentation on how to do this. I have plenty of prefixes I can set aside for /128 addressing to customers but don’t see how to set this up to automatically happen when a DHCP client requests an address along with a prefix.
Could it be that google router is expecting this as a SLAAC address you can just advertise? Some implementations I’ve seen deliver both, a /56 as PD and another /64 with auto-configuration (most likely for internal router administration from provider), maybe this could solve the problem.
Yes think so. I’m not 100% sure how it is implemented on their infra, but I would say announcing a /64 to the interface pointing to customer should do the work.
I have tested this at home network, announcing a /64 from my prefix pool to wireguard interface pointing to a remote location site, and the remote device get a single IP from SLAAC if it is listening for RAs. That way I can have a management public IPv6 that is auto-routed back to my main location.
You may want to do a test first with couple of users having those google devices and then decide if it is a good solution for you or not.
What you want to do fully is:
/56 ia_pd per customer, static (because BCOP-690 and SLAAC breaks with dynamic PD)
/128 ia_na per customer.
MikroTik DHCPv6 server doesn’t support ia_na, it only supports ia_pd.
You could use a /64 per VLAN with IPv6 RA, but this doesn’t support RADIUS/AAA. Each customer CPE will get randomised /128 over SLAAC, if illegal activities were to be conducted over these /128 SLAAC IPs, you’ll have issues with law enforcement when they come asking for logs.
This is one reason why all carriers and Telcos use ia_na and ia_pd with RADIUS or DIAMETER in some orgs.
Hello Nate, a question, starting from the fact that within the objectives of ipv6 it is that each client device has a public IP, and that the nat concept would not be present, how illegal activity could be carried out from the wan IP of the cpe device the client’s?
Following that line, wouldn’t it be useful for the WAN of the cpe to be assigned link-local IPV6 addresses or private iIPV6 addresses that are not routable to the Internet? Of course, assuming that clients do not need public access to their CPE, as is our case, we manage the CPE only ourselves and not the client.