ATT IPV6 Migration Guide R1 February 2012

8/13/2019 ATT IPV6 Migration Guide R1 February 2012

http://slidepdf.com/reader/full/att-ipv6-migration-guide-r1-february-2012 1/41

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

AT&T is a registered trademark of AT&T Knowledge Ventures.

AT&T

IPv6Migration Guide

Release 1.0

February 29, 2012





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 orchanged by AT&T at any time without notice. Any contractual relationship between AT&T and acustomer is contingent upon AT&T and a customer entering into a written agreement signed byauthorized 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&Tfiling a tariff with federal and/or state regulatory agencies and such tariff becoming effective. Suchcontract 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 networkenvironments. 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 “dual-stack”.

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 facingcorporate 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 serviceswill 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 IPv6capabilities. For DMZs of corporate networks, this trend will drive the need to have public facing contentreachable through IPv6 as well as the current IPv4.

The broad use of private (RFC 1918) addressing in corporate networks helps lessen the urgency of IPv6migration 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 technicalissues, or best practices are still evolving. An initial focus on the public facing corporate infrastructureallows the organization to begin adopting the technology in a limited fashion. This provides a means fordeveloping experience with IPv6 technology and addressing the more immediate emerging needs, whileminimizing 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 initialguidance and open issues on Corporate Intranet Access.

Corporations typically deploy one or more Internet access facilities to support the enterprise. Thefacilities are used to provide employees access to web-based content and applications, as well as tosupport 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 securityappliances 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 withonline 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 initialfocus 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 scopegreatly 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 internalresources and intranet connectivity. This greatly lessens the concern associated with IPv4 exhaustion forenterprise 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 potentialsolutions; 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 andaccepted.

The following paragraphs provide a brief context for some of the non-enterprise IPv6 adoption issuesalong 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, thisspace is the least technically savvy. There are a number of approaches being explored in the end-useraccess space.

Many of these approaches involve assigning an IPv6 address to the customer’s connection whilemaintaining 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 tofollow. 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 notavailable 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 bethe predominant driver for the migration to IPv6. However, the approaches and technologies are largely aservice 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 releasesof this document.

2.2 Internet Content

Internet content refers to the market segment with business models based primarily on providing Internet-

based content and services. The initial migration guidance provided for enterprise migration isconceptually applicable to these environments, but the scale and diversity of technologies presentadditional 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 IPv6access 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 industryand often a key aspect of the company’s value proposition. These businesses, together with InternetService 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 someapplicability for these businesses. An important caveat is that the urgency for providing IPv6 access to theinternal 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 capabilitiesmay 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 servicesmigrate to IPv6 capabilities, enterprises will need to re-evaluate and adapt their remote accessmechanisms.

The current version of this guide does not address Remote Access. Existing IPv4 mechanisms shouldcontinue to serve until native IPv6-only connectivity starts emerging as the norm. The guide will beamended 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 alsofertile ground for “green field” or totally new kinds of network usage. Package tracking, smart gridmeters, 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 usagecharges 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 acatch-22. Devices can’t support IPv6 until the network allows it, and the network development effort iscomplicated by huge demand for new capabilities, including VoIP, at a scale well beyond initialexpectations. For now, it is expected that IPv6 cellular wireless ubiquity will lag behind wirelinedeployment.





2.5 Corporate Internet Access

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

Figure 2.5-Typical Enterprise Network

The scope of the DMZ and associated ‘public’ resources is typically quite small compared to theenterprise intranet. The scope of the intranet can be quite extensive with significant implications fordeployment of IPv6. The use of private addressing, however, greatly reduces the urgency of migration

for the intranet portion of the enterprise.

Intranet Complexities

One of the fundamental differences between IPv4 and IPv6 is in the use of private addressing. Where

IPv4 allows the use of private addressing in the corporate Intranet, and can take advantage of NetworkAddress Translation (NAT) to provide a beneficial decoupling between internal corporate networks andthe Internet. In contrast, the use of NAT is currently discouraged in IPv6, with the expectation that alldevices 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 toswitch to a new service provider, some degree of re-addressing is required. With NAT, the scope of thisre-addressing effort is greatly reduced, affecting only the DMZ. The internal private addressing remainsintact. 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 significantwork to be done before these technologies are fully mature.

Internet

DMZ

EnterpriseNetwork

(LAN/WAN)Internet

Access

Router

Public Content

-Web

- Email

- Etc





