RFC 5726
Mobile IPv6 Location Privacy Solutions
Pages: 48
Experimental
Experimental
Part 2 of 3 – Pages 20 to 37
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
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
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
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)
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.
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.
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
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".
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.
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.
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.
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.
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).
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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:
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)