Subject: [6tisch] Optimizing Neighbor Discovery during the join process

From: Mališa Vučinić <[email-masked]>
Date: Wed, 18 Apr 2018 15:22:54 +0000

All,

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.

High-level, it looks as a win-win, but I kindly solicit any opinions on how
this could be specified in detail.

Mališa

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Apr 2018 12:18:59 -0400

Mališa Vučinić <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 18 Apr 2018 16:47:31 +0000

> 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.

> specific (the 2-byte assignment is optional, and could assign different

There is nothing 802.15.4-specific in this, see below.

> Are you suggesting that the JP would send replies to the pledge using

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.

> 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?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Apr 2018 13:16:55 -0400

Mališa Vučinić <[email-masked]> 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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 18 Apr 2018 17:36:58 +0000

> acceptable to some coap libraries.

Indeed, good point about a different adress in the response.

@Pascal, would it be possible for JP to use all-routers as the source IPv6
address? If not, does it help if we define our own well-known address?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Apr 2018 12:41:26 +0000

Hello all :

Guessing the Link Local of the JP looks like a very bad idea. Because the JP may not form a link local from EUI. This is being discouraged for privacy reasons. Guessing is really unclean any way.

To resolve the address of the device at the JP you could

-         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.

-         Lookup the Link Local of the device on the way back, if there is no NCE, but that’s a multicast from the JP to locate the JN

To reverse resolve the IP

-         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.

-         Else you can define a multicast all-JPs and use the multicast IP over unicast MAC trick by extension to RFC 6085.

-         Early implementations / pre standards can ship with FF02::2 instead of all-JPs, but the standard should be correct otherwise we’ll pay it at the IESG.

For the mail below:

-         There is no such thing as traffic from all-routers. With RFC 6085 we are tricking “all” at L3 with a unicast L2 to make the L3 multicast become a sort of  anycast and where we get to choose which JP.

-         There is such thing as traffic source set to unspecified address (all zeroes) though. If that’s enough for you, you may use that.

-         With RFC 6775 update, ND registration for a link local is a one hop thing, does not fly to the root or what, so the cost is really limited

Take care,

Pascal

From: 6tisch <[email-masked]> On Behalf Of Mališa Vucinic
Sent: mercredi 18 avril 2018 19:37
To: Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] Optimizing Neighbor Discovery during the join process

@Pascal, would it be possible for JP to use all-routers as the source IPv6 address? If not, does it help if we define our own well-known address?

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 19 Apr 2018 13:31:37 +0000

Pascal,

If we were to use the unspecified address, would the following be OK:

- Join Request: L3 source: Pledge LL; L3 destination: all-zeros; L2 source:
pledge EUI; L3 destination: JP EUI from the Beacon
- Join Response: L3 source: all-zeros; L3 destination: pledge LL; L2
source: JP EUI; L2 destination: Pledge EUI

(Join Request and Join Response refer to packets exchanged between the
pledge and the JP.)

This seems to:
- resolve Michael's concern about CoAP libraries expecting the response to
come from the same IPv6 address where it was sent to
- not introduce any additional packet overhead
- avoid an ND exchange doubling communication overhead
- avoid the need to keep a separate insecure cache at JP. How this would be
implemented is implementation specific, one example is an ephemeral cache
entry discussed in previous emails.

Let me know if you see any pitfalls, to me it looks quite appealing as an
option.

Mališa

On Thu, Apr 19, 2018 at 2:41 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello all :
>
>
>
> Guessing the Link Local of the JP looks like a very bad idea. Because the
> JP may not form a link local from EUI. This is being discouraged for
> privacy reasons. Guessing is really unclean any way.
>
>
>
> -         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.
>
> -         Lookup the Link Local of the device on the way back, if there
> is no NCE, but that’s a multicast from the JP to locate the JN
>
>
>
> -         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.
>
> -         Else you can define a multicast all-JPs and use the multicast
> IP over unicast MAC trick by extension to RFC 6085.
>
> -         Early implementations / pre standards can ship with FF02::2
> instead of all-JPs, but the standard should be correct otherwise we’ll pay
> it at the IESG.
>
>
>
>
>
> For the mail below:
>
> -         There is no such thing as traffic from all-routers. With RFC
> 6085 we are tricking “all” at L3 with a unicast L2 to make the L3 multicast
> become a sort of  anycast and where we get to choose which JP.
>
> -         There is such thing as traffic source set to unspecified
> address (all zeroes) though. If that’s enough for you, you may use that.
>
> -         With RFC 6775 update, ND registration for a link local is a one
> hop thing, does not fly to the root or what, so the cost is really limited
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch <[email-masked]> *On Behalf Of *Mališa Vucinic
> *Sent:* mercredi 18 avril 2018 19:37
> *To:* Michael Richardson <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] Optimizing Neighbor Discovery during the join
> process
>
>
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Apr 2018 13:37:48 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Guessing the Link Local of the JP looks like a very bad idea. Because
    > the JP may not form a link local from EUI. This is being discouraged
    > for privacy reasons. Guessing is really unclean any way.

