Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4

[millerwissen]

Greetings!

This will be my first one and I'm hoping to share this information with everyone because I literally am tired of reading about people not knowing how IPv6 works assuming that you either have only public addresses or nothing, anything outside of ULAs without internet access or public IPv6 = impossible. The worst part is that they use this an excuse not to implement IPv6 in their network but now that's over.

The point of this tutorial will be to change this concept once and for all and hopefully this will change a few things for a lot of people out there. As in I want to plant the final nail in the coffin and answer all the questions once and for all.

If you just want the tutorial skip to the chapter where I talk about this but first an introduction to the scope of the problem. And excuse my rant :)

1 -- Introduction:

NAT44 came to resolve a problem the lack of IPv4 addresses or at least many would assume that at first glance or if you ask the people at IETF about RFC1918 (that is after they regain consciousness from their panic attacks upon you mention that RFC) you will get a lot of angry, dismissive and frowny comments from them about how awful it was and that IPv6 with all public addresses came exactly to address this problem, as in the whole point of IPv6 was to solve the lack of addresses of IPv4.

The reality is that NAT44 brought one major security benefit, your computers can be in a safe internal network without being immediately exposed to the internet or rely on a system firewall which you may/may not have control over it, you also don't have to worry about unencrypted traffic being sniffed by your ISP as in traffic in transit from amongst your internal computers, does it mean NAT is a security feature? Yes and No, the whole point of having an edge and core router is to control and direct traffic with far more horsepower than your phone/fridge/security camera has in terms of routing and firewall but we'll get to that.

The point of NAT is simple, control, your network your rules no one else has the right to force you to design your internal network a certain way, as for security it does provide you with advanced port control where it needs it and by that I mean you can move port 3389 to 12345 for example it does not mean it will filter anything that's the job of the firewall obviously, you can route ports out different uplinks, load balance and just in general have full control, but that means that if you have a machine where having a certain port exposed to the internet will cause it to be compromised by being on an internal network that cannot be reached from the outside it puts you in a position where NAT is your most important security feature in this example, but of course if you were to route that port to a public ip address (v4 or v6 doesn't matter what it is) you would be just as compromised, the key is control.

The people at IETF decided that the common/average IPv6 deployment MUST be public and NAT is evil, and your system must be able to handle security individually (given no network firewall in between such as pfsense) which is a common case with the average people which only have an ISP provided box in their home if you think about it, not everyone out there is even aware of the benefits of having a firewall in their network and can perceive that as an unnecessary expense because 'it just works', but in reality having a firewall is quite important and no i'm not shilling for firewall platforms whether it's opnsense pfsense or any other firewall solution available in specific, regardless whether it's paid or free this applies to any firewall out there that is controlling the traffic from outside to inside.

Ask yourself, do you want or need a public ip address on your smart fridge, your phone, your security camera, your computer even, do you actually NEED it, as it are you actually accessing it's resources directly over the internet (not using an encrypted site-to-site tunnel such as wireguard with static routes/iBGP) do you want a botnet to have the same access to your devices as you do while they constantly try to use common known exploits and even brute force to get into all of your devices while you sleep? Does that sound like a good way to setup network? Because this is how IETF thinks it should be, you buy a fridge which you have 0 access to it's firewall features it relies on some cloud server for control/software updates if they decide to make your fridge EOL and you keep it connected you're on your own and they never provided any access to control services/ports for it most likely.

Yes I am absolutely furious with IETF for many reasons, I have tried to push for an ID (Internet Draft) in the past to acknowledge and standardise the prefixes for NAT66 but upon being met with hostility by pretty much everyone there I gave up and instead decided to simply spread the word because the bottom line is this, you don't need anyone's permission to do anything internally you can run any IP prefix inside your private network the only advantage of having standard prefixes is to avoid the possibility of not being able to reach an external network. They did standardise some of the prefixes and pretty much all of them are in the f000::/4 subnet for many purposes and not only NAT/ULA but the "F" prefix was designed to be a special use case prefix multicast/ula/link-local/site-local etc.

What do I mean by f000::/4? It's everything from f000:0000:0000:0000:0000:0000:0000:0000 to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff It consists of 8 hextets (unlike IPv4's octets IPv6 it's called hextets).

What about 0000::/4? It's everything from 0000:0000:0000:0000:0000:0000:0000:0000 to 0fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

This is perfect for NAT66/NPt it allows you to customise 8 hextets allowing you lots of freedom when organising your internal addresses, you can do something like this for example:

f1:33:3:1a :: 1 : 2 : 3 : 4

f1 = Network 1/Organisation 1
33 = France
3 = Strasbourg
1a = Location 1 Building A
:: = Separator
1 = 1st Internal Separation
2 = 2nd Internal Separation
3 = 3rd Internal Separation
4 = 4th Internal Separation

This gives you the network f1:33:3:1a::/64 for this site/location. Again just an example feel free to customise as you please it's your network after all.

There is one important thing you must keep in mind when you use addresses with fewer than 4 digits eg: f1 instead of f001 it actually sits in 0000::/4 this is not an issue but you must keep that in mind for WAN rules otherwise it will potentially 'leak out' of your firewall.

