MIME-Version: 1.0
References: 
 <176091053564.1982765.8763055214756116141@dt-datatracker-84f8f646b-tg6mn>
 <aee85e4d-d5da-4bc7-9a6a-debe6be9db59@gmail.com>
In-Reply-To: <aee85e4d-d5da-4bc7-9a6a-debe6be9db59@gmail.com>
From: Daryll Swer <contact@daryllswer.com>
Date: Mon, 27 Oct 2025 10:58:14 +0530
Message-ID: 
 <CACyFTPFhsAm-SF_v519SPEPgt7XoNFd-p3E75o=MhT5B+8+g+Q@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ab29fc06421d2c62"
Message-ID-Hash: LEDV64UODTEGW5AXIONB6ZTHZFVL2GAW
CC: IPv6 Operations <v6ops@ietf.org>,
 JORDI PALET MARTINEZ <jordi.palet@theipv6company.com>
Precedence: list
Subject: =?utf-8?q?=5Bv6ops=5D_Re=3A_I-D_Action=3A_draft-palet-v6ops-prefix-assignmen?=
	=?utf-8?q?t-00=2Etxt?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/v6ops/4EbHrW6ag4RRXPSUVFLUBzDRBkc>

--000000000000ab29fc06421d2c62
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Brian

I haven't read the draft yet, but have a small point to make.

I really don't understand why you mention EUI-64 in 2025. Surely we would
> now recommend pseudo-random IIDs everywhere per RFC 7217/8064. (I realise
> those RFCs assume SLAAC is generating the identifier, but EUI-64 also
> assumes SLAAC.)
>
EUI-64 *should *(MUST even) be discouraged from being used on endpoints
(PCs, Phones, IoT devices etc).

However, EUI-64 is widely used in DC networks for Out-of-Band IPv6 access
over IPMI (or equivalent) where the server box's MGMT port generates an
IPv6 address using SLAAC (which in turn runs on a dedicated OOB infra) and
finally, we use basic bash/python script to map MAC addresses of the
server's MGMT MAC (was in turn was injected into an inventory tracking
software of sorts, like Netbox) to our /64 SLAAC prefix, to derive the
/128, this /128 is then injected into the company's software pipeline for
automation/DNS etc.

DHCPv6 ia_na to my knowledge is not widely supported yet for OOB on servers
and equivalent devices that have dedicated bypass path to the CPU for
management. SLAAC+EUI-64 is preferred for OOB on such devices.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://l.mailtrack.com/l/2ecb03219b71ed55fd1847b0e9bdbd8c6fab5e16?u=3D215=
3471>


On Mon, 27 Oct 2025 at 10:11, Brian E Carpenter <brian.e.carpenter@gmail.co=
m>
wrote:

> Hi Jordi,
>
> A few initial comments:
>
> >  3.2. Prefix Size Choices
> >
> > [RFC7608] already discusses about the IPv6 prefix length recommendation=
s
> for forwarding, and the need for routing and forwarding implementations t=
o
> ensure that longest-prefix-match works on any prefix length.
>
> I think it's worth being 100% clear:
>
> ... ensure that longest-prefix-match works on any prefix length up to /12=
8.
>
>
> >  3.2.1. Rationale for using /64
> >
> > The IPv6 Addressing Architecture ([RFC4291]) specifies that all the
> Interface Identifiers for all the unicast addresses (except for 000/3) ar=
e
> required to be 64 bits long and to be constructed in Modified EUI-64 form=
at.
>
> The IPv6 Addressing Architecture actually consists of RFC 4291 as updated
> by RFC 5952, 6052, 7136, 7346, 7371 and 8064. One of those (section 5 of
> RFC 7136) removes the EUI-64 requirement, which is only of historical
> interest.
>
> >  3.3.1. GUA (Global Unicast Addresses)
> >
> > Using GUA is the most common approach. It provides full functionality
> for both end-points of the point-to-point link and consequently,
> facilitates troubleshooting, so it is the recommended approach.
>
> Please write it out in full "Globally Reachable Unicast Addresses" to
> match the terminology defined in RFC 8190 and used in the IANA registry
> [1]. This is important because according to the addressing architecture
> ULAs have global scope, but they are not globally reachable. (Yes, it's
> bizarre; in effect "global scope" =3D=3D "routable".)
>
> In the ULA (and LLA) sections 3.3.2 and 3.3.3, you might mention that
> traceroutes with ULA and link-local segments are not unusual, but they ar=
e
> confusing for the user and might even give out information that is
> considered a security risk.
>
> >  3.4.2.1. Numbering Interfaces
> ...
> > On the other hand, using the EUI-64, makes it more difficult to remembe=
r
> and handle the interfaces, but provides an additional degree of protectio=
n
> against port (actually address) scanning as described at [RFC7707].
>
> I really don't understand why you mention EUI-64 in 2025. Surely we would
> now recommend pseudo-random IIDs everywhere per RFC 7217/8064. (I realise
> those RFCs assume SLAAC is generating the identifier, but EUI-64 also
> assumes SLAAC.)
>
> I'm very sympathetic to the arguments made in sections 4-6, but I suspect
> the text will need a lot of editing to make it completely objective and
> avoid anything that looks like personal opinion.
>
> Regards/Ng=C4=81 mihi
>     Brian Carpenter
>
> On 20-Oct-25 10:48, internet-drafts@ietf.org wrote:
> > Internet-Draft draft-palet-v6ops-prefix-assignment-00.txt is now
> available.
> >
> >     Title:   IPv6 Prefix Assignment to end-users
> >     Author:  Jordi Palet Martinez
> >     Name:    draft-palet-v6ops-prefix-assignment-00.txt
> >     Pages:   27
> >     Dates:   2025-10-19
> >
> > Abstract:
> >
> >     This document describes different alternatives and best current
> >     practices for assignment of IPv6 prefixes for end-user broadband
> >     networks, including considerations about point-to-point links, thei=
r
> >     size, numbering choices, pool choices, customer prefix assignment
> >     size and persistance of those assignments.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-palet-v6ops-prefix-assignment/
> <https://l.mailtrack.com/l/7007dc686944954ecaf34a5f4ade965243c19748?u=3D2=
153471>
> >
> > There is also an HTMLized version available at:
> >
> https://datatracker.ietf.org/doc/html/draft-palet-v6ops-prefix-assignment=
-00
> <https://l.mailtrack.com/l/c879bea132506ce15814ed96ccc50aa82ef4dfb4?u=3D2=
153471>
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list -- i-d-announce@ietf.org
> > To unsubscribe send an email to i-d-announce-leave@ietf.org
> _______________________________________________
> v6ops mailing list -- v6ops@ietf.org
> To unsubscribe send an email to v6ops-leave@ietf.org
>

