On Wednesday 09 September 2015 14:59:10 Agrawal, Sachin wrote: > But, with DTLS security, we would have to find a mechanism to allow > successful decryption of packets when sender changes its address.
Or we figure out a way to announce that the address is changing. This is a lot harder since now we must monitor the network interfaces for the address attribute: when a temporary address becomes stale and what the new address is. That WILL require AF_NETLINK on Linux (bye-bye Android and Tizen...) and we'll be very, very pressed for the same information on other OS. Not to mention that this is about IPv6. For IPv4, the address change can be instantaneous, with no warning and no ability to send with the previous address once it happens. Third-party implementations of OIC will also be hard-pressed to implement the same solution. Easy way out: ignore the problem and let the keepalive/timeout mechanism to break the connection. OBSERVE replies (assuming they're CONfirmed), won't get confirmed, so the sender stops sending; clients sending to an address and receiving from another will ignore the reply, until they decide to drop the address from the cache and restart from multicast discovery. That reminds me: what is the time-to-live of a multicast discovery? How long should discovered resources be cached for? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
