Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

[Brian E Carpenter <[e-mail]>]

Thinking about it, what counts for privacy is the unpredictable part of the whole address, not the unpredictable part of the IID as such. If an attacker sees

2001:db8:4006:80b:a1b3:6d7a:3f65:dd13

it really doesn't matter whether a1b3:6d7a is part of a randomly assigned prefix or of a randomly assigned IID. It's equally unguessable.

Admittedly, if an attacker sees numerous addresses that match 2001:db8:4006:80b:a1b3:6d7a::/96 they might deduce something, but that is the case for a /64 prefix anyway.

So what matters is using a pseudo-random value for everything possible, whether it's a subnet ID or an interface ID.

Regards
    Brian

On 21-Dec-22 21:48, Pascal Thubert (pthubert) wrote:
> Hello Mark
>>
>> Why do you think a /96 is a good prefix length?
>>
> 
> Depends what you use it for. For allocating as many addresses as you like 32 is enough. For embedding IPv4 that is enough. For encoding semantic addresses 64 is not enough. There’s no absolute value across all use cases.
> 
> 
>> Have you considered the privacy address implications of only having 32 bits to work with instead of 64?
> 
>   Illusion ! As soon as it is known that a /48 delegates /64s, privacy is all gone: you may rotate all you want, all addresses in the 64 are the same host.
> How long can that remain a secret?
> 
>   Arguably variable size is a big better but that’s a thin layer of obfuscation.
> 
> If you want to hide your tree in the forest you must allocate a few longer prefixes.
> 
>>
>> What about address discovery via unsolicited address probing? Sending 4 billion packets is much, much easier than sending 4 billion times 4 billion packets to try to discover live addresses within a /64.
>>
> 
> But then the attacker would need to know which /32 to probe in. So no not such a big deal.
> 
> The real issue is that the router will not shield the host any more. Since the router has only a prefix route all the ddos goes straight to the host. Be prepared !
> 
> The only protection against those attacks is the address registration.
> 
> Regard,
> 
> Pascal
> 
> 
>> Are you worried about IPv6 address space running out?
>>
>> The early designs of IPv6 only had 64 bit addresses. RFC1710:
>>
>> "SIPP supports addresses which are twice the number of bits as IPv4
>>    addresses.  These addresses support an address space which is four
>>    billion (2^^32) times the size of IPv4 addresses (2^^32).  Another
>>    way to say this is that SIPP supports four billion internets each the
>>    size of the maximum IPv4 internet.  That is enough to allow each
>>    person on the planet to have their own internet.  Even with several
>>    layers of hierarchy (with assignment utilization similar to IPv4)
>>    this would allow for each person on the planet to have their own
>>    internet each holding several thousand hosts."
>>
>> IPv6 today with 128 bit addresses is equivalent to the first designs of IPv6 with 64 bit addresses, except that a host can have 2^64 bits for itself, instead of only a single address.
>>
>> Regards,
>> Mark.
>>
>>
>>     ____
>>
>>     Ed/____
>>
>>     __ __
>>
>>     *From:*v6ops [mailto:[e-mail] <mailto:[e-mail]>] *On Behalf Of *Lorenzo Colitti
>>     *Sent:* Tuesday, December 20, 2022 10:00 AM
>>     *To:* Gert Doering <[e-mail] <mailto:[e-mail]>>
>>     *Cc:* V6 Ops List <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>>     *Subject:* Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt____
>>
>>     __ __
>>
>>     On Thu, Dec 15, 2022 at 11:44 PM Gert Doering <[e-mail] <mailto:[e-mail]>> wrote:____
>>
>>         Something like a /96 per host - so "limitless amounts of host would
>>         fit into a single /64" would avoid that, and still fulfill the
>>         stated necessity of having many many many addresses per hosts.____
>>
>>     __ __
>>
>>     The reason the draft mentions /64 is:____
>>
>>       * A /64 provides "infinite" addresses.____
>>       * In practice, /64 is the only prefix length that supports SLAAC.____
>>       * SLAAC is the only address assignment mechanism required to be supported by all hosts.____
>>
>>     That means that a node that gets a /64 is guaranteed to be able to extend the network indefinitely to all IPv6 nodes while maintaining end-to-end connectivity to all of them. That's a major improvement over IPv4's current capabilities. It's true that a /64 is relatively expensive in terms of address space. That said, this proposal is targeted towards larger networks. Fortunately, smaller networks tend to be less tightly managed, and for many of those networks, directly using SLAAC is fine.____
>>
>>     __ __
>>
>>     That said - based on past experience I fear that there is no single number that will get consensus in this group. For example, I definitely wouldn't want to *recommend* /96, because /96 would lose the above advantages. So, how about we just state the facts? Something like:____
>>
>>     __ __
>>
>>     =====____
>>
>>     Delegating a /64 prefix to the client allows the client to provide limitless addresses to IPv6 nodes connected to it (e.g., virtual machines, tethered devices), because all IPv6 nodes are required to support SLAAC.____
>>
>>     =====____
>>
>>     _______________________________________________
>>     v6ops mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops