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

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

I read through the draft and found myself feeling that the arguments presented were rather uncompelling. So I'm going to provide some pushback.
Since the draft is presenting itself as recommendations for *all* networks, I decided to think about how I would look at it in the context of (1) a wireline broadband access service operator, (2) a wireless operator, and (3) an enterprise network operator.

Going through the list of benefits, the following struck me:
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.

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.

3. Tethering and translation (like 464XLAT) tend to be really specific to wireless networks. These are the most compelling benefits listed, but they don't apply to enterprise and wireline.

>From an enterprise and wireline perspective, I'm completely unconvinced that the suggested benefits are worthy of a BCP recommendation. 

>From a wireline perspective, I also see the recommendation as useless, since I'm not aware of any wireline architectures (BBF or CableLabs) that don't do PD. The wireline operators don't need a BCP to tell them to continue doing this. Of course the reason they do PD isn't even listed as among the benefits, since they don't do this for the sake of attachment by an individual host. They do this so customers can run entire private networks behind a fully-functional CE router. But I'm not aware of any wireline operator who requires the device requesting IA-PD to be a router.

>From a wireless perspective, I don't really see this as being what would convince a wireless operator to deploy PD. The case I try to make is that wireless is more and more being used in the same manner as wireline: to support an entire LAN of networked devices behind a CE router (usually with a USB-connected wireless device). In many places, operators are saying that wireless is the deployment model for getting "broadband access" to rural areas. If this use case is going to be fully supported with IPv6, then PD has to be supplied. Of course, with wireless networks being able to easily recognize the type of device used and the user, the network operator will always have the ability to selectively offer the PD to only certain users and/or certain devices.
Barbara