[dhcwg] Re: [v6ops] Re: [IPv6]Re: Android now su pports DHCPv6 PD

--===============5609888950502499506==
Content-Type: multipart/alternative; boundary="0000000000000bd995063f0055b2"

--0000000000000bd995063f0055b2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

FWIW a university campus network seems like a great use case for DHCPv6 PD.
It's very similar to a mobile network in that it provides access to large
numbers of unmanaged devices. Per-device subnets (either using PD or using
RAs as described in RFC 8273) should make it easy to support large numbers
of devices without scaling issues and should make it easier to defend
against on-link ND attacks.

Speaking of the address policy specifically, the wording in the current
policy seems to ban RFC 8273 as well, since in RFC 8273 the network
provides a /64 prefix for every device - it just uses RAs to do so instead
of PD.

On Wed, Sep 17, 2025 at 11:41=E2=80=AFPM Tim Chown <[email protected]> w=
rote:

> On 17/09/2025, 01:36, "Lorenzo Colitti" <[email protected]> wrote:
>
>
>
> On Wed, 17 Sept 2025, 09:17 Mark Smith, <[email protected]> wrote:
>
> 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.
>
>
>
> There's no need to look at history here. We can just observe that all
> cellular networks assign two or more /64s to every device by default, all
> the time. That is the industry standard and was strongly argued for by th=
e
> IETF when mobile operators originally designed the standards to assign on=
ly
> a single /128 per device.
>
>
>
> Why RIPE would have a policy that allows cellular networks to provide
> multiple /64s per device but doesn't allow, say, enterprise networks to d=
o
> the same seems somewhat arbitrary and unfair. After all, both of these ar=
e
> IETF-standard deployment models.
>
>
>
> Well, =E2=80=9CRIPE=E2=80=9D is just a community of people, that could re=
define/clarify
> that policy to reflect modern reality.
>
>
>
> As an NREN advocating campuses deploy IPv6, we have to justify giving mor=
e
> than a /48 to an organisation, and if DHCP-PD isn=E2=80=99t acceptable th=
en those
> organisations will need to look at LIR status.  That=E2=80=99s not curren=
tly an
> expensive proposition, in the grand scheme of university finances.  An NR=
EN
> can route such LIR space alongside assignments from its own space, as we =
do.
>
>
>
> Tim
>

--0000000000000bd995063f0055b2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">FWIW a university campus network seems like a great use ca=
se for DHCPv6 PD. It&#39;s very similar to a mobile network in that it prov=
ides access to large numbers of unmanaged devices. Per-device subnets (eith=
er using PD or using RAs as described in RFC 8273) should make it easy to s=
upport large numbers of devices without scaling issues and should make it e=
asier to defend against on-link ND attacks.<div><br></div><div>Speaking of =
the address policy specifically, the wording in the current policy seems to=
 ban RFC 8273 as well, since in RFC 8273 the network provides a /64 prefix =
for every device - it just uses RAs to do so instead of PD.</div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Se=
p 17, 2025 at 11:41=E2=80=AFPM Tim Chown &lt;<a href=3D"mailto:Tim.Chown@ji=
sc.ac.uk" target=3D"_blank">[email protected]</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div>





<div lang=3D"EN-GB">
<div>
<div id=3D"m_-1795022561236349103m_-4052212344409543820mail-editor-referenc=
e-message-container">
<div>
<div>
<div>
<p class=3D"MsoNormal">On 17/09/2025, 01:36, &quot;Lorenzo Colitti&quot; &l=
t;<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
m</a>&gt; wrote:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12pt"><u></u>=C2=A0<u></u></p=
>
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36pt">On Wed, 17 Sept 2025, 09:=
17 Mark Smith, &lt;<a href=3D"mailto:[email protected]" target=3D"_bla=
nk">[email protected]</a>&gt; wrote:<u></u><u></u></p>
</div>
<blockquote style=3D"border-top:none;border-right:none;border-bottom:none;b=
order-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4=
.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<blockquote style=3D"border-top:none;border-right:none;border-bottom:none;b=
order-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4=
.8pt;margin-right:0cm">
<p class=3D"MsoNormal" style=3D"margin-left:36pt">If but anyone had warned =
of this outcome before.<u></u><u></u></p>
</blockquote>
</div>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36pt"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36pt">If you&#39;re worried abo=
ut IPv6 address space running out, you might want to have a look at the ori=
ginal IPv6 proposal in RFC 8507, which proposed a 64 bit address space.<u><=
/u><u></u></p>
</div>
</div>
</div>
</blockquote>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36pt"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36pt">There&#39;s no need to lo=
ok at history here. We can just observe that all cellular networks assign t=
wo or more /64s to every device by default, all the time. That is the indus=
try standard and was strongly argued for
 by the IETF when mobile operators originally designed the standards to ass=
ign only a single /128 per device.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36pt"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36pt">Why RIPE would have a pol=
icy that allows cellular networks to provide multiple /64s per device but d=
oesn&#39;t allow, say, enterprise networks to do the same seems somewhat ar=
bitrary and unfair. After all, both of
 these are IETF-standard deployment models.<u></u><u></u></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt"><u></u>=C2=A0<u></u><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt">Well, =E2=80=9CRIPE=
=E2=80=9D is just a community of people, that could redefine/clarify that p=
olicy to reflect modern reality.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt"><u></u>=C2=A0<u></u><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt">As an NREN advocating=
 campuses deploy IPv6, we have to justify giving more than a /48 to an orga=
nisation, and if DHCP-PD isn=E2=80=99t acceptable then those organisations =
will need to look at LIR status.=C2=A0 That=E2=80=99s not
 currently an expensive proposition, in the grand scheme of university fina=
nces.=C2=A0 An NREN can route such LIR space alongside assignments from its=
 own space, as we do.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt"><u></u>=C2=A0<u></u><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt">Tim<u></u><u></u></sp=
an></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>

</div></blockquote></div>

--0000000000000bd995063f0055b2--


--===============5609888950502499506==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGhjd2cgbWFp
bGluZyBsaXN0IC0tIGRoY3dnQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZGhjd2ctbGVhdmVAaWV0Zi5vcmcK

--===============5609888950502499506==--