Something like f1:33:3:1a::77::2a (could mean for instance 77 = Virtual Machines, 2a = VM 2 and the A is the first virtual IP or simply 2 for physical nics) f1:33:3:1a::/64 being your network in this example, conveniently sized, easy to route, organised and now if the public IPv6 changes or the entire prefix changes your internal addresses are static/dynamically assigned by your own infrastructure and everything will work as expected without any outages.

See how customisible this is? Instead of using randomly assigned ISP owned addresses you have lots of flexibility and lots of addresses thanks to f000::/4, not everything is available for use let's explore further:

Let's separate these further:

f000::/8 - f999::/8 = The "numbers", Available to use!

fa::/8 and fb::/8 = Also not in use, Available to use!

Usually I like to also avoid fc:: fd:: fe:: ff:: even though they are 00fc 00fd 00fe 00ff mostly to avoid confusion, they are technically speaking not related to fc00 fd00 and when I refer to solely fd i do mean fd00 just to make things shorter to understand but it is important to highlight this important distinction especially if you plan to control these subnets from leaving via WAN later on.

fc00::/8 and fd00::/8 = Those are actual ULAs RFC4193, these are used by many things because it's an "official" local IPv6 address much like the ones from RFC1918 but the downside is using these can lead to problems for instance the matter protocol assigns fd::/8 addresses to your local devices for internal communications, so if you use matter at home i would stay away from using
fd::/8 as your internal network, fc can be used by certain things like VPNs and whatnot so to avoid the possibility of things not working i usually don't touch fc either but technically fa fb fc are all options as well I like using fa fb for SAN networks.

fe80::/8 - I do not touch fe either because of fe80::/10 as defined in RFC 4291 is used for link-local this is a core feature of IPv6, fec0::/10 used to be site local unicast but it has been since deprecated RFC 3879 for references. and finally ff00::/8 is multicast also from RFC4291.

In short you can use anything from f000::/4 except "fe,ff" and you should avoid "fc,fd" just in case something else may need it, literally everything else up for grabs eg. f1f3:: f333:: f16:: f22:: f35:: f117:: etc and to be specific you can technically use 00fe 00ff but i'm only mentioning this because you should be aware 00ff 00fe is not the same as fe00 in IPv6 and something I did not make clear enough in earlier tutorials because it's one of those things you assume everyone obviously understands it but in really many will confuse that. 0000::/4 is also perfectly fine to use and so is anything from a000::/4 - e000::/4 there are cases where you may want to use those for the sake of network segmentation/tiering having addresses starting with specific letters may be very desirable.

so for a SAN literally fa::3:1a/64 as the example for the VM used earlier even fa::1 would be a nice short ipv6 in this network, it can be even easier to remember than IPv4, all this can be your reality it does not have to be complicated it does not have to be difficult, IPv6 can be this easy.

2 -- Understanding your options at the network design level.

A - Direct IPv6:
This could be a desired configuration sometimes, just like servers that had their public IPv4 directly on device, if you have limited resources a VM or a machine somewhere with a single ipv4 and even a large ipv6 prefix but a very simple purpose it may be the case that all you want is just a public ipv6 and ipv4 with nothing in between but ufw/iptables and that's about it, there is a use case for it but certainly shouldn't be the default just like using public IPv4 even if there were enough IPv4s out there would've seem quite insecure because it is but it means no added routing complexity.

B - NAT66/NPt:
This is basically the same as RFC1918 (the good old 192.168.x.x addresses) the difference here between NAT66 and NPt is how ports are handled with NAT66 you will have the same limitation as you have with IPv4 in terms of ports which is 65.536 ports per public IP, if this isn't enough you can use multiple public ips, each will give you the same number of ports, keep in mind this is the amount of concurrent connections not the number of maximum connections you can ever make, if you understand this limitation which for most home users it really isn't a concern for most cases then NAT66 is fine here, also if you run your static routes/iBGP with wireguard anything handled by your site-to-site VPNs do not count so if your home workstation is "f1:33:3:1a::55:1" and your office workstation is "f2:33:3:1a::55:1" and they're connected through site-to-site vpn then this internal connection goes through the VPN and does not count towards your port limit, if you have lots of site but they're all internally interconnected NAT66 is still plenty suitable, the other option is NPt which will translate all your internal addresses to the external prefix, this however assumes you have a prefix which to many may seem like an obvious assumption right? surely every ISP that supports IPv6 will just give you at least an /64 you can delegate to your network with all ports open, surely right? no..

for NPt it will translate the 'right side' of the :: (separator) to the left side so using the example from earlier:

Example Internal IPv6 = f1:33:3:1a::1:2:3:4a/64
Example External IPv6 Network = 2001:4860:4860::/64
Example NPt Translated Address: 2001:4860:4860::1:2:3:4a/64

In Germany for instance if you call Vodafone and ask for bridged mode you will get 1x public IPv4 (not a given in this day and age.. sometimes you're stuck with CGNAT or even DS-Lite so I can't complain too much about them) but if you use a /128 your IPv6 will be fully open, as in you can route services but a /64 prefix will not be open ports, this can be on purpose to mitigate some of the problems mentioned earlier since home users are not expected to know how to design/handle their networks and they decided to silently block "all"/most incoming ports by default was a good enough solution to reduce botnets and compromised systems, by having NAT66 on your network you actually have all 65.536 ports available to you but only if you use /128 on the WAN side (single IPv6) and NAT66 so obviously here NAT66 is a no-brainer, but if your ISP allows you to use your prefix you might also consider NPt.

