idnits 2.17.1 draft-huang-behave-rfc3338bis-02.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 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.) ** The abstract seems to contain references ([RFC3338]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC3338, but the abstract doesn't seem to directly say this. It does mention RFC3338 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2010) is 5164 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'BIS' is mentioned on line 396, but not defined == Unused Reference: 'RFC1918' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC2766' is defined on line 449, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2767 (Obsoleted by RFC 6535) ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 3338 (Obsoleted by RFC 6535) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave B. Huang 3 Internet-Draft H. Deng 4 Obsoletes: 3338 (if approved) China Mobile 5 Intended status: Experimental T. Savolainen 6 Expires: September 8, 2010 Nokia 7 March 7, 2010 9 Dual Stack Hosts Using "Bump-in-the-API" (BIA) 10 draft-huang-behave-rfc3338bis-02 12 Abstract 14 This document describes the "Bump-In-the-API" (BIA) host based 15 protocol translation mechanism that allows applications supporting 16 only one IP address family to communicate with peers that are 17 reachable or supporting only the other address family. 19 This specification addresses scenarios where a host is provided dual 20 stack or IPv6 only network connectivity. In the dual stack network 21 case, single address family applications in the host sometime will 22 communicate directly with other hosts using the different address 23 family. In the case of IPv6 only network or IPv6 only destination, 24 IPv4-originated communications have to be translated into IPv6. 25 Technically, the BIA-enabled host resolves both A and AAAA addresses 26 of the destination and behaves according to received responses. 28 Acknowledgement of previous work 30 This document is an update to and directly derivative from Seungyun 31 Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and Erik Nordmark's 32 [RFC3338], which similarly provides a dual stack host means to 33 communicate with other IPv6 host using existing IPv4 appliations.The 34 original document was a product of the NGTRANS working group. 36 The changes in this document reflect four components 38 1. Supporting IPv6 only network connections 40 2. IPv4 address pool use private address 42 3. Extending ENR and address mapper to operate differently 44 4. Adding an alternative way to implement the ENR 46 The goal of this mechanism is the same as that of the Bump-in-the- 47 stack mechanism, but this mechanism provides the translation method 48 between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply 49 achieved without IP header translation. 51 Status of this Memo 53 This Internet-Draft is submitted to IETF in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF), its areas, and its working groups. Note that 58 other groups may also distribute working documents as Internet- 59 Drafts. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 The list of current Internet-Drafts can be accessed at 67 http://www.ietf.org/ietf/1id-abstracts.txt. 69 The list of Internet-Draft Shadow Directories can be accessed at 70 http://www.ietf.org/shadow.html. 72 This Internet-Draft will expire on September 8, 2010. 74 Copyright Notice 76 Copyright (c) 2010 IETF Trust and the persons identified as the 77 document authors. All rights reserved. 79 This document is subject to BCP 78 and the IETF Trust's Legal 80 Provisions Relating to IETF Documents 81 (http://trustee.ietf.org/license-info) in effect on the date of 82 publication of this document. Please review these documents 83 carefully, as they describe your rights and restrictions with respect 84 to this document. Code Components extracted from this document must 85 include Simplified BSD License text as described in Section 4.e of 86 the Trust Legal Provisions and are provided without warranty as 87 described in the BSD License. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 92 2. Dual Stack Host Architecture Using BIA . . . . . . . . . . . . 6 93 2.1. Function Mapper . . . . . . . . . . . . . . . . . . . . . 6 94 2.2. Extension Name Resolver . . . . . . . . . . . . . . . . . 7 95 2.3. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 7 96 3. Behavior Examples . . . . . . . . . . . . . . . . . . . . . . 10 97 3.1. dual stack network and IPv6 only peer . . . . . . . . . . 10 98 3.2. IPv6 only network and dual-stack peer . . . . . . . . . . 10 99 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 11 100 4.1. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 11 101 4.2. Internally Assigned IPv4 or IPv6 Addresses . . . . . . . . 11 102 5. ALG related . . . . . . . . . . . . . . . . . . . . . . . . . 12 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 104 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 105 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 106 Appendix A. Implementation of ENR . . . . . . . . . . . . . . . . 16 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 109 1. Introduction 111 [RFC3338] stated that there are few applications for IPv6 [RFC2460] 112 as compared with IPv4 in which a great number of applications are 113 available. In order to advance the transition smoothly, it is highly 114 desirable to make the availability of IPv6 applications increase to 115 the same level as IPv4. Unfortunately, however, this is expected to 116 take a long time. 118 BIA [RFC3338] proposed a mechanism of dual stack hosts using the 119 technique called "Bump-in-the-API" in the IP security area. The 120 technique inserts an API translator between the socket API module and 121 the TCP/IP module in the dual stack hosts, so that it translates the 122 IPv4 socket API function into IPv6 socket API function and vice 123 versa. 125 BIS [RFC2767] specifies a host translation mechanism using a 126 technique called "Bump-in-the-Stack". It translates IPv4 into IPv6, 127 and vice versa using the IP conversion mechanism defined in SIIT 128 [RFC2765]. BIS allows hosts to communicate with other IPv6 hosts 129 using existing IPv4 applications. However, this approach is to use a 130 translator which is inserted between the TCP/IP module and network 131 card driver, so that it has the same limitations as the SIIT based IP 132 header translation methods. In addition, its implementation is 133 dependent upon the network interface driver. 135 When IPv4 applications on the dual stack communicate with other IPv6 136 hosts, the API translator detects the socket API functions from IPv4 137 applications and invokes the IPv6 socket API functions to communicate 138 with the IPv6 hosts, and vice versa. In order to support 139 communication between IPv4 applications and the target IPv6 hosts, 140 pooled IPv4 addresses will be assigned through the extension name 141 resolver in the API translator. But the those IPv4 addresses never 142 flow out from them. 144 The network scenario specified in [RFC3338] is a dual stack network. 145 where IPv4 communication can be transported independently of IPv6. 146 However, if the network provides only IPv6 transport, applications's 147 IPv4 packets have to be translated into IPv6. 149 This specification assumes that host knows it is connected with a 150 dual stack network or IPv6-only network. The host learns that from 151 layer 2 or from results of layer 3 IP address configuration 152 mechanisms. 154 If the network which host is connecting with is IPv6 only network, 155 then host's IPv6 application will behave reguarly, and it's IPv4 156 application's packets have to be translated into IPv6 in order to 157 communicate with IPv6 applications. 159 If the network which host is connecting with is dual stack network, 160 then host will behave as what [RFC3338] originally described. 162 The scenario where destination peer is not reachable with the address 163 family a host is provisioned with is not covered by this document, as 164 that requires network based protocol translation solution. However, 165 the BIA technology can complement network based protocol translation 166 . 168 Moreover, since the translation is automatically carried out with the 169 help of DNS protocol, most applications do not need to know whether 170 target hosts are IPv6 or IPv4 ones. That is, this allows hosts to 171 communicate with other IPv6 hosts using existing IPv4 applications ; 172 thus it seems as if peers are always dual stack hosts with 173 applications for both IPv4 and IPv6. 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119] . 179 This document uses terms defined in [RFC2460] , [RFC2893] , [RFC2767] 180 and [RFC3338]. 182 2. Dual Stack Host Architecture Using BIA 184 Figure 1 shows the architecture of the host in which BIA is 185 installed. 187 +----------------------------------------------+ 188 | +------------------------------------------+ | 189 | | | | 190 | | IPv4 applications | | 191 | | | | 192 | +------------------------------------------+ | 193 | +------------------------------------------+ | 194 | | Socket API (IPv4, IPv6) | | 195 | +------------------------------------------+ | 196 | +-[ API translator]------------------------+ | 197 | | +-----------+ +---------+ +------------+ | | 198 | | | Ext. Name | | Address | | Function | | | 199 | | | Resolver | | Mapper | | Mapper | | | 200 | | +-----------+ +---------+ +------------+ | | 201 | +------------------------------------------+ | 202 | +--------------------+ +-------------------+ | 203 | | | | | | 204 | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | 205 | | | | | | 206 | +--------------------+ +-------------------+ | 207 +----------------------------------------------+ 209 Figure 1: Architecture of the dual stack host using BIA 211 Dual stack hosts defined in RFC2893 [RFC2893] need applications, 212 TCP/IP modules and addresses for both IPv4 and IPv6. The proposed 213 hosts in this document have an API translator to communicate with 214 other IPv6 hosts using existing IPv4 applications. The API 215 translator consists of 3 modules, an extension name resolver, an 216 address mapper and a function mapper. 218 2.1. Function Mapper 220 It translates an IPv4 socket API function into an IPv6 socket API 221 function, and vice versa. 223 When detecting the IPv4 socket API functions from IPv4 applications, 224 it intercepts the function call and invokes new IPv6 socket API 225 functions which correspond to the IPv4 socket API functions. Those 226 IPv6 API functions are used to communicate with the target IPv6 227 hosts. When detecting the IPv6 socket API functions from the data 228 received from the IPv6 hosts, it works symmetrically in relation to 229 the previous case. 231 2.2. Extension Name Resolver 233 It returns a proper answer in response to the IPv4 or IPv6 234 application's request. 236 When an IPv4 application in an IPv6 only network tries to resolve 237 names via the resolver library (e.g. gethostbyname()), BIA intercept 238 the function call and instead call the IPv6 equivalent functions 239 (e.g. getnameinfo()) that will resolve both A and AAAA records. 241 If only AAAA record is available, it requests the address mapper to 242 assign an IPv4 address corresponding to the IPv6 address, then 243 creates the A record for the assigned IPv4 address, and returns the A 244 record to the IPv4 application. 246 If both A and AAAA record are available in the IPv6 only network, it 247 doesn't requests the address mapper but directly send this A record 248 and AAAA record to address mapper to store this relationship, then 249 directly pass this A record to the IPv4 application. 251 2.3. Address Mapper 253 It internally maintains a table of the pairs of an IPv4 address and 254 an IPv6 address. The IPv4 addresses are assigned from an IPv4 255 address pool. The pool can consists of private IPv4 addresses. 257 When the extension name resolver or the function mapper requests it 258 to assign an IPv4 address corresponding to an IPv6 address, it 259 selects and returns an IPv4 address out of the pool, and registers a 260 new entry into the table dynamically. The registration occurs in the 261 following 3 cases: 263 (1) When the extension name resolver gets only an 'AAAA' record for 264 the target host name in the dual stack or IPv6 only network and there 265 is not a mapping entry for the IPv6 address. 267 (2) When the extension name resolver gets both an 'A' record and an 268 'AAAA' record for the target host name in the IPv6 only network and 269 there is not a mapping entry for the IPv6 address. But it doesn't 270 need an IPv4 address out of the pool, just registers both IPv4 and 271 IPv6 address from 'A' and 'AAAA' records into a new entry into the 272 table. 274 (3) When the function mapper gets a socket API function call from the 275 data received and there is not a mapping entry for the IPv6 source 276 address. 278 When the resolver or the function mapper requests mapper to assign an 279 IPv4 address corresponding to an IPv6 address, mapper, if required, 280 selects and returns an IPv4 address out of the pool, and registers a 281 new entry into the table dynamically. The following table describes 282 how mappings are created into the table in each scenario : 284 Mapping table | Access | Peer | Created 285 entry for |link type | support| address mapping 286 -------------------+-------------+------------------------------- 287 (1) real IPv4 |IPv4 or DS | v4 | < no mapping needed > 288 (2) real IPv6 |IPv6 or DS | v6 | < no mapping needed > 289 (3) real IPv4 |IPv6 | v4 & v6| real IPv4 -> real IPv6 290 (4) real IPv6 |IPv4 | v4 & v6| real IPv6 -> real IPv4 291 (5) local IPv4 |IPv6 or DS | v6 | local IPv4 -> real IPv6 292 (6) local IPv6 |IPv4 or DS | v4 | local IPv6 -> real IPv4 293 (7) real IPv4 |IPv6 | v4 | out of scope 294 (8) real IPv6 |IPv4 | v6 | out of scope 296 Figure 2: Address Mapper's mapping table illustration 298 Below are examples for all eight scenarios: 300 (1) When the resolver gets an 'A' reply for application's 'A' query 301 on access network supporting IPv4, there is no need to create mapping 302 (or just stub mapping real IPv4 -> real IPv4). 304 (2) When the resolver gets an 'AAAA' reply for application's 'AAAA' 305 query on access network supporting IPv6, there is no need to create 306 mapping (or just stub mapping real IPv6 -> real IPv6). 308 (3) When the resolver gets both 'A' and 'AAAA' replies for 309 application's 'A' query on IPv6-only access, there shall be mapping 310 for real IPv4 to real IPv6. 312 (4) When the resolver gets both 'A' and 'AAAA' replies for 313 application's 'AAAA' query on IPv4-only access, there shall be 314 mapping for real IPv6 to real IPv4. 316 (5) When the resolver gets only an 'AAAA' record for the target host 317 name for application's 'A' request on IPv6 only or DS access network, 318 a local IPv4 address will be given to application and mapping for 319 local IPv4 address to real IPv6 address is created. 321 (6) When the resolver gets only an 'A' record for the target host 322 name for application's 'AAAA' request on IPv4 only or DS access 323 network, a local IPv6 address will be given to application and 324 mapping for local IPv6 address to real IPv4 address is created. 326 (7) When the resolver gets only an 'A' record for the target host 327 name for application's 'A' request on IPv6 only access network, a 328 double translation would be required and thus is out of the scope of 329 this document. 331 (8) When the resolver gets only an 'AAAA' record for the target host 332 name for application's 'AAAA' request on IPv4 only access network, a 333 double translation would be required and thus is out of the scope of 334 this document. 336 NOTE: There is only one exception. When initializing the table, 337 mapper registers a pair of its own IPv4 address and IPv6 address into 338 the table statically. 340 NOTE: This is the same as that of the Address Mapper in [RFC2767]. 342 3. Behavior Examples 344 The mechanism of BIA could be used in two type of network 345 environments, the first is dual stack network and IPv6 only peer, the 346 second is IPv6 only network and dual stack peer. ENR will behave 347 according to different network environment. 349 3.1. dual stack network and IPv6 only peer 351 There are several reasons to not upgrade IPv4 applications to support 352 IPv6 such as charging, codec, lack of knowledge et al, and this is 353 out of scope of this document. Section 4 of [RFC3338] already has 354 stated in detail how this work, there are no need to modify anything 355 here. 357 3.2. IPv6 only network and dual-stack peer 359 When a dual stack server locates in the IPv6 only network, and not 360 yet updated IPv4 applicaiton need to visit this server. This is the 361 network scenario of IPv6 only and dual stack peer. There is the need 362 to replace "host6" with "host46" in figure 2 of section 4 of 363 [RFC3338] because the peer host is dual stack. 365 If only 'AAAA' records is resolved, so the ENR need to request the 366 address mapper to allocate any IPv4 addresses from its pool, it's the 367 same as the section 4 of [RFC3338]. 369 If both the 'A' and 'AAAA' records are resolved, then there will be a 370 little difference with section 4 of [RFC3338], the ENR does not need 371 to request one IPv4 address from address mapper which is 372 corresponding to the IPv6 address. on the contrarary, ENR will store 373 the mapping between received destination's IPv4 and IPv6 addresses 374 which are from 'A' and 'AAAA' records. After that, the ENR will 375 return 'A' record to the application as is. 377 4. Considerations 379 Other considerations in [RFC3338] are still the same, here only 380 clarify the section of IPv4 Address Pool and Mapping Table and 381 Internally Assigned IPv4 or IPv6 Addresses to support private IPv4 382 address. 384 4.1. IPv4 Address Pool and Mapping Table 386 The address pool consists of the private IPv4 addresses. This pool 387 can be implemented at different granularity in the node e.g., a 388 single pool per node, or at some finer granularity such as per user 389 or per process. However, if a number of IPv4 applications 390 communicate with IPv6 hosts or IPv6 applications communicate with 391 IPv4 hosts, the available address spaces will be exhausted. As a 392 result, it will be impossible for IPv4 applications to communicate 393 with IPv6 nodes. It requires smart management techniques for address 394 pool. For example, it is desirable for the mapper to free the oldest 395 entry and reuse the IPv4 address or IPv6 address for creating a new 396 entry. This issues is the same as [BIS]. In case of a per-node 397 address mapping table, it MAY cause a larger risk of running out of 398 address. 400 4.2. Internally Assigned IPv4 or IPv6 Addresses 402 The IPv4 addresses, which are internally assigned to IPv6 target 403 hosts out of the pool, are the private IPv4 addresses. IPv4 404 addresses, which are internally assigned to IPv6 target hosts out of 405 the spool, never flow out from the host, and so do not negatively 406 affect other hosts. 408 5. ALG related 410 BIA host should only perform a minimum of ALG to avoid complicated 411 ALG design for various kind of appliation such as FTP, RTSP et al. 412 ALG design is not encouraged for host based translation. It is out 413 of scope of this document. 415 6. Security Considerations 417 This is the same as the [RFC3338], newly added function doesn't bring 418 new threat to the host based translation. 420 7. Acknowledgments 422 The author thanks the discussion from Gang Chen, Dapeng Liu, Bo Zhou, 423 Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of 424 this document. 426 The efforts of Suresh Krishnan, Mohamed Boucadair, Yiu L. Lee, James 427 Woodyatt, Lorenzo Colitti, Qibo Niu, Pierrick Seite, Dean Cheng, 428 Christian Vogt, Jan M. Melen in reviewing this document are 429 gratefully acknowledged. 431 Advice from Dan Wing, Dave Thaler and Magnus Westerlund are greatly 432 appreciated 434 8. Normative References 436 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 437 E. Lear, "Address Allocation for Private Internets", 438 BCP 5, RFC 1918, February 1996. 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 444 (IPv6) Specification", RFC 2460, December 1998. 446 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 447 (SIIT)", RFC 2765, February 2000. 449 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 450 Translation - Protocol Translation (NAT-PT)", RFC 2766, 451 February 2000. 453 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 454 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 455 RFC 2767, February 2000. 457 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 458 IPv6 Hosts and Routers", RFC 2893, August 2000. 460 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 461 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 462 RFC 3338, October 2002. 464 Appendix A. Implementation of ENR 466 It's not necessarily implment the ENR in the kernel level, but just 467 implement it as the user space by set the default DNS server to 468 127.0.0.1, then IPv4 application could always send DNS query to the 469 localhost, then ENR will send both A and AAAA query to the actual DNS 470 server. So ENR will keep the real DNS server address. 472 Authors' Addresses 474 Bill Huang 475 China Mobile 476 53A,Xibianmennei Ave., 477 Xuanwu District, 478 Beijing 100053 479 China 481 Email: bill.huang@chinamobile.com 483 Hui Deng 484 China Mobile 485 53A,Xibianmennei Ave., 486 Xuanwu District, 487 Beijing 100053 488 China 490 Email: denghui02@gmail.com 492 Teemu Savolainen 493 Nokia 494 Hermiankatu 12 D 495 FI-33720 TAMPERE 496 Finland 498 Email: teemu.savolainen@nokia.com