at&t position on ipv6 · pdf file · 2012-02-02at&t position on ipv6...

AT&T Position on IPv6

Executive Summary

The focus of this white paper is on the rationale and strategies for AT&T and enterprise customers to plan for and initiate transition towards IPv6 deployments. IP version 6 is the newest version of the Internet Protocol, offering a number of improvements over the existing IP version 4. Most importantly, IPv6 will provide enough addresses to allow for every region, country and company to have an abundance of IP addresses to

meet their needs, while the IPv4 address space is projected to reach exhaust around 2011/2012 timeframe at the current rate of consumption.

AT&T Position on IPv6_________________________________________________________________________________________________________________________ �

Introduction IP version 6 is the newest version of the Internet Protocol, offering a number of improvements over the existing IP version 4. Most importantly, IPv6 will provide enough addresses to allow for every region, country and company to have an abundance of IP addresses to meet their needs, while the IPv4 address space is projected to reach exhaust around 2011/2012 timeframe [4] at the current rate of consumption.

IPv6 is expected to coexist with IPv4, for a considerable period of time. The exhaustion of IPv4 address space is a constraint for new network and application deployments, and may impact existing IPv4 installations that need more IPv4 addresses or need access to IPv6 resources. With improved and expanded addressing capacity and inherent security and mobility features, IPv6 is a significant improvement over the current protocol. It facilitates new developments focused on end-to-end communication models. AT&T recognizes the potential of IPV6, is committed to a thorough testing of its capabilities, and has embarked upon a phased implementation plan to deploy IPv6 throughout its global network infrastructure over the next several years.

The focus of this white paper is on the rationale and strategies for AT&T and enterprise customers to plan for and initiate transition towards IPv6 deployments. Technical information on IPv6 is widely publicized. For example, the IPv6 Forum [14] provides a broad range of resources on this topic. References [3] and [6] also provide technical highlights on IPv6. Therefore an in-depth technical discussion of the IPv6 addressing and architecture protocol suite is not the focus of this paper. Instead this paper will address the reasons to move to IPv6, IPv6 implementation options, the industry readiness for IPv6 adoption, AT&T’s approach to IPv6 deployment and enterprise transition strategies for IPv6. The appendix provides a brief historical review of IPv6.

Reasons to Move to IPv6 To date, EU countries, Japan, Korea, China and India have cited increasing difficulties in obtaining sufficient IPv4 address allocations. For historical reasons, the current distribution of IPv4 address allocation is vastly uneven in favor of the U.S. These countries view IPv6 deployment as providing a fresh start and a means to distribute IP addresses more equitably. In fact, IPv6 has been adopted as an industry strategy backed by government policies in some of these countries, thus spurring focused research and development for IPv6 technology and applications. These efforts have, over the past 18 months, made significant in-roads in validating IPv6 applications in multimedia and peer-to-peer (P2P) areas involving new categories of IP-aware devices.

From a U.S. mobile operator perspective, so long as operators continued to assign private IP addresses to terminals and public addresses to network elements, IPv4 shortage was thought not to be a significant concern for some years to come. However, recent advances in mobile technology and emerging user application trends have highlighted the value of IPv6 for mobile operators and the opportunity costs of not adopting IPv6 [8,9]. The rise of SIP-based real-time IP multimedia communications and emerging P2P applications with always-on and always-reachable mobile terminal devices have infused new thinking about how best to leverage and ensure the continued growth in data enabled mobile devices.

Visibility of IPv6 in U.S. public policies has also been elevated recently. In response to the U.S. government’s concern on cyberspace security, the North American IPv6 Task Force (NAV6TF) had promoted end-to-end IPSec based on IPv6 as a means to attainable security solutions. It has since expanded its recommendations [7] calling for IPv6 deployment in the U.S. Government for national business, economic, social and political reasons, starting with the U.S. Department of Defense (DoD).

IPv6 provides advantages that enable innovative applications, which can leverage the demand for global public IP addresses by potentially billions of mobile devices. In the following sections we consider these reasons to transition to IPv6:

• IPv4 address exhaustion

• Government mandates

• IPv6 functional improvements

• Leveraging IPv6 for new applications

IPv4 Address Space ExhaustIPv4 has a 32-bit address space providing a theoretical limit of a little over 4 billion unique addresses. However, past practices of Class (A, B, C) based addressing inadvertently led to address space fragmentation and hugely inefficient allocation and assignment of IP addresses. Over the past decade, IP address demands driven by exponential growth of both wireline Internet, and data-enabled mobile terminals have raised concerns that an IP address shortage could be imminent.

