tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6275

 
 
 

Mobility Support in IPv6

Part 7 of 8, p. 132 to 149
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 132 
11.7.  Processing Bindings

11.7.1.  Sending Binding Updates to the Home Agent

   In order to change its primary care-of address as described in
   Sections 11.5.1 and 11.5.3, a mobile node MUST register this care-of
   address with its home agent in order to make this its primary care-of
   address.

   Also, if the mobile node wants the services of the home agent beyond
   the current registration period, the mobile node should send a new
   Binding Update to it well before the expiration of this period, even
   if it is not changing its primary care-of address.  However, if the
   home agent returned a Binding Acknowledgement for the current
   registration with the Status field set to 1 (accepted but prefix
   discovery necessary), the mobile node should not try to register

Top      Up      ToC       Page 133 
   again before it has learned the validity of its home prefixes through
   mobile prefix discovery.  This is typically necessary every time this
   Status value is received, because information learned earlier may
   have changed.

   To register a care-of address or to extend the lifetime of an
   existing registration, the mobile node sends a packet to its home
   agent containing a Binding Update, with the packet constructed as
   follows:

   o  The Home Registration (H) bit MUST be set in the Binding Update.

   o  The Acknowledge (A) bit MUST be set in the Binding Update.

   o  The packet MUST contain a Home Address destination option, giving
      the mobile node's home address for the binding.

   o  The care-of address for the binding MUST be used as the Source
      Address in the packet's IPv6 header, unless an Alternate Care-of
      Address mobility option is included in the Binding Update.  This
      option MUST be included in all home registrations, as the ESP
      protocol will not be able to protect care-of addresses in the IPv6
      header.  (Mobile IPv6 implementations that know they are using
      IPsec AH to protect a particular message might avoid this option.
      For brevity the usage of AH is not discussed in this document.)

   o  If the mobile node's link-local address has the same interface
      identifier as the home address for which it is supplying a new
      care-of address, then the mobile node SHOULD set the Link-Local
      Address Compatibility (L) bit.

   o  If the home address was generated using RFC 4941 [21], then the
      link local address is unlikely to have a compatible interface
      identifier.  In this case, the mobile node MUST clear the Link-
      Local Address Compatibility (L) bit.

   o  If the IPsec security associations between the mobile node and the
      home agent have been established dynamically, and the mobile node
      has the capability to update its endpoint in the used key
      management protocol to the new care-of address every time it
      moves, the mobile node SHOULD set the Key Management Mobility
      Capability (K) bit in the Binding Update.  Otherwise, the mobile
      node MUST clear the bit.

   o  The value specified in the Lifetime field MUST be non-zero and
      SHOULD be less than or equal to the remaining valid lifetime of
      the home address and the care-of address specified for the
      binding.

Top      Up      ToC       Page 134 
      Mobile nodes that use dynamic home agent address discovery should
      be careful with long lifetimes.  If the mobile node loses the
      knowledge of its binding with a specific home agent, registering a
      new binding with another home agent may be impossible as the
      previous home agent is still defending the existing binding.
      Therefore, to ensure that mobile nodes using home agent address
      discovery do not lose information about their binding, they SHOULD
      de-register before losing this information, or use small
      lifetimes.

   The Acknowledge (A) bit in the Binding Update requests the home agent
   to return a Binding Acknowledgement in response to this Binding
   Update.  As described in Section 6.1.8, the mobile node SHOULD
   retransmit this Binding Update to its home agent until it receives a
   matching Binding Acknowledgement.  Once reaching a retransmission
   timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart
   the process of delivering the Binding Update, but trying instead the
   next home agent returned during dynamic home agent address discovery
   (see Section 11.4.1).  If there was only one home agent, the mobile
   node instead SHOULD continue to periodically retransmit the Binding
   Update at this rate until acknowledged (or until it begins attempting
   to register a different primary care-of address).  See Section 11.8
   for information about retransmitting Binding Updates.

   With the Binding Update, the mobile node requests the home agent to
   serve as the home agent for the given home address.  Until the
   lifetime of this registration expires, the home agent considers
   itself the home agent for this home address.

   Each Binding Update MUST be authenticated as coming from the right
   mobile node, as defined in Section 5.1.  The mobile node MUST use its
   home address -- either in the Home Address destination option or in
   the Source Address field of the IPv6 header -- in Binding Updates
   sent to the home agent.  This is necessary in order to allow the
   IPsec policies to be matched with the correct home address.

   When sending a Binding Update to its home agent, the mobile node MUST
   also create or update the corresponding Binding Update List entry, as
   specified in Section 11.7.2.

   The last Sequence Number value sent to the home agent in a Binding
   Update is stored by the mobile node.  If the sending mobile node has
   no knowledge of the correct Sequence Number value, it may start at
   any value.  If the home agent rejects the value, it sends back a
   Binding Acknowledgement with a status code 135, and the last accepted
   sequence number in the Sequence Number field of the Binding
   Acknowledgement.  The mobile node MUST store this information and use
   the next Sequence Number value for the next Binding Update it sends.

Top      Up      ToC       Page 135 
   If the mobile node has additional home addresses, then the mobile
   node SHOULD send an additional packet containing a Binding Update to
   its home agent to register the care-of address for each such other
   home address.

   The home agent will only perform DAD for the mobile node's home
   address when the mobile node has supplied a valid binding between its
   home address and a care-of address.  If some time elapses during
   which the mobile node has no binding at the home agent, it might be
   possible for another node to autoconfigure the mobile node's home
   address.  Therefore, the mobile node MUST treat the creation of a new
   binding with the home agent using an existing home address, the same
   as creation of a new home address.  In the unlikely event that the
   mobile node's home address is autoconfigured as the IPv6 address of
   another network node on the home network, the home agent will reply
   to the mobile node's subsequent Binding Update with a Binding
   Acknowledgement containing a Status of 134 (Duplicate Address
   Detection failed).  In this case, the mobile node MUST NOT attempt to
   re-use the same home address.  It SHOULD continue to register the
   care-of addresses for its other home addresses, if any.  Mechanisms
   outlined in "Mobile IPv6 Bootstrapping in Split Scenario" [22] allow
   mobile nodes to acquire new home addresses to replace the one for
   which Status 134 was received.

11.7.2.  Correspondent Registration

   When the mobile node is assured that its home address is valid, it
   can initiate a correspondent registration with the purpose of
   allowing the correspondent node to cache the mobile node's current
   care-of address.  This procedure consists of the return routability
   procedure followed by a registration.

   This section defines when the correspondent registration is to be
   initiated and the rules to follow while it is being performed.

   After the mobile node has sent a Binding Update to its home agent,
   registering a new primary care-of address (as described in
   Section 11.7.1), the mobile node SHOULD initiate a correspondent
   registration for each node that already appears in the mobile node's
   Binding Update List.  The initiated procedures can be used to either
   update or delete binding information in the correspondent node.

   For nodes that do not appear in the mobile node's Binding Update
   List, the mobile node MAY initiate a correspondent registration at
   any time after sending the Binding Update to its home agent.
   Considerations regarding when (and if) to initiate the procedure
   depend on the specific movement and traffic patterns of the mobile
   node and are outside the scope of this document.

Top      Up      ToC       Page 136 
   In addition, the mobile node MAY initiate the correspondent
   registration in response to receiving a packet that meets all of the
   following tests:

   o  The packet was tunneled using IPv6 encapsulation.

   o  The Destination Address in the tunnel (outer) IPv6 header is equal
      to any of the mobile node's care-of addresses.

   o  The Destination Address in the original (inner) IPv6 header is
      equal to one of the mobile node's home addresses.

   o  The Source Address in the tunnel (outer) IPv6 header differs from
      the Source Address in the original (inner) IPv6 header.

   o  The packet does not contain a Home Test, Home Test Init, Care-of
      Test, or Care-of Test Init message.

   If a mobile node has multiple home addresses, it becomes important to
   select the right home address to use in the correspondent
   registration.  The used home address MUST be the Destination Address
   of the original (inner) packet.

   The peer address used in the procedure MUST be determined as follows:

   o  If a Home Address destination option is present in the original
      (inner) packet, the address from this option is used.

   o  Otherwise, the Source Address in the original (inner) IPv6 header
      of the packet is used.

   Note that the validity of the original packet is checked before
   attempting to initiate a correspondent registration.  For instance,
   if a Home Address destination option appeared in the original packet,
   then rules in Section 9.3.1 are followed.

   A mobile node MAY also choose to keep its topological location
   private from certain correspondent nodes, and thus need not initiate
   the correspondent registration.

   Upon successfully completing the return routability procedure, and
   after receiving a successful Binding Acknowledgement from the home
   agent, a Binding Update MAY be sent to the correspondent node.

   In any Binding Update sent by a mobile node, the care-of address
   (either the Source Address in the packet's IPv6 header or the Care-of
   Address in the Alternate Care-of Address mobility option of the
   Binding Update) MUST be set to one of the care-of addresses currently

