idnits 2.17.1 draft-kniveton-nemo-prefix-delegation-00.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 940. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 956), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 263 has weird spacing: '...uration with ...' == Line 321 has weird spacing: '..., it is possi...' == Line 337 has weird spacing: '...ion may not...' == Line 342 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 (October 15, 2004) is 7125 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 858, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 867, 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: 20 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Mobility TJ. Kniveton 2 Internet-Draft Nokia 3 Expires: April 15, 2005 P. Thubert 4 Cisco 5 October 15, 2004 7 Mobile Network Prefix Delegation 8 draft-kniveton-nemo-prefix-delegation-00 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 15, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This paper extends the Nemo Basic Support [10] for a Mobile Router to 42 synchronize its Mobile Network Prefixes with its Home Agents and 43 obtain new ones dynamically. The proposed prefix delegation 44 mechanism is agnostic to the way the prefixes are managed and 45 provisioned at the Home Agent; it might be used for bootstrapping, 46 resynchronization at binding creation or after a loss of states (eg 47 MR reboot), MNP Renumbering, and configuration checking for loop 48 avoidance. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Motivation for NEMO prefix delegation . . . . . . . . . . . . 3 54 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2 Configuration Management . . . . . . . . . . . . . . . . . 4 56 2.3 Provisioning . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.4 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.5 The NEMO bootstrap problem . . . . . . . . . . . . . . . . 5 59 2.6 Local Mobility Management . . . . . . . . . . . . . . . . 5 60 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1 Which capabilities? . . . . . . . . . . . . . . . . . . . 6 62 3.1.1 Prefix Request capability . . . . . . . . . . . . . . 6 63 3.1.2 Full prefix list capability for HA . . . . . . . . . . 6 64 3.1.3 Full prefix list capability for MR . . . . . . . . . . 7 65 3.2 Rationale for New Binding Options . . . . . . . . . . . . 7 66 3.3 Rationale for a new bit in the BU . . . . . . . . . . . . 7 67 3.4 Why not Alternate Standard-based Solutions? . . . . . . . 7 68 4. Terminology and concepts . . . . . . . . . . . . . . . . . . . 9 69 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.1 New Mobility Headers . . . . . . . . . . . . . . . . . . . 10 71 5.2 New Prefix Status bit . . . . . . . . . . . . . . . . . . 10 72 5.3 Prefix Lease Duration . . . . . . . . . . . . . . . . . . 10 73 5.4 Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 11 74 5.5 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.6 Backward Compatibility . . . . . . . . . . . . . . . . . . 12 76 5.7 Basic PD flow . . . . . . . . . . . . . . . . . . . . . . 12 77 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.1 Binding Update . . . . . . . . . . . . . . . . . . . . . . 13 79 6.2 Binding Acknowledgement . . . . . . . . . . . . . . . . . 14 80 6.3 Mobile Network Prefix option . . . . . . . . . . . . . . . 15 81 6.4 Mobile Network Prefix Request option . . . . . . . . . . . 16 82 6.5 Mobile Network Prefix Confirmation option . . . . . . . . 18 83 7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 21 84 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22 85 9. Back End considerations . . . . . . . . . . . . . . . . . . . 23 86 10. Security Considerations . . . . . . . . . . . . . . . . . . 24 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 90 Intellectual Property and Copyright Statements . . . . . . . . 27 92 1. Introduction 94 The reader of that document is expected to be familiar with both the 95 Mobile IPv6 [8] and NEMO Basic Support [10] documents. As such, it 96 is well understood that neither protocol provides the means for 97 provisioning the Mobile Nodes and Routers with essential parameters 98 such as Home Address and Home Network. 100 The process by which a router obtains a prefix dynamically is called 101 prefix delegation. In the NEMO context, the prefix assignment is 102 managed by an authority in the Home Network and divides it into 103 subnets for MNPs, which are then assigned to the MRs. An MNP can be 104 preassigned to the associated MR (e.g. manually or automatically 105 with a provisionning system), or assigned dynamically by a server 106 such as a DHCP Prefix Delegation server. 108 As prescribed by [10], the HA checks whether a MR is authorized for 109 the MNPs it claims as part of the NEMO Binding Update with the 110 explicit prefix option. Also, MNPs have to belong to an aggregation 111 that is permanently advertised be the HA to the routing 112 infrastruture. Consequently, there is a strong relationship between 113 the HA that the MR registers to and the prefixes it claims with the 114 registration, and it makes sense for the HA to participate actively 115 to the delegation process as well. 117 [10] standardizes an interface between a Mobile Router and its Home 118 Agent, as well as an interface between Home Agents. The protocol is 119 agnostic as to how the back-end is implemented in terms of AAA, 120 provisioning, or routing between the HAs and their IGP, and enables 121 various forms of deployment, as described in [11]. 123 In the same fashion, the document extends [10] for a Mobile Router to 124 obtain its Mobile Network Prefix dynamically from its Home Agent, 125 with no assumption about the specific back-end implementation for 126 prefix management and service authorization. 128 2. Motivation for NEMO prefix delegation 130 A number of reasons motivate adding this capability to NEMO Basic 131 Support [10]. 133 Mainly, there is an unanswered question as to how a MR could be 134 dynamically assigned its prefix. In a situation where a site has 135 many MRs, it may be impractical to assign the prefixes statically in 136 the non-volatile memory of the MR. Consequently, we would like a 137 mechanism for the HA to assign the prefix, similar to how a MN can 138 bootstrap its Home Address. 140 2.1 Requirements 142 There is thus a need for a Mobile Router to obtain dynamically one or 143 more MNPs, linked to the HA that the MR binds with. 145 Since the process might be used as part of a mobility scenario, there 146 is also a need to optimize the delegation flow by limiting the number 147 of protocol exchanges that take place for delegation and 148 registration. 150 Since the initial configuration may be erroneous or may need to 151 evolve overtime, there is a need to manage the MNPs on a Mobile 152 Router. This includes initial setting up, and synchronizing 153 overtime. 155 2.2 Configuration Management 157 The Implicit Mode of NEMO 'externalizes' the configuration of the 158 MNPs in a MR and its HA. In the example of a static configuration, 159 both side are initially provisioned with the association between the 160 MRs and their MNPs, and maintain matching states between them. 162 The failure to configure and maintain these matching states, over 163 time, ends up in routing loops and unreachable prefixes. Tools for 164 synchronizing MNPs in the runtime environment would be a valuable 165 addition to [10]. 167 2.3 Provisioning 169 In practice, provisioning both sides manually is error-prone and 170 should be avoided. It can not be taken for granted, either, that in 171 all cases, a provisioning system can be deployed with the capability 172 to configure both the Mobile Router and the back-end in a 173 transactional manner. 175 Consequently, it appears necessary to provide a way to configure one 176 side only, and have the other side learn from it in a trusted fashion 177 and with no additional manual intervention. 179 The Explicit Prefix mode enables a flow where the configuration of 180 that association is not centralized at the HA but distributed to all 181 the MRs. In fact, the HA is required to validate that the MR has 182 been authorized for the MNPs it claims and then again, some level of 183 information duplication might occur. 185 In the general case, it may be easier to manage the prefix 186 attribution in a centralized manner and have the MRs learn their 187 prefixes dynamically. 189 2.4 Renumbering 191 The concept of lifetime is one core idea with IPv6. Nothing is 192 eternal. Overtime, it might be desirable to modify the configuration 193 of the MNPs. This task, called renumbering, is especially difficult 194 for Mobile Routers when they are geographically distributed and not 195 be readily available to the administrators. 197 It is thus desirable to extend [10] with a renumbering mechanism. In 198 particular, it makes sense to provide that extension within the 199 prefix delegation mechanism, since the operations that take place are 200 vastly similar. 202 2.5 The NEMO bootstrap problem 204 Nemo basic support expects a Mobile router to be provisioned with 205 some information in order to start up - Home Network or Home Agent 206 address, Home Address, Mobile Network Prefixes, security tokens, 207 etc... 209 In some situations, it may be impractical to actually provision all 210 this information into the router at deployment time, and some of it 211 has to be obtained dynamically when a system boots up, possibly 212 through manually keying by the final user. 214 It is absolutely required to reduce such manual keying of information 215 to the bare minimum, like a user ID and password. And while NEMO can 216 benefit from the MIP6 effort on the bootstrap problem (as described 217 in the MIP6 bootstrap problem statement document [9]) for most 218 parameters, the dynamic provisionning of Mobile Network Prefix(es) is 219 not considered by MIPv6. 221 2.6 Local Mobility Management 223 In turn, the bootstrap problem is linked to the Local Mobility 224 Management problem; some LMM solutions such as HMIP deploy regional 225 Home Agents from which bootstrap information has to be obtained when 226 moving into their area of coverage; as opposed to the initial 227 bootstrap problem which occurs at the first startup of a device and 228 may not happen again for an extensive period of time, LMM is tied to 229 movement, and could be quite frequent. 231 3. Rationale 233 This section details the rationale behind some of the design 234 decisions that lead to this solution. 236 3.1 Which capabilities? 238 3.1.1 Prefix Request capability 240 The minimum capability that could be envisionned for a NEMO Prefix 241 Delegation mechanism is for a MR to request a new prefix in a Binding 242 Update and for the HA to provide the prefix as part of the Binding 243 Acknowledgement. Then the Mobile Router installs the newly obtained 244 prefix on the interface that needs it, and moves forward in implicit 245 or explicit mode. 247 3.1.2 Full prefix list capability for HA 249 The capability to request a new prefix is sufficient in a basic 250 delegation flow where a MR that is already bound and -hopefully- 251 synchronized with its HA in terms of prefix ownership; it is also 252 required in some bootstrapping and renumbering flows; but it is 253 hardly sufficient in order to synchronize the MR and the HA states 254 regarding MNPs: 256 Bootstrapping: At bootstrapping time, the MR needs the list of all 257 the prefixes that are attributed in order to populate its 258 interfaces. Asking them one by one and having to make a 259 distinction between already allocated prefixes versus dynamic 260 allocation would make the flow much more complex. 262 Expired prefixes: That list is also needed for a MR in order to 263 synchronize its current configuration with that of the HA. In 264 particular, it is used for a MR to discover when the HA does not 265 have the associated states in place for one of its MNPs. This may 266 happen for some configuration error or because the prefix has 267 expired, and the only way to know is if the prefix is missing in a 268 full list of all prefixes by the HA. 270 Newly allocated prefixes: Finally, the list is needed for a MR to 271 learn new prefixes that would be attributed in runtime, and to 272 install those prefixes on its interfaces. Once the new prefixes 273 are installed, it is required that the MR confirms its use of the 274 prefixes so that the HA can set up routing in a loopfree fashion. 276 So, the capability for a HA to list all the prefixes for a MR is 277 needed for the MR to realize that the HA is missing some state and 278 eventually to try to get the missing prefixes in explicit mode. This 279 may happen on demand by the MR (e.g. at bootstrap time or binding 280 creation time), or whenever the HA needs to communicate a change, 281 such as a shortened or expired MNP lifetime. 283 3.1.3 Full prefix list capability for MR 285 So the capability for a HA to list all the prefixes is not 286 sufficient, as the HA is not the repository of that knowledge. It 287 might be simpler for the MR to dump its own list of prefixes and have 288 the HA check the list, even for implicit prefixes. 290 3.2 Rationale for New Binding Options 292 Associated with the capability to request a new prefix, it seems 293 relevant to specify whether the prefix is for implicit or explicit 294 mode, or if its lifetime is limited to that of the binding cache or 295 not. Other fields such as the prefix length are needed as well. In 296 order to convey that information, an optional field is needed in the 297 BU. 299 It is not desirable to extend the existing NEMO MNP option, which 300 carries a prefix that is not needed. As a result, we propose a new 301 option type, the MNP Request Option. 303 Associated with the capability for a HA to list all the prefixes for 304 a MR, one critical piece of information is needed that would not fit 305 in the NEMO MNP option. Again, we propose a new option for the 306 Binding Acknowledgement, the MNP Confirmation Option. 308 3.3 Rationale for a new bit in the BU 310 A single bit in the BU is enough for a MR to request a full list of 311 prefixes from the HA, if we do not need a filter of any sort? 313 It is important that the HA set that bit in its full list of prefixes 314 in order to differentiate between an empty list (there is no prefix 315 for that MR) and no list (HA is not providing a list in that BA). 317 3.4 Why not Alternate Standard-based Solutions? 319 Proposing a new, specific solution might seem irrelevant when a 320 standard, generic mechanism already exists: in this case, the DHCPv6 321 Prefix Delegation. In fact, it is possible for the Home Agent to 322 act as a DHCPv6PD Delegating Router. This solution presents the 323 advantage of reusing existing standard flows from RFC3633 [6]. 325 Yet, in a deployment where the MNPs are preassigned to the MR, a AAA 326 server, interfacing with the HA, and eventually coupled with a 327 provisioning system in its back-end, can provide the required service 328 for assigning and authorizing the prefixes to the MRs; in such a 329 case, the value of implementing a DHCPv6PD server is highly arguable. 330 It is more generic to let the HA handle the backend interfaces on 331 behalf of the MR and expose a consistent NEMO interface for all 332 deployments. 334 In more detail, a DHCPv6PD based solution presents a number of 335 inconveniences: 337 Delegating Router: A collocated Delegating Router function may not 338 be available for all implementation of NEMO Home Agent. In 339 particular, some implementations are server based. 341 Operational overhead: Depending on the mechanism that is used to 342 attribute the MNPs to the MRs, the Delegating function, even if 343 available, might be a costly overhead. Rather, an embedded, 344 back-end agnostic flow might be a desirable option. 346 Movement overhead: Some flows, for instance local mobility 347 management, might require a prefix delegation as part of the 348 handling of the movement. Segregating the delegation from the 349 binding adds a round trip delay to the recovery from the movement. 351 Binding Lifetime: It might be useful to associate implicitly the 352 lifetime of a delegated prefix with that of the binding. This 353 pleads for a design that places the Home Agent function in the 354 flow by construction. 356 Authentication Mechanism: While NEMO basic Support protects its own 357 flows, there is no mandate to secure the tunneled packets. 359 Back-end interaction: If a prefix is attributed to a MR for a 360 duration that exceeds that of its binding, this information needs 361 to be shared with all HAs, at least for authorization purposes. 362 This requires a specific backend integration that does not exist 363 in the Prefix Delegation Function, for instance via a AAA server. 365 4. Terminology and concepts 367 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 368 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 369 interpreted as described in RFC2119 [1]. 371 Most of the mobility related terms used in this document are defined 372 in the Mobility Related Terminology document [7] and in the Mobile 373 IPv6 specification [8]. 375 Additionally, some terms were created or extended for NEMO. These 376 specific terms are defined in the Mobile Network Terminology document 377 [12] 379 This draft introduces the following definitions: 381 Mobile Network Prefix Request (MNPReq) Option: A new optional field 382 in the MIPv6 Mobility Header for use with the Binding Update 383 message, as described further in this document. This field is set 384 by a MR to request the delegation of a new prefix as a Mobile 385 Network Prefix. 387 Mobile Network Prefix Confirmation (MNPConf) Option: A new optional 388 field in the MIP6 Mobility Header for use with the Binding 389 Acknowledgement message, as described further in this document. 391 transient prefix: A prefix that is attributed to a Mobile Router in 392 association with a binding cache entry. If the BCE is removed, 393 the prefix is freed. 395 Persistent prefix: A prefix that is attributed to a Mobile Router for 396 a period of time that does not depend on the existence of a 397 binding cache entry. 399 5. Overview 401 5.1 New Mobility Headers 403 This paper introduces a new option to the MIP6 Mobility Header, for 404 use with the Binding Update message, the Mobile Network Prefix 405 Request Option. A MR may include one or more MNPReq option(s) in a 406 Binding Update message at any time, in order to obtain additional 407 prefixes. 409 This paper introduces another new option to the MIP6 Mobility Header, 410 for use with the Binding Acknowledgement message, the Mobile Network 411 Prefix Confirmation Option. An HA will include one or more MNPConf 412 option(s) in a Binding Acknowledgement message, either in response to 413 a Mobile Network Prefix Request Option, or for its own purposes, for 414 instance in order inform a MR about a change in the lifetime of an 415 MNP. 417 5.2 New Prefix Status bit 419 Finally, this paper introduces a new bit to both the MIP6 Binding 420 Update and Binding Acknowledgement, the Prefix Status bit. A MR may 421 include the Prefix Status bit in a Binding Update message at any 422 time, either in order to get its initial configuration, or to check 423 whether its current configuration matches that of the Home Agent - 424 which might be particularily useful in implicit mode. When the 425 Prefix Status bit is set in the BU, the Acknowledge bit MUST be set 426 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 Confirmation options. 435 5.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 On 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 5.4 Protocol Flow 466 The operation of prefix delegation has a slightly different semantic 467 than home address delegation under Mobile IPv6. If the HA or another 468 router allowed the routing for an address to be changed, the worst 469 possible effect would be unauthorized access, and possibly stealing a 470 message flow from one node. So we protect against this using reverse 471 routability. 473 On the other hand, if the routing for an entire prefix were changed 474 in a malevolent manner, traffic for a large portion of a site could 475 be lost or redirected. Therefore, it is important to focus more 476 closely on exactly how the authorization works for delegating that 477 prefix. 479 There is a 4-step flow for dynamic prefix delegation that must be 480 followed: 482 1. Provisioning -- The administrative entity managing the address 483 space for a site must allocate, either manually or automatically, 484 a prefix to be used by the MR. This could be done when the MR's 485 account with HoA and security association is established, or it 486 could be done at the time of the delegation request. 488 This provisioning must be stored in some permanent location 489 accessible by the HA, since it is necessary to verify autorization 490 for an MR to use a MNP. 492 2. Request -- The MR must signal that it would like a prefix to be 493 delegated by the HA. 495 3. Authorization -- The HA must check that the MR is allowed to use 496 a certain prefix. At this point, the HA does a lookup operation, 497 or if this is a dynamic prefix that has not yet been allocated, 498 the HA does step (1) and provisions a prefix for a certain time 499 period. 501 4. Delegation -- The HA signals to the MR that it is authorized to 502 use a certain prefix for a certain period of time. For 503 simplicity, it should be assumed that this lifetime is the length 504 of the MR's binding, since it is not useful for the MR to continue 505 to have a binding if its MNP has expired. It is possible the 506 lifetime is longer (i.e. infinity if it is a (statically 507 provisioned) persistent prefix). 509 5.5 Renumbering 511 It is possible to redeploy the persistent prefix space, for instance 512 if Home is being renumbered, or if a dynamically attributed prefix 513 has not been bound for a long period of time. In that case, the HA 514 rejects a new binding as the routing states can not be set up, and 515 the MR has to request one or more new persistent prefix(es). 517 5.6 Backward Compatibility 519 An HA that does not support this extension will ignore the 520 unrecognized option. If the HA supports this extension, a binding 521 update with the MNPReq option can be accepted per the NEMO basic 522 support checks: after the packet is checked according to the NEMO 523 spec, the HA processes the option(s). 525 5.7 Basic PD flow 527 When a MR needs an additional prefix to populate an interface, it 528 adds an MNPreq option to its Binding update message. 530 If the HA can obtain the required prefix for that MR, it operates 531 following the NEMO basic support, in either Implicit Mode or Explicit 532 Mode, using the prefixes as if they were received with the BU. This 533 includes setting up the routing states and responding with a positive 534 or a negative status. 536 If the routing states are established correctly and the HA responds 537 with a positive status, then the HA adds the prefix list to the 538 binding ack message. 540 From that point on, both the MR and the HA operate as prescribed by 541 the NEMO basic standard, either in implicit or explicit mode. 543 6. Message Formats 545 6.1 Binding Update 547 A new flag (S) is included in the Binding Update to indicate to the 548 Home Agent that the MR wishes to get the full list of all prefixes 549 that are already assigned to it. The rest of the Binding Update 550 format remains the same as defined in [10]. 552 When the (S) bit is set, the (R) and and (A) bits MUST be set as 553 well. 555 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Sequence # | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 |A|H|L|K|M|R|S| Reserved | Lifetime | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 . . 564 . Mobility options . 565 . . 566 | | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Prefix Status (S) The Prefix Status (S) bit is set by a MR to request 570 the full list of all prefixes that are already assigned to it 572 6.2 Binding Acknowledgement 574 A new flag (S) is included in the Binding Acknowledgement to indicate 575 to the Mobile Router that the Home Agent is providing the complete 576 list of prefixes that are already assigned to the MR. The rest of 577 the Binding Acknowledgement format remains the same as defined in 578 [10]. 580 When the (S) bit is set, the (R) bit MUST be set as well. 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Status |K|R|S|Reserved | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Sequence # | Lifetime | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | | 590 . . 591 . Mobility options . 592 . . 593 | | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Prefix Status (S) The Prefix Status (S) bit is set by a HA to 597 indicate that it provides the full list of all prefixes that are 598 already assigned to the MR. 600 6.3 Mobile Network Prefix option 602 New flags are included in the Mobile Network Prefix option defined in 603 [10]. This allows the option to cover all the prefixes owned by the 604 MR, including those that are managed using the implicit prefix mode. 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Type | Length |P|I|D|Reserved1| Prefix Length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | | 612 + + 613 | | 614 + Mobile Network Prefix + 615 | | 616 + + 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 The new flags introduced by this specification are: 622 Persistent (P) The (P) bit is set if the prefix is expected to be 623 persistently assigned to the MR beyond the lifetime of the 624 associated binding. 626 Implicit (I) The (I) bit is set if the prefix is expected to be 627 assigned to and routed via the MR even if the prefix is not listed 628 in an explicit mode BU. 630 Delegated (D) The (D) bit is set if the prefix was obtained using the 631 Delegation Mechanism as described in this specification. It is 632 used to acknowledge that a previously delegated prefix is actually 633 installed and routable via the Mobile Router. 635 6.4 Mobile Network Prefix Request option 637 This new option is included in the Binding Update to indicate to the 638 Home Agent that the MR wishes to get a new prefix assigned to it for 639 use as a MNP. 641 When this option is present, the (S) MAY be set as well in the BU in 642 order to get the full list of all prefixes. 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Type | Length | Prefix Length |P|I| Reserved1 | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | CorID | Reserved2 | Prefix type | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 Type: TBA 654 Length: 8-bit unsigned integer indicating the length in octets of the 655 option excluding the type and length fields. Set to 6. 657 Prefix Length: 8-bit unsigned integer indicating the prefix length of 658 the IPv6 prefix contained in the option (valid range isno 659 1..128). 661 Persistent (P): The (P) bit is set if the prefix that is requested to 662 be persistently assigned to the MR. 664 Implicit (I): The (I) bit is set if the prefix that is requested to 665 be assigned to, and routed via the MR, even if the prefix was not 666 listed in an explicit mode BU. 668 CorId: A Correlator that is set by the MR in order to associate a MNP 669 request with the prefix given in the confirmation. There can be 670 at most one active prefix associated with each Correlator. This 671 mechanism ensures the uniqueness of the allocation of a prefix, 672 should either the BU or the BA be lost in transit. 674 Prefix Type: Indicates the type of prefix that is requested: 676 0: None Specified 677 1: Private 679 2: Unique Local 681 3: Global 683 6.5 Mobile Network Prefix Confirmation option 685 This new option is included in the Binding Acknowledgment to indicate 686 to the Mobile Router whether a new prefix was assigned, and what it 687 is. 689 When this option is present, the (S) MAY be set as well in the BU in 690 order to indicate that the complete list of prefixes is attached. 692 0 1 2 3 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Type | Length | Prefix Length |P|I|D|Reserved1| 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | CorID | Status | Prefix type | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Valid Lifetime | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | | 702 + + 703 | | 704 + Mobile Network Prefix + 705 | | 706 + + 707 | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Type TBA 712 Length: 8-bit unsigned integer indicating the length in octets of the 713 option excluding the type and length fields. Set to 26. 715 Prefix Length: 8-bit unsigned integer indicating the length of the 716 IPv6 prefix contained in the option (valid range is 1..128). 718 Persistent (P): The (P) bit is set if the prefix is persistently 719 assigned to the MR. 721 Implicit (I): The (I) bit is set if the prefix is assigned to and 722 routed via the MR even if the prefix is not listed in explicit 723 mode BU. 725 Delegated (D): The (D) bit is set if the prefix was obtained using a 726 the Delegation Mechanism described in this specification. 728 CorId: If the (D) bit is set, this option contains the prefix being 729 delegated in response to the MNPReq containing the same Correlator 730 If the (D) bit is not set, the Correlator value is defined by the 731 HA. 733 Status: Indicates what happened in response to the corresponding 734 request: 736 0: OK (Route successfully created for designated prefix) 738 1: Prefix is not currently registered 740 2: Mobile Network Option sent from non-MR 742 3: Invalid prefix (not part of valid address space) 744 4: Prefix not owned by this domain/link (HA can not delegate) 746 5: Prefix not owned by MR which sent this MNO 748 6: Could not create route / insufficient resources 750 7: Policy does not allow allocation of PrefixLen. Prefix 751 allocated as shown, with longer prefixlen. 753 8: Persistent prefixes are not supported. 755 9: Transient prefixes are not supported. 757 10: NEMO Implicit mode is not supported. 759 Prefix Type: Indicates the type of prefix enclosed: 761 0: None Specified 763 2: Unique Local 765 3: Global 767 Valid Lifetime: 32-bit unsigned integer. The length of time in 768 seconds (relative to the time the packet is sent) that the prefix 769 is valid for being installed on an MR ingress interface. A value 770 of all one bits (0xffffffff) represents infinity. The Valid 771 Lifetime is also used by RFC2461 [3] and RFC2462 [4], and must be 772 used in the RAs sent over the MR ingress interface for that 773 prefix. 775 Mobile Network Prefix: A 16 byte field containing the Mobile Network 776 Prefix. 778 7. Mobile Router Operation 780 When the Mobile Router has determined the Home Address it is going to 781 use and the Home Agent it is going to register with, it constructs a 782 Binding Update with the R bit set. At this time, the Mobile Router 783 will add either a MNP Option, or a MNPReq Option, or both, to the BU. 785 If the Mobile Router already has one or more persistent MNPs and does 786 not need more, it simply adds a MNP Option. If the MR is not 787 pre-configured with a persistent prefix, it may request either a 788 persistent or transient prefix. 790 If more than one prefix is needed, than more than one can be 791 requested by simply appending multiple MNPReq Options to the BU. 793 When the Binding Acknowledgment is received back from the HA, the MR 794 will process it as normal, and when the MNPC Option(s) are 795 encountered, it should verify that it sent a request using the 796 included CorID, and then react according to the status field, as 797 follows: 799 0: Begin forwarding this prefix and using it in Router Advertisements 800 as described in NEMO. If the P bit is set and the MR supports 801 persisten prefixes, add it to the list of prefixes. 803 1: (unknown) 805 2: Contact system administrator. 807 3: MR may try again with a different prefix. 809 4: MR may try dynamic home agent discovery to contact correct HA. 811 5: MR should retry, with P bit turned off, to obtain a transient 812 prefix. 814 6: MR should try another HA, or wait and try again later. 816 7: Same response as for status 0. 818 8. Home Agent Operation 820 The Home Agent receives a Binding Update from the Mobile Router, it 821 processes the BU as described in the Mobile IPv6 protocol [8] and 822 NEMO basic support [10]. When it arrives at a MNPO (assuming the 823 Binding Update is valid as already processed), it takes steps as 824 follows: 826 Step 1. Verify that the MR is allowed to be allocated a prefix of 827 the requested type and allocate one. 829 Step 2. If the request is for a persistent prefix, save the 830 allocation in the back-end permanent store. 832 Step 3. Set up routing for this prefix. If the BU was of lifetime 833 0, do not set up routing for this prefix, but simply allocate it. 835 Step 4. For each MNPR option, respond with a MNPC option in the 836 BAck. If the MNPR was received in a BU from a non-MR, send status 837 2 and 0s for prefix information. Otherwise, send a response with 838 result code 0, and filling in the appropriate prefix information. 840 After these steps are followed, the Home Agent continues its 841 operation as normal, until another MNPO or MNPR is received. 843 9. Back End considerations 844 10. Security Considerations 846 11. Acknowledgements 848 The authors wish to thank: 850 Pekka Paakkonen and Juhani Latvakoski from VTT Electronics for their 851 initial work on the matter. 853 12 References 855 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 856 Levels", BCP 14, RFC 2119, March 1997. 858 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 859 Specification", RFC 2460, December 1998. 861 [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 862 for IP Version 6 (IPv6)", RFC 2461, December 1998. 864 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 865 Autoconfiguration", RFC 2462, December 1998. 867 [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 868 Addressing Architecture", RFC 3513, April 2003. 870 [6] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 871 Configuration Protocol (DHCP) version 6", RFC 3633, December 872 2003. 874 [7] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 875 3753, June 2004. 877 [8] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 878 IPv6", RFC 3775, June 2004. 880 [9] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", 881 draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004. 883 [10] Devarapalli, V., "Network Mobility (NEMO) Basic Support 884 Protocol", draft-ietf-nemo-basic-support-03 (work in progress), 885 June 2004. 887 [11] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home 888 Network models", draft-ietf-nemo-home-network-models-00 (work 889 in progress), April 2004. 891 [12] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 892 draft-ietf-nemo-terminology-01 (work in progress), February 893 2004. 895 Authors' Addresses 897 T.J. Kniveton 898 Nokia, Inc. 899 313 Fairchild Dr. 900 Building B-223 901 Mountain View 94043 902 USA 904 Phone: +1 650 625 2025 905 EMail: tj@kniveton.com 907 Pascal Thubert 908 Cisco Systems 909 Village d'Entreprises Green Side 910 400, Avenue de Roumanille 911 Batiment T3 912 Biot - Sophia Antipolis 06410 913 FRANCE 915 Phone: +33 4 97 23 26 34 916 EMail: pthubert@cisco.com 918 Intellectual Property Statement 920 The IETF takes no position regarding the validity or scope of any 921 Intellectual Property Rights or other rights that might be claimed to 922 pertain to the implementation or use of the technology described in 923 this document or the extent to which any license under such rights 924 might or might not be available; nor does it represent that it has 925 made any independent effort to identify any such rights. Information 926 on the procedures with respect to rights in RFC documents can be 927 found in BCP 78 and BCP 79. 929 Copies of IPR disclosures made to the IETF Secretariat and any 930 assurances of licenses to be made available, or the result of an 931 attempt made to obtain a general license or permission for the use of 932 such proprietary rights by implementers or users of this 933 specification can be obtained from the IETF on-line IPR repository at 934 http://www.ietf.org/ipr. 936 The IETF invites any interested party to bring to its attention any 937 copyrights, patents or patent applications, or other proprietary 938 rights that may cover technology that may be required to implement 939 this standard. Please address the information to the IETF at 940 ietf-ipr@ietf.org. 942 Disclaimer of Validity 944 This document and the information contained herein are provided on an 945 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 946 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 947 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 948 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 949 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 950 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 952 Copyright Statement 954 Copyright (C) The Internet Society (2004). This document is subject 955 to the rights, licenses and restrictions contained in BCP 78, and 956 except as set forth therein, the authors retain all their rights. 958 Acknowledgment 960 Funding for the RFC Editor function is currently provided by the 961 Internet Society.