draft-ietf-v6ops-v4v6tran-framework-01.txt   draft-ietf-v6ops-v4v6tran-framework-02.txt 
V6OPS B. Carpenter V6OPS B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational S. Jiang Intended status: Informational S. Jiang
Expires: August 6, 2011 Huawei Technologies Co., Ltd Expires: January 27, 2012 Huawei Technologies Co., Ltd
V. Kuarsingh V. Kuarsingh
Rogers Communications Rogers Communications
February 2, 2011 July 26, 2011
Framework for IP Version Transition Scenarios Framework for IP Version Transition Scenarios
draft-ietf-v6ops-v4v6tran-framework-01 draft-ietf-v6ops-v4v6tran-framework-02
Abstract Abstract
This document sets out a framework for the presentation of scenarios This document sets out a framework agreed by the V6OPS WG for the
and recommendations for a variety of approaches to the transition presentation of scenarios and recommendations for a variety of
from IPv4 to IPv6, given the necessity for a long period of co- approaches to the transition from IPv4 to IPv6, given the necessity
existence of the two protocols. for a long period of co-existence of the two protocols.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 6, 2011. This Internet-Draft will expire on January 27, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
7. Informative References . . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
This document sets out a framework for the presentation of scenarios This document sets out a framework for the presentation of scenarios
and recommendations for a variety of approaches to the transition and recommendations for a variety of approaches to the transition
from IPv4 to IPv6, given the necessity for a long period of co- from IPv4 to IPv6, given the necessity for a long period of co-
existence of the two protocols. A general "call to arms" for existence of the two protocols. A general "call to arms" for
transition is found in [RFC5211], and a recommendation for four transition is found in [RFC5211], and a recommendation for four
principal scenarios is given in principal scenarios is given in [RFC6180]. A report on experience
[I-D.arkko-ipv6-transition-guidelines]. A report on experience and and plans of various Internet Service Providers (ISPs) is given in
plans of various Internet Service Providers (ISPs) is given in
[RFC6036]. However, it is clear that operators require more detailed [RFC6036]. However, it is clear that operators require more detailed
technical recommendations than are available so far. Unfortunately, technical recommendations than are available so far. Unfortunately,
the number of different combinations of existing IPv4 deployment the number of different combinations of existing IPv4 deployment
models, customer profiles and requirements, and possible coexistence models, customer profiles and requirements, and possible coexistence
and transition models, is enormous, so it is quite impracticable to and transition models, is enormous, so it is quite impracticable to
produce either a set of recommendations for each case, or a produce either a set of recommendations for each case, or a
recommended "one size fits all" model. That is why this document recommended "one size fits all" model. That is why this document
proposes a set of topics or dimensions, as a framework for a proposes a set of topics or dimensions, as a framework for a
reasonable number of recommendation documents. reasonable number of recommendation documents.
skipping to change at page 3, line 38 skipping to change at page 3, line 37
give a complete view of mechanisms an ISP may need to deploy, since give a complete view of mechanisms an ISP may need to deploy, since
it considers the requirements for an individual node, not for a it considers the requirements for an individual node, not for a
network or service infrastructure as a whole. network or service infrastructure as a whole.
[RFC4029] discussed scenarios for introducing IPv6 into ISP networks, [RFC4029] discussed scenarios for introducing IPv6 into ISP networks,
as the problem was viewed some years ago. Its end goal was simply a as the problem was viewed some years ago. Its end goal was simply a
dual-stack ISP backbone. Today's view is that this is insufficient, dual-stack ISP backbone. Today's view is that this is insufficient,
as it does not allow for prolonged interworking between IPv6-only and as it does not allow for prolonged interworking between IPv6-only and
legacy (IPv4-only) hosts. Indeed, the end goal today might be an legacy (IPv4-only) hosts. Indeed, the end goal today might be an
IPv6-only ISP backbone, with some form of legacy IPv4 support IPv6-only ISP backbone, with some form of legacy IPv4 support
[I-D.arkko-ipv6-transition-guidelines]. [RFC6180].
Although the basic IPv6 standards are stable, considerable work Although the basic IPv6 standards are stable, considerable work
continues in several IETF working groups, on issues such as continues in several IETF working groups, on issues such as
multihoming, tunneling, and IP layer interworking between IPv6-only multihoming, tunneling, and IP layer interworking between IPv6-only
and IPv4-only hosts. However, operators faced with IPv4 address and IPv4-only hosts. However, operators faced with IPv4 address
exhaustion in the coming few years need immediate guidance. These exhaustion in the coming few years need immediate guidance. These
operators cannot avoid the need for general skills acquisition, or operators cannot avoid the need for general skills acquisition, or
the need to write their own detailed deployment plan, but they also the need to write their own detailed deployment plan, but they also
need guidance for generic scenarios similar to their actual need guidance for generic scenarios similar to their actual
situation. They cannot obtain such guidance from individual protocol situation. They cannot obtain such guidance from individual protocol
specifications developed by the IETF, so there is a need for specifications developed by the IETF, so there is a need for
additional documents. additional documents.
This draft is maintained as a "living document" of the V6OPS WG,
because it is not considered necessary to archive it as an RFC.
2. Document Topics 2. Document Topics
On the assumption that a series of documents are produced describing On the assumption that a series of documents are produced describing
and recommending transition scenarios, there are two basic and recommending transition scenarios, there are two basic
conditions: conditions:
1. The documents will not be primary protocol specifications, 1. The documents will not be primary protocol specifications,
because those are the outcome of IETF working groups chartered to because those are the outcome of IETF working groups chartered to
work on specific protocol mechanisms. work on specific protocol mechanisms.
2. The documents are addressed to service providers who have taken 2. The documents are addressed to service providers who have taken
the decision to support IPv6, have acquired basic knowledge and the decision to support IPv6, have acquired basic knowledge and
skipping to change at page 5, line 47 skipping to change at page 5, line 47
5. Acknowledgements 5. Acknowledgements
Useful comments and contributions were made by Randy Bush and other Useful comments and contributions were made by Randy Bush and other
members of the V6OPS WG. members of the V6OPS WG.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
6. Change log 6. Change log
draft-ietf-v6ops-v4v6tran-framework-02: updated as living document
for WG, 2011-07-26
draft-ietf-v6ops-v4v6tran-framework-01: small addition following draft-ietf-v6ops-v4v6tran-framework-01: small addition following
WGLC, 2011-02-02 WGLC, 2011-02-02
draft-ietf-v6ops-v4v6tran-framework-00: adopted by WG at IETF 79, draft-ietf-v6ops-v4v6tran-framework-00: adopted by WG at IETF 79,
2010-12-01 2010-12-01
draft-carpenter-v4v6tran-framework-00: original version, 2010-08-18 draft-carpenter-v4v6tran-framework-00: original version, 2010-08-18
7. Informative References 7. Informative References
[I-D.arkko-ipv6-transition-guidelines]
Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment",
draft-arkko-ipv6-transition-guidelines-14 (work in
progress), December 2010.
[I-D.ietf-6man-node-req-bis] [I-D.ietf-6man-node-req-bis]
Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements RFC 4294-bis", Requirements", draft-ietf-6man-node-req-bis-11 (work in
draft-ietf-6man-node-req-bis-07 (work in progress), progress), May 2011.
December 2010.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6 into Savola, "Scenarios and Analysis for Introducing IPv6 into
ISP Networks", RFC 4029, March 2005. ISP Networks", RFC 4029, March 2005.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006. April 2006.
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211,
July 2008. July 2008.
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider
Scenarios for IPv6 Deployment", RFC 6036, October 2010. Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment", RFC 6180,
May 2011.
Authors' Addresses Authors' Addresses
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland, 1142 Auckland, 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Building, No.3 Xinxi Rd., Huawei Building, No.3 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing Shang-Di Information Industry Base, Hai-Dian District, Beijing
P.R. China P.R. China
Email: shengjiang@huawei.com Email: jiangsheng@huawei.com
Victor Kuarsingh Victor Kuarsingh
Rogers Communications Rogers Communications
Canada Canada
Email: Victor.Kuarsingh@rci.rogers.com Email: Victor.Kuarsingh@rci.rogers.com
 End of changes. 14 change blocks. 
22 lines changed or deleted 24 lines changed or added

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