A Second Chance to a Fair Share of IP – IPv6

~Deployment Considerations~

A brief review of the IPv6 protocol features revealed that the next version of IP represents an evolutionary rather than a revolutionary step. Despite some of the significant differences between IPv4 and IPv6 detailed in Part I [1] of this paper, the main feature justifying interest in an upgrade is the larger address space. In the context of short term planning this realization can dampen the business interest in deploying IPv6. On the other hand, a long term perspective on the service requirements and public needs regarding IP communications emphasizes the strategic importance of an IPv6 infrastructure.

The complex benefits of a larger address space can easily be overlooked at a first sight as they span multiple aspects of an IP service. The acquisition of large IPv4 addresses is becoming more and more expensive compared to IPv6. Dedicated, fixed addresses for each appliance and host provide the infrastructure for new types of services. Large deployments of multicast services are significantly easier in IPv6 due to the large number of multicast addresses available. At the same time IPv6 can offer the means to creatively solve some of the problems of today’s networks. A good example is the intent of Cable Operators to deploy IPv6 for management purposes at first. The IPv4 private addresses will not be able to cope with the expected large increase in the number of devices that need to be managed such as Cable Modems, Home Appliances, and VoIP phones. An IPv6 management network could resolve the problem while services continue to be provided over IPv4.

Going beyond the benefits of addressing, Service Providers (SP) are also taking advantage of the extraordinary opportunity offered by IPv6 to redesign their networks and services in a better way based on the experience gained in the IPv4 world. Nevertheless, before adopting the new protocol, network operators have to find a comforting answer to the question: Is IPv6 ready for deployment? Part I of this paper provided a positive answer to this question for most important features of IPv6. Part II intends to piece these features together into relevant deployment scenarios for several network types.

Part II -IPv6 is Ready for Deployment Today

The most relevant IPv6 features at both Control and Data Forwarding Plane level are currently ready for deployment. They provide the functionality needed to deploy scaleable, high performance and resilient services. It would be fair to say that some of the features we grew accustomed with in IPv4, features that we would like to implement out of habit might not be yet released even though they most likely are in an advanced stage of Early Field Trial. These missing pieces in the puzzle are not however show stoppers for a deployment.

The principles used in designing IPv4 networks are applicable in the case of IPv6 networks and services as well. The factors to consider are:

• Topological and protocol hierarchy.

• Redundancy at various level of the OSI stack

• Addressing aggregation becomes even more of a factor with the large IPv6 addresses.

• Scalability.

• Network security and management is an integral part of the design.

• Finite resources always make cost an important factor.

IPv6 deployment planning and design implies an additional factor: Coexistence. It is reasonable and realistic to expect that IPv6 services will be, at least for a good period of time an overlay on an existent IPv4 network. This expectation is rooted in the similarities between the two protocols but mostly in the ROI considerations or the Cost factor mentioned earlier. At the same time, the coexistence offers an opportunity to have the two protocols complement each other. As mentioned earlier, IPv6 can be used to manage an IPv4 infrastructure in the same way an existent IPv4 Network Management System (NMS) can be used to collect IPv6 NM information from dual stack routers. This coexistence however is not necessarily symbiotic as the two protocols will have to share the same resources. At first the newcomer will generally be perceived of lesser priority and generally constrained from impacting the performance of existing, revenue generating IPv4 services. That is expected to change in time so a migration strategy should also be built in the IPv6 deployment design.

Part I of this paper presented the multitude of tools that can be leveraged in deploying IPv6 services. Tunneling mechanisms were for a long time a cheap and easy way to provide IPv6 access for those trying to familiarize themselves with the protocol and for research groups. The performance and scalability characteristics of tunnels make them less desired in the case of production deployments.

The intent of this paper is to discuss Native IPv6 Deployments. While always an option, tunneling is considered a last resort mechanism used only in parts of the network that are not ready for a migration to native IPv6.

The deployment topic is rather vast and it would be impossible to provide all the relevant details in the limited space of a paper. The high-level perspective presented here is complemented with useful references that can help the interested reader reach more in-depth knowledge of this topic.

Common Denominators

There are a few elements that are generically common to all deployment scenarios. For instance they can all be viewed in terms of several distinct layers shown in Figure 1.

Figure 1 - Network Functional and Design Layers

Each layer fulfills certain functions that in turn drive certain design and protocol requirements. A system level perspective can be rather overwhelming in the case of a large network while a view focused on one or two of the layers shown in Figure 1 can be more practical. Moreover, various layers of a network can be operated by different entities and that entitles an independent analysis of the layers and their interaction.

