You are on page 1of 41

AT&T IPv6 Migration Guide

Release 1.0

February 29, 2012

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.

Technical Assistance This is an AT&T proprietary document developed for use by AT&T customers. For additional technical assistance contact your AT&T sales team. (This document was prepared by AT&T Solution Center Network Design and Consulting Division.) Legal Disclaimer This document does not constitute a contract between AT&T and a customer and may be withdrawn or changed by AT&T at any time without notice. Any contractual relationship between AT&T and a customer is contingent upon AT&T and a customer entering into a written agreement signed by authorized representatives of both parties and which sets forth the applicable prices, terms and conditions relating to specified AT&T products and services, and/or, to the extent required by law, AT&T filing a tariff with federal and/or state regulatory agencies and such tariff becoming effective. Such contract and/or tariff, as applicable, will be the sole agreement between the parties and will supersede all prior agreements, proposals, representations, statements or understandings, whether written or oral, between the parties relating to the subject matter of such contract and/or tariff.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.

Table of Contents
1 2 Introduction ............................................................................................................................................ 5 Migration Scenarios Overview ............................................................................................................... 6 2.1 2.2 2.3 2.4 2.5 3 3.1 3.2 End-User Connections .................................................................................................................. 6 Internet Content ............................................................................................................................ 7 Remote Access ............................................................................................................................. 7 Mobility ........................................................................................................................................ 7 Corporate Internet Access............................................................................................................. 8 IPv6 Addressing ......................................................................................................................... 10 Planning ...................................................................................................................................... 12 3.2.1 Assess Corporate Network Requirements ........................................................................ 12 3.2.2 Provider Assigned or Provider Independent Addresses.................................................... 13 3.2.3 Develop an Addressing Strategy ....................................................................................... 14 3.3 3.4 Implementation ........................................................................................................................... 15 Multi-Homing ............................................................................................................................. 16 3.4.1 Single Carrier Multi-homing............................................................................................. 17 3.4.2 Multi-Carrier Multi-homing.............................................................................................. 17 3.4.3 Multi-Region Multi-homing ............................................................................................. 17 4 5 Establish IPv6 Enabled Connectivity ................................................................................................... 19 Access Router Configuration ............................................................................................................... 20 5.1 5.2 5.3 6 6.1 BGP ............................................................................................................................................ 20 Static ........................................................................................................................................... 21 Access-List Formats ................................................................................................................... 22 Perimeter Security (Firewall) ..................................................................................................... 24 6.1.1 Traffic Filters .................................................................................................................... 25 6.1.2 Proxy and Translation ....................................................................................................... 26 6.2 Internal Security ......................................................................................................................... 27 6.2.1 Router Solicitation and Router Advertisement ................................................................. 27 6.2.2 Automatic Tunneling ........................................................................................................ 27 6.3 7 8 Candidate Best Practices............................................................................................................. 28 Servers/Endpoints ................................................................................................................................. 29 Domain Name System (DNS) .............................................................................................................. 31

IPv6 Strategy ........................................................................................................................................ 10

Security................................................................................................................................................. 24

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.

Testing/Verification.............................................................................................................................. 35

10 Conclusion ............................................................................................................................................ 36 Appendix A ................................................................................................................................................. 37 A-1 Establishing a Teredo Tunnel........................................................................................................ 37 A-2 IPv6 Address Example .................................................................................................................. 38 A-3 Frequently Asked Questions: ........................................................................................................ 39

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.

1 Introduction
The purpose of this document is to provide guidance for customers adopting IPv6 into existing network environments. The information provided assumes an existing network environment based on IPv4 with the goal of adding IPv6 capabilities into the existing infrastructure to create what is referred to as dualstack. There are a number of potential network environments that might need to adopt IPv6 (as outlined in Migration Scenarios Overview). The initial focus of this document is to address the public facing corporate infrastructure (i.e. web, mail, public application servers, etc). The secondary focus of this guide will be for migration of internal corporate networks. Future releases of this document will continue the process into the back-end for migration of corporate intranet applications and the private Wide Area Network (WAN). As IPv4 address space is exhausted, end-user services will be provided via IPv6. Most of these services will initially be structured to maintain connectivity to the IPv4 Internet via various transition mechanisms. As this process proceeds, an increasingly larger portion of the end-user population will have IPv6 capabilities. For DMZs of corporate networks, this trend will drive the need to have public facing content reachable through IPv6 as well as the current IPv4. The broad use of private (RFC 1918) addressing in corporate networks helps lessen the urgency of IPv6 migration for the internal corporate network. For a limited base of internal users, IPv6 requirements can be addressed through transition mechanisms. IPv6 technology adoption is a moving target. This guide provides current best practices and recommendations. In addition, there are some areas highlighted where there may still be open technical issues, or best practices are still evolving. An initial focus on the public facing corporate infrastructure allows the organization to begin adopting the technology in a limited fashion. This provides a means for developing experience with IPv6 technology and addressing the more immediate emerging needs, while minimizing the technical risks associated with early adoption. As the technology matures and technical issues are resolved, broader based adoption can be pursued.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.

2 Migration Scenarios Overview

This section outlines some of the primary areas that might be faced during IPv6 adoption in the near future. The current release of this document focuses on Corporate Internet Access along with some initial guidance and open issues on Corporate Intranet Access. Corporations typically deploy one or more Internet access facilities to support the enterprise. The facilities are used to provide employees access to web-based content and applications, as well as to support Internet facing corporate resources such as web content, email servers, extranet applications, and remote user (e.g. IPSec) access. Additionally, DMZ based DNS servers, load balancers, and security appliances are common to this environment. The initial drivers for IPv6 deployment are most apparent in the consumer end-user space. IPv4 address exhaustion is prompting service providers to leverage IPv6 in consumer-based offers. Businesses with online consumer business models (search, social, retailing, gaming, etc) will need to add IPv6 to support Internet-based access to a migrating consumer customer base. For these enterprise networks, the initial IPv6 focus should be on external facing resources. An initial focus on web content, extranet apps, etc, allows the enterprise to gain experience and presence in the IPv6 space. The technical issues for this level of migration are much less challenging and the reduced scope greatly reduces the negative implications if the approach needs to be modified as the technology matures. Most non-web centric enterprises make extensive use of private addressing and IPv4 NAT for internal resources and intranet connectivity. This greatly lessens the concern associated with IPv4 exhaustion for enterprise networks. Overall, this is a good thing because there are some unique technical challenges for migration of enterprise networks. If IPv6 deployment is required, there are a number of potential solutions; however this is still a very fluid area for IPv6 technology. For most enterprises, full migration to IPv6 throughout the enterprise is best deferred until best practices are more fully developed and accepted. The following paragraphs provide a brief context for some of the non-enterprise IPv6 adoption issues along with our description of a specific enterprise migration scenario as defined in the remainder of this guide.


End-User Connections

End-user refers to the consumer broadband Internet market, typically homes served by broadband (UVerse, DSL, cable, etc). This segment of the market is the most active area in the adoption of IPv6. Adoption in this space is being driven largely by public IPv4 address exhaustion. While most active, this space is the least technically savvy. There are a number of approaches being explored in the end-user access space. Many of these approaches involve assigning an IPv6 address to the customers connection while maintaining their existing in-house networks as-is (e.g. 192.168.x.x). This minimizes the impact on customers while allowing the service provider to provision new customers using IPv6 rather than IPv4. These tunneling/gateway approaches are viewed as transitional, with a more comprehensive migration to follow. Movement toward dual-stack (IPv4 and IPv6) models allows connectivity to both domains. These will typically attempt to use IPv6 as the first choice and fall back to IPv4 for resources that are not available via IPv6. This approach will facilitate the gradual phasing out of IPv4 content and connectivity. For the enterprise network architect, it is important to understand the movement in this space as it will be the predominant driver for the migration to IPv6. However, the approaches and technologies are largely a service provider issue and out of scope for this guide. One notable exception is for corporate remote access solutions. Enterprise architects should be aware of residential consumer deployments in planning
NDC Release 1.0 2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures. 6

and deploying remote access solutions for IPv6. This will be addressed more fully in subsequent releases of this document.


Internet Content

Internet content refers to the market segment with business models based primarily on providing Internetbased content and services. The initial migration guidance provided for enterprise migration is conceptually applicable to these environments, but the scale and diversity of technologies present additional layers of complexity well beyond the intent of this guide. To effectively serve their online consumer customer base, Internet content providers will likely be early adopters of IPv6 technology. It will be considered a competitive necessity to provide both IPv4 and IPv6 access to commercial content and services. These industries have unique challenges relative to content availability, distributed content, back-end systems, load distribution, etc. that are unique to the industry and often a key aspect of the companys value proposition. These businesses, together with Internet Service Providers and equipment vendors, represent the vanguard of IPv6 technology development. As mentioned, the complexity of these environments is well beyond the intended scope of this guide. By the same token, these businesses also have internal enterprise networks that face the same technology and migration challenges outlined in this guide. For the internal corporate network, this guide has some applicability for these businesses. An important caveat is that the urgency for providing IPv6 access to the internal user base may be somewhat higher due to the Internet centric nature of the business.


Remote Access

Remote access refers to the set of approaches that allow external users to access the corporate network, generally leveraging Internet connectivity at both the remote and the corporate site. These capabilities may be leveraged by work at home employees, travelling/mobile employees, and business partners. There are many technologies and solutions currently in use for remote access. Some of the unique features of IPv6 are likely to expand the options in this space. As endpoints served by consumer services migrate to IPv6 capabilities, enterprises will need to re-evaluate and adapt their remote access mechanisms. The current version of this guide does not address Remote Access. Existing IPv4 mechanisms should continue to serve until native IPv6-only connectivity starts emerging as the norm. The guide will be amended as IPv6 Remote Access technologies are deployed and mature.



