idnits 2.17.1 draft-ietf-nemo-prefix-delegation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 837. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 ([9]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (November 17, 2006) is 6367 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) == Unused Reference: '2' is defined on line 744, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 753, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 770, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 774, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '4') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3513 (ref. '5') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3633 (ref. '6') (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '7') ** Obsolete normative reference: RFC 3775 (ref. '8') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4285 (ref. '11') ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '12') Summary: 13 errors (**), 0 flaws (~~), 7 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: May 21, 2007 TJ. Kniveton 5 Nokia 6 November 17, 2006 8 Mobile Network Prefix Delegation 9 draft-ietf-nemo-prefix-delegation-01.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 May 21, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This paper extends the Nemo Basic Support [9] for a Mobile Router to 43 synchronize its Mobile Network Prefixes with its Home Agents and 44 obtain new ones dynamically. 46 The proposed prefix delegation mechanism is agnostic to the way the 47 back end is implemented; it enables bootstrapping, resynchronization 48 at binding creation or after a loss of states (eg MR reboot), MNP 49 Renumbering, and configuration checking for loop avoidance. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. motivation for a NEMO prefix delegation . . . . . . . . . . . 3 55 2.1 Configuration management . . . . . . . . . . . . . . . . . 4 56 2.2 Provisioning . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4 The NEMO bootstrap problem . . . . . . . . . . . . . . . . 4 59 2.5 Local Mobility Management . . . . . . . . . . . . . . . . 5 60 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1 Which capabilities? . . . . . . . . . . . . . . . . . . . 6 63 4.1.1 Prefix Request capability . . . . . . . . . . . . . . 6 64 4.1.2 Full prefix list capability for HA . . . . . . . . . . 6 65 4.1.3 Full prefix list capability for MR . . . . . . . . . . 7 66 4.2 Rationale for new Binding options . . . . . . . . . . . . 7 67 4.3 Rationale for a new bit in the BU . . . . . . . . . . . . 7 68 4.4 Why not Alternate standard based solutions? . . . . . . . 7 69 5. Terminology and concepts . . . . . . . . . . . . . . . . . . . 9 70 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.1 New mobility Headers . . . . . . . . . . . . . . . . . . . 10 72 6.2 New Prefix Status bit . . . . . . . . . . . . . . . . . . 10 73 6.3 Prefix lease duration . . . . . . . . . . . . . . . . . . 10 74 6.4 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.5 backward compatibility . . . . . . . . . . . . . . . . . . 11 76 6.6 PD flow . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 78 7.1 Binding Update . . . . . . . . . . . . . . . . . . . . . . 12 79 7.2 Binding Acknowledgement . . . . . . . . . . . . . . . . . 13 80 7.3 Mobile Network Prefix option . . . . . . . . . . . . . . . 14 81 7.4 Mobile Network Prefix request option . . . . . . . . . . . 15 82 7.5 Mobile Network Prefix Confirm option . . . . . . . . . . . 17 83 8. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 19 84 9. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 20 85 10. Back End considerations . . . . . . . . . . . . . . . . . . 21 86 11. Security Considerations . . . . . . . . . . . . . . . . . . 22 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 88 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 14.1 Normative Reference . . . . . . . . . . . . . . . . . . . 23 91 14.2 Informative Reference . . . . . . . . . . . . . . . . . . 24 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 93 Intellectual Property and Copyright Statements . . . . . . . . 25 95 1. Introduction 97 The reader of that document is expected to be familiar with both the 98 Mobile IPv6 [8] and NEMO Basic Support [9] documents. As such, it is 99 well-understood that neither protocol provides the means for 100 provisioning the Mobile Nodes and Routers with essential parameters 101 such as Home Address and Home Network. 103 The process by which a router obtains a prefix dynamically is called 104 prefix delegation. In the NEMO context, the prefix is managed by an 105 authority than owns the Home Network and subnets it into MNPs that it 106 assigns to the MRs. An MNP can be preassigned to the associated MR 107 (e.g. manually or automatically with a provisionning system), or 108 assigned dynamically by a server such as a DHCP Prefix Delegation 109 server. 111 As prescribed by [9], the HA checks whether a MR is authorized for 112 the MNPs it claims as part of the NEMO Binding Update with the 113 explicit prefix option. Also, MNPs have to belong to an aggregation 114 that is permanently advertised be the HA to the routing 115 infrastruture. Consequently, there is a strong relationship between 116 the HA that the MR registers to and the prefixes it claims with the 117 registration, and it makes sense for the HA to participate actively 118 to the delegation process as well. 120 [9] standardizes an interface between a Mobile Router and its Home 121 Agent, as well as an interface between Home Agents. The protocol is 122 agnostic as to how the back end is implemented in terms of AAA, 123 provisioning, or routing between the HAs and their IGP, and enables 124 various forms of deployment, as described in [14]. 126 In a same fashion, the document extends [9] for a Mobile Router to 127 obtain its Mobile Network Prefix dynamically from its Home Agent, 128 with no assumption about the specific back-end implementation for 129 prefix management and service authorization. 131 2. motivation for a NEMO prefix delegation 133 A number of reasons plead for adding this capability to NEMO NEMO 134 Basic Support [9]. 136 Mainly, there is an unanswered question as to how a MR could be 137 dynamically assigned its prefix. In a situation where a site has 138 many MRs, it may be impractical to assign the prefixes statically in 139 the non-volatile memory of the MR. Consequently, we would like a 140 mechanism for the HA to assign the prefix, similar to how a MN can 141 bootstrap its Home Address. 143 2.1 Configuration management 145 The Implicit Mode of the NEMO Basic Support 'externalizes' the 146 configuration of the MNPs in a MR and its HA. In the example of a 147 static configuration, both side are initially provisioned with the 148 association between the MRs and their MNPs, and maintain matching 149 states between them. 151 The failure to configure and maintain these matching states overtime 152 ends up in routing loops and unreachable prefixes. Tools for 153 synchronizing MNPs in runtime would be a valuable addition to [9]. 155 2.2 Provisioning 157 In practice, provisioning both sides manually is error-prone and 158 should be avoided. It can not be taken for granted, either, that in 159 all cases, a provisioning system can be deployed with the capability 160 to configure both the Mobile Router and the back-end in a 161 transactional manner. Consequently, it appears necessary to provide 162 a way to configure one side only, and have the other side learn from 163 it in a trusted fashion and with no additional manual intervention. 165 The Explicit Prefix mode enables a flow where the configuration of 166 that association is not centralized at the HA but distributed to all 167 the MRs. In fact, the HA is required to validate that the MR has 168 been authorized for the MNPs it claims and then again, some level of 169 information duplication might occur. 171 In the general case, it may be easier to manage the prefix 172 attribution in a centralized manner and have the MRs learn their 173 prefixes dynamically. 175 2.3 Renumbering 177 The concept of lifetime is one core idea with IPv6. Nothing is 178 eternal. Overtime, it might be desirable to modify the configuration 179 of the MNPs. This task, called renumbering, is especially difficult 180 for Mobile Routers when they are geographically distributed and not 181 be readily available to the administrators. 183 It is thus desirable to extend [9] with a renumbering mechanism. In 184 particular, it makes sense to provide that extension within the 185 prefix delegation mechanism, since the operations that take place are 186 vastly similar. 188 2.4 The NEMO bootstrap problem 190 Nemo basic support expects a Mobile router to be provisioned with 191 some information in order to start up - Home Network or Home Agent 192 address, Home Address, Mobile Network Prefixes, security tokens, 193 etc... 195 In some situations, it may be impractical to actually provision all 196 this information into the router at deployment time, and some of it 197 has to be obtained dynamically when a system boots up, possibly 198 through manually keying by the final user. 200 It is absolutely required to reduce such manual keying of information 201 to the bare minimum, like a user ID and password. And while NEMO can 202 benefit from the MIP6 effort on the bootstrap problem (as described 203 in the MIP6 bootstrap problem statement document [13]) for most 204 parameters, the dynamic provisionning of Mobile Network Prefix(es) is 205 not considered by MIPv6. 207 2.5 Local Mobility Management 209 In turn, the bootstrap problem is linked to the Local Mobility 210 Management problem; some LMM solutions such as HMIP deploy regional 211 Home Agents from which bootstrap information has to be obtained when 212 moving into their area of coverage; as opposed to the initial 213 bootstrap problem which occurs at the first startup of a device and 214 may not happen again for an extensive period of time, LMM is tied to 215 movement, and could be quite frequent. 217 3. Requirements 219 There is thus a need for a Mobile Router to obtain dynamically one or 220 more MNPs, linked to the HA that the MR binds with. 222 Since the process may be used as part of a mobility scenario, there 223 is also a need to optimize the delegation flow by limiting the number 224 of protocol exchanges that take place for delegation and 225 registration. 227 Since the initial configuration may be erroneous or may need to 228 evolve overtime, there is a need to manage the MNPs on a Mobile 229 Router. This includes initial setting up, and synchronizing 230 overtime. 232 4. Rationale 234 This section details the rationale behind some of the design 235 decisions that lead to this solution. 237 4.1 Which capabilities? 239 4.1.1 Prefix Request capability 241 The minimum capability that could be envisionned for a NEMO Prefix 242 Delegation mechanism is for a MR to request for a new prefix in a 243 Binding Update and for the HA to provide the prefix as part of the 244 Binding Acknowledgement. Then the Mobile Router installs the newly 245 obtained prefix on the interface that needs it, and moves forward in 246 implicit or explicit mode. 248 4.1.2 Full prefix list capability for HA 250 The capability to request a new prefix is sufficient in a basic 251 delegation flow where a MR that is already bound and -hopefully- 252 synchronized with its HA in terms of prefix ownership; it is also 253 required in some bootstrapping and renumbering flows; but it is 254 hardly sufficient in order to synchronize the MR and the HA states 255 regarding MNPs: 257 Bootstrapping: At bootstrapping time, the MR needs the list of all 258 the prefixes that are attributed in order to populate its 259 interfaces. Asking them one by one and having to make a 260 distinction between already allocated prefixes versus dynamic 261 allocation would make the flow much more complex. 263 Expired prefixes: That list is also needed for a MR in order to 264 synchronize its current configuration with that of the HA. In 265 particular, it is used for a MR to discover when the HA does not 266 have the associated states in place for one of its MNPs. This may 267 happen for some configuration error or because the prefix has 268 expired, and the only way to know is if the prefix is missing in a 269 full list of all prefixes by the HA. 271 Newly allocated prefixes: Finally, the list is needed for a MR to 272 learn new prefixes that would be attributed in runtime, and to 273 install those prefixes on its interfaces. Once the new prefixes 274 are installed, it is required that the MR confirms its use of the 275 prefixes so that the HA can set up routing in a loopfree fashion. 277 So the capability for a HA to list all the prefixes for a MR is 278 needed for the MR to realize that the HA is missing some states and 279 eventually to try to get the missing prefixes in explicit mode. This 280 may happen on demand by the MR (e.g. at bootstrap time or binding 281 creation time), or whenever the HA needs to communicate about a 282 change, such as a shortened or expired MNP lifetime. 284 4.1.3 Full prefix list capability for MR 286 So the capability for a HA to list all the prefixes is not sufficient 287 is the HA is not the repository of that knowledge. It might be 288 simpler for the MR to dump its own list of prefixes and have the HA 289 check the list, even for implicit prefixes. 291 4.2 Rationale for new Binding options 293 Associated to the capability to request a new prefix, it seems 294 relevant to specify whether the prefix is for implicit or explicit 295 mode, or if its lifetime is limited with that of the binding cache or 296 not. Other fields such as the prefix length are needed as well. In 297 order to convey that information, an optional field is needed in the 298 BU. 300 It is not desirable to extend the existing NEMO MNP option, which 301 carries a prefix that is not needed, though. As a result, we propose 302 a new option type, the MNP request option. 304 Associated to the capability for a HA to list all the prefixes for a 305 MR, one critical information is needed, that would not fit in the 306 NEMO MNP option. Again, we propose a new option for the Binding 307 Acknowledgement, the MNP confirm option. 309 4.3 Rationale for a new bit in the BU 311 A single bit in the BU is enough for a MR to request a full list of 312 prefixes from the HA, if we do not need a filter of any sort???? 314 It is important that the HA set that bit in its full list of prefixes 315 in order to differentiate between an empty list (there's no prefix 316 for that MR) and no list (HA is not providing a list in that BA). 318 4.4 Why not Alternate standard based solutions? 320 Proposing a new, specific solution might seem irrelevant when a 321 standard, generic mechanism already exist, in this case the DHCPv6 322 Prefix Delegation. In fact, it is possible for the Home Agent to act 323 as a DHCPv6PD Delegating Router. This solution presents the 324 advantage of reusing existing standard flows from RFC3633 [6]. 326 Yet, in a deployment where the MNPs are preassigned to the MR, a AAA 327 server, interfacing with the HA, and eventually coupled with a 328 provisioning system in its back end, can provide the required service 329 for assigning and authorizing the prefixes to the MRs; in such a 330 case, the value of implementing a DHCPv6PD server is highly arguable. 331 It is more generic to let the HA handle the backend interfaces on 332 behalf of the MR and expose a consistent NEMO interface for all 333 deployments. 335 In more details, a DHCPv6PD based solution presents a number of 336 inconveniences: 338 Delegating Router: A collocated Delegating Router function may not be 339 available for all implementation of NEMO Home Agent. In 340 particular, some implementations are server based. 342 Operational overhead: Depending on the mechanism that is used to 343 attribute the MNPs to the MRs, the Delegating function, even if 344 available, might be a costly overhead. Rather, an embedded, back- 345 end agnostic flow might be a desirable option. 347 Movement overhead: Some flows, for instance local mobility 348 management, might require a prefix delegation as part of the 349 handling of the movement. Segregating the delegation from the 350 binding adds a round trip delay to the recovery from the movement. 352 Binding Lifetime: It might be useful to associate implicitly the 353 lifetime of a delegated prefix with that of the binding. This 354 pleads for a design that places the Home Agent function in the 355 flow by construction. 357 Authentication Mechanism: While NEMO basic Support protects its own 358 flows, there is no mandate to secure the tunneled packets. 360 Back-end interaction: If a prefix is attributed to a MR for a 361 duration that exceeds that of its binding, this information needs 362 to be shared with all HAs, at least for authorization purposes. 363 This requires a specific backend integration that does not exist 364 in the Prefix Delegation Function, for instance via a AAA server. 366 5. Terminology and concepts 368 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 369 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 370 interpreted as described in RFC2119 [1]. 372 Most of the mobility related terms used in this document are defined 373 in the Mobility Related Terminology document [7] and in the mobile 374 IPv6 specification [8]. 376 Additionally, some terms were created or extended for NEMO. These 377 specific terms are defined in the Mobile Network Terminology document 378 [12] 380 This draft introduces the following definitions: 382 Mobile Network Prefix Request (MNPReq) Option: A new optional field 383 in the MIP6 Mobility Header for use with the binding Update 384 message, as described further in this document. This field is set 385 by a MR to request the delegation of a new prefix as a Mobile 386 Network Prefix. 388 Mobile Network Prefix Confirm (MNPConf) Option: A new optional field 389 in the MIP6 Mobility Header for use with the binding 390 Acknowledgement message, as described further in this document. 392 transient prefix: A prefix that is attributed to a Mobile Router in 393 association with a binding cache entry. If the BCE is removed, 394 the prefix is freed. 396 Persistent prefix: A prefix that is attributed to a Mobile Router for 397 a period of time that does not depend on the existence of a 398 binding cache entry. 400 6. Overview 402 6.1 New mobility Headers 404 This paper introduces a new option to the MIP6 Mobility Header, for 405 use with the binding Update message, the Mobile Network Prefix 406 Request Option. A MR may include one or more MNPReq option(s) in a 407 Binding Update message at any time, in order to obtain additional 408 prefixes. 410 This paper introduces another new option to the MIP6 Mobility Header, 411 for use with the binding Acknowledgement message, the Mobile Network 412 Prefix Confirm Option. An HA will include one or more MNPConf 413 option(s) in a Binding Acknowledgement message, either in response to 414 a Mobile Network Prefix Request Option, or for its own purposes, for 415 instance in order inform a MR of a change about the lifetime of an 416 MNP. 418 6.2 New Prefix Status bit 420 This paper finally introduces a new bit to the MIP6 Binding Update 421 and Binding Acknowledgement, the Prefix Status bit. A MR may include 422 the Prefix Status bit in a binding Update message at any time, either 423 in order to get its initial configuration, or to check whether its 424 current configuration matches that of the Home Agent - which might be 425 particularily useful in implicit mode. When the Prefix Status bit is 426 set in the BU, the Acknowledge bit MUST be set as well. 428 The HA MAY set the Prefix Status bit in the Binding Acknowledgement 429 even if it was not set by the MR in the Binding Update; the other way 430 around, if the Prefix Status bit was set in the BU, then the HA MUST 431 echo it in the BA. When setting the Prefix Status bit, the HA also 432 lists all the prefixes associated to that Mobile Router using Mobile 433 Network Prefix Confirm options. 435 6.3 Prefix lease duration 437 A prefix may be obtained for the duration of the binding; in this 438 case, the prefix is called 'transient'. On the other hand, a prefix 439 can be assigned to a MR for a duration that is independent of a BCE 440 lifecycle, and that is controlled externally by the HA administrator; 441 in that case, the prefix is called 'persistent'. 443 A flag in the MNPReq option indicates the expectation of the MR in 444 terms of persistence for the requested prefix. If the HA can not 445 fulfill that expectation, it must reject the binding with a negative 446 status. 448 The lease of a transient prefix expires with the MR Binding Cache 449 Entry; as a result, transient prefixes can be managed internally by a 450 HA, for instance using a local pool that forms an aggregation owned 451 by the HA. 453 One the other hand, some of the information about a persistent prefix 454 has to be shared between the HAs in a Home Network and the back end 455 systems that enable the authorization. This is required to allow a 456 Mobile Router to rebind, with the same persistent prefixes, to a 457 different Home Agent, after a period of inactivity. 459 It is possible to assign a persistent prefix dynamically at the time 460 of the delegation; but the persistent mode also enables the 461 preassignment of an MNP to an MR, for instance by provisionning a AAA 462 server with the necessary information for each Mobile Router. 464 6.4 Renumbering 466 It is possible to redeploy the persistent prefix space, for instance 467 if Home is being renumbered, or if a dynamically attributed prefix 468 has not been bound for a long period of time. In that case, the HA 469 rejects a new binding as the routing states can not be set up, and 470 the MR has to request one or more new persistent prefix(es). 472 6.5 backward compatibility 474 An HA that would not support this extension will ignore the 475 unrecognized option. Else, if the HA supports this draft, and if a 476 binding update with the MNPReq option can be accepted per the NEMO 477 basic support checkings: 479 6.6 PD flow 481 When a MR needs an additional prefix to populate an interface, it 482 adds an MNPreq option to its Binding update message. 484 If the HA can obtain the required prefix for that MR, it operates 485 following the NEMO basic support, either in Implicit Mode, or in 486 explicit mode using the prefixes as if they were received with the 487 BU. This includes setting up the routing states and responding with 488 a positive or a negative status. 490 If the routing states are established correctly and the HA responds 491 with a positive status, then the HA adds the prefix list to the 492 binding ack message. 494 From that point on, both the MR and the HA operate as prescribed by 495 the NEMO basic standard, either in implicit or in explicit mode. 497 7. Message Formats 499 7.1 Binding Update 501 A new flag (S) is included in the Binding Update to indicate to the 502 Home Agent that the MR wishes to get the full list of all prefixes 503 that are already assigned to it. The rest of the Binding Update 504 format remains the same as defined in [9]. 506 When the (S) bit is set, the (R) and and (A) bits MUST be set as 507 well. 509 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Sequence # | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 |A|H|L|K|M|R|S| Reserved | Lifetime | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | | 517 . . 518 . Mobility options . 519 . . 520 | | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 1: Binding Update 525 Prefix Status (S) The Prefix Status (S) bit is set by a MR to request 526 the full list of all prefixes that are already assigned to it 528 7.2 Binding Acknowledgement 530 A new flag (S) is included in the Binding Acknowledgement to indicate 531 to the Mobile Router that the Home Agent provides the full list of 532 all prefixes that are already assigned to the MR. The rest of the 533 Binding Acknowledgement format remains the same as defined in [9]. 535 When the (S) bit is set, the (R) bit MUST be set as well. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Status |K|R|S|Reserved | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Sequence # | Lifetime | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | | 545 . . 546 . Mobility options . 547 . . 548 | | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Figure 2: Binding Acknowledgement 553 Prefix Status (S) The Prefix Status (S) bit is set by a HA to 554 indicate that it provides the full list of all prefixes that are 555 already assigned to the MR. 557 7.3 Mobile Network Prefix option 559 New flags are included in the Mobile Network Prefix option defined in 560 [9]. This allows the option to cover all the prefixes owned by the 561 MR, including those that are managed using the implicit prefix mode. 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Type | Length |P|I|D|Reserved1| Prefix Length | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | | 569 + + 570 | | 571 + Mobile Network Prefix + 572 | | 573 + + 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Figure 3: Mobile Network Prefix option 579 The new flags introduced by this specification are: 581 Persistent (P) The (P) bit is set if the prefix is expexted to be 582 persistently assigned to the MR. 584 Implicit (I) The (I) bit is set if the prefix is expexted to be 585 assigned to and routed via the MR even if the prefix is not listed 586 in explicit mode BU. 588 Delegated (D) The (D) bit is set if the prefix was obtained using a 589 the Delagation Mechanism as described in this specification. It 590 is used to acknowledge that a previously delegated prefix is 591 actually installed and routable via the Mobile Router. 593 7.4 Mobile Network Prefix request option 595 This new option is included in the Binding Update to indicate to the 596 Home Agent that the MR wishes to get a new prefix assigned to it for 597 use as a MNP. 599 When this option is present, the (S) MAY be set as well in the BU in 600 order to get the full list of all prefixes. 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Type | Length | Prefix Length |P|I| Reserved1 | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | CorID | Reserved2 | Prefix type | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Figure 4: Mobile Network Prefix request option 612 Type TBA 614 Length 8 bit unsigned integer indicating the length in octets of the 615 option excluding the type and length fields. Set to 6. 617 Prefix Length 8 bit unsigned integer indicating the prefix length of 618 the IPv6 prefix contained in the option. 620 Persistent (P) The (P) bit is set if the prefix that is requested to 621 expected to be persistently assigned to the MR. 623 Implicit (I) The (I) bit is set if the prefix that is requested to 624 expected to be assigned to, and routed via the MR, even if the 625 prefix is not listed in explicit mode BU. 627 CorId A Correlator that is set by the MR in order to associate a MNP 628 request with the prefix given in the confirm. There can be at 629 most one active prefix associated with each Correlator. This 630 mechanism ensure the unicity of the allocation of a prefix, should 631 aither the BU or the BA be lost in the way. 633 Prefix Type Indicates the type of prefix that is requested: 635 0 None Specified 637 2 Unique Local 639 3 Global 641 7.5 Mobile Network Prefix Confirm option 643 This new option is included in the Binding Update to indicate to the 644 Home Agent that the MR wishes to get a new prefix assigned to it for 645 use as a MNP. 647 When this option is present, the (S) MAY be set as well in the BU in 648 order to get the full list of all prefixes. 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Type | Length | Prefix Length |P|I|D|Reserved1| 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | CorID | Reserved2 | Prefix type | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Valid Lifetime | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | | 660 + + 661 | | 662 + Mobile Network Prefix + 663 | | 664 + + 665 | | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Figure 5: Mobile Network Prefix Confirm option 670 Type TBA 672 Length 8 bit unsigned integer indicating the length in octets of the 673 option excluding the type and length fields. Set to 26. 675 Prefix Length 8 bit unsigned integer indicating the prefix length of 676 the IPv6 prefix contained in the option. 678 Persistent (P) The (P) bit is set if the prefix is persistently 679 assigned to the MR. 681 Implicit (I) The (I) bit is set if the prefix is assigned to and 682 routed via the MR even if the prefix is not listed in explicit 683 mode BU. 685 Delegated (D) The (D) bit is set if the prefix was obtained using a 686 the Delagation Mechanism as described in this specification. 688 CorId If the (D) bit is set, the Correlator that was set by the MR in 689 an MNPReq and this option contains the prefix that is being 690 delegated in response to that Request. If the (D) bit is not set, 691 the Correlator value is defined by the HA. 693 Prefix Type Indicates the type of prefix that is requested: 695 0 None Specified 697 2 Unique Local 699 3 Global 701 Valid Lifetime 32-bit unsigned integer. The length of time in 702 seconds (relative to the time the packet is sent) that the prefix 703 is valid for being installed on an MR ingress interface. A value 704 of all one bits (0xffffffff) represents infinity. The Valid 705 Lifetime is also used by RFC2461 [3] and RFC2462 [4], and must be 706 used in the RAs sent over the MR ingress interface for that 707 prefix. 709 Mobile Network Prefix A 16 byte field contains the Mobile Network 710 Prefix. 712 8. Mobile Router Operation 713 9. Home Agent Operation 714 10. Back End considerations 715 11. Security Considerations 717 12. 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 [8] . 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 [8]. 729 13. 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 14. References 739 14.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] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 745 Specification", RFC 2460, December 1998. 747 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 748 for IP Version 6 (IPv6)", RFC 2461, December 1998. 750 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 751 Autoconfiguration", RFC 2462, December 1998. 753 [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 754 Addressing Architecture", RFC 3513, April 2003. 756 [6] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 757 Configuration Protocol (DHCP) version 6", RFC 3633, 758 December 2003. 760 [7] Manner, J. and M. Kojo, "Mobility Related Terminology", 761 RFC 3753, June 2004. 763 [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 764 IPv6", RFC 3775, June 2004. 766 [9] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 767 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 768 January 2005. 770 [10] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 771 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 772 RFC 4283, November 2005. 774 [11] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 775 "Authentication Protocol for Mobile IPv6", RFC 4285, 776 January 2006. 778 [12] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 779 draft-ietf-nemo-terminology-06 (work in progress), 780 November 2006. 782 14.2 Informative Reference 784 [13] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 785 Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in 786 progress), May 2006. 788 [14] Thubert, P., "NEMO Home Network models", 789 draft-ietf-nemo-home-network-models-06 (work in progress), 790 February 2006. 792 Authors' Addresses 794 Pascal Thubert 795 Cisco Systems 796 Village d'Entreprises Green Side 797 400, Avenue de Roumanille 798 Batiment T3 799 Biot - Sophia Antipolis 06410 800 FRANCE 802 Phone: +33 4 97 23 26 34 803 Email: pthubert@cisco.com 805 T.J. Kniveton 806 Nokia, Inc. 807 313 Fairchild Dr. 808 Building B-223 809 Mountain View 94043 810 USA 812 Phone: +1 650 625 2025 813 Email: tj@kniveton.com 815 Intellectual Property Statement 817 The IETF takes no position regarding the validity or scope of any 818 Intellectual Property Rights or other rights that might be claimed to 819 pertain to the implementation or use of the technology described in 820 this document or the extent to which any license under such rights 821 might or might not be available; nor does it represent that it has 822 made any independent effort to identify any such rights. Information 823 on the procedures with respect to rights in RFC documents can be 824 found in BCP 78 and BCP 79. 826 Copies of IPR disclosures made to the IETF Secretariat and any 827 assurances of licenses to be made available, or the result of an 828 attempt made to obtain a general license or permission for the use of 829 such proprietary rights by implementers or users of this 830 specification can be obtained from the IETF on-line IPR repository at 831 http://www.ietf.org/ipr. 833 The IETF invites any interested party to bring to its attention any 834 copyrights, patents or patent applications, or other proprietary 835 rights that may cover technology that may be required to implement 836 this standard. Please address the information to the IETF at 837 ietf-ipr@ietf.org. 839 Disclaimer of Validity 841 This document and the information contained herein are provided on an 842 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 843 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 844 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 845 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 846 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 847 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 849 Copyright Statement 851 Copyright (C) The Internet Society (2006). This document is subject 852 to the rights, licenses and restrictions contained in BCP 78, and 853 except as set forth therein, the authors retain all their rights. 855 Acknowledgment 857 Funding for the RFC Editor function is currently provided by the 858 Internet Society.