Enterprises may obtain IP addresses from their Internet Service Providers, or in some cases, from Regional Internet Registries (RIRs). RIR procedures limit the inventory of addresses that their customers may maintain, so service providers are likely to exhaust their IPv4 address inventories shortly after the RIR inventory exhausts. Table 1 provides some perspective on the timeframe for exhaustion of IPv4 address inventories at the RIRs. Current information on IPv4 address consumption can be found online [4]. How and when the constraints of the IPv4 address space impact the enterprise will depend on the particular circumstances of a given enterprise. For example, enterprises with relatively static networks may be unaffected for some time, while those with rapidly growing demand for large allocations of public address space should plan for an IPv6 transition sooner.

Table 1: Address Allocation

Internet Assigned Numbers Authority (IANA)

Worldwide oversight of IPv4 allocation to Regional Internet Registries (RIRs)

4.3 Billion IPv4 Addresses

> 82% already allocated to RIRs

Approximately 4% held in emergency reserve

< 14% available for allocation

Expect exhaustion of IPv4 reserves by June 2011

Regional Internet Registries (RIRs)

Five Registries worldwide – ARIN (North America), RIPE (Europe), APNIC (Asia/Pacific), LACNIC (Latin America), AFRINIC (Africa)

Regional oversight of IPv4 allocations to service providers, government and large businesses

Enforce policy regarding IPv4 address utilization and reporting

Expect exhaustion of IPv4 reserves by October 2012


Government MandatesAs noted earlier, countries in the Asia-Pacific region in particular feel as though they have been allocated an inadequate amount of IPv4 address space and are clamoring for a solution. For this reason, the Japanese government mandated the incorporation of IPv6 and set 2005 as the deadline for upgrading existing public and business telephone and data networks. On June 13, 2003, the U.S. Department of Defense issued a press release [5] mandating any new vendor providing IP services or hardware, for any project starting after October 2003, to support IPv6. In May 2005, the U.S. Government Accountability Office issued a report [12] to congress identifying the need to plan for the transition to IPv6. This triggered additional governmental considerations. On August 2nd, 2005, the Office of Management and Budget issued a memorandum [13] calling for all U.S. Federal Government agencies to plan for IPv6 transition with all agencies to be supporting IPv6 on their backbone networks by June 30th 2008.

The National Telecommunications and Information Administration (NTIA) report [11] noted a number of governmental activities in international markets aimed at accelerating deployment of IPv6. Japan, South Korea, China and the European Commission were identified as having multimillion dollar projects in place regarding IPv6 deployment.

IPv6 Functional Improvements IPv6 also provides major improvements over IPv4 that can benefit IP mobile and fixed network providers and network users whether enterprise or consumer. These key features of IPv6 are highlighted below:

Improved_Network_Management_IPv6 supports Stateless Address Auto-Configuration, which can significantly simplify operator efforts in configuration and management of fixed and mobile terminals (‘Plug-and-Play’). Site Auto-Renumbering of routers and terminal devices based on time-scoped public IPv6 addresses facilitates network consolidation.

Integrated_SecurityNative IPSec support in IPv6 enables robust end-to-end security for applications. IPSec provides embedded encryption and authentication mechanisms (Encapsulated Security Payload and Authentication Header) for both TCP and UDP, which is more secure than SSL.

Integrated_Mobile_IPIn addition to Layer 2 mobility management by the wireless network, Mobile IP can provide seamless uninterrupted IP sessions via Fast Handovers and Binding Updates between the home address and care-of address as the mobile terminal roams into a foreign network. Mobile IPv6 eliminates the need for the Foreign Agent with auto-configuration and neighbor discovery by the mobile host in the foreign network. Direct routing of the forwarded traffic to the mobile host, (i.e. avoidance of triangular or ‘trombone’ routing) is also supported. Mobile IP is required for seamless handovers when users move between access technologies, e.g. 3GPP to WLAN. There are a number of features to mobility, but some form of mobility is inherent in the Next Generation Network concept of accessing any application from anywhere.

Improved_RoutingRoute aggregation capability similar to the classless inter-domain routing (CIDR) in IPv4 is incorporated in IPv6 routing. The Unicast and Multicast routing of IPv4 have been extended with Anycast routing capabilities.

Ad-Hoc_NetworkingIPv6 will support the end-to-end (E2E) routing and addressing requirements of emerging Ad-Hoc networks, whereby mobile wireless devices can establish communications anytime and anywhere without the aid of a central infrastructure (i.e. base station or access point). Mobile devices can act as both a router and host either in mobile ad hoc networks (MANET) or personal area networks (PAN) that can interwork with the cellular network or the Internet. Such applications, made possible by short-range radio technologies (e.g. Bluetooth and 802.11) could extend the reach of conventional cellular networks both in the home networking and in remote out-of-reach scenarios (e.g. sensors located in remote areas for environmental monitoring, where information can be relayed by roaming mobile nodes acting as multi-hop routers).

