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

I have not understood this discussion about "solicitation".
It does not matter what would be the prefix size per every host (let's assume /56 or /64).
Hosts would not be capable of direct communication anyway - only through routers.

Moreover, it makes sense to suppress "solicitation" and "DAD" for such prefixes. Like mobile did.
It is the L3 emulation of P2P.

I do not understand the problem if the majority of /96 (out of the single /64) would not be assigned to any host.
So what? What is the problem?

Reminder: /96 appointments are by DHCP-PD only. This special PIO in RA is just informational.
Ed/
-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Tuesday, December 20, 2022 12:29 PM
To: v6ops@ietf.org
Subject: 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
> 
> 
> 

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops