[core] Discovery optimization for Link Format: use the unspecified IPv6 address

[Esko Dijk <[e-mail]>]

Hi CoRE,

In the recent spirit of removing unused bytes on the wire, I have the 
below proposal for cases where CoRE Link Format is used for discovery.
cBRSKI and cBRSKI Join Proxy are example protocols that use this.

In some cases, an IPv6 address is necessarily included in a Link Format 
response even though the protocol doesn't use the included address at all.
The proposal is that for such cases the IPv6 unspecified address (::) 
can be used, which shortens the payload and reduces potential for errors.

An example discovery interaction from cBRSKI:

~~~~
   REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp

   RES: 2.05 Content
   <coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp
~~~~

In this link-local discovery scenario, the responding entity (a Join 
Proxy) includes its LL IPv6 address in the link even though the client 
is not going to use it.
The client will use the IPv6 LL source address of the CoAP response to 
send the next (CoAPS) packet to, on UDP port 8485. This is how the 
protocol is currently specified.
It requires the IP layer or CoAP stack to be able to provide the IP 
source address of a response to the higher layer, which is generally 
available on embedded systems.

Knowing the client MUST follow this procedure for the resource, the 
server could decide to not disclose the IPv6 address: i.e. leave it 
unspecified in scope of the Link Format document.
RFC 4291 and RFC 4861 would allow such use of the unspecified address; 
and per RFC 3986/6690 it yields a valid CoRE link.

The result is then shorter - 31 bytes for the payload instead of 53.

~~~~
   REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp

   RES: 2.05 Content
   <coaps://[::]:8485>;rt=brski.jp
~~~~

This also reduces the potential for ambiguity in implementations, e.g. 
the behavior that some clients may parse the IP-literal to use it to 
contact the Join Proxy while others may use the IPv6 source address of 
the CoAP message.
If most client's don't parse the IP-literal then some error in the 
IP-literal on the server side may go undetected.

Does this sound like a proper use of Link Format? It does seem to make 
sense that we can suppress information that's already encoded in the 
response CoAP UDP message, one of the core features of CoAP :)
Is there a need to formally Update RFC 6690 before starting to use this? 
(To me it seems like a useful feature also in other scenarios.)
The formal semantics of the IPv6 unspecified address within a Link 
Format document then could be "an IPv6 adress equal to the IPv6 address 
in the link format resource's base URI". And similar for IPv4 
unspecified address.

regards
Esko

-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339