I have also a tutorial on how to do that for opnsense on the opnsense forums so here I will only focus on pfsense even though it's mostly similar:

3 -- How to do that in Pfsense:

• Go to Firewall > NAT > Outbound

• Change NAT Mode to Hybrid then Save/Apply Changes.

• Add a New Map Rule as follows:

--------
Interface: WAN
Address Family: IPv6
Protocol: Any
Source: [Network or Alias] f1:33:3:1a:: /64 (this is the example from earlier)
Translation: WAN Address
Description: "F--- IETF BS I have NAT66 and I am Free" or something else of your preference
--------

• Save and Apply Changes

4 -- Additional but important things:

IPv6 handles things a little differently you have RA (Router Advertisement) and DHCPv6, DHCPv6 is a little more nerfed compared to IPv4 with fewer options but it's much of the same idea, RA works along with DHCPv6 but it assigns addresses on in a different manner to DHCPv6 you should have both enabled, some devices do not support DHCPv6 and some will take addresses from either or both you have plenty of addresses it's not a problem, it is very common for a device with IPv6 to have multiple addresses assigned to it so don't be alarmed if you see literally a single nic with 5 IPv6 addresses depending on how your network runs, I personally manage my networks with a separate DNS/DHCP server solution you can also do that which will give you way more control over things or if you want to stick to running those on OPNsense directly you can do the following:

• Go to Services > Router Advertisement:

--------
Router Mode: Assisted (if you have a DHCPv6 server which you should ideally this is the correct mode)
Router Priority: High
RA Subnet(s): f1:33:3:1a::/64 (this is the example from earlier)
DNS Server 1: f1:33:3:1a::111:1/64 (this an example Internal IP)
DNS Server 2: f1:33:3:1a::111:2/64 (this an example Internal IP)
Domain Search List: dynamic.yournetwork.yourdomain.net (if have a domain for your location/network/whatever you can set it here just like DHCP).
--------

Save and Restart the RA Service.

Important: RA by default will assign any available address within your range, but it will not assign addresses already in use, unlike DHCP you cannot block or set a range within a network (sadly) but because it will not assign anything in use and usually really random addresses it's unlikely to cause problems but something to keep in mind if you do a lot of static addressing.

• Go to Services > DHCPv6 Server

• There are many ways to configure DHCPv6, but if you have NPt/PD you'll likely have your delegated prefix range here

• You can enable/disable the server if you have a separate more capable DHCP setup the options there should be pretty straightforward so i'll not get into details it is much the same as IPv4 except for Gateway, this is handled by RA in IPv6 instead you only assign the addresses themselves via DHCPv6, easy right?

Save and Restart the DHCPv6 Server.

Since not all of the IPs within f000::/4 are considered "bogon" networks technically if pfsense is not aware to drop any attempts to connect to an external network in these addresses it will forward to the upstream gateway, this may be desired under specific configurations but if not you may also want to create a rule to block these addresses from leaving through your WAN, that way if you accidently mistype an internal ip or due to a configuration error it is not on your local network it will also protect from the exploit of having that network reachable from your ISP side the same way you have that with RFC 1918 except since this isn't a standard configuration most routers don't know to drop these addresses so you must do that yourself, to do that it's pretty simple:

• Go to Firewall > Rules > WAN:

• Add a new Rule:

--------
Action: Block
Interface: WAN
Address Family: IPv6
Protocol: Any
Source: Any
Destination: Network f000::/4
Description: Block internal IPv6 (f000::/4) from leaving via WAN
--------
--------
Action: Block
Interface: WAN
Address Family: IPv6
Protocol: Any
Source: Any
Destination: Network 0000::/4
Description: Block internal IPv6 (0000::/4) from leaving via WAN
--------

(If you use any other internal subnets please also add those)

• Save and Apply Changes

• Restart your whole network, Ping and be amazed :)

• No traffic? Check your gateway settings and other rules conflicting.

• What about NAT64? That's for something else entirely and in RFC 6052 64:ff9b::/96 was assigned for that use case but this is not to be confused with NAT66 these are entirely different uses and it's beyond this tutorial.

I will also make a tutorial about multi-site vpn someday but goes without saying that by having these internal ipv6s you can obviously configure site-to-site encrypted tunnels and pretty much interconnect everything everywhere you can ping your office your datacentres everything directly using encrypted tunnels the possibilities are endless all it needs is a different left side of the /64 separator for each location and you're all set, tunnel + static routes or iBGP and your whole intranet cyberspace is here.

You should also be aware of something I literally had this tutorial on the OPNsense forums for OPNsense and was met with extreme hostility so much so I quit the forum as it was a waste of my time being there and arguing with the ignorance of that community, and that alone is enough of a reason for me to not recommend OPNsense to people because you're left with a philosophy and community not conducive to a user's long term familiarisation with the platform, pfsense has it's problems and netgate has a lot to improve but I cannot and will not stand for a community that just cannot think outside the box and hates on people that just do things different to the way they were taught to think, and this is why i'm sticking to only pfsense here, if you use OPNsense, good luck and figure it out yourself.

