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

From: Fred Baker <[email-masked]>
Date: Sat, 21 Aug 2010 09:38:39 -0700

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/

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 21 Aug 2010 11:10:39 -0700

Fred,

We are getting very close and i appreciate you taking the time.  I hope it
is clear that in the 3GPP context, the network is the easy part and
generally just works. The hard part is engineering the service (NAT64, ...)
to the end host.

Here is my feedback.

"Mobile telephone network operators, especially those using LTE, have
seriously considered IPv6-only operation, and some have deployed it"

--please replaces "LTE" with "3GPP".  LTE is a specific radio technology,
but it is the 3GPP packet core architecture that allows easy IPv6
deployments in 2G, 3G, and 4G all the same.  The deployment that i have
today at T-Mobile USA is 2G/3G with IPv6-only + NAT64 service.

 "full interoperability can be expected for those applications the walled
garden enables"

-- Please remove "for those applications the walled garden enables."  These
were not constraints that Jari specified, he did not use the term walled
garden, and the constraints specified in the previous few sentences about
specifically selecting applications and services adequately set the context.

If we can make these changes, i will be very happy with this draft.

Once again, thanks for your patience.

Cameron

On Sat, Aug 21, 2010 at 9:38 AM, Fred Baker <[email-masked]> wrote:

>  <<http://tools.ietf.org/rfcdiff?url2=draft-arkko-ipv6-transition-guidelines-05.txt>
>  draft-arkko-ipv6-transition-guidelines-05.txt<http://tools.ietf.org/html/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 2
> 1, 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/<http://www.tools.ietf.org/tools/rfcdiff/>
>
>