GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc5555

Network Working Group H. Soliman, Ed. Request for Comments: 5555 Elevate Technologies Category: Standards Track June 2009

        Mobile IPv6 Support for Dual Stack Hosts and Routers

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (c) 2009 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents in effect on the date of
 publication of this document (http://trustee.ietf.org/license-info).
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.

Abstract

 The current Mobile IPv6 and Network Mobility (NEMO) specifications
 support IPv6 only.  This specification extends those standards to
 allow the registration of IPv4 addresses and prefixes, respectively,
 and the transport of both IPv4 and IPv6 packets over the tunnel to
 the home agent.  This specification also allows the mobile node to
 roam over both IPv6 and IPv4, including the case where Network
 Address Translation is present on the path between the mobile node
 and its home agent.

Soliman Standards Track [Page 1] RFC 5555 DSMIPv6 June 2009

Table of Contents

 1. Introduction ....................................................3
    1.1. Requirements Notation ......................................4
    1.2. Motivation for Using Mobile IPv6 Only ......................4
    1.3. Scenarios Considered by This Specification .................4
 2. Solution Overview ...............................................6
    2.1. Home Agent Address Discovery ...............................6
    2.2. Mobile Prefix Solicitation and Advertisement ...............7
    2.3. Binding Management .........................................8
         2.3.1. Foreign Network Supports IPv6 .......................8
         2.3.2. Foreign Network Supports IPv4 Only ..................9
    2.4. Route Optimization ........................................11
    2.5. Dynamic IPv4 Home Address Allocation ......................11
 3. Extensions and Modifications to Mobile IPv6 ....................11
    3.1. Binding Update Extensions .................................11
         3.1.1. IPv4 Home Address Option ...........................11
         3.1.2. The IPv4 Care-of Address Option ....................13
         3.1.3. The Binding Update Message Extensions ..............13
    3.2. Binding Acknowledgement Extensions ........................14
         3.2.1. IPv4 Address Acknowledgement Option ................14
         3.2.2. The NAT Detection Option ...........................16
 4. Protocol Operation .............................................17
    4.1. Tunnelling Formats ........................................17
         4.1.1. Tunnelling Impacts on Transport and MTU ............18
    4.2. NAT Detection .............................................19
    4.3. NAT Keepalives ............................................21
    4.4. Mobile Node Operation .....................................22
         4.4.1. Selecting a Care-of Address ........................22
         4.4.2. Sending Binding Updates ............................23
         4.4.3. Sending Packets from a Visited Network .............25
         4.4.4. Movement Detection in IPv4-Only Networks ...........26
    4.5. Home Agent Operation ......................................26
         4.5.1. Sending Packets to the Mobile Node .................28
    4.6. Correspondent Node Operation ..............................29
 5. Security Considerations ........................................29
    5.1. Handover Interactions for IPsec and IKE ...................30
    5.2. IKE Negotiation Messages between the Mobile Node
         and Home Agent ............................................33
         5.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling .....33
         5.2.2. IKEv2 Operation for Securing Data over IPv4 ........36
 6. Protocol Constants .............................................38
 7. Acknowledgements ...............................................38
 8. IANA Considerations ............................................38
 9. References .....................................................39
    9.1. Normative References ......................................39
    9.2. Informative References ....................................40
 10. Contributors ..................................................41

Soliman Standards Track [Page 2] RFC 5555 DSMIPv6 June 2009

1. Introduction

 Mobile IPv6 [RFC3775] and NEMO [RFC3963] allow mobile nodes to move
 within the Internet while maintaining reachability and ongoing
 sessions, using an IPv6 home address or prefix.  However, since IPv6
 is not widely deployed, it is unlikely that mobile nodes will
 initially use only IPv6 addresses for their connections.  It is
 reasonable to assume that mobile nodes will, for a long time, need an
 IPv4 home address that can be used by upper layers.  It is also
 reasonable to assume that mobile nodes will move to networks that
 might not support IPv6 and would therefore need the capability to
 support an IPv4 care-of address.  Hence, this specification extends
 Mobile IPv6 capabilities to allow dual stack mobile nodes to request
 that their home agent (also dual stacked) tunnel IPv4/IPv6 packets
 addressed to their home addresses, as well as IPv4/IPv6 care-of
 address(es).
 Using this specification, mobile nodes would only need Mobile IPv6
 and [RFC3963] to manage mobility while moving within the Internet,
 hence eliminating the need to run two mobility management protocols
 simultaneously.  This specification provides the extensions needed in
 order to allow dual stack mobile nodes to use IPv6 mobility only.
 This specification will also consider cases where a mobile node moves
 into a private IPv4 network and gets configured with a private IPv4
 care-of address.  In these scenarios, the mobile node needs to be
 able to traverse the IPv4 NAT in order to communicate with the home
 agent.  IPv4 NAT traversal for Mobile IPv6 is presented in this
 specification.
 In this specification, the term "mobile node" refers to both a mobile
 host and a mobile router unless the discussion is specific to either
 hosts or routers.  Similarly, we use the term "home address" to
 reflect an address/prefix format.  Note that both mobile host and
 router functionality have already been defined in [RFC3775] and
 [RFC3963], respectively.  This specification does not change those
 already defined behaviors, nor does it extend the specific types of
 hosts and router support already defined, with the following two
 exceptions: (i) allowing the mobile node to communicate with its home
 agent even over IPv4 networks, and (ii) allowing the use of IPv4 home
 addresses and prefixes.
 In this specification, extensions are defined for the binding update
 and binding acknowledgement.  It should be noted that all these
 extensions apply to cases where the mobile node communicates with a
 Mobility Anchor Point (MAP) as defined in [RFC5380].  The

Soliman Standards Track [Page 3] RFC 5555 DSMIPv6 June 2009

 requirements on the MAP are identical to those stated for the home
 agent; however, it is unlikely that NAT traversal would be needed
 with a MAP, as it is expected to be in the same address domain.

1.1. Requirements Notation

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

1.2. Motivation for Using Mobile IPv6 Only

 IPv6 offers a number of improvements over today's IPv4, primarily due
 to its large address space.  Mobile IPv6 offers a number of
 improvements over Mobile IPv4 [RFC3344], mainly due to capabilities
 inherited from IPv6.  For instance, route optimization and dynamic
 home agent discovery can only be achieved with Mobile IPv6.
 One of the advantages of the large address space provided by IPv6 is
 that it allows mobile nodes to obtain a globally unique care-of
 address wherever they are.  Hence, there is no need for Network
 Address Translator (NAT) traversal techniques designed for Mobile
 IPv4.  This allows Mobile IPv6 to be a significantly simpler and more
 bandwidth-efficient mobility management protocol.  At the same time,
 during the transition towards IPv6, NAT traversal for existing
 private IPv4 networks needs to be considered.  This specification
 introduces NAT traversal for this purpose.
 The above benefits make the case for using only Mobile IPv6 for dual
 stack mobile nodes, as it allows for a long-lasting mobility
 solution.  The use of Mobile IPv6 for dual stack mobility eliminates
 the need for changing the mobility solution due to the introduction
 of IPv6 within a deployed network.

1.3. Scenarios Considered by This Specification

 There are several scenarios that illustrate potential
 incompatibilities for mobile nodes using Mobile IPv6.  Some of the
 problems associated with mobility and transition issues were
 presented in [RFC4977].  This specification considers the scenarios
 that address all the problems discussed in [RFC4977].  The scenarios
 considered in this specification are listed below.
 All of the following scenarios assume that both the mobile node and
 the home agent are IPv4- and IPv6-enabled and that only Mobile IPv6
 is used between the mobile node and the home agent.  We also assume

Soliman Standards Track [Page 4] RFC 5555 DSMIPv6 June 2009

 that the home agent is always reachable through a globally unique
 IPv4 address.  Finally, it's important to note that the following
 scenarios are not mutually exclusive.
 Scenario 1: IPv4-only foreign network
 In this scenario, a mobile node is connected to an IPv4-only foreign
 network.  The mobile node can only configure an IPv4 care-of address.
 Scenario 2: Mobile node behind a NAT
 In this scenario, the mobile node is in a private IPv4 foreign
 network that has a NAT device connecting it to the Internet.  If the
 home agent is located outside the NAT device, the mobile node will
 need a NAT traversal mechanism to communicate with the home agent.
 It should be noted that [RFC5389] highlights issues with some types
 of NATs that act as generic Application Level Gateways (ALGs) and
 rewrite any 32-bit field containing the NAT's public IP addresses.
 This specification will not support such NATs.
 Scenario 3: Home agent behind a NAT
 In this scenario, the communication between the mobile node and the
 home agent is further complicated by the fact that the home agent is
 located within a private IPv4 network.  However, in this scenario, we
 assume that the home agent is allocated a globally unique IPv4
 address.  The address might not be physically configured on the home
 agent interface.  Instead, it is associated with the home agent on
 the Network Address Port Translation (NAPT) device, which allows the
 home agent to be reachable through address or port mapping.
 Scenario 4: Use of IPv4-only applications
 In this scenario, the mobile node may be located in an IPv4, IPv6, or
 dual network.  However, the mobile node might be communicating with
 an IPv4-only node.  In this case, the mobile node would need a stable
 IPv4 address for its application.  The alternative to using an IPv4
 address is to use protocol translators; however, end-to-end
 communication with IPv4 is preferred to the use of protocol
 translators.
 The mobile node may also be communicating with an IPv4-only
 application that requires an IPv4 address.
 The cases above illustrate the need for the allocation of a stable
 IPv4 home address to the mobile node.  This is done using an IPv4
 home address.  Since running Mobile IPv4 and Mobile IPv6

Soliman Standards Track [Page 5] RFC 5555 DSMIPv6 June 2009

 simultaneously is problematic (as illustrated in [RFC4977]), this
 scenario adds a requirement on Mobile IPv6 to support IPv4 home
 addresses.
 Scenario 5: IPv6 and IPv4-enabled networks
 In this scenario, the mobile node should prefer the use of an IPv6
 care-of address for either its IPv6 or IPv4 home address.  Normal
 IP-in-IP tunnelling should be used in this scenario as described in
 [RFC3775].  Under rare exceptions, where IP-in-IP tunnelling for IPv6
 does not allow the mobile node to reach the home agent, the mobile
 node follows the sending algorithm described in Section 4.4.1.  UDP
 tunnelling in IPv6 networks is proposed in this document as a last-
 resort mechanism when reachability cannot be achieved through normal
 IP-in-IP tunnelling.  It should not be viewed as a normal mode of
 operation and should not be used as a first resort.

2. Solution Overview

 In order to allow Mobile IPv6 to be used by dual stack mobile nodes,
 the following needs to be done:
 o  Mobile nodes should be able to use IPv4 and IPv6 home or care-of
    addresses simultaneously and to update their home agents
    accordingly.
 o  Mobile nodes need to be able to know the IPv4 address of the home
    agent as well as its IPv6 address.  There is no need for IPv4
    prefix discovery, however.
 o  Mobile nodes need to be able to detect the presence of a NAT
    device and traverse it in order to communicate with the home
    agent.
 This section presents an overview of the extensions required in order
 to allow mobile nodes to use only Mobile IPv6 for IP mobility
 management.

2.1. Home Agent Address Discovery

 Dynamic Home Agent Address Discovery (DHAAD) is defined in [RFC3775]
 to allow mobile nodes to discover their home agents by appending a
 well-known anycast interface identifier to their home link's prefix.
 However, this mechanism is based on IPv6-anycast routing.  If a
 mobile node (MN) is located in an IPv4-only foreign network, it
 cannot rely on native IPv6 routing.  In this scenario, the solution
 for discovering the home agent's IPv4 address is through the Domain
 Name System (DNS).  If the MN is attached to an IPv6-only or dual

Soliman Standards Track [Page 6] RFC 5555 DSMIPv6 June 2009

 stack network, it may also use procedures defined in [CHOWDHURY] to
 discover home agent information.  Note that the use of [CHOWDHURY]
 cannot give the mobile node information that allows it to communicate
 with the home agent if the mobile node is located in an IPv4-only
 network.  In this scenario, the mobile node needs to discover the
 IPv4 address of its home agent through the DNS.
 For DNS lookup by name, the mobile node should be configured with the
 name of the home agent.  When the mobile node needs to discover a
 home agent, it sends a DNS request with QNAME set to the configured
 name.  An example is "ha1.example.com".  If a home agent has an IPv4
 and IPv6 address, the corresponding DNS record should be configured
 with both 'AAAA' and 'A' records.  Accordingly, the DNS reply will
 contain 'AAAA' and 'A' records.
 For DNS lookup by service, the SRV record defined in [RFC5026] is
 reused.  For instance, if the service name is "mip6" and the protocol
 name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS
 request with the QNAME set to "_mip6._ipv6.example.com".  The
 response should contain the home agent's FQDN(s) and may include the
 corresponding 'AAAA' and 'A' records as well.
 If multiple home agents reside on the home link, each configured with
 a public IPv4 address, then the operation above applies.  The correct
 DNS entries can be configured accordingly.

2.2. Mobile Prefix Solicitation and Advertisement

 According to [RFC3775], the mobile node can send a Mobile Prefix
 Solicitation and receive a Mobile Prefix Advertisement containing all
 prefixes advertised on the home link.
 A dual stack mobile node MAY send a Mobile Prefix Solicitation
 message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where
 the mobile node has no access to IPv6 within the local network.
 Securing these messages requires the mobile node to have a security
 association with the home agent, using IPsec and based on the mobile
 node's IPv4 care-of address as described in [RFC3775] and [RFC4877].
 [RFC3775] requires the mobile node to include the home address option
 in the solicitation message sent to the home agent.  If the mobile
 node is located in an IPv4 network, it will not be assigned an IPv6
 address to include in the source address.  In this case, the mobile
 node MUST use its home address in the source address field of the
 IPv6 packet, in addition to using the home address option as expected
 by [RFC3775].

Soliman Standards Track [Page 7] RFC 5555 DSMIPv6 June 2009

2.3. Binding Management

 A dual stack mobile node will need to update its home agent with its
 care-of address.  If a mobile node has an IPv4 and an IPv6 home
 address, it will need to create a binding cache entry for each
 address.  The format of the IP packet carrying the binding update and
 acknowledgement messages will vary depending on whether the mobile
 node has access to IPv6 in the visited network.  There are three
 different scenarios to consider with respect to the visited network:
 o  The visited network has IPv6 connectivity and provides the mobile
    node with a care-of address (in a stateful or stateless manner).
 o  The mobile node can only configure a globally unique IPv4 address
    in the visited network.
 o  The mobile node can only configure a private IPv4 address in the
    visited network.

2.3.1. Foreign Network Supports IPv6

 In this case, the mobile node is able to configure a globally unique
 IPv6 address.  The mobile node will send a binding update to the IPv6
 address of its home agent, as defined in [RFC3775].  The binding
 update MAY include the IPv4 home address option introduced in this
 document.  After receiving the binding update, the home agent creates
 two binding cache entries: one for the mobile node's IPv4 home
 address and another for the mobile node's IPv6 home address.  Both
 entries will point to the mobile node's IPv6 care-of address.  Hence,
 whenever a packet is addressed to the mobile node's IPv4 or IPv6 home
 address, the home agent will tunnel it in IPv6 to the mobile node's
 IPv6 care-of address that is included in the binding update.
 Effectively, the mobile node establishes two different tunnels, one
 for its IPv4 traffic (IPv4 in IPv6) and one for its IPv6 traffic
 (IPv6 in IPv6), with a single binding update.
 In this scenario, this document extends [RFC3775] by including the
 IPv4 home address option in the binding update message.  Furthermore,
 if the network supports both IPv4 and IPv6, or if the mobile node is
 experiencing problems with IP-in-IP tunnelling, this document
 proposes some mitigating actions as described in Section 4.4.1.
 After accepting the binding update and creating the corresponding
 binding cache entries, the home agent MUST send a binding
 acknowledgement to the mobile node as defined in [RFC3775].  In
 addition, if the binding update included an IPv4 home address option,
 the binding acknowledgement MUST include the IPv4 address
 acknowledgment option as described in Section 3.2.1.  This option

Soliman Standards Track [Page 8] RFC 5555 DSMIPv6 June 2009

 informs the mobile node whether the binding was accepted for the IPv4
 home address.  If this option is not included in the binding
 acknowledgement and the IPv4 home address option was included in the
 binding update, the mobile node MUST assume that the home agent does
 not support the IPv4 home address option and therefore SHOULD NOT
 include the option in future binding updates to that home agent
 address.
 When a mobile node acquires both IPv4 and IPv6 care-of addresses at
 the foreign network, it SHOULD prioritize the IPv6 care-of address
 for its MIPv6 binding as described in Section 4.4.1.

2.3.2. Foreign Network Supports IPv4 Only

 If the mobile node is in a foreign network that only supports IPv4,
 it needs to detect whether a NAT is in its communication path to the
 home agent.  This is done while exchanging the binding update and
 acknowledgement messages as shown later in this document.  NAT
 detection is needed for the purposes of the signaling presented in
 this specification.

2.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses)

 In this scenario, the mobile node will need to tunnel IPv6 packets
 containing the binding update to the home agent's IPv4 address.  The
 mobile node uses the IPv4 address it gets from the foreign network as
 a source address in the outer header.  The binding update will
 contain the mobile node's IPv6 home address.  However, since the
 care-of address in this scenario is the mobile node's IPv4 address,
 the mobile node MUST include its IPv4 care-of address in the IPv6
 packet.  The IPv4 address is represented in the IPv4 care-of address
 option defined in this specification.  If the mobile node had an IPv4
 home address, it MUST also include the IPv4 home address option
 described in this specification.
 After accepting the binding update, the home agent MUST create a new
 binding cache entry for the mobile node's IPv6 home address.  If an
 IPv4 home address option is included, the home agent MUST create
 another entry for that address.  All entries MUST point to the mobile
 node's IPv4 care-of address.  Hence, all packets addressed to the
 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in
 an IPv4 header that includes the home agent's IPv4 address in the
 source address field and the mobile node's IPv4 care-of address in
 the destination address field.
 After accepting the binding updates and creating the corresponding
 entries, the home agent MUST send a binding acknowledgement as
 specified in [RFC3775].  In addition, if the binding update included

