draft-ietf-v6ops-wireline-incremental-ipv6-03.txt   draft-ietf-v6ops-wireline-incremental-ipv6-04.txt 
v6ops V. Kuarsingh, Ed. v6ops V. Kuarsingh, Ed.
Internet-Draft Rogers Communications Internet-Draft Rogers Communications
Intended status: Informational L. Howard Intended status: Informational L. Howard
Expires: November 24, 2012 Time Warner Cable Expires: December 1, 2012 Time Warner Cable
May 23, 2012 May 30, 2012
Wireline Incremental IPv6 Wireline Incremental IPv6
draft-ietf-v6ops-wireline-incremental-ipv6-03 draft-ietf-v6ops-wireline-incremental-ipv6-04
Abstract Abstract
Operators worldwide are in various stages of preparing for, or Operators worldwide are in various stages of preparing for, or
deploying IPv6 into their networks. The operators often face deploying IPv6 into their networks. The operators often face
difficult challenges related to both IPv6 introduction along with difficult challenges related to both IPv6 introduction along with
those related to IPv4 run out. Operators will need to meet the those related to IPv4 run out. Operators will need to meet the
simultaneous needs of IPv6 connectivity and continue support for IPv4 simultaneous needs of IPv6 connectivity and continue support for IPv4
connectivity for legacy devices with a stagnant supply of IPv4 connectivity for legacy devices with a stagnant supply of IPv4
addresses. The IPv6 transition will take most networks from an IPv4- addresses. The IPv6 transition will take most networks from an IPv4-
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2012. This Internet-Draft will expire on December 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 39 skipping to change at page 3, line 39
5.1.5. Phase 0- Foundation: Tools and Management . . . . . . 15 5.1.5. Phase 0- Foundation: Tools and Management . . . . . . 15
5.2. Phase 1 - Tunneled IPv6 . . . . . . . . . . . . . . . . . 15 5.2. Phase 1 - Tunneled IPv6 . . . . . . . . . . . . . . . . . 15
5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 16 5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 16
5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 18 5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 18
5.3.1. Native Dual Stack Deployment Considerations . . . . . 19 5.3.1. Native Dual Stack Deployment Considerations . . . . . 19
5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 19 5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 19
5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 21 5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 21
5.5. Phase 3 - IPv6-Only . . . . . . . . . . . . . . . . . . . 22 5.5. Phase 3 - IPv6-Only . . . . . . . . . . . . . . . . . . . 22
5.5.1. DS-Lite Deployment Considerations . . . . . . . . . . 23 5.5.1. DS-Lite Deployment Considerations . . . . . . . . . . 23
5.5.2. NAT64 Deployment Considerations . . . . . . . . . . . 24 5.5.2. NAT64 Deployment Considerations . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This draft sets out to help wireline operators in planning their IPv6 This draft sets out to help wireline operators in planning their IPv6
deployments while ensuring continued support for IPv6-incapable deployments while ensuring continued support for IPv6-incapable
skipping to change at page 5, line 36 skipping to change at page 5, line 36
include: include:
- IPv4 exhaustion may occur long before all traffic is able to be - IPv4 exhaustion may occur long before all traffic is able to be
delivered over IPv6, necessitating IPv4 address sharing delivered over IPv6, necessitating IPv4 address sharing
- IPv6 will pose operational challenges since some of the software - IPv6 will pose operational challenges since some of the software
is quite new and has had short run time in large production is quite new and has had short run time in large production
environments and organizations are also not acclimatized to environments and organizations are also not acclimatized to
supporting IPv6 as a service supporting IPv6 as a service
- Many access network devices or subscriber controlled CPEs may
not support native IPv6 operation for a period of time. [RFC6540]
should remedy the situation over time as the document requires
IPv6 support for all IP-capable nodes
- Connectivity modes will move from IPv4-only to Dual Stack in the - Connectivity modes will move from IPv4-only to Dual Stack in the
home, changing functional behaviors in the consumer network and home, changing functional behaviors in the consumer network and
increasing support requirements for the operator increasing support requirements for the operator
- Although IPv6 support on CPEs is a newer phenomenon, there is a
strong push by operators and the industry as a whole to enable
IPv6 on devices. As demand grows, IPv6 enablement will no longer
be optional, but necessary on CPEs. Documents like [RFC6540]
provide useful tools in the short term to help vendors and
implementors understand what "IPv6 support" means.
These challenges will occur over a period of time, which means that These challenges will occur over a period of time, which means that
the operator's plans need to address the ever changing requirements the operator's plans need to address the ever changing requirements
of the network and subscriber demand. Although phases will be of the network and subscriber demand. Although phases will be
presented in this document, not all operators may need to enable each presented in this document, not all operators may need to enable each
discrete phase. It is possible that characteristics in individual discrete phase. It is possible that characteristics in individual
networks may allow certain operators to skip or jump to various networks may allow certain operators to skip or jump to various
phases. phases.
3.1. Relevance of IPv6 and IPv4 3.1. Relevance of IPv6 and IPv4
The delivery of high-quality unencumbered Internet service should be The delivery of high-quality unencumbered Internet service should be
the primary goal for operators. It is recognized that with the the primary goal for operators. With the imminent exhaustion of
imminent exhaustion of IPv4, IPv6 will offer the highest quality of IPv4, IPv6 will offer the highest quality of experience in the long
experience in the long term. Even though the operator may be focused term. Even though the operator may be focused on IPv6 delivery, they
on IPv6 delivery, they should be aware that both IPv4 and IPv6 will should be aware that both IPv4 and IPv6 will play a role in the
play a role in the Internet experience during transition. The Internet experience during transition. The Internet is made of many
Internet is made of many interconnecting systems, networks, hardware, interconnecting systems, networks, hardware, software and content
software and content sources - all of which will move to IPv6 at sources - all of which will move to IPv6 at different rates.
different rates.
Many subscribers use older operating systems and hardware which Many subscribers use older operating systems and hardware which
support IPv4-only operation. Internet subscribers don't buy IPv4 or support IPv4-only operation. Internet subscribers don't buy IPv4 or
IPv6 connections; they buy Internet connections, which demands the IPv6 connections; they buy Internet connections, which demands the
need to support both IPv4 and IPv6 for as long at the subscriber's need to support both IPv4 and IPv6 for as long at the subscriber's
home network demands such support. The operator may be able to home network demands such support. The operator may be able to
leverage one or the other protocol to help bridge connectivity on the leverage one or the other protocol to help bridge connectivity on the
operator's network, but the home network will likely demand both IPv4 operator's network, but the home network will likely demand both IPv4
and IPv6 for some time. and IPv6 for some time.
skipping to change at page 9, line 25 skipping to change at page 9, line 25
tail IPv4 content reach. This longer term view may be distant to tail IPv4 content reach. This longer term view may be distant to
some, but should be considered when planning out networks, addressing some, but should be considered when planning out networks, addressing
and services. The needs and costs of maintaining two IP stacks will and services. The needs and costs of maintaining two IP stacks will
eventually become burdensome and simplification will be desirable. eventually become burdensome and simplification will be desirable.
The operators should plan for this state and not make IPv6 inherently The operators should plan for this state and not make IPv6 inherently
dependent on IPv4 as this would unnecessarily constrain the network. dependent on IPv4 as this would unnecessarily constrain the network.
4. IPv6 Transition Technology Analysis 4. IPv6 Transition Technology Analysis
Operators should understand the main transition technologies for IPv6 Operators should understand the main transition technologies for IPv6
deployment and IPv4 runout. This draft provides a brief description deployment and IPv4 run out. This draft provides a brief description
of some of the mainstream and commercially available options. This of some of the mainstream and commercially available options. This
analysis is focused on the applicability of technologies to deliver analysis is focused on the applicability of technologies to deliver
residential services and less focused on commercial access, wireless, residential services and less focused on commercial access, wireless,
or infrastructure support. or infrastructure support.
The technologies in focus for this document are targeted on those The technologies in focus for this document are targeted on those
commercially available and in deployment. commercially available and in deployment.
4.1. Automatic Tunneling using 6to4 and Teredo 4.1. Automatic Tunneling using 6to4 and Teredo
skipping to change at page 12, line 11 skipping to change at page 12, line 11
path to be the only bridge to IPv4 at that time given the potential path to be the only bridge to IPv4 at that time given the potential
impact. The operator may also want to make sure that most of its impact. The operator may also want to make sure that most of its
internal services and a significant about of external content is internal services and a significant about of external content is
available over IPv6 before deploying DS-Lite. The availability of available over IPv6 before deploying DS-Lite. The availability of
services on IPv6 would help lower the demand on the AFTRs. services on IPv6 would help lower the demand on the AFTRs.
By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444, By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444,
DS-Lite can facilitate continued support of legacy IPv4 services even DS-Lite can facilitate continued support of legacy IPv4 services even
after IPv4 address run out. There are some functional considerations after IPv4 address run out. There are some functional considerations
to take into account with DS-Lite, such as those described in to take into account with DS-Lite, such as those described in
[I-D.donley-nat444-impacts] and in [I-D.ietf-softwire-dslite- [I-D.donley-nat444-impacts]and in [I-D.ietf-softwire-dslite-
deployment]. deployment].
DS-Lite requires client support on the CPE to function. The ability DS-Lite requires client support on the CPE to function. The ability
to utilize DS-Lite will be dependent on the operator providing DS- to utilize DS-Lite will be dependent on the operator providing DS-
Lite capable CPEs or retail availability of the supported client for Lite capable CPEs or retail availability of the supported client for
subscriber-acquired endpoints. subscriber-acquired endpoints.
4.6. NAT64 4.6. NAT64
NAT64 [RFC6146] provides the ability to connect IPv6-only connected NAT64 [RFC6146] provides the ability to connect IPv6-only connected
skipping to change at page 14, line 28 skipping to change at page 14, line 28
as [RFC4942], [RFC6092], and [RFC6169] are excellent resources. as [RFC4942], [RFC6092], and [RFC6169] are excellent resources.
5.1.4. Phase 0 - Foundation: Transition Architecture 5.1.4. Phase 0 - Foundation: Transition Architecture
The operators should plan out their transition architecture in The operators should plan out their transition architecture in
advance (with room for flexibility) to help optimize how they will advance (with room for flexibility) to help optimize how they will
build out and scale their networks. Should the operator consider build out and scale their networks. Should the operator consider
multiple technologies like CGN/NAT444, DS-Lite, NAT64 and 6RD, they multiple technologies like CGN/NAT444, DS-Lite, NAT64 and 6RD, they
may want to plan out where network resident equipment may be located may want to plan out where network resident equipment may be located
and potentially choose locations which can be used for all functional and potentially choose locations which can be used for all functional
roles (i.e. placement of NAT44 translator, AFTR, NAT64 gateway and roles (i.e. Placement of NAT44 translator, AFTR, NAT64 gateway and
6RD relays). Although these functions are not inherently connected, 6RD relays). Although these functions are not inherently connected,
additional management, diagnostic and monitoring functions can be additional management, diagnostic and monitoring functions can be
deployed along side the transition hardware without the need to deployed along side the transition hardware without the need to
distribute these to an excessive or divergent number of locations. distribute these to an excessive or divergent number of locations.
This approach may also prove beneficial if traffic patterns change This approach may also prove beneficial if traffic patterns change
rapidly in the future as the operators may need to evolve their rapidly in the future as the operators may need to evolve their
transition infrastructure faster than originally anticipated. Once transition infrastructure faster than originally anticipated. Once
such example may be the movement from a CGN/NAT44 model (dual stack) such example may be the movement from a CGN/NAT44 model (dual stack)
to DS-Lite. Since both traffic sets require a translation function to DS-Lite. Since both traffic sets require a translation function
skipping to change at page 24, line 43 skipping to change at page 24, line 43
legacy IPv4 applications, the operator may choose to implement legacy IPv4 applications, the operator may choose to implement
464XLAT [I-D.ietf-v6ops-464xlat] if possible. As support for IPv6 on 464XLAT [I-D.ietf-v6ops-464xlat] if possible. As support for IPv6 on
subscriber equipment and content increases, the efficiency of NAT64 subscriber equipment and content increases, the efficiency of NAT64
increases by reducing the need to translate traffic. The NAT64 increases by reducing the need to translate traffic. The NAT64
deployment would see an overall decline in usage as more traffic is deployment would see an overall decline in usage as more traffic is
promoted to IPv6-to-IPv6 native communication. NAT64 may play an promoted to IPv6-to-IPv6 native communication. NAT64 may play an
important part of an operator's late stage transition, as it removes important part of an operator's late stage transition, as it removes
the need to support IPv4 on the access network and provides a solid the need to support IPv4 on the access network and provides a solid
go-forward networking model. go-forward networking model.
It should be noted, as with any technology which utilizes address
sharing, that the IPv4 public pool sizes (IPv4 transport addresses
per [RFC6146]) can pose limits to IPv4 server connectivity for the
subscriber base. Operators should be aware that some IPv4 growth in
the near term is possible, so IPv4 translation pools need to be
monitored.
6. IANA Considerations 6. IANA Considerations
No IANA considerations are defined at this time. No IANA considerations are defined at this time.
7. Security Considerations 7. Security Considerations
Operators should review the documentation related to the technologies Operators should review the documentation related to the technologies
selected for IPv6 transition. In those reviews, operators should selected for IPv6 transition. In those reviews, operators should
understand what security considerations are applicable to the chosen understand what security considerations are applicable to the chosen
technologies. As an example, [RFC6169] should be reviewed to technologies. As an example, [RFC6169] should be reviewed to
 End of changes. 11 change blocks. 
22 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/