Two deployment aspects are also addressed independent of the network type: Network Management and Network Security.

Network Management

The deployment of a production network and a reliable service cannot be conceived without a Network Management System (NMS). The NMS can vary in scope and coverage from simple “in house developed” to highly specialized and highly integrated tools that provide functions such as: Service Provisioning, Topology mapping and discovery, Fault alert and troubleshooting, Billing, Resource planning and engineering.

Today’s NMS tools are mapping most of their IPv4 functions to IPv6 so the latest versions of software will meet the needs of an IPv6 deployment. There are however three aspects to particularly consider when designing the NMS of an IPv6 network:

• The Management Information Base (MIB) objects are not yet converged in the standardization bodies. A long and inconsistent process of standardizing the MIBs led to vendors implementing some earlier versions that will soon be obsolete or some very specific ones but not standardized. The work of defining unified MIBs for both IPv4 and IPv6 is soon to be completed for the new MIB-2 but until then, differences might be encountered between various vendor implementations.

• The transport of NM information can be done over IPv6 or IPv4. SNMP for instance is one of the mechanisms used to collect and transmit NM information and it is currently implemented by most vendors for both protocols. If the IPv6 service is deployed in an IPv4 network, the existent NMS can be leveraged to collect IPv6 NM information from dual stack devices. This is a very cost effective solution as long as all IPv6 network elements are accessible via IPv4.

• Provisioning paradigms are changing with IPv6. Despite complaining about the lack of IPv4 addresses, we enjoyed the flexibility of dynamically assigning temporary addresses via virtual templates and pools. In IPv6 it is recommended that each user receives the same prefix every time it connects to the network. This recommendation eliminates some of the convenient provisioning mechanisms used in IPv4.

Despite these few challenges, the latest NMS are ready to support IPv6 deployments today.

Network Security

Security can mean different things for different networks. A Service Provider is interested in being able to track the source of an attack so it implements RFC2827 [2] based filtering or Unicast Reverse Path Forwarding (uRPF). An Enterprise Network operator might choose to focus more on controlling the traffic that enters or leaves its network. In the end however, it comes down to controlling access to and protecting the network infrastructure and its users.

IPv6 promises the onset of a new order in terms of communications security, End-to-end security. Despite its mandated use of IPsec between hosts, the road to making this model a reality is expected to be long and challenged by the lack of support in host stacks and the lack of a universally adopted key exchange mechanism. In the interim, it is recommended to implement the security design principles and policies proven in IPv4 deployments, the principles of Perimeter Security.

The tools necessary to implement Security Policies similar to the IPv4 ones are for the most part available in both network elements and security devices such as Firewalls. No Intrusion Detection Systems (IDS) seem to support IPv6 today however some of their functionality can be implemented in the interim through alternative solutions. IPv6’s readiness for deployment from a Network Security perspective might be viewed differently depending on its intended use. It is suitable for commercial services but it might not be considered so for Government Agencies [3].

While designing an IPv6 deployment it is important to remember that when transported over IPv4, existent IPv4 security services can be used to secure IPv6 communications as well. A good example would be the transport of IPv4 encapsulated IPv6 traffic over an IPv4 IPsec VPN. At the same time, the very presence of IPv6 needs to be acknowledged by the IPv4 security policies. For instance, existent firewalls need to allow protocol 41 [4] for the various tunneling mechanisms.

This paper discusses IPv6 deployment strategies for several network types and network layers: MPLS and IP cores in Service Provider networks, Access layer of Service Providers and Enterprise networks. While not unique, the suggested strategies are viewed as a good match for the service needs of these environments as well as a good match to the existent IPv4 infrastructure.

Service Provider Networks – MPLS Core

The term Service Provider (SP) covers a multitude of provider types such as: Internet Service Providers (ISP), Network Access Providers (NAP), Network Service Providers (NSP) and Content Providers (CP). Their scope and their business models are always reflected in their network design. The Core layer of a SP network is not standing to benefit from IPv6’s larger address space. It does not need many prefixes however, it will be called upon to carry IPv6 traffic and support IPv6 features.

Most major Service Providers built or upgraded their IPv4 network around a Multi-Protocol Label Switch (MPLS) core. This is a common design for Mobile SPs worldwide. MPLS has proven itself as a reliable, scalable technology that enables SPs to integrate various transport technologies and to easily roll out value-add services. Figure 2 depicts the relevant aspects of such a network.

