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

[Vasilenko Eduard <[e-mail]>]

  *   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.
Ed/

From: v6ops [mailto:[e-mail]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, December 20, 2022 10:00 AM
To: Gert Doering <[e-mail]>
Cc: V6 Ops List <[e-mail]>; [e-mail]; [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.
=====