idnits 2.17.1 draft-ietf-ngtrans-dual-stack-hosts-01.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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 227 has weird spacing: '...tension addre...' == Line 256 has weird spacing: '...tension addre...' == Line 326 has weird spacing: '...tension addre...' -- 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.) -- The document date (June 24, 1999) is 9072 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIIT' ** Obsolete normative reference: RFC 1631 (ref. 'NAT') (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1933 (ref. 'TRANS-MECH') (Obsoleted by RFC 2893) -- Possible downref: Non-RFC (?) normative reference: ref. 'BUMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'NAT-PT' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 June 24, 1999 3 Expires in six month 4 K. Tsuchiya, Hitachi 5 H. Higuchi, Hitachi 6 Y. Atarashi, Hitachi 8 Dual Stack Hosts using the "Bump-in-the-Stack" Technique 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other docu- 24 ments at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in pro- 26 gress." 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 In the especially initial stage of the transition from IPv4 to 37 IPv6, it is hard to provide a complete set of IPv6 applications. 38 This memo proposes a mechanism of dual stack hosts using the tech- 39 nique called "Bump-in-the-Stack" in the IP security area. The 40 mechanism allows the hosts to communicate with other IPv6 hosts 41 using existing IPv4 applications. 43 1. Introduction 45 RFC1933 [TRANS-MECH] specifies transition mechanisms, including 46 dual stack and tunneling, for the initial stage. Hosts and routers 47 with the transition mechanisms are also developed. But there are 48 few applications for IPv6 [IPV6] as compared with IPv4 [IPV4] in 49 which a great number of applications are available. In order to 50 advance the transition smoothly, it is highly desirable to make the 51 availability of IPv6 applications increase to the same level as 52 IPv4. Unfortunately, however, this is expected to take a very long 53 time. 55 This memo proposes a mechanism of dual stack hosts using the tech- 56 nique called "Bump-in-the-Stack" [BUMP] in the IP security area. 57 The technique inserts modules, which snoop data flowing between a 58 TCP/IPv4 module and network card driver modules and translate IPv4 59 into IPv6 and vice versa, into the hosts, and makes them self- 60 translators. When they communicate with the other IPv6 hosts, 61 pooled IPv4 addresses are assigned to the IPv6 hosts internally, 62 but the IPv4 addresses never flow out from them. Moreover, since 63 the assignment is automatically carried out using DNS protocol, 64 users do not need to know whether target hosts are IPv6 ones. That 65 is, this allows them to communicate with other IPv6 hosts using 66 existing IPv4 applications; thus it seems as if they were dual 67 stack hosts with applications for both IPv4 and IPv6. So they can 68 expand the territory of dual stack hosts. Furthermore they can co- 69 exist with other translators because their roles are different. 71 This memo uses the words defined in [IPV4], [IPV6], and [TRANS- 72 MECH]. 74 2. Components 76 Dual stack hosts defined in RFC1933 [TRANS-MECH] need applications, 77 TCP/IP modules and addresses for both IPv4 and IPv6. The proposed 78 hosts in this memo have 3 modules instead of IPv6 applications, and 79 communicate with other IPv6 hosts using IPv4 applications. They are 80 a translator, an extension name resolver and an address mapper. 82 Figure 1 illustrates the structure of the host in which they are 83 installed. 85 +----------------------------------------------------------+ 86 | +----------------------------------------------------+ | 87 | | IPv4 applications | | 88 | +----------------------------------------------------+ | 89 | +----------------------------------------------------+ | 90 | | TCP/IPv4 | | 91 | | +-------------------------------------------+ | 92 | | | +-----------+ +---------+ +------------+ | 93 | | | | extension | | address | | translator | | 94 | | | | name | | mapper | +------------+ | 95 | | | | resolver | | | +------------+ | 96 | | | | | | | | IPv6 | | 97 | +--------+ +-----------+ +---------+ +------------+ | 98 | +----------------------------------------------------+ | 99 | | Network card drivers | | 100 | +----------------------------------------------------+ | 101 +----------------------------------------------------------+ 102 +----------------------------------------------------------+ 103 | Network cards | 104 +----------------------------------------------------------+ 105 Figure. 1 Structure of the proposed dual stack host 107 2.1 Translator 109 It translates IPv4 into IPv6 and vice versa using the IP conversion 110 mechanism defined in [SIIT]. 112 When receiving IPv4 packets from IPv4 applications, it converts 113 IPv4 packet headers into IPv6 packet headers, then fragments the 114 IPv6 packets (because header length of IPv6 is typically 20 bytes 115 larger than that of IPv4), and sends them to IPv6 networks. When 116 receiving IPv6 packets from the IPv6 networks, it works symmetri- 117 cally to the previous case, except that there is no need to frag- 118 ment the packets. 120 2.2 Extension Name Resolver 122 It returns a "proper" answer in response to the IPv4 application's 123 request. 125 The application typically sends a query to a name server to resolve 126 'A' records for the target host name. It snoops the query, then 127 creates another query to resolve both 'A' and 'AAAA' records for 128 the host name, and sends the query to the server. If the 'A' record 129 is resolved, it returns the 'A' record to the application as is. In 130 the case, there is no need for the IP conversion by the translator. 131 If only the 'AAAA' record is available, it requests the mapper to 132 assign an IPv4 address corresponding to the IPv6 address, then 133 creates the 'A' record for the assigned IPv4 address, and returns 134 the 'A' record to the application. 136 NOTE: This action is similar to that of the DNS ALG (Application 137 Layer Gateway) used in [NAT-PT]. See also [NAT-PT]. 139 2.3 Address mapper 141 It maintains an IPv4 address spool. The spool, for example, con- 142 sists of private addresses [PRIVATE]. Also, it maintains a table 143 which consists of pairs of an IPv4 address and an IPv6 address. 145 When the resolver or the translator requests it to assign an IPv4 146 address corresponding to an IPv6 address, it selects and returns an 147 IPv4 address out of the spool, and registers a new entry into the 148 table dynamically. The registration occurs in the following 2 149 cases: 151 (1) When the resolver gets only an 'AAAA' record for the target 152 host name and there is not a mapping entry for the IPv6 153 address. 154 (2) When the translator receives an IPv6 packet and there is not a 155 mapping entry for the IPv6 source address. 157 NOTE: There is only one exception. When initializing the table, 158 it registers a pair of its own IPv4 address and IPv6 address 159 into the table statically. 161 3. Action Examples 163 This section describes action of the proposed dual stack host 164 called "dual stack," which communicates with an IPv6 host called 165 "host6" using an IPv4 application. 167 3.1 Originator behavior 169 This subsection describes the originator behavior of "dual stack." 170 The communication is triggered by "dual stack." 171 The application sends a query to its name server to resolve 'A' 172 records for "host6." 174 The resolver snoops the query, then creates another query to 175 resolve both 'A' and 'AAAA' records for the host name, and sends it 176 to the server. In this case, only the 'AAAA' record is resolved, so 177 the resolver requests the mapper to assign an IPv4 address 178 corresponding to the IPv6 address. 180 NOTE: In the case of communication with an IPv4 host, the 'A' 181 record is resolved and then the resolver returns it to the 182 application as is. There is no need for the IP conversion as 183 shown later. 185 The mapper selects an IPv4 address out of the spool and returns it 186 to the resolver. 188 The resolver creates the 'A' record for the assigned IPv4 address 189 and returns it to the application. 191 NOTE: See subsection 4.3 about the influence on other hosts caused 192 by an IPv4 address assigned here. 194 The application sends an IPv4 packet to "host6." 196 The IPv4 packet reaches the translator. The translator tries to 197 translate the IPv4 packet into an IPv6 packet but does not know how 198 to translate the IPv4 destination address and the IPv4 source 199 address. So the translator requests the mapper to provide mapping 200 entries for them. 202 The mapper checks its mapping table and finds entries for each of 203 them, and then returns the IPv6 destination address and the IPv6 204 source address to the translator. 206 NOTE: The mapper will register its own IPv4 address and IPv6 207 address into the table beforehand. See subsection 2.3. 209 The translator translates the IPv4 packet into an IPv6 packet then 210 fragments the IPv6 packet if necessary and sends it to an IPv6 net- 211 work. 213 The IPv6 packet reaches "host6." Then "host6" sends a new IPv6 214 packet to "dual stack." 215 The IPv6 packet reaches the translator in "dual stack." 217 The translator gets mapping entries for the IPv6 destination 218 address and the IPv6 source address from the mapper in the same way 219 as before. 221 Then the translator translates the IPv6 packet into an IPv4 packet 222 and tosses it up to the application. 224 The following diagram illustrates the action described above: 226 "dual stack" "host6" 227 IPv4 TCP/ extension address translator IPv6 228 appli- IPv4 name mapper 229 cation resolver 230 | | | | | | | 231 <> | | 232 | | | | | | | 233 |------|------>| Query of 'A' records for "host6". | Name 234 | | | | | | | Server 235 | | |---------|-------|-----------|---------|--->| 236 | | | Query of 'A' records and 'AAAA' for "host6" 237 | | | | | | | | 238 | | |<--------|-------|-----------|---------|----| 239 | | | Reply only with 'AAAA' record. | 240 | | | | | | | 241 | | |<> | 242 | | | | | | | 243 | | |-------->| Request one IPv4 address | 244 | | | | corresponding to the IPv6 address. 245 | | | | | | | 246 | | | |<> | 247 | | | | | | | 248 | | |<--------| Reply with the IPv4 address. 249 | | | | | | | 250 | | |<> 251 | | | | | | | 252 |<-----|-------| Reply with the 'A' record. | | 253 | | | | | | | 254 Figure 2 Action of the originator (1/2) 255 "dual stack" "host6" 256 IPv4 TCP/ extension address translator IPv6 257 appli- IPv4 name mapper 258 cation resolver 259 | | | | | | | 260 <>| | | 261 | | | | | | | 262 |======|=======|=========|======>| An IPv4 packet. | 263 | | | | | | | 264 | | | |<------| Request IPv6 addresses 265 | | | | | corresponding to the IPv4 266 | | | | | addresses. | 267 | | | | | | | 268 | | | |------>| Reply with the IPv6| 269 | | | | | addresses. | 270 | | | | | | | 271 | | | | |<> 272 | | | | | | | 273 | | |An IPv6 packet. |===========|========>| 274 | | | | | | | 275 | | | | <> | 277 | | | | | | | 278 | | |An IPv6 packet. |<==========|=========| 279 | | | | | | | 280 | | | | |<> 281 | | | | | | | 282 |<=====|=======|=========|=======| An IPv4 packet. | 283 | | | | | | | 284 Figure 2 Action of the originator (2/2) 286 3.2 Recipient behavior 288 This subsection describes the recipient behavior of "dual stack." 289 The communication is triggered by "host6." 291 "host6" resolves the 'AAAA' record for "dual stack" through its 292 name server, and then sends an IPv6 packet to the IPv6 address. 294 The IPv6 packet reaches the translator in "dual stack." 296 The translator tries to translate the IPv6 packet into an IPv4 297 packet but does not know how to translate the IPv6 destination 298 address and the IPv6 source address. So the translator requests the 299 mapper to provide mapping entries for them. 301 The mapper checks its mapping table with each of them and finds a 302 mapping entry for the IPv6 destination address. 304 NOTE: The mapper will register its own IPv4 address and IPv6 305 address into the table beforehand. See subsection 2.3. 307 But there is not a mapping entry for the IPv6 source address, so 308 the mapper selects an IPv4 address out of the spool for it, and 309 then returns the IPv4 destination address and the IPv4 source 310 address to the translator. 312 NOTE: See subsection 4.3 about the influence on other hosts 313 caused by an IPv4 address assigned here. 315 The translator translates the IPv6 packet into an IPv4 packet and 316 tosses it up to the application. 318 The application sends a new IPv4 packet to "host6." 320 The following behavior is the same as that described in subsection 321 3.1. 323 The following diagram illustrates the action described above: 325 "dual stack" "host6" 326 IPv4 TCP/ extension address translator IPv6 327 appli- IPv4 name mapper 328 cation resolver 329 | | | | | | | 330 <> | | | 331 | | | | | | | 332 | | |An IPv6 packet. |<==========|=========| 333 | | | | | | | 334 | | | |<------| Request IPv4 addresses 335 | | | | | corresponding to the IPv6 336 | | | | | addresses. | 337 | | | | | | | 338 | | | |------>| Reply with the IPv4| 339 | | | | | addresses. | 340 | | | | | | | 341 | | | | |<> 342 | | | | | | | 343 |<=====|=======|=========|=======| An IPv4 packet. | 344 | | | | | | | 345 <> | | 346 | | | | | | | 347 |======|=======|=========|======>| An IPv4 packet. | 348 | | | | | | | 349 | | | | |<> 350 | | | | | | | 351 | | |An IPv6 packet. |===========|========>| 352 | | | | | | | 353 Figure 3 Action of the recipient 355 4. Considerations 357 This section considers some issues of the proposed dual stack 358 hosts. 360 4.1 IP conversion 362 In common with NAT [NAT], IP conversion needs to translate IP 363 addresses embedded in application layer protocols, which are typi- 364 cally found in FTP [FTP]. So it is hard to translate all such 365 applications completely. 367 4.2 IPv4 address spool and mapping table 369 The spool, for example, consists of private addresses [PRIVATE]. So 370 a large address space can be used for the spool. Nonetheless, IPv4 371 addresses in the spool will be exhausted and cannot be assigned to 372 IPv6 target hosts, if the host communicates with a great number of 373 other IPv6 hosts and the mapper never frees entries registered into 374 the mapping table once. To solve the problem, for example, it is 375 desirable for the mapper to free the oldest entry in the mapping 376 table and re-use the IPv4 address for creating a new entry. 378 4.3 Internally assigned IPv4 addresses 380 IPv4 addresses, which are internally assigned to IPv6 target hosts 381 out of the spool, never flow out from the host, and so do not nega- 382 tively affect other hosts. 384 5. References 386 [SIIT] Erik Nordmark, "Stateless IP/ICMP Translator (SIIT)", 387 Internet-Draft, Work in Progress, January 1999. 389 [IPV4] J. Postel, "Internet Protocol", RFC 791, September 1981. 391 [FTP] J. Postel, J.K. Reynolds, "File Transfer Protocol", RFC959, 392 October 1985. 394 [NAT] Kjeld Borch Egevang and Paul Francis, "The IP Network Address 395 Translator (NAT)", RFC1631, May 1994. 397 [IPV6] S. Deering and R. Hinden, "Internet Protocol, Version 6 398 (IPv6) Specification", RFC 2460, December 1998. 400 [PRIVATE] Y. Rekhter, B. Moskowitz, D. Karrenberg, 401 G. J. de Groot and E. Lear, "Address Allocation for 402 Private Internets", RFC1918, February 1996. 404 [TRANS-MECH] R. Gilligan and E. Nordmark, "Transition Mechanisms 405 for IPv6 Hosts and Routers", RFC 1933, April 1996. 407 [BUMP] D.A. Wagner and S.M. Bellovin, "A Bump in the Stack 408 Encryptor for MS-DOS Systems", The 1996 Symposium on Network 409 and Distributed Systems Security (SNDSS'96) Proceedings. 411 [NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation - 412 Protocol Translation (NAT-PT)", Internet-Draft, Work in 413 Progress, February 1999. 415 6. Acknowledgements 417 The authors gratefully acknowledge the many helpful suggestions of 418 the members of the WIDE Project, Kazuhiko YAMAMOTO, Jun MURAI, 419 Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO, at large. 421 7. Authors' Addresses 423 Kazuaki TSUCHIYA 424 Enterprise Server Division, Hitachi, Ltd. 425 810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN 427 Phone: +81-462-32-2121 428 Fax: +81-462-35-8324 429 Email: tsuchi@ebina.hitachi.co.jp 431 Hidemitsu HIGUCHI 432 Enterprise Server Division, Hitachi, Ltd. 433 810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN 435 Phone: +81-462-32-2121 436 Fax: +81-462-35-8324 437 Email: h-higuti@ebina.hitachi.co.jp 439 Yoshifumi ATARASHI 440 Enterprise Server Division, Hitachi, Ltd. 441 810 Shimoimaizumi, Ebina-shi, Kanagawa-ken, 243-0435 JAPAN 443 Phone: +81-462-32-2121 444 Fax: +81-462-35-8324 445 Email: atarashi@ebina.hitachi.co.jp 447 Changes 449 From 00 to 01: 450 - Updating references 451 - Referring to NAT-PT 452 - Replacing "migration" with "transition"