Also, If you're going to follow every RFC to a T and dot the Is then by all means go ahead and do that just don't say that what i'm teaching people here is wrong or has no use case or that is not recommended, because it is there are many reasons to do things this way and keep in mind this also applies to other platforms beyond the FreeBSD pf firewalls, the concept is the same.

Some other important things:

The point of a firewall is to protect yourself from exactly having your public ip addresses directly exposed to the internet, YES of course my point here is not to state that you NEED NAT66 or NPt in order to be safe, just that by having it you are going to be in a much better position to organise and secure your network, you also can route things internally with OSPF and BGP without relying on internet, as i mentioned earlier the idea of an Intranet is to have your own personal cyberspace and not rely on the public internet for everything, a little bit of BGP OSPF and WireGuard goes a long long way here which will be covered in the future, NAT66 also helps with that segmentation and tiering by allowing you to separate your networks but still go 'up' to subnets above, NAT66 is only there to translate from A to B the firewall is doing the blocking and control here doesn't matter if it's GUA to GUA ULA to GUA ot pseudo ULAs to ULAs or whatever. Not everyone has a pfsense box or an equally competent firewall this is why I say that the NAT66 network design should in fact be the standard just like IPv4 due to many lesser devices not being abl to handle firewalling themselves and some people just not having a proper firewall available, it does not mean that by having that a firewall becomes irrelevant it's quite the opposite, it's just one extra safeguard in a very hostile world which the IETF likes to make

Speaking of ULAs, I now recommend absolutely to avoid ULAs (fd00:: and fc00:: due to RFC 6724) it seems that those specific subnets will usually prioritise IPv4 traffic and other oddities so you can absolutely use them for special use cases but for a LAN or a dual stack setup I recommend the other f000::/4 subnets which work because they're not official ULAs (so I guess I want them to be that way now). Also notice fd00 fc00 not 00fd or 00fc this is very important.

I will once more make it clear that NAT is not a safety feature by itself, it is only to the extent other routers will drop bogon networks and not expose your internal prefixes to the internet directly as they're not part of the internet routing table, this doesn't mean you're safe from an ISP employee for instance just manually setting up a route to your internal prefixes from their end, this is why the firewall really is important, the NAT is about organising, segmenting and as an ADDED lifeline/safety measure not your main gate.

[patient0]

@millerwissen an almost 22'000 word long forum post, that's brave. I'd include a link to a blog post of yours instead. Good luck on you mission.

With the danger of me feeding a troll:

@millerwissen said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

The people at IETF decided that the common/average IPv6 deployment MUST be public and NAT is evil, and your system must be able to handle security individually (given no network firewall in between such as pfsense) which is a common case with the average people which only have an ISP provided box in their home

Please provide a link or links to support that statement. I have a hard time believing that, even the ISP provided boxes have a firewall.

@millerwissen said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

I have tried to push for an ID (Internet Draft) in the past

Again, since you refer to many other RFC, please include a link to your draft.

@millerwissen said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

Speaking of ULAs, I now recommend absolutely to avoid ULAs (fd00:: and fc00:: due to RFC 6724) it seems that those specific subnets will usually prioritise IPv4 traffic and other oddities

Provide links to sources, that sounds like you are mad.
Please point us to where in e.g. the FreeBSD code the filtering for ULAs and then prioritising of IPv4 is happening.

[millerwissen]

@patient0 Thanks for your comment, I don't like posting links it's not the job of the writer to convince the reader the information is accurate or making it easy for them to believe that, i rather let people do their own research and come to their own conclusions, but i will comment once to avoid ending up down the same rabbit hole as trolls in the other community.

@patient0 said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

The people at IETF decided that the common/average IPv6 deployment MUST be public and NAT is evil, and your system must be able to handle security individually (given no network firewall in between such as pfsense) which is a common case with the average people which only have an ISP provided box in their home

Of course they didn't straight up say that, that's a personal statement from and a personal observation based on their attitude towards NAT in general over many years not a recent development at all and being "IPv6 Purists" that want everything to be globally reachable without taking into consideration other deployments.

There is no such standard for forcing companies to have a firewall on their ISP boxes and not every deployment will be routed through the box, bridge mode is a common way in fact to be directly exposed even on boxes that do support firewalling (and is the best way to do it when you have your own firewall also), I would be surprised if you managed to check ISP boxes in every country of every continent and concluded that every single company will give the user a properly configured firewall and an interface to manage it because that is not what I see from my end and if you need a source for that I would recommend instead checking every ISP box and make a list to confirm their capabilities which is not something I am able to do other than mention that I have personally seen ISP boxes that did not have proper firewall features or give control to the user which is pretty much the same thing or arguably even worse.

@patient0 said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

I have tried to push for an ID (Internet Draft) in the past

My ID was not ideal because it didn't include all the necessary ranges only f000::/4 which doesn't technically cover 0xxx::/4 and I since learned that you must be very specific when mentioning ranges because people don't always realise that anything that starts with 0 is technically part of 0000::/4 and not whatever the other range is.