1) What L2 address would the JP use in the Enhanced Beacon?
   Could we mandate that whatever it uses there, that it also configure as
   a valid l3 LL address?  It doesn't have to use that address by default
   for any other traffic.

2) we could include the lower-64-bits of the LL address for the JP in the
   Enhanced Beacon.

    > - 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
    > 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.

    > - 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?

    > - There is such thing as traffic source set to unspecified address
    > (all zeroes) though. If that’s enough for you, you may use that.

ugh.
I can live with a source of ::, but I would rather not.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Apr 2018 13:40:31 -0400

> - Join Request: L3 source: Pledge LL; L3 destination: all-zeros; L2
    > source: pledge EUI; L3 destination: JP EUI from the Beacon

This may be hard to configure on some platforms/OSes.
The whole world is not OpenWSN.

A straight fe80::JPLL is just a stuffed ND entry.
Stuffing in ::/128 might not be permitted.

    > (Join Request and Join Response refer to packets exchanged between the

I can probably live with this.

    > - avoid the need to keep a separate insecure cache at JP. How this
    > would be implemented is implementation specific, one example is an
    > ephemeral cache entry discussed in previous emails.

I think that this are two important things.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 20 Apr 2018 09:20:03 +0000

Hello Mališa

The all-0 destination is tricky, not done anymore that I know off. Trying that may get us through hell at 6MAN and/or IESG.

I think that as an RFC you must described the clean way and then the optimizations when the LLs are based on EUI 64.

IMHO, the spec should say that:

-         That the pledge sends an RS to all-JPs at l3, L2 dest = unicast MAC of the JP.

-         That the pledge registers its LL using ND EARO.

With that we are clean from the standards perspective.

And then, to address your concern, the spec would then indicate that if the pledge or the JP LL are derived from EUI 64 then some optimizations are possible.
If the JP LL derives from EUI 64 you may:

-         Have a bit in the beacon that indicates so.

If the pledge LL derives from EUI 64 you may:

-         Skip the ND EARO to register the LL to the JP

-         Indicate in the join message that the LL derives from the MAC

-         Use it on the way back to skip the look up

Notes:

-         The JP just needs to have a threshold of unsecured NCE, and a sensible lifetime for these, but that’s not that difficult.

-         If the NCE for the pledge is no more there when the join response comes in then the JP needs to do a NS look up.

Also, I do not necessarily agree that the ND phase is that expensive. It is just a one-hop exchange.

Cheers,

Pascal

From: Mališa Vučinić <[email-masked]>
Sent: jeudi 19 avril 2018 15:32
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [6tisch] Optimizing Neighbor Discovery during the join process

Pascal,

- Join Request: L3 source: Pledge LL; L3 destination: all-zeros; L2 source: pledge EUI; L3 destination: JP EUI from the Beacon
- Join Response: L3 source: all-zeros; L3 destination: pledge LL; L2 source: JP EUI; L2 destination: Pledge EUI

(Join Request and Join Response refer to packets exchanged between the pledge and the JP.)

This seems to:
- resolve Michael's concern about CoAP libraries expecting the response to come from the same IPv6 address where it was sent to
- not introduce any additional packet overhead
- avoid an ND exchange doubling communication overhead
- avoid the need to keep a separate insecure cache at JP. How this would be implemented is implementation specific, one example is an ephemeral cache entry discussed in previous emails.

Let me know if you see any pitfalls, to me it looks quite appealing as an option.

Mališa

On Thu, Apr 19, 2018 at 2:41 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello all :

For the mail below:

Take care,

Pascal

From: 6tisch <[email-masked]<mailto:[email-masked]>> On Behalf Of Mališa Vucinic
Sent: mercredi 18 avril 2018 19:37
To: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] Optimizing Neighbor Discovery during the join process

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 20 Apr 2018 12:21:11 +0000

