Re: rfc4941bis: On the use of multiple addresses

[Fernando Gont <[e-mail]>]

Hi, LOrenzo,

Some clarifications in-line... and comments on the suggested email at
the end of this email...


On 30/1/20 21:18, Lorenzo Colitti wrote:
> 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.

My understanding is that it's about the effects of a limited NC size in
a network that hosts a virtually unlimited number of IPv6 addresses.

In their case, they focus on e.g. DoS triggered by address-scans... but
at the end of the day limited NCs work rather bad when presented with
more addresses than what they can handle.


> 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.

Fair enough. Reality is that if you need to keep mappins, you either
limit the number of mappings, or you become subject to DoS...



> 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

Not sure what you mean by "maintain forwarding entries for all neighbour
caches"?  (did you mean "for all network cache entries"? something else? ).


> 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]).

I ended up incorporating the following text (in Section 4 of the -06
rev), which is essentially what you proposed, modulo a small
modification in result to the text that I couldn't "parse":

   Network deployments are currently recommended to provide multiple
   IPv6 addresses from each prefix to general-purpose hosts [RFC7934].
   However, in some scenarios, use of a large number of IPv6 addresses
   may have negative implications on network devices that need to
   maintain entries for each IPv6 address in some data structures (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.
   [I-D.ietf-mboned-ieee802-mcast-problems]).

Please do let me know whether it looks fine, or you have any further
suggestions.

Thanks!

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