[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/