tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5726

 
 
 

Mobile IPv6 Location Privacy Solutions

Part 2 of 3, p. 20 to 37
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 20 
6.  IP Address Location Privacy Solution Using the Pseudo Home Address

6.1.  Home Binding Update

   When the mobile node attaches to a foreign link, it first performs
   the home binding update procedure for the real home address with the
   home agent, as specified in RFC 3775.  For hiding the real home
   address, we require the use of IPsec Encapsulating Security Payload
   (ESP) [3] in tunnel mode.  In order to provide location privacy, a
   non-null encryption transform must be used so that the real home
   address is encrypted and encapsulated, and made invisible to
   eavesdroppers on the MN-HA path.  The packet formats and processing
   rules are the same as specified in RFC 3775 and RFC 4877.

6.1.1.  Pseudo Home Address Registration

6.1.1.1.  Generation

   To protect location privacy in the route optimization mode, the
   mobile node replaces the real home address used in certain signaling
   and payload packets with the pseudo home address.  Different from the
   encrypted home address, the pseudo home address needs to be routable
   so that the home agent can intercept packets with the pseudo home
   address used as the destination address.  The pseudo home address is
   generated by concatenating one of the home network prefixes with a
   random bit string.  There are many ways to generate such a random bit
   string, for example, by using a random number generator or a secure
   encryption or hash algorithm.

   Using the pseudo home address instead of the real home address even
   in return routability and binding update to the correspondent has the
   following advantages.  First, the pseudo home address does not reveal
   the identity of a mobile node since it is not (or should not be)
   publicly known.  Hence, the signaling on the HA-CN is path is more
   secure since attackers will not be able to determine the identity of
   the mobile node based on the pseudo home address.  Second, the mobile

Top      Up      ToC       Page 21 
   node can communicate with a correspondent without disclosing its real
   home address.  Finally, the chosen pseudo home address can be
   different with different correspondents for both signaling and data
   traffic purposes.

   The prefix used to form the pseudo home address MUST be managed by
   the same home agent so that it can forward the return routability
   messages.  Even though it does not have to be the same as that used
   in the real home address, the prefix is highly recommended to be
   different.  For instance, a home agent may use a different prefix
   pool for location privacy purposes for a set of mobile nodes.  This
   ensures that the real home address and the pseudo home address are
   not co-related (assuming the mobile node chooses different interface
   identifiers (IIDs)).

6.1.1.2.  Registration

   The mobile node MUST register the pseudo home address to be used with
   the home agent before actually using it with a correspondent node.
   To do so, the mobile node indicates a pseudo home address in the
   Pseudo Home Address mobility option in the Binding Update message
   sent to the home agent.  If the home agent supports the location
   privacy solution, it performs the Duplicate Address Detection to
   detect whether this pseudo home address conflicts with other pseudo
   home addresses submitted from different mobile nodes.  Based on the
   result, the home agent indicates whether to accept the pseudo home
   address by setting the appropriate status code in the Pseudo Home
   Address Acknowledgement option in the Binding Acknowledgement
   message.  If the home agent prefers the use of a different home
   network prefix from that of the requested pseudo home address, the
   home agent returns the new pseudo home address in the Pseudo Home
   Address Acknowledgement mobility option to the mobile node.

   The mobile node MAY register the pseudo home address when it is about
   to communicate with a correspondent node with location privacy
   protection.  The default lifetime of registered pseudo home addresses
   is the same as the Home Binding Cache entry; however, a mobile node
   may choose any value and a home agent may grant any value.  The
   mobile node can add or delete any pseudo home address by using the
   Pseudo Home Address mobility option in the home Binding Update
   message.  The home agent does not have to recover the real home
   address from the pseudo home address.

6.1.2.  Home De-Registration

   When the mobile node returns to its home link, the home de-
   registration procedure is the same as specified in RFC 3775, i.e.,
   the real home address is used as the source IP address in the Binding

Top      Up      ToC       Page 22 
   Update message and the destination IP address in the Binding
   Acknowledgement message.  The de-registration of the real home
   address results in automatic de-registration of all pseudo home
   addresses.  When the mobile node decides to disconnect from the home
   agent while at its foreign link, the format of the Binding Update and
   Acknowledgement is the same as that defined for the home
   registration, except that the Lifetime field is set to zero.  The
   home agent deletes the corresponding Binding Cache entry including
   the registered pseudo home address, if any.

