Re: RFC4941bis: consequences of many addresses for the network

[Alexandre Petrescu <[e-mail]>]

Le 23/01/2020 à 14:32, Tim Chown a écrit :
>> On 23 Jan 2020, at 12:16, [e-mail] wrote:
>> 
>> 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?
> 
> The problem statement section in 4941bis is all about user privacy,
> no mention of operational / management complexity, or other “general
> problems” that SLAAC has.  It seems there are unstated problems here
> :)

Within "general [SLAAC] problems" I also think about "Permission-less 
extensions of the network with new links (and by implications new 
routers) are not supported."

Last December, we heard half-joking topics.  A further half of that half
might be related to SLAAC:

>>   - 64 bit boundary
>>   - M/O bits
>>   - ULA or not ULA
>>   - Extension headers
>>   - Defining new mechanisms for IID formats

Alex
> 
> Tim
> 
>> 
>> Cheers, Ole
>> 
>> 
>>> On 23 Jan 2020, at 11:26, Pascal Thubert (pthubert)
>>> <[e-mail]> 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 <[e-mail]>
>>>> On Behalf Of [e-mail] Sent: jeudi 23 janvier 2020
>>>> 09:59 To: 6man WG <[e-mail]> 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
>>>> [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 
>> --------------------------------------------------------------------
>>
>
>> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>