Thiago,

The matching of replies to requests is based on the token sent in the request 
and returned in the reply.  The address is not used for matching, AFAIK.

I don't know how DTLS uses addresses, so someone else will have to comment.

John  

-----Original Message-----
From: Macieira, Thiago 
Sent: Wednesday, September 09, 2015 8:11 AM
To: iotivity-dev at lists.iotivity.org
Cc: Light, John J
Subject: Re: [dev] Dealing with IP address changes

Hi John

The problem is matching a reply that came from address A2 to a request that was 
sent to address A1.

Does this matching need to happen before the DTLS layer kicks in?

On Tuesday 08 September 2015 08:48:08 Light, John J wrote:
> Thiago,
> 
> I don't fully understand how the situation you describe unfolds, so I 
> don't have a complete answer, but I have a piece of the puzzle.
> 
> Every time IoTivity receives a response concerning a resource, it 
> returns the latest address in the C API and updates the address in 
> OCResource for the C++ API.  So if a server changes its IP address, a 
> C++ client will use the new IP address, and a C client will be able to.
> 
> John
> 
> 
> 
> -----Original Message-----
> From: iotivity-dev-bounces at lists.iotivity.org
> [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Thiago 
> Macieira Sent: Monday, September 07, 2015 8:36 AM
> To: iotivity-dev at lists.iotivity.org
> Subject: [dev] Dealing with IP address changes
> 
> 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
> 
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

Reply via email to