Re: RFC4941bis: consequences of many addresses for the network

[Michael Richardson <[e-mail]>]

Fernando Gont <[e-mail]> wrote:
    > PLease let me reiterate: the problem being discussed in this thread is a
    > shortcoming of slaac.

I think that the problem is bigger than SLAAC.  That's just one way to
configure addresses, and as you said, the problem is about communicating policy.

    > It's certainly fine to add a note along the lines of "hey! don't regenerate
    > addresses too frequently (i.e., beware when overriding default falues(, or
    > else you might end up screwing the network".

    > But other than that, 4941bis is not about addressing shortcomings of slaac.

I think that 4941bis should say something about the network cost.
Section 3.5 has a paragraph about the client costs of having a large number
of addresses, and maybe that's a place to talk about what happens if there
are too many.

I think that we need some way for a host to recognize that it's used too many
temporary addresses.  I wish that 6man-grand was able to add some kind of ACK
from the routers, but that won't scale.  So, we need a heuristic.
I would be happy if the document just said that this is a place for future work.

I've seen (wired) ubuntu hosts with a screen full of temporary
addresses.  Maybe that's a bug.

----

I also think that 3.6 should suggest that the enable/disable should be
settable on a per-attachment ("ESSID" aka "Provisioning Domain") basis.  The
text about doing this per-prefix would seem to mostly address this
requirement, but I'd prefer to write this differently.  Maybe it's enough to
start a new a paragraph at "Another site..."

I don't know how a "site" will communicate it's need to the OS, except via a
trusted administrator.  Maybe I missed somethinig?