Esko, Makes sense to me. An alternative would be fe80::, which is a valid LL address, if any client is likely to check the format.
Regards/Ngā mihi Brian Carpenter On 17-Sep-25 23:44, Esko Dijk wrote:
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: [email protected] | +31 6 2385 8339 _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
