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 protected]]
Sent: jeudi 20 avril 2017 11:52
To: Gabriel Montenegro <[email protected]>
Cc: Pascal Thubert (pthubert) <[email protected]>; Erik Nordmark
<[email protected]>; huitema <[email protected]>;
[email protected]; Suresh Krishnan
<[email protected]>; [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