Soliman Standards Track [Page 9] RFC 5555 DSMIPv6 June 2009

 an IPv4 home address option, the binding acknowledgement MUST include
 the IPv4 address acknowledgment option as described in Section 3.2.1.
 The binding acknowledgement is encapsulated to the IPv4 care-of
 address, which was included in the source address field of the IPv4
 header encapsulating the binding update.

2.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses)

 In this scenario the mobile node will need to tunnel IPv6 packets
 containing the binding update to the home agent's IPv4 address.  In
 order to traverse the NAT device, IPv6 packets are tunneled using UDP
 and IPv4.  The UDP port allocated for the home agent is 4191
 (dsmipv6).
 The mobile node uses the IPv4 address it gets from the visited
 network as a source address in the IPv4 header.  The binding update
 will contain the mobile node's IPv6 home address.
 After accepting the binding update, the home agent MUST create a new
 binding cache entry for the mobile node's IPv6 home address.  If an
 IPv4 home address option is included, the home agent MUST create
 another entry for that address.  All entries MUST point to the mobile
 node's IPv4 care-of address included in the source address of the
 IPv4 header that encapsulated the binding update message.  In
 addition, the tunnel used MUST indicate UDP encapsulation for NAT
 traversal.  Hence, all packets addressed to the mobile node's home
 address(es) (IPv4 or IPv6) will be encapsulated in UDP and then
 encapsulated in an IPv4 header that includes the home agent's IPv4
 address in the source address field and the mobile node's IPv4 care-
 of address in the destination address field.  Note that the home
 agent MUST store the source UDP port numbers contained in the packet
 carrying the binding update in order to be able to forward packets to
 the mobile node.
 After accepting the binding updates and creating the corresponding
 entries, the home agent MUST send a binding acknowledgement as
 specified in [RFC3775].  In addition, if the binding update included
 an IPv4 home address option, the binding acknowledgement MUST include
 the IPv4 address acknowledgment option as described later in this
 specification.  The binding acknowledgement is encapsulated in UDP
 and then in IPv4 with the home agent's IPv4 address in the source
 address field and the mobile node's IPv4 care-of address in the
 destination field.  The IPv4 address in the destination field of the
 IPv4 packet is the source address that was received in the IPv4
 header containing the binding update message.  The inner IPv6 packet
 will contain the home agent's IPv6 address as a source address and
 the mobile node's IPv6 home address in the destination address field.

