Messages

Patrick is right on this one, Dual stack has been the standard for a while we're technically "mid transition" still. Here's my timeline (nothing official just my personal opinion):

1990s - Prototyping and testing of IPv6 stacks on Windows NT4/Linux etc
2000s - The very early transition/adoption dual stack a must
2010s - Early transition - lots of mass adoption more ISPs start to offer ipv6 to home customers but many IPv4 systems still around, cloudflare helps significantly with the shift to IPv6.
2020s - Mid transition - Most people have IPv6 but many legacy systems and slow to adopt companies and systems still on IPv4 eg some banks and government systems.
2030s - Post Transition - Most will be on dual stack by now and ready to move on, most new deployments can pretty much be IPv6 only no need to support IPv4 anymore but will be on dual stack until the end, NAT44 and NAT64 heavily used to minimise IPv4 costs, IPv4 begins to be phased out and removed to simplify things.
2040s - Obsolescence Phase - This is past year 2038 problem and IPv4 use is highly unlikely to still exist by then except for legacy systems which will also have to be 64bit due to the year 2038 problem, most if not all 32 bit systems completely obsolete and so are IPv4 deployments.

NAT66 and separate local networks can help people looking for private networks similar to RFC1918 so there is no reason to have IPv4 unless people simply don't know how to set things up via IPv6 or are using old software/legacy/retro hardware.

Only strictly ULAs.

https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/

I didn't know about that at all thanks for sharing this, I will add this information to my tutorials it's quite useful to know my "illegal" f000::/4 addresses are immune to this nasty RFC :)

Internal does in now way necessarily mean NAT. You can have well segregated networks across multiple locations all connected by secure VPNs and use the same GUAs the systems use to access the Internet for internal communication, too.

You could even do this back in the IPv4 days when everybody got globally routed prefixes easily.

"Internal" and "special private addresses" are not connected. "Internal" is a qualifier of your network topology and nothing more.

Absolutely you're right, It doesn't have to be at all, I have my SANs setup that way it even has 9014 MTU on every device, even redundant SANs at home, work and others which are not even routed or accessible beyond their respective local sites, and still dual stack on each, fa::/64 fb::/64 perfectly fine without a gateway or internet or NAT of any kind for this specific use case.

I could in theory NAT a separate such network to another more common network for convenience/separation/avoiding more iBGP routers/static routes and your example is a perfectly fine way to do it as well nothing wrong with that if the person wants it setup with a single prefix, now if i have 3 gateways 3 uplinks 3 prefixes my LAN will keep the same local addresses and i can simply change the gateway from 1 to 2 or 3 on any local device and everything is as predictable or I can manage two separate networks my internal DNS server resolves any local resource where it's supposed to be everyone is happy, I don't see the reason why I need to do two Internal + GUA for my LAN but both are perfectly valid use cases.

I also like using isolated internal networks for IoT they have no business going to the internet either, Matter always uses the fd:: ULAs + a non standard f000::/4 subnet for everything else works fine and truly isolated.

Bridging between subnets with NAT by port forwarding or NAT 1:1 can sometimes be easier than routing entire subnets eg if I have a website on my internal network that I self host or a DB server or a linux mirror resource which i want the guest network to also have access to it though an internal domain, a 'bridge' between LAN and Guest using simple NAT66 can make that resource available on that side without having to route entire networks or go 'above' via the internet and it will still benefit both sides.

I love having options, more the better (It's why I'm not straight or monogamous) and why I want RISC-V to succeed :)

So Yes, (Internal + GUA) it can also be done that way if preferred but there is no actual factual necessity under normal circumstances, NAT66 can combine both and simplify addressing + internal routing with iBGP/OSPF which will be predictable subnets and more hextets to make it clear just by looking at the address where it is what it's for etc 2+2 vs 2x2 situation but one is better than the other depending on your preferences and personal needs, and don't forget Internal DNS servers.

The whole point of IPv6 is that NAT must die. It breaks the end to end principle upon which the Internet was built and there already are lots of applications giving firewall admins headaches because of NAT - FTP (ok, deserves to die, too), VoIP, ...

The whole point of IPv6 is to be better than IPv4 at the stack level curtailing that whole IP shortage problem we had and also allow for so many more addresses to the point we have enough not to worry about that for a long time.

I appreciate your opinion everyone has their own and (ideally at least) the right to it, their personal perspective can be quite hard to understand without more information and insight on what they value, think and need so please don't take this personally.

I however absolutely disagree with your statement, NAT has many use cases, all of my networks are properly segmented, most have site to site Intranets with iBGP it's absolutely beautiful and nothing goes to the public internet Unencrypted as it should be in fact the default for the world by 2025.

