Subject: Re: [6lo] Draft applicability for 6775bis

From: Suresh Krishnan <[email-masked]>
Date: Tue, 4 Apr 2017 14:02:53 +0000

Hi Dave,

> On Mar 29, 2017, at 1:47 PM, Dave Thaler <[email-masked]> wrote:
> 
> Any issue with a standards track document having a normative reference to a BCP?

No issues that I know of. The downref rules seem to be pointing *from* Standards track and BCP documents *to* lower maturity level documents as per RFC3967. Just to be safe, I can still call this out in the IETF last call if the WG decides to go that way.

> If so, then could reword so that the MUST NOT is not in the same sentence as the BCP reference, e.g.
> 
>> However, the ability to return errors to address registrations MUST NOT be
>> used to restrict the ability of hosts to form and use addresses.  See [RFC7934]
>> for further discussion.
> 
> If there is no issue in having a normative reference to a BCP then I think Erik's text is fine.

I have no problems with this text either as it cleanly decouples the requirement from the background.

Thanks
Suresh

---

From: Brian Haberman <[email-masked]>
Date: Tue, 4 Apr 2017 10:42:29 -0400

On 4/4/17 10:02 AM, Suresh Krishnan wrote:
> No issues that I know of. The downref rules seem to be pointing
> *from* Standards track and BCP documents *to* lower maturity level
> documents as per RFC3967. Just to be safe, I can still call this out
> in the IETF last call if the WG decides to go that way.

Right. ST and BCP are at the same level, so there are no down-ref issues
with a normative reference. Those issues arise when ST or BCP documents
normatively reference Info and Experimental documents.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Apr 2017 16:15:46 +0000

Dear all:

I retrofitted the text with minors editions as follows:
"

2.  Applicability

   The purpose of the Address Registration Option (ARO) option [RFC6775]
   and the Extended ARO (EARO) option that is introduced in this
   document is to facilitate duplicate address detection (DAD) for hosts
   and pre-populate Neighbor Cache Entries (NCE) [RFC4861] in the
   routers to reduce the need for sending multicast neighbor
   solicitations and also to be able to support backbone routers.

   In some cases the address registration can fail or be useless for
   reasons other than a duplicate address.  Examples are the router
   having run out of space, a registration bearing a stale sequence
   number (e.g. denoting a movement of the host after this registration
   was placed), a host misbehaving and attempting to register an invalid
   address such as the unspecified address [RFC4291], or the host using
   an address which is not topologically correct on that link.  In such
   cases the host will receive an error to help diagnose the issue and
   may retry, possibly with a different address, and possibly
   registering to a different 6LR, depending on the returned error.

   However, the ability to return errors to address registrations MUST
   NOT be used to restrict the ability of hosts to form and use
   addresses as recommended in Host Address Availability Recommendations
   [RFC7934].  In particular, this is needed for enhanced privacy, which
   implies that each host will register a multiplicity of address as
   part mechanisms like Privacy Extensions for Stateless Address
   Autoconfiguration (SLAAC) in IPv6 [RFC4941].  This implies that a 6LR
   or 6LBR which is intended to support N hosts MUST have space to
   register at least on the order of 10N IPv6 addresses.
"

I also removed the administrative rejection, the return codes are now as follows:

