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

I agree that this *could* be accomplished by a /63 with a /64 for IA_PD and
a /128 from the other /64 for IA_NA, but this is "wasteful".  In the big
scheme of things it is not super-wasteful, but it is unnecessary in some
environments such as managed K8s with the Cilium CNI which does support a
routed mode.  It will also not help for clients which only implement IA_PD
and not IA_NA where this approach would yield the desired result but while
addressing the concern(s) which prevent those clients from implementing
IA_NA.

Your tangent is quite relevant here -- my motivating goal is for enabling
standards-based IPv6 auto-configuration for cloud service for NAT-less IPv6
environments that give customers the ability to both get an "IPv6 address"
while also being able to use Docker/K8s in a routed mode. Configuring the
prefixes for Docker/K8s *within* the /64 is less interesting as that can
typically be handled by automation/IPAM after the initial host/node IP is
available and reachable, as well as once the /64 prefix to the host/node is
routed. This topic may be worth its own drafts (in v6ops?) with options and
recommendations as there isn't good consistency, standardization, or
standards-based approaches across cloud service providers today.

    Erik


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

> 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
>
> Yes, I'm familiar with this method. I agree, using SLAAC for stateful
> addressing isn't ideal, and I never understood why SLAAC was/is pushed so
> hard in the industry for places where it makes no sense (besides a home
> network and non-production environments).
>
> "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" }
>
> Based on your description, I'd think the ideal solution to be, is
> standard, separate ia_na, separate ia_pd, static for both (with
> RADIUS/IPAM/Automation).
>
> 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:
>>
> So as far as non-IPv6-savvy end-users are concerned, it'll look like this:
> { "host_prefix": “2001:db8:0:1::/64”, "host_ip": “2001:db8::1” }
>
> So the non-savvy user goes like this: “Oh okay, 2001:db8:0:1::/64 or
> smaller self-subnetted /80s is what goes into my docker compose config or
> K8s config, and my host's public IP is 2001:db8::1 for MGMT/SSH etc”.
>
> They do not need to know about 2001:db8::/64 as that's on your-end
> underlying network infra, and they only need to know about 2001:db8::1/128.
>
> Regarding RIB/FIB, shouldn't be an issue with hierarchical aggregation
> with a proper subnet plan as mentioned earlier, your network routing table
> *shouldn't* be flooded with /128s or /63-/64s all over the place.
>
> Off on a tangent, but likely related strongly to the use case we're
> discussing, if the use case is multi-node Docker/K8s, there may be concerns
> for how IPv6 prefix delegation would look like, if for example the customer
> wants Anycast routing of their public-facing Docker containers/K8s pods
> without involvement of NAT66 (DNAT etc), my understanding with K8s CNIs is
> normally, they don't support “routed” mode (Like Docker latest version does
> aka NAT-less IPv6) and rely on DNAT, but I can be wrong, and possibly you
> already have a solution for this. As we are discussing on ensuring native
> (NAT-less) IPv6 for customers of a cloud service provider network.
>
> *--*
> Best Regards
> Daryll Swer
> Website: daryllswer.com
> <https://l.shortlink.es/l/71936e1feb4da06a5334d5d7b0a67f4a1a05af4b?u=2153471>
>
>
> On Fri, 4 Jul 2025 at 20:01, Erik Nygren <[email protected]> wrote:
>
>> 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]