--000000000000ab29fc06421d2c62
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><img width=3D"0" height=3D"0" class=3D"mailtrack-img" alt=
=3D"" style=3D"display:flex" src=3D"https://mailtrack.io/trace/mail/dca1faa=
8ac89c26e396ba8bfce12403f8fa253c2.png?u=3D2153471"><div dir=3D"ltr"><div>Br=
ian</div><div><br></div><div>I haven&#39;t read the draft yet, but have a s=
mall point to make.</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">I really don&#39;t understand why you mention EUI-64 in 2025=
. Surely we would now recommend pseudo-random IIDs everywhere per RFC 7217/=
8064. (I realise those RFCs assume SLAAC is generating the identifier, but =
EUI-64 also assumes SLAAC.)<br></blockquote><div>EUI-64 <b>should </b>(MUST=
 even)<b>=C2=A0</b>be discouraged from being used on endpoints (PCs, Phones=
, IoT devices etc).</div><div><br></div><div>However, EUI-64 is widely used=
 in DC networks for Out-of-Band IPv6 access over IPMI (or equivalent) where=
 the server box&#39;s MGMT port generates an IPv6 address using SLAAC (whic=
h in turn runs on a dedicated OOB infra) and finally, we use basic bash/pyt=
hon script to map MAC addresses of the server&#39;s MGMT MAC (was in turn w=
as injected into an inventory tracking software of sorts, like Netbox) to o=
ur /64 SLAAC prefix, to derive the /128, this /128 is then injected into th=
e company&#39;s software pipeline for automation/DNS etc.</div><div><br></d=
iv><div>DHCPv6 ia_na to my knowledge is not widely supported yet for OOB on=
 servers and equivalent devices that have dedicated bypass path to the CPU =
for management. SLAAC+EUI-64 is preferred for OOB on such devices.</div><di=
v><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><font color=
=3D"#000000" face=3D"arial, sans-serif"><br><b>--</b><br></font><div><font =
color=3D"#000000" face=3D"arial, sans-serif">Best Regards</font></div><div>=
<font color=3D"#000000" face=3D"arial, sans-serif">Daryll Swer</font></div>=
<div><font color=3D"#000000" face=3D"arial, sans-serif">Website: <a href=3D=
"https://l.mailtrack.com/l/2ecb03219b71ed55fd1847b0e9bdbd8c6fab5e16?u=3D215=
3471" target=3D"_blank">daryllswer.com</a></font></div></div></div></div><b=
r></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"lt=
r" class=3D"gmail_attr">On Mon, 27 Oct 2025 at 10:11, Brian E Carpenter &lt=
;<a href=3D"mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
Hi Jordi,<br>
<br>
A few initial comments:<br>
<br>
&gt;=C2=A0 3.2. Prefix Size Choices<br>
&gt; <br>
&gt; [RFC7608] already discusses about the IPv6 prefix length recommendatio=
ns for forwarding, and the need for routing and forwarding implementations =
to ensure that longest-prefix-match works on any prefix length.<br>
<br>
I think it&#39;s worth being 100% clear:<br>
<br>
... ensure that longest-prefix-match works on any prefix length up to /128.=
<br>
<br>
<br>
&gt;=C2=A0 3.2.1. Rationale for using /64<br>
&gt; <br>
&gt; The IPv6 Addressing Architecture ([RFC4291]) specifies that all the In=
terface Identifiers for all the unicast addresses (except for 000/3) are re=
quired to be 64 bits long and to be constructed in Modified EUI-64 format.<=
br>
<br>
The IPv6 Addressing Architecture actually consists of RFC 4291 as updated b=
y RFC 5952, 6052, 7136, 7346, 7371 and 8064. One of those (section 5 of RFC=
 7136) removes the EUI-64 requirement, which is only of historical interest=