Soliman Standards Track [Page 10] RFC 5555 DSMIPv6 June 2009

 The mobile node needs to maintain the NAT bindings for its current
 IPv4 care-of address.  This is done through sending the binding
 update regularly to the home agent.

2.4. Route Optimization

 Route optimization, as specified in [RFC3775], will operate in an
 identical manner for dual stack mobile nodes when they are located in
 a visited network that provides IPv6 addresses to the mobile node and
 while communicating with an IPv6-enabled correspondent node.
 However, when located in an IPv4-only network, or when using the IPv4
 home address to communicate with an IPv4 correspondent node, route
 optimization will not be possible due to the difficulty of performing
 the return-routability test.  In this specification, UDP
 encapsulation is only used between the mobile node and its home
 agent.  Therefore, mobile nodes will need to communicate through the
 home agent.
 Route optimization will not be possible for IPv4 traffic -- that is,
 traffic addressed to the mobile node's IPv4 home address.  This is
 similar to using Mobile IPv4; therefore, there is no reduction of
 features resulting from using this specification.

2.5. Dynamic IPv4 Home Address Allocation

 It is possible to allow for the mobile node's IPv4 home address to be
 allocated dynamically.  This is done by including 0.0.0.0 in the IPv4
 home address option that is included in the binding update.  The home
 agent SHOULD allocate an IPv4 address to the mobile node and include
 it in the IPv4 address acknowledgement option sent to the mobile
 node.  In this case, the lifetime of the binding is bound to the
 minimum of the lifetimes of the IPv6 binding and the lease time of
 the IPv4 home address.

3. Extensions and Modifications to Mobile IPv6

 This section highlights the protocol and implementation additions
 required to support this specification.

3.1. Binding Update Extensions

3.1.1. IPv4 Home Address Option

 This option is included in the mobility header, including the binding
 update message sent from the mobile node to a home agent or Mobility
 Anchor Point.  The alignment requirement for this option is 4n.

Soliman Standards Track [Page 11] RFC 5555 DSMIPv6 June 2009

  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 |P|    Reserved     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     IPv4 home address                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 1: IPv4 Home Address Option
 Type
    29
 Length
    6
 Prefix-len
    The length of the prefix allocated to the mobile node.  If only a
    single address is allocated, this field MUST be set to 32.  In the
    first binding update requesting a prefix, the field contains the
    prefix length requested.  However, in the following binding
    updates, this field must contain the length of the prefix
    allocated.  A value of zero is invalid and MUST be considered an
    error.
 P
    A flag indicating, when set, that the mobile node requests a
    mobile network prefix.  This flag is only relevant for new
    requests, and must be ignored for binding refreshes.
 Reserved
    This field is reserved for future use.  It MUST be set to zero by
    the sender and ignored by the receiver.
 IPv4 Home Address
    The mobile node's IPv4 home address that should be defended by the
    home agent.  This field could contain any unicast IPv4 address
    (public or private) that was assigned to the mobile node.  The
    value 0.0.0.0 is used to request an IPv4 home address from the
    home agent.  A mobile node may choose to use this option to
    request a prefix by setting the address to All Zeroes and setting
    the P flag.  The mobile node could then form an IPv4 home address

Soliman Standards Track [Page 12] RFC 5555 DSMIPv6 June 2009

    based on the allocated prefix.  Alternatively, the mobile node may
    use two different options, one for requesting an address (static
    or dynamic) and another for requesting a prefix.

3.1.2. The IPv4 Care-of Address Option

 This option is included in the mobility header, including the binding
 update message sent from the mobile node to a home agent or Mobility
 Anchor Point.  The alignment requirement for this option is 4n.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type        |   Length      |         Reserved              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     IPv4 Care-of address                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 2: The IPv4 CoA Option
 Type
    32
 Length
    6
 Reserved
    This field is set to zero by the sender and ignored by the
    receiver.
 IPv4 Care-of Address
    This field contains the mobile node's IPv4 care-of address.  The
    IPv4 care-of address is used when the mobile node is located in an
    IPv4-only network.

3.1.3. The Binding Update Message Extensions

 This specification extends the binding update message with one new
 flag.  The flag is shown and described below.

Soliman Standards Track [Page 13] RFC 5555 DSMIPv6 June 2009

  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
                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 |          Sequence #           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |A|H|L|K|M|R|P|F|  Reserved     |           Lifetime            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 3: Binding Update Message
 F
    When set, this flag indicates a request for forcing UDP
    encapsulation regardless of whether a NAT is present on the path
    between the mobile node and the home agent.  This flag may be set
    by the mobile node if it is required to use UDP encapsulation
    regardless of the presence of a NAT.  This flag SHOULD NOT be set
    when the mobile node is configured with an IPv6 care-of address --
    with the exception of the scenario mentioned in Section 4.4.1.

3.2. Binding Acknowledgement Extensions

3.2.1. IPv4 Address Acknowledgement Option

 This option is included in the mobility header, including the binding
 acknowledgement message sent from the home agent or Mobility Anchor
 Point to the mobile node.  This option indicates whether a binding
 cache entry was created for the mobile node's IPv4 address.
 Additionally, this option includes an IPv4 home address in the case
 of dynamic IPv4 home address configuration (i.e., if the unspecified
 IPv4 address was included in the binding update).  The alignment
 requirement for this option is 4n.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |   Status      |Pref-len   |Res|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      IPv4 home address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 4: IPv4 Address Acknowledgement Option

Soliman Standards Track [Page 14] RFC 5555 DSMIPv6 June 2009

 Type
    30
 Length
    6
 Status
    Indicates success or failure for the IPv4 home address binding.
    Values from 0 to 127 indicate success.  Higher values indicate
    failure.
 Pref-len
    The prefix length of the address allocated.  This field is only
    valid in case of success and MUST be set to zero and ignored in
    case of failure.  This field overrides what the mobile node
    requested (if not equal to the requested length).
 Res
    This field is reserved for future use.  It MUST be set to zero by
    the sender and ignored by the receiver
 IPv4 Home Address
    The IPv4 home address that the home agent will use in the binding
    cache entry.  This could be a public or private address.  This
    field MUST contain the mobile node's IPv4 home address.  If the
    address were dynamically allocated, the home agent will add the
    address to inform the mobile node.  Otherwise, if the address is
    statically allocated to the mobile node, the home agent will copy
    it from the binding update message.
 The following values are allocated for the status field:
 o  0 Success
 o  128 Failure, reason unspecified
 o  129 Administratively prohibited
 o  130 Incorrect IPv4 home address
 o  131 Invalid IPv4 address

