Thanks Claude. But maybe we should avoid normalizing ND proxy, lest we end up with ISPs that think it's okay to not provide delegated prefixes? We already have some doing that now; we don't need more.
Note that RFC 7278 doesn't prescribe ND proxy use for the mobile network case. Mobile networks provide the /64 over a point-to-point interface, so they can simply put the /64 and their own address on the LAN interface and it'll work fine, as described in the examples at the end of the RFC.
Agreed, ND proxy shouldn't be normalized. But the hack is the same whether it's automated or not; the difference is whether users get working IPv6 or give up because it's too hard to set up. The latter is worse: if users give up on IPv6, ISPs may conclude they needn't provide IPv6 at all, let alone delegated prefixes. I'm thinking of logging a warning whenever the fallback kicks in, suggesting users ask their ISP for PD.
You're right about RFC 7278, I misread it. It only describes a routed setup, moving the /64 to the LAN. So on point-to-point WANs I'll do exactly that, and use ND proxy only when the /64 is on-link on a broadcast WAN.
Things are improving, though. In Japan, NTT's newer 10G service delegates a /56 by default; only the older 1G service without a phone subscription is stuck with a single /64.
2 comments
[ 2.0 ms ] story [ 13.2 ms ] threadNote that RFC 7278 doesn't prescribe ND proxy use for the mobile network case. Mobile networks provide the /64 over a point-to-point interface, so they can simply put the /64 and their own address on the LAN interface and it'll work fine, as described in the examples at the end of the RFC.
You're right about RFC 7278, I misread it. It only describes a routed setup, moving the /64 to the LAN. So on point-to-point WANs I'll do exactly that, and use ND proxy only when the /64 is on-link on a broadcast WAN.
Things are improving, though. In Japan, NTT's newer 10G service delegates a /56 by default; only the older 1G service without a phone subscription is stuck with a single /64.