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 protected]> wrote:
>
> Hi Pascal
>
> See my comment below.
>
> On 10/5/21 12:40 PM, Pascal Thubert (pthubert) wrote:
>> Hello Dario
>>
>> Please see below;
>>
>>
>>> Le 5 oct. 2021 à 20:15, Dario Tedeschi <[email protected]>
>>> <mailto:[email protected]> a écrit :
>>>
>>> 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
>>>
>>>
>>
>> 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.
> [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.
>
>
>>
>> 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.
>
>
>>
>> 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)
>>>> <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Dear all:
>>>>
>>>> This draft is a continuation of our work on RFC 8505, 8928, and 8929.
>>>>
>>>> Comments welcome!
>>>>
>>>> Pascal
>>>>
>>>> -----Original Message-----
>>>> From: [email protected] <mailto:[email protected]>
>>>> <[email protected] <mailto:[email protected]>>
>>>> Sent: lundi 27 septembre 2021 15:29
>>>> To: Eric Levy- Abegnoli (elevyabe) <[email protected]
>>>> <mailto:[email protected]>>; Pascal Thubert (pthubert)
>>>> <[email protected] <mailto:[email protected]>>
>>>> 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
>>>> <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:
>>>> 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 protected] <mailto:[email protected]>
>>>> https://www.ietf.org/mailman/listinfo/6lo
>>>> <https://www.ietf.org/mailman/listinfo/6lo>
>>>
>
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