Leveraging IPv6 for New ApplicationsThe main feature of IPv6 is the virtually limitless address space with 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses available with IPv6 compared to approximately 4 billion with IPv4. This can provide persistent public IP addresses to a virtually unlimited number of always-on devices ranging from currently well-known device categories such as PCs and mobile phones to emerging device types such as sensor networks and intelligent infrastructures. The integrated support of IPSec deploys capabilities that can be leveraged for improved security.

This large address space enables a variety of new network capabilities and services:

• Push applications (e.g., push emails/messaging and alerting services)

• Peer-to-Peer based applications

• Seamless support of IP mobility

IPv6 Transition ConsiderationsWhile transition to IPv6 may at first seem a rather daunting prospect, it can be approached in a manageable way. In most cases, service providers and enterprises are talking about a gradual transition with both IPv4 and IPv6 being supported simultaneously. Turning up IPv6 network services, in this context, requires considerable planning to identify the appropriate steps for in-service operational changes to support IPv6, but this is feasible. There are a number of implementation options as to how IPv6 may be used to best advantage that should be considered depending on the predominant use cases expected by the service provider or enterprise. As with any network change, the security implications should also be considered and appropriate risk management strategies put in place. Beyond the direct upgrades of hosts and routers to support IPv6, there are a number of ancillary services that may also require consideration of potential impacts from transitioning services and applications to an IPv6 infrastructure.

Preparing for the Transition to IPv6Transitioning large networks to a native IPv6 network may reasonably be expected to take years. The first step, to begin transitioning to IPv6, is developing the detailed transition plans to support the in-service upgrade of the currently operational network infrastructure to support IPv6. Transition plans may vary widely from network to network; however, the transition plans should include the following sequence of activities – Assessment, Planning and Deployment. Depending on the scale and complexity of the existing network infrastructure, a number of different detailed plans may be required – e.g. for equipment inventory and upgrade capabilities and schedules, for trials and testing vs. operational deployment, for infrastructure vs. application rollout and for staff training and support.

IPv4-to-IPv6 Transition MechanismsThe transition to IPv6 is expected to be gradual and occur over several years. With this in mind, the Internet Engineering Task Force (IETF) has defined a wide range of transition mechanisms to allow smooth co-existence between IPv6 networks and legacy IPv4 networks.

Such mechanisms fall into three broad categories:

• Dual-stack (enables IPv4 and IPv6 to coexist in the same devices/networks)

• Tunneling (includes configured and automatic tunnels)

• Protocol Translation (enables an IPv6-only device to communicate with an IPv4-only device)

Dual-StackDual-stack refers to an IP capable device (e.g. a host computer, router) supporting simultaneously both IPv4 and IPv6 [12]. This enables applications to communicate across either an IPv4 or IPv6 network. Typically, the preferred network is based on name lookup and application preference. Many of the routers available today support this dual-stack capability. Network routers in conjunction with dual-stack application servers enable enterprises to manage the gradual transition to IPv6.

Requiring all new IP capable devices to support dual-stack is desirable in providing a flexible operational environment for transitioning to IPv6. Financial considerations in equipment refresh cycles will obviously impact the rate at which IPv6 capable devices can be deployed. Dual-stacked hosts connected to a dual-stack network enable applications to gradually migrate from IPv4 to IPv6 in a controlled manner. Hence, legacy IPv4 applications and devices can coexist with newly transitioned IPv6 applications on the same dual-stack network.

TunnelingTunneling refers to a technique that encapsulates one version of IP in another so the packets can be sent across a network that does not support the encapsulated IP version. This technique allows two IPv6 islands to communicate with each other across an IPv4 network. Tunneling enables different parts of the network to transition to IPv6 at different times.

There are two main categories of tunneling: configured and automatic tunnels. Configured tunnels refer to a manually configured tunnel between the endpoint routers at each end of the tunnel. The end points are statically configured; hence, any changes to network numbering would require the enterprise to modify the tunnel endpoints. In contrast, automatic tunnels refer to a device dynamically creating its own tunnel to dual-stacked routers. Tunnels can be configured to send IPv6 through an IPv4 network, or to send IPv4 through and IPv6 network. Standards such as IPv6 Tunnel Broker (RFC 3053), 6 to 4 (RFC 3056), Teredo (Tunneling IPv6 over UDP through NATs) and ISATAP (Intra-site Automatic Tunnel Addressing Protocol) send IPv6 packets encapsulated in IPv4 and can be referenced as IPv6-over-IPv4 mechanisms, while DSTM (dual-stack Transition Mechanism) sends IPv4 packets within IPv6 and can be referenced as IPv4-over IPv6 mechanism [12].

