On IPv6 networks with non-link local addresses, it's very common (and recommended) that devices use a randomly-generated IP address that expires after a pre-determined time. After that happens, the device will generate another device and start using it.
There's also a grace period in which the old address is still available, but is not preferred. That is to say, it's no longer selected by default as the outgoing address of any packet. A device can still be reached with this address, though. Question: how does IoTivity deal with this? And how does the OIC protocol do it? Scenario: DeviceA and DeviceB are happily communicating with each other, over a DTLS-encrypted channel. The type of communication is not relevant, as it can be: * regular unicast request-responses * OBSERVE replies * UDP-based block transfer What happens if the device sending a packet suddenly changes its address? Let's say that DeviceA is about to send a reply to DeviceB. DeviceA had address A1 that it used in the last packet. For the next packet, A1 lost freshness and A2 is now the preferred address. Should 1) DeviceA send still with A1? If so, how will DeviceB be told that the address has changed? How long is DeviceB allowed to cache the IP address for DeviceA for the resource it had discovered? How about the case of a long- standing OBSERVE reply, how will DeviceB be told that the address is changing? 2) DeviceA send now with A2? In this case, we need to assume that the DTLS layer will continue to authenticate the sender regardless of IP sender address. There is no problem here. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
