summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4068.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc4068.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc4068.txt')
-rw-r--r--doc/rfc/rfc4068.txt2355
1 files changed, 2355 insertions, 0 deletions
diff --git a/doc/rfc/rfc4068.txt b/doc/rfc/rfc4068.txt
new file mode 100644
index 0000000..16b0966
--- /dev/null
+++ b/doc/rfc/rfc4068.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group R. Koodli, Ed.
+Request for Comments: 4068 Nokia Research Center
+Category: Experimental July 2005
+
+
+ Fast Handovers for Mobile IPv6
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ Mobile IPv6 enables a Mobile Node to maintain its connectivity to the
+ Internet when moving from one Access Router to another, a process
+ referred to as handover. During handover, there is a period during
+ which the Mobile Node is unable to send or receive packets because of
+ link switching delay and IP protocol operations. This "handover
+ latency" resulting from standard Mobile IPv6 procedures, namely
+ movement detection, new Care of Address configuration, and Binding
+ Update, is often unacceptable to real-time traffic such as Voice over
+ IP. Reducing the handover latency could be beneficial to non-real-
+ time, throughput-sensitive applications as well. This document
+ specifies a protocol to improve handover latency due to Mobile IPv6
+ procedures. This document does not address improving the link
+ switching latency.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 1]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Addressing the Handover Latency. . . . . . . . . . . . . 5
+ 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 7
+ 3.3. Protocol Operation of Network-initiated Handover . . . . 9
+ 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.1. Handover Capability Exchange . . . . . . . . . . . . . . 15
+ 5.2. Determining New Care of Address. . . . . . . . . . . . . 15
+ 5.3. Packet Loss. . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 16
+ 6. Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.1. New Neighborhood Discovery Messages. . . . . . . . . . . 17
+ 6.1.1. Router Solicitation for Proxy Advertisement
+ (RtSolPr) . . . . . . . . . . . . . . . . . . . . 17
+ 6.1.2. Proxy Router Advertisement (PrRtAdv). . . . . . . 20
+ 6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 23
+ 6.2.1. Handover Initiate (HI). . . . . . . . . . . . . . 23
+ 6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . 25
+ 6.3. New Mobility Header Messages . . . . . . . . . . . . . . 27
+ 6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . 27
+ 6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . 28
+ 6.3.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 30
+ 6.4. New Options. . . . . . . . . . . . . . . . . . . . . . . 31
+ 6.4.1. IP Address Option . . . . . . . . . . . . . . . . 32
+ 6.4.2. New Router Prefix Information Option. . . . . . . 33
+ 6.4.3. Link-Layer Address (LLA) Option . . . . . . . . . 34
+ 6.4.4. Mobility Header Link-Layer Address (MH-LLA)
+ Option. . . . . . . . . . . . . . . . . . . . . . 35
+ 6.4.5. Neighbor Advertisement Acknowledgment (NAACK) . . 35
+ 7. Configurable Parameters. . . . . . . . . . . . . . . . . . . . 36
+ 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
+ 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 38
+ 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 39
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . . 39
+ 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39
+
+
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 2]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+1. Introduction
+
+ Mobile IPv6 [3] describes the protocol operations for a mobile node
+ to maintain connectivity to the Internet during its handover from one
+ access router to another. These operations involve movement
+ detection, IP address configuration, and location update. The
+ combined handover latency is often sufficient to affect real-time
+ applications. Throughput-sensitive applications can also benefit
+ from reducing this latency. This document describes a protocol to
+ reduce the handover latency.
+
+ This specification addresses the following problem: how to allow a
+ mobile node to send packets as soon as it detects a new subnet link,
+ and how to deliver packets to a mobile node as soon as its attachment
+ is detected by the new access router. The protocol defines IP
+ protocol messages necessary for its operation regardless of link
+ technology. It does this without depending on specific link-layer
+ features while allowing link-specific customizations. By definition,
+ this specification considers handovers that interwork with Mobile IP:
+ once attached to its new access router, an MN engages in Mobile IP
+ operations including Return Routability [3]. There are no special
+ requirements for a mobile node to behave differently with respect to
+ its standard Mobile IP operations.
+
+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 RFC 2119 [1]. The use
+ of the term, "silently ignore" is not defined in RFC 2119. However,
+ the term is used in this document and can be similarly construed.
+
+ The following terminology and abbreviations are used in this
+ document. The reference handover scenario is illustrated in
+ Figure 1.
+
+ Mobile Node (MN)
+ A Mobile IPv6 host.
+
+ Access Point (AP)
+ A Layer 2 device connected to an IP subnet that offers
+ wireless connectivity to an MN. An Access Point Identifier
+ (AP-ID) refers to the AP's L2 address. Sometimes, AP-ID is
+ also referred to as a Base Station Subsystem ID (BSSID).
+
+ Access Router (AR)
+ The MN's default router.
+
+
+
+
+Koodli, Ed. Experimental [Page 3]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ Previous Access Router (PAR)
+ The MN's default router prior to its handover.
+
+ New Access Router (NAR)
+ The MN's default router subsequent to its handover.
+
+ Previous CoA (PCoA)
+ The MN's Care of Address valid on PAR's subnet.
+
+ New CoA (NCoA)
+ The MN's Care of Address valid on NAR's subnet.
+
+ Handover
+ A process of terminating existing connectivity and obtaining
+ new IP connectivity.
+
+ Router Solicitation for Proxy Advertisement (RtSolPr)
+ A message from the MN to the PAR requesting information for
+ a potential handover.
+
+ Proxy Router Advertisement (PrRtAdv)
+ A message from the PAR to the MN that provides information
+ about neighboring links facilitating expedited movement
+ detection. The message also acts as a trigger for network-
+ initiated handover.
+
+ (AP-ID, AR-Info) tuple
+ Contains an access router's L2 and IP addresses, and the
+ prefix valid on the interface to which the Access Point
+ (identified by AP-ID) is attached. The triplet [Router's L2
+ address, Router's IP address, Prefix] is called "AR-Info".
+
+ Assigned Addressing
+ A particular type of NCoA configuration in which the NAR
+ assigns an IPv6 address for the MN. The method by which NAR
+ manages its address pool is not specified in this document.
+
+ Fast Binding Update (FBU)
+ A message from the MN instructing its PAR to redirect its
+ traffic (toward NAR).
+
+ Fast Binding Acknowledgment (FBack)
+ A message from the PAR in response to an FBU.
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 4]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ Fast Neighbor Advertisement (FNA)
+ A message from the MN to the NAR to announce attachment, and
+ to confirm the use of NCoA when the MN has not received an
+ FBACK.
+
+ Handover Initiate (HI)
+ A message from the PAR to the NAR regarding an MN's
+ handover.
+
+ Handover Acknowledge (HAck)
+ A message from the NAR to the PAR as a response to HI.
+
+ v +------------+
+ +-+ | Previous | <
+ | | ---------- | Access | ------ > ----\
+ +-+ | Router | < \
+ MN | (PAR) | \
+ | +------------+ +---------------+
+ | ^ IP | Correspondent |
+ | | Network | Node |
+ V | +---------------+
+ v /
+ v +------------+ /
+ +-+ | New | < /
+ | | ---------- | Access | ------ > ----/
+ +-+ | Router | <
+ MN | (NAR) |
+ +------------+
+
+ Figure 1: Reference Scenario for Handover
+
+3. Protocol Overview
+
+3.1. Addressing the Handover Latency
+
+ The ability to immediately send packets from a new subnet link
+ depends on the "IP connectivity" latency, which in turn depends on
+ the movement detection latency and new CoA configuration latency.
+ Once an MN is IP-capable on the new subnet link, it can send a
+ Binding Update to its Home Agent and one or more correspondents.
+ Once its correspondents successfully process the Binding Update,
+ which typically involves the Return Routability procedure, the MN can
+ receive packets at the new CoA. So, the ability to receive packets
+ from correspondents directly at its new CoA depends on the Binding
+ Update latency as well as the IP connectivity latency.
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 5]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ The protocol enables an MN to quickly detect that it has moved to a
+ new subnet by providing the new access point and the associated
+ subnet prefix information when the MN is still connected to its
+ current subnet (i.e., PAR in Figure 1). For instance, an MN may
+ discover available access points using link-layer specific mechanisms
+ (i.e., a "scan" in WLAN) and then request subnet information
+ corresponding to one or more of those discovered access points. The
+ MN may do this after performing router discovery or at any time while
+ connected to its current router. The result of resolving an
+ identifier associated with an access point is a [AP-ID, AR-Info]
+ tuple, which an MN can use in readily detecting movement: when
+ attachment to an access point with AP-ID takes place, the MN knows
+ the corresponding new router's coordinates including its prefix, IP
+ address, and L2 address. The "Router Solicitation for Proxy
+ Advertisement (RtSolPr)" and "Proxy Router Advertisement (PrRtAdv)"
+ messages (see Section 6.1) are used for aiding movement detection.
+
+ Through the RtSolPr and PrRtAdv messages, the MN also formulates a
+ prospective new CoA (NCoA) when it is still present on the PAR's
+ link. Hence, the latency due to new prefix discovery subsequent to
+ handover is eliminated. Furthermore, this prospective address can be
+ used immediately after attaching to the new subnet link (i.e., NAR's
+ link) when the MN has received a "Fast Binding Acknowledgment
+ (FBack)" message prior to its movement. If it moves without
+ receiving an FBack, the MN can still start using NCoA after
+ announcing its attachment through a "Fast Neighbor Advertisement
+ (FNA)" message. NAR responds to FNA if the tentative address is
+ already in use thereby reducing NCoA configuration latency. Under
+ some limited conditions in which the probability of address collision
+ is considered insignificant, it may be possible to use NCoA
+ immediately after attaching to the new link. Even so, all
+ implementations MUST support and SHOULD use the mechanism specified
+ in this document to avoid potential address conflicts.
+
+ To reduce the Binding Update latency, the protocol specifies a tunnel
+ between the Previous CoA (PCoA) and the NCoA. An MN sends a "Fast
+ Binding Update" message to its Previous Access Router to establish
+ this tunnel. When feasible, the MN SHOULD send an FBU from PAR's
+ link. Otherwise, it should be sent immediately after attachment to
+ NAR has been detected. Subsequent sections describe the protocol
+ mechanics. As a result, PAR begins tunneling packets arriving for
+ PCoA to NCoA. Such a tunnel remains active until the MN completes
+ the Binding Update with its correspondents. In the opposite
+ direction, the MN SHOULD reverse tunnel packets to PAR until it
+ completes the Binding Update. PAR SHOULD forward the inner packet in
+ the tunnel to its destination (i.e., to the MN's correspondent).
+ Such a reverse tunnel ensures that packets containing PCoA as a
+ source IP address are not dropped due to ingress filtering. Readers
+
+
+
+Koodli, Ed. Experimental [Page 6]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ may observe that even though the MN is IP-capable on the new link, it
+ cannot use NCoA directly with its correspondents without the
+ correspondents first establishing a binding cache entry (for NCoA).
+ Forwarding support for PCoA is provided through a reverse tunnel
+ between the MN and the PAR.
+
+ Setting up a tunnel alone does not ensure that the MN receives
+ packets as soon as it is attached to a new subnet link, unless the
+ NAR can detect the MN's presence. A neighbor discovery operation
+ involving a neighbor's address resolution (i.e., Neighbor
+ Solicitation and Neighbor Advertisement) typically results in
+ considerable delay, sometimes lasting multiple seconds. For
+ instance, when arriving packets trigger NAR to send Neighbor
+ Solicitation before the MN attaches, subsequent retransmissions of
+ address resolution are separated by a default period of one second
+ each. To circumvent this delay, an MN announces its attachment
+ through the FNA message that allows the NAR to consider MN to be
+ reachable. If there is no existing entry, FNA allows NAR to create
+ one. If NAR already has an entry, FNA updates the entry while taking
+ potential address conflicts into consideration. Through tunnel
+ establishment for PCoA and fast advertisement, the protocol provides
+ expedited forwarding of packets to the MN.
+
+ The protocol also provides the following important functionalities.
+ The access routers can exchange messages to confirm that a proposed
+ NCoA is acceptable. For instance, when an MN sends an FBU from PAR's
+ link, FBack can be delivered after the NAR considers the NCoA
+ acceptable for use. This is especially useful when addresses are
+ assigned by the access router. The NAR can also rely on its trust
+ relationship with PAR before providing forwarding support for the MN.
+ That is, it may create a forwarding entry for the NCoA subject to
+ "approval" from PAR which it trusts. Finally, the access routers
+ could transfer network-resident contexts, such as access control,
+ QoS, and header compression, in conjunction with handover. For these
+ operations, the protocol provides "Handover Initiate (HI)" and
+ "Handover Acknowledge (HAck)" messages. Both of these messages MUST
+ be supported and SHOULD be used. The access routers MUST have
+ necessary security association established by means outside the scope
+ of this document.
+
+3.2. Protocol Operation
+
+ The protocol begins when an MN sends an RtSolPr to its access router
+ to resolve one or more Access Point Identifiers to subnet-specific
+ information. In response, the access router (e.g., PAR in Figure 1)
+ sends a PrRtAdv message containing one or more [AP-ID, AR-Info]
+ tuples. The MN may send a RtSolPr at any convenient time, for
+ instance as a response to some link-specific event (a "trigger") or
+
+
+
+Koodli, Ed. Experimental [Page 7]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ simply after performing router discovery. However, the expectation
+ is that prior to sending RtSolPr, the MN will have discovered the
+ available APs by link-specific methods. The RtSolPr and PrRtAdv
+ messages do not establish any state at the access router; their
+ packet formats are defined in Section 6.1.
+
+ With the information provided in the PrRtAdv message, the MN
+ formulates a prospective NCoA and sends an FBU message when a link-
+ specific handover event occurs. The purpose of the FBU is to
+ authorize PAR to bind PCoA to NCoA, so that arriving packets can be
+ tunneled to the new location of the MN. Whenever feasible, the FBU
+ SHOULD be sent from PAR's link. For instance, an internal link-
+ specific trigger could enable FBU transmission from the previous
+ link. When it is not feasible, the FBU is sent from the new link.
+ Care must be taken to ensure that the NCoA used in FBU does not
+ conflict with an address already in use by some other node on the
+ link. For this, FBU encapsulation within FNA MUST be implemented and
+ SHOULD be used (see below) when the FBU is sent from NAR's link.
+
+ The format and semantics of FBU processing are specified in Section
+ 6.3.1.
+
+ Depending on whether an FBack is received on the previous link (which
+ clearly depends on whether the FBU was sent in the first place),
+ there are two modes of operation.
+
+ 1. The MN receives an FBack on the previous link. This means that
+ packet tunneling is already in progress by the time the MN
+ handovers to NAR. The MN SHOULD send FNA immediately after
+ attaching to NAR, so that arriving and buffered packets can be
+ forwarded to the MN right away.
+
+ Before sending an FBack to an MN, PAR can determine whether the
+ NCoA is acceptable to the NAR through the exchange of HI and HAck
+ messages. When assigned addressing (i.e., addresses are assigned
+ by the router) is used, the proposed NCoA in the FBU is carried in
+ HI, and the NAR MAY assign the proposed NCoA. Such an assigned
+ NCoA MUST be returned in HAck, and the PAR MUST in turn provide
+ the assigned NCoA in the FBack. If there is an assigned NCoA
+ returned in the FBack, the MN MUST use the assigned address (and
+ not the proposed address in the FBU) upon attaching to NAR.
+
+ 2. The MN does not receive the FBack on the previous link because the
+ MN has not sent the FBU or the MN has left the link after sending
+ the FBU (which itself may be lost), but before receiving an FBack.
+ Without receiving an FBack in the latter case, the MN cannot
+ ascertain whether PAR has successfully processed the FBU. Hence,
+ it (re)sends an FBU as soon as it attaches to NAR. To enable NAR
+
+
+
+Koodli, Ed. Experimental [Page 8]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ to forward packets immediately (when FBU has been processed) and
+ to allow NAR to verify whether NCoA is acceptable, the MN SHOULD
+ encapsulate the FBU in the FNA. If NAR detects that NCoA is in
+ use when processing the FNA, for instance while creating a
+ neighbor entry, it MUST discard the inner FBU packet and send a
+ Router Advertisement with the "Neighbor Advertisement Acknowledge
+ (NAACK)" option in which NAR MAY include an alternate IP address
+ for the MN to use. This discarding avoids the rare and
+ undesirable outcome that results from address collision. Detailed
+ FNA processing rules are specified in Section 6.3.3.
+
+ The scenario in which an MN sends an FBU and receives an FBack on
+ PAR's link is illustrated in Figure 2. For convenience, this
+ scenario is characterized as "predictive" mode of operation. The
+ scenario in which the MN sends an FBU from NAR's link is illustrated
+ in Figure 3. For convenience, this scenario is characterized as a
+ "reactive" mode of operation. Note that the reactive mode also
+ includes the case in which an FBU has been sent from PAR's link but
+ an FBack has not been received yet.
+
+ Finally, the PrRtAdv message may be sent unsolicited (i.e., without
+ the MN first sending a RtSolPr). This mode is described in Section
+ 3.3.
+
+3.3. Protocol Operation of Network-initiated Handover
+
+ In some wireless technologies, the handover control may reside in the
+ network even though the decision to undergo handover may be mutually
+ arrived at between the MN and the network. In these networks, the
+ PAR can send an unsolicited PrRtAdv containing the link layer
+ address, IP address, and subnet prefixes of the NAR when the network
+ decides that a handover is imminent. The MN MUST process this
+ PrRtAdv to configure a new care of address on the new subnet, and
+ MUST send an FBU to PAR prior to switching to the new link. After
+ transmitting PrRtAdv, the PAR MUST continue to forward packets to the
+ MN on its current link until the FBU is received. The rest of the
+ operation is the same as that described in Section 3.2.
+
+ The unsolicited PrRtAdv also allows the network to inform the MN
+ about geographically adjacent subnets without the MN having to
+ explicitly request that information. This can reduce the amount of
+ wireless traffic required for the MN to obtain a neighborhood
+ topology map of links and subnets. Such usage of PrRtAdv is
+ decoupled from the actual handover; see Section 6.1.2.
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 9]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ MN PAR NAR
+ | | |
+ |------RtSolPr------->| |
+ |<-----PrRtAdv--------| |
+ | | |
+ |------FBU----------->|--------HI--------->|
+ | |<------HAck---------|
+ | <--FBack---|--FBack---> |
+ | | |
+ disconnect forward |
+ | packets===============>|
+ | | |
+ | | |
+ connect | |
+ | | |
+ |--------- FNA --------------------------->|
+ |<=================================== deliver packets
+ | |
+
+ Figure 2: "Predictive" Fast Handover
+
+4. Protocol Details
+
+ All descriptions refer to Figure 1.
+
+ After discovering one or more nearby access points, the MN sends
+ RtSolPr to resolve access point identifiers to subnet router
+ information. This is convenient to do after performing router
+ discovery. However, the MN can send RtSolPr at any time, e.g., when
+ one or more new access points are discovered. The MN can also send
+ RtSolPr more than once during its attachment to PAR. The trigger for
+ sending RtSolPr can originate from a link-specific event, such as the
+ promise of a better signal strength from another access point coupled
+ with fading signal quality with the current access point. Such
+ events, often broadly referred to as "L2 triggers", are outside the
+ scope of this document. Nevertheless, they serve as events that
+ invoke this protocol. For instance, when a "link up" indication is
+ obtained on the new link, protocol messages (e.g., FNA) can be
+ immediately transmitted. Implementations SHOULD make use of such
+ triggers whenever possible.
+
+
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 10]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ MN PAR NAR
+ | | |
+ |------RtSolPr------->| |
+ |<-----PrRtAdv--------| |
+ | | |
+ disconnect | |
+ | | |
+ | | |
+ connect | |
+ |------FNA[FBU]-------|------------------->|
+ | |<-----FBU-----------|
+ | |------FBack-------->|
+ | forward |
+ | packets===============>|
+ | | |
+ |<=================================== deliver packets
+ | |
+
+ Figure 3: "Reactive" Fast Handover
+
+ The RtSolPr message contains one or more AP-IDs. A wildcard requests
+ all available tuples.
+
+ As a response to RtSolPr, PAR sends a PrRtAdv message that indicates
+ one of the following possible conditions.
+
+ 1. If the PAR does not have an entry corresponding to the new access
+ point, it MUST respond indicating that the new access point is
+ unknown. The MN MUST stop fast handover protocol operations on
+ the current link. The MN MAY send an FBU from its new link.
+
+ 2. If the new access point is connected to the PAR's current
+ interface (to which MN is attached), the PAR MUST respond with a
+ Code value indicating that the new access point is connected to
+ the current interface, but not send any prefix information. This
+ scenario could arise, for example, when several wireless access
+ points are bridged into a wired network. No further protocol
+ action is necessary.
+
+ 3. If the new access point is known and the PAR has information about
+ it, then PAR MUST respond indicating that the new access point is
+ known and supply the [AP-ID, AR-Info] tuple. If the new access
+ point is known, but does not support fast handover, the PAR MUST
+ indicate this with Code 3 (See Section 6.1.2).
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 11]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ 4. If a wildcard is supplied as an identifier for the new access
+ point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples
+ that are subject to path MTU restrictions (i.e., provide any `n'
+ tuples without exceeding the link MTU).
+
+ When further protocol action is necessary, some implementations MAY
+ choose to begin buffering copies of incoming packets at the PAR. If
+ such FIFO buffering is used, the PAR MUST continue forwarding the
+ packets to PCoA (i.e., buffer and forward). Such buffering can be
+ useful when the MN leaves without sending the FBU message from the
+ PAR's link. The PAR SHOULD stop buffering after processing the FBU
+ message. The size of the buffer is an implementation-specific
+ consideration.
+
+ The method by which Access Routers exchange information about their
+ neighbors, and thereby allow construction of Proxy Router
+ Advertisements with information about neighboring subnets is outside
+ the scope of this document.
+
+ The RtSolPr and PrRtAdv messages MUST be implemented by an MN and an
+ access router that supports fast handovers. However, when the
+ parameters necessary for the MN to send packets immediately upon
+ attaching to the NAR are supplied by the link layer handover
+ mechanism itself, use of above messages is optional on such links.
+
+ After a PrRtAdv message is processed, the MN sends an FBU at a time
+ determined by link-specific events, and includes the proposed NCoA.
+ The MN SHOULD send the FBU from PAR's link whenever "anticipation" of
+ handover is feasible. When anticipation is not feasible or when it
+ has not received an FBack, the MN sends an FBU immediately after
+ attaching to NAR's link. This FBU SHOULD be encapsulated in an FNA
+ message. The encapsulation allows the NAR to discard the (inner) FBU
+ packet if an address conflict is detected as a result of (outer) FNA
+ packet processing (see FNA processing below). In response to the
+ FBU, the PAR establishes a binding between PCoA ("Home Address") and
+ NCoA, and sends the FBack to the MN. Prior to establishing this
+ binding, PAR SHOULD send an HI message to NAR, and receive HAck in
+ response. To determine the NAR's address for the HI message, the PAR
+ can perform the longest prefix match of NCoA (in FBU) with the prefix
+ list of neighboring access routers. When the source IP address of
+ the FBU is PCoA, i.e., the FBU is sent from the PAR's link, and the
+ HI message MUST have a Code value set to 0; see Section 6.2.1. When
+ the source IP address of the FBU is not PCoA, i.e., the FBU is sent
+ from the NAR's link, the HI message MUST have a Code value of 1; see
+ Section 6.2.1.
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 12]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ The HI message contains the PCoA, Link-Layer Address, and the NCoA of
+ the MN. In response to processing an HI message with Code 0, the NAR
+
+ 1. determines whether NCoA supplied in the HI message is a valid
+ address for use. If it is, the NAR starts proxying [6] the
+ address for PROXY_ND_LIFETIME during which the MN is expected to
+ connect to the NAR. The NAR MAY use the Link-Layer Address to
+ verify whether a corresponding IP address exists in its forwarding
+ tables.
+
+ 2. allocates NCoA for the MN when assigned addressing is used,
+ creates a proxy neighbor cache entry, and begins defending it.
+ The NAR MAY allocate the NCoA proposed in HI.
+
+ 3. MAY create a host route entry for PCoA in case NCoA cannot be
+ accepted or assigned. This host route entry SHOULD be implemented
+ such that until the MN's presence is detected, either through
+ explicit announcement by the MN or by other means, arriving
+ packets do not invoke neighbor discovery. The NAR MAY also set up
+ a reverse tunnel to the PAR in this case.
+
+ 4. provides the status of the handover request in the Handover
+ Acknowledge (HAck) message.
+
+ When the Code value in HI is 1, NAR MUST skip the above operations
+ since it would have performed those operations during FNA processing.
+ However, it SHOULD be prepared to process any other options that may
+ be defined in the future. Sending an HI message with Code 1 allows
+ NAR to validate the neighbor cache entry it creates for the MN during
+ FNA processing. That is, NAR can make use of the knowledge that its
+ trusted peer (i.e., PAR) has a trust relationship with the MN.
+
+ If HAck contains an assigned NCoA, the FBack MUST include it, and the
+ MN MUST use the address provided in the FBack. The PAR MAY send the
+ FBack to the previous link to facilitate faster reception in the
+ event that the MN is still present. The result of the FBU and FBack
+ processing is that PAR begins tunneling the MN's packets to NCoA. If
+ the MN does not receive an FBack message even after retransmitting
+ the FBU for FBU_RETRIES, it must assume that fast handover support is
+ not available and stop the protocol operation.
+
+ When the MN establishes link connectivity with the NAR, it SHOULD
+ send a Fast Neighbor Advertisement (FNA) message (see 6.3.3). If the
+ MN has not received an FBack by the time the FNA is being sent, it
+ SHOULD encapsulate the FBU in the FNA and send them together.
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 13]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ When the NCoA corresponding to the FNA message is acceptable, the NAR
+ MUST
+
+ 1. delete its proxy neighbor cache entry, if any is present.
+
+ 2. create a neighbor cache entry and set its state to REACHABLE
+ without overwriting an existing entry for a different layer 2
+ address.
+
+ 3. forward any buffered packets.
+
+ 4. enable the host route entry for PCoA, if any is present.
+
+ When the NCoA corresponding to the FNA message is not acceptable, the
+ NAR MUST
+
+ 1. discard the inner (FBU) packet.
+
+ 2. send a Router Advertisement with the NAACK option in which it MAY
+ include an alternate NCoA for use. This message MUST be sent to
+ the source IP address present in the FNA using the same Layer 2
+ address present in the FNA.
+
+ If the MN receives a Router Advertisement with a NAACK option, it
+ MUST use the IP address, if any, provided in the NAACK option.
+ Otherwise, the MN should configure another NCoA. Subsequently, the
+ MN SHOULD send an FBU using the new CoA. As a special case, the
+ address supplied in NAACK could be PCoA itself, in which case the MN
+ MUST NOT send any more FBUs.
+
+ Once the MN has confirmed its NCoA, it SHOULD send a Neighbor
+ Advertisement message. This message allows MN's neighbors to update
+ their neighbor cache entries with the MN's addresses.
+
+ Just as in Mobile IPv6, the PAR sets the 'R' bit in the Prefix
+ Information option, and includes its 128 bit global address in the
+ router advertisements. This allows the mobile nodes to learn the
+ PAR's global IPv6 address. The MN reverse tunnels its packets to the
+ same global address of PAR. The tunnel end-point addresses must be
+ configured accordingly. When PAR receives a reverse tunneled packet,
+ it must verify if a secure binding exists for the MN identified by
+ PCoA in the tunneled packet, before forwarding the packet.
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 14]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+5. Miscellaneous
+
+5.1. Handover Capability Exchange
+
+ The MN expects a PrRtAdv in response to its RtSolPr message. If the
+ MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it
+ must assume that PAR does not support the fast handover protocol and
+ stop sending RtSolPr messages.
+
+ Even if an MN's current access router is capable of fast handover,
+ the new access router to which the MN attaches may be incapable of
+ fast handover. This is indicated to the MN during "runtime", through
+ the PrRtAdv message with a Code value of 3 (see Section 6.1.2).
+
+5.2. Determining New Care of Address
+
+ Typically, the MN formulates its prospective NCoA using the
+ information provided in a PrRtAdv message and sends the FBU. The PAR
+ MUST use the NCoA present in the FBU in its HI message. The NAR MUST
+ verify if the NCoA present in HI is already in use. In any case, NAR
+ MUST respond to HI using a HAck, in which it may include another NCoA
+ to use, especially when assigned address configuration is used. If
+ there is a CoA present in HAck, the PAR MUST include it in the FBack
+ message.
+
+ If a PrRtAdv message carries an NCoA, the MN MUST use it as its
+ prospective NCoA.
+
+5.3. Packet Loss
+
+ Handover involves link switching, which may not be exactly
+ coordinated with fast handover signaling. Furthermore, the arrival
+ pattern of packets is dependent on many factors, including
+ application characteristics, network queuing behaviors, etc. Hence,
+ packets may arrive at the NAR before the MN is able to establish its
+ link there. These packets will be lost unless they are buffered by
+ the NAR. Similarly, if the MN attaches to the NAR and then sends an
+ FBU message, packets arriving at the PAR will be lost unless they are
+ buffered. This protocol provides an option to indicate a request for
+ buffering at the NAR in the HI message. When the PAR requests this
+ feature (for the MN), it SHOULD also provide its own support for
+ buffering.
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 15]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+5.4. DAD Handling
+
+ Duplicate Address Detection (DAD) was defined in [7] to avoid address
+ duplication on links when stateless address auto-configuration is
+ used. The use of DAD to verify the uniqueness of an IPv6 address
+ configured through stateless auto-configuration adds delays to a
+ handover.
+
+ The probability of an interface identifier duplication on the same
+ subnet is very low, however it cannot be ignored. In this document,
+ certain precautions are proposed to minimize the effects of a
+ duplicate address occurrence.
+
+ In some cases, the NAR may already have the knowledge required to
+ assess whether the MN's address is a duplicate before the MN moves to
+ the new subnet. For example, the NAR can have a list of all nodes on
+ its subnet, perhaps for access control, and by searching this list,
+ it can confirm whether the MN's address is a duplicate. The result
+ of this search is sent back to the PAR in the HAck message. If such
+ knowledge is not available at the NAR, it may indicate this by not
+ confirming the NCoA in the HAck message. The NAR may also indicate
+ this in the NAACK option in response to the FNA message. In such
+ cases, the MN would have to follow the address configuration
+ procedure according to [6] after attaching to the NAR.
+
+5.5. Fast or Erroneous Movement
+
+ Although this specification is for fast handover, the protocol is
+ limited in terms of how fast an MN can move. Ping-Pong is a special
+ case of fast movement, where an MN moves between the same two access
+ points rapidly. Another instance of the same problem is erroneous
+ movement, i.e., the MN receives information prior to a handover that
+ it is moving to a new access point, but it is either moved to a
+ different one or it aborts movement altogether. All of the above
+ behaviors are usually the result of link layer idiosyncrasies and
+ thus are often resolved at the link layer itself.
+
+ IP layer mobility, however, introduces its own limits. IP layer
+ handovers should occur at a rate suitable for the MN to update the
+ binding of, at least, its HA and preferably that of every CN with
+ which it is in communication. An MN that moves faster than necessary
+ for this signaling to complete, which may be a few seconds, may start
+ losing packets. The signaling cost over the air interface and in the
+ network may increase significantly, especially in the case of rapid
+ movement between several access routers. To avoid the signaling
+ overhead, the following measures are suggested.
+
+
+
+
+
+Koodli, Ed. Experimental [Page 16]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ An MN returning to the PAR before updating the necessary bindings
+ when present on the NAR MUST send a Fast Binding Update with the Home
+ Address equal to the MN's PCoA and a lifetime of zero to the PAR.
+ The MN should have a security association with the PAR since it
+ performed a fast handover to the NAR. The PAR, upon receiving this
+ Fast Binding Update, will check its set of outgoing (temporary fast
+ handover) tunnels. If it finds a match, it SHOULD tear down that
+ tunnel (i.e., stop forwarding packets for this MN and start
+ delivering packets directly to the node instead). The MN SHOULD NOT
+ attempt to use any of the fast handover mechanisms described in this
+ specification and SHOULD revert back to standard Mobile IPv6.
+
+ Temporary tunnels for the purpose of fast handovers should use short
+ lifetimes (a small number of seconds or less). The lifetime of such
+ tunnels should be enough to allow an MN to update all its active
+ bindings. The default lifetime of the tunnel should be the same as
+ the lifetime value in the FBU message.
+
+ The effect of erroneous movement is typically limited to the loss of
+ packets since routing can change and the PAR may forward packets
+ toward another router before the MN actually connects to that router.
+ If the MN discovers itself on an unanticipated access router, a Fast
+ Binding Update to the PAR SHOULD be sent. Since Fast Binding Updates
+ are authenticated, they supercede the existing binding and packets
+ MUST be redirected to the newly confirmed location of the MN.
+
+6. Message Formats
+
+ All the ICMPv6 messages have a common Type specified in [4]. The
+ messages are distinguished based on the Subtype field (see below).
+ The values for the Subtypes are specified in Section 9. For all the
+ ICMPv6 messages, the checksum is defined in [2].
+
+6.1. New Neighborhood Discovery Messages
+
+6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr)
+
+ Mobile Nodes send Router Solicitation for Proxy Advertisement in
+ order to prompt routers for Proxy Router Advertisements. All the
+ Link-Layer Address options have the format defined in 6.4.3.
+
+
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 17]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ 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 | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Subtype | Reserved | Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+-+-+-+-+-+-+-+-
+
+ Figure 4: Router Solicitation for Proxy (RtSolPr) Message
+
+ IP Fields:
+
+ Source Address
+ An IP address assigned to the sending interface.
+
+ Destination Address
+ The address of the Access Router or the all routers
+ multicast address.
+
+ Hop Limit 255. See RFC 2461.
+
+ Authentication Header
+ If a Security Association for the IP Authentication
+ Header exists between the sender and the
+ destination address, then the sender SHOULD include
+ this header. See RFC 2402 [5].
+
+ ICMP Fields:
+
+ Type The Experimental Mobility Protocol Type. See [4].
+
+
+ Code 0
+
+ Checksum The ICMPv6 checksum.
+
+ Subtype 2
+
+ Reserved MUST be set to zero by the sender and ignored by
+ the receiver.
+
+ Identifier MUST be set by the sender so that replies can be
+ matched to this Solicitation.
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 18]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ Valid Options:
+
+ Source Link-Layer Address
+ When known, the Link-Layer Address of the sender
+ SHOULD be included using the Link-Layer Address
+ option. See the LLA option format below.
+
+ New Access Point Link-Layer Address
+ The Link-Layer Address or identification of the
+ access point for which the MN requests routing
+ advertisement information. It MUST be included in
+ all RtSolPr messages. More than one such address
+ or identifier can be present. This field can also
+ be a wildcard address with all bits set to zero.
+
+ Future versions of this protocol may define new option types.
+ Receivers MUST silently ignore any options that they do not recognize
+ and continue processing the rest of the message.
+
+ Including the source LLA option allows the receiver to record the
+ sender's L2 address so that neighbor discovery can be avoided when
+ the receiver needs to send packets back to the sender (of the RtSolPr
+ message).
+
+ When a wildcard is used for a New Access Point LLA, no other New
+ Access Point LLA options must be present.
+
+ A Proxy Router Advertisement (PrRtAdv) message should be received by
+ the MN in response to a RtSolPr. If such a message is not received
+ in a timely manner (no less than twice the typical round trip time
+ (RTT) over the access link or 100 milliseconds if RTT is not known),
+ it SHOULD resend the RtSolPr message. Subsequent retransmissions can
+ be up to RTSOLPR_RETRIES, but MUST use an exponential backoff in
+ which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled
+ prior to each instance of retransmission. If Proxy Router
+ Advertisement is not received by the time the MN disconnects from the
+ PAR, the MN SHOULD send an FBU immediately after configuring a new
+ CoA.
+
+ When RtSolPr messages are sent more than once, they MUST be rate
+ limited with MAX_RTSOLPR_RATE per second. During each use of a
+ RtSolPr, exponential backoff is used for retransmissions.
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 19]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+6.1.2. Proxy Router Advertisement (PrRtAdv)
+
+ Access routers send Proxy Router Advertisement messages gratuitously
+ if the handover is network-initiated or as a response to a RtSolPr
+ message from an MN, providing the Link-Layer Address, IP address, and
+ subnet prefixes of neighboring routers. All the Link-Layer Address
+ options have the format defined in Section 6.4.3.
+
+ IP Fields:
+
+ Source Address
+ MUST be the Link-Local Address assigned to the
+ interface from which this message is sent.
+
+ Destination Address
+ The Source Address of an invoking Router
+ Solicitation for a Proxy Advertisement or the
+ address of the node the Access Router is
+ instructing to handover.
+
+ 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 | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Subtype | Reserved | Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+-+-+-+-+-+-+-+-
+
+ Figure 5: Proxy Router Advertisement (PrRtAdv) Message
+
+ Hop Limit 255. See RFC 2461 [6].
+
+
+ Authentication Header
+ If a Security Association for the IP Authentication
+ Header exists between the sender and the
+ destination address, the sender SHOULD include this
+ header. See RFC 2402 [5].
+
+ ICMP Fields:
+
+ Type The Experimental Mobility Protocol Type. See RFC
+ 4065 [4].
+
+ Code 0, 1, 2, 3 or 4. See below.
+
+
+
+
+Koodli, Ed. Experimental [Page 20]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ Checksum The ICMPv6 checksum.
+
+ Subtype 3
+
+ Reserved MUST be set to zero by the sender and ignored by
+ the receiver.
+
+ Identifier Copied from the Router Solicitation for Proxy
+ Advertisement or set to Zero if unsolicited.
+
+ Valid Options in the following order:
+
+ Source Link-Layer Address
+ When known, the Link-Layer Address of the sender
+ SHOULD be included using the Link-Layer Address
+ option. See the LLA option format below.
+
+ New Access Point Link-Layer Address
+ The Link-Layer Address or identification of the
+ access point is copied from the RtSolPr message.
+ This option MUST be present.
+
+ New Router's Link-Layer Address
+ The Link-Layer Address of the Access Router for
+ which this message is proxied. This option MUST be
+ included when Code is 0 or 1.
+
+ New Router's IP Address
+ The IP address of NAR. This option MUST be
+ included when Code is 0 or 1.
+
+ New Router Prefix Information Option.
+ Specifies the prefix of the Access Router for which
+ the message is proxied and is used for address
+ auto-configuration. This option MUST be included
+ when Code is 0 or 1. However, when this prefix is
+ the same as that used in the New Router's IP
+ Address option (above), the Prefix Information
+ option need not be present.
+
+ New CoA Option
+ MAY be present when a PrRtAdv is sent unsolicited.
+ PAR MAY compute a new CoA using NAR's prefix
+ information and the MN's L2 address, or by any
+ other means.
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 21]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ Future versions of this protocol may define new option types.
+ Receivers MUST silently ignore any options they do not recognize and
+ continue processing the message.
+
+ Currently, Code values 0, 1, 2, 3 and 4 are defined.
+
+ A Proxy Router Advertisement with Code 0 means that the MN should use
+ the [AP-ID, AR-Info] tuple (present in the options above) for
+ movement detection and NCoA formulation. In this case, the Option-
+ Code field in the New Access Point LLA option is 1, reflecting the
+ LLA of the access point for which the rest of the options are
+ related. Multiple tuples may be present.
+
+ A Proxy Router Advertisement with Code 1 means that the message is
+ sent unsolicited. If a New CoA option is present following the New
+ Router Prefix Information option, the MN SHOULD use the supplied NCoA
+ and send the FBU immediately or else stand to lose service. This
+ message acts as a network-initiated handover trigger; see Section
+ 3.3. The Option-Code field in the New Access Point LLA option (see
+ below) in this case is 1 reflecting the LLA of the access point for
+ which the rest of the options are related.
+
+ A Proxy Router Advertisement with Code 2 means that no new router
+ information is present. Each New Access Point LLA option contains an
+ Option-Code value (described below) that indicates a specific
+ outcome.
+
+ - When the Option-Code field in the New Access Point LLA option
+ is 5, handover to that access point does not require a change
+ of CoA. No other options are required in this case.
+
+ - When the Option-Code field in the New Access Point LLA option
+ is 6, the PAR is not aware of the Prefix Information requested.
+ The MN SHOULD attempt to send an FBU as soon as it regains
+ connectivity with the NAR. No other options are required in
+ this case.
+
+ - When the Option-Code field in the New Access Point LLA option
+ is 7, it means that the NAR does not support fast handover.
+ The MN MUST stop fast handover protocol operations. No other
+ options are required in this case.
+
+ A Proxy Router Advertisement with Code 3 means that new router
+ information is only present for a subset of access points requested.
+ The Option-Code field values (defined above including a value of 1)
+ distinguish different outcomes for individual access points.
+
+
+
+
+
+Koodli, Ed. Experimental [Page 22]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ A Proxy Router Advertisement with Code 4 means that the subnet
+ information regarding neighboring access points is sent unsolicited,
+ but the message is not a handover trigger, unlike when the message is
+ sent with Code 1. Multiple tuples may be present.
+
+ When a wildcard AP identifier is supplied in the RtSolPr message, the
+ PrRtAdv message should include any `n' [Access Point Identifier,
+ Link-Layer Address option, Prefix Information Option] tuples
+ corresponding to the PAR's neighborhood.
+
+6.2. Inter-Access Router Messages
+
+6.2.1. Handover Initiate (HI)
+
+ The Handover Initiate (HI) is an ICMPv6 message sent by an Access
+ Router (typically PAR) to another Access Router (typically NAR) to
+ initiate the process of a MN's handover.
+
+ 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 | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Subtype |S|U| Reserved | Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+-+-+-+-+-+-+-+-
+
+ Figure 6: Handover Initiate (HI) Message
+
+ IP Fields:
+
+ Source Address
+ The IP address of the PAR.
+
+ Destination Address
+ The IP address of the NAR.
+
+ Hop Limit 255. See RFC 2461 [6].
+
+ Authentication Header
+ The authentication header MUST be used when this
+ message is sent. See RFC 2402 [5].
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 23]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ ICMP Fields:
+
+ Type The Experimental Mobility Protocol Type. See RFC
+ 4065 [4].
+
+ Code 0 or 1. See below
+
+ Checksum The ICMPv6 checksum.
+
+ Subtype 4
+
+ S flag Assigned address configuration flag. When set,
+ this message requests a new CoA to be returned by
+ the destination. May be set when Code = 0. MUST
+ be 0 when Code = 1.
+
+ U flag Buffer flag. When set, the destination SHOULD
+ buffer any packets moving toward the node indicated
+ in the options of this message. Used when Code =
+ 0, SHOULD be set to 0 when Code = 1.
+
+ Reserved MUST be set to zero by the sender and ignored by
+ the receiver.
+
+ Identifier MUST be set by the sender so replies can be matched
+ to this message.
+
+ Valid Options:
+
+ Link-Layer Address of MN
+ The Link-Layer Address of the MN that is undergoing
+ handover to the destination (i.e., NAR). This
+ option MUST be included so that the destination can
+ recognize the MN.
+
+ Previous Care of Address
+ The IP address used by the MN while attached to the
+ originating router. This option SHOULD be included
+ so that a host route can be established if
+ necessary.
+
+ New Care of Address
+ The IP address the MN wishes to use when connected
+ to the destination. When the `S' bit is set, the
+ NAR MAY assign this address.
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 24]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ The PAR uses a Code value of 0 when it processes an FBU with PCoA as
+ a source IP address. The PAR uses a Code value of 1 when it
+ processes an FBU whose source IP address is not PCoA.
+
+ If a Handover Acknowledge (HAck) message is not received as a
+ response in a short time period (no less than twice the typical RTT
+ between source and destination, or 100 milliseconds if RTT is not
+ known), the Handover Initiate SHOULD be resent. Subsequent
+ retransmissions can be up to HI_RETRIES, but MUST use exponential
+ backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds)
+ is doubled during each instance of retransmission.
+
+6.2.2. Handover Acknowledge (HAck)
+
+ The Handover Acknowledgment message is a new ICMPv6 message that MUST
+ be sent (typically by NAR to PAR) as a reply to the Handover Initiate
+ message.
+
+ 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 | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Subtype | Reserved | Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+-+-+-+-+-+-+-+-
+
+ Figure 7: Handover Acknowledge (HAck) Message
+
+ IP Fields:
+
+ Source Address
+ Copied from the destination address of the Handover
+ Initiate Message to which this message is a
+ response.
+
+ Destination Address
+ Copied from the source address of the Handover
+ Initiate Message to which this message is a
+ response.
+
+ Hop Limit 255. See RFC 2461 [6].
+
+ Authentication Header
+ The authentication header MUST be used when this
+ message is sent. See RFC 2402 [5].
+
+
+
+
+Koodli, Ed. Experimental [Page 25]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ ICMP Fields:
+
+ Type The Experimental Mobility Protocol Type. See RFC
+ 4065 [4].
+
+ Code
+ 0: Handover Accepted, NCoA valid
+ 1: Handover Accepted, NCoA not valid
+ 2: Handover Accepted, NCoA in use
+ 3: Handover Accepted, NCoA assigned
+ (used in Assigned addressing)
+ 4: Handover Accepted, NCoA not assigned
+ (used in Assigned addressing)
+ 128: Handover Not Accepted, reason unspecified
+ 129: Administratively prohibited
+ 130: Insufficient resources
+
+ Checksum The ICMPv6 checksum.
+
+ Subtype 5
+
+ Reserved MUST be set to zero by the sender and ignored by
+ the receiver.
+
+ Identifier Copied from the corresponding field in the Handover
+ Initiate message to which this message is a
+ response.
+
+ Valid Options:
+
+ New Care of Address
+ If the S flag in the Handover Initiate message is
+ set, this option MUST be used to provide NCoA the
+ MN should use when connected to this router. This
+ option MAY be included, even when the `S' bit is
+ not set, e.g., Code 2 above.
+
+ Upon receiving an HI message, the NAR MUST respond with a Handover
+ Acknowledge message. If the `S' flag is set in the HI message, the
+ NAR SHOULD include the New Care of Address option and a Code 3.
+
+ The NAR MAY provide support for PCoA (instead of accepting or
+ assigning NCoA), establish a host route entry for PCoA, and set up a
+ tunnel to the PAR to forward MN's packets sent with PCoA as a source
+ IP address. This host route entry SHOULD be used to forward packets
+ once the NAR detects that the particular MN is attached to its link.
+
+
+
+
+
+Koodli, Ed. Experimental [Page 26]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ When responding to an HI message containing a Code value 1, the Code
+ values 1, 2, and 4 in the HAck message are not relevant.
+
+ Finally, the new access router can always refuse handover, in which
+ case it should indicate the reason in one of the available Code
+ values.
+
+6.3. New Mobility Header Messages
+
+ Mobile IPv6 uses a new IPv6 header type called Mobility Header [3].
+ The Fast Binding Update, Fast Binding Acknowledgment, and Fast
+ Neighbor Advertisement messages use the Mobility Header.
+
+6.3.1. Fast Binding Update (FBU)
+
+ The Fast Binding Update message is identical to the Mobile IPv6
+ Binding Update (BU) message. However, the processing rules are
+ slightly different.
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence # |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A|H|L|K| Reserved | Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . .
+ . Mobility options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 8: Fast Binding Update (FBU) Message
+
+ IP fields:
+
+ Source Address
+ The PCoA or NCoA
+
+ Destination Address
+ The IP address of the Previous Access Router
+
+ A flag MUST be set to one to request that PAR send a Fast
+ Binding Acknowledgment message.
+
+ H flag MUST be set to one. See RFC 3775 [3].
+
+ L flag See RFC 3775 [3].
+
+
+
+
+Koodli, Ed. Experimental [Page 27]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ K flag See RFC 3775 [3].
+
+ Reserved This field is unused. MUST be set zero.
+
+ Sequence Number
+ See RFC 3775 [3].
+
+ Lifetime See RFC 3775 [3].
+
+ Mobility Options
+ MUST contain an alternate CoA option set to the
+ NCoA when an FBU is sent from PAR's link.
+
+ The MN sends an FBU message any time after receiving a PrRtAdv
+ message. If the MN moves prior to receiving a PrRtAdv message, it
+ SHOULD send an FBU to the PAR after configuring NCoA on the NAR
+ according to Neighbor Discovery and IPv6 Address Configuration
+ protocols.
+
+ The source IP address is PCoA when the FBU is sent from PAR's link,
+ and the source IP address is NCoA when sent from NAR's link. When
+ the FBU is sent from NAR's link, it SHOULD be encapsulated within an
+ FNA.
+
+ The FBU MUST also include the Home Address Option, and the Home
+ Address is PCoA. An FBU message MUST be protected so that PAR is
+ able to determine that the FBU message is sent by a genuine MN.
+
+6.3.2. Fast Binding Acknowledgment (FBack)
+
+ The Fast Binding Acknowledgment message is sent by the PAR to
+ acknowledge receipt of a Fast Binding Update message in which the 'A'
+ bit is set. The Fast Binding Acknowledgment message SHOULD NOT be
+ sent to the MN before the PAR receives a HAck message from the NAR.
+ The Fast Binding Acknowledgment MAY also be sent to the MN on the old
+ link.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 28]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Status |K| Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence # | Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . .
+ . Mobility options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 9: Fast Binding Acknowledgment (FBack) Message
+
+ IP fields:
+
+ Source Address
+ The IP address of the Previous Access Router.
+
+ Destination Address
+ The NCoA
+
+ Status 8-bit unsigned integer indicating the disposition
+ of the Fast Binding Update. Values of the Status
+ field that are less than 128 indicate that the
+ Binding Update was accepted by the receiving node.
+ The following such Status values are currently
+ defined:
+
+ 0 Fast Binding Update accepted
+ 1 Fast Binding Update accepted but NCoA is
+ invalid. Use NCoA supplied in "alternate" CoA
+
+ Values of the Status field that are greater than or
+ equal to 128 indicate that the Binding Update was
+ rejected by the receiving node. The following such
+ Status values are currently defined:
+
+ 128 Reason unspecified
+ 129 Administratively prohibited
+ 130 Insufficient resources
+ 131 Incorrect interface identifier length
+
+ `K' flag See RFC 3775 [3].
+
+ Reserved An unused field. MUST be set to zero.
+
+
+
+
+
+Koodli, Ed. Experimental [Page 29]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ Sequence Number
+ Copied from the FBU message for use by the MN in
+ matching this acknowledgment with an outstanding
+ FBU.
+
+ Lifetime The granted lifetime in seconds for which the
+ sender of this message will retain a binding for
+ traffic redirection.
+
+ Mobility Options
+ MUST contain an "alternate" CoA if Status is 1.
+
+6.3.3. Fast Neighbor Advertisement (FNA)
+
+ A MN sends a Fast Neighbor Advertisement to announce itself to the
+ NAR. When the Mobility Header Type is FNA, the Payload Proto field
+ may be set to IPv6 to assist FBU encapsulation.
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . .
+ . Mobility Options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 10: Fast Neighbor Advertisement (FNA) Message
+
+ IP fields:
+
+ Source Address
+ NCoA
+
+ Destination Address
+ NAR's IP Address
+
+ Mobility Options
+ MUST contain the Mobility Header Link-Layer Address
+ of the MN in the MH-LLA option format. See Section
+ 6.4.4.
+
+ The MN sends a Fast Neighbor Advertisement to the NAR, as soon as it
+ regains connectivity on the new link. Arriving or buffered packets
+ can be immediately forwarded. If NAR is proxying NCoA, it creates a
+ neighbor cache entry in REACHABLE state. If there is no entry, it
+ creates one and sets it to REACHABLE. If there is an entry in the
+ INCOMPLETE state without a Link-Layer Address, it sets it to
+
+
+
+Koodli, Ed. Experimental [Page 30]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ REACHABLE. During the process of creating a neighbor cache entry,
+ NAR can also detect if NCoA is in use, thus avoiding address
+ collisions. Since the FBU is encapsulated within the FNA when sent
+ from NAR's link, NAR drops the FBU if it detects a collision.
+
+ The combination of NCoA (present in source IP address) and the Link-
+ Layer Address (present as a Mobility Option) SHOULD be used to
+ distinguish the MN from other nodes.
+
+6.4. New Options
+
+ All the options are of the form shown in Figure 11.
+
+ The Type values are defined from the Neighbor Discovery options
+ space. The Length field is in units of 8 octets, except for the
+ Mobility Header Link-Layer Address option, whose Length field is in
+ units of octets in accordance with Section 6.2 in [3]. Option-Code
+ provides additional information for each of the options (See
+ individual options below).
+
+ 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 | Option-Code | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ... ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 11: Option Format
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 31]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+6.4.1. IP Address Option
+
+ This option is sent in the Proxy Router Advertisement, the Handover
+ Initiate, and Handover Acknowledge messages.
+
+ 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 | Option-Code | Prefix Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + IPv6 Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 12: IPv6 Address Option
+
+ Type 17
+
+ Length The size of this option in 8 octets including the
+ Type, Option-Code, and Length fields.
+
+ Option-Code 1 Old Care-of Address
+ 2 New Care-of Address
+ 3 NAR's IP address
+
+ Prefix Length
+ The Length of the IPv6 Address Prefix.
+
+ Reserved MUST be set to zero by the sender and MUST be
+ ignored by the receiver.
+
+ IPv6 Address The IP address for the unit defined by the Type
+ field.
+
+
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 32]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+6.4.2. New Router Prefix Information Option
+
+ This option is sent in the PrRtAdv message to provide the prefix
+ information valid on the NAR.
+
+ 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 | Option-Code | Prefix Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Prefix +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 13: New Router Prefix Information Option
+
+ Type 18
+
+ Length The size of this option in 8 octets including the
+ Type, Option-Code, and Length fields.
+
+ Option-Code 0
+
+ Prefix Length
+ 8-bit unsigned integer. The number of leading bits
+ in the Prefix that are valid. The value ranges
+ from 0 to 128.
+
+ Reserved MUST be set to zero by the sender and MUST be
+ ignored by the receiver.
+
+ Prefix An IP address or a prefix of an IP address. The
+ Prefix Length field contains the number of valid
+ leading bits in the prefix. The bits in the prefix
+ after the prefix length are reserved and MUST be
+ initialized to zero by the sender and ignored by
+ the receiver.
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 33]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+6.4.3. Link-Layer Address (LLA) 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 | Option-Code | LLA...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 14: Link-Layer Address Option
+
+ Type 19
+
+ Length The size of this option in 8 octets including the
+ Type, Option-Code, and Length fields.
+
+ Option-Code
+ 0 wildcard requesting resolution for all nearby
+ access points
+ 1 Link-Layer Address of the New Access Point
+ 2 Link-Layer Address of the MN
+ 3 Link-Layer Address of the NAR (i.e., Proxied
+ Originator)
+ 4 Link-Layer Address of the source of the RtSolPr
+ or PrRtAdv message
+ 5 The access point identified by the LLA belongs
+ to the current interface of the router
+ 6 No prefix information available for the access
+ point identified by the LLA
+ 7 No fast handovers support available for the
+ access point identified by the LLA
+
+ LLA The variable length Link-Layer Address.
+
+ Depending on the size of the individual LLA option, appropriate
+ padding MUST be used to ensure that the entire option size is a
+ multiple of 8 octets.
+
+ The New Access Point Link-Layer Address contains the Link-Layer
+ Address of the access point for which handover is about to be
+ attempted. This is used in the Router Solicitation for the Proxy
+ Advertisement message.
+
+ The MN Link-Layer Address option contains the Link-Layer Address of
+ an MN. It is used in the Handover Initiate message.
+
+ The NAR (i.e., Proxied Originator) Link-Layer Address option contains
+ the Link-Layer Address of the Access Router to which the Proxy Router
+ Solicitation message refers.
+
+
+
+Koodli, Ed. Experimental [Page 34]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+6.4.4. Mobility Header Link-Layer Address (MH-LLA) Option
+
+ This option is identical to the LLA option, but is carried in the
+ Mobility Header messages (i.e., FNA). In the future, other Mobility
+ Header messages may also make use of this option. For instance,
+ including this option in FBU allows PAR to obtain the MN's LLA
+ readily. The format of the option when the LLA is 6 bytes is shown
+ in Figure 15. When the LLA size is different, the option MUST be
+ aligned appropriately. See Section 6.2 in [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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Option-Code | Pad0=0 | LLA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LLA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 15: Mobility Header Link-Layer Address Option
+
+ Type 7
+
+ Length The size of this option in octets not including the
+ Type, Length, and Option-Code fields.
+
+ Option-Code 2 Link-Layer Address of the MN
+
+ LLA The variable length Link-Layer Address.
+
+6.4.5. Neighbor Advertisement Acknowledgment (NAACK)
+
+ 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 | Option-Code | Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 16: Neighbor Advertisement Acknowledgment Option
+
+ Type 20
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 35]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ Length 8-bit unsigned integer. Length of the option, in 8
+ octets. The length is 1 when NCoA is not supplied.
+ The length is 3 when NCoA is supplied (immediately
+ following the Reserved field).
+
+ Option-Code 0
+
+ Status 8-bit unsigned integer indicating the disposition
+ of the Fast Neighbor Advertisement message. The
+ following Status values are currently defined:
+
+ 1 The New CoA is invalid.
+ 2 The New CoA is invalid; use the supplied CoA.
+ The New CoA MUST be present following the
+ Reserved field.
+ 128 Link Layer Address unrecognized.
+
+ Reserved MUST be set to zero by the sender and MUST be
+ ignored by the receiver.
+
+ The NAR responds to the FNA with the NAACK option to notify the MN to
+ use a different NCoA if there is address collision. If the NCoA is
+ invalid, the Router Advertisement MUST use the NCoA as the
+ destination address but use the L2 address present in the FNA. The
+ MN SHOULD use the NCoA if it is supplied with the NAACK option. If
+ the NAACK indicates that the Link-Layer Address is unrecognized, the
+ MN MUST NOT use the NCoA or PCoA and SHOULD start the process of
+ acquiring an NCoA at the NAR immediately.
+
+ New option types may be defined in the future.
+
+7. Configurable Parameters
+
+ Parameter Name Default Value Definition
+ ------------------- ---------------------- -------
+ RTSOLPR_RETRIES 3 Section 6.1.1
+ MAX_RTSOLPR_RATE 3 Section 6.1.1
+ FBU_RETRIES 3 Section 4
+ PROXY_ND_LIFETIME 1.5 seconds Section 6.2.2
+ HI_RETRIES 3 Section 6.2.1
+
+
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 36]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+8. Security Considerations
+
+ The following security vulnerabilities are identified, and suggested
+ solutions are mentioned.
+
+ 1. Insecure FBU: In this case, packets meant for one address could be
+ stolen, or redirected to some unsuspecting node. This concern is
+ the same as that in an MN and Home Agent relationship.
+
+ Hence, the PAR MUST ensure that the FBU packet arrived from a node
+ that legitimately owns the PCoA. The access router and its hosts
+ may use any available mechanism to establish a security
+ association that MUST be used to secure FBU. The current version
+ of this protocol does not specify how this security association is
+ established. However, future work may specify this security
+ association establishment.
+
+ If an access router can ensure that the source IP address in an
+ arriving packet could only have originated from the node whose
+ Link-Layer Address is in the router's neighbor cache, then a bogus
+ node cannot use a victim's IP address for malicious redirection of
+ traffic. Such an operation is recommended at least on neighbor
+ discovery messages including the RtSolPr message.
+
+ 2. Secure FBU, malicious or inadvertent redirection: In this case,
+ the FBU is secured, but the target of binding happens to be an
+ unsuspecting node due to inadvertent operation or malicious
+ intent. This vulnerability can lead to an MN with a genuine
+ security association with its access router redirecting traffic to
+ an incorrect address.
+
+ However, the target of malicious traffic redirection is limited to
+ an interface on an access router with which the PAR has a security
+ association. The PAR MUST verify that the NCoA to which PCoA is
+ being bound actually belongs to NAR's prefix. To do this, HI and
+ HAck message exchanges are to be used. When NAR accepts NCoA in
+ HI (with Code = 0), it proxies NCoA so that any arriving packets
+ are not sent on the link until the MN attaches and announces
+ itself through FNA. Therefore, any inadvertent or malicious
+ redirection to a host is avoided. It is still possible to jam
+ NAR's buffer with redirected traffic. However, since NAR's
+ handover state corresponding to NCoA has a finite (and short)
+ lifetime corresponding to a small multiple of anticipated handover
+ latency, the extent of this vulnerability is arguably small.
+
+ 3. Sending an FBU from NAR's link: A malicious node may send an FBU
+ from NAR's link providing an unsuspecting node's address as NCoA.
+ Since the FBU is encapsulated in the FNA, NAR should detect the
+
+
+
+Koodli, Ed. Experimental [Page 37]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ collision with an address in use when processing the FNA, and then
+ drop the FBU. When NAR is unable to detect address collisions,
+ there is a vulnerability that redirection can affect an
+ unsuspecting node.
+
+9. IANA Considerations
+
+ This document defines four new experimental ICMPv6 messages that use
+ the Experimental Mobility Protocol ICMPv6 format [4]. These four new
+ Subtype value assignments out of the Experimental Mobility Protocol
+ Subtype Registry [4] have been assigned as follows:
+
+ Subtype Description Reference
+ ------- ----------- ---------
+ 2 RtSolPr Section 6.1.1
+ 3 PrRtAdv Section 6.1.2
+ 4 HI Section 6.2.1
+ 5 HAck Section 6.2.2
+
+ This document defines four new Neighbor Discovery [6] options that
+ have received Type assignments from IANA.
+
+ Option-Type Description Reference
+ ----------- ----------- ---------
+ 17 IP Address Option Section 6.4.1
+ 18 New Router Prefix
+ Information Option Section 6.4.2
+ 19 Link-Layer Address
+ Option Section 6.4.3
+ 20 Neighbor Advertisement
+ Acknowledgment Option Section 6.4.5
+
+ This document defines three new Mobility Header messages that have
+ received type allocations from the Mobility Header Types registry at
+ http://www.iana.org/assignments/mobility-parameters:
+
+ 1. Fast Binding Update, described in Section 6.3.1
+
+ 2. Fast Binding Acknowledgment, described in Section 6.3.2, and
+
+ 3. Fast Neighbor Advertisement, described in Section 6.3.3.
+
+ This document defines a new Mobility Option which has received type
+ assignments from the Mobility Options Type registry at
+ http://www.iana.org/assignments/mobility-parameters:
+
+ 1. Mobility Header Link-Layer Address option, described in Section
+ 6.4.4.
+
+
+
+Koodli, Ed. Experimental [Page 38]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+10. Acknowledgments
+
+ The editor would like to thank all those who have provided feedback
+ on this specification, but can only mention a few here: Martin
+ Andre, Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Suvidh Mathur,
+ Koshiro Mitsuya, Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC
+ Peng, Domagoj Premec, and Jonathan Wood. The editor would like to
+ acknowledge a contribution from James Kempf to improve this
+ specification. The editor would also like to thank the [mipshop]
+ working group chair Gabriel Montenegro and the erstwhile [mobile ip]
+ working group chairs Basavaraj Patil and Phil Roberts for providing
+ much support for this work.
+
+11. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Conta, A. and S. Deering, "Internet Control Message Protocol
+ (ICMPv6) for the Internet Protocol Version 6 (IPv6)
+ Specification", RFC 2463, December 1998.
+
+ [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
+ IPv6", RFC 3775, June 2004.
+
+ [4] Kempf, J., "Instructions for Seamoby and Experimental Mobility
+ Protocol IANA Allocations", RFC 4065, July 2005.
+
+ [5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
+ November 1998.
+
+ [6] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
+ for IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+ [7] Thomson, S. and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+12. Contributors
+
+ This document originated in the fast handover design team effort.
+ The members of this design team in alphabetical order were: Gopal
+ Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham
+ Soliman, George Tsirtsis, and Alper Yegin.
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 39]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ The design team member's contact information:
+
+ Gopal Dommety
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+
+ Phone:+1 408 525 1404
+ EMail: gdommety@cisco.com
+
+
+ Karim El Malki
+ Ericsson Radio Systems AB
+ LM Ericssons Vag. 8
+ 126 25 Stockholm
+ SWEDEN
+
+ Phone: +46 8 7195803
+ Fax: +46 8 7190170
+ EMail: Karim.El-Malki@era.ericsson.se
+
+
+ Mohamed Khalil
+ Nortel Networks
+
+ EMail: mkhalil@nortelnetworks.com
+
+
+ Charles E. Perkins
+ Communications Systems Lab
+ Nokia Research Center
+ 313 Fairchild Drive
+ Mountain View, California 94043
+ USA
+
+ Phone: +1-650 625-2986
+ Fax: +1 650 625-2502
+ EMail: charliep@iprg.nokia.com
+
+
+ Hesham Soliman
+ Flarion Technologies
+
+ EMail: H.Soliman@flarion.com
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 40]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+ George Tsirtsis
+ Flarion Technologies
+
+ EMail: G.Tsirtsis@flarion.com
+
+
+ Alper E. Yegin
+ Samsung Advanced Institute of Technology
+ 75 West Plumeria Drive
+ San Jose, CA 95134
+ USA
+
+ Phone: +1 408 544 5656
+ EMail: alper.yegin@samsung.com
+
+Author's Address
+
+ Rajeev Koodli, Editor
+ Nokia Research Center
+ 313 Fairchild Drive
+ Mountain View, CA 94043 USA
+
+ Phone: +1 650 625 2359
+ Fax: +1 650 625 2502
+ EMail: Rajeev.Koodli@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 41]
+
+RFC 4068 Fast Handovers for Mobile IPv6 July 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Koodli, Ed. Experimental [Page 42]
+