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

[Mark Smith <[e-mail]>]

On Tue, 20 Dec 2022, 18:14 Vasilenko Eduard, <vasilenko.eduard=
[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]] *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]> 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]
> https://www.ietf.org/mailman/listinfo/v6ops
>