idnits 2.17.1 draft-dommety-mobileip-lma-ipv6-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 717 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 112 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 125 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 28 instances of lines with control characters in the document. ** The abstract seems to contain references ([5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 43 has weird spacing: '...routers send ...' == Line 44 has weird spacing: '...oes its own d...' == Line 47 has weird spacing: '...This draft pr...' == Line 48 has weird spacing: '...e. The main ...' == Line 49 has weird spacing: '...provide an in...' == (107 more instances...) -- 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 (December 2001) is 8160 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 651, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 667, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 670, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 674, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 677, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 687, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-01 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-01) exists of draft-soliman-mobileip-hmipv6-00 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-10 -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2463 (ref. '8') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. '9') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '10') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '11') (Obsoleted by RFC 4862) == Outdated reference: A later version (-03) exists of draft-calhoun-mobileip-proactive-fa-01 -- Possible downref: Normative reference to a draft: ref. '12' == Outdated reference: A later version (-06) exists of draft-perkins-aaav6-00 -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: A later version (-02) exists of draft-dommety-mobileip-anchor-handoff-01 -- Possible downref: Normative reference to a draft: ref. '14' Summary: 14 errors (**), 0 flaws (~~), 20 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Gopal Dommety, Cisco Systems 2 Category: Standards Track Madhavi W. Subbarao, Cisco 3 Systems 4 Title: draft-dommety-mobileip-lma-ipv6-03.txt Kent Leung, Cisco Systems 5 Raj Patil, Nokia 6 July 2001 8 Expires December 2001 10 Local Mobility Agents in IPv6 11 draft-dommety-mobileip-lma-ipv6-03.txt 13 Status of this Memo 15 This document is a submission by the mobile-ip Working Group of the 16 Internet Engineering Task Force (IETF). Comments should be submitted 17 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 19 Distribution of this memo is unlimited. 21 This document is an Internet Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and working groups. Note that other groups may also distribute 25 working documents as Internet Drafts. 27 Internet Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 Mobile IPv6 is better integrated into IPv6, thereby obviating the need 41 for Foreign Agents (FA) in IPv6 [5]. In IPv6 most, if not all, of the 42 functions of the Mobile IPv4 FA [1] are assumed by other parts of the 43 Mobile IPv6 architecture. Specifically, all routers send Router 44 Advertisements and the Mobile Node (MN) does its own detunneling and 45 Routing Header processing. 47 This draft proposes the concept of Local Mobility Agents (LMA) in 48 Mobile IPv6 Architecture. The main advantage is that LMAs facilitate 49 fast handoffs and provide an inter-network mechanism between IPv6 and 50 IPv4 networks. Other advantages include aiding in Authentication in 51 Local Domain, satisfying the need of commercial operators to have a 52 central/controlling element for mobile users/stations in their 53 networks through access control, and localizing signalling. LMA is an 54 optional entity. 56 1. Introduction 58 Mobile IPv6 is better integrated into IPv6, thereby obviating the 59 need for FA in IPv6 [5]. In IPv6 most, if not all, of the 60 functions of the Mobile IPv4 FA [1] are assumed by other parts of the 61 Mobile IPv6 architecture. Specifically, all routers send Router 62 Advertisements and the MN does its own detunneling and Routing Header 63 processing. 65 This draft proposes the concept of Local Mobility Agents (LMA) in 66 Mobile IPv6 Architecture. LMAs are analogous to FAs in Mobile IPv4. 67 The main advantage is that LMAs facilitate fast handoffs and provide 68 an inter-network mechanism between IPv6 and IPv4 networks. Other 69 advantages include Authentication in Local Domain and satisfying the 70 need of commercial operators to have a central/controlling element 71 for mobile users/stations in their networks. LMA is an optional entity. 73 In wide area deployment, the handoff latencies in current Mobile IP 74 could be high. In a mobile environment, it is important to limit 75 the delay experienced in communication as a MN moves from one access 76 point/base station to another. The introduction of LMA into the 77 Mobile IPv6 Architecture enables fast handoffs. Moreover, the evolution 78 of the Internet to IPv6 will be gradual. LMAs provide the capability of 79 establishing either a IPv6 tunnel between the Home Agent (HA) and LMA, or 80 an IPv4 tunnel to support legacy systems. 82 1.1 Problem Description 84 Mobility agents similar to FA in Mobile IPv4 do not exist in Mobile 85 IPv6. Although there is no need for such agents for the operation of 86 Mobile IP in IPv6, the introduction of LMAs into the Mobile IPv6 87 Architecture has several advantages: 89 A) Fast Handoff: As a MN moves from one subnet to another, the break 90 in communication perceived by the user must be low. This is 91 especially important for real-time data services and voice 92 applications. Having a LMA provides advantages for the following 93 reasons: 95 1. It provides the option of using a LMA Care of Address 96 (CoA). This eliminates at least one round trip time if using DHCPv6 97 [6] or Autoconfiguration with Duplicate Address Detection (DAD) [11] 98 to obtain the COA. (It may be possible to perform Stateless 99 Autoconfiguration without DAD.) 101 2. It introduces the possibility of managing handoffs locally 102 by performing quick rerouting. Examples of such mechanisms are Local 103 Anchoring [14], Regionalized Tunnels [3], and Proactive Handoffs[12]. 104 By using LMA, a MN can send a Binding Update BU to a HA or 105 Corresponding Node (CN) through encapsulation via the LMA. Thus, the 106 waiting time incurred by the MN in transmitting sequential bindings is 107 eliminated. LMAs can be used to create a hierarchy either dynamically 108 or statically. 110 NOTE: Fast Handoff in the case where the Link Layer permits 111 wireless access to more than one access point can be done with 112 simultaneous bindings. By using hierarchies, LMAs can still reduce 113 signalling back to the HA, thereby speeding up a handoff. 115 B) Inter-network mechanism between IPv6 and IPv4: LMAs provide the 116 option of establishing either an IPv6 tunnel or IPv4 tunnel between 117 the HA and LMA, depending on the network. This enables the operation 118 of Mobile IPv6 over the existing Internet, which is predominently IPv4 119 and will most likely evolve gradually to IPv6. 121 C) Authentication in the Local Domain. The Mobile has to authenticate 122 to the Foreign Domain. LMA's aiding in Authentication in Local Domain 123 and satisfying the need of commercial operators to have a 124 central/controlling element for mobile users/stations in their 125 networks through access control. 127 D) Useful in Creating Static or Dynamic Hierarchies. 129 2. Solution 131 2.1 Network Model 133 The network model being considered is illustrated in Figure 1. 135 +----------------------------------+ +----------------+ 136 | Visited | | | 137 | Network | | | 138 | | | | 139 | +------+ +-------+ | IPv6 or IPv4 | +------+ | 140 | | | | | | tunnel to HA | | | | 141 | | MN |-------------| LMA |-------------------------|HA/CN | | 142 | | | | |-------------------------| | | 143 | +------+ +-------+ | | +------+ | 144 | | | | 145 | | +----------------+ 146 | +-------+ | 147 | | LMA | | 148 | | | | 149 | | | | 150 | +-------+ | 151 +----------------------------------+ 153 Figure 1: Network Model 155 The above figure shows a new element LMA in the IPv6 mobility 156 architecture. There are two types of LMAs possible depending on the 157 palcement of the LMA relative to the mobile. 159 1. LMA that has Link Layer connectivity to the MN (similar 160 to FA in Mobile IPv4). 162 2. LMAs that do not have Link Layer connectivity to the MN 163 at that instant of time (similar to Anchor FA[14] or GFA[3]). 165 There are processing differences between the LMA that has Link Layer 166 connectivity to the MN and the LMA that does not. Using the LMA 167 framework, static or dynamic hierarchies can be created, and various 168 handoff schemes can be realized. 170 The scenarios described below illustrate the working of IPv6 in the 171 presence of LMAs. The details are provided in 172 Sections 2.2 and 3. 174 Option 1: Scnario with out a LMA (Basic Operation of Mobile IPv6): 176 +----------------------------------+ +----------------+ 177 | Visited | | | 178 | Network | | | 179 | | | | 180 | +------+ | | +------+ | 181 | | | | | | | | 182 | | MN |-----------------------------------------------|HA/CN | | 183 | | | | | | | | 184 | +------+ | | +------+ | 185 | | | | 186 | | +----------------+ 187 +----------------------------------+ 189 Fig 2: Basic Operation of Mobile IPv6 without LMA 191 In this option, the IP packets destined to the mobiles are routed as 192 follows: 194 1. If the CN has a biniding cache for the mobile, source routes the 195 packets to the MN 197 2. If the CN does not have a biniding cache, the packets are routed 198 to the HA and the HA tunnels the packets to MN. 200 Option 2: Scenario with LMA that has link layer connectivity with the 201 MN (henceforth this type of LMA is referred to as LC-LMA). 203 +----------------------------------+ +----------------+ 204 | Visited | | | 205 | Network | | | 206 | | | | 207 | +------+ +-------+ | | +------+ | 208 | | | | | | | | | | 209 | | MN |*************| LMA |-------------------------|HA/CN | | 210 | | | | |-------------------------| | | 211 | +------+ +-------+ | | +------+ | 212 | | | | 213 | | +----------------+ 214 +----------------------------------+ 216 Fig 3: Operation with Link Connected LMA (****** denotes Link Layer 217 connectivity). 219 In this configuration, LMA advertises the LMA CoA, which is used by 220 the MN in its encapsulated Binding Updates (BU) (see Section 2.2.2). 222 (1) HA tunnels packets for MN to LMA and LMA detunnels and 223 forwards packets to MN, or 225 (2) CN source routes the packets to MN via LMA. 227 LMA can also optionally advertise an IPv4 option if it can support an 228 IPv4 tunnel. If IPv4 option is present in BU, HA determines whether to 229 establish IPv6 or IPv4 tunnel to the LC-LMA (depending on HA 230 capabilities). 232 Option 3: Scenario with a LC-LMA and an LMA with out direct link layer 233 connectivity to the mobile. 235 +----------------------------------+ +----------------+ 236 | Visited | | | 237 | Network | | | 238 | | | | 239 | +------+ +-------+ +-----+ | | +------+ | 240 | | | | | | | | | | | | 241 | | MN |****|LC-LMA |---|LMA 1| -----------------------|HA/CN | | 242 | | | | |---| | -----------------------| | | 243 | +------+ +-------+ +-----+ | | +------+ | 244 | | | | 245 | | +----------------+ 246 +----------------------------------+ 248 Fig 4: Operation with Link Connected LMA and another LMA (hierarchy) 250 In this scenario, a hierarchy is either a statically or 251 dynamically established using Local Mobility Agents (Section 4). 253 LC-LMA maintains visitor mapping of MN home address with LC-LMA CoA. 254 LMA 1 maintains visitor mapping of MN home address with LMA 1 and 255 LC-LMA CoA. 257 (1) When packets for MN arrive at LMA 1 (via either 258 tunneling from HA or source routed from CN), it verifies that the MN 259 is visiting on its network, and then tunnels the packets to LC-LMA 260 CoA. 261 (2) LC-LMA detunnels and forwards packets to MN. 263 Depending of the capabilities of the various Agents, whenever 264 tunelling is performed, IPv6 or IPv4 tunnel is established between 265 entities. 267 Option 4: Scenario with LMA that does not have link layer connectivity 268 with the MN. 270 +----------------------------------+ +----------------+ 271 | Visited | | | 272 | Network | | | 273 | | | | 274 | +------+ +-------+ | | +------+ | 275 | | | | | | | | | | 276 | | MN |-------------| LMA |-------------------------|HA/CN | | 277 | | |-------------| |-------------------------| | | 278 | +------+ +-------+ | | +------+ | 279 | | | | 280 | | +----------------+ 281 +----------------------------------+ 283 Fig 4: Operation with LMA that is not Link Connected 285 In this sceanrio, the Mobile is assumed to know the LMA. Possible 286 methods by which the mobile learns of the LMA are: 288 A. All routers on the link advertise the LMA CoA 289 which they learn from LMA advertisements. The MN uses the LMA CoA in 290 its encapsulated Binding Updates (see Section 2.2.2). 292 B. An LMA discovery procedure is followed 294 C. The Mobile has knowledge of the LMA. For example, when performing 295 anchoring the mobile knows the previous LC-LMA. 297 Once the appropriate tunnels/binding caches are established. The routing of 298 packets is as follows: 300 (1) HA tunnels packets for MN to LMA and LMA Tunnels packets to 301 Co-located CoA of the MN, or 302 (2) CN source routes the packets to MN via LMA, and LMA Tunnels 303 packets to Co-located CoA of the MN. 305 In both cases, LMA tunnels packets to MN. 307 2.2 Enhancements 309 In order to facilitate the above described scenarios, the following 310 enhancements are proposed: 312 The neighbor discovery phase is proposed to be enhanced to send the 313 LMA CoA in the Router Advertisement message. 315 An enhancement is proposed where a MN can either send a Binding Update 316 to the HA/CN in a one-phase or two-phase approach. In the one-phase 317 approach, bindings at the LMA and HA/CN can be updated in a single 318 transmission by the MN, where the MN sends an encaspulated Binding 319 Update to the LMA, which is then detunneled and relayed to the HA/CN. 320 In the two-phase approach, a Binding Update is first sent to the LMA 321 and once the Binding Update is acknowledged by the LMA, the MN sends a 322 Binding Update to HA/CN. Two-Phase Binding Update is similar to the 323 procedure described in [4] and may incur higher latency than the 324 one-phase approach. 326 2.2.1 Neighbour Discovery Extension 328 The LMAs send Router Advertisements with the following new option. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type | Length | Sequence Number | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Binding Lifetime |C|L| reserved | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 + + 339 | | 340 + LMA CoA + 341 | | 342 + + 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | More LMA Care of Addresses | 346 + + 348 Fields: 350 Type Message type. To be assigned. 352 Length 8-bit unsigned integer. The length in bytes 353 of the option (including the type and length fields). 355 Sequence Number 356 The count of Agent Advertisement messages sent 357 since the agent was initialized (Similar to 358 Sequence Number in Mobile IPv4). 360 Binding Lifetime 361 Longest lifetime (in seconds) that the LMA is willing 362 to accept in any Binding Update. 364 C Bit if not set indicates that the first LMA CoA is 365 that of LC-LMA, i.e., the mobile can use this CoA 366 with out acquiring its own CoA. 368 L Bit indicating whether the LMA can support a 369 IPv4 tunnel. Bit when set indicates the support to 370 terminate a IPv4 tunnel. 372 TBW (To be Worked on) Multiple LMAs on the link. 374 2.2.2 Binding Update and Binding Update Acknowledgement Usage 376 In order to create a hierarchy, encapsulated binding updates are sent 377 as shown in the figure below. 379 A Binding Update has the format specified in [5] with the addition of a new 380 bit following the 'Duplicate Address Detection' (D) bit: 382 L Bit indicating that the MN is requesting a IPv4 383 tunnel. In order for the MN to set this bit, an LMA 384 advertisement with the L bit set must have been heard. 386 A new header extension (TBD) will be used in the Binding Update 387 Acknowledgement to indicate the preference of the HA. Note: That most 388 of the time the MN is aware of the HA's capabilities and will request 389 the appropriate tunnel type. 391 +----------------------------------//-----+ 392 | Original | | 393 | | Original Packet Payload | 394 | Header | | 395 | w/ BU DH | | 396 +----------------------------------//-----+ 397 398 | 399 v 400 < Original Packet > 401 402 +---------+ - - - - - +-------------------------//--------------+ 403 | IPv6 | IPv6 | | 404 | | Extension | Original Packet with Binding Update | 405 | Header | Headers | | 406 +---------+ - - - - - +-------------------------//--------------+ 407 < Binding Update with original Binding Update Encapsulated > 409 BU: Binding Update 410 DH: Destination Header 412 Using this tunneling mechanisim a static/dynamic hierarchy can be 413 created as required [3][14]. (See Section 4.) 415 Since IP Authentication Headers (AH) are used for authentication in 416 Mobile IPv6, the Binding Update between the MN and HA/CN is 417 encapsulated within a Binding Update sent to the LMA. The inner 418 Binding Update, i.e., BU between MN and HA/CN, contains all of the 419 necessary extensions [5], including IPv6 headers. It is necessary 420 to encapsulate the Binding Update between the MN and HA/CN so that 421 proper authentication will pass at the HA/CN. Note that the LMA cannot 422 simply create a Binding Update on behalf of the MN since authentication at the 423 HA/CN would fail. 425 If a MN is communicating with multiple hosts, only the first 426 Binding Update needs to be transmitted in this manner. This establishes 427 the visitor binding at the LMA. The remaining Binding Updates can be 428 transmitted 429 directly to the CNs with the LMA CoA as the CoA in the Binding Update. 431 3 Processing Considerations 433 3.1 Mobile Node 435 The MN behaves as a regular Mobile IPv6 node using a CoA. The 436 variation is that the MN uses a LMA CoA instead of a co-located CoA 437 and sends its Binding Updates to the HA/CN via a LMA. Note that if 438 the MN should desire, it may use a co-located CoA and register via the 439 LMA. In this case, the LMA simply forwards packets destined for the 440 MN to the co-located CoA. (Although using a LMA CoA reduces latency, 441 this draft allows for using co-located CoA and sending Binding Update via 442 LMA. Mobile can also send a Binding Update directly with its 443 co-located CoA.) 445 The MN learns of the LMA CoA and IPv4 tunnel options provided by the LMA 446 either by listening to Router Advertisements or performing Router 447 Solicitation as specified in [5]. 449 The MN sends a Binding Update to the HA/CN via the LMA as follows. 450 The MN creates a Binding Update to the HA/CN with CoA set to the LMA CoA, 451 IPv6 Destination Address set to HA/CN address, and IPv6 Source Address 452 set to MN home address. The MN will include the necessary extensions 453 so that the HA/CN can properly authenticate the Binding Update when it 454 is relayed by the LMA. The MN encapsulates this Binding Update within 455 another Binding Update destined to the LMA. If the LMA advertises an 456 IPv4 option, the MN sets the 'L' bit in both Binding Updates if it 457 desires an IPv4 tunnel. 459 For hierarchical network configurations (e.g., Option 3 in Section 2.1), 460 further encapsulation is done as described in Section 4. 462 The MN receives packets via the LMA with an IPv6 Routing Header set to LMA 463 CoA and IPv6 Destination Address set to MN address. (If a CN does not 464 have a binding cache entry, the packet is routed via the MN's home 465 network and the the IPv6 Destination Address will be the MN's home 466 address.) 468 3.2 Local Mobility Agent 470 3.2.1 LMA with Link Layer connectivity 472 Signaling Flow: 474 MN Advertisement LMA HA/CN 475 |<--------------------- | | 476 | Binding Update | | 477 |---------------------->| Binding Update | 478 | |---------------------->| 479 | | | 480 | | | 481 | | Binding Ack | 482 | Binding Ack |<----------------------| 483 |<----------------------| | 485 The LMA will send periodic Router Advertisements as defined in Section 2.2.1 486 to facilitate neighbor discovery. If the LMA receives a Router Solication 487 message, it will respond by sending a LMA Router Advertisement. 489 As described in Section 2.2.2, the Binding Update to the HA/CN is encapsulated 490 within a Binding Update sent to the LMA. When the LMA receives a Binding 491 Update 492 from a MN, it checks that the 493 proper authentication is present. If the Binding Update is valid, the LMA 494 strips off the tunnel headers and forwards the internal Binding Update 495 packet to the HA/CN. It enters the Binding Update Request in its Pending 496 Binding Update table. 498 The Binding Update Acknowledgements are encapsulated: inner Binding 499 Acknowledgement 500 has Destination Address = MN home address and Source Address = HA/CN 501 address. Outer 502 Binding Acknowledgement has Destination Address = LMA CoA and 503 Source Address = HA/CN address. 505 When the MN receives the Binding Update Acknowledgement for the encapsulated 506 Binding Update, i.e., between MN and HA/CN, the MN can assume that the 507 Binding Update 508 to the LMA was also received. (Since the encapsulated Binding Update could 509 not 510 have been received by the HA/CN unless the outer Binding Update was received 511 by the LMA.) 513 When a LMA receives a packet for the MN, it relays the packet after 514 adjusting the Routing Header extension and sends it to the MN much 515 like a FA in Mobile IPv4 Architecture. 517 3.2.2 LMA with out link Layer connectivity 519 When LMA receives packets, it tunnels these packets to the registered CoA 520 in the Binding Update (the registered CoA could be LC-LMA CoA or 521 co-located CoA). It additionally authenticates the Binding Updates and 522 sends tunneled Binding Updates/Acknowledgements. This operation is 523 similar to the operation of a HA in IPv6 (The other alternative is to 524 change the Routing Header and the Destination Header. One needs to take 525 caution that the order of headers for IPSec is preserved before 526 delivering the packet to the MN in this case ). 528 3.3 Home Agent 530 Th Home Agent is much like a regular IPv6 HA, except that the HA may choose 531 between establishing an IPv6 or IPv4 tunnel depending on the request from 532 the MN 533 and the HA capabilities. If the 'L' bit is set in the received Binding 534 Update and 535 the HA can support an IPv4 tunnel, the HA may set up an IPv4 tunnel between 536 the 537 HA and CoA. 539 3.4 Correspondent Node 541 The Correspondent node behaves much like a regular IPv6 node. If the CN 542 receives 543 a Binding Update with the 'L' bit set and does not understand this option, 544 the CN simply 545 ignores the bit and processes the Binding Update as usual, i.e., assumes 546 the BU is a 547 regular IPv6 BU and the bit is not set. 549 4. Creating a Hierarchy using LMAs 551 With LMAs, either a static hierarchy or dynamic hierarchy (Section 552 2.1, Option 3, Fig. 4) can be formed using encapsulated Binding 553 Updates. 555 4.1 Dynamic Hierarchy 557 A dynamic hierarchy can be formed using various approaches. Th main idea 558 is that the 559 MN remembers the LMA CoA and IPv4 options of the last LMA to which it was 560 attached. When 561 the MN determines that it has moved to the domain of another LMA, the MN 562 registers back 563 with the 'previous' LMA, creating a dynamic set of tunnels. The tunnel 564 between the HA and 565 'previous' LMA is still maintained, and a new tunnel is established between 566 the 'new' LMA and 567 'previous' LMA. The LMA sends LMA advertisements as described in Section 568 2.2.1, with 569 the inclusion of any necessary extensions for building the dynamic 570 hierarchy. Similarly, 571 the MN sends encapsulated Binding Updates in the same manner as described 572 for Static Hierarchy (Section 4.1), with the inclusion of any necessary 573 extensions. 574 The details of the scheme will depend on the specific dynamic 575 hierarchy scheme being employed. 577 As an example using Local Anchoring [14], the mobile as it moves to 578 the new subnet, performs a Binding update through the new LC-LMA to 579 the old LC-LMA (Anchor LMA) and packets get forwarded through the old 580 LC-LMA to the new LC-LMA the LMAs will include the necessary 581 extensions in the LMA advertisements to announce the anchoring 582 capability. The MN maintains an anchor LMA within a zoned region 583 (domain), and as it moves within the domain, it registers back with 584 the anchor LMA. It includes the necessary anchor extensions in its 585 Binding Updates to the 'new' LMA and anchor LMA, i.e., BU (ii) and 586 (iii) from Section 4.1. As the MN moves from one zoned region to 587 another, the existing dynamic hierarchy can be dismantled and a new 588 dynamic hierarchy can be established. 590 4.2 Static Hierarchy 592 In a static hierarchy, the LMA 1 announces its capabilities in its LMA 593 advertisements. The LC-LMA advertises both LC-LMA CoA and LMA 1 CoA. 594 Thus, the MN learns of the static hierarchy structure via the LC-LMA 595 advertisements. 597 When the MN first enters a foreign domain, the MN sends encapsulated 598 Binding Updates as follows: 599 (i) Inner Most Binding Update: LMA 1 CoA to HA/CN. 600 (ii) Outer-1 Binding Update: LC-LMA CoA to LMA 1 601 (iii) Outer Most Binding Update: LC-LMA CoA to LC-LMA 603 As the MN moves from an LC-LMA to a 'new' LC-LMA still within the domain of 604 LMA 1, 605 it need only register back with the 'new' LC-LMA. Thus, the signaling all 606 the way 607 back to the HA/CN is reduced (the implicit and valid assumption is that the 608 'previous' LC-LMA and 'new' LC-LMA are in closer proximity). 610 5. How Existing Handoff Proposals for IPv4 apply to IPv6 612 To Be Discussed Later 614 6. How Local Authentication can be performed in IPv6 616 To Be Discussed Later 618 7. Synergies and differences between MAP [4] and this draft 620 The approach described herein does not require the MN to obtain a 621 co-located CoA (using either DHCP or Autoconfiguration). The MN registers 622 back with the HA using the LMA CoA, and can use the LMA to create either 623 a static or dynamic hierarchy. Hence, the latency involved with the MN 624 acquiring a co-located CoA is avoided. Moreover, by using hiearchies, 625 the signaling all the way back to the HA each time is avoided. 627 Since the Binding Update is forwarded to the HA/CN directly by the LMA, 628 the delay in the MN waiting for a Binding Acknowledgement from the LMA and then 629 registering back with the HA/CN using the LMA CoA is also avoided. 631 The reduction in latency will aid in the efficiency of fast handoffs. 633 6. Security Considerations 635 Security associations as specified in [5] are used to protect all the 636 binding update and reply mesages. 638 7. IANA Considerations 640 8. Acknowledgments 642 The authors would like to thank Steve Deering for his suggestions 643 and helpful discussion. 645 9. References 647 [1] C. Perkins. IP Mobility Support. Request for Comments 648 (Proposed Standard) 2002, Internet Engineering Task Force, 649 October 1996. 651 [2] S. Deering. ICMP Router Discovery Messages. Request for 652 Comments (Proposed Standard) 1256, Internet Engineering Task 653 Force, September 1991. 655 [3] E. Gustafsson, et. al. Mobile IP Regional Tunnel Management. 656 draft-ietf-mobileip-reg-tunnel-01.txt, August 1999. 658 [4] H. Soliman and K. El Malki, Hierarchical Mobile IPv6 and Fast 659 Handoffs. draft-soliman-mobileip-hmipv6-00.txt, June 2000. 661 [5] D. Johnson and C. Perkins, "Mobility Support in IPv6", 662 draft-ietf-mobileip-ipv6-10.txt, February 2000. 664 [6] Jim Bound and Charles Perkins. Dynamic Host Configuration 665 Protocol for IPv6 (DHCPv6), February 1999. Work in progress. 667 [7] Alex Conta and Stephen Deering. Generic packet tunneling in 668 IPv6 specification. RFC 2473, December 1998. 670 [8] Alex Conta and Stephen Deering. Internet Control Message 671 Protocol (ICMPv6) for the Internet Protocol version 6 (IPv6) 672 specification. RFC 2463, December 1998. 674 [9] Stephen E. Deering and Robert M. Hinden. Internet Protocol 675 version 6 (IPv6) specification. RFC 2460, December 1998. 677 [10] Thomas Narten, Erik Nordmark, and William Allen Simpson. 678 Neighbor Discovery for IP version 6 (IPv6). RFC 2461, December 679 1998. 681 [11] Susan Thomson and Thomas Narten. IPv6 stateless address 682 autoconfiguration. RFC 2462, December 1998. 684 [12] J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted Hand-off, 685 draft-calhoun-mobileip-proactive-fa-01.txt, June 2002 687 [13] N. Asokhan et. al, AAA for IPv6 Network Access, 688 draft-perkins-aaav6-00.txt, March 2000. 690 [14] G. Dommety and T. Ye, "Local and Indirect Registration for 691 Anchoring Handoffs", 692 draft-dommety-mobileip-anchor-handoff-01.txt(work in 693 progress), July 2000. 695 Internet Draft 697 Authors Information 699 Gopal Dommety 700 Cisco Systems, Inc. 701 170 West Tasman Drive 702 San Jose, CA 95134 703 e-mail: gdommety@cisco.com 705 Madhavi W. Subbarao 706 Cisco Systems, Inc. 707 7025 Kit Creek Road 708 RTP, NC 27709 709 e-mail: msubbara@cisco.com 711 Kent Leung 712 Cisco Systems, Inc. 713 170 West Tasman Drive 714 San Jose, CA 95134 715 e-mail: kleung@cisco.com 717 Raj Patil 718 Nokia 720 Appendix: 722 Three options of sending Binding Updates via the LMA. 724 1. Sequential Bindings (Similar to MAP[4]) 726 MN Advertisement LMA HA/CN 727 |<--------------------- | | 728 | Binding Update | | 729 |---------------------->| | 730 | Binding Ack | | 731 |<----------------------| Binding Update | 732 |---------------------------------------------->| 733 | Binding Ack | 734 |<----------------------------------------------| 736 The drawback in this case is the latency incurred by sequential transmissions. 738 2. LMA Relays Bindings to HA/CN 740 MN Advertisement LMA HA/CN 741 |<--------------------- | | 742 | Binding Update | | 743 |---------------------->| Binding Update | 744 | |---------------------->| 745 | | | 746 | | | 747 | | Binding Ack | 748 | Binding Ack |<----------------------| 749 |<----------------------| | 751 In this case MN sends a Binding Update to LMA, and LMA sends a 752 Binding Update to HA/CN on behalf of MN. If the Binding Update is 753 required to be acknowledged, LMA waits for the Binding Update Ack 754 from the HA/CN and once it receives the Ack, it sends an Ack for the 755 original Binding Update from the MN. The problem in this case, 756 however, is that the HA/CN will not be able to authenticate the Binding 757 Update sent by the LMA on behalf of the MN. 759 3. Encapsulated Bindings 761 MN Advertisement LMA HA/CN 762 |<--------------------- | | 763 | Binding Update | | 764 |---------------------->| Binding Update | 765 | |---------------------->| 766 | | | 767 | | | 768 | | Binding Ack | 769 | Binding Ack |<----------------------| 770 |<----------------------| | 772 In this case MN sends a Binding Update to LMA with the Binding Update for 773 HA/CN encapsulated. Once the LMA authenticates the MN, the LMA relays the 774 inner Binding Update to HA/CN. The HA/CN sends a Binding Ack back to the MN 775 encapsulated within a Binding Ack to the LMA.