The internet is hostile, some oppressive jurisdictions nowadays thinking they have a say on what people do and what they should have access to it's utterly ridiculous for them to think they can control the internet and private subnets are extremely important for privacy reasons and many others.

But technology as a whole does not have to die, science is about discovery and evolution you don't have to destroy things just because you don't personally use them, not everyone has to use, not even every deployment necessarily needs or benefits from it and if it doesn't suit them it doesn't make any difference to them but it may make a whole lot of difference to someone who uses it and needs it, technology is for everyone not for the few that have a say in the matter and that's the core of the problem.

For example, I dislike 2 wheels for a choice in vehicle, but some people like them and for their personal needs can make perfect sense, but I don't like it so I wouldn't go as far as being the full Jeremy Clarkson and ban everything with less than 4 wheels just because I don't care or I don't use or I don't see the point of it.

I have never seen a single case of NAT66 or NAT44 breaking any application despite hearing about that argument before, which to me sounds like people who want something to 'just work' in a world where it takes a little more than that for things to 'just work'; if an application is so poorly written it expects public ips or port forwarding I think they need to figure out their priorities in business before hating on NAT, if it is free and open source and it requires that then the user should take that into consideration before picking the application that suits their needs. NAT or no NAT won't fix bad software or software constrained by other factors.

Also there's this 'laziness' in developers and some large companies when designing certain things, take for instance game servers a common case where instead of using dedicated servers and securing their instances many companies went for P2P and expected full port forwarding which also caused many other problems over time introducing vulnerabilities and even remote code execution (see for instance the COD Modern Warfare 3 fiasco for that one). Not to mention the ones that just completely neglect their servers altogether but the user chooses to partake, is it now the fact the devs couldn't be bothered to design things properly at fault or NAT that is at fault.

If understanding the basics of how network functions is too much for a Firewall/System Admin then they shouldn't be of managing a firewall, they may cause far more harm than they're aware especially long-term; That alone is even more of a liability for themselves or the company they're working for if they don't understand how things work NAT or no NAT will not save those people from themselves so I don't see this as a valid argument either.

FTP also has many uses, many old protocols, plain http, telnet etc again not everything has to be sent over the public internet when you have a site to site encrypted tunnel or even just a point to point tunnel then why use FTPS/SSH unless you want the double encryption on purpose, if enough file transfers or low end hardware that can be a small boost in performance and saves some time setting it up so there is a scenario where even unencrypted FTP can be perfectly fine for 2025 and if opening ports and routing them is too much work for someone setting up an FTP server even if local or even disable a firewall on a private network then once again I guess they need to reassess their priorities in life and consider other options.

Even for commercial VPNs within internal networks you can setup many internal gateways a vms with even something like opnsense instances or a linux box in your private network simply change your v4 and v6 gateways on a machine and it goes out a completely different route on any device without having to run a vpn client for that and that can run 24/7 whenever you need it, the possibilities are endless and none of that may be something you care/use but there is a use and this whole attitude of "NAT must die" is why people still use RFC 1918 addresses and sometimes even disable IPv6. Don't even get me started on some commercial vpn services that simply ignore ipv6 because "too much work/nat66 is impossible".

Site to site without having to worry about gateways? S-NAT! Yes even that.. I can completely ignore gateway configs and access a machine from another country even internally. Nonsense right? who needs NAT it should clearly die :)

Imagine being able to ping every device you own on your private Intranet fully configured fully encrypted without having to worry but no instead why not promote that people should use public ips as the "only" option and nothing else is allowed :))

Why have a clean and tidy home when we can just toss everything on the floor right, or have colour eyesight when everything can be black and white.

And for the record, "Clippy wouldn't kill NAT" for those who understand the meaning.

Sorry for resurrecting old thread but I just wanted to leave my interest for RISC-V and not only it's great for everyone outside of the US not being tied to US tech, it's going to allow us to have far greater competition in the market and for opnsense this is quite important, I do think you might also have to at least consider moving to Linux for RISC-V even though it's not a related project TrueNAS did move to Linux with SCALE and that went pretty well especially in terms of hardware support.

FreeBSD is quite mature with PF and other aspects that work quite well for firewall projects and I also like that FreeBSD gets some love and use still on this front so I would much rather see FreeBSD catch up to RISCV than switch to linux also makes it far more realistic to add RISCV support to OPNsense/pFsense than to fork or even start a whole new project from scratch like IXSystems did with TrueNAS SCALE though this would cost a lot of time and development. There was a linux based firewall eons ago I think it was called ClearOS but it's probably completely dead now it was Linux based though the performance was not even close to pfsense/opnsense but it had a lot more bloat with it.