6.2.  Correspondent Binding Update Using the Pseudo Home Address

6.2.1.  Return Routability Procedure

   The location privacy solution specified in this section does not
   introduce any change to the care-of address test procedure as
   specified in RFC 3775.  In the following, we highlight the extensions
   to the home address test procedure, during which the mobile node
   obtains a home keygen token generated based on the pseudo home
   address.

   The mobile node generates and sends a Home Test Init message to the
   home agent.  The format of this message is:

       IPv6 header (source = care-of address, destination = home agent)
       ESP header in tunnel mode
       IPv6 header (source = home address, destination = correspondent)
       Mobility Header (HoTI)
           Home Init Cookie
           Pseudo Home Address mobility option (pseudo home address)

   The difference from what is specified in RFC 3775 is that the mobile
   node includes a Pseudo Home Address mobility option (see Section 7.3)
   in the Home Test Init message.  A new option for carrying the pseudo
   home address is necessary because the security association between
   the mobile node and the home agent is based on the real home address.
   The pseudo home address contained in the Pseudo Home Address option
   is selected by the mobile node from a set of pseudo home addresses
   that have been registered with the home agent during the home
   registration procedure.  Note that the Home Test Init message is
   protected by an IPsec security association in the ESP tunnel mode
   with a non-null encryption algorithm and a non-null authentication
   algorithm, as specified in RFC 3776.

   When receiving a Home Test Init message, the home agent performs the
   operation as specified in Section 6.6.4.  If this operation succeeds
   when the Pseudo Home Address mobility option is present in the Home
   Test Init message, the home agent generates a Home Test Init message

Top      Up      ToC       Page 23 
   and forwards it to the correspondent node.  As shown in the
   following, the pseudo home address carried in the Pseudo Home Address
   mobility option is used as the source IP address in the forwarded
   Home Test Init message.

       IPv6 header (source = pseudo home address,
                    destination = correspondent)
       Mobility Header (HoTI)
           Home Init Cookie

   The forwarded Home Test Init message looks the same to the
   correspondent node as what is specified in RFC 3775 and the
   correspondent node does not realize that the pseudo home address is
   used, and just generates a home keygen token using the same algorithm
   as specified in RFC 3775.

      home keygen token =
          First (64, HMAC_SHA1 (Kcn, (pseudo home address | nonce | 0)))

   The correspondent node then replies with a Home Test message.  As
   shown in the following, the format of this message is the same as
   that specified in RFC 3776, and the pseudo home address is used as
   the destination IP address.

       IPv6 header (source = correspondent,
                    destination = pseudo home address)
       Mobility Header (HoT)
           Home Init Cookie
           Home Keygen Token
           Home Nonce Index

   When the home agent intercepts the Home Test message using proxy
   Neighbor Discovery, it performs the operation as specified in
   Section 6.6.5.  If this operation succeeds, the home agent generates
   the following Home Test message and forwards to the mobile node.

       IPv6 header (source = home agent, destination = care-of address)
       ESP header in tunnel mode
       IPv6 header (source = correspondent, destination = home address)
       Mobility Header (HoT)
           Home Init Cookie
           Home Keygen Token
           Home Nonce Index
           Pseudo Home Address Acknowledgement mobility option
              (pseudo home address)

Top      Up      ToC       Page 24 
   When the mobile node receives the Home Test message, it performs
   operation as specified in Section 6.5.5.  If such operation succeeds,
   the mobile node obtains a home keygen token computed using the pseudo
   home address.  After the care-of address test is completed, the
   mobile node hashes the care-of keygen token and the home keygen token
   together to generate Kbm using the same method as specified in RFC
   3775.

6.2.2.  Route-Optimized Correspondent Binding Update

   In this procedure, the mobile node MUST use the same pseudo home
   address used during the home address test procedure.  The pseudo home
   address is carried in the Home Address option in the correspondent
   Binding Update message.

       IPv6 header (source = care-of address,
                    destination = correspondent)
       Destination option header
           Home Address destination option (pseudo home address)
       Parameters:
           sequence number (within the Binding Update message header)
           home nonce index (within the Nonce Indices option)
           care-of nonce index (within the Nonce Indices option)
           First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
           | BU)))

   When the correspondent node receives the Binding Update message, it
   performs the same operation as specified in RFC 3775.  If such
   operation succeeds and an acknowledgement is requested by the mobile
   node, the correspondent node replies with the following Binding
   Acknowledgement message.

       IPv6 header (source = correspondent,
                    destination = care-of address)
       Parameters:
           sequence number (within the Binding Update message header)
           First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
           | BA)))

   After the mobile node receives the Binding Acknowledgement message
   indicating that the correspondent registration succeeds, the mobile
   node can now use the pseudo home address for communicating with the
   correspondent node.

