Re: [v6ops] Implementation Status of PREF64

[Vasilenko Eduard <[e-mail]>]

Many IP addresses could improve privacy, but “improve privacy” could be classified as harmful to internal Enterprise traffic.
It is a tiny advantage for traffic going to the Internet that could not overcome the complexity and cost of managing many virtual things (bigger logs, more difficult troubleshooting, additional requirements to CAM tables).
I suspect that it is not enough motivation to pay the price for Enterprises.
Is anything else exist that could justify many IP addresses in the Enterprise environment?
PS: we do not have many addresses for an apartment or a house.
Eduard
From: v6ops [mailto:[e-mail]] On Behalf Of David Farmer
Sent: Friday, October 1, 2021 9:30 AM
To: Lorenzo Colitti <lorenzo=[e-mail]>
Cc: v6ops list <[e-mail]>
Subject: Re: [v6ops] Implementation Status of PREF64



On Fri, Oct 1, 2021 at 12:50 AM Lorenzo Colitti <lorenzo=[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Oct 1, 2021 at 2:15 PM David Farmer <farmer=[e-mail]<mailto:[e-mail]>> wrote:
So, is there a compromise somewhere between 1 and 2^64 addresses to be had? Isn't it possible to request multiple addresses, that is to request multiple IA_NA options? Then if the server returns a number of addresses below a threshold, then refuse the addresses?

Well, let's find out. :-)

Let's see if we get enough consensus to work on an RFC that says that all general-purpose DHCPv6 clients are entitled to receive N addresses; that any network that does not provide that number of addresses is in violation of the RFC; and that any client disabling the IPv4 stack if it does not get at least N addresses is in full compliance with all IETF specifications including RFC 8415.

Personally I will be very surprised if you get consensus on any N even on this thread (let alone the WG or the IETF). The reason for that 1 is unacceptable to some folks, but any time you go beyond 1, then lots of infrastructure needs to be changed. And that's the rub here: IMO, when folks say they want DHCPv6, it's not because they want security or access control or tracking or whatever else. It's because they want to run their networks in the same way as they do in IPv4. That means an IPAM that maps one MAC to one IP and one DNS name, for example. If you're an enterprise, that's a legitimate desire: why pay costs that you don't think are necessary? The problem is that the enterprise does not pay the costs of NAT; device manufacturers, app developers, and users do. It would be good for users to stop having to pay those costs when we upgrade to IPv6. This is where we're stuck I think.

Another reason for not having a hard number is that TCAM is expensive and that any number that would provide enough flexibiilty in the long term (e.g., one IPv6 address per app on the device) would likely be too expensive today. That's obviously easily solved with DHCPv6 PD, but the problem with DHCPv6 PD is that it's not IA_NA, and requires infrastructure to be changed. Same problem as above.

Anyway, we can try this out as a thought experiment. I'll start: how about N=64?

Well, we run a quite sizable IPv6 network, I haven't looked at the numbers in a couple of years, but we were seeming an average of 4 and change IPv6 address per MAC address including LL, we had some outliers with a few hundred and even one with more than a thousand. Let's be generous, call it 5 IPv6 GUA addresses per host on average. I think almost 13 times average might be a bit much, but 2 to 5 times the average seems reasonable, so I'd probably start with a limit of 25 per host on our network. But, I need to go look at what the 90th, 95th, and 99th percentiles are at, I just don't remember.

So, for an RFC how about 10, I have a much bigger budget than a lot of networks.

Next bid, please.

Thanks
--
===============================================
David Farmer               Email:[e-mail]<mailto:[e-mail]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================