Mobile cellular wireless technologies and applications are a high growth field. The mobility space is also fertile ground for green field or totally new kinds of network usage. Package tracking, smart grid meters, truck and rail car geo location, are just a few examples where huge numbers of endpoints need to be addressed. This would imply that mobile wireless growth should lead the way in IPv6 deployment. But cellular wireless networks are intimately tied to their end devices capabilities and configurations. Both networks and devices must evolve and deploy capabilities in coordination with each other. This tight coupling is largely due to the added cost of wireless spectrum and billing plans that feature usage charges and subscriptions based on types of services needed. End user devices that presume to use IPv6 networking must be tested, approved, and be able to register for prearranged services. This creates a catch-22. Devices cant support IPv6 until the network allows it, and the network development effort is complicated by huge demand for new capabilities, including VoIP, at a scale well beyond initial expectations. For now, it is expected that IPv6 cellular wireless ubiquity will lag behind wireline deployment.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


Corporate Internet Access

The figure below depicts a typical (simple) enterprise network. A firewall provides security functions with appropriate policies for a DMZ and the corporate Intranet. The DMZ contains a set of external resources such as the corporate web site and external email. The Enterprise consists of corporate employees/users, internal servers/applications and the LAN/WAN infrastructure for the corporation.

Enterprise Network (LAN/WAN)

Internet Access Router

Public Content -Web - Email - Etc


Figure 2.5-Typical Enterprise Network The scope of the DMZ and associated public resources is typically quite small compared to the enterprise intranet. The scope of the intranet can be quite extensive with significant implications for deployment of IPv6. The use of private addressing, however, greatly reduces the urgency of migration for the intranet portion of the enterprise. Intr anet Complexities One of the fundamental differences between IPv4 and IPv6 is in the use of private addressing. Where IPv4 allows the use of private addressing in the corporate Intranet, and can take advantage of Network Address Translation (NAT) to provide a beneficial decoupling between internal corporate networks and the Internet. In contrast, the use of NAT is currently discouraged in IPv6, with the expectation that all devices will have globally unique addresses. This approach has been rationalized in the IPv6 community due to the abundance of available IPv6 addresses, coupled with the desire to eliminate stateful NAT, and erroneous prevailing perception that it provides increased security. Unfortunately, this stance fails to recognize some of the additional benefits of NAT that are specific to the corporate Intranet. Within the DMZ, IPv4 addresses are typically provided by the service provider. If a corporation wants to switch to a new service provider, some degree of re-addressing is required. With NAT, the scope of this re-addressing effort is greatly reduced, affecting only the DMZ. The internal private addressing remains intact. Similarly, if Provider Assigned (versus Provider Independent) IPv6 addresses are used for the entire enterprise, the task of re-addressing the network to switch providers is much more complex. Automated addressing mechanisms have the potential to address this problem, but there is still significant work to be done before these technologies are fully mature.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.

Many enterprises use multiple internet access connections from diverse corporate locations and/or diverse carriers. With IPv4 it is quite common to have separate blocks of provider assigned addressing for each of these connections. Internal users will appear as the appropriate source address on the Internet based on passing through an independent NAT/Firewall function for each connection. This assures appropriate routing and session symmetry to maintain firewall state. These multi-homing scenarios are much more complicated for IPv6. Given that IPv6 does not have a supported NAT equivalent, the enterprise must either deploy Provider Independent IPv6 addressing or assign multiple IPv6 host addresses to each end device. Even then, the issue of session symmetry must also be addressed, or a means of sharing state across diverse firewalls must be deployed. The issues surrounding NAT elimination, multi-homing, and automatic address assignment coupled with the scope and risk of unduly early intranet deployment warrant significant deliberation prior to IPv6 deployment. Many of these issues are being addressed in current work. Best practice approaches will emerge going forward. Public Resour ce Migr ation Accordingly, the initial focus for the enterprise should be on the public facing aspects of the network. These represent a much smaller scope greatly reducing the negative implications of an initial misstep. This allows the enterprise architect a prudent learning curve in IPv6 technologies while allowing some of the emerging technologies and approaches to mature before wide scale deployment in the intranet. Migration of the public facing enterprise resources is a nicely bounded project that allows the business early participation in the IPv6 space while avoiding undue risk. It is this initial migration that is discussed in the remainder of the current version of this guide.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.

3 IPv6 Strategy
With a goal of establishing dual-stack (simultaneous IPv4 and IPv6) internet access, the following fundamental sequence occurs:

1. 2. 3. 4. 5. 6. 7.

Establish an addressing plan Procure Dual-Stack Internet Service Configure the Access Router Configure the firewall Configure IPv6 on DMZ Resources Augment DNS Testing & Verification
Steps for IPv6 Internet Migration

These steps are covered directly in the subsequent sections of this document. Although it is not listed in the steps above, it is very important to conduct a thorough infrastructure assessment of current hardware and softwares ability to support IPv6. This goes beyond simply verifying that IPV6 networking support is included in firewalls, routers, switches, application servers, name servers, user PCs, reporting tools, etc. IPv6 addresses are significantly larger and require more memory and additional processing. This creates an incremental burden on equipment that must, presumably, continue to support IPv4 networking. Running both protocols in a dual-stack scenario will be more than twice as complicated and require significant additional capacity from any hardware that participates in this transition. This document primarily addresses an early phase of IPv6 migration where one focuses on public facing elements (web, email, etc). We might also suggest that a serious assessment of the enterprises ability to handle the additional complexity and capacity demand of running two simultaneous protocols should be done in the early phases of migration. This allows for adjustment of capital expense budgets to cover the deficiencies that will be discovered.


IPv6 Addressing

This section provides an overview of considerations and implications for establishing an IPv6 addressing plan. The current version of this guide only addresses migration of the public facing side of the enterprise, while counseling a more deliberate stance toward migration of the private side. The IPv6 addressing plan, however, does not lend itself to the same level of private/public separation as there is for IPv4. Accordingly, some thought should be given to the IPv6 allocation plan for the entire enterprise even at this initial step. That said, the implications of a mis-step for the initial public migration are not severe. If the addressing plan needs to be redone or re-worked the scope of changes required for public facing devices is fairly limited. One of the main differences between IPv4 and IPv6 is the size of the IPv6 address space. IPv6 provides significantly more IP addresses than IPv4. IPv4 uses 32-bit addressing which limits the number of IP addresses to 232 or about 4.3 billion addresses. In comparison, IPv6 provides 2128, or in the longer notation, thats 340 undecillion, 282 decillion, 366 nonillion, 920 octillion, 938 septillion, 463 sextillion, 463 quintillion, 374 quadrillion, 607 trillion, 431 billion, 768 million, 211 thousand and 456 addresses. Every conceivable device in the world could be assigned an IPv6 address, and there would still be plenty of addresses left over. With so many addresses, many IPv6 advocates believe there is no need for IPv6 Network Address Translation. In fact, the industry best practice advocates the use of a public (or globalunique) IPv6 address on every device that requires connectivity to the IPv6 Internet. This applies not only to the public facing servers but also to the private internal devices inside a corporate network. This

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


may be a strange concept for network and security administrators who have viewed NAT as a security mechanism to hide internal devices from the outside world. Does this mean IPv6 networks are less secure than IPv4 networks? It can be argued that the private IPv6 networks with publicly-assigned addresses are just as secure as IPv4 privately-addressed networks. First, the smallest subnet that is expected to be used in IPv6 networks is a 64-bit prefix. This means even the smallest IPv6 subnets will have significantly more addresses than the entire IPv4 Internet. Moreover, the smallest address space that should be allocated by an Internet Service Provider (ISP) to an enterprise customer is a 56-bit prefix and a 48-bit prefix if allocated directly by a Regional Internet Registrar (RIR). Therefore, it would take a potential hacker a long time to completely probe the combination of 272 (128 bits minus 56-bit prefix) addresses and all potential TCP/UDP ports in an attempt to enumerate a network. In effect due to such large address allocation, the publicly-addressed IPv6 devices could be as tough if not tougher to discover than the privately addressed IPv4 devices. It is like a hacker trying to probe the entire IPv4 Internet address space a trillion times repeatedlynot practical. Although NAT provides a clean delineation between private and public networks, it should not be viewed as a security mechanism. It does not provide a corporate network any meaningful security mechanisms from outside attackers. Network security is the implementation of a security policy and is provided by network firewalls, intrusion prevention systems, and other security software and appliances. Similar precautions and protection must be deployed in IPv6 networks. The drawbacks to using public addresses inside a corporate intranet include:

NAT based IPv4 networks segregate the task of internal addressing from external/public addressing. If there is a need to change public addresses the internal private addressing is unaffected. Geographically dispersed networks with multiple Internet connections and/or providers can use separate NAT functions to the public addressing allocated for each individual ISP connection. This maintains symmetric routing in the enterprise which simplifies stateful firewall implementation. This also avoids the need for exception routes in the global Internet and/or the need for multiple host address assignments to end devices in the enterprise. Private addressing in IPv4 lends itself to the use of relatively simple address assignments (x.x.x.1 or x.x.x.254 for instance). While it is possible to simply overlay this approach within specific IPv6 subnets, it is not advised. Best practice is to use the full hexadecimal range afforded in the IPv6 format. This helps maintain the difficulty of potential hackers enumerating a corporate network. Finally network administrators must be more careful about allocating IPv6 addresses to the rest of the corporate network and not just the public facing servers. Network administrators no longer have NAT to rely on to mask overlapping or misappropriated addresses.

These drawbacks are significant, and much of the current work in the IPv6 community is aimed at addressing these inherent drawbacks. Among the work in progress in support of NAT features for IPv6, there may be some hope for proponents of NAT. Recently, more and more network equipment vendors have been warming up to IPv6 NAT. One vendor reported it will have its first release of IPv6 NAT sometime in 2012, though the adoption rate of this future technology has to be proven. One of the perceived benefits of IPv6 (i.e. public addressing) is providing a network environment to foster direct (peer to peer) communication between endpoints without the aid of intermediate gateways. If a killer application emerges that does not work over NAT, then corporations may be forced to maintain a NATless network environment. For IPv6, RFC 6296 proposes the use of stateless NAT where the internal
NDC Release 1.0 2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures. 11