Top      Up      ToC       Page 25 
   Such a Binding Update message may also be used by the mobile node to
   delete a previously established binding at the correspondent node.
   In this case, similar to what is specified in RFC 3775, Kbm is
   generated exclusively from the home keygen token that is based on the
   pseudo home address.

6.2.3.  Reverse-tunneled Correspondent Binding Update

   The mobile node may choose to use reverse tunneling for sending the
   Binding Update.  The format of messages during such a procedure is
   similar to what is described in Sections 5 and 6.2.1, except that a
   pseudo home address is used in place of the real home address.  The
   Encrypted Home Address destination and the Encrypted Home Address
   routing header SHOULD be used to carry the encrypted pseudo home
   address.

6.2.4.  Using Different Pseudo Home Addresses with Different
        Correspondent Nodes

   Based on its configuration and policy, the mobile node can choose to
   use the same or different pseudo home addresses when communicating
   with different correspondent nodes.  Using a different pseudo home
   address with each correspondent node may help prevent the mobile
   node's activities from being linked and correlated.  To do so, the
   mobile node selects a different but already registered pseudo home
   address and repeats the return routability procedure and the
   correspondent binding update procedure with each correspondent node.

   In addition, if the mobile node prefers, it MAY use different pseudo
   home addresses for different sessions with the same correspondent
   node.  This typically requires additional configuration at the mobile
   node that associates a specific session (for example, identified by
   the port number and the protocol number, among others) with a
   specific pseudo home address.  This document does not address details
   of this solution.

6.3.  Payload Packets

6.3.1.  Reverse Tunneling Mode

   The format of payload packets reverse-tunneled via the home agent is
   the same as that specified for the home address test procedure in
   Section 6.2.1.

Top      Up      ToC       Page 26 
6.3.2.  Route Optimization Mode

   When the route-optimized correspondent binding update procedure is
   performed, the format of payload packets exchanged between the mobile
   node and the correspondent node is the same as specified in RFC 3775.
   The operation of the mobile node when communicating with the
   correspondent node via the route optimization mode is described in
   Section 6.5.6.

   When the reverse tunneled correspondent binding update procedure is
   performed, the format of payload packets exchanged between the mobile
   node and the correspondent node is the same as specified in Section
   5, except that the encrypted pseudo home address SHOULD be included
   in the Encrypted Home Address destination option and the Encrypted
   Home Address routing header.

6.4.  Prefix Discovery

   The solution to protect location privacy during the prefix discovery
   procedure is similar to that used during the home binding update
   procedure.

6.5.  Mobile Node Operation

   In this section, we describe the mobile node's operation when the
   location privacy solution is used.

6.5.1.  Conceptual Data Structures

6.5.1.1.  Pseudo Home Address Table

   We introduce a new data structure, called Pseudo Home Address table,
   to record the information of pseudo home addresses.  The mobile node
   may maintain a Pseudo Home Address table for each home agent it
   registers with.  Each entry in the table contains a pseudo home
   address and its associated state, i.e., "unconfirmed" or "confirmed".
   The mobile node creates or updates entries in the Pseudo Home Address
   table when sending the home Binding Update message or receiving the
   home Binding Acknowledgement message.  The pseudo home address can be
   used as a key to search the table.  There MUST NOT be any duplicated
   pseudo home addresses stored in the Pseudo Home Address table.

6.5.1.2.  Binding Update List

   The Binding Update List entry is extended with a field, called Pseudo
   Home Address.  This field MAY be implemented as a pointer that points
   to a corresponding entry in the Pseudo Home Address table.  This
   pointer is initialized as NULL when the Binding Update List entry is