I can however still find the archive https://datatracker.ietf.org/doc/draft-millerwissen-f000-reservation/

And all I wanted with that was to formalise the use of private networks within IPv6 but internet drafts require so much annoying text formatting and this and that that I literally couldn't be bothered to write that myself and just threw that into an LLM and even the LLM struggled to get that formatting exactly as they expected, which to me says they're more about that than actually getting the good ideas into discussion, and if you need a source for that again look at their attitude and take your own conclusions, not everything will have an easy fact checkable source in life :)

Anyway, I decided not being worth the time again because they didn't care about enough instead most companies end up using pseudo GUAs nowadays for "official" private networking deployments (either my proposed using the letters a-f including ones with 0 on left minus the fe00 ff00 ofc or an actual public GUA they own) instead they focus on IPv6 purism which may help under certain scenarios but 99% of the use cases for most people and also the fact most people nowadays their ipv6 network is basically just SLAAC and effectively a single L2 mess with everything in one place is about showing people that there are better ways and that it's worth spending time cleaning that up making better networks. And most importantly that IPv6 can be just as private as IPv4 and this should never be used as an excuse to avoid deploying IPv6 which I cannot believe this but even today you will hear people saying they just disable IPv6 because it's too complicated or they hate networking or even because they don't understand or think everything must be public in IPv6, and so they rather IPv6 to 'just exist' in the background but only focus on IPv4 completely ignoring the IPv6 stack which opens up a whole other can of worms.

Privacy being extremely important a combination of NAT and site-to-site routing (which may and may not include NAT depending on specifics) is also going to take advantage of said private subnets, none of this requires anyones permission or standardisation but the goal was to make it standard as it was with IPv4 and let the user decide whether they wanted to have a GUA LAN with public ipv6 on device and manage firewalling themselves or not.

@patient0 said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

Speaking of ULAs, I now recommend absolutely to avoid ULAs (fd00:: and fc00:: due to RFC 6724) it seems that those specific subnets will usually prioritise IPv4 traffic and other oddities

I never mentioned FreeBSD code here, your firewall may be FreeBSD but your clients are very likely Windows/Mac/Linux and they are the ones that matter here, FreeBSD as far as I know has no such filtering or prioritisation in place, however windows (at least) when using actual ULAs for example you will get your traffic 'upstream' prioritised over IPv4, how? if a domain has both IPv4 and IPv6 available and the local network is within the ULA ranges it seems to be picking IPv4 first, I had this discussion in the OPNsense forums, that whole discussion was deleted but if I remember correctly there were also some other threads about that specific problem when using ULAs but you can look those up if you want to, for the record I do have mixed experiences with that because I don't use ULAs i like my custom ranges which are technically bogon GUAs and wouldn't be treated the same way as the ULA, with my custom ranges when i ping for example google.com i do get ipv6 first even in windows but it's possible if you use ULAs you won't according to those reports due to this RFC it seems, which is more than enough of a reason to avoid using it for your LAN. This also may vary depending on the version of Windows, I only use Windows Server ever since the 2000s so I don't like using workstation versions of windows I don't even have a single install available here to test but it may be worth trying at some point to see if it is the case.

And yes I am quite mad I have very little patience but it doesn't mean I don't have a point :)

[Patch]

@millerwissen said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

IPv6 can be just as private as IPv4 and this should never be used as an excuse to avoid deploying IPv6

In the deployments I have seen ISP mostly provide customers with

• dynamic IPv4 address (individual devices accessing the internet via a NAT)
• static IPv6 prefix (internal devices accessing the internet via fixed or viable address within the CIDR prefix range. Part of which is often related to a devices MAC address)

This ISP decision severely compromised user privacy because

• When any device accesses the internet, the external party can use the IPv6 prefix to identify the ISP and what IPv6 CIDR range size is delegated to each customer.
• If one device on a customer network ever discloses location data (eg every mobile phone), from that time on the street address of the IPv6 prefix is public (data aggregation company) knowledge.
• At a later time if any device or software program uses this internet connection, the street address is encoded in every internet data transfer. As a result location services are always on independent of any user program setting.

This privacy compromise is in addition to 1. the finger printing published by using an IPv6 address, part of which is a hash of the MAC address. 2. Typical use of device specific fully static IPv6 (or small set of addresses), unless users manually configure an alternative.

I'm happy to be corrected but, IPv6 as implemented appears to be excellent for monitoring a population but a dramatic step backwards for user privacy.

[millerwissen]

@Patch
Ok so, l will try my best to go through all this.

@Patch said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

In the deployments I have seen ISP mostly provide customers with

dynamic IPv4 address (individual devices accessing the internet via a NAT)
static IPv6 prefix (internal devices accessing the internet via fixed or viable address within the CIDR prefix range. Part of which is often related to a devices MAC address)

That depends, I have Vodafone here in Germany with bridged mode still 1 real IPv4 no CGNAT and 1 Dynamic /128 free to use IPv6, if i enable router mode in the modem I get delegated a prefix but only if i use their modem to manage, I would lose complete control and you have to go really really out of your way to request bridged mode which is not guaranteed for every customer in every region, O2 did not give me that at all which is why I had to cancel and switch to vodafone, O2 was only DS-Lite.

