idnits 2.17.1 draft-perkins-behave-dpinat-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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 1 instance 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 date (October 19, 2009) is 5296 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) == Unused Reference: '1' is defined on line 340, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 354, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-perkins-sourceipnat-00 -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '2') (Obsoleted by RFC 5996) == Outdated reference: A later version (-07) exists of draft-xli-behave-ivi-02 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-00 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Behave Working Group C. Perkins 3 Internet-Draft WiChorus Inc. 4 Expires: April 22, 2010 October 19, 2009 6 Payload-assisted Delivery for SIPNAT 7 draft-perkins-behave-dpinat-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 22, 2010. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 SIPNAT has been proposed as an effective method for enabling global 46 Internet access to IPv6-only domains. New methods have been devised 47 for accurate delivery of packets from the global Internet into the 48 internal domain of destinations that do not share a common address 49 space with the majority of the global Internet. These improvements 50 can be used to augment Source-IP NAT so that perfect accuracy can be 51 achieved in many common cases of interest. 53 1. Introduction 55 Enabling the transition from IPv4 to IPv6 will depend to a large 56 extent upon how well businesses and online organizations can depend 57 on IPv6 to carry on their daily operations. One way to justify such 58 dependence on IPv6 is to assure businesses that their online services 59 will be accessible from the entire existing IPv54 Internet. 61 With traditional port-mapped NAT (NAPT), this has not been possible 62 because, for each source-destination flow, the translation parameters 63 for the flow have had to be established by the internal network node 64 (i.e., the node with the IP address that is incompatible with the 65 addressing domain of the global Internet). In particular, for each 66 such flow there needs to be an external IP address and an external 67 port assigned. Packets arriving at the external IP address and port 68 are then translated and retransmitted with new IP headers containing 69 the translated IP address and port number. This works for 70 IPv6-->IPv4 translation, IPv4-->IPv4 translation (e.g., today's 71 Internet), and other variations as well. It is a workable solution 72 (with various second-order difficulties) for enabling outgoing 73 traffic to be delivered into the global Internet. 75 But any business requires global presence and continuous, on-demand 76 availability. The customers have to be able to initiate contact with 77 the business services, not the other way around. Similary for all 78 other online service organizations (including governmental, non- 79 profit, and family websites). 81 One idea for enabling such incoming translations has been proposed, 82 called "source-IP NAT" (SIPNAT). This proposal relies on DNS to 83 establish the required parameters for the flow translation. It has 84 the advantage of dynamic allocation and deallocation of global IPv4 85 addresses for the potentially huge population of internal (say, IPv6) 86 network nodes. This is essential for scalability. The more global 87 IPv4 addresses, the better SIPNAT works. With as few as 128 IPv4 88 addresses, SIPNAT can offer reliability in excess of 99.99%, 89 depending on the arrival rate for new flows, the cohesiveness of each 90 flow, and other details about the statistics of the incoming traffic. 92 There are other protocol-specific mechanisms that can be used to 93 assist with the translation of incoming traffic. For almost all HTTP 94 traffic, the translation can be perfect. For SIP and peer-to-peer 95 traffic, other mechanisms can often be employed. For some traffic, 96 there may not be any additional mechanisms that are conveniently 97 realizable, or even available at all. For example, "ping" and 98 "telnet" do not make available the information needed for the 99 protocol mechanisms in this document. 101 2. Failure cases for SIPNAT 103 SIPNAT relies on DNS Request messages to initialize a pending flow 104 translation. The pending flow translation will become established 105 when the first packet of the flow arrives at the external IP address 106 on the NAT box which has been allocated for that flow. The process 107 of establishment mainly involves inserting the source IP address of 108 that first packet as part of the parameters for the flow translation. 109 This also enables correct synthesis of the translated IPv6 address 110 that will be reported to the destination, and defines the IPv4 source 111 address for responses that are transmitted by the IPv6 destination to 112 be translated by the source-IP NAT. 114 The newly allocated IP address may already be supporting several (or 115 many) existing established flows; at any particular time, SIPNAT 116 requires that only one pending flow translation may await 117 establishment at the allocated IPv4 address. Because of this, SIPNAT 118 (while effective and generally robust) does have failure modes. 120 o The DNS Request does not identify the actual source computer. 121 This means the initial allocation for global Internet address on 122 the NAT cannot be established until a packet arrives from the 123 actual source. It is then possible for a flow translation to be 124 assigned on a global Internet address that already is hosting a 125 previous flow translation for the same requesting source-IP 126 address. In other words, it is possible for a source node, which 127 is already getting service from the NAT at a particular IPv4 128 address, to be accidentally allocated that same IPv4 address for a 129 different internal destination. But, according to the rules of 130 SIPNAT, two different IPv6 destinations for the same global 131 Internet source cannot be translated through the same NAT IPv4 132 address. 134 o Each IPv4 NAT interface to the global Internet can sustain only 135 one pending assignment. If too many new DNS resolutions arrive 136 nearly simultaneously, new flow allocations may temporarily become 137 unavailable. 139 o It is possible for a flow to persist even after the IPv4 address 140 allocated for the flow has timed out. For such flows, incoming 141 packets may be lost. To counter this, flow timeouts should be set 142 as long as possible consistent with the target error rate. This 143 amounts to a trade-off against the likelihood that the same 144 source-IP address will request a new flow before all of its 145 previous flows at the allocated NAT IP address have completed (and 146 their flow translation parameters deactivated) 148 The SIPNAT document describes how to reduce or eliminate these 149 vulnerabilities by appropriate configuration and adjustments for the 150 timeout parameters. The first case is the most difficult case for 151 SIPNAT. Fortunately, according to traffic flows that have been 152 analyzed to date, this almost never happens for small-to-medium scale 153 websites that constitute the main use case for SIPNAT. This case 154 does happen for very large servers, but even then it is rare, and 155 such servers would be more efficiently handled by IVI [3]. 157 3. Using the Payload 159 The basic proposal in this document is to use information contained 160 in the payload to assist in translating the IP header from the global 161 Internet for better-assured delivery to the proper internal host. 162 This goes beyond previous suggestions for careful configuration and 163 management of the NAT interface. 165 For instance, almost all HTTP GET traffic has the host destination 166 host name as part of the HTTP payload: 168 http.host: news.google.com 170 http.host: my-IPv6-server.example-operator.com 172 For all such incoming traffic, translation can be performed with 100% 173 accuracy. Current experience with border routers offering DPI 174 features indicates that the translation can be done at wire speed. 175 It is expected that this one simple observation will, for all 176 practical purposes, eliminate any remaining ambiguities about the 177 delivery of HTTP traffic. 179 Even in the unlikely event that the "http.host" field is not present 180 in the HTTP GET traffic, web traffic offers other possibilities for 181 guiding correct traffic. For example, the pathname of the object 182 webpage is typically unique to the destination. In other words, it 183 is rarely the case that two different destinations in the same domain 184 would use the same pathname to identify any webpages hosted by those 185 destinations. If a database of associations between pathnames and 186 actual destinations is maintained, any such traffic containing the 187 pathname for a destination can be delivered correctly. Information 188 about rare cases where duplicate pathnames occur can also be 189 maintained. Even if the pathname can narrow down the selection to a 190 choice between a few competing websites, the other context for the 191 flow translation will typically be sufficient for accurate delivery. 193 Other protocols, such as SIP, also typically utilize URIs and URLS 194 that provide domain names identifying the desired destination. For 195 each such protocol, the DPI methods required for extracting the 196 destination information will be different, but the principle is the 197 same. 199 4. Peer-to-Peer 201 After HTTP traffic, the next major source of traffic on the Internet 202 is Peer-to-Peer traffic. This is typically filesharing traffic, 203 often using the BitTorrent protocol. In order to understand the 204 interactions of such traffic with SIPNAT, we will use BitTorrent as 205 an example. 207 BitTorrent relies on four different kinds of protocol entities. 209 o Directory of trackers 211 o Trackers 213 o Servers 215 o Clients 217 A client uses some method for finding a tracker that maintains 218 information about servers offering a particular file of interest. 219 Once contact with a tracker is established, the client obtains a list 220 of file segments, and for each file segment, a list of servers that 221 offer availability for that file segment. A client can select one or 222 more servers for each segment of the desired file. If a transfer for 223 a specific file segment from one of the selected servers does not 224 complete, the client can pick another server for that file segment. 225 Eventually, all segments will be collected together for assembly into 226 the complete file of interest. 228 With this as context, it should be considered which configurations 229 are of most interest. For example, consider an IPv6-only server 230 offering segments to clients on the global Internet. In many cases, 231 this sort of service will work just fine, especially if the clients 232 attempt to resolve the server's domain name before issuing the 233 request for the file segment. However, the tracker often supplies 234 the IP address of the server instead of the server's domain name. 235 For such communications, the client would expect to make contact with 236 the server without any intermediate DNS resolution to obtain the IP 237 address of the server. In this case, the SIPNAT would not have the 238 opportunity to allocate the necessary IPv4 address for the flow 239 translation. 241 Nevertheless, it is still possible to handle such incoming traffic, 242 based on detailed methods for inspecting peer-to-peer traffic 243 payloads. This is to be specified in a companion ALG document 244 describing mechanisms for handling IPv4-->IPv6 translation for the 245 lists of servers provided by trackers. One simple solution is just 246 to set up IVI-style network interfaces for the servers. For dynamic 247 allocations of IPv4 network interfaces on the NAT router, additional 248 payload inspection and alterations are needed. 250 5. Other traffic 252 Aside from HTTP, peer-to-peer, and SIP traffic, other protocol 253 services should be considered on a case-by-case basis. 255 For instance, DNS traffic is extremely common on the Internet. 256 However, it is most likely not a suitable candidate for such protocol 257 translations as typically handled by NATs. Therefore, for the 258 purposes of this document, we may consider DNS traffic to be out of 259 scope for the translation problem. 261 Mobile IP signaling is not a good candidate for such protocol 262 translations, because a client is either a Mobile IPv4 mobile node or 263 a Mobile IPv6 mobile node, and there are already methods specified by 264 which a Mobile IPv6 mobile node can access its home agent by way of 265 IPv4 addresses. 267 It needs to be determined whether or not mail servers that have IPv6 268 addresses only should be accessible by way of SIPNAT. It seems more 269 likely, even if they should be accessible at all to the existing IPv4 270 global Internet, they would be either dual-stack already, or else 271 good candidates for assignment of a permanent (IVI-style) IPv4 272 address on the NAT. 274 FTP does not seem to offer a good way to identify the destination by 275 way of the payload-oriented mechanisms described earlier in this 276 document. Such FTP services are better handled by way of IVI-style 277 static address assignment. For most of the cases of interest, file 278 access is more likely mediated by HTTP access instead of FTP, and the 279 remaining cases are typically those more appropriate for static 280 assignment anyway. 282 Telnet is not used very often any more, and anyway is likely to be 283 handled very well by SIPNAT except for cases when the client attempts 284 to contact a destination by using the raw IP address. SIPNAT does 285 not offer a solution for that case. 287 IKEv2 [2] has been designed to work across NAT boundaries. 288 Consequently, it does not require the use of IP addresses as part of 289 the IKEv2 message payload. In the case of SIPNAT, the Notify 290 payloads NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 291 will correctly indicate the presence of address translation. If use 292 of a well-known IPv6 prefix is used to translate the IPv4 address, 293 there may be an opportunity to precisely identify the type of NAT as 294 "SIPNAT". 296 ... think about SSH ... 298 6. Segregation by access type 300 HTTP is a particularly common case that is easy for SIPNAT to handle 301 with the extensions described in this document. For destinations 302 that only offer services by way of HTTP, all traffic can be delivered 303 accurately based on the payload. This means that many different 304 allocations could be made at the same time without danger of 305 ambiguity. Effectively, the restriction for only one pending 306 allocation at a time could be removed. 308 Suppose, then, that there is a special class of destinations that 309 only offer HTTP service. Also suppose that the NAT is equipped to 310 detect the "http.host" field of incoming HTTP GET requests. For 311 every destination in this special class, each DNS Request could 312 return the same IPv4 address in the DNS Reply. The same sort of flow 313 translation would be set up for each HTTP destination assigned to the 314 IPv4 address, but the destination IP address parameter would be 315 determined by the payload, and matched against the initial allocation 316 as determined by the DNS entity. However, packet delivery should 317 still be granted only for destinations that had been allocated to the 318 IPv4 address by way of a preceding DNS request. This eligibility 319 requirement should be a matter of operator policy. For such traffic, 320 the flow timeout parameter could be configured to a much larger 321 value. 323 This scheme could potentially be extended to allow HTTP access to 324 some destinations identified by IP address (not hostname) in URLs. 325 In other words, the pathname is located at a raw IP address instead 326 of the usual domain name for the destination node. For these cases, 327 the payload can be delivered accurately, but no DNS Request would be 328 received to trigger the allocation of a pending flow translation. 330 Such unusual URLs can be supported under the typical configuration 331 choice for HTTP servers as has been described. Again, it is a matter 332 for operator choice whether it should be appropriate to provide that 333 support. Moreover, it is not clear how a source would ever get such 334 a URL with an IPv4 address to represent the IPv6-only destination. 336 7. References 338 7.1. Normative References 340 [1] Perkins, C., "Translating IPv4 to IPv6 based on source IPv4 341 address", draft-perkins-sourceipnat-00 (work in progress), 342 October 2009. 344 7.2. Informative References 346 [2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 347 December 2005. 349 [3] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI 350 Translation Design and Deployment for the IPv4/IPv6 Coexistence 351 and Transition", draft-xli-behave-ivi-02 (work in progress), 352 June 2009. 354 [4] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: 355 DNS extensions for Network Address Translation from IPv6 Clients 356 to IPv4 Servers", draft-ietf-behave-dns64-00 (work in 357 progress), July 2009. 359 Author's Address 361 Charles E. Perkins 362 WiChorus Inc. 363 3590 N. 1st Street, Suite 300 364 San Jose CA 95134 365 USA 367 Email: charliep@computer.org