idnits 2.17.1 draft-ietf-ngtrans-translator-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. ** The abstract seems to contain references ([INET]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2767 (ref. 'BIS') (Obsoleted by RFC 6535) ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2401 (ref. 'IPsec') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1631 (ref. 'NAT') (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 2766 (ref. 'NATPT') (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2765 (ref. 'SIIT') (Obsoleted by RFC 6145) Summary: 15 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft K. Yamamoto 3 IIJ Research Laboratory 4 Expires in six months M. Sumikawa 5 Category: Informational Hitachi, Ltd. 6 March, 2000 8 Overview of Transition Techniques 9 for IPv6-only to Talk to IPv4-only Communication 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet- Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This memo discusses translators to enable direct communication 37 between IPv4 hosts and IPv6 hosts. Three translation mechanisms are 38 described. From the address mapping point of view, the translators 39 are categorized into four types and each feasibility is considered. 40 This memo is based on a paper appeared in Proceedings of 41 INET98[INET]. 43 1. Introduction 45 In the early stage of the migration from IPv4[IPv4] to IPv6[IPv6], 46 it is expected that IPv6 sites will be connected to the IPv4 47 Internet. On the other hand, in the late stage of the migration, 48 IPv4 sites will be connected to the IPv6 Internet. IPv4 hosts need 49 to be connected to the Internet even after the IPv4 address space 50 is exhausted. So, it is necessary to develop translators to enable 51 direct communication between IPv4 hosts and IPv6 hosts. 53 This memo assumes the following for the practical migration scenario 54 from IPv4 to IPv6: 56 (1) We cannot modify both IPv4 hosts and IPv6 hosts in typical 57 environments. 59 (2) A small space of IPv4 address is also assigned to an IPv6 60 site according to the current severe address assignment 61 policy. 63 (3) An IPv4 site can also obtain a large space of IPv6 64 address. 66 In this memo, the word "translator" is used as an intermediate 67 component between an IPv4 host and an IPv6 host to enable direct 68 communication between them, without requiring any modifications to 69 them according to the assumption (1) above. 71 This memo is organized as follows: Three translation techniques are 72 described in Section 2. Address mapping between IPv4 and IPv6 is 73 discussed in Section 3. 75 Both SIIT[SIIT] and SOCKS[SOCKS] are a kind of translator between 76 IPv4 and IPv6. This memo, however, does not cover such 77 technologies because they require specific modifications to IPv4 78 and/or IPv6 hosts. BIS[BIS] is a technology to make an IPv4 host 79 be dual-stack. So, BIS is outside the scope of this memo. 81 2. Translation Techniques of IPv4 and IPv6 83 For translation between IPv4 and IPv6, three technologies are 84 available: header conversion, transport relay, and application 85 level gateway(ALG). 87 2.1 Header Conversion 89 Header conversion refers to converting IPv6 packet headers to IPv4 90 packet headers, or vice versa, and adjusting (or re-calculating) 91 checksums if necessary. This is IP level translation. (Note that 92 NAT[NAT] is an IPv4-to-IPv4 header converter.) 94 The procedure to translate IPv4 packets to IPv6 packets, or vice 95 versa, is defined as a part of SIIT. NATPT[NATPT] (excluding its 96 ALG portion) is an example this kind of translator, which is based 97 on SIIT. (Note that generic concerns about header translation were 98 originally raised in [IPNGWP]. ) 100 Header conversion could be fast enough, but it has disadvantages in 101 common with NAT. A good example is difficulty in the translation of 102 network layer addresses embedded in application layer protocols, 103 which are typically found in FTP and FTP Extensions[EFTP]. 105 Also, header conversion has problems which are not found in NAT: a 106 large IPv4 packet is fragmented to IPv6 packets because the header 107 length of IPv6 is typically 20 bytes larger than that of IPv4. Also 108 not all the semantics of ICMP[ICMP] and that of ICMPv6[ICMPv6] are 109 inter-changeable. However, the latter problem is believed minor in 110 practical cases. 112 2.2 Transport Relay 114 Transport relay refers to relaying a {TCP, UDP}/IPv4 session and a 115 {TCP, UDP}/IPv6 session in the middle. This is transport level 116 translation. 118 For example, a typical TCP relay server works as follows: when a 119 TCP request reaches a relay server, the network layer tosses it up 120 to the TCP layer even if the destination is not the server's 121 address. The server accepts this TCP packet and establishes a TCP 122 connection with the source host. Then the server also makes one 123 more TCP connection to the real destination. When two connections 124 are established, the server reads data from one of the two 125 connections and writes the data to the other. 127 Transport relay does not have problems like fragmentation or ICMP 128 conversion, since each session is closed in IPv4 and IPv6, 129 respectively, but it does have problems like the translation of 130 network layer addresses embedded in application layer protocols. 132 2.3 Application Level Gateway (ALG) 134 An ALG for a transaction service is used to hide site information 135 and improve service performance with a cache mechanism. An ALG can 136 be a translator between IPv4 and IPv6 if it supports both 137 protocols. This is application level translation. 139 Since each service is closed in IPv4 and IPv6, respectively, there 140 are no disadvantages found in header conversion, but ALGs for each 141 service must be capable of running over both IPv4 and IPv6 143 3. Address Mapping 145 Address mapping refers to the allocation of an IPv6 destination 146 address for a given IPv4 destination address, and vice versa. It 147 also includes the allocation of an IPv6 source address for a given 148 IPv4 source address, and vice verca. If translation is performed 149 at the Internet protocol level or transport level, address mapping 150 is an essential issue. 152 If an FQDN(Fully Qualified Domain Name) is used to specify a 153 target host, address mapping is not necessary. So, the ALG is free 154 of this problem. 156 In the case that address mapping is dynamic, it must be 157 implemented in interaction with DNS. If it is static and 158 proliferation of mapped addresses is limited to a small 159 region(i.e. Translator A, described later), it can be implemented 160 by extending resolver libraries on local hosts. However, this 161 violates the assumption (1). So, it is recommended that DNS is 162 used for address mapping even in the static case. 164 Examples: 166 An example of static mapping: suppose that an application tries 167 resolving AAAA/A6[A6] records against a host name. A DNS server 168 receives this query but it can resolve only A record. In this 169 case, the server converts them to AAAA/A6 records embedding them 170 into the pre-configured prefix. Then it returns these records to 171 the application. ([NATPT] also discusses this mechanism.) 173 An example of dynamic mapping: if a DNS server receives a 174 request to return A records for a host name, but only an AAAA/A6 175 record is resolved, the server picks up an IPv4 address from its 176 address pool then returns it as A record. 178 There are two criteria for addresses to be assigned: (1) the 179 assigned addresses must be reachable between a connection initiating 180 host and a translator, and (2) if addresses are assigned dynamically 181 by DNS, it must be ensured that the DNS cache doesn't cause problems 182 for further communications. 184 If transport relay is used for translation, address mapping is 185 necessary only for destination addresses since source address 186 mapping is closed in the relay server. In other words, the protocol 187 association of the first transport session is mapped to a local port 188 number on the relay server. 190 For header conversion, source address mapping is not essential, 191 either. A protocol association can be represented by a local port of 192 the conversion router or by an address out of the pool or by both. 194 3.1. Translator Categories 196 This memo categorizes IPv4/IPv6 translators from the address mapping 197 point of view. The first picture illustrates the Internet in the 198 early stage of the migration. The second one does that in the late 199 stage. 201 In the early stage 203 +----------------------+ 204 +-------------+ Translator A | | 205 | |--------------->| | 206 | IPv6 site | | The IPv4 Internet | 207 | |<---------------| | 208 +-------------+ Translator B | | 209 +----------------------+ 211 In the late stage 213 +----------------------+ 214 +-------------+ Translator C | | 215 | |--------------->| | 216 | IPv4 site | | The IPv6 Internet | 217 | |<---------------| | 218 +-------------+ Translator D | | 219 +----------------------+ 221 For simplicity, IPv4/IPv6 translators are categorized into four 222 types. Note that practical translation stories could be combination 223 of these four types. 225 Translator A: It is used in the early stage of transition to 226 establish a connection from an IPv6 host in an IPv6 site 227 to an IPv4 host in the IPv4 Internet. 229 Translator B: It is used in the early stage of transition to 230 establish a connection from an IPv4 host in the IPv4 Internet 231 to an IPv6 host in an IPv6 site. 233 Translator C: It is used in the late stage of transition to 234 establish a connection from an IPv4 host in an IPv4 site 235 to an IPv6 host in the IPv6 Internet. 237 Translator D: It is used in the late stage of transition to 238 establish a connection from an IPv6 host in the IPv6 Internet 239 to an IPv4 host in an IPv4 site. 241 3.2. Observations on Address Mapping for Each Translator 243 Here are observations on address mapping for each translator: 245 Translator A: 246 Destination address mapping: global IPv4 to global IPv6 247 Static or dynamic: static 248 Address pool: a part of assigned global IPv6 addresses 249 to the IPv6 site 250 DNS cache problem: not encountered 251 Implementation: straightforward 252 Note: IPv4 addresses can be embedded to pre-configured IPv6 253 prefix. 255 Translator B: 256 Destination address mapping: global IPv6 to global IPv4 257 Static or dynamic: dynamic 258 Address pool: assigned global IPv4 addresses to the IPv6 site 259 DNS cache problem: potentially proliferated into the IPv4 Internet 260 Implementation: very hard 261 Note: it is recommended to use static address mapping for 262 several IPv6 hosts(servers) in the IPv6 site to provide 263 their services to the IPv4 Internet or to use dual-stack 264 servers without translators. 266 Translator C: 267 Destination address mapping: global IPv6 to private IPv4 268 Static or dynamic: dynamic 269 Address pool: a part of private IPv4 addresses 270 DNS cache problem: closed to the IPv4 site 271 Implementation: possible 272 Note: mapped addresses should be reserved as long as possible 273 for UDP applications which can't tell the end of 274 communications and for applications which cache DNS entries. 276 Translator D: 277 Destination address mapping: global IPv4 to global IPv6 278 Static or dynamic: static 279 Address pool: assigned global IPv6 addresses to the site 280 DNS cache problem: not encountered 281 Implementation: straightforward 282 Note: IPv4 addresses can be embedded to pre-configured IPv6 283 prefix. 285 Security Consideration 287 When one or more IPv4/IPv6 translators are used in the intermediate 288 path of an IPv4 host and an IPv6 host, end-to-end authentication 289 mechanisms based on IPv4 and/or IPv6 address (including 290 IPsec[IPsec]) is not available. This problem is well-known in the 291 case of NAT. 293 References 295 [A6] M. Crawford, C. Huitema and S. Thomson, "DNS Extensions to 296 Support IP Version 6", , 297 1999 299 [BIS] K. Tsuchiya, H. Higuchi and Y. Atarashi, "Dual Stack Hosts 300 using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, 2000. 302 [EFTP] M. Allman, S. Ostermann, and C. Metz, "FTP Extensions for 303 IPv6 and NATs", RFC 2428, 1998. 305 [ICMP] J. Postel, "Internet Control Message Protocol", RFC 792, 306 1981. 308 [ICMPv6] A. Conta and S. Deering, "Internet Control Message Protocol 309 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 310 Specification", RFC 2463, 1998. 312 [INET] K. Yamamoto, A. Kato, M Sumikawa, and J. Murai, "Deployment 313 and Experiences of WIDE 6bone", in Proceedings of INET98, 1998. 315 [IPNGWP] B. Carpenter, "IPng White Paper on Transition and Other 316 Considerations", RFC 1671, 1994. 318 [IPsec] S. Kent and R. Atkinson, "Security Architecture for the 319 Internet Protocol", RFC 2401, 1998. 321 [IPv4] J. Postel, "Internet Protocol", RFC 791, 1981. 323 [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 324 (IPv6) Specification", RFC 2460, 1998 326 [NAT] K. Egevang and P. Francis, "The IP Network Address Translator 327 (NAT)", RFC 1631, 1994. 329 [NATPT] G. Tsirtsis and P. Srishuresh, "Network Address Translation - 330 Protocol Translation (NAT-PT)", RFC 2766, 2000. 332 [SIIT] E. Nordmark, "Stateless IP/ICMP Translator (SIIT)", 333 RFC 2765, 2000. 335 [SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and 336 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1996. 338 Acknowledgements 340 The authors would like to thank many people for their contributions 341 to this memo, especially Rundy Bush, Brian Carpenter, Shin-ichi 342 Fujisawa, Jun-ichiro Ito, Akira Jinzaki, Akira Kato, Atsushi Onoe, 343 Kazushi Sugyo, and Shigeya Suzuki (in alphabetical order). 345 Authors' Addresses 347 Kazuhiko YAMAMOTO 348 Research Laboratory, Internet Initiative Japan Inc. 349 Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho Chiyoda-ku, Tokyo 350 101-0054 JAPAN 352 Phone: +81-3-5259-6350 353 FAX: +81-3-5259-6351 354 EMail: kazu@iijlab.net 356 Munechika Sumikawa 357 Hitachi, Ltd. 358 1 Horiyamashita, Hadano city, Kanagawa 359 259-1392 JAPAN 361 Phone: +81-463-88-1311 362 FAX: +81-463-88-8062 363 EMail: sumikawa@ebina.hitachi.co.jp 365 Changes 367 From 02 to 03: 368 - The title changed from "Categorizing Translators between IPv4 369 and IPv6" to "Overview of Transition Techniques for 370 IPv6-only to Talk to IPv4-only Communication". 371 - The word "translator" is explicitly defined. 372 - Even in the case of static mapping, DNS is recommended for the 373 address mapping. 374 - Both SIIT and SOCKS are now outside of the scope. 375 - The assumption (1) is changed: IPv6 hosts cannot be modified, 376 either. 377 - Updating references 378 - Sumikawa's address is changed. 380 From 01 to 02: 381 - Updating references 382 - Refering RFC 1671 383 - Adding the case of A6 records 384 - Adding security consideration 386 From 00 to 01: 387 - Updating references 388 - Refering to NATPT 389 - Replacing TCP relay with transport relay to generalize 390 - Clarify that the library extensions can be used only for 391 Translator A.