I did try some tricks to delegate a prefix in the past but results in incoming ports being blocked by default, so I get basically 1 usable IPv6 and 1 IPv4 which is fine with NAT66, unless you really have more than 100 devices busy on your network you're highly unlikely to run out of ports anyway which is why CG-NAT worked for ISPs.

DS-Lite is the more common way to get IPv4 nowadays, IPv4 over IPv6 effectively, most ISPs have very little reason to keep the IPv4 legacy stack so managing only IPv6 makes sense as costs them less which is all the ISPs care about.

Prefix can be dynamic depends on several factors usually they use your mac address to delegate/distribute a prefix/ip via DHCPv6-PD, PPPoE is no longer used, so yes you are correct in the sense of the ISP knows your physical mac address at the WAN but that's about it if you're using NAT/NPt they won't know your LAN addresses, with NAT66 they will only see 1 ip with NPt they can also see how many devices you have on that segment at least which can give them a clue about your usage patterns, eg. 3 devices vs 76 devices will certainly look "interesting" to them if they're looking for something in particular.

@Patch said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

This ISP decision severely compromised user privacy because

When any device accesses the internet, the external party can use the IPv6 prefix to identify the ISP and what IPv6 CIDR range size is delegated to each customer.

I agree partially, the problem I have with your statement is that it's the same with IPv4 they know who you are, you are a subscriber you are verified you pay the bill they can see your unencrypted traffic and your mac addresses and even source/destination ips, does not matter what stack it is.

So to sum up you are right in what they can see but they already could see all that with IPv4, using encrypted VPNs and site-to-site tunnels means that instead of you going to vm1.myoffice.net you go to vm1.myoffice.intranet for example your local DNS server can send that to a pseudo-GUA/internal private ip eg. d2:12::1a if you have OSPF/BGP this means your router instead of sending this to your gateway it will send to your VPN site-to-site bridge, through which ends up on your other side where you have yet another internal private ip (non internet reachable ipv6) where that vm can be reached you never touched the open internet, your ISP doesn't know anything except there's an active connection between location a and location b via port 12345.

With the way things are going with the governments out there thinking they control the internet this is going to be the future, lots of private networks, site-to-site connections and VPNs, and when they start making this illegal people will have to move out of their jurisdictions or end up breaking the law to retain their privacy, at that point they may also try to make encryption itself illegal and many other things, in reality nothing they think can be stopped can actually be stopped if you understand networking their measures to control the population are laughable at best, but if we ever truly end up in the world of 1984 then you better be light on your feet and be willing to move elsewhere quickly before you're unable to escape but until then, VPNs and there is no difference between IPv4 and IPv6 in that regard and your local mesh and wireless networks may either be made illegal/require licensing enforced backdoors etc, this is happening more and more the EU was considering mandatory backdoors and many other nonsense the public doesn't know or isn't well enough informed to care which by the time they find out it will be too late, they're too busy with their TikTok..

The only if we can even call that an advantage with IPv6 is the internet background radiation so to speak where bots are constantly probing open ports, this is usually less for now at least with ipv6 when you have really random addresses for the public ipv6 side far more addresses means a lot more work for them to find an active ipv6 but once they find you they will also keep probing open ports, really important to have a firewall, NAT will not save you from the bots whether it's IPv4 or IPv6.

If you are fortunate enough to own your own ASN and you have a few IPv4 and IPv6 prefixes then you can just find an ISP willing to peer BGP and have them, but don't expect residential ISPs to accommodate that either and this also doesn't change the fact they know who you are regardless.

[sysxtreme]

Hello everyone,
I'd like to share my experiences with IPv6 deployment on FreeBSD-based firewalls like pfSense, particularly in scenarios involving multiple ISP connections and prefix delegation challenges. I've been tinkering with this for a while, and while IPv6 can be tricky, I've found a workable approach that might help others facing similar hurdles. I'll keep it technical but straightforward—please feel free to chime in with your thoughts or corrections!

The Challenge with ULA Prefixes and Client Prioritization

In my setup, I've noticed that many client operating systems tend to prioritize IPv4 over IPv6 when Unique Local Addresses (ULAs) are in use. This behavior isn't limited to Windows 11; I've observed it on Linux distributions like Fedora 43 and Debian 13, as well as on Android and iOS devices (and likely others). Essentially, when a ULA (from the fc00::/7 range) is assigned to local interfaces, clients often default to IPv4 for outbound connections, even when IPv6 is available and preferred in policy tables. This effectively sidelines IPv6 usability, making ULAs less practical for everyday LAN environments despite their intended role for private, non-routable addressing.

Why NAT66 Became My Go-To Solution

Given my network topology, NAT66 emerged as the most viable option for enabling functional IPv6 across the board. Here's a bit about my setup for context:

• I have dual ISPs, each providing a /56 prefix delegation to their respective modems.
• The pfSense firewall receives only a /64 on each WAN interface, leaving no additional prefixes available for delegation to the LAN side.
• This constraint prevents direct assignment of Global Unicast Addresses (GUAs) to LAN clients or the use of NPTv6 (Network Prefix Translation) to map a GUA prefix to a ULA prefix internally.

