Transporting local IP addresses in payloads

[chrysn]

This is a topic that has come up in different seemingly unrelated CoAP based drafts, and maybe corr-clar can provide some more generic language:

Talking of IP addresses that are not globally unique is asking for trouble when it is not assured that the peer interprets them the same way.

• This is part of RFC9176: "If the base URI contains a link-local IP literal, it MUST NOT contain a Zone Identifier and MUST be local to the link on which the registration request is received." (basically doing split-horizon -- don't talk about resources the peer can't reach)

  In hindsight, that may not even be completely sharp: a better criterion would have been "link-local addresses must only be sent to clients that use link-local addresses of the same link", and maybe some words on reverse proxies.

• In multicast-notifications we've started out with some language against link-local addresses, but found that they'd be fine in some cases, but that there is also some trouble to be found with non-global multicast addresses in some scenarios (unicast-prefix-based site-local address should be fine: it's OK to send them if it can be ensured that the peer will fail to join them if it tried, unless it's really the right group).

Back in 7252 we didn't know that we'd one day have secure connections across proxies, so a proxy might still have inspected addresses if it had knowledge of the content format -- but that was shaky back then and is impossible now.

I think we should at some point encode some expectations on non-global addresses (mainly IP addresses, not sure how that'd relate to names -- anyone talking of localhost probably has the intention of that being a host-relative reference). Those could be:

• If a client selects a proxy (informally a "forward proxy", formally maybe "sends a request to an address that it does not believe to be the authoritative source of the information") and receives non-global addresses through it, it knows that those are to be understood in the context of that proxy. It better resolve any references through the proxy, and make no assumptions on their meanings when accessed directly or though another proxy.
• When a service is hosted behind a reverse proxy (and it'd be the owner of the service who knows that, for they put one address in the resolution mechanism for its name but instruct that system there to forward the request), the server better not hand out non-global addresses unless they are either part of some data structure where the client knows that they are local to the server, or client and server have some out-of-band knowledge of each other.

This might also be part of a larger "responsibilities around selecting proxies" topic (with yet another example in RD: "You can't use simple registration with a proxy" means for a client that it can't select a proxy, and for a server that it can't enable simple registration unless it empowers the proxy to play along).

CC'ing @rikard-sics and @marco-tiloca-sics with whom I discussed this earlier today.