#23 server responds from wrong endpoint (ipv6 address)

[Peter A. Bigot]

When coap-server is started on a node that has multiple IPv6 addresses bound to a particular interface, and a client sends a request to one of them from another host, the server may respond from a different address:

No.     Time        Source                Destination           Protocol Length Info
  95 6.199450    fd5c:f310:9ade:0:c4ce:b38:35d0:945e fd5c:f310:9ade:0:ca60:ff:fe24:e903 CoAP     70     CON, MID:10591, GET, coap://llc
  96 6.199519    fd5c:f310:9ade:0:3056:6a5f:cb3e:7129 fd5c:f310:9ade:0:c4ce:b38:35d0:945e CoAP     199    ACK, MID:10591, 2.05 Content (text/plain)
 144 8.328725    fd5c:f310:9ade:0:c4ce:b38:35d0:945e fd5c:f310:9ade:0:ca60:ff:fe24:e903 CoAP     70     CON, MID:10591, GET, coap://llc
 145 8.328789    fd5c:f310:9ade:0:3056:6a5f:cb3e:7129 fd5c:f310:9ade:0:c4ce:b38:35d0:945e CoAP     199    ACK, MID:10591, 2.05 Content (text/plain)
 453 12.588220   fd5c:f310:9ade:0:c4ce:b38:35d0:945e fd5c:f310:9ade:0:ca60:ff:fe24:e903 CoAP     70     CON, MID:10591, GET, coap://llc
 454 12.588302   fd5c:f310:9ade:0:3056:6a5f:cb3e:7129 fd5c:f310:9ade:0:c4ce:b38:35d0:945e CoAP     199    ACK, MID:10591, 2.05 Content (text/plain)
1051 21.193978   fd5c:f310:9ade:0:c4ce:b38:35d0:945e fd5c:f310:9ade:0:ca60:ff:fe24:e903 CoAP     70     CON, MID:10591, GET, coap://llc
1052 21.194019   fd5c:f310:9ade:0:3056:6a5f:cb3e:7129 fd5c:f310:9ade:0:c4ce:b38:35d0:945e CoAP     199    ACK, MID:10591, 2.05 Content (text/plain)
1387 38.147942   fd5c:f310:9ade:0:c4ce:b38:35d0:945e fd5c:f310:9ade:0:ca60:ff:fe24:e903 CoAP     70     CON, MID:10591, GET, coap://llc
1388 38.148014   fd5c:f310:9ade:0:3056:6a5f:cb3e:7129 fd5c:f310:9ade:0:c4ce:b38:35d0:945e CoAP     199    ACK, MID:10591, 2.05 Content (text/plain)

This breaks the transaction lookup algorithm resulting in (obviously) a failure to recognize the ACK and unnecessary retransmission of the packets. This when the server has:

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fd5c:f310:9ade:0:3056:6a5f:cb3e:7129/64 scope global temporary dynamic 
       valid_lft 86379sec preferred_lft 14379sec
    inet6 fd5c:f310:9ade:0:4d5d:ec2:5be1:2f0e/64 scope global temporary deprecated dynamic 
       valid_lft 86379sec preferred_lft 0sec
    inet6 fd5c:f310:9ade:0:885a:5748:63e9:42f7/64 scope global temporary deprecated dynamic 
       valid_lft 86379sec preferred_lft 0sec
    inet6 fd5c:f310:9ade:0:1009:73ae:bba8:dcd5/64 scope global temporary deprecated dynamic 
       valid_lft 86379sec preferred_lft 0sec
    inet6 fd5c:f310:9ade:0:84e2:f126:7b78:d77c/64 scope global temporary deprecated dynamic 
       valid_lft 86379sec preferred_lft 0sec
    inet6 fd5c:f310:9ade:0:ca60:ff:fe24:e903/64 scope global dynamic 
       valid_lft 86379sec preferred_lft 14379sec
    inet6 fe80::ca60:ff:fe24:e903/64 scope link 
       valid_lft forever preferred_lft forever

Note that the client is directing the request to the DNS-registered IP address, but the server is responding from the current (non-deprecated) temporary address.

[Sergej Pupykin]

it also breaks multicast:
./coap-server -v 10 -g FF12::11
./coap-client -v 10 -m get coap://[FF12::11]/.well-known/core

however unicast works with the same server:
./coap-client -v 10 -m get coap://[::1]/.well-known/core