Nothing wrong with deploying ULAs, but treating IPv6 like IPv4 (private addresses NATed to a single public address) has a major caveat: When choosing a source address, clients always prefer IPv4 over a ULA (unless the destination is also a ULA). This means the IPv6 NAT will only get used for connecting to IPv6-only services. For dual-stack services, your clients will use IPv4. As a result, you'll see very little IPv6 Internet traffic with this setup.

So yes, better than nothing, but not a "fully modern dual-stack environment".
As a slight improvement, you can deploy your single delegated /64 in the "primary" LAN, while using NAT for the others.

Cheers
Maurice

So I actually have quite a bit of experience with NAT66 myself even made this tutorial to help people that aren't familiar with it:

https://forum.opnsense.org/index.php?topic=47644.0

But what you just said I haven't really noticed on any of my deployments over the years both official ULAs and the rest of the f000::/4 range which are technically not official "ULAS" and might be why they bypass this behaviour altogether.

I have seen the behaviour you're mentioning on only some specific use cases and very very rarely:

- Linux i almost never ever see it preferring IPv4 over IPv6
- Windows Server 2016-2025 almost never IPv4 over IPv6
- MacOS Mojave-Tahoe same as Linux
- Windows 10/11 occasionally I have indeed noticed this behaviour on specifically Desktop versions of Windows for some odd reason i ping eg google.com and it goes to ipv4 instead of ipv6 but ping -6 google.com will immediately just ping with ipv6 but it's not consistent some domains will prefer ipv4 some ipv6.

 I'm not able to replicate this consistently nor explain why but I'm curious if you've tested many other OSes and if you only use strictly ULAs or any of the other f000::/4 subnets.

I want to clarify something some people brought up to me in private that I should've made it a little more clear while the point of the tutorial is to explain how to do NAT66 and to show that IANA/IETF could've done things better in the beginning and that giving people options is important especially keeping it mind not everyone HAS a dedicated firewall on their network and that's the point i'm trying to make here the 'default' behaviour/deployments affects the masses not people like you and me with advanced knowledge of computers and networks.

Some people may have read this and think that by not using NAT66 you're immediately in danger no matter what, if you have opensense/pfsense or any competent firewall managing your network connection the default behaviour is usually to Block any incoming connection to your routed subnet ips so yes you're "safe" even though you're using external ips but this has some caveats and downsides.

- if you change that default behaviour or create a conflicting rule you're immediately exposing your network devices to the internet including those that cannot defend themselves, which brings me to the next point.

- Not all devices can manage firewalls, so obviously having a central firewall has many advantages and can be essential on most modern networks no matter the layout you use even if you literally just use IPv4 and NAT44 you can't just trust any old potentially compromised router do it's job properly and not reset itself or have a potential vulnerability.

- You have very little flexibility in terms of your networking, so now you're stuck with external ipv6 addresses on a per device basis which you do not own this is extremely important because you can route internal ips via tunnels but external ips will cause a lot of conflicts unless you really do some static routing and isolation which is a lot of unnecessary work and even then all that for an IP prefix you most likely don't own. And don't forget the amount of flexibility you get having your entire f000::/4 subnet, 8 hextets to play with.

- Lack of segmentation, I can have many many entirely separate internal subnets which some can and some can't communicate to each other for many reasons but you can certainly have full separation between your IoT network, your Guest network, your Security network your personal Network and many others by using internal addresses.

- You have nothing to lose, the argument over having a single IPv6 only applies on cases where this is restricted by the ISP or you prefer that for maximum control over your prefixes and whatnot, NPt (Network Prefix Translation) handles the 1:1 NAT per IP seamlessly and each internal ip gets it's equivalent external ipv6 and you can have the same experience albeit with a single prefix and single internal subnet. Though you can still create other internal gateways and route the other less important devices using just regular NAT66 over a single ipv6 this would be a hybrid configuration.

- I'm not against having public ips nor am saying that you're immediately in danger if you use them (when you do have a proper firewall in between) but i'm against people being told there is no other way and that public ips are the best way to do it and that mindset has to change if IPv6 is to truly replace IPv4 otherwise people will keep using IPv4 forever anyway and the whole point of IPv6 is gone.

Sei vorsichtig, nicht alle deine IPv6 Ports mit Regeln zu öffnen, da dich das in einen gefährlichen Zustand bringen würde.
Ich persönlich bevorzuge statische Adressen innerhalb lokaler Netzwerke, daher nutze ich in der Regel entweder NAT66 oder NPt.
Ich habe hier ein Tutorial dazu erstellt (auf Englisch).

