Hello Michael
> Pascal Thubert (pthubert) <[email protected]> wrote:
> PT> Which is much better IMHO. This can be expressed as a compressed
> PT> IPv6 address; any compression works for like 6LoWPAN, including
> PT> one single bit that says that it is derived from the MAC. Looks
> PT> very close to the above, but in principle quite different.
>
> So I think that you are saying that the Enhanced Beacon needs to include the
> full IPv6 (LL) of the Join Proxy, but that it could say that is in fact
> compressed
> using 6LoWPAN mechanisms.
> So, something like RFC6282, section 3.1.1, but only the second byte, with CID
> probably forced to 0? Is this what you had in mind?
[PT>] Yes. We need to provide a generic way to stay IPv6 compliant, even if
today we believe that all LL addresses used here will be EUI-64 based.
RFC 6282 source format for SAC=0 works but is probably an overkill since the
address is always a LL with a constant /64 prefix.
Maybe we can just have one bit. On, the 64bits suffix is inline, Off, the
suffix is derived from the MAC address; semi quoting:
.
1: 64 bits. The first 64-bits of the address are elided.
The value of those bits is the link-local prefix padded with
zeros. The remaining 64 bits are carried in-line.
0: 0 bits. The address is fully elided. The first 64 bits
of the address are the link-local prefix padded with zeros.
The remaining 64 bits are computed from the encapsulating
header (e.g., 802.15.4 or IPv6 destination address) as
specified in Section 3.2.2.
>
> >> > - Piggy back an ARO in the join request, implicitly associated with
> >> > the link local of the device. The JP may store it or not, I guess it
> >> > could have a bounded amount of NCE for this use. At least, it could
> >> > immediately reject the Join if the LL is a duplicate with another
> >> > node, in which case a NA (status/=0) would work. Otherwise duplicate
> >> > LL may be an issue for a non-EUI64-based LL.
>
> >> I don't like this.
>
> pt> Well no one likes duplicate addresses, either, but the issue
> pt> will arise if the pledge wants privacy.
>
> I don't like trying to stuff the ARO into the join request.
> It violates too many layers in most systems. Even a flat-code space
> contiki,RIOT
> or OpenWSN, it will be convoluted. Any OS with more layers will find it
> impossible.
>
[PT>] OK
> pt> Note that the ND exchange is one hop Q&A so it does not 'double' the
> cost of anything.
> pt> The point is that we must document the proper way and then
> pt> explain optimizations; if we only have an optimization and that
> pt> optimization depends on EUI 64 then we're in for privacy-related
> pt> issues.
>
> I feel that I disagree for two reasons.
> a) Regardless of what we do at L3, if one uses a manufacturer derived
> EUI-64 for the 8-byte layer-2 address, then one discloses. And this
> occurs even when encrypted.
> In the industrial IoT space assumed by 6tisch, the devices do not
> visit coffee shops. Even if attached to one's person (a true "PAN"),
> the devices do not talk to the coffee shop network. Nor do they join
> the coffee shop network.
>
> If you still need privacy beyond tracking the device between coffee
> shops, then you need a randomized L2. Doing things at L3 won't get
> you any additional privacy.
>
> b) The "prohibition" against deriving L3 addresses from L2 ones is
> predicated upon the concept that L2 addresses are constant.
> Since a major point of the join process is to get a "randomized"
> (not linked to manufacturer) 2-byte address... I'd call our
> process privacy enhancing.
>
> c) I think that we would prefer, for security purposes, to have a strong
> link between something we can print on the outside of the device
> and the L2 address used. That doesn't have to be manufacturer EUI-64
> 4-byte prefix + serial number.
>
> So I just gotta push back on the privacy argument.
> We aren't building protocols for *Internet*, we are building *internet*
> protocols.
[PT>] Privacy is just one reason why the IPv6 address does not match the MAC.
Think about all we went through for the RH injection and why we did RFC 6553/4
and "use of rpl info" the way they are.
Don't you think that forcing an implicit relation between the MAC and the IP is
going to cause knee-jerks in the review process?
The idea of signaling it at the cost of one bit leaves the future open and
allows us to do what we do today.
My suggestion is to transport that bit in the join and in the response back,
same as the beacon one.
>
> >> > - If the prefix is known, we can define an anycast address “any JP on
> >> > this prefix” similar to the home agent anycast address in RFC 3775.
> >>
> >> Yes, but can we sanely reply from that address?
> >> Are anycast addresses allowed in source addresses?
>
> > [PT>] for all I know, they are not. So no you cannot use that in
> > the reply.
>
> Then we shouldn't address traffic to it if we expect a reply :-) But, it must
> be
> allowed in replies, or UDP to anycast couldn't ever work.
>
> > [PT>] And I have never seen it used in the reply.
>
> > If we really need to enforce that the response come to the same
> > address as the source of the request we are in a tight corner.
>
> Yeah, because operating systems want to associate the packet with the right
> socket.
[PT>]
I'm used to APIs that ship a UDP packet with the 4 tuple and the data, no
question asked, no state kept. Certainly if it was TCP I'd see things your way.
Deciding to maintain a state associated to the input socket seems to be a CoAP
implementation decision that matches what HTTP does but is not required.
Also, I thought we wanted to be fully stateless on the JP, so I'm getting
confused by this keeping a relation between the join request and the response
in the CoAP server on the JP.
>
> > If this is a consequence of an implementation as opposed to a
> > standard then that implementation could be corrected, too.
>
> It's how sockets work.
[PT>] same as above. Do we maintain a state between the request and the
response?
All the best
Pascal
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | network architect [
> ] [email protected] http://www.sandelman.ca/ | ruby on rails
> [
>
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