Top      Up      ToC       Page 137 
   in use by the mobile node or to the mobile node's home address.  A
   mobile node MAY set the care-of address differently for sending
   Binding Updates to different correspondent nodes.

   A mobile node MAY also send a Binding Update to such a correspondent
   node, instructing it to delete any existing binding for the mobile
   node from its Binding Cache, as described in Section 6.1.7.  Even in
   this case a successful completion of the return routability procedure
   is required first.

   If the care-of address is not set to the mobile node's home address,
   the Binding Update requests that the correspondent node create or
   update an entry for the mobile node in the correspondent node's
   Binding Cache.  This is done in order to record a care-of address for
   use in sending future packets to the mobile node.  In this case, the
   value specified in the Lifetime field sent in the Binding Update
   SHOULD be less than or equal to the remaining lifetime of the home
   registration and the care-of address specified for the binding.  The
   care-of address given in the Binding Update MAY differ from the
   mobile node's primary care-of address.

   If the Binding Update is sent to the correspondent node, requesting
   the deletion of any existing Binding Cache entry it has for the
   mobile node, the care-of address is set to the mobile node's home
   address and the Lifetime field set to zero.  In this case, generation
   of the binding management key depends exclusively on the home keygen
   token (Section 5.2.5).  The care-of nonce index SHOULD be set to zero
   in this case.  In keeping with the Binding Update creation rules
   below, the care-of address MUST be set to the home address if the
   mobile node is at home, or to the current care-of address if it is
   away from home.

   If the mobile node wants to ensure that its new care-of address has
   been entered into a correspondent node's Binding Cache, the mobile
   node needs to request an acknowledgement by setting the Acknowledge
   (A) bit in the Binding Update.

   A Binding Update is created as follows:

   o  The current care-of address of the mobile node MUST be sent either
      in the Source Address of the IPv6 header or in the Alternate
      Care-of Address mobility option.

   o  The Destination Address of the IPv6 header MUST contain the
      address of the correspondent node.

Top      Up      ToC       Page 138 
   o  The Mobility Header is constructed according to rules in Sections
      6.1.7 and 5.2.6, including the Binding Authorization Data
      (calculated as defined in Section 6.2.7) and possibly the Nonce
      Indices mobility options.

   o  The home address of the mobile node MUST be added to the packet in
      a Home Address destination option, unless the Source Address is
      the home address.

   Each Binding Update MUST have a Sequence Number greater than the
   Sequence Number value sent in the previous Binding Update to the same
   destination address (if any).  The sequence numbers are compared
   modulo 2**16, as described in Section 9.5.1.  There is no
   requirement, however, that the Sequence Number value strictly
   increase by 1 with each new Binding Update sent or received, as long
   as the value stays within the window.  The last Sequence Number value
   sent to a destination in a Binding Update is stored by the mobile
   node in its Binding Update List entry for that destination.  If the
   sending mobile node has no Binding Update List entry, the Sequence
   Number SHOULD start at a random value.  The mobile node MUST NOT use
   the same Sequence Number in two different Binding Updates to the same
   correspondent node, even if the Binding Updates provide different
   care-of addresses.

   The mobile node is responsible for the completion of the
   correspondent registration, as well as any retransmissions that may
   be needed (subject to the rate limitation defined in Section 11.8).

11.7.3.  Receiving Binding Acknowledgements

   Upon receiving a packet carrying a Binding Acknowledgement, a mobile
   node MUST validate the packet according to the following tests:

   o  The packet meets the authentication requirements for Binding
      Acknowledgements defined in Sections 6.1.8 and 5.  That is, if the
      Binding Update was sent to the home agent, the underlying IPsec
      protection is used.  If the Binding Update was sent to the
      correspondent node, the Binding Authorization Data mobility option
      MUST be present and have a valid value.

   o  The Binding Authorization Data mobility option, if present, MUST
      be the last option and MUST NOT have trailing padding.

   o  The Sequence Number field matches the Sequence Number sent by the
      mobile node to this destination address in an outstanding Binding
      Update, and the Status field is not 135.

Top      Up      ToC       Page 139 
   Any Binding Acknowledgement not satisfying all of these tests MUST be
   silently ignored.

   When a mobile node receives a packet carrying a valid Binding
   Acknowledgement, the mobile node MUST examine the Status field as
   follows:

   o  If the Status field indicates that the Binding Update was accepted
      (the Status field is less than 128), then the mobile node MUST
      update the corresponding entry in its Binding Update List to
      indicate that the Binding Update has been acknowledged; the mobile
      node MUST then stop retransmitting the Binding Update.  In
      addition, if the value specified in the Lifetime field in the
      Binding Acknowledgement is less than the Lifetime value sent in
      the Binding Update being acknowledged, the mobile node MUST
      subtract the difference between these two Lifetime values from the
      remaining lifetime for the binding as maintained in the
      corresponding Binding Update List entry (with a minimum value for
      the Binding Update List entry lifetime of 0).  That is, if the
      Lifetime value sent in the Binding Update was L_update, the
      Lifetime value received in the Binding Acknowledgement was L_ack,
      and the current remaining lifetime of the Binding Update List
      entry is L_remain, then the new value for the remaining lifetime
      of the Binding Update List entry should be

         max((L_remain - (L_update - L_ack)), 0)

      where max(X, Y) is the maximum of X and Y.  The effect of this
      step is to correctly manage the mobile node's view of the
      binding's remaining lifetime (as maintained in the corresponding
      Binding Update List entry) so that it correctly counts down from
      the Lifetime value given in the Binding Acknowledgement, but with
      the timer countdown beginning at the time that the Binding Update
      was sent.

      Mobile nodes SHOULD send a new Binding Update well before the
      expiration of this period in order to extend the lifetime.  This
      helps to avoid disruptions in communications that might otherwise
      be caused by network delays or clock drift.

   o  If the Binding Acknowledgement correctly passes authentication and
      the Status field value is 135 (Sequence Number out of window),
      then the mobile node MUST update its binding sequence number
      appropriately to match the sequence number given in the Binding
      Acknowledgement.  Otherwise, if the Status field value is 135 but
      the Binding Acknowledgement does not pass authentication, the
      message MUST be silently ignored.

Top      Up      ToC       Page 140 
   o  If the Status field value is 1 (accepted but prefix discovery
      necessary), the mobile node SHOULD send a Mobile Prefix
      Solicitation message to update its information about the available
      prefixes.

   o  If the Status field indicates that the Binding Update was rejected
      (the Status field is greater than or equal to 128), then the
      mobile node can take steps to correct the cause of the error and
      retransmit the Binding Update (with a new Sequence Number value),
      subject to the rate limiting restriction specified in
      Section 11.8.  If this is not done or it fails, then the mobile
      node SHOULD record in its Binding Update List that future Binding
      Updates SHOULD NOT be sent to this destination.

   The treatment of a Binding Refresh Advice mobility option within the
   Binding Acknowledgement depends on where the acknowledgement came
   from.  This option MUST be ignored if the acknowledgement came from a
   correspondent node.  If it came from the home agent, the mobile node
   uses the Refresh Interval field in the option as a suggestion that it
   SHOULD attempt to refresh its home registration at the indicated
   shorter interval.

   If the acknowledgement came from the home agent, the mobile node
   examines the value of the Key Management Mobility Capability (K) bit.
   If this bit is not set, the mobile node SHOULD discard key management
   protocol connections, if any, to the home agent.  The mobile node MAY
   also initiate a new key management connection.

   If this bit is set, the mobile node SHOULD move its own endpoint in
   the key management protocol connections to the home agent, if any.
   The mobile node's new endpoint should be the new care-of address.

11.7.4.  Receiving Binding Refresh Requests

   When a mobile node receives a packet containing a Binding Refresh
   Request message, if the mobile node has a Binding Update List entry
   for the source of the Binding Refresh Request, and the mobile node
   wants to retain its Binding Cache entry at the correspondent node,
   then the mobile node should start a return routability procedure.  If
   the mobile node wants to have its Binding Cache entry removed, it can
   either ignore the Binding Refresh Request and wait for the binding to
   time out, or at any time, it can delete its binding from a
   correspondent node with an explicit Binding Update with a zero
   lifetime and the care-of address set to the home address.  If the
   mobile node does not know if it needs the Binding Cache entry, it can
   make the decision in an implementation-dependent manner, such as
   based on available resources.

Top      Up      ToC       Page 141 
   Note that the mobile node should be careful not to respond to Binding
   Refresh Requests for addresses not in the Binding Update List to
   avoid being subjected to a denial of service attack.

   If the return routability procedure completes successfully, a Binding
   Update message SHOULD be sent, as described in Section 11.7.2.  The
   Lifetime field in this Binding Update SHOULD be set to a new
   lifetime, extending any current lifetime remaining from a previous
   Binding Update sent to this node (as indicated in any existing
   Binding Update List entry for this node), and the lifetime SHOULD
   again be less than or equal to the remaining lifetime of the home
   registration and the care-of address specified for the binding.  When
   sending this Binding Update, the mobile node MUST update its Binding
   Update List in the same way as for any other Binding Update sent by
   the mobile node.

11.8.  Retransmissions and Rate Limiting

   The mobile node is responsible for retransmissions and rate limiting
   in the return routability procedure, in registrations, and in
   solicited prefix discovery.

   When the mobile node sends a Mobile Prefix Solicitation, Home Test
   Init, Care-of Test Init, or Binding Update for which it expects a
   response, the mobile node has to determine a value for the initial
   retransmission timer:

   o  If the mobile node is sending a Mobile Prefix Solicitation, it
      SHOULD use an initial retransmission interval of
      INITIAL_SOLICIT_TIMER (see Section 12).

   o  If the mobile node is sending a Binding Update and does not have
      an existing binding at the home agent, it SHOULD use
      InitialBindackTimeoutFirstReg (see Section 13) as a value for the
      initial retransmission timer.  This long retransmission interval
      will allow the home agent to complete the Duplicate Address
      Detection procedure mandated in this case, as detailed in
      Section 11.7.1.

   o  Otherwise, the mobile node should use the specified value of
      INITIAL_BINDACK_TIMEOUT for the initial retransmission timer.

   If the mobile node fails to receive a valid matching response within
   the selected initial retransmission interval, the mobile node SHOULD
   retransmit the message until a response is received.

Top      Up      ToC       Page 142 
   The retransmissions by the mobile node MUST use an exponential back-
   off process in which the timeout period is doubled upon each
   retransmission, until either the node receives a response or the
   timeout period reaches the value MAX_BINDACK_TIMEOUT.  The mobile
   node MAY continue to send these messages at this slower rate
   indefinitely.

   The mobile node SHOULD start a separate back-off process for
   different message types, different home addresses, and different
   care-of addresses.  However, in addition an overall rate limitation
   applies for messages sent to a particular correspondent node.  This
   ensures that the correspondent node has a sufficient amount of time
   to respond when bindings for multiple home addresses are registered,
   for instance.  The mobile node MUST NOT send Mobility Header messages
   of a particular type to a particular correspondent node more than
   MAX_UPDATE_RATE times within a second.

   Retransmitted Binding Updates MUST use a Sequence Number value
   greater than that used for the previous transmission of this Binding
   Update.  Retransmitted Home Test Init and Care-of Test Init messages
   MUST use new cookie values.

12.  Protocol Constants

           DHAAD_RETRIES                   4 retransmissions
           INITIAL_BINDACK_TIMEOUT         1 second
           INITIAL_DHAAD_TIMEOUT           3 seconds
           INITIAL_SOLICIT_TIMER           3 seconds
           MAX_BINDACK_TIMEOUT             32 seconds
           MAX_DELETE_BCE_TIMEOUT          10 seconds
           MAX_NONCE_LIFETIME              240 seconds
           MAX_TOKEN_LIFETIME              210 seconds
           MAX_RO_FAILURE                  3 retries
           MAX_RR_BINDING_LIFETIME         420 seconds
           MAX_UPDATE_RATE                 3 times
           PREFIX_ADV_RETRIES              3 retransmissions
           PREFIX_ADV_TIMEOUT              3 seconds

13.  Protocol Configuration Variables

           MaxMobPfxAdvInterval            Default: 86,400 seconds
           MinDelayBetweenRAs              Default: 3 seconds,
                                           Min: 0.03 seconds
           MinMobPfxAdvInterval            Default: 600 seconds
           InitialBindackTimeoutFirstReg   Default: 1.5 seconds

Top      Up      ToC       Page 143 
   Home agents MUST allow the first three variables to be configured by
   system management, and mobile nodes MUST allow the last variable to
   be configured by system management.

   The default value for InitialBindackTimeoutFirstReg has been
   calculated as 1.5 times the default value of RetransTimer, as
   specified in Neighbor Discovery (RFC 4861 [18]) times the default
   value of DupAddrDetectTransmits, as specified in Stateless Address
   Autoconfiguration (RFC 4862 [19]).

   The value MinDelayBetweenRAs overrides the value of the protocol
   constant MIN_DELAY_BETWEEN_RAS, as specified in Neighbor Discovery
   (RFC 4861 [18]).  This variable SHOULD be set to MinRtrAdvInterval,
   if MinRtrAdvInterval is less than 3 seconds.

14.  IANA Considerations

   This document defines a new IPv6 protocol, the Mobility Header,
   described in Section 6.1.  This protocol has been assigned protocol
   number 135.

   This document also creates a new name space "Mobility Header Type",
   for the MH Type field in the Mobility Header.  The current message
   types are described starting from Section 6.1.2, and are the
   following:

      0  Binding Refresh Request

      1  Home Test Init

      2  Care-of Test Init

      3  Home Test

      4  Care-of Test

      5  Binding Update

      6  Binding Acknowledgement

      7  Binding Error

   Future values of the MH Type can be allocated using Standards Action
   or IESG Approval [23].

Top      Up      ToC       Page 144 
   Furthermore, each mobility message may contain mobility options as
   described in Section 6.2.  This document defines a new name space
   "Mobility Option" to identify these options.  The current mobility
   options are defined starting from Section 6.2.2 and are the
   following:

      0  Pad1

      1  PadN

      2  Binding Refresh Advice

      3  Alternate Care-of Address

      4  Nonce Indices

      5  Authorization Data

   Future values of the Option Type can be allocated using Standards
   Action or IESG Approval [23].

   Finally, this document creates a third new name space "Status Code"
   for the Status field in the Binding Acknowledgement message.  The
   current values are listed in Section 6.1.8 and are the following:

   0  Binding Update accepted

   1  Accepted but prefix discovery necessary

   128  Reason unspecified

   129  Administratively prohibited

   130  Insufficient resources

   131  Home registration not supported

   132  Not home subnet

   133  Not home agent for this mobile node

   134  Duplicate Address Detection failed

   135  Sequence number out of window

   136  Expired home nonce index

   137  Expired care-of nonce index

Top      Up      ToC       Page 145 
   138  Expired nonces

   139  Registration type change disallowed

   174  Invalid Care-of Address

   Future values of the Status field can be allocated using Standards
   Action or IESG Approval [23].

   All fields labeled "Reserved" are only to be assigned through
   Standards Action or IESG Approval.

   This document also defines a new IPv6 destination option, the Home
   Address option, described in Section 6.3.  This option has been
   assigned the Option Type value 0xC9.

   This document also defines a new IPv6 type 2 routing header,
   described in Section 6.4.  The value 2 has been allocated by IANA.

   In addition, this document defines four ICMP message types, two used
   as part of the dynamic home agent address discovery mechanism, and
   two used in lieu of Router Solicitations and Advertisements when the
   mobile node is away from the home link.  These messages have been
   assigned ICMPv6 type numbers from the informational message range:

   o  The Home Agent Address Discovery Request message, described in
      Section 6.5;

   o  The Home Agent Address Discovery Reply message, described in
      Section 6.6;

   o  The Mobile Prefix Solicitation, described in Section 6.7; and

   o  The Mobile Prefix Advertisement, described in Section 6.8.

   This document also defines two new Neighbor Discovery [18] options,
   which have been assigned Option Type values within the option
   numbering space for Neighbor Discovery messages:

   o  The Advertisement Interval option, described in Section 7.3; and

   o  The Home Agent Information option, described in Section 7.4.

Top      Up      ToC       Page 146 
15.  Security Considerations

15.1.  Threats

   Any mobility solution must protect itself against misuses of the
   mobility features and mechanisms.  In Mobile IPv6, most of the
   potential threats are concerned with false bindings, usually
   resulting in denial-of-service attacks.  Some of the threats also
   pose potential for man-in-the-middle, hijacking, confidentiality, and
   impersonation attacks.  The main threats this protocol protects
   against are the following:

   o  Threats involving Binding Updates sent to home agents and
      correspondent nodes.  For instance, an attacker might claim that a
      certain mobile node is currently at a different location than it
      really is.  If a home agent accepts such spoofed information sent
      to it, the mobile node might not get traffic destined to it.
      Similarly, a malicious (mobile) node might use the home address of
      a victim node in a forged Binding Update sent to a correspondent
      node.

      These pose threats against confidentiality, integrity, and
      availability.  That is, an attacker might learn the contents of
      packets destined to another node by redirecting the traffic to
      itself.  Furthermore, an attacker might use the redirected packets
      in an attempt to set itself as a man in the middle between a
      mobile and a correspondent node.  This would allow the attacker to
      impersonate the mobile node, leading to integrity and availability
      problems.

      A malicious (mobile) node might also send Binding Updates in which
      the care-of address is set to the address of a victim node.  If
      such Binding Updates were accepted, the malicious node could lure
      the correspondent node into sending potentially large amounts of
      data to the victim; the correspondent node's replies to messages
      sent by the malicious mobile node will be sent to the victim host
      or network.  This could be used to cause a distributed denial-of-
      service attack.  For example, the correspondent node might be a
      site that will send a high-bandwidth stream of video to anyone who
      asks for it.  Note that the use of flow-control protocols such as
      TCP does not necessarily defend against this type of attack,
      because the attacker can fake the acknowledgements.  Even keeping
      TCP initial sequence numbers secret does not help, because the
      attacker can receive the first few segments (including the ISN) at
      its own address, and only then redirect the stream to the victim's
      address.  These types of attacks may also be directed to networks
      instead of nodes.  Further variations of this threat are described
      elsewhere [28] [35].

Top      Up      ToC       Page 147 
      An attacker might also attempt to disrupt a mobile node's
      communications by replaying a Binding Update that the node had
      sent earlier.  If the old Binding Update was accepted, packets
      destined for the mobile node would be sent to its old location as
      opposed to its current location.

      A malicious mobile node associated to multiple home agents could
      create a routing loop amongst them.  This can be achieved when a
      mobile node binds one home address located on a first home agent
      to another home address on a second home agent.  This type of
      binding will force the home agents to route the same packet among
      each other without knowledge that a routing loop has been created.
      Such looping problem is limited to cases where a mobile node has
      multiple home agents and is permitted to be associated with the
      multiple home agents.  For the single home agent case, a policy at
      the home agent would prevent the binding of one home address to
      another home address hosted by the same home agent.

      The potential problems caused by such routing loops in this
      scenario can be substantially reduced by use of the Tunnel-Limit
      Option specified in RFC 2473 [7].

      In conclusion, there are denial-of-service, man-in-the-middle,
      confidentiality, and impersonation threats against the parties
      involved in sending legitimate Binding Updates, the threat of
      routing loops when there are multiple home agents, and denial-of-
      service threats against any other party.

   o  Threats associated with payload packets: Payload packets exchanged
      with mobile nodes are exposed to similar threats as that of
      regular IPv6 traffic.  However, Mobile IPv6 introduces the Home
      Address destination option and a new routing header type (type 2),
      and uses tunneling headers in the payload packets.  The protocol
      must protect against potential new threats involving the use of
      these mechanisms.

      Third parties become exposed to a reflection threat via the Home
      Address destination option, unless appropriate security
      precautions are followed.  The Home Address destination option
      could be used to direct response traffic toward a node whose IP
      address appears in the option.  In this case, ingress filtering
      would not catch the forged "return address" [38] [43].

      A similar threat exists with the tunnels between the mobile node
      and the home agent.  An attacker might forge tunnel packets
      between the mobile node and the home agent, making it appear that
      the traffic is coming from the mobile node when it is not.  Note
      that an attacker who is able to forge tunnel packets would

