Sounds like we should consider this direction. What about "me.arpa" ?
It could be specifically defined as the sender (either hostname or IP
address, whatever is known) of the message that contains the hostname
"me.arpa" or "same.arpa".
Additional benefits in cBRSKI context are:
1. For sender of Link Format: not having to encode the IPv6 LL address
in UTF-8 format.
2. For receiver: not having to, or accidentally trying to, parse the
IPv6 LL address from UTF-8 format.
3. Avoid duplicate information in two different encodings which might
lead to unexpected bugs (e.g. due to implementations using the different
version of the information).
Esko
On 16-10-2025 19:05, Toerless Eckert wrote:
Define/allocate "same.arpa" ?
---
Semantic: May be used by any application where the recipient can deduce
a prior hostname (or in the absence of the hostname an IP/IPv6 address)
from the context in which it receives a URL with hostname "same.arpa".
That hostname should then be used to connect to this URL. URL responders are
assumed to recognize and accordingly react to a "same.arpa" URL.
"same.arpa" can have arbitrary, application specific subdomain.
---
The question really if in our use-case we will actually save significantly.
If the only benefit is saving bytes on the wire, it's a bit underhwlming.
The use of a generic hostname would be a lot more attractive if it would
help to solve other problems too.
Cheers
Toerless
On Mon, Oct 13, 2025 at 08:46:43PM +0200, Esko Dijk wrote:
RFC9031 uses 6tisch.arpa on the forward direction in Uri-Host.
Ok! This is also an interesting type of special hostname. In cBRSKI,
Uri-Host wouldn't be added to the request as we target the JP directly with
the CoAPS request as if it were the final server and not a proxy.
And unlike the 6TiSCH case the proxy can't inspect the CoAP request as it is
hidden in DTLS encryption.
In cBRSKI discovery the authority component that includes the host is in a
link in the CoRE Link Format document and it cannot be elided from there.
I don't think foo.alt is going to fly...
It was exactly the purpose to not make a client fly off somewhere ;-)
Thinking about this: a ".alt" name might have some effect in a system that
uses a non-IETF-defined resolution mechanism in the "alt" namespace.
The domain ".invalid" is at least guaranteed to have non-resolvable names.
But I didn't like using such a name on purpose. (You may have the same feel
about "foo.alt")
Since then I wonder why we didn't just leave Uri-Host option out.
I think it's because we wanted to get out of .well-known, so Uri-Path
could
be "j", ignoring RFC8820.
Uri-Host is included because RFC 9031 uses the CoAP (forward/explicit) proxy
mechanism which needs a target host definition, being the "host to forward
the request to".
The proxy resolves the hostname into an anycast IP address. Because this
final host is by design a 6TiSCH Registrar the client already knows it
supports the "j" resource.
But I think according to RFC 8820 this would still not be allowed though:
To avoid collisions, rigidity, and erroneous client assumptions,
Specifications MUST NOT define a
fixed prefix for their URI paths -- for example, "/myapp" -- unless
allowed by the scheme definition.
The scheme in this case is "coap" which doesn't define a specific allowance
for fixed URI paths outside of ".well-known". But in practice it just works
fine so I'm okay with that.
Esko
On 12-10-2025 20:28, Michael Richardson wrote:
Esko Dijk<[email protected]> wrote:
> 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.
uhm, okay.
> An even shorter version would be just "alt" for the hostname. Or
> "jp.brski.alt" if potential name clashes are a worry.
RFC9031 uses 6tisch.arpa on the forward direction in Uri-Host.
I don't think foo.alt is going to fly...
Since then I wonder why we didn't just leave Uri-Host option out.
I think it's because we wanted to get out of .well-known, so Uri-Path could
be "j", ignoring RFC8820.
--
Michael Richardson<[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list [email protected]
To unsubscribe send an [email protected]
--
*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]
