[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                         A. Ebalard
Internet-Draft                                                      EADS
Intended status: Informational                        September 30, 2010
Expires: April 3, 2011

                     MIPv6 from IPv4-only networks


   MIPv6 [RFC3775] protocol has been designed to work on IPv6 networks:
   nothing was initially provisioned in the specification to support
   movement of Mobile Nodes to IPv4-only networks (with or without NAT)
   or the communication with IPv4 peers.

   DSMIPv6 [RFC5555] is the official solution specified to address those
   needs.  It requires IPv4/NAT-awareness by the MIPv6 module, IKE
   module and IPsec stack.  The global approach selected by DSMIPv6
   requires changes to implementations and increases complexity.

   This memo presents an alternative approach to support operations of
   MIPv6 mobile nodes from IPv4-only networks.  It does not require
   changes to MIPv6 modules, IKE module and IPsec stack.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 3, 2011.

Copyright Notice

   Copyright (c) 2010 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

Ebalard                   Expires April 3, 2011                 [Page 1]

Internet-Draft                     m6t                    September 2010

   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Initial thoughts . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problems and solutions . . . . . . . . . . . . . . . . . . . .  4
     2.1.  UDP port to use on the tunnel GW . . . . . . . . . . . . .  4
     2.2.  MN's CoA on the tunnel interface . . . . . . . . . . . . .  5
     2.3.  Maintaining NAT states . . . . . . . . . . . . . . . . . .  6
     2.4.  Route management on the tunnel GW  . . . . . . . . . . . .  6
     2.5.  Multiple tunnel interfaces on a MN . . . . . . . . . . . .  7
     2.6.  MTU considerations . . . . . . . . . . . . . . . . . . . .  7
     2.7.  Miscellanous . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Protocol operations  . . . . . . . . . . . . . . . . . . . . .  8
   4.  Interactions with MIPv6  . . . . . . . . . . . . . . . . . . .  9
   5.  Pros and cons  . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
     6.1.  Preventing DoS . . . . . . . . . . . . . . . . . . . . . . 10
       6.1.1.  Against the MN . . . . . . . . . . . . . . . . . . . . 10
       6.1.2.  Against the HA . . . . . . . . . . . . . . . . . . . . 11
       6.1.3.  Against the GW . . . . . . . . . . . . . . . . . . . . 11
       6.1.4.  Against the Infrastructure . . . . . . . . . . . . . . 12
   7.  Implementation . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13

Ebalard                   Expires April 3, 2011                 [Page 2]

Internet-Draft                     m6t                    September 2010

1.  Introduction

1.1.  Initial thoughts

   MIPv6 [RFC3775] protocol has been designed to work on IPv6 networks:
   nothing was initially provisioned in the specification to support
   movement of Mobile Nodes to IPv4-only networks (with or without NAT)
   or the communication with IPv4 peers.

   In order to address the need to support those use cases, DSMIPv6
   [RFC5555] has been published: it provides a global solution to
   support the movement of mobile nodes to IPv4-only networks with and
   without NAT and their communication with IPv4 peers via the Home
   Agent.  The use of DSMIPv6 inhibits Route Optimization mechanism.

   The approach selected by DSMIPv6 is to implement IPv4 and NAT
   awareness in MIPv6, IPsec and IKE componenst on the MN and its HA.
   Even if this probably has advantages (efficient on-wire format), this
   IPv4/NAT-awareness also adds a lot of complexity to the MIPv6 process
   and in its relationships with IPsec and IKE.

   Considering the initial problems at hand:

   1.  Supporting the use of MIPv6 for MN stuck in IPv4-only networks.
   2.  Supporting the communication of MIPv6 MN with IPv4 peers.

   the following separate approaches are possible:

   1.  Use of a simple tunnel (over IPv4/UDP) between the MN and its HA
   2.  Use of NAT64 mechanism in the Home Network.  Other different
       solutions may be more suitable.

   This document tries and address the first problem by covering the
   first approach.

1.2.  Rationale

   MIPv6 works fine when IPv6 connectivity is available because its
   logic remains quite simple.  The absence of NAT on IPv6 networks
   (i.e. flat routing) has made it possible to greatly simplify the
   protocol and its deployment, compared to MIPv4.

   IPsec and IKE have seen limited deployment in IPv4 networks (in favor
   of TLS) partly due to the difficulty or inability to use them in
   ubiquitous NAT environments.  When IPv6 connectivity is available,
   IPsec and IKE work and interoperate easily.  The interactions with
   MIPv6 in order to secure the operation of the protocol are quite
   simple (see [MIGRATE]).

Ebalard                   Expires April 3, 2011                 [Page 3]

Internet-Draft                     m6t                    September 2010

   Basically, if it is possible to mask the existence of IPv4 and NAT to
   MIPv6, IPsec and IKE, it may be possible to allow its use from IPv4-
   only networks without invasive and costly changes in the
   implementation.  This is what m6t protocol aims at.

   Additionally, the rationale for this work also results from:

   o  Considerations on the limited set of flows associated with MIPv6
      protocol: when RO is not used, MN's traffic always go via the HA.
   o  The use of Teredo by the author on IPv4 networks as an alternative
      solution to DSMIPv6 (due to its unavailability on most platform).
   o  Considerations on the architectural requirements and drawbacks of
      Teredo (qualification procedure, reliance on Teredo servers, MTU
      considerations, ...) in the specific context of a MIPv6 MN.

2.  Problems and solutions

   As discussed above, the idea is to provide IPv6 connectivity via a
   simple tunnel over IPv4 and UDP to the HA.  On the MN, the tunnel
   interface hides the existence of IPv4/NAT and makes it possible to
   operate MIPv6 in a transparent fashion.  On a gateway in front of the
   HA (or on the HA), this provides the same benefit.  Nonetheless,
   creating, using and maintaining this tunnel both on the MN and the
   gateway in front of the HA requires some care.  Problems and selected
   solutions are discussed below.

2.1.  UDP port to use on the tunnel GW

   For a given deployment, clients of the tunnel gateway (MN or MR) need
   to access it on a known port.  In some environments, it may be
   beneficial for admins to be able to select that specific port.  For
   that reason, it does not seems worth asking IANA to allocate a
   dedicated port for that purpose.

   Basically, the tunnel mechanism described in this memo is a custom
   version (MIPv6-oriented) of what STUN [RFC5389] or Teredo [RFC4380]
   provide.  As the tunnel GW is a closed service dedicated to the MN,
   it may be possible to have the GW listen on STUN or Teredo ports
   (respectively 3478/udp and 3544/udp).

   As filtering may be in place in the IPv4 networks the MN found
   themselves, it could be possible to use a destination port associated
   with a protocol which is usually authorized, like 4500/udp, 500/udp
   or 53/udp.

   As the choice of the specific ports to be used for a given MN
   community highly depends on the habits of the MN and the foreign

Ebalard                   Expires April 3, 2011                 [Page 4]

Internet-Draft                     m6t                    September 2010

   networks they are usually in, the choice of the port on which the
   tunnel gateway should listen is left as a local decision.  The
   service of the gateway may be available on different ports.

2.2.  MN's CoA on the tunnel interface

   A MN needs an IPv6 address to use as source for the packets it sends
   to the HA, i.e. to be configured on the MN's tunnel interface.
   Because this address will be the one seen by the HA for the MN, it
   needs to be unique among all the MN.  Additionally, all the addresses
   used by the MN for their tunnel connectivity needs to be routed from
   the HA to the tunnel gateway.

   The MN has a unique address available: its HoA.  Nonetheless, it is
   not directly usable over the tunnel because the associated prefix is
   also the home prefix.  Using this would create additional routing
   complexities on the HA and may create additional attack vectors.

   As the addresses used by the MN will never be directly routed over
   the Internet, it is possible to use a Unique Local prefix for that
   purpose.  Generation of an ULA prefix should be performed as
   described in [RFC4193].  The remaining of the address after the 48
   bits ULA prefix are set as follows.

   The 16 bits directly following the first 48 bits of ULA prefix are
   available for the administrator to configure additional subnets if

   The interface identifier is constructed in the following fashion by a

   o  the first 16 bits are filled with the MN ID, a value known by the
      MN.  It does not need to be known by the tunnel GW or the HA.  It
      is just required to be unique among the set of MN using the /64
   o  the following 48 bits are filled with random bits by the MN each
      time it changes its point of attachment in the IPv4
      infrastructure.  The rationale for this random value is given
      later in the document.

   From a theroretical standpoint, the combination of the subnet ID and
   the MN ID allows an administrator to support up to 2**32 MN, i.e.
   those are not a limiting factors.

   In the end, the tunneling component on the MN should be provided
   directly with the /80 prefix.

   To summarize, the prefix has the following format:

Ebalard                   Expires April 3, 2011                 [Page 5]

Internet-Draft                     m6t                    September 2010

     |    /48 ULA prefix   | 16 bits | 16 bits |      48 bits      |
     |                     |subnet ID|  MN ID  |    random value   |

   Note that the addressing scheme based on ULA provided above is only
   indicative: nothing prevents an administrator to use an internal
   prefix instead of an ULA prefix if it better suits her needs.  The
   only requirement for the operation of the protocol is the per-MN
   uniqueness of the prefix among the set of MN.

2.3.  Maintaining NAT states

   The MN needs to maintain states in the NAT GW which handles its
   traffic in order to remain reachable from the HA (i.e. by peers which
   use the MN-HA tunnel).

   The MN basically needs to exchange keep-alive messages with the
   tunnel GW in order for the states in the NAT GW to be maintained.
   Those exchanges are required only when no traffic is exchanged
   between the MN and its HA.

   If the MN has not sent and received traffic via the tunnel for 30
   seconds (default refresh interval borrowed from Teredo
   specification), the tunneling component on the MN will send an empty
   IPv6 packet (Next Header in IPv6 header set to 59) via the tunnel.
   The IPv6 source address of the packet is set to the tunnel interface
   address and the destination address is set to fe80::1.

   When the tunnel component receives the IPv6 packet over the tunnel,
   the specific destination address (fe80::1) and the absence of upper
   layer (next header set to 59) indicate the packet is a keep-alive
   message.  It verifies an active state exists for the source address
   in the packet and that the IPv4 parameters match the state.  If this
   is the case, it replies with a similar message but with the addresses
   reversed.  Otherwise, it silently drops the packet.

2.4.  Route management on the tunnel GW

   Route management on the tunnel gateway is implementation dependent
   but reflects the status of states.  The tunnel gateway maintains
   states associating the IPv6 address of a MN with its IPv4 information
   (IPv4 address and UDP port) to be able to forward IPv6 traffic over
   UDP from the HA to the peer.  States can be either temporary or

   A temporary state is created when a valid UDP-encapsulated IPv6
   packet is received from a MN and the IPv6 address is not already

Ebalard                   Expires April 3, 2011                 [Page 6]

Internet-Draft                     m6t                    September 2010

   known.  Such a state has a short lifetime (some milli-seconds to a
   few seconds) and either become active or is deleted.

   A temporary state becomes active when a packet from the HA to the MN
   is processed by the tunnel gateway.  An active state has a longer
   lifetime which is extended each time traffic is exchanged with the MN
   (data or keep-alive messages).

   In practice, the protocol does not offer a way for a MN to deregister
   a state.  When the MN registers from a new IPv4-only network, it
   generates a new IPv6 address and uses it.  As no traffic is exchanged
   after some point via the tunnel for that address, it is garbage
   collected automatically.

   For security reasons discussed later in the document, address-related
   information (IPv6 address, IPv4 address, UDP port) in states (active
   or temporary) are never updated.  More specifically, if the source
   address of an IPv6 packet received over UDP matches an existing state
   but there is a mismatch in IPv4-related information, the packet
   should be dropped and no modification to existing should occur.

2.5.  Multiple tunnel interfaces on a MN

   A MN may want to use multiple tunnel interfaces simultaneously, via
   the same tunnel gateway.  The addressing scheme and the protocol does
   not prevent that.  This is mainly a matter of preference among the
   different interfaces.  Additionally, if the same prefix, subnet ID
   and MN ID are used for all the tunnel interfaces of the MN (i.e. the
   same /80 prefix), then some local syncrhonization is required to
   prevent the 48 simultaneous use of identical 48 bits random values.

2.6.  MTU considerations

   Proposed approach is based on UDP tunneling.  As for Teredo protocol,
   implementation of this specification SHOULD NOT set the DF bit of the
   encapsulating IPv4 header.

   Nonetheless, packets exchanged between the MN and its HA via the
   tunnel may undergo PMTUD both at the IPv6 level (between the tunnel
   GW and the HA) and at the IPv4 level (between the MN and the tunnel
   GW).  When implementing the mechanism, PMTUD support should be one of
   the first things to validate.

   Teredo does not provide a mechanism for a Teredo client to control
   the MTU of its Teredo interface and the one on the relay.  It is
   statically set to 1280, which is a safe bet to counter the possible
   filtering of ICMP messages in the IPv4 internet.

Ebalard                   Expires April 3, 2011                 [Page 7]

Internet-Draft                     m6t                    September 2010

   In the protocol described in this memo, a different approach is
   selected.  The MTU of the tunnel interface is initially set to a
   default value of 1472 bytes on both sides (on the MN and on its
   tunnel GW).  Reception of ICMP Packet too big messages from IPv4
   routers on the path may be used to locally update the MTU of the

   For use in specific environments, implementations should provide a
   mean for administrator to set the default MTU to a different value.

2.7.  Miscellanous

   This subsection covers additional miscellanous points:

   o  HA reachability via the tunnel GW: monitoring the reachability of
      the HA via the tunnel gateway is outside the scope of the protcol
      but may be implemented if needed.  The reachability will usually
      depend on the UDP ports used for contacting the GW, i.e. on the
      filtering implemented by the IPv4 network (probably by the NAT
   o  Teredo automatic sunset equivalent: Teredo provides an automatic
      sunset mechanism.  The protocol does not provide one.  This is
      left has an implementation decision.  It should be noted that the
      use of the tunnel from a fast IPv4-only network (ethernet access)
      may be more efficient in some case than the use of a native IPv6-
      enabled connection mean via an slower network (3G).
   o  Usability from a public address: when a public IPv4 address is
      available at the MN, other transition mechanisms (e.g. 6to4) may
      be used to get IPv6 connectivity.  From an encapsulation
      standpoint, 6to4 is more efficient (8 bytes gain per packet).
      Additionally, unlike 6to4, current approach requires (no matter
      the characteristics of the available IPv4 address) to implement
      and use the keep-alive mechanism described above.  Nonetheless,
      compared to 6to4, proposed approach may provide a shorter path to
      join the HA via the tunnel GW.
   o  Behavior on IPv6-enabled networks: the mechanism is useful from
      IPv4-only networks (with or without NAT) but also works when IPv6
      and IPv4 are both available.  When usable (i.e.  IPv4 is
      available), the mechanism provides an additional IPv6 interface on
      the system that the MIPv6 module can consider.  The activation of
      the mechanism does not inhibit other existing interfaces.

3.  Protocol operations

   This short section describes the operation of the protocol.

   The m6t tunnel component on a MN is initially configured with:

Ebalard                   Expires April 3, 2011                 [Page 8]

Internet-Draft                     m6t                    September 2010

   o  The IPv4 address (and UDP port) of the tunnel gateway associated
      with its HA
   o  A /80 prefix created as described in previous section.

   When a MN gets IPv4 connectivity (IPv4 address and route), it selects
   a random 48 bits value.  It concatenates this values to its
   configured /80 prefix and installs the address on the tunnel
   interface.  A default route is configured for IPv6 traffic to flow
   via this tunnel.  A UDP socket is created for further emission to the
   GW IPv4 address (and UDP port).

   At that point, if the MIPv6 module decides to use the newly
   configured address as CoA (e.g. this is the only one available at the
   moment on the MN), it sends an IPsec-protected Binding Update message
   to its HA (or an IKE packet for negotiating IPsec SA for protecting
   the Binding Update message).  The packet is routed via the tunnel
   interface and sent to the tunnel GW via the UDP socket.

   The tunnel GW in front (or on) the HA receives the IPv4 packet and
   processes it after some sanity checks on the addresses (as described
   in previous section).  It creates a temporary state containing the
   addresses and ports and forwards the packet to the final destination
   (the HA).

   The HA processes the packet and sends a reply (IPsec protected BA,
   IKE packet, ...) to the MN.  The tunnel gateway handles that packet
   and first verifies if an active state exists for that destination.
   If it is the case, the packet is forwarded to the remote IPv4 NAT GW
   using the parameters available in the state.  If no active state
   exists, then, a lookup at the temporary states is performed: if one
   is found, it is marked active and used.

4.  Interactions with MIPv6

   per se, m6t does not have specific interactions with MIPv6 (or IPsec/
   IKE).  When a MN uses m6t, it benefits from additional and
   transparent IPv6 connectivity to its HA.  The decision to use this
   additional connectivity is left to the MIPv6 module based on its

   On the tunnel gateway, the only assumption made by m6t protocol is
   the expected reply from the HA to the first packet sent by a MN from
   a freshly generated m6t address.  This is required for validation of
   temporary state (created by first packet), i.e. switch from temporary
   to valid.  If the first packet is the beginning of an IKE
   negotiation, reply will create the state.  More often, first packet
   will be an IPsec-protected BU to which the HA will reply with by an

Ebalard                   Expires April 3, 2011                 [Page 9]

Internet-Draft                     m6t                    September 2010

   IPsec-protected BA.

5.  Pros and cons

   This short section provides the pros and cons of the approach.

   The approach described in this memo is simple, standalone and
   transparent both on the MN and the HA.  It does not require any
   changes to the MIPv6, IKE or IPsec code running on both compoments.
   It is fully compatible with NEMO.

   Unlike DSMIPv6, as the approach does not modify MIPv6
   implementations, it does not extend MIPv6 protocol to support
   communications with IPv4 peers.  NAT64 may be used at the edge of the
   Home Network to allow communications with IPv4 peers.  Other more
   suitable solutions may exist.  Additionally, DSMIPv6 provides IPv4
   address stability to the MN (i.e. an IPv4 HoA).  The approach
   described in this memo does not provide that either.  In most
   environments, IPv4 address stability is usually not needed or useful
   because nodes are usually provisioned with private IPv4 address and
   have for that reason limited reachability outside their private

6.  Security Considerations

6.1.  Preventing DoS

6.1.1.  Against the MN

   Nothing is done to prevent an active attacker located on the path
   between the MN and the tunnel GW with the ability to access and
   modify the traffic.  Because such an attacker has access to all the
   traffic exchanged with the tunnel GW and the HA, there is not much
   that can be done.  A similar threat exist in [RFC5555]

   Nonetheless, if an attacker has read acccess and is able to send
   traffic in parallel of a MN (e.g. case of a MN connected to an
   unprotected wireless network), m6t protocol provides protection to
   the MN.  More precisely, the use of a new IPv6 random address by the
   MN each time it changes its point of attachment creates a new state
   on the remote m6t tunnel gateway, associated with its mapped IPv4
   address and port.  Because existing m6t bindings between an IPv6
   care-of address and an IPv4 address and UDP port cannot be replaced
   or modified, it is not possible for the attacker to cause the m6t
   gateway to redirect the MN's traffic to a different IPv4 address and
   UDP port.

Ebalard                   Expires April 3, 2011                [Page 10]

Internet-Draft                     m6t                    September 2010

   Note that nothing prevents an implementation of changing its IPv6
   address more frequently.

6.1.2.  Against the HA

   The access via the tunnel GW is not expected to open additional DoS
   possibilities against the HA.

6.1.3.  Against the GW

   The Gateway is basically a single point of failure for the MN which
   use it as their connection mean to their HA from IPv4 network.  If an
   attacker manages to perform a DoS against the tunnel GW, this may
   prevent legitimate peers to access their HA.

   In order to prevent that, care is needed when implementing the tunnel
   GW.  Rate limiting and garbage collection can be used for that

   When a packet is received from a new IPv4 address, some initial
   sanity checks are performed on the packet (IPv6 destination address
   is HA address, IPv6 address is from the configured ULA prefix, ...).

   After that initial validation of the packet, a state is recorded,
   containing the IPv4 source @, the UDP source port and the IPv6 source
   address of the packet.  Such a state should be associated a very low
   (few ms) garbage collection timer.  The value should be configured
   based on the environment in which the tunnel GW is deployed: it
   should basically match the expected processing time of a packet on
   the HA (first IKE packet, BU, ...) and the RTT between the gateway
   and the HA.

   Creation of such states should also be rate-limited on a per IPv4
   address basis (not considering the source port): this would prevent
   an individual attacker to perform a DoS against the service.  It
   would basically require her to have access to a set of bot.  The
   upper limit to use per IPv4 address is not specified in this memo.
   It should be configured locally based on the environment.  It may be
   possible for some deployments to expect multiple simultaneous
   connections originatig from the same NAT GW.

   When a packet is received by the tunnel GW from the HA, a lookup is
   performed to check if a valid state exists for the IPv6 destination
   address.  If one is found, it provides the IPv4 destination address
   and port of the NAT GW associated with that IPv6 address.  If it does
   not yet exist, then a lookup for the address in the pending temporary
   states is performed.  If one is found, it becomes active.  The packet
   is forwarded to the remote GW on the given IPv4 address and UDP port.

Ebalard                   Expires April 3, 2011                [Page 11]

Internet-Draft                     m6t                    September 2010

   Garbage collecting for that state is activated: the purpose is for
   state to be removed if no traffic is exchanged in both direction for
   more than the expected NAT GW timeout.  The maintenance of the state
   is left to the MN as described in a previous section of the document.

6.1.4.  Against the Infrastructure

   An attacker may want to use the tunnel GW to create amplification
   attacks against elements of the IPv4 infrastructure.  For the reasons
   explained above, an attacker will not be able to redirect a MN's
   traffic to a controlled address.  But the HA is still expected to
   reply to some unauthenticated probes.  For instance, if an attacker
   targets it's IKE daemon via the tunnel GW, it will get an answer.  If
   it is able to spoof its source address, the response will be sent to
   the spoofed source address.  This kind of attack is still already
   possible on the IPv4 infrastructure and the attacker would not get
   additional gain in using the tunnel GW for such a scenario.

7.  Implementation

   A (proof of concept) implementation (client and tunnel gateway) has
   been developed by the author for Linux.  It is available at
   http://natisbad.org/m6t/ under a GPLv2 license.  The implementation
   interoperates transparently and out of the box with unmodified
   versions of UMIP (Mobile IPv6 for Linux, see http://umip.org/).

8.  IANA Considerations

   This document has no IANA actions.

9.  Acknowledgements

   The author would like to thank Julien Laganier, Romain Kuntz and
   Christophe Regouby for interesting technical discussions and reviews
   of the draft.

   This document was generated using xml2rfc.

10.  References

10.1.  Normative References

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

Ebalard                   Expires April 3, 2011                [Page 12]

Internet-Draft                     m6t                    September 2010

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

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

10.2.  Informative References

   [MIGRATE]  Ebalard, A. and S. Decugis, "PF_KEY Extension as an
              Interface between Mobile IPv6 and IPsec/IKE",
              draft-ebalard-mext-pfkey-enhanced-migrate-00 (work in
              progress), August 2008.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

Author's Address

   Arnaud Ebalard
   EADS Innovation Works
   12, rue Pasteur - BP76
   Suresnes  92152

   Email: arno@natisbad.org

Ebalard                   Expires April 3, 2011                [Page 13]

Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/