Subject: [Iot-directorate] Iotdir last call review of draft-ietf-6lo-backbone-router-13

From: Dominique Barthel via Datatracker <[email-masked]>
Date: Thu, 30 Jan 2020 09:51:23 -0800

Reviewer: Dominique Barthel
Review result: Ready with Nits

Thanks to the authors for this work.
I think this document is ready, with a few nits as described below.
I found it clear, including comprehensive introduction and reference sections.
Here are a few comments/questions, followed by a list of merely editorial nits.
Dominique

# Comments/Questions:
Picture 1., which gives a global view of the architecture we are talking about,
should be referenced as soon as end of Intro (specifically, together with “This
specification defines the 6BBR as a Routing Registrar …”.

3. Overview:
Picture 1 shows one 6BBR per LLN. Can an LLN operate with multiple 6BBRs, to
avoid single point of failure?

“The combined Binding Tables of all the 6BBRs on a backbone form a distributed
database of 6LNs that reside in the LLNs or on the IPv6 Backbone.” From the
definition of 6LN and from Figure 1., it had not occurred to me that a 6LN
could reside on the Backbone. Can you clear out this doubt?

“The proxy-ND operation can co-exist with IPv6 ND over the Backbone.”
I seems to me that IPv6 ND will happen on the Backbone no matter what the 6BBR
does. Do you mean “The proxy-ND operation of the 6BBR can co-exist with the
6BBR bridging IPv6 ND between the Backbone and the LLN.”?

“The 6BBR may co-exist with a proprietary snooping or …“. My understanding of
the 6BBR is that is is a box containing a set of functions. Which function of
the 6BBR is specifically being referenced here?

3.2 Access Link
Figure 2 has two arrows pointing to nowhere. What is the information being
conveyed by this representation? multicast? Another arrow has the (multicast)
annotation but does not have the same graphical representation.

3.3 Route-Over Mesh
I suggest to add a picture showing the LLN mesh structure, with 6LNs, 6LRs and
a 6LBR. This would ease the reading of the text. I’m sure you can rip one such
picture off of another draft. BTW, can there be multiple 6LBRs for one LLN,
much like multiple DAG roots for RPL. If yes, this needs to be mentionned, and
maybe doarn in the picture.

Figure 3. Same comment about arrows pointing to nowhere (a 3 arrows bunch, in
this picture, as opposed to 2, in the previous picture).

3.4
“Addresses in a LLN … must be registered … “. Is the use of lowercase “must”
intended? “Over the LLN, Binding Table management is as follows:” Sorry to
sound stupid, but the list of actions does not include the initial
registration. Likewise, the transitions between the Tentative, Reachable or
Stale states are not described fully, left to the reader to imagine. The tone
of voice of the Binding Table management is narrative. Why is RFC2119 language
not used? After reading section 9, it occurred to me that this description
might just be a preview of section 9. If true, please state this explicitely
and add a forward reference.

5
“If this registration is”. Not sure what “this” refers to. Was this piece of
text moved around?

7.
“Global including Unique Local addresses”
Why “including”? Aren’t they disjoint ranges?

9.
How does Section 9 “Creating and Maintaining a Binding” articulate with Section
3.4 “The Binding Table”? Is 3.4 just a preview (hence the narrative style)? In
which case, a forward reference from 3.4 to 9 would be useful.

9.2
“An NS(DAD) with no EARO or with an EARO that indicates a duplicate If the
Registration Lifetime is of a long duration, …” Cut&Paste error?

# Nits:
- “In practice, IPv6 addresses very rarely conflict because of the entropy of
the 64-bit Interface IDs, not because address duplications are detected and
resolved.” -> “In practice, the fact that IPv6 addresses very rarely conflict
is mostly attributable to the entropy of the 64-bit Interface IDs, not to the
address duplicate detection and resolution mechanisms”. - inconsistent use of
“broadcasted” versus “broadcast” - 1. Intro : “that provide proxy services” ->
“provides” - 2.2 Bridging proxy : “6BR” -> “6BBR” - 3 Overview: “Figure 1
illustrates backbone link” -> “Figure 1 illustrates a backbone link” - 3
Overview: “In the case, the co-existing function” -> “Any such co-existing
function” - 3 Overview: “Registering Node” is a term defined in RFC8505.
However, “registering node” is also found in this document, without
capitalization. Please check if this is intentional. - 3 Overview: “.. MAY also
be used with a 6LBR, if one is present, and the 6BBR.” -> “between a 6LBR, if
one is present, and the 6BBR.” - 3.2 “The 6BBRs applies” -> “6BBR” - 3.2 “in
that example” -> “in this example” - 3.3 “The 6LBR (acting as Registering Node)
proxies the registration to the 6BBR, using [RFC8505] to register the addresses
the 6LN (Registered Node) on its behalf to the 6BBR”. -> “the addresses of the
6LN” -> “its” is ambiguous. I believe that, grammatically, "it" refers to the
subject, which is “the 6LBR” in this sentence. Better avoid any ambiguity by
rewriting, probably cutting the sentence into several ones. - 3.3 “As a
non-normative example of a Route-Over Mesh, the 6TiSCH architecture suggests …
, and is … ”. Ambiguous sentence. Break it in two. -> “a 6LBR that serves the
LLN. The latter is either …”. - 3.4 “a LLN”-> “an LLN” ? - 3.4 “Conflicting
registrations are solved by the 6BBRs transparently to the Registering Nodes.”
-> “6BBRs, transparently” - 3.6 “The router can then determine the freshest
EARO in case of a conflicting NA(EARO) messages,” -. “in case of conflicting
NA(EARO) messages,” - 5. “This specification enables an address to be
registered to more than one 6BBR.” -> “allows for an address to be registered
at more than on 6BBR”. - 5. “a 6LBR MUST be capable to maintain a state”->
“capable of maintaining” - 8. “It acts as a Layer-2 Bridge for all types
unicast packets” -> “all types of unicast packets” - 8. “the 6BBR MUST either
answer directly to the NS(Lookup) message or” -> “the 6BBR MUST either answer
the NS(Lookup) message directly or” - 8. “it is eventually be discovered“ ->
“it is eventually discovered“ - 9. “pointing on the registering node” ->
“pointing to the registering node” - 9. “A Bridging Proxy MAY register Link
Local addresses to the 6BBR and proxy ND for those addresses over the
backbone.”. -> “register at the 6BBR“ or “register by the 6BBR”. -> “for these
addresses” - 9. “the current DAD operation continues as it was” -> “continues
unaltered” ? - 9.2 “in order to a allow for a parallel registration to arrive
to this node” -> “to allow” -> “to arrive at” - 9.2 “that is not as fresh as
this“ -> “that is not as fresh as this Binding“? - 9.3 “the 6BBR MUST attempts
a NUD procedure” ->  “attempt” - 10 “routing registrar” -> “Routing Registrar”
- 11 Security Considerations: “either by means of physical or IP security for
the Backbone Link or MAC-layer security.” bad grammatical construct. - 11
Security Considerations: “A possible attack …  can easily … take over.” From
the quoted text, it looks that the attack described succeeds. From the next
sentence in the paragraph, it looks that the attack does not succeed. Can you
rephrase or elaborate? For example “One could think that a possible attack
would be …. But …” - 12 Protocol Constants: “relatively long value” is used
twice, even though the recommended value is very different. I guess you mean
“STALE_DURATION
   SHOULD be configured to a value that is long relative to the address
   lifetime. For example, in LLNs with …, a good value is …”.
- Appendix B: “The term LLN is used … , meeting the requirements listed in … “.
I guess you mean something slightly different. Using the term “LLN” cannot by
itself meet the technical requirements of App B.3 of RFC8505. - Appendix B:
“Each LLN in the subnet is attached at an IPv6 Backbone Router (6BBR).” ->
“attached to an IPv6 Backbone Router (6BBR)”, or “attached to the Backbone
through a 6BBR”. - Appendix B: “In this way,” -> “This way, “ - Appendix B:
“The IPv6 ND operation is minimized as the number of 6LNs grows in the LLN.” ND
where? On the Backbone, the number of ND operations still grows with the number
of 6LNs in the LLNs, I beleive. What does “minimized” exactly means, btw? In
absolute numbers? In relative numbers?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 31 Jan 2020 16:55:42 +0000

Hello Dominique:

> specification defines the 6BBR as a Routing Registrar …”.

Good point! the intro text now looks like:

"
   This specification defines the 6BBR as a Routing Registrar [RFC8505]
   that provide proxy services for IPv6 Neighbor Discovery.  As
   represented in Figure 1, Backbone Routers federate multiple LLNs over
   a Backbone Link to form a MultiLink Subnet (MLSN).  Backbone Routers
   placed along the LLN edge of the Backbone handle IPv6 Neighbor
   Discovery, and forward packets on behalf of registered nodes.
"

> 3. Overview:
> Picture 1 shows one 6BBR per LLN. Can an LLN operate with multiple 6BBRs,
> to avoid single point of failure?

Sure; I reused an image that illustrates RPL DODAGs but that was a bad idea.
What about this (sorry if your font is not fixed size): ?

                |
              +-----+               +-----+       +-----+ IPv6
    (default) |     |    (Optional) |     |       |     | Node
       Router |     |          6LBR |     |       |     | or
              +-----+               +-----+       +-----+ 6LN
                 |  Backbone side      |             |
     ----+-------+-----------------+---+-------------+----+-----
         |                         |                      |
      +------+                 +------+                +------+
      | 6BBR |                 | 6BBR |                | 6BBR |
      |      |                 |      |                |      |
      +------+                 +------+                +------+
         o     Wireless side   o   o  o      o           o o
     o o   o  o  o   o  o  o o   o  o  o   o o  o  o  o o     o   o
    o  o o  o o   o o  o   o   o  o  o  o       o     o  o  o o o
    o   o  o  o  o  o   o  o  o  LLN  o   o  o  o  o   o   o  o   o
      o   o o   o   o   o  o     o  o    o      o     o     o o
     o     o                o

> 
> “The combined Binding Tables of all the 6BBRs on a backbone form a
> distributed database of 6LNs that reside in the LLNs or on the IPv6 Backbone.”
> From the definition of 6LN and from Figure 1., it had not occurred to me that a
> 6LN could reside on the Backbone. Can you clear out this doubt?

Actually a 6LN is a L3 construct and as such can be attached to any network including Wi-Fi or Ethernet.
e.g., you could have a device that sleeps and needs a 6BBR acting 	as sleeping proxy.
There might be a need for additional text when we really work on a 6LN sitting in the backbone, e.g., to insist that the 6LN does not listen to multicast NS so it ignores DAD and Lookup, which are handled by the 6BBR.
Suggestion is to turn the last block of the intro as:

"
   A 6LoWPAN node (6LN) registers all its IPv6 Addresses using an
   NS(EARO) as specified in [RFC8505] to the 6BBR.  The 6BBR is also a
   Border Router that performs IPv6 Neighbor Discovery (IPv6 ND)
   operations on its Backbone interface on behalf of the 6LNs that have
   registered addresses on its LLN interfaces without the need of a
   broadcast over the wireless medium.  A 6LN that resides on the
   backbone does not register to the SNMA groups associated to its
   Registered Addresses and defers to the 6BBR to answer or preferably
   forward to it as unicast the corresponding multicast packets. 
"

> I seems to me that IPv6 ND will happen on the Backbone no matter what the
> 6BBR does. Do you mean “The proxy-ND operation of the 6BBR can co-exist
> with the 6BBR bridging IPv6 ND between the Backbone and the LLN.”?

I agree ND will be there. I meant that there can be normal nodes doing ND and 6BBR proxying ND on a same backbone.
Proposed clarification:
"

   The operation of IPv6 ND and of proxy-ND are not mutually exclusive
   on the Backbone, meaning that nodes attached to the Backbone and
   using IPv6 ND can transparently interact with 6LNs that rely on a
   6BBR to proxy ND for them, whether the 6LNs are reachable over a LLN
   or directly attached to the Backbone.

"

> 
> “The 6BBR may co-exist with a proprietary snooping or …“. My understanding
> of the 6BBR is that is is a box containing a set of functions. Which function of

Clarifying to
"
   The [RFC8505] registration mechanism used to learn addresses to be
   proxied for may co-exist in a 6BBR with a proprietary snooping or the
   traditional bridging functionality of an Access Point, in order to
   support legacy LLN nodes that do not support this specification.

"
Works ?

> annotation but does not have the same graphical representation.

True and True. 

The RS(multicast) is intercepted by the AP, so it will never be really multicast over the wireless.
The multiple arrows effectively denote a real multicast.

Let le add text to explain that prior to the picture
"
    The RS sent initially by the 6LN(STA) is a transmitted as a multicast but
    since it is intercepted by the 6BBR, it is never effectively broadcasted.
    The multiple arrows associated to the ND messages on the backbone denote a
    real Layer-2 broadcast.

"

> 3.3 Route-Over Mesh
> I suggest to add a picture showing the LLN mesh structure, with 6LNs, 6LRs
> and a 6LBR. This would ease the reading of the text. I’m sure you can rip one
> such picture off of another draft. BTW, can there be multiple 6LBRs for one
> LLN, much like multiple DAG roots for RPL. If yes, this needs to be
> mentionned, and maybe doarn in the picture.

OK let me add pictures for both cases
"
   The simplest topology from the Layer-3 perspective occurs when the
   wireless network appears as a single hop hub-and-spoke network as
   shown in Figure 2.  The Layer-2 operation may effectively be hub-and-
   spoke (e.g., Wi-Fi) or Mesh-Under, with a Layer-2 protocol handling
   the complex topology.

                    |
                 +-----+               +-----+       +-----+ IPv6
       (default) |     |    (Optional) |     |       |     | Node
          Router |     |          6LBR |     |       |     | or
                 +-----+               +-----+       +-----+ 6LN
                    |  Backbone side      |             |
        ----+-------+-----------------+---+-------------+----+-----
            |                         |                      |
         +------+                 +------+                +------+
         | 6BBR |                 | 6BBR |                | 6BBR |
         | 6LR  |                 | 6LR  |                | 6LR  |
         +------+                 +------+                +------+
      (6LN) (6LN) (6LN)       (6LN) (6LN) (6LN)          (6LN) (6LN)

                      Figure 2: Access Link Use case
"

And 

"

3.3.  Route-Over Mesh

   A more complex Multi-Link Subnet topology occurs when the wireless
   network appears as a Layer-3 Mesh network as shown in Figure 4.  A
   so-called Route-Over routing protocol exposes routes between 6LRs
   towards both 6LRs and 6LNs, and a 6LBR acts as Root of the Layer-3
   Mesh network and proxy-registers the LLN addresses to the 6BBR.

                   |
                +-----+               +-----+       +-----+ IPv6
      (default) |     |    (Optional) |     |       |     | Node
         Router |     |          6LBR |     |       |     | or
                +-----+               +-----+       +-----+ 6LN
                   |  Backbone side      |             |
       ----+-------+-----------------+---+-------------+----+-----
           |                         |                      |
        +------+                 +------+                +------+
        | 6BBR |                 | 6BBR |                | 6BBR |
        +------+                 +------+                +------+
            |                        |                       |
        +------+                 +------+                +------+
        | 6LBR |                 | 6LBR |                | 6LBR |
        +------+                 +------+                +------+
       (6LN) (6LR) (6LN)       (6LR) (6LN) (6LR)        (6LR) (6LR)(6LN)
    (6LN)(6LR) (6LR) (6LN)   (6LN) (6LR)(6LN) (6LR)  (6LR)  (6LR) (6LN)
      (6LR)(6LR) (6LR)         (6LR)  (6LR)(6LN)    (6LR) (6LR)(6LR)
    (6LR)  (6LR)    (6LR)   (6LR) (6LN)(6LR) (6LR)    (6LR) (6LR) (6LR)
    (6LN) (6LN)(6LN) (6LN) (6LN)       (6LN) (6LN)  (6LN)  (6LN) (6LN)

                    Figure 4: Route-Over Mesh Use case"

> Figure 3. Same comment about arrows pointing to nowhere (a 3 arrows bunch,
> in this picture, as opposed to 2, in the previous picture).
> 

Added same text

Please let me know if we are OK so far; I'll continue next week.

In the meantime,  could you please resend the nits in a format that is not concatenated, if you still have that?
As below it is unreadable : (

Many thanks again!

pascal

> sound stupid, but the list of actions does not include the initial registration.
> Likewise, the transitions between the Tentative, Reachable or Stale states are
> not described fully, left to the reader to imagine. The tone of voice of the
> Binding Table management is narrative. Why is RFC2119 language not used?
> After reading section 9, it occurred to me that this description might just be a
> preview of section 9. If true, please state this explicitely and add a forward
> reference.
> 
> 5
> “If this registration is”. Not sure what “this” refers to. Was this piece of text
> moved around?
> 
> 7.
> - “In practice, IPv6 addresses very rarely conflict because of the entropy of the
> 64-bit Interface IDs, not because address duplications are detected and
> resolved.” -> “In practice, the fact that IPv6 addresses very rarely conflict is
> mostly attributable to the entropy of the 64-bit Interface IDs, not to the
> capitalization. Please check if this is intentional. - 3 Overview: “.. MAY also be
> used with a 6LBR, if one is present, and the 6BBR.” -> “between a 6LBR, if one
> is present, and the 6BBR.” - 3.2 “The 6BBRs applies” -> “6BBR” - 3.2 “in that
> example” -> “in this example” - 3.3 “The 6LBR (acting as Registering Node)
> rewriting, probably cutting the sentence into several ones. - 3.3 “As a non-
> normative example of a Route-Over Mesh, the 6TiSCH architecture suggests …
> -> “6BBRs, transparently” - 3.6 “The router can then determine the
> -> freshest
> “capable of maintaining” - 8. “It acts as a Layer-2 Bridge for all types unicast
> packets” -> “all types of unicast packets” - 8. “the 6BBR MUST either answer
> directly to the NS(Lookup) message or” -> “the 6BBR MUST either answer the
> NS(Lookup) message directly or” - 8. “it is eventually be discovered“ -> “it is
> eventually discovered“ - 9. “pointing on the registering node” -> “pointing to
> the registering node” - 9. “A Bridging Proxy MAY register Link Local addresses
> to the 6BBR and proxy ND for those addresses over the backbone.”. ->
> “register at the 6BBR“ or “register by the 6BBR”. -> “for these addresses” - 9.
> “the current DAD operation continues as it was” -> “continues unaltered” ? -
> 9.2 “in order to a allow for a parallel registration to arrive to this node” -> “to
> allow” -> “to arrive at” - 9.2 “that is not as fresh as this“ -> “that is not as fresh
> as this Binding“? - 9.3 “the 6BBR MUST attempts a NUD procedure” ->
> “attempt” - 10 “routing registrar” -> “Routing Registrar”
> - 11 Security Considerations: “either by means of physical or IP security for the
> Backbone Link or MAC-layer security.” bad grammatical construct. - 11
> twice, even though the recommended value is very different. I guess you
> mean “STALE_DURATION
> “The IPv6 ND operation is minimized as the number of 6LNs grows in the LLN.”
> ND where? On the Backbone, the number of ND operations still grows with
> the number of 6LNs in the LLNs, I beleive. What does “minimized” exactly
> means, btw? In absolute numbers? In relative numbers?
> 
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: <[email-masked]>
Date: Fri, 31 Jan 2020 17:18:58 +0000

Hello Pascal,

Attached is a text file with my nits.
I hope you can sort out the line ending issue.
It displays cleanly on my side.
Best regards

Dominique

Le 31/01/20 17:55, « Pascal Thubert (pthubert) » <[email-masked]> a
écrit :

>There might be a need for additional text when we really work on a 6LN
>sitting in the backbone, e.g., to insist that the 6LN does not listen to
>multicast NS so it ignores DAD and Lookup, which are handled by the 6BBR.
>In the meantime,  could you please resend the nits in a format that is
>not concatenated, if you still have that?
>>registration.
>>non-
>> - Appendix B: “The term LLN is used … , meeting the requirements listed
>>in …
>> “.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 31 Jan 2020 17:35:40 +0000

Perfect that way!!!!

Many thanks Dominique I'll go through that next.

Have a great week end 😊

Pascal

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: vendredi 31 janvier 2020 18:19
> To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: Re: [6lo] Iotdir last call review of draft-ietf-6lo-backbone-router-13
> 
> Hello Pascal,
> 
> >> Picture 1., which gives a global view of the architecture we are
> >>talking about,  should be referenced as soon as end of Intro
> >>(specifically, together with “This  specification defines the 6BBR as
> >>a Routing Registrar …”.
> >
> >> Picture 1 shows one 6BBR per LLN. Can an LLN operate with multiple
> >>6BBRs,  to avoid single point of failure?
> >
> >> From the definition of 6LN and from Figure 1., it had not occurred to
> >>me that a  6LN could reside on the Backbone. Can you clear out this
> >>doubt?
> >
> >sitting in the backbone, e.g., to insist that the 6LN does not listen
> >to multicast NS so it ignores DAD and Lookup, which are handled by the
> 6BBR.
> >> I seems to me that IPv6 ND will happen on the Backbone no matter what
> >>the  6BBR does. Do you mean “The proxy-ND operation of the 6BBR can
> >>co-exist  with the 6BBR bridging IPv6 ND between the Backbone and the
> >>LLN.”?
> >
> >I agree ND will be there. I meant that there can be normal nodes doing
> >ND and 6BBR proxying ND on a same backbone.
> >Proposed clarification:
> >"
> >
> >> “The 6BBR may co-exist with a proprietary snooping or …“. My
> >>understanding  of the 6BBR is that is is a box containing a set of
> >>functions. Which function of  the 6BBR is specifically being
> >>referenced here?
> >
> >Clarifying to
> >"
> >> Figure 2 has two arrows pointing to nowhere. What is the information
> >>being  conveyed by this representation? multicast? Another arrow has
> >>the
> >>(multicast)
> >Let le add text to explain that prior to the picture "
> >> I suggest to add a picture showing the LLN mesh structure, with 6LNs,
> >>6LRs  and a 6LBR. This would ease the reading of the text. I’m sure
> >>you can rip one  such picture off of another draft. BTW, can there be
> >>multiple 6LBRs for one  LLN, much like multiple DAG roots for RPL. If
> >>yes, this needs to be  mentionned, and maybe doarn in the picture.
> >
> >                      Figure 2: Access Link Use case "
> >
> >And
> >
> >"
> >
> >
> >3.3.  Route-Over Mesh
> >
> >> Figure 3. Same comment about arrows pointing to nowhere (a 3 arrows
> >>bunch,  in this picture, as opposed to 2, in the previous picture).
> >>
> >
> >Added same text
> >
> >> intended? “Over the LLN, Binding Table management is as follows:”
> >>Sorry to  sound stupid, but the list of actions does not include the
> >>initial registration.
> >> Likewise, the transitions between the Tentative, Reachable or Stale
> >>states are  not described fully, left to the reader to imagine. The
> >>tone of voice of the  Binding Table management is narrative. Why is
> >>RFC2119 language not used?
> >> After reading section 9, it occurred to me that this description
> >>might just be a  preview of section 9. If true, please state this
> >>explicitely and add a forward  reference.
> >>
> >> 5
> >> “If this registration is”. Not sure what “this” refers to. Was this
> >>piece of text  moved around?
> >>
> >> 7.
> >> 3.4 “The Binding Table”? Is 3.4 just a preview (hence the narrative
> >>style)? In  which case, a forward reference from 3.4 to 9 would be
> >>useful.
> >>
> >> 9.2
> >> “An NS(DAD) with no EARO or with an EARO that indicates a duplicate
> >>If the  Registration Lifetime is of a long duration, …” Cut&Paste
> >>error?
> >>
> >> # Nits:
> >> - “In practice, IPv6 addresses very rarely conflict because of the
> >>entropy of the  64-bit Interface IDs, not because address duplications
> >>are detected and  resolved.” -> “In practice, the fact that IPv6
> >>addresses very rarely conflict is  mostly attributable to the entropy
> >>of the 64-bit Interface IDs, not to the  address duplicate detection
> >>and resolution mechanisms”. - inconsistent use of  “broadcasted”
> >>versus “broadcast” - 1. Intro : “that provide proxy services” ->
> >>“provides” - 2.2 Bridging proxy : “6BR” -> “6BBR” - 3 Overview:
> >>“Figure
> >>1
> >> Overview: “In the case, the co-existing function” -> “Any such
> >>co-existing  function” - 3 Overview: “Registering Node” is a term
> >>defined in RFC8505.
> >> used with a 6LBR, if one is present, and the 6BBR.” -> “between a
> >>6LBR, if one  is present, and the 6BBR.” - 3.2 “The 6BBRs applies” ->
> >>“6BBR” - 3.2 “in that  example” -> “in this example” - 3.3 “The 6LBR
> >>(acting as Registering
> >>Node)
> >> proxies the registration to the 6BBR, using [RFC8505] to register the
> >>addresses  the 6LN (Registered Node) on its behalf to the 6BBR”. ->
> >>“the addresses of the  6LN” -> “its” is ambiguous. I believe that,
> >>grammatically, "it" refers to the  subject, which is “the 6LBR” in
> >>this sentence. Better avoid any ambiguity by  rewriting, probably
> >>cutting the sentence into several ones. - 3.3 “As a
> >>non-
> >> normative example of a Route-Over Mesh, the 6TiSCH architecture
> >>suggests …  , and is … ”. Ambiguous sentence. Break it in two. -> “a
> >>6LBR that serves the  LLN. The latter is either …”. - 3.4 “a LLN”->
> >>“an LLN” ? - 3.4 “Conflicting  registrations are solved by the 6BBRs
> >>transparently to the Registering Nodes.”
> >>registered to more than one 6BBR.” -> “allows for an address to be
> >>registered  at more than on 6BBR”. - 5. “a 6LBR MUST be capable to
> >>maintain a state”->  “capable of maintaining” - 8. “It acts as a
> >>Layer-2 Bridge for all types unicast  packets” -> “all types of
> >>unicast packets” - 8. “the 6BBR MUST either answer  directly to the
> >>NS(Lookup) message or” -> “the 6BBR MUST either answer the
> >> eventually discovered“ - 9. “pointing on the registering node” ->
> >>“pointing to  the registering node” - 9. “A Bridging Proxy MAY
> >>register Link Local addresses  to the 6BBR and proxy ND for those
> >>addresses over the backbone.”. ->  “register at the 6BBR“ or “register
> >>by the 6BBR”. -> “for these addresses” - 9.
> >> 9.2 “in order to a allow for a parallel registration to arrive to
> >>this node” -> “to  allow” -> “to arrive at” - 9.2 “that is not as
> >>fresh as this“ -> “that is not as fresh  as this Binding“? - 9.3 “the
> >>6BBR MUST attempts a NUD procedure” ->  “attempt” - 10 “routing
> >>registrar” -> “Routing Registrar”
> >> - 11 Security Considerations: “either by means of physical or IP
> >>security for the  Backbone Link or MAC-layer security.” bad
> >>grammatical construct. - 11  Security Considerations: “A possible
> >>attack …  can easily … take over.”
> >>From
> >> the quoted text, it looks that the attack described succeeds. From
> >>the next  sentence in the paragraph, it looks that the attack does not
> >>succeed.
> >>Can you
> >> rephrase or elaborate? For example “One could think that a possible
> >>attack  would be …. But …” - 12 Protocol Constants: “relatively long
> >>value” is used  twice, even though the recommended value is very
> >>different. I guess you  mean “STALE_DURATION
> >> “attached to an IPv6 Backbone Router (6BBR)”, or “attached to the
> >>Backbone  through a 6BBR”. - Appendix B: “In this way,” -> “This way,
> >>“ - Appendix B:
> >> ND where? On the Backbone, the number of ND operations still grows
> >>with  the number of 6LNs in the LLNs, I beleive. What does “minimized”
> >>exactly  means, btw? In absolute numbers? In relative numbers?
> >>
> >>
> ________________________________________________________________
> _________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.