Check Point Whitepaper Enterprise IPv6 Transition Technical Whitepaper
Contents Introduction 3 Transition Mechanisms 3 Dual Stack 4 Tunneling 4 Translation 7 Recommendations 8 Transition Security Considerations 9 For Further Reading 9 2
Introduction IPv6 is starting to be deployed. The pool of unallocated IPv4 addresses is shrinking rapidly. The last block of IPv4 addresses from the ICANN Assigned Numbers Authority (IANA) was assigned on January 31, 2011. It is expected that the Regional Internet Address registries will have assigned their last blocks of IPv4 addresses in the next 12 months. IPv4 addresses will become much harder to obtain for most enterprises and large block needed by ISPs will be close to impossible to obtain. In the Asia/Pacific region the APNIC Regional Registry is essentially out of IPv4 addresses. This is expected to happen in North America and Europe in the next 12 months. We are approaching the day when new Internet users will only be able to obtain IPv6 addresses. Due to this shortage of IPv4 addresses, IPv6 is starting to be deployed widely. It is available in most infrastructure products including host operating systems, routers, switches, firewalls, load balancers, and similar equipment. Large content producers, such as Google, Yahoo, and Facebook are starting to provide their content over IPv6. Many Internet Service Providers (ISPs) are now providing native IPv6 service. For example, AT&T has a number of IPv6 transition and network design services targeted at business and government customers. Their marketing information, available online, not only presents their offerings but also includes information explaining why a move to IPv6 is important. AT&T certainly is not alone in offering these services. British Telecom, Verizon, Deutsche Telekom, NTT, Hurricane Electric and others also provide IPv6 transition and consulting services. While there are not many Enterprise wide deployments of IPv6 today, it is the time for Enterprise networks to start planning their IPv6 deployment. There are many transition mechanisms that have been defined to enable the transition from IPv4 to IPv6. These range from dual stack, tunneling based solutions, various forms of header translation, and some that combine several approaches. It is not straightforward for an Enterprise network IT department to select the best transition mechanisms for their network. Each transition scenario is designed for a range of environments and has a mix of advantages and disadvantages. The purpose of this whitepaper is to provide an overview of the current IPv6 transition mechanisms and make recommendations on the transition mechanisms that are appropriate for most of Check Point s Enterprise customers. It also discusses the security considerations of these IPv6 transition mechanisms so they do not create new security vulnerabilities. Transition Mechanisms A broad range of IPv6 transition technologies have been developed. At the general level these mechanisms are designed to make it easier to transition from IPv4 to IPv6. This is necessary because there isn t a direct way to interoperate between an IPv6 node and IPv4 node. Some people blame IPv6 for lacking this capability, but the problem is actually with the design of IPv4. It was not designed to allow any forward capability. 3
The transition mechanisms fall into three classes: Dual stack Dual stack is the concept of running IPv4 and IPv6 at the same time in parallel. That is, IPv4 and IPv6 packets will flow over the same wire and are transmitted/received on the same interface. Tunneling Tunneling is the concept of running one protocol over another. For example, carrying an IPv6 packet as the data portion of an IPv4 packet. Translation Translation is the concept of translating one protocol to another, like Network Address Translatioin (NAT). For example, translating an IV4 packet into an IPv6 packet. There are also some hybrid technologies that combine several of the techniques, but they are not relevant for Enterprise environments and are not discussed in this white paper. Each class of transition mechanism has advantages and disadevantages, and is designed for specific scenarios. Dual Stack Dual stack is the concept of running IPv4 and IPv6 concurrently. This is the first transition strategy developed by the Internet Engineering Task Force (IETF). An example of this is shown in the following Figure 1: Figure 1. Dual Stack When Dual Stack was designed, it was assumed that the Internet would run IPv4 and IPv6 concurrently before it ran out of IPv4 addresses. For a variety of reasons this has not happened and in general has made the transition to IPv6 more difficult. However, because the current Internet is still running IPv4 (e.g., there is very little if any IPv6-only infrastructure), it is still the best transition strategy for most networks. This is especially true for Enterprise networks. As long as a site has some global IPv4 addresses, Dual Stack should be the core of an Enterprise networks transition strategy. 4
Tunneling There are a number of different IPv6 tunneling mechanisms. They are used to allow one type of protocol to cross a part of the Internet that does not support it. For example, one common case allows a home or small remote office to get access to IPv6, when the ISP does not yet provide support for IPv6, to tunnel IPv6 packets inside of IPv4 packets in order to reach the part of the Internet that does support IPv6. This is shown in Figure 2. Figure 2. IPv6 in IPv4 tunnel Another use of IPv6 over IPv4 tunnels that are useful in Enterprise networks is to use it to bridge the parts of the Enterprise network that are IPv4 only. In some cases, it may not be possible to completely convert an Enterprise network to run dual stack, as there will be parts of the network that may remain IPv4 only. In this case, IPv6 over IPv4 tunnels can be used to cross the portions of the Enterprise network that don t support IPv6. A variant of this is used to carry IPv4 over IPv6. If an ISP has decided to convert their core network to IPv6 only, they will still need a way to carry their customers' IPv4 traffic until all of their customers have support for IPv6. IPv4 in IPv6 tunneling is being considered by large ISPs who can no longer get enough IPv4 addresses to run their internal network; this isn t an approach that will be useful by most Enterprise networks for some time to come. There are two sub-classes of tunneling, configured tunnels and automatic tunneling. These are described in the following sections. Configured Tunnels Configured are tunnels that are manually configured and do not change. They are created by an end user in the case of a host or by a network administrator in the case of a router. The current defined types of static tunnels include: IPv6 in IPv4 tunnels [RFC4213] Generic Packet Tunneling in IPv6 Specification [RFC2473] Tunnel Brokers [RFC3053] IPv6 over MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798] 5
IPv6 in IPv4 is the main approach to tunnel IPv6 in IPv4. Similarly, Generic Packet Tunneling in IPv6 is the main approach to tunnel IPv4 in IPv6. These may be host to host, host to router, or router to router. These tunnels are very similar to VPNs except they do not secure or authenticate the traffic. IPSEC VPN technology can also be used to create secure and/or authenticated tunnels. Unencrypted tunnels are appropriate inside an Enterprise, but using VPN technology is preferred for creating tunnels between the main Enterprise network and remote sites. This parallels the approach taken with IPv4 VPNs. These tunnels are shown in the following figure: Figure 3. Configured IPv6 in IPv4 tunnel Tunnel Brokers are intermediaries that are designed to create and terminate tunnels for access to the public Internet. There are versions of these that support configured tunnels such as provided by Hurricane Electric [HE], SixXS, and others such as part of 6RD automatic tunnels that are deployed by certain ISPs. Both work well and can provide access to the IPv6 Internet when native dual stack is not available from an Enterprise s ISP. There are other types of configured tunneling mechanisms such as 6PE. These tunneling mechanism are designed for ISPs and aren t useful for Enterprise networks. 6PE allows IPv6 traffic to be carried over an ISP's MPLS network. Automatic Tunnels Automatic tunnels are automatic in the sense they don t have to be manually configured. Generally this means that they can be enabled with very little user input; essentially just turn it on. This is a good way to make it easy to give IPv6 access to hosts or networks that aren't IPv6 enabled or if the local ISP cannot provide IPv6. Various versions of these mechanisms have shipped in major operating systems such as Windows Vista, Windows 7, and MacOS X. These include: 6to4 [RFC3056] Teredo [RFC4380] ISATAP [RFC5214] IPv6 Rapid Deployment (6RD) [RFC5969] 6
6to4 is like basic configured IPv6 in IPv4 tunnels, except that the destination is sent to the anycast address of remote end of the tunnel instead of a unicast address. This has the advantage of making it easy to setup, but requires that enough tunnel servers be deployed to provide a reliable service. While easy to setup, its reliability is only as good as the tunnel relay. While 6to4 tunnels are used widely today, reliability problems are fairly common. For this reason, they are not recommended for Enterprise environments or other environments [RFC6343]. Teredo tunneling uses UDP encapsulation in order to make it work through IPv4 Network Address Translators. Teredo tunnels are enabled by default in Windows Vista and Windows 7. ISATAP is designed for use inside of a site, unlike 6to4 and Teredo that are designed to work between sites. ISATAP works by treating the IPv4 network as a virtual IPv6 link. While ISATAP is an interesting approach, it has some obvious scaling limitations and isn t recommended for Enterprise networks. IPv6 Rapid Deployment (6RD) is similar to 6to4 except instead of a global IPv6 prefix and anycast address for the tunnel endpoint, it uses the prefix and tunnel endpoint address of the ISP that is providing the service. Instead of running over the global Internet it runs in a single provider. Due to these differences, this kind of automatic tunnel is much more reliable than 6to4 tunnels and is recommend in environments where they are provided by a service provider. Translation Translation is a technology that is similar to what is called Network Address Translation (NAT), but in the case of IPv6, has IPv4 on one side and IPv6 on the other, instead of the traditional IPv4 NAT where it has IPv4 on both sides. Variants of this include: NAT64 (IPv6 to IPv4) NAT46 (IPv4 to IPv6) NAT66 (IPv6 to IPv6) Using this terminology, today s IPv4 NAT would be called NAT44. NAT64 is based on the idea that if you have IPv6 it s fairly straightforward to map an IPv4 address into an IPv6 address because the IPv6 address space is so much larger than the IPv4 address space. NAT64 can provide the same level of service that is provided by today s NAT44. This will allow an IPv6 only node to reach the IPv4 Internet in the same way as an IPv4 node with a private address can reach a web server on the Internet that has a public IPv4 address. The main usage of this technology is for IPv6 only nodes and networks to get access to the IPv4 Internet. This is not likely to be very useful for Enterprise networks in the short term as they have IPv4 addresses (public or private) and can access the IPv4 Internet using IPv4. It may be useful in the future as Enterprises decide to transition their networks to IPv6 only. For example, it would be useful to connect to extranet partners and subsidiary networks who did not support IPv6. Transiting to IPv6 might allow an Enterprise to sell their public IPv4 addresses to someone else. NAT46 is a more specialized version of a translator. Unlike the NAT64 translator it is not possible to represent the whole IPv6 address space in IPv4. If this were possible, then it wouldn t have been necessary to create a new version of IP with larger addresses. The main use of a NAT46 translator is to provide access to an IPv6 only server from an IPv4 only network. This is not expected to see widespread usage and is not recommended for Enterprise networks. 7
NAT66 is a relatively new idea because IPv6 was originally designed to eliminate the need for Network Address Translation. This is because the original reason for NAT in IPv4 was to get around the scarcity of IPv4 addresses. NAT allowed private IPv4 addresses to be used inside of a site and only a few public IPv4 addresses on the outside of the site. IPv6 is designed to eliminate any scarcity of IP addresses and there isn t any need to deploy NAT for that reason. The reason NAT66 is being evaluated is that NAT also had the property of obscuring the addresses being used inside of a site. That is, it is very difficult to tell what the topology of the site is by looking at packets sent to public sites on the Internet. Consequently NAT66 is being considered to provide that capability. It is too early to make any recommendations on this to Enterprises, as there isn t enough experience with this technology at the present time and there are other ways that IP adresses leak out of sites (e.g., email headers, web cookies, etc.). Recommendations There are many technology choices available when designing an IPv6 transition plan for an Enterprise network. This section makes recommendations as to the transition mechanisms that are appropriate for most of Check Point s Enterprise customers. The majority of Check Point s customers should use Dual Stack as the core of their transition plan. They should run IPv4 and IPv6 concurrently on their network. This is the simplest approach overall to deploy IPv6, and is the easiest to manage and debug. Security policies can be implemented for IPv6 that match the security policies implemented for IPv4. Internal services can be made available on IPv6 in a gradual manner. Clients that are not able to run IPv6 will still be able to access services via IPv4. The best approach for IPv6 Internet service is native Dual Stack IPv6 (along with IPv4) from the Enterprise s current ISP. If this is not available, a configured tunnel can be setup to an existing tunnel broker service. This is preferred over an automatic tunnel service as it will be more stable and reliable. Configured tunnels or preferably secure VPN based tunnels should be used to connect to remote Enterprise sites if native IPv6 service is not available to the remote sites. IPv6 based VPNs should be used when native IPv6 is available. Automatic tunneling solutions are not recommended for use in Enterprise networks. While they are included in most host operating systems such as Windows Vista, Windows 7 and MacOS X, they generate IPv6 traffic that may create security vulnerabilities because they can be setup by the user without the knowledge and consent of the network administrator. A good general tunnel security policy is to not allow automatic tunnels by default, and only allow specific tunnel instances. Translation solutions are not recommend as part of an Enterprise IPv6 transition plan. They are best suited to environments where there is very limited availability of IPv4 addresses. This is not the case for most Enterprises who are running their network today with IPv4. This class of solution is recommended for large ISPs and Telco s who have run out of IPv4 addresses and can no longer obtain additional IPv4 addresses. This is not the case for most Enterprises today and is not very likely in the near future. The exception to this recommendation is if the Enterprise is using IPv6 internally and no longer using IPv4. In this case NAT64 can be used to connect to the IPv4 Internet in the same manner as NAT44 is used today with IPv4. 8
Transition Security Considerations Dual Stack allows Enterprise security policies to be created and implemented that parallel IPv4. Check Point s firewalls make this very straightforward. Tunneling makes it more challenging to look inside of the packets in the tunnel. This gets especially complicated given the number of possible ways of creating IPv6 related tunnels. A recommended approach is to create default rules to block all types of transition tunnels (for example, IPv6 over IPv4 from any source to any destination) and only allow them if an explicit rule is created to allow it from a specific source to a specific destination. This is especially true of automatic tunnels that could be created by a user on an IPv6 capable node. This type of tunneling security policy can also be created using Check Point s IPv6 capable firewalls. VPNs are recommended to carry Enterprise IPv6 traffic between Enterprise sites. Check Point s firewalls are also capable of setting up this kind of site-to-site IPv6 VPNs. For Further Reading 6in4, Basic Transition Mechanisms for IPv6 Hosts and Routers, RFC4213 4in6, Generic Packet Tunneling in IPv6 Specification, RFC2473 6to4, Connection of IPv6 Domains via IPv4 Clouds, RFC3056 Advisory Guidelines for 6to4 Deployment, RFC6343 Tunnel Brokers, IPv6 Tunnel Broker, RFC3053 6PE, Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE), RFC4798 Teredo, Tunneling IPv6 over UDP through Network Address Translations (NATs), RFC4380 ISATAP, Intra-Site Automatic Tunnel Addressing Protocol, RFC5214 6RD, IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Protocol Specification, RFC5969 HE, Hurricane Electric Free IPv6 Tunnel Broker SixZS, SixXS IPv6 Deployment & Tunnel Broker IPv6-to-IPv6 Network Prefix Translation, experimental, RFC6296 AT&T IPv6 are you ready British Telecom, BT & IPv6, Helping Customers Thrive in a Changing World Verizon, IPv6 Get Ready for the Next Generation Internet Deutsche Telekom, Das Internet ist voll NTT, NTT Communications helps you create new Internet business with IPv6 9
About Check Point Software Technologies Ltd. Check Point Software Technologies Ltd. (www.checkpoint.com), worldwide leader in securing the Internet, is the only vendor to deliver Total Security for networks, data and endpoints, unified under a single management framework. Check Point provides customers uncompromised protection against all types of threats, reduces security complexity and lowers total cost of ownership. Check Point first pioneered the industry with FireWall-1 and its patented Stateful Inspection technology. Today, Check Point continues to innovate with the development of the software blade architecture. The dynamic software blade architecture delivers secure, flexible and simple solutions that can be fully customized to meet the exact security needs of any organization or environment. Check Point customers include tens of thousands of businesses and organizations of all sizes including all Fortune 100 companies. Check Point award-winning ZoneAlarm solutions protect millions of consumers from hackers, spyware and identity theft. CHECK POINT OFFICES Worldwide Headquarters 5 Ha Solelim Street Tel Aviv 67897, Israel Tel: 972-3-753 4555 Fax: 972-3-624-1100 email: info@checkpoint.com U.S. Headquarters 800 Bridge Parkway Redwood City, CA 94065 Tel: 800-429-4391 ; 650-628-2000 Fax: 650-654-4233 URL: http://www.checkpoint.com 2003 2011 Check Point Software Technologies Ltd. All rights reserved. Check Point, AlertAdvisor, Application Intelligence, Check Point 2200, Check Point 4000 Appliances, Check Point 4200, Check Point 4600, Check Point 4800, Check Point 12000 Appliances, Check Point 12200, Check Point 12400, Check Point 12600, Check Point 21400, Check Point 6100 Security System, Check Point Anti-Bot Software Blade, Check Point Application Control Software Blade, Check Point Data Loss Prevention, Check Point DLP, Check Point DLP-1, Check Point Endpoint Security, Check Point Endpoint Security On Demand, the Check Point logo, Check Point Full Disk Encryption, Check Point GO, Check Point Horizon Manager, Check Point Identity Awareness, Check Point IPS, Check Point IPSec VPN, Check Point Media Encryption, Check Point Mobile, Check Point Mobile Access, Check Point NAC, Check Point Network Voyager, Check Point OneCheck, Check Point R75, Check Point Security Gateway, Check Point Update Service, Check Point WebCheck, ClusterXL, Confidence Indexing, ConnectControl, Connectra, Connectra Accelerator Card, Cooperative Enforcement, Cooperative Security Alliance, CoreXL, DefenseNet, DynamicID, Endpoint Connect VPN Client, Endpoint Security, Eventia, Eventia Analyzer, Eventia Reporter, Eventia Suite, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, FloodGate-1, Hacker ID, Hybrid Detection Engine, IMsecure, INSPECT, INSPECT XL, Integrity, Integrity Clientless Security, Integrity SecureClient, InterSpect, IP Appliances, IPS-1, IPS Software Blade, IPSO, R75, Software Blade, IQ Engine, MailSafe, the More, better, Simpler Security logo, Multi-Domain Security Management, MultiSpect, NG, NGX, Open Security Extension, OPSEC, OSFirewall, Pointsec, Pointsec Mobile, Pointsec PC, Pointsec Protector, Policy Lifecycle Management,Power-1, Provider-1, PureAdvantage, PURE Security, the puresecurity logo, Safe@Home, Safe@Office, Secure Virtual Workspace, SecureClient, SecureClient Mobile, SecureKnowledge, SecurePlatform, SecurePlatform Pro, SecuRemote, SecureServer, SecureUpdate, SecureXL, SecureXL Turbocard, Security Management Portal, SecurityPower, Series 80 Appliance, SiteManager-1, Smart-1, SmartCenter, SmartCenter Power, SmartCenter Pro, SmartCenter UTM, SmartConsole, SmartDashboard, SmartDefense, SmartDefense Advisor, SmartEvent, Smarter Security, SmartLSM, SmartMap, SmartPortal, SmartProvisioning, SmartReporter, SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker, SmartWorkflow, SMP, SMP On-Demand, SocialGuard, SofaWare, Software Blade Architecture, the softwareblades logo, SSL Network Extender, Stateful Clustering, Total Security, the totalsecurity logo, TrueVector, UserCheck, UTM-1, UTM-1 Edge, UTM-1 Edge Industrial, UTM-1 Total Security, VPN-1, VPN-1 Edge, VPN-1 MASS, VPN-1 Power, VPN-1 Power Multi-core, VPN-1 Power VSX, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 UTM, VPN-1 UTM Edge, VPN-1 VE, VPN-1 VSX, VSX, VSX-1, Web Intelligence, ZoneAlarm, ZoneAlarm Antivirus + Firewall, ZoneAlarm DataLock, ZoneAlarm Extreme Security, ZoneAlarm ForceField, ZoneAlarm Free Firewall, ZoneAlarm Pro Firewall, ZoneAlarm Internet Security Suite, ZoneAlarm Security Toolbar, ZoneAlarm Secure Wireless Router, Zone Labs, and the Zone Labs logo are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. ZoneAlarm is a Check Point Software Technologies, Inc. Company. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. Patent No. 5,606,668, 5,835,726, 5,987,611, 6,496,935, 6,873,988, 6,850,943, 7,165,076, 7,540,013, 7,725,737 and 7,788,726 and may be protected by other U.S. Patents, foreign patents, or pending applications. February 14, 2012