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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Jen


> In a nutshell, SLAAC is good for hosts, ...

To be demonstrated. 

I'd agree for the AAC piece, I have definite use cases where it is useful for the host to select its address, e.g., where the address has opaque semantics, or where the efficient compression depends on the address format. 

But the reactive SL operation is not good for the host or the whole planet as it goes. It leads to massive power wasting, hosts that think they have a usable address but they do not, wasted resources in the fabrics, and in the end, disenchanted users with an IPv6 experience way below that of IPv4. 


> ... while DHCP is convenient for operators.

What's necessary for operators is to know deterministically which addresses are used by which device. DHCP also allows the operator to force which address that is. Which might be desirable in some cases, and not in others.

My bottom line:

SLAAC should be deprecated because it fails to provide reliable addresses in modern networks and because it causes undesirable wastes of energy and resources.
SLAAC cannot be deprecated until the alternates are generally available, and generations of devices are replaced. A lot time.
We need alternates that cover all use cases. Your proposal is one of the needed alternates and I support it.
We also need an alternate with AAC and no DHCP. For that the best plan is to revive efficient ND. Now that we have RFC 8505 and RFC 8928, that should be doable.

All the best,

Pascal



> -----Original Message-----
> From: v6ops <[e-mail]> On Behalf Of Jen Linkova
> Sent: vendredi 16 décembre 2022 2:20
> To: Ole Troan <[e-mail]>
> Cc: V6 Ops List <[e-mail]>; [e-mail]; draft-collink-v6ops-
> [e-mail]
> Subject: Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-
> ent64pd-01.txt
> 
> On Fri, Dec 16, 2022 at 7:47 AM Ole Troan <[e-mail]> wrote:
> >
> > And DHCP PD can of course also assign a /128 prefix to the host if
> > that’s desired. :-)
> 
> That's very much UNDESIRED, thank you ;)
> 
> In a nutshell, SLAAC is good for hosts, while DHCP is convenient for
> operators.
> So let's hide SLAAC from the operator while still having it available for the
> host.
> Hence /64.
> 
> >
> > > On 15 Dec 2022, at 15:45, Gert Doering <[e-mail]> wrote:
> > >
> > > Hi,
> > >
> > >> On Thu, Dec 15, 2022 at 02:59:33PM +1100, Jen Linkova wrote:
> > >> We've just submitted -01 version of draft-collink-v6ops-ent64pd,
> > >> which proposes using DHCPv6-PD to delete /64 per host (the draft
> > >> was very briefly presented at the last IETF).
> > >
> > > I do not think that a /64 per host is reasonable address usage.
> > >
> > > To implement this, network admins need not only to add v6 subnets to
> > > broadcast segments but also add pools of sizeable size, which does
> > > create pressure in the /48.../64 range of the addresses they have
> > > ("one /48 per site").
> > >
> > > 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.
> > >
> > > Gert Doering
> > >        -- NetMaster
> > > --
> > > have you enabled IPv6 on something today...?
> > >
> > > SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> > > Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> > > D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> > > Tel: [phone]         USt-IdNr.: DE813185279
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> --
> SY, Jen Linkova aka Furry
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops