Re: IPv4 flag day

["Aaron C. de Bruyn via NANOG" <nanog () lists nanog org>]

Oops--I did confuse them.
Apologies.

Time to buy another batch of 800-page IPv6 tomes to put on a shelf and
eventually read.
I guess I'm the reason we haven't switched to IPv6 yet. ;)

-A


On Fri, Jun 19, 2026 at 1:48 PM Gary Sparkes <gary () kisaracorporation com>
wrote:

> ULA is the equivalent of RFC1918, effectively. FC00::/7
>
>
>
> You’re thinking of link-local addresses which are the fe80 addresses.
> Those are autogenerated. ULA is assigned however you want – SLAAC, DHCPv6,
> static, etc…. RFC1918 equivalent.
>
>
>
> Nominally, you’d almost never think about link-local.
>
>
>
> You essentially have all of fc00::/7 to utilize as you wish.
>
>
>
> So, for you, I suppose, you could do FC00:0:22:XXXX::/64
>
>
>
> 22nd state, XXXX being vlan ID or some other identifier or whatever you
> want (servers could be FC00:0:22:1::/64 and workstations FC00:0:22:2::/64
> and so on – feel free to be creative! You have FC00::/32 through
> FC00:3E8::/32 to play around in! With /48’s I like to do
> PRE:FIX:HERE:VLANID::/64)
>
>
>
> Including the office number, so you could do FC00:22:0:1 (the 0 between
> the 22 and 1 is the office number, second the network/vlan identifier,
> whatever – you can be creative and as long or compact as you want here).
>
>
>
> So let’s say you have FC00:22:0:1::1 – okay, that’s a router!
> FC00:22:0:2:SLAA:CASS:IGNE:DAUTOCONF – sweet that’s a workstation (SLAAC
> for simplicity sake, DHCPv6 can also be an option, but a bit more to
> configure/maintain). FC00:22:0:1::250 – that’s the linux server!
>
>
>
> Okay, so now your linux server is FC00:22:0:1::250, still simple enough.
> And any firewall logs with that info will immediately tell you right where
> it is and what network it’s on, etc.
>
>
>
> Then with NPT, you’re mapping provider prefix aaand you’re right where you
> were with V4, including needing to update DNS in failover.
>
>
>
> Now you just change the provider prefix portion instead of the whole IP
> address. The ::250 will stay the same on either provider externally. NPT
> will just convert say, 1234:5678:1234:5678::/64 to FC00:22:0:1::/64 at the
> edge, and vice versa. So your linux server would be 1234:5678:1234:5678::250
>
>
>
> You never want to hardcode link-local addressing, that’s all entirely
> autonomous and is used for a variety of things, but that’s out of scope
> here.
>
>
>
>
>
> *From:* Aaron C. de Bruyn <aaron () heyaaron com>
> *Sent:* Friday, June 19, 2026 4:24 PM
> *To:* Gary Sparkes <gary () kisaracorporation com>
> *Cc:* North American Network Operators Group <nanog () lists nanog org>;
> Marco Moock <mm () dorfdsl de>
> *Subject:* Re: IPv4 flag day
>
>
>
> On Fri, Jun 19, 2026 at 1:03 PM Gary Sparkes <gary () kisaracorporation com>
> wrote:
>
> The clean path would be NPTv6 with ULA for the same exact setup.
>
> It would slot in and work identically to how the IPv4 deployment is today.
>
> Instead of RFC1918, you have ULA addressing. Same concept.
>
> Except with NPTv6 you're doing 1:1 and eliminate PAT.
>
> Of course, if you're single provider, might as well just use prefix
> delegation, NPT's real shine is the multi-WAN scenario with no upstream
> routing protocol that sparked off a lot of discussion.
>
> As to changing providers when using prefix delegation, most stuff can
> auto-update itself, but otherwise it's a simple find/replace exercise in
> documentation and records when your provider prefix changes as the last
> half of the address is entirely stable, and the first half is (mostly)
> provider.
>
>
>
> Maybe I need to do a bit more digging as I'm not an expert at IPv6--but
> aren't ULA addresses basically randomly assigned to hosts based on their
> NIC HW address and a few other things?
>
>
>
> A short example from a very large client I manage:
>
> They use IPv4 10/8
>
> The next octet is allocated for the state the office is located in "plus
> 100".  So if they open an office in Alabama (22nd state to join the union),
> it's gonna be 10.122/16.
>
> The third octet is assigned sequentially.  The first office opened in
> Alabama is 10.122.0.0/24.
>
> The last octet is static.  Router at .254, linux server at .250, Windows
> (ugh) RDP server at .249, workstations are DHCP between .100 and .199,
> etc...
>
>
>
> You can give me nearly any IP from this client and I know the device.
>
> But ULA gives me: fe80::ae1f:6bff:feb0:3c98/64
>
>
>
> What even is that?  Their router?  A Windows box?
>
>
>
> Hard-code the address to fe80::122:00000:250/64 (just to know it's a linux
> server in Alabama) and then set up NPTv6...and update a *ton* of DNS info
> so the rest of the world can easily get to the correct machines?
>
>
>
> Again, I'm having to renumber somewhere--either update a bunch of DNS or
> update a bunch of internal machines when I change ISPs or have a fail-over.
>
>
>
> At least that's what it always seemed like to me after going through all
> the 800-page IPv6 tomes over the years. ;)
>
>
>
> -A
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/RUN3LBYYAY77TYVEMVM6M4456E72YF2C/