Understanding CoAP proxies

Question

According to the CoAP specification RFC7252 section 5.7 two types of CoAP proxies exists, namely forward-proxy and reverse-proxy. Orthogonal to this definition a proxy can be CoAP-CoAP or HTTP-CoAP proxy.

I have the following questions according to these definitions:

1. What are the use cases where each of these proxy types (forward-proxy, reverse-proxy, CoAP-CoAP and HTTP-CoAP) has to be used?
2. What exactly does the proxy in those use cases?
3. Which part of the CoAP message does each proxy need in order to accomplish its tasks? (I assume that proxy looks at some of the CoAP options?)
4. Where runs the proxy? On the boarder router?

It well be very nice if someone can provide in addition to the answers to the questions above also good reverences and examples.

Answer 1

1. Some use cases for proxy times are:

   • Forward proxies: Escaping a restrictive firewall (eg. because outgoing connections are blocked unless they go through a proxy); a special case thereof is accessing resources on CoAP from within a browser, when a CoAP-over-WebSocket server is used as a forward proxy.
   • Reverse proxies: Roughly the same as for forward proxies but in the reverse direction (ie. if the server is in a firewalled network, there can be a reverse proxy running on the firewall that lets requests in selectively). Additionally, reverse proxies can be used for load balancing on the unconstrained server side.
   • HTTP-CoAP-proxies: Accessing CoAP devices from programming environments that don't have good CoAP support (eg. if your monitoring system supports polling a HTTP server, a H-C proxy easily allows monitoring your CoAP servers).
   • CoAP-HTTP proxies: Making services on the big web available to constrained devices (eg. querying a weather forecast). This is often of limited use as those web services don't use data formats suitable for a constrained device.

2. That barely varies over the cases; apart from the obvious (cross-proxies translating CoAP and HTTP messages back and forth), forward and reverse proxies only differ in whether they react to messages with a Proxy-* option (typically Proxy-Scheme) set (forward proxies), or to those without (reverse proxies).

3. All proxies need to inspect the full message (ie. all header fields and look at all options). Most header fields (token, message-ID, mtype to some extent) and several options (eg. Observe) are hop-by-hop, ie. the server acts on them and creates new values for the forwarded request. If there is anything in the message the proxy would need to understand but doesn't (ie. unknown Proxy-Unsafe options), it rejects forwarding.

4. That is fully up to the application, but in most of the common examples, that would be some kind of border router; could be the 6LBR in a 6LoWPAN scenario, or the firewall of a larger setup. In cases of routing between a CoAP-over-WebSocket endpoint and the rest of the CoAP world, the CoAP-over-WebSocket server often runs on the same machine that also serves the web application that uses the socket.