Internet DRAFT - draft-engelstad-ngtrans-mobility-requirements
draft-engelstad-ngtrans-mobility-requirements
INTERNET DRAFT P. Engelstad
Telenor R&D
Expires February 2002 August 14. 2001
Requirements to mobility while transitioning from IPv4 to IPv6.
<draft-engelstad-ngtrans-mobility-requirements-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. 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 document is an individual submission for the NGTRANS Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ngtrans@sunroof.eng.sun.com mailing list.
Abstract
This document explores how layer-3 mobility can be provided to mobile
nodes that are subjects to and affected by the transition mechanisms
specified by the NGTRANS Working Group. It points out that the
combination of mobility and transition mechanisms might lead to
problems that will require a solution, and suggests requirements that
a solution should meet.
1. Introduction
Engelstad [Page 1]
INTERNET DRAFT Transition Mobility Requirements
1.1 Intent of this draft
This draft is a working document, intended to represent the ideas of
people in the NGTRANS Working Group that are interested in IP
mobility and are concerned with how mobility can be accommodated
during the transition from IPv4 to IPv6.
The content of this first version is intended to trigger interest for
and discussion around the problem presented - more than being
prescriptive in any form. Thus, others are invited to contribute to
the content and structure of the document. Comments and minor
contributions, as well as co-authoring and major restructuring are
welcome.
1.2. Assumptions related to transition mechanisms
This draft assumes that there will be a need for connectivity between
IPv4-only nodes, dual stack nodes, and IPv6-only nodes that are
moving and changing network access.
A fully inter-connected IPv6 Internet (with capital 'I') will
probably be formed gradually as different IPv6 islands chooses to
inter-connect. Thus, a mobile node cannot expect that the IPv6-only
access networks have native IPv6 connection with any node on the IPv6
Internet. Hopefully a transition mechanism can accommodate
connectivity.
The connectivity between the mobile nodes (including correspondent
nodes) may rely on some of the many transition mechanism that are
being specified in the NGTRANS Working Group. These include [6to4],
[6over4], [SIIT], [NAT-PT], [ISATAP] and [DSTM] -just to mention a
few of them. [NGTRANS-MECH] gives a detailed overview. Other
mechanisms may also be defined at a later stage.
1.3. Assumptions related to mobility
It is also assumed that the mobile nodes would like to be able to
move between IPv4-only, dual stack, and IPv6-only access network
(although IP4-only nodes cannot expect to be able to connect to
IPv6-only networks, and vice versa).
Mobile IPv4 is assumed to be the preferred protocol that supports
transparent, layer-3 mobility for IPv4 flows, while Mobile IPv6 is
the corresponding protocol for IPv6 mobility.
Both protocols support transparent layer-3 mobility across different
Engelstad [Page 2]
INTERNET DRAFT Transition Mobility Requirements
(heterogeneous) underlying technologies, but there are no protocols
that support transparent mobility across different layer-3 protocols
(i.e. between IPv4 and IPv6).
1.4. Problem statement is required
It is not obvious how transparent, layer-3 mobility will be supported
when the flows involve both IPv4 and IPv6 communication, i.e. when
end-to-end connectivity requires that both IPv4 and IPv6 be used
along the communication path.
People interested in this problem would probably need to work out a
problem statement document that clarifies this issue, e.g.:
- Will an IPv6-only node that relies on transition mechanisms for
communication need transparent layer-3 mobility while roaming
IPv6-only networks?
- Will a dual stack node that relies on transition mechanisms need
transparent layer-3 mobility while roaming between IPv4-only and
IPv6-only networks? (Nodes that visit dual stack networks can
probably choose from both IPv4-only and IPv6-only solution space.)
- Are there any schemes at hand today to address these problems, or
are separate protocols or solutions required?
This draft assumes that a separate solution is required to address
these problems, and proposes a set of requirements that should be met
by this "transition-mobility" solution. The requirements are listed
in the next section.
2. Requirements that should be met by a "transition-mobility"
solution
In the following is listed a number of proposed requirements to a
solution for mobility during IPv4-to-IPv6 transition. Some general
design issues of the architectural principles of the Internet ([IP-
ARCH]) become particularly relevant for such a solution.
2.1 Transparent layer-3 mobility
The transparency requirement dictates that a change of network
connection should not break the transport layer connection of
transport layer protocols. Thus, the tuple of IP-address(es),
Engelstad [Page 3]
INTERNET DRAFT Transition Mobility Requirements
transport-protocol and port(s) in the packets that are received by
the mobile node must not be changed as the node moves. Moreover, the
change of connection should not make the mobile node unreachable for
incoming traffic, if it was reachable to a fixed IP address in the
first place.
2.2 Flexibility
Since it is difficult to foresee the future, a transition-mobility
solution should be independent on how the transition process will
evolve; i.e. it should be flexible to accommodate a wide range of
transition scenarios.
However, as a guideline one may make the following assumption about
pre-transition and post-transition mobility:
- Prior to the transition IPv4-only nodes communicate with IPv4-only
nodes over the IPv4 Internet, and Mobile IPv4 is the preferred
protocol for layer-3 mobility.
- After the transition IPv6-only nodes communicate with IPv6-only
nodes over the IPv6 Internet, and Mobile IPv6 is the preferred
protocol for layer-3 mobility.
2.3 Independence of Transition Mechanisms
The optimal solution should be able to handle the majority of
transition mechanisms that exist today, and it should not hinder
development of new and better mechanism; i.e. it should make few
assumptions about the transition mechanism in use.
Another option is to split the solution into a number of sub-
solutions; e.g. each transition mechanism offers its own
(sub-)solution to the mobility problem.
2.4 Modularity
Hopefully the transition process will go on for only a limited period
of time, and the process will probably evolve gradually. A modular
transition-mobility solution it therefore preferred. This means that
it may be plugged into and unplugged from the network without
altering neither the existing IPv4-based pre-transition protocols nor
IPv6-based post-transition protocols.
2.5 Simplicity
Engelstad [Page 4]
INTERNET DRAFT Transition Mobility Requirements
The transition-mobility solution should not delay the transition
process. Thus, it must be an easy solution that does not take many
years to develop. It should be easy to implement and easy to ensure
inter-operability between different implementations.
2.6 The solution should consume as little IPv4 address space as
possible
The main reason for converting to IPv6 is the lack of IPv4 addresses.
The enormous IPv6 address space will solve that problem, although a
great portion of the IPv6 address space may also be "wasted" on
routing mechanisms (e.g. hierarchical routing?) that minimize the
routing table problem as well.
In the worst case, the transition-mobility solution may be around for
a long time. It is therefore important that it consumes as little
IPv4 addresses as possible.
A significant number of users today acquire their IP addresses
dynamically (PPP dial-up, DHCPv4, etc.) and use it for only a limited
period of time. Many of them obviously do not need to be reachable
for incoming traffic; they initiate the communication session
themselves (e-mail, web-browsing etc.). However, they still would
prefer to be able to move after they initiated the communication.
These users should be able to be mobile without the fixed permanent
IPv4 home address that the basic mode of Mobile IPv4 prescribes,
because permanently assigned addresses occupy the address even when
it is not needed. Dynamic home address discovery, as specified in
[HADDR-DISC], might be one way out of this problem. The transition-
mobility solution may alternatively support other dynamic address
allocation schemes. It could for example be based on DHCP, which is
proposed in [DSTM].
2.7 The "end-to-end argument" revisited
A transition-mobility solution that pushes the logic and the
complexity of the solution to the end host should be preferred. Dual
stack hosts must be configured to handle mobility and/or the
transition from IPv4 to IPv6, anyway, and putting transition-mobility
functionality in the host could be an integrated part of this
configuration.
Network Address Translation (NAT) is the classic example that shows
that putting the (lack of) logic in the NAT-boxes and deviating from
the end-to-end-principle to solve a temporary problem, easily leads
Engelstad [Page 5]
INTERNET DRAFT Transition Mobility Requirements
to complex inter-network behavior and new problems.
It should be noted that most transition mechanisms inherently places
the logic in the network.
3. Security Issues
The mobility mechanism that is used to re-direct the flow to the
mobile node must be protected by authentication and authorization.
Layer-3 mobility solutions often include either host-based routing or
relaying of traffic by a mobility agent. In both cases the flow is
re-directed as the mobile node moves. (Mobile IPv6, for example,
solves this problem by requiring a security association between the
mobile node and the home agent. The binding updates are authenticated
and authorized before the flow is forwarded to the subnet where the
mobile node is located.)
Denial-of-service attacks may be a relevant security threat to
statefull transition-mobility solutions where the states of the flows
are maintained in one single node.
References
[MIPv4] C.E. Perkins, "IP Mobility Support", IETF RFC 2002, October
1996.
[MIPv6] D.B. Johnson and C.E. Perkins, "Mobility Support in IPv6",
<draft-ietf-mobileip-ipv6-11.txt>, Work in Progress.
[6to4] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4
Clouds", IETF RFC 3056, IETF, February 2001.
[DSTM] J. Bound, L. Toutain, H. Affifi, "Dual Stack Transition
Mechanism (DSTM)", <draft-ietf-ngtrans-dstm-04.txt>, IETF, Work in
Progress.
[6over4] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC2529, IETF, March 1999.
[SIIT] E. Nordmark, "Stateless IP/ICMP Translator", RFC 2765, IETF,
February 2000.
[NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation -
Engelstad [Page 6]
INTERNET DRAFT Transition Mobility Requirements
Protocol Translation (NAT-PT)", RFC 2766, IETF, February 2000.
[ISATAP] F.L. Templin, "Intra-Site Automatic Tunnel Addressing
Protocol (ISATAP).", <draft-ietf-ngtrans-isatap-01.txt>, IETF, Work
in Progress.
[NGTRANS-MECH] W. Biemolt et. al., "An overview of the introduction
of IPv6 in the Internet", IETF, Work in Progress.
[HADDR-DISC] P. Calhoun and C.E. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, IETF, January 2000.
[IP-ARCH] B. Carpenter (ed.), "Architectural Principles of the
Internet", RFC 1958, IETF, June 1996.
Author's address
Paal E. Engelstad
Telenor R&D, Palo Alto
399 Sherman Ave. Suite #12
Palo Alto, CA 94306, USA
Tel.: + 1-650- 714 7537
e-mail: paal@telenorisv.com
Feel free to contact me directly on this e-mail address, or through
NGTRANS WG's mailing list on ngtrans@sunroof.eng.sun.com, if you have
comments or opinions regarding this draft. Your comments are welcome!
Engelstad [Page 7]