.<br>
<br>
&gt;=C2=A0 3.3.1. GUA (Global Unicast Addresses)<br>
&gt; <br>
&gt; Using GUA is the most common approach. It provides full functionality =
for both end-points of the point-to-point link and consequently, facilitate=
s troubleshooting, so it is the recommended approach.<br>
<br>
Please write it out in full &quot;Globally Reachable Unicast Addresses&quot=
; to match the terminology defined in RFC 8190 and used in the IANA registr=
y [1]. This is important because according to the addressing architecture U=
LAs have global scope, but they are not globally reachable. (Yes, it&#39;s =
bizarre; in effect &quot;global scope&quot; =3D=3D &quot;routable&quot;.)<b=
r>
<br>
In the ULA (and LLA) sections 3.3.2 and 3.3.3, you might mention that trace=
routes with ULA and link-local segments are not unusual, but they are confu=
sing for the user and might even give out information that is considered a =
security risk.<br>
<br>
&gt;=C2=A0 3.4.2.1. Numbering Interfaces<br>
...<br>
&gt; On the other hand, using the EUI-64, makes it more difficult to rememb=
er and handle the interfaces, but provides an additional degree of protecti=
on against port (actually address) scanning as described at [RFC7707].<br>
<br>
I really don&#39;t understand why you mention EUI-64 in 2025. Surely we wou=
ld now recommend pseudo-random IIDs everywhere per RFC 7217/8064. (I realis=
e those RFCs assume SLAAC is generating the identifier, but EUI-64 also ass=
umes SLAAC.)<br>
<br>
I&#39;m very sympathetic to the arguments made in sections 4-6, but I suspe=
ct the text will need a lot of editing to make it completely objective and =
avoid anything that looks like personal opinion.<br>
<br>
Regards/Ng=C4=81 mihi<br>
=C2=A0 =C2=A0 Brian Carpenter<br>
<br>
On 20-Oct-25 10:48, <a href=3D"mailto:internet-drafts@ietf.org" target=3D"_=
blank">internet-drafts@ietf.org</a> wrote:<br>
&gt; Internet-Draft draft-palet-v6ops-prefix-assignment-00.txt is now avail=
able.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0IPv6 Prefix Assignment to end-us=
ers<br>
&gt;=C2=A0 =C2=A0 =C2=A0Author:=C2=A0 Jordi Palet Martinez<br>
&gt;=C2=A0 =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 draft-palet-v6ops-prefix-assignm=
ent-00.txt<br>
&gt;=C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A027<br>
&gt;=C2=A0 =C2=A0 =C2=A0Dates:=C2=A0 =C2=A02025-10-19<br>
&gt; <br>
&gt; Abstract:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0This document describes different alternatives and =
best current<br>
&gt;=C2=A0 =C2=A0 =C2=A0practices for assignment of IPv6 prefixes for end-u=
ser broadband<br>
&gt;=C2=A0 =C2=A0 =C2=A0networks, including considerations about point-to-p=
oint links, their<br>
&gt;=C2=A0 =C2=A0 =C2=A0size, numbering choices, pool choices, customer pre=
fix assignment<br>
&gt;=C2=A0 =C2=A0 =C2=A0size and persistance of those assignments.<br>
&gt; <br>
&gt; The IETF datatracker status page for this Internet-Draft is:<br>
&gt; <a href=3D"https://l.mailtrack.com/l/7007dc686944954ecaf34a5f4ade96524=
3c19748?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://datatrack=
er.ietf.org/doc/draft-palet-v6ops-prefix-assignment/</a><br>
&gt; <br>
&gt; There is also an HTMLized version available at:<br>
&gt; <a href=3D"https://l.mailtrack.com/l/c879bea132506ce15814ed96ccc50aa82=
ef4dfb4?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://datatrack=
er.ietf.org/doc/html/draft-palet-v6ops-prefix-assignment-00</a><br>
&gt; <br>
&gt; Internet-Drafts are also available by rsync at:<br>
&gt; rsync.ietf.org::internet-drafts<br>
&gt; <br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; I-D-Announce mailing list -- <a href=3D"mailto:i-d-announce@ietf.org" =
target=3D"_blank">i-d-announce@ietf.org</a><br>
&gt; To unsubscribe send an email to <a href=3D"mailto:i-d-announce-leave@i=
etf.org" target=3D"_blank">i-d-announce-leave@ietf.org</a><br>
_______________________________________________<br>
v6ops mailing list -- <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v=
6ops@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:v6ops-leave@ietf.org" tar=
get=3D"_blank">v6ops-leave@ietf.org</a><br>
</blockquote></div></div>

--000000000000ab29fc06421d2c62--