prefix is replaced with the public prefix. The RFC proposes a prefix replacement while maintaining most of the host bits 1. This is significantly different from todays IPv4 NAT that is stateful. Many of the complexities and application issues associated with IPv4 NAT can be traced to its stateful implementation. A stateless implementation for IPv6 would avoid most of these issues while maintaining the advantages / avoiding the drawbacks of not having NAT. For more details on IPv6 NAT, please refer to RFC6296IPv6-to-IPv6 Network Prefix Translation. The rest of this section primarily focuses on planning and implementation of IPv6 addresses without the use of NAT. NAT was covered to highlight the present issues and potential impacts in outlining a corporate addressing plan. The following sections place more emphasis on the public-facing network infrastructure. In addition to this document, please review Section 2 of the AT&Ts IPv6 Fundamentals Guide for more information on IPv6 addressing.


Planning 1. Assess corporate network requirements 2. Determine the type of public address 3. Develop an addressing strategy

There are three key steps in developing an IPv6 addressing plan.

It is very important to understand the overall corporate network requirements. Does the enterprise operate only in the US market or in other countries? Is the Enterprise divided into different Lines of Business (LoB)? Are there multiple corporate Internet connections? Is the Internet service with one or more ISPs? These are only some of the questions that should be considered before moving forward. A second step is to decide on the type of global-unique address that is right for the corporate network. This step is just as important as the first step. If a poor decision is made in this step, then the network may need to be completely readdressed latera major undertaking. The final step is to craft an addressing strategy that will be assigned to the public facing network. Referring to Figure 2.5, there are three network segments that are public facing: customer router to ISP router, customer router to firewall, and the DMZ. What IPv6 prefix boundary should be used for point to point connections? How about segments with small, medium, large number of devices? What specific addresses will be assigned to actual devices? Some of these questions will be addressed in the following sections, and readers should use the information to determine the appropriate strategy that is right for them. 3.2.1 Assess Corporate Network Requirements

It will be very rare to see an enterprise upgrading their entire corporate network to IPv6 all at once. Most enterprises will take a phased approach over a course of several years with the initial focus on the public facing network. In fact, the U.S. federal agencies are mandated to make their Internet services available to support IPv6 users by the end of 2012. By 2014, these agencies must upgrade their internal networks to IPv6. Many enterprises may not have this tight timeline but will likely follow a similar path to IPv6 by initially starting at the Internet edge and then into the core corporate network. However, this does not mean the corporate network requirements should be collected in phases. Enterprises should conduct some level of assessment of the entire corporate network before migrating the

The stateless NAT approach is a bit more complex than a 1:1 mapping of the subnet bits, but this description captures the concept, and it represents a much simpler approach than stateful IPv4 NAT.
2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures. 12

NDC Release 1.0

public network. Why is it important to identify requirements for internal networks during this phase? It is not critical to have a fully developed plan incorporating all aspects of the corporate infrastructure, but some up front attention can avoid pitfalls and rework later. For instance, a network administrator may choose a 64-bit IPv6 prefix to assign to the Internet servers because it spells a recognizable address such as 2001:DB8:ACE::/64, but later finds out that this address space conflicts with the corporate addressing plan that was later developed to allocate a contiguous 56-bit prefix to each branch office. One acceptable solution could be to ignore the issue and to simply skip over the entire /56 prefix that the hex ACE prefix resides within. This results in underutilization of IPv6 addresses--255 unused 64-bit prefixes. The other option might be to readdress the Internet devices to a different 64-bit prefix, but this option will interrupt Internet services while the devices are being updated. Some may argue the first option is probably the best approach in tackling this issue since there are plenty of IPv6 addresses go around. However if this action is taken too frequently, then it will lead to fragmented addressing that could place more burden on network routers in maintaining and processing additional IPv6 routes. Once the overall corporate network requirements are understood, the attention can now be given to the Internet network segments referenced in Figure 2.5. What IPv6 prefix and prefix length will be allocated to each network segment? What IPv6 services will be allowed through the Internet router and the corporate firewall? What is the approach for making the corporate services available to IPv6 Internet users? Will the servers be dual-stacked? Or will there be physically separate servers to support IPv6 users? These are some of the probing questions that must be answered during this first step. They are listed here to give readers some ideas of the types of questions that must be addressed in documenting the overall corporate network requirements. Whatever the approach, nothing should be taken for granted. IPv6 should not be treated as just another protocol, or one may overlook important requirements or dependencies. 3.2.2 Provider Assigned or Provider Independent Addresses

There are two types of IPv6 global-unique addresses: Provider-Assigned (PA) and Provider-Independent (PI). Either PA or PI addresses must be used in order to access content on the IPv6 Internet. The terms represent two avenues an enterprise can use to obtain public addresses. The PA addresses are allocated by the ISP, and the PI addresses are allocated directly by the RIR such as ARIN. One of the main advantages of using the PA address is it helps to control the amount of routes maintained by Internet routers. By using a PA address, an enterprise loses the ability to advertise their allocated space into the global routing table. Instead, an enterprises PA routes are aggregated by the ISP who owns the larger PA prefix. Potentially, an ISP with over 10,000 customers could be represented on the Internet by a single IPv6 route. There are obvious benefits for the ISP and the global Internet community in conserving memory, processor, and other resources, but why should the end-users care? Better performance. Endusers may not be able to perceive the performance improvement, but a smaller global routing table translates to better performing and more efficient Internet especially when routers are expected to maintain both IPv4 and IPv6 routes with an IPv6 route taking up more memory space and resources. A more streamlined global Internet also translates to reduced costs for infrastructure equipment and peering facilities. The number of individual IPv4 subnets in the global routing table has been steadily increasing for many years. This is partly due to the fact that IPv4 addresses owned by one ISP are accepted by another ISP. Typically if an IPv4 block is /24 or shorter (i.e. /8 to /24), then most ISPs will accept another providers address into their network. IPv6 will change the size of the network block that an ISP accepts. At the time of this writing, ISPs will not accept another providers PA address. In addition, PA addresses are more or less owned by the ISP. If a company changes service providers, then it would have to forfeit the

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


PA address back to the ISP. This means the entire corporate network must be re-addressed using a new PA block from the new ISP. Therefore, many enterprises are electing to apply for PI addresses that are directly allocated by RIRs and provide the flexibility to take the addresses to any provider without the concern of network readdressing. The PI address may also be a required element when developing a multi-homing network solution. Most ISPs will not accept PI prefixes longer than a 48-bit prefix. Subsequently, /48 is the longest prefix handed out by RIRs. (Please note: There is an annual maintenance fee associated with PI addresses. Please visit the RIRs website for the pricing list.) Some ISPs may accept longer prefixes (i.e. /49 through /64). However it is unlikely that these longer prefixes will be announced to Internet peering partners. Longer prefixes may be supported by the directly connected ISP, but they will likely be filtered across peering connections either by the ISP, peering partners, or both. Depending on the corporate requirements and the Internet routing policies, enterprises may need to request prefixes larger than 48-bits from RIRs. Please consult with your ISP about their routing policies and determine if PA is sufficient to satisfy the corporate network requirements. However for larger enterprises, a PI prefix may be the most prudent option to avoid network readdressing in the future and to get around routing policy restrictions. 3.2.3 Develop an Addressing Strategy This step is perhaps the toughest. It is overwhelming to develop an overall addressing strategy that satisfies immediate and future network needs. It is made even more challenging with the understanding that Industry best practices are still being formulated and RFCs are being updated based on real-world deployments and lessons learned. For instance, IPv6 does not promote the use of variable subnetting. The industry standard advocates the use of a 64-bit prefix on every network segment regardless of its size. This is even true across a point to point connection where /30 is typically used in IPv4 networks. Recently, RFC 6164 was created to introduce a new standard that advocates the use of 127-bit prefixes for point-to-point links. At the time of this writing it is uncertain whether RFC6164 will be readily adopted by the industry. RFC 5375 points out several drawbacks of using variable subnetting such as misuse of reserved address space. However the main disadvantage of variable subnetting is that autoconfiguration does not work if the subnet boundary is not exactly 64-bits. It can not be 65-bits, 127-bits, or 63-bits. The subnet must be exactly 64-bit network prefix in order for autoconfiguration to work properly. This should not be a major issue for a point-to-point or small network like a DMZ since devices on these networks are manually configured. For a small branch office, autoconfiguration may be appropriate to avoid manual configuration or to deploy a DHCP infrastructure. If the present best practice of 64-bit subnet is deployed, then about 18.4 quintillion IPv6 addresses would go unused for a small network. Since there are plenty of IPv6 addresses, underutilization of IP address space is not much of a concern for IPv6 advocates. In fact, the present best practice is to allocate 48-bit prefix to an enterprise and 56-bit prefix to a site. This translates to 256 sites and 256 64-bit subnets per site. This seems to be an overallocation for a branch office that perhaps has just three subnets for a data network, a voice network, and a special application network. Ultimately, it comes down to individual companies to determine what addressing scheme is appropriate for their environment. 56-bit prefix boundary should be used as a guide and not as a strict standard. Use the appropriate boundary prefix for each site that satisfies the present and the future requirements. Best practices will continue to evolve and develop in this space. The details of the corporate LAN and WAN addressing will be covered in future releases of this guide. For the public facing networks, companies must select a group of 64-bit prefixes from their overall IPv6 address pool to assign to the public network segments such as the DMZ, CE-Firewall LAN, etc. This group of prefixes should be chosen from either the upper or the lower bounds of the IPv6 address pool.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