> 2) we could include the lower-64-bits of the LL address for the JP in the
[PT>] Which is much better IMHO. This can be expressed as a compressed IPv6 address; any compression works for like 6LoWPAN, including one single bit that says that it is derived from the MAC. Looks very close to the above, but in principle quite different.

>     > LL may be an issue for a non-EUI64-based LL.
[PT>] 
[PT>] Well no one likes duplicate addresses, either, but the issue will arise if the pledge wants privacy. 
Note that the ND exchange is one hop Q&A so it does not 'double' the cost of anything.
The point is that we must document the proper way and then explain optimizations; if we only have an optimization and that optimization depends on EUI 64 then we're in for privacy-related issues.

> Are anycast addresses allowed in source addresses?
[PT>] for all I know, they are not. So no you cannot use that in the reply.

> I can live with a source of ::, but I would rather not.
[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.
If this is a consequence of an implementation as opposed to a standard then that implementation could be corrected, too.
 
Take care,

[PT>] 
Pascal

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 20 Apr 2018 13:30:27 +0000

Hi Pascal,

Thanks for the clarifications.

One point I strongly disagree with is about the cost of the ND exchange. ND
is indeed done on one-hop but in 6TiSCH case this maps to the* shared cell*,
where the collisions happen. Once we get pass that critical first hop,
things are much easier as we have dedicated cells towards the 6LBR. So, I
would by no means underestimate the effect of doubling the communication
overhead on the shared cell due to ND.

I also think that a solution where ND is done for the first time once the
pledge becomes a joined node, and JP or pledge do not have to worry about
insecure NCE is quite clean. With that, JP becomes stateless at *all*
levels, including IP, which is quite good from the security point of view
during the join process. It also removes 50% of overhead on the shared cell
in a fully generic setting. To me, it seems that you are recommending to
give up from that because 1) some people will not like it; 2) some stacks
might need to be amended to support either destination all-zeros, or source
all-JPs.

That said, please note that the *existing* text in -05 already mentions ND
as a phase in the join process. We do not detail how ND is done, and I
don't think we should by any means do it in the minimal-security draft. In
the existing text, we reference Section 5.5.1 of RFC6775. We also give a
recommendation that the NCE resulting from the ND exchange should be kept
separately, as the pledge is not yet authenticated.

A specific optimization when JP's LL is constructed from its L2 address
with a bit in the EB is more of a workaround to me, but I can live with it.
I guess this would belong to the richardson-enahnced-beacon document?

Mališa

On Fri, Apr 20, 2018 at 11:20 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Mališa
>
>
>
> The all-0 destination is tricky, not done anymore that I know off. Trying
> that may get us through hell at 6MAN and/or IESG.
>
>
>
> I think that as an RFC you must described the clean way and then the
> optimizations when the LLs are based on EUI 64.
>
>
>
> And then, to address your concern, the spec would then indicate that if
> the pledge or the JP LL are derived from EUI 64 then some optimizations are
> possible.
>
> -         The JP just needs to have a threshold of unsecured NCE, and a
> sensible lifetime for these, but that’s not that difficult.
>
> -         If the NCE for the pledge is no more there when the join
> response comes in then the JP needs to do a NS look up.
>
>
>
> *From:* Mališa Vučinić <[email-masked]>
> *Sent:* jeudi 19 avril 2018 15:32
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>; [email-masked]
>
>
> - avoid the need to keep a separate insecure cache at JP. How this would
> be implemented is implementation specific, one example is an ephemeral
> cache entry discussed in previous emails.
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 20 Apr 2018 14:27:11 +0000

Hello Mališa

All the below makes sense to me and I agree with the general direction that you are taking. Let’s see the final text – and don’t forget to signal in the join that the LL derives from the MAC so on the way back we skip the look up!

Take care,

Pascal

Sent: vendredi 20 avril 2018 15:30

Hi Pascal,

One point I strongly disagree with is about the cost of the ND exchange. ND is indeed done on one-hop but in 6TiSCH case this maps to the shared cell, where the collisions happen. Once we get pass that critical first hop, things are much easier as we have dedicated cells towards the 6LBR. So, I would by no means underestimate the effect of doubling the communication overhead on the shared cell due to ND.

