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

Hi Alexandre,
By different, I mean: completely different.
For example, the router could announce on the link:
fdxy:<blah>/64 with A=1 (for SLAAC)
2001:db8:0:1001::/64 with A=1 (for SLAAC)
2001:db8:0:1002::/64 with A=0, P=1 (for /96 prefix per host), I hope 2^32 maximum hosts is not a restriction for a link

And later (over the years) the same router would be re-configured to announce the:
fdxy:<blah>/64 with A=0, P=1 (for /96 prefix per host)
2001:db8:0:1002::/64 with A=0, P=1 (for /96 prefix per host)

Eduard
-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Tuesday, December 20, 2022 12:17 PM
To: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

Le 20/12/2022 à 08:14, Vasilenko Eduard a écrit :
> * 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

A 'different' 64?  The first different bit would situate between 64th and 96th positions or must it be somewhere before the 64th?

Would a longest-prefix match algorithm identify the difference?

When it is said that the subnet prefix length is /64 and the delegated prefix length is /96: are these two prefixes precisely equal in the first 64bits?

Alex

> 
> * 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: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 
> <mailto: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