3.2. Mobile Access Gateway Considerations 3.2.1. Extensions to Binding Update List Entry To support the IPv4 home address mobility feature, the conceptual Binding Update List entry data structure needs to be extended with the following additional fields. o The IPv4 home address assigned to the mobile node's attached interface. This IPv4 home address may have been statically configured in the mobile node's policy profile, or, may have been dynamically allocated by the local mobility anchor. The IPv4 home address entry also includes the corresponding subnet mask. o The IPv4 default router address of the mobile node. This is acquired from the mobile node's local mobility anchor through the received Proxy Binding Acknowledgement message. 3.2.2. Extensions to Mobile Node's Policy Profile To support the IPv4 home address mobility support feature, the mobile node's policy profile, specified in Section 6.2 of [RFC5213], MUST be extended with the following additional fields. Extensions to the mandatory section of the policy profile: o This field identifies all the IP versions for which the home address mobility support needs to be extended to the mobile node. The supported modes are IPv4-only, IPv6-only, and dual IPv4/IPv6. Extensions to the optional section of the policy profile: o The IPv4 home address assigned to the mobile node's attached interface. The specific details on how the network maintains the association between the address and the attached interface is outside the scope of this document. This address field also includes the corresponding subnet mask. 3.2.3. Signaling Considerations 3.2.3.1. Mobile Node Attachment and Initial Binding Registration After detecting a new mobile node on its access link, the mobile access gateway on the access link MUST determine if IPv4 home address mobility support needs to be enabled for that mobile node. The mobile node's policy profile identifies the supported modes (IPv4- only, IPv6-only, or dual IPv4/IPv6) for that mobile node for which
the mobile service needs to be enabled. Based on those policy considerations and from other triggers such as from the network, if it is determined that IPv4 home address mobility support needs to be enabled for the mobile node, considerations from Section 6.9.1.1 of [RFC5213] MUST be applied with the following exceptions. o The IPv4 Home Address Request option MUST be present in the Proxy Binding Update message. * If the mobile access gateway learns the mobile node's IPv4 home address either from its policy profile or from other means, the mobile access gateway MAY ask the local mobility anchor to allocate that specific address by including exactly one instance of the IPv4 Home Address Request option with the IPv4 home address and the prefix length fields in the option set to that specific IPv4 address and the prefix length of the corresponding home network. * The mobile access gateway MAY also ask the local mobility anchor for dynamic IPv4 home address allocation. It can include exactly one instance of the IPv4 Home Address option with the IPv4 home address and the prefix length fields in the option set to the ALL_ZERO value. Furthermore, the (P) flag in the option MUST be set to 0. This serves as a request to the local mobility anchor for the IPv4 home address allocation. o The Proxy Binding Update message MUST be constructed as specified in Section 6.9.1.5 of [RFC5213]. However, the Home Network Prefix option(s) [RFC5213] MUST be present in the Proxy Binding Update only if IPv6 home address mobility support also needs to be enabled for the mobile node. Otherwise, the Home Network Prefix option(s) MUST NOT be present. o When using IPv4 transport to carry the signaling messages, the related considerations from Section 4 MUST be applied additionally. 3.2.3.2. Receiving Proxy Binding Acknowledgement All the considerations from Section 6.9.1.2 of [RFC5213] MUST be applied with the following exceptions. o If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (The mobile node is not authorized for IPv4 mobility service), the mobile access gateway SHOULD NOT send a Proxy Binding Update message including a IPv4 Home Address Request option until an administrative action is taken.
o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS
(The mobile node is not authorized for the requesting IPv4 home
address), the mobile access gateway SHOULD NOT request the same
IPv4 address again, but MAY request the local mobility anchor to
perform the address assignment by including exactly one instance
of the IPv4 Home Address Request option with the IPv4 home address
and the prefix length fields in the option set to the ALL_ZERO
value.
o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE
(The mobile node is not authorized for IPv6 mobility service), the
mobile access gateway SHOULD NOT send a Proxy Binding Update
message including any Home Network Prefix option(s) until an
administrative action is taken.
o If there is no IPv4 Home Address Reply option present in the
received Proxy Binding Acknowledgement message, the mobile access
gateway MUST NOT enable IPv4 support for the mobile node and the
rest of the considerations from this section can be skipped.
o If the received Proxy Binding Acknowledgement message has the
Status field value in the IPv4 Home Address Reply option set to a
value that indicates that the request was rejected by the local
mobility anchor, the mobile access gateway MUST NOT enable IPv4
mobility support.
o If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted), the
mobile access gateway MUST update a Binding Update List entry for
that mobile node. The entry MUST be updated with the assigned
IPv4 home address and other accepted registration values.
o If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted) and
has the IPv4 Home Address Reply option set to a value that
indicates that the request was accepted by the local mobility
anchor, the mobile access gateway MUST establish a bidirectional
tunnel to the local mobility anchor (if there is no existing
bidirectional tunnel to that local mobility anchor) and with the
encapsulation mode set to IPv4-or-IPv6-over-IPv6 (an IPv4 or IPv6
packet carried as a payload of an IPv6 packet). Considerations
from Section 5.6.1 of [RFC5213] MUST be applied for managing the
dynamically created bidirectional tunnel. However, when using
IPv4 transport, the encapsulation mode MUST be set to the
negotiated encapsulation mode, as specified in Section 4 of this
document.
o The mobile access gateway MUST set up the route for forwarding the
IPv4 packets received from the mobile node (using its IPv4 home
address) through the bidirectional tunnel set up for that mobile
node.
o The default router address MUST be obtained from the IPv4 Default-
Router Address option present in the received Proxy Binding
Acknowledgement message. The mobile access gateway SHOULD
configure this address on its interface and respond to any Address
Resolution Protocol (ARP) requests sent by the mobile node to
resolve the hardware address of the default router. However,
since the link between the mobile access gateway and the mobile
node is a point-to-point link, implementations will be able
receive any packets sent to the default router address without
having to explicitly configure the default router address on its
interface. The mobile access gateway MAY also use the default
router address as the source address for any datagrams sent to the
mobile node and originated by the mobile access gateway itself.
It MUST also use this address in the DHCP Router option [RFC2132]
in the DHCP messages.
o If there is an IPv4 DHCP Support Mode option (Section 3.3.4)
present in the received Proxy Binding Acknowledgement message and
if the (S) flag in the option is set to a value of (1), then the
mobile access gateway MUST function as a DHCP server for the
mobile node. If either the (S) flag in the option is set to a
value of (0), or if the option is not present in the request, then
the mobile access gateway MUST function as a DHCP Relay for the
mobile node.
3.2.3.3. Binding Re-Registration and De-Registrations
When sending a Proxy Binding Update either to extend the lifetime of
a mobility session or to de-register the mobility session, the
respective considerations from [RFC5213] MUST be applied.
Furthermore, the following additional considerations MUST also be
applied.
o If there is an IPv4 home address assigned to the mobility session,
then there MUST be exactly one instance of the IPv4 Home Address
Request option present in the Proxy Binding Update message. The
IPv4 home address and the prefix length fields in the option MUST
be set to that specific address and its corresponding subnet-mask
length.
o If there was no IPv4 home address requested in the initial Proxy
Binding Update message, but it is determined that the IPv4 home
address MUST be requested subsequently, then there MUST be exactly
one instance of the IPv4 Home Address Request option present in
the Proxy Binding Update message. The IPv4 home address in the
option MUST be set to either ALL_ZERO or to a specific address
that is being requested.
o For performing selective de-registration of IPv4 home address but
still retaining the mobility session with all the IPv6 home
network prefixes, the Proxy Binding Update message with the
lifetime value of (0) MUST NOT include any IPv6 Home Network
Prefix options [RFC5213]. It MUST include exactly one instance of
the IPv4 Home Address Request option with the IPv4 home address
and the prefix length fields in the option set to the IPv4 home
address that is being de-registered. Similarly, for selective de-
registration of all the IPv6 home network prefixes, the Proxy
Binding Update message MUST NOT include the IPv4 Home address
option, it MUST include a Home Network Prefix option for each of
the assigned home network prefixes assigned for that mobility
session and with the prefix value in the option set to that
respective prefix value.
o The Home Network Prefix option(s) [RFC5213] MUST NOT be present if
the same option(s) was not present in the initial Proxy Binding
Update message. Otherwise, considerations from [RFC5213] with
respect to this option MUST be applied.
o If at any point the mobile access gateway fails to extend the
binding lifetime with the local mobility anchor for the mobile
node's IPv4 address, it MUST remove any forwarding state set up
for the mobile node's IPv4 home address.
3.2.4. Routing Considerations for the Mobile Access Gateway
o On receiving a packet from the bidirectional tunnel established
with the mobile node's local mobility anchor, the mobile access
gateway MUST remove the outer header before forwarding the packet
to the mobile node.
o On receiving a packet from a mobile node connected to its access
link, the packet MUST be forwarded to the local mobility anchor
through the bidirectional tunnel established with the local
mobility anchor. However, when the EnableMAGLocalRouting flag is
set, considerations from Section 6.10.3 of [RFC5213] MUST be
applied with respect to local routing.
o When forwarding the packet through the bidirectional tunnel, the
encapsulation considerations as specified in Section 3.1.3 MUST be
applied (except that the source and destination addresses fields
in the outer encapsulation header are reversed). However, before
forwarding the packet, the mobile access gateway MUST ensure the
source address in the received packet is the address allocated for
that mobile node and that there is an active binding on the local
mobility anchor for that mobile node.
o The mobile access gateway SHOULD use the Proxy ARP [RFC0925] to
reply to ARP Requests that it receives from the mobile node
seeking address resolutions for the destinations on the mobile
node's home subnet. When receiving an ARP Request, the mobile
access gateway SHOULD examine the target IP address of the
Request, and if this IP address matches the mobile node's IPv4
home subnet, it SHOULD transmit a Proxy ARP Reply. However, on
certain types of links, the mobile node does not use ARP for
address resolutions, instead it forwards all the packets to the
mobile access gateway. On such types of links, the mobile access
gateway is not required to support the Proxy ARP function. At the
same time, implementations not supporting the Proxy ARP function
on links where the mobile node uses ARP for seeking address
resolutions for the destinations on the mobile node's home subnet
will result in communication failure.
3.3. Mobility Options and Status Codes
To support the IPv4 home address mobility feature, this specification
defines the following new options and status codes.
3.3.1. IPv4 Home Address Request Option
A new option, the IPv4 Home Address Request option, is defined for
use with the Proxy Binding Update message sent by the mobile access
gateway to the local mobility anchor. This option is used to request
IPv4 home address assignment for the mobile node.
The IPv4 Home Address Request option has an alignment requirement of
4n. Its format is as follows:
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 |Prefix-len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 Home Address Request Option
Type
36
Length
An 8-bit unsigned integer indicating the length of the option
in octets, excluding the Type and Length fields. This field
MUST be set to (6).
Prefix-len
This 6-bit unsigned integer indicating the prefix length of the
mobile node's IPv4 home network corresponding to the IPv4 home
address contained in the option.
Reserved
This 10-bit field is unused for now. The value MUST be
initialized to (0) by the sender and MUST be ignored by the
receiver.
IPv4 home address
This 4-byte field containing the IPv4 home address that is
being requested. The value of 0.0.0.0 is used to request that
the local mobility anchor perform the address allocation.
3.3.2. IPv4 Home Address Reply Option
A new option, the IPv4 Home Address Reply option, is defined for use
in the Proxy Binding Acknowledgement message sent by the local
mobility anchor to the mobile access gateway. This option can be
used to send the assigned mobile node's IPv4 home address.
The IPv4 Home Address Reply option has an alignment requirement of
4n. Its format is as follows:
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 | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Home Address Reply Option
Type
37
Length
An 8-bit unsigned integer indicating the length of the option
in octets, excluding the Type and Length fields. This field
MUST be set to (6).
Status
Indicates success or failure for the IPv4 home address
assignment. Values from 0 to 127 indicate success. Higher
values (128 to 255) indicate failure. The following Status
values are currently allocated by this document:
0 Success
128 Failure, reason unspecified
129 Administratively prohibited
130 Incorrect IPv4 home address
131 Invalid IPv4 address
132 Dynamic IPv4 home address assignment not available
Prefix-len
This 6-bit unsigned integer is used to carry the prefix length
of the mobile node's IPv4 home network corresponding to the
IPv4 home address contained in the option.
Reserved (Res)
This 2-bit field is unused for now. The value MUST be
initialized to (0) by the sender and MUST be ignored by the
receiver.
IPv4 home address
This 4-byte field is used to carry the IPv4 home address
assigned to the mobile node.
3.3.3. IPv4 Default-Router Address Option A new option, the IPv4 Default-Router Address option, is defined for use in the Proxy Binding Acknowledgement message sent by the local mobility anchor to the mobile access gateway. This option can be used to send the mobile node's IPv4 default router address. The IPv4 Default-Router Address option has an alignment requirement of 4n. Its format is as follows: 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 | Reserved (R) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Default-Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IPv4 Default-Router Address Option Type 38 Length An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to (6). Reserved (R) This 16-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver. IPv4 Default-Router Address A 4-byte field containing the mobile node's default router address. 3.3.4. IPv4 DHCP Support Mode Option A new option, the IPv4 DHCP Support Mode option, is defined for use in the Proxy Binding Acknowledgement message sent by the local mobility anchor to the mobile access gateway. This option can be
used to notify the mobile access gateway as to whether it should function as a DHCP Server or a DHCP Relay for the attached mobile node. The IPv4 DHCP Support Mode option has no alignment requirement. Its format is as follows: 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 | Reserved (R) |S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: IPv4 DHCP Support Mode Option Type 39 Length An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to 2. Reserved (R) This 15-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver. DHCP Support Mode (S) A 1-bit field that specifies the DHCP support mode. This flag indicates whether the mobile access gateway should function as a DHCP Server or a DHCP Relay for the attached mobile node. The flag value of (0) indicates the mobile access gateway should act as a DHCP Relay, and the flag value of (1) indicates it should act as a DHCP Server. 3.3.5. Status Codes This document defines the following new Status values for use in the Proxy Binding Acknowledgement message. These values are to be allocated from the same numbering space, as defined in Section 6.1.8 of [RFC3775].
NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170
Mobile node not authorized for IPv4 mobility service.
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 171
Mobile node not authorized for the requesting IPv4 home address.
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: 172
Mobile node not authorized for IPv6 mobility service.
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: 173
Multiple IPv4 home address assignments not supported.
3.4. Supporting DHCP-Based Address Configuration
This section explains how DHCP-based address configuration support
can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It
explains the protocol operation, supported DHCP server deployment
configurations, and the protocol interactions between DHCP agents and
mobility entities in each of the supported configurations.
This specification supports the following two DHCP deployment
configurations.
o DHCP relay agent co-located with the mobile access gateway.
o DHCP server co-located in the mobile access gateway.
The following are the configuration requirements:
o The DHCP server or the DHCP relay agent configured on the mobile
access gateway is required to have an IPv4 address for exchanging
the DHCP messages with the mobile node. This address is the
mobile node's default router address provided by the local
mobility anchor. Optionally, all the DHCP servers co-located with
the mobile access gateways in the Proxy Mobile IPv6 domain can be
configured with a fixed IPv4 address. This fixed address can be
an IPv4 private address [RFC1918] that can be used for the DHCP
protocol communication on any of the access links. This address
will be used as the server identifier in the DHCP messages.
o A DHCP server identifies a DHCP interface from the contents of the
DHCP "Client-identifier" option [RFC2132], if present, or from the
client hardware address (chaddr), as specified in [RFC2131]. Note
that the name "Client-identifier" is a misnomer as it actually
identifies an interface and not the client. The DHCP server uses
this identity to identify the interface for which the address is
assigned. A mobile node in a Proxy Mobile IPv6 domain, can attach
to the network through multiple interfaces and can obtain address
configuration for each of its interfaces. Additionally, it may
perform handoffs between its interfaces. The following are the
related considerations with respect to the identification
presented to the DHCP server.
* If the mobile node attaches to the Proxy Mobile IPv6 domain
through multiple physical interfaces, the DHCP server will
uniquely identify each of those interfaces and will perform
address assignment. The DHCP server will identify the
interface as specified in RFC 2131. The mobile node SHOULD
generate and use the "Client-identifier" for each physical
interface according to [RFC4361]. Any time the mobile node
performs a handoff of a physical interface to a different
mobile access gateway, using the same interface, the DHCP
server will always be able to identify the binding using the
presented identifier. The presented identifier (either the
"Client-identifier" or the hardware address) will remain as the
primary key for each binding, just as how they are unique in a
Binding Cache entry.
* If the mobile node is capable of performing a handoff between
interfaces, as per [RFC5213], a "Client-identifier" value MUST
be used for the attachment point that is not tied to any of the
physical interfaces. The identifier MUST be generated
according to [RFC4361], which guarantees that the identifier is
stable and unique across all "Client-identifier" values in use
in the Proxy Mobile IPv6 domain.
o All the DHCP servers co-located with the mobile access gateways in
a Proxy Mobile IPv6 domain can be configured with the same set of
DHCP option values (e.g., DNS Server, SIP Server, etc.) to ensure
the mobile node receives the same configuration values on any of
the access links in that Proxy Mobile IPv6 domain.
3.4.1. DHCP Server Co-Located with the Mobile Access Gateway
This section explains the operational sequence of home address
assignment operation when the DHCP server is co-located with the
mobile access gateway.
MN MAG(DHCP-S) LMA |------>| | 1. DHCPDISCOVER | |------->| 2. Proxy Binding Update | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) | |========| 4. Tunnel/Route Setup |<------| | 5. DHCPOFFER (IPv4 HoA) |------>| | 6. DHCPREQUEST (IPv4 HoA) |<------| | 7. DHCPACK | | | Figure 7: Overview of DHCP Server Located at Mobile Access Gateway o It is possible that the mobile access gateway may have already completed the Proxy Mobile IPv6 signaling with the local mobility anchor to request both IPv6 home network prefix(es) and IPv4 home address assignment prior to Step 1. In such an event, the Proxy Mobile IPv6 signaling steps (Steps 2 to 4) above are not relevant. o It is possible the mobile access gateway may have initially completed the Proxy Mobile IPv6 signaling prior to Step 1, but only for requesting IPv6 home network prefix(es), and it may later request IPv4 home address assignment after detecting the DHCP triggers from the mobile node as shown above. o The mobile access gateway may choose to ignore the DHCPDISCOVER messages until the Proxy Mobile IPv6 signaling is successfully completed, or it may choose to send a delayed response for reducing the additional delay waiting for a new DHCPDISCOVER message from the mobile node. Initial IPv4 Home Address Assignment: o To acquire the mobile node's IPv4 home address from the local mobility anchor, the mobile access gateway will initiate Proxy Mobile IPv6 signaling with the local mobility anchor. o After the successful completion of the Proxy Mobile IPv6 signaling and upon acquiring the mobile node's IPv4 home address from the local mobility anchor, the DHCP server on the mobile access gateway will send a DHCPOFFER message [RFC2131] to the mobile node. The offered address will be the mobile node's IPv4 home address, assigned by the local mobility anchor. The DHCPOFFER message will also have the Subnet Mask option [RFC2132] and Router option [RFC2132], with the values in those options set to the mobile node's IPv4 home subnet mask and default router address, respectively. Additionally, the Server Identifier option will be included and with the value in the option set to the default router address.
o If the mobile node sends the DHCPREQUEST message, the DHCP server
will send DHCPACK message, as per [RFC2131].
IPv4 Home Address Renewal with the DHCP Server (No Handoff):
o Any time the mobile node goes into the DHCP RENEWING state
[RFC2131], it simply unicasts the DHCPREQUEST message including
the assigned IPv4 home address in the 'Requested IP Address'
option. The DHCPREQUEST is sent to the address specified in the
Server Identifier option of the previously received DHCPOFFER and
DHCPACK messages.
o The DHCP server will send a DHCPACK to the mobile node to
acknowledge the assignment of the committed IPv4 address.
IPv4 Home Address Renewal with the DHCP Server (after Handoff):
When the mobile node goes into the DHCP RENEWING state [RFC2131], it
directly unicasts the DHCPREQUEST message to the DHCP server that
currently provided the DHCP lease. However, if the mobile node
changed its point of attachment and is attached to a new mobile
access gateway, it is required that the mobile node update the DHCP
server address and use the address of the DHCP server that is co-
located with the new mobile access gateway. The following approach
can be adopted to ensure the mobile node uses the DHCP server on the
attached link.
MN oMAG(DHCP-S) nMAG(DHCP-S)
| : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK
| : |
* The use of a fixed DHCP server address on all DHCP servers
Figure 8: Address Renewal with the DHCP Server
o The use of a stable address, either the IPv4 default router
address of the mobile node or a fixed IPv4 address common in that
Proxy Mobile IPv6 domain, as the DHCP Server Identifier will
ensure the DHCPREQUEST message sent by the mobile node to renew
the address will be received by the new mobile access gateway on
the attached link.
o The mobile access gateway after completing the Proxy Mobile IPv6
signaling and upon acquiring the IPv4 home address of the mobile
node will return the address in the DHCPACK message. However, if
the mobile access gateway is unable to complete the Proxy Mobile
IPv6 signaling or is unable to acquire the same IPv4 address as
requested by the mobile node, it will send a DHCPNACK message
[RFC2131] to the mobile node, as shown in Figure 8.
3.4.2. DHCP Relay Agent Co-Located with the Mobile Access Gateway
A DHCP relay agent is co-located with each mobile access gateway. A
DHCP server is located somewhere in the Proxy Mobile IPv6 domain
(e.g., is co-located with the local mobility anchor). Figure 9 shows
the sequence of IPv4 home address assignment using DHCP Relay.
MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update *
| |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| | 3. Tunnel/Route Setup*
|------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R
|<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R
|------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R
|<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R
| | |
Figure 9: Overview of the DHCP Relay Located at Mobile Access Gateway
o The Proxy Mobile IPv6 signaling (starting at Step 1) and the DHCP
address configuration (starting at Step 4) may start in any order.
However, the DHCPOFFER (Step 5) and the immediate steps following
it will occur in the specified order and only after the Tunnel/
Route Setup (Step 3).
o It is possible the mobile access gateway may have initially
completed the Proxy Mobile IPv6 signaling with the local mobility
anchor only to request IPv6 home network prefix(es) and may later
request IPv4 home address assignment after detecting the DHCP
triggers from the mobile node (after Step 4).
o The mobile access gateway may choose to ignore the DHCPDISCOVER
messages until the Proxy Mobile IPv6 signaling is successfully
completed, or it may choose to send a delayed response for
reducing the additional delay waiting for a new DHCPDISCOVER
message from the mobile node.
Initial IPv4 Home Address Assignment:
o To acquire the mobile node's IPv4 home address from the local
mobility anchor, the mobile access gateway will initiate Proxy
Mobile IPv6 signaling with the local mobility anchor.
o After the successful completion of the Proxy Mobile IPv6 signaling
and upon acquiring the mobile node's IPv4 home address from the
local mobility anchor, the mobile access gateway will enable
forwarding for all the DHCP messages between the mobile node and
the DHCP server.
o The DHCP relay agent on the mobile access gateway will add the
DHCP Relay Agent Information option [RFC3046] to the DHCPDISCOVER
message. The assigned IPv4 home address will be included in the
Agent Remote ID Sub-option of the DHCP Relay Agent Information
option. This sub-option is used as a hint for requesting the DHCP
server to allocate that specific IPv4 address.
o On receiving a DHCPOFFER message from the DHCP server, the mobile
access gateway will ensure the assigned address is currently
assigned by the local mobility anchor to that mobile node. If
this address is different from what is assigned to the mobile
node, then the mobile access gateway will drop the DHCPOFFER
message and an administrative error message will be logged.
o When the DHCP messages are sent over administrative boundaries,
the operators need to ensure these messages are secured. All the
DHCP messages relayed by the mobile access gateway can be tunneled
to the local mobility anchor if needed. Alternatively, if the
network in the Proxy Mobile IPv6 domain is secure enough, the
mobile access gateway can just relay the DHCP messages to the
server. To achieve this, all the mobile access gateways need to
have a route towards the DHCP server.
IPv4 Home Address Renewal to the same DHCP Server: (No Handoff)
o When the DHCP client goes into the DHCP RENEW STATE [RFC2131], it
directly unicasts DHCPREQUEST messages to the DHCP server. The
DHCP relay agent may not detect any changes in the DHCP state.
For example, if the mobile node releases the IPv4 address, the
relay agent would not be aware of it. The following describes
additional mechanisms for the mobile access gateway to detect any
changes in the DHCP state.
* The DHCP relay agent can intercept all IPv4 DHCP packets
destined to the set of addresses used within the Proxy Mobile
IPv6 domain as DHCP addresses. Since the link between a mobile
node and a mobile access gateway is the point-to-point link,
the mobile access gateway will be in path for all the messages.
* The DHCP relay agent can use the DHCP Server Identifier
Override Sub-option [RFC5107] to be in path for all the DHCP
message flows. The DHCP client uses the DHCP server address
that is overridden by the DHCP relay agent address as a
destination address of DHCPREQUEST. The DHCP Server Identifier
Override Sub-option is recommended only when the fixed DHCP
relay address is configured on all the mobile access gateways.
Otherwise, the DHCP relay agent address is changed when the
mobile node changes the attached mobile access gateway.
o However, if the DHCP server is co-located with the local mobility
anchor, then the DHCP relay agent is not required to intercept the
unicast DHCP messages between the mobile node and the DHCP server.
This is because the local mobility anchor will ensure that the
DHCP state is consistent with the Proxy Mobile IPv6 binding that
exists for the IPv4 address.
o Once the mobile access gateway intercepts the DHCP message from
the mobile node to the DHCP server, it can verify if the mobile
node is negotiating the same IPv4 address that the local mobility
anchor allocated for that mobile node. If the address in the
DHCPREQUEST message does not match with the IPv4 address allocated
for the mobile node, then the mobile access gateway SHOULD drop
the DHCP message and an administrative error message can be
logged.
o Any time the mobile access gateway detects that the mobile node
has released its IPv4 address, it can send a Proxy Binding Update
to the local mobility anchor and de-register the IPv4 mobility
session.
3.4.3. Common DHCP Considerations
The following DHCP-related considerations are common to both the
supported configuration modes, specified in Sections 3.4.1 and 3.4.2.
o When a mobile node sends a DHCPDISCOVER message [RFC2131], the
DHCP server or the relay agent co-located with the mobile access
gateway will trigger the mobile access gateway to complete the
Proxy Mobile IPv6 signaling. This is the required interaction
between these two protocols. The mobile access gateway, on
receiving this trigger, will check if there is already an assigned
IPv4 home address for the mobile node, from the local mobility
anchor. If there is no assigned IPv4 home address assigned for
that mobile node, the mobile access gateway will complete the
Proxy Mobile IPv6 signaling with the local mobility anchor by
sending a Proxy Binding Update message.
o The mobile node needs to be identified by the MN-Identifier, as
specified in Section 6.6 of [RFC5213]. This identity should be
associated to the DHCP messages sent by the mobile node.
o The mobile access gateway will drop all the DHCPDISCOVER messages
until it completes the Proxy Mobile IPv6 signaling. If the mobile
access gateway is unable to complete the Proxy Mobile IPv6
signaling, or, if the local mobility anchor does not assign an
IPv4 address for the mobile node, the mobile access gateway MUST
NOT enable IPv4 home address mobility support for the mobile node
on that access link.
o The trigger for initiating Proxy Mobile IPv6 signaling can also be
delivered to the mobile access gateway as part of a context
transfer from the previous mobile access gateway, or delivered
from the other network elements in the radio network, the details
of which are outside the scope of this document.
o The DHCPOFFER message [RFC2131] sent to the mobile node MUST
include the Subnet Mask option [RFC2132] and the Router option
[RFC2132]. The values in the Subnet Mask option and Router option
MUST be set to the mobile node's IPv4 home subnet mask and its
default router address, respectively.
o The DHCPOFFER message [RFC2131] sent to the mobile node MUST
include the Interface MTU option [RFC2132]. The DHCP servers in
the Proxy Mobile IPv6 domain MUST be configured to include the
Interface MTU option. The MTU value SHOULD reflect the tunnel MTU
for the bidirectional tunnel between the mobile access gateway and
the local mobility anchor.
o The DHCP lease length allocated to the mobile node's IPv4 home
address may be different from the binding lifetime at the local
mobility anchor for that mobile node's session. It is not
possible to keep these lifetimes synchronized, and so its not
required that the configured lifetimes should be kept same in both
DHCP and Proxy Mobile IPv6.
o When the mobile node performs a handoff from one mobile access
gateway to another, the mobile access gateway on the new link will
initiate the Proxy Mobile IPv6 signaling with the local mobility
anchor. On completing the Proxy Mobile IPv6 signaling, the mobile
access gateway has the proper IPv4 address state that the local
mobility anchor has allocated for the mobile node and that can be
used for supporting DHCP based address configuration on that link.
o Any time the mobile node detects a link change event due to
handoff, or due to other reasons such as re-establishment of the
link-layer, the following are the mobile node's considerations
with respect to the DHCP protocol.
* If the mobile node is DNAv4-capable (Detecting Network
Attachment version 4) [RFC4436] and if it performs DNAv4
procedures after receiving a link change event, it would always
detect the same default router on any of the access links in
that Proxy Mobile IPv6 domain, as the mobile access gateway
configures a fixed link-layer address on all the access links,
as per the base Proxy Mobile IPv6 specification [RFC5213]. The
mobile node will not perform any DHCP operation specifically
due to this event.
* If the mobile node is not DNAv4-capable [RFC4436], after
receiving the link change event it will enter INIT-REBOOT state
[RFC2131] and will send a DHCPREQUEST message as specified in
Section 3.7 of [RFC2131]. The mobile node will obtain the same
address configuration as before, as the link change does not
result in any change at the network layer.
o The mobile node may release its IPv4 home address at any time by
sending the DHCPRELEASE message [RFC2131]. When the mobile access
gateway detects the DHCPRELEASE message sent by the mobile node,
it should consider this as a trigger for de-registering the mobile
node's IPv4 home address. It will apply the considerations
specified in Section 3.2.3.3 for performing the de-registration
procedure. However, this operation MUST NOT release any IPv6 home
network prefix(es) assigned to the mobile node.
(page 35 continued on part 3)