idnits 2.17.00 (12 Aug 2021) /tmp/idnits58557/draft-haddad-mext-nat64-mobility-harmful-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (March 13, 2011) is 4080 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-mext-rfc3775bis has been published as RFC 6275 == Outdated reference: draft-ietf-behave-dns64 has been published as RFC 6147 == Outdated reference: draft-ietf-behave-v6v4-xlate-stateful has been published as RFC 6146 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Extensions for IPv6 W. Haddad 3 (mext) Ericsson 4 Internet-Draft C. Perkins 5 Intended status: Informational WiChorus Inc. 6 Expires: September 14, 2011 March 13, 2011 8 A Note on NAT64 Interaction with Mobile IPv6 9 draft-haddad-mext-nat64-mobility-harmful-02 11 Abstract 13 This memo discusses potential NAT64 technology repercussions for 14 mobile nodes using Mobile IPv6. An ambiguity is identified related 15 to the use of DNS during bootstrapping, which is likely to inhibit 16 proper signaling between mobile node and home agent. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 14, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 62 1. Introduction 64 NAT64 technology, as described in 65 [I-D.ietf-behave-v6v4-xlate-stateful], enables faster IPv4 network 66 conversion to IPv6-only operation while maintaining contact with the 67 remaining global IPv4 Internet. In this document, we are concerned 68 with IPv6-only nodes attached to a network for which NAT64 provides 69 connectivity with IPv4 networks. 71 This document aims to highlight potential NAT64 repercussions for 72 mobile nodes using Mobile IPv6 ([I-D.ietf-mext-rfc3775bis]) and 73 attached to a network behind a NAT64. 75 2. Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 3. NAT64 Incompatibility with Mobile IPv6 83 NAT technologies have from the very beginning exhibited numerous 84 incompatibities with the Internet. Hence, the new incompatibility 85 described in this document should not come as a surprise! 87 The NAT64 mechanism considered here complies with the DNS64 88 technology described in [I-D.ietf-behave-dns64] to provide the 89 querying host with a synthetic DNS response in which, the queried 90 FQDN is locally translated to an IPv6 address using the v6 prefix 91 assigned to the NAT64 v6 interface. By inserting the translated IPv6 92 address in the synthetic DNS response, the querying node acts as if 93 the destination is also using an IPv6 stack. This, in turn, enables 94 the two nodes to establish a session during which, all exchanged 95 packets are routed through the querying node's local NAT64 in order 96 to reach their destinations. 98 As NAT64 technology is likely to be widely deployed, we consider its 99 behavior in relationship to Mobile IPv6. For this purpose, suppose 100 that a mobile node (MN) configured with an IPv6 home address (HoA) 101 leaves its NAT64-serviced home network and attaches to a foreign 102 network also serviced by NAT64, and configures a new IPv6 address, 103 i.e., a care-of address (CoA). We analyze two scenarios which 104 require using MIPv6 either to maintain a session, or to establish an 105 optimal path to exchange the data packets, using MIPv6 route 106 optimization (RO). 108 In the first scenario, suppose that before detaching from its home 109 network, the MN has established a session with a corresponding node 110 (CN) which is attached to an IPv4 network. Due to the NAT64 presence 111 in the home network, the MN acts as if it were communicating with an 112 IPv6-enabled CN. Hence, the MN decides upon attaching to the new 113 NAT64-serviced foreign network, to run the MIPv6 return routability 114 procedure with the CN by sending first a home test init (HoTI) 115 message via its home agent. Such messages will be discarded either 116 by the CN or by a more intelligent NAT64 -- in which case it would 117 likely be followed by an ICMP message sent to the MN. In both cases, 118 the MN can detect that the RR procedure is failing. Consequently, 119 there is little harm to the MN's communications and no data packet 120 loss since the MN will keep using MIPv6 bidirectional tunneling (BT) 121 mode. 123 However, the situation worsens when we consider another scenario in 124 which the MN decides to establish a session with the same CN from the 125 foreign NAT64-serviced network. In such case, the MN will first 126 obtain a synthetic DNS reply which presents the CN as being an IPv6- 127 enabled node. Based on that, the MN may try to create a binding at 128 the CN. The MN might first run the RR procedure which will 129 ultimately fail (for the same reasons as in the first scenario). 130 More likely, the MN will initiate the session with the CN by using 131 the BT mode then switching to the RO mode. In this case, the MN 132 first tunnels its data packets to its HA without having them being 133 intercepted by the foreign NAT64. However, after reaching the HA, 134 the data packets will most likely be dropped at some point. This is 135 due to the presence of the foreign NAT64 IPv6 prefix in the CN's IPv6 136 address. 138 4. Security Considerations 140 This document describes scenarios where a NAT64, using DNS64, can 141 disrupt communications to a mobile node visiting the associated 142 network. It does not introduce any new security vulnerabilities, 143 provide any guidance about how to improve security, or describe any 144 effects on existing security practices. 146 5. Acknowledgements 148 Thanks to Francis Dupont and Joel Halpern for reviewing the document 149 at an early stage. 151 6. References 153 6.1. Normative References 155 [I-D.ietf-mext-rfc3775bis] 156 Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 157 in IPv6", draft-ietf-mext-rfc3775bis-13 (work in 158 progress), March 2011. 160 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 161 Requirement Levels", BCP 14, RFC 2119, March 1997. 163 6.2. Informative References 165 [I-D.ietf-behave-dns64] 166 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 167 "DNS64: DNS extensions for Network Address Translation 168 from IPv6 Clients to IPv4 Servers", 169 draft-ietf-behave-dns64-11 (work in progress), 170 October 2010. 172 [I-D.ietf-behave-v6v4-xlate-stateful] 173 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 174 NAT64: Network Address and Protocol Translation from IPv6 175 Clients to IPv4 Servers", 176 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 177 progress), July 2010. 179 Authors' Addresses 181 Wassim Haddad 182 Ericsson 183 300 Holger Way 184 San Jose, CA 95134 185 US 187 Phone: +408 750 5667 188 Email: Wassim.Haddad@ericsson.com 190 Charles E. Perkins 191 WiChorus Inc. 192 3590 North, 1st Street, Suite 300 193 San Jose, CA 95134 194 US 196 Email: Charliep@computer.org