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

Erik

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,

IA_NA pool /64 per customer. Each customer has their VNI, the VNI contains
their N number of VMs, for which each VM gets a /128 ia_na on the WAN
interface of the VM. Honestly nothing wasteful and not bad at all.

For ia_pd, I'd prefer /48 parent aggregate per customerID by default, out
of which, /56 ia_pd per VM. If you argue wasteful-ness, can also do /60 and
potentially /64 with smaller parent aggregate such as /50 etc.

 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.

I'd assume your cloud-init/pre-packaged VM images have DHCPv6 client
configuration in place to accept both ia_na and ia_pd, I don't see this
being a problem.

If the customer prefers custom VMs (something I've done on CSP for my own
VM use), you can always have a FAQ ready and point them to it.

some environments such as managed K8s with the Cilium CNI which does
> support a routed mode.

Can you share some public documentation on how this works? True NAT-Less
IPv6 with BGP-based load balancing across N nodes, I'm assuming. May also
help others here who are interested in this discussion for the draft to
sort out their views.

It's also possible to not use ia_pd nor BGP on customer host at all. With
ExaBGP we can inject routes where next-hop = ia_na's next hop for the
routed prefix (/64 or /60 or /56). This may also provide improved behaviour
for live VM migration, where next hypervisor has new ExaBGP route with new
next-hop. Old Hypervisor would then no longer advertise the route.

 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.

This requires more extensive discussion (v6ops appears to be the correct
place as this is intended for operations), and I'm in favour and if
possible, help out on an IPv6 Addressing Architecture recommendation/guide
for Cloud Service Provider networks draft. The main goal being:
1. NAT-less IPv6 end-to-end, overlay and underlay and customer facing
interfaces.
2. Supports K8s/Docker at scale (Anycast included)
3. The addressing mechanism must be easily scalable (I'm biased towards
BGP, BGP to the underlying HV host, BGP even to the VM but likely not
viable so ExaBGP could be nice)

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://l.shortlink.es/l/21a9b6e39080ff029fe960b1e93e22fb22f58475?u=2153471>


On Fri, 4 Jul 2025 at 21:23, Erik Nygren <[email protected]> wrote:

> 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]