IPv6 #

Most of the IPv6 basics is neatly covered by OneMarkFifty on YouTube.

Docomo Celullar 4G / 5G #

*Since about 2022, all devices officially sold by NTT DoCoMo resellers are IPv6 capable, so Docomo seems to put new devices on IPv6-first networks, with 4-in-6 capability enabled. So, the first paragraph below is applicable only for BYOD devices or older phones without IPv6 capability.

It looks like IPv4 capable devices, depending on the location, get assigned either only v4 address or both v4 and v6 addresses on the Docomo network. The IPv4 address is always behind a CGNAT. In my case, when the device is on a single-stack IPv4, it get assigned 10.n.n.n.

When the device gets an IPv6 addresss (going forward, probably this will be more prevalent), it configures an additional Dual-Stack Light (DS-Light) IPv4 address, in my case, typically 192.0.0.2. So, from user’s perspective there seems to be zero issues accessing both IPv4 and IPv6 resources.

The assigned IPv6 prefix is dynamic, when the device reboots it gets an address with a new IPv6 prefix. Probably the network also reassigns the prefix every 24 or 48 hours as well.

Refs:

No DHCPv6 Prefix Delegation #

While downstream devices connected to a Docomo 5G router or a smartphone get assigned IPv6 addresses within the same 240a:nnnn::/64 prefix, unfortunately, the router does not implement DHCPv6 prefix delegation (PD) or the network does not allow it (possibly both). This means that some of the IPv6 experiments cannot be done on global IPv6 addresses and should be conducted using local addresses in the fc00::/7 range.

The gateway router (running OpenWrt) must be configured to “relay” RA and DHCPv6 requests to the ISP router (Docomo 5G modem/router) to allow downstream nodes to get global IPv6 addresses. However, nodes that use predictable SLAAC addresses sometimes fails to get an address immediately after a reboot. I think this happens because of the following procedure.

After a reboot, the node sends a DHCPv6 request, which gets relayed to the ISP router. The ISP router allows the node to self-assign an address (use the SLAAC scheme). The node generates a stateless predictable address and sends a duplicate address detection (DAD) ICMPv6 request to the network, to which, it gets a reply “yes, there is already a device with that address” from the ISP router, because the address is already in the ARP table of the ISP router. Furthermore, because the link-local hardware address the requested SLAAC address is assgned to is not the node’s own interface but the WAN interface of the gateway router, the node concludes that the address is already in use by another device on the network.

Eventually such nodes still manage to obtain an IPv6 address via SLAAC. This requires more investigation, possible reasons why the nodes eventually manage to obtain a SLAAC address:

the assignment becomes possible when the network prefix changes,
over time, the ISP router discards stale records from its ARP table.

Note As far as I understand, the “no DHCPv6 prefix delegation” issue is limited to only celullar connections. On other networks, such as ドコモ光電話 (DoCoMo Hikari Denwa - home phone/internet over fiber) and probably offerings by other competing ISPs, I think prefix delegation will not be an issue. Users who really need this functionality probably can easily switch to ISPs that offer it. So, while it is possible to setup a downstream router to mitigate the delayed IPv6 assignment on some nodes (configure, fake prefix delegation, or filtering certain ICMPv6-DAD responses). The time investment required to find such a workaround is probably not worth it.

We can list other machines (neighbours) the node is aware of with ip neigh or to list only IPv6 neighbours:

ip -6 neigh

Ref: