v6ops V. Kuarsingh, Ed.
Internet-Draft Rogers Communications
Intended status: Informational July 5, 2011
Expires: January 6, 2012
Wireline Incremental IPv6
draft-kuarsingh-wireline-incremental-ipv6-00
Abstract
Operators are currently challenged with enabling IPv6 within their
networks while maintaing IPv4 connectivity beyond IPv4 address
depletion. In the Wireline world, this will often require the
replacement of access network equipment and consumer equipment along
with the uplift of the core network. During the transition from the
IPv4-Only service environment to the IPv6/IPv4 dual service
environment, operators may often need to use multiple transition
technologies and mechanisms to maintain services for their customer
base. This draft is set up to show how some Wireline provides
(including Cable, DSL and Fibre) may accomplish this using
tunnelling, translation and native IPv6 services.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Kuarsingh Expires January 6, 2012 [Page 1]
Internet-Draft Wireline Incremental IPv6 July 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Reasons for a Phased Approach . . . . . . . . . . . . . . . . 4
3.1. Relevance of IPv6 and IPv4 . . . . . . . . . . . . . . . . 4
3.2. IPv4 Resource Challenges . . . . . . . . . . . . . . . . . 4
3.3. IPv6 Introduction and Maturity . . . . . . . . . . . . . . 5
3.4. Impact to Operators . . . . . . . . . . . . . . . . . . . 5
4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 6
4.1. Automatic Tunnelling using 6to4 and Teredo . . . . . . . . 6
4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 7
4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8
4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 9
5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 9
5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 9
5.1.2. Phase 0 - Foundation: Routing . . . . . . . . . . . . 10
5.1.3. Phase 0 - Foundation: Network Policy and Security . . 10
5.1.4. Phase 0 - Foundation: Transition Architecture . . . . 10
5.2. Phase 1 - Tunnelled IPv6 . . . . . . . . . . . . . . . . . 10
5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 11
5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 12
5.5. Phase 3 - Tunnelled IPv4 . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Kuarsingh Expires January 6, 2012 [Page 2]
Internet-Draft Wireline Incremental IPv6 July 2011
1. Introduction
IPv6 represents the strategic IP protocol version which will meet the
addressing needs of the Internet into the future. Many operators are
already working to implement IPv6 within their networks, and many
others may just be starting this process. A solid IPv6 plan will
need to include both the baseline requirements to enable IPv6 within
the network, but must also include facilities to provide continuance
for IPv4 connectivity. Given the vast number of technological
options now available to operators for transition to IPv6, the task
may seem daunting when attempting to identify which technologies are
appropriate for a given network, and how these technologies can be
introduced.
This draft sets out to help operators who may be just starting the
evaluation process by identifying which technologies can be used in
an incremental fashion to transition from an IPv4-only environment to
an efficient IPv6/IPv4 environment. Although no single plan will
work for for all operators, generically, those listed herein provide
a baseline which can be included in many plans.
This draft is specifically catered towards wireline environments
which may use technologies such as Cable, DSL and/or Fibre as the
access method to the end consumer. This draft also attempts to
follow the methodologies set out in [I-D.ietf-v6ops-v4v6tran-
framework] to identify how the technologies can be used. This
document also attempts to follow the principles laid out in [RFC6180]
which provides guidance on using transition mechanisms. This
document will show how tunnelling using 6RD and DS-Lite as well as
translation via CGN can be used with native IPv6 to deliver effective
dual stack services in an evolving wireline network.
2. Motivation
Wireline Operators are increasingly becoming aware of the need to
support IPv6. The depletion of unassigned IPv4 addresses within IANA
and the RIRs has highlighted the need to move beyond IPv4. In many
operator environments, the main task will be the addition of IPv6
into the network. As straightforward as this task may seem, it will
require forethought and planning. However, of greater concern is
that the introduction of IPv6 may need to take place in a volatile
environment where IPv4 resources are depleted complicating what
technologies can be used, and how dual stack services may be offered
to customers.
Operators will want to understand which of the prevailing
technologies can be used in a changing network environment while
Kuarsingh Expires January 6, 2012 [Page 3]
Internet-Draft Wireline Incremental IPv6 July 2011
adapting to the needs and conditions of the network. The Operator's
main goal will be to maintain quality IP services to Internet
customers while the world moves from a predominately IPv4 centric
system to a dual stack IPv6/IPv4 system and eventually to an IPv6
centric world.
3. Reasons for a Phased Approach
Operators may want to consider a phased approach to IPv6 service
introduction for a number of reasons. These reasons include the
relevance of both IPv4 and IPv6 services in the new ecosystem over
the next few years. Both protocols will play a key role in providing
a holistic service to customers in various ways. IPv4 resources will
likely become depleted in many networks during the IPv6 transition
inhibiting the general use of traditional dual stack. Additionally,
IPv6 will often be a new protocol for operators and their staff
further challenging their task and potentially limiting how quickly
they can move to full IPv6 dependence.
3.1. Relevance of IPv6 and IPv4
The reality for operators over the next few years will be that both
IPv4 and IPv6 will play a role in the Internet experience. Although
many IPv6 advocates seek to move the Internet to IPv6 quickly, the
fact that many older operating systems and hardware support IPv4-only
operating modes will need to be accepted.
Additionally, the Internet is made of of many interconnecting
systems, networks and various content sources all of which will move
to IPv6 at different rates. The Operator's mandate during this time
of transition will be to support connectivity to both IPv6 and IPv4
through various technological means.
3.2. IPv4 Resource Challenges
Since connectivity to IPv4-only endpoints and/or content will remain
a reality for a period of time, IPv4 resource challenges are of key
concern to operators. The lack of new IPv4 addressees for additional
endpoints means that growth in some networks will be based on address
sharing.
Networks are growing at different rates based on a number of factors
which may be related to emerging markets and/or proliferation of
Internet based services. Given the reality that growth on the
Internet will continue, IPv4 address constraints will likely impact
many if not most operators at some point. This will play an
important role when considering what technologies are viable as the
Kuarsingh Expires January 6, 2012 [Page 4]
Internet-Draft Wireline Incremental IPv6 July 2011
transition period moves on. Of note will be any use of technologies
which rely on IPv4 as the mechanism to supply IPv6 services such as
6RD. Also, if native dual stack is considered by the operator,
challenges on the IPv4 path is also of concern.
3.3. IPv6 Introduction and Maturity
Operators will want to or be forced to support IPv6 at some point.
The introduction of IPv6 will require the operationalization of IPv6.
The IPv4 environment we have today was built over time and was
matured by experience. Although many of these experiences are
transferable from IPv4 to IPv6, new experience is necessary for IPv6
nonetheless.
Engineering and Operational staff will need to become acclimatized to
IPv6 which will take time as experience is gained. During this ramp
up period, Operators will need to be aware that instability may occur
and should be taking this into account when selecting what
technologies are viable during early transition. Operators may not
want to subject their mature IPv4 service to a "new IPv6" path
initially while it may be going through growing pains. This plays a
role during initial transition when considering technologies which
require IPv6 to support IPv4 services such as DS-Lite.
Of consideration as well will be the reality that some of these
technologies are new and/or are still under development and
refinement. Deployment experience may be needed to vet these
technologies out and stabilize them in production environments. Many
supporting systems are also under development and have newly
developed IPv6 functionality including vendor implementations of
DHCPv6, Management Tools, Monitoring Systems, Diagnostic systems,
along with other systems.
Although the base technological capabilities exist to enable and run
IPv6 in most environments; until such time as each key technical
member of an operator's organization can identify IPv6, understand
it's relevance to the IP Service offering, how it operates and how to
troubleshoot it - it's still maturing.
3.4. Impact to Operators
The lack of new IPv4 addresses related to depletion and the relative
maturity state of IPv6 within the operator network will both impact
what technologies can be used, when they can be used and how they can
be used. Operators are welcome to evaluate the impact of these
challenges on their own, but some considerations are highlighted
herein.
Kuarsingh Expires January 6, 2012 [Page 5]
Internet-Draft Wireline Incremental IPv6 July 2011
The lack of IPv4 addresses will surely mean that any service
requiring it's use as a method to deliver just IPv4, or a vehicle to
deliver IPv6 may be short lived. This may also limited their
usefulness to initial transition phases. Nothing precludes an
operator from using technologies for longer periods of time, but the
relative impacts need to be considered. Also, some technologies
based on native IPv6 delivery will need to be weighed as well. This
includes traditional dual stack and more importantly technologies
like DS-Lite which require a native IPv6 path to the customer premise
The operator may want to wait until a certain maturity level is
reached with respect to IPv6 before making IPv6 connectivity
mandatory to service IPv4 flows given the potential for failure at
the outset.
4. IPv6 Transition Technology Analysis
Understanding the main IPv6 transition technologies and those related
to dealing with IPv4 run out should be a primary goal of any
operator. Although this draft is not designed to list all options or
to provide a full technical analysis of each of the identified
technologies, it provides a brief description and explains how they
can or may be used in a transitioning operator network.
4.1. Automatic Tunnelling using 6to4 and Teredo
Operators may not be actively deploying IPv6, but automatic
mechanisms do exist on deployed operating systems and hardware that
should be of note. Such technologies include 6to4 described within
[RFC3056] which is mostly commonly used in a deployment mode using
anycast relays as described in [RFC3068]. Additionally, Teredo
[RFC4380] is also used widely by many Internet hosts as a means to
reach the IPv6 world when no native or operator provided path is made
available.
The operator may not want or have intended for these technologies to
be active in their networks, but should be aware that the traffic
exists and may be inclined to provide the best possible experience
for these endpoints. Drafts such as [I-D.ietf-v6ops-6to4-advisory]
have been written to help operators understand observed problems and
provide guidelines on how to manage such protocols. An Operator may
want to incrementally provide local relays for 6to4 and/or Teredo to
help improve the protocol's performance for ambient traffic utilizing
these methods. Experiences such as those described in [I-D.jjmb-
v6ops-comcast-ipv6-experiences] show that local relays have proved
beneficial to 6to4 protocol performance.
Kuarsingh Expires January 6, 2012 [Page 6]
Internet-Draft Wireline Incremental IPv6 July 2011
4.2. Carrier Grade NAT (NAT444)
Carrier Grade NAT (GGN), specifically as deployed in a NAT444
scenario [I-D.ietf-behave-lsn-requirements], is also a relevant
technology. CGN/NAT444 is not a IPv6 specific function, but may
prove beneficial for those operators who offer dual stack services to
endpoints. CGNs are known to cause certain challenges for the IPv4
service path as described in documents like [I-D.donley-nat444-
impacts], but may often be necessary for a time.
In a network where IPv4 address availability is low or no new
addressees can be assigned to Internet hosts, a CGN/NAT444 deployment
may be a viable way to provide continued access to the IPv4 path.
Other technologies may also be used, but a provider may choose to use
this method earlier on since it's a well understood method of
delivering IPv4 connectivity - notwithstanding the challenges of
NAT444. When considered in the overall IPv6 transition, CGN/NAT444
may play a vital role in delivery Internet services.
4.3. 6RD
6RD as described in [RFC5969] does provide a quick and effective way
to deliver IPv6 services to access network endpoints which do not yet
support IPv6. 6RD provides tunnelled connectivity to IPv6 over the
existing IPv4 path. The lack of native IPv6 for a customer premise
may be related to technological challenges of delivering IPv6 on a
give access type or related to other operational or technical
impediments that may existing in an operator's environment.
6RD defiantly offers a solid early transition option to operators by
eliminating the bottle neck of needing to deploy native IPv6 to the
access edge. Over time, as the access edge is upgraded, 6RD can be
replaced by native IPv6 access. 6RD can be delivered along with CGN/
NAT444, but this would be a sub-optimal way of delivering service
since the operator would then need to relay all IPv6 traffic as well
as provide NAT functionally for IPv4 flows.
6RD may also be seen as advantageous during early transition while
IPv6 traffic volumes are low. During this period, the operator can
gain experience with IPv6 on the core and improve their peering
framework to meet those of the IPv4 service. Scaling of 6RD may be
required by adding relays to the operator's network, but since 6RD is
stateless, this task is quite manageable. In the case where CGN/
NAT444 is used, there are stateful considerations to be made on the
NAT444 path.
Operators may want to use 6RD, as noted, while traffic volumes are
low and while internal services are mainly on IPv4. As higher
Kuarsingh Expires January 6, 2012 [Page 7]
Internet-Draft Wireline Incremental IPv6 July 2011
capacities are reached on the IPv6 path, the operator may want to
move away from delivering heavy loads on a tunnelled connection. 6RD
can continue to run indefinitely if the operator wishes to continue
this service, but over time, native IPv6 would be a much more
efficient way of delivering robust IPv6 services.
4.4. Native Dual Stack
Native Dual Stack is often referred to as the "Gold Standard" of IPv6
and IPv4 delivery. It is a method of service delivery which is
already used in some deployments. Native Dual Stack does however
require that Native IPv6 be delivered to the customer premise. This
technology option is most desirable in many cases and can be used
immediately if the access network and customer premise equipment
supports IPv6, or can also be used incrementally to tunnelling
options such as 6RD over time.
As time progresses, Native Dual Stack may be challenging to deliver
if more IPv4 addresses are not available on the IPv4 path. For a
sub-set of the IPv6 Native Dual Stack Customers, operators may
include CGN/NAT444 as an assist technology. Delivering Native Dual
Stack would require the operator's core and access network support
IPv6 with the required assisting systems like DHCPv6, DNS, and
diagnostic/management facilities to help maintain the IPv6
connection.
4.5. DS-Lite
DS-Lite, as described in [I-D.ietf-softwire-dual-stack-lite], is an
architecturally desirable way of delivery both IPv4 and IPv6 services
in an IPv4 constrained environment. DS-Lite is able to provide IPv4
services to customer networks which are only addressed with IPv6.
DS-Lite uses tunnelling mechanisms to pass IPv4 traffic between the
customer's network device (often a CPE) and the IPv4 internet using a
provider managed AFTR.
DS-Lite however can only be used where there are native IPv6
facilities to the customer permise endpoint. This may mean that the
technology's use may not be viable during early transition. The
operator may also not want to use DS-Lite immediately after IPv6
introduction as the organization may be development and maturing
their IPv6 environment and may not want to subject the customers IPv4
connection to the IPv6 path. This is likely an early transition
consideration and would diminish over time as IPv6 service delivery
is matured. The provider may also want to make sure that most of
their internal services, and external provider content is available
over IPv6 before deploying DS-Lite. This would lower the overall
load on the AFTR devices helping reduce cost and load on that layer
Kuarsingh Expires January 6, 2012 [Page 8]
Internet-Draft Wireline Incremental IPv6 July 2011
of the network. Nothing precludes an operator from using DS-Lite
earlier in the transition, but the operator needs to be aware of the
challenges that can arise. If DS-Lite is used during early
transition the operator will face scenario where they have support
personnel learning to troubleshoot IPv6 while this new protocol is
supporting the legacy IPv4 service.
One of the strongest benefits of DS-Lite is the ability to continue
to grow IPv4 services if required without the need to deploy more
IPv4 addressees to customer endpoints. This is quite advantageous as
the transition period progresses and IPv4 resources become more and
more challenging to secure.
5. IPv6 Transition Phases
The Phases described below are not provided as a ridged set of stops
but as a guideline which can be considered by the operator. The
phases reflect the need to support IPv4 and IPv6 during transition as
well as the premise that some technologies may prove beneficial at
various periods during the IPv6 transition.
Operators may want to follow all these steps, skip some steps if
possible or develop their own plans should they have other
considerations which may be of relevance to them. The main goal
however should be a set of phases that helps introduce IPv6, and
allows for both protocols to work for a period of time as the
Internet as whole moves to IPv6, followed by a declining need to add
more IPv4 support.
Additional guidelines and information on utilizing IPv6 transition
mechanisms can also be found in [RFC6180].
5.1. Phase 0 - Foundation
Before moving an organization to support IPv6 services, a foundation
needs to be made to support IPv6. This foundation includes the
following basic (non-exhaustive) list of items.
5.1.1. Phase 0 - Foundation: Training
Training may seem to be the most obvious step, but needs to be done
effectively and widely across key technical personnel. Unlike IPv4
which had existed for a long period of time before it became "mission
critical" for many organizations, IPv6 is being introduced at a time
when IP services are vial for most many Internet users. This should
not be taken likely and organizations need to commit to training
their staff. Staff may also have far less if any experience with
Kuarsingh Expires January 6, 2012 [Page 9]
Internet-Draft Wireline Incremental IPv6 July 2011
IPv6 which is not the same as with IPv4. This means the little
expose they get in their training may be all they have to lean on as
they seek to support IPv6 at the outset.
5.1.2. Phase 0 - Foundation: Routing
The network will all need to be in place to support IPv6. This
includes the routed infrastructure along with addressing principles,
routing principles, peering and related network functions. Since
IPv6 is quite different from IPv4 in the number of addresses which
are made available, careful attention to a scalable and manageable
architecture needs to be made. Also, given that customer
environments will no longer receive a token single address as is
common in IPv4, operators will need to understand the impacts of
delegating larges sums of addresses (Prefixes) to consumer endpoints.
Delegating prefixes can be of specific importance in Cable
environments where downstream customers often move between access
nodes, raising the concern of frequent renumbering and/or managing
movement of routed prefixes within the network.
5.1.3. Phase 0 - Foundation: Network Policy and Security
Like many principles, network policy and security need to be
considered for IPv6. It is possible that many of the IPv4 policies
may transfer over to the IPv6 world, others may not be applicable.
There is also a potential that new policies need to be made to deal
with issues specifically related to IPv6. This document does not
highlight these specific issues, but raises the awareness they are of
consideration and should be addressed.
5.1.4. Phase 0 - Foundation: Transition Architecture
The operator may want plan out their transition architecture in
advance (with obvious room for flexibility) to help optimize how they
will build out and scale their networks. If the operator should want
to use multiple technologies like CGN/NAT444, DS-Lite and 6RD, they
may want to plan out where such equipment may be located and
potentially choose locations which can be used for all three roles.
This would allow for the least disruption as the operator evolves the
transition environment to meet the needs of the network.
5.2. Phase 1 - Tunnelled IPv6
During the initial phase of transition the operator may want to
support IPv6 before native IPv6 services are possible on the access
network. During this period of time, tunnelled access to IPv6 is
likely a very viable and desirable option. Providers can deploy
relays for automatic tunnelling technologies like 6to4 and Teredo,
Kuarsingh Expires January 6, 2012 [Page 10]
Internet-Draft Wireline Incremental IPv6 July 2011
and can more importantly deploy technologies like 6RD. It should be
noted that technologies like 6to4 and Teredo do not share the same
address selection behaviours as those like 6RD as per address
selection [RFC3484].
The operator can deploy 6RD relays quite easily and scale them as
needed to meet the early customer needs of IPv6. Since 6RD requires
the upgrade or replacement of most CPEs, the operator may want ensure
that the CPEs support not just 6RD but Native Dual Stack and other
tunnelling technologies if possible. 6RD client side deployments are
now available in the retail channel products and within the OEM
market making it a viable option for a wide range of operations.
Retail availability of 6RD is important since not all operators
control or have influence over what is deployed in the consumer site.
If the operator does not have the access network challenge of
deploying Naive IPv6, they may want to skip this phase. However, the
operator may still want to deploy 6to4 and/or Teredo relays to help
the automatic tunnelling technology operation while Native IPv6 is
deployed. This initial phase also provides the added benefit of
allow the operational folks to deterministically know what the IPv6
prefix assignment is based on the IPv4 address. Many operational
tools are available or have been built to identify what IPv4 (often
dynamic) address was assigned to a customer host/CPE. So a simple
tool and/or method can be built to help the operational folks in an
organization know what the IPv6 prefix is for 6RD based on to
knowledge of the IPv4 address.
5.3. Phase 2: Native Dual Stack
As a follow-up phase to "Tunnelled IPv6" or as an initial step, the
operator may deploy Native IPv6 to the customer premise. This phase
would then allow for both IPv6 and IPv4 to be natively access by the
customer equipment. It is also possible that the second phase be
enabled in pockets of the network while the access network is
undergoing upgrades.
As one of the most desirable options, Native Dual Stack should be
sought as soon as possible if the operator's network allows. During
this phase, the operator can confidently work with content providers
and internal groups to move content to IPv6. Since there are no
translation devices needed for this mode of operation, it allows both
protocols (IPv6 and IPv4) to work efficiently within the network.
Efficiency in this context refers to the need (or lack there of) to
translate, incrementally route or relay customer traffic within the
operator's network.
Kuarsingh Expires January 6, 2012 [Page 11]
Internet-Draft Wireline Incremental IPv6 July 2011
5.4. Intermediate Phase for CGN
During the first two phases, acquiring more IPv4 addresses may become
challenging, therefore CGN may be required. The CGN/NAT444
infrastructure can be enabled if needed during either phase. CGN/
NAT444 is less optimal in a 6RD deployment (if used with 6RD to a
given endpoint) since all traffic must transverse some type of
operator equipment.
In the case of Native Dual Stack, CGN/NAT444 can be used to assist in
extending connectivity for the IPv4 path. During this time, for
endpoints subject to the CGN/NAT444 function, the Native IPv6 path is
available for higher quality connectivity. It would be the
expectation that the IPv6 path becomes better utilized by the
customer over time by virtue of IPv6 support in the home network and
within the content provider's realm.
5.5. Phase 3 - Tunnelled IPv4
Over time, the operator will mature IPv6 and have more ubiquitous
coverage within the network. Once the operator is familiar with
IPv6, tools have been developed and operational procedures refined,
more efficient modes of connectivity can be enabled. Once such
technology is DS-Lite. DS-Lite allows the operator to grow the IPv4
customer base if needed without the need to deploy more IPv4
addresses to customers. DS-Lite still requires IPv4 address sharing,
but this is seen as no worse and often more advantageous then NAT444
and other address sharing options give a single NAT layer.
The operator can also move endpoints (Dual Stack) to DS-Lite
retroactively in an attempt to reclaim IPv4 addresses for
redeployment. Redeployment of addressees may be desirable if IPv4
resources are needed for legacy equipment which cannot be upgraded to
IPv4 and no new IPv4 addressees can be acquired otherwise. The
operator may want to have already moved most external content and
internal content to IPv6 before this phase implemented. By having a
significant amount of traffic on IPv6, the operator would limit the
amount of translation resources which are needed at the AFTR layer to
support IPv4 flows. This would also be a benefit to the customer as
their traffic need not be translated by a operator device improving
performance.
If the operator was forced to enable CGN for a NAT444 deployment,
they may be able to co-locate the AFTR and CGN functions within the
network to simplify capacity management and the engineering of flows.
This phase can also co-exist with Native Dual Stack if desired since
the same basic foundation is needed for both technologies on the IPv6
side. DS-Lite however requires incremental functions in the network
Kuarsingh Expires January 6, 2012 [Page 12]
Internet-Draft Wireline Incremental IPv6 July 2011
such as the programming of the CPE and the implementation of the
AFTRs'.
6. IANA Considerations
No IANA considerations are defined at this time.
7. Security Considerations
No Additional Security Considerations are made in this document.
8. Acknowledgements
Thanks to the following people for their textual contributions and/or
guidance on IPv6 deployment considerations: John Brzozowski, Lee
Howard, Jason Weil, Nik Lavorato, John Cianfarani, and Chris Donley.
9. References
9.1. Normative References
[I-D.ietf-v6ops-v4v6tran-framework]
Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for
IP Version Transition Scenarios",
draft-ietf-v6ops-v4v6tran-framework-01 (work in progress),
February 2011.
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment", RFC 6180,
May 2011.
9.2. Informative References
[I-D.donley-nat444-impacts]
Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A.,
and V. Ganti, "Assessing the Impact of NAT444 on Network
Applications", draft-donley-nat444-impacts-01 (work in
progress), October 2010.
[I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for IP address sharing
schemes", draft-ietf-behave-lsn-requirements-01 (work in
progress), March 2011.
Kuarsingh Expires January 6, 2012 [Page 13]
Internet-Draft Wireline Incremental IPv6 July 2011
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work
in progress), May 2011.
[I-D.ietf-v6ops-6to4-advisory]
Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
draft-ietf-v6ops-6to4-advisory-02 (work in progress),
June 2011.
[I-D.jjmb-v6ops-comcast-ipv6-experiences]
Brzozowski, J., "Comcast IPv6 Experiences",
draft-jjmb-v6ops-comcast-ipv6-experiences-00 (work in
progress), March 2011.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
Author's Address
Victor Kuarsingh (editor)
Rogers Communications
8200 Dixie Road
Brampton, Ontario L6T 0C1
Canada
Email: victor.kuarsingh@rci.rogers.com
URI: http://www.rogers.com
Kuarsingh Expires January 6, 2012 [Page 14]