Figure 2- MPLS Core of a Service Provider

Labels are exchanged between the Label Switching Routers (PE and P routers) with the help of LDP or RSVP. In an MPLS network only the PEs need to be aware of all prefixes which implies a simplified core from the routing perspective. Commonly deployed IGPs are OSPF and ISIS. The typical services provided are: Layer 2 connectivity with the help of AToM tunnels, Unicast traffic transport and connectivity, MPLS VPNs, QoS and in a smaller measure Multicast transport.

6PE for the MPLS Core

Observing the principle of minimal impact on the existent IPv4 network and services, an IPv6 deployment can leverage the MPLS infrastructure with the help of 6PE. The core switches tagged packets, regardless of type or content solely based on the top label. This means that the MPLS core does not have to be IPv6 aware and the only devices that would require an upgrade to dual stack are the Provider Edge (PE) routers. Figure 3 presents the operation of 6PE over an MPLS network [5].

Figure 3 - 6PE Operation in an MPLS Network

An IPv6 Address Family is added under the Multi-Protocol BGP enabling the 6PE routers to exchange IPv6 prefixes and corresponding labels. Conceptually, this deployment mechanism is very similar to an IPv4 VPN with a single, global VRF encompassing all 6PE routers. The packets are switched based on the top IPv4 label until the penultimate hop where the label is popped and the packet is sent to the 6PE router only with the IPv6 label. 6PE can also leverage any Traffic Engineering tunnels deployed in the MPLS core to support SLA requirements or redundancy.

The 6PE design is easy to scale up by upgrading and enabling the functionality on more PE routers as service coverage requires it. Hierarchical Route Reflectors (RR) can be used to scale the MP-BGP peering. RRs used for the IPv4 services can be used for IPv6 services as well. The network elements behind the 6PE routers are handling IPv6 natively and they can run a native IGP that is redistributed into MP-BGP. This solution leverages the performance of MPLS thus easily achieving line rate forwarding of IPv6 traffic through the 6PE routers.

Services Provided with 6PE

A 6PE based deployment inherits all the benefits and shortcomings of MPLS. It easily supports the roll out of IPv6 VPN services similar to the IPv4 ones. It also enables the SP to provide Inter-AS and Carrier Supporting Carrier connectivity for IPv6 traffic. The DSCP bits of IPv6 packets can be mapped into the MPLS EXP bits for deploying end-to-end QoS Differentiated Service for IPv6. On the other hand, an IPv6 multicast service cannot be replicated in the core, a limitation currently plaguing IPv4 multicast in MPLS networks as well. Solutions to this problem are currently being worked on. If the need to roll out multicast services arises before a solution is available, a work around could be to hop the multicast traffic across the core with the help of Layer 2 MPLS tunnels such as Pseudowire.

Service Provider Networks – IP Core

Despite being in vogue, MPLS does not appeal to all Service Providers some choosing to use IPv4 switching in the Core. Advances in switching mechanisms and technologies eliminated the gap between IP and Label based forwarding performance. New protocol features enabled IP based networks to provide similar services to the MPLS ones. Figure 4 depicts the relevant aspects of a network with an IP Core.

Figure 4 - IP Core of a Service Provider

Unlike MPLS, IP Core routers need to be aware of all prefixes in the network. Commonly deployed IGPs in the core are OSPF and ISIS. The typical services provided are: Layer 2 connectivity with the help of L2TPv3 tunnels, Unicast traffic transport and connectivity, Layer 3 VPNs, QoS and Multicast transport and services.

Native IPv6 for the IP Core

6PE was mentioned as an elegant, non-disruptive way to transport IPv6 across an MPLS network. This solution is not suitable for an IP core and enabling MPLS only for the IPv6 service is not recommended as it would add a complex overlay to the network. The best option in this case is to choose an IPv6 deployment model similar to IPv4, a native IPv6 Core.

In this case all routers need to be upgraded to dual stack and the two protocols operate in parallel as ships in the night. The migration impact is clearly more significant then the 6PE case. The core is now IPv6 aware and it has to handle not only the forwarding but also the control plane for this additional protocol, its resources are shared between the two protocols. Figure 5 presents the main elements of a native IPv6 core.

Figure 5 – Native IPv6 Core Deployment

The IPv6 routing protocol in the core should generally match that of IPv4: OSPFv3 or IS-IS. IPv4 and IPv6 IGP processes run independent of each other thus doubling the resource needs previously used in the core. If the IPv4 and IPv6 topologies are identical, a single IS-IS process can be used for both [6]. These routing protocols can easily extend into the Edge Layer of the network in a scalable manner with the use of multiple areas. BGP in this case is used to interface with major customers, other SPs or InterExchanges.

