ATT IPV6 Migration Guide R1 February 2012.pdf - The Cisco ...

AT&T 

IPv6 

Migration Guide 

Release 1.0 

February 29, 2012 

NDC Release 1.0 © 2012 AT&T Knowledge Ventures. All rights reserved. 1 

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. 



Table of Contents 

1 Introduction ............................................................................................................................................ 5 

2 Migration Scenarios Overview ............................................................................................................... 6 

2.1 End-User Connections .................................................................................................................. 6 

2.2 Internet Content ............................................................................................................................ 7 

2.3 Remote Access ............................................................................................................................. 7 

2.4 Mobility ........................................................................................................................................ 7 

2.5 Corporate Internet Access............................................................................................................. 8 

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

3.1 IPv6 Addressing ......................................................................................................................... 10 

3.2 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 Implementation ........................................................................................................................... 15 

3.4 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 Establish IPv6 Enabled Connectivity ................................................................................................... 19 

5 Access Router Configuration ............................................................................................................... 20 

5.1 BGP ............................................................................................................................................ 20 

5.2 Static ........................................................................................................................................... 21 

5.3 Access-List Formats ................................................................................................................... 22 

6 Security ................................................................................................................................................. 24 

6.1 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 Candidate Best Practices............................................................................................................. 28 

7 Servers/Endpoints ................................................................................................................................. 29 

8 Domain Name System (DNS) .............................................................................................................. 31 



9 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 



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. 



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. 

2.1 End-User Connections 

End-user refers to the consumer broadband Internet market, typically homes served by broadband (U- 

Verse, 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 customer’s 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 



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

of this document. 

2.2 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 company’s 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. 

2.3 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. 

2.4 Mobility 

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 can’t 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. 



2.5 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) 

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. 

Intranet Complexities 

DMZ 

Internet 

Access 

Router 

Internet 

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. 



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 Resource Migration 

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. 



3 IPv6 Strategy 

With a goal of establishing dual-stack (simultaneous IPv4 and IPv6) internet access, the following 

fundamental sequence occurs: 

1. Establish an addressing plan 

2. Procure Dual-Stack Internet Service 

3. Configure the Access Router 

4. Configure the firewall 

5. Configure IPv6 on DMZ Resources 

6. Augment DNS 

7. 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 software’s 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 enterprise’s 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. 

3.1 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 2 32 or about 4.3 billion addresses. In comparison, IPv6 provides 2 128 , or in the longer 

notation, that’s 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 



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 2 72 (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 repeatedly—not 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 



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 today’s 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 RFC6296—“IPv6-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&T’s “IPv6 Fundamentals Guide” for 

more information on IPv6 addressing. 

3.2 Planning 

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

1. Assess corporate network requirements 

2. Determine the type of public address 

3. Develop an addressing strategy 

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 later—a 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 

1 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. 



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 enterprise’s 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 provider’s 

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 provider’s 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 



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 RIR’s 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. 



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 

doesn’t cause issues within the public infrastructure. 

Please see Appendix A-2 for an example of IPv6 address allocation to the public facing infrastructure. 

3.3 Implementation 

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 71 st 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 today’s 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 & Verification for test options. 



3.4 Multi-Homing 

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.4—IPv6 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 host’s 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 



outed out through the Internet service connecting to ISP#2. This is because the aggregate address 

“2001:DB8:1235::/48” encompassing the host’s 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 it’s 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 isn’t 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 provider’s network will not grossly impact their business. Some of the enterprises today 

use the ISP’s allocated address space to develop an IPv4 multi-homing solution. In today’s IPv4 

networks, ISPs allow enterprises to advertise another ISP’s address into their network. However this 

practice is forbidden in IPv6 networks. Most if not all ISPs will not accept another ISP’s 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 enterprise’s prefix will not be visible beyond the ISP’s 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 carrier’s 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 



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 -- 

http://www.iana.org/assignments/IPv6-unicast-address-assignments/IPv6-unicast-addressassignments.xml.) 

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. 



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. 



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 ISP’s 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. 

5.1 BGP 

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 

customer’s 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 address-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 activate command and added under the IPv6 address family. 

Since the IPv4 and IPv6 neighbors have been defined with the remote-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 network command. Note there is a slight difference in the syntax 

of the IPv6 network 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 192.168.10.2 

neighbor 192.168.10.2 remote-as 7018 



neighbor 2001:DB8::2 remote-as 7018 !configure IPv6 neighbor 

address/ASN 

address-family ipv4 !define ipv4 address family 

neighbor 192.168.10.2 activate !enable BGP for neighbor 

(enabled by default) 

no neighbor 2001:DB8::2 activate !disable IPv6 neighbor 

relationship 

network 192.168.100.0 mask 255.255.255.0 !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 ISP’s network. This policy may vary between service providers. 

5.2 Static 

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. 



5.3 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: 



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. 



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 it’s not a private address, it hasn’t been scrubbed by a 

firewall.” “If it is a private address it won’t 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 v4v6 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. 

6.1 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 firewall’s 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. 



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. 



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. 



6.2 Internal Security 

6.2.1 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 don’t 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. 



6.3 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 



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. 



Figure 7.1—NAT64 

Note in the above example, the enterprise Webserver www.abccompany.com is only assigned an IPv4 

address of 12.1.1.1. 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 NAT’ing device translates the IPv6 address to IPv4. The destination 

address 2001:DB8:8400::C1:101 is replaced with 12.1.1.1. 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. 



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, 

www.abccompany.com 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 www.abccompany.com. 

Figure 8.1—Standard-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. 



Figure 8.2—Quad-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 www.abccompany.com 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 isn’t this server reachable 



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 www.abccompany.com 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 www.abccompany.com, the enterprise would use 

IPv6.abccompany.com to cater to IPv6 users and maintain www.abccompany.com 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 IPv6.abccompany.com 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 isn’t 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 



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 Draft—“Happy Eyeballs: Success with Dual-Stack Hosts draft-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. 



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 3 rd 

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 client’s 

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. 



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. 



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. It’s 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 system’s 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, IPv6.google.com is only reachable via IPv6 address. If the 

Teredo client attempts to surf to IPv6.google.com, 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 



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 isn’t 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 



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 http://www.iana.org/assignments/ipv4-address-space/ipv4-addressspace.xml 

• NRO http://www.nro.net/statistics/ 

• Geoff Huston http://www.potaroo.net/tools/ipv4/index.html 

• Tony Hain http://www.tndh.net/~tony/ietf/ipv4-pool.htm 

• ARIN https://www.arin.net/knowledge/statistics/index.html 

https://www.arin.net/participate/meetings/ARIN-XXVI/ 

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: 

https://www.arin.net/resources/request/IPv6_initial_alloc.html 

• For non-ISPs in the US, use the following link: 

https://www.arin.net/resources/request/IPv6_initial_assign.html 



Appendix A 

• For organizations in Asia-Pacific, please read the IPv6 policies listed in the link: 

http://ftp.apnic.net/apnic/docs/IPv6-address-policy 

• For EMEA organizations, IPv6 policies are listed in the following link: 

http://www.ripe.net/ripe/docs/IPv6policy.html 

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

Registrars: 

http://iana.org/assignments/IPv6-unicast-address-assignments/IPv6-unicast-addressassignments.xml 

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. 



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 www.gs.com 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.

ATT IPV6 Migration Guide R1 February 2012.pdf - The Cisco ...

Create successful ePaper yourself

Delete template?

Save as template?