idnits 2.17.00 (12 Aug 2021) /tmp/idnits52288/draft-mohan-nflm-proto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 823. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 2005) is 6062 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: '9' is defined on line 766, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4068 (ref. '2') (Obsoleted by RFC 5268) -- Obsolete informational reference (is this intentional?): RFC 4140 (ref. '3') (Obsoleted by RFC 5380) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '4') (Obsoleted by RFC 8415) == Outdated reference: draft-ietf-ipv6-2461bis has been published as RFC 4861 == Outdated reference: draft-ietf-ipv6-rfc2462bis has been published as RFC 4862 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '9') (Obsoleted by RFC 6275) -- Unexpected draft version: The latest known version of draft-ipsec-rfc2401bis is -00, but you're referring to -06. Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M.Parthasarathy 3 Internet Draft Basavaraj Patil 4 Document: draft-mohan-nflm-proto-00.txt Rajeev Koodli 5 Expires: April 2006 Nokia 6 October 2005 8 Network-based Fast Handovers for Local Mobility (NFLM) 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 Local Mobility is IP mobility over a restricted geographical and 42 administrative domain. This document describes a network based 43 localized mobility management protocol which does not require host 44 involvement while moving within such a local mobility domain. 46 Network-based Fast Handovers for local mobility October 2005 48 Table of Contents 50 1.0 Introduction..................................................2 51 2.0 Terminology...................................................3 52 3.0 Requirements for LMM..........................................4 53 4.0 IP Address Configuration......................................5 54 4.1 DHCPv6.....................................................6 55 4.2 Stateless Address Autoconfiguration........................7 56 4.3 Duplicate Address Detection................................7 57 5.0 Local Domain Configuration....................................8 58 6.0 Protocol Details..............................................8 59 6.1 Predictive handoff.........................................9 60 6.2 Reactive handoff..........................................10 61 7.0 Packet Forwarding in local domain............................12 62 8.0 Message Formats..............................................12 63 8.1 MN identifier option......................................12 64 8.2 Handover Initiate message.................................13 65 8.3 Handover Acknowledgement message..........................14 66 8.4 Fast Binding Update.......................................14 67 8.5 Fast Binding Acknowledgement..............................14 68 9.0 IANA Considerations..........................................14 69 10.0 Security considerations.....................................15 70 11.0 Normative References........................................16 71 12.0 Informative References......................................16 72 13.0 Acknowledgments.............................................16 73 14.0 Author's Addresses..........................................16 74 Intellectual Property Statement..................................17 75 Disclaimer of Validity...........................................17 76 Copyright Statement..............................................18 77 Acknowledgment...................................................18 79 1.0 Introduction 81 Localized mobility management has been addressed by various protocols 82 like HMIPv6 [3]. These protocols involve the host to manage the 83 mobility on their own when moving within the local domain. This 84 document describes a protocol where the mobility is managed by the 85 network without the involvement of the host. The protocol is based on 86 FMIPv6 [2] message exchanges. In FMIPv6 [2], the handoff is either 87 initiated by the network or the mobile node. In either case, the host 88 sends a fast binding update (FBU) to setup a tunnel with the access 89 router on the previous link. By establishing such a tunnel, the 90 mobile node ensures that the packets can keep flowing as it updates 91 the home agent and the correspondent node using the Mobile IPv6 [10] 92 signaling over the Internet, including the Return Routability 93 Network-based Fast Handovers for local mobility October 2005 95 procedure. The protocol described in this document does not involve 96 the host to send the FBU; instead the Access router sends the FBU to 97 a Mobility Anchor Point (MAP) on behalf of the mobile node. This 98 ensures that the packets can continue to flow from the MAP towards 99 the new access router while the mobile node does not even know that 100 it has changed access routers. We refer to this protocol as Network- 101 based Fast Handovers for Local Mobility (NFLM). 103 This document is organized as follows. First, it discusses the 104 requirements of the localized mobility management protocol(LMM). 105 Next, it discusses the IP address configuration mechanism followed by 106 the protocol description. All the messages defined in this document 107 are taken from [2]. There are no new messages defined here. There are 108 a few extra options needed by NFLM which are defined in Section 8.0. 110 2.0 Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [1]. 116 The following terminology and abbreviations are taken from [2] and 117 modified for NFLM. 119 Mobile Node (MN) 121 A Mobile IPv6 host. 123 Access Point (AP) 125 A Layer 2 device connected to an IP subnet that offers wireless 126 connectivity to an MN. An Access Point Identifier (AP-ID) refers 127 to the AP's L2 address. Sometimes, AP-ID is also referred to as a 128 Base Station Subsystem ID (BSSID). 130 Access Router (AR) 132 The MN's default router. 134 Previous Access Router (PAR) 136 The MN's default router prior to its handover. 138 New Access Router (NAR) 140 The MN's default router subsequent to its handover. 142 Previous CoA (PCoA) 143 Network-based Fast Handovers for local mobility October 2005 145 The MN's Care of Address valid on PAR's subnet. 147 Handover 149 The process by which a mobile node moves from one point of 150 attachment to another point of attachment, resulting in the MN 151 terminating existing connectivity and establishing new IP 152 connectivity. 154 Fast Binding Update (FBU) 156 A message from the NAR instructing the MAP to redirect traffic 157 (toward NAR). 159 Fast Binding Acknowledgment (FBack) 161 A message from the MAP in response to an FBU. 163 Handover Initiate (HI) 165 A message from the PAR to the NAR regarding an MN's handover. 167 Handover Acknowledge (HAck) 169 A message from the NAR to the PAR as a response to HI. 171 MN identifier 173 An identifier to uniquely identify a mobile node in the local 174 domain. This can be a link-layer address or some other identifier 175 depending on the access technology. 177 MAP 179 Mobility Anchor Point. The router that maintains reachability for 180 hosts in the local domain using host routes. 182 3.0 Requirements for LMM 184 The requirements for a localized mobility management protocol can be 185 considered as follows. 187 1) The protocol should address mobility within the local domain as 188 shown in Figure 1 without the involvement of the host. To be 189 more specific, the protocol is used when the MN moves between AP 190 2 and AP 3. 192 2) The host should be able to maintain the same IP address when 193 moving within the local mobility domain. 195 Network-based Fast Handovers for local mobility October 2005 197 Localized Mobility Localized Mobility 198 Management Domain A Management Domain B 200 +-------+ +-------+ 201 | MAP | | MAP | 202 +-------+ +-------+ 203 / \ | 204 / \ | 205 / \ | 206 / \ | 207 / \ | 208 / \ | 209 +-----+ +-----+ +-----+ 210 |AR A1| |AR A2| |AR B1| 211 +-----+ +-----+ +-----+ 212 * * * 213 * * * * * 214 * * * * * 215 * * * * * 216 * * * * * 217 * * * * * 218 /\ /\ /\ /\ /\ 219 /AP\ /AP\ /AP\ /AP\ /AP\ 220 / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ 221 ------ ------ ------ ------ ------ 223 +--+ +--+ 224 |MN|----->|MN| 225 +--+ +--+ 226 Local 227 Mobility 229 Figure 1) Localized Mobility Management Domain 231 3) The host should not have any involvement in its mobility 232 management (except for advertising its presence on the new 233 link), when moving within the local mobility domain. 235 4) Access Routers should be able to discover MAPs and prefixes 236 dynamically without the need for manual configuration. 238 4.0 IP Address Configuration 240 The mobile node configures the IP address when it enters the local 241 domain for the first time. The mobile node configures the IP address 242 as it would do when it moves to a new IP link i.e., there is nothing 243 special required from the mobile node. Once it has configured the IP 244 Network-based Fast Handovers for local mobility October 2005 246 address as described below, the MN does not have to configure a new 247 IP address as long as it stays within the local domain. This implies 248 that when the mobile node connects to a new access router, it should 249 not determine that it has moved to a new IP link. Otherwise, it will 250 configure a new IP address which should be avoided. This influences 251 the address configuration method. Following sections describe the 252 address configuration options. 254 4.1 DHCPv6 256 DHCPv6 [4] may be used for address configuration in the local domain. 257 This can be enabled in different ways. 259 . As specified in stateless autoconfiguration [6], the host 260 attempts to use stateful autoconfiguration if no routers are 261 present on the link. This can be achieved by turning of the 262 router advertisements on the Access Routers. 264 . Routers can be configured to send router advertisements without 265 including any prefixes but setting the Managed address 266 configuration flag (M bit) in the router advertisement. This 267 will trigger the host to invoke DHCPv6 for address 268 configuration. 270 Since mobile hosts are expected to send router solicitation to detect 271 whether they moved links or not, the latter option SHOULD be used. 273 As specified in [4], the client MUST include the client identifier 274 option in the DHCP request message. Any valid DHCP unique identifier 275 specified in [4] can be used. When the client may have moved to a new 276 link (e.g. switching wireless access point), the client should use 277 the CONFIRM message along with the client Identifier option that was 278 sent with the DHCP request message. The client performs DAD and 279 declines the address if the address is used already on the link. 281 The DHCP server SHOULD be located centrally so that it is able to 282 assign the same address to the client as long as it remains in the 283 local domain. The DHCP relay agent will be present on the Access 284 routers, forwarding the DHCP messages towards the DHCP server. When 285 the server receives the DHCP message from the relay agent, either the 286 link-address or the interface ID option will be present. 288 The link-address field is assigned from the interface on which the 289 message is received from the client. If there is more than one prefix 290 on the interface from which the packet was received, the DHCP relay 291 agent may not be able to pick the right prefix to insert in the link- 292 address field. The link-address field should match the prefix of the 293 client's address in the CONFIRM request. As the server uses the link- 294 address field to select an appropriate address for the client, 295 Network-based Fast Handovers for local mobility October 2005 297 inserting a wrong link-address value can lead the server to reject 298 the request and return NotOnLink status in its reply. Hence, this 299 option should not be used by the relay agent unless it can insert the 300 prefix matching the address in the CONFIRM request. 302 The DHCPv6 relay agent may use the Interface-ID field to influence 303 the address assignment policy on the server. As this is considered to 304 be opaque, the agent may copy the prefix of the requested address in 305 the CONFIRM request to the Interface-ID. Then the server may be 306 configured to use the Interface-ID for policy assignment i.e the 307 interface-ID SHOULD match the prefix of the requested address. 309 4.2 Stateless Address Autoconfiguration 311 The client may also autoconfigure the address using the prefix 312 information in the Router advertisements (RA) sent by the Access 313 Router. As the client needs to keep the same address across all the 314 links that moves in the NELMM domain, all the access routers in the 315 local mobility domain SHOULD advertise the same set of client 316 prefixes so that the clients believe that they have not moved at 317 layer 3. 319 The router advertisement normally contains prefixes that are valid 320 for the link. The prefix information option contained in the RA has 321 two bits for each prefix. The A bit indicates whether the prefix can 322 be used to auto-configure an address. This bit MUST be set on at 323 least one prefix so that the mobile nodes can autoconfigure an 324 address. There is another bit in the RA namely the L bit which is 325 used to determine the on-link status. As the mobile nodes roam around 326 in the local domain keeping the same address, it is not possible to 327 use the prefix information to determine the current point of 328 attachment of a given node. Both the Access router and the MAP use 329 the host routes to learn about the current Point of Attachment of the 330 clients. Hence, the on-link flag MUST NOT be set on any prefixes. 332 When the client configures the address for the first time, it would 333 send a router solicitation with unspecified source address. The 334 router advertisement MUST contain the same set of prefixes that will 335 be advertised by all Access routers in the local mobility domain. The 336 mobile node follows the procedure described in [5] and [6] for 337 configuring the address. When the MN believes that it may have moved 338 to a new link, it should send a router solicitation with the address 339 configured earlier. This is used by the new access router to set up 340 any tunnel if needed. 342 4.3 Duplicate Address Detection 344 Duplicate Address Detection MUST be performed on all unicast 345 addresses prior to assigning them to an interface, regardless of 346 Network-based Fast Handovers for local mobility October 2005 348 whether they are obtained through stateless address autoconfiguration 349 or DHCPv6 [6]. This procedure verifies that another node on the link 350 is not using the same address. But the LMM requirements require that 351 the node maintains the same address in the local domain. This implies 352 that one has to make sure that no two nodes on any link has the same 353 address. 355 NFLM achieves this by MAP verifying that there is only one binding 356 for a given MN address. But as the node moves to a different link, 357 the binding needs to be updated. If the MAP would check whether a 358 binding exists already, the update would fail as the binding was 359 created when the node was on a previous link. Hence, the MAP uses a 360 unique client identifier to verify that it is the same client that 361 moved to a new link. The security issues related to this are 362 discussed later. 364 5.0 Local Domain Configuration 366 The local domain configuration consists of two parts. 368 1. Discovery of MAP by Access Routers. 370 2. Discovery of the prefixes that needs to be advertised to the 371 clients by Access Routers. 373 RFC 2782 [8] defines the service resource record (SRV RR), that 374 allows a client to locate the address of a particular 375 service/protocol. This can be used by the Access Routers to discover 376 MAP in the local domain. A new service name ("netlmm-aflm") for NFLM 377 needs to be defined and the protocol name is 'ipv6'. 379 All the Access routers advertise prefixes for clients to configure an 380 address that is valid in the local domain. These prefixes can be 381 learnt from the MAP using Mobile Prefix discovery as defined in RFC 382 3775 [8]. 384 6.0 Protocol Details 386 The NFLM protocol begins when the mobile node is handing over to a 387 new Access Router. In some wireless technologies, the handover 388 control may reside in the network (Access Router). NFLM supports both 389 Predictive handoff and Reactive handoff. MN does not do anything 390 special in the NFLM protocol. It does what a node would do when it 391 receives a L2 trigger. The next two sections discuss the Predictive 392 and reactive handoff. 394 Network-based Fast Handovers for local mobility October 2005 396 6.1 Predictive handoff 398 The Predictive handoff happens when the MN is already connected to 399 the local domain and the Access Router receives a L2 trigger 400 informing it of a certain MN's upcoming movement to a new Access 401 Router. The trigger provides enough information from which the IP 402 address of the new access router (NAR) and IP address of the MN can 403 be obtained. 405 MN PAR NAR MAP 406 | | | | 407 | | | | 408 | --L2 Trigger -->|------ HI------>|---- FBU -->| 409 | | | | 410 | |<------HAck-----|-----FBack--| 411 | | | | 412 Disconnect | | | 413 | | | | 414 Connect | | | 415 | --NA---------->| | | 416 | | | | 417 | | forward packets| | 418 |<==================================|<===========| 419 | | | | 421 When the PAR receives the L2 trigger, PAR sends a Handoff Initiate 422 message to the NAR. The Handoff Initiate message contains the MN's IP 423 address (PCoA) and MN's identifier. When NAR receives the HI message, 424 it SHOULD check whether a tunnel to the MAP exists for PCoA or not. 425 If the tunnel already exists, it could mean one of two things. The HI 426 message from PAR is spurious and NAR already had setup a tunnel with 427 MAP when it saw the L2 trigger earlier. It could also mean that there 428 is already a node with the same PCoA address on the link. The NAR 429 could verify the MN's identifier to see whether it is the same node 430 or a different node. If it is the same node, then it continues 431 processing the HI message. Otherwise, it returns failure indicating 432 Duplicate Address. When PAR receives such a message, it SHOULD fail 433 the handover process if possible. If the handover has already 434 happened, then the MN would figure out that it has a duplicate 435 address when it does DAD on the new link. 437 If NAR successfully processes the HI message, it sends a Fast Binding 438 Update message to the MAP to redirect the tunnel from the old Access 439 Router to itself. The FBU message contains PCoA as the home address, 440 NAR's address as the Care-of address and an option to carry the MN's 441 unique identifier. When MAP receives the FBU message, it does the 442 following checks. 444 Network-based Fast Handovers for local mobility October 2005 446 . It checks to see if there is a binding for the PCoA. If it does 447 not exist, it creates a new binding entry. 449 . If a binding already exists, it checks to see if the MN's 450 identifier in the FBU matches with the identifier in the 451 binding. If it does not match, it fails the request. If it 452 matches, then it updates the binding information. 454 Once the MAP successfully processes the FBU, it sets (or updates) the 455 tunnel to NAR for sending and receiving packets from PCoA. Normally a 456 host route will be added for PCoA pointing to the tunnel. When the 457 NAR receives a successful FBack message, it checks to see if the FBU 458 was processed successfully. If there is a failure, the same is 459 indicated in the HAck message. If FBack indicates success, it creates 460 a tunnel to the MAP and sets up the forwarding in such a way that 461 packets with source address as PCoA gets forwarded into the tunnel. 462 It also maintains state (similar to the binding state) which can be 463 used to verify duplicates or spurious indications from PAR or MN. It 464 also creates a host route for forwarding packets to the MN. NAR sends 465 a HAck message back to the PAR indicating that it successfully 466 processed the Handoff procedure. When PAR receives the HAck message, 467 it removes the PAR-MAP tunnel and host routes for PCoA. 469 When the MN connects to the new link, it sends out a Neighbor 470 advertisement. The NAR can use this indication to start forwarding 471 packets to the PCoA. It will also forward the buffered packets (if 472 any) when the NA indication is received. 474 6.2 Reactive handoff 476 This handoff procedure happens when the MN connects to the local 477 domain for the first time or it connects to a new Access Router as a 478 result of L2 change. This is explained separately depending on how 479 the address is configured. 481 6.2.1 Autoconfiguration 483 When the MN connects to the local domain for the first time, 484 following things could happen. 486 . MN sends a router solicitation with unspecified address 488 . MN sends a router solicitation with an address configured from a 489 previous network probing to see if it is still connected to the 490 same network. 492 In either case, NAR just sends a Router advertisement. 494 Network-based Fast Handovers for local mobility October 2005 496 If the MN receives the RA, it assigns the IP address if there any 497 valid prefixes present and then it SHOULD send a unsolicited NA to 498 indicate its presence. 500 When the NAR receives the unsolicited NA, it sends the FBU message to 501 the MAP and the rest of the processing is the same as the previous 502 section. The unsolicited NA should contain the MN's identifier in 503 the SLLA option [5]. 505 If there is a failure in the FBU processing, the MAP and NAR does not 506 forward packets to the MN. The NAR SHOULD send an RA with NAACK 507 indicating failure [2]. 509 If the MN has already configured an address in the local domain and 510 just handing over to a new Access Router, it would send a router 511 solicitation and/or a neighbor solicitation to verify whether it is 512 still connected to the same access router or not. If the old Access 513 Router receives this message, it does not do any NFLM specific 514 operation. If it handed off to a new Access Router, the NS/RS message 515 is an indication that a new MN is possibly trying to get access. The 516 NAR checks to see if a tunnel/binding already exists for the PCoA. If 517 it exists, it checks to see if the MN's identifier matches with the 518 binding state. If there is a mismatch, router advertisement is sent 519 with NAACK option indicating failure. If it is successful, then the 520 NAR sends FBU to the MAP. The MAP also SHOULD add the IP address of 521 the PAR in the FBack option. This enables the NAR to send an 522 unsolicited HAck to PAR for cleaning up the host routes. Rest of the 523 processing by MAP and NAR is similar to the previous section. 525 6.2.2 DHCP Configuration 527 If the client is booting up for the first time, then it would send a 528 REQUEST [4] message to acquire the IP address. When the server sends 529 a successful DHCPv6 reply message to the client, the client assigns 530 the address normally and sends an unsolicited NA. This can be used as 531 an indication to setup the tunnel with the MAP as described in the 532 previous section. 534 If the client is handing off to a new Access Router, it SHOULD send a 535 CONFIRM [4] message. A successful reply to the CONFIRM can be taken 536 as an indication to send the FBU to the MAP. 538 DISCUSS: The DHCP server does not seem to check the client 539 identifier option in the CONFIRM request to match with the client 540 identifier option that was sent earlier during the REQUEST. 542 Network-based Fast Handovers for local mobility October 2005 544 MN NAR MAP 545 | | | 546 | | | 547 L2 Trigger -->| RtSol/NA/DHCP-->| ------- FBU -->| 548 | | | 549 | |<-------FBack---| 550 | | | 551 | | | 552 | | | 553 | forward packets | 554 |<================|<===============| 555 | | | 557 7.0 Packet Forwarding in local domain 559 The communication between a mobile node in the local domain and a 560 node in the external domain happens through MAP. MAP intercepts 561 packets from the external network and forwards it to the Access 562 Router (via the tunnel) to where the node is attached currently. MAP 563 always knows the correct point of attachment of the mobile node. 565 The communication between two nodes in the local domain can happen 566 through multiple ways. As the on-link (L bit) prefix is not set in 567 the RA, all packets from the MN are sent to the Access Router. If the 568 attached node is connected to the same Access Router, then the router 569 may forward the packets directly to the attached node without going 570 through MAP. It may also send a redirect to the mobile node so that 571 it can directly reach the peer node. If the peer node is not 572 connected to the same Access Router, then it forwards to the MAP 573 which in turn forwards to the right Access Router where the node is 574 located. 576 8.0 Message Formats 578 The messages defined in [2] will be used by NFLM. Instead of Link- 579 layer option, this document defines a new MN identifier option which 580 will be used by the network to identify a mobile node. 582 The messages used by NFLM are Handover Initiate message, Handover 583 Acknowledgement message, Fast Binding Update and Fast Binding 584 Acknowledgement. Following sections describe the differences between 585 NFLM and FMIPv6 [2]. 587 8.1 MN identifier option 589 This is a new option defined by NFLM. Though this has resemblance to 590 the Link Layer address option, this subsumes the functionality of the 591 link-layer address option. 593 Network-based Fast Handovers for local mobility October 2005 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Type | Length | Option-Code | Identifier 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Type TBD 603 Length 605 The size of this option in 8 octets including Type, Option- 606 code, and Length fields. 608 Option-code TBD 610 Identifier 612 A unique identifier for the MN in the local domain. It MAY 613 be a link-layer address of the MN or any other unique 614 identifier that can be used to uniquely identify a given 615 node in the local domain. 617 Appropriate padding MUST be used to ensure that the option size is 618 a multiple of 8 octets. 620 8.2 Handover Initiate message 622 The Handover Initiate message is an ICMPv6 message sent by an Access 623 Router (PAR) to another Access Router (AR) to initiate the process of 624 a MN's handover. 626 The message format is identical to [2] except for the options. 627 Following options MUST be included. 629 MN-identifier option 631 The unique value to identify the MN in the local network 633 Previous care-of Address 635 The IP address used by the MN while attached to the router where 636 this message is originating. It is the same as the MN's address 637 that is configured in the local domain. 639 Network-based Fast Handovers for local mobility October 2005 641 8.3 Handover Acknowledgement message 643 The Handover Acknowledgement message is an ICMPv6 message sent by an 644 Access Router (NAR) to another Access Router (PAR) to acknowledge the 645 MN's handover. NAR also sends an unsolicited HAck to flush the host 646 routes in PAR for the reactive handoff case. 648 MN-identifier option 650 This SHOULD be included to help PAR locate any state if needed. 652 A new code value should be defined to indicate that PCoA is not 653 valid. 655 8.4 Fast Binding Update 657 The Fast Binding Update message is sent by the Access router to the 658 Mobility anchor point to update the current binding of the MN. The 659 Home Address is PCoA and care-of address is the IP address of the 660 router originating this message (NAR). 662 The MN-identifier option SHOULD also be included in the message. 664 8.5 Fast Binding Acknowledgement 666 The Fast Binding Acknowledgement message is sent by the MAP to the 667 Access Router to acknowledge the Binding Update. 669 The MN-identifier option MAY be included in the message. The Alt-coa 670 option defined in [2] is not needed. 672 The MAP SHOULD also include the IP address of the PAR in its 673 response. This is used by NAR to send an unsolicited message to PAR 674 to clean up the host routes. 676 9.0 IANA Considerations 678 This document specifies the following messages which require new Type 679 assignment from IANA. 681 1. Fast Binding Update: Section 8.4 682 2. Fast Binding Acknowledgment: Section 8.5 683 3. Handover Initiate: Section 8.2 684 4. Handover Acknowledgment: Section 8.3 685 Network-based Fast Handovers for local mobility October 2005 687 The Handover Acknowledgment message needs an additional Type 688 assignment to support unsolicited transmission mode. 690 This document specifies the following new option which requires Type 691 assignment from IANA. 693 1. Mobile Node Identifier Option: Section 8.1 695 This document specifies a new code value for the HAck message. 697 1. PCoA Not valid, Duplicate Address 699 The future versions of this document may specify additional IANA 700 assignments. 702 10.0 Security considerations 704 As the MAP and AR is under the same trusted domain, the communication 705 between them (MAP-AR and AR-AR) can be secured using IPsec [10]. 707 Fast Binding Updates are sent by the Access Router to redirect 708 traffic destined to a particular address (PCoA) to itself. Fast 709 Binding Updates are triggered by unsolicited NA, Router Solicitation, 710 L2 trigger, DHCPv6 reply and DHCPv6 confirm messages. An attacker may 711 be able to send false messages to trigger the FBU and hence 712 redirecting the traffic to either itself or the victim. The victim 713 will be located on the link because the care-of address would be NAR. 715 Access Router check to see if a binding already exists by checking 716 both the IP address and the MN-identifier. This prevents an attacker 717 on the link to redirect traffic to itself. But the attacker can move 718 to a new link and cause the same attack by spoofing the MN-identifier 719 and the IP address. This is limited in the Predictive handoff case 720 because only L2 triggers can cause the access router to send the FBU. 721 If L2 triggers cannot be spoofed, such attacks can be avoided. 723 If neighbor discovery messages are secured using SEND [7], then the 724 attacker cannot spoof IP addresses within the local domain. A 725 legitimate owner of the IP address can still spoof MAC address as it 726 is not protected by SEND. But this attack is not specific to NFLM. 728 Even if DHCP messages are secured, the attacker can still trigger 729 false FBU by sending a CONFIRM message. SEND does not apply to 730 addresses configured using DHCP. 732 Attacker can pre-create a binding if it knows the IP address that 733 will be assigned to the MN. If SEND is used, then the attacker cannot 734 spoof the IP address. 736 Network-based Fast Handovers for local mobility October 2005 738 11.0 Normative References 740 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 741 Levels", BCP 14, RFC 2119, March 1997 743 [2] R. Koodli et al., "Fast Handovers for Mobile IPv6", RFC 4068, 744 July 2005 746 12.0 Informative References 748 [3] H. Soliman et al., "Hierarchical Mobile IPv6 Mobility 749 Management", RFC 4140, August 2005 751 [4] R. Droms et. al, "Dynamic Host Configuration Protocol for IPv6", 752 RFC 3315, July 2003 754 [5] T. Narten et al., "Neighbor Discovery for IP version 6 (IPv6)", 755 draft-ietf-ipv6-2461bis-04.txt, work in progress 757 [6] S. Thomson et. al, "IPv6 Stateless Address Autoconfiguration", 758 draft-ietf-ipv6-rfc2462bis-08.txt, work in progress 760 [7] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", RFC 3971, 761 March 2005 763 [8] A. Gulbrandsen et. al, "A DNS RR for specifying the location of 764 services (DNS SRV)", RFC 2782, February 2000 766 [9] D. Johnson et. al, "Mobility support in IPv6", RFC 3775, June 767 2004 769 [10] S. Kent et. al, "Security Architecture for the Internet 770 Protocol", draft-ipsec-rfc2401bis-06.txt, work in progress 772 13.0 Acknowledgments 774 The authors would like to thank Charles Perkins for providing a very 775 good feedback on this document. 777 14.0 Author's Addresses 779 Mohan Parthasarathy 780 NOKIA 781 313 Fairchild Drive 782 Mountain View CA-94043 783 Network-based Fast Handovers for local mobility October 2005 785 Email: mohan.parthasarathy@nokia.com 787 Rajeev Koodli 788 NOKIA 789 313 Fairchild Drive 790 Mountain View CA-94043 792 Email: Rajeev.Koodli@nokia.com 794 Basavaraj Patil 795 Nokia 796 6000 Connection drive, 797 Irving, TX 75039 799 Email: basavaraj.patil@nokia.com 801 Intellectual Property Statement 803 The IETF takes no position regarding the validity or scope of any 804 Intellectual Property Rights or other rights that might be claimed to 805 pertain to the implementation or use of the technology described in 806 this document or the extent to which any license under such rights 807 might or might not be available; nor does it represent that it has 808 made any independent effort to identify any such rights. Information 809 on the procedures with respect to rights in RFC documents can be 810 found in BCP 78 and BCP 79. 812 Copies of IPR disclosures made to the IETF Secretariat and any 813 assurances of licenses to be made available, or the result of an 814 attempt made to obtain a general license or permission for the use of 815 such proprietary rights by implementers or users of this 816 specification can be obtained from the IETF on-line IPR repository at 817 http://www.ietf.org/ipr. 819 The IETF invites any interested party to bring to its attention any 820 copyrights, patents or patent applications, or other proprietary 821 rights that may cover technology that may be required to implement 822 this standard. Please address the information to the IETF at 823 ietf-ipr@ietf.org. 825 Disclaimer of Validity 827 This document and the information contained herein are provided on an 828 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 829 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 830 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 831 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 832 Network-based Fast Handovers for local mobility October 2005 834 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 835 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 837 Copyright Statement 839 Copyright (C) The Internet Society (2005). 841 This document is subject to the rights, licenses and restrictions 842 contained in BCP 78, and except as set forth therein, the authors 843 retain all their rights. 845 Acknowledgment 847 Funding for the RFC Editor function is currently provided by the 848 Internet Society.