idnits 2.17.00 (12 Aug 2021) /tmp/idnits19822/draft-krishnan-netext-pmip-lr-02.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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 5, 2010) is 4331 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: 'LR-PS' is mentioned on line 109, but not defined == Missing Reference: 'MN1-ID' is mentioned on line 515, but not defined == Missing Reference: 'MN1-HNP' is mentioned on line 515, but not defined == Missing Reference: 'MN2-ID' is mentioned on line 515, but not defined == Missing Reference: 'MN2-HNP' is mentioned on line 515, but not defined == Missing Reference: 'MN-ID' is mentioned on line 569, but not defined == Missing Reference: 'HNP' is mentioned on line 569, but not defined == Unused Reference: 'I-D.ietf-netext-pmip6-lr-ps' is defined on line 671, but no explicit reference was found in the text == Outdated reference: draft-ietf-netext-pmip6-lr-ps has been published as RFC 6279 ** Downref: Normative reference to an Informational draft: draft-ietf-netext-pmip6-lr-ps (ref. 'I-D.ietf-netext-pmip6-lr-ps') == Outdated reference: draft-ietf-netlmm-pmip6-ipv4-support has been published as RFC 5844 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netext WG S. Krishnan, Ed. 3 Internet-Draft Ericsson 4 Intended status: Standards Track R. Koodli 5 Expires: January 6, 2011 Cisco Systems 6 P. Loureiro 7 NEC 8 Q. Wu 9 Huawei 10 A. Dutta 11 Telcordia 12 July 5, 2010 14 Localized Routing for Proxy Mobile IPv6 15 draft-krishnan-netext-pmip-lr-02 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 allows mobile nodes attached to the 24 same or different mobile access gateways to exchange traffic by using 25 localized forwarding or a direct tunnel between the gateways. This 26 document proposes an initiation mechanism for localized routing. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 6, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Initiation of Localized Routing . . . . . . . . . . . . . . . 4 64 2.1. MAG behavior . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. LMA behavior . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Conventions used in this document . . . . . . . . . . . . . . 5 67 4. Scenario A11: Two MNs attached to the same MAG and LMA . . . . 6 68 4.1. Handover Considerations . . . . . . . . . . . . . . . . . 8 69 5. Scenario A21: Two MNs attached to different MAGs but same 70 LMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.1. Handover Considerations . . . . . . . . . . . . . . . . . 11 72 6. Scenario A12: Two MNs attached to the same MAG with 73 different LMAs . . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.1. Handover Considerations . . . . . . . . . . . . . . . . . 13 75 7. Scenario A22: Two MNs attached to the different MAGs with 76 different LMAs . . . . . . . . . . . . . . . . . . . . . . . . 14 77 8. IPv4 support in Localized Routing . . . . . . . . . . . . . . 15 78 9. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16 79 9.1. Localized Routing Initiation (LRI) . . . . . . . . . . . . 16 80 9.2. Localized Routing Acknowledgment (LRA) . . . . . . . . . . 17 81 10. New Mobility Option . . . . . . . . . . . . . . . . . . . . . 19 82 10.1. MAG IPv6 Address . . . . . . . . . . . . . . . . . . . . . 19 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 13. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 87 15. Normative References . . . . . . . . . . . . . . . . . . . . . 24 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 90 1. Introduction 92 Proxy Mobile IPv6 [RFC5213] describes the protocol operations to 93 maintain reachability and session persistence for a Mobile Node (MN) 94 without the explicit participation from the MN in signaling 95 operations at the Internet Protocol (IP) layer. In order to 96 facilitate such network-based mobility, the PMIPv6 protocol defines a 97 Mobile Access Gateway (MAG), which acts as a proxy for the Mobile 98 IPv6 [RFC3775] signaling, and the Local Mobility Anchor (LMA) which 99 acts similar to a Home Agent. The LMA and the MAG estalish a 100 bidirectional tunnel for forwarding all data traffic belonging to the 101 Mobile Nodes. In the case where both endpoints are located in the 102 same PMIPv6 domain, this can be suboptimal and results in higher 103 delay and congestion in the network. Moreover, it increases 104 transport costs and traffic load at the LMA. 106 To overcome these issues, localized routing can be used to allow 107 nodes attached to the same or different MAGs to directly exchange 108 traffic by using localized forwarding or a direct tunnel between the 109 gateways. [LR-PS] defines the problem statement for PMIPv6 localized 110 routing. This document describes a solution for PMIPv6 localized 111 routing. The protocol specified here assumes that each MN is 112 attached to a MAG and that each MN's MAG has established a binding 113 for the attached MN at its selected LMA according to [RFC5213]. 115 2. Initiation of Localized Routing 117 Since the traffic to be localized passes through both the LMA and the 118 MAGs, it is possible, at least in some scenarios, for either of them 119 to initiate LR. In order to eliminate ambiguity, the protocol 120 described in this document selects the initiator of the LR based on 121 the following rules. 123 2.1. MAG behavior 125 The MAG MUST Initiate LR if both the communicating MNs are attached 126 to it and the MNs are anchored at different LMAs. The MAG MUST NOT 127 initiate LR in any other case. 129 2.2. LMA behavior 131 The LMA MUST Initiate LR if both the communicating MNs are anchored 132 to it. The LMA MUST NOT initiate LR in any other case. 134 3. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 4. Scenario A11: Two MNs attached to the same MAG and LMA 142 In this scenario, the two Mobile Nodes involved in communication are 143 attached to a single MAG and both are anchored at the same LMA. 145 Internet 146 : 147 | 148 | 149 +-----+ 150 | LMA | 151 +-----+ 152 | 153 | 154 | 155 +-----+ 156 | MAG | 157 +-----+ 158 : : 159 +---+ +---+ 160 |MN1| |MN2| 161 +---+ +---+ 163 The LMA initiates a localized routing session by detecting a flow 164 between two MNs attached to the same MAG. The exact flow 165 identification mechanism is not specified in this document, and is 166 left open for implementations and specific deployments. An example 167 trigger could be that an application-layer signaling entity detects 168 the possibility of localized routing and notifies the LMA about the 169 two flow end-points, and the LMA determines that the two end-points 170 are attached to the same MAG. Such a trigger mechanism offers 171 localized routing at the granularity of an individual application 172 session, providing flexibility in usage. It is also possible that 173 one of the mobility entities (LMA or MAG) could decide to initiate 174 localized routing based on configured policy. 176 +----+ +----+ +----+ +----+ 177 |MN1 | |MN2 | |MAG | |LMA | 178 +----+ +----+ +----+ +----+ 179 | | | | 180 | data | data | 181 |<--------------------->|<------------->| 182 | | | | 183 | | data | data | 184 | |<--------->|<------------->| 185 | | | LR decision 186 | | | LRI(Opt1) | 187 | | |<--------------| 188 | | | | 189 | | | LRA(Opt2) | 190 | | |-------------->| 191 | | | | 192 | data | | 193 |<--------------------->| | 194 | | | | 195 | | data | | 196 | |<--------->| | 197 | | | | 198 | | | | 200 Opt1: R=0,S=0,MN1-ID,MN1-HNP,MN2-ID,MN2-HNP 201 Opt2: R=1,U=0,MN1-ID,MN1-HNP,MN2-ID,MN2-HNP 203 After detecting a possibility for localized routing, the LMA 204 constructs a Localized Routing Initiation (LRI) message that is used 205 to signal the intent to initiate localized routing and to convey 206 parameters for the same. This is a Mobility Header message and it 207 contains the MN-Identifier and the Home Network Prefix (as Mobility 208 Header options) for each of the MNs involved. The LMA sends the LRI 209 message to the MAG where the two MNs are attached. 211 The MAG starts by verifying that the two MNs are indeed attached to 212 it. It then verifies if the EnableMAGLocalRouting flag is set to 1. 213 If it is not, the MAG is not configured to allow localized routing 214 and it will reject the LRI and send an LRA with status code 215 "Localized Routing Not Allowed". It then creates Localized Routing 216 Entries(LREs) for each direction of the communication between the two 217 MNs. The exact form of the forwarding entries is left for the 218 implementations to decide; however, they should contain the HNP 219 corresponding to the destination IP address and a next-hop identifier 220 (e.g. the layer 2 address of the next- hop). These LREs MUST 221 override the BUL entries for the specific HNPs identified in the LRI 222 message. Hence all traffic matching the HNPs is forwarded locally. 224 If a MAG is unable to make deliver packets using the LREs, it is 225 possible that the MN is no longer attached to the MAG. Hence, the 226 MAG SHOULD fall back to using the BUL entry, and the LMA MUST forward 227 the received packets using its BCE. 229 The local forwarding is not permanent. For instance, the LMA may 230 send a LRI message with a request to cancel an existing local 231 forwarding service. The local forwarding also has a default 232 lifetime, upon the expiry of which, the forwarding reverts to 233 bidirectional tunneling. When local forwarding service ceases, the 234 corresponding LFE entries MUST be removed. 236 The MAG completes the processing of the LRI message and responds with 237 a Local Routing Acknowledgment (LRA) message. This Mobility Header 238 message also includes the MN-ID and the HNP for each of the 239 communicating MNs as well as an appropriate Status code indicating 240 the outcome of LRI processing. Status code 0 indicates localized 241 routing was successfully offered by the MAG. Any other value for 242 Status code indicates the reason for the failure to offer localized 243 routing service. When Status code is 0, the LMA sets a flag in the 244 BCE corresponding to the HNPs to record that localized routing is in 245 progress for that HNP. 247 The MAG may refresh the lifetime of an existing local forwarding 248 service. For this, it sends an unsolicited LRA (U-LRA) message that 249 contains the new lifetime value. The MAG MUST wait for the following 250 LRI message from the LMA before it can conclude that the refresh 251 request is granted. 253 4.1. Handover Considerations 255 If one of the MNs, say MN1, detaches from the MAG and attaches to 256 another MAG(say nMAG) the localized routing state needs to be re- 257 established. When the LMA receives the PBU from nMAG for MN1, it 258 will see that localized routing is active for for MN1. It will hence 259 initiate LR at nMAG and update the LR state of MAG. After the 260 handover completes, the localized routing will resemble Scenario A21. 262 5. Scenario A21: Two MNs attached to different MAGs but same LMA 264 The LMA may choose to support local forwarding to mobile nodes 265 attached to two different MAGs within a single PMIPv6 domain. 267 Internet 268 : 269 | 270 | 271 +-----+ 272 | LMA | 273 +-----+ 274 | 275 | 276 +----+-----+ 277 | | 278 +----+ +----+ 279 |MAG1| |MAG2| 280 +----+ +----+ 281 : : 282 +---+ +---+ 283 |MN1| |MN2| 284 +---+ +---+ 286 As earlier, the LMA initiates LRI as a response to some trigger 287 mechanism. In this case, however, it sends two separate LRI messages 288 to the two MAGs. In addition to the MN-ID and the HNP options, each 289 LRI message contains the IP Address of the counterpart MAG. When the 290 MAG IP Address option is present, each MAG MUST create a local 291 forwarding entry such that the packets for the MN attached to the 292 remote MAG are sent over a tunnel associated with that remote MAG. 293 The tunnel between the MAGs is assumed to be established by means 294 outside the scope of this document. 296 +----+ +----+ +----+ +----+ +----+ 297 |MN1 | |MN2 | |MAG1| |MAG2| |LMA | 298 +----+ +----+ +----+ +----+ +----+ 299 | | | | | 300 | data | data | 301 |<--------------------->|<----------------------->| 302 | | | | | 303 | | data | data | 304 | |<--------------------->|<----------->| 305 | | | | | 306 | | | | | 307 | | | LRI(Opt1) | 308 | | |<------------------------| 309 | | | | | 310 | | | | LRI(Opt2) | 311 | | | |<------------| 312 | | | | | 313 | | | LRA(Opt3) | 314 | | |------------------------>| 315 | | | | | 316 | | | | LRA(Opt4) | 317 | | | |------------>| 318 | | | | | 319 | | | | | 320 | | | | | 321 | data | data | | 322 |<--------------------->|<--------->| | 323 | | | | | 324 | | data | | 325 | |<--------------------->| | 326 | | | | | 327 | | | | | 329 Opt1: R=0,S=0,MN1-ID,MN1-HNP,MAG2-IPv6-Address 330 Opt2: R=0,S=0,MN2-ID,MN2-HNP,MAG1-IPv6-Address 331 Opt3: R=1,U=0,MN1-ID,MN1-HNP,MAG2-IPv6-Address 332 Opt4: R=1,U=0,MN2-ID,MN2-HNP,MAG1-IPv6-Address 334 As before, each MAG responds to the LRI with an LRA message. Barring 335 the error cases, all subsequent packets are routed between the MAGs 336 locally, without traversing the LMA. 338 The protocol does not require any synchronization between the MAGs 339 before local forwarding begins. Each MAG begins its local forwarding 340 independent of the other. 342 5.1. Handover Considerations 344 If one of the MNs, say MN1, detaches from its current MAG (in this 345 case MAG1) and attaches to another MAG (say nMAG1) the localized 346 routing state needs to be re-established. When the LMA receives the 347 PBU from nMAG1 for MN1, it will see that localized routing is active 348 for for MN1. It will hence initiate LR at nMAG1 and update the LR 349 state of MAG2 to use nMAG1 instead of MAG1. 351 6. Scenario A12: Two MNs attached to the same MAG with different LMAs 353 In this scenario, both the MNs are attached to the same MAG, but are 354 anchored at two different LMAs. 356 Internet 357 : : 358 +------------------+ 359 | | 360 +----+ +----+ 361 |LMA1| |LMA2| 362 +----+ +----+ 363 | | 364 | | 365 +------------------+ 366 | 367 | 368 | 369 +-----+ 370 | MAG | 371 +-----+ 372 : : 373 +---+ +---+ 374 |MN1| |MN2| 375 +---+ +---+ 377 Hence, neither LMA has a means to determine that the two Mobile Nodes 378 are attached to the same MAG. Only the MAG can possibly determine 379 that the two Mobile Nodes involved in communication are attached to 380 it. Hence the local routing has to be initiated by the MAG. 382 The MAG sends an LRI message containing the MN-ID, HNP and the 383 counterpart LMA address to each LMA. Each LMA makes decision to 384 support local forwarding independently, based on, among others, 385 policy configuration for the counterpart LMA. Each LMA MUST respond 386 to the LRI message with an LRA message. Only after it receives both 387 the LRA messages each with Status value set to zero (success) from 388 the two different LMAs, the MAG MUST conclude that it can provide 389 local forwarding support for the two Mobile Nodes. 391 +----+ +----+ +----+ +----+ +----+ 392 |MN1 | |MN2 | |MAG | |LMA1| |LMA2| 393 +----+ +----+ +----+ +----+ +----+ 394 | | | | | 395 | data | data | data | 396 |<--------------------->|<--------->|<----------->| 397 | | | | | 398 | | data | data | 399 | |<--------->|<----------------------->| 400 | | | | | 401 | | | | | 402 | | | LRI(Opt1) | | 403 | | |---------->| | 404 | | | | | 405 | | | LRI(Opt2) | 406 | | |------------------------>| 407 | | | | | 408 | | | LRA(Opt3) | | 409 | | |<----------| | 410 | | | | | 411 | | | LRA(Opt4) | 412 | | |<------------------------| 413 | | | | | 414 | | | | | 415 | | | | | 416 | data | data | | 417 |<--------------------->|<--------->| | 418 | | | | | 419 | | data | | | 420 | |<--------->| | | 421 | | | | | 422 | | | | | 424 Opt1: R=0,S=0,MN1-ID,MN1-HNP 425 Opt2: R=0,S=0,MN2-ID,MN2-HNP 426 Opt3: R=1,U=0,MN1-ID,MN1-HNP 427 Opt4: R=1,U=0,MN2-ID,MN2-HNP 429 6.1. Handover Considerations 431 If one of the MNs, say MN1, detaches from its current MAG (in this 432 case MAG1) and attaches to another MAG (say nMAG1) the localized 433 routing state needs to be re-established. After the handover 434 completes, the localized routing will resemble Scenario A22. 436 7. Scenario A22: Two MNs attached to the different MAGs with different 437 LMAs 439 This scenario will not be covered in this document since PMIPv6 does 440 not define any form of inter-LMA communications. When a supported 441 scenario, such as Scenario A12, morphs into Scenario A22 the node 442 that initiated the localized routing session SHOULD tear it down in 443 order to prevent lasting packet loss. This can result in transient 444 packet loss when routing switches between the localized path into the 445 normal path through the LMAs. In applications that are loss 446 sensitive, this can lead to observable service disruptions. In 447 deployments where Scenario A22 is possible, it is recommended that 448 localized routing not be initiated when packet-loss-sensitive 449 applications are in use. 451 8. IPv4 support in Localized Routing 453 PMIPv6 MNs can use an IPv4 HoA as described in 454 [I-D.ietf-netlmm-pmip6-ipv4-support]. In order to support the setup 455 and maintenance of localized routes for these IPv4 HoAs in PMIPv6, 456 MAGs must add the IPv4 HoAs into their LREs. The MAGs MUST also 457 support encapsulation of IPv4 packets as described in 458 [I-D.ietf-netlmm-pmip6-ipv4-support]. The localized routing protocol 459 messages MUST include a IPv4 HoA option in their signaling messages 460 in order to support IPv4 addresses for localized routing. 462 If the transport network between the PMIPv6 entitites involved in 463 localized routing is IPv4-only, the LRI and LRA messages MUST be 464 encapsulated similar to the PBU/PBA messages as specified in 465 [I-D.ietf-netlmm-pmip6-ipv4-support]. The encapsulation mode used 466 SHOULD be identical to the one used to transport PBU and PBA 467 messages. 469 9. Message Formats 471 All the Localized routing messages use a new mobility header type 472 (TBA1). The LRI message requests creation or deletion of localized 473 routing state and the LRA message acknowledges the creation or 474 deletion of such localized routing state. 476 9.1. Localized Routing Initiation (LRI) 478 The LMA sends an LRI message to a MAG to request local forwarding for 479 a pair of MNs. The MAG may also send this message to request the two 480 LMAs for offering local forwarding as described in Section 6 . 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Sequence # | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 |R|S| Reserved | Lifetime | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | 490 . . 491 . Mobility options . 492 . . 493 | | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 Sequence Number: A monotonically increasing integer. Set by a 497 sending node in a request message, and used to match a reply to 498 the request. 500 'R' flag: Set to 0, indicates it is an LRI message. 502 'S' flag: When set to 1, indicates a request to stop local 503 routing. 505 Reserved: This field is unused. MUST be set zero. 507 Lifetime: The requested time in seconds for which the sender 508 wishes to have local forwarding. A value of 0xffff (all ones) 509 indicates an infinite lifetime. 511 Mobility Options: MUST contain the MN-ID, followed by one or more 512 HNPs for each of the MNs. For instance, for Mobile Nodes MN-1 and 513 MN-2 with identifiers MN1-ID, MN2-ID and Home Network Prefixes 514 MN1-HNP and MN2-HNP, the following tuple in the following order 515 MUST be present: [MN1-ID, MN1-HNP], [MN2-ID, MN2-HNP]. The 516 MN-ID and HNP options are the same as in [RFC5213]. MAY contain 517 the remote MAG IPv6 address option, which is identical to the HNP 518 option except for Prefix Length equal to 128 bits. 520 The LRI message SHOULD be re-transmitted if a corresponding LRA 521 message is not received within LRA_WAIT_TIME time units, up to a 522 maximum of LRI_RETRIES, each separated by LRA_WAIT_TIME time units. 524 9.2. Localized Routing Acknowledgment (LRA) 526 A MAG sends an LRA message to the LMA as a response to the LRI 527 message. An LMA may also send this message to a MAG as a response to 528 the LRI message as described in Section 6 . 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Sequence # | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |R|U| Reserved | Status | Lifetime | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | | 538 . . 539 . Mobility options . 540 . . 541 | | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Sequence Number: is copied from the sequence number field of the 545 LRI message being responded to. 547 'R' flag: Set to 1, indicates it is an LRA message. 549 'U' flag: When set to 1, the LRA message is sent unsolicited. 550 The Lifetime field indicates a new requested value. The MAG MUST 551 wait for the regular LRI message to confirm that the request is 552 acceptable to the LMA. 554 Reserved: This field is unused. MUST be set zero. 556 Status: 558 0: Success 560 128: Localized Routing Not Allowed 561 129: MN not attached 563 Lifetime: The time in seconds for which the local forwarding is 564 supported. Typically copied from the corresponding field in the 565 LRI message. 567 Mobility Options: When Status code is 0, MUST contain the [MN-ID, 568 HNP] tuples in the same order as in the LRI message. When Status 569 code is 1, MUST contain only those [MN-ID, HNP] tuples for which 570 local forwarding is supported. The MN-ID and HNP options are the 571 same as in [RFC5213]. 573 10. New Mobility Option 575 10.1. MAG IPv6 Address 577 The MAG IPv6 address mobility option contains the IPv6 address of a 578 MAG involved in the localized routing. The MAG IPv6 address option 579 has an alignment requirement of 8n+4. 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type | Length | Reserved | Address Length| 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | | 587 + + 588 | | 589 + MAG IPv6 Address + 590 | | 591 + + 592 | | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Type 596 TBA3 598 Length 600 8-bit unsigned integer indicating the length of the option 601 in octets, excluding the type and length fields. This field 602 MUST be set to 18. 604 Reserved (R) 606 This 8-bit field is unused for now. The value MUST be 607 initialized to 0 by the sender and MUST be ignored by the 608 receiver. 610 Address Length 612 This field MUST be set to 128. 614 MAG IPv6 Address 616 A 16 byte field containing the MAG's IPv6 Address. 618 11. Security Considerations 620 The protocol specified in this document uses the same security 621 association between the LMA and the MAG to protect the LRI and LRA 622 messages. No new security risks are identified. Support for 623 integrity protection using IPsec is required, but support for 624 confidentiality is not necessary. 626 12. IANA Considerations 628 The Localized Routing Initiation, described in Section 9.1 and the 629 Local Routing Acknowledgment, described in Section 9.2 require a 630 single Mobility Header Type (TBA1) from the Mobility Header Types 631 registry at http://www.iana.org/assignments/mobility-parameters 633 The MAG IPv6 Address and the LMA IPv6 Address require a Mobility 634 Option Type each (TBA2 and TBA3) from the Mobility Options registry 635 at http://www.iana.org/assignments/mobility-parameters 637 13. Authors 639 This draft merges ideas from five different drafts addressing the 640 PMIP localized routing problem. The authors of these drafts are 641 listed below (in alphabetical order) 643 Kuntal Chowdhury 645 Ashutosh Dutta 647 Rajeev Koodli 649 Suresh Krishnan 651 Marco Liebsch 653 Paulo Loureiro 655 Desire Oulai 657 Behcet Sarikaya 659 Qin Wu 661 Hidetoshi Yokota 663 14. Acknowledgments 665 The authors would like to thank Sri Gundavelli, Julien Abeille, Tom 666 Taylor, Kent Leung, Mohana Jeyatharan, Jouni Korhonen, Glen Zorn, 667 Ahmad Muhanna and Zoltan Turanyi for their comments and suggestions. 669 15. Normative References 671 [I-D.ietf-netext-pmip6-lr-ps] 672 Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized 673 Routing Problem Statement", 674 draft-ietf-netext-pmip6-lr-ps-00 (work in progress), 675 September 2009. 677 [I-D.ietf-netlmm-pmip6-ipv4-support] 678 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 679 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-18 680 (work in progress), February 2010. 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, March 1997. 685 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 686 in IPv6", RFC 3775, June 2004. 688 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 689 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 691 Authors' Addresses 693 Suresh Krishnan (editor) 694 Ericsson 695 8400 Blvd Decarie 696 Town of Mount Royal, Quebec 697 Canada 699 Email: suresh.krishnan@ericsson.com 701 Rajeev Koodli 702 Cisco Systems 704 Email: rkoodli@cisco.com 706 Paulo Loureiro 707 NEC 709 Email: paulo.loureiro@nw.neclab.eu 711 Qin Wu 712 Huawei 714 Email: Sunseawq@huawei.com 716 Ashutosh Dutta 717 Telcordia 719 Email: adutta@research.telcordia.com