It is important to note that there is always the option to build a separate network core just for IPv6. This is of course a more expensive proposition however it represents an opportunity to build a new, state-of-the-art infrastructure for the next generation services. The IPv4 network can be phased out slowly by tunneling the IPv4 traffic over the new core. Such strategies are being planned and rolled out today.

Services Provided with a Native IPv6 Core

A Native IPv6 core can match in service support the existent IPv4 deployment. All IPv6 features are currently available to provide: Layer 2 connectivity with the help of L2TPv3 tunnels, Unicast traffic transport and connectivity, QoS and Multicast transport and services. Design wise most of these services can basically match their IPv4 counterparts. The Multicast constraints singled out in MPLS networks are not an issue to native deployments. Such an environment can provide multicast services for Content Providers delivering Multimedia streams to users in a PIM-SSM design. It can support the multicast services deployed between sites of the same Enterprise customer in a PIM-SM or PIM-Bidir design depending on applications and needs.

Broadband Access Networks

The Access Layer of Service Providers saw tremendous growth recently with the popular adoption of Broadband access. Broadband services started with the need for faster Internet and gaming access and they are now evolving to provide telephony services over IP and multimedia content access such as movies or music. With large numbers of devices under its management, this portion of the network is bound to benefit the most from a larger address space.

Access Technologies and Access Service Models

There are several types of technologies that are being used to provide broadband access. The most popular ones are Cable, xDSL, Ethernet to the home and Wireless while of the less popular, one could mention Power Line Communication (PLC). A summary of the most relevant elements for the popular access technologies is presented in Figure 6.

Figure 6 – Access Technologies.

Many of these network elements operate at OSI layers lower than IP so in principle they should not be affected by the version of the protocol transported. In reality they sometime need a certain level of IP visibility. In some cases such visibility is simply an operational improvement as is the case of Layer 2 switches enabled to do ICMP snooping. The switch could operate just as well without this functionality. In other cases such visibility is intrinsic to the operation of the technology as in the case of Cable networks where snooping is a requirement. In its current version, the standardization document for the Cable technologies, DOCSIS 2.0 does not provision for MLD snooping support which is critical to IPv6 operation relying on multicast traffic for, amongst so many things, Neighbor and Router Discovery. The DOCSIS specific QoS mechanisms are not yet mapped into IPv6 either. These are some of the factors that limit native IPv6 deployments in cable networks [7].

Unlike all other access technologies, Cable is not ready for native deployments at this time. Until the new DOCSIS specification (3.0) is implemented the only IPv6 deployment option for cable is tunnel based.

There are two main entities that participate in providing broadband access:

• Network Service Provider (NSP) provides IP connectivity to the Internet or other resources. It manages the users at Layer 3 by assigning IP addresses and certain services based on user profiles. The NSP can be and ISP or a CP.

• Network Access Provider (NAP) concerns itself exclusively with providing the users with controlled layer two access to the network resources and then transporting their traffic to the NSP of choice.

The NSP and the NAP can be two independent entities or one and the same and these two scenarios imply different business and service models.

When the NSP is the same with the NAP the user traffic is handled at Layer 3 in the access network. This traffic can be encapsulated in PPP in which case the PPP sessions are terminated at the access layer. If different than the NSP, the NAP hands the user traffic to the NSP for Layer 3 processing. Typically the user traffic is PPP encapsulated with the PPP sessions terminated at the edge between the NAP and the NSP. The NAP can also use an L2TP tunnel to aggregate the PPP sessions while transporting them to the NSP. Figure 7 depicts these service models in the case of xDSL but they are access technology independent [7].

Figure 7 - Access Service Models.

IPv6 in Broadband Access Networks

All IPv6 features necessary to support the service models shown in Figure 7 are currently available (AAA services, DNS services, encapsulation and forwarding support). With the exception of Cable networks, IPv6 broadband access services can be deployed natively whether a PPP encapsulation is used or not. L2TP aggregation is available for the IPv6 PPP sessions and the L2TP tunnel can be established over IPv6 or over IPv4. The later case is particularly interesting since it implies the fact that only the access layer needs to be upgraded to dual stack while the rest of the NAP can stay IPv4 since the IPv6 PPP sessions are transported over IPv4 through L2TP. Figure 8 presents IPv6 access service deployments that map their IPv4 counterparts. This approach is practical in that it does not require changes in the operation and management of the network; everything is done similar to IPv4.

