draft-ietf-softwire-stateless-4v6-motivation-01.txt   draft-ietf-softwire-stateless-4v6-motivation-02.txt 
softwire M. Boucadair, Ed. Softwires Working Group M. Boucadair, Ed.
Internet-Draft France Telecom Internet-Draft France Telecom
Intended status: Informational S. Matsushima Intended status: Informational S. Matsushima
Expires: August 13, 2012 Softbank Telecom Expires: December 14, 2012 Softbank Telecom
Y. Lee Y. Lee
Comcast Comcast
O. Bonness O. Bonness
Deutsche Telekom Deutsche Telekom
I. Borges I. Borges
Portugal Telecom Portugal Telecom
G. Chen G. Chen
China Mobile China Mobile
February 10, 2012 June 12, 2012
Motivations for Stateless IPv4 over IPv6 Migration Solutions Motivations for Carrier-side Stateless IPv4 over IPv6 Migration
draft-ietf-softwire-stateless-4v6-motivation-01 Solutions
draft-ietf-softwire-stateless-4v6-motivation-02
Abstract Abstract
IPv4 service continuity is one of the most pressing problems that IPv4 service continuity is one of the most pressing problems that
must be resolved by Service Providers during the IPv6 transition must be resolved by Service Providers during the IPv6 transition
period - especially after the exhaustion of the public IPv4 address period - especially after the exhaustion of the public IPv4 address
space. Current standardization effort that addresses IPv4 service space. Current standardization effort that addresses IPv4 service
continuity focuses on stateful mechanisms. This document elaborates continuity focuses on stateful mechanisms. This document elaborates
on the motivations for the need to undertake a companion effort to on the motivations for the need to undertake a companion effort to
specify stateless IPv4 over IPv6 approaches. specify stateless IPv4 over IPv6 approaches.
skipping to change at page 1, line 45 skipping to change at page 1, line 46
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 13, 2012. This Internet-Draft will expire on December 14, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 25 skipping to change at page 2, line 25
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Why Stateless IPv4 over IPv6 Solutions are Needed? . . . . . . 4 3. Why Stateless IPv4 over IPv6 Solutions are Needed? . . . . . . 4
3.1. Network Architecture Simplification . . . . . . . . . . . 5 3.1. Network Architecture Simplification . . . . . . . . . . . 5
3.1.1. Network Dimensioning . . . . . . . . . . . . . . . . . 5 3.1.1. Network Dimensioning . . . . . . . . . . . . . . . . . 5
3.1.2. No Intra-domain Constraint . . . . . . . . . . . . . . 5 3.1.2. No Intra-domain Constraint . . . . . . . . . . . . . . 5
3.1.3. Logging - No Need for Dynamic Binding Notifications . 5 3.1.3. Logging - No Need for Dynamic Binding Notifications . 6
3.1.4. No Additional Protocol for Port Control is Required . 6 3.1.4. No Additional Protocol for Port Control is Required . 6
3.2. Operational Tasks and Network Maintenance Efficiency . . . 6 3.2. Operational Tasks and Network Maintenance Efficiency . . . 6
3.2.1. Preserve Current Practices . . . . . . . . . . . . . . 6 3.2.1. Preserve Current Practices . . . . . . . . . . . . . . 6
3.2.2. Planned Maintenance Operations . . . . . . . . . . . . 7 3.2.2. Planned Maintenance Operations . . . . . . . . . . . . 7
3.2.3. Reliability and Robustness . . . . . . . . . . . . . . 7 3.2.3. Reliability and Robustness . . . . . . . . . . . . . . 7
3.2.4. Support of Multi-Vendor Redundancy . . . . . . . . . . 7 3.2.4. Support of Multi-Vendor Redundancy . . . . . . . . . . 7
3.2.5. Simplification of Qualification Procedures . . . . . . 7 3.2.5. Simplification of Qualification Procedures . . . . . . 7
3.3. Facilitating Service Evolution . . . . . . . . . . . . . . 8 3.3. Facilitating Service Evolution . . . . . . . . . . . . . . 8
3.3.1. Implicit Host Identification . . . . . . . . . . . . . 8 3.3.1. Implicit Host Identification . . . . . . . . . . . . . 8
3.3.2. No Organizational Impact . . . . . . . . . . . . . . . 8 3.3.2. No Organizational Impact . . . . . . . . . . . . . . . 9
3.4. Cost Minimization Opportunities . . . . . . . . . . . . . 9 3.4. Cost Minimization Opportunities . . . . . . . . . . . . . 9
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Dependency Between IPv4 and IPv6 Address Assignments . . . 10 4.1. Dependency Between IPv4 and IPv6 Address Assignments . . . 10
4.2. IPv4 Port Utilisation Efficiency . . . . . . . . . . . . . 11 4.2. IPv4 Port Utilisation Efficiency . . . . . . . . . . . . . 11
4.3. IPv4 Port Randomization . . . . . . . . . . . . . . . . . 11 4.3. IPv4 Port Randomization . . . . . . . . . . . . . . . . . 11
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 31 skipping to change at page 3, line 31
complex process for all Service Providers. There is nothing like a complex process for all Service Providers. There is nothing like a
"One size fits all" solution or one target architecture that would "One size fits all" solution or one target architecture that would
work for all situations. Each Service Provider has to take into work for all situations. Each Service Provider has to take into
account its own context (e.g., service infrastructures), policies and account its own context (e.g., service infrastructures), policies and
marketing strategy (a document that informs Service Providers about marketing strategy (a document that informs Service Providers about
the impact of the IPv4 address shortage, and provides some the impact of the IPv4 address shortage, and provides some
recommendations and guidelines, is available at [EURESCOM]). recommendations and guidelines, is available at [EURESCOM]).
Current standardization effort that is meant to address this IPv4 Current standardization effort that is meant to address this IPv4
service continuity issue focuses mainly on stateful mechanisms that service continuity issue focuses mainly on stateful mechanisms that
assume the sharing of any global IPv4 address that is left between sharing of global IPv4 addresses between Customers is based upon the
several customers, based upon the deployment of NAT (Network Address deployment of NAT (Network Address Translation) capabilities in the
Translation) capabilities in the network. Because of some caveats of network. Because of some caveats of such stateful approaches the
such stateful approaches the Service Provider community feels that a Service Provider community feels that a companion effort is required
companion effort is required to specify stateless IPv4 over IPv6 to specify stateless IPv4 over IPv6 approaches. Note that the
approaches. This document provides elaboration on such need. stateless solution elaborated in this document focuses on the
carrier-side stateless IPv4 over IPv6 solution. States may still
exist in other equipments such as customer premises equipment.
This document provides elaboration on the need for carrier-side
stateless IPv4 over IPv6 solution.
More discussions about stateless vs. stateful can be found at More discussions about stateless vs. stateful can be found at
[RFC6144]. [RFC6144].
2. Terminology 2. Terminology
This document makes use of the following terms: This document makes use of the following terms:
State: as used in [RFC1958]. State: as used in [RFC1958].
skipping to change at page 13, line 34 skipping to change at page 13, line 34
9. Acknowledgments 9. Acknowledgments
Many thanks to the following individuals who provided valuable Many thanks to the following individuals who provided valuable
comments: comments:
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| X. Deng | W. Dec | D. Wing | A. Baudot | | X. Deng | W. Dec | D. Wing | A. Baudot |
| E. Burgey | L. Cittadini | R. Despres | J. Zorz | | E. Burgey | L. Cittadini | R. Despres | J. Zorz |
| M. Townsley | L. Meillarec | R. Maglione | J. Queiroz | | M. Townsley | L. Meillarec | R. Maglione | J. Queiroz |
| C. Xie | X. Li | O. Troan | J. Qin | | C. Xie | X. Li | O. Troan | J. Qin |
| B. Sarikaya | N. Skoberne | J. Arkko | | | B. Sarikaya | N. Skoberne | J. Arkko | D. Lui |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Special thanks to W. Dec who provided a summary of the motivation Special thanks to W. Dec who provided a summary of the motivation
items. items.
10. Informative References 10. Informative References
[EURESCOM] [EURESCOM]
Levis, P., Borges, I., Bonness, O. and L. Dillon L., "IPv4 Levis, P., Borges, I., Bonness, O. and L. Dillon L., "IPv4
address exhaustion: Issues and Solutions for Service address exhaustion: Issues and Solutions for Service
Providers", March 2010, <http://archive.eurescom.eu/~pub/ Providers", March 2010, <http://archive.eurescom.eu/~pub/
deliverables/documents/P1900-series/P1952/D2bis/ deliverables/documents/P1900-series/P1952/D2bis/
P1952-D2bis.pdf>. P1952-D2bis.pdf>.
[I-D.ietf-behave-lsn-requirements] [I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for Carrier Grade NATs and H. Ashida, "Common requirements for Carrier Grade NATs
(CGNs)", draft-ietf-behave-lsn-requirements-05 (work in (CGNs)", draft-ietf-behave-lsn-requirements-06 (work in
progress), November 2011. progress), May 2012.
[I-D.ietf-intarea-nat-reveal-analysis] [I-D.ietf-intarea-nat-reveal-analysis]
Boucadair, M., Touch, J., Levis, P., and R. Penno, Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Solution Candidates to Reveal a Host "Analysis of Solution Candidates to Reveal a Host
Identifier in Shared Address Deployments", Identifier (HOST_ID) in Shared Address Deployments",
draft-ietf-intarea-nat-reveal-analysis-00 (work in draft-ietf-intarea-nat-reveal-analysis-02 (work in
progress), February 2012. progress), April 2012.
[I-D.matsushima-v6ops-transition-experience] [I-D.matsushima-v6ops-transition-experience]
Matsushima, S., Yamazaki, Y., Sun, C., Yamanishi, M., and Matsushima, S., Yamazaki, Y., Sun, C., Yamanishi, M., and
J. Jiao, "Use case and consideration experiences of IPv4 J. Jiao, "Use case and consideration experiences of IPv4
to IPv6 transition", to IPv6 transition",
draft-matsushima-v6ops-transition-experience-02 (work in draft-matsushima-v6ops-transition-experience-02 (work in
progress), March 2011. progress), March 2011.
[I-D.vixie-dnsext-dns0x20] [I-D.vixie-dnsext-dns0x20]
Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to
 End of changes. 11 change blocks. 
20 lines changed or deleted 26 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/