Top      Up      ToC       Page 27 
   created (for example, when the mobile node sends a Binding Update
   message or a Home Test Init message to the home agent).  For the
   binding sent to a specific home agent, the Pseudo Home Address field
   points to the first entry in the Pseudo Home Address table (or NULL
   if the table is empty), so that the mobile node can access all the
   pseudo home addresses registered at this home agent; on the other
   hand, for the binding sent to a specific correspondent node, the
   Pseudo Home Address field points to the Pseudo Home Address table
   entry that contains the actual pseudo home address used with this
   correspondent node (or NULL if no pseudo home address is used with
   this correspondent node).

6.5.2.  Binding Update to the Home Agent

   The mobile node may decide to perform the home registration with
   location privacy protection, for example, when it attaches to a
   foreign link or when it needs to extend the lifetime of a registered
   home binding.

   Since IPsec tunnel mode is used, the mobile node MUST negotiate a
   non-null encryption algorithm (for example, during the bootstrapping)
   and use it to protect the home Binding Update message as specified in
   RFC 3775 and RFC 4877.  In addition, the mobile node can register a
   pseudo home address as described above.  If the mobile node does not
   wish to register the pseudo home address at this point, but wishes to
   discover whether the home agent supports the location privacy
   solution, the mobile node includes a Pseudo Home Address mobility
   option without the Pseudo Home Address field in the Binding Update
   message sent to the home agent.

   After sending the home de-registration binding update message, in
   addition to the operation specified in RFC 3775, the mobile node MUST
   stop using any data structure specific to the location privacy
   solution and MAY delete them after the Binding Acknowledgement
   message is processed successfully.

6.5.3.  Binding Acknowledgement from the Home Agent

   With IPsec tunnel mode, the mobile node follows the rules specified
   in RFC 3775 and RFC 4877 to process the Binding Acknowledgement
   message.

   In addition, if one or more Pseudo Home Address Acknowledgement
   mobility options are present in the Binding Acknowledgement message,
   the mobile node checks the Status field in each option.  If the
   Status field in one option is 0 (Success), the pseudo home address,
   if not already present, is added into the Pseudo Home Address table,
   and the state of the corresponding entry is set to "confirmed".

Top      Up      ToC       Page 28 
   Otherwise, the mobile node deletes any existing pseudo home address
   with the "unconfirmed" state (i.e., either an error code or no
   acknowledgement for such a pseudo home address is received) from the
   Pseudo Home Address table.

   The mobile node considers that the home agent supports the location
   privacy solution, if a valid Pseudo Home Address Acknowledgement
   mobility option with or without a Pseudo Home Address field is
   received.

   Note that the mobile node MUST determine whether the home
   registration succeeds or not based on what is specified RFC 3775.

6.5.4.  Home Test Init to the Home Agent

   To enable location privacy protection during communication with the
   correspondent node in the route optimization mode, the mobile node
   generates a Home Test Init message based on what is specified in RFC
   3775 and RFC 3776.  In addition, if the return routability procedure
   is for a new session with the correspondent node, the mobile node
   selects any pseudo home address from those already registered with
   the home agent and stored in the Pseudo Home Address table;
   otherwise, the mobile node must use the same pseudo home address as
   used with the same correspondent node before.  The selected pseudo
   home address is carried in the Pseudo Home Address mobility option of
   the generated Home Test Init message.  This Home Test Init message is
   protected by an IPsec security association with a non-null encryption
   algorithm.

   After sending the Home Test Init message to the home agent, if there
   is no Binding Update List entry existing for the correspondent node,
   the mobile node creates one entry that points to the pseudo home
   address used; otherwise, the mobile node updates the existing entry.

6.5.5.  Home Test from the Home Agent

   When the mobile node receives a Home Test message from the home
   agent, it processes the packet based on processing rules specified in
   RFC 3775 and RFC 3776.  If this is a valid packet and there is a
   Pseudo Home Address Acknowledgement option included, the mobile node
   examines the Status field inside this mobility option as follows:

   o  If the Status field indicates that the home address test procedure
      using the pseudo home address succeeds (the Status field is 0), in
      addition to what is specified in RFC 3775, the mobile node
      prepares to use the pseudo home address carried in the Pseudo Home
      Address Acknowledgement option for the correspondent registration.

