Rob Wilton \(rwilton\) <rwilton=40cisco.com@xxxxxxxxxxxxxx> wrote:
> If it is okay to require that join proxies always implement the
> stateful mode, and that seems to have superior behaviour, then it there
> a reason why we want to standardize the stateless mode at all?
I think that the MUST implement both for the Join Proxy is wrong.
A 6LR MAY implement one or both or none.
I am happy for the Registrar to have a MUST/SHOULD though.
> Specifically, under what scenarios would a join-proxy decide to use
> stateless mode instead of stateful?
When it is constrained in memory for the state.
That could be a dynamic decision.
> Alternatively, I could see a slightly different proposal:
> - registrar MUST implement both (my expectation is that this device is
> likely be less constrained by code and memory)
> - if a join-proxy can store state then it MUST implement stateful, and
> default to using it, but MAY limit the amount of state it holds.
> - If a join-proxy cannot store state then it MUST implement stateless.
> - A join-proxy MAY implement both stateful and stateless, with stateful
> used by default, and stateless used if there is no further space for
> stateful operation.
This is more aligned with my thinking.
There is an aspect of procurement that enters here:
If I buy a Registrar that does not implement stateless, and devices
containing proxies that only implement stateless, then I will have a
failure.
I think that if the Registrar announces it supports stateless, then join
proxies that support stateless OUGHT to use that. I think it's cheaper in
battery life and more resilient to attacks than stateful. It comes as a cost
in network bandwidth, which might cause other nodes to expend more power.
If so, a network operator can turn that off by changing parameters on the Registrar.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
