IPv6 address within gcoap handler

[Citrullin]

Description

In order to finish #14095, I need to be able to get the IPv6 destination address of a incoming packet in a coap handler. As field in coap_pkt_t for example.

Useful links

None

[miri64]

I think that is the general idea behind sock_aux_local which is not yet supported by gcoap. Maybe @maribu has some insights into the ongoing development there. If not, it should be easy to be ported, now that sock_aux_local is in place.

[Citrullin]

I think that is the general idea behind sock_aux_local which is not yet supported by gcoap. Maybe @maribu has some insights into the ongoing development there. If not, it should be easy to be ported, now that sock_aux_local is in place.

That is also what he told me already on the mailing list :) Just created the issue, so that it doesn't get forgotten and also get pinged when it is merged ^^

[chrysn]

A field in coap_pkt_t would be one way of solving this (the other being changing the coap_handler_t signature).

Nanocoap (in which coap_pkt_t is defined) is a pure CoAP message tool and has no dealings with how or where to it is transported whatsoever. There are aspects of a CoAP message that behave differently depending on how it's transported (for example, observe values in CoAP-over-TCP are different than in CoAP-over-UDP, and block-wise's szx=7 has meaning there while it's an error in CoAP-over-UDP). However, nanocoap can't handle CoAP-over-TCP right now anyway.

Coming from the angle of accessing the addresses, it should be feasible to add two fields -- one indicating the transport (probably a driver-like stuct, although it could just as well be a sentinel value in the beginning) and one indicating the transport details -- to the nanocoap message. This offers up two routes:

• Applications that don't need this could leave out these fields (keeping the current compactness and staying away from any indirect calls).
• When we evolve to support CoAP-over-TCP (and really OSCORE, which is why I have given this whole thing some thought before, but really the topic is transport-independence in general), we could over one or two releases evolve the coap_pkt_t into something more generic (not necessarily CoAP-over-UDP as nanocoap now does), and that would behave more like a tagged union and not necessarily have all the CoAP-over-UDP fields. (For example, the experimental CoAP-over-GATT doesn't even have tokens).

At any rate, we could have either a generic "give me the peer's IPv6 address if it did come over some IPv6 transport", but beware that the IP address itself doesn't tell you much (and should really not be used for anything security related); the two more meaningful questions to ask are "Can I send requests there in role reversal mode (and where would that be to)?" and "Is there any security information associated for the requester?" (which would come up dry for CoAP-over-UDP unless IPsec, but would be more meaningful for CoAP-over-UDP).

[maribu]

I have to admit that while I was motivated to the access to the UDP endpoint via sock_aux_local for identifying and classifying a CoAP request, I'm only using this for my own CoAP library. I have developed an access control mechanism that also covers the destination address via an HMAC - hence I need access to it.

I have not yet looked into the integration of that into gcoap. But I think that just extending coap_pkt_t is right now the easiest to do, but only if a magic pseudo module is pulled in. (Otherwise everyone has to pay the increase in RAM & ROM consumption, even if this feature is not needed.)

I fully agree with @chrysn that we should support other transports than UDP. And that adding an UDP endpoint to the coap_pkt_t is not sensible with support for multiple transports in mind. But I believe that breaking API changes are bound to be the result of adding other transports anyway. Without other transports not yet supported, it is difficult to implement a proper way of providing access to the local endpoint a CoAP message came in.

But how about we mark this as unstable, so that the breaking API change once support for additional transport gets in does not surprise anyone and doesn't need 2 ACKs.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[Citrullin]

@JKRhb I think you wrote a workaround for this issue. Works for now, but I don't know how it will behave when you have different IPv6 addresses. link-local, global etc.

I guess this even with the workaround still an issue?