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

[Vasilenko Eduard <[e-mail]>]

> Have you considered the privacy address implications of only having 32 bits to work with instead of 64?
What is proposed (“prefix per host”) does break privacy anyway. IID manipulation (does not matter how many bits) would not help. The observer would see that it is the same host. Prefix bit manipulation is needed.
If DHCP-PD would give /96 then 32 bits of the prefix could be randomized.
If DHCP_PD would give /64 then no bits left for randomized.
Hence, /96 is much better on privacy!
Effectively, only /96 permits to specify privacy. With /64 per host, privacy is dead forever.

> 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.
Indeed. /64 is much more difficult to scan than /96. Have I understood you right that this point is in favor of /96 too?

> Are you worried about IPv6 address space running out?
It was a bad idea initially to waste almost 50% of address space that is for privacy only. In fact, almost (n^64-1)/n^64 of address space is wasted.
In reality, it is a little better because a few bits are needed on the link anyway.
Now, there is a chance to return IPv6 address space to 96 bits.
I remember that HP CEO said, “I see the market for 2 computers next year”.
Or Bill claimed that “640kB is for sure enough”.

> 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.
The world has already abused IPv6 address so much.

Eduard
From: Mark Smith [mailto:[e-mail]]
Sent: Tuesday, December 20, 2022 1:08 PM
To: Vasilenko Eduard <[e-mail]>
Cc: Lorenzo Colitti <[e-mail]>; Gert Doering <[e-mail]>; V6 Ops List <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt


On Tue, 20 Dec 2022, 18:14 Vasilenko Eduard, <vasilenko.eduard=[e-mail]<mailto:[e-mail]>> wrote:

  *   A /64 provides "infinite" addresses.
/96 is infinite too (for the host)

  *   In practice, /64 is the only prefix length that supports SLAAC.
Not a problem. The SLAAC may be on the different /64

  *   SLAAC is the only address assignment mechanism required to be supported by all hosts.
No problem. Hosts may support SLAAC and “/96 prefix per host” for a long time, even at the same time on the same link.
I do not see a reason why the new address acquisition mechanism should stick to the /64 prefix boundary.

Why not?

Why do you think a /96 is a good prefix length?

Have you considered the privacy address implications of only having 32 bits to work with instead of 64?

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.

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