idnits 2.17.1 draft-korhonen-dmm-local-prefix-01.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 date (July 29, 2013) is 3923 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: 'MN' is mentioned on line 518, but not defined == Missing Reference: 'LMA' is mentioned on line 419, but not defined == Unused Reference: 'I-D.bhandari-dhc-class-based-prefix' is defined on line 630, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network-Based Mobility Extensions J. Korhonen 3 (Netext) Renesas Mobile 4 Internet-Draft T. Savolainen 5 Intended status: Standards Track Nokia 6 Expires: January 30, 2014 S. Gundavelli 7 Cisco 8 July 29, 2013 10 Local Prefix Lifetime Management for Proxy Mobile IPv6 11 draft-korhonen-dmm-local-prefix-01.txt 13 Abstract 15 This specification defines a protocol extension to Proxy Mobile IPv6 16 that enables prefix lifetime management for locally assigned prefixes 17 within a Proxy Mobile IPv6 domain. A locally assigned prefix is 18 managed by a Mobile Access Gateway and is always topologically 19 anchored to the Mobile Access Gateway within the Proxy Mobile IPv6 20 domain. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 30, 2014. 45 Copyright Notice 47 Copyright (c) 2013 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. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Mobility Options . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 6 66 4.1. Extensions to Binding Update List Entry Data Structure . . 6 67 4.2. Local Prefix/Address Assignment . . . . . . . . . . . . . 7 68 4.3. Local Use of Prefixes/Addresses . . . . . . . . . . . . . 7 69 4.4. Local Prefixes/Addresses Management . . . . . . . . . . . 7 70 4.4.1. Deprecating Prefixes/Addresses . . . . . . . . . . . . 7 71 4.4.2. Temporary Tunneling Between Mobile Access Gateways . . 8 72 4.4.3. Informing a Mobile Node of an Inoperable 73 Prefix/Address . . . . . . . . . . . . . . . . . . . . 8 74 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 8 75 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 8 76 5.2. Local Prefix/Address Context Transfer . . . . . . . . . . 8 77 5.3. Local Prefixes/Addresses Management . . . . . . . . . . . 9 78 6. Signaling Flow Examples . . . . . . . . . . . . . . . . . . . 9 79 6.1. Stateless Address AutoConfiguration Example . . . . . . . 9 80 6.2. Stateful Address Configuration Example . . . . . . . . . . 11 81 7. Configuration Objects . . . . . . . . . . . . . . . . . . . . 13 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 This specification defines a protocol extension to Proxy Mobile IPv6 93 (PMIPv6) [RFC5213] that enables prefix/address lifetime management 94 for locally assigned prefixes/addresses within a PMIPv6 domain. A 95 prefix/address locally assigned to the mobile node (MN) is managed by 96 a specific Mobile Access Gateway (MAG) and is always topologically 97 anchored to that MAG within the PMIPv6 domain. The protocol 98 extension essentially defines a context transfer mechanism that 99 allows for a source MAG to inform a target MAG about locally assigned 100 prefixes/addresses during the handover. 102 After a handover, the prefixes/addresses from the source MAG are 103 topologically in an incorrect location when the mobile node (MN) is 104 attached to the target MAG. The context transfer mechanism defined 105 in this specification can implicitly serve as a trigger to create a 106 temporary tunneling (read, localized routing) between MAGs for the 107 period prefixes/addresses from the source MAG are used under the 108 target MAG. 110 Additionally, using the context transfer information the target MAG 111 can take required actions to deprecate those prefixes/addresses that 112 belong to the source MAG. The specified mechanism is a complementary 113 for Simple Procedures for Detecting Network Attachment in IPv6 (DNA) 114 [RFC6059]. Explicit network side prefix/address deprecation is 115 useful in situations, for instance, when the MN does not implement 116 DNA or there is a need to trigger DHCPv6 Reconfigure procedure 117 [RFC3315] when the MN attaches to the target MAG. 119 [Discussion: it is to be verified whether the existing PMIPv6 120 Localized Routing protocol [RFC6705] with small enhancements is 121 appropriate for the temporary tunneling between MAGs for the 122 purpose this specification has.] 124 Locally assigned prefixes/addresses that are topologically anchored 125 to the MAG allow for optimized access to local resources near the 126 MAG. This, of course, assumes the MAG is able to route certain 127 traffic locally bypassing the PMIPv6 tunnel, and the MN is able to 128 detect which prefixes/addresses are local or have mobility 129 [I-D.korhonen-6man-prefix-properties][I-D.bhandari-dhc-class-based-pr 130 efix]. 132 2. Solution Overview 134 The protocol solution in this specification is targeted to the 135 following use case and illustrated in Figure 1. Additional use cases 136 outside the IP mobility domain are discussed extensively in 138 [I-D.lepape-6man-prefix-metadata]. 140 o A MN is assigned with multiple prefixes that it uses to configure 141 multiple IPv6 addresses. 143 o Some of the prefixes/addresses assigned to the MN are anchored at 144 the Local Mobility Anchor (LMA) and provide mobility within the 145 PMIPv6 domain. 147 o Some of the prefixes/addresses assigned to the MN are local to the 148 MAG the MN is currently attached to. These prefixes/addresses 149 provide mobility only in a limited area, for example, within the 150 layer-2 domain under the MAG control. 152 o When the MN moves from a MAG (i.e., a source MAG) to another MAG 153 (i.e., a target MAG), the prefixes/addresses anchored to the LMA 154 remain but the prefixes/addresses anchored to a MAG will change. 155 The prefixes/addresses are topologically only valid under the MAG 156 they are anchored to. 158 o If DHCPv6 is used for configuring addresses to the MN, then the 159 DHCPv6 server is collocated in the LMA. 161 +----------------------> Internet 162 | ^ 163 | : mobility 164 | | (Prefix_z) 165 | +-----+ 166 | | LMA | 167 | +-----+ 168 +---+ +---+ | +---+ 169 |rtr| |CNx| | |CNy| 170 +---+ +---+ | +---+ 171 | | | | 172 ---+---------+------+ +--------+--------+ +-----+----- 173 local | | | | local 174 network | | | | network 175 (Prefix_x) +---+ +---+ (Prefix_y) 176 |src| temporary |tgt| 177 |MAG|===============|MAG| 178 +---+ tunnel +---+ 179 : : 180 +--+ +--+ 181 |MN|--------------->|MN| 182 +--+ handover +--+ 184 Figure 1: Local services provided topologically close to a MAG 186 In order to provide a mechanism for a source MAG to inform the target 187 MAG about prefixes the MN might have configured and that are 188 topologically valid only under the source MAG, there is a need for a 189 context transfer of locally assigned prefix/address information 190 between MAGs. This specification extends both the PMIPv6 signaling 191 and the Binding Cache in the LMA with a local prefix/address 192 information. 194 During the Proxy Binding Update (PBU) and the Proxy Binding 195 Acknowledgement (PBA) exchange, MAGs and the LMA inform each other 196 about locally assigned prefixes/addresses. Using that information, a 197 target MAG can do the following two things: 199 o Make sure the prefixes/addresses from the source MAG get 200 deprecated and eventually invalidated using some mechanism (that 201 essentially does not require end host stack changes). 203 o Optionally create of a temporary tunnel between the source and the 204 target MAG, and setting up the required host routes for routing 205 addresses belonging to the source MAG back and forth until the 206 addresses become invalid. 208 3. Mobility Options 210 A MAG uses the Local Prefix mobility option (LPO) to inform the LMA 211 of the IPv6 prefix/address and its valid lifetime (see [RFC4861] and 212 [RFC3315]) that shall be locally assigned to a MN. After a handover 213 an LMA uses the option to inform a target MAG of the IPv6 prefix/ 214 address that was assigned to a MN by the previous MAG. The Local 215 Prefix option has an alignment of 4n. There can be zero or more LPOs 216 in a PUB and in a PBA. 218 0 1 2 3 219 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type=TBD1 | Length=22 | Prefix Length |R| Reserved | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Valid Lifetime | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 | Local Prefix/address | 228 | | 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 2: Local Prefix Mobility Option 234 Type: 236 Set to TBD1. 238 Length: 240 The length of the Local Prefix mobility option in octets, 241 excluding the Option Type and Length fields. The length is set to 242 22. 244 Prefix Length: 246 The prefix length of the local IPv6 prefix. Valid prefix lengths 247 are between 1 and 128. In case of an IPv6 address the prefix 248 length is 128. 250 'R': 252 Set to 1 if the sender of the LPO wants the receiver to deprecate/ 253 invalidate/remove the prefix/address. Otherwise set to 0. 255 Reserved: 257 This field is reserved for future use. MUST be set to zero by the 258 sender and ignored by the receiver. 260 Valid Lifetime: 262 The valid lifetime of the IPv6 prefix/address. The value follows 263 the valid lifetime semantics of Prefix Information Option 264 [RFC4861] and OPTION_IAADDR option [RFC3315]. 266 Local Prefix/address: 268 The locally assigned IPv6 prefix/address. 270 4. Mobile Access Gateway Operation 272 4.1. Extensions to Binding Update List Entry Data Structure 274 The Binding Update List Entry (BULE) data structure for each MN's 275 mobility binding with its LMA is extended with zero or more locally 276 assigned IPv6 prefix/address, and its lifetime information. 278 4.2. Local Prefix/Address Assignment 280 A MAG maintains a pool of locally usable prefixes/addresses. If the 281 'EnableLocalPrefixManagement' configuration object is set to TRUE, 282 then the MAG assigns one or more local prefixes/addresses to the MN 283 during the initial attach. Essentially the MAG adds new Local Prefix 284 Mobility Options into the Proxy Binding Update (PBU) message, and 285 eventually advertises those prefixes to the MN when using Stateless 286 Address AutoConfiguration (SLAAC). 288 4.3. Local Use of Prefixes/Addresses 290 The local prefixes/addresses are topologically anchored to the MAG, 291 and do not really provide mobility in a same level as PMIPv6 provides 292 for Home Network Prefixes (HNP) anchored to the LMA. This 293 specification also requires the MAG is provided with a functionality 294 that certain traffic can bypass the PMIPv6 tunnel in the MAG. Such 295 functionality is already hinted in [RFC5213] Section 6.10.3. 296 However, this specification further assumes the local corresponded 297 nodes do not need to be directly on the access link connected to the 298 MAG. They can be any number of IP hops away. 300 There is no restriction on the scope of the local prefixes/addresses. 301 A MN could use local addresses to the MAG as its source address to 302 access the Internet, assuming local addresses have a global scope. 303 Similarly, the MN could use the home address anchored to the LMA to 304 reach local destinations around the MAG. 306 4.4. Local Prefixes/Addresses Management 308 After a MN has moved from a source MAG to a target MAG as a result of 309 a handover, the MN might be configured with prefixes/addresses that 310 topologically belong to the source MAG. In this case, the target MAG 311 may purposely need to deprecate and invalidate or otherwise handle 312 prefixes/addresses that are topologically in a wrong place (i.e., are 313 anchored to the source MAG). We could assume that the DNA [RFC6059] 314 handles this but explicit actions by the target MAG make sure that 315 MNs without DNA support are also covered. 317 4.4.1. Deprecating Prefixes/Addresses 319 A target MAG receives information of prefixes/addresses that are not 320 valid under the target MAG in LPOs included in a PBA from a LMA. If 321 SLAAC is used to configure addresses to a MN, then the target MAG 322 SHOULD deprecate prefixes from the source MAG by sending a Router 323 Advertisement with a Prefix Information Option (PIO) and set at least 324 the preferred lifetime to zero (0). The valid lifetime is set to 325 value received in the corresponding LPO. If e.g. SeND [RFC3971] is 326 used, then the valid lifetime can also be set to zero (0). 328 4.4.2. Temporary Tunneling Between Mobile Access Gateways 330 During the handover from a source MAG to a target MAG, it might not 331 be possible to make the MN to discard all addresses in use that 332 belong to the source MAG. This is the case, for example, when the MN 333 does not implement the DNA functionality and the valid lifetime of 334 the prefixes is still greater than zero. In this case, it would be 335 beneficial to establish a temporary tunnel for the local addresses 336 from the source MAG to the target MAG for the period the valid 337 lifetime of the prefixes expires. The temporary tunnel would be 338 removed immediately when valid lifetime of the local prefix from the 339 source MAG expires. Whether the target MAG initiates the creation of 340 the temporary tunnel between MAGs is controlled by the 341 'EnableTemporaryLocalizedRouting' configuration object. 343 [Discussion: it is to be verified whether [RFC6705] is usable for 344 this purpose and whether it has to be extended to cover the above use 345 case or do we need to develop a new one.] 347 4.4.3. Informing a Mobile Node of an Inoperable Prefix/Address 349 If tunneling between MAGs as described in Section 4.4.2 is not an 350 option, then the target MAG SHOULD respond to all IP packets a MN 351 originates with an address belonging to the source MAG with an ICMPv6 352 error Destination Unreachable Message and set the Code to 5 (Source 353 address failed ingress/egress policy) [RFC4443]. The configuration 354 SHOULD remain active until the valid lifetime received from the 355 corresponding LPO expires. 357 5. Local Mobility Anchor Operation 359 5.1. Extensions to Binding Cache Entry Data Structure 361 The Binding Cache Entry (BCE) data structure for each currently 362 registered MN is extended with zero or more locally assigned IPv6 363 prefix/address and its valid lifetime pairs. The prefix/address in 364 the Local Prefix mobility option MUST NOT be used as a BCE look up 365 key. 367 5.2. Local Prefix/Address Context Transfer 369 The operation of the LMA is fairly simple. When the LMA received a 370 PBU and the BCE for the MN has no prior knowledge of a local prefix/ 371 address information learned from the received LPO option, then the 372 LMA: 374 o Records the prefix/address into the BCE. 376 o Records the valid lifetime of the prefix/address into the BCE. 378 o Echoes the prefix/address, the valid lifetime and 'R' set to 0 379 information back to the MAG in the LPO option included in the PBA. 381 If the BCE for the MN has existing local prefix/address information 382 learned from the received LPO option, then the LMA: 384 o Records the new prefix/address into the BCE. 386 o Records the new valid lifetime of the prefix/address into the BCE. 388 o Returns the old prefix/address, the valid lifetime and 'R' set to 389 1 information back to the MAG in the LPO option included in the 390 PBA. 392 5.3. Local Prefixes/Addresses Management 394 After a MN has moved from a source MAG to a target MAG as a result of 395 a handover, the MN might be configured with prefixes/addresses that 396 topologically belong to the source MAG. If DHCPv6 was used to 397 configure addresses to the MN, then the LMA SHOULD initiate the 398 DHCPv6 Reconfigure procedure towards the MN immediately after sending 399 the PBA to the target MAG. If SLAAC was used to configure addresses 400 to the MN, then the LMA does not need to do anything beyond what has 401 already been done in Section 5.2. 403 6. Signaling Flow Examples 405 6.1. Stateless Address AutoConfiguration Example 407 Figure 3 shows example PMIPv6 signaling for the initial attachment to 408 the PMIPv6 domain and a handover with locally assigned prefixes and 409 when the stateless autoconfiguration (SLAAC) [RFC4862] is used for 410 configuring addresses. 412 In the following figure 'PIO' stands for Prefix Information Option 413 [RFC4861] in a Router Advertisement, 'p' means the preferred lifetime 414 in a PIO, and 'v' means the valid lifetime in a PIO. 'lp1' stands for 415 local prefix 1 and 'lt1' for its valid lifetime. Similarly 'lp2' 416 stands for local prefix 2 and 'lt2" for its valid lifetime. 'lp1' is 417 different from 'lp2'. 419 [MN] [MAG_1] [MAG_2] [LMA] 420 | | | | 421 |--- Rtr Sol --->| | | 422 | | | | 423 | MAG_1 assigns local | | 424 | IPv6 prefix lp1 | | 425 | | | | 426 | |--- PBU ------------------------>| 427 | | LPO=lp1/lt1/R=0, | 428 | | HNP=0, | LMA records 429 | | HI=1, ... | lp1/lt1, assigns 430 | | | HNP pref 431 | | | | 432 | |<-- PBA -------------------------| 433 | | LPO=lp1/lt1/R=0, | 434 |<-- Rtr Adv ----| HNP=pref, ... | 435 | PIO=pref, | | | 436 | PIO=lp1/p=lt1/v=lt1 (new) | | 437 | | | | 438 .... handover takes place .... 439 | | | | 440 |--- Rtr Sol -------------------->| | 441 | | | | 442 | | MAG_2 assigns local | 443 | | IPv6 prefix lp2 | 444 | | | | 445 | | |--- PBU ------->| 446 | | | LPO=lp2/lt2/R=0, 447 | | | HNP=0, HI=3,| 448 | | | ... | 449 | | | lp2 != lp1, thus 450 | | | LMA records 451 | | | lp2/lt2, returns 452 | | | previous lp1/lt1 453 | | | | 454 | | |<-- PBA --------| 455 |<-- Rtr Adv ---------------------| LPO=lp1/lt1/R=1, 456 | PIO=pref, | | HNP=pref, ... 457 | PIO=lp2/p=lt2/v=lt2, (new) | | 458 | PIO=lp1/p=0/v=lt1 (old) | | 459 | | | | 461 Figure 3: Local prefix assignment and lifetime management example 462 using SLAAC 464 6.2. Stateful Address Configuration Example 466 Figure 4 shows example PMIPv6 signaling for the initial attachment to 467 the PMIPv6 domain with locally assigned prefixes and when the 468 stateful address configuration (DHCPv6) is used for configuring 469 addresses. 471 In the following figures 'p' means the preferred lifetime in an IA_TA 472 or IA_NA, and 'v' means the valid lifetime in an IA_TA or IA_NA 473 respectively. Also, 'la1' stands for local address 1 and 'lt1' for 474 its valid lifetime. Similarly 'la2' stands for local address 2 and 475 'lt2" for its valid lifetime. 'la1' is different from 'la2'. The 476 'IA_xA' stands for either IA_TA or IA_NA. 478 [MN] [MAG_1/Relay] [DHCPv6-S ~ ~ ~ ~ ~ LMA] 479 | | | | 480 |--- Rtr Sol --->| | | 481 | | | | 482 | MAG_1 assigns local | | 483 | IPv6 address la1 | | 484 | | | | 485 | |--- PBU ------------------------>| 486 | | LPO=la1/R=0,| | 487 | | HNP=0, | LMA records 488 | | HI=1, ... | la1, assigns 489 | | | HNP pref 490 | | | | 491 | |<-- PBA -------------------------| 492 |<-- Rtr Adv ----| LPO=la1/lt1/R=0, | 493 | M=1, ... | HNP=pref, | | 494 | | ... | | 495 | | | | 496 |--- Solicit --->| Relay adds | | 497 | | link-addr=pref | | 498 | | | | 499 | |--- Relay-f --->| DHCPv6 server | 500 | | | adds IA_xA with| 501 | | | la1/p=lt1/v=lt1, 502 | | | HoA based on pref, 503 | | | Reconfigure Accept, 504 | | | ... | 505 | |<-- Relay-r ----| | 506 |<--- Advert or -| | | 507 | Reply | | | 508 | | | | 509 | ... DHCPv6 negotiation may continue... 510 | | | | 512 Figure 4: Local prefix assignment example using stateful DHCPv6 514 Figure 5 shows example PMIPv6 signaling for a handover with locally 515 assigned prefixes and when the stateful address configuration 516 (DHCPv6) is used for configuring addresses. 518 [MN] [MAG_2/Relay] [DHCPv6-S ~ ~ ~ ~ ~ LMA] 519 | | | | 520 .... handover takes place .... 521 | | | | 522 [ |--- Rtr Sol --->| ] | | 523 | | | | 524 | MAG_2 assigns local | | 525 | IPv6 address la2 | | 526 | | | | 527 | |--- PBU ------------------------>| 528 | | LPO=la2/lt2/R=0, | 529 | | HNP=0, | la2 != la1, thus 530 | | HI=3, ... | LMA records 531 | | | la2/lt2, returns 532 | | | previous la1/lt1/R=1 533 | | | | 534 | |<-- PBA -------------------------| 535 [ |<-- Rtr Adv ----| ] LPO=la1/lt1/R=1, | 536 | M=1, ... | HNP=pref, | | 537 | | ... | | 538 | | | | 539 |<-- Reconfigure ----------------------------------| 540 | IA_xA, | | | 541 | ... | | | 542 | | | | 543 |--- Renew --------------------------------------->| 544 | IA_xA with | | | 545 | HoA, | | DHCPv6 server 546 | la1, | | adds IA_xA with 547 | ... | | la1/p=0/v=0, 548 | | | la2/p=lt2/v=lt2, 549 | | | HoA, | 550 | | | ... | 551 | | | | 552 |<-- Reply ----------------------------------------| 553 | ... | | | 554 | | | | 556 Figure 5: Local prefix change example using stateful DHCPv6 during a 557 handover 559 7. Configuration Objects 561 This specification defines two configuration objects. 563 EnableLocalPrefixManagement 565 This configuration object is available in both a MAG and in a LMA. 566 When set to TRUE (i.e., enabled), the PMIPv6 node enables the 567 local IPv6 prefix/address lifetime management functionality. The 568 default value is FALSE (i.e., disabled). 570 EnableTemporaryLocalizedRouting 572 This configuration object is available in both a MAG and in a LMA. 573 When set to TRUE (i.e., enabled), the MAG or the LMA MAY initiate 574 the localized routing (tunnel) [RFC6705] for the period locally 575 meaningful prefixes from the previous MAG are still valid. The 576 default value is FALSE (i.e., disabled). 578 8. Security Considerations 580 The security considerationf for the Proxy Mobile IPv6 [RFC5213] 581 apply. Furthermore, generic security threats regarding the address/ 582 prefix ownership also apply [RFC3971]. An attacker can make use of 583 unprotected Router Advertisements to interfere the address selection 584 the MN does and in that way hijact traffic. This requires that the 585 attacker is albe to gain access to the same link the victim host is. 587 [Editor's Note: security considerations to be imporved.] 589 9. IANA Considerations 591 One new mobility options for the use with PMIPv6 is defined in the 592 [RFC6275] "Mobility Options" registry. The mobility option is 593 defined in Section 3: 595 Local Prefix Mobility Option is set to TBD1 597 10. Acknowledgements 599 We ack. 601 11. References 602 11.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 608 and M. Carney, "Dynamic Host Configuration Protocol for 609 IPv6 (DHCPv6)", RFC 3315, July 2003. 611 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 612 Message Protocol (ICMPv6) for the Internet Protocol 613 Version 6 (IPv6) Specification", RFC 4443, March 2006. 615 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 616 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 617 September 2007. 619 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 620 Address Autoconfiguration", RFC 4862, September 2007. 622 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 623 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 625 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 626 in IPv6", RFC 6275, July 2011. 628 11.2. Informative References 630 [I-D.bhandari-dhc-class-based-prefix] 631 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 632 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 633 based prefix", draft-bhandari-dhc-class-based-prefix-05 634 (work in progress), July 2013. 636 [I-D.korhonen-6man-prefix-properties] 637 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 638 Liu, "IPv6 Prefix Properties", 639 draft-korhonen-6man-prefix-properties-02 (work in 640 progress), July 2013. 642 [I-D.lepape-6man-prefix-metadata] 643 Pape, M., Systems, C., and I. Farrer, "IPv6 Prefix Meta- 644 data and Usage", draft-lepape-6man-prefix-metadata-00 645 (work in progress), July 2013. 647 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 648 Neighbor Discovery (SEND)", RFC 3971, March 2005. 650 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 651 Detecting Network Attachment in IPv6", RFC 6059, 652 November 2010. 654 [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 655 Dutta, "Localized Routing for Proxy Mobile IPv6", 656 RFC 6705, September 2012. 658 Authors' Addresses 660 Jouni Korhonen 661 Renesas Mobile 662 Porkkalankatu 24 663 FIN-00180 Helsinki 664 Finland 666 Email: jouni.nospam@gmail.com 668 Teemu Savolainen 669 Nokia 670 Hermiankatu 12 D 671 FI-33720 Tampere 672 FINLAND 674 Email: teemu.savolainen@nokia.com 676 Sri Gundavelli 677 Cisco 678 170 West Tasman Drive 679 San Jose, CA 95134 680 USA 682 Email: sgundave@cisco.com