idnits 2.17.1 draft-abeille-netlmm-proxymip6ro-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 798. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (November 13, 2007) is 6002 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) == Missing Reference: 'T' is mentioned on line 585, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-07 == Outdated reference: A later version (-01) exists of draft-jaehwoon-netlmm-flush-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.jaehwoon-netlmm-flush' ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NetLMM Working Group M. Liebsch 3 Internet-Draft L. Le 4 Expires: May 16, 2008 NEC Laboratories 5 J. Abeille 6 Cisco Technology Center 7 November 13, 2007 9 Route Optimization for Proxy Mobile IPv6 10 draft-abeille-netlmm-proxymip6ro-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 16, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 The IETF is specifying a protocol for network-based localized 44 mobility management, which takes basic operation for registration, 45 tunnel management and de-registration into account. This document 46 specifies a protocol for route optimization in networks, which 47 support network-based mobility management. The specified protocol 48 focuses on efficient set up and maintenance of a route optimized path 49 between two mobile nodes and suits complex mobility scenarios as well 50 as networks with multiple mobility anchors. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Terminology and Functional Components . . . . . . . . . . . . 6 57 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1. General procedure . . . . . . . . . . . . . . . . . . . . 7 59 4.2. Route Optimization - Direct Mode . . . . . . . . . . . . . 8 60 4.2.1. RO Setup Procedure . . . . . . . . . . . . . . . . . . 8 61 4.2.2. RO Handover Procedure . . . . . . . . . . . . . . . . 10 62 4.3. Route Optimization - Proxy Mode . . . . . . . . . . . . . 12 63 4.3.1. RO Setup Procedure . . . . . . . . . . . . . . . . . . 12 64 4.3.2. RO Handover Procedure . . . . . . . . . . . . . . . . 14 65 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 17 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 67 7. Normative References . . . . . . . . . . . . . . . . . . . . . 19 68 Appendix A. MAG-local Route Optimization . . . . . . . . . . . . 20 69 Appendix B. Early State Activation (ESA) Policy . . . . . . . . . 21 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 71 Intellectual Property and Copyright Statements . . . . . . . . . . 23 73 1. Requirements notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 The NetLMM WG is specifying a protocol for network-based localized 82 mobility management (NetLMM), taking basic support for registration, 83 de-registration and handover into account in a first protocol 84 release. The specification of extensions and optimization is for 85 further study and subject for either being incorporated into future 86 versions of the protocol or specified in separate documents. In 87 scope of the base protocol specification is the set up and 88 maintenance of a forwarding tunnel between an MN's Mobility Access 89 Gateway (MAG) and its selected Local Mobility Anchor (LMA). Data 90 packets will always traverse the MN's MAG and its LMA, irrespective 91 of the location of the MN's remote communication endpoint. Even 92 though two communicating MNs might be located close to each other or 93 within the same local mobility domain, packets will traverse the MNs' 94 LMA(s). 96 This document specifies a protocol for route optimization in networks 97 which enable mobility and reachability to nodes by means of network- 98 based mobility management. Even though the concept behind the 99 proposed protocol is agnostic to the details of the NetLMM protocol, 100 this document focuses on the operation of the protocol with Proxy 101 MIPv6 [I-D.ietf-netlmm-proxymip6] as base protocol for network-based 102 mobility. 104 Control for route optimization in Mobile IPv6 is assigned to MNs and 105 Correspondent Nodes (CNs). MNs can send Binding Update (BU) 106 signaling to a CN to create a binding between the MN's home address 107 (HoA) and its care-of address (CoA) at the CN. [RFC3775] specifies 108 the Return Routability Test procedure between the CN and the MN to 109 help validate an MN's binding, as a CN might not have a security 110 association (SA) with the MN. Key concept of PMIPv6 is to relocate 111 the responsibility for maintaining a node's binding on the LMA from 112 the client (MN) to the functional entity MAG, which is co-located 113 with the infrastructure's access routers. To create and update a 114 binding at the MN's LMA, the MAG sends a Proxy BU (PBU) to the MN's 115 LMA and receives the LMA's Proxy BACK (PBACK) on behalf of the MN. 116 The binding establishes a valid tunnel for routing the MN's data 117 packets from the MAG to the LMA (uplink) and from the LMA to the MAG 118 (downlink). Relocating full control for route optimization from the 119 client to the MAG function according to the PMIPv6 architecture is 120 possible, but might not be the optimal approach. The set up and 121 maintenance of a route optimized path in network-based mobility 122 scenario is considered different from client-based mobility. This 123 document focuses on the establishment of a route optimized path 124 between two nodes, which are attached to the network by means of 125 PMIPv6. The set up of an optimized route between an MN's MAG and a 126 CN is not considered, as it reveals the address of the MN's MAG, 127 which can be mapped to the MN's location. Furthermore, it might be 128 against an operator's policy to reveal address information of its 129 infrastructure's network nodes. The MIPv6 Return Routability Test 130 procedure is not considered either, as the two MN's MAGs might share 131 an SA to protect signaling between MAGs. An alternative approach is 132 proposed to avoid relying on an SA between MAGs. 134 This protocol aims at efficient set up and maintenance of a route 135 optimized path between two MNs' MAGs, while taking difficult mobility 136 scenarios into account. Such scenarios comprise the set up of route 137 optimization between two MNs which are registered with different 138 LMAs, and the maintenance of the route optimized path in case one or 139 both terminals hand over. To coordinate the set up and maintenance 140 of the route optimized path efficiently, this protocol introduces the 141 function Route Optimization Controller (RO controller), which is 142 assigned to LMAs. During the set up of the route optimized path, one 143 LMA is dynamically selected as active RO controller. In case the two 144 MNs are registered with different LMAs, only one LMA, which has the 145 active RO controller function assigned for the associated route 146 optimized path, will coordinate the maintenance of the RO path and 147 the establishment of the RO states on the MAG(s) upon handover. 149 3. Terminology and Functional Components 151 o RO - Route Optimization 153 o RO Communication - RO focus is on data exchange between two mobile 154 nodes, MN1 and MN2, which are each registered in a NetLMM domain 155 (This includes the case where MN1 and MN2 are registered in two 156 different domains). Route optimized traffic goes from MN1 to 157 MAG1, then from MAG1 to MAG2 and from MAG2 to MN2 as well as vice 158 versa without traversing any LMA. 160 o RO Association - An association between MAG1 and MAG2, between 161 which RO is set up and maintained. To set up an association, 162 signaling will be used to create RO states at each MAG. The 163 association and state information can include MN profile data. 165 o RO Setup Trigger - This function is assigned to a network entity, 166 which first detects that RO can be established between the MAGs of 167 two communicating MNs. 169 o RO Update Trigger - When RO has been set up between MN1 and MN2 170 and one of them or even both initiate a handover, RO states need 171 to be updated or established. The relevant RO update trigger 172 function is assigned to an entity, which detects that RO states 173 need to be updated. 175 o RO Controller - The relevant RO controller functional entity for a 176 RO communication is selected the first time RO is set up between a 177 pair of MNs. In this protocol, the relevant active RO control 178 function is assigned to either MN1's or MN2's mobility anchor. 179 The entity which has been selected as active RO controller remains 180 anchored as controlling entity for the duration of the route 181 optimized communication and the lifetime of associated RO states. 183 4. Protocol Operation 185 4.1. General procedure 187 When MN1 initiates traffic towards MN2, the traffic is routed via 188 MN1's MAG and LMA (Figure 1). Either MN1's MAG or the LMA can detect 189 that a route optimized path can be set up between the two MNs. As an 190 example, detection can be based on the two MNs' IP address or the 191 associated MAGs' IP address. Accordingly, either the MAG or the LMA 192 takes over the role of the RO setup trigger. In the following 193 description, the LMA will serve as RO setup trigger. During the set 194 up phase of the route optimized path, either MN1's LMA (LMA1) or 195 MN2's LMA (LMA2) will be selected as active RO controller for this 196 particular RO association. In case both MNs are registered with the 197 same LMA, this single LMA will serve as RO controller. The LMA, 198 which has the active RO controller function assigned, coordinates the 199 set up of the route optimized path and associated signaling with the 200 relevant MAG(s). After the route optimized path has been set up 201 between the two MNs' MAGs, one or both MNs might hand over to a 202 different MAG. In that case, the LMA, which serves as active RO 203 controller for this particular RO association, coordinates the re- 204 establishment of the RO states on the relevant MAGs. 206 Internet Backbone 207 : : 208 : : 209 | | 210 +----+ +----+ 211 |LMA1|--------------|LMA2| 212 +----+ +----+ 213 | | 214 | | 215 +----+ +---------+----+ 216 | | | 217 +----+ +----+ +----+ 218 |MAG1| |MAG2| |MAG3| 219 +----+ +----+ +----+ 220 : : 221 +---+ +---+ 222 |MN1| |MN2| 223 +---+ +---+ 225 Figure 1: Reference architecture for route optimization in NetLMM 227 The protocol supports two modes of operation, the Direct Mode and the 228 Proxy Mode. In Direct Mode, the two relevant MAGs can exchange 229 signaling to set up and maintain RO states for a particular pair of 230 MNs. This might require these MAGs to share an SA to protect 231 signaling messages. Setting up SAs between MAGs for route 232 optimization is different from an SA between neighbor access routers 233 to allow protection of handover related signaling. For route 234 optimization, all relevant MAGs must share an SA, independent of 235 whether or not they are geographically adjacent. This might impact 236 the amount of SA-related states on each MAG. If this is not an 237 issue, the protocol's Direct Mode allows MAGs to exchange signaling 238 directly. Alternatively, the Proxy Mode can be operated, where only 239 LMAs exchange signaling with MAGs to set up and maintain RO states. 240 Inter-MAG signaling is not required in a system which operates the 241 Proxy Mode for route optimization. This section describes the two 242 modes separately, taking initial set up as well as maintenance of a 243 route optimized path in case of a handover into account. 244 Furthermore, description of both modes distinguish setting up a route 245 optimized path between two MNs which are registered with the same LMA 246 from a scenario where both MNs are registered with different LMAs. 248 This document specifies the following new conceptual messages for 249 route optimization. All messages need to be acknowledged by means of 250 an associated Ack message. Ack messages carry a status code field. 252 o RO Initiate - This message is sent from an LMA to inform another 253 entity (either an LMA or a MAG, depending on the scenario) that it 254 has to initiate or continue a RO procedure. By default, the 255 receiving entity should create but not activate any forwarding 256 states for the route optimized path. 258 o RO Setup - This message is sent from an LMA (in the proxy mode) or 259 a MAG (in the direct mode) to a MAG to activate or update RO 260 forwarding states for a particular RO association. 262 o RO Report - This message is used to inform about the result of 263 setting up RO states on a MAG. 265 An optional extension to this route optimization protocol solves 266 possible issues with out of order packets when the communication path 267 of an associated pair of MNs switches from non-route optimized to 268 route optimized. The associated extension is described in 269 [I-D.jaehwoon-netlmm-flush]. 271 4.2. Route Optimization - Direct Mode 273 4.2.1. RO Setup Procedure 275 In all scenarios, MN1 initiates traffic to MN2. 277 In Figure 2, both MNs are registered with the same LMA (LMA1). The 278 LMA detects, that route optimization can be set up, hence, serves as 279 RO setup trigger [T]. As both MNs are registered with the same LMA, 280 LMA1 serves as active RO controller (ROC). The LMA sends the RO 281 Initiate message to MAG2. This message carries the ID and Home 282 Network Prefix of MN1, the IP address of MAG1 as well as the ID of 283 MN2. After MAG2 has acknowledged the RO Initiate message, it sends 284 the RO Setup message to MAG1, carrying the ID of MN1 and MN2, as well 285 as the Home Network Prefix of MN2. MAG1 acknowledges the RO Setup 286 message. RO states are now established on MAG1 and MAG2. The result 287 of the set up is reported to the RO controller by means of a RO 288 Report message. 290 +----+ +----+ +----+ 291 |MAG1| |LMA1| |MAG2| 292 +----+ +----+ +----+ 293 | | | 294 | [T] | 295 | (ROC) | 296 | | | 297 | |-----RO Init----->| 298 | |<--RO Init Ack----| 299 | | | 300 |<---------------RO Setup--------------| 301 |--------------RO Setup Ack----------->| 302 | | | 303 | |<---RO Report-----| 304 | |--RO Report Ack-->| 305 | | | 307 Figure 2: RO Direct Mode - One relevant LMA in the topology 309 Figure 3 illustrates the set up of a route optimized path between two 310 MNs which are registered with different LMAs. MN1 is registered with 311 LMA1, MN2 is registered with LMA2. As MN1 initiates traffic, LMA1 312 detects the possibility to set up a route optimized path for this 313 communication [T], but does not know the IP address of MAG2. It 314 sends a RO Initiate message to LMA2, which carries information about 315 MAG1's IP address, MN1's ID and Home Network Prefix as well as the 316 Home Network Prefix of MN2. During this message handshake between 317 LMA1 and LMA2, one LMA can be selected as active RO controller for 318 this particular RO association. In this example, LMA2 is selected as 319 RO controller. Further set up of RO states is similar to Figure 2. 320 The only difference is that LMA2 should inform LMA1, who triggered 321 route optimization, of the procedure's result, which is done by means 322 of the RO Report message. 324 +----+ +----+ +----+ +----+ 325 |MAG1| |LMA1| |LMA2| |MAG2| 326 +----+ +----+ +----+ +----+ 327 | | | | 328 | [T] | | 329 | | (ROC) | 330 | | | | 331 | |------RO Init---->| | 332 | |<---RO Init Ack---| | 333 | | |----RO Init---->| 334 | | |<--RO Init Ack--| 335 |<-----------------------RO Set-----------------------| 336 |----------------------RO Setup Ack------------------>| 337 | | |<--RO Report----| 338 | | |-RO Report Ack->| 339 | |<----RO Report----| | 340 | |--RO Report Ack-->| | 341 | | | | 343 Figure 3: RO Direct Mode - Two relevant LMAs in the topology 345 4.2.2. RO Handover Procedure 347 This section specifies the signaling to maintain RO states in a 348 handover case. Figure 4 refers to the case where both MNs are 349 registered with the same LMA (LMA1). When LMA1 receives the Proxy BU 350 (PBU) from MN1's new MAG1 (nMAG1), it knows that RO states at MAGs 351 need to be updated (at MAG2) and established (at nMAG1). As LMA1 352 represents the RO trigger function as well as the active RO 353 controller for this RO association, LMA1 can send the RO Initiate to 354 nMAG1 to initiate the establishment of RO states. RO states on pMAG1 355 might expire or be explicitly deleted with MN1's Binding Update List 356 (BUL) entry. Whereas nMAG1 established the RO states, existing 357 states in MAG2 are updated through this procedure. The remaining 358 procedure is according to Figure 2. 360 +-----+ +-----+ +----+ +----+ 361 |nMAG1| |pMAG1| |LMA1| |MAG2| 362 +-----+ +-----+ +----+ +----+ 363 | | | | 364 | | (ROC) | 365 | | [T] | 366 |----------------- PBU- ------------->| | 367 |<----------------PBAck --------------| | 368 | | | | 369 | | | | 370 |<----------------RO Init-------------| | 371 |---------------RO Init Ack---------->| | 372 | | | | 373 | | | | 374 |-------------------------RO Setup -------------------->| 375 |<----------------------RO Setup Ack--------------------| 376 | | | | 377 | | | | 378 |----------------RO Report----------->| | 379 |<-------------RO Report Ack----------| | 380 | | | | 381 | | | | 383 Figure 4: RO Direct Mode - One relevant LMA in the topology, MN1 384 handover 386 Figure 5 illustrates the case where MN1 and MN2 are registered with 387 different LMAs. Again, MN1 initiates a handover from pMAG1 to nMAG1, 388 which results in nMAG1 sending a PBU to LMA1. In this scenario, we 389 assume that LMA2 serves as active RO controller, therefore LMA1 has 390 to initiate the update procedure by means of sending a RO Initiate 391 message to LMA2. Even though LMA2 is under control of the RO setup 392 and maintenance, it is preferable to send the RO Initiate from LMA1 393 to nMAG1, as there might be no SA established between LMA2 and nMAG1 394 and such cross-signaling should be avoided in any case. Hence, LMA2 395 controls LMA1 to send the RO Initiate to nMAG1 by means of the first 396 RO Initiate/Ack message handshake. LMA1 sends a RO Initiate message 397 to nMAG1 to initiate the RO Setup handshake between nMAG1 and MAG2. 398 The remaining procedure is similar to Figure 3, including the 399 notification of the procedure's result to the RO controller by means 400 of sending a RO Report message from LMA1 to LMA2. 402 Note: in the case where the RO update trigger and active RO 403 controller function are on the same LMA, this one does not send a RO 404 Initiate message to the other LMA, but directly sends a RO Initiate 405 message to its MAG. 407 +-----+ +-----+ +----+ +----+ +----+ 408 |nMAG1| |pMAG1| |LMA1| |LMA2| |MAG2| 409 +-----+ +-----+ +----+ +----+ +----+ 410 | | | | | 411 |------------PBU------------>| (ROC) | 412 |<----------PBAck -----------| | | 413 | | [T] | | 414 | | |----RO Init---->| | 415 | | |<--RO Init Ack--| | 416 | | | | | 417 |<----------RO Init----------| | | 418 |---------RO Init Ack------->| | | 419 | | | | | 420 | | | | | 421 |------------------------RO Setup--------------------------->| 422 |<---------------------RO Setup Ack--------------------------| 423 | | | | | 424 | | | | | 425 |----------RO Report-------->| | | 426 |<-------RO Report Ack-------| | | 427 | | | | | 428 | | |---RO Report--->| | 429 | | |<-RO Report Ack-| | 430 | | | | | 431 | | | | | 433 Figure 5: RO Direct Mode - Two relevant LMAs in the topology, MN1 434 handover 436 4.3. Route Optimization - Proxy Mode 438 In this mode, MAGs do not exchange signaling directly. A MAG 439 exchanges signaling only with the LMA, which is associated with the 440 attached MN. As a consequence, LMAs will proxy signaling messages 441 between MAGs to set up and update RO states. 443 4.3.1. RO Setup Procedure 445 The description in this section still assumes that MN1 initiates 446 traffic with MN2. The LMA serves as RO setup trigger and controller, 447 as in Direct Mode. According to Figure 6, the LMA sends a RO 448 Initiate message to MAG2 to create RO states. The RO Initiate 449 message indicates to MAG2 that the message sender (LMA1) serves as 450 proxy to set up the RO communication between MAG1 and MAG2. The 451 message contains MN2's ID, MN1's ID and Home Network Prefix, as well 452 as MAG1's IP address. MAG2 acknowledges the RO Initiate with the 453 associated Ack message. Subsequently, the LMA sends a RO Setup 454 message to MAG1 to proxy the signaling between MAG2 and MAG1. The 455 message contains MN1's ID, MN2's ID and Home Network Prefix, as well 456 as MAG2's IP address. At the reception of the RO Setup message, MAG1 457 creates and activates RO states for bi-directional route optimized 458 path for this particular RO association between between MAG1 and 459 MAG2. At reception of the associated Ack message, the LMA sends a RO 460 Setup message to MAG2 to indicate that MAG1's RO states have been 461 established and activated, as well as to activate MAG2's RO states 462 for a bi-directional route optimized path. 464 Note: RO states are established on MAG2 after the reception of the RO 465 Initiate message. For secure and stable operation, RO states on MAG2 466 should be activated only after the reception of the RO Setup message, 467 which indicates the status of MAG1's RO states. 469 +----+ +----+ +----+ 470 |MAG1| |LMA1| |MAG2| 471 +----+ +----+ +----+ 472 | | | 473 | [T] | 474 | (ROC) | 475 | | | 476 | |-------RO Init------>| 477 | |<----RO Init Ack-----| 478 | | | 479 |<-----RO Setup------| | 480 |----RO Setup Ack--->| | 481 | | | 482 | |------RO Setup------>| 483 | |<----RO Setup Ack----| 484 | | | 486 Figure 6: RO Proxy Mode - One relevant LMA in the topology 488 In the scenario with two LMAs (Figure 7), LMA1 serves as RO trigger, 489 whereas LMA2 is selected as active RO controller for this particular 490 RO association. As LMA1 has no information about MN2's MAG2, it 491 sends the RO Initiate message to LMA2 to request setting up RO 492 between MAG1 and MAG2. LMA2 establishes RO states at MAG2 by means 493 of the RO Initiate message. 495 As in the previous topology with a common LMA, MAG2 acknowledges the 496 RO Initiate message. LMA2 notifies LMA1 about the created RO states 497 at MAG2 by means of a RO Report handshake. The result causes LMA1 to 498 proxy the RO Setup message, which is sent to MAG1. MAG1 has now all 499 RO states set up and activated, whereas MAG2 waits for the RO Setup 500 from LMA2 to activate its states according to MAG1's status. 502 +----+ +----+ +----+ +----+ 503 |MAG1| |LMA1| |LMA2| |MAG2| 504 +----+ +----+ +----+ +----+ 505 | | | | 506 | [T] (ROC) | 507 | | | | 508 | |-----RO Init---->| | 509 | |<---RO Init Ack | | 510 | | | | 511 | | |----RO Init---->| 512 | | |<--RO Init Ack--| 513 | | | | 514 | |<---RO Report----| | 515 | |--RO Report Ack->| | 516 | | | | 517 |<----RO Setup-----| | | 518 |---RO Setup Ack-->| | | 519 | | | | 520 | | | | 521 | |----RO Report--->| | 522 | |<-RO Report Ack--| | 523 | | | | 524 | | |----RO Setup--->| 525 | | |<-RO Setup Ack--| 526 | | | | 528 Figure 7: RO Proxy Mode - Two relevant LMAs in the topology 530 4.3.2. RO Handover Procedure 532 After MN's handover, nMAG1 notifies the LMA (LMA1) about MN1's 533 arrival by means of the PBU message. LMA1 recognizes that RO states 534 for this particular RO association need to be established at nMAG1 535 and updated on MAG2. As LMA1 is assigned the function of the RO 536 update trigger as well as the active RO controller, it coordinates 537 maintenance of the route optimized path according to Figure 8. 538 Signaling sequence between nMAG1, LMA1 and MAG2 is the same as for 539 the set up of RO states (Figure 6) 540 +-----+ +-----+ +----+ +----+ 541 |nMAG1| |pMAG1| |LMA1| |MAG2| 542 +-----+ +-----+ +----+ +----+ 543 | | | | 544 | | (ROC) | 545 | | | | 546 |-----------------PBU--------------->| | 547 |<---------------PBAck---------------| | 548 | | [T] | 549 |<--------------RO Init--------------| | 550 |-------------RO Init Ack----------->| | 551 | | | | 552 | | |----RO Setup---->| 553 | | |<--RO Setup Ack--| 554 | | | | 555 |<-------------RO Setup--------------| | 556 |------------RO Setup Ack----------->| | 557 | | | | 558 | | | | 560 Figure 8: RO Proxy Mode - One relevant LMA in the topology, MN1 561 handover 563 In the scenario, where MN1 and MN2 are tracked by different LMAs 564 (Figure 9), LMA1 recognizes the need to update the RO association and 565 serves as RO update trigger. In this scenario, we assume that LMA2 566 has been selected as active RO controller for this particular RO 567 association, hence LMA1 sends a RO Initiate message to LMA2, which 568 coordinates the update procedure. After having received the RO 569 Initiate Ack from LMA2, LMA1 can start the RO update procedure by 570 means of sending a RO Initiate message to MAG1. The remaining 571 message sequence is according to Figure 9 and the same as for the RO 572 setup procedure with two LMAs (Figure 7). 574 Note: in the case where the RO update trigger and active RO 575 controller function are on the same LMA, this one does not send a RO 576 Initiate message to the other LMA, but directly sends a RO Initiate 577 message to its MAG. 579 +-----+ +-----+ +----+ +----+ +----+ 580 |nMAG1| |pMAG1| |LMA1| |LMA2| |MAG2| 581 +-----+ +-----+ +----+ +----+ +----+ 582 | | | | | 583 |------------PBU------------>| (ROC) | 584 |<----------PBAck------------| | | 585 | | [T] | | 586 | | |-----RO Init--->| | 587 | | |<--RO Init Ack--| | 588 | | | | | 589 |<---------RO Init-----------| | | 590 |--------RO Init Ack-------->| | | 591 | | | | | 592 | | |----RO Report-->| | 593 | | |<-RO Report Ack-| | 594 | | | | | 595 | | | |---RO Setup--->| 596 | | | |<-RO Setup Ack-| 597 | | | | | 598 | | |<----RO Report--| | 599 | | |-RO Report Ack->| | 600 | | | | | 601 |<---------RO Setup----------| | | 602 |--------RO Setup Ack------->| | | 603 | | | | | 604 | | | | | 606 Figure 9: RO Proxy Mode - Two relevant LMAs in the topology, MN1 607 handover 609 5. Message Format 611 To suit the format of the Proxy MIPv6 messages, the three 612 differential messages RO Initiate, RO Setup and RO Report as well as 613 the associated Ack messages are encoded according to the message data 614 encoding rules for the Mobility Header (MH) as specified in 615 [RFC3775]. Messages for RO are extensions to 616 [I-D.ietf-netlmm-proxymip6] and identified by the MH Type. 618 Parameters being carried by any of these messages are encoded as 619 message options according to the type-length-value format specified 620 in [RFC3775]. The following message option is specified for this 621 protocol: MAG IP Address Option. 623 Details about the message and message option format are t.b.d. 625 Note: As an option to the RO protocol's direct mode, a Proxy BU 626 message handshake can be used to substitute the RO Setup message 627 handshake between MAGs. In this case, the RO Initiate message from 628 an LMA serves as trigger to release the PBU to establish RO states on 629 MAGs according to the protocol operation described in Section 4.2. 631 6. Security Considerations 633 Security threats for route optimization in network-based mobility 634 management comprise the danger of unauthorized set up or redirect of 635 an established forwarding path by a malicious node. Signaling 636 messages of this protocol between a MAG and an LMA as well as between 637 LMAs must be authenticated by means of IPsec [RFC4301]. The use of 638 IPsec between an LMA and a MAG follows [I-D.ietf-netlmm-proxymip6]. 640 Protection of signaling messages between an LMA and a MAG uses the 641 mechanisms of Encapsulating Security Payload (ESP) [RFC4303] in 642 transport mode with mandatory data origin authentication by means of 643 a non-null payload authentication algorithm. The use of encryption 644 is optional. The same requirements apply to signaling between LMAs 645 as well as between MAGs. In particular, if the network which 646 interconnects two LMAs and/or two MAGs is not trusted, the use of 647 encryption is recommended to support confidentiality protection 648 between LMAs and between MAGs respectively. 650 In case setting up a security association between MAGs appears 651 difficult, the protocol's proxy mode allows secure operation without 652 mandating such security association. 654 In case RO is established between two MNs which are registered with 655 different LMAs, the proposed RO protocol avoids direct signaling 656 between one MN's LMA and the other MN's MAG. Instead, MAGs exchange 657 signaling only with LMAs which maintain a registration for attached 658 MNs. This avoids dependency on an existing security association 659 between all possible MAG-LMA-pairs. 661 7. Normative References 663 [I-D.ietf-netlmm-proxymip6] 664 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 665 and B. Patil, "Proxy Mobile IPv6", 666 draft-ietf-netlmm-proxymip6-07 (work in progress), 667 November 2007. 669 [I-D.jaehwoon-netlmm-flush] 670 Lee, J., "Flushing Mechanism for Routing Optimization in 671 PMIPv6", draft-jaehwoon-netlmm-flush-00 (work in 672 progress), June 2007. 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, March 1997. 677 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 678 in IPv6", RFC 3775, June 2004. 680 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 681 Internet Protocol", RFC 4301, December 2005. 683 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 684 RFC 4303, December 2005. 686 Appendix A. MAG-local Route Optimization 688 In some scenarios, both MNs could be attached to the same MAG. The 689 MNs can be registered to the same LMA or two different LMAs. In this 690 case, the most efficient path is to route the traffic from MN1 to MN2 691 directly via the MAG, without going through the LMA(s). 693 Establishing this direct path could be done as part of the PMIP base 694 operation as it has been discussed in the NetLMM Working Group. 695 However, if it is so, and if one MN hands off, RO states would have 696 to be installed after the handover. We believe that it is more 697 efficient and consistent to install the optimized path as part of a 698 RO service and treat the handover case with the RO handover 699 procedures described in Section 4. 701 Appendix B. Early State Activation (ESA) Policy 703 In the procedures described in Section 4, the MAGs are provided with 704 the relevant information needed to setup RO one after the other. 705 Additionally, the MAG being contacted first only activates the states 706 when it receives the notification of the success of the RO setup on 707 the second MAG. As an example, in Figure 2, the first MAG contacted, 708 MAG2, activates the RO states after having received and processed the 709 RO setup Ack from MAG1. In a similar fashion, in Figure 6, MAG2 710 activates the RO states after having received and processed the RO 711 Setup from LMA1. 713 This approach avoids to start using the RO path in the case where the 714 RO setup failed on either MAG. However, the setup of the RO path can 715 be slightly optimized at the cost of suppressing this mechanism: the 716 first MAG could create and activate the RO states without waiting for 717 the notification concerning the second MAG. We call this enhancement 718 Early State Activation. 720 As an example in Figure 2, MAG2 could activate the RO states after 721 having received and processed the RO Initiate message from LMA1. In 722 a similar fashion in Figure 6, MAG2 could activate the RO states 723 after having received and processed the RO Initiate message from 724 LMA1. 726 In case ESA is used, additional mechanisms need to be defined to 727 handle RO setup failure. Indeed, the second MAG contacted could be 728 unable to create the states for some reason, while the RO states and 729 forwarding would already be active on the other MAG. 731 Authors' Addresses 733 Marco Liebsch 734 NEC Laboratories 735 Kurfuersten-Anlage 36 736 69115 Heidelberg, 737 Germany 739 Phone: +49 6221 4342146 740 Email: liebsch@nw.neclab.eu 742 Long Le 743 NEC Laboratories 744 Kurfuersten-Anlage 36 745 69115 Heidelberg, 746 Germany 748 Phone: +49 6221 4342224 749 Email: le@nw.neclab.eu 751 Julien Abeille 752 Cisco Technology Center 753 Av. des Uttins 5 754 1180 Rolle, 755 Switzerland (FR) 757 Phone: +41 21 822 1696 758 Email: jabeille@cisco.com 760 Full Copyright Statement 762 Copyright (C) The IETF Trust (2007). 764 This document is subject to the rights, licenses and restrictions 765 contained in BCP 78, and except as set forth therein, the authors 766 retain all their rights. 768 This document and the information contained herein are provided on an 769 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 770 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 771 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 772 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 773 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 774 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 776 Intellectual Property 778 The IETF takes no position regarding the validity or scope of any 779 Intellectual Property Rights or other rights that might be claimed to 780 pertain to the implementation or use of the technology described in 781 this document or the extent to which any license under such rights 782 might or might not be available; nor does it represent that it has 783 made any independent effort to identify any such rights. Information 784 on the procedures with respect to rights in RFC documents can be 785 found in BCP 78 and BCP 79. 787 Copies of IPR disclosures made to the IETF Secretariat and any 788 assurances of licenses to be made available, or the result of an 789 attempt made to obtain a general license or permission for the use of 790 such proprietary rights by implementers or users of this 791 specification can be obtained from the IETF on-line IPR repository at 792 http://www.ietf.org/ipr. 794 The IETF invites any interested party to bring to its attention any 795 copyrights, patents or patent applications, or other proprietary 796 rights that may cover technology that may be required to implement 797 this standard. Please address the information to the IETF at 798 ietf-ipr@ietf.org. 800 Acknowledgment 802 Funding for the RFC Editor function is provided by the IETF 803 Administrative Support Activity (IASA).