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 protected]] Sent: jeudi 20 avril 2017 11:52 To: Gabriel Montenegro <[email protected]<mailto:[email protected]>> Cc: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>>; Erik Nordmark <[email protected]<mailto:[email protected]>>; huitema <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Suresh Krishnan <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> 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)
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