Many enterprises use multiple internet access connections from diverse corporate locations and/or diversecarriers. 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 asupported 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 mustalso 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 withthe scope and risk of unduly early intranet deployment warrant significant deliberation prior to IPv6deployment. 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 ofthe 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 businessearly participation in the IPv6 space while avoiding undue risk. It is this initial migration that is discussedin 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 followingfundamental sequence occurs:

1. Establish an addressing plan

2. Procure Dual-Stack Internet Service3. 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 simplyverifying 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 morememory 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 assessmentof the enterprise’s ability to handle the additional complexity and capacity demand of running twosimultaneous 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 232

or about 4.3 billion addresses. In comparison, IPv6 provides 2128

, or in the longernotation, 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 global-

unique) 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, thesmallest address space that should be allocated by an Internet Service Provider (ISP) to an enterprise

customer is a 56-bit prefix and a 48-bit prefix if allocated directly by a Regional Internet Registrar (RIR).

Therefore, it would take a potential hacker a long time to completely probe the combination of 272 (128

bits minus 56-bit prefix) addresses and all potential TCP/UDP ports in an attempt to enumerate a network.

In effect due to such large address allocation, the publicly-addressed IPv6 devices could be as tough if not

tougher to discover than the privately addressed IPv4 devices. It is like a hacker trying to probe the entire

IPv4 Internet address space a trillion times 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 fromexternal/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 eachindividual 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 usethe 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 addressesto the rest of the corporate network and not just the public facing servers. Networkadministrators 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 ataddressing 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 NAT-

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

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.

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

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 requirements2. 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 operateonly 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 networkmay need to be completely readdressed later—a major undertaking. The final step is to craft anaddressing 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 ISProuter, 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 specificaddresses 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 forthem.

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. Mostenterprises 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 availableto 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 byinitially 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 isnot 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 IPv6addresses--255 unused 64-bit prefixes. The other option might be to readdress the Internet devices to adifferent 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 plentyof 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 processingadditional IPv6 routes.

Once the overall corporate network requirements are understood, the attention can now be given to theInternet network segments referenced in Figure 2.5. What IPv6 prefix and prefix length will be allocatedto 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 Internetusers? 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 arelisted 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 mainadvantages of using the PA address is it helps to control the amount of routes maintained by Internetrouters. 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 singleIPv6 route. There are obvious benefits for the ISP and the global Internet community in conservingmemory, processor, and other resources, but why should the end-users care? Better performance. End-users 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 tomaintain both IPv4 and IPv6 routes with an IPv6 route taking up more memory space and resources. Amore 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 thetime of this writing, ISPs will not accept another provider’s PA address. In addition, PA addresses aremore 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 newPA 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 prefixhanded 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. /49through /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 filteredacross peering connections either by the ISP, peering partners, or both. Depending on the corporaterequirements 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 prudentoption to avoid network readdressing in the future and to get around routing policy restrictions.

3.2.3 Develop an Addressing StrategyThis step is perhaps the toughest. It is overwhelming to develop an overall addressing strategy thatsatisfies immediate and future network needs. It is made even more challenging with the understandingthat Industry best practices are still being formulated and RFCs are being updated based on real-worlddeployments 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 tointroduce 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 pointsout several drawbacks of using variable subnetting such as misuse of reserved address space. Howeverthe 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 exactly64-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 manuallyconfigured. For a small branch office, autoconfiguration may be appropriate to avoid manualconfiguration or to deploy a DHCP infrastructure. If the present best practice of 64-bit subnet isdeployed, 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 forIPv6 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 over-allocation for a branch office that perhaps has just three subnets for a data network, a voice network, anda special application network.

Ultimately, it comes down to individual companies to determine what addressing scheme is appropriatefor their environment. 56-bit prefix boundary should be used as a guide and not as a strict standard. Usethe 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 WANaddressing 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 IPv6address pool to assign to the public network segments such as the DMZ, CE-Firewall LAN, etc. Thisgroup 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 the2001: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 ofrequired 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 networksegment 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 byincorporating 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, IPv6devices may also assign autoconfigured addresses if the subnet is on a 64-bit boundary. In order to avoidthis, 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 potentiallycause 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 nottrue. In the real world operations, these anycast addresses can be assigned much like any unicastaddresses without limitations. Even so, these addresses should be avoided as a best practice to minimizeissues in the future if these anycast addresses are treated differently

Administrators should also pay attention to their choice of variable subnet prefix or manually configuredaddress 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 suchas a MAC address then it is considered universally administered. The 71st

bit should be set. Bit 72

