On Wed, 18 Apr 2018 at 18:19, Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > 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? > Pascal had a concern with pledge guessing JP’s link-local from L2 of the beacon, I’ll let him expand. > 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). There is nothing 802.15.4-specific in this, see below. > > Are you suggesting that the JP would send replies to the pledge using > ff02::2? No, pledge constructs its link-local and addresses the join request to the well-known IPv6, and L2 destination is the source address of the beacon. For join response, I’d say that the source IPv6 is JP’s link-local and the destination IPv6 is pledge’s link-local, coming from CoAP. If it happens that the pledge built its link-local from EUI-64, only those 8 bytes need to be signaled in CoAP option, but this is internal to JP. > 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. Yes, I guess you could call it an ephemeral cache entry constructed by CoAP at JP when the join response is received, before being forwarded to the pledge. As soon as the packet is passed to L2, the cache entry is removed. Can we do this? > > > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