Top      Up      ToC       Page 148 
      typically also be able to forge packets that appear to come
      directly from the mobile node.  This is not a new threat as such.
      However, it may make it easier for attackers to escape detection
      by avoiding ingress filtering and packet tracing mechanisms.
      Furthermore, spoofed tunnel packets might be used to gain access
      to the home network.

      Finally, a routing header could also be used in reflection
      attacks, and in attacks designed to bypass firewalls.  The
      generality of the regular routing header would allow circumvention
      of IP-address based rules in firewalls.  It would also allow
      reflection of traffic to other nodes.  These threats exist with
      routing headers in general, even if the usage that Mobile IPv6
      requires is safe.

   o  Threats associated with dynamic home agent and mobile prefix
      discovery.

   o  Threats against the Mobile IPv6 security mechanisms themselves: An
      attacker might, for instance, lure the participants into executing
      expensive cryptographic operations or allocating memory for the
      purpose of keeping state.  The victim node would have no resources
      left to handle other tasks.

   As a fundamental service in an IPv6 stack, Mobile IPv6 is expected to
   be deployed in most nodes of the IPv6 Internet.  The above threats
   should therefore be considered as being applicable to the whole
   Internet.

   It should also be noted that some additional threats result from
   movements as such, even without the involvement of mobility
   protocols.  Mobile nodes must be capable to defend themselves in the
   networks that they visit, as typical perimeter defenses applied in
   the home network no longer protect them.

15.2.  Features

   This specification provides a series of features designed to mitigate
   the risk introduced by the threats listed above.  The main security
   features are the following:

   o  Reverse tunneling as a mandatory feature.

   o  Protection of Binding Updates sent to home agents.

   o  Protection of Binding Updates sent to correspondent nodes.

Top      Up      ToC       Page 149 
   o  Protection against reflection attacks that use the Home Address
      destination option.

   o  Protection of tunnels between the mobile node and the home agent.

   o  Closing routing header vulnerabilities.

   o  Mitigating denial-of-service threats to the Mobile IPv6 security
      mechanisms themselves.

   The support for encrypted reverse tunneling (see Section 11.3.1)
   allows mobile nodes to defeat certain kinds of traffic analysis.

   Protecting those Binding Updates that are sent to home agents and
   those that are sent to arbitrary correspondent nodes requires very
   different security solutions due to the different situations.  Mobile
   nodes and home agents are naturally expected to be subject to the
   network administration of the home domain.

   Thus, they can and are supposed to have a security association that
   can be used to reliably authenticate the exchanged messages.  See
   Section 5.1 for the description of the protocol mechanisms, and
   Section 15.3 below for a discussion of the resulting level of
   security.

   It is expected that Mobile IPv6 route optimization will be used on a
   global basis between nodes belonging to different administrative
   domains.  It would be a very demanding task to build an
   authentication infrastructure on this scale.  Furthermore, a
   traditional authentication infrastructure cannot be easily used to
   authenticate IP addresses because IP addresses can change often.  It
   is not sufficient to just authenticate the mobile nodes;
   authorization to claim the right to use an address is needed as well.
   Thus, an "infrastructureless" approach is necessary.  The chosen
   infrastructureless method is described in Section 5.2, and
   Section 15.4 discusses the resulting security level and the design
   rationale of this approach.

   Specific rules guide the use of the Home Address destination option,
   the routing header, and the tunneling headers in the payload packets.
   These rules are necessary to remove the vulnerabilities associated
   with their unrestricted use.  The effect of the rules is discussed in
   Sections 15.7, 15.8, and 15.9.

   Denial-of-service threats against Mobile IPv6 security mechanisms
   themselves concern mainly the Binding Update procedures with
   correspondent nodes.  The protocol has been designed to limit the
   effects of such attacks, as will be described in Section 15.4.5.


Next RFC Part