Subject: Re: [6lo] New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

From: Dario Tedeschi <[email-masked]>
Date: Tue, 5 Oct 2021 11:14:58 -0700

Hi Pascal,

Thank you for new draft. However I do have some comments/questions.

What benefit does the ‘M’ bit provide over simply detecting a multicast address in the Target Address field?

The IPv6 multicast address type is clearly defined in RFC 4291 (section 2.4) <https://datatracker.ietf.org/doc/html/rfc4291#section-2.4>, and the detection of such an address is trivial. Most (if not all) Stacks have a simple function/macro to do that job and many existing protocols already use this mechanism to distinguish between unicast and multicast addresses.  It seems to me that a special bit to indicate multicast registration would be redundant and require handling for 4 different cases, 2 of which would be errors:

M = 1, Target = multicast addr
M = 1, Target= unicast addr  — ERROR
M = 0, Target = multicast addr — ERROR
M = 0, Target= unicast addr

I also wonder about the requirement for non-storing RPL networks to propagate multicast membership up the DODAG. My understanding is that non-storing networks typically use MPL (RFC 7731) <https://www.rfc-editor.org/rfc/rfc7731.html>  which does not need multicast memberships to be propagated throughout the DODAG. It uses a flooding mechanism to forward multicast datagrams, and does not unicast at L2. Could the new document accommodate non-storing networks using MPL?
   
Regards
Dario

> On Sep 27, 2021, at 6:32 AM, Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 
> Dear all:
> 
> This draft is a continuation of our work on RFC 8505, 8928, and 8929.
> 
> Comments welcome!
> 
> Pascal
> 
> -----Original Message-----
> From: [email-masked] <[email-masked]> 
> Sent: lundi 27 septembre 2021 15:29
> To: Eric Levy- Abegnoli (elevyabe) <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
> Subject: New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt
> 
> 
> A new version of I-D, draft-thubert-6lo-unicast-lookup-01.txt
> has been successfully submitted by Pascal Thubert and posted to the IETF repository.
> 
> Name:		draft-thubert-6lo-unicast-lookup
> Revision:	01
> Title:		IPv6 Neighbor Discovery Unicast Lookup
> Document date:	2021-09-27
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/
> Html:           https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-thubert-6lo-unicast-lookup
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-unicast-lookup-01
> 
> Abstract:
>   This document updates RFC 8505 in order to enable unicast address
>   lookup from a 6LoWPAN Border Router acting as an Address Registrar.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 5 Oct 2021 19:40:42 +0000

Hello Dario

Please see below;

Le 5 oct. 2021 à 20:15, Dario Tedeschi <[email-masked]> a écrit :

 Hi Pascal,

The IPv6 multicast address type is clearly defined in RFC 4291 (section 2.4)<https://datatracker.ietf.org/doc/html/rfc4291#section-2.4>, and the detection of such an address is trivial. Most (if not all) Stacks have a simple function/macro to do that job and many existing protocols already use this mechanism to distinguish between unicast and multicast addresses.  It seems to me that a special bit to indicate multicast registration would be redundant and require handling for 4 different cases, 2 of which would be errors:

  *   M = 1, Target = multicast addr
  *   M = 1, Target= unicast addr  — ERROR
  *   M = 0, Target = multicast addr — ERROR
  *   M = 0, Target= unicast addr

True enough. Dario.

I’ve been pondering that too. On the one hand it seems cleaner to announce the service that the 6LN expects. Otoh as you point out it can be inferred from the address.

Another way of seeing this is that the error cases that you indicate can be detected if we have the bit otherwise they can’t.

Then there’s anycast which is missing from both RPL and ND , which cannot be distinguished by the look of the address and thus requires a bit.

Then there’s possibly the need of an IPv4 AF. All in all I tended to favor having the bit but that’s really not a strong position, happy to be convinced otherwise.

What do others think?

I also wonder about the requirement for non-storing RPL networks to propagate multicast membership up the DODAG. My understanding is that non-storing networks typically use MPL (RFC 7731)<https://www.rfc-editor.org/rfc/rfc7731.html>  which does not need multicast memberships to be propagated throughout the DODAG. It uses a flooding mechanism to forward multicast datagrams, and does not unicast at L2. Could the new document accommodate non-storing networks using MPL?