"
   +-------+-----------------------------------------------------------+
   | Value | Description                                               |
   +-------+-----------------------------------------------------------+
   |  0..2 | See [RFC6775].  Note that a Status of 1 "Duplicate        |
   |       | Address" applies to the Registered Address. If the Source |
   |       | Address conflicts with an existing registration,          |
   |       | "Duplicate Source Address" should be used instead         |
   |       |                                                           |
   |   3   | Moved: The registration fails because it is not the       |
   |       | freshest                                                  |
   |       |                                                           |
   |   4   | Removed: The binding state was removed. This may be       |
   |       | placed in an asynchronous NS(ARO) message, or as the      |
   |       | rejection of a proxy registration to a Backbone Router    |
   |       |                                                           |
   |   5   | Proof requested: The registering node is challenged for   |
   |       | owning the registered address or for being an acceptable  |
   |       | proxy for the registration                                |
   |       |                                                           |
   |   6   | Duplicate Source Address: The address used as source of   |
   |       | the NS(ARO) conflicts with an existing registration.      |
   |       |                                                           |
   |   7   | Invalid Source Address: The address used as source of the |
   |       | NS(ARO) is not usable on this link, e.g. it is not        |
   |       | topologically correct                                     |
   |       |                                                           |
   |   8   | Invalid Registered Address: The address being registered  |
   |       | is not usable on this link, e.g. it is not topologically  |
   |       | correct                                                   |
   +-------+-----------------------------------------------------------+
"

Does that work?

Take care,

Pascal

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: mardi 4 avril 2017 16:42
To: [email-masked]
Subject: Re: [6lo] Draft applicability for 6775bis

> in the IETF last call if the WG decides to go that way.

Right. ST and BCP are at the same level, so there are no down-ref issues with a normative reference. Those issues arise when ST or BCP documents normatively reference Info and Experimental documents.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Apr 2017 08:35:04 +0000

Dear all: 

FWIW, I also created a ticket https://trac.ietf.org/trac/6lo/ticket/20 to track the issue. 

Please let me know if the text below is OK (you may leverage the ticket); I'll time out and post by the end of week.

Take care,

Pascal

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: mardi 4 avril 2017 18:16
To: Erik Nordmark <[email-masked]>; Christian Huitema <[email-masked]>; Lorenzo Colitti <[email-masked]>
Cc: Brian Haberman <[email-masked]>; [email-masked]
Subject: Re: [6lo] Draft applicability for 6775bis

Dear all:

2.  Applicability

"

Does that work?

Take care,

Pascal

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: mardi 4 avril 2017 16:42
To: [email-masked]
Subject: Re: [6lo] Draft applicability for 6775bis

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 19 Apr 2017 22:12:29 +0000

> out and post by the end of week.

Thanks Pascal, looks good. 

Lorenzo? 

Unless we hear otherwise, we can think about WG LC perhaps as early as next week.

Thanks,

Gabriel (on behalf of chairs)

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Apr 2017 18:51:53 +0900

Thanks for writing this up. The text is very helpful.

In the general case, I'm not sure 10N is a reasonable recommendation. RFC
7934 section 7 discusses at some length the question of how many addresses
are necessary, and the conclusion is "in general it is not possible to
estimate in advance how many addresses are required".

