idnits 2.17.1 draft-nat46compare-perkins-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2010) is 5160 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: '5' is defined on line 293, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-xli-behave-ivi-02 ** Downref: Normative reference to an Informational draft: draft-xli-behave-ivi (ref. '2') == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-07 ** Downref: Normative reference to an Informational draft: draft-ietf-behave-v6v4-framework (ref. '3') == Outdated reference: A later version (-01) exists of draft-xli-behave-xlate-partial-state-00 ** Downref: Normative reference to an Informational draft: draft-xli-behave-xlate-partial-state (ref. '4') == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-00 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: September 9, 2010 X. Li 5 C. Bao 6 CERNET Center/Tsinghua University 7 March 8, 2010 9 Comparison and integration of IVI, IVI+DHCP, 1:N IVI and SIPNAT 10 draft-nat46compare-perkins-01.txt 12 Abstract 14 IVI, IVI + DHCPv6, 1:N IVI, Bidirectional NAT, and SIPNAT have been 15 proposed to global Internet access to IPv6-only domains. These 16 methods are not all mutually exclusive, and we propose that IVI 17 (along with its variants) along with SIPNAT may be considered 18 together as a more complete solution for enabling access from today's 19 IPv4 global Internet into IPv6-only domains. This would likely have 20 the effect of accelerating the adoption of IPv6, since with such 21 access enablements there would be much reduced incentive for new 22 deployments to require IPv4 addressability. As part of the 23 discussion, we also include a comparison of the various techniques so 24 the relative trade-offs may be more easily understood. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 9, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 1. Introduction 66 IVI [2], 1:N IVI [4], and SIPNAT [1] have been proposed to enable 67 communications to be initiated from today's IPv4-based Internet and 68 successfully terminated at IPv6-only devices. This is important so 69 that IPv6-only devices will be fully functional and reachable in 70 today's IPv4 Internet. 72 In particular, it is not enough to only support outgoing connections 73 (i.e., connections initiated by the IPv6 network device not directly 74 reachable from today's IPv4 Internet). For many purposes, it is 75 required to support incoming connections. Businesses need to serve 76 communications from their clients, which almost always seem to 77 emanate from the global IPv4 Internet. This means that such 78 communications have to be admissible even when the target computer 79 (in the internal domain) has not triggered the setup operations at 80 the border router which are typically required for operations such as 81 NAT to work. Such communications, which are initiated from sites 82 external to the site hosting the IPv6-only destination are classified 83 as belonging to "Scenario 2" or "Scenario 4" [3] 85 With traditional port-mapped NAT (NAPT), this has not been possible 86 because, for each source-destination flow, the translation parameters 87 for the flow have had to be established by the internal network node 88 (i.e., the node with the IP address that is incompatible with the 89 addressing domain of the global Internet). In particular, for each 90 such flow there needs to be an external IP address and an external 91 port assigned. Packets arriving at the external IP address and port 92 are then translated and retransmitted with new IP headers containing 93 the translated IP address and port number. This works for 94 IPv6-->IPv4 translation, IPv4-->IPv4 translation (e.g., today's 95 Internet), and other variations as well. It is a workable solution 96 (with various second-order difficulties) for enabling outgoing 97 traffic to be delivered into the global Internet. 99 But any business requires global presence and continuous, on-demand 100 availability. The customers have to be able to initiate contact with 101 the business services, not the other way around. Similarly for all 102 other online service organizations (including governmental, non- 103 profit, and family websites). 105 2. Proposals for supporting Scenario 2 and Scenario 4 communications 107 To enable such incoming translations IVI [2] (along with several 108 variations for improved scalability) and "source-IP NAT" (SIPNAT)[1] 109 have been proposed. It is not the purpose of this document to 110 reiterate the individual designs. Instead, we exhibit the 111 characteristics of each proposal in such a way that it is easier to 112 identify the best translation technique according to the needs of the 113 specific IPv6-only destinations. For some destinations that 114 experience persistent high-volume traffic, IVI is best. For some 115 destinations that support significant traffic which is variable from 116 time to time, IVI+DHCP is best. For destinations that host certain 117 appropriate applications, 1:N IVI may be best. For some other 118 destinations hosting relatively lower-volume websites, SIPNAT may be 119 best. 121 IVI 123 IVI [2] statically reserves an IPv4 address on the translator for 124 each IPv6 destination which is to be made reachable to the global 125 IPv4 Internet. This is done via a one-to-one mapping algorithm 126 between IPv4 and IPv6 addresses. The IPv4 address can only be 127 used by the single IPv6 destination. 129 IVI + DHCP 131 (IVI + DHCP) uses DHCP to dynamically reserve an IPv4 address on 132 the translator, and as part of the reservation process updates the 133 DNS so that the allocated address is returned for the IPv6 134 destination to be made reachable. At any one time, the IPv4 135 address can only be used by the single IPv6 destination, but the 136 IPv4 address can be reused for another IPv6 destination depending 137 on the DHCP lifetime allocation policies. 139 1:N IVI 141 1:N IVI [4] statically reserves an IPv4 address and a port range 142 (either high or low) on the translator for each IPv6 destination 143 which is to be made reachable to the global IPv4 Internet. For 144 example, this could be done by preconfiguration The IPv4 address 145 and port range and can only be used by the single IPv6 146 destination. DHCP could be extended for this purpose to also 147 return the port range when the IPv4 reservation is made. This 148 would allow temporal sharing for the address and port range. 150 SIPNAT 152 SIPNAT ("Source-IP NAT") dynamically associates an IPv4 address on 153 the translator, on demand, when a communication is initiated from 154 the global IPv4 Internet. The FQDN of the destination IPv6 does 155 not typically have a persistent resolution for any particular IPv4 156 address. A single IPv4 address of the translator can be 157 simultaneously used for flows to many different IPv6 destinations. 158 The source IPv4 address of incoming packets is used to identify 159 the desired IPv6 destination. For any such source IPv4 address, 160 only one destination is reachable at the translator's IPv4 161 interface address which as been associated with the IPv6 162 destination. Ports are not required for the translation, but 163 should be considered as part of of the set of flow translation 164 parameters. 166 The authors believe that all of these approaches have interesting use 167 cases and should be coordinated into an overall solution. 169 o IVI is a good solution for destinations that serve many flows, and 170 are each typically active serving one or more flows from the IPv4 171 Internet. In this case, there is little or no advantage to be 172 gained by dynamic assignment. 174 o IVI + DHCP is a good solution for destinations that may be 175 inactive for extended periods of time, but are also likely to 176 serve many flows during other extended periods of time. 178 o 1:N IVI is a good solution which may be workable for situations 179 where destinations host applications that are resilient and aware 180 of port restrictions. 182 o SIPNAT is a good solution for situations where there are a large 183 number of IPv6 destinations, each of which serves a relatively low 184 volume of flows (e.g, fewer than 100 distinct flows per hour). 186 3. Work to be done 188 The usefulness of this integrated solution set depends upon 189 establishing policies for partitioning the available IPv4 addresses 190 of the translator according to persistence of IPv4 address and the 191 persistence of the FQDN resolution. For sites requiring full 192 persistence, IVI should be used. Sites serving a continual stream of 193 new flow requests fit within this classification. For sites 194 requiring persistence of association between FQDN and IPv4 address, 195 (IVI + DHCP) should be used. Sites which sometimes serve a high 196 volume of flow requests, but at other times are quiescent, fit this 197 second classification. Sites which serve flows less frequently 198 (e.g., approximately 1 per minute or so) can be served by SIPNAT. 200 The exact percentages and flow rates for these classifications remain 201 to be determined. As experienced is acquired in the management of 202 larger domains, better estimates for economical allocations of IPv4 203 addresses will become feasible. In general, the more IPv4 addresses 204 that are available on the translator, the better. But, on the other 205 hand, the fewer IPv4 addresses required, the better. Soon, the IPv4 206 address space will be exhausted and it is important to improve as 207 much as possible the utilization of this valuable resource. 209 The partitioning of the translator's IPv4 address space is to be made 210 between IVI, (IVI+DHCP), and SIPNAT. This partitioning may be 211 static, based on observed traffic characteristics. As our 212 understanding improves, we suggest that the partitioning itself 213 should be made dynamic. For instance, if a particular website grows 214 in popularity so that it is constantly serving new flow requests, it 215 may be advisable to remove it from SIPNAT handling by assigning a 216 permanent IVI address on the NAT IPv4 interface. Conversely, a 217 particular IVI website may be partitioned into multiple destinations, 218 each of which might have lower traffic volume and therefore require a 219 lower persistence of addressability, potentially served well by (IVI 220 + DHCP) or SIPNAT. Many variations are likely to be found useful. 222 4. Comparison Chart 224 The comparison chart is made based on the following characteristics: 226 Translator complexity 228 Stateless 230 DNS decoupled 232 Conserves IPv4 addresses 234 Application Port Transparency 236 Continuous service (vs. dynamic assignment) 238 =================================================================== 239 | | Stateless | Conserves | Port xlate | 240 | | | Decoupled | App Transp. | Cont. | 241 =================================================================== 242 1:1 IVI | Y | Y | N | Y | N | Y | 243 ------------------------------------------------------------------- 244 1:1 IVI+DHCP | Y | Y | Y | Y | N | N | 245 ------------------------------------------------------------------- 246 1:N IVI | Y | Y | Y | N | Y | Y | 247 ------------------------------------------------------------------- 248 Bidirectional NAPT| N | N | Y | N | Y | N | 249 ------------------------------------------------------------------- 250 SIPNAT | N | N | Y | Y | N | N | 251 =================================================================== 252 where: 253 "Decoupled" means "Decoupled from DNS" 254 "Conserves" means "Conserves IPv4 Addresses" 255 "App Transp." means "Application Transparency" 256 "Port xlate" means "Ports are translated" 257 "Cont." means "Continuous service at all times" 259 Figure 1: Comparison of approaches 261 5. Summary 263 Several solutions have been proposed for the cases denoted as 264 "Scenario 2" and "Scenario 4". We have found that these solutions 265 can be coordinated as described in this document, and propose that 266 our solutions be considered together for standardization in 267 fulfillment of the requirement. 269 6. References 271 6.1. Normative References 273 [1] Perkins, C., "Translating IPv4 to IPv6 based on source IPv4 274 address", draft-perkins-sourceipnat-01 (work in progress), 275 October 2009. 277 [2] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI 278 Translation Design and Deployment for the IPv4/IPv6 Coexistence 279 and Transition", draft-xli-behave-ivi-02 (work in progress), 280 June 2009. 282 [3] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 283 Translation", draft-ietf-behave-v6v4-framework-07 (work in 284 progress), February 2010. 286 [4] Li, X. and C. Bao, "Stateless/Partial-state 1:N Network Address 287 and Protocol Translation between IPv4 and IPv6 nodes", 288 draft-xli-behave-xlate-partial-state-00 (work in progress), 289 March 2010. 291 6.2. Informative References 293 [5] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: 294 DNS extensions for Network Address Translation from IPv6 Clients 295 to IPv4 Servers", draft-ietf-behave-dns64-00 (work in 296 progress), July 2009. 298 Authors' Addresses 300 Charles E. Perkins 301 WiChorus Inc. 302 3590 N. 1st Street, Suite 300 303 San Jose CA 95134 304 USA 306 Email: charliep@computer.org 308 Xing Li 309 CERNET Center/Tsinghua University 310 Room 225, Main Building, Tsinghua University 311 Beijing 100084 312 China 314 Email: xing@cernet.edu.cn 316 Congxiao Bao 317 CERNET Center/Tsinghua University 318 Room 225, Main Building, Tsinghua University 319 Beijing 100084 320 China 322 Email: congxiao@cernet.edu.cn