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

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