For a constrained 6lo network, 10N seems reasonable. However, one of the
concerns I have with RFC6775bis is this text:

   Efficiency aware IPv6 Neighbor Discovery Optimizations
   [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND
   [RFC6775] can be extended to other types of links beyond IEEE std
   802.15.4 for which it was defined.  The registration technique is
   beneficial when the Link-Layer technique used to carry IPv6 multicast
   packets is not sufficiently efficient in terms of delivery ratio or
   energy consumption in the end devices, in particular to enable
   energy-constrained sleeping nodes.  The value of such extension is
   especially apparent in the case of mobile wireless nodes, to reduce
   the multicast operations that are related to classical ND ([RFC4861],
   [RFC4862]) and plague the wireless medium.  This serves scalability
   requirements listed in Appendix A.6.

I don't think this is good guidance for general purpose networks. On a
less-constrained device such as a phone connected to a less-constrained
network such as 802.11, ethernet, or LTE, I certainly wouldn't want to be
limited to 10 addresses. This is why RFC 7934 section 7 does not give a
recommendation for number of addresses per host, saying instead that the
network should be able to provide as many as necessary.

A registration-based mechanism is fundamentally different from an
opportunistic mechanism in that the scalability is determined by the number
of configured addresses, not the number of active addresses. For example:
on 802.11, for example, my device can configure 100, 1000, or 1000000
addresses in the same solicited-node multicast group (there are 2^40
addresses there, so there's plenty of space), and nothing in the network
will experience any load, until those addresses are used and have to be in
some router's neighbour cache. And if the neighbour cache were to implement
implement per-MAC address thresholds it would be possible to switch
addresses very frequently

I don't think we should say that 6LoWPAN ND can be extended to other links
without having good text on how to make a trade-off between the scalability
benefits that it claims and the address availability benefits that it gives
up.

On Thu, Apr 20, 2017 at 7:12 AM, Gabriel Montenegro <
[email-masked]> wrote:

> > Please let me know if the text below is OK (you may leverage the
> ticket); I'll time
> > out and post by the end of week.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Apr 2017 18:54:43 +0900

On Wed, Apr 5, 2017 at 1:15 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> [...]

As worded, it's not clear to me how this option is substantially different
from the administrative rejection option. Could it be scoped more tightly,
e.g., renamed to "Address topologically incorrect"?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Apr 2017 10:00:43 +0000

Hello Lorenzo:

Say the user registers, say, unspecified, is “Address topologically incorrect” the right thing?
I can add that code, but how do you return that the requester asks for pure garbage?

Take care,

Pascal

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: jeudi 20 avril 2017 11:55
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Erik Nordmark <[email-masked]>; Christian Huitema <[email-masked]>; Brian Haberman <[email-masked]>; [email-masked]
Subject: Re: [6lo] Draft applicability for 6775bis

On Wed, Apr 5, 2017 at 1:15 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
I also removed the administrative rejection, the return codes are now as follows:
[...]
   |   8   | Invalid Registered Address: The address being registered  |
   |       | is not usable on this link, e.g. it is not topologically  |
   |       | correct                                                   |

As worded, it's not clear to me how this option is substantially different from the administrative rejection option. Could it be scoped more tightly, e.g., renamed to "Address topologically incorrect"?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Apr 2017 19:03:19 +0900

I think so. the unspecified address is certainly not topologically correct
because it's not in the right /64.

In general, random garbage has only one chance in 2^64 of being
topologically correct. :-)

On Thu, Apr 20, 2017 at 7:00 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* jeudi 20 avril 2017 11:55
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* Erik Nordmark <[email-masked]>; Christian Huitema <
> [email-masked]>; Brian Haberman <[email-masked]>;
> [email-masked]
> *Subject:* Re: [6lo] Draft applicability for 6775bis
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Apr 2017 11:46:09 +0000

I’m wondering whether we should propose a guidance at all. I think the aim was in the ‘at least’, indicating that less than that would be a bad idea, but not giving an upper bar. That’s an admin/ best practice thing. Basically a device supports so many registrations, and the network admin must provide enough such devices to support his network. The devices I’m used to allow to configure such a bar (for SAVI purpose) - I mean there nothing new there, SAVI was there first - and the goal is really to protect the switch/router against ddos.

What do others think?

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: jeudi 20 avril 2017 11:52
To: Gabriel Montenegro <[email-masked]<mailto:[email-masked]>>
Cc: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Erik Nordmark <[email-masked]<mailto:[email-masked]>>; huitema <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Suresh Krishnan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] Draft applicability for 6775bis

In the general case, I'm not sure 10N is a reasonable recommendation. RFC 7934 section 7 discusses at some length the question of how many addresses are necessary, and the conclusion is "in general it is not possible to estimate in advance how many addresses are required".

For a constrained 6lo network, 10N seems reasonable. However, one of the concerns I have with RFC6775bis is this text:

I don't think this is good guidance for general purpose networks. On a less-constrained device such as a phone connected to a less-constrained network such as 802.11, ethernet, or LTE, I certainly wouldn't want to be limited to 10 addresses. This is why RFC 7934 section 7 does not give a recommendation for number of addresses per host, saying instead that the network should be able to provide as many as necessary.