For instance if the assigned address pool is 2001:DB:1234::/48, then choose the prefixes from the 2001:DB:1234:: or the 2001:DB:FFFF::. This approach will aid in avoiding address conflicts as prefixes are allocated to the corporate LAN in the next phase of IPv6 implementation. The actual number of required 64-bit prefixes will be determined by whether the Industry best practice is followed. As mentioned previously, the Industry standard dictates that a 64-bit prefix is allocated to any network segment regardless of size. Recall that even if there may only be three devices on a network, a 64-bit prefix is expected to be used. Technically, companies can elect to depart from this standard by incorporating variable subnetting and use longer prefixes to accommodate smaller number of devices. However, it is advised that careful research and tests are conducted to ensure non-standard deployment doesnt cause issues within the public infrastructure. Please see Appendix A-2 for an example of IPv6 address allocation to the public facing infrastructure.



While most of the corporate LAN may use DHCPv6 or autoconfiguration, network devices shown in Figure 2.5 will likely be manually configured with an address. Even with manual configuration, IPv6 devices may also assign autoconfigured addresses if the subnet is on a 64-bit boundary. In order to avoid this, administrators can disable router advertisement on the default gateway devices such as the Internet router or the firewall. Otherwise, the Internet servers may assume multiple IPv6 addresses and potentially cause issues if the server responds with a different address than the addresses used to setup the session. There are also other considerations when using manual address configuration. According to RFC 3627, all zeros and all ones should be avoided since they are reserved anycast address. The RFC claims the addresses will fail Duplicate Address Detection queries. However, according to RFC 5375, this is not true. In the real world operations, these anycast addresses can be assigned much like any unicast addresses without limitations. Even so, these addresses should be avoided as a best practice to minimize issues in the future if these anycast addresses are treated differently Administrators should also pay attention to their choice of variable subnet prefix or manually configured address that defines bits 71 and 72 bits of the address. Bit 71 is used to identify whether the address is universally or locally administered. For instance, if the host address is based on an industry standard such as a MAC address then it is considered universally administered. The 71st bit should be set. Bit 72 defines whether the address is a unicast or multicast address. By setting this bit, it tells the world that the address is used for multicast services. In todays implementation, these bits are ignored by most IPv6 devices, but it may be utilized in the future. Therefore, network administrators should be mindful and choose addresses wisely. A common IPv4 practice is to use either the lowest or highest number (x.x.x.1 or x.x.x.254) for the default gateways. Many enterprises may attempt to continue this practice in IPv6. There are no technical issues with this approach. However one must consider that there are 0:0:0:0 to FFFF:FFFF:FFFF:FFFF number of addresses to choose from in a 64 bit prefix boundary. One could choose 0:0:0:1 as the host address for a default gateway or servers. This approach makes it easier for potential hackers to map your network. So it may be best to choose an IPv6 address that is not easily guessed. Internet address for the corporate servers will be well known to potential hackers via DNS lookup. This does not mean that the corporate firewalls or other Internet devices need to be made easy to discover. One way to hide them from the Internet is to assign a more complex and unrecognizable IPv6 address with access filtering enabled. However this is prone to human errors. With a more complex hexadecimal addressing scheme, administrators are more prone to mistakes in configuring the IPv6 addresses. Enterprises should always test the final configuration to ensure devices are configured and working correctly. Please see Section 9 Testing & Ver ification for test options.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.




Deploying a multi-homed Internet solution can be very challenging whether it is over an IPv4 or IPv6 network. However, IPv6 is further complicated by the fact that IPv6 deployment is in its infancy. There are simply not enough enterprises that have fully deployed an IPv6 Internet solution to share lessonslearned or establish best practices. Many enterprises claim they have migrated their services to dual-stack environment, but if you look under the covers, it would be apparent that most are partial deployments. Most enterprises are doing just enough to make their Internet services available to potential IPv6 users, without the level of redundancy or advanced functionality that has been established to provide highly available, high performance and secure IPv4 networks. IPv6 is brand new territory for the networking Industry. Most enterprises may maintain a simple IPv6 Internet network until IPv6 multi-homing issues are better understood and addressed by the Industry. In short, enterprises should be cautious in rolling out an IPv6 multi-homing solution and should expect to run into obstacles along the way.

Figure 3.4IPv6 Multi-homing As an example, one of the biggest challenges of designing a multi-homing network solution is addressing the asymmetric routing issue. Without IPv6 NAT, global-unique addresses will be assigned to internal corporate network devices. Therefore enterprises must pay closer attention to the internal corporate routing in ensuring that internal hosts are routed correctly out through the appropriate Internet PoP that is advertising the aggregate address of the hosts prefix. Otherwise, asymmetric routing may occur where the inbound traffic is not forwarded to the same Internet PoP that it originated from. For instance in Figure 3.4, it depicts an enterprise that has an active/active Corporate Internet requirement. This scenario assumes the enterprise has obtained a /47 PI prefix from RIRs and has divided it up to two /48 prefix. Each /48 are advertised as the primary route through ISP#1 and ISP#2. One host is assigned out of the 2001:DB8:1235:ffff::/56 prefix. In order for this host to receive packets from the Internet, it must be
NDC Release 1.0 2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures. 16

routed out through the Internet service connecting to ISP#2. This is because the aggregate address 2001:DB8:1235::/48 encompassing the hosts prefix (2001:DB8:1235:FFFF::/56) is advertised out of this connection. If for some reason the host was routed out through ISP#1, then the return traffic would be returned through ISP#2 since its advertising a more specific /48 prefix. This is not the desired result since the firewall will not have a matching session in its state table. If there isnt a match, then the packet is dropped. This is one of the key examples as to why enterprises should not have a myopic view of focusing just on the public-facing infrastructure. There must be some investment made in reviewing the overall corporate network requirements during initial Internet deployment. 3.4.1 Single Carrier Multi-homing Single provider multi-homing is typically deployed by small to midsize corporations that require redundant Internet services. This can be in the form of multiple Internet connections at a single location or a geographically separated location. When multi-homing with a single provider, an enterprise can elect to use either the PA or the PI addresses. The benefit of using the PA addresses is that the enterprise does not need to apply for the PI addresses which could take time and money. Another benefit may be that some ISPs may allow longer IPv6 prefixes into the network. An ISP may allow 64-bit prefix to be advertised into their network. This may give enterprises flexibility to implement a better load-distribution solution based on granular prefixes or subnets. However the main drawback of PA addresses is that ISPs do not allow enterprises to take PA addresses to another ISP. This means enterprises will be forced to readdress their corporate network whenever they decide to change providers. It may be advantageous even for single provider enterprises to use PI addresses to allow flexibility to move to another ISP but also to implement multi-provider solution if the corporate requirements change in the future. 3.4.2 Multi-Carrier Multi-homing Multi-provider multi-homing is the most popular solution for regional or global enterprises that operate within a single continent. By using multiple ISPs, enterprises can have the peace of mind that a major outage on one providers network will not grossly impact their business. Some of the enterprises today use the ISPs allocated address space to develop an IPv4 multi-homing solution. In todays IPv4 networks, ISPs allow enterprises to advertise another ISPs address into their network. However this practice is forbidden in IPv6 networks. Most if not all ISPs will not accept another ISPs PA addresses. In order to achieve a resilient multi-provider solution, enterprises will likely need to use PI addresses to be able to failover a prefix block from one provider to another. As a general rule, an ISP will not advertise across its peering connections a prefix longer than a /48. The ISP may accept a longer prefix such as 64-bit prefix into the network, but the enterprise will need to also advertise a summary prefix 48bits or shorter. Otherwise, the enterprises prefix will not be visible beyond the ISPs network. Another important point to consider in a multi-provider solution is the size of the prefix that may be required to satisfy the network requirements. If the Internet connections are used as primary and backup, then a single 48-bit prefix may be sufficient. 48-bit prefix can be advertised via eBGP with a shorter or longer ASN hop to prefer one carriers Internet over another. However if multiple Internet connections are actively utilized simultaneously, then multiple 48-bit prefixes may be required since ISPs will not forward routes longer than a 48-bit prefix. A minimum of /48 for each Internet connection is required as shown above in Figure 3.4. Each connection can advertise a /48 as the primary address and a summary route for failover. If one of the Internet connections fails, then the surviving Internet connection will receive traffic that was destined for the other connection following the summary route similar to a typical IPv4 multi-homing implementation. 3.4.3 Multi-Region Multi-homing The present best practice dictates that enterprises that operate in multiple continents acquire addresses from each RIR where they operate. Most Tier-1 ISPs will likely allow enterprises with PI addresses from one region to use them in another region. However, routing policies are still being finalized, and it is
NDC Release 1.0 2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures. 17