I also think that a solution where ND is done for the first time once the pledge becomes a joined node, and JP or pledge do not have to worry about insecure NCE is quite clean. With that, JP becomes stateless at all levels, including IP, which is quite good from the security point of view during the join process. It also removes 50% of overhead on the shared cell in a fully generic setting. To me, it seems that you are recommending to give up from that because 1) some people will not like it; 2) some stacks might need to be amended to support either destination all-zeros, or source all-JPs.

That said, please note that the existing text in -05 already mentions ND as a phase in the join process. We do not detail how ND is done, and I don't think we should by any means do it in the minimal-security draft. In the existing text, we reference Section 5.5.1 of RFC6775. We also give a recommendation that the NCE resulting from the ND exchange should be kept separately, as the pledge is not yet authenticated.

A specific optimization when JP's LL is constructed from its L2 address with a bit in the EB is more of a workaround to me, but I can live with it. I guess this would belong to the richardson-enahnced-beacon document?

Mališa

On Fri, Apr 20, 2018 at 11:20 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Mališa

Notes:

Cheers,

Pascal

From: Mališa Vučinić <[email-masked]<mailto:[email-masked]>>
Sent: jeudi 19 avril 2018 15:32
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Pascal,

This seems to:

Mališa

For the mail below:

Take care,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 20 Apr 2018 13:58:27 -0400

mcr> 1) What L2 address would the JP use in the Enhanced Beacon?
    mcr> Could we mandate that whatever it uses there, that it also configure as
    mcr> a valid l3 LL address?  It doesn't have to use that address by default
    mcr> for any other traffic.
    mcr> 
    mcr> 2) we could include the lower-64-bits of the LL address for the JP in the
    mcr> Enhanced Beacon.

Pascal Thubert (pthubert) <[email-masked]> 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?

    >> 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> 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>] for all I know, they are not. So no you cannot use that in

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.

    > 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.
    
    > 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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 Apr 2018 08:46:09 +0000

Hello Michael

> 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.

> 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

> We aren't building protocols for *Internet*, we are building *internet*

[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.

> 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.
> 
> 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. 

>     > standard then that implementation could be corrected, too.
[PT>]  same as above. Do we maintain a state between the request and the response?

All the best

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Apr 2018 14:21:42 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Maybe we can just have one bit. On, the 64bits suffix is inline,
    > Off, the suffix is derived from the MAC address; semi quoting:  

    > specified in Section 3.2.2.

I like this very much, but I'm not certain I understand where it goes.
I thought into the Enhanced Beacon, but other words below make me think
you want to put it into the join request

    > 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?

Maybe.

    > The idea of signaling it at the cost of one bit leaves the future
    > open and allows us to do what we do today.

I'm open to signaling it. More options means more bugs.

    > response back, same as the beacon one.

I'm confused here.
We are putting the IPv6LL of the joining node into the join request
as context.  Are you saying that a bit here would say if the L2 address
is the same? I think that the best way to do that is to have two
different dictionary keys.  Let me think about the best way to do this.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Apr 2018 15:56:17 -0400

Diff: https://www.ietf.org/rfcdiff?url2=draft-richardson-6tisch-enrollment-enhanced-beacon-01

Pascal, Mališa, I have made the following changes to the Enhanced beacon draft:

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   TBD-XXX     |R|P| res |  proxy prio |    rank priority      |
    +-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+
    | pan priority  |                                               |
    +---------------+                                               +
    |                           Join Proxy lower-64                 |
    +                        (present if P=1)                       +
    |                                                               |
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               |                                               |
    +-+-+-+-+-+-+-+-+                                               +
    |                           network ID                          |
    +                   variable length, up to 16 bytes             +
    ~                                                               ~
    +                                                               +
    |                                                               |
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               |
    +-+-+-+-+-+-+-+-+

Perhaps someone can come up with a better description than "lower-64".
I guess maybe IID would appropriate?
I also changed the networkID to be variable length, up to 16 bytes as
we discussed in person.
I have again changed the number of bits allocated to rank priority.

What I hope is that by moving this stuff out of 6tisch-minimal security,
offering the optimization to get rid of the ND process in a 802.15.4 specific document, 
that the 6tisch-minimal-security can remain mute about this.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 24 Apr 2018 20:07:43 +0000

Hello Michael 

Regards,

Pascal

> Le 24 avr. 2018 à 20:21, Michael Richardson <[email-masked]> a écrit :
> 
> 
I’m Addressing the join response coming back. At that point the JP has the MAC of the pledge but not its LL. The bit in the request to the JRC is echoed and the JP knows without a lookup that the ll address derived from EUI 64...

Take care,

Pascal