Additionally, I require load balancing and failover between the two WAN links. Achieving this with IPv6 using NPTv6 proved impractical, as it doesn't lend itself well to multi-link scenarios without complex routing gymnastics. NAT66, however, allows me to masquerade internal IPv6 traffic behind the WAN GUAs, enabling seamless load balancing (e.g., via policy-based routing) and automatic failover. It's not the "purest" IPv6 approach, but it gets the job done reliably in constrained environments like mine.

Choosing an Internal Prefix: Balancing Priorities and Avoiding Conflicts

The key question then becomes: What prefix should be used internally with NAT66? Here's what I considered:

• ULAs (fc00::/7): As mentioned, their lower precedence in client OSes (per RFC 6724 and similar guidelines) often leads to IPv4 fallback, diminishing IPv6 adoption.
• GUAs (2000::/3): Using a real GUA range risks address overlaps with legitimate internet services, which could cause routing conflicts or unintended exposure.
• Unallocated Ranges (e.g., a000::/4, f000::/8 to f999::/8, fa::/8, fb::/8): These might seem tempting, but they're subject to future IANA assignments, potentially leading to overlaps down the line as the address space evolves.

To sidestep these issues while maintaining high IPv6 priority on clients, I opted for the 2001:db8::/32 prefix, which is explicitly reserved for documentation purposes as outlined in RFC 3849. I fully acknowledge that this range is intended solely for examples, tutorials, and testing—not production use. However, in my controlled lab-like environment, it functions flawlessly: Clients treat it as a standard GUA (due to its position in the 2000::/3 block), ensuring IPv6 takes precedence without any overlap risks to real-world internet addresses.

The Results: A Smooth IPv6 Experience

With this configuration in place on pfSense:

• LAN clients can reach any IPv6 destination on the internet without hiccups.
• Load balancing and failover across the dual WANs work as expected, distributing traffic efficiently.
• Internal addressing is simplified. I use shorter, memorable IPv6 addresses for local services, which makes management a breeze.

Overall, this has given me the robust IPv6 connectivity I've been aiming for, even with the ISP limitations. It's not without trade-offs (e.g., deviating from strict RFC compliance), but it's a pragmatic solution that prioritizes functionality.

Best regards

[millerwissen]

@sysxtreme Thanks for your comment and sharing your experience, even though you used an AI model to output your comment I will try to get to the core of your original message and the overall comment remarks.

@sysxtreme said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

Why NAT66 Became My Go-To Solution

NAT66 is a tool, it's not for everyone but it solves many problems, for instance you can run your internal prefixes purely on OSPF without NAT if you had nothing but GUAs on firewall policies alone and limited BGP ASN and hextets available to customise the address in fact i find this quite nice that i can encode information into the IPv6 address as I please just by looking at the address I know everything i need to know without even needing DNS lookup making this really nice and quick during deployment, daily work etc, or one can also deploy NAT66 and naturally convert from public GUA to the bogon pseudo-GUA.

@sysxtreme said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

These might seem tempting, but they're subject to future IANA assignments, potentially leading to overlaps down the line as the address space evolves.

This is possible but highly unlikely because IANA started at 2 for a reason therefore anything 0xxx::/4 is already past it's assignment likelihood except for 64::/xx which was assigned for 'official' NAT64 deployments and can also be used as you please but they set it aside for that.

The letters axxx::/4 to fxxx::/4 they also went to the very end to reserve link-local and multicast and even the ULAs it's unlikely they will then assign fa00::/4 and fb00::/4 to the public GUA pool, so why am i so confident? because there is no need to they still have to go to 3000 4000 5000 6000 7000 8000 9000 until they finally get to the letters this is enough IPv6 for our galaxy if not the observable universe (maybe not that much XD but it's a lot..) certainly enough for the solar system and absolutely enough for Earth Mars and stations in between this is how many addresses we're talking about here, it's a lot of computers, phones, IoT devices that need to be manufactured before we ever see the world be anywhere near using up those numbers alone.

Can they do it out of spite to just annoy us? sure but our WAN egress block policy will take care of that if someone ever makes those public GUAs and they're using internally the traffic never leaves their internal network it is therefore reserved, you can do that with any IPv6 address there is just need to do that because to others because then you're limiting yourself on what you can access on the internet for no reason, will it ever happen and within the next 100 years? extremely unlikely unless like i said it's out of their spite and annoyance which won't work anyway as long as you're able to block traffic from leaving via your WAN so it's a pointless effort and people won't want those addresses due to this so might as well reserve them for what was proposed initially keeping them for "special use cases".

@sysxtreme said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

To sidestep these issues while maintaining high IPv6 priority on clients, I opted for the 2001:db8::/32 prefix

This is a valid configuration but no more "correct" than our other addresses here because they can also turn that into a public GUA and use another range for documentation purposes and you should also do the same block that subnet from leaving via WAN regardless but if someone just wants an IPv6 that "looks" more like a normal GUA within the 2001 that's a perfectly valid range too, and i also recommend checking here for the other IPv4 reserved subnets I use them on every deployment for many other purposes and especially if you want to keep the RFC 1918 available for 'average people' to use them especially if they don't know about the other ranges:

The wikipedia page about it https://en.wikipedia.org/wiki/Reserved_IP_addresses

