idnits 2.17.1 draft-eddy-tlmarch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 795. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 811), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 370 has weird spacing: '...nd NATs gene...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7225 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 630, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (ref. '1') (Obsoleted by RFC 5944) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 2993 (ref. '6') ** Obsolete normative reference: RFC 2581 (ref. '7') (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2988 (ref. '8') (Obsoleted by RFC 6298) ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 3715 (ref. '10') ** Obsolete normative reference: RFC 2461 (ref. '12') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '13') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (ref. '14') (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' -- Possible downref: Non-RFC (?) normative reference: ref. '25' == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '27') Summary: 20 errors (**), 0 flaws (~~), 5 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Eddy 3 Internet-Draft NASA GRC/Verizon FNS 4 Expires: December 30, 2004 J. Ishac 5 NASA GRC 6 M. Atiquzzaman 7 University of Oklahoma 8 July 2004 10 An Architecture for Transport Layer Mobility 11 draft-eddy-tlmarch-00 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 30, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document describes a generalized architecture for implementing 45 mobility in the transport layer rather than the network layer. In 46 addition, the document discusses the advantages of this approach, the 47 basic mechanisms and interactions required to support transport layer 48 mobility, and examples of how to enable mobility in various transport 49 protocols, using this architecture. 51 1. Requirements Notation 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119. 57 2. Introduction 59 This document outlines an architecture that supports transport layer 60 mobility, allowing nodes to remain reachable and retain existing 61 connections while changing their point of attachment to the Internet. 62 This architecture includes common mechanisms to support movement 63 detection and location management, so that these problems do not need 64 to be solved per transport protocol. Instead, the only requirement 65 needed to add mobility support for a given transport protocol is some 66 protocol-specific mechanism to update bindings to particular IP 67 addresses. This architecture places mobility functions on the end 68 hosts, rather than in the network. If use of mobile devices 69 continues to increase, while deployment of network-layer support for 70 mobility does not, a solution such as the one described in this 71 document is potentially beneficial to end-users. 73 While this document describes an architecture placing the crux of 74 mobility support at the transport layer, several solutions exist at 75 other layers. For example, some wireless links are capable of 76 handling link-layer mobility, allowing for seamless communication 77 over a covered area. At the network layer, Mobile IP [1] provides 78 mobility for both IPv4 and IPv6 based hosts by using the notion of a 79 home network for a mobile node as an indirection point to the node's 80 current location . Since, Mobile IP attacks a similar problem space 81 to the transport layer mobility architecture this document describes, 82 we compare the two approaches fairly extensively in Section 6. 84 The architecture described in this document provides support for 85 common services mobile hosts require. Mechanisms for movement 86 detection are suggested to allow a host to know when its connectivity 87 is changing. Movement detection events can then trigger the location 88 updates that are another part of the architecture, and the binding 89 updates which are transport-specific. Location management (via 90 location updates) is the portion of the architecture that lets a host 91 receive new connections, while binding updates are used by individual 92 transport protocols to maintain existing connections during movement. 93 The movement detection and location management functions are fully 94 specified here, but only examples are provided of how binding updates 95 may be implemented in common transport protocols. The exact format 96 of binding updates is heavily protocol-dependent, and best scoped in 97 documents specific to each protocol. This document does not define 98 any wire protocols for location management or movement detection; the 99 transport layer mobility architecture makes use of existing protocols 100 for these features. 102 For proper operation, many transport protocols need to be aware of 103 mobility anyway (transparent network layer mobility is fundamentally 104 broken), so moving the bulk of a mobility solution into the transport 105 (where it may be edge-provided rather than network-provided) is a 106 reasonalbe design [2]. While mobility support at the transport layer 107 may offer significant benefits compared to solutions at other layers, 108 it does not solve the entire mobile/wireless problem space. In 109 particular the following issues are not dealt with fully in this 110 document: 111 o Interactions with NAT may affect binding updates is some 112 transports and not others. NAT affects a host's global 113 reachability and thus may break the location management functions 114 of the architecture, but movement detection should be unaffected 115 by the presence of NATs. 116 o Security issues for binding updates in individual transports are 117 not discussed. We give some examples of how these may be 118 authenticated in some common transports. 119 o Some transport protocols may not easily be able to implement the 120 binding updates required by this architecture. Applications using 121 these protocols may be better served by Mobile IP. In some cases, 122 these transports typically service very short-lived connections, 123 whose lifetimes are likely too short to worry about the 124 macro-mobility this architecture deals with anyways. Such 125 services are typically light on state and can inexpensively retry 126 at the application or user level, so this is not a large 127 consideration. 129 Section 3 describes how movement detection may be performed within 130 this architecture. Section 4 then presents the architecture's 131 location management mechanism. Examples of how binding updates may 132 be implemented in common transport protocols are contained in Section 133 5. Section 6 is a comparison of the Mobile IP system to the 134 transport layer mobility architecture. Layer interactions with other 135 mobility architectures such as Mobile IP are outlined in Section 7, 136 and Section 8 contains security considerations. 138 3. Movement Detection 140 Movement detection in the transport layer mobility architecture is 141 very similar to movement detection in Mobile IP. The major 142 difference is that with transport layer mobility, in addition to 143 detecting new networks, the mobile host MUST obtain an address on the 144 new network. 146 With IPv6, a mobile node can use the built-in neighbor discovery [12] 147 mechanism to detect when it has moved onto a new network. IPv6 148 address auto-configuration [13] and DHCPv6 [14] may then be used to 149 obtain an address and configuration information in the new network. 150 With IPv4, ICMP router discovery [15] messages may be used for 151 mobility detection and DHCP [16] is employed for obtaining an address 152 and configuration. 154 As in Mobile IP, movement detection and configuration of the mobile 155 host on new networks occurs independently of the transport layer. An 156 operating system implementing the transport layer mobility 157 architecture MUST provide a means for transport protocols to 158 recognize when the process of joining a new network is taking place. 159 For example, this could be accomplished using message passing or by 160 providing a pollable variable. This mechanism should provide 161 distinct values for when a new network has been detected on an 162 interface, and when it has been finally configured. In addition, the 163 operating system MAY provide additional information about networks 164 and interfaces to the transport layer. This might include media 165 type, signal strength, error rate, or other metrics that might help a 166 transport protocol decide if changing its address bindings would be 167 advantageous. 169 This means of movement detection handles macro-mobility. Handling 170 micro-mobility within networks is largely out of scope, however we 171 discuss some problematic interactions. Micro-mobility based on local 172 registration requires some anchor point in the network, which does 173 not exist as part of the transport layer mobility architecture. 174 Paging-based micro-mobility solutions may also be difficult to 175 incorporate, as DNS provides the location management service for 176 transport layer mobility, and DNS has no notion of paging nodes for 177 address changes. Integrating micro-mobility into the architecture is 178 possible future work that might be handled in a separate protocol, 179 and lack of support for it does not significantly affect the 180 applicability of the architecture in many conceivable cases. 182 4. Location Management 184 Locating a static host in order to access some service on it is 185 generally accomplished using the Domain Name System (DNS), which maps 186 human-meaningful domain names into IP addresses. This mapping is 187 stored in a distributed database. The servers providing this 188 database have become integral portions of the Internet architecture. 189 The dynamic DNS [17] extension allows for updates to the database to 190 be made without the intervention of administrators. This allows the 191 DNS to be used as a location management system for mobile nodes. 193 In Mobile IP, location management is a service provided by the home 194 agent (HA). A mobile host is always reachable at a static IP 195 address. There is no need for DNS entries that point to it to be 196 updated when it moves, as the HA will forward all packets directed to 197 the mobile node's address through the Mobile IP tunnel. 199 With a dynamic DNS system already deployed as an integral portion of 200 the Internet architecture, we may remove the mobile host's 201 requirement of a fixed IP address and HA, and allow it to roam 202 freely, acquiring addresses specific to the network it is currently 203 attached to at any time. Location management is provided by updating 204 its DNS records to reflect its current address. This approach 205 leverages an existing piece of the Internet architecture (the DNS) 206 rather than adding new pieces (home and foreign agents) to it. 207 Additionally, this approach provides route optimization by always 208 pointing requests at a mobile host's current location rather than 209 forwarding them through some indirection architecture. 211 Securing the dynamic DNS against remote-redirection attacks can be 212 accomplished using signatures to authenticate updates [18]. For the 213 purpose of mobility, these signatures are most naturally generated by 214 the SIG(0) method [19] which uses a public key stored in the DNS and 215 a private key stored on the mobile node. The mobile node uses its 216 private key to sign its updates in the specified manner and the 217 public key available to the DNS server is used to verify that the 218 signature on the update was generated by the private key, and thus 219 the update is from the mobile node and not spoofed. 221 The security of this method relies on the protection of a mobile 222 node's private key. In cases where physical security of a mobile 223 device cannot be taken for granted, encrypting the private key with a 224 short pass phrase may help. This would require the user to input the 225 pass phrase in order to unlock the private key, either each time a 226 DNS update needs to be sent or once for a session which may span 227 several updates (similar to current passphrase agents). 229 Relying on the DNS for location management opens hosts using the 230 location management feature of this architecture up to a potential 231 impersonation vulnerability, related to stale DNS information. For 232 example, if a host (A) moves off of a network, but takes some time 233 before reconnecting and updating its DNS record, another host (B) may 234 acquire its old address. Another host (C) wishing to connect to some 235 service on A, will look up A's address using the DNS, and begin 236 communicating with B. If B can impersonate A suitably enough to fool 237 C, then some sensitive information might be divulged. For typical 238 mobile service users today, this scenario is not expected to cause 239 many problems, but may be a concern for some. The problem can be 240 avoided completely if A has notification that it is going offline for 241 some time, then it might either preemptively remove its vulnerable 242 DNS records, or update them to the address of some cooperating host 243 that will provide its services in the interim. 245 5. Binding Updates 247 In the transport layer mobility architecture, movement detection and 248 location management are provided outside the transport protocol. 249 Triggers exist between the movement detection algorithm and the 250 transport to initiate the transport's updating of its IP address 251 bindings when an address is obtained in a new network, and likewise a 252 trigger exists between movement detection and location management to 253 update the mobile node's primary address in the DNS. The detail of 254 this process which is not codified in this document, is the exact 255 means a transport protocol uses to perform binding updates. This is 256 dependent on the specific transport protocol, and the ability may be 257 native in some transports, while requiring an extension to others. 258 This section provides some examples of how various groups have 259 implemented binding updates in the SCTP and TCP transport protocols, 260 and an appendix shows an in-depth timing diagram of how the 261 architecture fits together and functions with one particular 262 transport protocol. 264 Due to SCTP's built-in ability to have transport associations bound 265 to multiple addresses, binding updates in SCTP are a fairly natural 266 extension. The only addition required to the base protocol is 267 implementation of ASCONF chunks [20]. Several proposals have 268 simultaneously appeared from different groups for using these chunks 269 to do binding updates in a transport layer mobility scheme (TraSH 270 [21], mSCTP [22], Cellular SCTP [23]). In particular, we shall 271 describe the operation of the TraSH scheme. 273 With TraSH, handoffs begin after a mobile node enters a new network 274 and receives a router advertisement and configures an address in the 275 new network. In the architecture described in this document, these 276 functions would occur under the responsibility of the movement 277 detection procedures. TraSH then adds the new IP address into 278 existing SCTP associations in addition to any old addresses in the 279 association. As the mobile node moves further into the coverage area 280 of the new network and discovers it is better connected there, it 281 changes the primary destination address in its SCTP associations. At 282 this point, the mobile node also uses the new address and new network 283 to initiate new associations and updates its location management 284 information. Finally, as connectivity with old networks degrades and 285 is lost, the mobile node deletes the corresponding addresses from its 286 SCTP associations. The architecture describe in this document 287 provides the location management services, and the ASCONF extension 288 to SCTP provides all that is needed for binding updates (new address 289 addition, change of primary address, and removal of old addresses). 290 A timing diagram of the entire procedure may be found in the 291 appendix. 293 Unlike SCTP, TCP was not originally designed with the idea of being 294 bound to multiple addresses simultaneously, so binding updates for 295 TCP have generally been implemented in a completely different manner. 296 While it would be possible to define TCP options similar to SCTP's 297 ASCONF extension, to allow for the same granularity in adding, 298 prioritizing, and deleting addresses, most TCP mobility work has 299 simply focused on rebinding the currently used address (for example 300 Migrate [24], and TCP-R [25]). This address replacement logically 301 takes place at the same time as the change of primary address with 302 TraSH, at the point where movement detection has observed and 303 configured a new network AND determined that connectivity there is 304 superior to that in the network whose address is currently used in 305 the TCP connection. The old address is completely replaced by the 306 new one in the transport control block and used to initiate new 307 connections at this point. 309 Properly doing binding updates in TCP requires slightly more work, in 310 that proposals must be careful to ensure that the binding updates are 311 not spoofable, usually by some cryptographic means, and TCP lacks any 312 standardized features that can provide this. For example the Migrate 313 proposal for mobile TCP uses an elliptic curve Diffie-Hellman key 314 exchange to authenticate the binding updates. The key data is 315 negotiated at connection setup time via additional options. Other 316 transports that do not currently include negotiation of cryptographic 317 keys at startup will have to provide their own methods for this, or 318 risk vulnerability to possible remote redirection attacks. 320 The architecture described in this document leaves the exact format 321 and functioning of binding updates to be specifically defined for 322 each transport protocol that wishes to use the architecture. What is 323 provided, is a common means of movement detection and location 324 updates. 326 6. Comparison with Mobile IP 328 Mobile IP [1] has been adopted as a standard for enabling host 329 mobility in the Internet architecture. Mobile IP provides mobility 330 support at the network layer, allowing all transports and 331 applications built on top of it to transparently work on mobile 332 hosts. The current Mobile IP approach, in IPv4, suffers from a 333 number of drawbacks, however. 335 For Mobile IP to function, a mobile node must have a home agent (HA) 336 in its home network. In addition, foreign agents (FA) must be 337 deployed in each foreign network the mobile node might attach to. 338 These architectural elements are not commonly found in the Internet 339 architecture. Thus, there is a strong reliance on network 340 administrators to both deploy and configure these agents. 342 The triangle routes set up by Mobile IP add additional latency to the 343 round-trip path that packets follow. The redirection and 344 encapsulation of packets at the HA into a tunnel results in a waste 345 of bandwidth and is especially expensive if the tunnel to the care-of 346 address has high delay. If the network path between the HA and 347 care-of address is disturbed, connectivity between the mobile node 348 and corresponding hosts may be broken, even though the disturbance 349 doesn't affect the direct paths between them. In addition, due to 350 the use of spoofed source addresses by numerous large-scale 351 distributed denial of service attacks and worm propagation, many 352 routers implement ingress filtering [4], which blocks packets that 353 seem to originate from a topologically impossible location. Since 354 mobile nodes use their static home IP addresses as a source addresses 355 in packets they send, these outgoing packets may be dropped by 356 routers in the foreign network. 358 Triangular routing can be removed using either route optimization or 359 reverse-tunneling. Route optimization procedures have been studied 360 for Mobile IP. However, they are currently not standardized. 361 Furthermore, implementing route optimization will either require 362 support from routers or major changes to end-hosts, including those 363 which are not necessarily mobile. Reverse-tunneling [5] allows 364 mobile nodes to tunnel all network traffic through the HA. The 365 downside to using topologically correct reverse tunnels is that the 366 inefficient side of the triangle route is used in both directions 367 rather than just one, further exacerbating the problems with 368 bandwidth and delay. 370 Also, stateful firewalls and NATs generally rely on seeing a TCP 371 SYN exchange to instantiate the state that allows them to process 372 packets correctly. If a mobile host with an existing TCP connection 373 changes network attachment points, firewalls and NATs are likely to 374 drop its packets and break the connection. Since many popular 375 applications use TCP, this is a problem. A similar problem applies 376 to services on the mobile host (using any transport protocol) when it 377 moves behind a NAT. 379 As a mobile host moves between networks, it may be disconnected for a 380 short period as the host detects a new network and registers the new 381 location with the HA. This could result in packet loss at the higher 382 layers if packets are sent to the old care-of address, and are not 383 buffered or redirected by the network. Smooth handover methods have 384 been investigated, but are not yet standard, and are likely to 385 require additional work on the part of routers. 387 Since changes in network point of attachment occur transparently when 388 using Mobile IP, transport protocols that keep state about the 389 network path and base their behaviors on that state may not adapt to 390 the new network in an efficient manner. For example, TCP keeps state 391 including an estimate of the round-trip time [8] and the available 392 capacity [7] of a network path. These properties may vary widely 393 between the various points of attachment that a mobile node 394 encounters. Without warning that a transition between networks is 395 taking place, the transport layer can do nothing to help smooth the 396 transition, such as pausing its transmissions, reprobing the network, 397 or sending zero-window advertisements causing peers to do the same. 399 Mobile IP provides no protection against bogus HAs or FAs. Malicious 400 users in a network may configure home and foreign agents that can be 401 used to either compromise the privacy of a mobile node's data or deny 402 it service. For example, a bogus HA might be set up to monitor a 403 mobile node's traffic even when it was away in a foreign network. A 404 bogus FA could likewise be configured to monitor the traffic of 405 visiting mobile nodes. Either bogus HA or FA advertisements could be 406 used to slow the registration process as a denial of service attack. 408 In a Mobile IP system, there is no location privacy for mobile nodes. 409 Since mobile nodes always use a fixed IP address which is from their 410 home network, foreign agents can use this address to infer where 411 nodes are from both geographically (since addresses are used for 412 routing) and organizationally (since address blocks are ownership is 413 not private). Since an HA redirects packets to the care-of addresses 414 of mobile nodes, HAs have similar information regarding a mobile 415 node's current location. 417 Many of the downsides to the Mobile IP approach are artifacts of its 418 place in the protocol stack. Since Mobile IP resides in the network 419 layer, it's features are tied to services provided by the network 420 infrastructure rather than the end hosts. This makes the end-users' 421 capacity for mobility dependent upon the actions of their service 422 providers. Implementing mobility as a feature of the transport layer 423 can move some power back to the users and offer mitigations to many 424 of the listed drawbacks in the Mobile IP system. 426 The transport layer mobility architecture described in this document 427 requires no additional network infrastructure aside from what IP 428 networks currently provide. 430 With mobility anchored in the transport layer, there is implicit 431 route optimization. Packets move directly from end source to end 432 destination, with no indirection. There are no triangle routes. 434 Topologically correct endpoint addresses are always used with 435 transport layer mobility, which make the system robust to ingress 436 filtering. 438 In transport layer mobility, transport protocols are explicitly aware 439 of changes in their network attachment status. This allows 440 transports to take the proper action in order to smooth transitions 441 into the new networks, like pausing transmissions during the handover 442 and reseting congestion control state. 444 Stateful firewalls and NATs may still pose a problem for mobile 445 transport protocols, although potentially less-so than with Mobile 446 IP. For example, TCP can be extended for mobility by setting the SYN 447 bit on the first segment in an ongoing mobile connection which comes 448 from a new address. This pokes a hole for the connection in such 449 devices. Other transport protocols that are affected by NATs may or 450 may not find similar protocol-specific solutions. 452 The transport layer mobility architecture does not use HAs or FAs and 453 so is immune to bogus agents. The system is however vulnerable to 454 bogus DHCP servers. This problem is shared by the entire networks a 455 bogus DHCP server resides on, however, harming both mobile and static 456 nodes that use DHCP for configuration. In practice, non-authorized 457 DHCP servers can be quickly located and removed from production 458 networks. 460 Transport layer mobility provides a different amount of location 461 privacy than Mobile IP. Corresponding nodes always know the mobile 462 node's current location with transport layer mobility, although this 463 information is more hidden from the home network, and the identity of 464 the mobile node is more hidden from the foreign network. No active 465 agents are charged with keeping state about a host. As the DNS is 466 used for location management, a node's current location is always 467 known and globally available information. Updating a mobile node's 468 location in DNS is, however, only required if the node is running 469 services that it desires be globally reachable for new sessions. If 470 this is not the case, or if its services can be located via some 471 other mechanism (for example, via a connection to a peer-to-peer 472 network that is persistent across the node's movements due to 473 transport layer mobility), then a mobile node need not advertise its 474 current location in the DNS. Encrypting binding and location updates 475 would remove any identification of a mobile node's "home". 476 Additionally, dynamic DNS service could be provided by any party - 477 not necessarily in a "home" network - so some degree of anonymousness 478 is possible using transport layer mobility. 480 Transport layer mobility enables "soft" handovers (not involving the 481 teardown of connectivity at one point before it is re-established 482 elsewhere) to be achieved for nodes having multiple interfaces or 483 even single interfaces using technologies like software radios. This 484 type of activity might also be possible in the Mobile IP framework. 486 This allows for the decoupling of registration on the new network's 487 interface and ongoing data transfer on the old network's interface, 488 further smoothing a node's handover between networks. 490 The current specification for Mobile IPv6 [3] mitigates some of the 491 problems discussed for Mobile IPv4, although still lacks some 492 features in comparison with transport layer mobility. 494 MIPv6 does not require FAs to be deployed in foreign networks. 495 However, HAs are still needed as additional infrastructure in the 496 Internet. The specification supports route optimization as a 497 standard feature. As with transport layer mobility, location privacy 498 from the the corresponding nodes is not provided, and as in version 499 4, there is no location privacy from the home network nor identity 500 privacy from the foreign network. 502 MIPv6 can coexist with ingress filtering by using the Home Address 503 Option to ensure topologically correct addressing. MIPv6 must still 504 support packet encapsulation in its bidirectional tunneling mode. 505 Also, HAs are still required to encapsulate data packets at least 506 during the initial stage of the binding update procedure. This 507 coupling of data forwarding and location management raises issues 508 regarding scalability of MIPv6; the HA may still become a network 509 bottleneck. 511 IPsec is a built-in part of MIPv6, which is used for securing the 512 binding update, while in version 4, separate security mechanisms are 513 used based on statically configured security associations [9]. 515 NAT devices may still exist in an IPv4-IPv6 overlay network, at least 516 in the near future. The incompatibility between NAT and IPsec [10] 517 may create a problem for MIPv6. As in NAT traversal for Mobile IP 518 version 4 [11], some special protocol format will need to be defined 519 to allow operation of MIPv6 through NATs. 521 Higher layer protocols, such as reliable transports like TCP and 522 SCTP, will still have no information about handovers, since all the 523 MIPv6 operation is transparent to the transport layer. 525 Some proposals in the IETF MIPSHOP group (particularly FMIPv6 and 526 HMIPv6) exist to lessen the latency of the handover and the amount of 527 packet loss that may occur. 529 7. Layer Interactions 531 Typically, the division of labor between protocols is clear in the 532 Internet architecture. This is true of the basic requirements for 533 packet service such as routing, addressing, ordering, and 534 reliability. The proper place in the stack for more advanced 535 features like mobility is unclear, because such a feature was not 536 required when the stack layers were initially created. The mobility 537 extension of the architecture defined in this document stretches 538 across several layers. It uses network and application layer 539 protocols for movement detection (IP and DHCP), an application 540 protocol for location management (DNS), and handles binding updates 541 in individual transport protocols (examples given for TCP and SCTP). 543 The literature is full of diverse approaches to mobility. 544 Particularly, Mobile IP is a proposed standard [1]. While section 545 Section 6 lists a number of reasons why the approach outlined in this 546 document may be preferred over Mobile IP (versions 4 and 6), it is 547 possible to use both approaches simultaneously. This would enable 548 mobility support through Mobile IP for transport protocols that have 549 not been extended to use this document's mobility architecture, and 550 would simultaneously allow a more pleasant mobility experience to 551 transport protocols that do interface with this architecture. 553 For example, in the current MIPv6 specification, a mobile node can 554 initiate communications to another node using either the mobile 555 node's home address or its current care-of address. By using the 556 care-of address, the mobile node can establish an efficient 557 communication channel to any other node, an not simply those that 558 support route optimization and have established the proper network 559 bindings. However, the connection duration is limited to the 560 lifetime of the care-of address. Transport layer mobility can be 561 used as a means to extend the connection over multiple care-of 562 addresses. Thus, transport layer mobility might provide a valuable 563 benefit to applications requiring long-lived connections. 565 Thus, mobility at both the transport and network layers may be able 566 to co-exist when both residing on the same node. However, 567 complications arise when a mobile node acts as a mobile router (MR), 568 providing network mobility (NEMO) [26][27]. With NEMO, the MR builds 569 a bi-directional tunnel to its home agent, thus providing mobility to 570 hosts and networks attached to it. 572 As a result, nodes behind a mobile router are: 573 o Unaware of any changes in network attachment. 574 o No longer the mobile endpoint and thus, do not own a unique 575 care-of address on the foreign network. 577 o Subject to all packets being transparently tunneled to the MR's 578 home network. 580 By masking movement and providing nodes with addresses from the MR's 581 home network, the algorithms outlined in this document for movement 582 detection and location management are no longer applicable for the 583 duration that node stays attached to that MR. Thus, attachment to a 584 mobile router is treated as a single foreign network. Should the 585 node detach from the mobile router and move to a different mobile or 586 foreign network, it behaves normally following the architecture 587 outlined in this document. All this is done without any special 588 requirements by either entity. 590 The mobile router MAY wish to notify hosts with mobility awareness of 591 changes in attachment, so that transport mobility aware hosts can 592 take appropriate action to reprobe the network paths. However, 593 specification of any such communication does not currently exist. 594 Also, mobile routers MUST tunnel packets that follow the architecture 595 outlined in this document and MUST NOT split those connections as an 596 attempt to provide route optimization. 598 8. Security Considerations 600 Security and privacy concerns have been addressed, where relevant, 601 throughout this document. The security of the transport layer 602 mobility architecture is mainly dependent upon the authentication of 603 the location updates and binding updates. The location updates 604 specified use dynamic DNS with the SIG(0) extension for 605 authentication, and are thus vulnerable to any holes this system's 606 design or implementation may possess. The exact format of the 607 binding updates is specific to each transport protocol. The examples 608 presented for SCTP and TCP take different approaches to 609 authenticating the binding updates, each of which has its own 610 security considerations. 612 9 References 614 [1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 615 2002. 617 [2] Eddy, W., "At What Layer Does Mobility Belong?", to appear in 618 IEEE Communications, 2004. 620 [3] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 621 IPv6", RFC 3775, June 2004. 623 [4] Ferguson, D., "Network Ingress Filtering: Defeating Denial of 624 Service Attacks which employ IP Source Address Spoofing", RFC 625 2827, May 2000. 627 [5] Montenegro, G., "Reverse Tunneling for Mobile IP, Revised", RFC 628 3024, January 2001. 630 [6] Hain, T., "Architectural Implications of NAT", RFC 2993, 631 November 2000. 633 [7] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 634 Control", RFC 2581, April 1999. 636 [8] Paxson, V. and M. Allman, "Computing TCP's Retransmission 637 Timer", RFC 2988, November 2000. 639 [9] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP 640 Authentication, Authorization, and Accounting Requirements", 641 RFC 2977, October 2000. 643 [10] Aboba, B. and W. Dixon, "IPsec-Network Address Translator (NAT) 644 Compatibility Requirements", RFC 3715, March 2004. 646 [11] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network 647 Address Translation (NAT) Devices", RFC 3519, April 2003. 649 [12] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 650 for IP Version 6 (IPv6)", RFC 2461, December 1998. 652 [13] Thomson, S. and T. Narten, "IPv6 Stateless Address 653 Autoconfiguration", RFC 2462, December 1998. 655 [14] Deering, S., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 656 Carney, "Dynamic Host Configuration Protocol for IPv6 657 (DHCPv6)", RFC 3315, July 2003. 659 [15] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 660 September 1991. 662 [16] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 663 March 1997. 665 [17] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 666 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 667 April 1997. 669 [18] Wellington, B., "Secure Domain Name System (DNS) Dynamic 670 Update", RFC 3007, November 2000. 672 [19] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( 673 SIG(0)s )", RFC 2931, September 2000. 675 [20] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Rytina, I., 676 Belinchon, M. and P. Conrad, "Stream Control Transmission 677 Protocol (SCTP) Dynamic Address Reconfiguration", September 678 2003. 680 [21] Fu, S., Atiquzzaman, M., Ma, L., Ivancic, W., Lee, Y., Jones, 681 J. and S. Lu, "TraSH: A Transport Layer Seamless Handover for 682 Mobile Networks", University of Oklahoma Technical Report 683 OU-TNRL-04-10, January 2004. 685 [22] Koh, S., Lee, M., Riegel, M., Ma, M. and M. Tuexen, "Mobile 686 SCTP for Transport Layer Mobility", February 2004. 688 [23] Aydin, I. and C. Shen, "Cellular SCTP: A Transport-Layer 689 Approach to Internet Mobility", October 2003. 691 [24] Snoeren, A. and H. Balakrishnan, "An End-to-End Approach to 692 Host Mobility", Proc. of the Sixth Annual ACM/IEEE 693 International Conference on Mobile Computing and Networking, 694 August 2000. 696 [25] Funato, D., Yasuda, K. and H. Tokuda, "TCP-R: TCP Mobility 697 Support for Continuous Operation", International Conference on 698 Network Protocols (ICNP), October 1997. 700 [26] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, 701 "Network Mobility (NEMO) Basic Support Protocol", 702 draft-ietf-nemo-basic-support-03 (work in progress), June 2004. 704 [27] Ernst, T. and H-Y. Lach, "Network Mobility Support 705 Terminology", draft-ietf-nemo-terminology-01 (work in 706 progress), February 2004. 708 Authors' Addresses 710 Wesley M. Eddy 711 NASA GRC/Verizon FNS 713 EMail: weddy@grc.nasa.gov 715 Joseph Ishac 716 NASA GRC 718 EMail: jishac@grc.nasa.gov 720 Mohammed Atiquzzaman 721 University of Oklahoma 723 EMail: atiq@ou.edu 725 Appendix A. Mobility Example Using TraSH 727 In this diagram, "New AR" is the access router in a new network that 728 the Mobile Node is moving into, while maintaining a connection with 729 corresponding node CN, and Location Manager is a dynamic DNS server. 730 This example uses the ASCONF chunks that are part of a proposed SCTP 731 extension, as conceived by the TraSH adaptation of SCTP for mobility 732 support. The steps that TraSH goes through in order to perform 733 movement detection, binding updates, and location updates are shown 734 in order. 736 Mobile Node New AR CN DHCP Server Location Manager 737 | | | | | 738 | Router ADV | | | | 739 |<--------------| | | | 740 | | | 741 | Request IP address from new domain | | 742 |------------------------------------------->| | 743 | Assign IP address to MN | | 744 |<-------------------------------------------| | 745 | | | 746 | Add_IP ASCONF Chunk | | | 747 |------------------------------>| | | 748 | Add_IP ACK | | | 749 |<------------------------------| | | 750 | | | | 751 ~ ~ ~ ~ 752 ~ ~~~~~~~~~~~~~~~~~~ MN Continue Moving ~~~~~~~~~~~~~~~~~~~ ~ 753 ~ ~ ~ ~ 754 | Set_Primary ASCONF Chunk | | | 755 |------------------------------>| | | 756 | | | | 757 | Location Update Request | 758 |----------------------------------------------------------->| 759 | | 760 | Set_Primary ACK | | | 761 |<------------------------------| | | 762 | | | | 763 | Location Update Reply | 764 |<-----------------------------------------------------------| 765 ~ ~ ~ ~ 766 ~ ~~~~~~~~~~~~~~~~~~ MN Continue Moving ~~~~~~~~~~~~~~~~~~~ ~ 767 ~ ~ ~ ~ 768 | Delete_IP ASCONF Chunk | | | 769 |------------------------------>| | | 770 | Delete_IP ACK | | | 771 |<-------- 773 Intellectual Property Statement 775 The IETF takes no position regarding the validity or scope of any 776 Intellectual Property Rights or other rights that might be claimed to 777 pertain to the implementation or use of the technology described in 778 this document or the extent to which any license under such rights 779 might or might not be available; nor does it represent that it has 780 made any independent effort to identify any such rights. Information 781 on the procedures with respect to rights in RFC documents can be 782 found in BCP 78 and BCP 79. 784 Copies of IPR disclosures made to the IETF Secretariat and any 785 assurances of licenses to be made available, or the result of an 786 attempt made to obtain a general license or permission for the use of 787 such proprietary rights by implementers or users of this 788 specification can be obtained from the IETF on-line IPR repository at 789 http://www.ietf.org/ipr. 791 The IETF invites any interested party to bring to its attention any 792 copyrights, patents or patent applications, or other proprietary 793 rights that may cover technology that may be required to implement 794 this standard. Please address the information to the IETF at 795 ietf-ipr@ietf.org. 797 Disclaimer of Validity 799 This document and the information contained herein are provided on an 800 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 801 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 802 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 803 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 804 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 805 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 807 Copyright Statement 809 Copyright (C) The Internet Society (2004). This document is subject 810 to the rights, licenses and restrictions contained in BCP 78, and 811 except as set forth therein, the authors retain all their rights. 813 Acknowledgment 815 Funding for the RFC Editor function is currently provided by the 816 Internet Society.