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
