Hi all,
Just wanted to continue the earlier thread about use of the IPv6
unspecified address in CoRE link format links. The CoRE consensus was
that this isn't a good idea - for various reasons related to the
unspecified result of an unsuspecting client trying to resolve such a link.
An alternative to the string "::" would be a short hostname that's
guaranteed to be not resolved using the DNS, or using some local name
configuration, or other known methods.
I found this domain that would have the desired properties: "alt". See
RFC 9476. This can be used to construct hostnames that are allowed to be
used in URIs but have no defined way in IETF to resolve, nor is there a
registry for the "alt" domain. This implies that a generic client
getting a link with such a hostname; by design (if knowing about RFC
9476) would not look it up using DNS, or otherwise (if not knowing about
the RFC) would get a failed address lookup such that the link can't be
followed.
Now the example for discovery of Join Proxies becomes:
~~~~
REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp
RES: 2.05 Content
Content-Format: 40 (application/link-format)
Payload:
<coaps://jp.alt:8485>;rt=brski.jp
~~~~
In the (likely) case that the client knows about cBRSKI Join Proxies, it
would just ignore the "jp.alt" hostname because that's what the protocol
specifies and use only the port number.
In the case a generic client not knowing about cBRSKI would get the
link, it wouldn't lead to any CoAP request being sent out or DTLS
handshake being attempted. So that seems safe.
An even shorter version would be just "alt" for the hostname. Or
"jp.brski.alt" if potential name clashes are a worry.
best regards,
Esko
On 27-9-2025 02:02, Brian E Carpenter wrote:
On 27-Sep-25 09:10, Christian Amsüss wrote:
On Sat, Sep 27, 2025 at 08:47:00AM +1200, Brian E Carpenter wrote:
On your point 2: when CoRE link format, that contains links with an
IP literal in the URI,
Especially, it is *guaranteed* to fail if the IP literal is an IPv6
link-local address, since the URI cannot express the interface ID,
because the browser community has categorically refused the necessary
extension to the URI syntax. (RFC 6874 is obsolete.)
I don't think this is guaranteed to fail, at least not for CoAP clients.
At least one CoRE document (RFC9176) has talked about link-local address
in web links (and thus URLs) specifically, and taken a
split-horizon-like view: As long as the request is made through a
link-local address, the server *can* represent link-local addresses as
long as it learned them on the same interface.
Yes, but the context here was sending a URI to a different host, and that
is pretty certain to fail.
GRASP relies on exactly what you describe: if you learn a link-local
address
via GRASP discovery, you *must* associate it with the same interface.
It isn't
hard, but quite a lot of software gets this wrong in my experience,
because
it's (badly) adapted from IPv4 code.
Brian
BR
Christian
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
