Re: rfc4941bis: On the use of multiple addresses

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

This is playing ostrich again.

 Limiting the amount of addresses is an obvious implication of SAVI in a managed network. When we did RFC 8505 the Sec-Dir review insisted to have text  to protect against DOS attacks. The SAVI draft did not go through that full cycle and is not complete to that regard. So I think the original text was a lot better.

And the size of the cache is mostly irrelevant to the ND churn these days. When addresses are dropping for the lack of rmemory there’s really an issue.  What’s relevant is the amount of new addresses joining the network, the number of nodes in the network that need to resolve it, and what nodes do when they sleep cycle or roam.

We measured (on the wire) several hundred multicast per second in average over 90 minutes during a keynote with a large audience. /64 per host is indeed tempting in such environment. But it boils down to IPv4 with 8 bytes addresses. We can do better.

Regards,

Pascal

Le 31 janv. 2020 à 01:18, Lorenzo Colitti <lorenzo=[e-mail]> a écrit :


I don't think the two RFC citations are appropriate. RFC 6583 is about the size of subnets, not about the number of hosts per subnet. RFC 7039 is about the SAVI framework, and I don't think there's anything in there about limiting the number of bindings. I also can't find anything in that document that talks about "enforcing port security that may enforce a limit on the maximum number of configured addresses per host". SAVI is a security mechanism to prevent spoofing, not a mechanism to limit the number of addresses.

draft-ietf-mboned-ieee802-mcast-problems is relevant in the sense that more addresses on the link create more neighbour discovery traffic. So how about rewording to the following?

=====
Network deployments are currently recommended to provide multiple IPv6 addresses from each prefix to general-purpose hosts. In some scenarios, use of a large number of IPv6 addresses may have negative implications on network devices that permanently maintain forwarding entries for all neighbour caches (e.g., [RFC7039]). Additionally, concurrent active use of multiple IPv6 addresses will increase neighbour discovery traffic if neighbour caches in network devices are not large enough to store all addresses on the link. This can impact performance and energy efficiency on networks on which multicast is expensive (e.g. [draft-ietf-mboned-ieee802-mcast-problems]).
=====

On Fri, Jan 31, 2020 at 7:54 AM Fernando Gont <[e-mail]<mailto:[e-mail]>> wrote:
Folks,

Based on the recent discussion regarding the possible impact of the use
of multiple addresses, I suggest we include the following text in
Section 4 of rfc4941bis:

"Network deployments are currently recommended to provide multiple IPv6
addresses from each prefix to general-purpose hosts. However, in some
scenarios, use of a large number of IPv6 addresses may have negative
implications on some network devices (e.g. [RFC6583]), exacerbate other
operational problems (e.g. [draft-ietf-mboned-ieee802-mcast-problems])
and/or may lead to traffic employing these addresses being dropped by
devices that enforcing port security that may enforce a limit on the
maximum number of configured addresses per host (e.g. [RFC7039]). A
discussion on possible approaches to allow for unconstrained use of IPv6
addresses can be found in [RFC7934]"

Thoughts?

Thanks!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: [e-mail]<mailto:[e-mail]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------