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
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
