Internet DRAFT - draft-baker-v6ops-end2end
draft-baker-v6ops-end2end
IPv6 Operations F. Baker
Internet-Draft Cisco Systems
Expires: February 13, 2006 August 12, 2005
The End to End Problem in a fully generalized IPv4, IPv6, and IPv4+IPv6
network
draft-baker-v6ops-end2end-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 13, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This note is intended to describe the end to end problem as it
applies to a network of networks, wherein some component networks
independently run only IPv4 with or without a transition mechanism,
some run only IPv6 with or without a transition mechanism and without
coordination of transition mechanisms, and some run IPv4 and IPv6 in
parallel supporting native routing.
Baker Expires February 13, 2006 [Page 1]
Internet-Draft The End to End Problem in Transition August 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transition, and transition problems . . . . . . . . . . . . . 4
2.1 A provably correct transition plan . . . . . . . . . . . . 4
2.2 The IPv4 rendezvous problem . . . . . . . . . . . . . . . 6
2.3 The IPv6 rendezvous problem . . . . . . . . . . . . . . . 6
2.4 And then there is multicast... . . . . . . . . . . . . . . 7
3. End to end arguments in transition design . . . . . . . . . . 8
3.1 The end to end problem in IPv6 over or in IPv4 . . . . . . 8
3.2 The end to end problem in IPv4 over or in IPv6 . . . . . . 9
3.3 Mutual encapsulation considered bizarre . . . . . . . . . 10
4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1 Normative References . . . . . . . . . . . . . . . . . . . 16
8.2 Informative References . . . . . . . . . . . . . . . . . . 16
8.3 More Informative References . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20
A. Requirements for a general transition strategy . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 23
Baker Expires February 13, 2006 [Page 2]
Internet-Draft The End to End Problem in Transition August 2005
1. Introduction
This note is intended to describe the end to end problem as it
applies to a network of networks, wherein some component networks
independently run only IPv4 with or without a transition mechanism,
some run only IPv6 with or without a transition mechanism and without
coordination of transition mechanisms, and some run IPv4 and IPv6 in
parallel supporting native routing. This is to say that the IETF
recommendations in [RFC2893] and [RFC4029] are not necessarily
implemented during IPv6 deployment, and this creates issues for the
Internet as a whole.
[RFC1958] states that
Many members of the Internet community would argue that there is
no architecture, but only a tradition, which was not written
down for the first 25 years (or at least not by the IAB).
However, in very general terms, the community believes that the
goal is connectivity, the tool is the Internet Protocol, and the
intelligence is end to end rather than hidden in the network.
The current exponential growth of the network seems to show that
connectivity is its own reward, and is more valuable than any
individual application such as mail or the World-Wide Web. This
connectivity requires technical cooperation between service
providers, and flourishes in the increasingly liberal and
competitive commercial telecommunications environment.
The key to global connectivity is the inter-networking layer.
The key to exploiting this layer over diverse hardware providing
global connectivity is the "end to end argument".
This note starts from those key observations, including the End to
End Argument (which will be spelled out in Section 3), and raises a
very deep concern about the wild proliferation of mutually
incompatible transition strategies with little or no useful guidance
from the networking community.
Baker Expires February 13, 2006 [Page 3]
Internet-Draft The End to End Problem in Transition August 2005
2. Transition, and transition problems
Much has been written about possible transition scenarios, and about
the transition from an IPv4 to an IPv6 Internet. [RFC2185], which is
somewhat dated, comments on the Routing Aspects of the transition.
[RFC2893] proposes basic Transition Mechanisms. [RFC3574] comments
on the Transition Scenarios for 3GPP Networks. [RFC3750] looks at
unmanaged networks, and [RFC3904] evaluates that approach. [RFC4038]
comments on the application issues. Numerous other documents look at
specific transition scenarios and propose various ways to translate
between IPv4 and IPv6 in a gateway at the network layer, tunnel IPv4
over IPv6 or IPv6 over IPv4, and rendezvous between systems of either
type over networks running the other.
2.1 A provably correct transition plan
A provably correct algorithm, in mathematical terms, is one for which
a proof can be presented demonstrating that it works without error in
all cases. It is not exclusive: there may also be other algorithms
that work correctly, and the fact may or may not be readily proven.
The IETF's current recommendation, originally proposed in [RFC1933]
and now documented in [RFC2893] is that the best possible transition
mechanism envisions these steps:
1. The basic network runs IPv4 forwarding and routing.
2. IPv6 forwarding and routing is added to that network, either by
tunneling IPv6 over IPv4 or by directly bringing IPv6 forwarding
and routing up in parallel with the IPv4 network.
3. Applications determine whether IPv6 connectivity is available
between them, and if so use it; otherwise, they default to IPv4,
which is presumed to work.
4. A market develops, driving IPv6 deployment to also become
essentially ubiquitous. The key steps in this development
include
* administrations obtaining and deploying IPv6 address space,
perhaps in response to increasingly stringent IPv4 prefix
allocation guidelines or diminishing allocation availability,
* business drivers toward end to end connectivity that are not
readily solved using NAT traversal techniques,
* some edge networks administrations deploying only IPv6, and
Baker Expires February 13, 2006 [Page 4]
Internet-Draft The End to End Problem in Transition August 2005
* other administrations needing to communicate with the IPv6-
only administrations or using IPv6-only applications.
5. At some point in the (very) distant future, IPv6 connectivity is
sufficiently ubiquitous that IPv4 connectivity becomes
unnecessary. At this point, businesses independently remove IPv4
from the network as being no longer useful.
Within a single administration, one could imagine that central IPv4
network being instead an IPv6 network with IPv4 connectivity provided
over it by tunneling. Within a single administration, this is
workable, as the administration is in control of all access to that
network and the basic paradigm is preserved (IPv4 connectivity is
ubiquitous and IPv6 connectivity is growing). The key point is that
at the network edge, IPv4 and IPv6 always run natively, providing
robust IPv4 services until IPv6 becomes ubiquitous, and after that
robustly provides IPv6 connectivity, and other transition mechanisms
if used operate within a single administration.
A network connecting IPv6 over an IPv4 core is as shown in Figure 1.
The gateways may be provided by the central network or by its
clients; the key point is that they interoperate.
,---. ,---.
,' `. ,' `.
/ \ / \
/ \ / \
; IPv6+IPv4 : ; IPv4 :
| Network | | Network |
: ; ,---. : ;
\ +----+,' `.+--\ /
\ | GW | \ R \ /
`. ,+----+ \---+`. ,'
'---' : IPv4 : '---'
| Network |
,---. : ; ,---.
,' `.+--\ +----+,' `.
/ \ R \ | GW | \
/ \---+`. ,'+----+ \
; IPv4 : '---' ; IPv6+IPv4 :
| Network | | Network |
: ; : ;
\ / \ /
\ / \ /
`. ,' `. ,'
'---' '---'
Figure 1: An end to end IPv4 network with potential IPv6 connectivity
Baker Expires February 13, 2006 [Page 5]
Internet-Draft The End to End Problem in Transition August 2005
This is not without risk; there is concern in some sectors that
relatively new IPv6 services might destabilize IPv4 services in a
domain. However, it is provably correct. There may or may not be
IPv6 connectivity between any two points in the network, but if the
entire network is running and routing IPv4, there is at minimum IPv4
connectivity.
2.2 The IPv4 rendezvous problem
If static tunneling of IPv6 traffic over an IPv4 infrastructure, such
as the 6bone, is used, routing IPv6 through the tunnels is not hard.
There is a problem in the second step, however, if dynamic tunneling
(or translation) is used; there must be some means for a system on
one side of an IPv4-only domain to determine the ingress and egress
gateways between which to tunnel. The ingress and egress systems
must, of course, interoperate, and must provide a path that gets
traffic between the relevant endpoints. Various approaches have been
suggested, including
o advertising DNS names of end systems with the addresses of
translators between naming domains [RFC2694][RFC2766],
o Automated Tunneling [RFC3056],
o Translating IPv4 addresses to IPv6 addresses in IPv6 routing
[RFC3513] section 2.5.5,
o Tunnel Brokers [I-D.blanchet-v6ops-tunnelbroker-tsp],
o The use of an address server to determine the appropriate egress
gateway address from the ingress gateway or end system[I-D.bound-
dstm-exp],
o The use of an address server to interconnect IPv4 NATs
[I-D.liumin-v6ops-silkroad],
o and a variety of others.
2.3 The IPv6 rendezvous problem
At this point, various administrations are deploying or considering
deploying IPv6-only or what are called "IPv6-dominant" networks. An
IPv6-dominant network is one that internally routes only IPv6 and
perhaps only forwards IPv6, and provides IPv4 services by tunneling
or translation to IPv6. The problem noted in the preceding paragraph
applies equally to such networks; there must be a way to establish
IPv4 routes over the intervening IPv6 network, and if dynamic
Baker Expires February 13, 2006 [Page 6]
Internet-Draft The End to End Problem in Transition August 2005
tunneling is used, there must be a way to dynamically determine the
appropriate ingress and egress gateways.
2.4 And then there is multicast...
There is a saying in IETF circles concerning routing, which is the
issue addressed in this document. "There is a simple test that will
tell whether one understands a given routing problem adequately, and
whether a given solution is adequate to cover the routing issues.
Simply repeat the sentence used to describe the solution using the
word 'Multicast'".
There is need for additional transition work regarding deployment of
IPv6 multicast.
Baker Expires February 13, 2006 [Page 7]
Internet-Draft The End to End Problem in Transition August 2005
3. End to end arguments in transition design
In [Saltzer], Saltzer and Reed discussed a fundamental argument,
which they call the End to End Argument. This has been stated in
many ways, but at its simplest it states that unnecessary complexity
in a network results in side-effects that decrease performance,
reduce functionality, and in the worst case cause the system to fail
in some way. The paper argues that unnecessary network complexity is
to be avoided, leaving maximum flexibility to the end system to
innovate and change. "A satisfactory solution", it could be said,
"contains no unnecessary complexity", and "first, does no harm."
3.1 The end to end problem in IPv6 over or in IPv4
Figure 2 shows a network that has multiple transition strategies for
IPv6 connectivity. Granting that each transition strategy works in
isolation, and therefore the two IPv6 networks connected via
transition strategy A inter-work and the two IPv6 networks connected
via transition strategy B inter-work, it is not obvious that all four
IPv6 networks inter-work.
,---. ,---.
,' `. ,' `.
/ \ / \
/ \ / \
; IPv6+IPv4 : ; IPv6+IPv4 :
| Network | | Network |
: ; ,---. ,---. : ;
\ +----+,' `. ,' `.+----+ /
\ |GW-A| \ / |GW-B| /
`. ,+----+ \ / +----+`. ,'
'---' : IPv4 :: IPv4 : '---'
| Network || Network |
,---. : Transition ;: Transition : ,---.
,' `.+----+ Strategy / \ Strategy +----+,' `.
/ |GW-A| A / \ B |GW-B| \
/ +----+`. ,' `. ,'+----+ \
; IPv6+IPv4 : '---' '---' ; IPv6+IPv4 :
| Network | | Network |
: ; : ;
\ / \ /
\ / \ /
`. ,' `. ,'
'---' '---'
Figure 2: An end to end network with multiple support strategies for
IPv6
Baker Expires February 13, 2006 [Page 8]
Internet-Draft The End to End Problem in Transition August 2005
The problem is, of course, that the transition strategies are not
necessarily compatible. Imagine, for example, that strategy A
depends on routing to distribute the IPv4 addresses of edge dual
stack routers, enabling them to dynamically create tunnels as needed,
while strategy B depends on DNS for this function. While both of the
IPv4 cores are providing IPv6 transition services, neither will
directly interoperate with the other.
If the central IPv4 networks are providing the transition strategy,
they have the opportunity to bridge the two together. The means to
do this is unspecified, however, and may be problematic. In the
example just given, one domain might have to poll all names in the
other domain in order to map the addresses. If the transition
strategies are implemented by the edge networks around the IPv4
domains, however, they will be unaware of the other part of the
network and will not know to translate. For them, the only option is
to provide both transition strategies (BGP NHRP-like extensions *and*
DNS lookups) in their gateways and perform the correct transition for
any given address - which they can only do if they know the
difference between routes from different domains.
In the early stages of the transition plan mentioned in Section 2,
this is perfectly acceptable. During the interval in which IPv6
connectivity is not guaranteed end to end, there is no expectation of
such a guarantee. IPv4 continues to operate end to end, and that is
sufficient during the early stages of the transition.
3.2 The end to end problem in IPv4 over or in IPv6
Figure 3 Addresses the mirror issue raised in Section 2.3. As in
Section 3.1, it shows a network that has multiple transition
strategies for IPv4 connectivity over intervening IPv6 networks.
Granting that each transition strategy works in isolation, and
therefore the two IPv4 networks connected via transition strategy A
inter-work and the two IPv4 networks connected via transition
strategy B inter-work, it is not obvious that all four IPv4 networks
inter-work.
Baker Expires February 13, 2006 [Page 9]
Internet-Draft The End to End Problem in Transition August 2005
,---. ,---.
,' `. ,' `.
/ \ / \
/ \ / \
; IPv6+IPv4 : ; IPv6+IPv4 :
| Network | | Network |
: ; ,---. ,---. : ;
\ +----+,' `. ,' `.+----+ /
\ |GW-A| \ / |GW-B| /
`. ,+----+ \ / +----+`. ,'
'---' : IPv6 :: IPv6 : '---'
| Network || Network |
,---. : Transition ;: Transition : ,---.
,' `.+----+ Strategy / \ Strategy +----+,' `.
/ |GW-A| A / \ B |GW-B| \
/ +----+`. ,' `. ,'+----+ \
; IPv6+IPv4 : '---' '---' ; IPv6+IPv4 :
| Network | | Network |
: ; : ;
\ / \ /
\ / \ /
`. ,' `. ,'
'---' '---'
Figure 3: An end to end network with multiple support strategies for
IPv4
Once again, the transition strategies are not necessarily compatible.
If, for example, strategy A depends on a tunnel server between IPv4
NATs around an IPv6 core, and strategy B depends on distribution of
the IPv6 address of the gateway in BGP, IPv4 connectivity across the
combined IPv6 domains will be problematic.
In the final stages of the transition plan mentioned in Section 2,
this is perfectly acceptable. At the point where IPv4 support
becomes a lower business priority, IPv6 connectivity is presumed to
exist end to end, and there is no longer a need, and therefore no
continuing expectation, of such a guarantee. IPv6 continues to
operate end to end, and that is sufficient during the final stages of
the transition.
3.3 Mutual encapsulation considered bizarre
Figure 4 shows the network this author greatly fears that we are in
the process of building. It combines the worst parts of Section 3.1
with the worst effects of Section 3.2, resulting in a network in
which neither IPv4 nor IPv6 connectivity is guaranteed between any
two points.
Baker Expires February 13, 2006 [Page 10]
Internet-Draft The End to End Problem in Transition August 2005
,---. ,---.
/ \ / \
/ \ / \
; IPv4+6 : ; IPv4+6 :
| Network | | Network |
: +----+---. ,---. ,---. ,---+----+ ;
\ |GW-A| \ / \ / \ / |GW-D| /
\ +----+ +----+ \ / +----+ +----+ /
`---' ; IPv6 |GW-B| IPv4 : ; IPv4 |GW-C| IPv6 : `---'
| Network+----+Network | | Network----+Network |
,---. :Transition :Transition :Transition :Transition ,---.
/ +----+A / \ B / \ C / \ D+----+ \
/ |GW-A| / \ / \ / \ |GW-D| \
; IPv4+6+----+--' `---' `---' `--+----+IPv4+6 :
| Network | | Network |
: ; : ;
\ / \ /
\ / \ /
`---' `---'
Figure 4: An end to end network with multiple transition strategies
The problem is that there is a continuing requirement for some form
of connectivity, whether IPv4 or IPv6, but neither can be guaranteed
in such a network.
The trap here is local optimizations for what some might consider to
be an isolated network. While each individual local optimization may
work in isolation, there is no guarantee that the network of networks
it uses as its context works, and therefore its connectivity or the
connectivity of others may be limited by the choices it makes.
Baker Expires February 13, 2006 [Page 11]
Internet-Draft The End to End Problem in Transition August 2005
4. Recommendation
In the opinion of this writer, Section 2 provably works despite the
kinds of problems raised in Section 3.1 or Section 3.2. The problems
those sections raise result from the complexities in the network
related to the transition strategies in use, which from the
perspective of the argument in [Saltzer] are unnecessary complexities
that result in a failure of the network to deliver connectivity. The
problems that extra complexity causes are acceptable only because
connectivity is in fact guaranteed in another way.
In comparison, Section 3.3 provably fails to guarantee connectivity
by either IPv4 or IPv6. The "unnecessary complexities" tolerated by
Section 3.1 overwhelm the network to cause utter connectivity
failure. As a result, although "current exponential growth of the
network seems to show that connectivity is its own reward, and is
more valuable than any individual application such as mail or the
World-Wide Web", the network we are well on our way to creating fails
to deliver that fundamental characteristic. This transition non-
plan, through negligence, fails the "do no harm" test.
In the mind of this writer, therefore, the scenarios contemplated in
Section 3 are to be avoided at all costs. Rather than allowing a
proliferation of incompatible transition approaches, the IETF must
recommend a provably correct transition approach that supports
Section 2 throughout each of its steps.
Baker Expires February 13, 2006 [Page 12]
Internet-Draft The End to End Problem in Transition August 2005
5. IANA Considerations
This memo adds no new IANA considerations.
Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during
the RFC publication process. From the author's perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's
discretion.
Baker Expires February 13, 2006 [Page 13]
Internet-Draft The End to End Problem in Transition August 2005
6. Security Considerations
One could view the problem analysis that is at the heart of this
document as a security consideration. In any event, the document
does not create new problems. It points out a set of problems that
already exist.
Baker Expires February 13, 2006 [Page 14]
Internet-Draft The End to End Problem in Transition August 2005
7. Acknowledgements
Detailed comments were received from Dave Green, Dave Ward, Pekka
Savola, Ralph Droms, Steve Klynsma, Stig Venaas, and Tim Chown. Dave
Green suggested the text found in Appendix A.
Baker Expires February 13, 2006 [Page 15]
Internet-Draft The End to End Problem in Transition August 2005
8. References
8.1 Normative References
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2185] Callon, R. and D. Haskin, "Routing Aspects Of IPv6
Transition", RFC 2185, September 1997.
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000.
[Saltzer] Saltzer, JH. and DP. Reed, "End-to-end arguments in system
design", ACM Transactions on Computer Systems (TOCS) v.2
n.4, p277-288, Nov 1984.
8.2 Informative References
[I-D.blanchet-v6ops-tunnelbroker-tsp]
Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the
Tunnel Setup Protocol (TSP)",
draft-blanchet-v6ops-tunnelbroker-tsp-02 (work in
progress), May 2005.
[I-D.bound-dstm-exp]
Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism
(DSTM)", draft-bound-dstm-exp-03 (work in progress),
July 2005.
[I-D.liumin-v6ops-silkroad]
Min, L., "Tunneling IPv6 with private IPv4 addresses
through NAT devices", draft-liumin-v6ops-silkroad-03 (work
in progress), July 2005.
[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A.
Heffernan, "DNS extensions to Network Address Translators
(DNS_ALG)", RFC 2694, September 1999.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
Baker Expires February 13, 2006 [Page 16]
Internet-Draft The End to End Problem in Transition August 2005
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks",
RFC 3574, August 2003.
[RFC3750] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Unmanaged Networks IPv6 Transition Scenarios",
RFC 3750, April 2004.
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Evaluation of IPv6 Transition Mechanisms for
Unmanaged Networks", RFC 3904, September 2004.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6 into
ISP Networks", RFC 4029, March 2005.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
8.3 More Informative References
[I-D.despres-v6ops-transition-v5roadmap]
Despres, R., "The v5 Approach for the Transition from IPv4
to IPv6", draft-despres-v6ops-transition-v5roadmap-00
(work in progress), July 2005.
[I-D.huitema-v6ops-teredo]
Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", draft-huitema-v6ops-teredo-05 (work in progress),
April 2005.
[I-D.ietf-v6ops-3gpp-analysis]
Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
progress), October 2004.
[I-D.ietf-v6ops-ent-analysis]
Bound, J., "IPv6 Enterprise Network Analysis",
draft-ietf-v6ops-ent-analysis-03 (work in progress),
July 2005.
[I-D.ietf-v6ops-ipsec-tunnels]
Savola, P., "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
draft-ietf-v6ops-ipsec-tunnels-00 (work in progress),
July 2005.
Baker Expires February 13, 2006 [Page 17]
Internet-Draft The End to End Problem in Transition August 2005
[I-D.ietf-v6ops-mech-v2]
Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07
(work in progress), March 2005.
[I-D.ietf-v6ops-natpt-to-exprmntl]
Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work
in progress), July 2005.
[I-D.jaehwoon-dstm-multitep]
Lee, J., "Multiple TEP Extension to DSTM",
draft-jaehwoon-dstm-multitep-02 (work in progress),
July 2005.
[I-D.lee-v6ops-natpt-mobility]
Shin, M. and J. Lee, "Considerations for Mobility Support
in NAT-PT", draft-lee-v6ops-natpt-mobility-01 (work in
progress), July 2005.
[I-D.massar-v6ops-heartbeat]
Massar, J., "SixXS Heartbeat Protocol",
draft-massar-v6ops-heartbeat-01 (work in progress),
June 2005.
[I-D.massar-v6ops-tunneldiscovery]
Massar, J., "IPv6 Tunnel Discovery",
draft-massar-v6ops-tunneldiscovery-00 (work in progress),
July 2005.
[I-D.ooms-v6ops-bgp-tunnel]
Clercq, J., "Connecting IPv6 Islands over IPv4 MPLS using
IPv6 Provider Edge Routers (6PE)",
draft-ooms-v6ops-bgp-tunnel-05 (work in progress),
May 2005.
[I-D.palet-v6tc-goals-tunneling]
Palet, J., "Goals for Tunneling Configuration",
draft-palet-v6tc-goals-tunneling-00 (work in progress),
February 2005.
[I-D.parent-v6tc-protocol-exploration]
Parent, F., "v6tc Protocol Exploration",
draft-parent-v6tc-protocol-exploration-00 (work in
progress), December 2004.
[I-D.reddy-dhcpv6-opt-dstm-exp]
Reddy, A. and J. Bound, "Dual Stack Transition Mechanism
Baker Expires February 13, 2006 [Page 18]
Internet-Draft The End to End Problem in Transition August 2005
(DSTM) Options for DHCPv6",
draft-reddy-dhcpv6-opt-dstm-exp-00 (work in progress),
April 2005.
[I-D.shin-dstm-ports]
Shin, M., "Ports Option Support in DSTM",
draft-shin-dstm-ports-00 (work in progress), June 2005.
[I-D.yamamoto-v6tc-security-considerations]
Yamamoto, S., "Security Considerations for the Tunnel
Broker Model",
draft-yamamoto-v6tc-security-considerations-00 (work in
progress), July 2005.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack
Hosts using the "Bump-In-the-Stack" Technique (BIS)",
RFC 2767, February 2000.
[RFC2772] Rockell, R. and B. Fink, "6Bone Backbone Routing
Guidelines", RFC 2772, February 2000.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
Baker Expires February 13, 2006 [Page 19]
Internet-Draft The End to End Problem in Transition August 2005
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, December 2004.
[RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer
3 Provider Provisioned Virtual Private Networks (PPVPNs)",
RFC 4031, April 2005.
Author's Address
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Email: fred@cisco.com
Baker Expires February 13, 2006 [Page 20]
Internet-Draft The End to End Problem in Transition August 2005
Appendix A. Requirements for a general transition strategy
What we need is Internet-level transition strategy that defines a
limited subset of simple transition mechanisms that provide reliable
bi-directional connectivity into a dual-stack backbone and to the
global dual-stacked Internet backbone.
To avoid the fragmentation this document concerns itself with, the
advice of the IPv6 Operations Working Group is that Enterprises
should transition to IPv6 by:
Case 1: Fully dual stacked backbone: Deploying a native IPv6 service
along with native IPv4 service throughout the Enterprise from dual
stack hosts to dual stack routers connecting to a dual-stacked
Internet backbone. (Preferred method)
Case 2: Partially dual-stacked backbone: Deploying a limited number
of dual stack "work group" routers with tunnels between them. The
dual-stacked work group routers provide both IPv4 and IPv6 service
to dual-stack hosts while the majority of the Enterprise backbone
network remains IPv4-only. Since the Enterprise has an IPv4-
dominant infrastructure throughout most of the Enterprise's
backbone, the IPv6-capable work group routers must tunnel IPv6
through the IPv4 enterprise to a central dual-stacked router that
connects the IPv6 work group router tunnels and provides service
to the dual-stack Internet backbone. Both IPv4 and IPv6 service
is provided from the host to the global dual-stacked backbone. It
is expected that this network design may be eventually upgraded to
case 1.
Case 3: Deploying limited IPv6-in-IPv4 tunneling (bidirectional) from
dual stack hosts to a tunnel end-point (tunnel broker, 6to4,
etc...) that can connect hosts to a native IPv6 backbone. This
case assumes an Enterprise architecture with only one (or a few)
dual-stacked router which is acting as the IPv6 TEP. This
solution has the most overhead and least scalability and should be
used for early adoption until upgrades to case 1 or 2 can be made.
If the IPv4 infrastructure contains NAT, then the tunnel setup
protocol must provide NAT traversal and keep-alive features.
All of these provide both native IPv6 and IPv4 connectivity to a
fully dual-stacked backbone. That is the key to interoperability.
Translation should not be used as an Enterprise solution for IPv6
connectivity - it breaks the End to End model described in [Saltzer],
and is too technically complex to maintain as an enterprise service
for a large multi-application network. Translation should only be
used at the edge of a network for specific pieces of equipment that
Baker Expires February 13, 2006 [Page 21]
Internet-Draft The End to End Problem in Transition August 2005
cannot be upgraded to IPv6 by a dual-stack software patch.
IPv6 dominant networks are only recommended for edge networks that
have all internal communications via IPv6 and only a small portion of
external communications via IPv4.
If the IPv6 dominant network may act as a local backbone that will
have to service some IPv4-only networks, then it needs manual (GRE)
IPv4-in-IPv6 tunnels or some form of automatic edge-to-edge IPv4-in-
IPv6 tunnels (not defined at this point) to service the IPv4 traffic
through the infrastructure between IPv4-only islands and to the
global dual-stack backbone. Perhaps some form of BGP tunnels could
service this need.
Baker Expires February 13, 2006 [Page 22]
Internet-Draft The End to End Problem in Transition August 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baker Expires February 13, 2006 [Page 23]
