[v6ops] Re: I-D Action: draft-palet-v6ops-prefix-assignment-00.txt

[Daryll Swer <[e-mail]>]

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=2153471>


On Mon, 27 Oct 2025 at 10:11, Brian E Carpenter <[e-mail]>
wrote:

> Hi Jordi,
>
> A few initial comments:
>
> >  3.2. Prefix Size Choices
> >
> > [RFC7608] already discusses about the IPv6 prefix length recommendations
> for forwarding, and the need for routing and forwarding implementations to
> 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 /128.
>
>
> >  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) are
> required to be 64 bits long and to be constructed in Modified EUI-64 format.
>
> 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" == "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 are
> 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 remember
> and handle the interfaces, but provides an additional degree of protection
> 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ā mihi
>     Brian Carpenter
>
> On 20-Oct-25 10:48, [e-mail] 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, their
> >     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=2153471>
> >
> > 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=2153471>
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>