Soliman Standards Track [Page 15] RFC 5555 DSMIPv6 June 2009

 o  132 Dynamic IPv4 home address assignment not available
 o  133 Prefix allocation unauthorized

3.2.2. The NAT Detection Option

 This option is sent from the home agent to the mobile node to
 indicate whether a NAT was in the path.  This option MAY also include
 a suggested NAT binding refresh time for the mobile node.  This might
 be useful for scenarios where the mobile node is known to be moving
 within the home agent's administrative domain and, therefore, the NAT
 timeout is known (through configuration) to the home agent.  Section
 3.5 of [RFC5405] discusses issues with NAT timeout in some detail.
 The alignment requirement for this option is 4n.  If a NAT is
 detected, this option MUST be sent by the home agent.
  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     |F|          Reserved           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Refresh time                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 5: The NAT Detection Option
 Type
    31
 Length
    6
 F
    This flag indicates to the mobile node that UDP encapsulation is
    required.  When set, this flag indicates that the mobile node MUST
    use UDP encapsulation even if a NAT is not located between the
    mobile node and home agent.  This flag SHOULD NOT be set when the
    mobile node is assigned an IPv6 care-of address -- with the
    exception of accommodating the scenarios discussed in
    Section 4.4.1.

Soliman Standards Track [Page 16] RFC 5555 DSMIPv6 June 2009

 Reserved
    This field is reserved for future use.  It MUST be set to zero by
    the sender and ignored by the receiver.
 Refresh Time
    A suggested time (in seconds) for the mobile node to refresh the
    NAT binding.  If set to zero, it is ignored.  If this field is set
    to all 1s, it means that keepalives are not needed, i.e., no NAT
    was detected.  The home agent MUST be configured with a default
    value for the refresh time.  The recommended value is outlined in
    Section 6.

4. Protocol Operation

 This section presents the protocol operation and processing for the
 messages presented above.  In addition, this section introduces the
 NAT detection and traversal mechanism used by this specification.

4.1. Tunnelling Formats

 This specification allows the mobile node to use various tunnelling
 formats depending on its location and the visited network's
 capabilities.  The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6,
 or use UDP encapsulation to tunnel IPv6 in IPv4.  Naturally, this
 specification also supports tunnelling IPv6 in IPv6 [RFC2473].
 This specification allows UDP-based tunnelling to be used between the
 mobile node and its home agent or MAP.  A UDP encapsulation format
 means the following order of headers:
    IPv4/v6
    UDP
    IP (v4 or v6)
    Other headers
 Note that the use of UDP encapsulation for IPv6 care-of addresses
 SHOULD NOT be done except in the circumstances highlighted in Section
 4.4.1.
 When using this format, the receiver parses the version field
 following the UDP header in order to determine whether the following
 header is IPv4 or IPv6.  The rest of the headers are processed
 normally.  The above order of headers does not take IPsec headers

Soliman Standards Track [Page 17] RFC 5555 DSMIPv6 June 2009

 into account as they may be placed in different parts of the packet.
 The above format MUST be supported by all implementations of this
 specification and MUST always be used to send the binding update
 message.
 UDP tunnelling can also encapsulate an Encapsulating Security Payload
 (ESP) header as shown below:
    IPv4/v6
    UDP
    ESP
    IP (v4 or v6)
    Other headers
 The negotiation of the secure tunnel format described above is
 discussed in Section 5.2.  The receiver of a UDP tunnel detects
 whether or not an ESP header is present based on the UDP port used.

4.1.1. Tunnelling Impacts on Transport and MTU

 Changing the tunnel format may occur due to movement of the mobile
 node from one network to another.  This can impact the link and path
 MTU, which may affect the amount of bandwidth available to the
 applications.  The mobile node may use Path MTU Discovery (PMTUD) as
 specified in [RFC4459].
 To accommodate traffic that uses Explicit Congestion Notification
 (ECN), it is RECOMMENDED that the ECN and Differentiated Services
 Code Point (DSCP) information be copied between the inner and outer
 header as defined in [RFC3168] and [RFC2983].  It is RECOMMENDED that
 the full-functionality option defined in Section 9.1.1 of [RFC3168]
 be used to deal with ECN.
 Note that some implementations may not be able to use ECN over the
 UDP tunnel.  This is due to the lack of access to ECN bits in the UDP
 API on most platforms.  However, this issue can be avoided if UDP
 encapsulation is done in the kernel.
 Note that, when using UDP encapsulation, the Time to Live (TTL) field
 must be decremented in the same manner as when IP-in-IP encapsulation
 is used.

Soliman Standards Track [Page 18] RFC 5555 DSMIPv6 June 2009

4.2. NAT Detection

 This section deals with NAT detection for the purpose of
 encapsulating packets between the mobile node and the home agent when
 the mobile node is present in a private IPv4 network.  Mobile IPv6
 uses IKEv2 to establish the IPsec security association (SA) between
 the mobile node and the home agent.  IKEv2 has its own NAT detection
 mechanism.  However, IKEv2's NAT detection is only used for the
 purpose of setting up the IPsec SA for secure traffic.  The
 interactions between the two NAT traversal mechanisms are described
 in Section 5.
 NAT detection is done when the initial binding update message is sent
 from the mobile node to the home agent.  When located in an IPv4-only
 foreign link, the mobile node sends the binding update message
 encapsulated in UDP and IPv4.  The source address of the IPv6 packet
 is the mobile node's IPv6 home address.  The destination address is
 the IPv6 address of the home agent.  The IPv4 header contains the
 IPv4 care-of address in the source address field and the IPv4 address
 of the home agent in the destination address field.
 When the home agent receives the encapsulated binding update, it
 compares the IPv4 address of the source address field in the IPv4
 header with the IPv4 address included in the IPv4 care-of address
 option.  If the two addresses match, no NAT device was in the path.
 Otherwise, a NAT was in the path and the NAT detection option is
 included in the binding acknowledgement.  The binding acknowledgement
 and all future packets are then encapsulated in UDP and IPv4.  The
 source address in the IPv4 header is the IPv4 address of the home
 agent.  The destination address is the IPv4 address received in the
 IPv4 header encapsulating the binding update (this address will be
 different from the IPv4 care-of address when a NAT is in the path).
 The source port in the packet is the home agent's source port.  The
 destination port is the source port received in the binding update
 message.  Note that the home agent stores the port numbers and
 associates them with the mobile node's tunnel in order to forward
 future packets.
 Upon receiving the binding acknowledgement with the NAT detection
 option, the mobile node sets the tunnel to the home agent to UDP
 encapsulation.  Hence, all future packets to the home agent are
 tunneled in UDP and IPv4.  For all tunneled IPv6 packets, the source
 address in the IPv6 header is the mobile node's IPv6 home address and
 the destination address is the correspondent node's IPv6 address.
 All tunneled IPv4 packets will contain the mobile node's IPv4 home
 address in the source address field of the inner IPv4 packet and the

Soliman Standards Track [Page 19] RFC 5555 DSMIPv6 June 2009

 correspondent node's IPv4 address in the destination address field.
 The outer IPv4 header is the same whether the inner packet is IPv4 or
 IPv6.
 If no NAT device was detected in the path between the mobile node and
 the home agent, then IPv6 packets are tunneled in an IPv4 header
 unless the home agent forces UDP encapsulation using the F flag.  The
 content of the inner and outer headers are identical to the UDP
 encapsulation case.
 A mobile node MUST always tunnel binding updates in UDP when located
 in an IPv4-only network.  Essentially, this process allows for
 perpetual NAT detection.  Similarly, the home agent MUST encapsulate
 binding acknowledgements in a UDP header whenever the binding update
 is encapsulated in UDP.
 In conclusion, the packet formats for the binding update and
 acknowledgement messages are shown below:
 Binding update received by the home agent:
    IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
    UDP header
    IPv6 header (src=V6HOA, dst=HAADDR)
    ESP header
    Mobility header
    BU [IPv4 HAO]
    IPv4 CoA option
 Where V4ADDR is either the IPv4 care-of address or the address
 provided by the NAT device.  V6HOA is the IPv6 home address of the
 mobile node.  The binding update MAY also contain the IPv4 home
 address option, IPv4 HAO.
 Binding acknowledgement sent by the home agent:
    IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
    UDP header
    IPv6 header (src=HAADDR, dst=V6HOA)

Soliman Standards Track [Page 20] RFC 5555 DSMIPv6 June 2009

    ESP header
    Mobility header
    BA ([IPv4 ACK], NAT DET)
 Where V6HOA is the IPv6 home address of the mobile node.  The IPv4
 ACK is the IPv4 address acknowledgement option, which is only
 included if the IPv4 home address option is present in the BU.  The
 NAT DET is the NAT detection option, which MUST be present in the
 binding acknowledgement message if the binding update was
 encapsulated in UDP.