uncertain how non-regional addresses will be treated by smaller ISPs in a particular region. For instance, ARIN-obtained address is accepted by AT&T in other regions like Europe and Asia, but it is unclear whether other European ISPs (that AT&T peers with) will honor the advertised address into their network. In an effort to minimize the number of IPv6 routes in the core, an ISP may decide to filter longer non-regional prefixes from entering its Internet. The longest IPv6 prefix that is allocated to RIRs is 23-bits long. (Please visit the following link to see other regional allocations - An ISP may decide to filter based on this 23-bit prefix boundary. Since Tier-1 ISPs have no control over the policies of smaller ISPs, it is recommended that regional address space is used in multi-region solution at this time. It also provides a clean delineation between each region, and WAN routing can be further simplified through summarization based on regional addresses.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


4 Establish IPv6 Enabled Connectivity

Establishing IPv6 connectivity is a simple matter of procuring an Internet connection with Dual-Stack functionality. Ideally, this would be a simple logical change to the existing connection, with no outages and no changes required to the existing environment. Due to functional differences across hardware platforms and availability of dual-stack service, this may not be feasible. At a minimum a minor outage should be planned to allow reconfiguration of carrier equipment and/or re-homing to alternate carrier facilities. As part of the procurement process, AT&T provides an IPv6 address to be used for the Internet WAN connection. This is used on the customer access router for the Internet interface. If BGP peering is specified, this address is used to establish the IPv6 BGP session with AT&T. Additional provider assigned addressing may also be provided by AT&T, or a customer may choose to use their own (Provider Independent) addressing (refer to IPv6 Addressing). Once provisioned, the connection continues to provide IPv4 connectivity as before. When ready, the customer can configure the Internet access router with the appropriate IPv6 elements to begin using the Dual-Stack capabilities of the connection.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


5 Access Router Configuration

This section provides sample router configurations that can be applied on the Internet edge routers. It includes examples of IPv6 BGP configurations to establish IPv4 and IPv6 BGP neighbor relationships with the ISPs router. It also provides sample configurations for static routes for those who may not be comfortable with BGP. The last section provides information on applying IPv6 access lists. For the most part, the IPv6 commands are very similar to IPv4 commands but with slight differences.



BGP router configuration for a dual-stack Internet service requires the use of address families to define IPv4 and IPv6 peers and corresponding advertisement of routes. Note: IPv4 address family is not required in order for an IPv4 BGP relationship to be established. BGP (for IPv4) can be initiated under the main BGP process without defining the IPv4 address family. As such, some customers may choose to only create the IPv6 address family and maintain the IPv4 relationship under the main BGP process. However there is no harm in creating the IPv4 address family. It does not reset the BGP session. It also may be an easier way to manage the BGP configuration by organizing IPv4 and IPv6 BGP configurations under their respective address family. Listed below are some guidelines for configuring BGP on the customers router. BGP configuration steps: Create a BGP router-id Configure IPv4 and IPv6 BGP neighbors Create IPv4 and IPv6 address families Advertise BGP network routes within each address family The first step is to define the BGP router-id under the BGP process. When the router-id is not defined, Cisco routers will default to using the highest loopback IPv4 address. If no IPv4 addresses are present on the router, the IPv6 BGP session will not be established with its peer. Therefore as a best practice, the router-id should be specifically defined under the BGP process. The IPv4 and IPv6 BGP neighbors must be defined under the main BGP process with the corresponding Autonomous System Number (ASN) of its peer. The IPv4 and IPv6 address families need to be configured via addr ess-family [ipv4/IPv6]. By default when an IPv4 address family is defined, both the IPv4 and IPv6 neighbors that were created in the first step will appear automatically under the IPv4 address family. The IPv6 neighbor should only be defined under the IPv6 address family. To do this, the IPv6 neighbor must be disabled under the IPv4 address family by issuing the no neighbor <IPv6 addr ess> activate command and added under the IPv6 address family. Since the IPv4 and IPv6 neighbors have been defined with the r emote-as of the peer under the main BGP process, there is no need to redefine the remote AS under the address family. Instead the neighbors are activated to establish a BGP relationship with the peer by including the activate keyword with the neighbor command as shown below. Customers can then advertise IPv4/IPv6 BGP routes through the use of the familiar networ k <ipv4/IPv6 addr esses> command. Note there is a slight difference in the syntax of the IPv6 networ k command in that it allows the use of the /nn subnet instead of the mask keyword used with IPv4 prefixes. BGP Configuration: router bgp 65000 bgp router-id neighbor remote-as 7018

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


neighbor 2001:DB8::2 remote-as 7018

!configure IPv6 neighbor address/ASN address-family ipv4 !define ipv4 address family neighbor activate !enable BGP for neighbor (enabled by default) no neighbor 2001:DB8::2 activate !disable IPv6 neighbor relationship network mask !network address to be advertised address-family IPv6 !define IPv6 address family neighbor 2001:DB8::2 activate !enable BGP for IPv6 neighbor network 2001:DB8:F::/56 !define network address to be advertised Table 5.1-BGP Configuration In the above table, the /56 prefix under the IPv6 address family was used only as an example. Most customers with Provider-Independent (PI) addresses will be allocated /48 or shorter prefixes. A /56 prefix will likely be assigned by the ISP from the Provider Assigned (PA) block. These longer /56 PA prefixes are typically filtered by the ISP and are summarized into the aggregate PA prefix for the ISP. Even though /56 is announced into an ISP, the /56 route will not appear in the global routing table because most ISPs will not advertise the longer PA prefixes to their peering partners. ISPs will however allow customers to advertise PI blocks as long as they are /48 or shorter. These PI blocks will be forwarded to their peering partners. However ISPs will implement a policy to prevent longer prefixes (ranging from /48 to /128) from being advertised. The longer prefixes may be allowed within the ISP network but will be filtered and not allowed beyond the ISPs network. This policy may vary between service providers.



This section briefly describes how to configure IPv6 static routes. If readers are familiar with configuring IPv4 static routes on Cisco routers, then configuring IPv6 static routes will appear to be very similar but with some slight differences. The configuration of IPv6 static routes requires the following format: IPv6 route IPv6-network/prefix next-hop Below is an example of a static route command for IPv6: IPv6 route 2001:DB8:124F:1::/64 2001:DB8:124F::2 Note (as with most IPv6 commands), the static route command begins with the key word IPv6. The word route indicates this to be a static route. The next argument is the IPv6 network. So, 2001:DB8:124F:1::/64 is the network with a /64 prefix. The last argument is the next-hop and is shown in the above example as 2001:DB8:124F::2 An IPv6 static route that will be commonly used is the default route. The example below shows how the IPV6 static default route is expressed: IPv6 route ::/0 2001:DB8:C00:4F00::EEF6:A0EA The syntax for the IPv6 default route is very different from IPv4. The ::/0 is short hand for: 0000:0000:0000:0000:0000:0000:0000:0000/0 One would agree that ::/0 is much easier to type and less prone to typographic mistakes.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.



Access-List Formats

This section will briefly describes ACL formats as used on Cisco routers. Using Cisco IOS ACLs has changed slightly in IPv6. The standard ACL functionality in IPv6 is similar to standard ACLs in IPv4. An access list determines what traffic is blocked and what traffic is forwarded at router interfaces, and allows filtering based on source, destination, protocol type, port number, and inbound/outbound directions on a specific interface. Each access list has an implicit deny statement at the end. When deploying ACLs in IPv6, there are some subtleties to consider. For instance, all IPv4 IOS ACLs have an implicit deny ip any any at the end of the ACL. With IPv6, the IOS ACLs have the following 2 implicit permit statements along with a deny statement, as shown below: permit icmp any any nd-na permit icmp any any nd-ns deny IPv6 any any The permit statements are added so that Neighbor Discovery (which performs the equivalent functionality of ARP in IPv4) is not disabled when an ACL is applied to an interface. This can lead to problems if one wants to enable the log option on the ACLs. Adding the statement deny IPv6 any any log will override the implicit permits, and neighbor discovery traffic will be denied. So be careful when using the log option. IPv6 IOS ACLs only use named ACLs. The format is shown below: IPv6 access-list access-list-name permit protocol source-IPv6-prefix/prefix-length destination-IPv6prefix/prefix-length, or deny protocol source-IPv6-prefix/prefix-length destination-IPv6prefix/prefix-length Below is an example of an IPv6 ACL: IPv6 access-list RFC4890-in-partial permit icmp any any echo-reply permit icmp any any echo-request permit icmp any any 1 3 permit icmp any any 1 4 permit icmp any any packet-too-big permit icmp any any time-exceeded permit icmp any any parameter-problem deny icmp any any router-advertisement

The above IPv6 ACL is named RFC4890-in-partial. There are seven permits and one deny statements. What is not shown is the implicit permit and deny statements mentioned earlier. Applying an IPv6 ACL to an interface is not the same as it was in IPv4. Format in IPv6: IPv6 traffic-filter access-list-name in IPv6 traffic-filter access-list-name out Example:

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


interface FastEthernet0/1 IPv6 traffic-filter RFC4890-in-partial in The following section on security contains additional information on traffic filters and examples of router and switch configurations.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


6 Security
The long view of security in an IPv6 world may include dramatic enhancements over the current set of IPv4 best practices. Some have envisioned an abandonment of classical perimeter security as currently implemented by firewalls, in favor of end-to-end security models for each TCP/IP session. Use of NAT in a security model has become a common discussion point in the migration to IPv6 networking. A common best practice in IPv4 perimeter security models includes network address translation (NAT). NAT alone is not comprehensive protection but it does identify where the fence is. Presumably other constructs of good perimeter security (stateful inspection, rule imposition, blanket inbound blocking, etc) are implemented at this same juncture. If its not a private address, it hasnt been scrubbed by a firewall. If it is a private address it wont be allowed outside the fence without first being scrubbed. These are typical sentiments of current firewall strategies. But idealistic views of IPv6 consider NAT as a roadblock to a future of creative and innovative end to end communications. That same idealism might want the firewall to give way to per-session based authentication and authorization. But those are notions for the future. This section will presume to build from existing IPv4 best practices and augment them based on new features and new mechanisms occurring in IPv6. New features and mechanisms introduced in an IPv6 enabled world that can become problematic in a security discussion, particularly during a migration phase, include

Automatic assignment of endpoint addressing Automatic identification of routers and gateways Lack of standard support for IPv6 private addressing (IPv6 NAT). New constructs, including Extension Headers at the IP layer Numerous dual-stack and v4<->v6 translation scenarios that will likely be embraced in typical migration scenarios.

The remainder of this section will identify new elements of good security practices aimed at reinforcing public interfaces to preclude new IPv6 based attacks, and general guidelines to adopt inside the enterprise to prevent unauthorized tunneling through the firewall. It is critical to denote that a current Security Policy must be the strategy that drives the security policies. Further, software deficiencies are very commonly found in IPv4 enabled network elements, and it is anticipated that IPv6 enabled network elements will also have a range of deficiencies that will require patching, upgrades, or work-arounds to address.


Perimeter Security (Firewall)

An IPv6 firewall is not just an IPv4 firewall with extra rules. The IPv6 IP header is very different, includes additional header extensions, and needs specific consideration for analysis of potential vulnerabilities. Analyzing an IPv6 packet as if it were an IPv4 packet could give unpredictable results. This is a critical issue for securing the perimeter and will remain an enduring issue even if IPv6 firewalls are largely relegated to passing IPSec tunnels to an ultimate destination for authentication. The concept of a perimeter still remains and must be guarded. An important first step in migrating to an IPv6 presence, even on the outside of the perimeter, is to carefully consider the firewalls ability to support and analyze IPv6 packets. The firewall must be able to support IPv6 and meet the internal certification of both the hardware and software for your enterprise. Typical enterprise connections to the public Internet allow for a DMZ to host public facing web services and file servers. Below we show a configuration that accommodates both IPv4 and IPv6 connectivity to the Internet.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


IPv6 can initially be used to enable IPv6 web, email, and ftp servers as a set of publicly available services, while IPv4 continues to provide two way (firewalled) traffic from the enterprise to the IPv4 Internet. The two networks (IPv4 and IPv6) operate independently but both use the same physical links. Being independent of each other, the treatment of specific traffic flows may differ. We focus here on DMZ access for IPv6 based services while presuming to preclude IPv6 access into the larger enterprise. 6.1.1 Traffic Filters

One of primary differences between IPv4 and IPv6 firewall filters has to do with ICMP traffic. In IPv4, firewalls largely treat ICMP traffic as a potential security problem for denial-of-service flood attacks. ICMP is frequently blocked altogether. There are some instances in IPv4 where ICMP packets provide useful information, such as path MTU detection (packet-too-big replies), or in testing reachability. But even these are often viewed as not worth the exposure to ICMP based attacks, and it is not uncommon for firewalls and border routers to block all ICMP traffic. In IPv6, however, ICMP packets are used in new ways that become critical to discovering layer-two reachability information. IPv6 neighbors and routers discover reachability details to each other using solicitations and advertisements over automatically defined link local subnets. These are all part of a new Neighbor Discovery Protocol (NDP). Blocking all ICMPv6 traffic would disable NDP and be equivalent to blocking ARP traffic in IPv4. With the increased role of ICMP in IPv6, blocking all ICMP messages is not recommended.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


But allowing all ICMPv6 traffic still carries the risk of certain denial of service flood attacks, so a specific strategy should be devised based on what ICMP traffic is deemed appropriate for needed functions. RFC 4890 describes ICMPv6 filtering recommendations for firewalls. The table below shows typical ICMP treatments in both IPv4 and IPv6. These are examples and should not be taken as hard recommendations. Each firewall policy needs to consider these carefully.

Another new element in IPv6 networking involves header extensions. These are used for various functions including supporting IPSec definitions, Fragmentation, Mobility, and Routing options. Intended to add functionality for specific purposes, extension headers complicate IPv6 and present problems for firewalls to effectively analyze. One specific extension header that has been deprecated in IPv6 is the routing extension header type 0 because of its similarity to the IPv4 source routing option. Firewalls are typically configured to drop such packets in both IPv4 and IPv6. Other extension headers need specific consideration in IPv6. 6.1.2 Proxy and Translation

A possible option in early phases of migration to IPv6 might be to use a firewall that performs proxy and translation functions for outbound requests that resolve to IPv6-only endpoints. A proxy firewall essentially terminates outbound requests and initiates a new request from the outside boundary of the firewall. Adding IPv6 translation allows the firewall to communicate with IPv6 destinations on the public side and translate return packets into IPv4 for reply back to internal IPv4-only hosts.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.



Internal Security
Router Solicitation and Router Advertisement

As discussed above, NDP uses ICMPv6 to determine link layer reachability between nodes on a common subnet. In addition to neighbor solicitations and advertisements, NDP also includes router solicitations and advertisements to determine default routing gateways. This can automate the process of discovering router gateways and network prefix assignments. But this can also present the risk of a rogue entity on the subnet announcing itself as the priority gateway and hijacking traffic. All IPv6 devices on a LAN segment will receive the announcement and discover the priority of any advertising router (low, medium and high). The router with high priority will be the primary default router for the LAN and become the default gateway for LAN devices. To prevent this from occurring filters need to be applied at the port level. Cisco and other vendors have features on their switches to allow layer 3 filters to be applied to a layer 2 port. Below is a snippet from a Cisco switch: IPv6 access-list ACCESS_PORT remark **Block all traffic DHCP server -> client** deny udp any eq 547 any eq 546 remark **Block Router Advertisements** deny icmp any any router-advertisement permit any any Interface GigabitEthernet 1/0/1 switchport IPv6 traffic-filter ACCESS_PORT in The filter above will deny any router advertisements for a particular port on the switch (the filter also shows how to deny DHCP server packets). Since you can filter router advertisement on a workstation and you dont want to deny router advertisements from an actual router, this is the only way to prevent a rogue device from becoming a router on the LAN. Also, not all switches support this feature. The administrator responsible for device configuration should contact the appropriate network equipment vendor to get a list of supported switches. This guide is primarily focused on the firewall and DMZ. Default routing behaviors should be defined on servers and router gateways in the DMZ to avoid the risk of rogue router advertisements. 6.2.2 Automatic Tunneling

Even though we have defined this early phase of IPv6 migration to consist of an Internet connection and public servers in a DMZ with the internal enterprise remaining IPv4, there is still a risk of internal hosts attempting to automatically launch IPv4 based tunnels to Internet based tunnel gateways. Security policies should be defined and host configurations administered to prevent this (assuming it is an unwanted behavior). The table below offers help in blocking automatic tunnels at the perimeter firewall.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.



Candidate Best Practices

The bullet point list below is taken from a Cisco presentation and offers consideration points for possible best practice security steps to consider. Implement privacy extensions carefully Filter internal-use IPv6 addresses at the enterprise border routers Filter unneeded services at the firewall Selectively filter ICMP Maintain host and application security Determine what extension headers will be allowed through the access control device Determine which ICMPv6 messages are required Deny IPv6 fragments destined to an internetworking device when possible Ensure adequate IPv6 fragmentation filtering capabilities Drop all fragments with less than 1280 octets (except the last one) Implement RFC 2827-like filtering and encourage your ISP to do the same Document procedures for last-hop traceback Use cryptographic protections where critical Use static neighbor entries for critical systems Implement ingress filtering of packets with IPv6 multicast source addresses Use traditional authentication mechanisms on BGP and IS-IS Use IPsec to secure protocols such as OSPFv3 and RIPng Use IPv6 hop limits to protect network devices Use static tunneling rather than dynamic tunneling Implement outbound filtering on firewall devices to allow only authorized tunneling endpoints

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


7 Servers/Endpoints
There is not a single right approach to making the corporate public facing application services available to IPv6 end users. Most enterprises will likely deploy a dual-stack infrastructure where an IPv6 address is added to the same interface that an IPv4 address is already assigned. This approach eliminates the need for a separate server which minimizes the capital cost. However, some enterprises may feel uneasy about supporting an immature IPv6 service on a stable IPv4 server. IPv4 has been around for many years. IPv4 applications have been thoroughly tested as can be. There are newly found flaws that come to light from time to time, but software vendors and customers are quick to remediate these issues. With IPv6, there is not an industry-wide support for it at the time being. If the customer base is not pushing on Vendors for IPv6, vendors will not invest the resources to support it. Like most software, vendors can make their attempts to thoroughly test their applications for problems, but it is not until the greater user community gets their hands on the applications that unexpected issues and flaws are discovered. While vendors may state their application is IPv6 ready, it may take several iterations or releases before some issues are identified and resolved. For this reason, some enterprises may elect to deploy a separate physical server for IPv6. Or as an alternative, they could also consider using Network Address Translation (NAT64) or load-balancers to intercept IPv6 sessions and present it to the corporate servers as IPv4. In Figure 7.1, it illustrates how an enterprise can use NAT64 to service IPv6 users while keeping their Internet servers IPv4 only.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


Figure 7.1NAT64 Note in the above example, the enterprise Webserver is only assigned an IPv4 address of When an IPv6 user attempts to access this site, the user is given the IPv6 address (2001:DB8:8400::C1:101) in the DNS response. The packets follow the appropriate routing path to the destination site. At the site, a NATing device translates the IPv6 address to IPv4. The destination address 2001:DB8:8400::C1:101 is replaced with The source address is also translated to an IPv4 address. As far as the Webserver is concerned, it is processing an IPv4 request and is not aware of the initial IPv6 request. There are some drawbacks with this approach. AT&T encourages readers to conduct their own research and test the solution thoroughly before rolling them out in your production environment.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


8 Domain Name System (DNS)

Before moving forward with this section, please make sure the corporate Internet gateways/servers are accessible over both IPv4 and IPv6 Internet. Premature announcement of domain name may result in black-holing traffic sometimes referred to as internet brokenness. In a typical IPv4 network environment depicted in Figure 8.1, an IPv4 user enters an easily recognizable or memorable domain name into an application such as a web browser. The application uses the underlying operating system to issue a DNS query to resolve the domain name to an IPv4 address. These requests are referred to as a Standard A record request. Upon receiving a Standard A request, a DNS server will respond with an answer containing the IPv4 address associated with the requested domain name. In Figure 8.1, is associated with both an IPv4 and an IPv6 address with a DNS entry for both addresses. However, the user is configured to support IPv4-only addressing and will likely request just a Standard A or IPv4 address from the DNS server. It will receive only the IPv4 address corresponding to

Figure 8.1Standard-A DNS Request If the end-user is dual-stacked as shown in Figure 8.2, it will send two DNS requests to its DNS server: one for Standard-A and second for Quad-A. As mentioned above, Standard-A is an IPv4 address record associated with a domain name. Quad-A or AAAA is associated with the IPv6 address. As long as the DNS server has the Quad-A record for the requested domain name, it will provide the IPv6 address back to the end-user in its response. Notice in the figure below, the DNS server is IPv4-only and does not have an IPv6 address assigned. This is fine since both the Standard-A and Quad-A requests are made using IPv4 source/destination addresses. In this example, the dual-stack end-user is pointing only to an IPv4 DNS server. Therefore, it will use the IPv4 address to request both a Standard-A and a Quad-A record from the DNS server. If the DNS server was also dual-stacked, then the client will likely issue DNS requests using its IPv6 address instead of IPv4. This is the default behavior of most operating system. If the end-user has a choice between IPv4 and IPv6 destination addresses, then most operating system will prefer IPv6 over IPv4. Note: this default behavior can be changed by modifying the prefixpolicy table of the operating system.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


Figur e 8.2Quad-A DNS Request Before a Quad-A record can be provided by any DNS server, it must first exist in an authoritative DNS server for the requested domain name. In most situations, the requested domain name may not be cached on the initial DNS server an end-user is pointing to. If the entry does not exist, the DNS server will query its upstream DNS servers and may contact the root DNS server for the requested domain zone such as .com, .net, .edu, etc. The root server should have the IPv4 and IPv6 addresses of the authoritative DNS servers for the requested domain. This information is imported into the root server from the domain name registrars. Therefore, it is very important to update the corporate profile with the domain registrar. The corporate profile will include at minimum the primary domain name and an IP address of the DNS servers. If the authoritative DNS servers are available by an IPv6 address, then the profile must be updated to include the new IPv6 address. Otherwise, other non-authoritative DNS servers will not know who to contact to access the DNS information via IPv6. As mentioned above, the Quad-A records can be obtained from an IPv4-only addressed DNS server. The DNS server does not need to be IPv6 capable. Quad-A record requests can be made using either the IPv4 or IPv6 protocol. Conversely, an IPv6-only host can request Standard A record (i.e. IPv4 address). In the near term, enterprises can choose to migrate their internet gateways or servers to IPv6 while keeping their DNS servers IPv4-only with very little drawback. It is an acceptable migration approach since most end-users are expected to be dual-stacked for many years. Moreover, most service providers should exchange domain information across both IPv4 and dual-stacked DNS servers. Therefore should also appear on the dual-stack DNS servers even though the authoritative DNS server is only available via IPv4 address. However if the service providers support IPv6-only DNS servers or not share domain information between IPv4, IPv6, and dual-stacked DNS servers, then there is a chance some end-users may not receive a DNS response. To eliminate this uncertainty, enterprises can decide to dual-stack their DNS servers and make their domains accessible by IPv4 or IPv6 users. However dual-stacked DNS servers do not completely resolve connectivity issues. As mentioned earlier, many dual-stack end-users have experienced internet brokenness. Brokenness occurs when a dualstack end-user is not able to access contents via IPv6 address, but the destination is accessible via IPv4 address. A dual-stack user will typically request and receive both a Standard-A and a Quad-A record from their upstream DNS servers assuming both records exist. Upon receiving these records, a dual-stack user will use its IPv6 address to connect to the remote server via IPv6 because operating systems by default prefer IPv6 over IPv4. If the destination is not reachable via IPv6, then the session may time out without trying to access the destination via IPv4. This will give most users the impression that the content server is down, but in reality, it is available via its IPv4 address. Why isnt this server reachable

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


via IPv6? One reason may be that IPv6 Internet service is not supported by all ISPs. In addition, IPv6 peering relationship is still being established between providers. ISPs may have an IPv4 peering relationship with another provider, but it may not have an IPv6 connection between the ISPs. This will create a situation depicted in Figure 8.3 where a destination is reachable via IPv4, but it is not reachable via IPv6. As shown below, three ISPs have a fully-meshed IPv4 peering relationship with each other, but a hub/spoke IPv6 relationship between ISP(A) to other two providers. In most peering relationships, ISPs will tag routes learned from its peers as non-transit routes. This means that ISP(A) will not pass routes learned from its peers to another peering partner. For instance, ISP(A) will not advertise routes learned from ISP(B) to ISP(C). Therefore ISP(C) will not have an IPv6 route to that is hosted on ISP(B)s network. Even though the end-user on ISP(C)s network has connectivity to IPv6, this user does not have access to all contents on the IPv6 Internet. This issue may persist for some time until the peering or network relationships become more mature.

Figure 8.3--Internet Brokenness and IPv6 Peering Because of the brokenness issue, many enterprises have chosen to setup a secondary domain name to host their IPv6 web servers. For instance instead of, the enterprise would use to cater to IPv6 users and maintain for IPv4 users. The main benefit of this approach is it eliminates the brokenness issue, but it also introduces other challenges. One of the questions it raises is how would IPv6 users know to use to access the web server via IPv6? If the end-user is dual-stacked, then a company could place a link on the IPv4 homepage to redirect these users to the IPv6 site. Unfortunately, this approach does not help those IPv6-only addressed end-users, but it is highly unlikely that these users would be provided IPv6-only addresses without the ISP providing some type of translation services to give them access to IPv4 sites. Some vendors have begun to address the brokenness issue. In previous Windows versions, the browser timed out without attempting the IPv4 addresses of the destination server. However in recent lab tests, Windows 7 clients are now resolving to the IPv4 website when IPv6 connection isnt available. This is quite promising, but more work is needed in this area. Presently, it is taking some time to failover to the IPv4 site due to retries and timeouts. For some impatient users, the long delay may not be acceptable, and
NDC Release 1.0 2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures. 33

the users may click away from the site before it has an opportunity to retrieve the data. Therefore a faster discovery and failover solution must be incorporated to make the transition seamless to the end-user as documented in Internet DraftHappy Eyeballs: Success with Dual-Stack Hosts dr aft-ietf-v6opshappy-eyeballs-04. Otherwise the enterprises may lose out on potential customers and revenue. Eventually these connectivity issues will be addressed by vendors, ISPs, enterprises, and/or end-users. In the meantime, some users may struggle with inconsistent IPv6 service.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


9 Testing/Verification
This is perhaps the most important step in the IPv6 migration process. One must determine if the following questions can be answered with a firm yes: 1) Do you have access to the corporate Internet router from the IPv6 Internet? 2) Are the security rule-sets implemented correctly? 3) Are you receiving Quad-A DNS responses? 4) And ultimately, can you access the corporate Internet servers from the IPv6 Internet? Before tackling the above questions, the testing personnel must first connect to the IPv6 Internet. This Internet connection must not be the same IPv6 connection that the corporate servers are on. It can be a 3rd party transition service such as an IPv6 tunnel broker or Teredo tunnel service. There are for-free tunnel brokers like Hurricane Electric that may require user registration. Alternatively, one can use the Teredo service that is readily supported on most Windows and Linux operating systems. The Teredo service can be used by any users with an IPv4 Internet connection. The Teredo service may be a quick and easy way to connect to the IPv6 internet. Once connected to the IPv6 Internet, the tester can use the typical network troubleshooting tools like ping or tracert to test connectivity to IPv6 destination addresses. One may need to use the option 6 for IPv6 along with these commands. This should allow testers to confirm there is IPv6 connectivity to the Corporate Internet and key servers/gateways. It can also be used to conduct preliminary security tests of the firewall. There are some security tools for IPv6 that can be used to verify that the implemented rule-sets are working properly. For DNS, the tester can use nslookup to perform DNS query against its DNS server. The test may need to go into the nslookup mode and issue set type=aaaa to force the nslookup application to request Quad-A request. As another option, the test can issue either ping or tracert with the -6 option using the domain name as the destination. -6 option will force the clients operating system to issue a Quad-A request for the domain name. Now, the tester is ready to test the application by typing the URL for the server into the application. If the application is able to retrieve the information, it is likely the data was retrieved via IPv6. However if the tester is using Teredo service, then the tester may need to modify the prefixpolicy. By default, Windows Operating System prefers IPv4 over IPv6 destination address. So if the domain name resolves to both IPv4 and IPv6 addresses, then the Windows 7 client will use IPv4 address to access the data. Therefore, it is highly recommended that Wireshark is used to determine if the client is using IPv6 or IPv4 addresses to access the destination.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


