[6lo] Eric Rescorla's No Objection on draft-ietf-6lo-rfc6775-update-17: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-6lo-rfc6775-update-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


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?