4.3. NAT Keepalives

 If a NAT is detected, the mobile node will need to refresh the NAT
 bindings in order to be reachable from the home agent.  NAT bindings
 can be refreshed through sending and receiving traffic encapsulated
 in UDP.  However, if the mobile node is not active, it will need to
 periodically send a message to the home agent in order to refresh the
 NAT binding.  This can be done using the binding update message.  The
 binding update/acknowledgement pair will ensure that the NAT bindings
 are refreshed in a reliable manner.  There is no way for the mobile
 node to know the exact time of the NAT binding.  The default time
 suggested in this specification is NATKATIMEOUT (see Section 6).  If
 the home agent suggests a different refresh period in the binding
 acknowledgement, the mobile node SHOULD use the value suggested by
 the home agent.
 If the refresh time in the NAT detection option in the binding
 acknowledgement is set to all 1s, the mobile node need not send
 messages to refresh the NAT binding.  However, the mobile node may
 still be required to encapsulate traffic in UDP.  This scenario may
 take place when a NAT is not detected but the home agent still
 requires the mobile node to use UDP encapsulation.
 It should be noted that a mobile node that does not need to be
 reachable (i.e., one that only cares about the session continuity
 aspect of Mobile IP) does not need to refresh the NAT binding.  In
 this case, the mobile node would only be able to initiate
 communication with other nodes.  However, this is likely to imply
 that the mobile node will need to send a binding update before
 initiating communication after a long idle period as it is likely to
 be assigned a different port and IPv4 address by the NAT when it
 initiates communication.  Hence, an implementation may choose, for
 the sake of simplicity, to always maintain the NAT bindings even when
 it does not need reachability.

Soliman Standards Track [Page 21] RFC 5555 DSMIPv6 June 2009

 Note that keepalives are also needed by IKEv2 over UDP port 4500.
 This is needed for IKE (Internet Key Exchange Protocol) dead-peer
 detection, which is not handled by DSMIPv6 keepalives.

4.4. Mobile Node Operation

 In addition to the operations specified in [RFC3775] and [RFC3963],
 this specification requires mobile nodes to be able to support an
 IPv4 home address.  This specification also requires the mobile node
 to choose an IPv4 or an IPv6 care-of address.  We first discuss
 care-of address selection, then continue with binding management and
 transmission of normal traffic.

4.4.1. Selecting a Care-of Address

 When a mobile node is in a dual stacked, visited network, it will
 have a choice between an IPv4 and an IPv6 care-of address.  The
 mobile node SHOULD prefer the IPv6 care-of address and bind it to its
 home address(es).  If a mobile node attempted to bind the IPv6 care-
 of address to its home address(es) and the binding update timed out,
 the mobile node SHOULD:
 o  Resend the binding update using the exponential back-off algorithm
    described in [RFC3775].
 o  If after three attempts, in total, a binding acknowledgement was
    not received, the mobile node SHOULD send a new binding update
    using the IPv4 care-of address.  The exponential backoff algorithm
    described in [RFC3775] should be used for re-transmission of the
    binding update if needed.
 This procedure should be used to avoid scenarios where IPv6
 connectivity may not be as reliable as IPv4.  This unreliability may
 take place during early deployments of IPv6 or may simply be due to
 temporary outages affecting IPv6 routing.
 It is RECOMMENDED that upon movement, the mobile node not change the
 IP address family chosen for the previous binding update unless the
 mobile node is aware that it has moved to a different administrative
 domain where previous problems with IPv6 routing may not be present.
 Repeating the above procedure upon every movement can cause
 significant degradation of the mobile node's applications'
 performance due to extended periods of packet losses after handover,
 if the routing outage is still in effect.
 When using an IPv4 care-of address and IP-in-IP encapsulation, if the
 mobile node implementation is made aware by upper layers of
 persistent packet losses, it may attempt to resend the binding update

Soliman Standards Track [Page 22] RFC 5555 DSMIPv6 June 2009

 with the F flag set, requesting UDP encapsulation for all packets.
 This may avoid packet losses due to situations where local
 firewalling policies prevent the use of IP-in-IP encapsulation.
 The effect of this address selection mechanism is to allow the
 following preferences in the absence of NAT:
 1. IPv6
 2. IPv4 (using IP-in-IP or UDP encapsulation if a NAT is detected)
 3. UDP encapsulation when IP-in-IP is not allowed by the local
    domain.

4.4.2. Sending Binding Updates

 When sending an IPv6 packet containing a binding update while
 connected to an IPv4-only access network, mobile nodes MUST ensure
 the following:
 o  The IPv6 packet is encapsulated in UDP.
 o  The source address in the IPv4 header is the mobile node's IPv4
    care-of address.
 o  The destination address in the IPv4 header is the home agent's
    IPv4 address.
 o  The source address in the IPv6 header is the mobile node's IPv6
    home address.
 o  The IPv4 home address option MAY be included in the mobility
    header.  This option contains the IPv4 home address.  If the
    mobile node did not have a static home address, it MAY include the
    unspecified IPv4 address, which acts as a request for a dynamic
    IPv4 home address.  Alternatively, one or more IPv4 home address
    options may be included with requests for IPv4 prefixes (i.e.,
    with the P flag set).
 o  If the mobile node wishes to use UDP encapsulation only, it must
    set the F flag in the binding update message.
 o  The IPv6 packet MUST be authenticated as per [RFC3775], based on
    the mobile node's IPv6 home address.
 When sending a binding update from a visited network that supports
 IPv6, the mobile node MUST follow the rules specified in [RFC3775].
 In addition, if the mobile node has an IPv4 home address or needs

Soliman Standards Track [Page 23] RFC 5555 DSMIPv6 June 2009

 one, it MUST include the IPv4 home address option in the mobility
 header.  If the mobile node already has a static IPv4 home address,
 this address MUST be included in the IPv4 home address option.
 Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST
 include the IPv4 0.0.0.0 address in the IPv4 home address option.
 In addition to the rules in [RFC3775], the mobile node should follow
 the care-of address selection guidelines in Section 4.4.1.
 When the mobile node receives a binding acknowledgement from the home
 agent, it follows the rules in [RFC3775] and [RFC3963].  In addition,
 the following actions MUST be made:
 o  If the status field indicated failure with error code 144, the
    mobile node MAY resend the binding update without setting the F
    flag.
 o  If the mobility header includes an IPv4 address acknowledgement
    option indicating success, the mobile node should create two
    entries in its binding update list: one for the IPv6 home address
    and another for the IPv4 home address.
 o  If the NAT detection option is present, the mobile node MUST
    tunnel future packets in UDP and IPv4.  This MUST be indicated in
    the binding update list.
 o  If no IPv4 address acknowledgement option is present, and an IPv4
    home address option was present in the binding update, the mobile
    node MUST only create one binding update list entry for its IPv6
    home address.  The mobile node MAY include the IPv4 home address
    option in future binding updates.
 o  If an IPv4 address acknowledgement option is present and it
    indicates failure for the IPv4 home address binding, the mobile
    node MUST NOT create an entry for that address in its binding
    update list.  The mobile node MAY include the IPv4 home address
    option in future binding updates.

4.4.2.1. Removing Bindings

 Mobile nodes will remove bindings from the home agent's binding cache
 whenever they move to the home link, or simply when mobility support
 is not needed.
 Deregistering the IPv6 home address is described in [RFC3775].  The
 same mechanism applies in this specification.  Mobile nodes may
 remove the binding for only the IPv4 home address by sending a
 binding update that does not include the IPv4 home address option.

Soliman Standards Track [Page 24] RFC 5555 DSMIPv6 June 2009

 Upon receiving this binding update, the home agent will replace the
 existing cache entries with the content of the new message.  This
 ensures that the IPv4 home address binding is removed while
 maintaining an IPv6 binding.
 Note that the mobile node cannot remove the IPv6 home address binding
 while maintaining an IPv4 home address binding.
 A binding update message with a lifetime of zero will remove all
 bindings for the mobile node.

4.4.3. Sending Packets from a Visited Network

 When the mobile node is located in an IPv6-enabled network, it sends
 and receives IPv6 packets as described in [RFC3775].  In cases where
 IP-in-IP encapsulation is not providing connectivity to the home
 agent, the mobile node may choose to encapsulate in UDP as suggested
 in Section 4.4.1.  However, this encapsulation of IPv6 traffic should
 be used as a last resort, as described.  IPv4 traffic is encapsulated
 in IPv6 packets to the home agent.
 When the mobile node is located in an IPv4-only network, it will send
 IPv6 packets to its home agent according to the following format:
    IPv4 header (src=V4CoA, dst=HA_V4ADDR)
    [UDP header]
    IPv6 header (src=V6HoA, dst=CN)
    Upper layer protocols
 Here, the UDP header is only used if a NAT has been detected between
 the mobile node and the home agent, or if the home agent forced UDP
 encapsulation.  V4CoA is the IPv4 care-of address configured by the
 mobile node in the visited network.
 Similarly, IPv4 packets are sent according to the following format:
    IPv4 header (src=V4CoA, dst=HA_V4ADDR)
    [UDP header]
    IPv4 header (src=V4HoA, dst=V4CN)
    Upper Layer protocols

Soliman Standards Track [Page 25] RFC 5555 DSMIPv6 June 2009

 Here, the UDP header is only used if a NAT has been detected between
 the mobile node and the home agent, or if the home agent forced UDP
 encapsulation.

