Hi Bob, > > > > As far as I can see, if I set the RFC 4941 timer to a reasonable > > value, my IID will change much more often than my subnet prefix. > > > > I would like to see the answer to Brian's comment, I didn't see a response to it > in the thread. >
That is true. But the problem that I address is not why my IID does not change within the same subnet prefix. The problem is, based on this RFC, that it is not mandatory to change the IID when my node receives a new prefix. This is because it depends on the lifetime it receives from the RA. If the RA message says that my node might extend its lifetime, then the node does it while the IID is still valid (max lifetime). This means that when the lifetime is still valid and the new prefix uses this option, my IID will not change to a different prefix. What I added to my draft is that I set a mandatory priority on the IID lifetime. When it receives a new prefix, regardless of its own lifetime or on the lifetime that it received from the prefix, it MUST generate a new IID and change the status of the current IID to deprecated. This means that the node, after that, is not allowed to open any new sessions (will change it to new connections) using the old IID, but it can maintain its connection with the old IID. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
