idnits 2.17.1 draft-perkins-sourceipnat-01.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.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (October 12, 2009) is 5310 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 behave Working Group C. Perkins, Ed. 3 Internet-Draft WiChorus Inc. 4 Intended status: Standards Track October 12, 2009 5 Expires: April 15, 2010 7 Translating IPv4 to IPv6 based on source IPv4 address 8 draft-perkins-sourceipnat-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 15, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 A method is proposed to enable communications between an IPv4-only 47 node in today's Internet and an IPv6-only node, initiated by the 48 IPv4-only node. The communication depends on allocation of a flow 49 record and address triggered by a DNS query received for the target 50 v6-only node. DNS query conventions can be agreed upon to provide a 51 natural model for resolving IPv4 queries for IPv6-only nodes. The 52 NAT mechanism proposed demultiplexes multiple sessions through the 53 same dynamically allocated IP address, using flow records matching 54 the source address of incoming packets. This is in contrast to the 55 use of ports in NAT-PT boxes, which inhibits the support of incoming 56 traffic towards a node behind the NAT-PT. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Outgoing flows, initated by an IPv6-only device. . . . . . . . 8 64 5. Denial of Service . . . . . . . . . . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 67 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 68 Appendix A. Using NAT for the DNS resolution . . . . . . . . . . 13 69 Appendix B. Some observations about dual-stack solutions . . . . 14 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 As long as it is more difficult to deploy IPv6 nodes than IPv4 nodes 75 in today's Internet, adoption of IPv6 is going to be slow. The use 76 of NAT in today's Internet has created certain expectations and 77 operational conveniences, but at the cost of some important features. 78 In particular, communications are often not really bidirectional 79 since the device whose IP address is to be translated typically has 80 to initiate the communication. 82 In order to encourage the adoption of IPv6, it is likely to be 83 important to enable IPv6-only nodes to provide services to the 84 existing IPv4-dominant Internet. Otherwise, if services can be 85 provided for today's Internet only by assigning IPv4 addresses to the 86 service-providing nodes, there is decreased economic incentive for 87 moving to IPv6. 89 The approach proposed in this document should be considered a 90 specialized form of flow management, where flows are identified by 91 source and destination IP addresses (usually also including 92 additional information including ports). The NAT box manages the 93 flows, allocating and deallocating resources, and managing the 94 traffic (albeit intrusively) according to the mutual needs of the 95 source and destination networks. 97 Using the techniques proposed in this specification, communication 98 between IPv4 nodes and IPv6 nodes can be accomplished with minimal 99 requirements on the nodes and infrastructure: 101 o no dual stack 103 o no restriction to port-based communications 105 o no tunneling 107 o no changes to IPv4 or IPv6 hosts 109 Moreover, the approach is scalable because each IPv4 address used by 110 for the incoming flows can be shared by many different IPv6-only 111 devices. The degree of scalability is determined by the rate of 112 arrival for new incoming connection requests, and to a lesser extent 113 by the number of simultaneous connection requests initiated from any 114 particular IPv4 host. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [1]. 122 3. Overview 124 Suppose that an operator wishes to support a large population of 125 IPv6-only nodes. Also, suppose that the operator requires that the 126 IPv6 nodes should have free access to the existing IPv4 Internet, and 127 that customers in the existing Internet should also have free access 128 to service-providing nodes in the IPv6-only domain, as well as to any 129 of the other nodes in the domain for which such incoming 130 communications would be valuable. This might, for instance, greatly 131 simplify real-time gaming and VoIP. 133 Here is a proposed sequence of events. Let v6dev.foo.net be the FQDN 134 for a v6-only node in the operator's domain. When a node in the IPv4 135 Internet wishes to establish a communication with v6dev, it sends a 136 IPv4 DNS query to the name server (denoted fooNS) for foo.net. 137 Suppose that the fooNS is programmed to supply an IPv4 address for 138 such IPv4 DNS queries, but there is no such IPv4 address record 139 available. Then, fooNS contacts the NAT box to get the required IPv4 140 address; in this context, the NAT box has the function of address 141 allocation. Then fooNS creates a DNS reply with the appropriate A 142 record. Importantly, fooNS does NOT store this A record for v6dev. 143 Every distinct DNS query for v6dev could conceivably get a distinct 144 IPv4 address allocation. The cache time for the A record is set to 145 the minimum (either 0 or 1, depending on policy). 147 When fooNS sends the request to the NAT box (call it SIPNAT) for an 148 address allocation, SIPNAT allocates the address (call it v6dev-IPv4) 149 and creates a flow record with the following information: 151 o v6dev-IPv4 153 o the time when v6dev-IPv4 was allocated 155 o the IPv6 address of v6dev 157 o which nameserver made the request 159 It also sets the status of the address allocation as "pending", and 160 sets a timeout (call it BIND_TIMEOUT) by which the allocation has to 161 be "established". 163 In due time, a packet will arrive at v6dev-IPv4, which is the address 164 of a network interface of SIPNAT. Assuming this happens before the 165 expiration of BIND_TIMEOUT, SIPNAT "establishes" the allocation by 166 associating the following additional information with v6dev-IPv4: 168 o the source address of the incoming packet (call it CNv4, for 169 "correspondent node IPv4") 171 o the source port of the incoming packet 173 o the time of arrival 175 o the updated status of "established" 177 o a new timeout, "WAIT_TIME" 179 Then, SIPNAT does the address translation as detailed below and 180 delivers the IPv6 result to v6dev. 182 The translation is performed as follows: Suppose the incoming IPv4 183 packet has: 185 == , 187 where v6dev-IPv4 is an address of SIPNAT. 189 Then the outgoing IPv6 packet gets: 191 == 193 The same rules apply for ICMP, GRE, and other protocols. Ports 194 remain unchanged. If it is desired to use another IPv6 prefix to 195 identify CNv4 to v6dev, the rule above can be easily modified as long 196 as v6dev is configured appropriately. Whichever prefix is used, 197 v6dev will use it to send packets back through SIPNAT, which then 198 performs the reverse translation for delivery to CNv4 in the IPv4 199 Internet. 201 If, after the allocation is established, it happens that no packets 202 flow between v6dev and CNv4, then v6dev-IPv4 is deallocated for the 203 purpose of communications between v6dev and CNv4. v6dev-IPv4 may 204 remain in use for other purposes. SIPNAT waits for WAIT_TIME to 205 receive or send a packet on the (v6dev, CNv4) flow before 206 deallocating the flow. Under the assumption that fooNS has not 207 cached v6dev-IPv4 as the IPv4 address of v6dev.foo.net, there is no 208 need to notify fooNS about the deallocation. If, in the future, the 209 no-cache assumption is relaxed, a notification of the deallocation 210 would be needed. 212 When the NAT box has allocated all of its available IPv4 addresses 213 for active or pending communications, it begins to overload the 214 available IPv4 addresses. Each IPv4 address can be allocated for use 215 of multiple distinct communications. The same IPv4 address can be 216 used for numerous different IPv6-only nodes, or even for multiple 217 distinct flows to the same IPv6-only device. Each such flow is 218 identified by source and destination IPv4 address and port numbers, 219 along with possibly other information to be specified. Each new IPv4 220 DNS query for one of the IPv6-only nodes served by SIPNAT will 221 trigger another allocation of one of SIPNAT's IPv4 addresses. It is 222 not clear what the maximum degree of overload should be; it will 223 depend on the flow management performance of the IPv4 network 224 interfaces of the NAT box. 226 When a new allocation (call it again v6dev-IPv4) has been made for 227 one of SIPNAT's IPv4 addresses, incoming packets have to be inspected 228 to determine whether they contain a new IPv4 source address, not yet 229 associated with any other flow using v6dev-IPv4. If such a new 230 source address is detected, the new allocation is "established", the 231 new data is recorded, and the timeout for the new flow is set to 232 WAIT_TIME. 234 In a nutshell, the incoming sessions are demultiplexed into the IPv6- 235 only domain based on incoming IPv4 source address, not based on 236 incoming source port number. Given the prevalence of NATs in today's 237 Internet, the source port number takes on additional importance, 238 because the same IPv4 address could actually be used by multiple 239 source computers with their IP addresses hidden from the Internet. 240 Because of this, the source port number should be used as an 241 additional demultiplexing index. In this way, multiple instances of 242 the same source IPv4 address could be used at the same NATv4 address 243 as long as port numbers were available and different for the 244 different instances of that IPv4 source address. 246 4. Outgoing flows, initated by an IPv6-only device. 248 These can be handled in any of the ways proposed, but perhaps the 249 simple v6v4 NAT proposals are most appropriate here. Problems with 250 v4-mapped addresses and other difficulties associated with NATs are 251 noted in RFC 4966, but it should also be pointed out that a majority 252 of today's Internet citizens do not seem to be overly concerned with 253 these limitations. We should make it our first goal to make these 254 typical users equally or more happy with IPv6, even if the NAT 255 solution is inherently restrictive. In fact, different outgoing NAT 256 boxes can be used for the outgoing flows, as long as the incoming 257 flow maintains enough traffic to avoid expiration of WAIT_TIME. 259 5. Denial of Service 261 The v4-->v6 translation relies on the availability of IPv4 interfaces 262 on the NAT box for which no new flow allocation is "pending". If a 263 packet arrival at such a pending IPv4 interface were to cause that 264 interface to immediately become unavailable for establishing v4-->v6 265 flows, there would be an easy opportunity for an attacker to mount a 266 denial of service attack against the domain served by the source IP 267 (SIPNAT) NAT function. Namely, the attacker could simply spray 268 random IPv4 packets to all of the publicly accessible IPv4 network 269 interfaces of the SIPNAT. 271 In order to combat this denial of service vulnerability it is 272 necessary to avoid the loss of the pending resource. This can be 273 done most easily by requiring pending flows to remain pending until 274 no packets with new source IP addresses have been received at the 275 pending address for BINDING_WAIT time. Equivalently, this means that 276 such a pending allocation has its BINDING_WAIT timeout restarted 277 every time a packet arrives at the IPv4 network interface with a 278 previously unestablished source address. 280 A malicious attacker can still mount a denial of service attack, but 281 it would then require a much more sustained effort. The result would 282 be that any new pending flow allocation might collect quite a few new 283 flow records, which would all then have to be maintained for 284 WAIT_TIME before deallocation. But the requirement that the attacker 285 maintain the attack for a longer time should make it easier to trace 286 back the offending packets back to their source. Furthermore, 287 frequently offending source IP prefixes might well be blacklisted. 288 Packets from blacklisted prefixes could be discarded to avoid these 289 unwanted effects. 291 6. Security Considerations 293 Any scheme which uses an allocation scheme for IPv4 addresses on the 294 NAT box, such that the allocated resource even temporarily impacts 295 new allocations, is vulnerable to a denial of service attack. In the 296 case of SIPNAT, this DoS attack takes the form of flooding the DNS 297 Request mechanism. Such malicious flooding could have the effect of 298 depriving the IPv4 allocation for legitimate DNS Requests from 299 legitimate correspondents. 301 Allocations in the pending state are vulnerable to false 302 establishment by malicious nodes flooding packets to all of the 303 existing IPv4 addresses of the SIPNAT box (see Section 5). There are 304 methods to ameliorate such attacks, such as rate limiting requrests 305 or making restrictions on the possible source IP addresses that can 306 satisfy the flow establishment. The technique of leaving the flow 307 pending momentarily even after a candidate packet has arrived to 308 establish the flow, should also greatly reduce the vulnerability to 309 this attack. 311 7. Acknowledgments 313 Thanks to Vijay Devarapalli, who provided useful ideas to make 314 important improvements in the proposal. Thanks to Mark Andrews, who 315 offered the solution of extending the availability of "pending" flow 316 allocations, by restarting the BIND_TIMEOUT. 318 8. Normative References 320 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 321 Levels", BCP 14, RFC 2119, March 1997. 323 Appendix A. Using NAT for the DNS resolution 325 If the NAT box is used as the authoritative name server for a special 326 subdomain of foo.net, say for example v6only_domain.foo.net, then 327 this design can be carried out without requiring changes to the 328 existing DNS infrastructure. It is a matter of discussion whether or 329 not it would be desirable to recommend the isolation of such v6-only 330 devices and their transient A records to such subdomains. 332 Appendix B. Some observations about dual-stack solutions 334 From the standpoint of utility for conserving IPv4 address space 335 during the transition to IPv6, dual-stack designs do not offer the 336 advantages that are sometimes claimed. 338 There are three likely possibilities for a dual-stack implementation 340 o The IPv4 address is globally unique. This is very undesirable to 341 make as a requirement, since then we have accomplished nothing 342 towards the goal of making available more network-layer addresses. 344 o The IPv4 address is a private address, and there is a NAT box at 345 the border of the dual-stack domain. In this case, we have NAT. 346 Since IPv6-only hosts can work just fine with NATs, why require 347 dual stack? 349 o The IPv4 address is a private address, and the dual-stack node is 350 required to do tunnel processing on incoming v6-addressed packets 351 that it receives. This amounts to a substantial implementation 352 burden and, when communications occurs over a wireless medium, 353 even more overhead. 355 Nevertheless, dual-stack hosts are very useful when there is a need 356 for network nodes to offer IPv6-only applications as well as IPv4- 357 only applications. In this scenario, the node should host a dual- 358 stack implementation. Then, over time, as all the applications 359 migrate to IPv6, the need for configuring the IPv4 part of the dual- 360 stack platform will decrease until at some point the IPv4 361 configuration may be disregarded entirely. 363 Author's Address 365 Charles E. Perkins 366 WiChorus Inc. 367 3590 N. 1st Street, Suite 300 368 San Jose, CA 95134 369 USA 371 Email: charliep@computer.org