Because this is exactly what I DON'T WANT! I don't want to create another dependency between the Portal/OSS/BSS layer, and the Network itself (Dataplane/Controlplane/ManagementPlane). All the ISPs that I work for have mentioned the interaction between these two worlds as the biggest pain... And we are talking only about the ISP network interaction with ISP Portal/CRM/Billing/OSS/BSS. Depending on an extra integration outside the native network protocols is exactly what I want to avoid. My idea is to solve it only inside the protocols. The furthest I got was creating a static text page, generated by Jinja, which contained configuration examples, and delivering that link via DHCP option. I think I'll revisit that idea. And look for a SAFI that I can also send a URL to the other side via BGP. Em seg., 10 de nov. de 2025 às 08:35, Vasilenko Eduard < vasilenko.eduard@huawei.com> escreveu:
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.
-----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
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
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
Of course, many of them would still ask questions, but they would ask questions anyway... you could not teach the whole market. Ed/ purchase possible on the
clients.
-- Douglas Fernando Fischer Engº de Controle e Automação _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/U2N3E4
5IHKCTMBKQ2BR5WQ7LTBQA5HOW/
-- Douglas Fernando Fischer Engº de Controle e Automação