tech-invite   World Map     

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

RFC 5844

 
 
 

IPv4 Support for Proxy Mobile IPv6

Part 3 of 3, p. 35 to 49
Prev RFC Part

 


prevText      Top      Up      ToC       Page 35 
4.  IPv4 Transport Support

   The Proxy Mobile IPv6 specification [RFC5213] requires the signaling
   messages exchanged between the local mobility anchor and the mobile
   access gateway to be over an IPv6 transport.  However, in some cases,
   the local mobility anchor and the mobile access gateway are separated
   by an IPv4 network.

   The normal Proxy Mobile IPv6 specification [RFC5213] can be run over
   an IPv4 transport without any modifications by using a transition
   technology that allows IPv6 hosts to communicate over IPv4 networks.
   For example, the mobile access gateway and the local mobility anchor
   could have a simple configured IPv6-over-IPv4 tunnel.  Instead of
   configured tunnels, various mechanisms for automatic tunneling could
   be used, too.  To these tunnels, Proxy Mobile IPv6 would look just
   like any other application traffic running over IPv6.

   However, treating Proxy Mobile IPv6 just like any other IPv6 traffic
   would mean an extra layer of encapsulation for the mobile node's
   tunneled data traffic, adding 40 octets of overhead for each packet.

Top      Up      ToC       Page 36 
   The extensions defined in this section allow the mobile access
   gateway and the local mobility anchor to communicate over an IPv4
   network without this overhead.

            IPv4-Proxy-CoA                      IPv4-LMAA
                   |         + - - - - - - +        |
   +--+          +---+      /               \     +---+          +--+
   |MN|----------|MAG|=====   IPv4  Network  =====|LMA|----------|CN|
   +--+          +---+      \               /     +---+          +--+
                             + - - - - - - +

                     Figure 10: IPv4 Transport Network

   When the local mobility anchor and the mobile access gateway are
   configured and reachable using only IPv4 addresses, the mobile access
   gateway serving a mobile node can potentially send the signaling
   messages over IPv4 transport and register its IPv4 address as the
   care-of address in the mobile node's Binding Cache entry.  An IPv4
   tunnel (with any of the supported encapsulation modes) can be used
   for tunneling the mobile node's data traffic.  The following are the
   key aspects of this feature.

   o  The local mobility anchor and the mobile access gateway are both
      configured and reachable using an IPv4 address of the same scope.

   o  The IPv4 addresses used can be private IPv4 addresses, but it is
      assumed that there is no NAT between the local mobility anchor and
      the mobile access gateway.  However, it is possible to use UDP
      encapsulation if other types of middleboxes are present.

   o  The Mobility Header [RFC3775] is carried inside an IPv4 packet
      with UDP header (IPv4-UDP-MH), using a UDP port number for Proxy
      Mobile IPv6 signaling over IPv4.

   o  The mobile node can be an IPv6, IPv4, or a dual IPv4/IPv6 node and
      the IPv4 transport support specified in this section is agnostic
      to the type of address mobility enabled for that mobile node.

   o  The mobile node's data traffic will be tunneled between the local
      mobility anchor and the mobile access gateway.  There are several
      encapsulation modes available:

      *  IPv4 (IPv4 or IPv6 payload packet carried in an IPv4 packet).
         If payload protection using IPsec is enabled for the tunneled
         traffic, the Encapsulating Security Payload (ESP) header
         follows the outer tunnel header.

Top      Up      ToC       Page 37 
      *  IPv4-UDP (payload packet carried in an IPv4 packet with UDP
         header, using a UDP port number for Proxy Mobile IPv6 data;
         this is different port than is used for signaling).  If payload
         protection using IPsec is enabled, the ESP header follows the
         outer IPv4 header, as explained in Section 4.3.

      *  IPv4-UDP-TLV (payload packet carried in an IPv4 packet with UDP
         and TLV header) and IPv4-GRE (Payload packet carried in an IPv4
         packet with GRE header).  Refer to [GREKEY].  If payload
         protection using IPsec is enabled, the ESP header follows the
         outer IPv4 header, as explained in Section 4.3.

4.1.  Local Mobility Anchor Considerations

4.1.1.  Extensions to Binding Cache Entry

   To support this feature, the conceptual Binding Cache entry data
   structure maintained by the local mobility anchor [RFC5213] MUST be
   extended with the following additional parameters.  It is to be noted
   that all of these parameters are specified in [RFC5555] and also
   required here in the present usage context, and are presented here
   only for completeness.

   o  The IPv4 Proxy Care-of Address configured on the mobile access
      gateway that sent the Proxy Binding Update message.  The address
      MUST be the same as the source address of the received IPv4 packet
      that contains the Proxy Binding Update message.  However, if the
      received Proxy Binding Update message is not sent as an IPv4
      packet, i.e., when using IPv6 transport, this field in the Binding
      Cache entry MUST be set to the ALL_ZERO value.

4.1.2.  Extensions to Mobile Node's Policy Profile

   To support the IPv4 Transport Support feature, the mobile node's
   policy profile, specified in Section 6.2 of [RFC5213], MUST be
   extended with the following additional fields.  These are mandatory
   fields of the policy profile required for supporting this feature.

   o  The IPv4 address of the local mobility anchor (IPv4-LMAA).

4.1.3.  Signaling Considerations

   This section provides the rules for processing the Proxy Mobile IPv6
   signaling messages received over IPv4 transport.

Top      Up      ToC       Page 38 
4.1.3.1.  Processing Proxy Binding Updates

   o  If the Proxy Binding Update message is protected with IPsec ESP,
      IPsec processing happens before the packet is passed to Proxy
      Mobile IPv6.

   o  All the considerations from Section 5.3.1 of [RFC5213] except Step
      1 (about IPsec) MUST be applied on the encapsulated Proxy Binding
      Update message.  Note that the Checksum field in Mobility Header
      MUST be ignored.

   o  Upon accepting the request, the local mobility anchor MUST set up
      an IPv4 bidirectional tunnel to the mobile access gateway.  The
      tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA.
      The encapsulation mode MUST be determined by applying the
      following considerations:

      *  If the (F) flag in the received Proxy Binding Update message is
         set to the value of (1), but if the configuration flag,
         AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of
         (0), then the local mobility anchor MUST reject the request
         with the Status field value set to 129 (Administratively
         prohibited).

      *  If the (T) flag is set to (1), or GRE Key option is included,
         see [GREKEY].

      *  If the (F) flag in the received Proxy Binding Update message is
         set to the value of (1), then the encapsulation mode MUST be
         set to IPv4-UDP.  Otherwise, the encapsulation mode MUST be set
         to IPv4.

   o  The local mobility anchor MUST send the Proxy Binding
      Acknowledgement message with the Status field value set to (0)
      (Proxy Binding Update accepted).  The message MUST be constructed
      as specified in Section 4.1.3.2.

4.1.3.2.  Constructing the Proxy Binding Acknowledgement Message

   The local mobility anchor when sending the Proxy Binding
   Acknowledgement message to the mobile access gateway MUST construct
   the message as specified in Section 5.3.6 of [RFC5213].  However, if
   the Proxy Binding Update message was received over IPv4, the
   following additional considerations MUST be applied.

   o  The IPv6 Header is removed, and the Mobility Header containing the
      Proxy Binding Acknowledgement is encapsulated in UDP (with source
      port set to 5436 and destination port set to the source port of

Top      Up      ToC       Page 39 
      the received Proxy Binding Update message).  The Mobility Header
      Checksum field MUST be set to zero (and the UDP checksum MUST be
      used instead).

   o  The source address in the IPv4 header of the message MUST be set
      to the destination IPv4 address of the received request.

   o  If IPsec ESP is used to protect signaling, the packet is processed
      using transport mode ESP as described in Section 4.3.

   o  Figure 11 shows the format of the Proxy Binding Acknowledgement
      message sent over IPv4 and protected using ESP.

     IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
       ESP header (in transport mode)
         UDP header (sport=5436, dport=5436)
           Mobility Header (PBA)

       Figure 11: Proxy Binding Acknowledgement (PBA) Message Sent over
                                     IPv4

4.1.4.  Routing Considerations

4.1.4.1.  Forwarding Considerations

   Forwarding Packets to the Mobile Node:

   o  On receiving an IPv4 or an IPv6 packet from a correspondent node
      with the destination address matching any of the mobile node's
      IPv4 or IPv6 home addresses, the local mobility anchor MUST
      forward the packet through the bidirectional tunnel set up for
      that mobile node.

   o  The format of the tunneled packet is shown below.  The IPv4-UDP-
      TLV and IPv4-GRE encapsulation modes are described in [GREKEY].

  IPv4 Header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)] /* Tunnel Header */
    [UDP Header (src port=5437, dst port=5437]   /* If UDP encap nego */
      /* IPv6 or IPv4 Payload Packet */
      IPv6 header (src=CN, dst=MN-HOA)
        OR
      IPv4 header (src=CN, dst=IPv4-MN-HoA)

      Figure 12: Tunneled IPv4 Packet from LMA to MAG (IPv4 or IPv4-UDP
                             Encapsulation Mode)

Top      Up      ToC       Page 40 
   o  Forwarding Packets Sent by the Mobile Node:

      *  All the reverse tunneled packets (IPv4 and IPv6) that the local
         mobility anchor receives from the mobile access gateway, after
         removing the tunnel header (i.e., the outer IPv4 header along
         with the UDP and TLV header, if negotiated) MUST be routed to
         the destination specified in the inner packet header.  These
         routed packets will have the source address field set to the
         mobile node's home address.

4.1.4.2.  ECN and Payload Fragmentation Considerations

   The ECN considerations specified in Section 5.6.3 of [RFC5213] apply
   for the IPv4 transport tunnels as well.  The mobility agents at the
   tunnel entry and exit points MUST handle ECN information as specified
   in that document.

   The mobility agents at the tunnel entry and exit points MUST apply
   the IP packet fragmentation considerations as specified in [RFC4213].
   Additionally, they MUST also apply the considerations related to
   tunnel error processing and reporting as specified in the same
   specification.

4.1.4.3.  Bidirectional Tunnel Management

   The Tunnel Management considerations specified in Section 5.6.1 of
   [RFC5213] apply for the IPv4 transport tunnels as well, with just one
   difference that the encapsulation mode is different.

4.2.  Mobile Access Gateway Considerations

4.2.1.  Extensions to Binding Update List Entry

   To support the IPv4 Transport Support feature, the conceptual Binding
   Update List entry data structure maintained by the mobile access
   gateway [RFC5213] MUST be extended with the following additional
   parameters.

   o  The IPv4 address of the local mobility anchor.  This address can
      be obtained from the mobile node's policy profile.

4.2.2.  Signaling Considerations

   The mobile access gateway, when sending a Proxy Binding Update
   message to the local mobility anchor, MUST construct the message as
   specified in Section 6.9.1.5 of [RFC5213].  However, if the mobile
   access gateway is in an IPv4-only access network, the following
   additional considerations MUST be applied.

Top      Up      ToC       Page 41 
   o  The Proxy Binding Update message MUST be sent over IPv4 as
      described in Section 4.2.2.1.

   o  Just as specified in [RFC5213], when sending a Proxy Binding
      Update message for extending the lifetime of a currently existing
      mobility session or to de-register the mobility session, the Proxy
      Binding Update message MUST be constructed just as the initial
      request.

   Receiving Proxy Binding Acknowledgement:

   o  If the received Proxy Binding Acknowledgement message is protected
      with IPsec ESP, IPsec processing happens before the packet is
      passed to Proxy Mobile IPv6.  Considerations from Section 4 of
      [RFC5213] MUST be applied to authenticate and authorize the
      message.

   o  All the considerations from Section 6.9.1.2 of [RFC5213] MUST be
      applied on the encapsulated Proxy Binding Acknowledgement message.
      Note that the Checksum field in Mobility Header MUST be ignored.

   o  If the Status field indicates Success, the mobile access gateway
      MUST set up a bidirectional tunnel to the local mobility anchor.

   o  Upon accepting the request, the mobile access gateway MUST set up
      an IPv4 bidirectional tunnel to the local mobility anchor.  The
      tunnel endpoint addresses are the IPv4-Proxy-CoA and the IPv4-
      LMAA.  The encapsulation mode MUST be determined from the below
      considerations:

      *  If the (T) flag is set to (1), or the GRE Key option is
         included, see [GREKEY].

      *  If there is a NAT Detection option [RFC5555] in the received
         Proxy Binding Acknowledgement message, and the (F) flag is set
         to value of (1), the encapsulation mode for the tunnel MUST be
         set to IPv4-UDP.  Otherwise, the encapsulation mode MUST be set
         to IPv4.

4.2.2.1.  Constructing the Proxy Binding Update Message

   o  The IPv6 Header is removed, and the Mobility Header containing the
      Proxy Binding Update message is encapsulated in UDP (with the
      destination port set to 5436).  The Mobility Header Checksum field
      MUST be set to zero (and UDP checksum MUST be used instead).

Top      Up      ToC       Page 42 
   o  The source address in the IPv4 header MUST be set to IPv4-Proxy-
      CoA of the mobile access gateway and the destination address MUST
      be set to the local mobility anchor's IPv4-LMAA.

   o  If the configuration variable ForceIPv4UDPEncapsulationSupport is
      set to value of (1), then the (F) flag in the Proxy Binding Update
      message MUST be set to value of (1).

   o  If IPsec ESP is used to protect signaling, the packet is processed
      using transport mode ESP as described in Section 4.3.

   o  Figure 13 shows the format of the Proxy Binding Update message
      sent over IPv4 and protected using ESP.

     IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
       ESP header (in transport mode)
         UDP header (sport=5436, dport=5436)
           Mobility Header (PBU)

         Figure 13: Proxy Binding Update (PBU) Message Sent over IPv4

4.2.2.2.  Forwarding Considerations

   Forwarding Packets Sent by the Mobile Node:

   o  On receiving an IPv4 or an IPv6 packet from the mobile node to any
      destination, the mobile access gateway MUST tunnel the packet to
      the local mobility anchor.  The format of the tunneled packet is
      shown below.  The IPv4-UDP-TLV and IPv4-GRE encapsulation modes
      are described in [GREKEY].  However, considerations from Section
      6.10.3 of [RFC5213] MUST be applied with respect the local routing
      and on the use of EnableMAGLocalRouting flag.

 IPv4 Header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)] /* Tunnel Header */
    [UDP Header (src port=5437, dst port=5437]   /* If UDP encap nego */
      /* IPv6 or IPv4 Payload Packet */
      IPv6 header (src=MN-HOA, dst=CN)
        OR
      IPv4 header (src=IPv4-MN-HOA, dst=CN)

      Figure 14: Tunneled IPv4 Packet from MAG to LMA (IPv4 or IPv4-UDP
                             Encapsulation Mode)

Top      Up      ToC       Page 43 
   Forwarding Packets Received from the Bidirectional Tunnel:

   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.

4.3.  IPsec Considerations

4.3.1.  PBU and PBA

   The following section describes how IPsec is used to protect the
   signaling messages and data packets between the local mobility anchor
   and mobile access gateway when using IPv4 transport.

   The following are the Security Policy Database (SPD) example entries
   to protect PBU and PBA on the local mobility anchor and mobile access
   gateway.

           MAG SPD-S:
             - IF local_address = IPv4-Proxy-CoA_1 &
                  remote_address = IPv4-LMAA_1 & proto = UDP &
                  remote_port = 5436
               Then use SA ESP transport mode

           LMA SPD-S:
             - IF local_address = IPv4-LMAA_1 &
                  remote_address = IPv4-Proxy-CoA_1 & proto = UDP &
                  local_port = 5436
               Then use SA ESP transport mode

4.3.2.  Payload Packet

   The following are the SPD example entries to protect payload packets
   on the local mobility anchor and mobile access gateway.  Note that
   the example SPDs protect all payload packets sent to and from mobile
   nodes.  If an operator needs to apply a different security mechanism
   per mobile node, they need to create a SPD and a SA entry per mobile
   node.

Top      Up      ToC       Page 44 
           MAG SPD-S:
             - IF interface = tunnel to LMAA_1 &
                  local_address != Proxy-CoA_1 &
                  remote_address != LMAA_1 & proto=any
               Then use SA ESP tunnel mode

           LMA SPD-S:
             - IF interface = tunnel to Proxy-CoA_1 &
                  local_address != LMAA_1 &
                  remote_address != Proxy-CoA_1 & proto=any
               Then use SA ESP tunnel mode

   When payload packets are protected by IPsec, payload packets matching
   the SPDs are passed to the IPsec module and encapsulated using the
   tunnel mode ESP.  The tunnel mode ESP encapsulated payload packets
   are then directly sent to the peer mobile access gateway or local
   mobility anchor.  If IPsec is not applied to payload packets, then
   they are encapsulated as shown in Figures 12 and 14.

5.  Protocol Configuration Variables

5.1.  Local Mobility Anchor - Configuration Variables

   The local mobility anchor MUST allow the following variables to be
   configured by the system management.  The configured values for these
   protocol variables MUST survive server reboots and service restarts.

   AcceptForcedIPv4UDPEncapsulationRequest

      This flag indicates whether or not the local mobility anchor
      should accept IPv4 UDP encapsulation request for the mobile node's
      data traffic.  The default value for this flag is set to (0),
      indicating that plain IPv4 encapsulation (without UDP) is used for
      data traffic.

5.2.  Mobile Access Gateway - Configuration Variables

   The mobile access gateway MUST allow the following variables to be
   configured by the system management.  The configured values for these
   protocol variables MUST survive server reboots and service restarts.

   ForceIPv4UDPEncapsulationSupport

      This flag indicates whether or not the mobile access gateway
      should request the mobile node's local mobility anchor to use
      IPv4-UDP encapsulation mode for the mobile node's data traffic.
      The default value for this flag is set to (0), indicating that
      plain IPv4 encapsulation (without UDP) is used for data traffic.

Top      Up      ToC       Page 45 
6.  IANA Considerations

   This document defines four new Mobility Header options: the IPv4 Home
   Address Request option, IPv4 Home Address Reply option, IPv4 Default
   Router Address option, and IPv4 DHCP Support Mode option.  These
   options are described in Sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4,
   respectively.  The Type value for these options has been assigned
   from the same number space as allocated for the other mobility
   options, as defined in [RFC3775].

   The IPv4 Home Address Reply option, described in Section 3.3.2 of
   this document, introduces a new number space, IPv4 Home Address Reply
   status codes.  This document currently reserves the following values.
   Approval of any new status code values are to be made through IANA
   Expert Review.

   o  0 Success

   o  128 Failure, Reason Unspecified

   o  129 Administratively prohibited

   o  130 Incorrect IPv4 home address

   o  131 Invalid IPv4 address

   o  132 Dynamic IPv4 home address assignment not available

   The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this
   document, introduces a new number space, IPv4 DHCP Support Mode
   Flags.  This document reserves the value 0x1 for the (S) flag.
   Approval of flag values are to be made through IANA Expert Review.
   At this point in time, there are no thoughts on what the new flag
   allocations can be, and hence this document leaves this to the
   discretion of the Expert Review.

   This document also defines new Status values, used in Proxy Binding
   Acknowledgement message, as described in Section 3.3.5.  These values
   have been assigned from the same number space as allocated for other
   status codes [RFC3775].  Each of these allocated values is greater
   than 128.

      NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170

         Mobile node not authorized for IPv4 mobility service.

Top      Up      ToC       Page 46 
      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 assignment not supported.

   IANA has assigned two UDP port numbers, 5436 and 5437, for "pmip6-
   cntl" and "pmip6-data", respectively.

7.  Security Considerations

   All the security considerations from the base Proxy Mobile IPv6
   [RFC5213], Mobile IPv6 [RFC3775], and Dual-Stack Mobile IPv6
   [RFC5555] specifications apply when using the extensions defined in
   this document.  Additionally, the following security considerations
   need to be applied.

   This document defines new mobility options for supporting the IPv4
   Home Address assignment and IPv4 Transport Support features.  These
   options are to be carried in Proxy Binding Update and Proxy Binding
   Acknowledgement messages.  The required security mechanisms specified
   in the base Proxy Mobile IPv6 protocol for protecting these signaling
   messages are sufficient when carrying these mobility options.

   This specification describes the use of IPv4 transport for exchanging
   signaling messages between the local mobility anchor and the mobile
   access gateway.  These can be protected using IPsec as described in
   Section 4.3.

8.  Contributors

   This document reflects discussions and contributions from several
   people (in alphabetical order):

   Kuntal Chowdhury

      kchowdhury@starentnetworks.com

   Vijay Devarapalli

      vijay.devarapalli@azairenet.com

Top      Up      ToC       Page 47 
   Pasi Eronen

      Pasi.Eronen@nokia.com

   Sangjin Jeong

      sjjeong@etri.re.kr

   Basavaraj Patil

      basavaraj.patil@nokia.com

   Myungki Shin

      myungki.shin@gmail.com

9.  Acknowledgements

   The IPv4 support for Proxy Mobile IPv6 was initially covered in
   "Proxy Mobile IPv6" (March 2007).  We would like to thank all the
   authors of the document and acknowledge that initial work.

   Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles
   Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen,
   Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen,
   Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe
   Wu, and Zu Qiang for their helpful review of this document.

   Also, we would like to thank Spencer Dawkins, Tim Polk, Menachem
   Dodge, Adrian Farrel, and Pekka Savola for their reviews of this
   document as part of the IESG review process.  Finally, special thanks
   to Jouni Korohonen for his support in addressing the IPsec issues.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

Top      Up      ToC       Page 48 
   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4361]  Lemon, T. and B. Sommerfeld, "Node-specific Client
              Identifiers for Dynamic Host Configuration Protocol
              Version Four (DHCPv4)", RFC 4361, February 2006.

   [RFC5107]  Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp,
              "DHCP Server Identifier Override Suboption", RFC 5107,
              February 2008.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

10.2.  Informative References

   [RFC0925]  Postel, J., "Multi-LAN address resolution", RFC 925,
              October 1984.

   [RFC1332]  McGregor, G., "The PPP Internet Protocol Control Protocol
              (IPCP)", RFC 1332, May 1992.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4436]  Aboba, B., Carlson, J., and S. Cheshire, "Detecting
              Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.

   [RFC4977]  Tsirtsis, G. and H. Soliman, "Problem Statement: Dual
              Stack Mobility", RFC 4977, August 2007.

Top      Up      ToC       Page 49 
   [GREKEY]   Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
              "GRE Key Option for Proxy Mobile IPv6", Work in Progress,
              May 2009.

Authors' Addresses

   Ryuji Wakikawa
   TOYOTA InfoTechnology Center, U.S.A., Inc.
   465 Bernardo Avenue
   Mountain View, CA  94043
   USA

   EMail: ryuji@us.toyota-itc.com


   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   EMail: sgundave@cisco.com