Bei OPNsense ist das Standardverhalten, eingehenden Zugriff zu blockieren, sodass du sicher bist, solange du es dabei belässt :)
Allerdings solltest du auch prüfen, ob du beim Delegieren des IPv6 Präfixes deine Ports manuell weiterleiten oder öffnen kannst. Denn bei Vodafone hier in Hessen werden keine Ports geöffnet, wenn man das gesamte Präfix nutzt, selbst wenn man es in OPNsense erlaubt.
Verwendet man jedoch nur eine einzelne IPv6 Adresse und macht NAT66, kann man mit Vodafone Ports nach Belieben weiterleiten. Daher bin ich sehr neugierig auf Deutsche Glasfaser.

Tutorial link, falls interessant: https://forum.opnsense.org/index.php?topic=47644.0

Just letting people know I improved the WAN output blocking logic to further improve the blocking of f000::/4 out the WAN as a Bogon network while allowing FE FF so that things work as expected.

Fiz um tutorial sobre isto nos fóruns do pfSense (firewall de código aberto baseado em FreeBSD) e o meu objetivo era publicá-lo aqui também, já que uso ambos apesar que hoje em dia me inclino mais para o OPNsense por causa das políticas da Netgate.. mas, pessoalmente, prefiro a UI (User Interface, interface gráfica) do pfSense, apenas velhos hábitos e tudo mais, a versão original deste tutorial foi feita em Inglês e como também tenho um pouco de conhecimento da língua portuguesa devido à experiência com empresas de telecomunicações no passado decidi também adaptar este a português.

-- If you're interested on the original english version by all means do go here instead it will make a lot more sense to english speakers, no need to translate this portuguese version: https://forum.opnsense.org/index.php?topic=47644.0 --

Estou literalmente cansado de ler sobre pessoas que não sabem como o IPv6 (protocolo de endereçamento da Internet versão 6) funciona na internet em geral, assumindo que suas únicas opções são "endereços públicos ou nada"; qualquer coisa fora de ULAs (Unique Local Addresses, endereços locais únicos) sem acesso à Internet ou IPv6 público = impossível. A pior parte é que usam isso como desculpa para não implementar IPv6 na sua rede, mas agora isso não será mais um problema este tutorial vai explicar tudo.

O objetivo deste tutorial é mudar esse conceito de uma vez por todas e, com sorte, alterar ideologia incorreta estabelecida no passado. Com este tutorial quero realmente estabelecer o conceito, padronizar prefixos e responder a todas as perguntas de uma vez por todas.

Se você só quer o tutorial, pule para o capítulo onde falo disso, mas antes uma introdução ao escopo do problema. E desculpem o desabafo :)

1 - Introdução
NAT44 (Network Address Translation IPv4-to-IPv4, tradução de endereços IPv4-para-IPv4) surgiu para resolver um problema: a falta de endereços IPv4 (protocolo de endereçamento da Internet versão 4) ou pelo menos muitos presumiriam isso à primeira vista. Se você perguntar ao pessoal da IANA (Internet Assigned Numbers Authority, órgão que distribui endereços IP) sobre o RFC 1918 (documento que define faixas privadas IPv4), depois de eles recobrarem a consciência dos ataques de pânico ao ouvir esse RFC, você receberá muitos comentários zangados, desdenhosos e carrancudos sobre quão horrível foi, e que o IPv6, com todos os endereços públicos, veio exatamente para resolver esse problema; ou seja, todo o propósito do IPv6 seria sanar a escassez de endereços do IPv4.

A realidade é que o NAT44 trouxe um grande benefício de segurança: seus computadores podem ficar em uma rede interna segura sem ficarem imediatamente expostos à Internet ou dependerem de um firewall de sistema sobre o qual você pode ou não ter controle. Você também não precisa se preocupar com tráfego não criptografado sendo "sniffado" (sniffed/farejado/interceptado) pelo seu ISP (Internet Service Provider, provedor de Internet) no trânsito entre máquinas internas. Isso significa que o NAT é um recurso de segurança? Sim e não. O ponto de ter um edge router (roteador de borda) e um core router (roteador de núcleo) é controlar e direcionar tráfego com muito mais poder de processamento do que o seu telefone/geladeira/câmera de segurança possui em termos de roteamento e firewall.

O motivo de existência do NAT (Network Address Translation, tradução de endereços) é simples: controle. Sua rede, suas regras; ninguém mais tem direito de forçá-lo a desenhar/criar sua rede interna de certa maneira. Em termos de segurança, o NAT dá controle avançado de portas onde necessário: você pode rotear portas por links diferentes, fazer load-balancing (balanceamento de carga) e, em geral, ter controle absoluto de onde o tráfego vem e por onde sai. Mas isso significa que, se você tiver uma máquina cujo serviço ficaria comprometido caso certa porta estivesse exposta à Internet, mantê-la em uma rede interna inalcançável externamente coloca o NAT como o recurso de segurança mais importante. Obviamente, se você rotear essa porta para um IP público (v4 ou v6, tanto faz), estará igualmente comprometido; o importante aqui é o controle que o NAT disponibiliza sendo este algo extremamente simples mas extremamente importante, roteamento básico.