Security risks associated with automatic tunneling should be considered prior to introducing automatic tunneling. Automatic tunneling may allow user-nodes to establish tunnels that bypass an enterprise’s security mechanisms (e.g. firewalls, intrusion detection…) reducing the depth of security as well as allowing unsolicited traffic. Even though automatic tunneling provides an extremely flexible transition mechanism to move to IPv6, the risks associated with each transition mechanism should be analyzed [12].

Translation Translation refers to a method of translating one version of IP to another. This method does not depend on dual-stack for transition to IPv6, but rather enables devices on different versions of IP to communicate with each other through an intermediate device which performs protocol translation. This technique does not achieve end-to-end transparency in network communications and should only be used as a last resort. Because of this lack of transparency certain applications [12] may not function correctly.

Security Considerations

Transitioning_From_an_IPv4-only_Security_Policy__to_a_Dual-Stack_(IPv4/IPv6)_Security_PolicyThe transition to IPv6 requires special attention to security considerations. Enterprise security policies typically address exposures and security mitigation techniques in the IPv4 environment. Firewalls and intrusion

AT&T Position on IPv6_________________________________________________________________________________________________________________________ 4

Application

Data Link (Ethernet)

TCP UDP

IPv4 IPv6

Figure 1: Dual-Stack Reference Architecture

detection systems are generally configured to protect an enterprise’s network, host computer and data assets in an IPv4 environment. However, with the introduction of dual-stack and IPv6, enterprises will need to address additional security issues during and after the transition. As mentioned earlier, automatic tunneling can bypass IPv4 safeguards. Therefore, transitional dual-stack security policies should be developed to address the many networking aspects [1] that IPv6 introduces:

• Anycast addresses

• Scoped addresses

• New extension headers

• Tunneling protocols

• Transport headers

• Privacy addresses

• ICMP options

NAT_(Security_Friend_or_Foe?)As mentioned earlier, IPv6 supports native IPSec, enabling robust end-to-end security for mobile wireless services and enterprise applications. Further, IPv6 provides enough addresses to make NAT (Network Address Translation) obsolete. However, due to the co-existence of IPv4 and IPv6 during the transition period, NAT will likely continue to be used in enterprise IPv4 environments. Many enterprises have deployed RFC 1918 private IP addresses and NAT to mitigate IPv4 address shortages. Unfortunately, IPSec and NAT tend not to interoperate seamlessly and may cause problems [1] in a dual-stack network. Even though NAT was introduced to mitigate public IPv4 shortages through translation, NAT has evolved into a security mechanism to allow the enterprise to use RFC 1918 address space internally while being able to communicate externally. When used in combination with private IP addresses, NAT is believed to hide the details of the internal enterprise network from the public Internet.

NAT is not transparent, and it can obstruct the ability to perform bi-directional communication, global addressing, always-on systems, peer-to-peer networks, and push services – which are inherent [1] to the design of IPv6. IPv6 transition planning must take into account interactions with NAT functions used in enterprise IPv4 networks.

In summary, the transition to IPv6 will be evolutionary rather than revolutionary. During this transition, both protocols will coexist and attention to security considerations is absolutely critical. Existing enterprise IPv4 security policies will not be sufficient during the transition to IPv6. The enterprise must analyze the risks associated with each transition mechanism and develop a dual-stack security policy which covers native IPv4 and IPv6, as well as the transition and coexistence techniques (e.g. tunneling, dual-stack, etc.).

Other_Implications_of_Transition_to_IPv6_Transitioning a network and applications to IPv6 involves consideration of networking aspects beyond the differences in the length of the address field. There are a number of protocols involved in the network that may use or embed IP address information for their normal

operation. For example, network attachment and navigation functions such as DHCP and DNS need to be populated with appropriate IPv6 entries and application protocols such as SIP may also require some awareness of IPv6.

Assessment_of_Readiness_of_the_Industry__The NTIA report [11] indicated that the large vendors of networking equipment (e.g. Cisco, Juniper) have implemented IPv6 capabilities in their equipment for some time. Major operating systems for PCs (e.g. Linux, Microsoft Widows and MAC OS-X) also provide support for IPv6. While these device capabilities may be available, in many cases they are not configured for default usage.

Alliance for Telecommunications Industry Solutions (ATIS) has also studied the current readiness and transition challenges associated with IPv6 and issued a report [1] on the subject. The ATIS/TOPS/IPv6 Task Force has also assessed progress on these challenges in [2].

The 2005 Government Accountability Office (GAO) report [12] surveyed 23 agencies to measure readiness against to the following criteria:

• Transition plan established

• Inventory

• Cost estimated

• Business plan developed