Figure 8 - IPv6 Access Services that match the existent IPv4 ones.

The deployment of IPv6 offers however the opportunity to try new services that might not be possible with the existent IPv4 service models. As an example, the wholesale model of PPP sessions terminated at the NSP is not suitable for multicast. The multicast traffic can be replicated only by the NSP across all PPP sessions leading to a significant impact on the NAP’s network resources. This is not a scalable solution for a multicast service, the replication has to be done as close to the user as possible. A more suitable service model that could be deployed using IPv6 would be to handle the users at Layer 3 at the access layer. It is thus expected that hybrids of the designs shown in Figure 8 are likely for the IPv4 and IPv6 services [7]. These hybrids are made possible by features such as IPv6 Routed Bridged Encapsulation (RBE) that allows the user IPv4 PPP sessions to be bridged while the IPv6 traffic is routed (Figure 9).

Figure 9 – IPv4/IPv6 hybrid models.

IPv6 offers SPs more flexibility in service design and allows them to build support for new services with native deployments in Broadband Access Networks. From this perspective, Cable remains a challenge with tunneling being the only deployment option until the new version of DOCSIS that supports IPv6 is implemented.

Enterprise Networks

Enterprise networks can be layered similar to the SP ones yet in this case all these layers are most often under the administration of the same organization. For this reason this network type is discussed as a whole.

Depending on the size of the enterprise, its network can be as simple as a single campus, layer 2 network with access to the internet or it can be a multi-campus, layer 3 hierarchical network with access to multiple ISPs, sophisticated storage networks and resources for mobile and remote workers. Figure 10 depicts the relevant aspects of a complex Enterprise network.

Figure 10 – Enterprise Network Elements

Commonly deployed IGPs are OSPF, ISIS and EIGRP. Enterprise networks offer redundancy at both Layer 2 and Layer 3 in order to meet uptime requirements. The typical services provided are: Layer 2 and 3 connectivity, storage and content management, VPNs, multicast and mobility. BGP is typically used to interface with the ISPs.

There are multiple arguments in favor of deploying IPv6 in certain enterprises. Software development businesses can offer resources for the groups working on IPv6. Businesses that have customers using IPv6, DoD is a major such customer, might need to deploy IPv6 as well. The various branches of DoD are enterprises in themselves. It is however fair to say that any deployment of IPv6 in an Enterprise network is most likely gated by the availability of applications that support or better yet require IPv6.

Native IPv6 in Enterprise Networks

A Native IPv6 deployment in an Enterprise network is a natural selection. It can map the features and protocols of the IPv4 design. There are of course few points to consider:

• IPv6 might not be rolled out over the entire enterprise at first, but rather in few islands. For example, the networks in few buildings hosting the IPv6 development team of a software company are upgraded to dual stack. These islands can be interconnected for example with ISATAP tunnels or dedicated links.

• Various campuses are connected via IPv4 dedicated links or VPNs. The same approach can be used to interconnect the IPv6 networks in these locations. If IPv6 VPN services are not available with the SP, IPv6 traffic can be tunneled through the IPv4 VPN (which is most likely secured via encryption as well).

• The existent IPv4 network most likely has in place resources to terminate VPNs from remote and mobile users. These resources can be used by these users to set up connectivity to the enterprise network and then establish an IPv6 tunnel through this VPN. The Enterprise network will have to offer tunnel termination resources for this type of access.

• Layer 3 redundancy should be matched in the case of IPv6 as well (HSRP for IPv6).

• Most devices are expected to be dual stack so the existent NMS infrastructure can be used to manage the IPv6 network as well.

• Enterprise users and resources are expected to be dual stack thus being able to leverage both IPv4 and IPv6 networks. There will invariably be legacy applications and devices supporting legacy applications that are not upgradeable to dual stack. There will also be hosts that are not upgradeable to dual stack. Translation mechanisms will have to be used in order to provide access to such legacy devices. Note that one of the most popular translation mechanisms (NAT-PT) is currently in the process of being moved to experimental status by IETF. IPv4 over IPv6 tunnels (IPv4 over IPv6 or DSTM) might also become important in addressing this type of situations.

The well justified use of private IPv4 addresses in Enterprise Networks settled in the minds of network designers and operators over time. For various reasons but primarily security ones, they still demand private addresses despite all the global addresses made available by IPv6. It is expected that the IPv6 enabled Enterprise Networks will use two addressing schemes at the same time:

