[dhcwg] Re: [v6ops] New draft: DHCPv6 Recommended IPv6 Address Option

Just to clarify, this isn't for the router-side but rather for the
host-side and is not trying to reduce the block available for usage.
I agree that the router side in this scenario should be using unnumbered.

The specific motivating use-case for a cloud service provider is for
assisting their customers in configuring hosts (VM or bare metal) for the
default/common case.  In that case, we'd like to give every customer host a
/64. Most customers also still want/need to select a bootstrap /128 to show
up on that host which they can use to ssh into it and otherwise connect to
it.  One way to do this (which some cloud providers do) is to disable
privacy addressing and configure a MAC address and then you can infer a
SLAAC address that will get constructed, but this is gross in a bunch of
ways.

As a cloud service provider operator, I'd like my customers to be able to
say, including with a good default for the less IPv6 savvy that just works
as well as for managed kubernetes services that just works:

"Give VMs/Nodes/Hosts a /64 each.  Have them use the ::4 address as one of
their addresses."
Once VMs are provisioned, the response would be something like:
{ "host_prefix": "2001:db8:abcd::/64", "host_ip": "2001:db8:abcd::4" }

They'd still be free to disable this (if they wanted to use SLAAC or some
other mechanism) and/or to use a /80 or whatever as the Docker routed
subnet. Given this would be under customer control they could pick this in
a way to not be in the space they'd use for Docker, Pod networking, etc
(which is typically much smaller than a /64).

But users do seem to want both a prefix and an IP --- switching from a
world where today they get an IPv4 /32 and an IPv6 /128 per interface to no
longer having any IPv6 /128 and needing to figure it out on their own is
confusing for most users.

Another way to do this could be to split some of this out and have a way to
specify the ::4 as a tag in cloud-init, but that seems more fragile and
less generally useful.

Thanks for the feedback and input.

Best, Erik






On Fri, Jul 4, 2025 at 9:11 AM Daryll Swer <[email protected]> wrote:

