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

Daryll Swer <[email protected]> Fri, 4 Jul 2025 18:40:54 +0530
Newsgroups gmane.ietf.dhc,gmane.ietf.v6ops,gmane.ietf.ipv6
Message-ID <CACyFTPFBYJ8yv+hJJXF5q3xBaP93KMCbiuaZPJHeOSf0iGOPAg@mail.gmail.com>
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]