Network Working Group W. Eddy
Internet-Draft NASA GRC/Verizon FNS
Expires: December 30, 2004 J. Ishac
NASA GRC
M. Atiquzzaman
University of Oklahoma
July 2004
An Architecture for Transport Layer Mobility
draft-eddy-tlmarch-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 December 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes a generalized architecture for implementing
mobility in the transport layer rather than the network layer. In
addition, the document discusses the advantages of this approach, the
basic mechanisms and interactions required to support transport layer
mobility, and examples of how to enable mobility in various transport
protocols, using this architecture.
Eddy, et al. Expires December 30, 2004 [Page 1]
Internet-Draft Transport Layer Mobility July 2004
1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Eddy, et al. Expires December 30, 2004 [Page 2]
Internet-Draft Transport Layer Mobility July 2004
2. Introduction
This document outlines an architecture that supports transport layer
mobility, allowing nodes to remain reachable and retain existing
connections while changing their point of attachment to the Internet.
This architecture includes common mechanisms to support movement
detection and location management, so that these problems do not need
to be solved per transport protocol. Instead, the only requirement
needed to add mobility support for a given transport protocol is some
protocol-specific mechanism to update bindings to particular IP
addresses. This architecture places mobility functions on the end
hosts, rather than in the network. If use of mobile devices
continues to increase, while deployment of network-layer support for
mobility does not, a solution such as the one described in this
document is potentially beneficial to end-users.
While this document describes an architecture placing the crux of
mobility support at the transport layer, several solutions exist at
other layers. For example, some wireless links are capable of
handling link-layer mobility, allowing for seamless communication
over a covered area. At the network layer, Mobile IP [1] provides
mobility for both IPv4 and IPv6 based hosts by using the notion of a
home network for a mobile node as an indirection point to the node's
current location . Since, Mobile IP attacks a similar problem space
to the transport layer mobility architecture this document describes,
we compare the two approaches fairly extensively in Section 6.
The architecture described in this document provides support for
common services mobile hosts require. Mechanisms for movement
detection are suggested to allow a host to know when its connectivity
is changing. Movement detection events can then trigger the location
updates that are another part of the architecture, and the binding
updates which are transport-specific. Location management (via
location updates) is the portion of the architecture that lets a host
receive new connections, while binding updates are used by individual
transport protocols to maintain existing connections during movement.
The movement detection and location management functions are fully
specified here, but only examples are provided of how binding updates
may be implemented in common transport protocols. The exact format
of binding updates is heavily protocol-dependent, and best scoped in
documents specific to each protocol. This document does not define
any wire protocols for location management or movement detection; the
transport layer mobility architecture makes use of existing protocols
for these features.
For proper operation, many transport protocols need to be aware of
mobility anyway (transparent network layer mobility is fundamentally
broken), so moving the bulk of a mobility solution into the transport
Eddy, et al. Expires December 30, 2004 [Page 3]
Internet-Draft Transport Layer Mobility July 2004
(where it may be edge-provided rather than network-provided) is a
reasonalbe design [2]. While mobility support at the transport layer
may offer significant benefits compared to solutions at other layers,
it does not solve the entire mobile/wireless problem space. In
particular the following issues are not dealt with fully in this
document:
o Interactions with NAT may affect binding updates is some
transports and not others. NAT affects a host's global
reachability and thus may break the location management functions
of the architecture, but movement detection should be unaffected
by the presence of NATs.
o Security issues for binding updates in individual transports are
not discussed. We give some examples of how these may be
authenticated in some common transports.
o Some transport protocols may not easily be able to implement the
binding updates required by this architecture. Applications using
these protocols may be better served by Mobile IP. In some cases,
these transports typically service very short-lived connections,
whose lifetimes are likely too short to worry about the
macro-mobility this architecture deals with anyways. Such
services are typically light on state and can inexpensively retry
at the application or user level, so this is not a large
consideration.
Section 3 describes how movement detection may be performed within
this architecture. Section 4 then presents the architecture's
location management mechanism. Examples of how binding updates may
be implemented in common transport protocols are contained in Section
5. Section 6 is a comparison of the Mobile IP system to the
transport layer mobility architecture. Layer interactions with other
mobility architectures such as Mobile IP are outlined in Section 7,
and Section 8 contains security considerations.
Eddy, et al. Expires December 30, 2004 [Page 4]
Internet-Draft Transport Layer Mobility July 2004
3. Movement Detection
Movement detection in the transport layer mobility architecture is
very similar to movement detection in Mobile IP. The major
difference is that with transport layer mobility, in addition to
detecting new networks, the mobile host MUST obtain an address on the
new network.
With IPv6, a mobile node can use the built-in neighbor discovery [12]
mechanism to detect when it has moved onto a new network. IPv6
address auto-configuration [13] and DHCPv6 [14] may then be used to
obtain an address and configuration information in the new network.
With IPv4, ICMP router discovery [15] messages may be used for
mobility detection and DHCP [16] is employed for obtaining an address
and configuration.
As in Mobile IP, movement detection and configuration of the mobile
host on new networks occurs independently of the transport layer. An
operating system implementing the transport layer mobility
architecture MUST provide a means for transport protocols to
recognize when the process of joining a new network is taking place.
For example, this could be accomplished using message passing or by
providing a pollable variable. This mechanism should provide
distinct values for when a new network has been detected on an
interface, and when it has been finally configured. In addition, the
operating system MAY provide additional information about networks
and interfaces to the transport layer. This might include media
type, signal strength, error rate, or other metrics that might help a
transport protocol decide if changing its address bindings would be
advantageous.
This means of movement detection handles macro-mobility. Handling
micro-mobility within networks is largely out of scope, however we
discuss some problematic interactions. Micro-mobility based on local
registration requires some anchor point in the network, which does
not exist as part of the transport layer mobility architecture.
Paging-based micro-mobility solutions may also be difficult to
incorporate, as DNS provides the location management service for
transport layer mobility, and DNS has no notion of paging nodes for
address changes. Integrating micro-mobility into the architecture is
possible future work that might be handled in a separate protocol,
and lack of support for it does not significantly affect the
applicability of the architecture in many conceivable cases.
Eddy, et al. Expires December 30, 2004 [Page 5]
Internet-Draft Transport Layer Mobility July 2004
4. Location Management
Locating a static host in order to access some service on it is
generally accomplished using the Domain Name System (DNS), which maps
human-meaningful domain names into IP addresses. This mapping is
stored in a distributed database. The servers providing this
database have become integral portions of the Internet architecture.
The dynamic DNS [17] extension allows for updates to the database to
be made without the intervention of administrators. This allows the
DNS to be used as a location management system for mobile nodes.
In Mobile IP, location management is a service provided by the home
agent (HA). A mobile host is always reachable at a static IP
address. There is no need for DNS entries that point to it to be
updated when it moves, as the HA will forward all packets directed to
the mobile node's address through the Mobile IP tunnel.
With a dynamic DNS system already deployed as an integral portion of
the Internet architecture, we may remove the mobile host's
requirement of a fixed IP address and HA, and allow it to roam
freely, acquiring addresses specific to the network it is currently
attached to at any time. Location management is provided by updating
its DNS records to reflect its current address. This approach
leverages an existing piece of the Internet architecture (the DNS)
rather than adding new pieces (home and foreign agents) to it.
Additionally, this approach provides route optimization by always
pointing requests at a mobile host's current location rather than
forwarding them through some indirection architecture.
Securing the dynamic DNS against remote-redirection attacks can be
accomplished using signatures to authenticate updates [18]. For the
purpose of mobility, these signatures are most naturally generated by
the SIG(0) method [19] which uses a public key stored in the DNS and
a private key stored on the mobile node. The mobile node uses its
private key to sign its updates in the specified manner and the
public key available to the DNS server is used to verify that the
signature on the update was generated by the private key, and thus
the update is from the mobile node and not spoofed.
The security of this method relies on the protection of a mobile
node's private key. In cases where physical security of a mobile
device cannot be taken for granted, encrypting the private key with a
short pass phrase may help. This would require the user to input the
pass phrase in order to unlock the private key, either each time a
DNS update needs to be sent or once for a session which may span
several updates (similar to current passphrase agents).
Relying on the DNS for location management opens hosts using the
Eddy, et al. Expires December 30, 2004 [Page 6]
Internet-Draft Transport Layer Mobility July 2004
location management feature of this architecture up to a potential
impersonation vulnerability, related to stale DNS information. For
example, if a host (A) moves off of a network, but takes some time
before reconnecting and updating its DNS record, another host (B) may
acquire its old address. Another host (C) wishing to connect to some
service on A, will look up A's address using the DNS, and begin
communicating with B. If B can impersonate A suitably enough to fool
C, then some sensitive information might be divulged. For typical
mobile service users today, this scenario is not expected to cause
many problems, but may be a concern for some. The problem can be
avoided completely if A has notification that it is going offline for
some time, then it might either preemptively remove its vulnerable
DNS records, or update them to the address of some cooperating host
that will provide its services in the interim.
Eddy, et al. Expires December 30, 2004 [Page 7]
Internet-Draft Transport Layer Mobility July 2004
5. Binding Updates
In the transport layer mobility architecture, movement detection and
location management are provided outside the transport protocol.
Triggers exist between the movement detection algorithm and the
transport to initiate the transport's updating of its IP address
bindings when an address is obtained in a new network, and likewise a
trigger exists between movement detection and location management to
update the mobile node's primary address in the DNS. The detail of
this process which is not codified in this document, is the exact
means a transport protocol uses to perform binding updates. This is
dependent on the specific transport protocol, and the ability may be
native in some transports, while requiring an extension to others.
This section provides some examples of how various groups have
implemented binding updates in the SCTP and TCP transport protocols,
and an appendix shows an in-depth timing diagram of how the
architecture fits together and functions with one particular
transport protocol.
Due to SCTP's built-in ability to have transport associations bound
to multiple addresses, binding updates in SCTP are a fairly natural
extension. The only addition required to the base protocol is
implementation of ASCONF chunks [20]. Several proposals have
simultaneously appeared from different groups for using these chunks
to do binding updates in a transport layer mobility scheme (TraSH
[21], mSCTP [22], Cellular SCTP [23]). In particular, we shall
describe the operation of the TraSH scheme.
With TraSH, handoffs begin after a mobile node enters a new network
and receives a router advertisement and configures an address in the
new network. In the architecture described in this document, these
functions would occur under the responsibility of the movement
detection procedures. TraSH then adds the new IP address into
existing SCTP associations in addition to any old addresses in the
association. As the mobile node moves further into the coverage area
of the new network and discovers it is better connected there, it
changes the primary destination address in its SCTP associations. At
this point, the mobile node also uses the new address and new network
to initiate new associations and updates its location management
information. Finally, as connectivity with old networks degrades and
is lost, the mobile node deletes the corresponding addresses from its
SCTP associations. The architecture describe in this document
provides the location management services, and the ASCONF extension
to SCTP provides all that is needed for binding updates (new address
addition, change of primary address, and removal of old addresses).
A timing diagram of the entire procedure may be found in the
appendix.
Eddy, et al. Expires December 30, 2004 [Page 8]
Internet-Draft Transport Layer Mobility July 2004
Unlike SCTP, TCP was not originally designed with the idea of being
bound to multiple addresses simultaneously, so binding updates for
TCP have generally been implemented in a completely different manner.
While it would be possible to define TCP options similar to SCTP's
ASCONF extension, to allow for the same granularity in adding,
prioritizing, and deleting addresses, most TCP mobility work has
simply focused on rebinding the currently used address (for example
Migrate [24], and TCP-R [25]). This address replacement logically
takes place at the same time as the change of primary address with
TraSH, at the point where movement detection has observed and
configured a new network AND determined that connectivity there is
superior to that in the network whose address is currently used in
the TCP connection. The old address is completely replaced by the
new one in the transport control block and used to initiate new
connections at this point.
Properly doing binding updates in TCP requires slightly more work, in
that proposals must be careful to ensure that the binding updates are
not spoofable, usually by some cryptographic means, and TCP lacks any
standardized features that can provide this. For example the Migrate
proposal for mobile TCP uses an elliptic curve Diffie-Hellman key
exchange to authenticate the binding updates. The key data is
negotiated at connection setup time via additional options. Other
transports that do not currently include negotiation of cryptographic
keys at startup will have to provide their own methods for this, or
risk vulnerability to possible remote redirection attacks.
The architecture described in this document leaves the exact format
and functioning of binding updates to be specifically defined for
each transport protocol that wishes to use the architecture. What is
provided, is a common means of movement detection and location
updates.
Eddy, et al. Expires December 30, 2004 [Page 9]
Internet-Draft Transport Layer Mobility July 2004
6. Comparison with Mobile IP
Mobile IP [1] has been adopted as a standard for enabling host
mobility in the Internet architecture. Mobile IP provides mobility
support at the network layer, allowing all transports and
applications built on top of it to transparently work on mobile
hosts. The current Mobile IP approach, in IPv4, suffers from a
number of drawbacks, however.
For Mobile IP to function, a mobile node must have a home agent (HA)
in its home network. In addition, foreign agents (FA) must be
deployed in each foreign network the mobile node might attach to.
These architectural elements are not commonly found in the Internet
architecture. Thus, there is a strong reliance on network
administrators to both deploy and configure these agents.
The triangle routes set up by Mobile IP add additional latency to the
round-trip path that packets follow. The redirection and
encapsulation of packets at the HA into a tunnel results in a waste
of bandwidth and is especially expensive if the tunnel to the care-of
address has high delay. If the network path between the HA and
care-of address is disturbed, connectivity between the mobile node
and corresponding hosts may be broken, even though the disturbance
doesn't affect the direct paths between them. In addition, due to
the use of spoofed source addresses by numerous large-scale
distributed denial of service attacks and worm propagation, many
routers implement ingress filtering [4], which blocks packets that
seem to originate from a topologically impossible location. Since
mobile nodes use their static home IP addresses as a source addresses
in packets they send, these outgoing packets may be dropped by
routers in the foreign network.
Triangular routing can be removed using either route optimization or
reverse-tunneling. Route optimization procedures have been studied
for Mobile IP. However, they are currently not standardized.
Furthermore, implementing route optimization will either require
support from routers or major changes to end-hosts, including those
which are not necessarily mobile. Reverse-tunneling [5] allows
mobile nodes to tunnel all network traffic through the HA. The
downside to using topologically correct reverse tunnels is that the
inefficient side of the triangle route is used in both directions
rather than just one, further exacerbating the problems with
bandwidth and delay.
Also, stateful firewalls and NATs generally rely on seeing a TCP
SYN exchange to instantiate the state that allows them to process
packets correctly. If a mobile host with an existing TCP connection
changes network attachment points, firewalls and NATs are likely to
Eddy, et al. Expires December 30, 2004 [Page 10]
Internet-Draft Transport Layer Mobility July 2004
drop its packets and break the connection. Since many popular
applications use TCP, this is a problem. A similar problem applies
to services on the mobile host (using any transport protocol) when it
moves behind a NAT.
As a mobile host moves between networks, it may be disconnected for a
short period as the host detects a new network and registers the new
location with the HA. This could result in packet loss at the higher
layers if packets are sent to the old care-of address, and are not
buffered or redirected by the network. Smooth handover methods have
been investigated, but are not yet standard, and are likely to
require additional work on the part of routers.
Since changes in network point of attachment occur transparently when
using Mobile IP, transport protocols that keep state about the
network path and base their behaviors on that state may not adapt to
the new network in an efficient manner. For example, TCP keeps state
including an estimate of the round-trip time [8] and the available
capacity [7] of a network path. These properties may vary widely
between the various points of attachment that a mobile node
encounters. Without warning that a transition between networks is
taking place, the transport layer can do nothing to help smooth the
transition, such as pausing its transmissions, reprobing the network,
or sending zero-window advertisements causing peers to do the same.
Mobile IP provides no protection against bogus HAs or FAs. Malicious
users in a network may configure home and foreign agents that can be
used to either compromise the privacy of a mobile node's data or deny
it service. For example, a bogus HA might be set up to monitor a
mobile node's traffic even when it was away in a foreign network. A
bogus FA could likewise be configured to monitor the traffic of
visiting mobile nodes. Either bogus HA or FA advertisements could be
used to slow the registration process as a denial of service attack.
In a Mobile IP system, there is no location privacy for mobile nodes.
Since mobile nodes always use a fixed IP address which is from their
home network, foreign agents can use this address to infer where
nodes are from both geographically (since addresses are used for
routing) and organizationally (since address blocks are ownership is
not private). Since an HA redirects packets to the care-of addresses
of mobile nodes, HAs have similar information regarding a mobile
node's current location.
Many of the downsides to the Mobile IP approach are artifacts of its
place in the protocol stack. Since Mobile IP resides in the network
layer, it's features are tied to services provided by the network
infrastructure rather than the end hosts. This makes the end-users'
capacity for mobility dependent upon the actions of their service
Eddy, et al. Expires December 30, 2004 [Page 11]
Internet-Draft Transport Layer Mobility July 2004
providers. Implementing mobility as a feature of the transport layer
can move some power back to the users and offer mitigations to many
of the listed drawbacks in the Mobile IP system.
The transport layer mobility architecture described in this document
requires no additional network infrastructure aside from what IP
networks currently provide.
With mobility anchored in the transport layer, there is implicit
route optimization. Packets move directly from end source to end
destination, with no indirection. There are no triangle routes.
Topologically correct endpoint addresses are always used with
transport layer mobility, which make the system robust to ingress
filtering.
In transport layer mobility, transport protocols are explicitly aware
of changes in their network attachment status. This allows
transports to take the proper action in order to smooth transitions
into the new networks, like pausing transmissions during the handover
and reseting congestion control state.
Stateful firewalls and NATs may still pose a problem for mobile
transport protocols, although potentially less-so than with Mobile
IP. For example, TCP can be extended for mobility by setting the SYN
bit on the first segment in an ongoing mobile connection which comes
from a new address. This pokes a hole for the connection in such
devices. Other transport protocols that are affected by NATs may or
may not find similar protocol-specific solutions.
The transport layer mobility architecture does not use HAs or FAs and
so is immune to bogus agents. The system is however vulnerable to
bogus DHCP servers. This problem is shared by the entire networks a
bogus DHCP server resides on, however, harming both mobile and static
nodes that use DHCP for configuration. In practice, non-authorized
DHCP servers can be quickly located and removed from production
networks.
Transport layer mobility provides a different amount of location
privacy than Mobile IP. Corresponding nodes always know the mobile
node's current location with transport layer mobility, although this
information is more hidden from the home network, and the identity of
the mobile node is more hidden from the foreign network. No active
agents are charged with keeping state about a host. As the DNS is
used for location management, a node's current location is always
known and globally available information. Updating a mobile node's
location in DNS is, however, only required if the node is running
services that it desires be globally reachable for new sessions. If
Eddy, et al. Expires December 30, 2004 [Page 12]
Internet-Draft Transport Layer Mobility July 2004
this is not the case, or if its services can be located via some
other mechanism (for example, via a connection to a peer-to-peer
network that is persistent across the node's movements due to
transport layer mobility), then a mobile node need not advertise its
current location in the DNS. Encrypting binding and location updates
would remove any identification of a mobile node's "home".
Additionally, dynamic DNS service could be provided by any party -
not necessarily in a "home" network - so some degree of anonymousness
is possible using transport layer mobility.
Transport layer mobility enables "soft" handovers (not involving the
teardown of connectivity at one point before it is re-established
elsewhere) to be achieved for nodes having multiple interfaces or
even single interfaces using technologies like software radios. This
type of activity might also be possible in the Mobile IP framework.
This allows for the decoupling of registration on the new network's
interface and ongoing data transfer on the old network's interface,
further smoothing a node's handover between networks.
The current specification for Mobile IPv6 [3] mitigates some of the
problems discussed for Mobile IPv4, although still lacks some
features in comparison with transport layer mobility.
MIPv6 does not require FAs to be deployed in foreign networks.
However, HAs are still needed as additional infrastructure in the
Internet. The specification supports route optimization as a
standard feature. As with transport layer mobility, location privacy
from the the corresponding nodes is not provided, and as in version
4, there is no location privacy from the home network nor identity
privacy from the foreign network.
MIPv6 can coexist with ingress filtering by using the Home Address
Option to ensure topologically correct addressing. MIPv6 must still
support packet encapsulation in its bidirectional tunneling mode.
Also, HAs are still required to encapsulate data packets at least
during the initial stage of the binding update procedure. This
coupling of data forwarding and location management raises issues
regarding scalability of MIPv6; the HA may still become a network
bottleneck.
IPsec is a built-in part of MIPv6, which is used for securing the
binding update, while in version 4, separate security mechanisms are
used based on statically configured security associations [9].
NAT devices may still exist in an IPv4-IPv6 overlay network, at least
in the near future. The incompatibility between NAT and IPsec [10]
may create a problem for MIPv6. As in NAT traversal for Mobile IP
Eddy, et al. Expires December 30, 2004 [Page 13]
Internet-Draft Transport Layer Mobility July 2004
version 4 [11], some special protocol format will need to be defined
to allow operation of MIPv6 through NATs.
Higher layer protocols, such as reliable transports like TCP and
SCTP, will still have no information about handovers, since all the
MIPv6 operation is transparent to the transport layer.
Some proposals in the IETF MIPSHOP group (particularly FMIPv6 and
HMIPv6) exist to lessen the latency of the handover and the amount of
packet loss that may occur.
Eddy, et al. Expires December 30, 2004 [Page 14]
Internet-Draft Transport Layer Mobility July 2004
7. Layer Interactions
Typically, the division of labor between protocols is clear in the
Internet architecture. This is true of the basic requirements for
packet service such as routing, addressing, ordering, and
reliability. The proper place in the stack for more advanced
features like mobility is unclear, because such a feature was not
required when the stack layers were initially created. The mobility
extension of the architecture defined in this document stretches
across several layers. It uses network and application layer
protocols for movement detection (IP and DHCP), an application
protocol for location management (DNS), and handles binding updates
in individual transport protocols (examples given for TCP and SCTP).
The literature is full of diverse approaches to mobility.
Particularly, Mobile IP is a proposed standard [1]. While section
Section 6 lists a number of reasons why the approach outlined in this
document may be preferred over Mobile IP (versions 4 and 6), it is
possible to use both approaches simultaneously. This would enable
mobility support through Mobile IP for transport protocols that have
not been extended to use this document's mobility architecture, and
would simultaneously allow a more pleasant mobility experience to
transport protocols that do interface with this architecture.
For example, in the current MIPv6 specification, a mobile node can
initiate communications to another node using either the mobile
node's home address or its current care-of address. By using the
care-of address, the mobile node can establish an efficient
communication channel to any other node, an not simply those that
support route optimization and have established the proper network
bindings. However, the connection duration is limited to the
lifetime of the care-of address. Transport layer mobility can be
used as a means to extend the connection over multiple care-of
addresses. Thus, transport layer mobility might provide a valuable
benefit to applications requiring long-lived connections.
Thus, mobility at both the transport and network layers may be able
to co-exist when both residing on the same node. However,
complications arise when a mobile node acts as a mobile router (MR),
providing network mobility (NEMO) [26][27]. With NEMO, the MR builds
a bi-directional tunnel to its home agent, thus providing mobility to
hosts and networks attached to it.
As a result, nodes behind a mobile router are:
o Unaware of any changes in network attachment.
o No longer the mobile endpoint and thus, do not own a unique
care-of address on the foreign network.
Eddy, et al. Expires December 30, 2004 [Page 15]
Internet-Draft Transport Layer Mobility July 2004
o Subject to all packets being transparently tunneled to the MR's
home network.
By masking movement and providing nodes with addresses from the MR's
home network, the algorithms outlined in this document for movement
detection and location management are no longer applicable for the
duration that node stays attached to that MR. Thus, attachment to a
mobile router is treated as a single foreign network. Should the
node detach from the mobile router and move to a different mobile or
foreign network, it behaves normally following the architecture
outlined in this document. All this is done without any special
requirements by either entity.
The mobile router MAY wish to notify hosts with mobility awareness of
changes in attachment, so that transport mobility aware hosts can
take appropriate action to reprobe the network paths. However,
specification of any such communication does not currently exist.
Also, mobile routers MUST tunnel packets that follow the architecture
outlined in this document and MUST NOT split those connections as an
attempt to provide route optimization.
Eddy, et al. Expires December 30, 2004 [Page 16]
Internet-Draft Transport Layer Mobility July 2004
8. Security Considerations
Security and privacy concerns have been addressed, where relevant,
throughout this document. The security of the transport layer
mobility architecture is mainly dependent upon the authentication of
the location updates and binding updates. The location updates
specified use dynamic DNS with the SIG(0) extension for
authentication, and are thus vulnerable to any holes this system's
design or implementation may possess. The exact format of the
binding updates is specific to each transport protocol. The examples
presented for SCTP and TCP take different approaches to
authenticating the binding updates, each of which has its own
security considerations.
9 References
[1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[2] Eddy, W., "At What Layer Does Mobility Belong?", to appear in
IEEE Communications, 2004.
[3] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Ferguson, D., "Network Ingress Filtering: Defeating Denial of
Service Attacks which employ IP Source Address Spoofing", RFC
2827, May 2000.
[5] Montenegro, G., "Reverse Tunneling for Mobile IP, Revised", RFC
3024, January 2001.
[6] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[7] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[8] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[9] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
Authentication, Authorization, and Accounting Requirements",
RFC 2977, October 2000.
[10] Aboba, B. and W. Dixon, "IPsec-Network Address Translator (NAT)
Compatibility Requirements", RFC 3715, March 2004.
Eddy, et al. Expires December 30, 2004 [Page 17]
Internet-Draft Transport Layer Mobility July 2004
[11] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network
Address Translation (NAT) Devices", RFC 3519, April 2003.
[12] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[13] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[14] Deering, S., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[15] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[16] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[17] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[18] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[19] Eastlake 3rd, D., "DNS Request and Transaction Signatures (
SIG(0)s )", RFC 2931, September 2000.
[20] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Rytina, I.,
Belinchon, M. and P. Conrad, "Stream Control Transmission
Protocol (SCTP) Dynamic Address Reconfiguration", September
2003.
[21] Fu, S., Atiquzzaman, M., Ma, L., Ivancic, W., Lee, Y., Jones,
J. and S. Lu, "TraSH: A Transport Layer Seamless Handover for
Mobile Networks", University of Oklahoma Technical Report
OU-TNRL-04-10, January 2004.
[22] Koh, S., Lee, M., Riegel, M., Ma, M. and M. Tuexen, "Mobile
SCTP for Transport Layer Mobility", February 2004.
[23] Aydin, I. and C. Shen, "Cellular SCTP: A Transport-Layer
Approach to Internet Mobility", October 2003.
[24] Snoeren, A. and H. Balakrishnan, "An End-to-End Approach to
Host Mobility", Proc. of the Sixth Annual ACM/IEEE
International Conference on Mobile Computing and Networking,
Eddy, et al. Expires December 30, 2004 [Page 18]
Internet-Draft Transport Layer Mobility July 2004
August 2000.
[25] Funato, D., Yasuda, K. and H. Tokuda, "TCP-R: TCP Mobility
Support for Continuous Operation", International Conference on
Network Protocols (ICNP), October 1997.
[26] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol",
draft-ietf-nemo-basic-support-03 (work in progress), June 2004.
[27] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", draft-ietf-nemo-terminology-01 (work in
progress), February 2004.
Authors' Addresses
Wesley M. Eddy
NASA GRC/Verizon FNS
EMail: weddy@grc.nasa.gov
Joseph Ishac
NASA GRC
EMail: jishac@grc.nasa.gov
Mohammed Atiquzzaman
University of Oklahoma
EMail: atiq@ou.edu
Eddy, et al. Expires December 30, 2004 [Page 19]
Internet-Draft Transport Layer Mobility July 2004
Appendix A. Mobility Example Using TraSH
In this diagram, "New AR" is the access router in a new network that
the Mobile Node is moving into, while maintaining a connection with
corresponding node CN, and Location Manager is a dynamic DNS server.
This example uses the ASCONF chunks that are part of a proposed SCTP
extension, as conceived by the TraSH adaptation of SCTP for mobility
support. The steps that TraSH goes through in order to perform
movement detection, binding updates, and location updates are shown
in order.
Mobile Node New AR CN DHCP Server Location Manager
| | | | |
| Router ADV | | | |
|<--------------| | | |
| | |
| Request IP address from new domain | |
|------------------------------------------->| |
| Assign IP address to MN | |
|<-------------------------------------------| |
| | |
| Add_IP ASCONF Chunk | | |
|------------------------------>| | |
| Add_IP ACK | | |
|<------------------------------| | |
| | | |
~ ~ ~ ~
~ ~~~~~~~~~~~~~~~~~~ MN Continue Moving ~~~~~~~~~~~~~~~~~~~ ~
~ ~ ~ ~
| Set_Primary ASCONF Chunk | | |
|------------------------------>| | |
| | | |
| Location Update Request |
|----------------------------------------------------------->|
| |
| Set_Primary ACK | | |
|<------------------------------| | |
| | | |
| Location Update Reply |
|<-----------------------------------------------------------|
~ ~ ~ ~
~ ~~~~~~~~~~~~~~~~~~ MN Continue Moving ~~~~~~~~~~~~~~~~~~~ ~
~ ~ ~ ~
| Delete_IP ASCONF Chunk | | |
|------------------------------>| | |
| Delete_IP ACK | | |
|<--------
Eddy, et al. Expires December 30, 2004 [Page 20]
Internet-Draft Transport Layer Mobility July 2004
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 (2004). 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.
Eddy, et al. Expires December 30, 2004 [Page 21]