idnits 2.17.1 draft-kniveton-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 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 936. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 949. ** 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 58 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([10]), 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 == Line 264 has weird spacing: '...uration with ...' == Line 322 has weird spacing: '..., it is possi...' == Line 338 has weird spacing: '...ion may not...' == Line 343 has weird spacing: '...egating funct...' == 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 (July 17, 2005) is 6856 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 867, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 876, 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) == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-bootstrap-ps (ref. '9') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-home-network-models-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-home-network-models (ref. '11') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '12') Summary: 17 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Mobility T. Kniveton 3 Internet-Draft Nokia 4 Expires: January 18, 2006 P. Thubert 5 Cisco 6 July 17, 2005 8 Mobile Network Prefix Delegation 9 draft-kniveton-nemo-prefix-delegation-01 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 January 18, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This paper extends the Nemo Basic Support [10] 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 prefixes are managed and 46 provisioned at the Home Agent; it might be used for bootstrapping, 47 resynchronization at binding creation or after a loss of states (eg 48 MR reboot), MNP Renumbering, and configuration checking for loop 49 avoidance. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Motivation for NEMO prefix delegation . . . . . . . . . . . . 3 55 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2 Configuration Management . . . . . . . . . . . . . . . . . 4 57 2.3 Provisioning . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.5 The NEMO bootstrap problem . . . . . . . . . . . . . . . . 5 60 2.6 Local Mobility Management . . . . . . . . . . . . . . . . 5 61 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1 Which capabilities? . . . . . . . . . . . . . . . . . . . 6 63 3.1.1 Prefix Request capability . . . . . . . . . . . . . . 6 64 3.1.2 Full prefix list capability for HA . . . . . . . . . . 6 65 3.1.3 Full prefix list capability for MR . . . . . . . . . . 7 66 3.2 Rationale for New Binding Options . . . . . . . . . . . . 7 67 3.3 Rationale for a new bit in the BU . . . . . . . . . . . . 7 68 3.4 Why not Alternate Standard-based Solutions? . . . . . . . 7 69 4. Terminology and concepts . . . . . . . . . . . . . . . . . . . 9 70 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.1 New Mobility Headers . . . . . . . . . . . . . . . . . . . 10 72 5.2 New Prefix Status bit . . . . . . . . . . . . . . . . . . 10 73 5.3 Prefix Lease Duration . . . . . . . . . . . . . . . . . . 10 74 5.4 Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 11 75 5.5 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.6 Backward Compatibility . . . . . . . . . . . . . . . . . . 12 77 5.7 Basic PD flow . . . . . . . . . . . . . . . . . . . . . . 12 78 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.1 Binding Update . . . . . . . . . . . . . . . . . . . . . . 13 80 6.2 Binding Acknowledgement . . . . . . . . . . . . . . . . . 14 81 6.3 Mobile Network Prefix option . . . . . . . . . . . . . . . 15 82 6.4 Mobile Network Prefix Request option . . . . . . . . . . . 16 83 6.5 Mobile Network Prefix Confirmation option . . . . . . . . 18 84 7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 21 85 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22 86 9. Back End considerations . . . . . . . . . . . . . . . . . . . 23 87 10. Security Considerations . . . . . . . . . . . . . . . . . . 24 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 91 Intellectual Property and Copyright Statements . . . . . . . . 27 93 1. Introduction 95 The reader of that document is expected to be familiar with both the 96 Mobile IPv6 [8] and NEMO Basic Support [10] documents. As such, it 97 is well understood that neither protocol provides the means for 98 provisioning the Mobile Nodes and Routers with essential parameters 99 such as Home Address and Home Network. 101 The process by which a router obtains a prefix dynamically is called 102 prefix delegation. In the NEMO context, the prefix assignment is 103 managed by an authority in the Home Network and divides it into 104 subnets for MNPs, which are then assigned to the MRs. An MNP can be 105 preassigned to the associated MR (e.g. manually or automatically with 106 a provisionning system), or assigned dynamically by a server such as 107 a DHCP Prefix Delegation server. 109 As prescribed by [10], the HA checks whether a MR is authorized for 110 the MNPs it claims as part of the NEMO Binding Update with the 111 explicit prefix option. Also, MNPs have to belong to an aggregation 112 that is permanently advertised be the HA to the routing 113 infrastruture. Consequently, there is a strong relationship between 114 the HA that the MR registers to and the prefixes it claims with the 115 registration, and it makes sense for the HA to participate actively 116 to the delegation process as well. 118 [10] standardizes an interface between a Mobile Router and its Home 119 Agent, as well as an interface between Home Agents. The protocol is 120 agnostic as to how the back-end is implemented in terms of AAA, 121 provisioning, or routing between the HAs and their IGP, and enables 122 various forms of deployment, as described in [11]. 124 In the same fashion, the document extends [10] for a Mobile Router to 125 obtain its Mobile Network Prefix dynamically from its Home Agent, 126 with no assumption about the specific back-end implementation for 127 prefix management and service authorization. 129 2. Motivation for NEMO prefix delegation 131 A number of reasons motivate adding this capability to NEMO Basic 132 Support [10]. 134 Mainly, there is an unanswered question as to how a MR could be 135 dynamically assigned its prefix. In a situation where a site has 136 many MRs, it may be impractical to assign the prefixes statically in 137 the non-volatile memory of the MR. Consequently, we would like a 138 mechanism for the HA to assign the prefix, similar to how a MN can 139 bootstrap its Home Address. 141 2.1 Requirements 143 There is thus a need for a Mobile Router to obtain dynamically one or 144 more MNPs, linked to the HA that the MR binds with. 146 Since the process might be used as part of a mobility scenario, there 147 is also a need to optimize the delegation flow by limiting the number 148 of protocol exchanges that take place for delegation and 149 registration. 151 Since the initial configuration may be erroneous or may need to 152 evolve overtime, there is a need to manage the MNPs on a Mobile 153 Router. This includes initial setting up, and synchronizing 154 overtime. 156 2.2 Configuration Management 158 The Implicit Mode of NEMO 'externalizes' the configuration of the 159 MNPs in a MR and its HA. In the example of a static configuration, 160 both side are initially provisioned with the association between the 161 MRs and their MNPs, and maintain matching states between them. 163 The failure to configure and maintain these matching states, over 164 time, ends up in routing loops and unreachable prefixes. Tools for 165 synchronizing MNPs in the runtime environment would be a valuable 166 addition to [10]. 168 2.3 Provisioning 170 In practice, provisioning both sides manually is error-prone and 171 should be avoided. It can not be taken for granted, either, that in 172 all cases, a provisioning system can be deployed with the capability 173 to configure both the Mobile Router and the back-end in a 174 transactional manner. 176 Consequently, it appears necessary to provide a way to configure one 177 side only, and have the other side learn from it in a trusted fashion 178 and with no additional manual intervention. 180 The Explicit Prefix mode enables a flow where the configuration of 181 that association is not centralized at the HA but distributed to all 182 the MRs. In fact, the HA is required to validate that the MR has 183 been authorized for the MNPs it claims and then again, some level of 184 information duplication might occur. 186 In the general case, it may be easier to manage the prefix 187 attribution in a centralized manner and have the MRs learn their 188 prefixes dynamically. 190 2.4 Renumbering 192 The concept of lifetime is one core idea with IPv6. Nothing is 193 eternal. Overtime, it might be desirable to modify the configuration 194 of the MNPs. This task, called renumbering, is especially difficult 195 for Mobile Routers when they are geographically distributed and not 196 be readily available to the administrators. 198 It is thus desirable to extend [10] with a renumbering mechanism. In 199 particular, it makes sense to provide that extension within the 200 prefix delegation mechanism, since the operations that take place are 201 vastly similar. 203 2.5 The NEMO bootstrap problem 205 Nemo basic support expects a Mobile router to be provisioned with 206 some information in order to start up - Home Network or Home Agent 207 address, Home Address, Mobile Network Prefixes, security tokens, 208 etc... 210 In some situations, it may be impractical to actually provision all 211 this information into the router at deployment time, and some of it 212 has to be obtained dynamically when a system boots up, possibly 213 through manually keying by the final user. 215 It is absolutely required to reduce such manual keying of information 216 to the bare minimum, like a user ID and password. And while NEMO can 217 benefit from the MIP6 effort on the bootstrap problem (as described 218 in the MIP6 bootstrap problem statement document [9]) for most 219 parameters, the dynamic provisionning of Mobile Network Prefix(es) is 220 not considered by MIPv6. 222 2.6 Local Mobility Management 224 In turn, the bootstrap problem is linked to the Local Mobility 225 Management problem; some LMM solutions such as HMIP deploy regional 226 Home Agents from which bootstrap information has to be obtained when 227 moving into their area of coverage; as opposed to the initial 228 bootstrap problem which occurs at the first startup of a device and 229 may not happen again for an extensive period of time, LMM is tied to 230 movement, and could be quite frequent. 232 3. Rationale 234 This section details the rationale behind some of the design 235 decisions that lead to this solution. 237 3.1 Which capabilities? 239 3.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 a new prefix in a Binding 243 Update and for the HA to provide the prefix as part of the Binding 244 Acknowledgement. Then the Mobile Router installs the newly obtained 245 prefix on the interface that needs it, and moves forward in implicit 246 or explicit mode. 248 3.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 state 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 a change, 282 such as a shortened or expired MNP lifetime. 284 3.1.3 Full prefix list capability for MR 286 So the capability for a HA to list all the prefixes is not 287 sufficient, as the HA is not the repository of that knowledge. It 288 might be simpler for the MR to dump its own list of prefixes and have 289 the HA check the list, even for implicit prefixes. 291 3.2 Rationale for New Binding Options 293 Associated with 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 to 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. As a result, we propose a new 302 option type, the MNP Request Option. 304 Associated with the capability for a HA to list all the prefixes for 305 a MR, one critical piece of information is needed that would not fit 306 in the NEMO MNP option. Again, we propose a new option for the 307 Binding Acknowledgement, the MNP Confirmation Option. 309 3.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 is no prefix 316 for that MR) and no list (HA is not providing a list in that BA). 318 3.4 Why not Alternate Standard-based Solutions? 320 Proposing a new, specific solution might seem irrelevant when a 321 standard, generic mechanism already exists: in this case, the DHCPv6 322 Prefix Delegation. In fact, it is possible for the Home Agent to 323 act 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 detail, a DHCPv6PD based solution presents a number of 336 inconveniences: 338 Delegating Router: A collocated Delegating Router function may not 339 be 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 4. 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 MIPv6 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 Confirmation (MNPConf) Option: A new optional 389 field 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 5. Overview 402 5.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 Confirmation 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 about a change in the lifetime of an 416 MNP. 418 5.2 New Prefix Status bit 420 Finally, this paper introduces a new bit to both the MIP6 Binding 421 Update and Binding Acknowledgement, the Prefix Status bit. A MR may 422 include the Prefix Status bit in a Binding Update message at any 423 time, either in order to get its initial configuration, or to check 424 whether its current configuration matches that of the Home Agent - 425 which might be particularily useful in implicit mode. When the 426 Prefix Status bit is set in the BU, the Acknowledge bit MUST be set 427 as well. 429 The HA MAY set the Prefix Status bit in the Binding Acknowledgement 430 even if it was not set by the MR in the Binding Update; the other way 431 around, if the Prefix Status bit was set in the BU, then the HA MUST 432 echo it in the BA. When setting the Prefix Status bit, the HA also 433 lists all the prefixes associated to that Mobile Router using Mobile 434 Network Prefix Confirmation options. 436 5.3 Prefix Lease Duration 438 A prefix may be obtained for the duration of the binding; in this 439 case, the prefix is called 'transient'. On the other hand, a prefix 440 can be assigned to a MR for a duration that is independent of a BCE 441 lifecycle, and that is controlled externally by the HA administrator; 442 in that case, the prefix is called 'persistent'. 444 A flag in the MNPReq option indicates the expectation of the MR in 445 terms of persistence for the requested prefix. If the HA can not 446 fulfill that expectation, it must reject the binding with a negative 447 status. 449 The lease of a transient prefix expires with the MR Binding Cache 450 Entry; as a result, transient prefixes can be managed internally by a 451 HA, for instance using a local pool that forms an aggregation owned 452 by the HA. 454 On the other hand, some of the information about a persistent prefix 455 has to be shared between the HAs in a Home Network and the back-end 456 systems that enable the authorization. This is required to allow a 457 Mobile Router to rebind, with the same persistent prefixes, to a 458 different Home Agent, after a period of inactivity. 460 It is possible to assign a persistent prefix dynamically at the time 461 of the delegation; but the persistent mode also enables the 462 preassignment of an MNP to an MR, for instance by provisionning a AAA 463 server with the necessary information for each Mobile Router. 465 5.4 Protocol Flow 467 The operation of prefix delegation has a slightly different semantic 468 than home address delegation under Mobile IPv6. If the HA or another 469 router allowed the routing for an address to be changed, the worst 470 possible effect would be unauthorized access, and possibly stealing a 471 message flow from one node. So we protect against this using reverse 472 routability. 474 On the other hand, if the routing for an entire prefix were changed 475 in a malevolent manner, traffic for a large portion of a site could 476 be lost or redirected. Therefore, it is important to focus more 477 closely on exactly how the authorization works for delegating that 478 prefix. 480 There is a 4-step flow for dynamic prefix delegation that must be 481 followed: 483 1. Provisioning -- The administrative entity managing the address 484 space for a site must allocate, either manually or automatically, 485 a prefix to be used by the MR. This could be done when the MR's 486 account with HoA and security association is established, or it 487 could be done at the time of the delegation request. 489 This provisioning must be stored in some permanent location 490 accessible by the HA, since it is necessary to verify autorization 491 for an MR to use a MNP. 493 2. Request -- The MR must signal that it would like a prefix to be 494 delegated by the HA. 496 3. Authorization -- The HA must check that the MR is allowed to use a 497 certain prefix. At this point, the HA does a lookup operation, or 498 if this is a dynamic prefix that has not yet been allocated, the 499 HA does step (1) and provisions a prefix for a certain time 500 period. 502 4. Delegation -- The HA signals to the MR that it is authorized to 503 use a certain prefix for a certain period of time. For 504 simplicity, it should be assumed that this lifetime is the length 505 of the MR's binding, since it is not useful for the MR to continue 506 to have a binding if its MNP has expired. It is possible the 507 lifetime is longer (i.e. infinity if it is a (statically 508 provisioned) persistent prefix). 510 5.5 Renumbering 512 It is possible to redeploy the persistent prefix space, for instance 513 if Home is being renumbered, or if a dynamically attributed prefix 514 has not been bound for a long period of time. In that case, the HA 515 rejects a new binding as the routing states can not be set up, and 516 the MR has to request one or more new persistent prefix(es). 518 5.6 Backward Compatibility 520 An HA that does not support this extension will ignore the 521 unrecognized option. If the HA supports this extension, a binding 522 update with the MNPReq option can be accepted per the NEMO basic 523 support checks: after the packet is checked according to the NEMO 524 spec, the HA processes the option(s). 526 5.7 Basic PD flow 528 When a MR needs an additional prefix to populate an interface, it 529 adds an MNPreq option to its Binding update message. 531 If the HA can obtain the required prefix for that MR, it operates 532 following the NEMO basic support, in either Implicit Mode or Explicit 533 Mode, using the prefixes as if they were received with the BU. This 534 includes setting up the routing states and responding with a positive 535 or a negative status. 537 If the routing states are established correctly and the HA responds 538 with a positive status, then the HA adds the prefix list to the 539 binding ack message. 541 From that point on, both the MR and the HA operate as prescribed by 542 the NEMO basic standard, either in implicit or explicit mode. 544 6. Message Formats 546 6.1 Binding Update 548 A new flag (S) is included in the Binding Update to indicate to the 549 Home Agent that the MR wishes to get the full list of all prefixes 550 that are already assigned to it. The rest of the Binding Update 551 format remains the same as defined in [10]. 553 When the (S) bit is set, the (R) and and (A) bits MUST be set as 554 well. 556 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Sequence # | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 |A|H|L|K|M|R|S| Reserved | Lifetime | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | | 564 . . 565 . Mobility options . 566 . . 567 | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Prefix Status (S) The Prefix Status (S) bit is set by a MR to request 571 the full list of all prefixes that are already assigned to it 573 6.2 Binding Acknowledgement 575 A new flag (S) is included in the Binding Acknowledgement to indicate 576 to the Mobile Router that the Home Agent is providing the complete 577 list of prefixes that are already assigned to the MR. The rest of 578 the Binding Acknowledgement format remains the same as defined in 579 [10]. 581 When the (S) bit is set, the (R) bit MUST be set as well. 583 0 1 2 3 584 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Status |K|R|S|Reserved | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Sequence # | Lifetime | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | | 591 . . 592 . Mobility options . 593 . . 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Prefix Status (S) The Prefix Status (S) bit is set by a HA to 598 indicate that it provides the full list of all prefixes that are 599 already assigned to the MR. 601 6.3 Mobile Network Prefix option 603 New flags are included in the Mobile Network Prefix option defined in 604 [10]. This allows the option to cover all the prefixes owned by the 605 MR, including those that are managed using the implicit prefix mode. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Type | Length |P|I|D|Reserved1| Prefix Length | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | | 613 + + 614 | | 615 + Mobile Network Prefix + 616 | | 617 + + 618 | | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 The new flags introduced by this specification are: 623 Persistent (P) The (P) bit is set if the prefix is expected to be 624 persistently assigned to the MR beyond the lifetime of the 625 associated binding. 627 Implicit (I) The (I) bit is set if the prefix is expected to be 628 assigned to and routed via the MR even if the prefix is not listed 629 in an explicit mode BU. 631 Delegated (D) The (D) bit is set if the prefix was obtained using the 632 Delegation Mechanism as described in this specification. It is 633 used to acknowledge that a previously delegated prefix is actually 634 installed and routable via the Mobile Router. 636 Alignment: Must be 8n + 4. 638 6.4 Mobile Network Prefix Request option 640 This new option is included in the Binding Update to indicate to the 641 Home Agent that the MR wishes to get a new prefix assigned to it for 642 use as a MNP. 644 When this option is present, the (S) MAY be set as well in the BU in 645 order to get the full list of all prefixes. 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Type | Length | Prefix Length |P|I| Reserved1 | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | CorID | Reserved2 | Prefix type | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 Type: TBA 657 Length: 8-bit unsigned integer indicating the length in octets of the 658 option excluding the type and length fields. Set to 6. 660 Prefix Length: 8-bit unsigned integer indicating the prefix length of 661 the IPv6 prefix contained in the option (valid range isno 662 1..128). 664 Persistent (P): The (P) bit is set if the prefix that is requested to 665 be persistently assigned to the MR. 667 Implicit (I): The (I) bit is set if the prefix that is requested to 668 be assigned to, and routed via the MR, even if the prefix was not 669 listed in an explicit mode BU. 671 CorId: A Correlator that is set by the MR in order to associate a MNP 672 request with the prefix given in the confirmation. There can be 673 at most one active prefix associated with each Correlator. This 674 mechanism ensures the uniqueness of the allocation of a prefix, 675 should either the BU or the BA be lost in transit. 677 Prefix Type: Indicates the type of prefix that is requested: 679 0: None Specified 681 1: Private 683 2: Unique Local 685 3: Global 687 6.5 Mobile Network Prefix Confirmation option 689 This new option is included in the Binding Acknowledgment to indicate 690 to the Mobile Router whether a new prefix was assigned, and what it 691 is. 693 When this option is present, the (S) MAY be set as well in the BU in 694 order to indicate that the complete list of prefixes is attached. 696 0 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Type | Length | Prefix Length |P|I|D|Reserved1| 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | CorID | Status | Prefix type | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Valid Lifetime | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | | 706 + + 707 | | 708 + Mobile Network Prefix + 709 | | 710 + + 711 | | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 Type TBA 716 Length: 8-bit unsigned integer indicating the length in octets of the 717 option excluding the type and length fields. Set to 26. 719 Prefix Length: 8-bit unsigned integer indicating the length of the 720 IPv6 prefix contained in the option (valid range is 1..128). 722 Persistent (P): The (P) bit is set if the prefix is persistently 723 assigned to the MR. 725 Implicit (I): The (I) bit is set if the prefix is assigned to and 726 routed via the MR even if the prefix is not listed in explicit 727 mode BU. 729 Delegated (D): The (D) bit is set if the prefix was obtained using a 730 the Delegation Mechanism described in this specification. 732 CorId: If the (D) bit is set, this option contains the prefix being 733 delegated in response to the MNPReq containing the same Correlator 734 If the (D) bit is not set, the Correlator value is unused. 736 Status: Indicates what happened in response to the corresponding 737 request: 739 0: OK (Route successfully created for designated prefix) 741 1: Prefix is not currently registered 743 2: Mobile Network Option sent from non-MR 745 3: Invalid prefix (not part of valid address space) 747 4: Prefix not owned by this domain/link (HA can not delegate) 749 5: Prefix not owned by MR which sent this MNO 751 6: Could not create route / insufficient resources 753 7: Policy does not allow allocation of PrefixLen. Prefix 754 allocated as shown, with longer prefixlen. 756 8: Persistent prefixes are not supported. 758 9: Transient prefixes are not supported. 760 10: NEMO Implicit mode is not supported. 762 Prefix Type: Indicates the type of prefix enclosed: 764 0: None Specified 766 1: Private 768 2: Unique Local 770 3: Global 772 Valid Lifetime: 32-bit unsigned integer. The length of time in 773 seconds (relative to the time the packet is sent) that the prefix 774 is valid for being installed on an MR ingress interface. A value 775 of all one bits (0xffffffff) represents infinity. The Valid 776 Lifetime is also used by RFC2461 [3] and RFC2462 [4], and must be 777 used in the RAs sent over the MR ingress interface for that 778 prefix. 780 Mobile Network Prefix: A 16 byte field containing the Mobile Network 781 Prefix. 783 7. Mobile Router Operation 785 When the Mobile Router has determined the Home Address it is going to 786 use and the Home Agent it is going to register with, it constructs a 787 Binding Update with the R bit set. At this time, the Mobile Router 788 will add either a MNP Option, or a MNPReq Option, or both, to the BU. 790 If the Mobile Router already has one or more persistent MNPs and does 791 not need more, it simply adds a MNP Option. If the MR is not pre- 792 configured with a persistent prefix, it may request either a 793 persistent or transient prefix. 795 If more than one prefix is needed, than more than one can be 796 requested by simply appending multiple MNPReq Options to the BU. 798 When the Binding Acknowledgment is received back from the HA, the MR 799 will process it as normal, and when the MNPC Option(s) are 800 encountered, it should verify that it sent a request using the 801 included CorID, and then react according to the status field, as 802 follows: 804 0: Begin forwarding this prefix and using it in Router Advertisements 805 as described in NEMO. If the P bit is set and the MR supports 806 persisten prefixes, add it to the list of prefixes. 808 1: (unknown) 810 2: Contact system administrator. 812 3: MR may try again with a different prefix. 814 4: MR may try dynamic home agent discovery to contact correct HA. 816 5: MR should retry, with P bit turned off, to obtain a transient 817 prefix. 819 6: MR should try another HA, or wait and try again later. 821 7: Same response as for status 0. 823 8. Home Agent Operation 825 The Home Agent receives a Binding Update from the Mobile Router, it 826 processes the BU as described in the Mobile IPv6 protocol [8] and 827 NEMO basic support [10]. When it arrives at a MNPO (assuming the 828 Binding Update is valid as already processed), it takes steps as 829 follows: 831 Step 1. Verify that the MR is allowed to be allocated a prefix of the 832 requested type and allocate one. 834 Step 2. If the request is for a persistent prefix, save the 835 allocation in the back-end permanent store. 837 Step 3. Set up routing for this prefix. If the BU was of lifetime 0, 838 do not set up routing for this prefix, but simply allocate it. 840 Step 4. For each MNPR option, respond with a MNPC option in the BAck. 841 If the MNPR was received in a BU from a non-MR, send status 2 and 842 0s for prefix information. Otherwise, send a response with result 843 code 0, and filling in the appropriate prefix information. 845 If the Binding Update contains an S bit, the Home Agent includes a 846 Mobile Network Prefix Option for each prefix the Home Agent believes 847 is assigned to the Mobile Router. 849 After these steps are followed, the Home Agent continues its 850 operation as normal, until another MNPO or MNPR is received. 852 9. Back End considerations 853 10. Security Considerations 855 11. Acknowledgements 857 The authors wish to thank: 859 Pekka Paakkonen and Juhani Latvakoski from VTT Electronics for their 860 initial work on the matter. 862 12. References 864 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 865 Levels", BCP 14, RFC 2119, March 1997. 867 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 868 Specification", RFC 2460, December 1998. 870 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 871 for IP Version 6 (IPv6)", RFC 2461, December 1998. 873 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 874 Autoconfiguration", RFC 2462, December 1998. 876 [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 877 Addressing Architecture", RFC 3513, April 2003. 879 [6] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 880 Configuration Protocol (DHCP) version 6", RFC 3633, 881 December 2003. 883 [7] Manner, J. and M. Kojo, "Mobility Related Terminology", 884 RFC 3753, June 2004. 886 [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 887 IPv6", RFC 3775, June 2004. 889 [9] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", 890 draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004. 892 [10] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 893 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 894 January 2005. 896 [11] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home 897 Network models", draft-ietf-nemo-home-network-models-00 (work 898 in progress), April 2004. 900 [12] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 901 draft-ietf-nemo-terminology-01 (work in progress), 902 February 2004. 904 Authors' Addresses 906 T.J. Kniveton 907 Nokia, Inc. 908 313 Fairchild Dr. 909 Building B-223 910 Mountain View 94043 911 USA 913 Phone: +1 650 625 2025 914 Email: tj@kniveton.com 916 Pascal Thubert 917 Cisco Systems 918 Village d'Entreprises Green Side 919 400, Avenue de Roumanille 920 Batiment T3 921 Biot - Sophia Antipolis 06410 922 FRANCE 924 Phone: +33 4 97 23 26 34 925 Email: pthubert@cisco.com 927 Intellectual Property Statement 929 The IETF takes no position regarding the validity or scope of any 930 Intellectual Property Rights or other rights that might be claimed to 931 pertain to the implementation or use of the technology described in 932 this document or the extent to which any license under such rights 933 might or might not be available; nor does it represent that it has 934 made any independent effort to identify any such rights. Information 935 on the procedures with respect to rights in RFC documents can be 936 found in BCP 78 and BCP 79. 938 Copies of IPR disclosures made to the IETF Secretariat and any 939 assurances of licenses to be made available, or the result of an 940 attempt made to obtain a general license or permission for the use of 941 such proprietary rights by implementers or users of this 942 specification can be obtained from the IETF on-line IPR repository at 943 http://www.ietf.org/ipr. 945 The IETF invites any interested party to bring to its attention any 946 copyrights, patents or patent applications, or other proprietary 947 rights that may cover technology that may be required to implement 948 this standard. Please address the information to the IETF at 949 ietf-ipr@ietf.org. 951 Disclaimer of Validity 953 This document and the information contained herein are provided on an 954 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 955 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 956 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 957 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 958 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 959 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 961 Copyright Statement 963 Copyright (C) The Internet Society (2005). This document is subject 964 to the rights, licenses and restrictions contained in BCP 78, and 965 except as set forth therein, the authors retain all their rights. 967 Acknowledgment 969 Funding for the RFC Editor function is currently provided by the 970 Internet Society.