Re: [Ila] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt

[Tom Herbert <[e-mail]>]

On Wed, Feb 21, 2018 at 6:55 AM, Mikael Abrahamsson <[e-mail]> wrote:
> On Mon, 19 Feb 2018, Tom Herbert wrote:
>
>> This draft discusses issue of privacy in IPv6 network prefix assignment.
>> Specifically the privacy problems of an assigned network prefix becoming a
>> persistent identifier for devices (e.g. /64 assignment to devices in mobile
>> networks).  The use of identifier/locator split is suggested as a solution.
>
>
> Current state of available address for a PDN is /64. In most implementations
> I am aware of, if the PDN is brought down, and then up again, a new /64 will
> be used. The host can therefore control this part of "privacy", cycle PDN
> when it feels it's appropriate to get new address space to avoid tracking. I
> am supportive of this approach and any spatial overlap of multiple
> PDNs/address space approach, so that connections can be moved over to use
> the new address, gracefully.
>
> I consider anything that gives the host less than /64 worth of addresses a
> regression from current situation. We can always discuss if /80 is enough
> etc, but anyhow, it's a regression that should be presented front and center
> by any proposed change to current state of affairs.
>
> I have now read section 6 twice, and I still have no idea how many usable
> addresses the host has available to itself according to
> draft-herbert-ipv6-prefix-address-privacy-00.
>
> Can you please enlighten me?
>
Mikael,

As mentioned in section 6, addresses contain no hierachy beyond the
provider prefix so the space over which addresses are assign can be
flat large space (/32, /48, etc). The goal is that from any outside
observer all addresses seem to be randomly chosen from the space with
no means to create correlations.

Host are assigned addresses from the space. The goal is that all
addresses appear to be randomly assigned in that space. Conceptually,
a host could request assignment for inidivual millions or billions of
addresses, but that won't scale. The alternative suggested is to
assign addresses in blocks using hidden aggregation as described in
section 6.2.2.2. Blocks would contain multiple addresses (could be
thousands, millions, etc.).

Tom