Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
draft-ietf-6lo-rfc6775-update-21

Thank you for a very readable document - this is not a simple process, but the document was clear and understandable.
Also, thank you for addressing Jürgen Schönwälder's OpsDir comments (I have not personally checked that each was incorporated, but the authors said that they would, and I'm trusting them).

Issues:
"In IPv6 ND [RFC4861], a router needs enough storage to hold NCEs for all the addresses to which it can currently forward packets." -- I do not believe that this is correct and am not quite sure how to fix it.
Can you point where in RFC4861 it says this? I'd agree that *to be efficient* a router should have enough space to hold an NCE for all locally attached subnets, but a constrained device *could* presumably age out and relearn old entries. Apart from that somewhat pathological case, if I'm a router and get a transit packet (not for a directly connected interface), I don't need to have a neighbor entry for it (otherwise "core" routers would need to build NCEs for every IP on the Internet :-P). Perhaps "for all directly connected subnets." or "for all directly connected addresses to which it can currently forward packets."? 

I'm somewhat uncomfortable with the uppercase MUST in:
"A network administrator MUST deploy updated 6LR/6LBRs to support the number and type of devices in their network, ..."
Having an uppercase MUST driving operators' design decisions stuff feels weird. I'd be perfectly fine with something like "In order to deploy this, network administrators MUST..." or "Network Administrators need to ensure that 6LR/6LBRs support the number and..." 


Nits:
Section 4.2.1.  Comparing TID values
"In order to keep this document self-contained and yet compatible, the text below is an exact copy from section 7.2.  "Sequence Counter Operation" of [RFC6550].""
I think that it would be helpful to delimit the copied text (perhaps by indenting it) -- it was unclear to me where the copied text started and ended, and so I had to go read RFC6550 (which kind of defeats the purpose of copying it).

Section 4.3.  Registration Ownership Verifier
"An RFC6775-only will confuse the name-spaces,"
Missing a word - perhaps "device", "6LoWPAN Router" or "implementation"?

Section 7.3.  RFC6775-only 6LoWPAN Router
"But if RFC6775-only and updated 6LRs
   coexist temporarily in a network, then it makes sense for an
   administrator to install a policy that allows so, and the capability
   to install such a policy should be configurable in a 6LBR though it
   is out of scope for this document."
s/that allows so/that allows this/ -- readability (purely a nit).


Section Appendix B.  Requirements (Not Normative)
"This section lists requirements that were discussed discussed by the 6lo WG..."
I guess that they were discussed at length? :-P

Section B.1.  Requirements Related to Mobility
" Due to the unstable nature of LLN links, even in an LLN of immobile nodes a 6LN may change"
s/of immobile nodes a/of immobile nodes, a/ (add comma -- also a nitty nit).

Thanks for the thoughtful privacy considerations in this document.

§3, last paragraph: The MUST seems like a statement of fact.

§12.1: There are normative downrefs to RFC 4919, RFC 6606, RFC 7102, RFC 7228 that were not mentioned in the IETF LC announcement, nor are they in the downref registry.

Section 6.1 has:

   Registration Ownership Verifier (ROVR):  Enables the correlation
                   between multiple attempts to register a same IPv6
                   Address.  This can be a unique ID of the Registering
                   Node, such as the EUI-64 address of an interface.
                   This can also be a token obtained with cryptographic
                   methods and used as proof of ownership of the
                   registration.  [...]

I understand that the actual crypto is (currently) in draft-ietf-6lo-ap-nd, but from the point
of view of this document, the ROVR token (or "crypto-ID" in the terminology of 6lo-ap-nd)
behaves as a bearer token.  That is, I include it with my EARO and my registration request
is authenticated and associated with that "identity"; there is not anything in this document
that ties the crypto-ID to the EARO.  From a very quick read of the other document, it sounds
like the 6LR can optionally request validation that the 6LN using the crypto-ID actually has control
of the associated private key, and is expected to do so on the first exchange, and so arguably the
transport key+LLA are what associates the crypto-ID with the EARO.

The conclusion from the above would be that this sort of ROVR is not itself proof of ownership of
anything, so it might be better to have text like "this can also be a token obtained with cryptographic
methods which can be used in additional protocol exchanges to associate a cryptographic identity
(key) with this registration".


In several places in section 7 it is indicated that implementations that support this spec should
always use the new data structures even when talking to RFC6775-only peers; this generally seems
fine due to the way that reserved fields are used.  I was not entirely sure if the same holds for the
use of new status codes in the EARO, though -- do things work out okay if (e.g.) "Moved" or "Removed"
are interpreted as a generic error?


In general the Security and Privacy Considerations seem well thought-out (in the model where
Layer-2 security is already in place), thank you!   (Key distribution remains a hard problem, of course,
and sharing such keys across groups does reduce the security properties of the system, but this
is not the right place to go into detail on such issues.)

One final nit: what is the "port" involved in the Binding?  It does not sound like it is an IP port...

I found this document quite challenging to read. It would be very
helpful if it started with a description of the failings of 6775 and a
brief overview of how it solves those. At the risk of self-citing, the
techniques of RFC 4101 might be helpful here.

In addition, I recognize that some of the guarantees here depend on
draft-ietf-6lo-ap-nd. I have not yet thoroughly reviewed that
document, but it is not yet clear to me precisely what guarantees it
in fact provides.



   This specification introduces the Extended Address Registration
   Option (EARO) based on the ARO as defined [RFC6775].  A 'T' flag is

Can you describe here the problem that ARO has that this solves?

   that this specification avoids the Duplicate Address message flow for
   Link-Local Addresses in a Route-Over [RFC6606] topology.

This sentence is not really maximally clear. Why does it avoid it?

   o  The address that is being registered with an NS with an EARO is
      now the Target Address, as opposed to the Source Address as

This would read better, I think if you said

"The address that is being registered is set to the target address in the NS containing
the EARO,as opposed to..."

                   denoting a ROVR size of 128, 192 and 256 bits
                   respectively.
   Status:         8-bit unsigned integer.  Indicates the status of a

It took me a minute to realize that this is the length of the *entire* option and so it's 1 larger than the length of the ROVR. Some text might help here.

                   registration of a particular IPv6 Address and it
                   cannot be used to correlate registrations of
                   different addresses.

"cannot" doesn't seem quite right. I.e., if you use the same EUI-64, someone could use it for that. Perhaps you mean "must not"

   rightmost bit and place the result in the EDAR message to maintain
   compatibility.  This way, the support of DAD is preserved.

Is there a reason for the rightmost bits? I see that https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-06 uses the leftmost bits for Crypto-ID.

   Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the
   Registered Address using a cryptographic ROVR.

I'm a little unsure how to read this text. It seems like the techniques you are discussing are about whether a node behaves incorrectly, but 6775 says that the first trust model of 3756 applies, and *that* says:

A model where all authenticated nodes trust each other to behave
       correctly at the IP layer and not to send any ND or RD messages
       that contain false information.  This model is thought to
       represent a situation where the nodes are under a single
       administration and form a closed or semi-closed group.  A
       corporate intranet is a good example.

So in that setting why do you need ownership guarantees? Is this just belt and suspenders?

      address, but a stronger identification (e.g., by security
      credentials) is RECOMMENDED.  When that maximum is reached, the
      router should use a Least-Recently-Used (LRU) algorithm to clean

What would these security credentials be?

I believe this document would have been easier to read for me if section 6 would have been before section 4; however, I guess that's a matter of taste.

On the TID in section 6.1: Should this field be zero if the T flag is not set? I guess you should at least say that the field should be ignored if the T flag is not set.