At that time, very few agencies had commenced planning for the transition which led to further action by the Office of Management and Budget (OMB) to set deadlines. The OMB memo [13] provided more specific direction on the information expected from an application and device inventory, a transition plan and impact analysis. These approaches to transition planning may be useful for many other organizations to consider in assessing the impacts of their own transitions to IPv6.

IPv6 Interoperability testing arrangements have been in place with University of New Hampshire Inter-Operability Laboratory and the NAv6TF through the Moonv6 [15] test bed. AT&T has participated in Moonv6 as well as in the 6Bone [16] research network. Such test beds provide a useful forum for assessing the operational readiness of protocols implementations and network elements.

At the end of the day, this kind of testing provides only an indication of future performance. Operational commercial services provide the real measure of industry readiness. AT&T plans to offer an initial set of commercial IPv6 services starting in 2009.

AT&T’s Support for IPv6In considering the strategy for migrating to IPv6, AT&T follows these guiding principles:

• Not only is IPv6 inevitable, it offers many advantages in the long-term

• IPv4 exhaust is within the planning horizon for most large projects

• Introduction of IPv6 has begun and will be incremental; initial emphasis will be placed on customer driven demands – especially large enterprises and the government


• Full migration to IPv6 will be a multi-year program

• New services should be targeted to include IPv6 support from Day 1 to avoid transition costs later; IPv6 will be included as part of the normal hardware/software refresh cycles whenever possible

AT&T’s experience with IPv6 began with technology trials using the 6Bone and Moonv6 networks. AT&T has now started commercial deployment of IPv6 services and continues to plan for the rollout of additional IPv6 service enhancements.

AT&T recognizes that enterprise customers will need continued support for their existing IPv4 infrastructure and for planned transitions to IPv6. This will necessitate a Dual Stack approach by the IP Service Provider, with some native IPv6 interfaces to be supported in both the Managed Internet Services (MIS) and Virtual Private Network (VPN) services alongside the current IPv4 offerings. Currently available and proven techniques will enable AT&T to support both IPv4 and IPv6 customers over a common “IPv6-aware” MPLS backbone. AT&T plans to offer Dual Stack IPv4/IPv6 Internet Access service (Managed Internet Service or MIS) as well as Dual Stack IPv4/IPv6 Virtual Private Network Service (AT&T Virtual Private Service or AVPN) on its global IP MPLS network in 2009. These two basic IPv6 connectivity services will provide enterprise customers the needed connectivity for other IPv6 based services.

The remainder of this section briefly describes AT&T’s experience with IPv6 technology, followed by descriptions of our initial commercial offerings for enterprise customers. [Note that AT&T plans to extend IPv6 capabilities to other parts of its network (broadband access, mobile networks, etc.) and to offer other IPv6 based services (e.g. Security, Hosting, VoIP, etc.). These will be covered in future updates].

AT&T’s Experience With IPv6 Technology TrialsAT&T has participated in various IPv6 test and research environments to gain operational experience with the protocol. For example, AT&T had connected to 6bone research network in the past. 6bone was

a virtual network which used IPv6-in-IPv4 tunneling technologies and was used as a global test bed for IPv6 to validate the essential protocols during their development by the IETF. 6bone is built as an overlay on the IPv4 Internet, where the links between routers are tunnels rather than physical circuits as shown in Figure 2. This tunnel-based access to 6bone enabled AT&T customers to participate in the worldwide interconnectivity of IPv6 experimental network implementations. In addition, AT&T gained operational experience in a tunnel environment.

AT&T also participated in the Moonv6 network, a global IPv6 interoperability test environment led by the North American IPv6 Task Force (NAv6TF). Moonv6 is a multi-site, multi-vendor, IPv6 based network designed to test the interoperability of various vendor-specific IPv6 network and application implementations. AT&T participated in the Moonv6 network by implementing an MPLS-based IPv6 wide-area backbone to provide connectivity for several IPv6 sites, including various DoD sites and the University of New Hampshire’s Inter-Operability Laboratory (UNH IOL) as shown in Figure 3. Essentially, AT&T implemented IPv6 at the edge of the AT&T network and carried data across AT&T’s MPLS core. AT&T gained valuable operational experience in an IPv6-over-an-MPLS-core implementation in a diverse application and traffic environment.

