I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:06 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 1:05 PM, Samaneh Tajalizadehkhoob via NANOG <nanog@lists.nanog.org> wrote: I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 10, 2025, at 12:35 PM, Vasilenko Eduard via NANOG <nanog@lists.nanog.org> wrote: Hi Douglas, You probably have the portal (that probably connected to the billing system). Why not to put the statement "This IPv4 block is delegated to you, and you use it as you see fit... And the default IPv4 route is the same IP as the default IPv6 route" On their "personal account" (or whatever you call their personal page)? It should resolve the address delivery problem. Of course, many of them would still ask questions, but they would ask questions anyway... you could not teach the whole market. Ed/ -----Original Message----- From: Douglas Fischer via NANOG <nanog@lists.nanog.org> Sent: Monday, November 10, 2025 13:52 To: nanog@lists.nanog.org Cc: Douglas Fischer <fischerdouglas@gmail.com> Subject: DHCP v6 for IPv4 Delegated prefrefix - Wan IPv6 Only to be routed with RFC8950 Trying to stay focused on IPv4 as a Service... I dream of being able to build a backbone that is truly IPv6 Only! But even taking some steps in 464xlat environments, there are still commercial demands that still impose the use of Dual-Stack. This is the case with clients who require (and pay for) a routed IPv4 address. I've been looking for a solution for some time to deliver a routed IPv4 address to the client, and to do so in a way that doesn't depend on exchanging information via email and similar means to let the client know which IPv4 block to use. Note 1: Almost all are business subscribers, and 95% of the time they purchase the delivery of an IPv4 /32 address as a service. In cases where we had access to the device, we frequently used DHCP IPv4 Option 121, pointing the routed block (/32, /31, or even /29) with the next- hop of the route pointing to the same IP address on the subscriber's side of the /30 link network with private IPs. The complex part is that the subscriber's "IT Guy" needs to have a minimum understanding of networking and know that they have to use those IPs as needed. In most cases, this is done in a loopback network, to be used as a VPN endpoint, for NAT... And in very rare cases, routed to the client's internal network to be used as a loopback for servers and similar things. We even developed some JerryRig scripts to retrieve this route information taught via DHCP IPv4 Option 121 and "semi-automate" the use of these IPs in loopbacks in address lists to facilitate client use. But this is only possible on CPEs where scripting is allowed, and even then it's a big challenge to handle multiple NOS on CPEs. My current goal is to find a way to deliver an IPv4 prefix to the subscriber and tell it, "This IPv4 block is delegated to you, and you use it as you see fit... And the default IPv4 route is the same IP as the default IPv6 route." Note2: I tried doing this with the 6PE format 0:0:0:0:0:ffff:IPv4_Block. But I haven't had success with common CPEs. I feel there's a good chance I'm reinventing the wheel. And this is already handled in some DHCPv6 options. And that's precisely why I'm asking my colleagues here if there's already something that can help me. If there isn't... Trying to keep the focus on IPv4 as a Service... Would it be too much to dream of setting something like that up? Note 3: I even considered JerryRiging the JerryRig. That would be a way to "teach via DHCPv6" that these clients have to establish a BGP session over IPv6 with IPv4 and IPv6 Address-Families. But I didn't see that this would help much in putting IPv4 in the loopback of the CPEs. So I left that aside. Any colleagues with suggestions on how to solve this type of problem? P.S.: Unfortunately, my customer base is still far from being able to do without IPv4. And handling things within the client's network IS NOT AN OPTION! Just like "464XLAT 1:1" isn't an option either due to the specific demands of the clients. -- Douglas Fernando Fischer Engº de Controle e Automação _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] 5IHKCTMBKQ2BR5WQ7LTBQA5HOW/ _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org] _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list... [lists[.]nanog[.]org]