Re: RFC4941bis: consequences of many addresses for the network

[Fernando Gont <[e-mail]>]

On 23/1/20 11:11, [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.
> 
> I don't think 7934 uses the words "unconstrained". There is always going to be a limit.

They do use "can address unlimited endpoints, subject to network 
limitations". That said, of course I agree with you in this respect.



> The network operator's response to this might 8273. In which case the privacy aspect changes quite a lot.

At the end of the day, you are always at the mercy of the network operator.




>>> 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?
> 
> Absolutely. Just that temporary addresses changes the equation quite a bit.
> A network might be willing to serve a small set of addresses to a host, but with temporary addresses there are really no limit.

I'd argue that that's a potential problem intrinsic to slaac, rather 
than temporary addresses.

Datapoint: I have some apps explicitly meant to circumvent security 
controls. RFC4941 is not enough, because address generation is bound to 
time (and OS implementations set a lower bound). So essentially I do 
one-address-per-application (configure the address, explicitly bind it 
when issuing connections, then remove it).



> If you do an address per transport connection, would you expect the network to serve that?
> And if it doesn't, how is the host supposed to detect it? An happy eyeballs approach?
> Right now that is completely unspecified in 4941bis (and sure it also was in 4941).
> Question is if we should (try to) fix that?

I think that at least a "warning note" on the topic would be desirable. 
That's one option. Another option might be to enforce an upper limit on 
the time regeneration frequency (although I'd expect that it would be 
virtually impossible to come up with an agreeable value)



>> 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.
> 
> For the purpose of 4941bis I would also be fine with a more ellaborate note expanding on the issues.

That sounds sensible. Unless I hear a specific text proposal beforehand, 
I will come back with suggested text later today.



> And I would also prefer that we suggested some strategies hosts can use to deal with this. There is already text in 4941bis regarding DAD. But the recommended behaviour when receiving DAD "rejects" seems a little harsh currently.

Wouldn't *this* be more of a slaac issue than a rfc4941bis one?

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