AT&T’s Approach for Supporting Enterprise CustomersOne of the values of operating an IP MPLS network such as AT&T’s is the ability to add new services such as IPv6 without requiring a complete overhaul of the network. To enable the IP MPLS network with IPv6 capabilities, AT&T plans to leverage Dual Stack, 6PE (IPv6 on Provider Edge) and 6VPE (IPv6 VPN on Provider Edge) technologies on the service provider edge routers. Dual Stack allows AT&T to support both IPv4 and IPv6 on the same edge router, and it allows customers to use IPv4 and IPv6 over the same access line. 6PE (IPv6 on Provider Edge) provides the capability to transport IPv6 across the MPLS core, which is very similar to how IPv4 is carried across the AT&T MPLS core today. 6PE edge routers exchange IPv6 route updates and labels using multi-protocol extensions to BGP4 (MP-BGP). 6VPE (IPv6 VPN on Provider Edge) provides the capability to transport network-based IPv6 VPN over an MPLS core. It is similar to a regular IPv4 MPLS-VPN provider edge, with the addition of support for the IPv6 address family within Virtual Routing and Forwarding (VRF). Since IPv4 will co-exist

AT&T Position on IPv6_________________________________________________________________________________________________________________________ 6

Internet

AT&T’s 6Bone Gateway Capability

6Bone Gateway Routers

6Bone Networks

Customer Router

Customer Router

Managed Router

CommonBackboneAT&T’s MIS

Figure �: AT&T Connectivity to 6Bone Network

AT&T MPLSNetwork

UNH IOLLocation

v6 Service Boundary

6PE6PE

6PE6PE6PE

v6 CE

v6 CE

v6 CE

v6 CE

v6 CE

v6 CE

6PE

DoDLocations

Figure �: AT&T Connectivity to Moonv6

with IPv6 for many years, Dual Stack, 6PE and 6VPE technologies enable AT&T to sustainably support both IPv4 and IPv6 customers over a common IP MPLS infrastructure.

The following sections describe how AT&T’s Dual Stack IPv4/IPv6-based MIS and AVPN offerings work in more detail.

Dual Stack IPv4/IPv6 Managed Internet ServiceFigure 4 below shows how Dual Stack and 6PE (native IPv6 Provider Edge) are used to support AT&T’s Dual Stack IPv4/IPv6 Internet Access Service. The diagram below shows the scenario where an Internet Access customer (Customer Edge 1 or CE1) communicates with another Internet Access customer (CE3) over the AT&T IPv6 enabled network. To send IPv6 packets from CE1 to CE3, CE1 transmits IPv6 packets to the 6PE1 (IPv6 Provider Edge 1). The 6PE1 encapsulates the IPv6 packets in MPLS packets and sends the packets toward the MPLS Core. The MPLS Core switches the packets and sends the packets to the 6PE2. 6PE2 then removes the MPLS packet header and sends the IPv6 packets to CE3. In other words, the IPv6 packets are tunneled (via MPLS) across the MPLS core and the tunneling is transparent to the customer. To support IPv6 Internet Access, the Domain Name Service (DNS) support will be extended to include IPv6. In addition, the peering router which connects AT&T to the broader external IP community via peering arrangements will also be Dual Stack and 6PE enabled to be ready to connect to the IPv6 Internet. Routing information among the 6PEs is communicated via the IPv6 MIS Route Reflector (RR).

Dual Stack IPv4/IPv6 AVPN ServiceFigure 5 below shows how Dual Stack and 6VPE technologies are used to support the AT&T Dual Stack IPv4/IPv6 AVPN Service. The diagram below shows the scenario where a customer at VPN B site 1 (CE1) communicates with VPN B site 2 (CE3). To send IPv6 packets from CE1 to CE3, CE1 transmits IPv6 packets to the 6VPE1. The 6VPE1 encapsulates the IPv6 packets in MPLS packets and sends the packets toward the MPLS Core. The MPLS Core switches the packets and sends the packets to the 6VPE2. 6VPE2 then removes the MPLS packet header and sends the IPv6 packets to the CE3. Again, the IPv6 packets are tunneled across the MPLS core and the tunneling is transparent

to the customer. The IPv6 VPN Route Reflector (RR) facilitates the communication of the customer’s Virtual Routing Forwarding (VRF) information among the 6VPEs.

Enterprise IPv6 Transition StrategiesThe previous section described how AT&T will be ready to support enterprise customers when they are ready for IPv6. This section briefly addresses steps which enterprise customers can take to add IPv6 connectivity to their network and begin using IPv6 applications and services. AT&T recognizes that each enterprise will have its own unique environment and will need to develop its own customized plan. Therefore this section only provides some basic information on issues and use cases to be considered in planning for the addition of IPv6 capabilities to the enterprise network.

Enterprises interested in using AT&T’s IPv6-based connectivity services should first establish IPv6 links between the PE (Provider Edge) and the CE (Customer Edge) routers. Once a site enables IPv6 on the PE to CE links, it will have connectivity to other IPv6 sites and the IPv6 Internet over AT&T’s network (see Figure 6 (a)). If enterprise sites establish connections to AT&T’s IPv6 enabled network as an IPv6 VPN user, they will be able to access their other IPv6 VPN sites over the AT&T network (see Figure 6(b)).

