[dhcwg] Re: [v6ops] Re: [IPv6]Re: Re: Re: An droid now supports DHCPv6 PD
Daryll Swer <[email protected]> Wed, 17 Sep 2025 07:44:28 +0530
| Newsgroups | gmane.ietf.dhc,gmane.ietf.v6ops |
|---|---|
| Message-ID | <CACyFTPEozAjT=Z6KL8r+b1+qc+TW0eav5Oc=Ygo_gt3OohC-zg@mail.gmail.com> |
--===============5840172898316442446== Content-Type: multipart/alternative; boundary="000000000000896fa4063ef5ccbd" --000000000000896fa4063ef5ccbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All these indecisive arguments on IPv6, is why we're here today with failure of 100% IPv6 adoption. SLAAC no SLAAC, DHCPv6 no DHCPv6, PD, no PD. /64 too much, /64 too less, /128 perfect, /128 not perfect and the ever changing "best practices for implementation" - dual stack, no dual stack, MAP-T, no MAP-T, 464xlat, no 464xlat etc. Oh and my favourite: /56-/64 dynamic broken PD for "privacy" in residential vs static/stable anti-privacy PD. Leading to fragmentation in software+hardware support, further complicating IPv6 adoption en masse. Personally I don't see a problem with /64 routed per host, anything larger is up to the discretion of the network operator. And anything smaller (excluding loopbacks and similar edge cases), is IPv4-centric approach. Also for those advocating for =3D>/65 prefix length, you may want to verify your ASIC's data sheets, chances are (I'm sure exceptions exists like HMC memory, which is above my pay grade) it'll explicitly say that it can support and scale more with <=3D/64s in the TCAM. In other words, I see no valid engineering reason to go smaller, excluding edge cases (loopbacks yada yada). -- Sent from my iPhone On Wed, 17 Sep 2025 at 6:43=E2=80=AFAM, Geoff Huston <[email protected]> wrote: > > > On 17 Sep 2025, at 10:16=E2=80=AFam, Mark Smith <[email protected]> = wrote: > > > > On Wed, 17 Sept 2025, 01:03 Gert Doering, <[email protected]> wrote: > >> Hi, >> >> On Tue, Sep 16, 2025 at 06:04:33PM +0900, Lorenzo Colitti wrote: >> > Recommendations for network operators are written in RFC 9663. Some te= xt >> > about expected prefix lengths is in section 8 of that RFC. RFC 9762 sa= ys >> > the prefix must be SLAAC-sized, which currently means it must be a /64 >> per >> > device. A /48 is fine for a small or medium network, but a campus with >> tens >> > of thousands of devices on it probably needs more than that. >> >> If but anyone had warned of this outcome before. >> > > If you're worried about IPv6 address space running out, you might want to > have a look at the original IPv6 proposal in RFC 8507, which proposed a 6= 4 > bit address space. > > IPv6 moving to 128 bits was not because 64 bits wasn't considered big > enough. It was to originally to support the GSE proposal, > > https://datatracker.ietf.org/doc/html/draft-ietf-ipngwg-gseaddr-00 > > While GSE didn't eventuate, what did eventuate was another 64 bits on the > end of addresses, which gave us a simple, one-size fits all default /64 > subnet size, iinstead of the error prone, complex, variable and potential > need to renumber "right-sized" subnets inherited from IPv4's CIDR - for > those who have no choice to do it. Most people do /24s when they can - fr= om > within Class A and Bs originally, and then RFC 1918 when that public IPv4 > address space became tight - because people used /24s. > > It has now given us the ability to give each host in networks where it > would be useful a /64 each. > > A /64 per host in a /128 address space is the equivalent of assigning a > single address per host in a 64 bit address space. It's more efficient th= an > what would have happened with a 64 bit address space - there would have > still been unused IPv6 64 bit addresses in the likely common /56 subnets > (i.e. IPv4 /24 equivalents). > > A 64 bit address space is 4 billion times larger than IPv4's 32 bit > address space. Has there been any other time in humanity where when > something wasn't big enough the next biggest designed size was 4 billion > times larger than the previous size? > > IPv4 was an experiment and proof of concept that escaped into production. > IPv6 is really the first true Internet Protocol for the world wide Intern= et > we have today and in the future. > > > There are many interpretations as to what happened and why in the 1991 - > 1994 period in the work on what became IPv6. Some of these are from folk > who were personally involved in the effort in various ways, others from > those who came later and tried to make some sense out of the somewhat > chaotic trail of material that the effort left in its wake. Mark's view > here is certainly one such interpretation of this material, but there are > certainly different interpretations as to how and why we landed up where = we > are today. > > There is the view that fixed boundaries in an address plan is never a goo= d > idea, and we should be able to allow network operators to define an > effective address plan to suit their particular requirements. There is > another view that iits possible to define an address plan such that "one > size fits all" - I've personally lost faith in that latter view! > > "first true Internet Protocol" - really?? > > Geoff > > > _______________________________________________ > v6ops mailing list -- [email protected] > To unsubscribe send an email to [email protected] > [image: f8447e837cbb0dbc945485daab3000cbc4af40a0] =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2= =80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80= =8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B= =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2= =80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80= =8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B= =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2= =80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80= =8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B= =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2= =80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80= =8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B --000000000000896fa4063ef5ccbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">All these indecisive arguments on IPv6, is why we're = here today with failure of 100% IPv6 adoption. SLAAC no SLAAC, DHCPv6 no DH= CPv6, PD, no PD. /64 too much, /64 too less, /128 perfect, /128 not perfect= and the ever changing "best practices for implementation" - dual= stack, no dual stack, MAP-T, no MAP-T, 464xlat, no 464xlat etc. Oh and my = favourite: /56-/64 dynamic broken PD for "privacy" in residential= vs static/stable anti-privacy PD.</div><div dir=3D"auto"><br></div><div di= r=3D"auto">Leading to fragmentation in software+hardware support, further c= omplicating IPv6 adoption en masse.</div><div dir=3D"auto"><br></div><div d= ir=3D"auto">Personally I don't see a problem with /64 routed per host, = anything larger is up to the discretion of the network operator. And anythi= ng smaller (excluding loopbacks and similar edge cases), is IPv4-centric ap= proach.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Also for those a= dvocating for =3D>/65 prefix length, you may want to verify your ASIC= 9;s data sheets, chances are (I'm sure exceptions exists like HMC memor= y, which is above my pay grade) it'll explicitly say that it can suppor= t and scale more with <=3D/64s in the TCAM. In other words, I see no val= id engineering reason to go smaller, excluding edge cases (loopbacks yada y= ada).<br clear=3D"all"><br clear=3D"all"><div dir=3D"auto"><div dir=3D"ltr"= class=3D"gmail_signature" data-smartmail=3D"gmail_signature">--<br>Sent fr= om my iPhone</div></div></div><div><br></div><div><br><div class=3D"gmail_q= uote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, 1= 7 Sep 2025 at 6:43=E2=80=AFAM, Geoff Huston <<a href=3D"mailto:gih@apnic= .net">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quot= e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl= e:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"> <div style=3D"line-break:after-white-space"> <br id=3D"m_-3568205788865460974lineBreakAtBeginningOfMessage"> <div><br> <blockquote type=3D"cite"> <div>On 17 Sep 2025, at 10:16=E2=80=AFam, Mark Smith <<a href=3D"mailto:= [email protected]" target=3D"_blank">[email protected]</a>> wr= ote:</div> <br> <div> <div dir=3D"ltr"> <div dir=3D"auto"> <div><br> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Wed, 17 Sept 2025, 01:03 Gert Doer= ing, <<a href=3D"mailto:[email protected]" rel=3D"noreferrer" target=3D"_bl= ank">[email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:r= gb(204,204,204)"> Hi,<br> <br> On Tue, Sep 16, 2025 at 06:04:33PM +0900, Lorenzo Colitti wrote:<br> > Recommendations for network operators are written in RFC 9663. Some te= xt<br> > about expected prefix lengths is in section 8 of that RFC. RFC 9762 sa= ys<br> > the prefix must be SLAAC-sized, which currently means it must be a /64= per<br> > device. A /48 is fine for a small or medium network, but a campus with= tens<br> > of thousands of devices on it probably needs more than that.<br> <br> If but anyone had warned of this outcome before.<br> </blockquote> </div> </div> <div dir=3D"auto"><br> </div> <div>If you're worried about IPv6 address space running out, you might = want to have a look at the original IPv6 proposal in RFC 8507, which propos= ed a 64 bit address space.</div> <div><br> </div> <div>IPv6 moving to 128 bits was not because 64 bits wasn't considered= =C2=A0big enough. It was to originally to support the GSE proposal,=C2=A0</= div> <div dir=3D"auto"><br> </div> <div dir=3D"auto"><a href=3D"https://datatracker.ietf.org/doc/html/draft-ie= tf-ipngwg-gseaddr-00" target=3D"_blank">https://datatracker.ietf.org/doc/ht= ml/draft-ietf-ipngwg-gseaddr-00</a><br> <br> While GSE didn't eventuate, what did eventuate was another 64 bits on t= he end of addresses, which gave us a simple, one-size fits all default /64 = subnet size, iinstead of the error prone, complex, variable and potential n= eed to renumber "right-sized" subnets inherited from IPv4's CIDR - for those who have no choice to do it. Mo= st people do /24s when they can - from within Class A and Bs originally, an= d then RFC 1918 when that public IPv4 address space became tight - because = people used /24s.=C2=A0</div> <div dir=3D"auto"><br> </div> <div>It has now given us the ability to give each host in networks where it= would be useful a /64 each.</div> <div dir=3D"auto"><br> </div> <div>A /64 per host in a /128 address space is the equivalent of assigning = a single address per host in a 64 bit address space. It's more efficien= t than what would have happened with a 64 bit address space - there would h= ave still been unused IPv6 64 bit addresses in the likely common /56 subnets (i.e. IPv4 /24 equivalents).</div> <div dir=3D"auto"><br> </div> <div>A 64 bit address space is 4 billion times larger than IPv4's 32 bi= t address space. Has there been any other time in humanity where when somet= hing wasn't big enough the next biggest designed size was 4 billion tim= es larger than the previous size?</div> <div><br> </div> <div>IPv4 was an experiment and proof of concept that escaped into producti= on. IPv6 is really the first true Internet Protocol for the world wide Inte= rnet we have today and in the future.</div> </div> </div> </div> </blockquote> <br> </div> <div>There are many interpretations as to what happened and why in the 1991= - 1994 period in the work on what became IPv6. Some of these are from folk= who were personally involved in the effort in various ways, others from th= ose who came later and tried to make some sense out of the somewhat chaotic trail of material that the eff= ort left in its wake. Mark's view here is certainly one such interpreta= tion of this material, but there are certainly different interpretations as= to how and why we landed up where we are today.</div> <div><br> </div> <div>There is the view that fixed boundaries in an address plan is never a = good idea, and we should be able to allow network operators to define an ef= fective address plan to suit their particular requirements. There is anothe= r view that iits possible to define an address plan such that "one size fits all" - =C2=A0I've p= ersonally lost faith in that latter view!</div> <div><br> </div> <div>"first true Internet Protocol" - really??</div></div><div st= yle=3D"line-break:after-white-space"> <div><br> </div> <div>Geoff</div> <div><br> </div> <div><br> </div> </div> _______________________________________________<br> v6ops mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">v= [email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]" tar= get=3D"_blank">[email protected]</a><br> </blockquote></div></div><span><span style=3D"display:none"><img src=3D"htt= ps://mailtrack.io/trace/mail/f8447e837cbb0dbc945485daab3000cbc4af40a0.png?u= =3D2153471&isAddon=3D1" alt=3D"f8447e837cbb0dbc945485daab3000cbc4af40a0= "></span>=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2= =80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80= =8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B= =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2= =80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80= =8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B= =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2= =80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80= =8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B= =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2= =80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80= =8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B= =E2=80=8B</span> --000000000000896fa4063ef5ccbd-- --===============5840172898316442446== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGhjd2cgbWFp bGluZyBsaXN0IC0tIGRoY3dnQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZGhjd2ctbGVhdmVAaWV0Zi5vcmcK --===============5840172898316442446==--