defines whether the address is a unicast or multicast address. By setting this bit, it tells the world that theaddress is used for multicast services. In today’s implementation, these bits are ignored by most IPv6devices, 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 technicalissues 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 hostaddress for a default gateway or servers. This approach makes it easier for potential hackers to map yournetwork. So it may be best to choose an IPv6 address that is not easily guessed. Internet address for thecorporate servers will be well known to potential hackers via DNS lookup. This does not mean that thecorporate 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 filteringenabled. 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 alwaystest 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 lessons-

learned 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 internalcorporate network devices. Therefore enterprises must pay closer attention to the internal corporaterouting in ensuring that internal hosts are routed correctly out through the appropriate Internet PoP that isadvertising the aggregate address of the host’s prefix. Otherwise, asymmetric routing may occur wherethe 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 scenarioassumes 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





routed 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 packetis 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 theoverall 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 requireredundant Internet services. This can be in the form of multiple Internet connections at a single locationor a geographically separated location. When multi-homing with a single provider, an enterprise can electto 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 thatsome ISPs may allow longer IPv6 prefixes into the network. An ISP may allow 64-bit prefix to beadvertised into their network. This may give enterprises flexibility to implement a better load-distributionsolution 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 toreaddress their corporate network whenever they decide to change providers. It may be advantageouseven for single provider enterprises to use PI addresses to allow flexibility to move to another ISP butalso 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 operatewithin a single continent. By using multiple ISPs, enterprises can have the peace of mind that a majoroutage 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 IPv4networks, 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 prefixsuch as 64-bit prefix into the network, but the enterprise will need to also advertise a summary prefix 48-