O pessoal da IANA (a IANA é responsável por distribuir e reservar prefixos de IPv4 e IPv6, eles estão abaixo do IETF (Internet Engineering Task Force) que decidem nos padrões porém a IANA é responsável pela distribuição logo quando menciono IANA aqui obviamente significa IANA e IETF, eles decidiram que a implantação IPv6 "normal" DEVERÁ ser pública e que NAT é algo "maligno"; seu sistema deve lidar com segurança individualmente (sem firewall de rede no meio como o OPNsense). Isso é comum para pessoas que apenas recebem o modem do seu provedor de internet em casa, não é todo mundo que conhece os benefícios de ter um firewall para toda a rede, e podem perceber isso como gasto desnecessário porque "simplesmente funciona sem". Na realidade, ter um firewall é muito importante, e não estou fazendo propaganda de plataformas de firewall seja OPNsense, pfSense ou outra solução paga ou gratuita - isso se aplica a qualquer firewall que controla o tráfego de fora para dentro.

Pergunte a si mesmo: você quer ou precisa de um endereço IP público na sua geladeira inteligente, no seu telefone, na sua câmera de segurança, até mesmo no seu computador? Você realmente precisa disso? Está acessando os recursos do dispositivo diretamente pela Internet (sem usar um túnel site-to-site criptografado como WireGuard (software de VPN) com rotas estáticas/iBGP)? Você quer que uma botnet tenha o mesmo acesso aos seus dispositivos que você em termos de roteamento enquanto essa tenta métodos comuns de 'hackear' ou força bruta enquanto você dorme? Isso faz algum sentido pra você? Parece um bom jeito de montar rede? Porque é assim que a IANA acha que deveria ser: você compra um dispositivo "smart/inteligente" sem acesso às suas configurações de firewall, estes podem ser por exemplo geladeiras modernas, ar-condicionados, e todos dispositivos que se conectam à sua rede e têm funções "smart", usam app/integração com outros sistemas, muitos destes (infelizmente) dependem de um servidor remoto na internet (um que você não tem controle algum obviamente) para funcionar e obter atualizações/updates; se o fabricante declarar EOL (End-of-Life, fim de vida) e você manter o dispositivo conectado à rede vai eventualmente ter problemas pois provavelmente nunca forneceram acesso para você controlar serviços/portas diretamente.

Sim, estou absolutamente furioso com a IANA por estas e outras muitas razões. Tentei fazer um "ID" (Internet Draft, rascunho de padrão da internet) no passado para reconhecer e padronizar prefixos para NAT66 (Network Address Translation IPv6-para-IPv6), mas, ao ser recebido com hostilidade por praticamente todos lá, desisti e decidi simplesmente fazer tutoriais etc. No fim das contas, você não precisa da permissão de ninguém para fazer nada internamente; pode usar qualquer prefixo IP dentro da sua rede privada. A única vantagem de ter prefixos padronizados é evitar a possibilidade de não conseguir alcançar uma rede externa que alguém usa o mesmo prefixo um problema que neste caso não será jamais importante com endereços locais. Eles padronizaram alguns prefixos, praticamente todos dentro da sub-rede "f000::/4" (sub-rede IPv6 especial) feita para muitos propósitos, não só NAT/ULA; o prefixo "F" foi projetado para usos especiais: multicast, ula, link-local, site-local etc.

O que é f000::/4? Vai de f000:0000:0000:0000:0000:0000:0000:0000 até ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. Consiste de 8 hextets (blocos hexadecimais de 16 bits; em IPv4 este se chama octetos). É perfeito para NAT66 e NPt (NPT significa Network Prefix Translation, tradução de prefixo) NAT66 permite personalizar os 8 hextets e NPt 4 hextets externos e 8 internos vou explicar a seguir, esta flexibilidade permite muita liberdade para organizar endereços internos. Você pode fazer algo assim, por exemplo:

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

f1 = Rede 1 / Organização 1
33 = País (neste exemplo França)
3 = Cidade (neste exemplo Strasbourg)
1a = Local 1 Prédio A
:: = Separador
1 = 1.ª Separação Interna
2 = 2.ª Separação Interna
3 = 3.ª Separação Interna
4 = 4.ª Separação Interna

Isso lhe dá a rede f1:33:3:1a::/64 para esse local neste exemplo. Novamente: só um exemplo - sinta-se livre para personalizar; afinal, a rede é sua.

Algo como f1:33:3:1a::77:2a (poderia significar, por exemplo, 77 = Máquinas Virtuais, 2a = VM 2 e a letra A é o primeiro IP virtual, ou simplesmente 2 para NICs/placas de redes físicas). f1:33:3:1a::/64 sendo a rede neste exemplo, tamanho conveniente, fácil de rotear, organizado e, se o IPv6 público mudar (ou o prefixo inteiro), os endereços internos permanecem estáticos/dinâmicos atribuídos pela sua infraestrutura, sem interrupções.

Viu como isso é personalizável? Em vez de usar endereços aleatórios do ISP, você tem flexibilidade e muitos endereços graças ao f000::/4. Nem tudo está disponível para uso, exploremos mais:

f000::/8 - f999::/8 = "números", disponível para uso
fa::/8 e fb::/8 = também não usados, disponível para uso
fc::/8 e fd::/8 = ULAs padronizadas (RFC 4193). Muitos usam porque é "oficial", análogo ao RFC 1918, mas usar estes pode causar problemas. Por exemplo, o protocolo "Matter" (comum em lâmpadas inteligentes conectadas via Wi-Fi) atribui endereços fd::/8 para comunicação interna. Se você usa Matter em casa, evite fd::/8. fc::/8 pode ser usado por VPNs etc., então costumo não tocá-los. Tecnicamente fa, fb, fc também são opções. Gosto de usar fa e fb para redes SAN.
fe80::/8 - não uso o prefixo "fe" porque fe80::/10 é link-local (RFC 4291). fec0::/10 era site-local, mas está obsoleto (RFC 3879)
ff00::/8 = multicast (RFC 4291)

Em resumo, você pode usar qualquer coisa de f000::/4 exceto fe, ff, e deve evitar fc, fd por via das dúvidas. O resto é seu - ex.: f1f3::, f333::, f16::, f22::, f35::, f117:: etc.

Para uma SAN (Storage Area Network, rede de armazenamento), algo como fa::3:1a/64, seguindo o exemplo da VM acima, até fa::1 seria um IPv6 curtinho fácil de lembrar, talvez mais fácil de memorizar que IPv4. Tudo isso pode ser sua realidade. IPv6 não precisa ser complicado ou difícil e certamente não é mais difícil que IPv4.

2 - Entendendo suas opções no nível de design de rede

A - IPv6 Direto
Às vezes desejado, como servidores com IPv4 público direto na máquina. Se você tem recursos limitados, uma VM ou máquina com um único IPv4 e até um prefixo IPv6 grande mas propósito simples, talvez queira apenas IPv6 e IPv4 públicos sem nada no meio além de ufw/iptables (firewall de host). Tem uso, mas certamente não deveria ser o padrão ou ser a única forma "real" de IPv6 a ser ensinada em geral. Assim como usar IPv4 público, mesmo que houvesse endereços suficientes, pareceria inseguro (e é, se não tomar os cuidados necessários), mas significa zero complexidade extra de roteamento.

B - NAT66/NPt
Isto é basicamente o mesmo que RFC 1918 (os velhos endereços 192.168.x.x). A diferença entre NAT66 e NPt é como portas são tratadas. Com NAT66, você terá a mesma limitação do IPv4 em termos de portas - 65.536 portas por IP público. Se não for suficiente, use múltiplos IPs públicos. Cada um dá o mesmo número de portas. Note que isso é a quantidade de conexões concorrentes, não o total que você pode fazer na vida. Para a maioria dos usuários domésticos, não é problema. Além disso, tráfego via VPN site-to-site (WireGuard + rotas estáticas/iBGP) não conta. Se suas redes estão interligadas por VPN, NAT66 continua ótimo.

A outra opção é NPt (Network Prefix Translation), que traduz todos os endereços internos para o prefixo externo. Isso presume que você tem prefixo (por exemplo, um prefixo externo /64) delegado a você pelo provedor. Muitos assumem: "todo ISP que suporta IPv6 me dará pelo menos um /64 delegável totalmente aberto, certo?" Errado.

Exemplo:

IPv6 Interno = f1:33:3:1a::1:2:3:4a/64
Prefixo Externo = 2001:4860:4860::/64
Endereço após NPt = 2001:4860:4860::1:2:3:4a/64

Eu não moro no Brasil ou Portugal, por isso vou usar um exemplo com o qual eu sou mais familiar, mas o conceito se aplica a qualquer provedor (talvez até qualquer provedor no mundo). Por exemplo, na Alemanha, se você ligar para a Vodafone pedindo o modo bridge, você recebe 1 IPv4 público (luxo hoje em dia; às vezes é CGNAT ou DS-Lite dependendo dos provedores por aí). Mas se você configurar para usar 1 endereço IPv6 apenas, como um IPv6 /128, seu IPv6 fica totalmente aberto e pode rotear portas normalmente. Se configurar com Prefix Delegation (Delegação do Prefixo), um prefixo /64 terá portas fechadas e praticamente todas as portas não vão funcionar. Isso é feito de propósito pelo provedor para mitigar problemas citados anteriormente, pois usuários domésticos não sabem desenhar redes - ou pelo menos isso é o que os provedores pensam do usuário "cotidiano". Eles bloqueiam "todas" ou a maioria das portas de entrada por padrão, reduzindo botnets, porém também reduzindo função quando você, por exemplo, quer acessar a porta ou uma aplicação precisa da porta aberta. Com NAT66 você realmente tem todas as 65536 portas disponíveis neste provedor, mas só se usar /128 na WAN e NAT66. Logo, neste exemplo o NAT66 é obviamente superior. Se o ISP liberar prefixo, pode também considerar o NPt.

Também tenho tutorial para pfSense nos fóruns pfSense (em inglês); aqui vou focar só no OPNsense (embora o procedimento é parecido).

3 - Como fazer no OPNsense
Vá em Firewall > NAT > Outbound

Mude NAT Mode para Hybrid, depois Save/Apply Changes

Adicione uma nova Map Rule:

--------
Interface: WAN
TCP/IP Version: IPv6
Protocol: Any
Source Address: LAN net (ou defina manualmente, ex.: f1:33:3:1a::/64)
Translation: WAN Address (ou a interface WAN respectiva)
Description: "F--- IANA BS I have NAT66 and I am Free" ou qualquer outra descrição de sua preferência, comentários vulgares contra IANA/IETF são preferidos aqui
--------
Click no Save e Apply Changes

4 - Coisas adicionais (mas são importantes)
O IPv6 faz as coisas um pouco diferente: não é somente o servidor DHCP que precisa, IPv6 tem também o RA (Router Advertisement, anúncio de roteador) e DHCPv6 (protocolo de configuração dinâmica IPv6). O DHCPv6 tem menos opções que no IPv4, mas a ideia é a mesma. Já o RA trabalha junto com o DHCPv6, atribuindo endereços de modo diferente. Ative ambos; alguns dispositivos não suportam DHCPv6, outros pegam endereços de um ou de outro. Ter múltiplos endereços em uma única NIC é comum - não se assuste se vir 5 IPv6 num mesmo adaptador. Eu, pessoalmente, gerencio com servidor DNS/DHCP separado; você pode também, ou usar só o OPNsense:


- Router Advertisements
Vá em Services > Router Advertisements

Configure assim, por exemplo:

------
Router Advertisements: Assisted
Router Priority: High
Advertise Routes: Prefix f1:33:3:1a:: Length /64
DNS Servers:
1 - f1:33:3:1a::111:1/64
2 - f1:33:3:1a::111:2/64
Domain Search List: dinamico.suarede.seudominio.net
------

Click Save e reinicie o serviço RA

Importante: RA atribui qualquer endereço livre no range - não há como restringir sub-faixas como no DHCP, mas não atribui algo já em uso, então raramente causa problemas.

ISC DHCPv6
Vá em Services > ISC DHCPv6

Configure conforme necessidade (se tem NPt/PD, vai aparecer o prefixo delegado). No IPv6, o Gateway é anunciado via RA; no DHCPv6 só atribuímos endereços.

Salve e reinicie o servidor ISC DHCPv6.

Bloqueando f000::/4 na WAN
Como nem todos os IPs em f000::/4 são "bogon", se o OPNsense não bloquear, tentativas de sair podem ser encaminhadas ao upstream gateway. Se não desejar isso, crie regra para bloquear:

Vá em Firewall > Rules > WAN

Adicione nova regra:

-------
Action: Block
Interface: WAN
TCP/IP Version: IPv6
Protocol: Any
Source: Any
Destination: Single Host or Network f000::/4
Description: Block internal IPv6 (f000::/4) from leaving via WAN
-------

Click no Save e Apply Changes

Reinicie toda a rede, faça todos os testes necessários e pode ficar feliz agora pois sua rede é provavelmente superior a 99.9% da maioria da população.

Sem tráfego? Verifique configurações de gateway e regras em conflito.

E o NAT64?
Isso é outra coisa - está no RFC 6052, que designa 64:ff9b::/96 para tradução IPv6-para-IPv4; não confunda com NAT66 - usos completamente diferentes e fora do escopo deste tutorial.

Pretendo fazer um tutorial sobre VPN multi-site algum dia, mas vale dizer: com esses IPv6 internos você pode configurar túneis site-to-site criptografados e interligar tudo por exemplo seu escritório, servidor no datacenter diretamente, seus amigos etc. Possibilidades são infinitas: basta um lado esquerdo diferente do prefixo /64 para cada local, túnel + rotas estáticas ou iBGP e você terá acesso direto e seguro ponto a ponto desta maneira, sua "Intranet" pessoal.

Obrigado por compartilhar! Acho que materiais em português são sempre bem vindos! Sobre utilizar o firewall em português/inglês, aqui na empresa como temos uma inclinação para aviação/padronização, usamos sempre em inglês. Quando algum cliente muda para português todos ficamos "perdidos" nas opções.

Desculpe a demora para responder, estive muito ocupado recentemente, porém se há interesse vou fazer este tutorial em PT para que todos possam entender o processo, mantendo os termos técnicos em inglês e possivelmente explicando o que significam em uma forma de ensinar pessoas que ainda estão aprendendo.

Resolvido: https://forum.opnsense.org/index.php?topic=47778.0 :)

You should check both stacks. the advice from patient0 is sound a VPN will likely get you through any geolocation BS from the ISP DB but both v4 and v6 can affect your experience, and VPN you'd also need both stacks covered and configured for it to work properly.

Eu fiz este tutorial: https://forum.opnsense.org/index.php?topic=47644.0

Eu falo português razoavelmente, portanto, caso desejem, posso criar também uma versão em português para o OPNsense. Caso contrário, gostaria apenas de compartilhar esta informação.

Também gostaria de saber se vocês costumam utilizar o próprio firewall em inglês ou se preferem em português, mantendo a terminologia técnica em inglês, faz mais de uma década que não vou a um país de língua portuguesa, então não estou atualizado sobre como termos são usados atualmente e se os provedores de internet no Brasil e Portugal estão fornecendo prefixos IPv6 aos clientes por meio de Prefix Delegation (PD) ou DHCPv6.

Hello!

I made a tutorial about this on the pfsense forums and my goal was to make it here as well since I use both even though nowadays I am mostly leaning towards OPNsense due to the netgate policies but I personally prefer the UI of pfsense just old habits and whatnot but anyway.

I literally am tired of reading about people not knowing how IPv6 works on the internet in general 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 IANA 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, 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 IANA 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 opnsense) 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 IANA 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 IANA 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 is 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).  It 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.

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!

