Subject: [Sandbox-mailoutput] [Django development] ID list for IPv6 over Networks of Resource-constrained Nodes notification: Changes to draft-ietf-6lo-rfc6775-update

From: IETF Secretariat <[email-masked]>
Date: Thu, 05 Apr 2018 13:45:36 -0700

The attached message would have been sent, but the tracker is in development mode.
It was not sent to anybody.

Subject: ID list for IPv6 over Networks of Resource-constrained Nodes notification: Changes to draft-ietf-6lo-rfc6775-update
From: IETF Secretariat <[email-masked]>
To: <[email-masked]>
Date: Thu, 05 Apr 2018 13:45:36 -0700

Hello,

This is a notification from the ID list for IPv6 over Networks of Resource-constrained Nodes.

Document: draft-ietf-6lo-rfc6775-update,
https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/

Change by Eric Rescorla on 2018-04-05 13:45 PDT:

[Ballot 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.

COMMENTS
          presence.
       o  The router (6LR or 6LBR) SHOULD be configurable so as to limit the
          number of addresses that can be registered by a single node, but
          as a protective measure only.  A node may be identified by MAC
          address, but a stronger identification (e.g., by security
          credentials) is RECOMMENDED.  When that maximum is reached, the

What would these security credentials be?

       This specification recommends using privacy techniques (see
       Section 9) and protecting against address theft such as provided by
       "Address Protected Neighbor Discovery for Low-power and Lossy
       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?

       Router.
    
       If the 6LBR is RFC6775-only, and the ROVR in the NS(EARO) was more
       than 64 bits long, then the 6LR MUST truncate the ROVR to the 64
       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.

                       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.  The scope of a ROVR is the
                       registration of a particular IPv6 Address and it
                       cannot be used to correlate registrations of

"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"

       Type:           33
       Length:         8-bit unsigned integer.  The length of the option in
                       units of 8 bytes.  It MUST be 2 when operating in
                       backward-compatible mode.  It MAY be 3, 4 or 5,
                       denoting a ROVR size of 128, 192 and 256 bits
                       respectively.

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.

       compatibility can be found in Section 7.
    
       The semantics of the Neighbor Solicitation (NS) and the ARO are
       modified as follows:
    
       o  The address that is being registered with an NS with an EARO is

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..."

       messages, the Duplicate Address Request (DAR) and Duplicate Address
       Confirmation (DAC), so as to convey the additional information all
       the way to the 6LBR.  In turn the 6LBR may proxy the registration
       using IPv6 ND over a Backbone Link as illustrated in Figure 1.  Note
       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?

       IPv6 addresses that those devices require and their address renewal
       rate and behavior.
    
    4.  Updating RFC 6775
    
       This specification introduces the Extended Address Registration

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

Best regards,

        The Datatracker draft tracking service
        (for the IETF Secretariat)