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 < [email protected]> 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. > > 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 <[email protected]> > > Sent: Monday, November 10, 2025 13:52 > > To: [email protected] > > Cc: Douglas Fischer <[email protected]> > > 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/[email protected]/message/U2N3E4 > > 5IHKCTMBKQ2BR5WQ7LTBQA5HOW/ > -- Douglas Fernando Fischer Engº de Controle e Automação _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/NDRAO6K6XWCZAGJ4Y22CLY6Q62QH4TYI/