Top      Up      ToC       Page 29 
   o  If the Status field indicates that the home address test procedure
      using the pseudo home address fails (the Status field is larger
      than 127), the mobile node can take steps to correct the cause of
      the error and retransmit the Home Test Init message, subject to
      the retransmission limit specified in RFC 3775.  If this is not
      done or it fails, then the mobile node SHOULD record in its
      Binding Update List that the future home address test procedure
      SHOULD NOT use the pseudo home address with this correspondent
      node.

6.5.6.  Route-Optimized Payload Packets

   After the mobile node completes the route-optimized correspondent
   registration procedure using the pseudo home address, payload packets
   are sent to the correspondent node with the pseudo home address in
   the Home Address destination option.

   The packet processing rules when sending and receiving route-
   optimized packets are the same as in RFC 3775 except that pseudo home
   addresses are used.  In addition, if encrypted pseudo home addresses
   are used, both the mobile node and the correspondent node need to
   replace the encrypted address with the pseudo home address before
   passing them to the upper layers.

   In the case that the mobile node masks the pseudo home address and
   uses the reverse-tunneled correspondent binding update procedure, the
   mobile node performs the operation specified in Section 5.3.4, except
   that the pseudo home address rather than the real home address is
   expected.

6.5.7.  Receiving Binding Refresh Request

   When the Mobile Node receives a Binding Refresh Request message from
   a correspondent node, the destination IP address may be the pseudo
   home address.  In this case, the mobile node needs to check the
   corresponding Binding Update List entry for the correspondent node.
   If the pseudo home address is invalid, the mobile node silently
   discards this message.  Otherwise, the mobile node refreshes the
   binding with the correspondent node by using the same pseudo home
   address.

6.6.  Home Agent Operation

   In this section, we describe the home agent's operation when the
   location privacy solution is used.

Top      Up      ToC       Page 30 
6.6.1.  Conceptual Data Structures

   The Binding Cache entry is extended with a field that points to a
   list of currently accepted pseudo home addresses.  Note that each
   registered pseudo home address MUST be unique and all the registered
   pseudo home addresses SHOULD be organized in such a way that the
   associated Binding Cache entry can be quickly located when a pseudo
   home address is used as the key to look up the Binding Cache.

6.6.2.  Binding Update from the Mobile Node

   If the received Binding Update message contains one or more Pseudo
   Home Address mobility options, the home agent MUST ignore such an
   option if it does not recognize it.  If the home agent recognizes
   such an option, a Pseudo Home Address Acknowledgement mobility option
   is generated and some fields therein are set as follows:

   o  If the Pseudo Home Address field received is empty, the Status
      field is set to 0 (Success), and the Pseudo Home Address field is
      empty.

   o  If the Pseudo Home Address field received is set to all zero, the
      Status field is set is 0 (Success), and a pseudo home address
      SHOULD be included in the Pseudo Home Address field, if the home
      agent supports the dynamic pseudo home address assignment;
      otherwise, the Status field is set to 132 (Dynamic pseudo home
      address assignment not available) and the Pseudo Home Address
      field is empty.

   o  The Pseudo Home Address field received may contain an IPv6
      address.  If the format of such an IP address is incorrect, the
      Status field is set to 130 (Incorrect pseudo home address).  If
      such an IP address is invalid, for example, the prefix is not a
      valid home network prefix or this is detected as a duplicated IP
      address, the Status field is set to 131 (Invalid pseudo home
      address).  In both cases, the Pseudo Home Address field is empty.
      If the home agent suggests a different pseudo home address, the
      Status field is set to 0 (Success), and the new pseudo home
      address is included in the Pseudo Home Address field.  Otherwise,
      if the home agent accepts the requested pseudo home address, the
      Status field is set as 0 (Success), and the same IP address is
      included in the Pseudo Home Address field.

   o  If the home agent does not allow the mobile node to use the pseudo
      home address with the correspondent node, the Status field SHOULD
      be set as 129 (Administratively prohibited) and the Pseudo Home
      Address field is empty.

Top      Up      ToC       Page 31 
   o  In case that the home agent does not accept the Pseudo Home
      Address mobility option for all other reasons, the Status field
      SHOULD be set as 128 (Failure, reason unspecified) and the Pseudo
      Home Address is empty.

   When receiving a Binding Update message protected with the IPsec
   tunnel mode, the home agent performs the operation specified in RFC
   4877.

   When receiving and successfully processing a Binding Update message
   for de-registration from the mobile node, in addition to what is
   specified in RFC 3775, the home agent MUST delete data structures
   related to the location privacy extension.

