Re: RFC4941bis: consequences of many addresses for the network

[Bob Hinden <[e-mail]>]

Ole,

Clearly a very number of addresses is a problem for router and other devices on the link.   I note looking at my local machine (MacOS 10.14.6) I have five IPv6 addresses:

Link-local
ULA (temp and secured)
Global  (temp and secured)

My router advertises a Global and ULA prefix.

This seems to be current practice.   Is this a problem?   If I had 100 local devices on my link that would be 700 addresses, 1000 devices, then 7,000 addresses.  Is that excessive?   Also, depends on how the nodes manage this state, completely separate entries for each address, or all the addresses tied to the same link address.

For RFC4941bis, I think text that raises the issue is a good thing, but the issue isn’t created by the bis draft, it a part of SLACC.   We have multiple ways of creating IPv6 addresses, they all contribute to this.

I think a new document that discusses the issue and makes some recommendations would be useful.

Bob






> On Jan 23, 2020, at 12:59 AM, [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.
> 
> 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.
> 
> There is no signal available in SLAAC apart from DAD to reject an address. If the network runs out of resources (or prohibits the additional address by policy) the address will not be served. The host has to be deal with that situation.
> 
> 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).
> 
> I would like to hear from other network-side implementors and operators.
> Is there an issue here?
> 
> Best regards,
> Ole
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------