Sure;

Bottom line here is that for MPL all the multicast packets of interest for the LLN are flooded throughout so I suspect that there is no need for the 6LR to signal to the root.

If that’s the case then there’s nothing to standardize.  All I need to clarify is that the RPL behavior in the spec is the one expected in a RPL domain that supports mop 3 otherwise what is done is out of scope for this doc.

 Do you see it otherwise?

I mean should the 6LR signal unicast to the root like for unicast traffic when serving a RPL unaware leaf?

 If so wouldn’t it be expected that the Root makes n unicast to all 6LRs that have listeners?

Should we describe that mode as well?

Pascal

Regards
Dario

On Sep 27, 2021, at 6:32 AM, Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>> wrote:

Dear all:

Comments welcome!

Pascal

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: lundi 27 septembre 2021 15:29
To: Eric Levy- Abegnoli (elevyabe) <[email-masked]<mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

Abstract:

The IETF Secretariat

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: Dario Tedeschi <[email-masked]>
Date: Tue, 5 Oct 2021 15:05:15 -0700

Hi Pascal

See my comment  below.

On 10/5/21 12:40 PM, Pascal Thubert (pthubert) wrote:
>> What benefit does the ‘M’ bit provide over simply detecting a 
>> multicast address in the Target Address field?
>>
>> The IPv6 multicast address type is clearly defined in RFC 4291 
>> (section 2.4) 
>> <https://datatracker.ietf.org/doc/html/rfc4291#section-2.4>, and the 
>> detection of such an address is trivial. Most (if not all) Stacks 
>> have a simple function/macro to do that job and many existing 
>> protocols already use this mechanism to distinguish between unicast 
>> and multicast addresses.  It seems to me that a special bit to 
>> indicate multicast registration would be redundant and require 
>> handling for 4 different cases, 2 of which would be errors:
>>
> I’ve been pondering that too. On the one hand it seems cleaner to 
> announce the service that the 6LN expects. Otoh as you point out it 
> can be inferred from the address.
>
> Another way of seeing this is that the error cases that you indicate 
> can be detected if we have the bit otherwise they can’t.
[DT] I take your point about detecting the errors, assuming an 
implementation could do something useful with that knowledge, other than 
just discarding the message.

>
> Then there’s anycast which is missing from both RPL and ND , which 
> cannot be distinguished by the look of the address and thus requires a 
> bit.
[DT] As for the anycast address, I suppose the question to ask is what 
would a router do differently knowing such information? I suspect we 
would have to define some new behavior along with the new bit.

>
> Then there’s possibly the need of an IPv4 AF. All in all I tended to 
> favor having the bit but that’s really not a strong position, happy to 
> be convinced otherwise.
[DT] I presume you are talking of "IPv4-Compatible" and "IPv4-Mapped" 
IPv6 addresses. If my presumption is correct, aren't these still easily 
identifiable through their unique prefixes (::/96 and ::ffff/96, 
respectively)?

> What do others think?
[DT] I have no strong opinion. The M bit just seemed redundant.

>
>> I also wonder about the requirement for non-storing RPL networks to 
>> propagate multicast membership up the DODAG. My understanding is that 
>> non-storing networks typically use MPL (RFC 7731) 
>> <https://www.rfc-editor.org/rfc/rfc7731.html> which does not need 
>> multicast memberships to be propagated throughout the DODAG. It uses 
>> a flooding mechanism to forward multicast datagrams, and does not 
>> unicast at L2. Could the new document accommodate non-storing 
>> networks using MPL?
>
> Sure;
>
> Bottom line here is that for MPL all the multicast packets of interest 
> for the LLN are flooded throughout so I suspect that there is no need 
> for the 6LR to signal to the root.
[DT] Yes, that's my understanding as well.

>
> If that’s the case then there’s nothing to standardize.  All I need to 
> clarify is that the RPL behavior in the spec is the one expected in a 
> RPL domain that supports mop 3 otherwise what is done is out of scope 
> for this doc.
>
>  Do you see it otherwise?
[DT] I agree that only RPL mode 3 needs to be defined and other modes 
are left out of scope.