6.6.3.  Binding Acknowledgement to the Mobile Node

   When sending a Binding Acknowledgement message protected with the
   IPsec tunnel mode, the home agent performs the operation specified in
   RFC 4877.

   The processing rules related to the Pseudo Home Address
   Acknowledgement mobility option are described in Section 6.6.2.

6.6.4.  Home Test Init from the Mobile Node

   When receiving a Home Test Init message from the mobile node, the
   home agent first verifies this message based on the IPsec processing
   rules as specified in RFC 3776.  If the verification fails, the home
   agent acts based on such IPsec processing rules.  Otherwise, if the
   Pseudo Home Address option does not exist in the Home Test Init
   message, the home agent performs the operation as specified in RFC
   3775.  Otherwise, the following operation is performed.

   1.  The home agent looks up its Binding Cache by using the real home
       address as a key.  If the pseudo home address carried in the
       Pseudo Home Address option does not match any pseudo home address
       associated with the corresponding Binding Cache entry (including
       when the Pseudo Home Address field is set as zero), it MUST
       reject the Home Test Init message by sending back a Home Test
       message including the Pseudo Home Address Acknowledgement option
       with the Status field set as 131 (Invalid pseudo home address).

   2.  Otherwise, the home agent constructs a Home Test Init message
       with the pseudo home address as the source IP address, and
       forwards the Home Test Init message to the correspondent node.

Top      Up      ToC       Page 32 
6.6.5.  Home Test to the Mobile Node

   When the home agent intercepts a Home Test message using proxy
   Neighbor Discovery, if the destination IP address matches with one of
   the real home addresses, the home agent performs the operation as
   specified in RFC 3775.  Otherwise, the home agent uses the
   destination IP address to look up the Binding Cache to find if there
   is a matched pseudo home addresses.  If not, the home agent discards
   this message silently.  When a matching pseudo home address is found,
   the home agent generates a Home Test message with a Pseudo Home
   Address Acknowledgement option and sends it to the mobile node.
   Inside the Pseudo Home Address Acknowledgement option, the Status
   field is set to zero (Success) and the Pseudo Home Address field is
   filled with the found pseudo home address.

6.7.  Correspondent Node Operation

   With the solution described in this section, when the correspondent
   node is involved in the route-optimized correspondent binding update
   procedure, there is no new operation if only pseudo home addresses
   are used without encryption.  This specification recommends using
   encrypted pseudo home addresses to thwart revealing any prefix
   information about a mobile node.  The additional operations are the
   same as specified in Section 5.5, except that the pseudo home
   address, instead of the real home address, is used.

7.  Extensions to Mobile IPv6

   This section describes the experimental extensions to Mobile IPv6
   used in this document.  For experimentation purposes, the
   experimental IPv6 Option Type, the experimental IPv6 Routing Header
   Type, and the experimental Mobility Option Type as defined in RFC
   4727 [12] and RFC 5096 [13] can be used in the Encrypted Home Address
   destination option, the Encrypted Home Address routing header, the
   Pseudo Home Address mobility option, and the Pseudo Home Address
   Acknowledgement mobility option.  In the following, we describe the
   format of each extension for illustration purpose.

7.1.  Encrypted Home Address Destination Option

   This option is used in the Destination Option extension header (Next
   Header value = 60).

Top      Up      ToC       Page 33 
       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
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  | Option Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                    Encrypted Home Address                     +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         A type for identifying the use of the encrypted home address in
         this option.  Implementations of this RFC can use the value
         0xFE.  This value is reserved in RFC 4727 for all experiments
         involving IPv6 destination options.

      Encrypted Home Address

         The encrypted home address generated from a either real or
         pseudo home address.

   The processing of other fields in the Encrypted Home Address option
   is the same as that of those fields in the Home Address option
   described in RFC 3775.  Note that if the Encrypted Home Address
   option is present in a packet, the encrypted home address therein
   MUST NOT be treated as the real source IP address by the receiver.

