JUst my 2 cents:
The code for stateless and stateful is really small.
No need to worry about code memory requirements when saying that both
modes MUST be supported by join-proxy.
Once both modes are supported the dynamic choice becomes possibel.
Peter
Michael Richardson schreef op 2022-06-14 16:36:
Rob Wilton \(rwilton\) <[email protected]> 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 <[email protected]> . o O ( IPv6 IøT
consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