@sysxtreme said in Updated tutorial for NAT66/NPt Your Private IPv6 similar to IPv4:

deviating from strict RFC compliance

There are very few scenarios where RFC compliance matters and that's usually when investors are involved, governments or the public internet etc and it's only really to appease whoever is in charge, for most companies and private individuals (non internet facing of course) the whole RFC compliance is very much optional and not really something to worry about RFCs are standards it's not law anywhere it's not mandatory and in fact your can even make your own set of rules and private internet standards as long as you don't try to enforce them on the public IANA regulated internet itself there is no harm done the idea of different divergent internets is hardly a new concept even arpa was compltely different than what we have today as a 'standard', over the internet they exist to keep a baseline it's good for everyone and also vendors to have something they can agree on basically, but again can be the default behaviour (though i still disagree on the non-NAT being default) and non RFC compliant in 'alternate' deployments.

To sum up I think your experience is exactly what people should have had ever since the 2000s when they were familiar with NAT44 and then they could've been introduced to IPv6 and have NAT as the default for complex deployments and for people familiar with IPv4 and then alternatively the public GUA with heavier reliance on firewalling as an optional design and with many use cases still but their push to overcomplicate and restrict the the defaults of IPv6 resulted in people feeling hesitant to move to IPv6, remaining unfamiliar to a lot and causing unnecessary burden and fights within the community to what is best. Regardless of how you deploy a good and satisfied result is a good and satisfied result.

[sysxtreme]

@millerwissen

I am not very good at writing in English, it is not my native language, so I write in English the best way I can, and ask the AI to adjust my text for corrections and improvements, however, it was enough to explain how I managed to overcome the difficulties and challenges of using IPv6 when two or more WAN links are used, and especially when the internet service provider does not give you a sufficient /48 prefix to support a scenario with your own modem and router, I saw many things across the internet about using IPv6 but no one encourages the use of NAT66 or NPTv6, as if it were easy to obtain prefixes to use internally. I ended up opening several complaints with the providers to get a /48 prefix or to be able to delegate additional prefixes so that I could use them internally, but the providers simply do not care, I even opened a case with a governmental telecommunications control agency to see if I could get something but still without success.

Of everything I have read, your post was the most truthful in showing the problems of IPv6 and how to solve them, congratulations on that, and it seems you also have a very great knowledge on the subject, something rare to see in internet forums, what exists the most are curious people who claim to know something when in fact they do not understand and just repeat things like parrots.

Regarding the IPv6 block designated for documentation, it really may be that in the future it could be allocated for another purpose, in which case I would have the same problem using GUA addresses.

I wanted to better understand the context in which you mentioned using OSPF to route the prefixes.

[millerwissen]

@sysxtreme That's perfectly fine, I just mentioned in case the AI changed the context of your statements, you don't have to be good at something to make a difference either, your english is perfectly fine.

Yes so one of the most fantastic use cases for NAT is translating a subnet to multiple subnets port forwarding and load balancing from the upstream/wans becomes a very easy task.

You certainly do not get more than a single prefix usually the norm really is /48 /56 and they become /64 in some cases you may also only get the one /64 you will get but it's fine with NPt/NAT66 you don't even need more than a single IPv6 for most use cases let alone more than a single /64.

I would not waste time trying to complain to your telecommunications agency about this because I would really not expect any government to have provisions for customers to get more than "what they need to be reasonably connected to the internet" in a very purposefully ambiguous language anyway which would allows the ISPs flexibility in how they want to connect their customers, most of the government really will not be able to understand the technical differences between deployment models and so they trust the ISPs to just 'make it work'.

Yes you can use OSPF internally (technically also BGP) but the usual OSPF deployment consists of point to point links which facilitate inter-router communication and routing so if you have a complex network you can just route things internally via OSPF/BGP and have NAT66/NPt at the upper end.

You can also Tier things:

WAN
---NAT66
MIDDLE NET
---NAT66 --NAT66 --NAT66 --NAT66
LAN 1 LAN 2 <OSPF> LAN3 <OSPF> LAN4

In this example your LAN 2/3/4 can route to each other via OSPF point to point links without any need for NAT among them but the middle net cannot access them just a WAN wouldn't due to firewalling and the connectivity to the upstream remains due to NAT+GW in this case the WAN router. LAN 1 remains isolated without routes to 2/3/4 but can see anything you port forward to MIDDLE NET and upstream towards WAN. (you may need to disable reply-to and a few other tweaks for this to work but anyway it's just an example).

It can be much much more complex than this but all internal subnets can remain within your local IPv6 ranges you don't even need /64 unless you're using that network for an actual LAN with RA/DHCPv6/SLAAC i personally use /96 more often than /64 because i just want the last 2 hextets anyway to match a /16 IPv4. You can also do NPt to your 'middle net' and from there NAT66 as needed you basically have an internal WAN also route traffic to different uplinks effectively increasing the overall internet speed available to you without causing any internal conflict and maintaining the internal routing structure.

Unrelated to your question but to other people out there IPv6 can be either "just work" or better than "just work" it really is up to how much you're willing to spend on engineering and designing and it will pay dividend in the future.

Hope it satisfied your curiosity.