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

Le 20/12/2022 à 08:19, Jen Linkova a écrit :
> 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?

I agree with the question, I have the same question.

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

Further, if on the same subnet (presumably a VLAN ptp link) there is a 
/96 then it is that /96 that decides who are neighbours, and how to 
solicit them.  If only the 64 bits of that /96 are used to solicitate 
neighbors then some might be missing.

If, on the other hand, a distinct /64 (a distinct 64th bit) than the /96 
is being used _too_ on that ptp link, then we talk about two completely 
different prefixes.  Only one of these two prefixes (the /96?) would be 
allocated by DHCPv6-PD.

And, there might be easiness in speaking about these /64 and /96s 
because simply on a ptp VLAN link there are actually only two IP 
addresses (_points_), and ND is probably not useful.

At that point one of course wonders about the validity of 2^96 or 2^64 
addresses on a ptp link to a Host?

If the answer to that is that one wants to put several virtual machines 
in that Host, each with its own address, then probably the better idea 
is to _route_ a prefix (e.g. a /96, another /64, or similar) to that 
Host, instead of 64sharing, or 96sharing, à la smartphones.

We should not be doing in Enterprise the same error that smartphones are 
doing where only 64s are allocated to smartphones and which are further 
64shared experimentally.  Yes, sorry, I call it an error, and for others 
it is a perfectly valid matter, sorry about that.  Maybe it is an 
ongoing experiment that lasts very long time.  Maybe a 96share would be 
another experiment that would last a very long time.

Alex

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