[Anima-bootstrap] joiner router stateful/stateless considerations

[Michael Richardson <[e-mail]>]

I finished writing:
  https://tools.ietf.org/html/draft-richardson-anima-state-for-joinrouter-00

(I had another draft name, but it turns outs there is a 50 character limit on
draft names)

Abstract:
   This document explores a number of issues affecting the decision to
   use a stateful or stateless forwarding mechanism by the join router
   (aka join assistant) during the bootstrap process for ANIMA.


I have 6 possible technologies that the joining router could use.
They fall into three categories from the point of view of the new node:
1) HTTPS
2) HTTPS via http-proxy
3) CoAP/DTLS.

1&2 could be unified if the registar is willing to accept an HTTP CONNECT
command via HTTP (and always connect to itself), and then do HTTPS.

I realize that I did not describe a method 7, which is a circuit/NAT
method for CoAP.

The Joining Router/Registrar interface is possibly agnostic about HTTPS vs
CoAPS for the IPIP methods.

From the new node point of view, if we were to make CoAPS mandator to implement
on the joining router, and HTTP optional that would make the IoT space work
best.

On the registrar<->Joining Router point of view, one could make either IPIP
or circuit proxy MTI.  The IPIP method is more difficult to implement on the
registrar, so some might argue for making it optional; but really it's about
simplifying the Joining Router.
The IPIP mechanisms are already required in the RPL space, and Pascal and 6lo
are working at ways to compress the IPIP header already.

It's possible to seperate the IPIP decapsulation from the registrar, but a
bit messy. If one terminates the DTLS/TLS on the IPIP decapsulator, it's much
easier, and that would be something one would do if one had to scale the
registrar beyond a single machine.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-