bits 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 berequired 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 connectionsare actively utilized simultaneously, then multiple 48-bit prefixes may be required since ISPs will notforward 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 summaryroute for failover. If one of the Internet connections fails, then the surviving Internet connection willreceive traffic that was destined for the other connection following the summary route similar to a typicalIPv4 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 fromone 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 theirnetwork. 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 RIRsis 23-bits long. (Please visit the following link to see other regional allocations --

http://www.iana.org/assignments/IPv6-unicast-address-assignments/IPv6-unicast-address-assignments.xml.) An ISP may decide to filter based on this 23-bit prefix boundary. Since Tier-1 ISPshave 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 WANrouting can be further simplified through summarization based on regional addresses.

http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml









4 Establish IPv6 Enabled Connectivity

Establishing IPv6 connectivity is a simple matter of procuring an Internet connection with Dual-Stackfunctionality. 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 outageshould 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 isspecified, this address is used to establish the IPv6 BGP session with AT&T. Additional providerassigned 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 theDual-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 relationshipswith the ISP’s router. It also provides sample configurations for static routes for those who may not becomfortable 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 defineIPv4 and IPv6 peers and corresponding advertisement of routes. Note: IPv4 address family is notrequired 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 toonly 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 alsomay be an easier way to manage the BGP configuration by organizing IPv4 and IPv6 BGP configurationsunder 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 onthe 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 correspondingAutonomous System Number (ASN) of its peer. The IPv4 and IPv6 address families need to beconfigured via address-family [ipv4/IPv6]. By default when an IPv4 address family is defined, both theIPv4 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, theIPv6 neighbor must be disabled under the IPv4 address family by issuing the no neighbor <IPv6

address> 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 theneighbor command as shown below. Customers can then advertise IPv4/IPv6 BGP routes through the use

of the familiar network <ipv4/IPv6 addresses> command. Note there is a slight difference in the syntaxof the IPv6 network command in that it allows the use of the /nn subnet instead of the mask keywordused with IPv4 prefixes.

BGP Conf i gur at i on:r out er bgp 65000bgp rout er - i d 192. 168. 10. 2nei ghbor 192. 168. 10. 2 r emot e- as 7018





nei ghbor 2001: DB8: : 2 r emote- as 7018 ! conf i gur e I Pv6 nei ghboraddress/ ASN

addr ess- f ami l y i pv4 ! def i ne i pv4 addr ess f ami l ynei ghbor 192. 168. 10. 2 act i vat e ! enabl e BGP f or nei ghbor

( enabl ed by def aul t )no nei ghbor 2001: DB8: : 2 act i vat e ! di sabl e I Pv6 nei ghbor

r el at i onshi pnet work 192. 168. 100. 0 mask 255. 255. 255. 0 ! net work addr ess t o be

adver t i sedaddr ess- f ami l y I Pv6 ! def i ne I Pv6 addr ess f ami l ynei ghbor 2001: DB8: : 2 act i vat e ! enabl e BGP f or I Pv6 nei ghbornet wor k 2001: DB8: F: : / 56 ! def i ne network addr ess t o be

adver t i sed

Table 5.1-BGP Configuration

In the above table, the /56 prefix under the IPv6 address family was used only as an example. Mostcustomers 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 prefixesare typically filtered by the ISP and are summarized into the aggregate PA prefix for the ISP. Eventhough /56 is announced into an ISP, the /56 route will not appear in the global routing table because mostISPs will not advertise the longer PA prefixes to their peering partners. ISPs will however allowcustomers 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 configuringIPv4 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:

I Pv6 r out e I Pv6- net wor k/ pr ef i x next - hop

Below is an example of a static route command for IPv6:

I Pv6 r out e 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”. Theword “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 shownin 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:I Pv6 rout e : : / 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 atrouter 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 theend.

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 2implicit 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 functionalityof 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 overridethe 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:

I Pv6 access- l i st access- l i st - nameper mi t pr ot ocol sour ce- I Pv6- pr ef i x/ pr ef i x- l engt h dest i nat i on- I Pv6-

pr ef i x/ pr ef i x- l engt h, ordeny pr ot ocol sour ce- I Pv6- pr ef i x/ pr ef i x- l engt h dest i nat i on- I Pv6-

pr ef i x/ pr ef i x- l engt h

Below is an example of an IPv6 ACL:

I Pv6 access- l i st RFC4890- i n- par t i alpermi t i cmp any any echo- r epl ypermi t i cmp any any echo- r equestpermi t i cmp any any 1 3permi t i cmp any any 1 4permi t i cmp any any packet - t oo- bi gper mi t i cmp any any t i me- exceededpermi t i cmp any any paramet er - probl em

deny i cmp any any rout er - adver t i sement

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:

I Pv6 t r af f i c- f i l t er access-list-name i nI Pv6 t r af f i c- f i l t er access-list-name out

Example:





i nt er f ace Fast Et her net 0/ 1I Pv6 t r af f i c- f i l t er RFC4890-in-partial i n

The following section on security contains additional information on traffic filters and examples of routerand 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 currentlyimplemented 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. Acommon 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 afirewall.” “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 aroadblock 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 practicesand augment them based on new features and new mechanisms occurring in IPv6.

New features and mechanisms introduced in an IPv6 enabled world that can become problematic in a

security discussion, particularly during a migration phase, include

• Automatic assignment of endpoint addressing

• Automatic identification of routers and gateways

• Lack of standard support for IPv6 private addressing (IPv6 NAT).

• New constructs, including Extension Headers at the IP layer

• Numerous dual-stack and v4<->v6 translation scenarios that will likely be embracedin 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 enterpriseto 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 verycommonly found in IPv4 enabled network elements, and it is anticipated that IPv6 enabled networkelements will also have a range of deficiencies that will require patching, upgrades, or work-arounds toaddress.

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 potentialvulnerabilities. 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 firewallsare largely relegated to passing IPSec tunnels to an ultimate destination for authentication. The conceptof 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 tocarefully 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 servicesand 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. Thetwo networks (IPv4 and IPv6) operate independently but both use the same physical links. Beingindependent 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 provideuseful information, such as path MTU detection (packet-too-big replies), or in testing reachability. Buteven 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 usingsolicitations 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. RFC4890 describes ICMPv6 filtering recommendations for firewalls. The table below shows typical ICMPtreatments 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 variousfunctions 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 andtranslation functions for outbound requests that resolve to IPv6-only endpoints. A proxy firewallessentially 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 publicside 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 discoveringrouter gateways and network prefix assignments. But this can also present the risk of a rogue entity onthe 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 filtersneed to be applied at the port level. Cisco and other vendors have features on their switches to allow layer3 filters to be applied to a layer 2 port. Below is a snippet from a Cisco switch:

I Pv6 access- l i st ACCESS_PORTr emar k **Bl ock al l t r af f i c DHCP ser ver - > cl i ent **deny udp any eq 547 any eq 546r emark **Bl ock Rout er Adver t i sement s**

deny i cmp any any r out er - adver t i sementper mi t any anyI nt er f ace Gi gabi t Et her net 1/ 0/ 1swi t chpor tI Pv6 t r af f i c- f i l t er ACCESS_PORT i n

The filter above will deny any router advertisements for a particular port on the switch (the filter alsoshows how to deny DHCP server packets). Since you can filter router advertisement on a workstation andyou don’t want to deny router advertisements from an actual router, this is the only way to prevent arogue 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 riskof 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 hostsattempting 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 anunwanted 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 tunnelingendpoints





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 isadded 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 aboutsupporting an immature IPv6 service on a stable IPv4 server. IPv4 has been around for many years. IPv4applications 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 isnot an industry-wide support for it at the time being. If the customer base is not pushing on Vendors forIPv6, 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 communitygets 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 areidentified and resolved. For this reason, some enterprises may elect to deploy a separate physical serverfor 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, itillustrates 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 IPv4address 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 destinationaddress 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 ofthe 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.

http://www.abccompany.com/







8 Domain Name System DNS)

