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

I’m also not in favor of this idea.

Note that RFC3633 had:

Upon the receipt of a valid Reply message, for each IA_PD the
requesting router assigns a subnet from each of the delegated
prefixes to each of the links to which the associated interfaces are
attached, with the following exception: the requesting router MUST
NOT assign any delegated prefixes or subnets from the delegated
prefix(es) to the link through which it received the DHCP message
from the delegating router.

Though this seems to have been lost somewhere along the way as didn’t find this restriction mentioned in the 8415bis work. Might be something to think about adding into section 18.2.10.1 in draft-ietf-dhc-rfc8415bis-12, though perhaps there was a reason for removing this text sometime in the past that I don’t recall?

Anyway, the PD assigned isn’t for use on the link on which the traffic to assign it was done, so it would be kind of weird to use an address from it.

- Bernie

On Jul 4, 2025, at 9:12 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 , 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 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

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

HTMLized: https://datatracker.ietf.org/doc/html/draft-nygren-dhc-recommended-ipv6-address

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

Status: https://datatracker.ietf.org/doc/draft-nygren-dhc-recommended-ipv6-address/

HTML: https://www.ietf.org/archive/id/draft-nygren-dhc-recommended-ipv6-address-00.html

HTMLized: https://datatracker.ietf.org/doc/html/draft-nygren-dhc-recommended-ipv6-address

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]

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