> Hi Erik
>
> I would be against the idea of insistingly treating DHCPv6 like a routing
> protocol. We already have the 'issue' with DHCPv6 HA
> <https://blogs.infoblox.com/ipv6-coe/high-availability-dhcpv6/>, across
> vendor inter-op, let alone trying to get network operators to do static
> ia_pd to begin with, and if the use-case is DC fabrics then, BGP
> unnumbered <https://blog.widodh.nl/2022/03/proxmox-with-bgpevpnvxlan/> to
> the host from leaf switch is far simpler and more scalable. Route a /128 to
> the host over BGP for loopback, route additional /64 (or aggregate /56, for
> /64 routed, per VM for a total of 256 VMs) for Docker (etc) use. The /128s
> won't pollute the internal table, as they would be aggregated to a much
> larger block (depending on your subnetting model) before being advertised
> from leaves back to the spines.
>
> Using both IA_PD and IA_NA separately could also meet this use-case, but
>> would require multiple FIB entries or would effectively mean assigning a
>> /63 per host.
>
> With a properly planned subnetting model, internal route table should be
> minimise-able with hierarchical aggregation of routes, so routes exported
> from Leaf to Spine wouldn't necessarily be hundreds or thousands of /128s
> or /64s, but larger single parent prefixes like /50 or /48 etc.
>
> while DHCPv6-PD also means that the host is free to use the rest of the
>> /64 for its own purposes
>
> Please correct me if I'm wrong, but my understanding is, If I was to have
> a single /64 routed to a host over ia_pd or BGP and I picked a /128 out of
> that /64 for my loopback, that breaks the “Contiguousness” of the /64,
> meaning, if the /64 is 2001:db8::/64, pick a /128 out of that, I can no
> longer configure the contiguous block of /64 on my Docker compose like
> *below*, because there's a chance, my containers may get a random /128
> that matches the /128 I picked out from for my loopback. Now, routing wise
> the concept would work as /128 is more specific than /64, but this seems
> less than ideal to me, as the risk of collision would exist.
>
> Docker *Routed* IPv6 config reference example:
>
>
>
>
>
>
>
>
>
>
> *networks:  ipv6_native:    driver: bridge    driver_opts:
> com.docker.network.bridge.gateway_mode_ipv6: "routed"    enable_ipv6: true
>   ipam:      driver: default      config:        - subnet: 2001:db8::/64
>       gateway: 2001:db8::1*
>
> If I'm paying my Cloud Service Provider for a bare-metal host or VM, I
> expect a full contiguous block for my use.
>
> *--*
> Best Regards
> Daryll Swer
> Website: daryllswer.com <https://www.daryllswer.com>
>
>
> On Fri, 4 Jul 2025 at 01:15, Erik Nygren <[email protected]> wrote:
>
>> Following some discussions at past IETFs, I've created a -00 draft for a
>> new "DHCPv6 Recommended IPv6 Address Option".
>> Abstract:
>>
>>    This document defines a new DHCPv6 option for communicating one or
>>    more recommended /128 IPv6 address to hosts within an assigned
>>    prefix.  The Recommended Address option allows DHCPv6 servers to
>>    suggest specific IPv6 addresses that hosts should additionally use
>>    when configuring addresses within the assigned prefix.
>>
>> Github:
>> https://github.com/enygren/draft-nygren-dhc-recommended-ipv6-address
>> <https://l.shortlink.es/l/a60725f6acf18932ea630a2c1f459c8afd617ede?u=2153471>
>>
>> HTMLized:
>> https://datatracker.ietf.org/doc/html/draft-nygren-dhc-recommended-ipv6-address
>> <https://l.shortlink.es/l/c673ae8b5079168f9584c8fa1262a15a328b6f38?u=2153471>
>>
>> The primary use-case for this is hosting, datacenter, and cloud
>> environments that want to assign a /64 per host but which also want to
>> ensure the host configures one or more addresses (such as for management
>> and running services).  Operators configuring servers in these environments
>> want to be able to ensure that a host will be available on a given /128
>> (for ssh'ing into, putting into DNS as a service endpoint, etc) while
>> DHCPv6-PD also means that the host is free to use the rest of the /64 for
>> its own purposes (eg, containers, K8s pods, temporary addresses, etc).
>>
>> Using both IA_PD and IA_NA separately could also meet this use-case, but
>> would require multiple FIB entries or would effectively mean assigning a
>> /63 per host.  Using PD_EXCLUDE and then IA_NA within the PD_EXCLUDE prefix
>> was another alternative, but seems messier, more fragile, and outside my
>> understanding of the intent of PD_EXCLUDE.
>>
>> I'd be happy to discuss in Madrid, either in hallways or presenting to
>> the DHC, v6ops, and/or 6man WG(s) if time is available.  It was suggested
>> that DHC would be the best venue to pursue this draft, but I'm open to
>> alternatives.
>>
>> Best,
>>
>>         Erik
>>
>>
>> ---------- Forwarded message ---------
>> From: <[email protected]>
>> Date: Thu, Jul 3, 2025 at 3:26 PM
>> Subject: New Version Notification for
>> draft-nygren-dhc-recommended-ipv6-address-00.txt
>> To: Erik Nygren <[email protected]>
>>
>>
>> A new version of Internet-Draft
>> draft-nygren-dhc-recommended-ipv6-address-00.txt has been successfully
>> submitted by Erik Nygren and posted to the
>> IETF repository.
>>
>> Name:     draft-nygren-dhc-recommended-ipv6-address
>> Revision: 00
>> Title:    DHCPv6 Recommended IPv6 Address Option
>> Date:     2025-07-03
>> Group:    Individual Submission
>> Pages:    8
>> URL:
>> https://www.ietf.org/archive/id/draft-nygren-dhc-recommended-ipv6-address-00.txt
>> <https://l.shortlink.es/l/7da0b71e99c60e6e44a8c2792b1c118041e9f523?u=2153471>
>> Status:
>> https://datatracker.ietf.org/doc/draft-nygren-dhc-recommended-ipv6-address/
>> <https://l.shortlink.es/l/34537424a18470a583bd6286b5e66c2bac6a077c?u=2153471>
>> HTML:
>> https://www.ietf.org/archive/id/draft-nygren-dhc-recommended-ipv6-address-00.html
>> <https://l.shortlink.es/l/eea1a253f833a155ac459b936073f0d82b6cc5f5?u=2153471>
>> HTMLized:
>> https://datatracker.ietf.org/doc/html/draft-nygren-dhc-recommended-ipv6-address
>> <https://l.shortlink.es/l/bb3749ed616248ddf83b4ccde5399aa0af1c0492?u=2153471>
>>
>>
>> Abstract:
>>
>>    This document defines a new DHCPv6 option for communicating one or
>>    more recommended /128 IPv6 address to hosts within an assigned
>>    prefix.  The Recommended Address option allows DHCPv6 servers to
>>    suggest specific IPv6 addresses that hosts should additionally use
>>    when configuring addresses within the assigned prefix.
>>
>>
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> v6ops mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
>

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]