Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

[DaeYoung KIM <[e-mail]>]

Sent from my iPhone

> On 17 Aug 2017, at 11:48, Mark Smith <[e-mail]> wrote:
> 
> Externally, it is not possible to determine whether a /64 is assigned
> to a link or a host - consequently, it isn't possible to know if
> source addresses from with a /64 represent a single device's traffic
> (the /64 is assigned to a single device) or traffic from a range of
> devices (a /64 is shared by many devices attached to a link.)

Exactly.

So, why would it bother you

   - if a host given a /64 prefix assigns a 64-bit IID to each of its interfaces, or 

   - if the same host subdivides the /64 prefix into multiple /96 prefixes each of which be given to internal devices behind, wherein each device then assigns 32-bit IIDs to its own interfaces.

Such domestic behaviors are not observable from outside, so why would you enforce 64 bits for whatever is classified as an IID?

> Individual source addresses however always represent traffic from a
> single device.

Of course.  

The original question was about the feasibility of 32-bit length of IIDs for internal devices behind a /64 host, in regards to privacy.

In a legacy IPv6 networking, the pool of 64-bit IIDs would be shared by hosts inside a subnet which may contain arbitrarily many hosts,

whereas in my scenario of internal /96 devices behind a /64 host, the pool of 32-bit IIDs would be shared by interfaces of a single device.

If obfuscation should be a measure of merit, the obfuscation of 32-bit IIDs across interfaces of a /96 device should not be terribly inferior to that of 64-bit IIDs across all interfaces of all hosts inside a /64 subnet.

My question then goes back to

   - What's the point of mandating 64 bits for IIDs when behaviors internal to or behind a /64 are not observable from outside anyhow?

   - Are there any practical ways to police them and return penalties to ill-behaving hosts?