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

On Sat, Aug 21, 2010 at 9:38 AM, Fred Baker <fred@cisco.com> wrote:

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/

	< 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/

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