Since most enterprises will be adding IPv6 to their pre-existing IPv4 networks, they would most likely use Dual Stack technology to establish the IPv6 link between PE and CE routers. This will allow customers to continue to support their IPv4 networks while adding or migrating applications and systems to IPv6 based on the needs of the enterprise.

Once an enterprise site establishes IPv6 connectivity to AT&T’s IPv6 enabled network, there are several options to implement IPv6 within the site. An enterprise can establish an IPv6 environment to connect to the IPv6 enabled CE router facing the AT&T’s network to gain some experience. Or, an enterprise may choose to use alternative transition mechanisms (e.g. tunneling) which were discussed in Section 3.


ISP-B

ISP-A

Peering Router 6PE6PE1 6PE2

6PE3

PE1

IPv4 only

IPv6 MIS RR

DualStackIPv4/IPv6

DualStackIPv4/IPv6

CE1

CE2CE3

CE4

CE5

IPv6 DNSServer

Figure 4: Dual Stack IPv4/IPv6 Managed Internet Access

VPN B1

VPN B2VPN A1

VPN A2

VPN A3VPN B3

6VPE1 6VPE2

PE2PE1

IPv4 only

IPv4 VPN RR IPv6

VPN RR

DualStackIPv4/IPv6

MP-iBGPIPv6

MP-iBGPIPv6

MP-iBGPIPv4

CE1

CE2CE3

CE4

CE5CE6

Figure �: Dual Stack IPv4/IPv6 AVPN

In addition to establishing IPv6 connectivity, an enterprise will also need to upgrade the surrounding infrastructure (e.g. DNS, DHCP and AAA) as necessary to support the IPv6 applications and services on their IT infrastructure.

ConclusionsAT&T recognizes the potential of IPV6, is committed to a thorough testing of its capabilities, and has embarked upon a phased implementation plan to deploy IPv6 throughout its global network infrastructure. The exhaustion of IPv4 address space is inevitable, driven by increasing demands for public IP addresses for always-on mobile terminals, as well as other Internet devices and applications. Government initiatives on IPv6 are advancing on a number of fronts. New IPv6 applications are beginning to emerge to leverage the functional improvements available with IPv6, and these applications will grow as the IPv6 network infrastructure becomes more widely available.

AT&T has been involved for some time with testing and trials of IPv6 technology. Based on this experience, AT&T has established an architecture for IPv6, and is deploying equipment to support IPv6 technology today. AT&T plans to launch commercial IPv6-based service offerings in 2009 with Dual Stack IPv4/IPv6 AVPN introduced in 2/09 and Dual Stack IPv4/IPv6 MIS by YE 09. AT&T is committed to support our enterprise customers when they decide the addition of IPv6 capabilities is appropriate for them.

Appendix

IPv6_HistoryThe Internet Engineering Task Force (IETF) is a large, volunteer international community of network designers, operators, vendors and researchers concerned with the evolution of the Internet architecture and its smooth operation. This organization is responsible for the primary technologies that make the Internet possible. Internet drafts, called Request For Comments, or RFCs, are the working documents of the IETF. As an indicator of the interest level in IP version 6, a search of published RFCs at http://www.rfc-editor.org reveals that there are 106

draft standards papers written for IP version 6 and various sub-topics related to the protocol. This is a notable amount of activity around a topic when one considers that BGP (Border Gateway Protocol), the routing protocol used by every single router on the internet today, yields only 47 results using the same search.

The IETF standards track is a progression of a standards document’s progression through much iteration of development and peer review. The process begins with “Proposed Standard” and moves to “Draft Standard”, before finally becoming an “Internet Standard”. An Internet Standard is considered the final authority for development. Often vendors will implement protocols in hardware and software long before they have reached the final phase. In fact, vendors have frequently implemented protocols with no accompanying standard. It is generally considered better to follow standards to facilitate interoperability between vendors.

IPv6_Standards_DevelopmentThe original standard for IP version 4 was initially published in September 1981, as RFC 791 by Jon Postel. In December 1995, RFC 1883 proposed a new standard for the Internet Protocol called IP version 6. (IP Version 5 was a real-time streaming protocol, which never materialized). RFC 2460 (1998) is the latest version to define the IPv6 standard.

IPv6_SpecificationsAn IP packet is comprised of a header and a payload. The header is like an envelope that is addressed to a destination. The header also has many other functions such as signifying the priority level of the packet, the sending source, and the application type. Each machine it passes through must universally understand all of the portions of the packet header. At every machine the header is inspected to make forwarding decisions about the packet and to apply priority policy or security policy. RFC 2460 defines the IPv6 packet header format, extension headers and options. The RFC also covers flow labels, packet sizes, traffic classes and the effect of IPv6 on upper layer protocols. The header format is illustrated in Figure 7: IPv6 Packet Header.


