Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am a sysadmin who has been slowly preparing for IPv6 as an eventuality, and have read quite a bit on it, though I admit there is much more to learn. That being said, and knowing that the industry says otherwise, I disagree on the seemingly accepted state that we should get rid of nat for ipv6, for a few key reasons.

1. Yes, browsers and other things will leak your private ip space sometimes, but nat does indeed provide a level of security simply due to complications in routing issues for attackers. Its certainly only a base layer, but it does help.

2. In many situations, we dont want devices on the internet at all, and on private only networks. This is doable with site private, but that brings me to

3. There is a lack of clearly communicated best practices for the industry. To the pont that adoption is almost nill. I recently had a private network setup via ATT, and they said I was the first customer on that network type to request ipv6...

4. Knowing how heavily the NSA was involved in ipv6 (in particular ipv6 ipsec), I have my concerns about the protocol itself, albiet as of yet unverified doubts. The corruption of NIST committees is a very serious thing to me.

5. As the admin, I want to be able to see non encrypted traffic and metdata traversing my exit points. I am having a harder and harder time diagnosing IPv6 because of how often it wants to tunnel to some ipv4 address that I dont trust (read: microsoft).

I know that all these points are fairly weak and suspect to criticism, but what gets me is that I dont hear this discussion. Instead I just hear either how ipv6 is god and you should embrace its loving arms, or I see people just sticking their head in the sand who say, I dont like it so Im going to ignore it and hold on to my ipv4 blocks until they make me.

Im open to conversations on the topic, and my list is larger but Im on mobile and late for fixing some ipv4 networking issues .



> 2. In many situations, we dont want devices on the internet at all, and on private only networks. ...

Unique Local Addressing (RFC 4193) solves this problem and requires no coordination with outside parties. The network admin gets to choose the scope of the ULA prefix, so you can trivially make your ULA traverse multiple LANs if you wish. (This addresses your first point, too.)

> 3. There is a lack of clearly communicated best practices for the industry.

Eh? This is the first hit for "IPv6 BCP": https://www.apnic.net/community/ipv6-program/ipv6-bcp

> 4. Knowing how heavily the NSA was involved in ipv6 (in particular ipv6 ipsec)...

Then -uh- don't use IPSec and block IPSec connection establishment attempts at your border firewalls. Or, because implementation of IPSec is -sadly- not a requirement for IPv6 implementers, use an IPv6 implementation that doesn't implement it.

Edit: You are aware that OpenVPN uses TLS for session authentication and IPSec for transport of tunnelled data? :)

> 5. As the admin, I want to be able to see non encrypted traffic and metdata traversing my exit points. I am having a harder and harder time diagnosing IPv6 because of how often it wants to tunnel to some ipv4 address that I dont trust (read: microsoft).

Are you talking about IPv6 over Teredo tunnels? If you are, then get a packet dump and fire up Wireshark... Teredo doesn't encrypt the traffic that it tunnels. If you aren't, and you're talking about something that's wrapping traffic in TLS, then -well- that doesn't have anything to do with IPv6.


I knew I was going to get flak for this, butnit has inspired me to dig into it further and I plan to come back with stronger points... Or perhaps Ill realize I was wrong and change my mind. Thanks for all the responses though, I have some reading and thinking to do.


4. Knowing how heavily the NSA was involved in [..] ipv6 ipsec, I have my concerns about the protocol itself

That's not an issue against IPv6. The entire ipsec standards were backported to IPv4, by people from the same organizations. There is no reason to assume IPSECv4 is any less tainted.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: