< draft-ietf-nemo-prefix-delegation-00.txt   draft-ietf-nemo-prefix-delegation-01.txt >
Network Mobility T. Kniveton Network Mobility P. Thubert
Internet-Draft Nokia Internet-Draft Cisco
Expires: February 19, 2006 P. Thubert Expires: May 21, 2007 TJ. Kniveton
Cisco Nokia
August 18, 2005 November 17, 2006
Mobile Network Prefix Delegation Mobile Network Prefix Delegation
draft-ietf-nemo-prefix-delegation-00 draft-ietf-nemo-prefix-delegation-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 19, 2006. This Internet-Draft will expire on May 21, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This paper extends the Nemo Basic Support [10] for a Mobile Router to This paper extends the Nemo Basic Support [9] for a Mobile Router to
synchronize its Mobile Network Prefixes with its Home Agents and synchronize its Mobile Network Prefixes with its Home Agents and
obtain new ones dynamically. The proposed prefix delegation obtain new ones dynamically.
mechanism is agnostic to the way the prefixes are managed and
provisioned at the Home Agent; it might be used for bootstrapping, The proposed prefix delegation mechanism is agnostic to the way the
resynchronization at binding creation or after a loss of states (eg back end is implemented; it enables bootstrapping, resynchronization
MR reboot), MNP Renumbering, and configuration checking for loop at binding creation or after a loss of states (eg MR reboot), MNP
avoidance. Renumbering, and configuration checking for loop avoidance.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation for NEMO prefix delegation . . . . . . . . . . . . 3 2. motivation for a NEMO prefix delegation . . . . . . . . . . . 3
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Configuration management . . . . . . . . . . . . . . . . . 4
2.2. Configuration Management . . . . . . . . . . . . . . . . . 4 2.2 Provisioning . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 The NEMO bootstrap problem . . . . . . . . . . . . . . . . 4
2.5. The NEMO bootstrap problem . . . . . . . . . . . . . . . . 5 2.5 Local Mobility Management . . . . . . . . . . . . . . . . 5
2.6. Local Mobility Management . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Which capabilities? . . . . . . . . . . . . . . . . . . . 6 4.1 Which capabilities? . . . . . . . . . . . . . . . . . . . 6
3.1.1. Prefix Request capability . . . . . . . . . . . . . . 6 4.1.1 Prefix Request capability . . . . . . . . . . . . . . 6
3.1.2. Full prefix list capability for HA . . . . . . . . . . 6 4.1.2 Full prefix list capability for HA . . . . . . . . . . 6
3.1.3. Full prefix list capability for MR . . . . . . . . . . 7 4.1.3 Full prefix list capability for MR . . . . . . . . . . 7
3.2. Rationale for New Binding Options . . . . . . . . . . . . 7 4.2 Rationale for new Binding options . . . . . . . . . . . . 7
3.3. Rationale for a new bit in the BU . . . . . . . . . . . . 7 4.3 Rationale for a new bit in the BU . . . . . . . . . . . . 7
3.4. Why not Alternate Standard-based Solutions? . . . . . . . 7 4.4 Why not Alternate standard based solutions? . . . . . . . 7
4. Terminology and concepts . . . . . . . . . . . . . . . . . . . 9 5. Terminology and concepts . . . . . . . . . . . . . . . . . . . 9
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. New Mobility Headers . . . . . . . . . . . . . . . . . . . 10 6.1 New mobility Headers . . . . . . . . . . . . . . . . . . . 10
5.2. New Prefix Status bit . . . . . . . . . . . . . . . . . . 10 6.2 New Prefix Status bit . . . . . . . . . . . . . . . . . . 10
5.3. Prefix Lease Duration . . . . . . . . . . . . . . . . . . 10 6.3 Prefix lease duration . . . . . . . . . . . . . . . . . . 10
5.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 11 6.4 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 11
5.5. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 12 6.5 backward compatibility . . . . . . . . . . . . . . . . . . 11
5.6. Backward Compatibility . . . . . . . . . . . . . . . . . . 12 6.6 PD flow . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.7. Basic PD flow . . . . . . . . . . . . . . . . . . . . . . 12 7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 7.1 Binding Update . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Binding Update . . . . . . . . . . . . . . . . . . . . . . 13 7.2 Binding Acknowledgement . . . . . . . . . . . . . . . . . 13
6.2. Binding Acknowledgement . . . . . . . . . . . . . . . . . 14 7.3 Mobile Network Prefix option . . . . . . . . . . . . . . . 14
6.3. Mobile Network Prefix option . . . . . . . . . . . . . . . 15 7.4 Mobile Network Prefix request option . . . . . . . . . . . 15
6.4. Mobile Network Prefix Request option . . . . . . . . . . . 16 7.5 Mobile Network Prefix Confirm option . . . . . . . . . . . 17
6.5. Mobile Network Prefix Confirmation option . . . . . . . . 18 8. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 19
7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 21 9. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 20
8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22 10. Back End considerations . . . . . . . . . . . . . . . . . . 21
9. Back End considerations . . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 14.1 Normative Reference . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 27 14.2 Informative Reference . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 25
1. Introduction 1. Introduction
The reader of that document is expected to be familiar with both the 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 Mobile IPv6 [8] and NEMO Basic Support [9] documents. As such, it is
is well understood that neither protocol provides the means for well-understood that neither protocol provides the means for
provisioning the Mobile Nodes and Routers with essential parameters provisioning the Mobile Nodes and Routers with essential parameters
such as Home Address and Home Network. such as Home Address and Home Network.
The process by which a router obtains a prefix dynamically is called The process by which a router obtains a prefix dynamically is called
prefix delegation. In the NEMO context, the prefix assignment is prefix delegation. In the NEMO context, the prefix is managed by an
managed by an authority in the Home Network and divides it into authority than owns the Home Network and subnets it into MNPs that it
subnets for MNPs, which are then assigned to the MRs. An MNP can be assigns to the MRs. An MNP can be preassigned to the associated MR
preassigned to the associated MR (e.g. manually or automatically with (e.g. manually or automatically with a provisionning system), or
a provisionning system), or assigned dynamically by a server such as assigned dynamically by a server such as a DHCP Prefix Delegation
a DHCP Prefix Delegation server. server.
As prescribed by [10], the HA checks whether a MR is authorized for As prescribed by [9], the HA checks whether a MR is authorized for
the MNPs it claims as part of the NEMO Binding Update with the the MNPs it claims as part of the NEMO Binding Update with the
explicit prefix option. Also, MNPs have to belong to an aggregation explicit prefix option. Also, MNPs have to belong to an aggregation
that is permanently advertised be the HA to the routing that is permanently advertised be the HA to the routing
infrastruture. Consequently, there is a strong relationship between infrastruture. Consequently, there is a strong relationship between
the HA that the MR registers to and the prefixes it claims with the 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 registration, and it makes sense for the HA to participate actively
to the delegation process as well. to the delegation process as well.
[10] standardizes an interface between a Mobile Router and its Home [9] standardizes an interface between a Mobile Router and its Home
Agent, as well as an interface between Home Agents. The protocol is 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, agnostic as to how the back end is implemented in terms of AAA,
provisioning, or routing between the HAs and their IGP, and enables provisioning, or routing between the HAs and their IGP, and enables
various forms of deployment, as described in [11]. various forms of deployment, as described in [14].
In the same fashion, the document extends [10] for a Mobile Router to In a same fashion, the document extends [9] for a Mobile Router to
obtain its Mobile Network Prefix dynamically from its Home Agent, obtain its Mobile Network Prefix dynamically from its Home Agent,
with no assumption about the specific back-end implementation for with no assumption about the specific back-end implementation for
prefix management and service authorization. prefix management and service authorization.
2. Motivation for NEMO prefix delegation 2. motivation for a NEMO prefix delegation
A number of reasons motivate adding this capability to NEMO Basic A number of reasons plead for adding this capability to NEMO NEMO
Support [10]. Basic Support [9].
Mainly, there is an unanswered question as to how a MR could be Mainly, there is an unanswered question as to how a MR could be
dynamically assigned its prefix. In a situation where a site has dynamically assigned its prefix. In a situation where a site has
many MRs, it may be impractical to assign the prefixes statically in many MRs, it may be impractical to assign the prefixes statically in
the non-volatile memory of the MR. Consequently, we would like a 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 mechanism for the HA to assign the prefix, similar to how a MN can
bootstrap its Home Address. bootstrap its Home Address.
2.1. Requirements 2.1 Configuration management
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 The Implicit Mode of the NEMO Basic Support 'externalizes' the
MNPs in a MR and its HA. In the example of a static configuration, configuration of the MNPs in a MR and its HA. In the example of a
both side are initially provisioned with the association between the static configuration, both side are initially provisioned with the
MRs and their MNPs, and maintain matching states between them. association between the MRs and their MNPs, and maintain matching
states between them.
The failure to configure and maintain these matching states, over The failure to configure and maintain these matching states overtime
time, ends up in routing loops and unreachable prefixes. Tools for ends up in routing loops and unreachable prefixes. Tools for
synchronizing MNPs in the runtime environment would be a valuable synchronizing MNPs in runtime would be a valuable addition to [9].
addition to [10].
2.3. Provisioning 2.2 Provisioning
In practice, provisioning both sides manually is error-prone and In practice, provisioning both sides manually is error-prone and
should be avoided. It can not be taken for granted, either, that in should be avoided. It can not be taken for granted, either, that in
all cases, a provisioning system can be deployed with the capability all cases, a provisioning system can be deployed with the capability
to configure both the Mobile Router and the back-end in a to configure both the Mobile Router and the back-end in a
transactional manner. transactional manner. Consequently, it appears necessary to provide
a way to configure one side only, and have the other side learn from
Consequently, it appears necessary to provide a way to configure one it in a trusted fashion and with no additional manual intervention.
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 The Explicit Prefix mode enables a flow where the configuration of
that association is not centralized at the HA but distributed to all 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 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 been authorized for the MNPs it claims and then again, some level of
information duplication might occur. information duplication might occur.
In the general case, it may be easier to manage the prefix In the general case, it may be easier to manage the prefix
attribution in a centralized manner and have the MRs learn their attribution in a centralized manner and have the MRs learn their
prefixes dynamically. prefixes dynamically.
2.4. Renumbering 2.3 Renumbering
The concept of lifetime is one core idea with IPv6. Nothing is The concept of lifetime is one core idea with IPv6. Nothing is
eternal. Overtime, it might be desirable to modify the configuration eternal. Overtime, it might be desirable to modify the configuration
of the MNPs. This task, called renumbering, is especially difficult of the MNPs. This task, called renumbering, is especially difficult
for Mobile Routers when they are geographically distributed and not for Mobile Routers when they are geographically distributed and not
be readily available to the administrators. be readily available to the administrators.
It is thus desirable to extend [10] with a renumbering mechanism. In It is thus desirable to extend [9] with a renumbering mechanism. In
particular, it makes sense to provide that extension within the particular, it makes sense to provide that extension within the
prefix delegation mechanism, since the operations that take place are prefix delegation mechanism, since the operations that take place are
vastly similar. vastly similar.
2.5. The NEMO bootstrap problem 2.4 The NEMO bootstrap problem
Nemo basic support expects a Mobile router to be provisioned with Nemo basic support expects a Mobile router to be provisioned with
some information in order to start up - Home Network or Home Agent some information in order to start up - Home Network or Home Agent
address, Home Address, Mobile Network Prefixes, security tokens, address, Home Address, Mobile Network Prefixes, security tokens,
etc... etc...
In some situations, it may be impractical to actually provision all In some situations, it may be impractical to actually provision all
this information into the router at deployment time, and some of it this information into the router at deployment time, and some of it
has to be obtained dynamically when a system boots up, possibly has to be obtained dynamically when a system boots up, possibly
through manually keying by the final user. through manually keying by the final user.
It is absolutely required to reduce such manual keying of information 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 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 benefit from the MIP6 effort on the bootstrap problem (as described
in the MIP6 bootstrap problem statement document [9]) for most in the MIP6 bootstrap problem statement document [13]) for most
parameters, the dynamic provisionning of Mobile Network Prefix(es) is parameters, the dynamic provisionning of Mobile Network Prefix(es) is
not considered by MIPv6. not considered by MIPv6.
2.6. Local Mobility Management 2.5 Local Mobility Management
In turn, the bootstrap problem is linked to the Local Mobility In turn, the bootstrap problem is linked to the Local Mobility
Management problem; some LMM solutions such as HMIP deploy regional Management problem; some LMM solutions such as HMIP deploy regional
Home Agents from which bootstrap information has to be obtained when Home Agents from which bootstrap information has to be obtained when
moving into their area of coverage; as opposed to the initial moving into their area of coverage; as opposed to the initial
bootstrap problem which occurs at the first startup of a device and 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 may not happen again for an extensive period of time, LMM is tied to
movement, and could be quite frequent. movement, and could be quite frequent.
3. Rationale 3. 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 may 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.
4. Rationale
This section details the rationale behind some of the design This section details the rationale behind some of the design
decisions that lead to this solution. decisions that lead to this solution.
3.1. Which capabilities? 4.1 Which capabilities?
3.1.1. Prefix Request capability 4.1.1 Prefix Request capability
The minimum capability that could be envisionned for a NEMO Prefix 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 Delegation mechanism is for a MR to request for a new prefix in a
Update and for the HA to provide the prefix as part of the Binding Binding Update and for the HA to provide the prefix as part of the
Acknowledgement. Then the Mobile Router installs the newly obtained Binding Acknowledgement. Then the Mobile Router installs the newly
prefix on the interface that needs it, and moves forward in implicit obtained prefix on the interface that needs it, and moves forward in
or explicit mode. implicit or explicit mode.
3.1.2. Full prefix list capability for HA 4.1.2 Full prefix list capability for HA
The capability to request a new prefix is sufficient in a basic The capability to request a new prefix is sufficient in a basic
delegation flow where a MR that is already bound and -hopefully- delegation flow where a MR that is already bound and -hopefully-
synchronized with its HA in terms of prefix ownership; it is also synchronized with its HA in terms of prefix ownership; it is also
required in some bootstrapping and renumbering flows; but it is required in some bootstrapping and renumbering flows; but it is
hardly sufficient in order to synchronize the MR and the HA states hardly sufficient in order to synchronize the MR and the HA states
regarding MNPs: regarding MNPs:
Bootstrapping: At bootstrapping time, the MR needs the list of all Bootstrapping: At bootstrapping time, the MR needs the list of all
the prefixes that are attributed in order to populate its the prefixes that are attributed in order to populate its
skipping to change at page 6, line 45 skipping to change at page 6, line 45
happen for some configuration error or because the prefix has 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 expired, and the only way to know is if the prefix is missing in a
full list of all prefixes by the HA. full list of all prefixes by the HA.
Newly allocated prefixes: Finally, the list is needed for a MR to Newly allocated prefixes: Finally, the list is needed for a MR to
learn new prefixes that would be attributed in runtime, and to learn new prefixes that would be attributed in runtime, and to
install those prefixes on its interfaces. Once the new prefixes install those prefixes on its interfaces. Once the new prefixes
are installed, it is required that the MR confirms its use of the 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. 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 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 needed for the MR to realize that the HA is missing some states and
eventually to try to get the missing prefixes in explicit mode. This 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 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, creation time), or whenever the HA needs to communicate about a
such as a shortened or expired MNP lifetime. change, such as a shortened or expired MNP lifetime.
3.1.3. Full prefix list capability for MR 4.1.3 Full prefix list capability for MR
So the capability for a HA to list all the prefixes is not So the capability for a HA to list all the prefixes is not sufficient
sufficient, as the HA is not the repository of that knowledge. It is the HA is not the repository of that knowledge. It might be
might be simpler for the MR to dump its own list of prefixes and have simpler for the MR to dump its own list of prefixes and have the HA
the HA check the list, even for implicit prefixes. check the list, even for implicit prefixes.
3.2. Rationale for New Binding Options 4.2 Rationale for new Binding options
Associated with the capability to request a new prefix, it seems Associated to the capability to request a new prefix, it seems
relevant to specify whether the prefix is for implicit or explicit 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 mode, or if its lifetime is limited with that of the binding cache or
not. Other fields such as the prefix length are needed as well. In 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 order to convey that information, an optional field is needed in the
BU. BU.
It is not desirable to extend the existing NEMO MNP option, which 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 carries a prefix that is not needed, though. As a result, we propose
option type, the MNP Request Option. a new option type, the MNP request option.
Associated with the capability for a HA to list all the prefixes for Associated to the capability for a HA to list all the prefixes for a
a MR, one critical piece of information is needed that would not fit MR, one critical information is needed, that would not fit in the
in the NEMO MNP option. Again, we propose a new option for the NEMO MNP option. Again, we propose a new option for the Binding
Binding Acknowledgement, the MNP Confirmation Option. Acknowledgement, the MNP confirm option.
3.3. Rationale for a new bit in the BU 4.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 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? 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 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 in order to differentiate between an empty list (there's no prefix
for that MR) and no list (HA is not providing a list in that BA). for that MR) and no list (HA is not providing a list in that BA).
3.4. Why not Alternate Standard-based Solutions? 4.4 Why not Alternate standard based solutions?
Proposing a new, specific solution might seem irrelevant when a Proposing a new, specific solution might seem irrelevant when a
standard, generic mechanism already exists: in this case, the DHCPv6 standard, generic mechanism already exist, in this case the DHCPv6
Prefix Delegation. In fact, it is possible for the Home Agent to act Prefix Delegation. In fact, it is possible for the Home Agent to act
as a DHCPv6PD Delegating Router. This solution presents the as a DHCPv6PD Delegating Router. This solution presents the
advantage of reusing existing standard flows from RFC3633 [6]. advantage of reusing existing standard flows from RFC3633 [6].
Yet, in a deployment where the MNPs are preassigned to the MR, a AAA Yet, in a deployment where the MNPs are preassigned to the MR, a AAA
server, interfacing with the HA, and eventually coupled with a server, interfacing with the HA, and eventually coupled with a
provisioning system in its back-end, can provide the required service provisioning system in its back end, can provide the required service
for assigning and authorizing the prefixes to the MRs; in such a for assigning and authorizing the prefixes to the MRs; in such a
case, the value of implementing a DHCPv6PD server is highly arguable. case, the value of implementing a DHCPv6PD server is highly arguable.
It is more generic to let the HA handle the backend interfaces on It is more generic to let the HA handle the backend interfaces on
behalf of the MR and expose a consistent NEMO interface for all behalf of the MR and expose a consistent NEMO interface for all
deployments. deployments.
In more detail, a DHCPv6PD based solution presents a number of In more details, a DHCPv6PD based solution presents a number of
inconveniences: inconveniences:
Delegating Router: A collocated Delegating Router function may not be Delegating Router: A collocated Delegating Router function may not be
available for all implementation of NEMO Home Agent. In available for all implementation of NEMO Home Agent. In
particular, some implementations are server based. particular, some implementations are server based.
Operational overhead: Depending on the mechanism that is used to Operational overhead: Depending on the mechanism that is used to
attribute the MNPs to the MRs, the Delegating function, even if attribute the MNPs to the MRs, the Delegating function, even if
available, might be a costly overhead. Rather, an embedded, back- available, might be a costly overhead. Rather, an embedded, back-
end agnostic flow might be a desirable option. end agnostic flow might be a desirable option.
skipping to change at page 9, line 5 skipping to change at page 9, line 5
Authentication Mechanism: While NEMO basic Support protects its own Authentication Mechanism: While NEMO basic Support protects its own
flows, there is no mandate to secure the tunneled packets. flows, there is no mandate to secure the tunneled packets.
Back-end interaction: If a prefix is attributed to a MR for a Back-end interaction: If a prefix is attributed to a MR for a
duration that exceeds that of its binding, this information needs duration that exceeds that of its binding, this information needs
to be shared with all HAs, at least for authorization purposes. to be shared with all HAs, at least for authorization purposes.
This requires a specific backend integration that does not exist This requires a specific backend integration that does not exist
in the Prefix Delegation Function, for instance via a AAA server. in the Prefix Delegation Function, for instance via a AAA server.
4. Terminology and concepts 5. Terminology and concepts
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
interpreted as described in RFC2119 [1]. interpreted as described in RFC2119 [1].
Most of the mobility related terms used in this document are defined Most of the mobility related terms used in this document are defined
in the Mobility Related Terminology document [7] and in the Mobile in the Mobility Related Terminology document [7] and in the mobile
IPv6 specification [8]. IPv6 specification [8].
Additionally, some terms were created or extended for NEMO. These Additionally, some terms were created or extended for NEMO. These
specific terms are defined in the Mobile Network Terminology document specific terms are defined in the Mobile Network Terminology document
[12] [12]
This draft introduces the following definitions: This draft introduces the following definitions:
Mobile Network Prefix Request (MNPReq) Option: A new optional field Mobile Network Prefix Request (MNPReq) Option: A new optional field
in the MIPv6 Mobility Header for use with the Binding Update in the MIP6 Mobility Header for use with the binding Update
message, as described further in this document. This field is set 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 by a MR to request the delegation of a new prefix as a Mobile
Network Prefix. Network Prefix.
Mobile Network Prefix Confirmation (MNPConf) Option: A new optional Mobile Network Prefix Confirm (MNPConf) Option: A new optional field
field in the MIP6 Mobility Header for use with the Binding in the MIP6 Mobility Header for use with the binding
Acknowledgement message, as described further in this document. Acknowledgement message, as described further in this document.
transient prefix: A prefix that is attributed to a Mobile Router in transient prefix: A prefix that is attributed to a Mobile Router in
association with a binding cache entry. If the BCE is removed, association with a binding cache entry. If the BCE is removed,
the prefix is freed. the prefix is freed.
Persistent prefix: A prefix that is attributed to a Mobile Router for 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 a period of time that does not depend on the existence of a
binding cache entry. binding cache entry.
5. Overview 6. Overview
5.1. New Mobility Headers 6.1 New mobility Headers
This paper introduces a new option to the MIP6 Mobility Header, for This paper introduces a new option to the MIP6 Mobility Header, for
use with the Binding Update message, the Mobile Network Prefix use with the binding Update message, the Mobile Network Prefix
Request Option. A MR may include one or more MNPReq option(s) in a 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 Binding Update message at any time, in order to obtain additional
prefixes. prefixes.
This paper introduces another new option to the MIP6 Mobility Header, This paper introduces another new option to the MIP6 Mobility Header,
for use with the Binding Acknowledgement message, the Mobile Network for use with the binding Acknowledgement message, the Mobile Network
Prefix Confirmation Option. An HA will include one or more MNPConf Prefix Confirm Option. An HA will include one or more MNPConf
option(s) in a Binding Acknowledgement message, either in response to option(s) in a Binding Acknowledgement message, either in response to
a Mobile Network Prefix Request Option, or for its own purposes, for 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 instance in order inform a MR of a change about the lifetime of an
MNP. MNP.
5.2. New Prefix Status bit 6.2 New Prefix Status bit
Finally, this paper introduces a new bit to both the MIP6 Binding This paper finally introduces a new bit to the MIP6 Binding Update
Update and Binding Acknowledgement, the Prefix Status bit. A MR may and Binding Acknowledgement, the Prefix Status bit. A MR may include
include the Prefix Status bit in a Binding Update message at any the Prefix Status bit in a binding Update message at any time, either
time, either in order to get its initial configuration, or to check in order to get its initial configuration, or to check whether its
whether its current configuration matches that of the Home Agent - current configuration matches that of the Home Agent - which might be
which might be particularily useful in implicit mode. When the particularily useful in implicit mode. When the Prefix Status bit is
Prefix Status bit is set in the BU, the Acknowledge bit MUST be set set in the BU, the Acknowledge bit MUST be set as well.
as well.
The HA MAY set the Prefix Status bit in the Binding Acknowledgement 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 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 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 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 lists all the prefixes associated to that Mobile Router using Mobile
Network Prefix options. Network Prefix Confirm options.
5.3. Prefix Lease Duration 6.3 Prefix lease duration
A prefix may be obtained for the duration of the binding; in this 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 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 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; lifecycle, and that is controlled externally by the HA administrator;
in that case, the prefix is called 'persistent'. in that case, the prefix is called 'persistent'.
A flag in the MNPReq option indicates the expectation of the MR in 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 terms of persistence for the requested prefix. If the HA can not
fulfill that expectation, it must reject the binding with a negative fulfill that expectation, it must reject the binding with a negative
status. status.
The lease of a transient prefix expires with the MR Binding Cache The lease of a transient prefix expires with the MR Binding Cache
Entry; as a result, transient prefixes can be managed internally by a Entry; as a result, transient prefixes can be managed internally by a
HA, for instance using a local pool that forms an aggregation owned HA, for instance using a local pool that forms an aggregation owned
by the HA. by the HA.
On the other hand, some of the information about a persistent prefix One 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 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 systems that enable the authorization. This is required to allow a
Mobile Router to rebind, with the same persistent prefixes, to a Mobile Router to rebind, with the same persistent prefixes, to a
different Home Agent, after a period of inactivity. different Home Agent, after a period of inactivity.
It is possible to assign a persistent prefix dynamically at the time It is possible to assign a persistent prefix dynamically at the time
of the delegation; but the persistent mode also enables the of the delegation; but the persistent mode also enables the
preassignment of an MNP to an MR, for instance by provisionning a AAA preassignment of an MNP to an MR, for instance by provisionning a AAA
server with the necessary information for each Mobile Router. server with the necessary information for each Mobile Router.
5.4. Protocol Flow 6.4 Renumbering
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.
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 It is possible to redeploy the persistent prefix space, for instance
if Home is being renumbered, or if a dynamically attributed prefix 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 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 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). the MR has to request one or more new persistent prefix(es).
5.6. Backward Compatibility 6.5 backward compatibility
An HA that does not support this extension will ignore the An HA that would not support this extension will ignore the
unrecognized option. If the HA supports this extension, a binding unrecognized option. Else, if the HA supports this draft, and if a
update with the MNPReq option can be accepted per the NEMO basic binding update with the MNPReq option can be accepted per the NEMO
support checks: after the packet is checked according to the NEMO basic support checkings:
spec, the HA processes the option(s).
5.7. Basic PD flow 6.6 PD flow
When a MR needs an additional prefix to populate an interface, it When a MR needs an additional prefix to populate an interface, it
adds an MNPreq option to its Binding update message. adds an MNPreq option to its Binding update message.
If the HA can obtain the required prefix for that MR, it operates If the HA can obtain the required prefix for that MR, it operates
following the NEMO basic support, in either Implicit Mode or Explicit following the NEMO basic support, either in Implicit Mode, or in
Mode, using the prefixes as if they were received with the BU. This explicit mode using the prefixes as if they were received with the
includes setting up the routing states and responding with a positive BU. This includes setting up the routing states and responding with
or a negative status. a positive or a negative status.
If the routing states are established correctly and the HA responds If the routing states are established correctly and the HA responds
with a positive status, then the HA adds the prefix list to the with a positive status, then the HA adds the prefix list to the
binding ack message. binding ack message.
From that point on, both the MR and the HA operate as prescribed by From that point on, both the MR and the HA operate as prescribed by
the NEMO basic standard, either in implicit or explicit mode. the NEMO basic standard, either in implicit or in explicit mode.
6. Message Formats 7. Message Formats
6.1. Binding Update 7.1 Binding Update
A new flag (S) is included in the Binding Update to indicate to the 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 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 that are already assigned to it. The rest of the Binding Update
format remains the same as defined in [10]. format remains the same as defined in [9].
When the (S) bit is set, the (R) and and (A) bits MUST be set as When the (S) bit is set, the (R) and and (A) bits MUST be set as
well. well.
2 3 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 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 # | | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|S| Reserved | Lifetime | |A|H|L|K|M|R|S| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Binding Update
Prefix Status (S) The Prefix Status (S) bit is set by a MR to request 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 the full list of all prefixes that are already assigned to it
6.2. Binding Acknowledgement 7.2 Binding Acknowledgement
A new flag (S) is included in the Binding Acknowledgement to indicate A new flag (S) is included in the Binding Acknowledgement to indicate
to the Mobile Router that the Home Agent is providing the complete to the Mobile Router that the Home Agent provides the full list of
list of prefixes that are already assigned to the MR. The rest of all prefixes that are already assigned to the MR. The rest of the
the Binding Acknowledgement format remains the same as defined in Binding Acknowledgement format remains the same as defined in [9].
[10].
When the (S) bit is set, the (R) bit MUST be set as well. When the (S) bit is set, the (R) bit MUST be set as well.
0 1 2 3 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 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 | | Status |K|R|S|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime | | Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Binding Acknowledgement
Prefix Status (S) The Prefix Status (S) bit is set by a HA to 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 indicate that it provides the full list of all prefixes that are
already assigned to the MR. already assigned to the MR.
6.3. Mobile Network Prefix option 7.3 Mobile Network Prefix option
New flags are included in the Mobile Network Prefix option defined in 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 [9]. This allows the option to cover all the prefixes owned by the
MR, including those that are managed using the implicit prefix mode. MR, including those that are managed using the implicit prefix mode.
0 1 2 3 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 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 | | Type | Length |P|I|D|Reserved1| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Mobile Network Prefix + + Mobile Network Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Mobile Network Prefix option
The new flags introduced by this specification are: The new flags introduced by this specification are:
Persistent (P) The (P) bit is set if the prefix is expected to be Persistent (P) The (P) bit is set if the prefix is expexted to be
persistently assigned to the MR beyond the lifetime of the persistently assigned to the MR.
associated binding.
Implicit (I) The (I) bit is set if the prefix is expected to be Implicit (I) The (I) bit is set if the prefix is expexted to be
assigned to and routed via the MR even if the prefix is not listed assigned to and routed via the MR even if the prefix is not listed
in an explicit mode BU. in 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. Delegated (D) The (D) bit is set if the prefix was obtained using a
the Delagation 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.
6.4. Mobile Network Prefix Request option 7.4 Mobile Network Prefix request option
This new option is included in the Binding Update to indicate to the 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 Home Agent that the MR wishes to get a new prefix assigned to it for
use as a MNP. use as a MNP.
When this option is present, the (S) MAY be set as well in the BU in 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. order to get the full list of all prefixes.
0 1 2 3 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 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 | | Type | Length | Prefix Length |P|I| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CorID | Reserved2 | Prefix type | | CorID | Reserved2 | Prefix type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBA Figure 4: Mobile Network Prefix request option
Length: 8-bit unsigned integer indicating the length in octets of the Type TBA
Length 8 bit unsigned integer indicating the length in octets of the
option excluding the type and length fields. Set to 6. option excluding the type and length fields. Set to 6.
Prefix Length: 8-bit unsigned integer indicating the prefix length of Prefix Length 8 bit unsigned integer indicating the prefix length of
the IPv6 prefix contained in the option (valid range isno 1..128). the IPv6 prefix contained in the option.
Persistent (P): The (P) bit is set if the prefix that is requested to Persistent (P) The (P) bit is set if the prefix that is requested to
be persistently assigned to the MR. expected to be persistently assigned to the MR.
Implicit (I): The (I) bit is set if the prefix that is requested to 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 expected to be assigned to, and routed via the MR, even if the
listed in an explicit mode BU. prefix is not listed in explicit mode BU.
CorId: A Correlator that is set by the MR in order to associate a MNP 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 request with the prefix given in the confirm. There can be at
at most one active prefix associated with each Correlator. This most one active prefix associated with each Correlator. This
mechanism ensures the uniqueness of the allocation of a prefix, mechanism ensure the unicity of the allocation of a prefix, should
should either the BU or the BA be lost in transit. aither the BU or the BA be lost in the way.
Prefix Type: Indicates the type of prefix that is requested: Prefix Type Indicates the type of prefix that is requested:
0: None Specified 0 None Specified
1: Private
2: Unique Local 2 Unique Local
3: Global 3 Global
6.5. Mobile Network Prefix Confirmation option 7.5 Mobile Network Prefix Confirm option
This new option is included in the Binding Acknowledgment to indicate This new option is included in the Binding Update to indicate to the
to the Mobile Router whether a new prefix was assigned, and what it Home Agent that the MR wishes to get a new prefix assigned to it for
is. use as a MNP.
When this option is present, the (S) MAY be set as well in the BU in 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. order to get the full list of all prefixes.
0 1 2 3 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 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| | Type | Length | Prefix Length |P|I|D|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CorID | Status | Prefix type | | CorID | Reserved2 | Prefix type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime | | Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Mobile Network Prefix + + Mobile Network Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Mobile Network Prefix Confirm option
Type TBA Type TBA
Length: 8-bit unsigned integer indicating the length in octets of the Length 8 bit unsigned integer indicating the length in octets of the
option excluding the type and length fields. Set to 26. option excluding the type and length fields. Set to 26.
Prefix Length: 8-bit unsigned integer indicating the length of the Prefix Length 8 bit unsigned integer indicating the prefix length of
IPv6 prefix contained in the option (valid range is 1..128). the IPv6 prefix contained in the option.
Persistent (P): The (P) bit is set if the prefix is persistently Persistent (P) The (P) bit is set if the prefix is persistently
assigned to the MR. assigned to the MR.
Implicit (I): The (I) bit is set if the prefix is assigned to and 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 routed via the MR even if the prefix is not listed in explicit
mode BU. mode BU.
Delegated (D): The (D) bit is set if the prefix was obtained using a Delegated (D) The (D) bit is set if the prefix was obtained using a
the Delegation Mechanism described in this specification. the Delagation Mechanism as 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: CorId If the (D) bit is set, the Correlator that was set by the MR in
an MNPReq and this option contains the prefix that is being
delegated in response to that Request. If the (D) bit is not set,
the Correlator value is defined by the HA.
0: None Specified Prefix Type Indicates the type of prefix that is requested:
1: Private 0 None Specified
2: Unique Local 2 Unique Local
3: Global 3 Global
Valid Lifetime: 32-bit unsigned integer. The length of time in Valid Lifetime 32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent) that the prefix seconds (relative to the time the packet is sent) that the prefix
is valid for being installed on an MR ingress interface. A value is valid for being installed on an MR ingress interface. A value
of all one bits (0xffffffff) represents infinity. The Valid of all one bits (0xffffffff) represents infinity. The Valid
Lifetime is also used by RFC2461 [3] and RFC2462 [4], and must be Lifetime is also used by RFC2461 [3] and RFC2462 [4], and must be
used in the RAs sent over the MR ingress interface for that used in the RAs sent over the MR ingress interface for that
prefix. prefix.
Mobile Network Prefix: A 16 byte field containing the Mobile Network Mobile Network Prefix A 16 byte field contains the Mobile Network
Prefix. Prefix.
7. Mobile Router Operation 8. Mobile Router Operation
9. Home Agent Operation
When the Mobile Router has determined the Home Address it is going to 10. Back End considerations
use and the Home Agent it is going to register with, it constructs a 11. Security Considerations
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.
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. 12. IANA Considerations
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 The specification requires the following allocations from IANA:
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 The Mobile Network Prefix Request option described in Section 7.4
operation as normal, until another MNPO or MNPR is received. requires a new option type. This option is included in the
Mobility header described in Mobile IPv6 [8] .
9. Back End considerations The Mobile Network Prefix Confirm option described in Section 7.5
10. Security Considerations requires a new option type. This option is included in the
Mobility header described in Mobile IPv6 [8].
11. Acknowledgements 13. Acknowledgements
The authors wish to thank: The authors wish to thank:
Pekka Paakkonen and Juhani Latvakoski from VTT Electronics for their Pekka Paakkonen and Juhani Latvakoski from VTT Electronics for their
initial work on the matter. initial work on the matter. Hesham Soliman for his suggestion to
couple PD with NAI.
12. References 14. References
14.1 Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
skipping to change at page 25, line 32 skipping to change at page 23, line 34
[6] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host [6] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[7] Manner, J. and M. Kojo, "Mobility Related Terminology", [7] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[9] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", [9] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
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, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
[11] Thubert, P., "NEMO Home Network models", [10] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
draft-ietf-nemo-home-network-models-04 (work in progress), "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)",
June 2005. RFC 4283, November 2005.
[11] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
"Authentication Protocol for Mobile IPv6", RFC 4285,
January 2006.
[12] Ernst, T. and H. Lach, "Network Mobility Support Terminology", [12] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-03 (work in progress), draft-ietf-nemo-terminology-06 (work in progress),
February 2005. November 2006.
Authors' Addresses 14.2 Informative Reference
T.J. Kniveton [13] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping
Nokia, Inc. Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in
313 Fairchild Dr. progress), May 2006.
Building B-223
Mountain View 94043
USA
Phone: +1 650 625 2025 [14] Thubert, P., "NEMO Home Network models",
Email: tj@kniveton.com draft-ietf-nemo-home-network-models-06 (work in progress),
February 2006.
Authors' Addresses
Pascal Thubert Pascal Thubert
Cisco Systems Cisco Systems
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue de Roumanille 400, Avenue de Roumanille
Batiment T3 Batiment T3
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
FRANCE FRANCE
Phone: +33 4 97 23 26 34 Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
T.J. Kniveton
Nokia, Inc.
313 Fairchild Dr.
Building B-223
Mountain View 94043
USA
Phone: +1 650 625 2025
Email: tj@kniveton.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 27, line 41 skipping to change at page 25, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 127 change blocks. 
464 lines changed or deleted 354 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/