A registration-based mechanism is fundamentally different from an opportunistic mechanism in that the scalability is determined by the number of configured addresses, not the number of active addresses. For example: on 802.11, for example, my device can configure 100, 1000, or 1000000 addresses in the same solicited-node multicast group (there are 2^40 addresses there, so there's plenty of space), and nothing in the network will experience any load, until those addresses are used and have to be in some router's neighbour cache. And if the neighbour cache were to implement implement per-MAC address thresholds it would be possible to switch addresses very frequently

I don't think we should say that 6LoWPAN ND can be extended to other links without having good text on how to make a trade-off between the scalability benefits that it claims and the address availability benefits that it gives up.

Lorenzo?

Thanks,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Apr 2017 11:59:09 +0000

Either way works for me. I’m happy with Lorenzo’s code. I’m also happy to have with this and a ”pure garbage” return code, if folks find useful to make that distinction.
Comments?

Pascal

Sent: jeudi 20 avril 2017 12:03

I think so. the unspecified address is certainly not topologically correct because it's not in the right /64.

In general, random garbage has only one chance in 2^64 of being topologically correct. :-)

On Thu, Apr 20, 2017 at 7:00 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Lorenzo:

Take care,

Pascal

From: Lorenzo Colitti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: jeudi 20 avril 2017 11:55
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: Erik Nordmark <[email-masked]<mailto:[email-masked]>>; Christian Huitema <[email-masked]<mailto:[email-masked]>>; Brian Haberman <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] Draft applicability for 6775bis

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Apr 2017 16:15:32 +0000

What about :

«
    This implies that a 6LR or 6LBR which is intended to support N hosts MUST have space to register at least on the order of 10N IPv6 addresses.
«
->
«
    This implies that the capabilities of 6LR and 6LBRs in terms of number of registrations must be clearly announced in the router documentation, and that a network administrator should deploy adapted 6LR/6LBRs to support the number and type of devices in his network, based on the number of IPv6 addresses that those devices require.
«

Works ?

Pascal
From: Lorenzo Colitti [mailto:[email-masked]]
Sent: jeudi 20 avril 2017 11:52
To: Gabriel Montenegro <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; Erik Nordmark <[email-masked]>; huitema <[email-masked]>; [email-masked]; Suresh Krishnan <[email-masked]>; [email-masked]
Subject: Re: [6lo] Draft applicability for 6775bis

Lorenzo?

Thanks,

---

From: Christian Huitema <[email-masked]>
Date: Thu, 20 Apr 2017 11:05:52 -0700

On 4/20/2017 9:15 AM, Pascal Thubert (pthubert) wrote:
>
> What about :
>
>  
>
> « 
>
>     This implies that a 6LR or 6LBR which is intended to support N
> hosts MUST have space to register at least on the order of 10N IPv6
> addresses.
>
> « 
>
> ->
>
> « 
>
>     This implies that the capabilities of 6LR and 6LBRs in terms of
> number of registrations must be clearly announced in the router
> documentation, and that a network administrator should deploy adapted
> 6LR/6LBRs to support the number and type of devices in his network,
> based on the number of IPv6 addresses that those devices require.
>
> « 
>
>  
>
> Works ?
>

I don't have a strong opinion on this wording, but I have a
recommendation for the authors of the draft. This discussion outlined a
couple of concerns about potential abuses. For example, I noted the
following:

1) Registration procedure could be used to deny access, by abusing the
administrative rejection option.

2) Nodes registering a large number of IID could overwhelm the
registration system.

I would also add a generic concern about unique identifiers and privacy.
This is an obvious concern in mobility scenarios, but even for static
networks it also is a concern if the option can be observed outside the
network. I understand that the encrypted link provides some mitigation,
but having provisions to vary the IID over time would be even better.

It might be a good idea to document these issues in the security
considerations.

-- Christian Huitema