4.4.4. Movement Detection in IPv4-Only Networks

 [RFC3775] describes movement detection mostly based on IPv6-specific
 triggers and Neighbor Discovery [RFC4861] information.  These
 triggers are not available in an IPv4-only network.  Hence, a mobile
 node located in an IPv4-only network SHOULD use [RFC4436] for
 guidance on movement-detection mechanisms in IPv4-only networks.
 The mobile node detects that it's in an IPv4-only network when the
 IPv6 movement-detection algorithm fails to configure an IPv6 address.
 This specification does not support mobile nodes returning home while
 using IPv4.  That is, the IPv4 support is only defined for mobile
 nodes that are in a visited network.

4.5. Home Agent Operation

 In addition to the home agent specification in [RFC3775] and
 [RFC3963], the home agent needs to be able to process the IPv4 home
 address option and generate the IPv4 address acknowledgement option.
 Both options are included in the mobility header.  Furthermore, the
 home agent MUST be able to detect the presence of a NAT device and
 indicate that presence in the NAT detection option included in the
 binding acknowledgement.
 A home agent must also act as a proxy for address resolution in IPv4
 for the registered IPv4 home addresses of mobile nodes it is serving.
 Moreover, the administrative domain of the home agent is responsible
 for advertising the routing information of registered IPv4 mobile-
 network prefixes of the mobile nodes.
 In order to comply with this specification, the home agent MUST be
 able to find the IPv4 home address of a mobile node when given the
 IPv6 home address.  That is, given an IPv6 home address, the home
 agent MUST store the corresponding IPv4 home address if a static one
 is present.  If a dynamic address is requested by the mobile node,
 the home agent MUST store that address (associated with the IPv6 home
 address) after it's allocated to the mobile node.
 When the home agent receives a binding update encapsulated in UDP and
 containing the IPv4 home address option, it needs to follow all the
 steps in [RFC3775] and [RFC3963].  In addition, the following checks
 MUST be done:

Soliman Standards Track [Page 26] RFC 5555 DSMIPv6 June 2009

 o  If the IPv4 care-of address in the IPv4 CoA option is not the same
    as the IPv4 address in the source address in the IPv4 header, then
    a NAT was in the path.  This information should be flagged for the
    binding acknowledgement.
 o  If the F flag in the binding update is set, the home agent needs
    to determine whether it accepts forcing UDP encapsulation.  If it
    does not, the binding acknowledgement is sent with error code 144.
    UDP encapsulation SHOULD NOT be used when the mobile node is
    located in an IPv6-enabled link, with the exception of the
    scenarios outlined in Section 4.4.1.
 o  If the IPv4 home address option contains a valid unicast IPv4
    address, the home agent MUST check that this address is allocated
    to the mobile node that has the IPv6 home address included in the
    home address option.  The same MUST be done for an IPv4 prefix.
 o  If the IPv4 home address option contained the unspecified IPv4
    address, the home agent SHOULD dynamically allocate an IPv4 home
    address to the mobile node.  If none is available, the home agent
    MUST return error code 132 in the status field of the IPv4 address
    acknowledgement option.  If a prefix is requested, the home agent
    SHOULD allocate a prefix with the requested length; if prefix
    allocation (of any length) is not possible, the home agent MUST
    indicate failure of the operation with the appropriate error code.
 o  If the binding update is accepted for the IPv4 home address, the
    home agent creates a binding cache entry for the IPv4 home
    address/prefix.  The home agent MUST include an IPv4
    acknowledgement option in the mobility header containing the
    binding acknowledgement.
 o  If the binding update is accepted for both IPv4 and IPv6 home
    addresses, the home agent creates separate binding cache entries,
    one for each home address.  The care-of address is the one
    included in the binding update.  If the care-of address is an IPv4
    address, the home agent MUST set up a tunnel to the IPv4 care-of
    address of the mobile node.
 When sending a binding acknowledgement to the mobile node, the home
 agent constructs the message according to [RFC3775] and [RFC3963].
 Note that the routing header MUST always contain the IPv6 home
 address as specified in [RFC3775].
 If the care-of address of the mobile node is an IPv4 address, the
 home agent includes the mobile node's IPv6 home address in the
 destination address field in the IPv6 header.  If a NAT is detected,
 the home agent MUST then encapsulate the packet in UDP and in an IPv4

Soliman Standards Track [Page 27] RFC 5555 DSMIPv6 June 2009

 header.  The source address is set to the home agent's IPv4 address
 and the destination address is set to the address received in the
 source address of the IPv4 header encapsulating the binding update.
 After creating a binding cache entry for the mobile node's home
 addresses, all packets sent to the mobile node's home addresses are
 tunneled by the home agent to the mobile node's care-of address.  If
 a NAT is detected, packets are encapsulated in UDP and IPv4.
 Otherwise, if the care-of address is an IPv4 address and no NAT is
 detected, packets are encapsulated in an IPv4 header unless UDP
 encapsulation is forced by the home agent.

4.5.1. Sending Packets to the Mobile Node

 The home agent follows the rules specified in [RFC3775] for sending
 IPv6 packets to mobile nodes located in IPv6 networks.  When sending
 IPv4 packets to mobile nodes in an IPv6 network, the home agent must
 encapsulate the IPv4 packets in IPv6.
 When sending IPv6 packets to a mobile node located in an IPv4
 network, the home agent uses the following format:
    IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
    [UDP header]
    IPv6 header (src=CN, dst= V6HoA)
    Upper layer protocols
 Where the UDP header is only included if a NAT is detected between
 the mobile node and the home agent or if the home agent forced UDP
 encapsulation.  V4ADDR is the IPv4 address received in the source
 address field of the IPv4 packet containing the binding update.
 When sending IPv4 packets to a mobile node located in an IPv4
 network, the home agent must follow the format negotiated in the
 binding update/acknowledgement exchange.  In the absence of a
 negotiated format, the default format that MUST be supported by all
 implementations is:
    IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
    [UDP header]
    IPv4 header (src=V4CN, dst= V4HoA)
    Upper layer protocols

Soliman Standards Track [Page 28] RFC 5555 DSMIPv6 June 2009

 Where the UDP header is only included if a NAT is detected between
 the mobile node and home agent or if the home agent forced UDP
 encapsulation.

4.6. Correspondent Node Operation

 This specification has no impact on IPv4 or IPv6 correspondent nodes.

5. Security Considerations

 This specification allows a mobile node to send one binding update
 for its IPv6 and IPv4 home addresses.  This is a slight deviation
 from [RFC3775], which requires one binding update per home address.
 However, like [RFC3775], the IPsec security association needed to
 authenticate the binding update is still based on the mobile node's
 IPv6 home address.  Therefore, in order to authorize the mobile
 node's IPv4 home address binding, the home agent MUST store the IPv4
 address corresponding to the IPv6 address that is allocated to a
 mobile node.  Therefore, it is sufficient for the home agent to know
 that the IPsec verification for the packet containing the binding
 update was valid, provided that it knows which IPv4 home address is
 associated with which IPv6 home address.  Hence, the security of the
 IPv4 home address binding is the same as the IPv6 binding.
 In effect, associating the mobile node's IPv4 home address with its
 IPv6 home address moves the authorization of the binding update for
 the IPv4 address to the Mobile IPv6 implementation, which infers it
 from the fact that the mobile node has an IPv6 home address and the
 right credentials for sending an authentic binding update for the
 IPv6 address.
 This specification requires the use of IKEv2 as the default mechanism
 for dynamic keying.
 In cases where this specification is used for NAT traversal, it is
 important to note that it has the same vulnerabilities associated
 with [RFC3519].  An attacker is able to hijack the mobile node's
 session with the home agent if it can modify the contents of the
 outer IPv4 header.  The contents of the header are not authenticated
 and there is no way for the home agent to verify their validity.
 Hence, a man in the middle attack, where a change in the contents of
 the IPv4 header can cause a legitimate mobile node's traffic to be
 diverted to an illegitimate receiver independently of the
 authenticity of the binding update message, is possible.
 In this specification, the binding update message MUST be protected
 using ESP transport mode.  When the mobile node is located in an
 IPv4-only network, the binding update message is encapsulated in UDP

Soliman Standards Track [Page 29] RFC 5555 DSMIPv6 June 2009

 as described earlier in Section 4.2.  However, UDP SHOULD NOT be used
 to encapsulate the binding update message when the mobile node is
 located in an IPv6-enabled network.  If protection of payload traffic
 is needed when the mobile node is located in an IPv4-only network,
 encapsulation is done using tunnel mode ESP over port 4500 as
 described in [RFC3948].  During the IKE negotiation with the home
 agent, if the mobile node and home agent support the use of port
 4500, the mobile node MUST establish the security association over
 port 4500, regardless of the presence of a NAT.  This is done to
 avoid switching between ports 500 and 4500 and the potential traffic
 disruption resulting from this switch.
 Handovers within private IPv4 networks or from IPv6 to IPv4 networks
 will impact the security association between the mobile node and the
 home agent.  The following section presents the expected behaviour of
 the mobile node and home agent in those situations.  The details of
 the IKE negotiations and messages are illustrated in Section 5.2.