> traffic when serving a RPL unaware leaf?
[DT] That certainly could be an optimization for non-storing mode so 
that a border-router might know what multicast groups to forward from 
outside the network. Unfortunately though there is no MOP that is 
"Non-storing with multicast", although one could argue semantics and 
simply use MOP 1.

[DT] If we were to opt for such behavior, 6LR nodes could simply add RPL 
Target options to their DAO's, for the multicast groups they were 
interested in (including those requested by leaf nodes).

> 6LRs that have listeners?
[DT] I'm not sure that would make sense when MPL is being used, but it 
makes for an interesting alternative to MPL.

> Should we describe that mode as well?
[DT] As an alternative to MPL? Sure.

>
> Pascal
>>
>> Regards
>> Dario
>>
>>
>>> On Sep 27, 2021, at 6:32 AM, Pascal Thubert (pthubert) 
>>> <pthubert=[email-masked] 
>>> <mailto:pthubert=[email-masked]>> wrote:
>>>
>>> Dear all:
>>>
>>> From: [email-masked] <mailto:[email-masked]> 
>>> <[email-masked] <mailto:[email-masked]>>
>>> To: Eric Levy- Abegnoli (elevyabe) <[email-masked] 
>>> <mailto:[email-masked]>>; Pascal Thubert (pthubert) 
>>> <[email-masked] <mailto:[email-masked]>>
>>> Name:draft-thubert-6lo-unicast-lookup
>>> Revision:01
>>> Title:IPv6 Neighbor Discovery Unicast Lookup
>>> Document date:2021-09-27
>>> Group:Individual Submission
>>> Pages:15
>>> URL: 
>>> https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.txt
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/
>>> Html: 
>>> https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.html
>>> Htmlized: 
>>> https://datatracker.ietf.org/doc/html/draft-thubert-6lo-unicast-lookup
>>> Diff: 
>>> https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-unicast-lookup-01
>>>
>>> Abstract:
>>> [email-masked] <mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Oct 2021 13:00:28 +0000

OK Dario, so we’d have 4 optional combinations:

unicast = mop 1 multicast = mop 3 (what the draft does today)
unicast = mop 1 multicast = MPL (that I believe the draft allows today but should clarify); in that mode, not message to the Root, the root floods all multicast messages with the idea that there’s always a listener somewhere
unicast = mop 1 multicast = mop 1 (to be added) in that mode the 6LR sends a DAO to the root for a multicast target, and the Root sends n messages that are unicast source routed to the n 6LR that have listeners, only the last address in the SRH is multicast
unicast = mop 1 multicast = MPL (that I believe the draft allows today but should clarify); in that mode, in that mode the 6LR sends a DAO to the root for a multicast target, and the root uses MPL only when there’s known listeners

Do we describe them all? Should we consume RPL MOPs?

I suggested that AODV RPL reuses MOP 4 to leave room…

Pascal

From: Dario Tedeschi <[email-masked]>
Sent: mercredi 6 octobre 2021 0:05
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [6lo] New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

Hi Pascal

See my comment  below.

Please see below;

Le 5 oct. 2021 à 20:15, Dario Tedeschi <[email-masked]><mailto:[email-masked]> a écrit :
 Hi Pascal,

True enough. Dario.

Another way of seeing this is that the error cases that you indicate can be detected if we have the bit otherwise they can’t.
[DT] I take your point about detecting the errors, assuming an implementation could do something useful with that knowledge, other than just discarding the message.

Then there’s anycast which is missing from both RPL and ND , which cannot be distinguished by the look of the address and thus requires a bit.
[DT] As for the anycast address, I suppose the question to ask is what would a router do differently knowing such information? I suspect we would have to define some new behavior along with the new bit.

Then there’s possibly the need of an IPv4 AF. All in all I tended to favor having the bit but that’s really not a strong position, happy to be convinced otherwise.
[DT] I presume you are talking of "IPv4-Compatible" and "IPv4-Mapped" IPv6 addresses. If my presumption is correct, aren't these still easily identifiable through their unique prefixes (::/96 and ::ffff/96, respectively)?