Before moving forward with this section, please make sure the corporate Internet gateways/servers areaccessible 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 networkenvironment depicted in Figure 8.1, an IPv4 user enters an easily recognizable or memorable domainname 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 bothaddresses. 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 correspondingto 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 recordassociated with a domain name. Quad-A or AAAA is associated with the IPv6 address. As long as theDNS server has the Quad-A record for the requested domain name, it will provide the IPv6 address backto the end-user in its response. Notice in the figure below, the DNS server is IPv4-only and does not havean 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 recordfrom the DNS server. If the DNS server was also dual-stacked, then the client will likely issue DNSrequests using its IPv6 address instead of IPv4. This is the default behavior of most operating system. Ifthe 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” tableof 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 cachedon the initial DNS server an end-user is pointing to. If the entry does not exist, the DNS server will queryits 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 DNSservers for the requested domain. This information is imported into the root server from the domain nameregistrars. 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 DNSservers. 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 knowwho 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. TheDNS 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. IPv4address). In the near term, enterprises can choose to migrate their internet gateways or servers to IPv6while keeping their DNS servers IPv4-only with very little drawback. It is an acceptable migrationapproach 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 supportIPv6-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 thisuncertainty, enterprises can decide to dual-stack their DNS servers and make their domains accessible byIPv4 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 dual-

stack end-user is not able to access contents via IPv6 address, but the destination is accessible via IPv4address. A dual-stack user will typically request and receive both a Standard-A and a Quad-A recordfrom 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 bydefault 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 thecontent 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 willcreate 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, buta 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 routeslearned from its peers to another peering partner. For instance, ISP(A) will not advertise routes learnedfrom ISP(B) to ISP(C). Therefore ISP(C) will not have an IPv6 route to www.abccompany.com that ishosted 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 timeuntil 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 tohost their IPv6 web servers. For instance instead of www.abccompany.com, the enterprise would useIPv6.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 otherchallenges. 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 theIPv4 homepage to redirect these users to the IPv6 site. Unfortunately, this approach does not help thoseIPv6-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 isquite 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 fasterdiscovery 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-v6ops-happy-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. Inthe 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. ThisInternet 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 wayto 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 tothe Corporate Internet and key servers/gateways. It can also be used to conduct preliminary security testsof the firewall. There are some security tools for IPv6 that can be used to verify that the implementedrule-sets are working properly. For DNS, the tester can use “nslookup” to perform DNS query against itsDNS 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’soperating system to issue a Quad-A request for the domain name. Now, the tester is ready to test theapplication by typing the URL for the server into the application. If the application is able to retrieve theinformation, 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 recommendedthat 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 IPv6adoption 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 thatenterprises 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 thesystem. 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 ExampleThe 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 corporaterequirements 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-FirewallLAN, 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, a64-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 froma 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 theenterprise 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 theenterprise 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 besupported for many years to come, it's wise for organizations to begin thinking about IPv6 and planningfor 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 wheneach RIR will exhaust, when all RIRs will exhaust and then when ISPs and enterprises will exhaust theiraddresses.

Here are the links of interest.

• IANA http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.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 IPv6to 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 theyqualify 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

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml


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

http://www.potaroo.net/tools/ipv4/index.html

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

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


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

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

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

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

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

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

http://iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml


http://en.wikipedia.org/wiki/WHOIS



http://tools.ietf.org/html/rfc1491



http://wiki.web.att.com/pages/viewpage.action?pageId=86934143




http://wiki.web.att.com/pages/viewpage.action?pageId=86934143









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.

H ow is v6 DNS ha ndled for Web sites that ar e both v6 an d v4 capable using the same domain nam e?

E.g., wha t if www.gs.com were both v6 v4 capa ble? How would you send v6 customer s 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 actualrequest 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.

Documents

ATT IPV6 Migration Guide R1 February 2012