Since I avoid ULA like the plague, this probably won't be a problem
for me and global IPv6 addresses will be served. But I'm not convinced
that favoring a ULA prefix (if available) over an ip6prefix is best at
all times.
Nothing is favored, DHCPv6 just hands out ULAs only (if one is there).
Client can still decide what it uses to connect to anywhere, besides it
can't use an ULA to connect to the internet anyway.
Thus flash renumbering should still work (since only the ULA-address
cannot be changed immediately).
Is that okay with you or do you see any other issues?
Well, one thing that still worries me, is that the behavior of the
DHCPv6 server is different depending on the state of the O flag. From
a DHCPv6 client perspective, it shouldn't. When both M- and O-flag are
set, it is up to the client to decide if it wants to use DHCPv6 or
SLAAC. You've made it clear that there may be reasons not to use an
adress provided by DHCPv6 and use SLAAC instead. But this should not
be the only (or default) way of operation. There may be reasons other
than broken IPv6 uplinks why network administrators choose to set both
M- and O-flags. I think the other reasons are far more common (the
lack of DHCPv6 support in Android is just one of them). Even with the
changes pushed out today, odhcpd makes the assumption that the
ip6prefix can't be relied upon if a ULA prefix is provided and I think
that is just incorrect.
First of all the O-Flag is ignored whenever the M-Flag is set. Plus
there cannot be clients that only do DHCPv6 but not RAs, since DHCPv6
does not transmit any kind of routes thus a client cannot ignore RAs.
There are no assumption of unreliability of a prefix, ULAs aren't used
for internet communication since they are not routed. Sorry, I don't see
your point.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
