Re: [v6ops] v6ops-host-addr-availability: A Little Pushback

["STARK, BARBARA H" <[e-mail]>]

In-line, marked with <bhs>.
Barbara

1. Privacy. Changing tracking requirements from needing to track a /128 to only needing to track a /64 does not provide for any sort of improved privacy against tracking. We need to stop perpetuating this myth. draft-ietf-dhc-dhcp-privacy already describes how to provide a single address that doesn't give away the MAC address. Other than not giving away the MAC, there is no privacy benefit I can see to more easily allowing tracking systems to track at the /64 instead of the /128.

Here's one privacy benefit that requires the ability to form multiple addresses: change your privacy address as often as you want, instead of how often the operator wants. Or, use different addresses to talk to different sites (e.g., a web server and an advertising server). These are both useful benefits if the network is trustworthy but the the attack is pervasive monitoring outside the network (e.g., by a national security agency).

<bhs> Privacy addresses can help with 2 privacy functions: (1) they obscure the MAC address; (2) self-generated SLAAC privacy addresses reduce the ability to do external-to-the-local network tracking down to the /64 prefix level. When the /64  is shared among multiple devices, there can potentially be a little bit of additional privacy from tracking – but even that depends, given all the info browsers hand out to HTTP servers. When a /64 is dedicated to a device, and the /64 never changes, the benefit of privacy addresses is reduced to obscuring the MAC address. A single unchanging privacy address within the unchanging prefix provides exactly the same obscuring of the MAC address as dozens of constantly changing privacy addresses. We need to stop perpetuating this privacy myth.

These aren't in the draft, but we could add them.

<bhs> If you want to list improved tracking as a benefit (i.e., reduced privacy), I would have no problem with that. Many people would indeed see that as a benefit.

2. Several of the listed benefits involve potential use by multiple processors on a host, virtual machines on a host, future applications, and identifier-locator addressing (ILA). In listing these, there was nothing that said "this is incredibly useful, but hosts are prevented from doing it (or run into a lot of complexity) if the host is restricted to a single DHCPv6-assigned IPv6 address". I didn't read that hosts would have a hard time having multiple processors or future applications in the absence of multiple addresses, and I didn't get out of the discussion that virtual machines and ILAs that require their own address are incredibly compelling and hosts and users can't live without them.

As someone who has worked on the ePDG implementation on Android devices, I can assure you that the architecture that's used to ensure that the baseband processor and the application processor could share an IP address is pretty contorted - you might even say nightmarish.

<bhs> But it’s been done? Now if you said that not using this nightmarish code would improve battery life of the devices, that would be a real benefit (from an operator perspective – who is your target audience). But if the code is done and works, then I don’t see why an operator should care how nightmarish it was for the OS implementation.

And VMs do require their own addresses - no host OS I'm aware of supports sharing an IP address with another host. The sharing has to be done by performing NAT on the upstream.

<bhs> I didn’t say VMs didn’t need their own addresses. What I said was I wasn’t convinced that all hosts needed VMs in order to do whatever it was the user wanted them to do. You haven’t provided a compelling reason why VMs are beneficial in hosts. Without that, I don’t understand why I should care whether or not  all hosts can run VMs.

... which is really the point here. What we're trying to say here is not that these use cases are hard or impossible without multiple addresses. What we're trying to say is that they exist, and that they can either be met using multiple addresses or (in most cases) by performing NAT66 in the host. We're recommending that we do not go to an architecture where hosts need to implement NAT66, and thus we recommend that the network should assign enough addresses that NAT66 is not necessary.

<bhs> NAT66 is not something that hosts inside enterprise networks need to be worried about. Yes, I can see that it’s a problem for UEs in a wireless network.

Also, I'm not sure exactly what you're trying to say here. Are you saying that:

  1.  You disagree that if the network assigns a single /128, hosts will implement and use NAT66; that they will instead reduce or disable (possibly user-visible) functionality.
  2.  You believe that it's fine if networks assign a single /128 to a device, even if it means that hosts will (possibly widely) implement NAT66.
  3.  Something else?
<bhs> I’m saying that you haven’t presented your case in a very compelling manner. The case for (the interior of) enterprise networks is non-existent. The case for wireline networks is unnecessary. I think it’s possible for you to make a compelling case for 3GPP wireless networks, but that needs work. I think it would be easier for you to make that case if you focused on that audience and that case. I also think that you would make the case better if you provided benefits worded in a way that cause the operator to care (i.e., by appealing to their self-interest). And “benefits” that are not real benefits detract from the argument because they provide an easy target for detractors to attack, and draw attention away from the real benefits.
Barbara