idnits 2.17.1 draft-ietf-ngtrans-bia-02.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 170 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 (January 2002) is 8138 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 490, but no explicit reference was found in the text == Unused Reference: 'NAT' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'IPV4' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'PRIVATE' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'NAT-PT' is defined on line 506, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1933 (ref. 'TRANS-MECH') (Obsoleted by RFC 2893) ** 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 (~~), 12 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: July 2002 Yong-Jin Kim 5 ETRI 6 Erik Nordmark 7 Alain Durand 8 Sun Microsystems 9 January 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 Applicatin version . 10 63 5.6 Implementation Issues .................................... 11 64 6. Limitations .................................................. 11 65 7. Security Considerations ...................................... 11 66 8. Acknowledgments .............................................. 11 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 applicationns. 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 implemetation 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, DNS, etc.) can be translated in API functions. 397 Its 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 This mechanism supports unicast communications only. If it can support 464 multicast functions, some other additional functionalities must be 465 considered in the function mapper module. 467 Since the IPv6 API has new advanced features, it is difficult to 468 translate such kind of IPv6 APIs into IPv4 APIs. Thus, IPv6 inbound 469 communication with advanced features may be discarded. 471 7. Security Considerations 473 Since the mechanism use the API translator at the socket API level, 474 hosts can utilize the security of network layer (e.g., IPsec) when they 475 communicate with IPv6 hosts using IPv4 applications via the mechanism. 477 8. Acknowledgments 479 We would like to acknowledge the implementation contributions by Wanjik 480 Lee(wjlee@arang.miryang.ac.kr) and i2soft Corporation(www.i2soft.net). 482 9. References 484 [TRANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 485 IPv6 Hosts and Routers", RFC 1933, April 1996. 487 [SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 488 2765, February 2000. 490 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", 491 STD 9, RFC 959, October 1985. 493 [NAT] Kjeld B. and P. Francis, "The IP Network Address 494 Translator (NAT)", RFC 1631, May 1994. 496 [IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, 497 September 1981. 499 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 500 (IPv6) Specification", RFC 2460, December 1998. 502 [PRIVATE] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 503 J. and E. Lear, "Address Allocation for Private 504 Internets", BCP 5, RFC 1918, February 1996. 506 [NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address 507 Translation - Protocol Translation (NAT-PT)", RFC 2766, 508 February 2000. 510 [BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts 511 using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, 512 February 2000. 514 [SOCK-EXT] R. Gilligan, S. Thomson, J. Bound and W. Stevens, "Basic 515 Socket Interface Extensions for IPv6", RFC2553, March 1999. 517 Appendix A : API list intercepted by BIA 519 The following functions are the API list which SHOULD be intercepted by 520 BIA module. 522 The functions that the application uses to pass addresses into the 523 system are: 525 bind() 526 connect() 527 sendmsg() 528 sendto() 530 The functions that return an address from the system to an application 531 are: 533 accept() 534 recvfrom() 535 recvmsg() 536 getpeername() 537 getsockname() 539 The functions that are related to socket options are : 541 getsocketopt() 542 setsocketopt() 544 The functions that are used for conversion of IP addresses embedded in 545 application layer protocol (e.g., FTP, DNS, etc.) are: 547 recv() 548 send() 550 As well, raw sockets for IPv4 and IPv6 SHOULD be intercepted. 552 Most of the socket functions require a pointer to the socket address 553 structure as an argument. Each IPv4 argument is mapped into 554 corresponding an IPv6 argument, and vice versa. 556 According to [SOCK-EXT], the following new IPv6 basic APIs and 557 structures are required. 559 IPv4 new IPv6 560 ------------------------------------------------ 561 AF_INET AF_INET6 562 sockaddr_in sockaddr_in6 563 gethostbyname() getaddrinfo() 564 gethostbyaddr() getnameinfo() 565 inet_ntoa()/inet_addr() inet_pton()/inet_ntop() 566 INADDR_ANY in6addr_any 568 Authors Addresses 570 Seungyun Lee 571 ETRI PEC 572 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea 573 Tel : +82 42 860 5508 574 Fax : +82 42 861 5404 575 Email : syl@pec.etri.re.kr 577 Myung-Ki Shin 578 ETRI PEC 579 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea 580 Tel : +82 42 860 4847 581 Fax : +82 42 861 5404 582 Email : mkshin@pec.etri.re.kr 584 Yong-Jin Kim 585 ETRI PEC 586 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea 587 Tel : +82 42 860 6564 588 Fax : +82 42 861 5404 589 Email : yjkim@pec.etri.re.kr 591 Alain Durand 592 Sun Microsystems 593 901 San Antonio Road 594 UMPK 17-202 595 Palo Alto, CA 94303-4900, USA 596 Tel : +1 650 786 7503 597 Fax : +1 650 786 5896 598 Email : Alain.Durand@sun.com 600 Erik Nordmark 601 Sun Microsystems, Inc. 602 901 San Antonio Road 603 Palo Alto, CA 94303, USA 604 Tel : +1 650 786 5166 605 Fax : +1 650 786 5896 606 Email : nordmark@sun.com