5.1. Handover Interactions for IPsec and IKE

 After the mobile node detects movement, it configures a new care-of
 address.  If the mobile node is in an IPv4-only network, it removes
 binding update list entries for correspondent nodes, since route
 optimisation cannot be supported.  This may cause inbound packet
 losses, as remote correspondent nodes are unaware of such movement.
 To avoid confusion in the correspondent node, the mobile node SHOULD
 deregister its binding with each correspondent node by sending a
 deregistration binding update.  The deregistration binding update
 message is tunnelled to the home agent and onto the correspondent
 node.  This is done after the mobile node updates the home agent with
 its new location as discussed below.
 The mobile node sends the binding update message to the home agent.
 If the mobile node is in an IPv6-enabled network, the binding update
 SHOULD be sent without IPv4/UDP encapsulation, unless UDP
 encapsulation is needed as described in Section 4.4.1.  If the mobile
 node is in an IPv4-only network, then -- after IPsec processing of
 the binding update (BU) message -- it encapsulates the BU in UDP/IPv4
 as discussed in Sections 4.2 and 4.4.  In order to be able to send
 the binding update while in an IPv4-only network, the mobile node
 needs to use the new IPv4 care-of address in the outer header, which
 is different from the care-of address used in the existing tunnel.
 This should be done without permanently updating the tunnel within
 the mobile node's implementation in order to allow the mobile node to
 receive packets on the old care-of address until the binding
 acknowledgement is received.  The method used to achieve this effect
 is implementation dependent and is outside the scope of this
 specification.  This implies that the IP forwarding function (which

Soliman Standards Track [Page 30] RFC 5555 DSMIPv6 June 2009

 selects the interface or tunnel through which a packet is sent) is
 not based solely on the destination address: some IPv6 packets
 destined to the home agent are sent via the existing tunnel, while
 BUs are sent using the new care-of address.  Since BUs are protected
 by IPsec, the forwarding function cannot necessarily determine the
 correct treatment from the packet headers.  Thus, the DSMIPv6
 implementation has to attach additional information to BUs, and this
 information has to be preserved after IPsec processing and made
 available to the forwarding function or to DSMIP extensions included
 in the forwarding function.  Depending on the mobile node's
 implementation, meeting this requirement may require changes to the
 IPsec implementation.
 Upon receiving the binding update message encapsulated in UDP/IPv4,
 the home agent processes it as follows.  In order to allow the
 DSMIPv6 implementation in the home agent to detect the presence of a
 NAT on the path to the mobile node, it needs to compare the outer
 IPv4 source address with the IPv4 address in the IPv4 care-of address
 option.  This implies that the information in the outer header will
 be preserved after IPsec processing and made available to the DSMIPv6
 implementation in the home agent.  Depending on the home agent's
 implementation, meeting this requirement may require changes to the
 IPsec implementation.
 The home agent updates its tunnel mode security association to
 include the mobile node's care-of address as the remote-tunnel header
 address and 4500 as the port number.  The IPv4 address and port
 number are likely to be wrong; the mobile node provides the correct
 information in a separate exchange as described below.  When the
 mobile node is located in a private IPv4 network (which is detected
 as described above), the new address and port number are allocated by
 the NAT.  The home agent will also enable or disable UDP
 encapsulation for outgoing ESP packets for the purpose of NAT
 traversal.
 If the Key Management Mobility Capability (K) bit was set in the
 binding update, and the home agent supports this feature, the home
 agent updates its IKE security associations to include the mobile
 node's care-of address as the peer address and 4500 as the port
 number.  The home agent may also need to change NAT traversal fields
 in the IKE_SA to enable the dynamic update of the IP address and port
 number, based on the reception of authenticated IKE messages or
 authenticated packets using tunnel mode ESP.  The dynamic updates are
 described in Section 2.23 of [RFC4306].  As described above, when the
 mobile node is located in a private IPv4 network, the address and
 port number used for IPsec and IKE traffic is not yet known by the
 home agent at this point.

Soliman Standards Track [Page 31] RFC 5555 DSMIPv6 June 2009

 The mobile node updates the IKE SA in one of two ways.  If the K flag
 was set in the binding acknowledgement message, the mobile node
 SHOULD send an empty informational message, which results in the IKE
 module in the home agent dynamically updating the SA information.
 The IKE implementation in the home agent is REQUIRED to support this
 feature.  Alternatively, the IKE SA should be re-negotiated.  Note
 that updating the IKE SA MUST take place after the mobile node has
 sent the binding update and received the acknowledgement from the
 home agent.
 It is important to note that the mobile node's IPv4 care-of address
 seen by the DSMIPv6 module in the home agent upon receiving the
 binding update may differ from the IPv4 care-of address seen by the
 IKE module and the care-of address used for forwarding IPsec tunnel
 mode traffic.  Hence, it is probable that different modules in the
 home agent will have a different care-of address that should be used
 for encapsulating traffic to the mobile node.
 After successfully processing the binding update, the home agent
 sends the binding acknowledgement to the mobile node's care-of
 address as received in the outer header of the packet containing the
 binding update.  Note that if the BU was rejected, the binding
 acknowledgement (BAck) is sent to the same address from which the BU
 was received.  This may require special treatment in IP forwarding
 and/or IPsec processing that resembles the sending of BUs in the
 mobile node (described above).
 Upon receiving the binding acknowledgement, the mobile node updates
 its local tunnel mode security association information to include the
 tunnel header IP source address, which is the mobile node's address,
 and the tunnel header IP destination, which is the home agent's
 address.  The mobile node may also need to enable or disable UDP
 encapsulation for outgoing ESP packets for the purpose of NAT
 traversal and the sending of keepalives.
 The mobile node MAY use MOBIKE [RFC4555] to update its IKE SA with
 the home agent.  Using MOBIKE requires negotiating this capability
 with the home agent when establishing the SA.  In this case, the
 mobile node and the home agent MUST NOT update their IPsec SAs
 locally, as this step is performed by MOBIKE.  Furthermore, the use
 of MOBIKE allows the mobile node to update the SA independently of
 the binding update exchange.  Hence, there is no need for the mobile
 node to wait for a binding acknowledgement before performing MOBIKE.
 The use of MOBIKE is OPTIONAL in this specification.

Soliman Standards Track [Page 32] RFC 5555 DSMIPv6 June 2009

5.2. IKE Negotiation Messages between the Mobile Node and Home Agent

 This specification defines a number of possible data encapsulation
 formats, depending on the mobile node's connectivity to the visited
 network.  When connected to an IPv6-enabled network, the tunnelling
 formats are clear.  However, when connected to an IPv4-only network,
 care should be taken when negotiating the IKE association and the
 consequential tunnelling formats used for secure and insecure
 traffic.  This section illustrates the IKE message exchange between
 the mobile node and home agent when the mobile node is located in an
 IPv4-only network.  Two different IKE negotiations are considered:
 o  IKEv2 operation for securing DSMIPv6 signaling.
 o  IKEv2 operation for securing data over IPv4

5.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling

 A mobile node connected to an IPv4-only network SHOULD follow the
 procedures described below in order to establish an SA for the
 protection of binding update and binding acknowledgement messages.
 Note that V4ADDR refers to either the mobile node's care-of address
 in the visited link or the public address allocated to the mobile
 node by the NAT.
 Mobile Node                                      Home Agent
 -----------                                      ----------
 IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
  UDP (500, 500) HDR, SAi1, KEi, Ni
   NAT-D, NAT-D -->
                    <- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
                             UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ]
                              NAT-D, NAT-D
 IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
   UDP (4500,4500) <non-ESP Marker > HDR, SK
   {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE),
   SAi2, TSi, TSr}
  -->
                    <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
                            UDP (4500,Y) <non-ESP Marker > HDR, SK
                            {IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE),
                            SAr2, TSi, TSr}

Soliman Standards Track [Page 33] RFC 5555 DSMIPv6 June 2009

 The corresponding Security Policy Database (SPD) entries are shown
 below.
 Mobile node SPD-S:
    IF local_address = home_address_1 &
       remote_address = home_agent_1 &
       proto = MH & local_mh_type = BU &
       remote_mh_type = BAck
   Then use SA ESP transport mode
   Initiate using IDi = user_1 to address home_agent_1
 Home Agent SPD-S:
    IF local_address = home_agent_1 &
       remote_address = home_address_1 &
       proto = MH &
       local_mh_type = BAck &
       remote_mh_type = BU
    Then use SA ESP transport mode
 Where home_address_1 is the mobile node's registered IPv6 home
 address and home_agent_1 is the IP address of the home agent.
 The above should result in BU/BA messages with the following BU
 received by the home agent:
    IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
    UDP header (sport=Z, dport=DSMIPv6)
    IPv6 header (src=V6HOA, dst=HAADDR)
    ESP header in transport mode
    Mobility header
    BU [IPv4 HAO]

