Network Mobility T. Kniveton Internet-Draft Nokia Expires: February 19, 2006 P. Thubert Cisco August 18, 2005 Mobile Network Prefix Delegation draft-ietf-nemo-prefix-delegation-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This paper extends the Nemo Basic Support [10] for a Mobile Router to synchronize its Mobile Network Prefixes with its Home Agents and obtain new ones dynamically. The proposed prefix delegation mechanism is agnostic to the way the prefixes are managed and provisioned at the Home Agent; it might be used for bootstrapping, resynchronization at binding creation or after a loss of states (eg MR reboot), MNP Renumbering, and configuration checking for loop Kniveton & Thubert Expires February 19, 2006 [Page 1]
Internet-Draft NEMO-PD August 2005 avoidance. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation for NEMO prefix delegation . . . . . . . . . . . . 3 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Configuration Management . . . . . . . . . . . . . . . . . 4 2.3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. The NEMO bootstrap problem . . . . . . . . . . . . . . . . 5 2.6. Local Mobility Management . . . . . . . . . . . . . . . . 5 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Which capabilities? . . . . . . . . . . . . . . . . . . . 6 3.1.1. Prefix Request capability . . . . . . . . . . . . . . 6 3.1.2. Full prefix list capability for HA . . . . . . . . . . 6 3.1.3. Full prefix list capability for MR . . . . . . . . . . 7 3.2. Rationale for New Binding Options . . . . . . . . . . . . 7 3.3. Rationale for a new bit in the BU . . . . . . . . . . . . 7 3.4. Why not Alternate Standard-based Solutions? . . . . . . . 7 4. Terminology and concepts . . . . . . . . . . . . . . . . . . . 9 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. New Mobility Headers . . . . . . . . . . . . . . . . . . . 10 5.2. New Prefix Status bit . . . . . . . . . . . . . . . . . . 10 5.3. Prefix Lease Duration . . . . . . . . . . . . . . . . . . 10 5.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 12 5.6. Backward Compatibility . . . . . . . . . . . . . . . . . . 12 5.7. Basic PD flow . . . . . . . . . . . . . . . . . . . . . . 12 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Binding Update . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Binding Acknowledgement . . . . . . . . . . . . . . . . . 14 6.3. Mobile Network Prefix option . . . . . . . . . . . . . . . 15 6.4. Mobile Network Prefix Request option . . . . . . . . . . . 16 6.5. Mobile Network Prefix Confirmation option . . . . . . . . 18 7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 21 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22 9. Back End considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Kniveton & Thubert Expires February 19, 2006 [Page 2]
Internet-Draft NEMO-PD August 2005 1. Introduction The reader of that document is expected to be familiar with both the Mobile IPv6 [8] and NEMO Basic Support [10] documents. As such, it is well understood that neither protocol provides the means for provisioning the Mobile Nodes and Routers with essential parameters such as Home Address and Home Network. The process by which a router obtains a prefix dynamically is called prefix delegation. In the NEMO context, the prefix assignment is managed by an authority in the Home Network and divides it into subnets for MNPs, which are then assigned to the MRs. An MNP can be preassigned to the associated MR (e.g. manually or automatically with a provisionning system), or assigned dynamically by a server such as a DHCP Prefix Delegation server. As prescribed by [10], the HA checks whether a MR is authorized for the MNPs it claims as part of the NEMO Binding Update with the explicit prefix option. Also, MNPs have to belong to an aggregation that is permanently advertised be the HA to the routing infrastruture. Consequently, there is a strong relationship between the HA that the MR registers to and the prefixes it claims with the registration, and it makes sense for the HA to participate actively to the delegation process as well. [10] standardizes an interface between a Mobile Router and its Home Agent, as well as an interface between Home Agents. The protocol is agnostic as to how the back-end is implemented in terms of AAA, provisioning, or routing between the HAs and their IGP, and enables various forms of deployment, as described in [11]. In the same fashion, the document extends [10] for a Mobile Router to obtain its Mobile Network Prefix dynamically from its Home Agent, with no assumption about the specific back-end implementation for prefix management and service authorization. 2. Motivation for NEMO prefix delegation A number of reasons motivate adding this capability to NEMO Basic Support [10]. Mainly, there is an unanswered question as to how a MR could be dynamically assigned its prefix. In a situation where a site has many MRs, it may be impractical to assign the prefixes statically in the non-volatile memory of the MR. Consequently, we would like a mechanism for the HA to assign the prefix, similar to how a MN can bootstrap its Home Address. Kniveton & Thubert Expires February 19, 2006 [Page 3]
Internet-Draft NEMO-PD August 2005 2.1. Requirements There is thus a need for a Mobile Router to obtain dynamically one or more MNPs, linked to the HA that the MR binds with. Since the process might be used as part of a mobility scenario, there is also a need to optimize the delegation flow by limiting the number of protocol exchanges that take place for delegation and registration. Since the initial configuration may be erroneous or may need to evolve overtime, there is a need to manage the MNPs on a Mobile Router. This includes initial setting up, and synchronizing overtime. 2.2. Configuration Management The Implicit Mode of NEMO 'externalizes' the configuration of the MNPs in a MR and its HA. In the example of a static configuration, both side are initially provisioned with the association between the MRs and their MNPs, and maintain matching states between them. The failure to configure and maintain these matching states, over time, ends up in routing loops and unreachable prefixes. Tools for synchronizing MNPs in the runtime environment would be a valuable addition to [10]. 2.3. Provisioning In practice, provisioning both sides manually is error-prone and should be avoided. It can not be taken for granted, either, that in all cases, a provisioning system can be deployed with the capability to configure both the Mobile Router and the back-end in a transactional manner. Consequently, it appears necessary to provide a way to configure one side only, and have the other side learn from it in a trusted fashion and with no additional manual intervention. The Explicit Prefix mode enables a flow where the configuration of that association is not centralized at the HA but distributed to all the MRs. In fact, the HA is required to validate that the MR has been authorized for the MNPs it claims and then again, some level of information duplication might occur. In the general case, it may be easier to manage the prefix attribution in a centralized manner and have the MRs learn their prefixes dynamically. Kniveton & Thubert Expires February 19, 2006 [Page 4]
Internet-Draft NEMO-PD August 2005 2.4. Renumbering The concept of lifetime is one core idea with IPv6. Nothing is eternal. Overtime, it might be desirable to modify the configuration of the MNPs. This task, called renumbering, is especially difficult for Mobile Routers when they are geographically distributed and not be readily available to the administrators. It is thus desirable to extend [10] with a renumbering mechanism. In particular, it makes sense to provide that extension within the prefix delegation mechanism, since the operations that take place are vastly similar. 2.5. The NEMO bootstrap problem Nemo basic support expects a Mobile router to be provisioned with some information in order to start up - Home Network or Home Agent address, Home Address, Mobile Network Prefixes, security tokens, etc... In some situations, it may be impractical to actually provision all this information into the router at deployment time, and some of it has to be obtained dynamically when a system boots up, possibly through manually keying by the final user. It is absolutely required to reduce such manual keying of information to the bare minimum, like a user ID and password. And while NEMO can benefit from the MIP6 effort on the bootstrap problem (as described in the MIP6 bootstrap problem statement document [9]) for most parameters, the dynamic provisionning of Mobile Network Prefix(es) is not considered by MIPv6. 2.6. Local Mobility Management In turn, the bootstrap problem is linked to the Local Mobility Management problem; some LMM solutions such as HMIP deploy regional Home Agents from which bootstrap information has to be obtained when moving into their area of coverage; as opposed to the initial bootstrap problem which occurs at the first startup of a device and may not happen again for an extensive period of time, LMM is tied to movement, and could be quite frequent. 3. Rationale This section details the rationale behind some of the design decisions that lead to this solution. Kniveton & Thubert Expires February 19, 2006 [Page 5]
Internet-Draft NEMO-PD August 2005 3.1. Which capabilities? 3.1.1. Prefix Request capability The minimum capability that could be envisionned for a NEMO Prefix Delegation mechanism is for a MR to request a new prefix in a Binding Update and for the HA to provide the prefix as part of the Binding Acknowledgement. Then the Mobile Router installs the newly obtained prefix on the interface that needs it, and moves forward in implicit or explicit mode. 3.1.2. Full prefix list capability for HA The capability to request a new prefix is sufficient in a basic delegation flow where a MR that is already bound and -hopefully- synchronized with its HA in terms of prefix ownership; it is also required in some bootstrapping and renumbering flows; but it is hardly sufficient in order to synchronize the MR and the HA states regarding MNPs: Bootstrapping: At bootstrapping time, the MR needs the list of all the prefixes that are attributed in order to populate its interfaces. Asking them one by one and having to make a distinction between already allocated prefixes versus dynamic allocation would make the flow much more complex. Expired prefixes: That list is also needed for a MR in order to synchronize its current configuration with that of the HA. In particular, it is used for a MR to discover when the HA does not have the associated states in place for one of its MNPs. This may happen for some configuration error or because the prefix has expired, and the only way to know is if the prefix is missing in a full list of all prefixes by the HA. Newly allocated prefixes: Finally, the list is needed for a MR to learn new prefixes that would be attributed in runtime, and to install those prefixes on its interfaces. Once the new prefixes are installed, it is required that the MR confirms its use of the prefixes so that the HA can set up routing in a loopfree fashion. So, the capability for a HA to list all the prefixes for a MR is needed for the MR to realize that the HA is missing some state and eventually to try to get the missing prefixes in explicit mode. This may happen on demand by the MR (e.g. at bootstrap time or binding creation time), or whenever the HA needs to communicate a change, such as a shortened or expired MNP lifetime. Kniveton & Thubert Expires February 19, 2006 [Page 6]
Internet-Draft NEMO-PD August 2005 3.1.3. Full prefix list capability for MR So the capability for a HA to list all the prefixes is not sufficient, as the HA is not the repository of that knowledge. It might be simpler for the MR to dump its own list of prefixes and have the HA check the list, even for implicit prefixes. 3.2. Rationale for New Binding Options Associated with the capability to request a new prefix, it seems relevant to specify whether the prefix is for implicit or explicit mode, or if its lifetime is limited to that of the binding cache or not. Other fields such as the prefix length are needed as well. In order to convey that information, an optional field is needed in the BU. It is not desirable to extend the existing NEMO MNP option, which carries a prefix that is not needed. As a result, we propose a new option type, the MNP Request Option. Associated with the capability for a HA to list all the prefixes for a MR, one critical piece of information is needed that would not fit in the NEMO MNP option. Again, we propose a new option for the Binding Acknowledgement, the MNP Confirmation Option. 3.3. Rationale for a new bit in the BU A single bit in the BU is enough for a MR to request a full list of prefixes from the HA, if we do not need a filter of any sort? It is important that the HA set that bit in its full list of prefixes in order to differentiate between an empty list (there is no prefix for that MR) and no list (HA is not providing a list in that BA). 3.4. Why not Alternate Standard-based Solutions? Proposing a new, specific solution might seem irrelevant when a standard, generic mechanism already exists: in this case, the DHCPv6 Prefix Delegation. In fact, it is possible for the Home Agent to act as a DHCPv6PD Delegating Router. This solution presents the advantage of reusing existing standard flows from RFC3633 [6]. Yet, in a deployment where the MNPs are preassigned to the MR, a AAA server, interfacing with the HA, and eventually coupled with a provisioning system in its back-end, can provide the required service for assigning and authorizing the prefixes to the MRs; in such a case, the value of implementing a DHCPv6PD server is highly arguable. It is more generic to let the HA handle the backend interfaces on Kniveton & Thubert Expires February 19, 2006 [Page 7]
Internet-Draft NEMO-PD August 2005 behalf of the MR and expose a consistent NEMO interface for all deployments. In more detail, a DHCPv6PD based solution presents a number of inconveniences: Delegating Router: A collocated Delegating Router function may not be available for all implementation of NEMO Home Agent. In particular, some implementations are server based. Operational overhead: Depending on the mechanism that is used to attribute the MNPs to the MRs, the Delegating function, even if available, might be a costly overhead. Rather, an embedded, back- end agnostic flow might be a desirable option. Movement overhead: Some flows, for instance local mobility management, might require a prefix delegation as part of the handling of the movement. Segregating the delegation from the binding adds a round trip delay to the recovery from the movement. Binding Lifetime: It might be useful to associate implicitly the lifetime of a delegated prefix with that of the binding. This pleads for a design that places the Home Agent function in the flow by construction. Authentication Mechanism: While NEMO basic Support protects its own flows, there is no mandate to secure the tunneled packets. Back-end interaction: If a prefix is attributed to a MR for a duration that exceeds that of its binding, this information needs to be shared with all HAs, at least for authorization purposes. This requires a specific backend integration that does not exist in the Prefix Delegation Function, for instance via a AAA server. Kniveton & Thubert Expires February 19, 2006 [Page 8]
Internet-Draft NEMO-PD August 2005 4. Terminology and concepts The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC2119 [1]. Most of the mobility related terms used in this document are defined in the Mobility Related Terminology document [7] and in the Mobile IPv6 specification [8]. Additionally, some terms were created or extended for NEMO. These specific terms are defined in the Mobile Network Terminology document [12] This draft introduces the following definitions: Mobile Network Prefix Request (MNPReq) Option: A new optional field in the MIPv6 Mobility Header for use with the Binding Update message, as described further in this document. This field is set by a MR to request the delegation of a new prefix as a Mobile Network Prefix. Mobile Network Prefix Confirmation (MNPConf) Option: A new optional field in the MIP6 Mobility Header for use with the Binding Acknowledgement message, as described further in this document. transient prefix: A prefix that is attributed to a Mobile Router in association with a binding cache entry. If the BCE is removed, the prefix is freed. Persistent prefix: A prefix that is attributed to a Mobile Router for a period of time that does not depend on the existence of a binding cache entry. Kniveton & Thubert Expires February 19, 2006 [Page 9]
Internet-Draft NEMO-PD August 2005 5. Overview 5.1. New Mobility Headers This paper introduces a new option to the MIP6 Mobility Header, for use with the Binding Update message, the Mobile Network Prefix Request Option. A MR may include one or more MNPReq option(s) in a Binding Update message at any time, in order to obtain additional prefixes. This paper introduces another new option to the MIP6 Mobility Header, for use with the Binding Acknowledgement message, the Mobile Network Prefix Confirmation Option. An HA will include one or more MNPConf option(s) in a Binding Acknowledgement message, either in response to a Mobile Network Prefix Request Option, or for its own purposes, for instance in order inform a MR about a change in the lifetime of an MNP. 5.2. New Prefix Status bit Finally, this paper introduces a new bit to both the MIP6 Binding Update and Binding Acknowledgement, the Prefix Status bit. A MR may include the Prefix Status bit in a Binding Update message at any time, either in order to get its initial configuration, or to check whether its current configuration matches that of the Home Agent - which might be particularily useful in implicit mode. When the Prefix Status bit is set in the BU, the Acknowledge bit MUST be set as well. The HA MAY set the Prefix Status bit in the Binding Acknowledgement even if it was not set by the MR in the Binding Update; the other way around, if the Prefix Status bit was set in the BU, then the HA MUST echo it in the BA. When setting the Prefix Status bit, the HA also lists all the prefixes associated to that Mobile Router using Mobile Network Prefix options. 5.3. Prefix Lease Duration A prefix may be obtained for the duration of the binding; in this case, the prefix is called 'transient'. On the other hand, a prefix can be assigned to a MR for a duration that is independent of a BCE lifecycle, and that is controlled externally by the HA administrator; in that case, the prefix is called 'persistent'. A flag in the MNPReq option indicates the expectation of the MR in terms of persistence for the requested prefix. If the HA can not fulfill that expectation, it must reject the binding with a negative status. Kniveton & Thubert Expires February 19, 2006 [Page 10]
Internet-Draft NEMO-PD August 2005 The lease of a transient prefix expires with the MR Binding Cache Entry; as a result, transient prefixes can be managed internally by a HA, for instance using a local pool that forms an aggregation owned by the HA. On the other hand, some of the information about a persistent prefix has to be shared between the HAs in a Home Network and the back-end systems that enable the authorization. This is required to allow a Mobile Router to rebind, with the same persistent prefixes, to a different Home Agent, after a period of inactivity. It is possible to assign a persistent prefix dynamically at the time of the delegation; but the persistent mode also enables the preassignment of an MNP to an MR, for instance by provisionning a AAA server with the necessary information for each Mobile Router. 5.4. Protocol Flow The operation of prefix delegation has a slightly different semantic than home address delegation under Mobile IPv6. If the HA or another router allowed the routing for an address to be changed, the worst possible effect would be unauthorized access, and possibly stealing a message flow from one node. So we protect against this using reverse routability. On the other hand, if the routing for an entire prefix were changed in a malevolent manner, traffic for a large portion of a site could be lost or redirected. Therefore, it is important to focus more closely on exactly how the authorization works for delegating that prefix. There is a 4-step flow for dynamic prefix delegation that must be followed: 1. Provisioning -- The administrative entity managing the address space for a site must allocate, either manually or automatically, a prefix to be used by the MR. This could be done when the MR's account with HoA and security association is established, or it could be done at the time of the delegation request. This provisioning must be stored in some permanent location accessible by the HA, since it is necessary to verify autorization for an MR to use a MNP. 2. Request -- The MR must signal that it would like a prefix to be delegated by the HA. Kniveton & Thubert Expires February 19, 2006 [Page 11]
Internet-Draft NEMO-PD August 2005 3. Authorization -- The HA must check that the MR is allowed to use a certain prefix. At this point, the HA does a lookup operation, or if this is a dynamic prefix that has not yet been allocated, the HA does step (1) and provisions a prefix for a certain time period. 4. Delegation -- The HA signals to the MR that it is authorized to use a certain prefix for a certain period of time. For simplicity, it should be assumed that this lifetime is the length of the MR's binding, since it is not useful for the MR to continue to have a binding if its MNP has expired. It is possible the lifetime is longer (i.e. infinity if it is a (statically provisioned) persistent prefix). 5.5. Renumbering It is possible to redeploy the persistent prefix space, for instance if Home is being renumbered, or if a dynamically attributed prefix has not been bound for a long period of time. In that case, the HA rejects a new binding as the routing states can not be set up, and the MR has to request one or more new persistent prefix(es). 5.6. Backward Compatibility An HA that does not support this extension will ignore the unrecognized option. If the HA supports this extension, a binding update with the MNPReq option can be accepted per the NEMO basic support checks: after the packet is checked according to the NEMO spec, the HA processes the option(s). 5.7. Basic PD flow When a MR needs an additional prefix to populate an interface, it adds an MNPreq option to its Binding update message. If the HA can obtain the required prefix for that MR, it operates following the NEMO basic support, in either Implicit Mode or Explicit Mode, using the prefixes as if they were received with the BU. This includes setting up the routing states and responding with a positive or a negative status. If the routing states are established correctly and the HA responds with a positive status, then the HA adds the prefix list to the binding ack message. From that point on, both the MR and the HA operate as prescribed by the NEMO basic standard, either in implicit or explicit mode. Kniveton & Thubert Expires February 19, 2006 [Page 12]
Internet-Draft NEMO-PD August 2005 6. Message Formats 6.1. Binding Update A new flag (S) is included in the Binding Update to indicate to the Home Agent that the MR wishes to get the full list of all prefixes that are already assigned to it. The rest of the Binding Update format remains the same as defined in [10]. When the (S) bit is set, the (R) and and (A) bits MUST be set as well. 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|S| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Status (S) The Prefix Status (S) bit is set by a MR to request the full list of all prefixes that are already assigned to it Kniveton & Thubert Expires February 19, 2006 [Page 13]
Internet-Draft NEMO-PD August 2005 6.2. Binding Acknowledgement A new flag (S) is included in the Binding Acknowledgement to indicate to the Mobile Router that the Home Agent is providing the complete list of prefixes that are already assigned to the MR. The rest of the Binding Acknowledgement format remains the same as defined in [10]. When the (S) bit is set, the (R) bit MUST be set as well. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|S|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Status (S) The Prefix Status (S) bit is set by a HA to indicate that it provides the full list of all prefixes that are already assigned to the MR. Kniveton & Thubert Expires February 19, 2006 [Page 14]
Internet-Draft NEMO-PD August 2005 6.3. Mobile Network Prefix option New flags are included in the Mobile Network Prefix option defined in [10]. This allows the option to cover all the prefixes owned by the MR, including those that are managed using the implicit prefix mode. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |P|I|D|Reserved1| Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The new flags introduced by this specification are: Persistent (P) The (P) bit is set if the prefix is expected to be persistently assigned to the MR beyond the lifetime of the associated binding. Implicit (I) The (I) bit is set if the prefix is expected to be assigned to and routed via the MR even if the prefix is not listed in an explicit mode BU. Delegated (D) The (D) bit is set if the prefix was obtained using the Delegation Mechanism as described in this specification. It is used to acknowledge that a previously delegated prefix is actually installed and routable via the Mobile Router. Alignment: Must be 8n + 4. Kniveton & Thubert Expires February 19, 2006 [Page 15]
Internet-Draft NEMO-PD August 2005 6.4. Mobile Network Prefix Request option This new option is included in the Binding Update to indicate to the Home Agent that the MR wishes to get a new prefix assigned to it for use as a MNP. When this option is present, the (S) MAY be set as well in the BU in order to get the full list of all prefixes. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |P|I| Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CorID | Reserved2 | Prefix type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBA Length: 8-bit unsigned integer indicating the length in octets of the option excluding the type and length fields. Set to 6. Prefix Length: 8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option (valid range isno 1..128). Persistent (P): The (P) bit is set if the prefix that is requested to be persistently assigned to the MR. Implicit (I): The (I) bit is set if the prefix that is requested to be assigned to, and routed via the MR, even if the prefix was not listed in an explicit mode BU. CorId: A Correlator that is set by the MR in order to associate a MNP request with the prefix given in the confirmation. There can be at most one active prefix associated with each Correlator. This mechanism ensures the uniqueness of the allocation of a prefix, should either the BU or the BA be lost in transit. Prefix Type: Indicates the type of prefix that is requested: 0: None Specified Kniveton & Thubert Expires February 19, 2006 [Page 16]
Internet-Draft NEMO-PD August 2005 1: Private 2: Unique Local 3: Global Kniveton & Thubert Expires February 19, 2006 [Page 17]
Internet-Draft NEMO-PD August 2005 6.5. Mobile Network Prefix Confirmation option This new option is included in the Binding Acknowledgment to indicate to the Mobile Router whether a new prefix was assigned, and what it is. When this option is present, the (S) MAY be set as well in the BU in order to indicate that the complete list of prefixes is attached. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |P|I|D|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CorID | Status | Prefix type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Length: 8-bit unsigned integer indicating the length in octets of the option excluding the type and length fields. Set to 26. Prefix Length: 8-bit unsigned integer indicating the length of the IPv6 prefix contained in the option (valid range is 1..128). Persistent (P): The (P) bit is set if the prefix is persistently assigned to the MR. Implicit (I): The (I) bit is set if the prefix is assigned to and routed via the MR even if the prefix is not listed in explicit mode BU. Kniveton & Thubert Expires February 19, 2006 [Page 18]
Internet-Draft NEMO-PD August 2005 Delegated (D): The (D) bit is set if the prefix was obtained using a the Delegation Mechanism described in this specification. CorId: If the (D) bit is set, this option contains the prefix being delegated in response to the MNPReq containing the same Correlator If the (D) bit is not set, the Correlator value is unused. Status: Indicates what happened in response to the corresponding request: 0: OK (Route successfully created for designated prefix) 1: Prefix is not currently registered 2: Mobile Network Option sent from non-MR 3: Invalid prefix (not part of valid address space) 4: Prefix not owned by this domain/link (HA can not delegate) 5: Prefix not owned by MR which sent this MNO 6: Could not create route / insufficient resources 7: Policy does not allow allocation of PrefixLen. Prefix allocated as shown, with longer prefixlen. 8: Persistent prefixes are not supported. 9: Transient prefixes are not supported. 10: NEMO Implicit mode is not supported. Prefix Type: Indicates the type of prefix enclosed: 0: None Specified 1: Private 2: Unique Local 3: Global Valid Lifetime: 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for being installed on an MR ingress interface. A value of all one bits (0xffffffff) represents infinity. The Valid Lifetime is also used by RFC2461 [3] and RFC2462 [4], and must be Kniveton & Thubert Expires February 19, 2006 [Page 19]
Internet-Draft NEMO-PD August 2005 used in the RAs sent over the MR ingress interface for that prefix. Mobile Network Prefix: A 16 byte field containing the Mobile Network Prefix. Kniveton & Thubert Expires February 19, 2006 [Page 20]
Internet-Draft NEMO-PD August 2005 7. Mobile Router Operation When the Mobile Router has determined the Home Address it is going to use and the Home Agent it is going to register with, it constructs a Binding Update with the R bit set. At this time, the Mobile Router will add either a MNP Option, or a MNPReq Option, or both, to the BU. If the Mobile Router already has one or more persistent MNPs and does not need more, it simply adds a MNP Option. If the MR is not pre- configured with a persistent prefix, it may request either a persistent or transient prefix. If more than one prefix is needed, than more than one can be requested by simply appending multiple MNPReq Options to the BU. When the Binding Acknowledgment is received back from the HA, the MR will process it as normal, and when the MNPC Option(s) are encountered, it should verify that it sent a request using the included CorID, and then react according to the status field, as follows: 0: Begin forwarding this prefix and using it in Router Advertisements as described in NEMO. If the P bit is set and the MR supports persisten prefixes, add it to the list of prefixes. 1: (unknown) 2: Contact system administrator. 3: MR may try again with a different prefix. 4: MR may try dynamic home agent discovery to contact correct HA. 5: MR should retry, with P bit turned off, to obtain a transient prefix. 6: MR should try another HA, or wait and try again later. 7: Same response as for status 0. Kniveton & Thubert Expires February 19, 2006 [Page 21]
Internet-Draft NEMO-PD August 2005 8. Home Agent Operation The Home Agent receives a Binding Update from the Mobile Router, it processes the BU as described in the Mobile IPv6 protocol [8] and NEMO basic support [10]. When it arrives at a MNPO (assuming the Binding Update is valid as already processed), it takes steps as follows: Step 1. Verify that the MR is allowed to be allocated a prefix of the requested type and allocate one. Step 2. If the request is for a persistent prefix, save the allocation in the back-end permanent store. Step 3. Set up routing for this prefix. If the BU was of lifetime 0, do not set up routing for this prefix, but simply allocate it. Step 4. For each MNPR option, respond with a MNPC option in the BAck. If the MNPR was received in a BU from a non-MR, send status 2 and 0s for prefix information. Otherwise, send a response with result code 0, and filling in the appropriate prefix information. If the Binding Update contains an S bit, the Home Agent includes a Mobile Network Prefix Option for each prefix the Home Agent believes is assigned to the Mobile Router. After these steps are followed, the Home Agent continues its operation as normal, until another MNPO or MNPR is received. Kniveton & Thubert Expires February 19, 2006 [Page 22]
Internet-Draft NEMO-PD August 2005 9. Back End considerations Kniveton & Thubert Expires February 19, 2006 [Page 23]
Internet-Draft NEMO-PD August 2005 10. Security Considerations 11. Acknowledgements The authors wish to thank: Pekka Paakkonen and Juhani Latvakoski from VTT Electronics for their initial work on the matter. Kniveton & Thubert Expires February 19, 2006 [Page 24]
Internet-Draft NEMO-PD August 2005 12. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [4] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [6] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [7] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [9] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-03 (work in progress), July 2005. [10] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [11] Thubert, P., "NEMO Home Network models", draft-ietf-nemo-home-network-models-04 (work in progress), June 2005. [12] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-03 (work in progress), February 2005. Kniveton & Thubert Expires February 19, 2006 [Page 25]
Internet-Draft NEMO-PD August 2005 Authors' Addresses T.J. Kniveton Nokia, Inc. 313 Fairchild Dr. Building B-223 Mountain View 94043 USA Phone: +1 650 625 2025 Email: tj@kniveton.com Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com Kniveton & Thubert Expires February 19, 2006 [Page 26]
Internet-Draft NEMO-PD August 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kniveton & Thubert Expires February 19, 2006 [Page 27]