10 Conclusion
The migration to dual stack capabilities will bring a lot of change, from security policy reviews to equipment upgrades to application testing to legal review. Organizations must be engaged in an IPv6 adoption team now that, similar to the Year 2000 event, delivers a holistic approach to dual stack support. Unlike Year 2000, dual stack services will be needed at a point of demand, versus a date on the calendar. Given the lack of maturity of the IPv6 software stack on many vendors, it is strongly urged that enterprises carefully evaluate and test the IPv6 functionality from devices that they choose to manage, or look at a service provider to deliver the managed abilities.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


Appendix A

Appendix A A-1 Establishing a Teredo Tunnel

Teredo is an IPv4 tunneling protocol that enables IPv4 users to access IPv6 resources. IPv4 users build an IPv4 tunnel across their existing IPv4 WAN and Internet to a publicly available Teredo Tunnel server. Once the tunnel is established, IPv4 users can send IPv6 packets inside the tunnel. Teredo can be used as a quick way to connect to the IPv6 Internet to test connectivity as discussed in Section 9. Since most enterprises are planning to migrate to Windows 7 Operating System in the next few years, this section will mainly focus on enabling Teredo service on Windows 7 clients and does not cover instructions for other Windows platforms. Some principles discussed in this section may also apply to Windows XP, Vista, etc. Unlike Windows XP, IPv6 protocol stack is enabled by default on Windows 7. Windows XP users must manually install the IPv6 protocol stack. Its simple to verify that a Windows system is running IPv6 by issuing a very familiar DOS command ipconfig /all. This command will provide a report of all IP addresses (IPv4 and IPv6) assigned to the systems interfaces. Under each interface, there should be an IPv6 link-local address that starts with FE80::/64. This shows that IPv6 protocol is running on the system. In the ipconfig /all results, one should also see a pseudo interface for the Teredo Tunnel service. At a quick glance, the Teredo interface may appear to be up and running. However this is not the case. It is actually in an "active" state. In this "active" state, an IPv6 address (2001::/32) is assigned to the Interface. This address is a legitimate IPv6 address reserved for Teredo service and can give users the wrong impression that they are connected to a Teredo Tunnel server. They are actually in a dormant mode and not connected to a live Tunnel server. This is likely to address the criticism of the previous Windows releases that automatically connected to a tunnel server. Since Teredo service is a tunneling protocol, it bypassed most conventional firewalls and intrusion detection systems because these systems were not capable of reading deeper into the encapsulated packets. So now, users must manually enable the Teredo protocol using the following steps: 1) Open up the Group Policy Manager console (gpedit.msc). Then go to Local Computer Policy> Admin Templates> Network> TCPIP Settings> IPv6 Transition Tech> Teredo Default Qualified. Change it to Enabled. 2) Now the Teredo service should be up and running. However you must follow the directions below to force Windows to perform Quad-A record request. a) By default, Windows Vista and 7 will not request a Quad-A record if there is no non-link local address assigned to the interface. Teredo Interface is ignored by the operating system. Even if a global unique address out of the (2001::/32) range is assigned to the Teredo interface, these two Windows operating system will not ask for a Quad-A record for a domain name. For instance, is only reachable via IPv6 address. If the Teredo client attempts to surf to, the Wireshark trace shows that the Teredo client only requests a standard A record. So this means most Teredo clients will not be able to get to any IPv6 websites since the IPv6 domain name will not resolve to an IPv6 address or Quad-A response. b) Workaround is to assign an IPv6 address and a default gateway manually to an active interface. When this is done, an IPv6 default route (::/0) will be added pointing to the default gateway address that was manually entered. This will force all IPv6 traffic to this default gateway. This is not what we want since this will black-hole the IPv6 traffic. So

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


