Re: RFC4941bis: consequences of many addresses for the network

[Fernando Gont <[e-mail]>]

On 24/1/20 07:52, [e-mail] wrote:
> Hi Philip,
> 
>> The question of an address per transport connection is why would you do that?
>> In many IPv4 installations, the NAT box has state per flow. So having an IPv6
>> address per transport connection doesn't seem beyond what we can do.
> 
> On reason might be because the application uses the temporary address in a way that taints it.
> E.g. the address is used in a connection where the user is identified through authentication.
> That address is now tained from thew perspective of privacy, and should not be used for other connections.
> 
> Given that we are downgrading 4941 to proposed standard, it might also be worth evaluating the state of 4941 implementations.
> Are applications clever enough to not reuse tainted addresses?
> Are they incorrectly exposed by e.g. MP-TCP or ICE implementations?
> Anyone with data on this?

As noted elsewhere, there's a difference between the generation of 
temporary addresses, and their use.

Hostas and applications are quite dumb baout the use of addresses -- not 
just temporary addresses -- since we haven't done much on the topic. 
That's why we had published this: 
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations

I'm not aware of any API to trigger the generation of a new address, or 
deprecate an existing one. Or even to make more appropriate use of 
addresses based on their properties.

But, again, this is not an issue of temporary addresses, specifically. 
And thus would seem out of scope for this document.



> 
>> The question is what the benefits are. I don't see a lot of privacy benefits
>> for lots of addresses.
>>
>> Note that a single network port may still end up with losts of addresses:
>> - users may use bridges to extend the network and connect more than one host
>>   to a single port
>> - users may run virtual machines (or containers) in bridged mode and end up
>>   with multiple virtual hosts by behind a single port
>> - having an IPv6 address per process on a host may have benefits in particular
>>   if many processes would like to use the same port for some reason
>>
>> Typically, even very small network switches support many thousand MAC
>> addresses. I think that network devices should support similar numbers of
>> IPv6 addresses per /64.
> 
> Sure, but when a host incurs a cost in the network, and the network has to have some policy in place to protect itself, there is going to be a limit.

If you want to enforce policy, that's what dhcpv6 is for.

If you use a /64 for the subnet (tons of addresses available), employ 
SLAAC for address configuration ("this is the local prefix... do what 
you please"), and even refrain from having SLAAC convey network policy 
(e.g. as in our circa 2011 to set a bit in PIOs regarding whether 
temporary addresses are desirable), I don't think you can complain about 
having nodes "using more addresses than you'd wish".



> I think we need some text in 4941 discussing this, and also give a recommendation for host behaviour. And perhaps also for network configuration.

I don't think we can give a recommendation other than something along 
the lines of "beware of regenerating temporary addresses too quickly, 
because this might affect the network".

RFC4941 is a deployed reality, and I don't think rfc4941is is changing 
anything significantly in terms of the number of addresses.

Rather I take this discussion as an indication that in a number of 
scenarios the network may want to convey policy (no surprises here), 
which leads e to believe that:

1) we should make dhcpv6 mandatory for once and for all, such that 
networks that want to enforce policy, they can

2) we might want to do something along the lines of 
draft-gont-6man-managing-slaac-policy, such that a network that wouldn't 
like privacy addresses, can convey that information to hosts.


However, when it comes to rfc4941bis, I don't think there's much more to 
do than simply including a small paragraph noting that an implementation 
should be aware about regenerating addresses too quickly,

The topic of "many addresses in a network" is way broader than temporary 
addresses, and includes e.g. "throw-away addresses" (one address per 
app), which have nothing to do with temporary addresses.

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