idnits 2.17.1 draft-ietf-mobileip-simple-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 171 instances of too long lines in the document, the longest one being 103 characters in excess of 72. ** The abstract seems to contain references ([3G-IMT], [RouteOpt], [MobIP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RouteOpt' is mentioned on line 34, but not defined == Missing Reference: 'IP-TNL' is mentioned on line 144, but not defined == Unused Reference: 'IP-Tnl' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'Route-Opt' is defined on line 419, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3G-IMT' ** Obsolete normative reference: RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DiffServ') ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv3' ** Obsolete normative reference: RFC 2002 (ref. 'MobIP') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. 'Route-Opt' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP-Tnl' Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Martin Johnsson 2 INTERNET-DRAFT Ericsson 4 draft-ietf-mobileip-simple-01.txt March, 1999 6 Simple Mobile IP (SMIP) 8 Status Of This Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. Internet-Drafts are working documents of 12 the Internet Engineering Task Force (IETF), its areas, and its working groups. 13 Note that other groups may also distribute working documents as Internet- 14 Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months and may 17 be updated, replaced, or obsoleted by otherdocuments at any time. It is 18 inappropriate to use Internet-Drafts as reference material or to cite them 19 other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes an alternative to the support for IP mobility compared 31 to the solution outlined and specified in [MobIP]. As the title of the solution 32 implies, it addresses the problems with the overall complexity of the current 33 Mobile IP solution including some of the proposed extensions as outlined in 34 [RouteOpt], [3G-IMT]. This more simplistic approach relies on two basic 35 prerequisites: Development made in recent years, and also development foreseen 36 in a near-term future, regarding certain key protocols and techniques for name- 37 to-address resolution, directory services, address assignment, and roaming 38 support; and also the fact that the solution is suited for usage within one 39 organizational scope. 41 1.0 Introduction 43 The support for IP mobility as specified in [MobIP] relies on the concept of 44 home agent (HA) and foreign agent (FA). The home agent resides on the same IP 45 subnet as the mobile terminal (MT) is normally connected to, and a foreign 46 agent resides on subnets which mobile terminals may visit. Through the use of a 47 fixed IP address and a care-of address assigned to the MT , the user may 48 connect its terminal to some other subnet besides the subnet which the terminal 49 is normally connected to. IP packets destined for the MT will be forwarded by 50 the HA to the FA and then finally to the MT (by means of tunneling). Packets 51 from the MT can be sent directly towards its destination. 53 The solution has several drawbacks (some just a result of evolving 54 technologies, no offense): 55 - triangular routing, i.e. assymetric routing with respect to topology 56 - inefficient use of link resources through the use of tunneling which may span 57 a large number of router hops 58 - support for QoS is not straightforward with triangular routing 59 - inefficient use of network resources through non-optimal routing 60 - the use of a fixed (and public) IP address, which is not the normal case in 61 today's Internet and intranets 63 To address at least some of these drawbacks, one basically has to look for a 64 more symmetric and distributed solution, possibly as similar as possible as the 65 solution in use for fix terminals, with the addition of the need for support 66 for mobility. It is also then possible to let the solution rely on existing 67 protocols, or protocols/technologies under development. In this context, it is 68 important to distinguish between session mobility and user mobility: 70 Session mobility: Applications and TCP sessions will not be affected by the 71 fact that the terminal is moving within and between subnets, except for some 72 packet loss which may result out from a handover between radio base stations. 74 User mobility: A user of an MT which may get connected to a subnet within the 75 context of an administrative domain, e.g. an intranet. 77 For datacom-type of applications, e.g. Web browsing, the requirement is to 78 support session mobility throughout a geographical area which has continious 79 radio coverage. Typical examples of such areas are buildings, campuses, and 80 public "hot spots" like hotels, conference centers, airports. 82 Regarding user mobility, the requirement is that it doesn't need to be better 83 than what is supported for fix terminals, though it should be noted that mobile 84 terminals may drive the need for increased support for user mobility. The 85 latter becomes more and more evident with the introduction of nomadic computing 86 and the nomadic office. Clearly, this means that the notion of "home" and 87 "foreign" don't make sense anymore. As a consequence, those concepts have been 88 removed and instead been renewed in this memo. 90 This background, prerequistes, and requirements, is the foundation for the 91 solution outlined in this memo. 93 2.0 A reference model 95 The following reference model is referred to in the following sections 96 describing the protocol layout and basic procedures. 98 |-------------------- Mobile LAN -------------------| 100 |------------- Local LAN ------------| 102 +----+ +---+ +----+ +-----+ 103 | | Air Interf. | | Fixed LAN | | | | 104 | MT |- - - - - - - |RBS|------------| LR |--------| MER | 105 | | | | | | | | 106 +----+ +---+ +----+ +-----+ 108 FIGURE 1. SMIP Reference Model 110 A Mobile Terminal (MT) connects to a LAN through the Radio Base Station (RBS) 111 via the air interface, e.g. Hiperlan 2 or 802.11. The RBS functions as a bridge 112 on the LAN. The Local Router (LR) routes packets to/from the subnet which the 113 MT is currently connected to. The Mobility-Enabled Router (MER) is a router 114 handling routing packets to and from Mobile LANs (MLAN). Each MT is connected 115 to an MLAN as well as a local LAN. Thus, an MT has two IP addresses for one 116 network interface (the air interface in this case); one reflecting connectivity 117 to the local LAN handled by LR, and one IP address reflecting connectivity to 118 the MLAN. An LLAN may have both wireless and fixed hosts connected to it, while 119 an MLAN only has wireless hosts connected. 121 As the MT is moving, the connectivity towards the local LAN is changing, and 122 thus also the IP address reflecting this change in local LAN connectivity. The 123 IP address reflecting the MLAN connectivity is never changing. 125 The protocol reference model for the MT is depicted in figure 2 below. 127 +-----------+ 128 |Application| 129 +-----------+ 130 | Transport | 131 +-----------+ 132 | IP-MLAN | 133 +-----------+ 134 | IP-LLAN | 135 +-----------+ 136 | Link | 137 +-----------+ 138 | Physical | 139 +-----------+ 141 FIGURE 2. MT protocol reference model. 143 The two levels of IP are stacked on top of each other, just like IP-in-IP 144 tunneling as defined in [IP-TNL]. As descibed above and according to the 145 protocol reference model, the transport layer will not experience any change in 146 IP address. 148 Other protocols of importance for the solution, and which are not shown in 149 figure 2, are DHCP and the optional use of IPsec protocols. The use of these 150 protocols will be further detailed below. 152 3. Protocols and procedures 154 3.1 Bootup phase 156 In the bootup phase, it is proposed that the MT accuires the two IP addresses 157 needed for the two IP layers, IP-MLAN and IP-LLAN, by means of extensions 158 through a set of new options to DHCP. 160 During the bootup phase, the MT will also retrieve information via DHCP about 161 the address of the MER handling the MLAN to which the MT is connected to. 163 3.2 IP packet handling 165 3.2.1 IP packet handling at the MT 167 The transport layer will submit packets for transmission to IP-MLAN. IP-MLAN 168 will set the source IP address to the address corresponding to the IP address 169 of the MLAN, and the destination IP address to the address of the packet's 170 final destination. IP-MLAN will in turn submit the IP packet to IP-LLAN. IP- 171 LLAN will set the source IP address to the address corresponding to the IP 172 address of the LLAN, and the destination IP address to the address of the MER. 173 Finally, the address is submitted to the link and physical layers for 174 transmission over the local LAN. 176 Upon reception, IP packets from the physical and link layers are delivered to 177 IP-LLAN. The contents of the IP header is checked to specifically verify that 178 the source IP address is the address of the MER. The IP header for the IP-LLAN 179 layer is then stripped off, and then the contents left of the packet is 180 delivered to the IP-MLAN layer. The IP-MLAN strips off the IP header of this 181 layer, and finally the packet is delivered to the transport layer. 183 3.2.2 IP packet handling at LR 185 Packets from the MT will be routed to the MER by LR as indicated by the IP 186 destination address. 188 Packets to the MT will be routed onto the local LAN which the MT is connected 189 to. 191 3.2.3 IP packet handling at MER 193 MER will receive packets from MTs destined for the MER itself. MER strips off 194 the IP header of this packet, and then uses the information in the IP header 195 related to MLAN for purposes of routing the packet to its final destination. 197 Packets received by the MER with an destination IP address associated to an MT 198 on an MLAN, will be encapsulated into an IP packet. The source IP address is 199 set to the address of MER, and the destination IP address to the address of the 200 MT pertaining to the local LAN which the MT is currently connected to. 202 3.3 IP mobility handling 204 As the MT moves, a shift may occur with respect to the connectivity to the 205 local LAN. It is currently out of the scope of this memo how an MT discovers 206 that a shift is underway with respect to LLAN. But for example, the protocols 207 at the air interface may include protocol support for indicating this shift in 208 connectivity. The current version of this memo only deals with the handling of 209 the IP connectivity and the correlation between MLAN and LLAN, and also the 210 necessary change of IP address at the IP-LLAN level due to change in LLAN 211 connectivity. 213 3.3.1 IP connectivity 215 As with fixed terminals, there is no need to advertise connectivity between an 216 MT and a router on a LAN (LR and MER in the SMIP case). 218 3.3.2 MLAN - LLAN correlation 220 To enable correct routing of messages from the MER towards an MT, the MER must 221 at each instance of time know the current location of the MT, i.e. to know 222 which LLAN the MT is currently connected to. Due to a possible movement of the 223 terminal, this connectivity may change over time. Thus, the MER must receive 224 indications about an MT's current location. 226 It is proposed that the MLAN - LLAN binding has limited lifetime, and thus the 227 binding must be periodically refreshed to avoid timer expiration. In addition, 228 it is also proposed that the MT triggers an update of this binding to the MER 229 whenever a change in this mapping occurs. If the timer expires, the mapping 230 shall be removed by the MER, and MER shall treat the MT as being unreachable. 232 This memo proposes to use an extension to ICMP for handling of IP connectivity 233 and correlation between MLAN and LLAN. The procedure of using an ICMP message 234 for this purpose, is to send an ICMP both periodically and triggered according 235 to the above description. 237 3.3.3 IP address for LLAN connectivity 239 Due to the movement of the MT, LLAN connectivity may change, and thus the IP 240 address reflecting this connectivity. 242 It is proposed that when the MT receives an indication that an handover between 243 RBSs results in that the MT moves from one LLAN to another, the MT requests a 244 new IP address for the LLAN level by means of a possible set of new options to 245 DHCP. 247 3.3.4 Moving out and within radio coverage 249 An MT may temporarily be moved out of the range of radio coverage from RBSs, 250 and later once again be moved within the range of radio coverage. This is 251 similar as unplugging and then replug a fix terminal to a LAN. 253 When an MT detects that it once again is connected to a local LAN, it is 254 proposed that the MT reinitiates DHCP requests for the two IP addressess 255 reflecting connectivity towards an LLAN and an MLAN. This may in turn lead to 256 that the MT will be assigned new IP addresses for one or both of the two IP 257 levels. DHCP may need to be extended with a set of new options to support this 258 scenario. 260 3.4 Security support 262 IPsec protocols such as the Authentication Header and the Encapsulating 263 Security Payload defined in [AH] and [ESP] respectively, may be inserted 264 between the two IP headers of the IP-LLAN and IP-MLAN levels. The rules that 265 govern the use of IPsec protocols shall comply to the IPsec protocol suite of 266 recommendations when using IPsec in tunnel mode of operation. 268 Other security mechanisms may be supported as well, for instance on the 269 transport level, but that is outside the scope of this memo. 271 3.5 ARP and broadcasts 273 As the MLAN is "virtual" in the sense that the mapping between the logical and 274 physical structure of the MLAN is not one-to-one, e.g. it may include router 275 hops, the Address Resolution Protocol as defined in [ARP] shall not be used. It 276 shall also be specifically noted that for clarity and consistency the MT shall 277 be, with respect to addressing, associated to the address of the IP-MLAN level. 278 This results in that all traffic to/from an MT must pass through the MER. 280 But, for the purpose of conserving bandwidth, and to make most efficient use of 281 network resources, ARP may be used to forward traffic directly between the 282 source and the destination hosts, iff they are located on the same LLAN. In 283 this case, the IP-LLAN protocol layer is "empty", i.e. no IP header is added by 284 IP-LLAN. 286 The assymetric traits of this option with respect to routing shall be used with 287 great care. 289 Other forms of broadcasts are sent just as unicast packets encapsulated to the MER, which will retransmit the broadcast encapsulated in unicast packets to all MTs on the MLAN. 291 3.6 Multicast 293 In IP, the Internet Group Management Protocol as defined in [IGMP] is the 294 foundation for group membership registration. A host reports group membership 295 to its local router by responding to group membership queries. The important 296 characteristic to note about IP multicast in this scope of work, is that it is 297 receiver-oriented, meaning that IP multicast addresses indicates a set of 298 destination hosts, i.e. those being members of a certain group. It has nothing 299 to do with the source IP address of a host. 301 With respect to mobility, the IP multicast paradigm is well suited to serve 302 also this aspect of connectivity, as both IGMP and the different routing 303 protocols for multicast rely on the soft state concept. As a result, the graph 304 of the distribution tree for a multicast group adapts depending on the current 305 locations of group members. 307 3.6.1 Receiving multicast 309 The discussion above results in that an MT with respect to IP multicast and 310 traffic directed towards an MT (i.e. MT is a group member), works exactly the 311 same as for fixed terminals. This means that the IP-MLAN layer is "empty" in 312 this direction of traffic. 314 One issue though may arise in the event of IGMP version 3 [IGMPv3]. In this 315 case, a member may indicate from which sender(s) the member host is willing to 316 receive IP multicast packets from. This may lead to the need for specifically 317 indicating the very source of a membership report, which then must correspond 318 to the address of the IP-MLAN. This is still for further study. 320 3.6.2 Transmitting multicast 322 When transmitting multicast packets, the source of the packets must equal the 323 address of the IP-MLAN level for reasons of consistency. Thus, IP multicast 324 packets are transmitted in the same way as unicast packets described above in 325 section 3. 327 This may lead to non-optimal distribution trees for IP multicast, especially 328 for those members which are nearer to the MT source than the MER. Possible 329 work-arounds or alternative solutions can quite easily be deduced, e.g. 330 snooping into tunneled datagram or shortcutting the IP-LLAN level, but this is 331 for further study. 333 An alternative option would be to transmit the multicast packets 334 unencapsulated, i.e. by shortcutting the IP-LLAN level. 336 4. Miscelleneaous 338 4.1 DNS 340 The DNS will resolve to addresses corresponding to the IP-MLAN level. Regarding 341 the IP-LLAN level, this address is invisible to DNS. 343 4.2 DHCP servers and MER/MLAN relation 345 The DHCP servers will through the responses back to the MT, give proposal(s) as 346 to which MER the MT can use and establish connectivity. The proposal should 347 preferably be based on the current location of the MT, i.e. LLAN connectivity, 348 and what MER(s) that are available in the "neighborhood" of MT's current 349 location. Proposals on MER may also be based on some estimate of how the MT may 350 move around, which results in some kind of judgement of tradeoffs based on 351 routing performance, QoS, etc. 353 This is not part of the current scope of this memo to define any algorithms or 354 rules, that can be used to decide upon appropriate proposal(s) on MER(s). For 355 the time being, it will be up to the management of DHCP servers to configure 356 appropriate MER proposals. 358 4.3 QoS 360 QoS is a difficult and still pending issue also for fixed terminals, and 361 becomes emphasized and highlighted for mobile terminals. On the IP layer, an MT 362 may make use of either of the two proposed solutions for QoS provisioning 363 defined as of today: Integrated Services using RSVP or Differentiated Services 364 (DiffServ) using the DS field in the IP header. 366 The main issue in SMIP as outlined in this memo, is the IP tunnel between the 367 MT and the MER, and of course the fact that the terminal is mobile. 369 Regarding RSVP, [RSVP-Tnl] describes how end-to-end RSVP sessions map to tunnel 370 sessions. Due to the aspect of a mobile terminal, the reservations for the 371 tunnel between the MT and the MER must be created dynamically on demand, which 372 is outlined as one of the options in [RSVP-Tnl]. 374 Regarding DiffServ as defined in [DiffServ], there are no specific rules as how 375 to perform mapping of a service indicated by the DS field between an end-to-end 376 service and the service for a tunnel. This will be a matter of local policies. 378 4.4 Handover between MERs 380 It could be envisaged that the need for session mobilility should be extended 381 beyond the limitation of connectivity to one MER, meaning that a "handover" 382 would be performed from one MER to another, possibly leading to a change in 383 MLAN connectivity, depending on how to solve this form of mobility. The support 384 for session mobility between MERs is for further study. 386 5. Notice Regarding Intellectual Property Rights 388 Ericsson may seek patent or other intellectual property protection 389 for some or all of the technologies disclosed in this document. If any 390 standards arising from this disclosure are or become protected by one or 391 more patents assigned to Ericsson, Ericsson intends to disclose 392 those patents and license them on reasonable and non-discriminatory 393 terms. Future revisions of this draft may contain additional information 394 regarding specific intellectual property protection sought or received. 396 6. References 398 [3G-IMT] : IP Mobility Architecture Framework, C. B. Becker et al, 399 Work in Progress 401 [AH]: IP Authentication Header, S. Kent et al, RFC 2402 403 [ARP]: Ethernet Address Resolution Protocol., D. C. Plummer, RFC 826 405 [DiffServ]: An Architecture for Differentiated Services, S. Blake et al, 406 RFC 2475 408 [ESP] : IP Encapsulating Security Payload, S. Kent et al, RFC 2406 410 [IGMP] : Internet Group Management Protocol, Version 2, W. Fenner, RFC 2236 412 [IGMPv3] : Internet Group Management Protocol, Version 3, B. Cain et al, 413 Work in Progress 415 [IP-Tnl]: IP Encapsulation within IP, C. Perkins, RFC 2003 417 [MobIP]: IP Mobility Support, C. Perkins, RFC 2002 419 [Route-Opt] : Route Optimization in Mobile IP, C. Perkins et al, 420 Work in Progress 422 [RSVP-Tnl] : RSVP Operation over IP Tunnels, A. Terzis et al, Work in Progress 423 7. Authors' Address 425 Martin Johnsson 426 Ericsson Radio Systems 427 Wireless LAN Systems 428 Esplanaden 3C 429 SE-164 80 Stockholm, Sweden 430 Martin.Johnsson@era.ericsson.se