Appendix A
we must add a default gateway that points to the Teredo Interface IPv6 address with a lower metrics than the existing ::/0 route in the routing table. Once this is done, Teredo clients will be able to access some IPv6 sites.

A-2 IPv6 Address Example

The figure below illustrates an approach for allocating IPv6 prefixes within an enterprise network. This is just an example. There is no one correct method. Each enterprise must carefully evaluate its corporate requirements and determine the appropriate addressing strategy that is right for them.

The diagram depicts four network segments that require IPv6 addresses: CE-PE WAN, CE-Firewall LAN, DMZ LAN, and Corporate LAN. In this example, an enterprise has been allocated a 48-bit prefix. The CE-PE link addresses are typically provided by the ISP. Therefore there isnt much a customer needs to do for this link. Next is the CE-Firewall LAN subnet. If the present Industry standard is followed, a 64-bit prefix should be allocated across this LAN even though there are just two devices in it. A 60-bit prefix is carved out from the aggregate 48-bit prefix for point to point connections. From which, a 64-bit was allocated to the CE-Firewall LAN. This gives sixteen 64-bit prefixes that could be used for other point to point connections. If longer prefixes such as 127-bit prefix are used, then it can support greater number of point to point connections. Similarly, the DMZ LAN segment is assigned a 64-bit prefix from a larger 60-bit that was taken from the aggregate 48-bit prefix. That takes about another sixteen 64-bit prefixes. Between the DMZ and CE-Firewall network segments, a total of thirty-two 64-bit prefixes have been allocated. That leaves a total of 254 contiguous 56-bit prefixes to be assigned to the rest of the enterprise network. If possible, IPv6 prefixes should be allocated across double-octet, octet, or half-octet boundaries. This will help to avoid overlapping prefixes. Double-octet is 16 bits wide and is represented by four hex digits within the two colons (:0000:) in IPv6. An octet is a byte or 8-bits. It takes up two hex
NDC Release 1.0 2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures. 38

