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

On Tue, Dec 20, 2022 at 6:14 PM Vasilenko Eduard
<vasilenko.eduard=40huawei.com@dmarc.ietf.org> 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

Sorry, could you please elaborate on this?
The scenario is:
- the host connects to a network, receives an RA which indicates that
this network supports DHCPv-PD.
-- the host gets a prefix delegated and uses that prefix to assign
addresses to its interface(s) using SLAAC.

So if the delegated prefix is too short for SLAAC, what 'different'
/64 can be used?

>> 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.

The question here is how exactly the host assigns addresses from the
delegated prefix. The only existing mechanism is SLAAC and it requires
/64.

>
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti
> Sent: Tuesday, December 20, 2022 10:00 AM
> To: Gert Doering <gert@space.net>
> Cc: V6 Ops List <v6ops@ietf.org>; xiaom@google.com; draft-collink-v6ops-ent64pd@ietf.org
> 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 <gert@space.net> 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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
SY, Jen Linkova aka Furry