Re: DHCP v6 for IPv4 Delegated prefrefix - Wan IPv6 Only to be routed with RFC8950

[Douglas Fischer via NANOG <nanog () 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.
>
> 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/


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/NDRAO6K6XWCZAGJ4Y22CLY6Q62QH4TYI/