Appendix A
digits. Half-octet is 4bits or one hex digit. The actual prefix boundary will be determined by the enterprise addressing strategy. In this example, the CE-Firewall and DMZ prefixes were chosen from the upper bounds of the 48-bit aggregate prefix. With this approach, network administrators do not have to be concerned about prefix overlaps or address conflicts. It will be clearly understood that upper bound is reserved for special purposes.

A-3 Frequently Asked Questions:

Why do we need IPv6?
With huge growth in wireless technology/devices and expansion of IP networks, many network service providers are expecting to run out of IPv4 addresses soon. Although IPv4 networks will continue to be supported for many years to come, it's wise for organizations to begin thinking about IPv6 and planning for the future. Many ISP such as AT&T will likely offer IPv6 services as dual-stack service that supports both IPv4/IPv6 addresses to enable organizations to slowly adopt IPv6.

How can I track exhaust of IPv4?

There are several sites that provide information about IPv4 address allocation and exhaust predictions. The date when IANA will exhaust is the most widely quoted and predicted date. Other dates include when each RIR will exhaust, when all RIRs will exhaust and then when ISPs and enterprises will exhaust their addresses. Here are the links of interest.

IANA space.xml NRO Geoff Huston Tony Hain ARIN

What are the main use cases (applications) of these v6 customers? E.g., Web surfing, consumer apps, etc.
Individual motivation to migrate to IPv6 varies for each customer. Some customers are interested in IPv6 to make sure they don't lose out on potential IPv6 only customers. Others may be pushed to support IPv6 due to business requirements levied on them by extranet partners who are migrating to IPv6. Some may be deploying devices that require large blocks of addresses for inventory/tracking purposes.

What's the process for requesting IPv6 addresses?

Organizations must meet certain minimum requirements to receive IPv6 addresses directly from ARIN, APNIC, or RIPE. Most ISPs will be assigned /32 network. Non-ISPs will typically be assigned minimum of /48 network address. ISPs and Non-ISPs can request larger block if they can provide legitimate justification for more addresses. Customers should review the policies listed below to determine if they qualify for IPv6 addresses. If not, they will need to request IPv6 addresses from their ISP.

For ISPs in the US, they should follow the instructions listed in the following linke: For non-ISPs in the US, use the following link:

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


Appendix A For organizations in Asia-Pacific, please read the IPv6 policies listed in the link: For EMEA organizations, IPv6 policies are listed in the following link:

Here's a link to IANA website listing the IPv6 blocks that have been allocated to the Regional Internet Registrars:

What IPv6 address assignment options are available?

There are 3 addressing options: manual, DHCP, or auto-configuration. Manual addressing allows users to statically assign IPv6 address on clients. DHCP allocates addresses dynamically to clients. However there is a slight difference in DHCPv6 compared to DHCPv4. There are two parameter options that must be enabled to turn on DHCP and to allocate other DHCP information to clients. Auto-configuration allows IPv6 clients to assign themselves IPv6 address based on Neighbor Discovery Protocol called Route Advertisement packets. Please see the attached charts to see summary of the information about DHCPv6 and Auto-configuration...

Do you SWIP the PA IPv6 address space that is assigned to a customer?

The answer is yes. There should not be any difference in the information provided with the SWIP (Shared WHOIS Project is the process used to submit, maintain and update information of WHOIS records per RFC 1491.) information for IPv4 and IPv6.

Do you accept v6 blocks from other RIRs? E.g., accept a RIPE block from a NY peering?
AT&T will only accept PI (Provider Independent) addresses and AT&T assigned PA (Provider Assigned) from a customer. AT&T will not accept IPv6 addresses that are owned by another provider.

What's AT&T Policy regarding IPv6 Internet multi-homing?

If a customer is interested in a multi-homing internet solution (i.e. connection to AT&T and another ISP), the customer must own the desired IPv6 address they want to advertise. IPv6 address must be directly assigned to the customer by their regional internet registry organization like ARIN. It can not be an address provided by another service provider. In addition, the IPv6 address block must be a minimum of /48 subnet. AT&T will not advertise anything longer than /48 subnet to the Internet. Within the AT&T network, the customer can advertise a longer subnet. However, AT&T will not advertise a prefix longer than a /48 subnet.

How many IPv6 routes does AT&T dual-stack MIS support?

BGP route advertisement is done on an exception basis. For each route, AT&T will add the route into the allowed filter list on the PE router to allow the route to be accepted into the network.

Do you have any v6 only customers? If so, why? Because no more v4 addressing or for some other reason?
There are very few customers who are considering a complete migration to IPv6 network. Most customers are electing to deploy a dual-stack infrastructure to support both IPv4 and IPv6 services. Those who are considering a complete migration have the added challenge of providing their IPv6 users access to internet/intranet resources that remain on IPv4 network.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.


Appendix A What 6-4/4-6 translation methods do you use?

AT&T is actively testing 2 transition technologies: 1) NAT64 to allow IPv6-only MIS customers to access IPv4 internet resources and 2) T6 gateway to allow IPv4-only internet users to access MIS customers' IPv6-only internet servers. This requires software to be installed on the user's PC.

Is there any impact on encrypted VPN tunnels with IPv6?

If it's native IPv6 end-to-end, then VPN tunnel will be fine. If you are trying to establish a tunnel via v4v6 NAT, then you will run into issues. It's because IPv6 utilizes the extended headers for IPSec. If NAT is performed in the path, then the extended headers are stripped and you lose the IPSec session information. In the dual-stack offer, customer should be able to establish native IPv4-Ipv4 and IPv6-IPv6 IPSec sessions without issues.

How is v6 DNS handled for Web sites that are both v6 and v4 capable using the same domain name? E.g., what if were both v6 & v4 capable? How would you send v6 customers AAAA records while v4 customers regular A records?
DNS servers will provide standard A or Quad-A record to any client that requests the information. IPv4 only clients can request a Quad-A record, and IPv6 only client can ask for standard A record. The actual request may vary depend on client operating system. Customer should test their applications and systems to better understand DNS behavior.

What does AT&T see in 2012 and beyond in terms of v6 deployment and # of v6 customers?
We expect a significant increase in interest and in actual adoption of IPv6 network services in 2012. We are actively engaged with many customers in discussing and strategize the best approach to migrating to IPv6.

NDC Release 1.0

2012 AT&T Knowledge Ventures. All rights reserved. AT&T is a registered trademark of AT&T Knowledge Ventures.