(b) – Dual Stack IPv4/IPv6 AVPN Data Flow

Site to SiteCommunication

Site to SiteCommunication

(a) – Dual Stack IPv4/IPv6 Internet Access Data Flows

Internet Access VPN B1

VPN B2VPN A1

VPN A2

VPN A3VPN B3

6VPE1 6VPE2

PE2PE1

IPv4 only

IPv4 VPN RR IPv6

VPN RR

DualStackIPv4/IPv6

MP-iBGPIPv6

MP-iBGPIPv6

MP-iBGPIPv4

CE1

CE2CE3

CE4

CE5CE6

ISP-B

ISP-A

Peering Router 6PE6PE1 6PE2

6PE3

PE1

IPv4 only

IPv6 MIS RR

DualStackIPv4/IPv6

DualStackIPv4/IPv6

CE1

CE2CE3

CE4

CE5

IPv6 DNSServer

Figure 6: Dual Stack IPv4/IPv6 Data Flows


For more information contact an AT&T Representative or visit www.att.com/business.

IPv6_Packet_HeaderThis new and improved header format provides the pathway to greater functionality for this next generation protocol. In particular, it is the source and destination address length, the flow label and the traffic class fields that provide for the majority of new features.

References[1] “ATIS Internet Protocol version 6 (IPv6) Report & Recommendation”

Alliance for Telecommunications Industry Standards, May 2006.

[2] “ATIS Internet Protocol version 6 (IPv6) Task Force Report on IPv6 Transition Challenges”, Alliance for Telecommunications Industry Standards, July 2007.

[3] Huston, G. (2003). Waiting for IP version 6. Retrieved September 15, 2003 from the Internet http://www.potaroo.net/papers/isoc/2003-01/Waiting.html.

[4] “IPv4 Address Report” http://www.potaroo.net/tools/ipv4. Retrieved April 13th, 2009.

[5] Mark, R. (2003). Pentagon Commits to IPv6. Retrieved June 13, 2003 from http://www.internetnews.com/bus-news/article.php/2221821.

[6] Microsoft, “Introduction to IPv6” (White Paper). http://technet.microsoft.com/en-us/library/bb726944.aspx.

[7] NAV6TF Input Paper to Presidential Critical Infrastructure Protection Board (PCIPB), Dec. 2002. http://www.nav6tf.org/documents/NAV6TF_PCIPB_INPUT_PART_II.pdf.

[8] L-F. Pau, “A Business Evaluation of the Next Generation IPv6 Protocol in Fixed and Mobile Communication Services”, Research paper, Erasmus University, Rotterdam School of Business, http://econpapers.repec.org/paper/dgreureri/2002253.htm.

[9] L-F. Pau, “IPv6 Return on investment analysis framework at a generic level”. Research papers, Erasmus University, Rotterdam School of Business, http://econpapers.repec.org/paper/dgreureri/2002254.htm.

[10] RFC 3194. The Host-Density Ratio for Address Assignment Efficiency, Nov. 2001.

[11] U.S. Dept. Commerce, NIST, NTIA, “Technical and Economic Assessment of Internet Protocol Version 6 (IPv6)” January 2006. http://www.ntia.doc.gov/ntiahome/ntiageneral/ipv6/final/ipv6finalTOC.htm.

[12] U.S. General Accountability Office, “Internet Protocol Version 6: Federal Agencies need to Plan for transition and manage Security Risks”, May 2005. http://www.gao.gov/new.items/d05471.pdf.

[13] U.S. Office of Management and Budget, “Transition Planning for Internet Protocol Version 6 (IPv6)”, M-05-22, August 2nd, 2005. http://www.whitehouse.gov/omb/memoranda/fy2005/ m05-22.pdf.

[14] http://www.ipv6forum.com.

[15] http://www.moonv6.org/.

[16] http://www.6Bone.net/.

05/11/09___AB-1607©_2009_AT&T_Intellectual_Property.__All_rights_reserved._AT&T_and_the_AT&T_logo_are_trademarks_of_AT&T_Intellectual_Property.__The_information_in_this_document_is_provided_by_AT&T_for_informational_purposes_only.__AT&T_does_not_warrant_the_accuracy_or__completeness_of_the_information_or_commit_to_issue_updates_or_corrections_to_the_information.__AT&T_is_not_responsible_for_any__damages_resulting_from_use_of_or_reliance_on_the_information.

Destination Address

Source Address

Payload Length Next Header

HopLimit

Flow LabelVersion Traffic Class

Figure �: IPv6 Packet Header

at&t position on ipv6 · pdf file · 2012-02-02at&t position on ipv6...

Documents