Hi,
First for all thread readers here, let me point to the minutes of the
interim in which we discussed the optimization proposal in depth:
https://datatracker.ietf.org/doc/minutes-interim-2025-core-14-202509241400/
The conclusion here was that CoRE Link Format relies on the fact that
absolute URIs in links are links that can be followed/resolved, or
*could* be by a client. Having the unspecified address in there makes
this behavior unspecified with potentially undesired side effects. E.g.
some resolvers will substitute the unspecified address with something
implementation-specific like "localhost" or an IP address it has
assigned. So the consensus was to try to stay away from such use. Maybe
a good standard behavior when seeing the unspecified address in a CoRE
link would be "don't resolve/follow this link".
On your point 2: when CoRE link format, that contains links with an IP
literal in the URI, travels through NATs/middleboxes it can be the case
that the resulting link can't be followed anymore by the client. So
you're right about seeing a potential problem there. But that depends on
the contents of the link, the specific address, and the specific network
topology. The same problem might occur when hostnames are included, e.g.
if a host behind a firewall can't be reached. I assume we don't want
middleboxes to go rewrite link-format document content. Security-wise,
if DTLS or OSCORE security is used this wouldn't be possible.
The default way of storage-efficient links in LF (see example below)
does address this problem as it allows the client to fetch the resources
at the same address/port/protocol it's already communicating on - can be
through NATs/middleboxes that change port numbers.
</coap/resource/example>;rt=mytype;if=example
The use of the unspecified address would not achieve the same benefit -
although it can point to another port, or another protocol, or another
port+protocol situated on the same server, like so:
<coaps://[::]:6789/secure/resource/example>;rt=mytype;if=example
there's no guarantee that the client using port 6789 will actually get
to this resource at all. (The middleboxes may have this port blocked or
mapped otherwise.) So the problem remains.
regards
Esko
On 26-9-2025 01:31, Toerless Eckert wrote:
Thanks, Esko
1. Given how Core LF is derived from RFC8288 (aka: for HTML), i was wondering
what
Mark would think about it:
> No real opinion - what Core does is a serialisation of links --
> as long as it maps back to the data model in 8288, how it's done is up to
core.
So, i think from that perspective we're fine.
2. Beyond saving bits on the wire, i wonder if/how this approach could make
specific
"middleboxes" operate more sanely.
The good old BEHAVE problem for NAT was that rewriting message payloads to
map
addresses and ports sucks. And does not work in the face of end-to-end
encryption.
Hence the WG and rules it came up with. Arguably, CoAP discovery with HTTPs
redirection does not comply to BEHAVE rules IMHO. But it seems it could do
so with this proposal. In a subset of cases.
For example, consider the gateway between some 802.16.4 mesh and
wifi/ethernet
is operating as some form of proxy/gsateway/middlebox - how exactly does it
need to operate.
Assume the gateway would operate simply as a UDP "circuit" or "stateless"
proxy
in the way we specify in draft-ietf-anima-constrained-join-proxy. Except
that this
use does not have to be constrained to BRSKI, but for arbitrary CORE
services.
For the gateway to operatore purely as a packet forwader without having to
look into
the payload and rewrite it, not only can the IP/IPv6 address not change,
but also
not the port number. So ultimately, we're talking about the use-case where
the
announcement does not include a port number, e.g.: 443 is being assumed. Or
when
we know the proxy can 1:1 map also the port number.
So - not quite sure if this can congeal to a set of use-cases thart would
make it
more important than just "save more bits on the wire", but i'll offer it as
food
for thought.
Arguable, if/when we "redirect" from coap to coaps, the coap connection
itself could
be packet modified by such a proxy - acting as a (*yuck* ?) ALG. Maybe not
if/when
the messages have some form of message signature. But i don't know if/when
that
happens in CoAP. Does it ever ? (outside of coaps of course).
3. If/when this gets adopted, there is of course the problem of backward
non-interoperability.
Off the top, only new services that explicitly demand support such an
extension would be
able to relilably use it.
So, to make it applicable to all the existing services and their discovery,
we need to
amend the idea by some form of indication by the client that it supports
the extension,
so that the server can appropriately format the announcement with it. No
idea, how to
do this, hopefully someone else knows. And for multicast, unfortunately
there is only
the option of simulcasting - old and new. Which will not be beneficial if
all we want to
get out of it is bit saving.
Cheers
Toerles
On Wed, Sep 17, 2025 at 01:44:24PM +0200, 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
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
