RE: Disabling temporary addresses by default?

["Pascal Thubert (pthubert)" <[e-mail]>]

What problems are we talking about? I’ve seen several things:

A) On the host:
   1) desire to avoid leaking user info and network info around the us
   2) simplicity in address allocation
   3) match address lifetime with session needs

B) On the network:
   1) avoid misusing wireless resources (broadcasts)
   2) match the state in the network with the needs of the client adapt resource allocation
   3) maintain a complete picture of the addresses in use to set up forwarding (think overlays) and provide visibility to ops
   4) SAVI, protecting the hosts against addresses impersonation and stealing


The number of temp addresses is only remote to most of these issues.

A1) temp addresses beyond one session leaks information. The ideal would thus be one address per session. Since there can be a number of concurrent sessions it is hard to provide an upper bound to the number of addresses a host may use at one point of time, but certainly there could be several.
A2) Multiplying the mechanisms creates hassle and possible interactions between the mechanisms. The ideal would be a simple exchange where the host may provide an address or get one back, the address being guaranteed unique and inserted in the access routers by the end of the exchange so it is usable immediately.

A3) The lifetime of a session may vary. If the duration is unknown then the address should be renewable whereas RFC 4941 just deprecates its.

B1) The more addresses a node uses with classical ND, the more broadcast churn on the Wi-Fi. Having multiple addresses exacerbates the problem but it’s really a protocol issue more than a conceptual issue with having multiple addresses.

B2) On the network side, there’s a lot of memory available to maintain state. What hurts is that the network does not know when the hosts creates a new address and when it releases it. The more BCPs we change over time the less the network can guess. The network cannot even recognize a permanent and a temporary address.

B3) Because it is blind with IPv6 ND, the network maintains state for addresses that are not used any more, and may release state for addresses that are still in use. It has to resorts to LRU and limits the count of addresses per MAC. Then again the amount of addresses in use only exacerbates the problem, but it is really a protocol issue.

B4) If the network maintains a state about the address, that state can be associated with a proof of ownership. This simplifies dramatically the SEND problem, since the proof is done onece with the network as opposed to individually with each peer, and the token can be larger than 64 bits.

The problem is thus NOT that the node has too many addresses, and it is thus NOT to define how many address a node should have, and what would be the default lifetime. There is no good answer for that, this thread has been quite clear about that. The problem is to keep the network in sync with the needs of the hosts so the network can serve them optimally within resources.

The ideal would be that the host maintains a state with the network for all the addresses in use, with a sense of lifetime, mobility, and possibly a proof of ownership of the resources that it claims.

One can get a lot more by being polite and just asking.

So I’m asking. Please look at RFC 8505.

Pascal