On Sep 2, 2019, at 1:47 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > Assuming that the prefix change is make-before-break (which we > do not clearly know how to do on the WAN side, I think), then the web > server should configure with the same rfc7212 IID, but a new prefix.
To be clear, the issue of the make-before-break is on the WAN DHCPv6-PD side. I believe that we concluded that it's possible to do in existing specifications, but not well enough implemented at both sides (ISP/CPE) device to depend upon. Ted Lemon wrote on 05/09/2019 18:31: > I don’t think there’s any need for the IID to be persistent. > Make-before-break is accomplished by deprecating the old prefix when > the new prefix is added. This is trivial to do; whether it is in fact > done is a different matter. I think that at present the client would > have to notice that it’s happened. Ray Hunter (v6ops) <v6...@globis.net> wrote: > Agreed. > Using RFC7217 will anyway almost certainly guarantee that the IID will > also change if the prefix changes. > The prefix is included in the function that generates candidate IID's. > RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) > That was done to prevent tracking when people move between wifi > hotspots. But, a host running a web server that wants to be in the same place could keep the same RID once generated. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet