Hi all,

in the OMA device management group we have been discussing the 
implications of IP address and/or port number changes of devices 
(particularly with devices that sleep for an extended period of time).

The challenge from a protocol point of view is to use an identifier that 
does not depend on the IP address and port. Of course, when a IP packet 
has to be sent to a specific node then IP address and port information 
has to be used from somewhere but my expectation is that at least the 
protocol machinery shouldn't break when an IP address changes (or there 
should be a story for how to recover).

In CoAP the 'endpoint' appears to be an important identifier. In an 
attempt to define what an endpoint is the CoAP specification is a bit 
confusing:

Section 1.2 says:

"
    Endpoint
       An entity participating in the CoAP protocol.  Colloquially, an
       endpoint lives on a "Node", although "Host" would be more
       consistent with Internet standards usage, and is further
       identified by transport-layer multiplexing information that can
       include a UDP port number and a security association
       (Section 4.1).
"	

Section 4.1 of RFC 7252 says:
	
"
    A CoAP endpoint is the source or destination of a CoAP message.  The
    specific definition of an endpoint depends on the transport being
    used for CoAP.  For the transports defined in this specification, the
    endpoint is identified depending on the security mode used (see
    Section 9): With no security, the endpoint is solely identified by an
    IP address and a UDP port number.  With other security modes, the
    endpoint is identified as defined by the security mode.
"

The two definitions do not appear to be in sync, particularly when using 
DTLS to secure CoAP since the DTLS record layer adds nothing with 
respect to additional multiplexing. I also did not find text that 
describes what the different endpoint definition is when DTLS is used.

In any case, when DTLS is used an IP address / port change at the client 
will prevent the CoAP server from finding the right security context and 
a new (hopefully abbreviated) handshake has to be run.

Luckily the implications of an IP address/port change are quite minimal 
for CoAP itself since the only impact (as far as I can tell) is with 
regards to the use of request/response exchange, as described in Section 
5.3.2 "Request/Response Matching Rules". The likelihood that a client 
changes IP address in the middle of a request/response interaction are 
IMHO minimal.

The story is more interesting when we look at extensions to CoAP, like 
CoAP Observe. Section 4.1 of https://tools.ietf.org/html/rfc7641 says:

"
    The entry in the list of observers is keyed by the client endpoint
    and the token specified by the client in the request.  If an entry
    with a matching endpoint/token pair is already present in the list
    (which, for example, happens when the client wishes to reinforce its
    interest in a resource), the server MUST NOT add a new entry but MUST
    replace or update the existing one.
"

With Observe a token is used for demultiplexing (in addition to the 
endpoint info). I assume that the spec uses the same definition of 
endpoint as in CoAP.

While the spec does not say what is actually being updated or replaced 
one can assume that a client sending a request with a new IP address and 
port (which corresponds to the endpoint definition in CoAP) gets at 
least that information updated.

The spec is IMHO unclear what should happen in case of an IP 
address/port change. I suspect that an implementation would send a new 
register message and the server would update state. Of course, when the 
IP address / port of the client is not in sync with what is being stored 
at the server then the notifications sent by the server will not reach 
the client.

The story for RD appears to be different again. First, there appears to 
be a different definition of endpoint being used (which I prefer more). 
For multiplexing it does not use IP address & port information. Of 
course, RD will still have to maintain this information but at least one 
can be sure that packets are not dropped after the IP address and/or 
port at the client change.

Section 11.1 of draft-ietf-core-resource-directory-08 says:

"
    An Endpoint is determined to be unique by an RD by the Endpoint
    identifier parameter included during Registration, and any associated
    TLS or DTLS security bindings.  An Endpoint MUST NOT be identified by
    its protocol, port or IP address as these may change over the
    lifetime of an Endpoint.
"

It appears that the way how state is indexed is different throughout the 
specifications developed in the CORE working group and I am curious 
whether someone else has been looking at the implications of IP address 
and/or port changes on the protocol operation. I would certainly 
appreciate your thoughts on this topic.

Ciao
Hannes