idnits 2.17.1 draft-ietf-netext-pmip-lr-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (May 7, 2012) is 4364 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: 'MN1-ID' is mentioned on line 612, but not defined == Missing Reference: 'MN1-HNP' is mentioned on line 612, but not defined == Missing Reference: 'MN2-ID' is mentioned on line 613, but not defined == Missing Reference: 'MN2-HNP' is mentioned on line 613, but not defined == Missing Reference: 'MN-ID' is mentioned on line 667, but not defined == Missing Reference: 'HNP' is mentioned on line 667, but not defined Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netext WG S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track R. Koodli 5 Expires: November 8, 2012 Cisco Systems 6 P. Loureiro 7 NEC 8 Q. Wu 9 Huawei 10 A. Dutta 11 NIKSUN 12 May 7, 2012 14 Localized Routing for Proxy Mobile IPv6 15 draft-ietf-netext-pmip-lr-10 17 Abstract 19 Proxy Mobile IPv6 (PMIPv6) is a network based mobility management 20 protocol that enables IP mobility for a host without requiring its 21 participation in any mobility-related signaling. PMIPv6 requires all 22 communications to go through the local mobility anchor. As this can 23 be suboptimal, localized routing (LR) allows mobile nodes attached to 24 the same or different mobile access gateways to route traffic by 25 using localized forwarding or a direct tunnel between the gateways. 26 This document proposes initiation, utilization and termination 27 mechanisms for localized routing between mobile access gateways 28 within a proxy mobile IPv6 domain. It defines two new signaling 29 messages, Localized Routing Initiation (LRI) and Local Routing 30 Acknowledgment (LRA), that are used to realize this mechanism. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 8, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Initiation of Localized Routing . . . . . . . . . . . . . . . 5 68 2.1. MAG behavior . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2. LMA behavior . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Teardown of Localized Routing . . . . . . . . . . . . . . . . 6 71 4. Conventions used in this document . . . . . . . . . . . . . . 7 72 5. Scenario A11: Two MNs attached to the same MAG and LMA . . . . 8 73 5.1. Handover Considerations . . . . . . . . . . . . . . . . . 10 74 6. Scenario A21: Two MNs attached to different MAGs but same 75 LMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.1. Handover Considerations . . . . . . . . . . . . . . . . . 13 77 6.2. Tunneling between the MAGs . . . . . . . . . . . . . . . . 13 78 7. Scenario A12: Two MNs attached to the same MAG with 79 different LMAs . . . . . . . . . . . . . . . . . . . . . . . . 15 80 7.1. Handover Considerations . . . . . . . . . . . . . . . . . 16 81 8. Scenario A22: Two MNs attached to different MAGs with 82 different LMAs . . . . . . . . . . . . . . . . . . . . . . . . 17 83 9. IPv4 support in Localized Routing . . . . . . . . . . . . . . 18 84 10. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19 85 10.1. Localized Routing Initiation (LRI) . . . . . . . . . . . . 19 86 10.2. Localized Routing Acknowledgment (LRA) . . . . . . . . . . 20 87 11. New Mobility Option . . . . . . . . . . . . . . . . . . . . . 22 88 11.1. MAG IPv6 Address . . . . . . . . . . . . . . . . . . . . . 22 89 12. Configuration Variables . . . . . . . . . . . . . . . . . . . 23 90 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24 91 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 15. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 94 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 17.1. Normative References . . . . . . . . . . . . . . . . . . . 28 96 17.2. Informative References . . . . . . . . . . . . . . . . . . 28 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 99 1. Introduction 101 Proxy Mobile IPv6 [RFC5213] describes the protocol operations to 102 maintain reachability and session persistence for a Mobile Node (MN) 103 without the explicit participation from the MN in signaling 104 operations at the Internet Protocol (IP) layer. In order to 105 facilitate such network-based mobility, the PMIPv6 protocol defines a 106 Mobile Access Gateway (MAG), which acts as a proxy for the Mobile 107 IPv6 [RFC6275] signaling, and the Local Mobility Anchor (LMA) which 108 acts similar to a Home Agent. The LMA and the MAG establish a 109 bidirectional tunnel for forwarding all data traffic belonging to the 110 Mobile Nodes. In the case where both endpoints are located in the 111 same PMIPv6 domain, this can be suboptimal and results in higher 112 delay and congestion in the network. Moreover, it increases 113 transport costs and traffic load at the LMA. 115 To overcome these issues, localized routing can be used to allow 116 nodes attached to the same or different MAGs to directly exchange 117 traffic by using localized forwarding or a direct tunnel between the 118 gateways. [RFC6279] defines the problem statement for PMIPv6 119 localized routing. This document describes a solution for PMIPv6 120 localized routing between two MNs in the same PMIPv6 domain. The 121 protocol specified here assumes that each MN is attached to a MAG and 122 that each MN's MAG has established a binding for the attached MN at 123 its selected LMA according to [RFC5213]. The protocol builds on the 124 scenarios defined in [RFC6279]. 126 2. Initiation of Localized Routing 128 Since the traffic to be localized passes through both the LMA and the 129 MAGs, it is possible, at least in some scenarios, for either of them 130 to initiate Localized Routing (LR). In order to eliminate ambiguity, 131 the protocol described in this document selects the initiator of the 132 LR based on the following rules. 134 2.1. MAG behavior 136 The MAG MUST initiate LR if both the communicating MNs are attached 137 to it and the MNs are anchored at different LMAs. The MAG MUST NOT 138 initiate LR in any other case. 140 2.2. LMA behavior 142 The LMA MUST initiate LR if both the communicating MNs are anchored 143 to it. The LMA MUST NOT initiate LR in any other case. 145 3. Teardown of Localized Routing 147 The use of localized routing is not persistent. Localized routing 148 has a defined lifetime as specified by the initiator, upon the expiry 149 of which, the forwarding MUST revert to using bidirectional 150 tunneling. When localized routing ceases, the corresponding LRE 151 entries MUST be removed. 153 If the initiator of LR wishes to terminate localized routing before 154 the expiry of the lifetime specified in the LRI message, it MUST do 155 so by sending a new LRI message with the lifetime set to zero. 157 4. Conventions used in this document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 This document also uses the terminology defined in Section 2 of 164 [RFC6279]. 166 5. Scenario A11: Two MNs attached to the same MAG and LMA 168 In this scenario, the two Mobile Nodes involved in communication are 169 attached to a single MAG and both are anchored at the same LMA as 170 shown in Figure 1. 172 Internet 173 : 174 | 175 | 176 +-----+ 177 | LMA | 178 +-----+ 179 | 180 | 181 | 182 +-----+ 183 | MAG | 184 +-----+ 185 : : 186 +---+ +---+ 187 |MN1| |MN2| 188 +---+ +---+ 190 Figure 1 192 The LMA initiates a localized routing session by detecting traffic 193 between two MNs attached to the same MAG. The exact traffic 194 identification mechanism is not specified in this document, and is 195 left open for implementations and specific deployments. An example 196 trigger could be that an application-layer signaling entity detects 197 the possibility of localized routing and notifies the LMA about the 198 two end-points, and the LMA determines that the two end-points are 199 attached to the same MAG. Such a trigger mechanism offers localized 200 routing at the granularity of an individual application session, 201 providing flexibility in usage. It is also possible that one of the 202 mobility entities (LMA or MAG) could decide to initiate localized 203 routing based on configured policy. Please note that a MAG 204 implementing the protocol specified in this specification will not 205 dynamically initiate LR in the same LMA case (i.e. by sending an 206 LRI), but can statically initiate LR based on the 207 EnableMAGLocalRouting configuration variable specified in [RFC5213]. 209 +----+ +----+ +----+ +----+ 210 |MN1 | |MN2 | |MAG1| |LMA | 211 +----+ +----+ +----+ +----+ 212 | | | | 213 | data | data | 214 |<--------------------->|<------------->| 215 | | | | 216 | | data | data | 217 | |<--------->|<------------->| 218 | | | LR decision 219 | | | LRI(Opt1) | 220 | | |<--------------| 221 | | | | 222 | | | LRA(Opt2) | 223 | | |-------------->| 224 | | | | 225 | data | | 226 |<--------------------->| | 227 | | | | 228 | | data | | 229 | |<--------->| | 230 | | | | 231 | | | | 233 Opt1: MN1-ID,MN1-HNP,MN2-ID,MN2-HNP 234 Opt2: U=0,MN1-ID,MN1-HNP,MN2-ID,MN2-HNP 236 where U is the flag defined in Section 9.1 and 9.2. 238 Figure 2 240 After detecting a possibility for localized routing, the LMA SHOULD 241 construct a Localized Routing Initiation (LRI) message that is used 242 to signal the intent to initiate localized routing and to convey 243 parameters for the same. This is a Mobility Header message and it 244 MUST contain the MN-Identifier and the Home Network Prefix (as 245 Mobility Header options) for each of the MNs involved. The LMA MUST 246 then send the LRI message to the MAG (MAG1) where the two MNs are 247 attached. The initiation of the LR procedure is shown in Figure 2. 249 The MAG (MAG1) MUST verify the attachment status of the two MNs 250 locally by checking the binding cache. The MAG MUST then verify if 251 the EnableMAGLocalRouting flag is set to 1. If it is not, the MAG 252 has not been configured to allow localized routing and it MUST reject 253 the LRI and MUST send an LRA with status code "Localized Routing Not 254 Allowed". Please note that this does not update behavior specified 255 in [RFC5213] but merely implements the LMA enforcement specified in 256 Section 6.10.3. of [RFC5213]. If MAG is configured to allow 257 localized routing it MUST then create Localized Routing Entries 258 (LREs) for each direction of the communication between the two MNs. 259 The exact form of the forwarding entries is left for the 260 implementations to decide; however, they SHOULD contain the Home 261 Network Prefix (HNP) corresponding to the destination IP address and 262 a next-hop identifier (e.g. the layer 2 address of the next hop). 263 These LREs MUST override the Binding Update List(BUL) entries for the 264 specific HNPs identified in the LRI message. Hence all traffic 265 matching the HNPs is forwarded locally. 267 If the MAG is unable to deliver packets using the LREs, it is 268 possible that one of the MNs is no longer attached to the MAG. 269 Hence, the MAG MUST fall back to using the BUL entry, and the LMA 270 MUST forward the received packets using its Binding Cache Entry 271 (BCE). 273 After processing the LRI message the MAG MUST respond with a Local 274 Routing Acknowledgment (LRA) message. This Mobility Header message 275 MUST also include the MN-ID and the HNP for each of the communicating 276 MNs as well as an appropriate Status code indicating the outcome of 277 LRI processing. Status code 0 indicates localized routing was 278 successfully offered by the MAG. Any other value for Status code 279 indicates the reason for the failure to offer localized routing 280 service. When Status code is 0, the LMA sets a flag in the BCE 281 corresponding to the HNPs to record that localized routing is in 282 progress for that HNP. 284 5.1. Handover Considerations 286 If one of the MNs, say MN1, detaches from the MAG and attaches to 287 another MAG (say nMAG) the localized routing state needs to be re- 288 established. When the LMA receives the PBU from nMAG for MN1, it 289 will see that localized routing is active for MN1. It MUST hence 290 initiate LR at nMAG and update the LR state of MAG. After the 291 handover completes, the localized routing will resemble Scenario A21. 292 The pMAG MUST follow the forwarding rules described in Section 6.10.5 293 of [RFC5213] and decide that it will no longer perform LR for MN1. 295 6. Scenario A21: Two MNs attached to different MAGs but same LMA 297 The LMA may choose to support local forwarding to mobile nodes 298 attached to two different MAGs within a single PMIPv6 domain. 300 Internet 301 : 302 | 303 | 304 +-----+ 305 | LMA | 306 +-----+ 307 | 308 | 309 +----+-----+ 310 | | 311 +----+ +----+ 312 |MAG1| |MAG2| 313 +----+ +----+ 314 : : 315 +---+ +---+ 316 |MN1| |MN2| 317 +---+ +---+ 319 Figure 3 321 As earlier, the LMA initiates LR as a response to some trigger 322 mechanism. In this case, however, it MUST send two separate LRI 323 messages to the two MAGs. In addition to the MN-ID and the HNP 324 options, each LRI message MUST contain the IP Address of the 325 counterpart MAG. When the MAG IP Address option is present, each MAG 326 MUST create a local forwarding entry such that the packets for the MN 327 attached to the remote MAG are sent over a tunnel associated with 328 that remote MAG. The tunnel between the MAGs is assumed to be 329 established following the considerations mentioned in Section 6.2. 331 +----+ +----+ +----+ +----+ +----+ 332 |MN1 | |MN2 | |MAG1| |MAG2| |LMA | 333 +----+ +----+ +----+ +----+ +----+ 334 | | | | | 335 | data | data | 336 |<--------------------->|<----------------------->| 337 | | | | | 338 | | data | data | 339 | |<--------------------->|<----------->| 340 | | | | | 341 | | | | | 342 | | | LRI(Opt1) | 343 | | |<------------------------| 344 | | | | | 345 | | | | LRI(Opt2) | 346 | | | |<------------| 347 | | | | | 348 | | | LRA(Opt3) | 349 | | |------------------------>| 350 | | | | | 351 | | | | LRA(Opt4) | 352 | | | |------------>| 353 | | | | | 354 | | | | | 355 | | | | | 356 | data | data | | 357 |<--------------------->|<--------->| | 358 | | | | | 359 | | data | | 360 | |<--------------------->| | 361 | | | | | 362 | | | | | 364 Opt1: MN1-ID,MN1-HNP,MAG2-IPv6-Address 365 Opt2: MN2-ID,MN2-HNP,MAG1-IPv6-Address 366 Opt3: U=0,MN1-ID,MN1-HNP,MAG2-IPv6-Address 367 Opt4: U=0,MN2-ID,MN2-HNP,MAG1-IPv6-Address 369 where U is the flag defined in Section 9.1 and 9.2. 371 Figure 4 373 In this case, each MAG responds to the LRI with an LRA message. All 374 subsequent packets are routed between the MAGs locally, without 375 traversing the LMA. If one of the MAGs (say MAG1) responds with a 376 successful LRA (Status value is zero) and the other (say 377 MAG2)responds with an error (Status value is non-zero) LR will still 378 be performed in one direction (MN1->MAG1->MAG2->MN2), but the packets 379 flowing the other way will take the LMA path 380 (MN2->MAG2->LMA->MAG1->MN1). 382 The protocol does not require any synchronization between the MAGs 383 before local forwarding begins. Each MAG begins its local forwarding 384 independent of the other. 386 No synchronization between MAGs is required because each MAG 387 initiates LR in one direction. After the LMA instructs MAG1 to 388 initiate LR, packets from MN1 to MN2 will take the path 389 MN1->MAG1->MAG2->MN2 while those from MN2 to MN1 will take the path 390 MN2->MAG2->LMA->MAG1->MN1 until LMA instructs MAG2 to do so as well. 391 At any instant a MAG will forward a packet either towards another MAG 392 or its own LMA and hence there would be no duplication of packets. 394 6.1. Handover Considerations 396 If one of the MNs, say MN1, detaches from its current MAG (in this 397 case MAG1) and attaches to another MAG (say nMAG1) the localized 398 routing state needs to be re-established. When the LMA receives the 399 PBU from nMAG1 for MN1, it will see that localized routing is active 400 for MN1. The LMA MUST then initiate LR at nMAG1 and update the LR 401 state of MAG2 to use nMAG1 instead of MAG1. 403 6.2. Tunneling between the MAGs 405 In order to support localized routing both MAGs SHOULD support the 406 following encapsulation modes for the user packets, which are also 407 defined for the tunnel between the LMA and MAG: 409 o IPv4-or-IPv6-over-IPv6 [RFC5844] 411 o IPv4-or-IPv6-over-IPv4 [RFC5844] 413 o IPv4-or-IPv6-over-IPv4-UDP [RFC5844] 415 o TLV-header UDP tunneling [RFC5845] 417 o Generic Routing Encapsulation (GRE) tunneling with or without GRE 418 key(s) [RFC5845] 420 MAG1 and the MAG2 MUST use the same tunneling mechanism for the data 421 traffic tunneled between them. The encapsulation mode to be employed 422 SHOULD be configurable. It is RECOMMENDED that: 424 1. As the default behavior, the inter-MAG tunnel uses the same 425 encapsulation mechanism as that being used for the PMIPv6 tunnel 426 between the LMA and the MAGs. MAG1 and MAG2 automatically start 427 using the same encapsulation mechanism without a need for a 428 special configuration on the MAGs or a dynamic tunneling 429 mechanism negotiation between them. 431 2. Configuration on the MAGs can override the default mechanism 432 specified in Option 1 above. MAG1 and MAG2 MUST be configured 433 with the same mechanism, and this configuration is most likely to 434 be uniform throughout the PMIPv6 domain. If the packets on the 435 PMIPv6 tunnel cannot be uniquely mapped on to the configured 436 inter-MAG tunnel, this scenario is not applicable, and Option 3 437 below SHOULD directly be applied. 439 3. An implicit or explicit tunnel negotiation mechanism between the 440 MAGs can override the default mechanism specified in Option 1 441 above. The employed tunnel negotiation mechanism is outside the 442 scope of this document. 444 7. Scenario A12: Two MNs attached to the same MAG with different LMAs 446 In this scenario, both the MNs are attached to the same MAG, but are 447 anchored at two different LMAs. MN1 is anchored at LMA1 and MN2 is 448 anchored at LMA2. Note that the two LMAs are part of the same 449 Provider Domain. 451 Internet 452 : : 453 +------------------+ 454 | | 455 +----+ +----+ 456 |LMA1| |LMA2| 457 +----+ +----+ 458 | | 459 | | 460 +------------------+ 461 | 462 | 463 | 464 +-----+ 465 | MAG | 466 +-----+ 467 : : 468 +---+ +---+ 469 |MN1| |MN2| 470 +---+ +---+ 472 Figure 5 474 Hence, neither LMA has a means to determine that the two Mobile Nodes 475 are attached to the same MAG. Only the MAG can possibly determine 476 that the two Mobile Nodes involved in communication are attached to 477 it. Therefore, the localized routing MUST be initiated by the MAG. 479 The MAG sends an LRI message containing the MN-ID, HNP and the 480 counterpart LMA address to each LMA. Each LMA makes decision to 481 support local forwarding independently, based on, among others, 482 policy configuration for the counterpart LMA. Each LMA MUST respond 483 to the LRI message with an LRA message. If the initiation of LR on 484 the LMA was successful, the Status value in the received LRA would be 485 set to zero. After the MAG receives both the LRA messages each with 486 Status value set to zero (success) from the two different LMAs, the 487 MAG will conclude that it can provide local forwarding support for 488 the two Mobile Nodes. 490 +----+ +----+ +----+ +----+ +----+ 491 |MN1 | |MN2 | |MAG | |LMA1| |LMA2| 492 +----+ +----+ +----+ +----+ +----+ 493 | | | | | 494 | data | data | data | 495 |<--------------------->|<--------->|<----------->| 496 | | | | | 497 | | data | data | 498 | |<--------->|<----------------------->| 499 | | | | | 500 | | | | | 501 | | | LRI(Opt1) | | 502 | | |---------->| | 503 | | | | | 504 | | | LRI(Opt2) | 505 | | |------------------------>| 506 | | | | | 507 | | | LRA(Opt3) | | 508 | | |<----------| | 509 | | | | | 510 | | | LRA(Opt4) | 511 | | |<------------------------| 512 | | | | | 513 | | | | | 514 | | | | | 515 | data | | | 516 |<--------------------->| | | 517 | | | | | 518 | | data | | | 519 | |<--------->| | | 520 | | | | | 521 | | | | | 523 Opt1: MN1-ID,MN1-HNP 524 Opt2: MN2-ID,MN2-HNP 525 Opt3: U=0,MN1-ID,MN1-HNP 526 Opt4: U=0,MN2-ID,MN2-HNP 528 where U is the flag defined in Section 9.1 and 9.2. 530 Figure 6 532 7.1. Handover Considerations 534 If one of the MNs, say MN1, detaches from its current MAG (in this 535 case MAG1) and attaches to another MAG (say nMAG1), the current MAG 536 MUST immediately stop using the LRE and MUST send all packets 537 originated by the other MN (MN2) towards its LMA (in this case LMA2). 539 8. Scenario A22: Two MNs attached to different MAGs with different LMAs 541 This scenario will not be covered in this document since PMIPv6 does 542 not define any form of inter-LMA communications. When a supported 543 scenario, such as Scenario A12, morphs into Scenario A22 the node 544 that initiated the localized routing session MUST tear it down in 545 order to prevent lasting packet loss. This can result in transient 546 packet loss when routing switches between the localized path into the 547 normal path through the LMAs. In applications that are loss 548 sensitive, this can lead to observable service disruptions. In 549 deployments where Scenario A22 is possible, the use of localized 550 routing is NOT RECOMMENDED when packet-loss-sensitive applications 551 are in use. 553 9. IPv4 support in Localized Routing 555 PMIPv6 MNs can use an IPv4 HoA as described in [RFC5844]. In order 556 to support the setup and maintenance of localized routes for these 557 IPv4 HoAs in PMIPv6, MAGs MUST add the IPv4 HoAs into their LREs. 558 The MAGs MUST also support encapsulation of IPv4 packets as described 559 in [RFC5844]. The localized routing protocol messages MUST include a 560 IPv4 HoA option in their signaling messages in order to support IPv4 561 addresses for localized routing. 563 If the transport network between the PMIPv6 entities involved in 564 localized routing is IPv4-only, the LRI and LRA messages MUST be 565 encapsulated similar to the PBU/PBA messages as specified in 566 [RFC5844]. The encapsulation mode used SHOULD be identical to the 567 one used to transport PBU and PBA messages. 569 10. Message Formats 571 The Localized routing messages use two new mobility header type (TBA1 572 and TBA2). The LRI message requests creation or deletion of 573 localized routing state and the LRA message acknowledges the creation 574 or deletion of such localized routing state. 576 10.1. Localized Routing Initiation (LRI) 578 The LRI messages uses a new mobility header type (TBA1). The LMA 579 sends an LRI message to a MAG to request local forwarding for a pair 580 of MNs. The MAG may also send this message to request the two LMAs 581 for offering local forwarding as described in Section 7 . 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Sequence # | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Reserved | Lifetime | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | | 591 . . 592 . Mobility options . 593 . . 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Sequence Number: A monotonically increasing integer. Set by a 598 sending node in a request message, and used to match a reply to 599 the request. 601 Reserved: This field is unused. MUST be set zero. 603 Lifetime: The requested time in seconds for which the sender 604 wishes to have local forwarding. A value of 0xffff (all ones) 605 indicates an infinite lifetime. When set to 0, indicates a 606 request to stop localized routing. 608 Mobility Options: MUST contain two separate MN-ID options, 609 followed by one or more HNPs for each of the MNs. For instance, 610 for Mobile Nodes MN1 and MN2 with identifiers MN1-ID, MN2-ID and 611 Home Network Prefixes MN1-HNP and MN2-HNP, the following tuple 612 in the following order MUST be present: [MN1-ID, MN1-HNP], 613 [MN2-ID, MN2-HNP]. The MN-ID and HNP options are the same as in 614 [RFC5213]. MAY contain the remote MAG IPv6 address option, 615 which is formatted identically to the HNP option, except that it 616 uses a different Type code and the Prefix Length is always equal 617 to 128 bits (see Section 10.1). 619 The LRI message SHOULD be re-transmitted if a corresponding LRA 620 message is not received within LRA_WAIT_TIME time units, up to a 621 maximum of LRI_RETRIES, each separated by LRA_WAIT_TIME time units. 623 10.2. Localized Routing Acknowledgment (LRA) 625 The LRA messages uses a new mobility header type (TBA2). A MAG sends 626 an LRA message to the LMA as a response to the LRI message. An LMA 627 may also send this message to a MAG as a response to the LRI message 628 as described in Section 7 . 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Sequence # | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 |U| Reserved | Status | Lifetime | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | | 638 . . 639 . Mobility options . 640 . . 641 | | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Sequence Number: is copied from the sequence number field of the 645 LRI message being responded to. 647 'U' flag: When set to 1, the LRA message is sent unsolicited. 648 The Lifetime field indicates a new requested value. The MAG MUST 649 wait for the regular LRI message to confirm that the request is 650 acceptable to the LMA. 652 Reserved: This field is unused. MUST be set zero. 654 Status: 656 0: Success 658 128: Localized Routing Not Allowed 659 129: MN not attached 661 Lifetime: The time in seconds for which the local forwarding is 662 supported. Typically copied from the corresponding field in the 663 LRI message. 665 Mobility Options: When Status code is 0, MUST contain the 666 [MN-ID, HNP] tuples in the same order as in the LRI message. 667 When Status code is not 0, MUST contain only those [MN-ID, HNP] 668 tuples for which local forwarding is supported. The MN-ID and 669 HNP options are the same as in [RFC5213]. 671 11. New Mobility Option 673 11.1. MAG IPv6 Address 675 The MAG IPv6 address mobility option contains the IPv6 address of a 676 MAG involved in the localized routing. The MAG IPv6 address option 677 has an alignment requirement of 8n+4. 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Type | Length | Reserved | Address Length| 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | | 685 + + 686 | | 687 + MAG IPv6 Address + 688 | | 689 + + 690 | | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Type 694 TBA3 696 Length 698 8-bit unsigned integer indicating the length of the option 699 in octets, excluding the type and length fields. This field 700 MUST be set to 18. 702 Reserved (R) 704 This 8-bit field is unused for now. The value MUST be 705 initialized to 0 by the sender and MUST be ignored by the 706 receiver. 708 Address Length 710 This field MUST be set to 128. 712 MAG IPv6 Address 714 A 16 byte field containing the MAG's IPv6 Address. 716 12. Configuration Variables 718 The LMA and the MAG must allow the following variables to be 719 configurable. 721 LRA_WAIT_TIME: This variable is used to set the time interval in 722 seconds between successive retransmissions of an LRI message. The 723 default value is 3 seconds. 725 LRI_RETRIES: This variable indicates the maximum number of times the 726 initiator retransmits an LRI message before stopping. The default 727 value for this variable is 3. 729 13. Security Considerations 731 The protocol inherits the the threats to [RFC5213] that are 732 identified in [RFC4832]. The protocol specified in this document 733 uses the same security association as defined in [RFC5213] for use 734 between the LMA and the MAG to protect the LRI and LRA messages. 735 This document also assumes the pre-existence of a MAG-MAG security 736 association if LR needs to be supported between them. Support for 737 integrity protection using IPsec is REQUIRED, but support for 738 confidentiality is OPTIONAL. The MAGs MUST perform ingress filtering 739 on the MN sourced packets before encapsulating them into MAG-MAG 740 tunnels in order to prevent address spoofing. 742 14. IANA Considerations 744 The Localized Routing Initiation, described in Section 10.1 and the 745 Localized Routing Acknowledgment, described in Section 10.2 each 746 require a Mobility Header Type (TBA1 and TBA2) from the Mobility 747 Header Types registry at 748 http://www.iana.org/assignments/mobility-parameters 750 The MAG IPv6 Address requires a Mobility Option Type (TBA3) from the 751 Mobility Options registry at 752 http://www.iana.org/assignments/mobility-parameters 754 15. Authors 756 This draft merges ideas from five different drafts addressing the 757 PMIP localized routing problem. The authors of these drafts are 758 listed below (in alphabetical order) 760 Kuntal Chowdhury 762 Ashutosh Dutta 764 Rajeev Koodli 766 Suresh Krishnan 768 Marco Liebsch 770 Paulo Loureiro 772 Desire Oulai 774 Behcet Sarikaya 776 Qin Wu 778 Hidetoshi Yokota 780 16. Acknowledgments 782 The authors would like to thank Sri Gundavelli, Julien Abeille, Tom 783 Taylor, Kent Leung, Mohana Jeyatharan, Jouni Korhonen, Glen Zorn, 784 Ahmad Muhanna, Zoltan Turanyi, Dirk von Hugo, Pete McCann, Xiansong 785 Cui, Carlos Bernardos, Basavaraj Patil, Jari Arkko, Mary Barnes, Les 786 Ginsberg, Russ Housley, Carl Wallace, Ralph Droms, Adrian Farrel and 787 Stephen Farrell for their comments and suggestions. 789 17. References 791 17.1. Normative References 793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 794 Requirement Levels", BCP 14, RFC 2119, March 1997. 796 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 797 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 799 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 800 Mobile IPv6", RFC 5844, May 2010. 802 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 803 "Generic Routing Encapsulation (GRE) Key Option for Proxy 804 Mobile IPv6", RFC 5845, June 2010. 806 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 807 in IPv6", RFC 6275, July 2011. 809 17.2. Informative References 811 [RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based 812 Localized Mobility Management (NETLMM)", RFC 4832, 813 April 2007. 815 [RFC6279] Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6 816 (PMIPv6) Localized Routing Problem Statement", RFC 6279, 817 June 2011. 819 Authors' Addresses 821 Suresh Krishnan 822 Ericsson 823 8400 Blvd Decarie 824 Town of Mount Royal, Quebec 825 Canada 827 Phone: +1 514 345 7900 x42871 828 Email: suresh.krishnan@ericsson.com 830 Rajeev Koodli 831 Cisco Systems 833 Email: rkoodli@cisco.com 835 Paulo Loureiro 836 NEC 838 Email: paulo.loureiro@nw.neclab.eu 840 Qin Wu 841 Huawei 843 Email: Sunseawq@huawei.com 845 Ashutosh Dutta 846 NIKSUN 848 Email: adutta@niksun.com