What do others think?

Sure;

 Do you see it otherwise?
[DT] I agree that only RPL mode 3 needs to be defined and other modes are left out of scope.

I mean should the 6LR signal unicast to the root like for unicast traffic when serving a RPL unaware leaf?
[DT] That certainly could be an optimization for non-storing mode so that a border-router might know what multicast groups to forward from outside the network. Unfortunately though there is no MOP that is "Non-storing with multicast", although one could argue semantics and simply use MOP 1.

[DT] If we were to opt for such behavior, 6LR nodes could simply add RPL Target options to their DAO's, for the multicast groups they were interested in (including those requested by leaf nodes).

 If so wouldn’t it be expected that the Root makes n unicast to all 6LRs that have listeners?
[DT] I'm not sure that would make sense when MPL is being used, but it makes for an interesting alternative to MPL.

Pascal

Regards
Dario

Dear all:

Comments welcome!

Pascal

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: lundi 27 septembre 2021 15:29
To: Eric Levy- Abegnoli (elevyabe) <[email-masked]<mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

Abstract:

The IETF Secretariat

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 6 Oct 2021 12:49:45 -0700

Hi Pascal,

I think the 2nd and 4th cases can be merged, by allowing a root node to 
automatically propagate the following multicast messages, using MPL:

  * All scope 3 (Realm-Local) multicast messages it either originates or
    receives on an MPL interface.
  * All Unicast-Prefix-based IPv6 Multicast Addresses (RFC 3306) higher
    than scope 3, where the network prefix (given in the mulitcast
    destination address), matches the prefix of the DODAG ID (the RPL
    network's subnet).

Automatic forwarding of the 2nd address type could be optional and 
administratively configured.

If nodes are interested in other multicasts higher than scope 3, they 
must explicitly inform the root by sending DAO messages with appropriate 
Target Options.

---------

The 3rd case, I think, needs its own mop code (i.e. "Non-storing mode 
with source-routed multicast").

For the 1st and 3rd cases, how do you envision multicasts propagating up 
the DODAG (towards the root)? Would a node simply L2 unicast to its 
preferred parent?

Regards
Dario

On 10/6/21 6:00 AM, Pascal Thubert (pthubert) wrote:
> unicast = mop 1 multicast = MPL (that I believe the draft allows today 
> but should clarify); in that mode, not message to the Root, the root 
> floods all multicast messages with the idea that there’s always a 
> listener somewhere
>
> unicast = mop 1 multicast = mop 1 (to be added) in that mode the 6LR 
> sends a DAO to the root for a multicast target, and the Root sends n 
> messages that are unicast source routed to the n 6LR that have 
> listeners, only the last address in the SRH is multicast
>
> unicast = mop 1 multicast = MPL (that I believe the draft allows today 
> but should clarify); in that mode, in that mode the 6LR sends a DAO to 
> the root for a multicast target, and the root uses MPL only when 
> there’s known listeners
>
> *From:* Dario Tedeschi <[email-masked]>
> *Sent:* mercredi 6 octobre 2021 0:05
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [6lo] New Version Notification for 
> draft-thubert-6lo-unicast-lookup-01.txt
>
> Hi Pascal
>
> See my comment  below.
>
>         Le 5 oct. 2021 à 20:15, Dario Tedeschi <[email-masked]>
>         <mailto:[email-masked]>a écrit :
>
>          Hi Pascal,
>
>         <https://datatracker.ietf.org/doc/html/rfc4291#section-2.4>,
>         and the detection of such an address is trivial. Most (if not
>         all) Stacks have a simple function/macro to do that job and
>         many existing protocols already use this mechanism to
>         distinguish between unicast and multicast addresses.  It seems
>         to me that a special bit to indicate multicast registration
>         would be redundant and require handling for 4 different cases,
>         2 of which would be errors:
>
>     announce the service that the 6LN expects. Otoh as you point out
>     it can be inferred from the address.
>
>     Another way of seeing this is that the error cases that you
>     indicate can be detected if we have the bit otherwise they can’t.
>
> implementation could do something useful with that knowledge, other 
> than just discarding the message.
>
>
>     cannot be distinguished by the look of the address and thus
>     requires a bit.
>
>     Then there’s possibly the need of an IPv4 AF. All in all I tended
>     to favor having the bit but that’s really not a strong position,
>     happy to be convinced otherwise.
>
> IPv6 addresses. If my presumption is correct, aren't these still 
> easily identifiable through their unique prefixes (::/96 and 
> ::ffff/96, respectively)?
>
>
>     What do others think?
>
>         I also wonder about the requirement for non-storing RPL
>         networks to propagate multicast membership up the DODAG. My
>         understanding is that non-storing networks typically use MPL
>         (RFC 7731) <https://www.rfc-editor.org/rfc/rfc7731.html> which
>         does not need multicast memberships to be propagated
>         throughout the DODAG. It uses a flooding mechanism to forward
>         multicast datagrams, and does not unicast at L2. Could the new
>         document accommodate non-storing networks using MPL?
>
>     Sure;
>
>     Bottom line here is that for MPL all the multicast packets of
>     interest for the LLN are flooded throughout so I suspect that
>     there is no need for the 6LR to signal to the root.
>
>     If that’s the case then there’s nothing to standardize.  All I
>     need to clarify is that the RPL behavior in the spec is the one
>     expected in a RPL domain that supports mop 3 otherwise what is
>     done is out of scope for this doc.
>
>
>
>      Do you see it otherwise?
>
> [DT] If we were to opt for such behavior, 6LR nodes could simply add 
> RPL Target options to their DAO's, for the multicast groups they were

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Oct 2021 20:09:23 +0000

Hello Dario

Le 6 oct. 2021 à 21:50, Dario Tedeschi <[email-masked]> a écrit :

 Hi Pascal,

I think the 2nd and 4th cases can be merged, by allowing a root node to automatically propagate the following multicast messages, using MPL:

  *   All scope 3 (Realm-Local) multicast messages it either originates or receives on an MPL interface.
  *   All Unicast-Prefix-based IPv6 Multicast Addresses (RFC 3306) higher than scope 3, where the network prefix (given in the mulitcast destination address), matches the prefix of the DODAG ID (the RPL network's subnet).

WFM, conforms https://www.rfc-editor.org/rfc/rfc7346.html#section-5

Automatic forwarding of the 2nd address type could be optional and administratively configured.

If nodes are interested in other multicasts higher than scope 3, they must explicitly inform the root by sending DAO messages with appropriate Target Options.

---------

The 3rd case, I think, needs its own mop code (i.e. "Non-storing mode with source-routed multicast").

Yes, but we have to look at backwards compatibility / brown field and allow though not recommend to use mop 1; same issue as already discussed with mop 3 in the dread

For the 1st and 3rd cases, how do you envision multicasts propagating up the DODAG (towards the root)? Would a node simply L2 unicast to its preferred parent?

The 6 LN does. It know about RPL and registers the multicast address. Upon. The first registration The 6LR sends a unicast DAO to the Root as we do for RUL. This time though the address in the target is multicast. The root makes a copy per 6LR that shows as transit and sends along the unicast SR path to the 6 LR as it would for a RUL unicast. Less efficient that mop 3 that builds a real multicast tree, but backward compatible for for nodes on path…

Works?

Pascal

Regards
Dario

Pascal

From: Dario Tedeschi <[email-masked]><mailto:[email-masked]>
Sent: mercredi 6 octobre 2021 0:05
To: Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

Hi Pascal

See my comment  below.

Please see below;

True enough. Dario.

What do others think?

Sure;

 Do you see it otherwise?

Pascal

Regards
Dario

Dear all:

Comments welcome!

Pascal

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: lundi 27 septembre 2021 15:29
To: Eric Levy- Abegnoli (elevyabe) <[email-masked]<mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

Abstract:

The IETF Secretariat

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 6 Oct 2021 14:33:26 -0700

Comments in line below:

On 10/6/21 1:09 PM, Pascal Thubert (pthubert) wrote:
>> I think the 2nd and 4th cases can be merged, by allowing a root node 
>> to automatically propagate the following multicast messages, using MPL:
>>
>>   * All Unicast-Prefix-based IPv6 Multicast Addresses (RFC 3306)
>>     higher than scope 3, where the network prefix (given in the
>>     mulitcast destination address), matches the prefix of the DODAG
>>     ID (the RPL network's subnet).
>>
>
>
>> must explicitly inform the root by sending DAO messages with 
>> appropriate Target Options.
>>
>> ---------
>>
> Yes, but we have to look at backwards compatibility / brown field and 
> allow though not recommend to use mop 1; same issue as already 
> discussed with mop 3 in the dread
>
[DT]
OK I think I get it. So if mop is 1 and MPL is disabled or not present, 
your 3rd case description applies. Makes sense to me.

It should however be clearly described in the doc. Perhaps something 
like: "In the absence of MPL, multicast datagrams are unicast and 
source-routed".

>> For the 1st and 3rd cases, how do you envision multicasts propagating 
>> up the DODAG (towards the root)? Would a node simply L2 unicast to 
>> its preferred parent?
>>
>
> The 6 LN does. It know about RPL and registers the multicast address. 
> Upon. The first registration The 6LR sends a unicast DAO to the Root 
> as we do for RUL. This time though the address in the target is 
> multicast. The root makes a copy per 6LR that shows as transit and 
> sends along the unicast SR path to the 6 LR as it would for a RUL 
> unicast. Less efficient that mop 3 that builds a real multicast tree, 
> but backward compatible for for nodes on path…
>
> Works?

[DT]
Yes that seems fine, but I was actually more interested in multicast 
*datagrams* that originate from a 6LR node mid-way in the tree. How do 
such datagrams propagate up to the root?. I can see three possible methods:

 1. L2 unicast to the preferred parent at each hop
 2. Encapsulate the mcast datagram in a link-local unicast IPv6 header
    at each hop, where the outer destination is the the link-local
    address of the preferred parent.
 3. Encapsulate the mcast datagram in a route-able unicast IPv6 header,
    where the outer destination is a global address of the root node and
    then allow normal IPv6 unicast forwarding to occur at each hop.

Options 2 and 3 allow for the addition of the RPL HbH option, without 
mutating the original packet and are similar to what existing RPL 
forwarders already do.

Or is this already covered in some other RFC?

>>> unicast = mop 1 multicast = MPL (that I believe the draft allows 
>>> today but should clarify); in that mode, not message to the Root, 
>>> the root floods all multicast messages with the idea that there’s 
>>> always a listener somewhere
>>>
>>> unicast = mop 1 multicast = MPL (that I believe the draft allows 
>>> today but should clarify); in that mode, in that mode the 6LR sends 
>>> a DAO to the root for a multicast target, and the root uses MPL only 
>>> when there’s known listeners
>>>
>>>         What benefit does the ‘M’ bit provide over simply detecting
>>>         a multicast address in the Target Address field?
>>>
>>>         The IPv6 multicast address type is clearly defined in RFC
>>>         4291 (section 2.4)
>>>         and the detection of such an address is trivial. Most (if
>>>         not all) Stacks have a simple function/macro to do that job
>>>         and many existing protocols already use this mechanism to
>>>         distinguish between unicast and multicast addresses.  It
>>>         seems to me that a special bit to indicate multicast
>>>         registration would be redundant and require handling for 4
>>>         different cases, 2 of which would be errors:
>>>
>>>     I’ve been pondering that too. On the one hand it seems cleaner
>>>     to announce the service that the 6LN expects. Otoh as you point
>>>     out it can be inferred from the address.
>>>
>>>     Then there’s anycast which is missing from both RPL and ND ,
>>>     which cannot be distinguished by the look of the address and
>>>     thus requires a bit.
>>>
>>> [DT] As for the anycast address, I suppose the question to ask is 
>>> what would a router do differently knowing such information? I 
>>> suspect we would have to define some new behavior along with the new 
>>> bit.
>>>
>>>
>>>     Then there’s possibly the need of an IPv4 AF. All in all I
>>>     tended to favor having the bit but that’s really not a strong
>>>     position, happy to be convinced otherwise.
>>>
>>> [DT] I presume you are talking of "IPv4-Compatible" and 
>>> "IPv4-Mapped" IPv6 addresses. If my presumption is correct, aren't 
>>> these still easily identifiable through their unique prefixes (::/96 
>>> and ::ffff/96, respectively)?
>>>
>>>
>>>     What do others think?
>>>
>>>         (RFC 7731) <https://www.rfc-editor.org/rfc/rfc7731.html>
>>>         which does not need multicast memberships to be propagated
>>>         throughout the DODAG. It uses a flooding mechanism to
>>>         forward multicast datagrams, and does not unicast at L2.
>>>         Could the new document accommodate non-storing networks
>>>         using MPL?
>>>
>>>     Sure;
>>>
>>>     I mean should the 6LR signal unicast to the root like for
>>>     unicast traffic when serving a RPL unaware leaf?
>>>
>>> that a border-router might know what multicast groups to forward 
>>> from outside the network. Unfortunately though there is no MOP that 
>>> is "Non-storing with multicast", although one could argue semantics 
>>> and simply use MOP 1.
>>>
>>> RPL Target options to their DAO's, for the multicast groups they 
>>> were interested in (including those requested by leaf nodes).
>>>
>>>
>>> [DT] I'm not sure that would make sense when MPL is being used, but 
>>> it makes for an interesting alternative to MPL.
>>>
>>>
>>>

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 7 Oct 2021 16:40:46 -0700

I’m OK having the `M` bit, but I would like to see the error cases called out and what actions a node must take. E.g. one of:

discard the packet 
send an ICMP Error ("Parameter Problem") or 
send an NA+EARO with error status.

Regards
Dario

> On Oct 5, 2021, at 3:05 PM, Dario Tedeschi <[email-masked]> wrote:
> 
> Hi Pascal
> 
> See my comment  below.
> 
>>> Le 5 oct. 2021 à 20:15, Dario Tedeschi <[email-masked]> <mailto:[email-masked]> a écrit :
>>> 
>>>  Hi Pascal,
>>> 
>>>> On Sep 27, 2021, at 6:32 AM, Pascal Thubert (pthubert) <pthubert=[email-masked] <mailto:pthubert=[email-masked]>> wrote:
>>>> 
>>>> Dear all:
>>>> 
>>>> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> 
>>>> To: Eric Levy- Abegnoli (elevyabe) <[email-masked] <mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>
>>>> URL:            https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.txt <https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.txt>
>>>> Status:         https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/ <https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/>
>>>> Html:           https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.html <https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.html>
>>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-thubert-6lo-unicast-lookup <https://datatracker.ietf.org/doc/html/draft-thubert-6lo-unicast-lookup>
>>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-unicast-lookup-01 <https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-unicast-lookup-01>
>>>> 
>>>> Abstract:
>>>> https://www.ietf.org/mailman/listinfo/6lo <https://www.ietf.org/mailman/listinfo/6lo>
>>> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Oct 2021 06:08:33 +0000

Makes sense Dario, will do.

I’m refining the draft right now; such details will probably only show in a few rounds, but they’ll be there.
01 to come out soon will:

- Cover Gene’s issues, mostly editorials, that he sent me in an offline file
- add anycast
- add non-storing multicast mode
- allow though not recommend mixed mode while signaling MOP 1 for backward compatibility
- update the DAO message with the ‘M’ and ‘A’ flags
- *not* provide the operation details

Keep safe;

Pascal

From: Dario Tedeschi <[email-masked]>
Sent: vendredi 8 octobre 2021 1:41
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [6lo] New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

  *   discard the packet
  *   send an ICMP Error ("Parameter Problem") or
  *   send an NA+EARO with error status.

Regards
Dario

On Oct 5, 2021, at 3:05 PM, Dario Tedeschi <[email-masked]<mailto:[email-masked]>> wrote:

Hi Pascal

See my comment  below.

Please see below;

True enough. Dario.

What do others think?

Sure;

 Do you see it otherwise?

Pascal

Regards
Dario

Dear all:

Comments welcome!

Pascal

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: lundi 27 septembre 2021 15:29
To: Eric Levy- Abegnoli (elevyabe) <[email-masked]<mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

Abstract:

The IETF Secretariat