Re: RFC4941bis: consequences of many addresses for the network

[Fernando Gont <[e-mail]>]

Hello, Ole,

On 23/1/20 05:59, [e-mail] wrote:
> While reviewing RFC4941bis
> (https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis) I think I
> found one gap.
> 
> A discussion of the consequences of a host having many (active)
> addresses on the network.
> 
> A 4941bis implementation following the defaults, would at the maximum
> use 8 active addresses. (Valid lifetime of one week and one new
> address per day.)
> 
> Shorter regeneration intervals or other approaches like a new address
> per connection could lead to dramatic numbers.

I guess we could add a small note to e.g. Section 4, along
the lines of:

"Use of an extremely large number of IPv6 addresses (as would result if
an implementation were to override TEMP_PREFERRED_LIFETIME with a much
shorter value) may have negative implications on some network devices,
and/or may lead to traffic from the offending addresses being policed by
devices enforcing port security (e.g. SAVI [REF]). A discussion on
possible approaches to allow for unconstrained use of IPv6 addresses can
be found in [RFC7934]"


Note: RFC7934 is *Very* relevant to this discussion.



> If we use Ethernet as an example, each new address requires state in
> the network. In the ND cache in first-hop routers, and in SAVI
> binding tables in bridges. Given ND's security properties these
> tables must be policed by the network. A host with a very liberal
> address regeneration policy might be viewed as performing an attack.

That's true, indeed. But isn't that sort of a design principle of SLAAC? 
-- i.e., kind of "anarchy" when it comes to host configuration?


SAVI with SLAAC is essentially telling nodes "do what you please", and 
then punishing nodes when they don't do what you *expect* or *wished*.



> SLAAC is also missing a mechanism to release an address. Which leads
> me to think that the address regeneration interval must not be
> shorter than the ND cache scavenger timeout (which in many networks
> is high to avoid cache churn and high level of address
> re-resolutions).

Which probably begs the question as why we don't make DHCPv6 mandatory, 
and add fill the necessary gaps there, so that a network that is to be 
operated as a managed network can apply policy to hosts, as needed. 
(yes, I did mean what I've just said :-) )

Put another way: SLAAC doesn't enforce any sort of policy on the 
network. Even attempts to *suggest* policy (e.g. 
draft-gont-6man-managing-slaac-policy) were shot down.

We also published draft-gont-6man-address-usage-recommendations to 
discuss the topic in a more general way. The suggestion was to take it 
to TAPS, where it somehow vanished.

So my personal conclusion is that one could certainly add a note like 
the one I suggested above. But other than that, I think further 
discussion of the topic belongs to a different document. -- We could 
revive draft-gont-6man-address-usage-recommendations if desired. -- in 
fact, it's kind of a shame that there hasn't been further work in that area.

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