Internet DRAFT - draft-haddad-behave-nat64-mobility-harmful

draft-haddad-behave-nat64-mobility-harmful






Behavior Engineering for Hindrance                             W. Haddad
Avoidance (behave)                                              Ericsson
Internet-Draft                                           August 26, 2009
Intended status: Informational
Expires: February 27, 2010


              A Note on NAT64 Interaction with Mobile IPv6
             draft-haddad-behave-nat64-mobility-harmful-00

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 27, 2010.

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.








Haddad                  Expires February 27, 2010               [Page 1]

Internet-Draft               NAT64 Mobility                  August 2009


Abstract

   This memo discusses potential NAT64 technology repercussions for
   mobile nodes using Mobile IPv6 stack.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  NAT64 Incompatibility with Mobile IPv6 . . . . . . . . . . . .  5
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10


































Haddad                  Expires February 27, 2010               [Page 2]

Internet-Draft               NAT64 Mobility                  August 2009


1.  Introduction

   NAT64 technology described in [I-D.ietf-behave-v6v4-xlate-stateful],
   enables rapid IPv4 network conversion to a pure IPv6 stack while
   keeping possible the contact with the remaining IPv4 networks.  It
   follows that nodes attached to a NAT64-powered network operate with
   an IPv6 stack only.

   This memo aims to highlight potential NAT64 repercussions for mobile
   nodes using Mobile IPv6 ([I-D.ietf-mext-rfc3775bis]) and operating
   from behind a NAT64.








































Haddad                  Expires February 27, 2010               [Page 3]

Internet-Draft               NAT64 Mobility                  August 2009


2.  Conventions used in this document

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














































Haddad                  Expires February 27, 2010               [Page 4]

Internet-Draft               NAT64 Mobility                  August 2009


3.  NAT64 Incompatibility with Mobile IPv6

   It is interesting to start this section by mentioning that NAT
   technology in general has had from its infancy the rare feature of
   being incompatible with the Internet.  Hence, the described new
   incompatibility should not come as a surprise!

   NAT64 mechanism relies on DNS64 technology described in
   [I-D.ietf-behave-dns64] to provide the querying host with a synthetic
   DNS response in which, the queried FQDN is locally translated to an
   IPv6 address using the v6 prefix assigned to the NAT64 v6 interface.
   By inserting the translated IPv6 address in the synthetic DNS
   response, the querying node is tempted to believe that the
   destination is also using an IPv6 stack which in turn, enables
   establishing a session between the two nodes.

   As NAT64 technology may have the potential of becoming widely
   deployed, we are tempted to study its behavior in the presence of a
   v6 mobility dimension.  For this purpose, we assume that a mobile
   node (MN) configured with an IPv6 home address (HoA) leaves its
   NAT64-powered home network and attaches to a foreign NAT64-powered
   network where it configures a new IPv6 address, i.e., care-of address
   (CoA).  In the following, we look into two scenarios which require
   using MIPv6 either to establish a new session or to try to switch the
   data packets exchange to the optimal path via using MIPv6 route
   optimization (RO) mode.

   In a first scenario, we consider that before detaching from its home
   network, the MN has established a session with a corresponding node
   (CN) which is attached to an IPv4 network.  However, due to the NAT64
   presence in the home network, the MN believes that it is talking with
   an IPv6-enabled CN and hence, it decides upon attaching to the new
   NAT64-powered foreign network, to run MIPv6 return routability (RR)
   procedure with the CN by sending first a home test init (HoTI)
   message via its home agent.  It is clear that such message will be
   discarded either by a "more" intelligent NAT64 (i.e., in which case
   it may be followed by an ICMP message sent to the MN) or by the CN.
   In both cases, the MN will correctly realize at some point that the
   RR procedure cannot succeed.  Consequently, there is no harm
   inflicted to the MN and more importantly, no data packet loss since
   the MN will keep using MIPv6 bidirectional tunneling (BT) mode.

   However, the situation becomes problematic when we consider another
   scenario in which, the MN decides to establish a session with the
   same CN from the foreign NAT64-powered network.  In such case, the MN
   will first obtain a synthetic DNS reply which presents the CN as
   being an IPv6-enabled node.  Based on that, the MN may either try to
   create a binding at the CN by running first the RR procedure which



Haddad                  Expires February 27, 2010               [Page 5]

Internet-Draft               NAT64 Mobility                  August 2009


   will ultimately fail (i.e., for the same reasons as in the first
   scenario) or more likely, will initiate the session with the CN by
   using the BT mode then switching to the RO mode.  In this case, the
   MN tunnels first its data packets to its HA without having them being
   intercepted by the foreign NAT64.  However, after reaching the HA,
   the data packets will most likely be dropped at some point.  This is
   due to the presence of the foreign NAT64 IPv6 prefix in the CN's IPv6
   address.











































Haddad                  Expires February 27, 2010               [Page 6]

Internet-Draft               NAT64 Mobility                  August 2009


4.  Security Considerations

   This memo describes scenarios where a NAT64 can inflict harm to a
   mobile node visiting the associated network.















































Haddad                  Expires February 27, 2010               [Page 7]

Internet-Draft               NAT64 Mobility                  August 2009


5.  Acknowledgements

   Thanks to Francis Dupont and Joel Halpern for reviewing the document
   at an early stage.















































Haddad                  Expires February 27, 2010               [Page 8]

Internet-Draft               NAT64 Mobility                  August 2009


6.  References

6.1.  Normative References

   [I-D.ietf-mext-rfc3775bis]
              Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", draft-ietf-mext-rfc3775bis-04 (work in
              progress), July 2009.

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

6.2.  Informative References

   [I-D.ietf-behave-dns64]
              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
              "DNS64: DNS extensions for Network Address Translation
              from IPv6 Clients to  IPv4 Servers",
              draft-ietf-behave-dns64-00 (work in progress), July 2009.

   [I-D.ietf-behave-v6v4-xlate-stateful]
              Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
              Address and Protocol Translation from IPv6 Clients to IPv4
              Servers", draft-ietf-behave-v6v4-xlate-stateful-01 (work
              in progress), July 2009.


























Haddad                  Expires February 27, 2010               [Page 9]

Internet-Draft               NAT64 Mobility                  August 2009


Author's Address

   Wassim Haddad
   Ericsson
   6210 Spine Road
   Boulder, CO 80301
   US

   Phone: +303 473 6963
   Email: Wassim.Haddad@ericsson.com









































Haddad                  Expires February 27, 2010              [Page 10]