Dumb question. There were at least a couple of comments early in the thread about “we should have an ID that says this”. I hacked one together, basically an updated version of the email.
(1) are we interested enough to actually have a draft, or does it just seem cute? (2) if we’re interested enough to have a draft, what working group? (3) if we’re interested enough to have a draft, it seems to me that I should have 1-3 co-authors, from SP, enterprise, and perhaps CDN environments, that can comment with some authority about the process and considerations in their environments. I would want the co-authors to add text as they deem it appropriate. See attached.
transition.xml
Description: XML document
IPv6 Operations F. Baker
Internet-Draft Cisco Systems
Intended status: Standards Track March 31, 2015
Expires: October 2, 2015
Ruminations on the IPv4->IPv6 Transition
draft-baker-v6ops-transition-ruminations-00
Abstract
This note present's the author's perspective on the transition.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 2, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Baker Expires October 2, 2015 [Page 1]
Internet-Draft IPv4->IPv6 Transition March 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Transition Technologies: IPv4 as a Service . . . . . . . . . 3
3. Steps in the transition . . . . . . . . . . . . . . . . . . . 4
3.1. IPv4-only network . . . . . . . . . . . . . . . . . . . . 4
3.2. IPv4 with scattered IPv6 experiments . . . . . . . . . . 4
3.3. IPv4+non-native IPv6, translated or overlay (e.g., as a
service) . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. IPv4+IPv6 native dual stack network . . . . . . . . . . . 4
3.5. IPv6+non-native IPv4, translated or overlay (e.g., as a
service) . . . . . . . . . . . . . . . . . . . . . . . . 4
3.6. IPv6 with scattered legacy IPv4 . . . . . . . . . . . . . 5
3.7. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Ruminations . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
9. Informative References . . . . . . . . . . . . . . . . . . . 5
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Seven years after its writing, the Basic Transition Mechanisms for
IPv6 Hosts and Routers [RFC4213], seems a little naive. The model
proposed was that the Internet, and any of its component networks,
would go through three essential phases:
1. IPv4-only network
2. IPv4+IPv6 Dual Stack network
3. IPv6-only Network
In fairness, the authors were trying to describe the transition in
broad terms, so the naivete is excusable. However, reality appears
to be more like:
1. IPv4-only network
2. IPv4 with lab experiments or isolated IPv6 networks without
IPv6-capable services
3. IPv4 with in some combination of overlay and native IPv6
deployment
Baker Expires October 2, 2015 [Page 2]
Internet-Draft IPv4->IPv6 Transition March 2015
4. IPv4+IPv6 (native) dual stack network
5. IPv6+IPv4 non-native, translated or overlay (e.g., as a service)
6. IPv6 with little bits of IPv4 here and there
7. IPv6-only
Even that is to some extent naive; only the smallest of networks can
change overnight. Real networks change in a piecemeal fashion. So
in a network that is somewhere in the process of transition probably
has components in each of those phases.
2. Transition Technologies: IPv4 as a Service
There are a variety of transition technologies available in either
commerical or open source implementation. The following is a fairly
comprehensive list, but may be partial.
o 464XLAT: Combination of Stateful and Stateless Translation
[RFC6877]
o Translation between IPv4 and a configured native IPv6 address
([I-D.ietf-v6ops-siit-dc] [I-D.ietf-v6ops-siit-dc-2xlat]
[I-D.anderson-v6ops-siit-eam])
o Mapping of Address and Port with Encapsulation (MAP)
[I-D.ietf-softwire-map]
o Mapping of Address and Port using Double Translation (MAP-T)
[I-D.ietf-softwire-map-t]
o Stateless Single Translation to an IPv4-embedded IPv6 Address
([RFC6145])
o Stateful Single Translation to an IPv6 Address ([RFC6146])
o Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
[RFC6333]
o Lightweight 4over6: An Extension to the DS-Lite Architecture
[I-D.ietf-softwire-lw4over6]
o LISP (4 over 6, [I-D.ietf-lisp-introduction])
Baker Expires October 2, 2015 [Page 3]
Internet-Draft IPv4->IPv6 Transition March 2015
3. Steps in the transition
As noted in Section 1, the network appears to go through about seven
steps or phases.
3.1. IPv4-only network
The first step is the existing IPv4 Internet.
3.2. IPv4 with scattered IPv6 experiments
With the publication of the original IPv6 Specification [RFC1883],
and especially with its successor [RFC2460], researchers started
learning about the technology. On March 30 1995, they set up the
first interconnection between two independent IPv6 implementations,
between sipper.pa-x.dec.com and ottawa.inria.fr. Several academic
and research networks such as Renater, HEANET, and Internet2,
deployed the technology in a trial mode.
Many networks continue to kick the tires, lacking a business
requirement to go to the next step.
3.3. IPv4+non-native IPv6, translated or overlay (e.g., as a service)
The third phase is wider trial deployment. This often involves IPv6/
IPv4 tunnels, local network deployment, 6rd [RFC5569], or ISATAP
[RFC5214].
3.4. IPv4+IPv6 native dual stack network
The fourth step is Dual Stack deployment. This calls for careful
definition, as there are cheap versions that stop at "we turned them
both on, but of course IPv4 is the one we depend on". In a Dual
Stack deployment, either protocol is useful and usable for any
purpose; it is feasible to turn IPv4 off for any supported service.
It is retained because of specific applications, equipment, or
constituencies that would object.
3.5. IPv6+non-native IPv4, translated or overlay (e.g., as a service)
The network begins to overcome the objections, and turn IPv4 off for
some set of equipment or applications. Content exists that must be
reached on IPv4-only networks including the general Internet, and not
all services within the network may be fully IPv6-capable. For that
reason, IPv4 must be maintained. But to reduce costs or to manage
the shrinking IPv4 address space, IPv4 is carried via translation or
encapsulation, using technologies such as those mentioned in
Section 2.
Baker Expires October 2, 2015 [Page 4]
Internet-Draft IPv4->IPv6 Transition March 2015
3.6. IPv6 with scattered legacy IPv4
As IPv6 proves viable, the overlay or translation system gets turned
off. At this point, IPv4 assumes a legacy status, comparable to
AppleTalk or DECNet.
3.7. IPv6-only
IPv4 has been turned off everywhere. It is cold in hell, and some IT
managers are having it pried out of their cold, dead hands.
4. Ruminations
The steps in Section 3 fall broadly into three groups: IPv4 networks,
perhaps with some toys, IPv6 networks with mitigations for issues
related to IPv4, and the Dual Stack Network. What may not be obvious
is that the transition from IPv4 with trial IPv6 deployment
(Section 3.3) to IPv6 with legacy IPv4 deployment (Section 3.6) has a
choice: one can go through Dual Stack (Section 3.4) or Simulated Dual
Stack (Section 3.5) phases, but there is no need to go through both.
Dual Stack will be easier, in the sense that for an instant both
technologies are feasible and then IPv4 is turned off. However, it
may be more expensive. We are beginning to see networks opt for IPv6
with an IPv4 translation or overlay, whatever problems that may
bring.
5. IANA Considerations
This memo asks the IANA for no new parameters.
6. Security Considerations
What - are my insecurities showing?
7. Privacy Considerations
Privacy was not considered in the writing of this memo.
8. Acknowledgements
9. Informative References
[I-D.anderson-v6ops-siit-eam]
tore, t., "Explicit Address Mappings for Stateless IP/ICMP
Translation", draft-anderson-v6ops-siit-eam-03 (work in
progress), January 2015.
Baker Expires October 2, 2015 [Page 5]
Internet-Draft IPv4->IPv6 Transition March 2015
[I-D.ietf-lisp-introduction]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Introduction to the Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-introduction-12 (work in
progress), February 2015.
[I-D.ietf-softwire-lw4over6]
Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
I. Farrer, "Lightweight 4over6: An Extension to the DS-
Lite Architecture", draft-ietf-softwire-lw4over6-13 (work
in progress), November 2014.
[I-D.ietf-softwire-map-t]
Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", draft-ietf-softwire-map-t-08 (work
in progress), December 2014.
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-12
(work in progress), November 2014.
[I-D.ietf-v6ops-siit-dc-2xlat]
tore, t., "SIIT-DC: Dual Translation Mode", draft-ietf-
v6ops-siit-dc-2xlat-00 (work in progress), January 2015.
[I-D.ietf-v6ops-siit-dc]
tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6
Data Centre Environments", draft-ietf-v6ops-siit-dc-00
(work in progress), December 2014.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010.
Baker Expires October 2, 2015 [Page 6]
Internet-Draft IPv4->IPv6 Transition March 2015
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC
6877, April 2013.
Appendix A. Change Log
Initial Version: April 2015
Author's Address
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: [email protected]
Baker Expires October 2, 2015 [Page 7]
Title: Ruminations on the IPv4->IPv6 Transition
| IPv6 Operations | F. Baker |
| Internet-Draft | Cisco Systems |
| Intended status: Standards Track | March 31, 2015 |
| Expires: October 2, 2015 |
Ruminations on the IPv4->IPv6 Transition
draft-baker-v6ops-transition-ruminations-00
Abstract
This note present's the author's perspective on the transition.
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 2, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
- 1. Introduction
- 2. Transition Technologies: IPv4 as a Service
- 3. Steps in the transition
- 3.1. IPv4-only network
- 3.2. IPv4 with scattered IPv6 experiments
- 3.3. IPv4+non-native IPv6, translated or overlay (e.g., as a service)
- 3.4. IPv4+IPv6 native dual stack network
- 3.5. IPv6+non-native IPv4, translated or overlay (e.g., as a service)
- 3.6. IPv6 with scattered legacy IPv4
- 3.7. IPv6-only
- 4. Ruminations
- 5. IANA Considerations
- 6. Security Considerations
- 7. Privacy Considerations
- 8. Acknowledgements
- 9. Informative References
- Appendix A. Change Log
- Author's Address
1. Introduction
Seven years after its writing, the Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213], seems a little naive. The model proposed was that the Internet, and any of its component networks, would go through three essential phases:
- IPv4-only network
- IPv4+IPv6 Dual Stack network
- IPv6-only Network
In fairness, the authors were trying to describe the transition in broad terms, so the naiveté is excusable. However, reality appears to be more like:
- IPv4-only network
- IPv4 with lab experiments or isolated IPv6 networks without IPv6-capable services
- IPv4 with in some combination of overlay and native IPv6 deployment
- IPv4+IPv6 (native) dual stack network
- IPv6+IPv4 non-native, translated or overlay (e.g., as a service)
- IPv6 with little bits of IPv4 here and there
- IPv6-only
Even that is to some extent naive; only the smallest of networks can change overnight. Real networks change in a piecemeal fashion. So in a network that is somewhere in the process of transition probably has components in each of those phases.
2. Transition Technologies: IPv4 as a Service
There are a variety of transition technologies available in either commerical or open source implementation. The following is a fairly comprehensive list, but may be partial.
- 464XLAT: Combination of Stateful and Stateless Translation [RFC6877]
- Translation between IPv4 and a configured native IPv6 address ([I-D.ietf-v6ops-siit-dc] [I-D.ietf-v6ops-siit-dc-2xlat] [I-D.anderson-v6ops-siit-eam])
- Mapping of Address and Port with Encapsulation (MAP) [I-D.ietf-softwire-map]
- Mapping of Address and Port using Double Translation (MAP-T) [I-D.ietf-softwire-map-t]
- Stateless Single Translation to an IPv4-embedded IPv6 Address ([RFC6145])
- Stateful Single Translation to an IPv6 Address ([RFC6146])
- Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [RFC6333]
- Lightweight 4over6: An Extension to the DS-Lite Architecture [I-D.ietf-softwire-lw4over6]
- LISP (4 over 6, [I-D.ietf-lisp-introduction])
3. Steps in the transition
As noted in Section 1, the network appears to go through about seven steps or phases.
3.1. IPv4-only network
The first step is the existing IPv4 Internet.
3.2. IPv4 with scattered IPv6 experiments
With the publication of the original IPv6 Specification [RFC1883], and especially with its successor [RFC2460], researchers started learning about the technology. On March 30 1995, they set up the first interconnection between two independent IPv6 implementations, between sipper.pa-x.dec.com and ottawa.inria.fr. Several academic and research networks such as Renater, HEANET, and Internet2, deployed the technology in a trial mode.
Many networks continue to kick the tires, lacking a business requirement to go to the next step.
3.3. IPv4+non-native IPv6, translated or overlay (e.g., as a service)
The third phase is wider trial deployment. This often involves IPv6/IPv4 tunnels, local network deployment, 6rd [RFC5569], or ISATAP [RFC5214].
3.4. IPv4+IPv6 native dual stack network
The fourth step is Dual Stack deployment. This calls for careful definition, as there are cheap versions that stop at "we turned them both on, but of course IPv4 is the one we depend on". In a Dual Stack deployment, either protocol is useful and usable for any purpose; it is feasible to turn IPv4 off for any supported service. It is retained because of specific applications, equipment, or constituencies that would object.
3.5. IPv6+non-native IPv4, translated or overlay (e.g., as a service)
The network begins to overcome the objections, and turn IPv4 off for some set of equipment or applications. Content exists that must be reached on IPv4-only networks including the general Internet, and not all services within the network may be fully IPv6-capable. For that reason, IPv4 must be maintained. But to reduce costs or to manage the shrinking IPv4 address space, IPv4 is carried via translation or encapsulation, using technologies such as those mentioned in Section 2.
3.6. IPv6 with scattered legacy IPv4
As IPv6 proves viable, the overlay or translation system gets turned off. At this point, IPv4 assumes a legacy status, comparable to AppleTalk or DECNet.
3.7. IPv6-only
IPv4 has been turned off everywhere. It is cold in hell, and some IT managers are having it pried out of their cold, dead hands.
4. Ruminations
The steps in Section 3 fall broadly into three groups: IPv4 networks, perhaps with some toys, IPv6 networks with mitigations for issues related to IPv4, and the Dual Stack Network. What may not be obvious is that the transition from IPv4 with trial IPv6 deployment [step3] to IPv6 with legacy IPv4 deployment [step6] has a choice: one can go through Dual Stack [step4] or Simulated Dual Stack [step5] phases, but there is no need to go through both. Dual Stack will be easier, in the sense that for an instant both technologies are feasible and then IPv4 is turned off. However, it may be more expensive. We are beginning to see networks opt for IPv6 with an IPv4 translation or overlay, whatever problems that may bring.
5. IANA Considerations
This memo asks the IANA for no new parameters.
6. Security Considerations
What - are my insecurities showing?
7. Privacy Considerations
Privacy was not considered in the writing of this memo.
8. Acknowledgements
9. Informative References
Appendix A. Change Log
- Initial Version:
- April 2015
Author's Address
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
