Re: RFC4941bis: consequences of many addresses for the network

Pascal,

All good points!
Before this diverge too far though, can we try to focus on RFC4941bis text.
Is there anything that document can say or should say to alleviate some of these issues?
Does temporary addresses add to the more general problem that SLAAC has?

Cheers,
Ole

> On 23 Jan 2020, at 11:26, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> Hello Ole
> 
> There are a number of cases where the address creates a state in the network:
> - in case there's routing taking place within the subnet (e.g., RPL in the an IOT LLN and RIFT or eVPN in a data center)
> - in case the network protects the address ownership since ND doesn't (SEND being what it is) and does minimal SAVI
> - in case the network tries to implement ND proxy which is mandated by IEEE std 802.11
> - in case Jen's draft is used to proactively assign ND state in the routers
> 
> In order to protect itself, the network blocks excessive amounts of addresses for a same device. It would serve this list to recognize it as a fact of life.
> 
> Sadly it is very hard with IPv6 ND alone to decide which address(es) to keep and which to remove. For the temporary addresses, LRU seems to work most of the time, with  a reasonable count of like 8 as suggested below. But some nodes like printers (silently) keep a permanent addresses that should survive the churn of other temporary addresses.
> 
> To serve the hosts correctly, the network is missing a classical but so useful information of lifetime that allows the state associated to the address to age out if not renewed. It is also classical in many IPv6-based standards (e.g., MIPv6, NEMO and RPL) that the nodes have  a chance to release a binding by indicating a lifetime of zero. The shortest path to get that is generalizing RFC 8505 to all MAC layers. *Is there any reason we do not?*
> 
> Conversely the network cannot signal how many addresses per node will be served properly in parallel. It cannot recommend lifetime values for temporary addresses and quasi-permanent addresses. It cannot signal that it rebooted and that all state need to be rebuilt. We need new RA information for that. I can write the draft within a few days if the group is willing to progress the work.
> 
> All the best,
> 
> Pascal
> 
>> -----Original Message-----
>> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of otroan@employees.org
>> Sent: jeudi 23 janvier 2020 09:59
>> To: 6man WG <ipv6@ietf.org>
>> Subject: RFC4941bis: consequences of many addresses for the network
>> 
>> 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
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------