idnits 2.17.1 draft-ietf-ngtrans-bia-04.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 1) being 62 lines 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 177 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([BIS]), 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 120: '... The client node SHOULD cycle through ...' RFC 2119 keyword, line 122: '... - BIA SHOULD do the work....' RFC 2119 keyword, line 130: '... BIA SHOULD not be used for IPv4 a...' RFC 2119 keyword, line 131: '...that application programers SHOULD use...' RFC 2119 keyword, line 133: '... well, it SHOULD not be used for e...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: BIA SHOULD not be used for IPv4 application of which source is available. We strongly recommend that application programers SHOULD use this mechanism only when an application source code is not available. As well, it SHOULD not be used for excuse not to port software or delaying porting. -- 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 (April 2002) is 8047 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) == Missing Reference: 'IPv6' is mentioned on line 101, but not defined == Unused Reference: 'FTP' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'NAT' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'IPV4' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'PRIVATE' is defined on line 516, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2893 (ref. 'TRANS-MECH') (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 2765 (ref. 'SIIT') (Obsoleted by RFC 6145) ** 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 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2767 (ref. 'BIS') (Obsoleted by RFC 6535) ** Obsolete normative reference: RFC 2553 (ref. 'SOCK-EXT') (Obsoleted by RFC 3493) Summary: 15 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Seungyun Lee 3 NGTRANS Working Group Myung-Ki Shin 4 Expires: October 2002 Yong-Jin Kim 5 ETRI 6 Erik Nordmark 7 Alain Durand 8 Sun Microsystems 9 April 2002 11 Dual Stack Hosts using "Bump-in-the-API" (BIA) 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC2026. 19 Internet Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and working groups. Note that other groups may 21 also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsolete by other documents at anytime. 25 It is inappropriate to use Internet Drafts as reference material or to 26 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 document specifies a mechanism of dual stack hosts using a 37 technique called "Bump-in-the-API"(BIA) which allows for the hosts to 38 communicate with other IPv6 hosts using existing IPv4 applications. The 39 goal of this mechanism is the same as that of the Bump-in-the-stack 40 mechanism [BIS], but this mechanism provides the translation method 41 between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achieved 42 without IP header translation. 44 Table of Contents: 46 1. Introduction ................................................. 2 47 2. Applicability and Disclaimer ................................. 3 48 2.1 Applicability ............................................ 3 49 2.2 Disclaimer ............................................... 3 50 3. Dual Stack Host Architecture using BIA ....................... 4 51 3.1 Function Mapper .......................................... 4 52 3.2 Name Resolver ............................................ 4 53 3.3 Address Mapper ........................................... 5 54 4. Behavior Example ............................................. 6 55 4.1 Originator Behavior ...................................... 6 56 4.2 Recipient Behavior ....................................... 8 57 5. Considerations .............................................. 9 58 5.1 Socket API Conversion .................................... 9 59 5.2 ICMP Messages Handling ................................... 10 60 5.3 IPv4 Address Pool and Mapping Table ...................... 10 61 5.4 Internally Assigned IPv4 Addresses ....................... 10 62 5.5 Mis-match between DNS Result and Peer Application version 10 63 5.6 Implementation Issues .................................... 11 64 6. Limitations .................................................. 11 65 7. Security Considerations ...................................... 11 66 8. Acknowledgments .............................................. 12 67 9. References ................................................... 12 68 Appendix : API list intercepted by BIA .......................... 13 69 Authors Addresses ............................................... 14 71 1. Introduction 73 RFC2767 [BIS] specifies a host translation mechanism using a technique 74 called "Bump-in-the-Stack". It translates IPv4 into IPv6, and vice versa 75 using the IP conversion mechanism defined in [SIIT]. BIS allows hosts to 76 communicate with other IPv6 hosts using existing IPv4 applications. 77 However, this approach is to use an API translator which is inserted 78 between TCP/IP module and network card driver, so that it has the same 79 limitations as the [SIIT] based IP header translation methods. In 80 addition, its implementation is dependent upon the network interface 81 driver. 83 This document specifies a new mechanism of dual stack hosts called 84 Bump-in-the-API(BIA) technique. The BIA technique inserts an API 85 translator between the socket API module and the TCP/IP module in the 86 dual stack hosts, so that it translates the IPv4 socket API function 87 into IPv6 socket API function and vice versa. With this mechanism, the 88 translation can be simplified without IP header translation. 90 Using BIA, the dual stack host assumes that there exists both 91 TCP(UDP)/IPv4 and TCP(UDP)/IPv6 stacks on the hosts. 93 When IPv4 applications on the dual stack communicate with other IPv6 94 hosts, the API translator detects the socket API functions from IPv4 95 applications and invokes the IPv6 socket API functions to communicate 96 with the IPv6 hosts, and vice versa. In order to support communication 97 between IPv4 applications and the target IPv6 hosts, pooled IPv4 98 addresses will be assigned through the name resolver in the API 99 translator. 101 This document uses terms defined in [IPv6],[TRANS-MECH] and [BIS]. 103 2. Applicability and Disclaimer 105 2.1 Applicability 107 The main purposes of BIA are the same as BIS [BIS]. It makes IPv4 108 applications communicate with IPv6 hosts without any modification of 109 IPv4 applications. However, while BIS is for systems with no IPv6 110 stack, BIA is for systems with an IPv6 stack, but on which some 111 applications are either not yet available on IPv6 or application for 112 which source code is not available or lost. It's good for early 113 adopters who do not have all applications handy, but not for mainstream 114 production usage. 116 There is an issue about a client node running BIA trying to contact an 117 dual stack node on a port number that is only associated to an IPv4 118 application (see section 5.5). There are 2 approaches. 120 - The client node SHOULD cycle through all the addresses and 121 end up trying the IPv4 one. 122 - BIA SHOULD do the work. 124 It is not clear at this time which behavior is desirable (it may very 125 well be application dependent), so we need to get feedback from 126 experimentation. 128 2.2 Disclaimer 130 BIA SHOULD not be used for IPv4 application of which source is 131 available. We strongly recommend that application programers SHOULD use 132 this mechanism only when an application source code is not available. As 133 well, it SHOULD not be used for excuse not to port software or delaying 134 porting. 136 3. Dual Stack Host Architecture using BIA 138 Figure 1 shows the architecture of the host in which BIA is installed. 140 +----------------------------------------------+ 141 | +------------------------------------------+ | 142 | | | | 143 | | IPv4 applications | | 144 | | | | 145 | +------------------------------------------+ | 146 | +------------------------------------------+ | 147 | | Socket API (IPv4, IPv6) | | 148 | +------------------------------------------+ | 149 | +-[ API translator]------------------------+ | 150 | | +-----------+ +---------+ +------------+ | | 151 | | | Name | | Address | | Function | | | 152 | | | Resolver | | Mapper | | Mapper | | | 153 | | +-----------+ +---------+ +------------+ | | 154 | +------------------------------------------+ | 155 | +--------------------+ +-------------------+ | 156 | | | | | | 157 | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | 158 | | | | | | 159 | +--------------------+ +-------------------+ | 160 +----------------------------------------------+ 161 Figure 1 Architecture of the dual stack host using BIA 163 Dual stack hosts defined in RFC1933 [TRANS-MECH] need applications, 164 TCP/IP modules and addresses for both IPv4 and IPv6. The proposed hosts 165 in this document have an API translator to communicate with other IPv6 166 hosts using existing IPv4 applications. The API translator consists of 3 167 modules, a name resolver, an address mapper and a function mapper. 169 3.1 Function Mapper 171 It translates IPv4 socket API function into IPv6 socket API function, 172 and vice versa. 174 When detecting the IPv4 socket API functions from IPv4 applications, it 175 intercepts the function call and invokes new IPv6 socket API functions 176 which correspond to the IPv4 socket API functions. Those IPv6 API 177 functions are used to communicate with the target IPv6 hosts. When 178 detecting the IPv6 socket API functions from the data received from the 179 IPv6 hosts, it works symmetrically in relation to the previous case. 181 3.2 Name Resolver 183 It returns a proper answer in response to the IPv4 application's 184 request. 186 When the IPv4 application sends a query to a name server with A records, 187 it detects the query, then creates another query to resolve both A and 188 AAAA records for the host name, and sends the query to the server. 190 If only the AAAA record is available, it requests the address mapper to 191 assign an IPv4 address corresponding to the IPv6 address, then creates 192 the A record for the assigned IPv4 address, and returns the A record to 193 the application. 195 NOTE: This action is the same as that of the Extension Name Resolver in 196 [BIS]. 198 3.3 Address Mapper 200 It internally maintains a table of the pairs of an IPv4 address and an 201 IPv6 address. The IPv4 addresses are assigned from an IPv4 address pool. 202 It uses the unassigned IPv4 addresses (e.g., 0.0.0.0 ~ 0.0.0.255). 204 When the name resolver or the function mapper requests it to assign an 205 IPv4 address corresponding to an IPv6 address, it selects and returns an 206 IPv4 address out of the pool, and registers a new entry into the table 207 dynamically. The registration occurs in the following 2 cases : 209 (1) When the name resolver gets only an 'AAAA' record for the target 210 host name and there is not a mapping entry for the IPv6 address. 212 (2) When the function mapper gets a socket API function call from the 213 data received and there is not a mapping entry for the IPv6 source 214 address. 216 NOTE: This is the same as that of the Address Mapper in [BIS]. 218 4. Behavior Examples 220 This section describes behaviors of the proposed dual stack host called 221 "dual stack", which communicates with an IPv6 host called "host6" using 222 an IPv4 application. 224 In this section, the meanings of arrows are as follows : 226 ---> A DNS message for name resolving created by the 227 applications and the name resolver in the API translator. 228 +++> An IPv4 address request to and reply from the address mapper 229 for the name resolver and the function mapper. 230 ===> Data flow by socket API functions created by the 231 applications and the function mapper in the API translator. 233 4.1 Originator Behavior 235 This sub-section describes the behavior when the "dual stack" sends data 236 to "host6". 238 When an IPv4 application sends a DNS query to its name server, the name 239 resolver intercepts the query and then creates a new query to resolve 240 both A and AAAA records. When only the AAAA record is resolved, the name 241 resolver requests the address mapper to assign an IPv4 address 242 corresponding to the IPv6 address. 244 The name resolver creates an A record for the assigned IPv4 address and 245 returns it to the IPv4 applications. 247 In order for the IPv4 application to send IPv4 packets to host6, it 248 calls the IPv4 socket API function. 250 The function mapper detects the socket API function from the 251 application. If the result is from IPv6 applications, it skips the 252 translation. In the case of IPv4 applications, it requires an IPv6 253 address to invoke the IPv6 socket API function, thus the function mapper 254 requests an IPv6 address to the address mapper. The address mapper 255 selects an IPv4 address from the table and returns the destination IPv6 256 address. Using this IPv6 address, the function mapper invokes an IPv6 257 socket API function corresponding to the IPv4 socket API function. 259 When the function mapper receives an IPv6 function call,it requests the 260 IPv4 address to the address mapper in order to translate the IPv6 socket 261 API function into an IPv4 socket API function. Then, the function mapper 262 invokes the socket API function for the IPv4 applications. 264 Figure 2 illustrates the behavior described above: 266 "dual stack" "host6" 267 IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name 268 appli- API |Name Address Function| (v6/v4) Server 269 cation |Resolver Mapper Mapper | 270 | | | | | | | | 271 <> | | | 272 | | | | | | | | 273 |--------|------->| Query of 'A' records for host6. | | 274 | | | | | | | | 275 | | |--------|--------|---------|--------------|------>| 276 | | | Query of 'A' records and 'AAAA' for host6 | 277 | | | | | | | | 278 | | |<-------|--------|---------|--------------|-------| 279 | | | Reply only with 'AAAA' record. | | 280 | | | | | | | 281 | | |<> | 282 | | | | | | | 283 | | |+++++++>| Request one IPv4 address | 284 | | | | corresponding to the IPv6 address. 285 | | | | | | | 286 | | | |<> | 287 | | | | | | | 288 | | |<+++++++| Reply with the IPv4 address. | 289 | | | | | | | 290 | | |<> 291 | | | | | | | 292 |<-------|--------| Reply with the 'A' record.| | 293 | | | | | | | 295 Figure 2 Behavior of the originator (1/2) 297 "dual stack" "host6" 298 IPv4 Socket | [ API Translator ] | TCP(UDP)/IP 299 appli- API |Name Address Function| (v6/v4) 300 cation |Resolver Mapper Mapper | 301 | | | | | | | 302 <> | | | 303 | | | | | | | 304 |========|========|========|=======>|An IPv4 Socket API function Call 305 | | | | | | | 306 | | | |<+++++++| Request IPv6 addresses| 307 | | | | | corresponding to the | 308 | | | | | IPv4 addresses. | 309 | | | | | | | 310 | | | |+++++++>| Reply with the IPv6 addresses. 311 | | | | | | | 312 | | | | |<> 313 | | | | | | | 314 | An IPv6 Socket API function call.|=========|=============>| 315 | | | | | | | 316 | | | | |<> | 318 | | | | | | | 319 | An IPv6 Socket API function call.|<========|==============| 320 | | | | | | | 321 | | | | |<> 322 | | | | | | | 323 | | | |<+++++++| Request IPv4 addresses| 324 | | | | | corresponding to the | 325 | | | | | IPv6 addresses. | 326 | | | | | | | 327 | | | |+++++++>| Reply with the IPv4 addresses. 328 | | | | | | | 329 |<=======|========|========|========| An IPv4 Socket function call. 330 | | | | | | | 332 Figure 2 Behavior of the originator (2/2) 334 4.2 Recipient Behavior 336 This subsection describes the recipient behavior of "dual stack". The 337 communication is triggered by "host6". 339 "host6" resolves the address of "dual stack" with 'AAAA' records through 340 its name server, and then sends an IPv6 packet to the "dual stack". 342 The IPv6 packet reaches the "dual stack" and the function mapper detects 343 it. 345 The function mapper requests the IPv4 address to the address mapper in 346 order to invoke the IPv4 socket API function to communicate with for 347 IPv4 application. Then the function mapper invokes the corresponding 348 IPv4 socket API function for the IPv4 applications corresponding to the 349 IPv6 functions. 351 Figure 3 illustrates the behavior described above: 353 "dual stack" "host6" 354 IPv4 Socket | [ API Translator ] | TCP(UDP)/IP 355 appli- API |Name Address Function| (v6/v4) 356 cation |Resolver Mapper Mapper | 357 | | | | | | | 358 <> | | | 359 | | | | | | | 360 | An IPv6 Socket function call.|<========|==============| 361 | | | | | | | 362 | | | |<+++++++| Request IPv4 addresses| 363 | | | | | corresponding to the IPv6 364 | | | | | addresses. | 365 | | | | | | | 366 | | | |+++++++>| Reply with the IPv4 addresses. 367 | | | | | | | 368 | | | | |<> 369 | | | | | | | 370 |<=======|========|========|========| An IPv4 function call | 371 | | | | | | | 372 <> | | | 373 | | | | | | | 374 |========|========|========|=======>| An IPv4 function call | 375 | | | | | | | 376 | | | | |<> 377 | | | | | | | 378 | | | |<+++++++| Request IPv6 addresses| 379 | | | | | corresponding to the IPv4 380 | | | | | addresses. | 381 | | | | | | | 382 | | | |+++++++>| Reply with the IPv6 addresses. 383 | | | | | | | 384 | An IPv6 Socket function call.|=========|=============>| 385 | | | | | | | 387 Figure 3 Behavior of Receiving data from IPv6 host 389 5. Considerations 391 5.1 Socket API Conversion 393 IPv4 socket API functions are translated into semantically the same IPv6 394 socket API functions and vice versa. See Appendix A for the API list 395 intercepted by BIA. IP addresses embedded in application layer 396 protocols (e.g., FTP) can be translated in API functions. Its 397 implementation depends on operating systems. 399 NOTE: Basically, IPv4 socket API functions are not fully compatible with 400 IPv6 since the IPv6 has new advanced features. 402 5.2 ICMP Message Handling 404 When an application needs ICMP messages values (e.g., Type, Code, etc.) 405 sent from a network layer, ICMPv4 message values SHOULD be translated 406 into ICMPv6 message values based on [SIIT], and vice versa. It can be 407 implemented using raw socket. 409 5.3 IPv4 Address Pool and Mapping Table 411 The address pool consists of the unassigned IPv4 addresses. However, if 412 a number of IPv4 applications communicate with IPv6 hosts, the available 413 address spaces will be exhausted. As a result, it will be impossible for 414 IPv4 applications to communicate with IPv6 hosts. It requires smart 415 management techniques for address pool. For example, it is desirable 416 for the mapper to free the oldest entry and re-use the IPv4 address for 417 creating a new entry. This issues is the same as [BIS]. 419 5.4 Internally Assigned IPv4 Addresses 421 The IPv4 addresses, which are internally assigned to IPv6 target hosts 422 out of the pool, are the unassigned IPv4 addresses (e.g., 0.0.0.0 ~ 423 0.0.0.255). There is no potential collision with another use of the 424 private address space when the IPv4 address flows out from the host. 426 5.5 Mis-match between DNS result(AAAA) and Peer Application version(v4) 428 If a server application you are using does not support IPv6 yet, but 429 runs on an machine that supports other IPv6 services and this is listed 430 with a AAAA record in the DNS, a client IPv4 application using BIA will 431 fail to connect to the server application, because there is a mis-match 432 between DNS query result (i.e., AAAA) and a server application 433 version(i.e., IPv4). A solution is to try all the addresses listed in 434 the DNS and just not fail after the first attempt. We have two 435 approaches : the client application itself SHOULD cycle through all the 436 addresses and end up trying the IPv4 one. Or it SHOULD be done by some 437 extensions of name resolver and API translator in BIA. For this, BIA 438 SHOULD do iterated jobs for finding the working address used by the 439 other application out of addresses returned by the extended name 440 resolver. It may very well be application dependent. 442 5.6 Implementation Issues 444 Some operating systems support the pre-load library functions, so it is 445 easy to implement the API translator by using it. For example, user can 446 replace all existing socket API functions with user-defined socket API 447 functions which translate the socket API function. In this case, every 448 IPv4 application has its own translation library using pre-load library 449 which will be bound into the application before executing it 450 dynamically. 452 The other operating systems support the user-defined layered protocol 453 allowing a user to develop some additional protocols and put them in the 454 existing protocol stack. In this case, the API translator can be 455 implemented as a layered protocol module. 457 In the above two approaches, it is assumed that there exists both 458 TCP(UDP)/IPv4 and TCP(UDP)/IPv6 stacks and there is no need to modify or 459 to add a new TCP-UDP/IPv6 stack. 461 6. Limitations 463 In common with [NAT-PT], BIA needs to translate IP addresses embedded in 464 application layer protocols, e.g., FTP. So it may not work for new 465 applications which embed addresses in payloads. 467 This mechanism supports unicast communications only. If it can support 468 multicast functions, some other additional functionalities must be 469 considered in the function mapper module. 471 Since the IPv6 API has new advanced features, it is difficult to 472 translate such kind of IPv6 APIs into IPv4 APIs. Thus, IPv6 inbound 473 communication with advanced features may be discarded. 475 7. Security Considerations 477 The security consideration of BIA mostly relies on that of [NAT-PT]. 478 The differences are due to the address translation occuring at the API 479 and not in the network layer. That is, since the mechanism use the API 480 translator at the socket API level, hosts can utilize the security of 481 network layer (e.g., IPsec) when they communicate with IPv6 hosts using 482 IPv4 applications via the mechanism. As well, there isn't a DNS ALG as 483 in NAT-PT, so there is no interference with DNSSEC. 485 The use of address pooling may open a denial of service attack 486 vulnerability. However, this security hazard may be prohibited, since 487 the pooled IPv4 addresses will not be used for the outside IPv4 routing 488 (these addresses are assigned from the unassigned IPv4 addresses (e.g., 489 0.0.0.0 ~ 0.0.0.255) by the address mapper). 491 8. Acknowledgments 493 We would like to acknowledge the implementation contributions by Wanjik 494 Lee(wjlee@arang.miryang.ac.kr) and i2soft Corporation(www.i2soft.net). 496 9. References 498 [TRANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 499 IPv6 Hosts and Routers", RFC 2893, August 2000. 501 [SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 502 2765, February 2000. 504 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", 505 STD 9, RFC 959, October 1985. 507 [NAT] Kjeld B. and P. Francis, "The IP Network Address 508 Translator (NAT)", RFC 1631, May 1994. 510 [IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, 511 September 1981. 513 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 514 (IPv6) Specification", RFC 2460, December 1998. 516 [PRIVATE] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 517 J. and E. Lear, "Address Allocation for Private 518 Internets", BCP 5, RFC 1918, February 1996. 520 [NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address 521 Translation - Protocol Translation (NAT-PT)", RFC 2766, 522 February 2000. 524 [BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts 525 using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, 526 February 2000. 528 [SOCK-EXT] R. Gilligan, S. Thomson, J. Bound and W. Stevens, "Basic 529 Socket Interface Extensions for IPv6", RFC2553, March 1999. 531 Appendix A : API list intercepted by BIA 533 The following functions are the API list which SHOULD be intercepted by 534 BIA module. 536 The functions that the application uses to pass addresses into the 537 system are: 539 bind() 540 connect() 541 sendmsg() 542 sendto() 544 The functions that return an address from the system to an application 545 are: 547 accept() 548 recvfrom() 549 recvmsg() 550 getpeername() 551 getsockname() 553 The functions that are related to socket options are : 555 getsocketopt() 556 setsocketopt() 558 The functions that are used for conversion of IP addresses embedded in 559 application layer protocol (e.g., FTP, DNS, etc.) are: 561 recv() 562 send() 564 As well, raw sockets for IPv4 and IPv6 SHOULD be intercepted. 566 Most of the socket functions require a pointer to the socket address 567 structure as an argument. Each IPv4 argument is mapped into 568 corresponding an IPv6 argument, and vice versa. 570 According to [SOCK-EXT], the following new IPv6 basic APIs and 571 structures are required. 573 IPv4 new IPv6 574 ------------------------------------------------ 575 AF_INET AF_INET6 576 sockaddr_in sockaddr_in6 577 gethostbyname() getaddrinfo() 578 gethostbyaddr() getnameinfo() 579 inet_ntoa()/inet_addr() inet_pton()/inet_ntop() 580 INADDR_ANY in6addr_any 582 Authors Addresses 584 Seungyun Lee 585 ETRI PEC 586 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea 587 Tel : +82 42 860 5508 588 Fax : +82 42 861 5404 589 Email : syl@pec.etri.re.kr 591 Myung-Ki Shin 592 ETRI PEC 593 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea 594 Tel : +82 42 860 4847 595 Fax : +82 42 861 5404 596 Email : mkshin@pec.etri.re.kr 598 Yong-Jin Kim 599 ETRI PEC 600 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea 601 Tel : +82 42 860 6564 602 Fax : +82 42 861 5404 603 Email : yjkim@pec.etri.re.kr 605 Alain Durand 606 Sun Microsystems 607 901 San Antonio Road 608 UMPK 17-202 609 Palo Alto, CA 94303-4900, USA 610 Tel : +1 650 786 7503 611 Fax : +1 650 786 5896 612 Email : Alain.Durand@sun.com 614 Erik Nordmark 615 Sun Microsystems, Inc. 616 901 San Antonio Road 617 Palo Alto, CA 94303, USA 618 Tel : +1 650 786 5166 619 Fax : +1 650 786 5896 620 Email : nordmark@sun.com