Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-06.txt

From: [email-masked]
Date: Mon, 3 Nov 2008 07:30:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : Mobile IPv6 Support for Dual Stack Hosts and Routers
	Author(s)       : H. Soliman
	Filename        : draft-ietf-mext-nemo-v4traversal-06.txt
	Pages           : 50
	Date            : 2008-11-03

The current Mobile IPv6 and 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 04 Nov 2008 21:54:53 +0100

Hi,

Sorry for the late review. Some comments inline. Some questions too.

[email-masked] writes:

> 2.1.  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 Mobile IPv6 only for dual
>    stack mobile nodes in order to allow for a long lasting mobility
>    solution and minimize the need to changing the mobility stack due to
>    the introduction of IPv6 within a deployed network.

Perhaps it is just my english, but I fail to understand last paragraph.

> 3.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 (AH or ESP) and based on
>    the mobile node's IPv4 care-of address as described in [RFC3775].
>    Since the mobile node needs to encapsulate all IPv6 traffic sent to
>    the home agent into IPv4 while located in an IPv4-only visited
>    network, this SA would match all packets if the selectors were based
>    on the information in the outer header.  That is, the SA selectors
>    being the protocol number (protocol is always IP in IP), as well as,
>    source and destination addresses are all common to all packets.

Possibly me but last sentence seems incorrect. If not, what is its
meaning?

>    If
>    this effect is not desired, the mobile node can base the SA on the
>    information in the inner header (i.e., using the home agent's IPv6
>    address, the mobile node's home address and the ICMP protocol
>    number).  This security association would use transport mode ESP
>    protection.

Not clear, IMHO.

> 3.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
>    addresses, the home agent will tunnel it in IPv6 to the mobile node's
>    IPv6 care-of address 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, the only addition to [RFC3775] is the inclusion of
>    the IPv4 home address option in the binding update message.
>
>    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 later in this specification.  This
>    option 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 it MIPv6 its binding.

Last sentence seems incorrect.

> 4.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
>
>       TBD
>
>    Length
>
>       6
>
>    Reserved
>
>       This field is set to zero by the sender and ignored by the
>       receiver.
>
>
>
>
> Soliman                    Expires May 7, 2009                 [Page 15]
> 
> Internet-Draft                   dsmipv6                   November 2008
>
>
>    IPv4 Care-of Address
>
>       This field contains the mobile node's IPv4 care- of address.  The

                                                   care-of

> 5.2.  NAT Detection
>
>    This section deals with NAT detection for the purpose of
>    encapsulating packets between the mobile node and the home agent.
>    Mobile IPv6 uses IKEv2 to establish te IPsec security association
>    between the mobile node and the home agent.

IKE is not mandatory, it is only optional. Or did I missed a reference
document?

What about 'may use IKE ...'

>    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 6
>
>    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 device 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
>    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.

What if filtering somewhere prevents IP over IP but is fine with UDP
encapsulated traffic. If the HA decides to go for IP over IP (i.e. does
not force the F flag), this will not work.

> 5.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 may take place
>    during early deployments of IPv6, or simply due to temporary outages
>    affecting IPv6 routing.
>
>    It is RECOMMENDED that upon movement the mobile node does 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'
>    performace 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 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 these address selection mechanism is to allow the
>    follwing preferences:

     following

> 6.  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.

ok.

>    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.
>
>    In this specification, the binding update message MUST be protected
>    using ESP transport mode.

Just to be sure: IP / UDP / IPv6 / ESP / MH ?

>     When the mobile node is located in an
>    IPv4-only network, the binding update message is encapsulated in UDP
>    as described earlier.  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 the switching between ports 500 and 4500 and the potential
>    traffic disruption resulting from this switch.

Is this summary correct for a MIPv6 MN that uses IPsec for both
signaling and data (payload) on an IPv4 network:

- signaling: IP / UDP / IPv6 / ESP / MH
- data: IP / UDP / ESP / IPv6 / L4

> 6.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
>    is sent without IPv4/UDP encapsulation.  If the mobile node is in an
>    IPv4-only network, then after IPsec processing of the BU message, it
>    encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.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 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
>    additional DSMIP processing added to 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,

                                                               IPv4/UDP

>    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.

How?

>    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

Following standard IKE procedure (i.e. 2.23 of RFC 4306) or is something
else expected?

>    authenticated packets using tunnel mode ESP.

How?

>    The dynamic updates are described in section 2.23 of RFC 4306.

For IKE, yes. For other cases, it is not.

>    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.
>
>    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,

How does the MIPv6 modules manages to tell the IKE module to do that?

>     which results in the IKE
>    module in the home agent to dynamically update the SA information.
>    The IKE implementation in the home agent is REQUIRED to support this
>    feature.

You mean on the MN, the HA or both?

>    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.

What does last sentence means?

>    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 BAck is sent
>    to the same address where the BU was received from.  This may require
>    special treatment in IP forwarding and/or IPsec processing which
>    resembles 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 keep alives.

How? 

>    The mobile node MAY use [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.

How IKE module and MIPv6 do synchronize on which address to use? More
precisely, how is MIPv6 module expected to tell IKE implementation to
use the correct address for update in MOBIKE context. 

> 6.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
>
> 6.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.
>
>    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}
>
>
>    The corresponding 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

Maybe it is a dumb question: How will the IKE daemon know how to contact
the HA (i mean decide to use V4ADDR as source and HAADDR as
destination)?

>    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]
>
>       IPv4 CoA option
>
>       (+ other 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
>
>       (+other 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
>
>       (+other 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)
>
>       (+ other as needed)
>
>    In addition, V4ADDR, the sport from the BU (Z), and an indication
>    that vanilla 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)
>
> 6.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.  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
>
>       where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA
>
>    If a NAT were 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 were 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
>
>    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.

Cheers,

a+