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

[Lorenzo Colitti <[e-mail]>]

On Wed, Sep 23, 2015 at 1:32 AM, STARK, BARBARA H <[e-mail]> wrote:

> 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).

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

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.

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.

... 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.

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?

Cheers,
Lorenzo