Re: RFC4941bis: consequences of many addresses for the network

[[e-mail]]

Fernando,

>> 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.
The network operator's response to this might 8273. In which case the privacy aspect changes quite a lot.

>> 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.
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?


> 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.
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.

Cheers,
Ole