1

As a sysadmin, I'm fairly experienced with IPv4. As such, I feel comfortable configuring firewalls to expose servers/services to the Internet with public IPv4 addresses.

I have a basic understanding of IPv6 addresses and name resolution in IPv6. Also, I understand that I can use TCP, UDP and ICMP in the same way as with IPv4, just with "a longer address", and that, due to the abundance of addresses, NAT is no longer necessary nor recommended (making properly configured firewall rules even more important).

So far, I have not enabled IPv6 for our public web services, since (a) it was not necessary (and, to be honest, it still isn't) and (b) I lack the years of experience I have with IPv4, which makes me less confident to be able to do this without opening some gaping security hole. However, it's 2022, not being available on IPv6 feels a bit embarrassing, and I won't get years of experience if I don't ever start.

In a nutshell, my question is: Can I use my IPv4 knowledge (and the basics mentioned above) to securely make an Internet service available to the public via IPv6, or are there some additional topics that I really should learn about first before "flipping the switch"?

Heinzi
  • 2,217
  • 5
  • 32
  • 52
  • "_I understand that I can use TCP, UDP and ICMP in the same way as with IPv4, just with 'a longer address'_." You can also use other existing or future protocols that you cannot with IPv4 on the public Internet because IPv4 NAPT only supports TCP, UDP, and ICMP. Many people would love to use SCTP, but NAPT has stifled innovation. QUIC had to be developed on top of UDP because of that, but a future version of QUIC on IPv6 could be its own transport protocol. – Ron Maupin Oct 13 '22 at 21:29

2 Answers2

2

Can I use my IPv4 knowledge (and the basics mentioned above) to securely make an Internet service available to the public via IPv6

Yup, definitely.

There is, however, one major security consideration when flipping the switch for IPv6 address family: by default IPv6 operates public address prefixes, so you may consider using unique-local (RFC 4193) prefixes for any private LANs (if you have any) behind your routers.

As for public-WAN-connected servers - well, same security/packet filter measures apply.

drookie
  • 8,625
  • 1
  • 19
  • 29
  • I'd add an often overlooked problem: firewalling all ICMPv6. In IPv4 it's already not great to firewall any ICMP (can at least cause PMTUD problems), but in IPv6 it's fatal since NDP which replaces IPv4's ARP is ICMPv6-based. – A.B Oct 07 '22 at 15:30
  • Just don’t filter any icmp: filtering icmp is an urban legend, taking its source in the fact that Windows 95 non-OSR2 was known to trap when receiving fragmented icmp frame. – drookie Oct 07 '22 at 17:18
  • _[RFC 4890, Recommendations for Filtering ICMPv6 Messages in Firewalls](https://www.rfc-editor.org/rfc/rfc4890)_ explains which ICMPv6 messages should or should not be filtered. – Ron Maupin Oct 09 '22 at 04:00
  • 1
    I wouldn't use unique-local for LAN. It is easier just to configure default deny rule when going from WAN to LAN. I will however enable SLAAC since it makes all hosts with non-static ip address practically immune against discovery through ip address scanning. – Lasse Michael Mølgaard Oct 13 '22 at 21:07
1

One of the most prolific authors in the IPv6 security domain is Fernando Gont. He (co-)authored several RFCs, Internet Drafts and other documents and gives talks on IPv6 in general and IPv6 security. Among his technical reports you have "IPv6 Security for IPv4 Engineers" (PDF) and an "IPv6 Security FAQ" (PDF), both from 2019, that you may find useful.

Dubu
  • 621
  • 3
  • 12