[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[hostmaster at uneedus.com]

Unlike IPv4 where most machines has one and only 1 IPv4 address, IPv6 
allows easy assignment of addresses, and in fact almost every machine 
running any operating system actually has many IPv6 addresses.  While the 
fixed addresses of SLAAC and DHCP exist, most OS's will use privacy 
addresses for outbound traffic.  Thus, both statements are kinda true.

Just as an example, Windows 7 and up will do the following by default:

1) A link local address, based on the MAC address.

2) If router advertisements are available, 1 address based on the prefix 
advertised by each router and the MAC address.  One address per router.

Multihome routing in v6 can be done in the workstation, as each router can 
be connected to a different upstream provider with a different prefix for 
each, but some OS's will use only one upstream in this case instead of 
using both, and also fail to go to the other one when that primary 
connection fails.  This is an issue that still needs work in many v6 OS 
stacks.  Since most networks only have one v6 router, this feature of 
multihome has not been used and tested enough to be bug free.

3) If DHCP6 is available, a DHCP assigned address from a block of 
addresses set up by the Network Administrator.

4) A randomly assigned "Privacy Address", that generally is replaced with 
a new one every 24 hours, and is the default address for all outbound v6 
traffic.  Some OS's will assign a privacy address in all available subnets 
and use them, while others will only set up one privacy address.

Of course, the action of #4 can be turned off by the administrator and is 
done if the business requires logging its employee traffic. #4 was done 
specifically to prevent internet wide tracking of a given MAC address, 
which would happen if #2 were the only global address assigned.  This is 
the problem you identified.

In effect, the best of both worlds exist.  Fixed addresses based on DHCP 
and SLAAC are available for inbound traffic, while outbound traffic not 
specifically bound to one of these fixed addresses always route via the 
changing random address, preventing tracking based on MAC address.

While these privacy addresses "hide" things, the administrator can still 
track everything on his network if needed as all communication is still 
done locally by the MAC address.  Good security practice is to restrict 
this data to that network's administrator.  Privacy Addresses are also 
done to prevent tracking by external actors, which can be associated with 
stalking and other such crimes by random internet actors, or like cookies, 
the serving of advertisements.

SWIP was never intended to register individual workstations as suggested, 
but to register contact addresses so that traffic and utilization of the 
total registered network segment. If someone on a given network segment is 
doing "bad" things, it gives you a point of contact.

Albert Erdmann
Network Administrator
Paradise On Line Inc.


On Wed, 12 Jul 2017, Owen DeLong wrote:

>> When applying this to IPv6 (and forgive my lack of knowledge) but part of
>> the address is identifying the physical interface (hardware).  Seems a SWIP
>> registration should be on that part of the address and then regardless of
>> service provider that host will always be identified the same, owned by Bob
>> Smith. As a service provider (SDWAN provider) I would NAT their network
>> portion of their traffic to return to me, but keep the host the same.
>> If I'm trying to hide the identity of the host by doing a full NAT with an
>> encrypted tunnel, I'm clearly up to no good and shouldn't be trusted by
>> content providers anyway. Trying to hide who I am is not security, it's
>> trying to disguise myself to obtain something my actual ID would not allow
>> me to, or I wouldn't want someone knowing I'm trying to obtain something.
>
> For better or worse, the IETF (and the OS vendors) have put significant effort
> into making sure that the above is completely and utterly false for all practical
> purposes.
>
> Owen
>
>
>