• Unique Local Unicast Addresses (ULA) for internal communications. They can be either centrally (FC00::/8) or locally (FD00::/8) assigned.

• Global Unicast Addresses for external communications.

Hosts will use Source Address Selection (SAS) mechanisms to source their traffic off of the SA relevant to the destination of the packet they intend to send. All routers should be configured with both address types on their interfaces unless there are segments that are not allowed to have access to the IPv6 internet. Traffic destined to or sourced from a ULA has to be stopped from crossing the boundaries of the Enterprise Network. Figure 11 captures some of the above mentioned aspects of a native IPv6 deployment in an Enterprise Network.

Figure 11 – Aspects of a native IPv6 deployment in Enterprise Networks.

Along with the use of IPv4 private addresses comes Network Address Translation (NAT) which is extensively used by private networks. Some of its perceived benefits might be defended particularly by those running enterprise networks who, nostalgically see it phased out by IPv6. While most of its benefits are not as substantial as it might seem, the value of NAT and the ways in which this value can be ported into IPv6 is extensively analyzed in [8].

The upgrade of the elements to dual stack has a significant impact on the network but this negative aspect is offset by multiple benefits of a native deployment. Multicast services can easily be deployed. Resources can be put in place to support Mobil IPv6 services which can offer new business models for certain Enterprises. Native IPv6 enterprise networks can be merged easier due to the renumbering features of IPv6. Multiple deployment approaches are however available for such an environment and they are discussed in [9].

Enterprises lag behind Service Providers in their adoption of IPv6. Companies such as Microsoft who is actively integrating IPv6 or government contractors who need to meet the government IPv6 requirements are the first to deploy it in their internal networks. Others are slow to follow since enterprises feel less constrained by the lack of addresses (NAT is solving their needs to access the Internet) and no killer apps were developed yet for IPv6 in this space.

Conclusions

The IPv6 feature analysis (Part I) and the discussion on the IPv6 deployment strategies (Part II) for various network types intends to highlight a very important message: IPv6 is a mature technology and it is ready for native deployment in production networks! Despite being a more expensive proposition, the emphasis was placed on Native IPv6 deployments since they reflect the strategic importance of the new protocol. Aside from better leveraging the larger address space, native IPv6 deployments also offer operators the opportunity to redesign their networks based on new needs and the lessons learned with IPv4. New services such as content delivery using multicast can be used to justify an initial build out of the IPv6 infrastructure. The ROI in an IPv6 network might appear less gloomy when placed in a long term perspective. This seems to be the belief of more and more providers that plan and roll out large scale IPv6 networks today.

The new version of IP might be just an evolutionary step but it can stimulate revolutionary changes in the world of communications. Governments recognize its importance for economical growth, providers see its potential to deliver new services in a more scalable manner, appliance manufacturers see its value when integrated in their products, and software companies are trying to seize on the peer-to-peer communication models it promises. The question is not: “What will my business gain from IPv6 today?” The question is: “What do I stand to loose by not considering IPv6 seriously today?” IPv6 represents a second chance to gain a fair share of the IP infrastructure that proved to be a great economical enabler of our times; this is a chance not to be missed.

Ciprian Popoviciu PhD, CCIE
Cisco Systems

References

[1] Ciprian Popoviciu "A Second Chance to a Fair Share of IP – IPv6 ~Deployment Considerations~" at http://www.citel.oas.org/newsletter/2005/marzo/ipv6_i.asp

[2] P Ferguson, D Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing”, RFC 2827, May 2000.

[3] “Default implementations of IPv6 may present a security risk and present perimeter detection issues for Federal agencies.” at http://www.us-cert.gov/federal/archive/infoNotices/FIN05-095.html

[4] Jordi Palet, et al. “Forwarding Protocol 41 in NAT Boxes”, draft-palet-v6ops-proto41-nat-03.txt

[5] “Cisco IOS IPv6 Provider Edge Router (6PE) over MPLS” at http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1835/
products_data_sheet09186a0080115501.html

[6] Lind et, al., "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.

[7] S. Asadulah, et al. “ISP IPv6 Deployment Scenarios in Broadband Access Networks”, draft-ietf-v6ops-bb-deployment-scenarios-01.txt

[8] G. Van de Velde, et al. “IPv6 Network Architecture Protection”, draft-ietf-v6ops-nap-00.txt

[9] Jim Bound “IPv6 Enterprise Network Analysis”, draft-ietf-v6ops-ent-analysis-01.txt