Mališa Vučinić <malisa.vuci...@inria.fr> wrote:
> We had a couple of side discussions regarding Neighbor Discovery
> (ND) in minimal-security draft.
> The problem is that with the current text in minimal-security and
> the ND exchange between the pledge and the JP, we double the
> communication overhead on the shared cell and require the JP to
> keep separate neighbor caches, one cache for secure, authenticated
> entries, and another cache for insecure entries.
> It seems to be possible to remove the ND exchange between the
> pledge and the JP by using something like FF02::2,
> i.e. all-routers. With the same approach, it seems to be possible
> to remove the need for separate caches by specifying how the JP
> handles packets received over the well-known address.
I thought that we eliminated the ND with the R-bit of the Enhanced Beacon
extension.
The JP is the link-layer ff80::<originating-L2> of the beacon?
I'm in favour of eliminating the ND for the JP, but I think that we should not
do this in minimal security, as minimal-security doesn't need to be 802.15.4
specific (the 2-byte assignment is optional, and could assign different things
for
different L2-types).
Are you suggesting that the JP would send replies to the pledge using ff02::2?
I don't really understand this eliminates the neighbor cache entries, although
I
can imagine that the stateless information in the CoAP could be used to
construct a neighbor cache entry.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