Soliman Standards Track [Page 34] RFC 5555 DSMIPv6 June 2009

    IPv4 CoA option
    (and others as needed)
 At the home agent, following UDP de-capsulation, the binding update
 is delivered to the IPsec module as shown below:
    IPv6 header (src=V6HOA, dst=HAADDR)
    ESP header in transport mode
    Mobility header
    BU [IPv4 HAO]
    IPv4 CoA option
    (and others as needed)
 In addition, V4ADDR and the sport (Z) need to be passed with the
 packet to ensure correct processing.
 Following IPsec processing, the binding update is delivered to the
 DSMIPv6 home agent module as follows:
    IPv6 header (src=V6HOA, dst=HAADDR)
    Mobility header
    BU [IPv4 HAO]
    IPv4 CoA option
    (and others as needed)
 In addition, V4ADDR and the sport (Z) need to be passed with the
 packet to ensure correct processing.
 The binding acknowledgement sent by the home agent module to the
 IPsec module is as follows:
    IPv6 header (src=HAADDR, dst=V6HOA)
    Mobility header
    BA ([IPv4 ACK], NAT DET)
    (and others as needed)

Soliman Standards Track [Page 35] RFC 5555 DSMIPv6 June 2009

 In addition, V4ADDR, the sport from the BU (Z), and an indication
 that UDP encapsulation must be used need to be passed with the packet
 to ensure correct processing.
 The binding acknowledgement sent by the home agent to the mobile node
 is as follows:
    IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
    UDP header (sport=DSMIPv6, dport=Z)
    IPv6 header (src=HAADDR, dst=V6HOA)
    ESP header in transport mode
    Mobility header
    BA ([IPv4 ACK], NAT DET)

5.2.2. IKEv2 Operation for Securing Data over IPv4

 To secure data traffic when the mobile node is located in an IPv4-
 only network, the mobile node MUST establish a child_SA for that
 purpose.  Note that V4ADDR refers to either the mobile node's care-of
 address in the visited link or the public address allocated to the
 mobile node by the NAT.  The procedure is as follows:
 Mobile Node                                     Home Agent
 -----------                                     ----------
 IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
  UDP (4500,4500) < non-ESP Marker > HDR, SK
   {[N], SA, Ni, [KEi], TSi, TSr}    -->
                      <--IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
                             UDP (4500,Y) < non-ESP Marker > HDR, SK
                              SA, Nr, [KEr], TSi, TSr}
 If no NAT is detected, the encapsulation used will be:
    IPv4 (source_addr=v4CoA, dest_addr=HAAddr)
    ESP
    IP (source_addr=HoA, set_addr=CNAddr)
    Upper_layer_HDR

Soliman Standards Track [Page 36] RFC 5555 DSMIPv6 June 2009

 Where IP is either IPv4 or IPv6 and HoA is either the IPv4 HoA or the
 IPv6 HoA.
 If a NAT is detected, the encapsulation used will be:
    IPv4 (source_addr=v4Addr, dest_addr=HAAddr)
    UDP (sport=Y, dport=4500)
    ESP
    IP (source_addr=HoA, set_addr=CNAddr)
    Upper_layer_HDR
 Where v4CoA may be the external IPv4 address of the NAT, IP is either
 an IPv4 or IPv6 header, and HoA is either the IPv4 or the IPv6 HoA.
 The above format shows the packet as seen by the home agent.
 The SPD, whether a NAT is detected or not, is set as follows.  Note
 that this rule is designed to match all data from the MN to nodes
 other than the home agent.  This is done so that this rule does not
 overlap with the earlier rule securing BU/BA signaling between the MN
 and the HA.
 Mobile Node SPD-S:
    IF local_address = home_address &
       remote_address != home_agent &
       proto=any
    Then use SA ESP tunnel mode
    Initiate using IDi = user_1 to address home_agent_1
 home agent SPD-S:
    IF local_address != home_agent &
       remote_address = home_address &
       proto=any
    Then use SA ESP tunnel mode

Soliman Standards Track [Page 37] RFC 5555 DSMIPv6 June 2009

 Where home_address is the MN's registered IPv6 or IPv4 home address
 and home_agent is the IPv6 or the IPv4 address of the home agent.

6. Protocol Constants

    NATKATIMEOUT = 110 seconds.

7. Acknowledgements

 Thanks to the following members (in alphabetical order) of the MIP6
 and NEMO Working Groups for their contributions, discussions, and
 reviews: Jari Arkko, Sri Gundavelli, Wassim Haddad, Alfred Hoenes,
 Conny Larsson, Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen
 Nielsen, and Keiichi Shima.  Thanks to Karen Nielsen, Pasi Eronen,
 and Christian Kaas-Petersen for raising the issue of IKEv2
 interactions and proposing the solution included in this document.
 Thanks to Pasi Eronen for many thorough reviews of this document.

8. IANA Considerations

 IANA has made the following allocations according to this
 specification:
    A UDP port (4191) has been assigned for the NAT traversal
    mechanism described in Section 4.2.
    The IPv4 home address option described in Section 3.1.1 has been
    assigned value 29.  This option is included in the mobility header
    described in [RFC3775].
    The IPv4 address acknowledgement option described in Section 3.2.1
    has been assigned value 29.  This option is included in the
    mobility header described in [RFC3775].
    The NAT detection option described in Section 3.2.2 has been
    assigned a value 31.  This option is included in the mobility
    header described in [RFC3775].
    The IPv4 care-of address option described in Section 3.1.2 has
    been assigned value 32.  This option is included in the mobility
    header described in [RFC3775].
 The status field in the IPv4 home address option has been allocated
 by IANA under the new registry: "DSMIPv6 IPv4 Home Address Option
 Status Codes".

Soliman Standards Track [Page 38] RFC 5555 DSMIPv6 June 2009

 The status field values are allocated using the following procedure:
 1. New status field values are allocated through IETF review.  This
    is for all RFC types including standards track, informational, and
    experimental status that originate from the IETF and have been
    approved by the IESG for publication.
 2. Requests for new option type value assignments from outside the
    IETF are only made through the publication of an IETF document,
    per 1 above.  Note also that documents published as Independent
    "RFC Editor contributions" [RFC4844] are not considered to be IETF
    documents.

9. References

9.1. Normative References

 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2473]   Conta, A. and S. Deering, "Generic Packet Tunneling in
             IPv6 Specification", RFC 2473, December 1998.
 [RFC3168]   Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
             of Explicit Congestion Notification (ECN) to IP", RFC
             3168, September 2001.
 [RFC3775]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
             in IPv6", RFC 3775, June 2004.
 [RFC3948]   Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
             Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
             3948, January 2005.
 [RFC3963]   Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
             Thubert, "Network Mobility (NEMO) Basic Support
             Protocol", RFC 3963, January 2005.
 [RFC4306]   Kaufman, C., Ed., "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.
 [RFC4555]   Eronen, P., "IKEv2 Mobility and Multihoming Protocol
             (MOBIKE)", RFC 4555, June 2006.

Soliman Standards Track [Page 39] RFC 5555 DSMIPv6 June 2009

 [RFC4861]   Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
             "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
             September 2007.
 [RFC4877]   Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation
             with IKEv2 and the Revised IPsec Architecture", RFC 4877,
             April 2007.
 [RFC5026]   Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed.,
             "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026,
             October 2007.

9.2. Informative References

 [CHOWDHURY] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
             Integrated Scenario", Work in Progress, April 2008.
 [RFC2983]   Black, D., "Differentiated Services and Tunnels", RFC
             2983, October 2000.
 [RFC3344]   Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
             3344, August 2002.
 [RFC3519]   Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
             Network Address Translation (NAT) Devices", RFC 3519,
             April 2003.
 [RFC4459]   Savola, P., "MTU and Fragmentation Issues with In-the-
             Network Tunneling", RFC 4459, April 2006.
 [RFC4844]   Daigle, L., Ed., and Internet Architecture Board, "The
             RFC Series and RFC Editor", RFC 4844, July 2007.
 [RFC4977]   Tsirtsis, G. and H. Soliman, "Problem Statement: Dual
             Stack Mobility", RFC 4977, August 2007.
 [RFC5380]   Soliman, H., Castelluccia, C., ElMalki, K., and L.
             Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
             Management", RFC 5380, October 2008.
 [RFC5389]   Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
             "Session Traversal Utilities for NAT (STUN)", RFC 5389,
             October 2008.
 [RFC5405]   Eggert, L. and G. Fairhurst, "Unicast UDP Usage
             Guidelines for Application Designers", BCP 145, RFC 5405,
             November 2008.

Soliman Standards Track [Page 40] RFC 5555 DSMIPv6 June 2009

10. Contributors

 This document reflects discussions and contributions from several
 people including (in alphabetical order):
    Vijay Devarapalli: vijay.devarapalli@azairenet.com
    James Kempf: kempf@docomolabs-usa.com
    Henrik Levkowetz: henrik@levkowetz.com
    Pascal Thubert: pthubert@cisco.com
    George Tsirtsis: G.Tsirtsis@Qualcomm.com
    Ryuji Wakikawa: ryuji@sfc.wide.ad.jp

Author's Address

 Hesham Soliman (editor)
 Elevate Technologies
 EMail: hesham@elevatemobile.com

Soliman Standards Track [Page 41]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5555.txt · Last modified: 2009/06/09 22:18 (external edit)