idnits 2.17.1 draft-ietf-mobileip-lowlatency-handoffs-v4-11.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 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2740. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2753. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2717), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 15 longer pages, the longest (page 39) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1302 has weird spacing: '...) HRqst v...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (3 October 2005) is 6770 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) ** Obsolete normative reference: RFC 3344 (ref. '1') (Obsoleted by RFC 5944) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 3012 (ref. '7') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-08 -- Possible downref: Normative reference to a draft: ref. '11' -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '14') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '16') (Obsoleted by RFC 4306) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. El Malki, Editor 3 INTERNET-DRAFT Athonet 4 Expires: April 2006 3 October 2005 6 Low Latency Handoffs in Mobile IPv4 7 9 Status of this memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (C) The Internet Society (2005). All Rights Reserved. 35 Abstract 37 Mobile IPv4 describes how a Mobile Node can perform IPv4-layer 38 handoffs between subnets served by different Foreign Agents. In 39 certain cases, the latency involved in these handoffs can be above 40 the threshold required for the support of delay-sensitive or real- 41 time services. The aim of this document is to present two methods to 42 achieve low-latency Mobile IPv4 handoffs. In addition, a combination 43 of these two methods is described. The described techniques allow 44 greater support for real-time services on a Mobile IPv4 network by 45 minimising the period of time when a Mobile Node is unable to send or 46 receive IPv4 packets due to the delay in the Mobile IPv4 Registration 47 process. 49 TABLE OF CONTENTS 51 1. Introduction.....................................................3 52 1.1. Terminology.................................................4 53 1.2. The Techniques..............................................5 54 1.3. L2 triggers.................................................7 55 1.4. Requirements language.......................................9 56 2. Requirements.....................................................9 57 3. The PRE-REGISTRATION Handoff Method.............................10 58 3.1. Operation..................................................10 59 3.2. Network-Initiated Handoff..................................13 60 3.3. Mobile-Initiated Handoff...................................14 61 3.4. Obtaining and Proxying nFA Advertisements..................16 62 3.4.1. Inter-FA Solicitation.................................16 63 3.4.2. Tunneled nFA Advertisements...........................17 64 3.5. Caching Router Advertisements..............................17 65 3.6. Movement Detection, MN and FA Considerations...............18 66 3.7. L2 Address Considerations..................................19 67 3.8. Applicability of PRE-REGISTRATION Handoff..................20 68 4. The POST-REGISTRATION Handoff Method............................21 69 4.1. Two Party Handoff..........................................22 70 4.2. Three Party Handoff........................................26 71 4.3. Renewal or Termination of Tunneling Service................31 72 4.4. When will the MN perform a Mobile IPv4 Registration?.......31 73 4.5. Handoff Request (HRqst) Message format.....................32 74 4.6. Handoff Reply (HRply) Message..............................34 75 4.7. Handoff To Third (HTT) Message.............................36 76 4.8. Applicability of POST-REGISTRATION Handoff Method..........36 77 5. Combined Handoff Method.........................................37 78 6. Layer 2 and Layer 3 Handoff timing Considerations...............38 79 7. Reverse Tunneling Support.......................................39 80 8. Handoff Signaling Failure Recovery..............................39 81 8.1. PRE-REGISTRATION Signaling Failure Recovery................39 82 8.1.1. Failure of PrRtSol and PrRtAdv........................39 83 8.1.2. Failure of Inter-FA solicitation and advertisement....40 84 8.2. POST-REGISTRATION Signaling Failure Recovery...............40 85 8.2.1. HRqst Message Dropped.................................40 86 8.2.2. HRply Message Dropped.................................41 87 9. Generalized Link Layer and IPv4 Address (LLA) Extension.........41 88 9.1. 3GPP2 IMSI Link Layer Address and Connection ID Extension..42 89 9.2. 3GPP IMSI Link Layer Address Extension.....................43 90 9.3. Ethernet Link Layer Address Extension......................44 91 9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension...44 92 9.5. Solicited IPv4 Address Extension...........................45 93 9.6. Access Point Identifier Extension..........................45 94 9.7. FA IPv4 Address Extension..................................46 95 10. IANA Considerations............................................46 96 10.1. New Extension values......................................47 97 10.2. Generalized Link Layer and IP Address Identifier (LLA) Sub- 98 type values.....................................................47 99 10.3. New Message Type and Code.................................47 100 11. Security Considerations........................................48 101 12. Acknowledgements...............................................50 102 13. Editor's Address...............................................50 103 14. Contributing Authors...........................................50 104 15. References.....................................................51 105 15.1. Normative References......................................51 106 15.2. Informative References....................................51 107 Appendix A - Gateway Foreign Agents................................52 108 Appendix B - Low Latency Handoffs for Multiple-Interface MNs.......53 109 Appendix C - PRE_REGISTRATION Message Summary......................54 111 1. 112 Introduction 114 Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IPv4- 115 layer handoff between subnets served by different Foreign Agents 116 (FAs). In certain cases, the latency involved in handoff can be 117 above the threshold required for the support of delay-sensitive or 118 real-time services. The aim of this document is to present two 119 techniques to achieve low-latency Mobile IPv4 handoff during movement 120 between FAs. A further combination of these two techniques is also 121 described. The presented techniques allow greater support for real- 122 time services on a Mobile IPv4 network by minimising the period of 123 time during which a MN is unable to send or receive IPv4 packets due 124 to the delay in the Mobile IPv4 Registration process. One or more of 125 these techniques may be required to achieve fast Mobile IPv4 handoffs 126 over different wireless technologies (e.g. WLAN, Cellular, WiMAX, 127 Flash-OFDM etc.). Each wireless technology has different layer-2 128 handoff procedures and the best low latency technique for each 129 scenario should be used to optimize the handoff performance. Further 130 deployment and experimentation is required to determine which 131 technique is best suited to the wireless technologies in terms of 132 implementation and performance. Therefore the authors encourage 133 further performance measurements and work on Low-Latency-over-foo 134 specifications in collaboration with the appropriate wireless 135 technology fora to describe the applicability to different wireless 136 layer-2s. 138 In the rest of this section, terminology used throughout the document 139 is presented, the handoff techniques are briefly described, and the 140 use of link layer information is outlined. In Section 2, a brief 141 description of requirements is presented. Section 3 describes the 142 details of the PRE-REGISTRATION handoff technique, while Section 4 143 describes the details of the POST-REGISTRATION handoff technique. In 144 Section 5, a combined method using the two handoff techniques 145 together is presented. Section 6 discusses Layer 2 and Layer 3 146 handoff timing considerations. Section 7 discusses reverse tunneling 147 support, Section 8 describes mechanisms to recover from message 148 failures while Section 9 describes protocol extensions required by 149 the handoff techniques. Sections 10 and 11 discuss IANA and security 150 considerations. Finally the three appendices discuss additional 151 material related to the handoff techniques. Appendix A gives a short 152 introduction to Regional Registrations [11] which can be used 153 together with low latency handoffs. Appendix B discusses low latency 154 handoff when a MN has multiple wireless L2 interfaces, in which case 155 the techniques in this document may not be necessary. Appendix C 156 provides a summary of the messages used in PRE-REGISTRATION. 158 1.1. 159 Terminology 161 This section presents a few terms used throughout the document. 163 oFA - old Foreign Agent (FA), the FA involved in handling the 164 care of address of a Mobile Node (MN) prior to a Layer 3 165 (L3) handoff. 167 nFA - new Foreign Agent, the FA anticipated to be handling a 168 MN's care of address after completion of an L3 handoff. 170 aFA - anchor Foreign Agent, the FA that is currently handling 171 the network end of the tunnel in POST-REGISTRATION. 173 L2 handoff - Movement of a MN's point of Layer 2 (L2) 174 connection from one wireless access point to another. 176 L3 handoff - Movement of a MN between FAs which involves 177 changing the care-of address (CoA) at Layer 3 (L3). 179 L2 trigger - Information from L2 that informs L3 of particular 180 events before and after L2 handoff. The descriptions of L2 181 triggers in this document are not specific to any particular 182 L2, but rather represent generalizations of L2 information 183 available from a wide variety of L2 protocols. 185 L2-MT - An L2 trigger that occurs at the MN informing of 186 movement to a certain nFA (Mobile Trigger). 188 L2-ST or source trigger - An L2 trigger that occurs at oFA, 189 informing the oFA that L2 handoff is about to occur. 191 L2-TT or target trigger - An L2 trigger that occurs at nFA, 192 informing the nFA that a MN is about to be handed off to 193 nFA. 195 L2-LU - An L2 trigger that occurs at the MN or nFA, informing 196 that the L2 link between MN and nFA is established. 198 L2-LD - An L2 trigger that occurs at the oFA, informing the oFA 199 that the L2 link between MN and oFA is lost. 201 low latency handoff - L3 handoff in which the period of time 202 during which the MN is unable to receive packets is 203 minimized. 205 low loss handoff - L3 handoff in which the number of packets 206 dropped or delayed is minimized. Low loss handoff is often 207 called smooth handoff. 209 seamless handoff - L3 handoff that is both low latency and low 210 loss. 212 bi-directional edge tunnel (BET) - A bidirectional tunnel 213 established between two FAs for purposes of temporarily 214 routing a MN's traffic to/from it on a new subnet without 215 requiring the MN to change CoA. 217 ping-pong - Rapid back and forth movement between two wireless 218 access points often due to failure of L2 handoff. Ping-pong 219 can occur if radio conditions for both the old and new 220 access points are about equivalent and less than optimal for 221 establishing a good, low-error L2 connection. 223 network-initiated handoff - L3 handoff in which oFA or nFA 224 initiates the handoff. 226 mobile-initiated handoff - L3 handoff in which the MN initiates 227 the handoff. 229 MN or FA identifier - An IPv4 address of a MN or FA, or an L2 230 identifier that can be resolved to the IPv4 address of a MN 231 or FA. If the identifier is an L2 identifier, it may be 232 specific to the L2 technology. 234 1.2. 235 The Techniques 237 Mobile IPv4 was originally designed without any assumptions about the 238 underlying link layers over which it would operate so that it could 239 have the widest possible applicability. This approach has the 240 advantage of facilitating a clean separation between L2 and L3 of the 241 protocol stack, but it has negative consequences for handoff latency. 242 The strict separation between L2 and L3 results in the following 243 built-in sources of delay: 245 - The MN may only communicate with a directly connected FA. This 246 implies that a MN may only begin the registration process after 247 an L2 handoff to nFA (new FA) has completed. 249 - The registration process takes some non-zero time to complete as 250 the Registration Requests propagate through the network. During 251 this period of time the MN is not able to send or receive 252 IPv4 packets. 254 This document presents techniques for reducing these built-in delay 255 components of Mobile IPv4. The techniques can be divided into two 256 general categories, depending on which of the above problems they 257 are attempting to address: 259 - Allow the MN to communicate with the nFA while still connected 260 to the oFA. 262 - Provide for data delivery to the MN at the nFA even before the 263 formal registration process has completed. 265 The first category of techniques allows the MN to "pre-build" its 266 registration state on the nFA prior to an underlying L2 handoff. 267 The second category of techniques allow for service to continue 268 uninterrupted while the handoff is being processed by the network. 270 Three methods are presented in this draft to achieve low-latency L3 271 handoff, one for each category described above and one as a 272 combination of the two: 274 - PRE-REGISTRATION handoff method, 276 - POST-REGISTRATION handoff method, 278 - combined handoff method. 280 The PRE-REGISTRATION handoff method allows the MN to be involved in 281 an anticipated IPv4-layer handoff. The MN is assisted by the network 282 in performing an L3 handoff before it completes the L2 handoff. The 283 L3 handoff can be either network-initiated or mobile-initiated. 284 Accordingly, L2 triggers are used both in the MN and in the FA to 285 trigger particular L3 handoff events. The PRE-REGISTRATION method 286 coupled to L2 mobility helps to achieve seamless handoffs between 287 FAs. The basic Mobile IPv4 concept involving advertisement followed 288 by registration is supported and the PRE-REGISTRATION handoff method 289 relies on Mobile IPv4 security. No new messages are proposed, except 290 for an extension to the Agent Solicitation message in the 291 mobile-initiated case. 293 The POST-REGISTRATION handoff method proposes extensions to the 294 Mobile IPv4 protocol to allow the oFA (old FA) and nFA (new FA) to 295 utilize L2 triggers to set up a bi-directional tunnel between oFA and 296 nFA that allows the MN to continue using its oFA while on nFA's 297 subnet. This enables a rapid establishment of service at the new 298 point of attachment which minimizes the impact on real-time 299 applications. The MN must eventually perform a formal Mobile IPv4 300 registration after L2 communication with the new FA is established, 301 but this can be delayed as required by the MN or FA. Until the MN 302 performs registration, the FAs will setup and move bidirectional 303 tunnels as required to give the MN continued connectivity. 305 The combined method involves running a PRE-REGISTRATION and a 306 POST-REGISTRATION handoff in parallel. If the PRE-REGISTRATION 307 handoff can be performed before the L2 handoff completes, the 308 combined method resolves to a PRE-REGISTRATION handoff. However, if 309 the PRE-REGISTRATION handoff does not complete within an access 310 technology dependent time period, the oFA starts forwarding traffic 311 for the MN to the nFA as specified in the POST-REGISTRATION handoff 312 method. This provides for a useful backup mechanism when completion 313 of a PRE-REGISTRATION handoff cannot always be guaranteed before the 314 L2 handoff completion. 316 It should be noted that the methods described in this document may be 317 applied to MNs having a single interface (e.g. Wireless LAN 318 interface) or multiple interfaces (e.g. one WLAN and one cellular 319 interface). However, the case of multiply-interfaced MNs needs 320 special consideration, since the handoff methods described in this 321 document may not be required in all cases (see Appendix B). 323 1.3. 324 L2 triggers 326 An L2 trigger is a signal of an L2 event. In this document, the L2 327 events relate to the L2 handoff process. One possible event is early 328 notice of an upcoming change in the L2 point of attachment of the 329 mobile node to the access network. Another possible event is the 330 completion of relocation of the mobile node's L2 point of attachment 331 to a new L2 access point. This information may come explicitly from 332 L2 in a solicited or unsolicited manner, or it may be derived from L2 333 messages. Although the protocols outlined in this document make use 334 of specific L2 information, Mobile IPv4 should be kept independent of 335 any specific L2. L2 triggers are an abstraction mechanism for a 336 technology specific trigger. Therefore, an L2 trigger that is made 337 available to the Mobile IPv4 stack is assumed to be generic and 338 technology independent. The precise format of these triggers is not 339 covered in this document, but the information required to be 340 contained in the L2 triggers for low latency handoffs is specified. 342 In order to properly abstract from the L2, it is assumed that one of 343 the three entities - the MN, oFA, or nFA - is made aware of the need 344 for an L2 handoff, and that the nFA or MN can optionally also be made 345 aware that an L2 handoff has completed. A specific L2 will often 346 dictate when a trigger is received and which entity will receive it. 347 Certain L2s provide advance triggers on the network-side, while 348 others provide advance triggers on the MN. Also, the particular 349 timing of the trigger with respect to the actual L2 handoff may 350 differ from technology to technology. For example, some wireless 351 links may provide such a trigger well in advance of the actual 352 handoff. In contrast, other L2s may provide little or no 353 information in anticipation of the L2 handoff. 355 An L2 trigger may be categorized according to whether it is received 356 by the MN, oFA, or nFA. Table 1 gives such a categorization along 357 with information contained in the trigger. The methods presented in 358 this document operate based on different types of L2 triggers as 359 shown in Table 1. Once the L2 trigger is received, the handoff 360 processes described hereafter are initiated. The three triggers: L2- 361 ST, L2-TT and L2-MT are independent of each other and are not 362 expected to occur together since each will trigger a different type 363 of handoff behaviour. 365 +-------------+----------------------+------------------------------+ 366 | L2 trigger | Mobile | Source | 367 | | Trigger | Trigger | 368 | | (L2-MT) | (L2-ST) | 369 +-------------+----------------------+------------------------------+ 370 | Recipient | MN | oFA | 371 +-------------+----------------------+--------------+---------------+ 372 | Method | PRE | PRE | POST | 373 | | mobile-initiated | network- | source | 374 | | | initiated | trigger | 375 +-------------+----------------------+--------------+---------------+ 376 | When? | sufficiently before | sufficiently | sufficiently | 377 | | the L2 handoff | before L2 | before L2 | 378 | | so that MN can | handoff for | handoff for | 379 | | solicit PrRtAdv | FA to send | oFA & nFA to | 380 | | from oFA. | PrRtAdv | exchange | 381 | | | to MN. | HRqst/HRply. | 382 +-------------+----------------------+--------------+---------------+ 383 | Parameters | nFA identifier | nFA identifier, MN identifier| 384 +-------------+----------------------+------------------------------+ 386 Table 1 - L2 Trigger 387 (continued on next page) 389 +------------+----------------------+---------------+---------------+ 390 | L2 trigger | Target | Link-Up | Link-Down | 391 | | Trigger | (L2-LU) | (L2-LD) | 392 | | (L2-TT) | | | 393 |------------+----------------------+---------------+---------------+ 394 | Recipient | nFA | MN or nFA | oFA | 395 |------------+-----------+----------+---------------+---------------+ 396 | Method | PRE | POST | PRE & POST | POST | 397 | | network | target | | | 398 | | initiated | trigger | | | 399 |------------+----------------------+---------------+---------------+ 400 | When? | | when radio | when radio | 401 | | same as | link between | link between | 402 | | source trigger | MN & nFA is | MN and oFA | 403 | | | established | is lost | 404 |------------+----------------------+---------------+---------------+ 405 | Parameters | oFA identifier | @MN: nFA IPv4 | MN identifier | 406 | | MN identifier | or L2 addr. | | 407 | | | @nFA: MN IPv4 | | 408 | | | or L2 addr. | | 409 +------------+----------------------+---------------+---------------+ 411 Table 1 - L2 Trigger 412 (continued from previous page) 414 1.4. 415 Requirements language 417 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 418 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 419 described in [2]. 421 2. 422 Requirements 424 The following requirements are applicable to low-latency handoff 425 techniques and are supported by the methods in this document: 427 - to provide low-latency and low loss handoff for real time services, 429 - to have no dependence on a wireless L2 technology, 431 - to support inter- and intra-access technology handoffs, 433 - to limit wireless bandwidth usage. 435 3. 436 The PRE-REGISTRATION Handoff Method 438 The PRE-REGISTRATION handoff method is based on the normal Mobile 439 IPv4 handoff procedure specified in [1], according to which: 441 - an advertisement for an FA is received by an MN, 442 - the advertisement allows the MN to perform movement detection, 443 - the MN registers with the FA. 445 The basic messages specified in [1] are extended to carry information 446 required to achieve fast handoffs. The PRE-REGISTRATION method 447 allows both the MN and FA to initiate the layer-3 handoff and it can 448 make use of L2 triggers on either the FA or MN side, depending on 449 whether network-initiated or mobile-initiated handoff occurs. 451 PRE-REGISTRATION supports the normal Mobile IPv4 model [1] and 452 optionally also the Regional Registration model [11]. There can be 453 advantages in implementing [11] together with Low Latency Handoff 454 mechanisms, in particular in cases where the HA is at a distance (in 455 terms of delay) from the nFA. The time required for the handoff 456 procedure to complete can be reduced by using a closer local HA, 457 called Gateway Foreign Agent (GFA) in [11]. However implementation 458 of [11] is not required by PRE-REGISTRATION. PRE-REGISTRATION also 459 supports movement where a new AAA transaction must occur to 460 authenticate the MN with a new domain. 462 3.1. 463 Operation 465 The PRE-REGISTRATION Handoff mechanism is summarized in Figure 1. 467 +---------+ 468 | HA (GFA)|<---------+ 469 +---------+ | 4. (Reg)RegReq 470 | 5. (Reg)RegReply 471 v 472 +-----+ 1a. PrRtSol +-----+ 473 | | -----------------> | nFA | 474 | oFA | 1b. PrRtAdv | | 475 +-----+ <----------------- +-----+ 476 ^ | ^ 477 (2a. PrRtSol)| | 2b | 478 | | PrRtAdv | 3. (Reg)RegReq 479 | | | 480 | v --------------------+ 481 +-----+ / 482 | MN | 483 +-----+ - - - - - -> 484 Movement 486 Figure 1 - PRE-REGISTRATION Handoff Protocol 488 The following steps provide more detail on the protocol: 490 1. Message 1a is a Proxy Router (Agent) Solicitation (PrRtSol) 491 from oFA to nFA. It is a Mobile IP agent solicitation 492 containing an identifier for the nFA (i.e. IP address or L2 493 address) in a Generalised Link Layer and IP Address Extension 494 (see section 9.). When message 1a is received by the nFA 495 containing nFA's correct identifier in the LLA extension, the 496 nFA MUST return the Proxy Router Advertisement (Agent 497 Advertisement) in message 1b. Message 1b is simply nFA's 498 agent advertisement containing the nFA layer 2 address in a 499 Generalised Link Layer and IP Address (LLA) Extension (see 500 9.3). Messages 1a and 1b SHOULD occur in advance of the 501 PRE-REGISTRATION Handoff in order not to delay the handoff. 502 For this to occur, oFA SHOULD solicit and cache 503 advertisements from neighbouring nFAs using messages 1a and 504 1b, thus decoupling the timing of this exchange from the rest 505 of the PRE-REGISTRATION Handoff. When the L3 handoff is 506 initiated by a target L2 trigger at nFA (L2-TT), message 1b 507 equals message 2b and is sent unsolicited directly to MN 508 (tunneled by nFA to MN through oFA) instead of being relayed 509 by oFA. 511 2. Message 2a is a Proxy Router Solicitation (PrRtSol) from MN 512 to oFA. It is different from a normal Router (Agent) 513 Solicitation since it is soliciting an advertisement from a 514 router different from the one receiving this message. It is 515 a Mobile IP agent solicitation containing an identifier for 516 the nFA (i.e. IP address or L2 address) in a Generalised Link 517 Layer and IP Address Extension (see section 9.). The 518 presence of message 2a indicates that the handoff is mobile- 519 initiated and its absence means that the handoff is network- 520 initiated. In mobile-initiated handoff, message 2a occurs if 521 there is an L2 trigger in the MN to solicit for a Proxy 522 Router Advertisement (PrRtAdv). When message 2a is received 523 by the oFA it MUST return the Proxy Router Advertisement 524 (Agent Advertisement) in message 2b. This is simply nFA's 525 agent advertisement containing the nFA layer 2 address in a 526 Generalised Link Layer and IP Address (LLA) Extension (see 527 9.3). In network-initiated source-triggered handoff, the L2 528 trigger occurs at oFA and oFA MUST relay the Agent 529 Advertisement in message 2b without the need for the MN to 530 solicit. Note that it is also possible for nFA to advertise 531 directly to the MN in the network-initiated target-trigger 532 case (section 3.2). 534 3. The MN performs movement detection upon receipt of a 535 solicited or unsolicited Agent Advertisement and, if 536 required, it sends a Registration Request (RegReq) message 537 [1] in message 3 to nFA. When a local Gateway Foreign Agent 538 (GFA) is present this message can optionally be a Regional 539 Registration Request (RegRegReq) [11]. Message 3 is routed 540 through oFA since the MN is not directly connected to nFA 541 prior to the L2 handoff. 543 4. Messages 4 and 5 complete the standard Mobile IPv4 544 Registration [1] or optionally Regional Registration [11] 545 initiated with message 3. The Registration Request MUST 546 contain the MN's layer 2 address in a Generalised Link Layer 547 and IP Address Extension (see 3.7 and 9). This identifier may 548 be a plain Ethernet address or an identifier specific to the 549 wireless technology. If the MN is not already connected to 550 nFA, the Registration Reply in message 5 MUST be buffered by 551 the nFA and unicast to the MN on-link as soon as the MN 552 connects to nFA (i.e. L2-LU trigger at nFA which can be 553 implemented by the MN sending an Agent Solicitation or 554 optionally using special layer 2 techniques which are outside 555 the scope of this document). This is necessary since the MN 556 may have to detach from oFA, due to the wireless L2 557 connection, before it receives the Reply. The MN's L2 558 address is obtained using the extensions in Section 9, as 559 described in 3.7. Figures 2 and 3 illustrate this procedure. 561 5. If the Registration is successful packets for the MN are 562 tunnelled from the HA (or GFA) to the nFA and then to the MN. 564 PRE-REGISTRATION is not dependent on [11]. However if the HA is at a 565 distance (in terms of delay) from the nFA, the use of a local GFA may 566 reduce the time required for the handoff procedure to complete. 568 The time at which the L2 trigger is received by the oFA or MN, 569 thereby triggering the PRE-REGISTRATION handoff, compared to the time 570 at which the actual L2 handoff occurs is important for the optimal 571 performance of the low latency handoff. That is, in the optimal case 572 the L2 trigger will be received and the four messaging steps of PRE- 573 REG described above will be completed (i.e. up to when the 574 Registration Request is processed by HA or GFA) before the MN moves. 575 Optimally the Registration Reply and the first packet redirected by 576 the HA (or GFA) to nFA will reach the MN at the moment in which the 577 MN's L2 link to nFA is fully established. The MN would therefore not 578 suffer any disruption due to the L3 handoff. This cannot always be 579 guaranteed unless particular implementation techniques are used. To 580 alleviate a part of this timing problem the MN MAY set the S bit [1] 581 in Low Latency Registration Requests sent by the MN. This allows the 582 MN to receive packets at both oFA and nFA during the short layer 2 583 handoff time. Other techniques may be required such as L2 techniques 584 or buffering but these are outside the scope of this document. In 585 addition further handoff smoothing considerations may be required to 586 prevent the loss of packets in-flight between HA (or GFA) and oFA 587 while the MN performs a PRE-REGISTRATION handoff. These are also 588 outside the scope of this document. 590 Figures 2, 3, and 4 contain message timing diagrams for the network- 591 initiated and mobile-initiated PRE-REGISTRATION handoff procedures. 593 3.2. 594 Network-Initiated Handoff 596 As described in Table 1, a PRE-REGISTRATION handoff can be initiated 597 at oFA by a source trigger or at nFA by a target trigger. Figures 2 598 and 3 contain message timing diagrams for PRE-REGISTRATION network- 599 initiated handoff for source and target triggers. 601 A source-triggered network-initiated handoff occurs when an L2 602 trigger is received at the oFA informing it of a certain MN's 603 upcoming movement from oFA to nFA. The L2 trigger contains 604 information including the MN's identifier (i.e. the IPv4 address 605 itself or an identifier which can be resolved to the IPv4 address) 606 and the nFA's identifier. An identifier may be an IPv4 address or 607 something specific to the wireless technology (e.g. Base Station or 608 Access Point Identifier). A target-triggered network-initiated 609 handoff occurs when an L2 trigger is received at the nFA informing it 610 of a certain MN's upcoming movement from oFA. This type of trigger 611 is also shown in Table 1 and contains information including the MN's 612 identifier and the oFA's identifier. 614 MN oFA nFA HA/GFA 615 | |<~~~~~~ L2-Source | | 616 | | Trigger | | 617 |<--------------------| | | 618 | PrRtAdv | | | 619 | | | | 620 |---------------------------------------->| | 621 | RegReq or | | | 622 | RegRegReq (routed via oFA) |------------------->| 623 | | RegReq or RegRegReq| 624 | | | 625 | Buffered ~~~~~>|<-------------------| 626 |---------------------------------------->| (Reg)RegReply | 627 | Agent Solicitation | | 628 | (sent when MN connects to nFA) | | 629 | | | 630 |<----------------------------------------| | 631 | (Reg)RegReply | | 632 | (sent when nFA receives Solicitation or L2-LU) | 634 Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram 635 (Network-Initiated, Source Trigger) 637 In a source-triggered handoff, when oFA receives the trigger (L2-ST) 638 it MUST send message 2b, the Proxy Router Advertisement (PrRtAdv), to 639 the MN. The PrRtAdv is nFA's agent advertisement [1] with one of the 640 link-layer extensions described in sections 9 (i.e. 9.3). The use of 641 the contents of this extension is described in section 3.7. Messages 642 1a and 1b SHOULD be exchanged by oFA and nFA before the L2 trigger is 643 received (see section 3.4.1). Message 2a is not used. 645 MN oFA nFA HA/GFA 646 | | L2-Target~~~~~~~~>| | 647 | | Trigger | | 648 | |...................| | 649 |<--------------------------------------- | | 650 | (PrRtAdv) |...................| | 651 | | Tunnelled Agent Advertisement | 652 | | | | 653 |---------------------------------------->| | 654 | RegReq. or | | | 655 | RegRegReq (routed via oFA) |------------------->| 656 | | RegReq or RegRegReq| 657 | | | 658 | Buffered ~~~~~>|<-------------------| 659 |---------------------------------------->| (Reg)RegReply | 660 | Agent Solicitation | | 661 | (sent when MN connects to nFA) | | 662 | | | 663 |<----------------------------------------| | 664 | (Reg)RegReply | | 665 | (sent when nFA receives Solicitation or L2-LU) | 667 Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram 668 (Network-Initiated, Target Trigger) 670 In a target-triggered handoff, when nFA receives the trigger (L2-TT) 671 it MUST tunnel an Agent Advertisement to the MN through oFA to 672 initiate the L3 handoff. The inner Advertisement is unicast by nFA 673 to MN, thus nFA treats the target-trigger as a Router (Agent) 674 Solicitation. This Advertisement is tunneled to oFA, which functions 675 as a normal router, decapsulating the Advertisement and forwarding it 676 to the MN. This message MUST be authenticated to prevent attacks 677 (see 3.4.2). 679 3.3. 680 Mobile-Initiated Handoff 682 As shown in Table 1, a mobile-initiated handoff occurs when an L2 683 trigger is received at the MN informing that it will shortly move to 684 nFA. The L2 trigger contains information such as the nFA's 685 identifier (i.e. nFA's IPv4 address or an identifier which can be 686 resolved to the nFA's IPv4 address). As an example, a Wireless LAN 687 MN may perform a scan to obtain the BSSID identifier of the Access 688 Point that is a potential handoff target (i.e. its signal is becoming 689 stronger). The message timing diagram is shown in Figure 4. 691 MN oFA nFA HA/GFA 692 |<~~~~~ L2-Trigger | | | 693 | | | | 694 |-------------------->| | | 695 | PrRtSol | | | 696 | | | | 697 |<--------------------| | | 698 | PrRtAdv | | | 699 | | | | 700 |---------------------------------------->| | 701 | RegReq or | | | 702 | RegRegReq (routed via oFA) |------------------->| 703 | | RegReq or RegRegReq| 704 | | | 705 | Buffered ~~~~~>|<-------------------| 706 |---------------------------------------->| (Reg)RegReply | 707 | Agent Solicitation | | 708 | (sent when MN connects to nFA) | | 709 | | | 710 |<----------------------------------------| | 711 | (Reg)RegReply | | 712 | (sent when nFA receives Solicitation or L2-LU) | 714 Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram 715 (Mobile-Initiated) 717 As a consequence of the L2 trigger (L2-MT) the MN MUST send message 718 1a, the Proxy Router Solicitation (PrRtSol). This message is a 719 unicast agent solicitation to oFA for a Proxy Router Advertisement 720 (PrRtAdv). This solicitation MUST have a TTL=1 as in [1]. The Proxy 721 Router Advertisement Solicitation unicast to oFA is an agent 722 solicitation with a special extension. The solicitation MUST have an 723 extension containing an FA identifier (i.e. IPv4 address or L2 724 address contained in an LLA extension, see section 9) because the MN 725 is soliciting another specific FA's advertisement from the oFA. This 726 specific FA will be the MN's nFA. The identifier is the IPv4 address 727 of the nFA or another identifier that can be used by the oFA to 728 resolve to nFA's IPv4 address. If the identifier is not an IPv4 729 address, it MAY be specific to the underlying wireless technology, 730 for example, an Access Point or Base Station Identifier (e.g. WLAN 731 BSSID) that can be mapped by oFA to the nFA IPv4 address as described 732 in 3.4.1. The extension containing the identifier is a subtype of 733 the Generalised Link-Layer Address extension described in Section 9. 735 Two extension subtypes have been defined to contain the nFA's IPv4 736 address and an access point identifier. They are called the 737 Solicited Agent IPv4 Address Extension and the Access Point 738 Identifier Extension, and are described in Sections 9.5 and 9.6. 739 These two extensions SHOULD NOT be present in the same PrRtSol 740 message. 742 When oFA receives the PrRtSol message it MUST reply to the MN with 743 the Proxy Router Advertisement (PrRtAdv, message 2b). The PrRtAdv is 744 simply the agent advertisement for the requested nFA, proxied by oFA. 745 In order to expedite the handoff, the actual nFA advertisement SHOULD 746 be cached by the oFA following a previous exchange with nFA, shown in 747 messages 1a and 1b, as specified in Section 3.5. The PrRtAdv message 748 MUST contain the nFA's L2 address (using the LLA extension in 9.3). 749 This is further described in section 3.7. 751 3.4. 752 Obtaining and Proxying nFA Advertisements 754 Since L2 triggers are involved in initiating PRE-REGISTRATION 755 handoff, the trigger timing SHOULD be arranged such that a full L3 756 PRE-REGISTRATION handoff can complete before the L2 handoff process 757 completes. That is, the L2 handoff should be completed after the 758 MN's Registration with the nFA is performed (message 3 in Fig.1). 759 The Registration MAY be transmitted in more than one copy (default 760 recommendation: 2) to reduce the probability that it is lost due to 761 errors on the wireless link. This would not apply to reliable 762 wireless links where retransmissions are performed at layer 2 in case 763 of error to guarantee packet delivery. 765 A PRE-REGISTRATION handoff in this case requires the MN to receive an 766 agent advertisement from the nFA through the old wireless access 767 point. How to achieve this is discussed in the following 768 subsections. Messages exchanged between FAs MUST be authenticated to 769 prevent impersonation attacks. The minimal requirement is that all 770 FAs involved in low latency handoffs MUST support manual pre- 771 configuration of security associations with other neighbouring FAs, 772 involving shared keys and the default algorithms of [1] (see Security 773 Considerations). 775 3.4.1. 776 Inter-FA Solicitation 778 This applies to the network-initiated source-triggered (L2-ST) and 779 mobile-initiated (L2-MT) cases only. Inter-FA solicitation assumes 780 that oFA has access to the IPv4 address of the nFA. The IPv4 address 781 of nFA is obtained by means of an L2 trigger at oFA in the 782 network-initiated case (see Section 3.2) or by means of the extension 783 to the Proxy Router Solicitation (PrRtSol) from the MN in the 784 mobile-initiated case (see Section 3.3). This extension to the 785 PrRtSol may contain an IPv4 address or another identifier, for 786 example an identifier of a Wireless Base Station such as the WLAN 787 BSSID. In the latter case the receiving oFA must implement a 788 mechanism to resolve the Base Station Identifier to an IPv4 address. 789 The default mechanism is to use a configured table of neighbouring 790 BSSID to FA IPv4 address mappings in each FA. Other automated 791 discovery mechanisms may also be used. 793 If oFA does not cache advertisements (see 3.5) once it receives an L2 794 trigger and obtains the address of the nFA for a specific MN it MUST 795 send a unicast agent solicitation (PrRtSol) to nFA. The nFA replies 796 to the oFA by unicasting an Agent Advertisement with appropriate 797 extensions (PrRtAdv). This method removes the TTL limitation of [1] 798 for Mobile IPv4 messages (i.e. TTL=1 is not applicable here). The 799 TTL limitation cannot be applied since oFA and nFA may be more than 800 one hop away and since it is unnecessary for a secured unicast 801 message. The ICMP solicitations and advertisements MUST be 802 authenticated and integrity protected. These messages MUST be 803 protected using ESP [10] to prevent attacks (see Security 804 Considerations section). An FA MUST NOT accept ICMP solicitations or 805 advertisements from sources that are not authenticated. 807 As a practical matter, oFA SHOULD pre-solicit and cache 808 advertisements from known neighboring FAs (see section 3.5) to avoid 809 performing the solicitation during an actual handoff procedure. 811 3.4.2. 812 Tunneled nFA Advertisements 814 This applies to the network-initiated target-triggered (L2-TT) case 815 only. Following a target trigger (L2-TT) the nFA MUST send a 816 tunneled agent advertisement to the MN through oFA. Tunneling nFA 817 advertisements assumes that the nFA is aware of the IPv4 address for 818 oFA and the MN. These IPv4 addresses are obtained by means of the FA 819 and MN contained in an L2 trigger received at nFA in the network- 820 initiated case (see Section 3.2). However in [1] the TTL must be 1 821 on Agent Advertisements from the nFA. Therefore tunneling 822 advertisements is applicable if the TTL limitation of [1] is relaxed. 823 For this purpose, a pre-established security association between oFA 824 and nFA MUST be in place to authenticate this message and relax the 825 TTL limitation. If the implementation requires this, a tunnel SHOULD 826 be configured when the inter-FA security association is established. 827 The tunneled ICMP advertisement MUST be secured using tunnel mode ESP 828 [10] between nFA and oFA. An FA MUST NOT accept tunneled ICMP 829 packets destined to it from sources that are not authenticated. 831 3.5. 832 Caching Router Advertisements 834 In the mobile-initiated (L2-MT) case and the network-initiated 835 source-triggered (L2-ST) case, the message exchange 1 in Figure 1 836 could impose an additional latency on the L3 handoff process if done 837 as part of the handoff procedure. In order to remove this source of 838 latency, the inter-FA Router (Agent) Solicitation and Advertisement 839 exchange SHOULD be performed in advance of handoff. A process SHOULD 840 be in place at the oFA to solicit its neighbouring nFAs at a 841 predefined time interval (MIN_SOLICITATION_INTERVAL). This interval 842 SHOULD NOT be set too small to avoid unnecessary consumption of 843 network bandwidth and nFA processing resources. The minimum value of 844 MIN_SOLICITATION_INTERVAL is 1 sec. If the FA Challenge/Response 845 mechanism in [7] is used then the MIN_SOLICITATION_INTERVAL MUST be 846 set to a value smaller then the window of time in which a challenge 847 remains valid so that the nFA challenge does not expire before the MN 848 issues the Registration Request. Therefore the recommended default 849 value for the MIN_SOLICITATION_INTERVAL in oFA is (0.5 * nFA's 850 CHALLENGE_WINDOW * nFA's Agent advertisement interval). The 851 CHALLENGE_WINDOW and Agent advertisement interval are defined in [7] 852 and [1] respectively. The minimum requirement is that the 853 MIN_SOLICITATION_INTERVAL MUST be manually configurable, while 854 possible autoconfiguration mechanisms are outside the scope of this 855 document. To allow advertisement caching in certain implementations 856 and in cases where the nFA advertisement interval is very small, it 857 MAY be necessary for the implementation in nFA to allow different 858 CHALLENGE_WINDOW and agent advertisement interval settings for its 859 nFA-oFA interface. 861 The oFA SHOULD cache the most recent advertisement from its 862 neighbouring nFAs. This advertisement MUST be sent to the MN in 863 message 2b with a TTL=1. The oFA SHOULD also have a mechanism in 864 place to create a list of neighbouring nFAs. The minimum requirement 865 for each FA is that it SHOULD allow manual configuration of a list of 866 nFA addresses that an MN could possibly perform an L3 handoff to. 867 The FA addresses in this list will depend on deployment and radio 868 coverage. It is also possible to specify another protocol to achieve 869 nFA discovery, but this is outside the scope of this document. 871 3.6. 872 Movement Detection, MN and FA Considerations 874 When the MN receives an Agent Advertisement with a Mobility Agent 875 extension, it performs actions according to the following movement 876 detection mechanism: the MN SHOULD be "Eager" to perform new 877 bindings. This means that the MN SHOULD perform Registrations with 878 any new FA from which it receives an advertisement (i.e. MN is 879 Eager), as long as there are no locally-defined policies in the MN 880 that discourage the use of the discovered FA. For example, the MN 881 could have a policy based on the cost of service. The method by 882 which the MN determines whether the FA is a new FA is described in 883 [1] and MAY use an FA-NAI extension [11]. By being "Eager" to perform 884 Registrations the MN reduces latency times. 886 The MN also needs to change its default router from oFA to nFA. The 887 MN MUST change its default router to nFA as soon as the 888 PRE-REGISTRATION procedure has completed (i.e. Registration Reply is 889 received by MN) as described in [1]. 891 Overall the MN behaves as described in [1] with the following 892 changes: the specified movement detection mechanism mentioned above 893 and the ability to use the L2-MT to initiate an agent solicitation 894 with a special extension (PrRtSol). Also, when the MN receives a L2- 895 LU trigger (i.e. new interface or link is up) it MUST immediately 896 send an Agent Solicitation [1] on that interface. An nFA that 897 receives an Agent Solicitation [1] will use it as an L2-LU trigger 898 event and according to [1] it will record the MN's IPv4/Layer 2 899 addresses (i.e. ARP entry). At that point the nFA starts delivering 900 data to the MN including the previously buffered Registration Reply. 901 The nFA MAY also use other L2 mechanisms to detect earlier that the 902 MN has attached to the new link and to start forwarding data to it. 903 The MN SHOULD NOT attempt to retransmit a low latency Registration 904 Request (i.e. Registration Request containing an LLA extension 905 described in 9.) when it does not receive the Registration Reply. 907 When moving from a PRE-REGISTRATION network to a normal Mobile IPv4 908 [1] network the MN will no longer receive PrRtAdv messages (i.e. 909 agent advertisements with the LLA extension). If the MN still 910 receives L2-MTs it will attempt to send PrRtSol messages. The normal 911 FA will reply with a normal agent advertisement [1]. If the MN does 912 not receive a PrRtAdv in reply to its PrRtSol, it MAY retransmit the 913 PrRtSol message once after PRE_SOL_INTERVAL seconds and then for 914 another PRE_SOL_ATTEMPTS times with exponential backoff of the 915 transmission interval. If a PrRtAdv is not received within 916 PRE_SOL_INTERVAL seconds after the last PrRtSol attempt, the MN MUST 917 stop sending PrRtSol messages until after a Registration with a new 918 FA is performed. The default value for PRE_SOL_ATTEMPTS is 2 and for 919 PRE_SOL_INTERVAL it is 1 second. It should be noted that the 920 performance of the movement detection mechanism mandated in 921 PRE-REGISTRATION (i.e. eager to register) may have sub-optimal 922 behaviour in a standard Mobile IPv4 [1] network. Therefore standard 923 movement detection mechanisms [1] should be used in plain Mobile IPv4 924 networks. Instead when the MN moves from a normal Mobile IPv4 [1] 925 network to a PRE-REGISTRATION network, the MN starts receiving L2-MT 926 triggers or PrRtAdv messages. When the MN receives L2-MT triggers or 927 PrRtAdv messages it SHOULD follow the PRE-REGISTRATION procedure. 929 If there is uncertainty as to which mode to choose (e.g. MN receives 930 messages from both PRE-REGISTRATION and normal FAs) the MN decides 931 based on its Registration status with the current FA. If the MN 932 already has a valid normal Mobile IPv4 Registration [1] with the 933 advertising FA, it SHOULD give priority to the PRE-REGISTRATION 934 procedure. Otherwise it SHOULD give priority to normal Mobile IPv4 935 [1] Registration procedure. The MN SHOULD NOT attempt to perform PRE- 936 REGISTRATION and standard Mobile IPv4 [1] Registrations in parallel. 938 3.7. 939 L2 Address Considerations 941 Some special considerations should be taken with respect to the 942 wireless system on which this handoff method is being implemented. 943 Consider an Ethernet-like system (e.g. IEEE 802.11) for example. In 944 PRE-REGISTRATION the MN is registering with an FA (nFA) that is not 945 its current first-hop router, therefore the L2 address of the 946 Ethernet frame containing the MN's Registration Request reaching the 947 nFA is not the MN's address. Therefore the FA MUST NOT use the 948 Ethernet address of the incoming Registration Request as the MN's L2 949 address as specified in [1]. This applies to the cases where the 950 wireless access points are bridges or routers and independently of 951 whether the FA is implemented in the wireless access points 952 themselves. In this case the MN's Registration Request (or Regional 953 Registration Request) MUST use an L2 address extension to the 954 Registration message. Such an L2 address is either the same L2 955 address that remains constant as the MN moves, or it is the MN's L2 956 address at nFA. To communicate its L2 address, the MN includes a 957 Generalised Link Layer and IP Address Extension (see Section 9) with 958 its Registration Request (or Regional Registration Request) message. 959 If this extension is present the FA MUST use the L2 address contained 960 in the extension to communicate with the MN. If a particular 961 wireless L2 technology has defined a special interface to the 962 wireless network that allows the FA to resolve the mapping between an 963 MN's IPv4 address and its L2 address without the need to use the 964 extension, the L2 address extension contents may be discarded. For 965 the same reasons above, the MN MUST NOT use the source L2 address of 966 the Agent Advertisement message (PrRtAdv) as its default router's L2 967 address. Therefore the nFA MUST include a Generalised Link Layer and 968 IP Address Extension (see Section 9.3) with its Agent Advertisement 969 (PrRtAdv) messages. 971 3.8. 972 Applicability of PRE-REGISTRATION Handoff 974 The PRE-REGISTRATON Handoff method is applicable to scenarios where a 975 period of service disruption due to layer 3 is not acceptable, for 976 example when performing real-time communications, and therefore where 977 an anticipation of the layer 3 handoff is required. Security for the 978 PRE-REGISTRATION handoff method is based on the same security model 979 as [1] including the use of AAA. A prerequisite for PRE-REGISTRATION 980 is that the FA or MN are able to obtain an L2 trigger informing them 981 of a pending L2 handoff procedure. The target of the L2 handoff is 982 another access point or radio network that is in the coverage area of 983 a new FA. The L2 trigger information may be in the form of 984 Identifiers that need to be resolved to IPv4 addresses using methods 985 that may be specific to the wireless network and are not considered 986 here. If, for example, the oFA or MN determines that the IPv4 987 address of the new FA matches oFA's address then the PRE-REGISTRATION 988 handoff SHOULD NOT be initiated. 990 The L2 trigger must allow enough time for the PRE-REGISTRATION 991 handoff procedure to be performed. In many wireless L2 technologies, 992 the L2 handoff procedure involves a number of message exchanges 993 before the effective L2 handoff is performed. For such technologies, 994 PRE-REGISTRATION handoff can be initiated at the beginning of the L2 995 handoff procedure and completed before the L2 handoff is completed. 996 It is efficient to engineer the network such that this succession of 997 events is ensured. 999 The PRE-REGISTRATION Handoff method is applicable in the following 1000 cases: 1002 - when the MN has locally defined policies that determine a 1003 preference for one access over another, for example due to service 1004 cost within the same or different technology, and therefore where 1005 it is necessary to allow the MN to select the appropriate FA with 1006 which to connect, 1008 - when L2 security between the MN and the FA is either not present 1009 or cannot be relied upon to provide adequate security, 1011 - when the trigger to initiate the handoff is received at the MN. 1013 In the first case it is necessary to involve eventual local MN 1014 policies in the movement detection procedure as described in 3.6. 1016 4. 1017 The POST-REGISTRATION Handoff Method 1019 The POST-REGISTRATION handoff method uses bi-directional edge tunnels 1020 (BETs) or unidirectional tunnels to perform low latency change in the 1021 L2 point of attachment for the MN without requiring any involvement 1022 by the MN. Figure 5 illustrates the basic POST-REGISTRATION handoff. 1024 +------+ 1025 | CN | 1026 +------+ 1027 | 1028 ... 1029 | 1030 +------+ BET +------+ 1031 | aFA |==========| nFA | 1032 +------+ +------+ 1033 | wireless link 1034 | 1035 movement +------+ 1036 ---------> | MN | 1037 +------+ 1039 Figure 5 - POST-REGISTRATION Concept 1041 Following a successful Mobile IPv4 Registration between MN and oFA, 1042 the oFA becomes the mobility anchor point for the MN, called the 1043 anchor FA (aFA). When the MN moves from oFA to nFA, rather than 1044 performing signaling over the wireless link to register with the nFA, 1045 the MN can defer the L3 handoff and continue to use its aFA (i.e. oFA 1046 in this case). If the MN moves to a third FA before registering with 1047 the nFA, in certain cases described later, the third FA signals aFA 1048 to move the wireless link end of the BET from nFA to it. The network 1049 end of the BET remains anchored at aFA until the MN performs the 1050 Mobile IPv4 Registration. 1052 Messages between oFA/aFA and nFA MUST be authenticated. The minimal 1053 requirement is that all FAs involved in low latency handoffs MUST 1054 support manual pre-configuration of security associations with other 1055 neighbouring FAs, involving shared keys and the default algorithms of 1056 [1]. POST-REGISTRATION FAs MUST implement the inter-FA 1057 authentication extension (FA-FA authentication extension) specified 1058 in [11] and MAY additionally use other security mechanisms. 1060 4.1. 1061 Two Party Handoff 1063 Two party handoff occurs when the MN moves from oFA to nFA. Normally 1064 this movement would result in a new Mobile IPv4 Registration at nFA. 1065 However in POST-REGISTRATION, the MN and nFA MAY delay this but 1066 maintain connectivity using the BET (or alternatively unidirectional 1067 tunnel) between oFA and nFA. The protocol is shown in Figure 6. 1069 1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT 1070 | oFA |<-------->| nFA | 1071 4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU 1072 ^ ^ 1073 old L2 | | new L2 1074 +-------+ +-----+ 1075 | | 1076 | | 1077 V V 1078 +------+ movement 1079 4c) L2-LU ---> | MN | ---------> 1080 +------+ 1082 Figure 6 - Two Party Handoff (POST-REGISTRATION) 1084 The following describes the progress of a two party handoff. The 1085 numbered items refer to steps in Figure 6. The source triggered 1086 HRqst/HRply message for tunnel creation, the target triggered 1087 HRqst/HRply message for tunnel creation and the HRqst/HRply to extend 1088 or terminate a BET (or unidirectional tunnel) are identified 1089 respectively using the suffixes (s), (t) and (r). 1091 1) Either the oFA or nFA receives an L2 trigger informing it that a 1092 certain MN is about to move from oFA to nFA. The two cases are: 1094 a) The L2 trigger is a source trigger (L2-ST) at oFA. The 1095 trigger contains the MN's L2 address and an identifier for 1096 the nFA (the IPv4 address itself or an L2 address that can 1097 be resolved to the IPv4 address of the nFA). 1099 b) The L2 trigger is a target trigger (L2-TT) at nFA. The 1100 trigger contains the MN's L2 address and an identifier for 1101 the oFA (the IPv4 address itself or an L2 address that can 1102 be resolved to the IPv4 address of the oFA). 1104 2) The FA receiving the trigger sends a Handoff Request (HRqst) to 1105 the other FA. There are two cases: 1107 a) If oFA is sending the HRqst, the H bit is set and the N 1108 bit is unset, indicating it is an HRqst(s). The HRqst(s) 1109 contains the lifetime of the tunnel the oFA is willing to 1110 support, the MN's IPv4 home address, the MN's HA address 1111 and an LLA option with the MN's L2 address. If the 1112 lifetime is zero and the T bit is not set, the oFA is not 1113 willing to tunnel any packets for MN. A positive lifetime 1114 and a set T bit indicate that the oFA is willing to tunnel 1115 for the indicated time. Section 4.5 describes the 1116 HRqst(s) and Section 9 describes the LLA option. 1118 b) If nFA is sending the HRqst, the N bit is set and the H 1119 bit is unset, indicating it is an HRqst(t). If the T bit 1120 is set, nFA has requested a reverse tunnel and the 1121 HRqst(t) contains the lifetime of the tunnel the nFA is 1122 requesting. The HRqst(t) also contains an LLA option with 1123 the MN's L2 address. The MN's IPv4 home address and HA 1124 address are not sent, unless they are discovered by some 1125 means outside the scope of this document (for example, as 1126 part of the L2-TT). Section 4.5 describes the HRqst(t). 1128 3) The FA receiving the HRqst sends a Handoff Reply (HRply) to the 1129 other FA. There are two cases: 1131 a) If oFA is sending the HRply, the N bit is set and the H 1132 and R bits are unset, indicating that the reply is in 1133 response to a HRqst(t), i.e. it is an HRply(t). If the T 1134 bit is set, the HRply(t) contains the tunnel lifetime the 1135 oFA is willing to provide, otherwise the tunnel lifetime 1136 is set to zero indicating that the oFA is not willing to 1137 provide tunnel service. If both HRply(t) and HRqst(t) 1138 have the T bit set and non-zero lifetime a BET is 1139 established. The HRply(t) also contains the MN's home 1140 subnet IPv4 address, the MN's HA address, and an LLA 1141 option containing the MN's L2 address. Section 4.6 1142 describes the HRply(t). 1144 b) If nFA sends the HRply, the H bit is set and the N and R 1145 bits are unset, indicating this is a response to HRqst(s), 1146 i.e. it is an HRply(s). If the T bit is set, the nFA 1147 indicates that it requests a reverse tunnel, and the 1148 lifetime field is set with the requested tunnel lifetime. 1149 The T Bit can be set in HRply only if the oFA had set the 1150 T bit in the corresponding HRqst or if the nFA requires to 1151 reverse tunnel incoming packets to oFA because ingress 1152 filtering is enabled on its network. This establishes a 1153 BET. The tunnel lifetime requested by the nFA must be 1154 less than or equal to the tunnel lifetime offered by oFA 1155 in the HRqst(s). Section 4.6 describes the HRply(s). 1157 4) The point during the L2 handoff in which the MN is no longer 1158 connected on a given link is signaled by an L2-LD trigger at oFA 1159 and MN. Completion of L2 handoff is signaled by an L2-LU 1160 trigger at nFA and MN. The trigger is handled as follows: 1162 a) When oFA receives the L2-LD trigger, it begins forwarding 1163 MN-bound packets through the forward tunnel to nFA. 1165 b) When the nFA receives the L2-LU trigger, it begins 1166 delivering packets tunneled from oFA to MN and forwards 1167 outbound packets from MN using normal routing mechanisms 1168 or through a reverse tunnel to oFA or HA. The nFA at this 1169 point may not yet be the default router of the MN (see 1170 section 4.4), therefore to receive all outbound packets 1171 from the MN the nFA must send a unicast proxy ARP message 1172 (used in [1]) to the MN upon receiving an L2-LU trigger. 1173 This proxy ARP message is an ARP Reply [5] sent by the nFA 1174 on behalf of oFA, therefore supplying the nFA link-layer 1175 address in the Sender Hardware Address field and the oFA 1176 IPv4 address in the Target Protocol Address field. 1178 c) When the MN receives the L2-LU, it MAY initiate the Mobile 1179 IPv4 Registration process by soliciting an Agent 1180 Advertisement as described in [1]. If the Registration is 1181 successful the nFA takes over the role of anchor FA (aFA) 1182 from the oFA. Alternatively the MN MAY defer the Mobile 1183 IPv4 Registration (see section 4.4). 1185 5) The oFA becomes an aFA if the MN moves to a third FA before 1186 having performed a Mobile IPv4 Registration with nFA. 1188 6) Should L2 handoff fail in Step 4 (due to L2 reasons) and a 1189 ping-pong situation arise, the oFA may be able to determine this 1190 case through the trigger mechanism (i.e. FA sees successive 1191 L2-ST/L2-TT followed by L2-LD and then L2-LU). The FA that 1192 originated the HRqst can in this case cancel the tunnel by 1193 sending an HRqst(r) to the other FA with lifetime zero. It will 1194 then simply continue delivering packets to MN exactly as if no 1195 handoff had been pending. Section 4.5 describes the HRqst(r). 1197 If the oFA sets the B bit in HRqst/HRply and the nFA has not 1198 requested a reverse tunnel by setting the T bit, the nFA SHOULD 1199 tunnel outgoing packets from the MN to the HA because the MN has 1200 requested this service from the oFA. The nFA SHOULD offer this 1201 service only if no security between the nFA and the MN's HA is 1202 required, or if there is an existing nFA-HA security association. 1204 The actual timing of BET or unidirectional tunnel placement depends 1205 on the available L2 triggers. The forward tunnel from oFA to nFA is 1206 constructed using one of the tunneling procedures described in [1] 1207 for the HA to FA tunnel with the difference that the ends of the 1208 tunnel are at the oFA and nFA, respectively. The reverse tunnel from 1209 nFA to oFA is constructed as described in [3] with the difference 1210 that the network end of the tunnel is at the oFA instead of the HA. 1211 If both forward and reverse tunnels are established then a BET has 1212 been established. With optimal L2 trigger information, as described 1213 above, the FAs can setup the BET immediately when the L2 handoff is 1214 initiated, start tunneling MN-bound data when the link to the MN goes 1215 down and the nFA can use the link up trigger to start delivering 1216 packets. In the absence of optimal L2 trigger information, the HRply 1217 can act as the trigger to start tunneling MN-bound data, but in this 1218 case, the period of packet delivery disruption to the MN could still 1219 be present and additional measures may be required to provide 1220 uninterrupted service. Particular implementation and deployment 1221 scenarios could require techniques to smooth the handoff by providing 1222 a means to convey packets arriving during the L2 handoff. The exact 1223 techniques are outside the scope of this document. 1225 Figures 7 and 8 show timing diagrams for source trigger (L2-ST) and 1226 target trigger (L2-TT) two party handoff, respectively. 1228 MN nFA oFA 1229 | | | 1230 | | HRqst(s) |<~~~ L2-ST 1231 | |<------------------| 1232 | | HRply(s) | 1233 | |------------------>| 1234 | | | 1235 --------------------------------------------<~~~ L2-LD 1236 L2 Handoff 1237 --------------------------------------------<~~~ L2-LU 1238 | | | 1239 |<------------------->| | 1240 | MN's traffic | | 1242 Figure 7 - Two Party Source Trigger Handoff Timing 1243 MN nFA oFA 1244 | | | 1245 | L2-TT ~~~>| HRqst(t) | 1246 | |------------------>| 1247 | | HRply(t) | 1248 | |<------------------| 1249 | | | 1250 --------------------------------------------<~~~ L2-LD 1251 L2 Handoff 1252 --------------------------------------------<~~~ L2-LU 1253 | | | 1254 |<------------------->| | 1255 | MN's traffic | | 1257 Figure 8 - Two Party Target Trigger Handoff Timing 1259 Once the tunnel between aFA and the current FA is in place, it is 1260 torn down by one of the following events: 1262 1) The aFA decides to stop tunneling because the lifetime it sent 1263 expires and was not renewed, or the aFA or current FA decide to 1264 terminate tunnel service prematurely for some other reason 1265 (refer to section 4.3). 1267 2) The MN completes the process by performing a Mobile IPv4 1268 Registration with the current FA. This may be initiated by the 1269 FA that sends an Agent Advertisement or by the MN that solicits 1270 for an Agent Advertisement as in [1]. 1272 3) The MN moves to a third FA (see section 4.2) 1274 4.2. 1275 Three Party Handoff 1277 Three party handoff is applicable when an MN, which has already 1278 established an aFA and is receiving tunneled packets through its 1279 current FA, moves to a new FA without performing a Mobile IPv4 1280 Registration. 1282 The need for the Three Party Handoff function depends on the wireless 1283 system in which POST-REGISTRATION is being implemented. For radio L2 1284 protocols in which it is possible for the MN to move so rapidly from 1285 one FA to another such that a probability exists that the Mobile IPv4 1286 Registration with nFA will not complete before the MN moves on, HTT 1287 (Handoff To Third) SHOULD be implemented. Certain wireless systems 1288 and implementations do not allow such fast movement between FAs and 1289 may force the Mobile IPv4 Registration to occur soon after L2 1290 handoff, in which case three party handoff is not applicable. If 1291 this three party handoff feature is not implemented, the FA SHOULD 1292 send an Agent Advertisement to the MN after L2 handoff has completed 1293 (L2-LU at nFA) and/or the MN SHOULD solicit an Agent Advertisement 1294 after L2 handoff (L2-LU at MN). 1296 +------+ 1297 +--->| aFA |<---+ 1298 | +------+ | 1299 4b) HRqst(r) | | 3) HRqst(t) 1300 HRply(r) | | HRply(t) 1301 | | 1302 v 2a) HRqst v 1303 1a) L2-ST ~~~> +------+ HTT +------+ <~~~ 1b) L2-TT 1304 | oFA |<-------->| nFA | 1305 4a) L2-LD ~~~> +------+ 2b) HTT +------+ <~~~ 5a) L2-LU 1306 ^ HRply ^ 1307 old L2 | | new L2 1308 +-------+ +-----+ 1309 | | 1310 | | 1311 V V 1312 +------+ movement 1313 5b) L2-LU ~~~> | MN | ---------> 1314 +------+ 1316 Figure 9 - Three Party Handoff 1318 The L3 handoff can be deferred either because of a decision by the 1319 MN/FA (i.e. MN does not send Agent Solicitations and FA does not send 1320 Agent Advertisements) or it may result from rapid movement between 1321 oFA and nFA that does not allow enough time for the registration to 1322 complete. This scenario is shown in Figure 9. In this case, oFA 1323 must inform nFA (i.e. the third FA) to contact aFA about moving the 1324 radio end of the tunnel. This is performed with the HTT message. 1325 The general idea behind the three party handoff procedure is that the 1326 oFA supplies nFA with the same information it would have obtained via 1327 an L2-TT if handoff had occurred from aFA to nFA, then the nFA 1328 performs an HRqst(t)/HRply(t) sequence with aFA in order to move the 1329 BET to nFA. When the L2 handoff is complete, oFA sends an HRqst(r) 1330 to aFA to terminate the previous BET. 1332 The following describes the progress of a three party handoff. The 1333 numbered items refer to steps in Figure 9. 1335 1) Either the oFA or nFA receives an L2 trigger informing it that a 1336 certain MN is about to be moved. The two cases are: 1338 a) The L2 trigger is a source trigger (L2-ST) at oFA. The 1339 trigger contains the MN's L2 address and an identifier for 1340 the nFA (the IPv4 address itself or an L2 address that can 1341 be mapped to the IPv4 address of the nFA). 1343 b) The L2 trigger is a target trigger (L2-TT) at nFA. The 1344 trigger contains the MN's L2 address and an identifier for 1345 the oFA (the IPv4 address itself or an L2 address that can 1346 be resolved to the IPv4 address of the oFA). 1348 2) The oFA and nFA exchange a HTT/HRply or HRqst/HTT pair. HTT is 1349 indicated by setting both the H and N bits in the HRqst or 1350 HRply. The HTT message MUST NOT have any tunnel flag bits set, 1351 because the tunnel is negotiated between the aFA and nFA, not 1352 oFA and nFA. There are two cases: 1354 a) The L2 trigger is an L2-ST. The oFA sends HTT to nFA 1355 containing the MN's home IPv4 address, the MN's HA 1356 address, an LLA containing the aFA's IPv4 address, and an 1357 LLA containing the L2 address of the MN. This is enough 1358 information for nFA to perform a target triggered handoff 1359 with aFA. The nFA responds with a HRply(s). Section 4.8 1360 describes the HTT. 1362 b) The L2 trigger is an L2-TT. The nFA sends HRqst(t) to oFA, 1363 exactly as if a two party handoff were occurring. The 1364 oFA responds with HTT containing the same information as 1365 in a) above. This is enough information for nFA to 1366 perform a target triggered handoff with aFA. 1368 3) Upon receipt of the HTT, the nFA first checks its Visitor Cache 1369 to see whether it is already tunneling for MN. If so, Step 6 is 1370 performed. If not, nFA performs a target triggered handoff with 1371 aFA, exactly as in Section 4.1, exchanging a HRqst(t)/HRply(t) 1372 pair. Because aFA receives no L2 trigger indicating when L2 1373 handoff starts, it may start tunneling to nFA upon transmission 1374 of the HRply(t). 1376 4) Once the L2 handoff is underway and the MN gets disconnected at 1377 L2, aFA and oFA exchange messages canceling tunnel service 1378 between aFA and oFA and allowing aFA to start the tunnel with 1379 nFA. 1381 a) The point in the L2 handoff process where the MN gets 1382 disconnected from oFA is signaled at oFA by L2-LD. 1384 b) The oFA exchanges a HRqst(r)/HRply(r) pair having lifetime 1385 zero with aFA. This cancels tunnel service between oFA 1386 and aFA. If aFA has not already established a tunnel to 1387 nFA, it must do so immediately upon receipt of the 1388 HRqst(r). The aFA provides tunneling service exactly as 1389 described in Section 4.1 Step 4a. 1391 5) Completion of L2 handoff is signaled by an L2-LU trigger at nFA 1392 and/or MN. The nFA and MN handle the trigger as follows: 1394 a) The nFA provides packet delivery service to the MN exactly 1395 as described in Section 4.1, Step 4b. 1397 b) The MN either defers or initiates Mobile IPv4 Registration 1398 when it receives the L2-LU, as in Section 4.1 1400 6) In the special case where nFA and aFA are the same (i.e. the MN 1401 is moving back to the original anchor FA), aFA recognizes that 1402 it is tunneling to oFA when it checks its Visitor Cache in Step 1403 3. In this case, there is no need for aFA to send the 1404 HRqst(t)/HRply(t) in Step 3. Upon receipt of the L2-LU trigger 1405 on handoff completion, the aFA begins routing packets to MN and 1406 the tunnel to nFA is torn down. The oFA still exchanges the 1407 HRqst(r)/HRply(r) with aFA in Step 4b because oFA cannot know a 1408 priori that aFA and nFA are the same, but they are redundant. 1410 Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and 1411 target trigger (L2-TT) three party handoff, respectively. 1413 MN nFA oFA aFA 1414 | | L2-ST ~~~> | | 1415 | | | | 1416 | |<-------------| | 1417 | | HTT | | 1418 | |------------->| | 1419 | | HRply(s) | | 1420 | |------------------------------>| 1421 | | HRqst(t) | | 1422 | |<------------------------------| 1423 | | HRply(t) | | 1424 | | | | 1425 ----------------------------------<~~~ L2-LD | 1426 |--------------->| 1427 L2 Handoff | HRqst(r) | 1428 | | 1429 |<---------------| 1430 | HRply(r) | 1431 | | 1432 ----------------------------------<~~~ L2-LU | 1433 | MN's traffic | | | 1434 |<-------------->| | | 1436 Figure 10 - Three Party Source Trigger Handoff Timing 1438 MN nFA oFA aFA 1439 | | | | 1440 | |<~~~ L2-TT | | 1441 | |------------->| | 1442 | | HRqst(t) | | 1443 | |<-------------| | 1444 | | HTT | | 1445 | |------------------------------>| 1446 | | HRqst(t) | | 1447 | |<------------------------------| 1448 | | HRply(t) | | 1449 | | | | 1450 ----------------------------------<~~~ L2-LD | 1451 |--------------->| 1452 L2 Handoff | HRqst(r) | 1453 | | 1454 |<---------------| 1455 | HRply(r) | 1456 | | 1457 ----------------------------------<~~~ L2-LU | 1458 | MN's traffic | | | 1459 |<-------------->| | | 1461 Figure 11 - Three Party Target Trigger Handoff Timing 1463 Unlike two party handoff, the timing of BET establishment between aFA 1464 and nFA cannot fully depend on the availability of L2 trigger 1465 information because aFA does not receive an L2 trigger signalling L2 1466 handoff. The two timing extremes at which aFA can place the BET with 1467 nFA are: 1469 1) At the earliest, aFA MAY start tunneling packets using the BET 1470 to nFA after sending the HRply(t) to nFA in response to the 1471 request for target-triggered handoff 1473 2) At the latest, aFA MAY start tunneling packets using the BET to 1474 nFA and tear down the BET with oFA when receiving the HRqst(r) 1475 from oFA indicating the MN has disconnected. 1477 In addition, aFA MAY continue tunneling to oFA if 1) is selected, 1478 until the HRqst(r) is received. In this case, the result may be 1479 duplicated packets at the MN because the MN will receive packets 1480 through oFA on the old L2 until it disconnects (L2-LD). If 2) is 1481 selected, the additional latency will add to the MN's L3 service 1482 disruption period. Of course, aFA can choose to place the BET some 1483 time between 1) and 2) if reliable bounds are available on the 1484 duration of time between L2-ST/L2-TT and the MN's disconnection 1485 (L2-LD). The exact selection of when to establish the BET is likely 1486 to be influenced by network engineering and implementation 1487 considerations, including whether a handoff smoothing solution is 1488 used, and is beyond the scope of this specification. 1490 4.3. 1491 Renewal or Termination of Tunneling Service 1493 To prevent a BET from expiring when its lifetime runs out, the MN's 1494 current FA signals the aFA to either renew or terminate the BET. 1495 This may be the case when the MN defers Mobile IPv4 Registration. If 1496 no such signal is received, the aFA will terminate the BET when the 1497 lifetime expires. In addition, the current FA or aFA may need to 1498 terminate the BET prior to the lifetime expiring. In order to avoid 1499 error conditions in which tunnels do not expire even though the MN to 1500 which they apply is no longer reachable, FAs SHOULD set the tunnel 1501 lifetime field to some value other that 0xffff, which indicates "good 1502 until cancelled". 1504 Figure 12 illustrates the message exchange that occurs between the FA 1505 needing to terminate or extend the tunnel (designated FA(1) in the 1506 figure) and the other FA (designated FA(2) in the figure). The 1507 HRqst(r)/HRply(r) is indicated by setting the R bit in the 1508 HRqst/HRply messages. If the HRqst(r) is renewing a BET then it 1509 contains a non-zero lifetime, otherwise if the lifetime is set to 1510 zero it indicates tunnel termination. The aFA has complete control 1511 over whether a tunnel is extended or terminated, and it MAY reply to 1512 a request for extension with a shorter lifetime than was requested. 1514 HRqst(r) 1515 +------+ <-------- +------+ 1516 | FA(2)| ---------> | FA(1)| 1517 +------+ HRply(r) +------+ 1519 Figure 12 - BET Renewal or Termination 1521 4.4. 1522 When will the MN perform a Mobile IPv4 Registration? 1524 The MN/FA have control over when to perform the Mobile IPv4 1525 Registration. Although the MN/FA may decide to defer Mobile IPv4 1526 Registration for a certain period, three possible events can lead to 1527 the need to terminate tunneling service. If this occurs the MN MUST 1528 perform the Mobile IPv4 Registration. These events are: 1530 1) The end of life for the BET is pending and a request by the 1531 current FA to aFA for renewal has been denied, or alternatively 1532 the current FA or aFA needs to terminate the BET prematurely. 1533 The FA in this case MUST initiate the Mobile IPv4 Registration 1534 by sending an Agent Advertisement to the MN as in [1]. 1536 2) The MN itself decides to perform a Mobile IPv4 Registration and 1537 initiates it by sending an Agent solicitation as in [1]. 1539 3) During a source triggered handoff, the oFA attempts to perform 1540 BET handoff but nFA is not capable of performing it. The FA in 1541 this case MUST initiate the Mobile IPv4 Registration by sending 1542 the MN an Agent Advertisement as in [1]. Note that this 1543 situation will never arise during target triggered handoff 1544 because an HRqst(t) will not be sent to oFA by an nFA that 1545 doesn't support POST-REGISTRATION. 1547 Some detailed scenarios relating to case 2) will be described 1548 hereafter. According to [1], when using an FA care-of address the MN 1549 MAY use the FA as its default router. Otherwise it MUST choose its 1550 default router from those advertised in the ICMP Router Advertisement 1551 portion of the Agent Advertisement. Here we assume that the FA 1552 router is also the MN's default router. In POST-REGISTRATION, when a 1553 tunnel is established between oFA and nFA and the MN has moved to 1554 nFA, the oFA MUST NOT send Agent Advertisements to the MN. In this 1555 case it is possible that the MN will not receive Agent Advertisements 1556 for extended periods of time. According to [8] hosts will remove 1557 default router entries if the lifetime of the Router Advertisement 1558 expires and no further advertisements are received. Note that the 1559 ICMP Router Advertisement lifetime is not related to the Registration 1560 Lifetime in the Mobility Agent Advertisement extension [1]. To avoid 1561 this disruption the MN MUST solicit the default router (i.e. FA) 1562 before the lifetime of its active default router entry runs out, or 1563 alternatively the FA MUST advertise as soon as the MN-nFA link is up 1564 (L2-LU). This effectively means that the MN will at most be able to 1565 defer Mobile IPv4 Registration for as long as the remaining lifetime 1566 of the active default router, as configured in the ICMP Router 1567 Advertisements. The MN MUST perform a Mobile IPv4 registration [1] 1568 when it receives an Agent Advertisement following a POST-REGISTRATION 1569 handoff. 1571 4.5. 1572 Handoff Request (HRqst) Message format 1574 This is a new Mobile IPv4 message carried on UDP (destination port 1575 434) [1]. The UDP header is followed by the fields below. 1577 0 1 2 3 1578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Type |H|N|R|M|G|T|B| Reserved | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Lifetime | Reserved | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | MN Home Address | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | HA Address | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | | 1589 + Identification + 1590 | | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Extensions ... 1593 +-+-+-+-+-+-+-+- 1595 Type TBD (Handoff Request) 1597 H Source triggered handoff request. When set and 1598 the N bit is unset, indicates that the request 1599 was the result of an L2-ST at oFA. 1601 N Target triggered handoff request. When set and 1602 the H bit is unset, indicates that the request 1603 was the result of an L2-TT at nFA. 1605 R Set if the request is an HRqst(r) (i.e. a request 1606 to renew the tunnel, H and N bits must be unset). 1608 M The FA issuing the HRqst will use Minimal 1609 Encapsulation as defined in [1,5] for the tunnel. 1611 G The FA issuing the HRqst will use GRE [4] 1612 Encapsulation as defined in [1,5] for the tunnel. 1613 Extensions of HRqst containing GRE type and key 1614 Fields are outside the scope of this document. 1616 T For an HRqst(s), indicates that the oFA is 1617 willing to support both forward and reverse 1618 tunnel service. For an HRqst(t), indicates that 1619 the nFA is requesting reverse tunnel service. 1621 B When sent in an HRqst(s), indicates that the MN 1622 has requested a reverse tunnel to the HA and that 1623 the nFA SHOULD use reverse tunnel to the HA if it 1624 will not be reverse tunneling to the oFA. 1626 Lifetime The lifetime of the tunnel in seconds. If this 1627 is an HRqst(t), then the lifetime represents a 1628 request by nFA for a reverse tunnel. If this is 1629 an HRqst(s), then the lifetime represents the 1630 maximum amount of time that oFA is willing to 1631 maintain both forward and reverse tunnels. If 1632 this is an HRqst(r), then the lifetime represents 1633 a request for the amount of time to renew the 1634 tunnel's lifetime. A value of 0 on an HRqst(s) 1635 indicates that the oFA is unwilling to grant 1636 tunnel service. A value of 0 on an HRqst(t) 1637 indicates that the nFA does not require reverse 1638 tunnel service. A value of 0 on an HRqst(r) 1639 indicates that the tunnel should be terminated. 1640 A value of 0xffff indicates infinity. 1642 MN Home Address For HRqst(s), the home address of the MN. 1644 HA Addr For HRqst(s), the HA address of the mobile node. 1646 Identification As in defined in [1]. 1648 Extensions The Message MUST include an LLA (see Section 9) 1649 containing the MN's L2 address and an L2 address 1650 that can be mapped to an IPv4 address for the FA. 1651 This Message MUST contain the FA-FA 1652 Authentication Extension [11] that is used to 1653 secure the HRqst message. 1655 4.6. 1656 Handoff Reply (HRply) Message 1658 This is a new Mobile IPv4 message carried on UDP (destination port 1659 434) [1]. The UDP header is followed by the fields below. 1661 0 1 2 3 1662 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | Type |H|N|R|M|G|T|B| Reserved | Code | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 | Lifetime | Reserved | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | MN Home Address | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 | HA Address | 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | | 1673 + Identification + 1674 | | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | Extensions ... 1677 +-+-+-+-+-+-+-+- 1678 Type TBD (Handoff Reply) 1680 Code A value indicating the result of the Handoff 1681 Request. Only two codes are currently supported, 1682 0, indicating success, and 1, indicating that the 1683 handoff cannot be performed. The remaining values 1684 are for future use. 1686 Lifetime The lifetime, in seconds, for which the 1687 bi-directional tunnel for the MN will be 1688 maintained. If this is an HRply(s), then the 1689 lifetime represents a request by nFA, and it can 1690 be any value up to the maximum value sent in the 1691 HRqst(s). Larger values are assumed to default 1692 to OFA's maximum. If this is an HRply(t), then 1693 the lifetime represents the maximum amount of 1694 time that the oFA will grant to the nFA. If this 1695 is a HRply(r), then the lifetime represents the 1696 amount of time by which the tunnel life will be 1697 extended. If the Code field indicates that 1698 handoff failed, the Lifetime field will be 1699 ignored and SHOULD be set to zero. A value of 1700 0 on an HRply(t) indicates that the oFA is 1701 unwilling to grant service. A value of 0 on an 1702 HRply(s) indicates that the nFA does not require 1703 service. A value of 0 on HRply(r) indicates that 1704 the tunnel lifetime will be terminated. A value 1705 of 0xffff indicates infinite lifetime. 1707 H Source triggered handoff reply. When set and 1708 the N bit is unset, indicates that the 1709 reply is in response to an HRqst(s). 1711 N Target triggered handoff reply. When set and 1712 the H bit is unset, indicates that the 1713 reply is in response to an HRqst(t). 1715 R Set if the reply is an HRply(r). Neither 1716 the H nor the N bit are set. 1718 M The FA issuing the HRqst will use Minimal 1719 Encapsulation as defined in [1,5] for 1720 the tunnel. 1722 G The FA issuing the HRqst will use GRE [4] 1723 Encapsulation as defined in [1,5] for the tunnel. 1724 When this flag bit is set the HRply may require 1725 extensions containing the GRE type and key 1726 fields, but they are outside the scope of this 1727 document. 1729 T For an HRply(s), indicates that the nFA is 1730 Requesting to reverse tunnel service. For an 1731 HRply(t), indicates that the oFA is willing to 1732 provide both forward and reverse tunnel service. 1734 B When sent in an HRply(t), indicates that the MN 1735 has requested a reverse tunnel to the HA and that 1736 the nFA SHOULD use reverse tunnel to the HA if 1737 it will not be reverse tunneling to the oFA. It 1738 can be set in HRply(t) only if the T bit was 1739 unset in the corresponding HRqst(t). 1741 MN Home Address For HRply(t), the home IPv4 address of the MN. 1743 HA Addr For HRply(t), the HA IPv4 address of the MN. 1745 Identification As in defined in [1]. 1747 Extensions This Message MUST contain the FA-FA 1748 Authentication Extension [11] that is used to 1749 secure the HRply message. 1751 4.7. 1752 Handoff To Third (HTT) Message 1754 The Handoff to Third message has the same format as the Handoff 1755 Request and Handoff Reply Messages, except both the H and N bits are 1756 set. If the HTT message is in response to a L2-ST and is sent to 1757 initiate a handoff, then, with the exception of the H and N bits, the 1758 message has the same fields set and includes the same extensions as 1759 an HRqst(s). If the HTT message is sent in response to an HRqst(t), 1760 then, with the exception of the H and N bits, the message has the 1761 same fields set and includes the same extensions as an HRply(t). The 1762 tunnel bits MUST NOT be set in the HTT message because BET 1763 construction is not negotiated between oFA and nFA, it is negotiated 1764 between nFA and aFA in the ensuing HRqst(t)/HRply(t). 1766 In addition, the HTT MUST contain the following extensions in the 1767 specified order: 1769 Solicited IPv4 Address Option: containing aFA's Address 1771 LLA Option: containing the L2 address of the MN. 1773 4.8. 1774 Applicability of POST-REGISTRATION Handoff Method 1776 The POST-REGISTRATION handoff approach allows FAs to communicate 1777 directly about a pending handoff, and does not require any IPv4 layer 1778 messages to be sent to or from a MN prior to the L2 handoff event. 1779 Therefore, it eliminates a possible source of handoff latency. This 1780 may be required when the link layer imposes hard deadlines on the 1781 time at which a handoff must occur, such as when a MN is rapidly 1782 moving out of a radio coverage area. Consequently, POST-REGISTRATION 1783 is primarily of interest in handoff between FAs that support the same 1784 radio access technology. Handoff between heterogeneous radio 1785 technologies will, of necessity, require interaction between the MN 1786 and the network, and so is not a domain of applicability for 1787 POST-REGISTRATION. 1789 Because a POST-REGISTRATION handoff is triggered by an unspecified 1790 mechanism that informs the oFA or nFA that an L2 handoff is pending, 1791 the POST-REGISTRATION approach is only applicable to networks where 1792 such a mechanism is available. For example, an L2 may provide 1793 indications of radio signal quality that cause the oFA or nFA to send 1794 the POST-REGISTRATION handoff messages. Any such indications must 1795 also provide each FA involved in the handoff with the identity of the 1796 other, so that messages can be sent to the right place. This may 1797 involve mapping L2 information onto FA IPv4 addresses. Also, the FAs 1798 involved in a handoff must have pre-provisioned security arrangements 1799 so that the POST-REGISTRATION messages can be authenticated. If a 1800 handoff is to be completed as a result of the POST-REGISTRATION 1801 messaging, any L2 handoff indications must also be securely 1802 authenticated so that traffic to the old point of attachment is not 1803 improperly halted. 1805 POST-REGISTRATION handoff is appropriate in the following cases: 1807 - L2 triggers are available on the network to indicate that L2 1808 handoff is pending. 1810 - Pre-provisioned security mechanisms are in place to allow fast 1811 and secure messaging between the FAs and between the MN and an FA. 1813 - Access point choice by the MN is not a concern or choice requires 1814 user intervention and therefore is not on the critical path for 1815 handoff. 1817 5. 1818 Combined Handoff Method 1820 The combined method uses both PRE-REGISTRATION and POST-REGISTRATION 1821 handoff. If PRE-REGISTRATION does not complete prior to the 1822 expiration of a timer on the nFA, the POST-REGISTRATION mechanism is 1823 used to create the tunnel between oFA and nFA. This protects the MN 1824 from delays caused by errors such as loss of the Mobile IPv4 1825 Registration Reply message involved in PRE-REGISTRATION for the 1826 mobile-initiated and network-initiated source-triggered cases. It 1827 also protects the MN from delays caused by errors or the loss of any 1828 of the Mobile IPv4 messages involved in PRE-REGISTRATION for the 1829 network-initiated target-triggered case. 1831 When the nFA receives a target-trigger it will follow the PRE- 1832 REGISTRATION procedure. When the combined method is used, the nFA 1833 MUST also start a timer when it receives a target-trigger. The timer 1834 should be set to a small value (default for target-trigger case: 1 1835 sec). 1837 According to PRE-REGISTRATION, the nFA will receive the Registration 1838 Request from the MN. When the combined method is used, this 1839 Registration Request sent by the MN MUST contain the IPv4 address of 1840 the oFA in an FA IPv4 address LLA extension (see 9.7). This same 1841 Registration Request message will contain multiple LLA extensions, 1842 since it will also contain the MN's layer 2 address in an LLA 1843 extension as described for PRE-REGISTRATION (see 3.7 and 9). When 1844 the nFA has not started the handoff procedure using a target-trigger 1845 (i.e. mobile-initiated or network-initiated target-triggered cases) 1846 the nFA MUST start a timer as soon as it receives the low latency 1847 Registration Request from the MN. This timer should be set to a 1848 small value (default for : 1 sec). 1850 In all cases the timer MUST be reset when the Registration Reply 1851 message is received by nFA. If the timer expires before the 1852 Registration Reply is received, the nFA MUST initiate the POST- 1853 REGISTRATION procedure. The nFA utilizes the oFA IPv4 address 1854 (previously received in the extension to the Registration Request 1855 message) as the destination of the POST-REGISTRATION HRqst message to 1856 create the tunnel between nFA and oFA. The nFA MAY tear down this 1857 tunnel when it receives and forwards a successful Registration Reply 1858 for that MN. 1860 6. 1861 Layer 2 and Layer 3 Handoff timing Considerations 1863 In the optimal cases considered in the PRE-REGISTRATION and 1864 POST-REGISTRATION handoffs it was assumed that a timely L2 trigger 1865 would be received in such a way that packets could be delivered to 1866 the MN via its nFA immediately upon connection. In this way the MN 1867 does not suffer disruption due to the L3 handoff. However such 1868 precise timing of the L2 trigger and handoff mechanism with respect 1869 to the actual L2 handoff event will not be possible in all wireless 1870 systems and may depend on particular implementation techniques. 1871 Therefore some uncertainty may exist at L3 as to exactly when the L2 1872 connection between the MN and the nFA becomes fully established and 1873 can be used for L3 traffic. It is possible that in certain 1874 implementations traffic will be re-routed too early or too late with 1875 respect to the moment when the connection between the MN and the nFA 1876 becomes fully established. The techniques that may solve this 1877 problem and allow the MN to receive traffic independently of the 1878 timing of the L2 handoff event include buffering and simultaneous 1879 bindings (i.e. bicasting: setting the S bit [1] in Registration 1880 Requests). However these are optional and are not mandated. 1882 7. 1883 Reverse Tunneling Support 1885 The handoff methods all support reverse tunneling. The MN may 1886 request reverse tunneling [3] by setting the T bit in its 1887 Registration Request. In the case of POST-REGISTRATION, if the MN 1888 had requested Reverse Tunneling previously at oFA, the Handoff 1889 message from oFA (see Section 4) includes the T bit enabled to inform 1890 nFA to establish a BET for the visitor entry. Typically, the T bit 1891 will always be set to ensure that any delays in the MN receiving its 1892 new care of address do not result in any delay in uplink packet 1893 transmission from the MN, but local policies and particular L2 1894 technologies may allow the reverse tunnel to be turned off. 1896 8. 1897 Handoff Signaling Failure Recovery 1899 In general and to a greater extent in wireless networks, packets 1900 carrying handoff signaling may be dropped or lost due to errors on 1901 the link. In this section, we consider mechanisms for recovery from 1902 handoff signaling failures. 1904 8.1. 1905 PRE-REGISTRATION Signaling Failure Recovery 1907 Failure of PRE-REGISTRATION signaling breaks down into three cases: 1909 1) Loss of messages PrRtSol and PrRtAdv on the air link. 1911 2) Loss of the solicitation by an FA to obtain another neighbouring 1912 FA's Advertisement or loss of the neighbouring FA's 1913 advertisement. 1915 3) Failure of the standard Mobile IPv4 Registration. 1917 Of these, case 3) is handled by standard Mobile IPv4 mechanisms 1918 described in [1]. Case 2) is expected to be a rare event because 1919 spontaneous packet drop rates on the fixed network are caused by 1920 congestion or router failure. Since bit error rates on wireless 1921 links are higher than on fixed links, case 1) is more likely to 1922 occur. In the following subsections, the cases 1) and 2) are 1923 considered. 1925 8.1.1. 1926 Failure of PrRtSol and PrRtAdv 1928 PRE-REGISTRATION handoff can fail in network-initiated handoff when 1929 the PrRtAdv sent by oFA in response to the source trigger (L2-ST) or 1930 the advertisement sent by nFA in response to the target trigger (L2- 1931 TT) fails to reach the MN. PRE-REGISTRATION handoff can also fail in 1932 mobile-initiated handoff when either the PrRtSol sent from the MN or 1933 return PrRtAdv sent from the oFA are dropped. To reduce the 1934 probability that PrRtAdv and PrRtSol are lost the MN and FA MAY 1935 transmit multiple copies of these messages. Should these messages 1936 fail anyway, in both cases the MN connects to the nFA without having 1937 received any prior signalling. In this case the MN solicits an FA 1938 Advertisement when it connects to nFA at L2 (L2-LU), as described in 1939 3.6, and performs a standard Mobile IPv4 registration with the nFA as 1940 specified in [1]. 1942 8.1.2. 1943 Failure of Inter-FA solicitation and advertisement 1945 The solicitation from an FA to another neighbouring FA may fail or 1946 the corresponding advertisement from the neighbouring FA may be lost. 1947 To reduce the probability that these messages are lost, the FAs MAY 1948 transmit multiple copies of these messages. If a failure occurs 1949 anyway, the FA soliciting the Agent Advertisement is unable to send a 1950 PrRtAdv in response to a source trigger or to a mobile-initiated 1951 PrRtSol. In these cases, when the MN does not receive a notification 1952 or confirmation of a PRE-REGISTRATION handoff, the MN MUST perform a 1953 standard Mobile IPv4 registration as soon as it connects to the nFA 1954 (L2-LU) as described in 8.1.1. 1956 8.2. 1957 POST-REGISTRATION Signaling Failure Recovery 1959 Failure occurs in POST-REGISTRATION when either the HRqst or HRply 1960 message is dropped. The effects of the failure and the recovery 1961 procedure depend on which message is dropped, and whether the handoff 1962 is source or target triggered. Since all of the POST-REGISTRATION 1963 signaling is going over the fixed network, it can be expected that 1964 spontaneous dropping of packets in the absence of congestion and 1965 router failure should be a relatively rare event. Nevertheless, 1966 failure recovery mechanisms SHOULD be implemented. 1968 8.2.1. 1969 HRqst Message Dropped 1971 If the HRqst message is dropped, the effect is the same for both 1972 source and target-triggered handoff. In either case, the FA to which 1973 the HRqst was destined will never respond with an HRply message. If 1974 the handoff is source-triggered, then the nFA never learns of the 1975 handoff, and the oFA never receives confirmation. If the handoff is 1976 target-triggered, then the oFA never learns of the handoff, and the 1977 nFA never receives confirmation. 1979 The recovery procedure in this case is as follows: the oFA MUST NOT 1980 construct a forward tunnel when the MN moves off-link (L2-LD) if the 1981 handoff is source-triggered, and the nFA MUST NOT construct a reverse 1982 tunnel if the handoff is target-triggered. If the nFA was not 1983 informed of the handoff by an HRqst message (corresponding to failure 1984 of source-triggered handoff) or if the handoff was not confirmed by 1985 an HRply message (corresponding to failure of target-triggered 1986 handoff) the nFA MUST unicast an Agent Advertisement to the MN as 1987 soon as its L2 connection is established (L2-LU at nFA). 1989 8.2.2. 1990 HRply Message Dropped 1992 If the HRply message is dropped, the FA sending the HRply will assume 1993 that the handoff has been confirmed, but the FA that is expecting to 1994 receive the HRply does not receive confirmation. In this case, the 1995 failure recovery procedure is different for source-triggered and 1996 target-triggered handoffs. 1998 In a target-triggered handoff, the oFA assumes the handoff is 1999 confirmed because it has sent the HRply, but the nFA has not received 2000 it so it does not have confirmation. The oFA starts tunneling 2001 packets to the nFA when the MN moves from its link (L2-LD). The nFA 2002 MUST send a FA Advertisement to the MN as soon as its L2 link is up 2003 (L2-LU at nFA) and MAY drop the tunneled packets. The nFA SHOULD 2004 send an ICMP Destination Unreachable [9] message to the oFA. When 2005 the oFA receives this message it will terminate the tunnel and stop 2006 forwarding packets. If reverse tunneling was requested the nFA MUST 2007 NOT reverse tunnel because it has not received handoff confirmation. 2009 In source-triggered handoff, the nFA assumes the handoff is confirmed 2010 because it has sent the HRply, but the oFA has not received it so it 2011 does not have confirmation. Without failure recovery, the MN could 2012 move to the nFA without the oFA being able to start the forward 2013 tunnel for the MN's packets, and the MN would not be able to initiate 2014 a Mobile IPv4 registration because it does not know that the handoff 2015 has failed. In this situation, the oFA MUST send out a HRqst message 2016 to the nFA with lifetime zero as soon as the MN leaves its link 2017 (L2-LD). The oFA SHOULD continue to retransmit the HRqst message, 2018 with exponential backoff for CONFIG-HFAIL seconds or until it 2019 receives an HRply acknowledging the request to cancel the tunnel. 2020 The default value for CONFIG-HFAIL is 10 seconds. When the nFA 2021 receives the HRqst, it MUST immediately send an Agent Advertisement 2022 to the MN, as is the case whenever a tunnel is cancelled. In 2023 addition, the oFA MUST also drop any packets received through the 2024 reverse tunnel from the nFA. The oFA SHOULD NOT send the ICMP 2025 Destination Unreachable message to the nFA because the nFA has been 2026 informed by the HRqst message to cancel the tunnel. However, if the 2027 nFA receives an ICMP Destination unreachable message for the tunnel 2028 prior to receiving the HRqst canceling the tunnel, it MUST send an FA 2029 Advertisement to the MN and cancel the tunnel. 2031 9. 2032 Generalized Link Layer and IPv4 Address (LLA) Extension 2034 This section defines the Generalized Link Layer and IPv4 Address 2035 (LLA) Extension, used by any node that needs to communicate Link 2036 Layer and IPv4 Addresses. The format of the extension relies on sub- 2037 types, where each sub-type defines its own sub-structure. This draft 2038 defines six sub-types. Future RFCs should allocate their own sub- 2039 type and define their own address formats. 2041 0 1 2 3 2042 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2044 | Type | Length | Sub-Type | LLA ... 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 Type 2049 TBD (skippable) [1] - when used in Registration Requests 2050 TBD (skippable) [1] - when used in Agent Advertisements 2052 Length 2054 The length of the Link Layer Address + the one octet Sub-Type 2055 field 2057 Sub-Type 2059 This field contains the Link Layer sub-type identifier 2061 LLA 2063 Contains the Link Layer Address 2065 In this document, seven subtypes are defined: 2067 1 3GPP2 International Mobile Station Identity and 2068 Connection ID [13] 2069 2 3GPP International Mobile Subscriber Identity [15] 2070 3 Ethernet 48 bit MAC address [5] 2071 4 64 bit Global ID, EUI-64 [6] 2072 5 Solicited IPv4 Address 2073 6 Access Point Identifier 2074 7 FA IPv4 Address 2076 The following subsections describe the extensions. 2078 9.1. 2079 3GPP2 IMSI Link Layer Address and Connection ID Extension 2081 The IMSI Link Layer Address Extension contains the International 2082 Mobile Station Identity. 2084 0 1 2 3 2085 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 | Type | Length | Sub-Type | IMSI ... 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 Type 2091 TBD (skippable) [1] 2093 Length 2095 The length of the IMSI field + the one octet Sub-Type field 2097 Sub-Type 2099 1 2101 IMSI 2103 Contains the IMSI, in the form: 2104 : 2105 Where the is an ASCII-based representation of the 2106 International Mobile Station Identifier, most significant 2107 digit first, ":" is ASCII 0x3a, and the Connection ID is the 2108 ASCII representation of a small, decimal number used for 2109 distinguishing different link-layer connections from the 2110 same mobile device. 2112 9.2. 2113 3GPP IMSI Link Layer Address Extension 2115 The IMSI Link Layer Address Extension contains the International 2116 Mobile Station Identity. 2118 0 1 2 3 2119 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 | Type | Length | Sub-Type | IMSI ... 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 Type 2126 TBD (skippable) [1] 2128 Length 2130 The length of the IMSI field + the one octet Sub-Type field 2132 Sub-Type 2134 2 2136 IMSI 2138 Contains the IMSI, a number composed of 15-digits or less, 2139 coded as described in [15]. 2141 9.3. 2142 Ethernet Link Layer Address Extension 2144 The Ethernet Link Layer Address Extension contains the 48 bit 2145 Ethernet MAC Address, as defined in [5]. 2147 0 1 2 3 2148 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | Type | Length | Sub-Type | MAC ... 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 Type 2155 TBD (skippable) [1] 2157 Length 2159 7 (includes the Sub-Type field) 2161 Sub-Type 2163 3 2165 MAC 2167 Contains the 48 bit Ethernet MAC Address. 2169 9.4. 2170 IEEE 64-Bit Global Identifier (EUI-64) Address Extension 2172 The 64-Bit Global Identifier (EUI-64) Address Extension contains the 2173 64 bit address, as defined in [6]. 2175 0 1 2 3 2176 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | Type | Length | Sub-Type | MAC ... 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 Type 2183 TBD (skippable) [1] 2185 Length 2187 9 (includes the Sub-Type field) 2189 Sub-Type 2191 4 2193 MAC 2195 Contains the 64-Bit Global Identifier Address. 2197 9.5. 2198 Solicited IPv4 Address Extension 2200 The 32-bit Solicited IPv4 Address Extension contains the IPv4 address 2201 of the agent (FA) being solicited. This extension MAY be present in 2202 an ICMP Agent Solicitation as explained in Section 3.3. 2204 0 1 2 3 2205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | Type | Length | Sub-Type | IPv4 addr ... 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 Type 2212 TBD (skippable) [1] 2214 Length 2216 5 (includes the Sub-Type field) 2218 Sub-Type 2220 5 2222 IPv4 Address 2224 Contains the 32-Bit IPv4 Address of the solicited node. 2226 9.6. 2227 Access Point Identifier Extension 2229 The 32-bit Access Point Identifier Extension contains an Identifier 2230 of the Access Point to which the MN will move. This may be a 2231 wireless L2 identifier. The MN is able to solicit an advertisement 2232 from the FA servicing a certain Access Point by using this extension 2233 with Agent Solicitations as explained in Section 3.3. 2235 0 1 2 3 2236 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 | Type | Length | Sub-Type | AP ID... 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 Type 2243 TBD (skippable) [1] 2245 Length 2247 5 (includes the Sub-Type field) 2249 Sub-Type 2251 6 2253 AP ID 2255 Contains the 32-Bit Access Point Identifier. 2257 9.7. 2258 FA IPv4 Address Extension 2260 The 32-bit FA IPv4 Address Extension contains the IPv4 address of the 2261 agent (FA). This extension MAY be present in a Registration Request 2262 message to identify the oFA as explained in section 5. 2264 0 1 2 3 2265 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2267 | Type | Length | Sub-Type | IPv4 addr ... 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 Type 2272 TBD (skippable) [1] 2274 Length 2276 5 (includes the Sub-Type field) 2278 Sub-Type 2280 7 2282 IPv4 Address 2284 Contains the 32-Bit IPv4 Address of the FA node. 2286 10. 2287 IANA Considerations 2289 This document defines one new extension to Mobile IPv4 Control 2290 messages and one new extension to Mobile IPv4 Router Discovery 2291 messages already maintained by IANA. This document also defines a 2292 new Mobile IPv4 Control message type to be used between FAs. To 2293 ensure correct interoperation based on this specification, IANA must 2294 reserve values in the Mobile IPv4 number space for two new extensions 2295 and one new message type. IANA must also manage the numbering spaces 2296 created by the two new extensions, the message type and its 2297 associated Code field. 2299 10.1. 2300 New Extension values 2302 Section 9 introduces two extensions. 2303 Generalized Link Layer and IPv4 Address (LLA) Extension for Router 2304 Discovery messages: A new Mobile IPv4 extension that follows after 2305 Mobile IPv4 ICMP Router Discovery messages (e.g. Mobile IP Agent 2306 Advertisements). The type value of this extension belongs to the 2307 Mobile IPv4 number space for Router Discovery messages maintained by 2308 IANA. The value assigned by IANA is TBD. This new extension uses 2309 the Link Layer and IPv4 Address Identifier (LLA) Sub-Type numbering 2310 space that requires IANA management (see section 10.2). 2312 Generalized Link Layer and IPv4 Address (LLA) Extension for Mobile IP 2313 Control messages: A new Mobile IPv4 extension appended to Mobile IP 2314 Control messages (e.g. Registration Request). The type value of this 2315 extension belongs to the Mobile IPv4 number space for extensions to 2316 Mobile IPv4 Control messages maintained by IANA. It MUST be in the 2317 skippable (128-255) range as defined in [1]. The value assigned is 2318 TBD by IANA. This new extension uses a the Link Layer and IP Address 2319 Identifier (LLA) Sub-Type numbering space that requires IANA 2320 management (see section 10.2). 2322 10.2. 2323 Generalized Link Layer and IP Address Identifier (LLA) Sub-type 2324 values 2326 This section describes the sub-type values that are applicable to 2327 both the Generalized LLA Extensions for Mobile IP Control and Router 2328 Discovery messages. This specification makes use of the Sub-type 2329 values 1-7, and all other values other than zero (reserved) are 2330 available for assignment via IETF consensus [14]. The seven Sub-type 2331 values defined in this specification are: 2333 1 3GPP2 International Mobile Station Identity and 2334 Connection ID [13] 2335 2 3GPP International Mobile Subscriber Identity [15] 2336 3 Ethernet 48 bit MAC address [5] 2337 4 64 bit Global ID, EUI-64 [6] 2338 5 Solicited IPv4 Address 2339 6 Access Point Identifier 2340 7 FA IPv4 Address 2342 10.3. 2343 New Message Type and Code 2345 Sections 4.4 and 4.5 define two new Mobile IPv4 message types: 2346 Handoff Request and Handoff Reply. These require two type numbers to 2347 be assigned by IANA from the Mobile IPv4 control message type address 2348 space. The Handoff Reply message also introduces its own Code field 2349 that requires IANA to manage a new Code address space. This 2350 specification makes use of the Code values 0-1, where 0 identifies a 2351 successful Handoff and 1 defines a generic handoff failure. All other 2352 values are available for assignment via IETF consensus [14]. 2354 Code Values for Mobile IP Handoff Reply Messages 2355 0 Successful Handoff 2356 1 Generic Handoff Failure 2357 2-255 Unallocated 2359 11. 2360 Security Considerations 2362 For the PRE-REGISTRATION method, as discussed in Section 3.8, the oFA 2363 and nFA MUST share a security association to authenticate and 2364 integrity protect messages transported between them. In addition oFA 2365 must be authorized to solicit nFA based on the security association. 2366 The minimal requirement to establish a security association between 2367 FAs is that both FAs support manual pre-configuration of security 2368 associations involving shared keys. Other mechanisms to establish 2369 security associations using IKE [16] based on shared and public keys 2370 may also be used. The inter-FA ICMP messages (solicitations and 2371 advertisements) MUST be authenticated and integrity protected using 2372 ESP [10]. The default ESP authentication algorithm for use in this 2373 specification is HMAC-SHA1-96 [12]. The absence of this security 2374 would allow denial of service attacks from malicious nodes at any 2375 distance from the FA. To secure Registration Request and Reply 2376 messages, PRE-REGISTRATION uses the security mechanisms already 2377 described in [1] and optionally [11]. 2379 POST-REGISTRATION introduces a new change to Mobile IPv4, which is 2380 the possibility that a MN may receive packets from an FA with which 2381 it has not yet performed a Mobile IPv4 Registration. It is not 2382 recommended that the MN drops packets from unknown FAs since it would 2383 effectively eliminate the advantages of POST-REGISTRATION. From a 2384 security viewpoint, dropping packets from unknown FAs would not 2385 provide significant protection for an MN from any attack. This is 2386 because any malicious host may use the MN's home address to send 2387 packets to the MN through its current known FA, therefore processing 2388 packets received from unknown FAs would not provide worse security 2389 than with normal Mobile IPv4. 2391 In a similar way to PRE-REGISTRATION, in POST-REGISTRATION oFA and 2392 nFA MUST share a security association required to protect the Handoff 2393 Request and Reply messages. The minimal requirement to establish a 2394 security association between FAs is that the FAs support manual pre- 2395 configuration of security associations involving shared keys. Other 2396 mechanisms to establish security associations using IKE [16] based on 2397 shared and public keys may also be used. The Handoff Request and 2398 Reply messages MUST be authenticated using the FA-FA authentication 2399 extension [11] that uses the default algorithm specified in [7]. The 2400 absence of this security would allow impersonation attacks and denial 2401 of service attacks. 2403 The minimal requirement is that all FAs involved in low latency 2404 handoffs MUST support manual pre-configuration of peer-to-peer 2405 security associations with neighbouring FAs, involving static keys 2406 and are already required to support the default algorithms of [1]. 2407 Other mechanisms to establish security associations using IKE [16] 2408 based on shared or public keys may also be used. 2410 Since the techniques outlined in this document depend on particular 2411 L2 information (triggers) to optimize performance, some level of L2 2412 security is assumed. Both PRE and POST-REGISTRATION techniques 2413 depend on L2 triggers, but the L2 security implications are different 2414 for the two techniques. 2416 In particular, in POST-REGISTRATION the L2 triggers initiate the 2417 establishment of tunnels that route IPv4 packets for the MN to its 2418 new location. Therefore the L2 triggers MUST be secured against any 2419 tampering by malicious nodes, either mobile or within the wired 2420 network. The L2 addresses or IPv4 addresses for the MN and the FAs 2421 that appear in the L2 triggers MUST correspond to the actual nodes 2422 that are participating in the handoff. If there is any possibility 2423 that tampering may occur, the recipient of an L2 trigger MUST have 2424 some way of authenticating the L2 information. Wireless networks 2425 that do not provide such features will be subject to impersonation 2426 attacks, where malicious nodes could cause FAs to believe that a MN 2427 has moved to other service areas or to allow a bogus MN to obtain 2428 unauthorized service from an FA prior to performing a Mobile IPv4 2429 registration. In POST-REGISTRATION the L2 triggers would be 2430 typically sent between a wireless base station and the FA. No 2431 standard protocol exists at this time to communicate the L2 trigger 2432 information but it is important that any future protocol used for 2433 this purpose provides adequate security. If the wireless base station 2434 and FA were integrated then this security threat would not apply. 2435 Also the layer-2 control messages on the wireless link must be 2436 secured appropriately to prevent a malicious node from running 2437 impersonation attacks and causing unwanted L2 triggers to be 2438 generated. Integrity and replay protection would be required to 2439 avoid impersonation threats and resource consumption threats where a 2440 malicious node replays old messages to cause resource consumption. 2441 This depends on the type of L2 security of the wireless link. For 2442 example in cellular technologies the control messages are secured, 2443 although the type of security varies depending on the cellular 2444 standard, but this is not typically the case in WLAN IEEE 802.11 2445 networks. 2447 In PRE-REGISTRATION the security of L2 triggers has different 2448 implications. The PRE-REGISTRATION technique depends on Mobile IPv4 2449 security between MN and FA, so the same security considerations in 2450 [1] apply. Should malicious nodes be able to generate or modify L2 2451 trigger information (i.e. L2-ST or L2-TT), this would cause 2452 advertisements to be sent to the MN. They would consume wireless 2453 resources and processing in the MN, but would not allow an 2454 impersonation attacks. In order to prevent such denial of service 2455 attacks, there should be a limit on the number of advertisements that 2456 an FA (oFA) will relay to the MN as a result of the reception of L2 2457 triggers. This number will depend on the L2 technology and the 2458 default limit is 10 per second. 2460 12. 2461 Acknowledgements 2463 The authors want to thank Lennart Bang, Bryan Hartwell, Joel 2464 Hortelius and Jonathan Wood for valuable comments and suggestions on 2465 the whole draft. The authors also thank the Mobile IPv4 WG chairs, 2466 Phil Roberts and Basavaraj Patil, for their input. 2468 13. 2469 Editor's Address 2471 Karim El Malki 2472 Athonet 2473 E-mail: karim@athonet.com 2475 14. 2476 Contributing Authors 2478 Pat Calhoun, Black Storm Networks 2479 2481 Tom Hiller, Lucent Technologies 2482 2484 James Kempf, NTT DoCoMo USA Labs 2485 2487 Peter J. McCann, Lucent Technologies 2488 2490 Ajoy Singh, Motorola 2491 2493 Hesham Soliman, Flarion 2494 2496 Sebastian Thalanany, Motorola 2497 2499 15. 2500 References 2502 15.1. 2503 Normative References 2505 [1] C. Perkins, Editor, "IPv4 Mobility Support for IPv4", RFC 2506 3344, August 2002. 2508 [2] S. Bradner. "Key words for use in RFCs to Indicate 2509 Requirement Levels". BCP 14, RFC 2119, March 1997. 2511 [3] G. Montenegro, "Reverse Tunneling for Mobile IPv4, revised", 2512 RFC 3024, January 2001. 2514 [4] D. Farinacci, T. Li, S. Hanks, and P. Traina, "Generic 2515 Routing Encapsulation (GRE)", RFC 2784, Internet Engineering 2516 Task Force, March 2000. 2518 [5] D. Plummer, "An Ethernet Address Resolution Protocol - or 2519 Converting Network Protocol Addresses to 48.bit Ethernet 2520 Address for Transmission on Ethernet Hardware", RFC 826, 2521 November 1982. 2523 [6] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 2524 Registration Authority", 2525 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, 2526 March 1997. 2528 [7] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response 2529 Extensions", RFC 3012, November 2000. 2531 [8] S. Deering, "ICMP Router Discovery", RFC 1256, September 1991 2533 [9] J. Postel, "Internet Control Message Protocol," RFC 792, 2534 September 1981. 2536 [10] S. Kent, R. Atkinson, "IPv4 Encapsulating Security Payload 2537 (ESP)", RFC 2406, November 1998. 2539 [11] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IPv4 2540 Regional Tunnel Management", draft-ietf-mobileip-reg-tunnel-08 2541 (work in progress), November 2003. 2543 [12] C. Madson and R. Glenn, "The Use of HMAC-SHA1-96 within ESP 2544 and AH", RFC 2404, November 1998. 2546 15.2. 2547 Informative References 2549 [13] TIA/EIA/IS-2000. 2551 [14] T. Narten, H, Alvestrand, "Guidelines for Writing an IANA 2552 Considerations Section in RFCs", BCP 26, RFC 2434, October 2553 1998. 2555 [15] 3GPP TS 23.003 (www.3gpp.org). 2557 [16] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", 2558 RFC 2409, November 1998. 2560 Appendix A - Gateway Foreign Agents 2562 The Mobile IPv4 Regional Registration specification [11] introduces 2563 the Gateway Foreign Agent (GFA), as a mobility agent that two FAs 2564 providing service to a MN have in common. Figure A.1 provides an 2565 example of a MN's initial registration through the GFA. If this is 2566 the first registration message, the message MUST be forwarded to the 2567 HA. All packets destined for the mobile will be delivered to the 2568 GFA, which in turn will forward the packets to the FA servicing the 2569 MN. 2571 Reg Req +-----+ Reg Req 2572 +----------->| oFA |--------------+ 2573 | +-----+ | 2574 | v 2575 +----+ +-----+ Reg Req +----+ 2576 | MN | | GFA |<------->| HA | 2577 +----+ +-----+ +----+ 2579 +-----+ 2580 | nFA | 2581 +-----+ 2583 Figure A.1 - Initial Registrations through GFA 2585 If the MN moves to an nFA that is serviced by a GFA common with oFA, 2586 the MN MAY issue a Regional Registration Request (see Figure A.2). 2587 The Regional Registration message does not need to be forwarded to 2588 the HA, since the MN's traffic can still be delivered to the same 2589 GFA. This optimized approach effectively reduces the latency 2590 involved in the registration process. 2592 +-----+ 2593 | oFA | 2594 +-----+ 2595 +----+ +-----+ +----+ 2596 | MN | | GFA | | HA | 2597 +----+ +-----+ +----+ 2598 | ^ 2599 | +-----+ | 2600 +------------>| nFA |-------------+ 2601 Regional Reg +-----+ Regional Reg 2603 Figure A.2 - Regional Registration through GFA 2605 Note that the GFA may also be the MN's first-hop router. 2607 Appendix B - Low Latency Handoffs for Multiple-Interface MNs 2609 For MNs that have two wireless network interfaces, either on the same 2610 wireless network or on wireless networks having different wireless L2 2611 technologies, the techniques discussed in this document may be 2612 unnecessary if the Mobile IPv4 stack on the MN allows switching an 2613 IPv4 address binding between interfaces. This Appendix discusses how 2614 multiple wireless interfaces can aid low latency handoff. 2616 +------+ +---------+ 2617 | HA |--------| (GFA) | 2618 +------+ +---------+ 2619 / \ 2620 ... ... 2621 / \ 2622 / \ 2623 +------+ +------+ 2624 | oFA | | nFA | 2625 +------+ +------+ 2626 | | 2627 +------+ +------+ 2628 | RN1 | | RN2 | 2629 +------+ +------+ 2630 +------+ 2631 | MN | ---------> 2632 +------+ 2633 Movement 2635 Figure B.1 - Network Model for Mobile IPv4 With Multi-Access 2637 Figure B.1 illustrates the normal and hierarchical MIPv4 models. As 2638 shown in the figure, assume that the MN is connected to Radio Network 2639 1 (RN1) and is registered with oFA through which it is receiving 2640 traffic. Suppose MN enters the coverage area of RN2 and nFA and that 2641 it prefers connectivity to this network for reasons beyond the scope 2642 of this document (e.g. user preferences, cost, QoS available etc.). 2643 The MN activates the interface to RN2 but continues communicating 2644 through RN1. The MN may solicit advertisements from nFA through the 2645 interface connected to RN1 to speed up the handoff process, provided 2646 there is no TTL restriction, or it can solicit advertisements through 2647 the interface connected to RN2 if it has been configured for IPv4 2648 traffic. 2650 Once the MN is registered with nFA and is successfully receiving and 2651 transmitting through the new network, it tears down the interface to 2652 RN1. If the MN has enough time to complete this procedure without 2653 incurring degraded service or disconnection, the MN would experience 2654 a seamless multi-access handoff but it may not be possible in all 2655 cases, due to network coverage or for other reasons. Should multiple 2656 interface handoff be possible then the low latency methods described 2657 in this document are not necessary. 2659 In order to support the possible failure of the connectivity with the 2660 new network (RN2/nFA) in the short period following handoff, the MN 2661 may use the S bit in its Mobile IPv4 Registration Request to maintain 2662 simultaneous bindings both its existing (HA or GFA) binding with oFA 2663 and a new binding with nFA. 2665 Appendix C - PRE_REGISTRATION Message Summary 2667 This appendix contains a quick reference for IPv4 and Layer 2 2668 addresses to be used in PRE-REGISTRATION messages. 2670 Proxy Router Advertisement (PrRtAdv) 2671 This is a standard Router/Agent Advertisement [1] with the following 2672 characteristics: 2673 Source IPv4 Address: nFA IPv4 Address 2674 Source Layer 2 Address: oFA L2 Address 2675 Destination IPv4 Address: MN IPv4 Address (from PrRtSol) 2676 Destination Layer 2 Address: MN L2 Address (from PrRtSol) 2677 LLA Extension (defined in this spec): containing nFA Layer 2 2678 Address. 2680 Proxy Router Solicitation (PrRtSol) 2681 This is a standard Router/Agent Solicitation [1] with the following 2682 characteristics: 2683 Source IPv4 Address: MN Address 2684 Source Layer 2 Address: MN Address 2685 Destination IPv4 Address: oFA Address (from source address of 2686 previous Router Advertisement or PrRtAdv) 2687 Destination Layer 2 Address: oFA Address (from source address of 2688 previous Router Advertisement or PrRtAdv LLA) 2689 LLA Extension (defined in this spec): depends on the layer 2 2690 Technology (e.g. typically for WLAN this would be the BSSID of the 2691 new WLAN Access Point) 2693 Registration Request (as seen on MN-oFA link) 2694 This is a Mobile IPv4 Registration Request message [1] with the 2695 following characteristics: 2696 Source IPv4 Address: MN Address 2697 Source Layer 2 Address: MN Address 2698 Destination IPv4 Address: nFA Address (from source addr of PrRtAdv) 2699 Destination Layer 2 Address: Default Router (i.e. oFA Address) 2700 Although this is not mandated, an MN implementation may set the S bit 2701 (see chapter 6.) in Registration Request messages to improve the 2702 handoff and avoid problems due to failed layer 2 handoffs and layer 2 2703 ping-pong effects between two base stations. 2705 Registration Reply (as seen on oFA-MN link) 2706 This is a Mobile IPv4 Registration Reply message [1] with the 2707 following characteristics: 2708 Source IPv4 Address: nFA Address 2709 Source Layer 2 Address: oFA Address 2710 Destination IPv4 Address: MN Address (from source of Registration 2711 Request) 2712 Destination Layer 2 Address: MN Address (from source of 2713 Registration Request) 2715 Full Copyright Statement 2717 Copyright (C) The Internet Society (2005). 2719 This document is subject to the rights, licenses and restrictions 2720 contained in BCP 78, and except as set forth therein, the authors 2721 retain all their rights. 2723 This document and the information contained herein are provided on an 2724 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2725 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2726 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2727 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2728 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2729 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2731 Intellectual Property 2733 The IETF takes no position regarding the validity or scope of any 2734 Intellectual Property Rights or other rights that might be claimed to 2735 pertain to the implementation or use of the technology described in 2736 this document or the extent to which any license under such rights 2737 might or might not be available; nor does it represent that it has 2738 made any independent effort to identify any such rights. Information 2739 on the procedures with respect to rights in RFC documents can be 2740 found in BCP 78 and BCP 79. 2742 Copies of IPR disclosures made to the IETF Secretariat and any 2743 assurances of licenses to be made available, or the result of an 2744 attempt made to obtain a general license or permission for the use of 2745 such proprietary rights by implementers or users of this 2746 specification can be obtained from the IETF on-line IPR repository at 2747 http://www.ietf.org/ipr. 2749 The IETF invites any interested party to bring to its attention any 2750 copyrights, patents or patent applications, or other proprietary 2751 rights that may cover technology that may be required to implement 2752 this standard. Please address the information to the IETF at ietf- 2753 ipr@ietf.org. 2755 Acknowledgement 2757 Funding for the RFC Editor function is currently provided by the 2758 Internet Society.