idnits 2.17.1 draft-haddad-behave-nat64-mobility-harmful-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 26, 2009) is 5355 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-mext-rfc3775bis-04 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-00 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance W. Haddad 3 Avoidance (behave) Ericsson 4 Internet-Draft August 26, 2009 5 Intended status: Informational 6 Expires: February 27, 2010 8 A Note on NAT64 Interaction with Mobile IPv6 9 draft-haddad-behave-nat64-mobility-harmful-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 27, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This memo discusses potential NAT64 technology repercussions for 48 mobile nodes using Mobile IPv6 stack. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions used in this document . . . . . . . . . . . . . . 4 54 3. NAT64 Incompatibility with Mobile IPv6 . . . . . . . . . . . . 5 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 59 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 1. Introduction 64 NAT64 technology described in [I-D.ietf-behave-v6v4-xlate-stateful], 65 enables rapid IPv4 network conversion to a pure IPv6 stack while 66 keeping possible the contact with the remaining IPv4 networks. It 67 follows that nodes attached to a NAT64-powered network operate with 68 an IPv6 stack only. 70 This memo aims to highlight potential NAT64 repercussions for mobile 71 nodes using Mobile IPv6 ([I-D.ietf-mext-rfc3775bis]) and operating 72 from behind a NAT64. 74 2. Conventions used in this document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 3. NAT64 Incompatibility with Mobile IPv6 82 It is interesting to start this section by mentioning that NAT 83 technology in general has had from its infancy the rare feature of 84 being incompatible with the Internet. Hence, the described new 85 incompatibility should not come as a surprise! 87 NAT64 mechanism relies on DNS64 technology described in 88 [I-D.ietf-behave-dns64] to provide the querying host with a synthetic 89 DNS response in which, the queried FQDN is locally translated to an 90 IPv6 address using the v6 prefix assigned to the NAT64 v6 interface. 91 By inserting the translated IPv6 address in the synthetic DNS 92 response, the querying node is tempted to believe that the 93 destination is also using an IPv6 stack which in turn, enables 94 establishing a session between the two nodes. 96 As NAT64 technology may have the potential of becoming widely 97 deployed, we are tempted to study its behavior in the presence of a 98 v6 mobility dimension. For this purpose, we assume that a mobile 99 node (MN) configured with an IPv6 home address (HoA) leaves its 100 NAT64-powered home network and attaches to a foreign NAT64-powered 101 network where it configures a new IPv6 address, i.e., care-of address 102 (CoA). In the following, we look into two scenarios which require 103 using MIPv6 either to establish a new session or to try to switch the 104 data packets exchange to the optimal path via using MIPv6 route 105 optimization (RO) mode. 107 In a first scenario, we consider that before detaching from its home 108 network, the MN has established a session with a corresponding node 109 (CN) which is attached to an IPv4 network. However, due to the NAT64 110 presence in the home network, the MN believes that it is talking with 111 an IPv6-enabled CN and hence, it decides upon attaching to the new 112 NAT64-powered foreign network, to run MIPv6 return routability (RR) 113 procedure with the CN by sending first a home test init (HoTI) 114 message via its home agent. It is clear that such message will be 115 discarded either by a "more" intelligent NAT64 (i.e., in which case 116 it may be followed by an ICMP message sent to the MN) or by the CN. 117 In both cases, the MN will correctly realize at some point that the 118 RR procedure cannot succeed. Consequently, there is no harm 119 inflicted to the MN and more importantly, no data packet loss since 120 the MN will keep using MIPv6 bidirectional tunneling (BT) mode. 122 However, the situation becomes problematic when we consider another 123 scenario in which, the MN decides to establish a session with the 124 same CN from the foreign NAT64-powered network. In such case, the MN 125 will first obtain a synthetic DNS reply which presents the CN as 126 being an IPv6-enabled node. Based on that, the MN may either try to 127 create a binding at the CN by running first the RR procedure which 128 will ultimately fail (i.e., for the same reasons as in the first 129 scenario) or more likely, will initiate the session with the CN by 130 using the BT mode then switching to the RO mode. In this case, the 131 MN tunnels first its data packets to its HA without having them being 132 intercepted by the foreign NAT64. However, after reaching the HA, 133 the data packets will most likely be dropped at some point. This is 134 due to the presence of the foreign NAT64 IPv6 prefix in the CN's IPv6 135 address. 137 4. Security Considerations 139 This memo describes scenarios where a NAT64 can inflict harm to a 140 mobile node visiting the associated network. 142 5. Acknowledgements 144 Thanks to Francis Dupont and Joel Halpern for reviewing the document 145 at an early stage. 147 6. References 149 6.1. Normative References 151 [I-D.ietf-mext-rfc3775bis] 152 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 153 in IPv6", draft-ietf-mext-rfc3775bis-04 (work in 154 progress), July 2009. 156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 157 Requirement Levels", BCP 14, RFC 2119, March 1997. 159 6.2. Informative References 161 [I-D.ietf-behave-dns64] 162 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 163 "DNS64: DNS extensions for Network Address Translation 164 from IPv6 Clients to IPv4 Servers", 165 draft-ietf-behave-dns64-00 (work in progress), July 2009. 167 [I-D.ietf-behave-v6v4-xlate-stateful] 168 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 169 Address and Protocol Translation from IPv6 Clients to IPv4 170 Servers", draft-ietf-behave-v6v4-xlate-stateful-01 (work 171 in progress), July 2009. 173 Author's Address 175 Wassim Haddad 176 Ericsson 177 6210 Spine Road 178 Boulder, CO 80301 179 US 181 Phone: +303 473 6963 182 Email: Wassim.Haddad@ericsson.com