Re: [6lo] Draft applicability for 6775bis

["Pascal Thubert (pthubert)" <[e-mail]>]

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:[e-mail]]
Sent: jeudi 20 avril 2017 11:52
To: Gabriel Montenegro <[e-mail]<mailto:[e-mail]>>
Cc: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; Erik Nordmark <[e-mail]<mailto:[e-mail]>>; huitema <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Suresh Krishnan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [6lo] Draft applicability for 6775bis

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 <[e-mail]<mailto:[e-mail]>> 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.

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)