tech-invite   World Map     

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

RFC 5844

 
 
 

IPv4 Support for Proxy Mobile IPv6

Part 2 of 3, p. 17 to 35
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 17 
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

Top      Up      ToC       Page 18 
   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.

Top      Up      ToC       Page 19 
   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.

Top      Up      ToC       Page 20 
   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

Top      Up      ToC       Page 21 
      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

Top      Up      ToC       Page 22 
      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

Top      Up      ToC       Page 23 
      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

Top      Up      ToC       Page 24 
      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.

Top      Up      ToC       Page 25 
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

Top      Up      ToC       Page 26 
   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].

Top      Up      ToC       Page 27 
   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

Top      Up      ToC       Page 28 
      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.

Top      Up      ToC       Page 29 
     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.

Top      Up      ToC       Page 30 
   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

Top      Up      ToC       Page 31 
      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.

Top      Up      ToC       Page 32 
   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

Top      Up      ToC       Page 33 
         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.

Top      Up      ToC       Page 34 
   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.

Top      Up      ToC       Page 35 
      *  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)

Next RFC Part