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
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
