Security Implications of Using IPv6 GUAs Only

Mon, 01 Dec 2014 00:00:00 +0000

When planning for IPv6 addressing, many organizations – rightfully & wisely – decide to go with global unicast addresses (GUAs) only (hence not to use unique local addresses/ULAs as of RFC 4193 at all), in order to avoid address selection hell or just for simplicity & consistency reasons. This post discusses security implications and complementary security controls of such an approach.

In their IPv4 networks, most of these organizations currently use RFC 1918 space, combined with NAT for specific connections or use cases. Ideally NAT is only in place “where strictly needed”, in practice it’s often used as a kludge to conceal of all types of bad network design or debatable application architectures. I won’t enter the “is NAT a security control?” debate here, one statement might be allowed though: as of section 3 (“Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links.”) RFC 1918 space is usually not reachable from the Internet. So using such address space for internal networks is a nice example of the isolation principle as of the “Seven Sisters” approach we like to use. Now, bringing NAT into these networks enables connections (usually between trusted and untrusted networks) which simply would not be possible without it [NAT], so this actually breaks the isolation property. Question: how can one ever call something that increases the number of possible interactions between assets and potential attack originators a ‘security control’?!

Routing on Insinuator.net - Bold Statements

Security Implications of Using IPv6 GUAs Only