summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5380.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5380.txt')
-rw-r--r--doc/rfc/rfc5380.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc5380.txt b/doc/rfc/rfc5380.txt
new file mode 100644
index 0000000..1b5b2bf
--- /dev/null
+++ b/doc/rfc/rfc5380.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group H. Soliman
+Request for Comments: 5380 Elevate Technologies
+Obsoletes: 4140 C. Castelluccia
+Category: Standards Track INRIA
+ K. ElMalki
+ Athonet
+ L. Bellier
+ INRIA
+ October 2008
+
+
+ Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document introduces extensions to Mobile IPv6 and IPv6 Neighbour
+ Discovery to allow for local mobility handling. Hierarchical
+ mobility management for Mobile IPv6 is designed to reduce the amount
+ of signalling between the mobile node, its correspondent nodes, and
+ its home agent. The Mobility Anchor Point (MAP) described in this
+ document can also be used to improve the performance of Mobile IPv6
+ in terms of handover speed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Soliman, et al. Standards Track [Page 1]
+
+RFC 5380 HMIPv6 October 2008
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................4
+ 3. Overview of HMIPv6 ..............................................5
+ 3.1. HMIPv6 Operations ..........................................6
+ 4. Mobile IPv6 Extension - Local Binding Update ....................9
+ 5. Neighbour Discovery Extension: The MAP Option ...................9
+ 6. Protocol Operation .............................................10
+ 6.1. Mobile Node Operation .....................................11
+ 6.1.1. Sending Packets to Correspondent Nodes .............12
+ 6.2. MAP Operations ............................................13
+ 6.3. Home Agent Operations .....................................13
+ 6.4. Correspondent Node Operations .............................13
+ 6.5. Local Mobility Management Optimisation within a
+ MAP Domain ................................................14
+ 6.6. Location Privacy ..........................................14
+ 7. MAP Discovery ..................................................15
+ 7.1. Mobile Node Operation .....................................15
+ 8. Updating Previous MAPs .........................................16
+ 9. Note on MAP Selection by the Mobile Node .......................16
+ 9.1. MAP Selection in Distributed MAP Environment ..............17
+ 9.2. MAP Selection in a Flat Mobility Architecture .............18
+ 10. Detection and Recovery from MAP Failures ......................18
+ 11. Tunelling Impacts on MTU ......................................19
+ 12. Security Considerations .......................................19
+ 12.1. Mobile Node - MAP Security ...............................20
+ 12.2. Mobile Node - Correspondent Node Security ................22
+ 12.3. Mobile Node - Home Agent Security ........................22
+ 13. IANA Considerations ...........................................22
+ 14. Acknowledgements ..............................................22
+ 15. References ....................................................23
+ 15.1. Normative References .....................................23
+ 15.2. Informative References ...................................23
+ Appendix A. Changes from RFC 4140 .................................24
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Soliman, et al. Standards Track [Page 2]
+
+RFC 5380 HMIPv6 October 2008
+
+
+1. Introduction
+
+ This specification introduces the concept of a hierarchical Mobile
+ IPv6 network, utilising a new node called the Mobility Anchor Point
+ (MAP).
+
+ Mobile IPv6 [RFC3775] allows nodes to move within the Internet
+ topology while maintaining reachability and ongoing connections
+ between mobile and correspondent nodes. To do this, a mobile node
+ sends binding updates (BUs) to its home agent (HA) every time it
+ moves.
+
+ The mobile node may send data packets via its home agent immediately
+ after sending the binding update, but the home agent will not be able
+ to route traffic back to the mobile node before it receives the
+ binding update. This incurs at least half a round-trip delay before
+ packets are again forwarded to the right place. There is an
+ additional delay for sending data packets if the mobile node chooses
+ to wait for a binding acknowledgement (BA). The round-trip times can
+ be relatively long if the mobile node and its home agent are in
+ different parts of the world.
+
+ Additional delay is also incurred if the mobile node employs route
+ optimisation. Authenticating binding updates requires approximately
+ 1.5 round-trip times between the mobile node and each correspondent
+ node (for the entire return routability procedure in a best-case
+ scenario, i.e., no packet loss). This can be done in parallel with
+ sending binding updates to the home agent, and there are further
+ optimisations that reduce the required 1.5 round-trips [RFC4449]
+ [RFC4651] [RFC4866].
+
+ Nevertheless, the signalling exchanges required to update your
+ location will always cause some disruption to active connections.
+ Some packets will be lost. Together with link layer and IP layer
+ connection setup delays, there may be effects to upper-layer
+ protocols. Reducing these delays during the time-critical handover
+ period will improve the performance of Mobile IPv6.
+
+ Moreover, in the case of wireless links, such a solution reduces the
+ number of messages sent over the air interface to all correspondent
+ nodes and the home agent. A local anchor point will also allow
+ Mobile IPv6 to benefit from reduced mobility signalling with external
+ networks.
+
+ For these reasons, a new Mobile IPv6 node, called the Mobility Anchor
+ Point, is used and can be located at any level in a hierarchical
+ network of routers, including the Access Router (AR). The MAP will
+ limit the amount of Mobile IPv6 signalling outside the local domain.
+
+
+
+Soliman, et al. Standards Track [Page 3]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ The introduction of the MAP provides a solution to the issues
+ outlined earlier, in the following way:
+
+ o The mobile node sends binding updates to the local MAP rather than
+ the home agent (HA) (which is typically further away) and
+ correspondent nodes (CNs).
+
+ o Only one binding update message needs to be transmitted by the
+ mobile node (MN) before traffic from the HA and all CNs is
+ re-routed to its new location. This is independent of the number
+ of CNs with which the MN is communicating.
+
+ A MAP is essentially a local home agent. The aim of introducing the
+ hierarchical mobility management model in Mobile IPv6 is to enhance
+ the performance of Mobile IPv6 while minimising the impact on Mobile
+ IPv6 or other IPv6 protocols. Furthermore, HMIPv6 allows mobile
+ nodes to hide their location from correspondent nodes and home
+ agents, while using Mobile IPv6 route optimisation. The security
+ differences between the MAP and the home agent are described in
+ Section 12.
+
+ It is pertinent to note that the use of the MAP does not rely on, or
+ assume the presence of, a permanent home agent. In other words, a
+ mobile node need not have a permanent home address or home agent in
+ order to be HMIPv6-aware or use the features in this specification.
+ A MAP may be used by a mobile node in a nomadic manner to achieve
+ mobility management within a local domain. Section 6.5 describes
+ such a scenario.
+
+2. Terminology
+
+ 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].
+
+ In addition, the following terms are introduced:
+
+ Access Router (AR)
+
+ The AR is the mobile node's default router. The AR aggregates the
+ outbound traffic of mobile nodes.
+
+ Mobility Anchor Point (MAP)
+
+ A Mobility Anchor Point is a router located in a network visited
+ by the mobile node. The MAP is used by the MN as a local HA. One
+ or more MAPs can exist within a visited network.
+
+
+
+
+Soliman, et al. Standards Track [Page 4]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ Regional Care-of Address (RCoA)
+
+ An RCoA is an address allocated by the MAP to the mobile node.
+
+ HMIPv6-Aware Mobile Node
+
+ An HMIPv6-aware mobile node is a mobile node that can receive and
+ process the MAP option received from its default router. An
+ HMIPv6-aware mobile node must also be able to send local binding
+ updates (binding update with the M flag set).
+
+ On-Link Care-of Address
+
+ The LCoA is the on-link CoA configured on a mobile node's
+ interface based on the prefix advertised by its default router.
+ In [RFC3775], this is simply referred to as the care-of address.
+ However, in this memo LCoA is used to distinguish it from the
+ RCoA.
+
+ Local Binding Update
+
+ The MN sends a local binding update to the MAP in order to
+ establish a binding between the RCoA and LCoA.
+
+3. Overview of HMIPv6
+
+ This hierarchical Mobile IPv6 scheme introduces a new function, the
+ MAP, and minor extensions to the mobile node operation. The
+ correspondent node and home agent operations will not be affected.
+
+ Just like Mobile IPv6, this solution is independent of the underlying
+ access technology, allowing mobility within or between different
+ types of access networks.
+
+ A mobile node entering a MAP domain will receive Router
+ Advertisements containing information about one or more local MAPs.
+ The MN can bind its current location (on-link CoA) with an address on
+ the MAP's subnet (RCoA). Acting as a local HA, the MAP will receive
+ all packets on behalf of the mobile node it is serving and will
+ encapsulate and forward them directly to the mobile node's current
+ address. If the mobile node changes its current address within a
+ local MAP domain (LCoA), it only needs to register the new address
+ with the MAP. Hence, only the Regional CoA (RCoA) needs to be
+ registered with correspondent nodes and the HA. The RCoA does not
+ change as long as the MN moves within a MAP domain (see below for
+ definition). This makes the mobile node's mobility transparent to
+ correspondent nodes it communicates with.
+
+
+
+
+Soliman, et al. Standards Track [Page 5]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ A MAP domain's boundaries are defined by the Access Routers (ARs)
+ advertising the MAP information to the attached mobile nodes. The
+ detailed extensions to Mobile IPv6 and operations of the different
+ nodes will be explained later in this document.
+
+ It should be noted that the HMIPv6 concept is simply an extension to
+ the Mobile IPv6 protocol. An HMIPv6-aware mobile node with an
+ implementation of Mobile IPv6 SHOULD choose to use the MAP when
+ discovering such capability in a visited network. However, in some
+ cases the mobile node may prefer to simply use the standard Mobile
+ IPv6 implementation. For instance, the mobile node may be located in
+ a visited network within its home site. In this case, the HA is
+ located near the visited network and could be used instead of a MAP.
+ In this scenario, the mobile node would only update the HA whenever
+ it moves. The method to determine whether the HA is in the vicinity
+ of the MN (e.g., same site) is outside the scope of this document.
+
+3.1. HMIPv6 Operations
+
+ The network architecture shown in Figure 1 illustrates an example of
+ the use of the MAP in a visited network.
+
+ In Figure 1, the MAP can help in providing seamless mobility for the
+ mobile node as it moves from Access Router 1 (AR1) to Access Router 2
+ (AR2), while communicating with the correspondent node. A
+ multi-level hierarchy is not required for a higher handover
+ performance. Hence, it is sufficient to locate one or more MAPs
+ (possibly covering the same domain) at any position in the operator's
+ network.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Soliman, et al. Standards Track [Page 6]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ +-------+
+ | HA |
+ +-------+ +----+
+ | | CN |
+ | +----+
+ | |
+ +-------+-----+
+ |
+ |RCoA
+ +-------+
+ | MAP |
+ +-------+
+ | |
+ | +--------+
+ | |
+ | |
+ +-----+ +-----+
+ | AR1 | | AR2 |
+ +-----+ +-----+
+ LCoA1 LCoA2
+
+ +----+
+ | MN |
+ +----+ ------------>
+ Movement
+
+ Figure 1: Hierarchical Mobile IPv6 domain
+
+ Upon arrival in a visited network, the mobile node will discover the
+ global address of the MAP. This address is stored in the Access
+ Routers and communicated to the mobile node via Router Advertisements
+ (RAs). A new option for RAs is defined later in this specification.
+ This is needed to inform mobile nodes about the presence of the MAP
+ (MAP Discovery). The discovery phase will also inform the mobile
+ node of the distance of the MAP from the mobile node. For example,
+ the MAP function could be implemented as shown in Figure 1, and, at
+ the same time, also be implemented in AR1 and AR2. In this case, the
+ mobile node can choose the first hop MAP or one further up in the
+ hierarchy of routers. The details on how to choose a MAP are
+ provided in Section 10.
+
+ The process of MAP Discovery continues as the mobile node moves from
+ one subnet to the next. Every time the mobile node detects movement,
+ it will also detect whether it is still in the same MAP domain. The
+ Router Advertisement used to detect movement will also inform the
+ mobile node, through Neighbour Discovery [RFC4861] and the MAP
+ option, whether it is still in the same MAP domain. As the mobile
+ node roams within a MAP domain, it will continue to receive the same
+
+
+
+Soliman, et al. Standards Track [Page 7]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ MAP option included in Router Advertisements from its AR. If a
+ change in the advertised MAP's address is received, the mobile node
+ MUST act on the change by sending binding updates to its HA and
+ correspondent nodes.
+
+ If the mobile node is not HMIPv6-aware, then no MAP Discovery will be
+ performed, resulting in the mobile node using the Mobile IPv6
+ [RFC3775] protocol for its mobility management. On the other hand,
+ if the mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6
+ implementation. If so, the mobile node will first need to register
+ with a MAP by sending it a BU containing its home address and on-link
+ address (LCoA). The home address used in the BU is the RCoA, which
+ the mobile node acquires via RFC 4877 [RFC4877] Section 9 mechanisms
+ when it first contacts a given MAP. The MAP MUST store this
+ information in its binding cache to be able to forward packets to
+ their final destination when received from the different
+ correspondent nodes or HAs.
+
+ The mobile node will always need to know the original sender of any
+ received packets to determine if route optimisation is required.
+ This information will be available to the mobile node because the MAP
+ does not modify the contents of the original packet. Normal
+ processing of the received packets (as described in [RFC3775]) will
+ give the mobile node the necessary information.
+
+ To use the network bandwidth in a more efficient manner, a mobile
+ node may decide to register with more than one MAP simultaneously and
+ to use each MAP address for a specific group of correspondent nodes.
+ For example, in Figure 1, if the correspondent node happens to exist
+ on the same link as the mobile node, it would be more efficient to
+ use the first hop MAP (in this case assume it is AR1) for
+ communication between them. This will avoid sending all packets via
+ the "highest" MAP in the hierarchy and thus will result in more
+ efficient usage of network bandwidth. The mobile node can also use
+ its current on-link address (LCoA) as a CoA, as specified in
+ [RFC3775]. Note that the mobile node MUST NOT present an RCoA from a
+ MAP's subnet as an LCoA in a binding update sent to another MAP. The
+ LCoA included in the binding update MUST be the mobile node's
+ address, derived from the prefix advertised on its link.
+
+
+
+
+
+
+
+
+
+
+
+
+Soliman, et al. Standards Track [Page 8]
+
+RFC 5380 HMIPv6 October 2008
+
+
+4. Mobile IPv6 Extension - Local Binding Update
+
+ This section outlines the extensions proposed to the binding update
+ specified in [RFC3775].
+
+ A new flag is added: the M flag, which indicates MAP registration.
+ When a mobile node registers with the MAP, the M and A flags MUST be
+ set to distinguish this registration from a BU being sent to the HA
+ or a correspondent node.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence # |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A|H|L|K|M| Reserved | Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2: Local Binding Update
+
+ M
+
+ If set to 1, it indicates a MAP registration.
+
+5. Neighbour Discovery Extension: The MAP Option
+
+ 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 | Dist | Pref |R| Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Valid Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Global IP Address for MAP +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: The MAP option
+
+
+
+
+
+Soliman, et al. Standards Track [Page 9]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ Type
+
+ IPv6 Neighbour Discovery option. Its value is 23.
+
+ Length
+
+ 8-bit unsigned integer. The length of the option and MUST be set
+ to 3.
+
+ Dist
+
+ A 4-bit unsigned integer identifying the distance between MAP and
+ the receiver of the advertisement, measure in the number of hops
+ and starting from 1 if the MAP is on the same link as the mobile
+ node. A distance value of zero MUST NOT be used.
+
+ Pref
+
+ The preference field, used as an indicator of operator preference.
+ A 4-bit unsigned integer. A decimal value of 15 indicates the
+ highest preference. When comparing two potential MAPs, the mobile
+ node SHOULD inspect this field as a tie-breaker for MAPs that have
+ equal Dist values.
+
+ R
+
+ When set to 1, it indicates that the mobile node is allocated the
+ RCoA by the MAP based on Section 9 of [RFC4877].
+
+ Valid Lifetime
+
+ The minimum value (in seconds) of both the valid lifetime of the
+ prefix used to form the MAP's address and that used to form the
+ RCoA. This value indicates the validity of the MAP's address and
+ the RCoA.
+
+ Global Address
+
+ One of the MAP's global addresses.
+
+6. Protocol Operation
+
+ This section describes the HMIPv6 protocol. In HMIPv6, the mobile
+ node has two addresses, an RCoA on the MAP's link and an on-link CoA
+ (LCoA). This RCoA is formed in a stateless manner by combining the
+ mobile node's interface identifier and the subnet prefix received in
+ the MAP option.
+
+
+
+
+Soliman, et al. Standards Track [Page 10]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ As illustrated in this section, this protocol requires updating the
+ mobile nodes' implementation only. The HA and correspondent node are
+ unchanged. The MAP performs the function of a "local" HA that binds
+ the mobile node's RCoA to an LCoA.
+
+6.1. Mobile Node Operation
+
+ When a mobile node moves into a new MAP domain (i.e., its MAP
+ changes), it needs to configure two CoAs: an RCoA on the MAP's link
+ and an on-link CoA (LCoA). After employing [RFC4877] to acquire an
+ RCoA, the mobile node sends a local BU to the MAP with the A and M
+ flags set. The local BU is a BU defined in [RFC3775] and includes
+ the mobile node's RCoA in the Home Address option. No alternate-CoA
+ option is needed in this message. The LCoA is used as the source
+ address of the BU. This BU will bind the mobile node's RCoA (similar
+ to a home address) to its LCoA. The MAP (acting as an HA) will then
+ return a binding acknowledgement to the MN. This acknowledgement
+ either identifies the binding as successful or contains the
+ appropriate fault code. No new error codes need to be supported by
+ the mobile node for this operation. The mobile node MUST silently
+ ignore binding acknowledgements that do not contain a routing header
+ type 2, which includes the mobile node's RCoA.
+
+ Following a successful registration with the MAP, a bi-directional
+ tunnel between the mobile node and the MAP is established. All
+ packets sent by the mobile node are tunnelled to the MAP. The outer
+ header contains the mobile node's LCoA in the source address field,
+ and the MAP's address in the destination address field. The inner
+ header contains the mobile node's RCoA in the source address field,
+ and the peer's address in the destination address field. Similarly,
+ all packets addressed to the mobile node's RCoA are intercepted by
+ the MAP and tunnelled to the mobile node's LCoA.
+
+ This specification allows a mobile node to use more than one RCoA if
+ it received more than one MAP option. In this case, the mobile node
+ MAY perform the binding update procedure for each RCoA. In addition,
+ the mobile node MUST NOT use one RCoA (e.g., RCoA1) derived from a
+ MAP's prefix (e.g., MAP1) as a care-of address in its binding update
+ to another MAP (e.g., MAP2). This would force packets to be
+ encapsulated several times (twice in this example) on their path to
+ the mobile node. This form of multi-level hierarchy will reduce the
+ protocol's efficiency and performance.
+
+ After registering with the MAP, the mobile node MUST register its new
+ RCoA with its HA by sending a BU that specifies the binding (RCoA,
+ home address), as in Mobile IPv6. The mobile node's home address is
+ used in the Home Address option and the RCoA is used as the care-of
+
+
+
+
+Soliman, et al. Standards Track [Page 11]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ address in the source address field. The mobile node may also send a
+ similar BU (i.e., that specifies the binding between the home address
+ and the RCoA) to its current correspondent nodes.
+
+ The mobile node SHOULD wait for the binding acknowledgement from the
+ MAP before registering the RCoA with other nodes (e.g., CN or HA, if
+ available). It should be noted that when binding the RCoA with the
+ HA and correspondent nodes, the binding lifetime MUST NOT be larger
+ than the mobile node's binding lifetime with the MAP, which is
+ received in the binding acknowledgement.
+
+ In order to speed up the handover between MAPs and reduce packet
+ loss, a mobile node SHOULD send a local BU to its previous MAP,
+ specifying its new LCoA. Packets in transit that reach the previous
+ MAP are then forwarded to the new LCoA.
+
+ The MAP will receive packets addressed to the mobile node's RCoA
+ (from the HA or correspondent nodes). Packets will be tunnelled from
+ the MAP to the mobile node's LCoA. The mobile node will de-capsulate
+ the packets and process them in the normal manner.
+
+ When the mobile node moves within the same MAP domain, it should only
+ register its new LCoA with its MAP. In this case, the RCoA remains
+ unchanged.
+
+ Note that a mobile node may send a BU containing its LCoA (instead of
+ its RCoA) to correspondent nodes. If these nodes are connected to
+ the same link, packets will then be routed directly, without going
+ through the MAP.
+
+6.1.1. Sending Packets to Correspondent Nodes
+
+ The mobile node can communicate with a correspondent node through the
+ HA, or in a route-optimised manner, as described in [RFC3775]. When
+ communicating through the HA, the message formats in [RFC3775] are
+ used.
+
+ If the mobile node communicates directly with the correspondent node
+ (i.e., the CN has a binding cache entry for the mobile node), the
+ mobile node MUST use the same care-of address used to create a
+ binding cache entry in the correspondent node (RCoA) as a source
+ address. According to [RFC3775], the mobile node MUST also include a
+ Home Address option in outgoing packets. The Home Address option
+ MUST contain the mobile node's home address.
+
+
+
+
+
+
+
+Soliman, et al. Standards Track [Page 12]
+
+RFC 5380 HMIPv6 October 2008
+
+
+6.2. MAP Operations
+
+ The MAP acts like an HA; it intercepts all packets addressed to
+ registered mobile nodes and tunnels them to the corresponding LCoA,
+ which is stored in its binding cache.
+
+ A MAP has no knowledge of the mobile node's home address. The mobile
+ node will send a local BU to the MAP with the M and A flags set. The
+ aim of this BU is to bind the RCoA (contained in the BU as a home
+ address) to the mobile node's LCoA. If successful, the MAP MUST
+ return a binding acknowledgement to the mobile node, indicating a
+ successful registration. This is identical to the HA operation in
+ [RFC3775]. No new error codes are introduced for HMIPv6. The
+ binding acknowledgement MUST include a routing header type 2 that
+ contains the mobile node's RCoA.
+
+ The MAP MUST be able to accept packets tunnelled from the mobile
+ node, with the mobile node being the tunnel entry point and the MAP
+ being the tunnel exit point.
+
+ The MAP employs [RFC4877] Section 9 procedures for the allocation of
+ RCoA, and subsequently acts as an HA for the RCoA. Packets addressed
+ to the RCoA are intercepted by the MAP, using proxy Neighbour
+ Advertisement, and then encapsulated and routed to the mobile node's
+ LCoA. This operation is identical to that of the HA described in
+ [RFC3775].
+
+ A MAP MAY be configured with the list of valid on-link prefixes that
+ mobile nodes can use to derive LCoAs. This is useful for network
+ operators that need to stop mobile nodes from continuing to use the
+ MAP after moving to a different administrative domain. If a mobile
+
+ node sent a binding update containing an LCoA that is not in the
+ MAP's "valid on-link prefixes" list, the MAP could reject the binding
+ update using existing error code 129 (administratively prohibited).
+
+6.3. Home Agent Operations
+
+ The support of HMIPv6 is completely transparent to the HA's
+ operation. Packets addressed to a mobile node's home address will be
+ forwarded by the HA to its RCoA, as described in [RFC3775].
+
+6.4. Correspondent Node Operations
+
+ HMIPv6 is completely transparent to correspondent nodes.
+
+
+
+
+
+
+Soliman, et al. Standards Track [Page 13]
+
+RFC 5380 HMIPv6 October 2008
+
+
+6.5. Local Mobility Management Optimisation within a MAP Domain
+
+ In [RFC3775], it is stated that for short-term communication,
+ particularly communication that may easily be retried upon failure,
+ the mobile node MAY choose to directly use one of its care-of
+ addresses as the source of the packet, thus not requiring the use of
+ a Home Address option in the packet. Such use of the CoA will reduce
+ the overhead of sending each packet due to the absence of additional
+ options. In addition, it will provide an optimal route between the
+ mobile node and correspondent node.
+
+ HMIPv6-aware mobile nodes can use their RCoA as the source address
+ without using a Home Address option. In other words, the RCoA can be
+ used as a source address for upper layers. Using this feature, the
+ mobile node will be seen by the correspondent node as a fixed node
+ while moving within a MAP domain.
+
+ This usage of the RCoA does not have the cost of Mobile IPv6 (i.e.,
+ no bindings or Home Address options are sent over the Internet), but
+ still provides local mobility management to the mobile nodes with
+ near-optimal routing. Although such use of RCoA does not provide
+ global mobility (i.e., communication is broken when a mobile node
+ changes its RCoA), it would be useful for several applications (e.g.,
+ web browsing). The validity of the RCoA as a source address used by
+ applications will depend on the size of a MAP domain and the speed of
+ the mobile node. Furthermore, because the support for BU processing
+ in correspondent nodes is not mandated in [RFC3775], this mechanism
+ can provide a way of obtaining route optimisation without sending BUs
+ to the correspondent nodes.
+
+ Enabling this mechanism can be done by presenting the RCoA as a
+ temporary home address for the mobile node. This may require an
+ implementation to augment its source address selection algorithm with
+ the knowledge of the RCoA in order to use it for the appropriate
+ applications.
+
+6.6. Location Privacy
+
+ In HMIPv6, a mobile node hides its LCoA from its correspondent nodes
+ and its home agent by using its RCoA in the source field of the
+ packets that it sends. As a result, address-based location tracking
+ of a mobile node by its correspondent nodes or its home agent is more
+ difficult because they only know its RCoA and not its LCoA.
+
+
+
+
+
+
+
+
+Soliman, et al. Standards Track [Page 14]
+
+RFC 5380 HMIPv6 October 2008
+
+
+7. MAP Discovery
+
+ This section describes how a mobile node obtains the MAP address and
+ subnet prefix, and how ARs in a domain discover MAPs.
+
+ This specification requires network administrators to manually
+ configure the MAP option information in ARs; future mechanisms may be
+ defined to allow MAPs to be discovered dynamically.
+
+7.1. Mobile Node Operation
+
+ When an HMIPv6-aware mobile node receives a Router Advertisement, it
+ should search for the MAP option. One or more options may be found
+ for different MAP IP addresses. A mobile node SHOULD register with
+ the MAP having the highest preference value. A MAP with a preference
+ value of zero SHOULD NOT be used for new local BUs (i.e., the mobile
+ node can refresh existing bindings but cannot create new ones).
+ However, a mobile node MAY choose to register with one MAP over
+ another, depending on the value received in the distance field,
+ provided that the preference value is above zero.
+
+ A MAP option containing a valid lifetime value of zero means that
+ this MAP MUST NOT be selected by the MN. A valid lifetime of zero
+ indicates a MAP failure. When this option is received, a mobile node
+ MUST choose another MAP and create new bindings. Any existing
+ bindings with this MAP can be assumed to be lost. If no other MAP is
+ available, the mobile node MUST NOT attempt to use HMIPv6.
+
+ If a multi-homed mobile node has access to several ARs simultaneously
+ (on different interfaces), it SHOULD use an LCoA on the link defined
+ by the AR that advertises its current MAP.
+
+ A mobile node MUST store the received option(s) in order to choose at
+ least one MAP to register with. Storing the options is essential, as
+ they will be compared to other options received later for the purpose
+ of the movement detection algorithm.
+
+ If the R flag is set, the mobile node MUST place its RCoA in place of
+ the home address in the binding update message. This causes the RCoA
+ to be bound to the LCoA in the MAP's binding cache.
+
+ A mobile node MAY choose to register with more than one MAP
+ simultaneously, or use both the RCoA and its LCoA as care-of
+ addresses simultaneously with different correspondent nodes.
+
+
+
+
+
+
+
+Soliman, et al. Standards Track [Page 15]
+
+RFC 5380 HMIPv6 October 2008
+
+
+8. Updating Previous MAPs
+
+ When a mobile node moves into a new MAP domain, the mobile node may
+ send a BU to the previous MAP requesting it to forward packets
+ addressed to the mobile node's new CoA. An administrator MAY
+ restrict the MAP from forwarding packets to LCoAs outside the MAP's
+ domain. However, it is RECOMMENDED that MAPs be allowed to forward
+ packets to LCoAs associated with some of the ARs in neighbouring MAP
+ domains, provided that they are located within the same
+ administrative domain.
+
+ For instance, a MAP could be configured to forward packets to LCoAs
+ associated with ARs that are geographically adjacent to ARs on the
+ boundary of its domain. This will allow for a smooth inter-MAP
+ handover as it allows the mobile node to continue to receive packets
+ while updating the new MAP, its HA and, potentially, correspondent
+ nodes.
+
+9. Note on MAP Selection by the Mobile Node
+
+ HMIPv6 provides a flexible mechanism for local mobility management
+ within a visited network. As explained earlier, a MAP can exist
+ anywhere in the operator's network (including the AR). Several MAPs
+ can be located within the same domain independently of each other.
+ In addition, overlapping MAP domains are also allowed and
+ recommended. Both static and dynamic hierarchies are supported.
+
+ When the mobile node receives a Router Advertisement including a MAP
+ option, it should perform actions according to the following movement
+ detection mechanisms. In a hierarchical Mobile IP network, such as
+ the one described in this document, the mobile node should be:
+
+ o "Eager" to perform new bindings.
+
+ o "Lazy" in releasing existing bindings.
+
+ The above means that the mobile node should register with any "new"
+ MAP advertised by the AR (Eager). The method by which the mobile
+ node determines whether the MAP is a "new" MAP is described in
+ Section 9.1. The mobile node should not release existing bindings
+ until it no longer receives the MAP option (or receives it with a
+ lifetime of zero) or the lifetime of its existing binding expires
+ (Lazy). This Eager-Lazy approach, described above, will assist in
+ providing a fallback mechanism in case of the failure of one of the
+ MAP routers, as it will reduce the time it takes for a mobile node to
+ inform its correspondent nodes and HA about its new care-of address.
+
+
+
+
+
+Soliman, et al. Standards Track [Page 16]
+
+RFC 5380 HMIPv6 October 2008
+
+
+9.1. MAP Selection in Distributed MAP Environment
+
+ The mobile node needs to consider several factors to optimally select
+ one or more MAPs, where several MAPs are available in the same
+ domain.
+
+ There are no benefits foreseen in selecting more than one MAP and
+ forcing packets to be sent from the higher MAP down through a
+ hierarchy of MAPs. This approach may add forwarding delays and
+ eliminate the robustness of IP routing between the highest MAP and
+ the mobile node; therefore, it is prohibited by this specification.
+ Allowing more than one MAP ("above" the AR) within a network should
+ not imply that the mobile node forces packets to be routed down the
+ hierarchy of MAPs. However, placing more than one MAP "above" the AR
+ can be used for redundancy and as an optimisation for the different
+ mobility scenarios experienced by mobile nodes. The MAPs are used
+ independently of each other by the MN (e.g., each MAP is used for
+ communication to a certain set of CNs).
+
+ In terms of the distance-based selection in a network with several
+ MAPs, a mobile node may choose to register with the furthest MAP to
+ avoid frequent re-registrations. This is particularly important for
+ fast mobile nodes that will perform frequent handoffs. In this
+ scenario, the choice of a more distant MAP would reduce the
+ probability of having to change a MAP and informing all correspondent
+ nodes and the HA.
+
+ In a scenario where several MAPs are discovered by the mobile node in
+ one domain, the mobile node may need sophisticated algorithms to be
+ able to select the appropriate MAP. These algorithms would have the
+ mobile node speed as an input (for distance-based selection) combined
+ with the preference field in the MAP option. However, this
+ specification proposes that the mobile node use the following
+ algorithm as a default, where other optimised algorithms are not
+ available. The following algorithm is simply based on selecting the
+ MAP that is most distant, provided that its preference value did not
+ reach a value of zero. The mobile node operation is shown below:
+
+ 1. Receive and parse all MAP options.
+
+ 2. Arrange MAPs in a descending order, starting with the furthest
+ MAP (i.e., MAP option having largest Dist field).
+
+ 3. Select first MAP in list.
+
+ 4. If either the preference value or the valid lifetime fields are
+ set to zero, select the following MAP in the list.
+
+
+
+
+Soliman, et al. Standards Track [Page 17]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ 5. Repeat step (4) while new MAP options still exist, until a MAP is
+ found with a non-zero preference value and a non-zero valid
+ lifetime.
+
+ Implementing the steps above would result in mobile nodes selecting,
+ by default, the most distant or furthest available MAP. This will
+ continue until the preference value reduces to zero. Following this,
+ mobile nodes will start selecting another MAP.
+
+9.2. MAP Selection in a Flat Mobility Architecture
+
+ Network operators may choose a flat architecture in some cases where
+ a Mobile IPv6 handover may be considered a rare event. In these
+ scenarios, operators may choose to include the MAP function in ARs
+ only. The inclusion of the MAP function in ARs can still be useful
+ to reduce the time required to update all correspondent nodes and the
+ HA. In this scenario, a mobile node may choose a MAP (in the AR) as
+ an anchor point when performing a handoff. This kind of dynamic
+ hierarchy (or anchoring) is only recommended for cases where inter-AR
+ movement is not frequent.
+
+10. Detection and Recovery from MAP Failures
+
+ This specification introduces a MAP that can be seen as a local home
+ agent in a visited network. A MAP, like a home agent, is a single
+ point of failure. If a MAP fails, its binding cache content will be
+ lost, resulting in loss of communication between mobile and
+ correspondent nodes. This situation may be avoided by using more
+ than one MAP on the same link and by utilising a form of context
+ transfer protocol between them. However, MAP redundancy is outside
+ the scope of this document.
+
+ In cases where such protocols are not supported, the mobile node
+ would need to detect MAP failures. The mobile node can detect this
+ situation when it receives a Router Advertisement containing a MAP
+ option with a lifetime of zero. The mobile node should then start
+ the MAP Discovery process and attempt to register with another MAP.
+ After it has selected and registered with another MAP, it will also
+ need to inform correspondent nodes and the home agent if its RCoA has
+ changed. Note that in the presence of a protocol that transfers
+ binding cache entries between MAPs for redundancy purposes, a new MAP
+ may be able to provide the same RCoA to the mobile node (e.g., if
+ both MAPs advertise the same prefix in the MAP option). This would
+ save the mobile node from updating correspondent nodes and the home
+ agent.
+
+
+
+
+
+
+Soliman, et al. Standards Track [Page 18]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ Access Routers can be triggered to advertise a MAP option with a
+ lifetime of zero (indicating MAP failure) in different ways:
+
+ o By manual intervention.
+
+ o In a dynamic manner.
+
+ One way of performing dynamic detection of MAP failure can be done by
+ probing the MAP regularly (e.g., every 10 seconds). If no response
+ is received, an AR MAY try to aggressively probe the MAP for a short
+ period of time (e.g., once every 5 seconds for 15 seconds); if no
+ reply is received, a MAP option may be sent with a valid lifetime
+ value of zero. The exact mechanisms for probing MAPs is outside the
+ scope of this document. The above text simply shows one example of
+ detecting failures.
+
+ This specification does not mandate a particular recovery mechanism.
+ However, any mechanism between the MAP and an AR SHOULD be secure to
+ allow for message authentication, integrity protection, and
+ protection against replay attacks.
+
+ Note that the above suggestion for detecting MAP failure may not
+ detect MAP failures that might take place between probes, i.e.,if a
+ MAP reboots between probes.
+
+11. Tunelling Impacts on MTU
+
+ This specification requires the mobile node to tunnel outgoing
+ traffic to the MAP. Similarly, the MAP tunnels inbound packets to
+ the mobile node. If the mobile node has a home agent elsewhere on
+ the Internet, this will result in double encapsulations of inbound
+ and outbound packets. This may have impacts on the mobile node's
+ path MTU. Hence, mobile nodes MUST consider the encapsulation of
+ traffic between the node and the MAP when calculating the available
+ MTU for upper layers.
+
+12. Security Considerations
+
+ This specification introduces a new concept to Mobile IPv6, namely, a
+ Mobility Anchor Point that acts as a local home agent. It is crucial
+ that the security relationship between the mobile node and the MAP is
+ strong; it MUST involve mutual authentication, integrity protection,
+ and protection against replay attacks. Confidentiality may be needed
+ for payload traffic, such as when the mobile node is unwilling to
+ reveal any traffic to the access network beyond what is needed for
+ the mobile node to attach to the network and communicate with a MAP.
+ Confidentiality is not required for binding updates to the MAP. The
+ absence of any of these protections may lead to malicious mobile
+
+
+
+Soliman, et al. Standards Track [Page 19]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ nodes impersonating other legitimate ones or impersonating a MAP.
+ Any of these attacks will undoubtedly cause undesirable impacts to
+ the mobile node's communication with all correspondent nodes having
+ knowledge of the mobile node's RCoA.
+
+ Three different relationships (related to securing binding updates)
+ need to be considered:
+
+ 1. The mobile node - MAP
+
+ 2. The mobile node - correspondent node
+
+ 3. The mobile node - home agent
+
+12.1. Mobile Node - MAP Security
+
+ In order to allow a mobile node to use the MAP's forwarding service,
+ initial authorisation (specifically for the service, not for the
+ RCoA) MAY be needed. Authorising a mobile node to use the MAP
+ service can be done based on the identity of the mobile node
+ exchanged during the security association (SA) negotiation process.
+ The authorisation may be granted based on the mobile node's identity
+ or based on the identity of a Certificate Authority (CA) that the MAP
+ trusts. For instance, if the mobile node presents a certificate
+ signed by a trusted entity (e.g., a CA that belongs to the same
+ administrative domain, or another trusted roaming partner), it would
+ be sufficient for the MAP to authorise the use of its service. Note
+ that this level of authorisation is independent of authorising the
+ use of a particular RCoA. Similarly, the mobile node trusts the MAP
+ if it presents a certificate signed by the same CA or by another CA
+ that the mobile node is configured to trust (e.g., a roaming
+ partner). It is likely that some deployments would be satisfied with
+ the use of self-signed certificates for either the mobile node or the
+ MAP or both. This guarantees that the mobile node and the MAP are
+ authenticated for address allocation and future binding updates
+ without the need for identity authentication. Hence, the use of
+ trusted third-party certificates is not required by this
+ specification.
+
+ It is important to note that in this specification, authentication
+ and authorisation are effectively the same thing. All the MAP needs
+ in order to allocate the mobile node an RCoA is to authenticate the
+ mobile node and verify that it belongs to a trusted group (based on
+ its certificate).
+
+ IKEv2 MUST be supported by the mobile node and the MAP. IKEv2 allows
+ the use of Extensible Authentication Protocol (EAP) as a mechanism to
+ bootstrap the security association between the communicating peers.
+
+
+
+Soliman, et al. Standards Track [Page 20]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ Hence, EAP can be used with IKEv2 to leverage the Authentication,
+ Authorization, and Accounting (AAA) infrastructure to bootstrap the
+ SA between the mobile node and the MAP. Such a mechanism is useful
+ in scenarios where an administrator wishes to avoid the configuration
+ and management of certificates on mobile nodes. A MAP MAY support
+ the use of EAP over IKEv2.
+
+ If EAP is used with IKEv2, the EAP method runs between the mobile
+ node and a AAA server. Following a successful authentication, the
+ resulting keying material can be used to bootstrap IKEv2 between the
+ MAP and the mobile node. The specification of which EAP methods
+ should be used or how keys are transported between the MAP and the
+ AAA server is outside the scope of this document.
+
+ HMIPv6 uses an additional registration between the mobile node and
+ its current MAP. As explained in this document, when a mobile node
+ moves into a new domain (i.e., served by a new MAP), it obtains an
+ RCoA and an LCoA and registers the binding between these two
+ addresses with the new MAP. The MAP then verifies the BU and creates
+ a binding cache entry with the RCoA and LCoA. Whenever the mobile
+ node gets a new LCoA, it needs to send a new BU that specifies the
+ binding between its RCoA and its new LCoA. This BU needs to be
+ authenticated; otherwise, any host could send a BU for the mobile
+ node's RCoA and hijack the mobile node's packets.
+
+ The MAP does not need to have prior knowledge of the identity of the
+ mobile node or its home address. As a result, the SA between the
+ mobile node and the MAP can be established using any key
+ establishment protocols such as IKEv2. A return routability test is
+ not necessary.
+
+ The MAP needs to set the SA for the RCoA (not the LCoA). This can be
+ performed with IKEv2 [RFC4306]. The mobile node uses its LCoA as the
+ source address, but specifies that the RCoA should be used in the SA.
+
+ This is achieved by using the RCoA as the identity in the IKE
+ CHILD_SA negotiation. This step is identical to the use of the home
+ address in IKE CHILD_SA when negotiating with the home agent.
+
+ The IPsec Peer Authorization Database (PAD) entries and configuration
+ payloads described in [RFC4877] for allocating dynamic home addresses
+ SHOULD be used by the MAP to allocate the RCoA for mobile nodes.
+ Binding updates between the MAP and the mobile node MUST be protected
+ with either Authentication Header (AH) or Encapsulating Security
+ Payload (ESP) in transport mode. When ESP is used, a non-null
+ authentication algorithm MUST be used.
+
+
+
+
+
+Soliman, et al. Standards Track [Page 21]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ The Security Policy Database (SPD) entries in both the home agent and
+ the mobile node are identical to those set up for the home agent and
+ mobile node, respectively, as outlined in [RFC4877].
+
+12.2. Mobile Node - Correspondent Node Security
+
+ Mobile IPv6 [RFC3775] defines a return routability procedure that
+ allows mobile and correspondent nodes to authenticate binding updates
+ and acknowledgements. This specification does not impact the return
+ routability test defined in [RFC3775]. However, it is important to
+ note that mobile node implementers need to be careful when selecting
+ the source address of the HoTI and CoTI messages, defined in
+ [RFC3775]. The source address used in HoTI messages SHOULD be the
+ mobile node's home address unless the mobile node wishes to use the
+ RCoA for route optimisation. The packet containing the HoTI message
+ is encapsulated twice. The inner encapsulating header contains the
+ RCoA in the source address field and the home agent's address in the
+ destination address field. The outer encapsulating header contains
+ the mobile node's LCoA in the source address field and the MAP's
+ address in the destination field.
+
+12.3. Mobile Node - Home Agent Security
+
+ The security relationship between the mobile node and its home agent,
+ as discussed in [RFC3775], is not impacted by this specification.
+
+ The relationship between the MAP and the mobile node is not impacted
+ by the presence of a home agent.
+
+13. IANA Considerations
+
+ Both the MAP option and M flag were allocated for RFC 4140 and will
+ continue to be used by this specification.
+
+14. Acknowledgements
+
+ The authors would like to thank Conny Larsson (Ericsson) and Mattias
+ Pettersson (Ericsson) for their valuable input to this document. The
+ authors would also like to thank the members of the French RNRT
+ MobiSecV6 project (BULL, France Telecom, and INRIA) for testing the
+ first implementation and for their valuable feedback. The INRIA
+ HMIPv6 project is partially funded by the French government.
+
+ In addition, the authors would like to thank the following members of
+ the working group, in alphabetical order: Samita Chakrabarti (Sun),
+ Gregory Daley, Gopal Dommety (Cisco), Francis Dupont (GET/Enst
+ Bretagne), Eva Gustaffson (Ericsson), Dave Johnson (Rice University),
+ Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti
+
+
+
+Soliman, et al. Standards Track [Page 22]
+
+RFC 5380 HMIPv6 October 2008
+
+
+ Kuparinen (Ericsson), Fergal Ladley, Gabriel Montenegro (Microsoft),
+ Nick "Sharkey" Moore, Vidya Narayanan (Qualcomm), Erik Nordmark
+ (Sun), Basavaraj Patil (Nokia), Brett Pentland (NEC), Thomas Schmidt,
+ and Alper Yegin (Samsung) for their comments on the document.
+
+15. References
+
+15.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
+ in IPv6", RFC 3775, June 2004.
+
+ [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+ Protocol", RFC 4306, December 2005.
+
+ [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+ "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+ September 2007.
+
+ [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
+ IKEv2 and the Revised IPsec Architecture", RFC 4877, April
+ 2007.
+
+15.2. Informative References
+
+ [RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization
+ Using a Static Shared Key", RFC 4449, June 2006.
+
+ [RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of
+ Enhancements to Mobile IPv6 Route Optimization", RFC 4651,
+ February 2007.
+
+ [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
+ Optimization for Mobile IPv6", RFC 4866, May 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Soliman, et al. Standards Track [Page 23]
+
+RFC 5380 HMIPv6 October 2008
+
+
+Appendix A. Changes from RFC 4140
+
+ o Dynamic MAP Discovery was removed.
+
+ o Updated the security section to use IKEv2 instead of IKEv1.
+
+ o The document clarified that HMIPv6 can be used without the need
+ for a home agent.
+
+ o Several editorials throughout the document.
+
+ o IKEv2 only is now used to allocate the RCoA.
+
+ RFC 4140 was implemented and interop tested by at least two different
+ organisations. A test suite including test cases for RFC 4140 was
+ also developed by Ericsson and run against both implementations. No
+ major issues were found. The scalability of Dynamic MAP Discovery,
+ defined in RFC 4140, was seen as inappropriate for large-scale
+ deployments and prone to loops. It was removed from this
+ specification.
+
+ At this time, there is no publicly known deployment of this
+ specification.
+
+Authors' Addresses
+
+ Hesham Soliman
+ Elevate Technologies
+
+ EMail: hesham@elevatemobile.com
+
+ Claude Castelluccia
+ INRIA
+
+ Phone: +33 4 76 61 52 15
+ EMail: claude.castelluccia@inria.fr
+
+
+ Karim ElMalki
+ Athonet
+
+ EMail: karim@elmalki.homeip.net
+
+ Ludovic Bellier
+ INRIA
+
+ EMail: ludovic.bellier@inria.fr
+
+
+
+
+Soliman, et al. Standards Track [Page 24]
+
+RFC 5380 HMIPv6 October 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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.
+
+ 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, THE IETF TRUST 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.
+
+Intellectual Property
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Soliman, et al. Standards Track [Page 25]
+