Mališa Vučinić <malisa.vuci...@inria.fr> wrote:
mcr> Are you suggesting that the JP would send replies to the
mcr> 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.
okay, I'm fine with that at this point.
I think it's better it be the constructed LL.
> 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.
Good.
mcr> I don't really understand this eliminates the neighbor cache
mcr> entries, although I can imagine that the stateless information in
mcr> 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?
I think that we can do this.
It might be better if the traffic came from ff02::2, but I'm not sure that
would be acceptable for IPv6 reasons.
I am concerned that a reply from a different L3 address will not be acceptable
to some coap libraries.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