7.2.  Encrypted Home Address Routing Header

   The encrypted home address is carried in this routing header.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  | Hdr Ext Len=2 | Routing Type  |Segments Left=1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                   Encrypted Home Address                      +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 34 
      Routing Type

         A type for identifying the use of the encrypted home address in
         this option.  Implementations of this RFC can use the value
         0xFE.  This value is reserved in RFC 4727 for all experiments
         involving IPv6 routing header.

      Encrypted Home Address

         The encrypted home address generated from a either real or
         pseudo home address.

   The processing of other fields in the Encrypted Home Address routing
   header is the same as described in RFC 3775.  Note that if this
   routing header is present in a packet, the encrypted home address
   therein MUST NOT be treated as the real destination IP address by the
   receiver.

7.3.  Pseudo Home Address Mobility Option

   This mobility option is included in the mobility header, including
   the Binding Update message and the Home Test Init message, and
   carries zero or one pseudo home address.  The alignment requirement
   for this option is 4n.

       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      |A|   Reserved  | Prefix length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                     Pseudo Home Address                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         A unique type (together with the 'A' bit in the Reserved field)
         for identifying the Pseudo Home Address Acknowledgement
         mobility option.  For experimental purpose, the value of this
         type is 18 as reserved in RFC 5096.

Top      Up      ToC       Page 35 
      Length

         The length of the Pseudo Home Address mobility option excluding
         the Type field and the Length field.  It MUST be 2 when the
         Pseudo Home Address field is not present; otherwise, it MUST be
         18.

      Reserved Field

         The 'A' bit, which MUST be set to zero to indicate that this is
         a Pseudo Home Address mobility option.  The rest of bits MUST
         be set as zero by the sender and ignored by the receiver.

      Prefix Length

         The length of the home network prefix of the included pseudo
         home address.  When the Pseudo Home Address field is not
         present, the Prefix Length field MUST be set as zero.

      Pseudo Home Address

         If present, the field contains a pseudo home address that the
         mobile node wants to use for location privacy protection or
         zero if the mobile node requests a pseudo home address from the
         home agent.  This field is not present if the mobile node only
         intends to discover whether the home agent supports the
         location privacy solutions.  The Length field is used to detect
         whether the Pseudo Home Address field is present in the Pseudo
         Home Address mobility option.

7.4.  Pseudo Home Address Acknowledgement Mobility Option

   This mobility option is included in the mobility header, including
   the Binding Acknowledgement message and the Home Test message sent to
   the mobile node, and carries zero or one pseudo home address.  This
   mobility option is used to indicate the status of the pseudo home
   address registration and/or whether the home agent supports the
   location privacy solutions.  The alignment requirement for this
   option is 2n.

Top      Up      ToC       Page 36 
       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     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|   Reserved  | Prefix length |    Status     |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                     Pseudo Home Address                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         A unique type (together with the 'A' bit in the Reserved field)
         for identifying the Pseudo Home Address Acknowledgement
         mobility option.  For experimental purpose, the value of this
         type is 18 as reserved in RFC 5096.

      Length

         The length of the Pseudo Home Address Acknowledgement mobility
         option excluding the Type field and the Length field.  It MUST
         be 4 when the Pseudo Home Address field is not present;
         otherwise, it MUST be 20.

      Reserved

         The 'A' bit, which MUST be set to one to indicate that this is
         a Pseudo Home Address Acknowledgement mobility option.  The
         rest of bits MUST be set as zero by the sender and ignored by
         the receiver.

      Prefix Length

         The length of the home network prefix of the included pseudo
         home address.  When the Pseudo Home Address field is not
         present, the Prefix Length MUST be set as zero.

      Status

         It indicates the status of the pseudo home address
         registration.  Values from 0 to 127 indicate success.  Higher
         values indicate failure.  The following values are reserved:

Top      Up      ToC       Page 37 
                0   Success
                128 Failure, reason unspecified
                129 Administratively prohibited
                130 Incorrect pseudo home address
                131 Invalid pseudo home address
                132 Dynamic pseudo home address assignment not available

      Reserved

         This field is reserved for future use.  It MUST be set to zero
         by the sender and ignored by the receiver.

      Pseudo Home Address

         If present, the field contains a pseudo home address that the
         home agent registers for the mobile node to use for location
         privacy protection.  This field is not present when the home
         agent only needs to indicate that it supports the location
         privacy solutions as a response to the query from the mobile
         node.  The Length field is used to detect whether the Pseudo
         Home Address field is present in the Pseudo Home Address
         Acknowledgement mobility option.



(page 37 continued on part 3)

Next RFC Part