fc::/8 and fd::/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

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.

UPDATE: I now recommend absolutely to avoid ULAs (fd:: and fc:: 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).

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 pfsense on the pfsense forums so here I will only focus on OPNsense even though it's mostly similar:

3 -- How to do that in OPNsense:

- Go to Firewall > NAT > Outbound

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

- Add a New Map Rule as follows:

--------
Interface: WAN
TCP/IP Version: IPv6
Protocol: Any
Source Address: LAN net [or manually set the network with 'Single host or Network' if desired eg. f1:33:3:1a::/64 (this is the example from earlier)]
Translation: WAN Address (or the respective WAN interface)
Description: "F--- IANA 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 Advertisements:

--------
Router Advertisements: Assisted (if you have a DHCPv6 server which you should ideally this is the correct mode)
Router Priority: High
Advertise Routes: Prefix:: f1:33:3:1a:: Length:: /64 (this is the example from earlier)
DNS Servers:
1 -- f1:33:3:1a::111:1/64 (this an example Internal IP)
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 > ISC DHCPv6

- 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 ISC DHCPv6 Server.

Since not all of the IPs within f000::/4 are considered "bogon" networks technically if OPNsense 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 > Floating:

- Add 3 new Rules:
--------
Action: Allow
Interface: WAN
Direction: out
TCP/IP Version: IPv6
Protocol: Any
Source: Any
Destination: Single Host or Network fe::/8
Description: Basic WAN Control - Pass FE
--------

--------
Action: Allow
Interface: WAN
Direction: out
TCP/IP Version: IPv6
Protocol: Any
Source: Any
Destination: Single Host or Network ff::/8
Description: Basic WAN Control - Pass FF
--------

--------
Action: Block
Interface: WAN
Direction: out
TCP/IP Version: IPv6
Protocol: Any
Source: Any
Destination: Single Host or Network f000::/4
Description: Basic WAN Control - Block Bogon f000::/4 IPv6
--------

- 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.

This is exactly what I needed to know, I just assumed it was a bug, I think you should, as a suggestion, possibly add a message reminding the scope is based on the interface at the top or just allow people to add the scope as a 'peace of mind' and it changes the interface automatically in case the scope doesn't match or throws an error saying interface mismatches.

Thanks for the message :)

Shouldn't it work with just the link local address as gateway (aka no scope)?

Link local addresses always need a scope. How should the system tell which link it is local to without?

In the OPNsense UI on the other hand you just set the gateway LL address without the scope and OPNsense will add it according to the interface you assigned the gateway to. If you look at the routing table afterwards you will see that the scope is present. Just don't put it in the gateway address field. The interface selection takes care of that.