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
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://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/U2N3E4 5IHKCTMBKQ2BR5WQ7LTBQA5HOW/
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]
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]
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]
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
Hey, Douglas, On Mon, Nov 10, 2025 at 07:52:06AM -0300, Douglas Fischer via NANOG wrote:
[...]
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.
You mean sending delegated prefixes from the DHCPv6 server? I'm very much afraid that the client-side implementations do not expect that, but on the other hand, this is something definitely worth trying and persuading the clients to implement.
I feel there's a good chance I'm reinventing the wheel. And this is already handled in some DHCPv6 options.
I have not found any but I'm not a DHCP expert. So with that, my guess would be to look into at least OpenWRT but also poke CPE device manufacturers about this, because I'm afraid that this is ultimately going to need an implementation anyway, maybe even a draft explicitly specifying that sending an IPv4 prefix inside OPTION_IAPREFIX is actually a thing. Have a nice day! Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
participants (4)
-
Douglas Fischer -
Maria Matejka -
Samaneh Tajalizadehkhoob -
Vasilenko Eduard