[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Diff: draft-arkko-ipv6-transition-guidelines-05.txt - transition-guideline.txt

Title: Diff: draft-arkko-ipv6-transition-guidelines-05.txt - transition-guideline.txt
Cameron:

Does the following address your concerns?

Fred



< draft-arkko-ipv6-transition-guidelines-05.txt   transition-guideline.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational F. Baker Intended status: Informational F. Baker
Expires: February 21, 2011 Cisco Systems Expires: February 22, 2011 Cisco Systems
August 20, 2010 August 21, 2010
Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
draft-arkko-ipv6-transition-guidelines-05 draft-arkko-ipv6-transition-guidelines-06
Abstract Abstract
The Internet continues to grow beyond the capabilities of IPv4. An The Internet continues to grow beyond the capabilities of IPv4. An
expansion in the address space is clearly required. With its expansion in the address space is clearly required. With its
increase in the number of available prefixes and addresses in a increase in the number of available prefixes and addresses in a
subnet, and improvements in address management, IPv6 is the only real subnet, and improvements in address management, IPv6 is the only real
option on the table. Yet, IPv6 deployment requires some effort, option on the table. Yet, IPv6 deployment requires some effort,
resources, and expertise. The availability of many different resources, and expertise. The availability of many different
deployment models is one reason why expertise is required. This deployment models is one reason why expertise is required. This
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 February 21, 2011. This Internet-Draft will expire on February 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 2, line 24 skipping to change at page 2, line 24
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Choosing a Deployment Model . . . . . . . . . . . . . . . 6 3.2. Choosing a Deployment Model . . . . . . . . . . . . . . . 6
4. Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . . 7 4. Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . . 7
4.1. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8 4.1. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8
4.2. Crossing IPv4 Islands . . . . . . . . . . . . . . . . . . 10 4.2. Crossing IPv4 Islands . . . . . . . . . . . . . . . . . . 10
4.3. IPv6-Only Core Network . . . . . . . . . . . . . . . . . . 11 4.3. IPv6-Only Core Network . . . . . . . . . . . . . . . . . . 11
4.4. IPv6-only Deployment . . . . . . . . . . . . . . . . . . . 11 4.4. IPv6-only Deployment . . . . . . . . . . . . . . . . . . . 11
5. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 13 5. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Internet continues to grow beyond the capabilities of IPv4. The The Internet continues to grow beyond the capabilities of IPv4. The
tremendous success of the Internet has strained the IPv4 address tremendous success of the Internet has strained the IPv4 address
space, which is no longer sufficient to fuel future growth. At the space, which is no longer sufficient to fuel future growth. At the
time of this writing, August 2010, the IANA "free pool" contains only time of this writing, August 2010, the IANA "free pool" contains only
14 unallocated unicast IPv4 /8 prefixes. Credible estimates based on 14 unallocated unicast IPv4 /8 prefixes. Credible estimates based on
past behavior suggest that the RIRs will exhaust their remaining past behavior suggest that the RIRs will exhaust their remaining
skipping to change at page 5, line 49 skipping to change at page 5, line 49
particular advantage to avoiding dealing with IPv6 as a part the particular advantage to avoiding dealing with IPv6 as a part the
normal network planning cycle. The migration tools already exist, normal network planning cycle. The migration tools already exist,
and while additional features continue to be developed it is not and while additional features continue to be developed it is not
expected that they radically change what networks have to do. In expected that they radically change what networks have to do. In
other words, there is no point in waiting for an improved design. other words, there is no point in waiting for an improved design.
There are only a few exceptional networks where co-existence with There are only a few exceptional networks where co-existence with
IPv4 is not a consideration at all. These networks are typically new IPv4 is not a consideration at all. These networks are typically new
deployments, strictly controlled by a central authority, and have no deployments, strictly controlled by a central authority, and have no
need to deal with legacy devices. For example, specialized machine- need to deal with legacy devices. For example, specialized machine-
to-machine networks that communicate only to designated servers can to-machine networks that communicate only to designated servers, such
easily be deployed as IPv6-only networks. In most other networks as Smart Grids, can easily be deployed as IPv6-only networks. Mobile
telephone network operators, especially those using LTE, have
seriously considered IPv6-only operation, and some have deployed it.
Research networks that can be separated from the IPv4 Internet to
find out what happens are also a candidate. In most other networks
IPv4 has to be considered. A typical requirement is that older, IPv4 has to be considered. A typical requirement is that older,
IPv4-only devices must be accommodated. Most networks that cross IPv4-only applications, systems, or services must be accommodated.
administrative boundaries or allow end user equipment have such Most networks that cross administrative boundaries or allow end user
requirements. Even in situations where the network consists of only equipment have such requirements. Even in situations where the
new, IPv6-capable devices it is typically required that the devices network consists of only new, IPv6-capable devices it is typically
can communicate with the IPv4 Internet. required that the devices can communicate with the IPv4 Internet.
It is expected that after a period of supporting both IPv4 and IPv6, It is expected that after a period of supporting both IPv4 and IPv6,
IPv4 can eventually be turned off. This should happen gradually. IPv4 can eventually be turned off. This should happen gradually.
For instance, a service provider network might stop providing IPv4 For instance, a service provider network might stop providing IPv4
service within its own network, while still allowing its IPv6 service within its own network, while still allowing its IPv6
customers to access the rest of the IPv4 Internet through overlay or customers to access the rest of the IPv4 Internet through overlay or
proxy services. Regardless of progress in supporting IPv6, it is proxy services. Regardless of progress in supporting IPv6, it is
widely expected that some legacy applications and some networks will widely expected that some legacy applications and some networks will
continue to run only over IPv4 for many years. All deployment continue to run only over IPv4 for many years. All deployment
scenarios need to deal with this situation. scenarios need to deal with this situation.
skipping to change at page 11, line 51 skipping to change at page 12, line 8
Our final deployment model breaks the requirement that all parties Our final deployment model breaks the requirement that all parties
must upgrade to IPv6 before any actual communications use IPv6. This must upgrade to IPv6 before any actual communications use IPv6. This
model makes sense when the following conditions are met: model makes sense when the following conditions are met:
o There is a fact or requirement that there be an IPv4-only domain o There is a fact or requirement that there be an IPv4-only domain
and an IPv6-only domain. and an IPv6-only domain.
o There is a requirement that hosts in the IPv4-only domain access o There is a requirement that hosts in the IPv4-only domain access
servers or peers in the IPv6-only domain and vice versa. servers or peers in the IPv6-only domain and vice versa.
This is enhanced when the network operator is able to select user
devices and applications, enabling him to ensure that any
communication exchange is in fact predictable and translatable. In
such a case, full interoperability can be expected for those
applications the walled garden enables.
When we say "IPv4-only" or "IPv6-only", we mean that the applications When we say "IPv4-only" or "IPv6-only", we mean that the applications
can communicate only using IPv4 or IPv6; this might be due to lack of can communicate only using IPv4 or IPv6; this might be due to lack of
capabilities in the applications, host stacks, or the network; the capabilities in the applications, host stacks, or the network; the
effect is the same. The reason to switch to an IPv6-only network may effect is the same. The reason to switch to an IPv6-only network may
be a desire to test such a configuration, or to simplify the network. be a desire to test such a configuration, or to simplify the network.
It is expected that as IPv6 deployment progresses, the second reason It is expected that as IPv6 deployment progresses, the second reason
will become more prevalent. One particular reason for considering an will become more prevalent. One particular reason for considering an
IPv6-only domain is the effect of overlapping private address space IPv6-only domain is the effect of overlapping private address space
to applications. This is important in networks that have exhausted to applications. This is important in networks that have exhausted
both public and private IPv4 address space and where arranging an both public and private IPv4 address space and where arranging an
 End of changes. 8 change blocks. 
14 lines changed or deleted 24 lines changed or added

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