idnits 2.17.1 draft-ietf-nemo-prefix-delegation-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 843. 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 abstract seems to contain references ([7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 21, 2007) is 6086 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) ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '3') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3633 (ref. '4') (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '5') ** Obsolete normative reference: RFC 3775 (ref. '6') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4282 (ref. '8') (Obsoleted by RFC 7542) ** Downref: Normative reference to an Informational RFC: RFC 4885 (ref. '10') Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Mobility P. Thubert 3 Internet-Draft Cisco 4 Expires: February 22, 2008 TJ. Kniveton 5 Nokia 6 August 21, 2007 8 Mobile Network Prefix Delegation 9 draft-ietf-nemo-prefix-delegation-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 22, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This paper extends the Nemo Basic Support [7] for a Mobile Router to 43 synchronize its Mobile Network Prefixes with its Home Agents and 44 obtain new ones dynamically. The proposed prefix delegation 45 mechanism is agnostic to the way the back end is implemented; it 46 enables bootstrapping, resynchronization at binding creation or after 47 a loss of states (eg MR reboot), MNP Renumbering, and configuration 48 checking for loop avoidance. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Motivation for a NEMO prefix delegation . . . . . . . . . . . 3 54 2.1. Configuration management . . . . . . . . . . . . . . . . . 4 55 2.2. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.4. The NEMO bootstrap problem . . . . . . . . . . . . . . . . 5 58 2.5. Local Mobility Management . . . . . . . . . . . . . . . . 5 59 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Which capabilities? . . . . . . . . . . . . . . . . . . . 6 62 4.1.1. Prefix Request capability . . . . . . . . . . . . . . 6 63 4.1.2. Full prefix list capability for HA . . . . . . . . . . 6 64 4.1.3. Full prefix list capability for MR . . . . . . . . . . 7 65 4.2. Rationale for new Binding options . . . . . . . . . . . . 7 66 4.3. Rationale for a new bit in the BU . . . . . . . . . . . . 7 67 4.4. Why not Alternate standard based solutions? . . . . . . . 7 68 5. Terminology and concepts . . . . . . . . . . . . . . . . . . . 9 69 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6.1. New mobility Headers . . . . . . . . . . . . . . . . . . . 10 71 6.2. New Prefix Status bit . . . . . . . . . . . . . . . . . . 10 72 6.3. Prefix lease duration . . . . . . . . . . . . . . . . . . 10 73 6.4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 11 74 6.5. backward compatibility . . . . . . . . . . . . . . . . . . 11 75 6.6. PD flow . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 77 7.1. Binding Update . . . . . . . . . . . . . . . . . . . . . . 12 78 7.2. Binding Acknowledgement . . . . . . . . . . . . . . . . . 13 79 7.3. Mobile Network Prefix option . . . . . . . . . . . . . . . 14 80 7.4. Mobile Network Prefix request option . . . . . . . . . . . 15 81 7.5. Mobile Network Prefix Confirm option . . . . . . . . . . . 17 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 20 87 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 89 Intellectual Property and Copyright Statements . . . . . . . . . . 22 91 1. Introduction 93 The reader of that document is expected to be familiar with both the 94 Mobile IPv6 [6] and NEMO Basic Support [7] documents. As such, it is 95 well-understood that neither protocol provides the means for 96 provisioning the Mobile Nodes and Routers with essential parameters 97 such as Home Address and Home Network. 99 The process by which a router obtains a prefix dynamically is called 100 prefix delegation. In the NEMO context, the prefix is managed by an 101 authority that owns the Home Network and subnets it into MNPs that it 102 assigns to the MRs. An MNP can be preassigned to the associated MR 103 (e.g. manually or automatically with a provisionning system), or 104 assigned dynamically by a server such as a DHCP Prefix Delegation 105 server. 107 As prescribed by [7], the HA checks whether a MR is authorized for 108 the MNPs it claims as part of the NEMO Binding Update with the 109 explicit prefix option. Also, MNPs have to belong to an aggregation 110 that is permanently advertised by the HA to the routing 111 infrastruture. Consequently, there is a strong relationship between 112 the HA that the MR registers to and the prefixes it claims with the 113 registration, and it makes sense for the HA to participate actively 114 to the delegation process as well. 116 [7] standardizes an interface between a Mobile Router and its Home 117 Agent, as well as an interface between Home Agents. The protocol is 118 agnostic as to how the back end is implemented in terms of AAA, 119 provisioning, or routing between the HAs and their IGP, and enables 120 various forms of deployment, as described in [12]. 122 In a same fashion, this document extends [7] for a Mobile Router to 123 obtain its Mobile Network Prefix dynamically from its Home Agent, 124 with no assumption about the specific back-end implementation for 125 prefix management and service authorization. 127 2. Motivation for a NEMO prefix delegation 129 A number of reasons plead for adding this capability to the NEMO 130 Basic Support [7]. 132 Mainly, there is an unanswered question as to how a MR could be 133 dynamically assigned its prefix. In a situation where a site has 134 many MRs, it may be impractical to assign the prefixes statically in 135 the non-volatile memory of the MR. Consequently, a mechanism for the 136 HA to assign the prefix, similar to how a MN can bootstrap its Home 137 Address, would be desirable. 139 2.1. Configuration management 141 The Implicit Mode of the NEMO Basic Support 'externalizes' the 142 configuration of the MNPs in a MR and its HA. In the example of a 143 static configuration, both side are initially provisioned with the 144 association between the MRs and their MNPs, and maintain matching 145 states between them. 147 The failure to configure and maintain these matching states overtime 148 ends up in routing loops and unreachable prefixes. Tools for 149 synchronizing MNPs in runtime would be a valuable addition to [7]. 151 2.2. Provisioning 153 In practice, provisioning both sides manually is error-prone and 154 should be avoided. It can not be taken for granted, either, that in 155 all cases, a provisioning system can be deployed with the capability 156 to configure both the Mobile Router and the back-end in a 157 transactional manner. Consequently, it appears necessary to provide 158 a way to configure one side only, and have the other side learn from 159 it in a trusted fashion and with no additional manual intervention. 161 The Explicit Prefix mode enables a flow where the configuration of 162 that association is not centralized at the HA but distributed to all 163 the MRs. In the other hand, the HA is required to validate that the 164 MR has been authorized for the MNPs it claims and then again, some 165 level of information duplication might occur. 167 In the general case, it may be easier to manage the prefix 168 attribution in a centralized manner and have the MRs learn their 169 prefixes dynamically. 171 2.3. Renumbering 173 The concept of lifetime is one core idea with IPv6. Nothing is 174 eternal. Overtime, it might be desirable to modify the configuration 175 of the MNPs. This task, called renumbering, is especially difficult 176 for Mobile Routers when they are geographically distributed and can 177 not be readily made available to the administrators. 179 It is thus desirable to extend the NEMO Basic Support [7] with a 180 renumbering mechanism. In particular, it makes sense to provide that 181 extension within the prefix delegation mechanism, since the 182 operations that take place are similar. 184 2.4. The NEMO bootstrap problem 186 The NEMO Basic Support [7] expects a Mobile Router to be provisioned 187 with some information in order to start up - Home Network or Home 188 Agent address, Home Address, Mobile Network Prefixes, security 189 tokens, etc... 191 In some situations, it may be impractical to actually provision all 192 this information into the router at deployment time, and some of it 193 has to be obtained dynamically when a system boots up, possibly 194 through manually keying by the final user. 196 It is absolutely required to reduce such manual keying of information 197 to the bare minimum, for instance a Network Access Identifier [8] 198 transported in the Mobile Node Identifier Option for Mobile IPv6 [9]. 199 And while NEMO can benefit from the MIP6 effort on the bootstrap 200 problem (as described in the MIP6 bootstrap problem statement 201 document [11]) for most parameters, the dynamic provisionning of 202 Mobile Network Prefix(es) is not considered by MIPv6. 204 2.5. Local Mobility Management 206 In turn, the bootstrap problem is linked to the Local Mobility 207 Management problem; some LMM solutions such as HMIP deploy regional 208 Home Agents from which bootstrap information has to be obtained when 209 moving into their area of coverage; as opposed to the initial 210 bootstrap problem which occurs at the first startup of a device and 211 may not happen again for an extensive period of time, LMM is tied to 212 movement, and could be quite frequent. 214 3. Requirements 216 There is thus a need for a Mobile Router to obtain dynamically one or 217 more MNPs, linked to the HA that the MR binds with. 219 Since the process may be used as part of a mobility scenario, there 220 is also a need to optimize the delegation flow by limiting the number 221 of protocol exchanges that take place for delegation and 222 registration. 224 Since the initial configuration may be erroneous or may need to 225 evolve overtime, there is a need to manage the MNPs on a Mobile 226 Router. This includes initial setting up, and synchronizing 227 overtime. 229 4. Rationale 231 This section details the rationale behind some of the design 232 decisions that lead to this solution. 234 4.1. Which capabilities? 236 4.1.1. Prefix Request capability 238 The minimum capability that could be envisionned for a NEMO Prefix 239 Delegation mechanism is for a MR to request for a new prefix in a 240 Binding Update and for the HA to provide the prefix as part of the 241 Binding Acknowledgement. Then the Mobile Router installs the newly 242 obtained prefix on the interface that needs it, and moves forward in 243 implicit or explicit mode. 245 4.1.2. Full prefix list capability for HA 247 The capability to request a new prefix is sufficient in a basic 248 delegation flow where a MR that is already bound and -hopefully- 249 synchronized with its HA in terms of prefix ownership; it is also 250 required in some bootstrapping and renumbering flows; but it is 251 hardly sufficient in order to synchronize the MR and the HA states 252 regarding MNPs: 254 Bootstrapping: At bootstrapping time, the MR needs the list of all 255 the prefixes that are attributed in order to populate its 256 interfaces. Asking them one by one and having to make a 257 distinction between already allocated prefixes versus dynamic 258 allocation would make the flow much more complex. 260 Expired prefixes: That list is also needed for a MR in order to 261 synchronize its current configuration with that of the HA. In 262 particular, it is used for a MR to discover when the HA does not 263 have the associated states in place for one of its MNPs. This may 264 happen for some configuration error or because the prefix has 265 expired, and the only way to know is if the prefix is missing in a 266 full list of all prefixes by the HA. 268 Newly allocated prefixes: Finally, the list is needed for a MR to 269 learn new prefixes that would be attributed in runtime, and to 270 install those prefixes on its interfaces. Once the new prefixes 271 are installed, it is required that the MR confirms its use of the 272 prefixes so that the HA can set up routing in a loopfree fashion. 274 So the capability for a HA to list all the prefixes for a MR is 275 needed for the MR to realize that the HA is missing some states and 276 eventually to try to get the missing prefixes in explicit mode. This 277 may happen on demand by the MR (e.g. at bootstrap time or binding 278 creation time), or whenever the HA needs to communicate about a 279 change, such as a shortened or expired MNP lifetime. 281 4.1.3. Full prefix list capability for MR 283 So the capability for a HA to list all the prefixes is not sufficient 284 is the HA is not the repository of that knowledge. It might be 285 simpler for the MR to dump its own list of prefixes and have the HA 286 check the list, even for implicit prefixes. 288 4.2. Rationale for new Binding options 290 Associated to the capability to request a new prefix, it seems 291 relevant to specify whether the prefix is for implicit or explicit 292 mode, or if its lifetime is limited with that of the binding cache or 293 not. Other fields such as the prefix length are needed as well. In 294 order to convey that information, an optional field is needed in the 295 BU. 297 It is not desirable to extend the existing NEMO MNP option, which 298 carries a prefix that is not needed, though. As a result, we propose 299 a new option type, the MNP request option. 301 Associated to the capability for a HA to list all the prefixes for a 302 MR, one critical information is needed, that would not fit in the 303 NEMO MNP option. Again, we propose a new option for the Binding 304 Acknowledgement, the MNP confirm option. 306 4.3. Rationale for a new bit in the BU 308 A single bit in the BU is enough for a MR to request a full list of 309 prefixes from the HA, if we do not need a filter of any sort???? 311 It is important that the HA set that bit in its full list of prefixes 312 in order to differentiate between an empty list (there's no prefix 313 for that MR) and no list (HA is not providing a list in that BA). 315 4.4. Why not Alternate standard based solutions? 317 Proposing a new, specific solution might seem irrelevant when a 318 standard, generic mechanism already exist, in this case the DHCPv6 319 Prefix Delegation. In fact, it is possible for the Home Agent to act 320 as a DHCPv6PD Delegating Router. This solution presents the 321 advantage of reusing existing standard flows from RFC3633 [4]. 323 Yet, in a deployment where the MNPs are preassigned to the MR, a AAA 324 server, interfacing with the HA, and eventually coupled with a 325 provisioning system in its back end, can provide the required service 326 for assigning and authorizing the prefixes to the MRs; in such a 327 case, the value of implementing a DHCPv6PD server is highly arguable. 328 It is more generic to let the HA handle the backend interfaces on 329 behalf of the MR and expose a consistent NEMO interface for all 330 deployments. 332 In more details, a DHCPv6PD based solution presents a number of 333 inconveniences: 335 Delegating Router: A collocated Delegating Router function may not 336 be available for all implementation of NEMO Home Agent. In 337 particular, some implementations are server based. 339 Operational overhead: Depending on the mechanism that is used to 340 attribute the MNPs to the MRs, the Delegating function, even if 341 available, might be a costly overhead. Rather, an embedded, back- 342 end agnostic flow might be a desirable option. 344 Movement overhead: Some flows, for instance local mobility 345 management, might require a prefix delegation as part of the 346 handling of the movement. Segregating the delegation from the 347 binding adds a round trip delay to the recovery from the movement. 349 Binding Lifetime: It might be useful to associate implicitly the 350 lifetime of a delegated prefix with that of the binding. This 351 pleads for a design that places the Home Agent function in the 352 flow by construction. 354 Authentication Mechanism: While NEMO basic Support protects its own 355 flows, there is no mandate to secure the tunneled packets. 357 Back-end interaction: If a prefix is attributed to a MR for a 358 duration that exceeds that of its binding, this information needs 359 to be shared with all HAs, at least for authorization purposes. 360 This requires a specific backend integration that does not exist 361 in the Prefix Delegation Function, for instance via a AAA server. 363 5. Terminology and concepts 365 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 366 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 367 interpreted as described in RFC2119 [1]. 369 Most of the mobility related terms used in this document are defined 370 in the Mobility Related Terminology document [5] and in the mobile 371 IPv6 specification [6]. 373 Additionally, some terms were created or extended for NEMO. These 374 specific terms are defined in the Mobile Network Terminology document 375 [10] 377 This draft introduces the following definitions: 379 Mobile Network Prefix Request (MNPReq) Option: A new optional field 380 in the MIP6 Mobility Header for use with the binding Update 381 message, as described further in this document. This field is set 382 by a MR to request the delegation of a new prefix as a Mobile 383 Network Prefix. 385 Mobile Network Prefix Confirm (MNPConf) Option: A new optional field 386 in the MIP6 Mobility Header for use with the binding 387 Acknowledgement message, as described further in this document. 389 transient prefix: A prefix that is attributed to a Mobile Router in 390 association with a binding cache entry. If the BCE is removed, 391 the prefix is freed. 393 Persistent prefix: A prefix that is attributed to a Mobile Router 394 for a period of time that does not depend on the existence of a 395 binding cache entry. 397 6. Overview 399 6.1. New mobility Headers 401 This paper introduces a new option to the MIP6 Mobility Header, for 402 use with the binding Update message, the Mobile Network Prefix 403 Request Option. A MR may include one or more MNPReq option(s) in a 404 Binding Update message at any time, in order to obtain additional 405 prefixes. 407 This paper introduces another new option to the MIP6 Mobility Header, 408 for use with the binding Acknowledgement message, the Mobile Network 409 Prefix Confirm Option. An HA will include one or more MNPConf 410 option(s) in a Binding Acknowledgement message, either in response to 411 a Mobile Network Prefix Request Option, or for its own purposes, for 412 instance in order inform a MR of a change about the lifetime of an 413 MNP. 415 6.2. New Prefix Status bit 417 This paper finally introduces a new bit to the MIP6 Binding Update 418 and Binding Acknowledgement, the Prefix Status bit. A MR may include 419 the Prefix Status bit in a binding Update message at any time, either 420 in order to get its initial configuration, or to check whether its 421 current configuration matches that of the Home Agent - which might be 422 particularily useful in implicit mode. When the Prefix Status bit is 423 set in the BU, the Acknowledge bit MUST be set as well. 425 The HA MAY set the Prefix Status bit in the Binding Acknowledgement 426 even if it was not set by the MR in the Binding Update; the other way 427 around, if the Prefix Status bit was set in the BU, then the HA MUST 428 echo it in the BA. When setting the Prefix Status bit, the HA also 429 lists all the prefixes associated to that Mobile Router using Mobile 430 Network Prefix Confirm options. 432 6.3. Prefix lease duration 434 A prefix may be obtained for the duration of the binding; in this 435 case, the prefix is called 'transient'. On the other hand, a prefix 436 can be assigned to a MR for a duration that is independent of a BCE 437 lifecycle, and that is controlled externally by the HA administrator; 438 in that case, the prefix is called 'persistent'. 440 A flag in the MNPReq option indicates the expectation of the MR in 441 terms of persistence for the requested prefix. If the HA can not 442 fulfill that expectation, it must reject the binding with a negative 443 status. 445 The lease of a transient prefix expires with the MR Binding Cache 446 Entry; as a result, transient prefixes can be managed internally by a 447 HA, for instance using a local pool that forms an aggregation owned 448 by the HA. 450 One the other hand, some of the information about a persistent prefix 451 has to be shared between the HAs in a Home Network and the back end 452 systems that enable the authorization. This is required to allow a 453 Mobile Router to rebind, with the same persistent prefixes, to a 454 different Home Agent, after a period of inactivity. 456 It is possible to assign a persistent prefix dynamically at the time 457 of the delegation; but the persistent mode also enables the 458 preassignment of an MNP to an MR, for instance by provisionning a AAA 459 server with the necessary information for each Mobile Router. 461 6.4. Renumbering 463 It is possible to redeploy the persistent prefix space, for instance 464 if Home is being renumbered, or if a dynamically attributed prefix 465 has not been bound for a long period of time. In that case, the HA 466 rejects a new binding as the routing states can not be set up, and 467 the MR has to request one or more new persistent prefix(es). 469 6.5. backward compatibility 471 An HA that would not support this extension will ignore the 472 unrecognized option. Else, if the HA supports this draft, and if a 473 binding update with the MNPReq option can be accepted per the NEMO 474 basic support checkings: 476 6.6. PD flow 478 When a MR needs an additional prefix to populate an interface, it 479 adds an MNPreq option to its Binding update message. 481 If the HA can obtain the required prefix for that MR, it operates 482 following the NEMO basic support, either in Implicit Mode, or in 483 explicit mode using the prefixes as if they were received with the 484 BU. This includes setting up the routing states and responding with 485 a positive or a negative status. 487 If the routing states are established correctly and the HA responds 488 with a positive status, then the HA adds the prefix list to the 489 binding ack message. 491 From that point on, both the MR and the HA operate as prescribed by 492 the NEMO basic standard, either in implicit or in explicit mode. 494 7. Message Formats 496 7.1. Binding Update 498 A new flag (S) is included in the Binding Update to indicate to the 499 Home Agent that the MR wishes to get the full list of all prefixes 500 that are already assigned to it. The rest of the Binding Update 501 format remains the same as defined in [7]. 503 When the (S) bit is set, the (R) and and (A) bits MUST be set as 504 well. 506 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Sequence # | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 |A|H|L|K|M|R|S| Reserved | Lifetime | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | | 514 . . 515 . Mobility options . 516 . . 517 | | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 1: Binding Update 522 Prefix Status (S) The Prefix Status (S) bit is set by a MR to 523 request the full list of all prefixes that are already assigned to 524 it 526 7.2. Binding Acknowledgement 528 A new flag (S) is included in the Binding Acknowledgement to indicate 529 to the Mobile Router that the Home Agent provides the full list of 530 all prefixes that are already assigned to the MR. The rest of the 531 Binding Acknowledgement format remains the same as defined in [7]. 533 When the (S) bit is set, the (R) bit MUST be set as well. 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Status |K|R|S|Reserved | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Sequence # | Lifetime | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | | 543 . . 544 . Mobility options . 545 . . 546 | | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Figure 2: Binding Acknowledgement 551 Prefix Status (S) The Prefix Status (S) bit is set by a HA to 552 indicate that it provides the full list of all prefixes that are 553 already assigned to the MR. 555 7.3. Mobile Network Prefix option 557 New flags are included in the Mobile Network Prefix option defined in 558 [7]. This allows the option to cover all the prefixes owned by the 559 MR, including those that are managed using the implicit prefix mode. 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Type | Length |P|I|D|Reserved1| Prefix Length | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | | 567 + + 568 | | 569 + Mobile Network Prefix + 570 | | 571 + + 572 | | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 3: Mobile Network Prefix option 577 The new flags introduced by this specification are: 579 Persistent (P) The (P) bit is set if the prefix is expexted to be 580 persistently assigned to the MR. 582 Implicit (I) The (I) bit is set if the prefix is expexted to be 583 assigned to and routed via the MR even if the prefix is not listed 584 in explicit mode BU. 586 Delegated (D) The (D) bit is set if the prefix was obtained using a 587 the Delagation Mechanism as described in this specification. It 588 is used to acknowledge that a previously delegated prefix is 589 actually installed and routable via the Mobile Router. 591 7.4. Mobile Network Prefix request option 593 This new option is included in the Binding Update to indicate to the 594 Home Agent that the MR wishes to get a new prefix assigned to it for 595 use as a MNP. 597 When this option is present, the (S) MAY be set as well in the BU in 598 order to get the full list of all prefixes. 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type | Length | Prefix Length |P|I| Reserved1 | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | CorID | Reserved2 | Prefix type | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Figure 4: Mobile Network Prefix request option 610 Type TBA 612 Length 8 bit unsigned integer indicating the length in octets of the 613 option excluding the type and length fields. Set to 6. 615 Prefix Length 8 bit unsigned integer indicating the prefix length of 616 the IPv6 prefix contained in the option. 618 Persistent (P) The (P) bit is set if the prefix that is requested to 619 expected to be persistently assigned to the MR. 621 Implicit (I) The (I) bit is set if the prefix that is requested to 622 expected to be assigned to, and routed via the MR, even if the 623 prefix is not listed in explicit mode BU. 625 CorId A Correlator that is set by the MR in order to associate a MNP 626 request with the prefix given in the confirm. There can be at 627 most one active prefix associated with each Correlator. This 628 mechanism ensure the unicity of the allocation of a prefix, should 629 aither the BU or the BA be lost in the way. 631 Prefix Type Indicates the type of prefix that is requested: 633 0 None Specified 635 2 Unique Local 637 3 Global 639 7.5. Mobile Network Prefix Confirm option 641 This new option is included in the Binding Update to indicate to the 642 Home Agent that the MR wishes to get a new prefix assigned to it for 643 use as a MNP. 645 When this option is present, the (S) MAY be set as well in the BU in 646 order to get the full list of all prefixes. 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Type | Length | Prefix Length |P|I|D|Reserved1| 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | CorID | Reserved2 | Prefix type | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Valid Lifetime | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | | 658 + + 659 | | 660 + Mobile Network Prefix + 661 | | 662 + + 663 | | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Figure 5: Mobile Network Prefix Confirm option 668 Type TBA 670 Length 8 bit unsigned integer indicating the length in octets of the 671 option excluding the type and length fields. Set to 26. 673 Prefix Length 8 bit unsigned integer indicating the prefix length of 674 the IPv6 prefix contained in the option. 676 Persistent (P) The (P) bit is set if the prefix is persistently 677 assigned to the MR. 679 Implicit (I) The (I) bit is set if the prefix is assigned to and 680 routed via the MR even if the prefix is not listed in explicit 681 mode BU. 683 Delegated (D) The (D) bit is set if the prefix was obtained using a 684 the Delagation Mechanism as described in this specification. 686 CorId If the (D) bit is set, the Correlator that was set by the MR 687 in an MNPReq and this option contains the prefix that is being 688 delegated in response to that Request. If the (D) bit is not set, 689 the Correlator value is defined by the HA. 691 Prefix Type Indicates the type of prefix that is requested: 693 0 None Specified 695 2 Unique Local 697 3 Global 699 Valid Lifetime 32-bit unsigned integer. The length of time in 700 seconds (relative to the time the packet is sent) that the prefix 701 is valid for being installed on an MR ingress interface. A value 702 of all one bits (0xffffffff) represents infinity. The Valid 703 Lifetime is also used by RFC2461 [2] and RFC2462 [3], and must be 704 used in the RAs sent over the MR ingress interface for that 705 prefix. 707 Mobile Network Prefix A 16 byte field contains the Mobile Network 708 Prefix. 710 8. Security Considerations 712 This protocol extension is protected by the mechanisms defined for 713 Mobile IPv6 and NEMO Basic Support. It is designed for use between a 714 Home Agent and a Mobile Router, so the threats introduced by the 715 Route Optimization process do not apply. 717 9. IANA Considerations 719 The specification requires the following allocations from IANA: 721 The Mobile Network Prefix Request option described in Section 7.4 722 requires a new option type. This option is included in the 723 Mobility header described in Mobile IPv6 [6] . 725 The Mobile Network Prefix Confirm option described in Section 7.5 726 requires a new option type. This option is included in the 727 Mobility header described in Mobile IPv6 [6]. 729 10. Acknowledgements 731 The authors wish to thank: 733 Pekka Paakkonen and Juhani Latvakoski from VTT Electronics for their 734 initial work on the matter. Hesham Soliman for his suggestion to 735 couple PD with NAI. 737 11. References 739 11.1. Normative Reference 741 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 742 Levels", BCP 14, RFC 2119, March 1997. 744 [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 745 for IP Version 6 (IPv6)", RFC 2461, December 1998. 747 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 748 Autoconfiguration", RFC 2462, December 1998. 750 [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 751 Configuration Protocol (DHCP) version 6", RFC 3633, 752 December 2003. 754 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 755 RFC 3753, June 2004. 757 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 758 IPv6", RFC 3775, June 2004. 760 [7] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 761 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 762 January 2005. 764 [8] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 765 Access Identifier", RFC 4282, December 2005. 767 [9] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 768 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 769 RFC 4283, November 2005. 771 [10] Ernst, T. and H-Y. Lach, "Network Mobility Support 772 Terminology", RFC 4885, July 2007. 774 11.2. Informative Reference 776 [11] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 777 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 779 [12] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network 780 Mobility Home Network Models", RFC 4887, July 2007. 782 Authors' Addresses 784 Pascal Thubert 785 Cisco Systems 786 Village d'Entreprises Green Side 787 400, Avenue de Roumanille 788 Batiment T3 789 Biot - Sophia Antipolis 06410 790 FRANCE 792 Phone: +33 4 97 23 26 34 793 Email: pthubert@cisco.com 795 T.J. Kniveton 796 Nokia, Inc. 797 313 Fairchild Dr. 798 Building B-223 799 Mountain View 94043 800 USA 802 Phone: +1 650 625 2025 803 Email: tj@kniveton.com 805 Full Copyright Statement 807 Copyright (C) The IETF Trust (2007). 809 This document is subject to the rights, licenses and restrictions 810 contained in BCP 78, and except as set forth therein, the authors 811 retain all their rights. 813 This document and the information contained herein are provided on an 814 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 815 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 816 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 817 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 818 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 819 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 821 Intellectual Property 823 The IETF takes no position regarding the validity or scope of any 824 Intellectual Property Rights or other rights that might be claimed to 825 pertain to the implementation or use of the technology described in 826 this document or the extent to which any license under such rights 827 might or might not be available; nor does it represent that it has 828 made any independent effort to identify any such rights. Information 829 on the procedures with respect to rights in RFC documents can be 830 found in BCP 78 and BCP 79. 832 Copies of IPR disclosures made to the IETF Secretariat and any 833 assurances of licenses to be made available, or the result of an 834 attempt made to obtain a general license or permission for the use of 835 such proprietary rights by implementers or users of this 836 specification can be obtained from the IETF on-line IPR repository at 837 http://www.ietf.org/ipr. 839 The IETF invites any interested party to bring to its attention any 840 copyrights, patents or patent applications, or other proprietary 841 rights that may cover technology that may be required to implement 842 this standard. Please address the information to the IETF at 843 ietf-ipr@ietf.org. 845 Acknowledgment 847 Funding for the RFC Editor function is provided by the IETF 848 Administrative Support Activity (IASA).