idnits 2.17.1 draft-ietf-v6ops-application-transition-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: ---------------------------------------------------------------------------- ** 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 30 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.) == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 2004) is 7374 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC2133' is mentioned on line 828, but not defined ** Obsolete undefined reference: RFC 2133 (Obsoleted by RFC 2553) == Missing Reference: 'MAXSOCK' is mentioned on line 994, but not defined == Unused Reference: 'RFC 3493' is defined on line 1157, but no explicit reference was found in the text == Unused Reference: 'RFC 3542' is defined on line 1161, but no explicit reference was found in the text == Unused Reference: 'DNSOPV6' is defined on line 1202, but no explicit reference was found in the text == Unused Reference: 'AF-APP' is defined on line 1206, but no explicit reference was found in the text == Unused Reference: 'IP-GGF' is defined on line 1214, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3493 ** Downref: Normative reference to an Informational RFC: RFC 3542 ** Obsolete normative reference: RFC 2767 (ref. 'BIS') (Obsoleted by RFC 6535) ** Obsolete normative reference: RFC 3338 (ref. 'BIA') (Obsoleted by RFC 6535) -- Possible downref: Non-RFC (?) normative reference: ref. '2893BIS' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 2732 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group M-K. Shin (ed.) 3 INTERNET DRAFT Y-G. Hong 4 Expires: August 2004 ETRI 5 J. Hagino 6 IIJ 7 P. Savola 8 CSC/FUNET 9 E. M. Castro 10 GSYC/URJC 11 February 2004 13 Application Aspects of IPv6 Transition 14 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsolete by other documents 27 at anytime. It is inappropriate to use Internet Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 As IPv6 networks are deployed and the network transition discussed, 39 one should also consider how to enable IPv6 support in applications 40 running on IPv6 hosts, and the best strategy to develop IP protocol 41 support in applications. This document specifies scenarios and 42 aspects of application transition. It also proposes guidelines on 43 how to develop IP version-independent applications during the 44 transition period. 46 Table of Contents: 48 1. Introduction .............................................. 3 49 2. Overview of IPv6 application transition ................... 3 50 3. Problems with IPv6 application transition ................. 5 51 3.1 IPv6 support in the OS and applications are unrelated.... 5 52 3.2 DNS does not indicate which the IP version will be used . 5 53 3.3 Supporting many versions of an application is difficult ..6 54 4. Description of transition scenarios and guidelines ........ 6 55 4.1 IPv4 applications in a dual-stack node .................. 7 56 4.2 IPv6 applications in a dual-stack node .................. 7 57 4.3 IPv4/IPv6 applications in a dual stack node ............. 9 58 4.4 IPv4/IPv6 applications in an IPv4-only node .............10 59 5. Application porting considerations ........................10 60 5.1 Presentation format for an IP address ...................11 61 5.2 Transport layer API .....................................12 62 5.3 Name and address resolution .............................13 63 5.4 Specific IP dependencies ............................... 13 64 5.4.1 IP address selection .................................13 65 5.4.2 Application framing ..................................13 66 5.4.3 Storage of IP addresses ..............................14 67 5.5 Multicast applications ..................................15 68 6. Developing IP version-independent applications ............16 69 6.1 IP version-independent structures .......................16 70 6.2 IP version-independent APIs .............................17 71 6.2.1 Example of overly simplistic TCP server application ..18 72 6.2.2 Example of overly simplistic TCP client application ..18 73 6.2.3 Binary/presentation format conversion ................19 74 6.3 Iterated jobs for finding the working address ...........20 75 6.3.1 Example of TCP server application ....................20 76 6.3.2 Example of TCP client application ....................21 77 7. Transition mechanism considerations .......................23 78 8. Security considerations ...................................23 79 9. Acknowledgements .........................................23 80 10. References ...............................................23 81 Authors' addresses ...........................................25 82 Appendix A. Binary/presentation format conversions ...........26 83 A.1 Network address to presentation format ..................26 84 A.2 Presentation format to network address ..................28 86 1. Introduction 88 As IPv6 is introduced in the IPv4-based Internet, several general 89 issues arise such as routing, addressing, DNS, scenarios, etc. 91 One important key to a successful IPv6 transition is the 92 compatibility with the large installed base of IPv4 hosts and 93 routers. This issue had been already been extensively studied, and 94 the work is still in progress. In particular, [2893BIS] describes 95 the basic transition mechanisms, dual-stack deployment and 96 tunneling. In addition, various kinds of transition mechanisms 97 have been developed to migrate to IPv6 network. However, these 98 transition mechanisms take no stance on whether applications 99 support IPv6 or not. 101 This document specifies application aspects of IPv6 transition. 102 That is, two inter-related topics are covered: 104 1. How different network transition techniques affect 105 applications, and what are the strategies for applications 106 to support IPv6 and IPv4. 108 2. How to develop IPv6-capable or protocol-independent 109 applications ("application porting guidelines"). 111 Applications will need to be modified to support IPv6 (and IPv4), 112 using one of a number of techniques described in sections 2-4. 113 Some guidelines to develop such application are then presented in 114 sections 5 and 6. 116 2. Overview of IPv6 application transition 118 The transition of an application can be classifed using four 119 different cases (excluding the first case when there is no IPv6 120 support either in the application or the operating system), as 121 follows: 123 +-------------------+ 124 | appv4 | (appv4 - IPv4-only applications) 125 +-------------------+ 126 | TCP / UDP / others| (transport protocols - TCP, UDP, 127 +-------------------+ SCTP, DCCP, etc.) 128 | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) 129 +-------------------+ 131 Case 1. IPv4 applications in a dual-stack node 132 +-------------------+ (appv4 - IPv4-only applications) 133 | appv4 | appv6 | (appv6 - IPv6-only applications) 134 +-------------------+ 135 | TCP / UDP / others| (transport protocols - TCP, UDP, 136 +-------------------+ SCTP, DCCP, etc.) 137 | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) 138 +-------------------+ 140 Case 2. IPv4-only applications and IPv6-only applications 141 in a dual-stack node 143 +-------------------+ 144 | appv4/v6 | (appv4/v6 - applications supporting 145 +-------------------+ both IPv4 and IPv6) 146 | TCP / UDP / others| (transport protocols - TCP, UDP, 147 +-------------------+ SCTP, DCCP, etc.) 148 | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) 149 +-------------------+ 151 Case 3. Applications supporting both IPv4 and IPv6 152 in a dual-stack node 154 +-------------------+ 155 | appv4/v6 | (appv4/v6 - applications supporting 156 +-------------------+ both IPv4 and IPv6) 157 | TCP / UDP / others| (transport protocols - TCP, UDP, 158 +-------------------+ SCTP, DCCP, etc.) 159 | IPv4 | (IP protocols supported/enabled in the OS) 160 +-------------------+ 162 Case 4. Applications supporting both IPv4 and IPv6 163 in an IPv4-only node 165 Figure 1. Overview of Application Transition 167 Figure 1 shows the cases of application transition. 169 Case 1 : IPv4-only applications in a dual-stack node. 170 IPv6 protocol is introduced in a node, but 171 applications are not yet ported to IPv6. 173 Case 2 : IPv4-only applications and IPv6-only applications 174 in a dual-stack node. 175 Applications are ported for IPv6-only. Therefore 176 there are two similar applications, one for each 177 protocol version (e.g., ping and ping6). 179 Case 3 : Applications supporting both IPv4 and IPv6 in a dual 180 stack node. 181 Applications are ported for both IPv4 and IPv6 support. 182 Therefore, the existing IPv4 applications can be 183 removed. 185 Case 4 : Applications supporting both IPv4 and IPv6 in an 186 IPv4-only node. 187 Applications are ported for both IPv4 and IPv6 support, 188 but the same applications may also have to work when 189 IPv6 is not being used (e.g. disabled from the OS). 191 Note that this draft does not address DCCP and SCTP considerations 192 at this phase. 194 3. Problems with IPv6 application transition 196 There are several reasons why the transition period between IPv4 197 and IPv6 applications may not be straightforward. These issues are 198 described in this section. 200 3.1 IPv6 support in the OS and applications are unrelated 202 Considering the cases described in the previous section, IPv4 and 203 IPv6 protocol stacks in a node is likely to co-exist for a long 204 time. 206 Similarly, most applications are expected to be able to handle both 207 IPv4 and IPv6 during another, unrelated long time period. That is, 208 the operating system being dual stack does not mean having both 209 IPv4 and IPv6 applications. Therefore, IPv6-capable application 210 transition may be independent of protocol stacks in a node. 212 It is even probable that applications capable of both IPv4 and IPv6 213 will have to work properly in IPv4-only nodes (whether the IPv6 214 protocol is completely disabled or there is no IPv6 connectivity at 215 all). 217 3.2 DNS does not indicate which the IP version will be used 219 The role of the DNS name resolver in a node is to get the list of 220 destination addresses. DNS queries and responses are sent using 221 either IPv4 or IPv6 to carry the queries, regardless of the 222 protocol version of the data records [DNSTRANS]. 224 The issue of DNS name resolution related to application transition, 225 is that a client application can not be certain of the version of 226 the peer application by only doing a DNS name lookup. For example, 227 if a server application does not support IPv6 yet, but runs on a 228 dual-stack machine for other IPv6 services, and this is listed with 229 an AAAA record in the DNS, the client application will fail to 230 connect to the server application. This is caused by a mis-match 231 between the DNS query result (i.e. IPv6 addresses) and a server 232 application version (i.e. IPv4). 234 It is bad practise to add an AAAA record for a node that does not 235 support all the services using IPv6 (rather, an AAAA record for the 236 specific service name and address should be used). However, the 237 application cannot depend on "good practise", and this must be 238 handled. 240 In consequence, the application should request all IP addresses 241 without address family constraints and try all the records returned 242 from the DNS, in some order, until a working address is found. In 243 particular, the application has to be able to handle all IP 244 versions returned from the DNS. 246 3.3 Supporting many versions of an application is difficult 248 During the application transition period, system administrators may 249 have various versions of the same application (an IPv4-only 250 application, an IPv6-only application, or an application supporting 251 both IPv4 and IPv6). 253 Typically one cannot know which IP versions must be supported prior 254 to doing a DNS lookup *and* trying (see section 3.2) the addresses 255 returned. Therefore, the users have a difficulty selecting the 256 right application version supporting the exact IP version required 257 if multiple versions of the same application are available. 259 To avoid problems with one application not supporting the specified 260 protocol version, it is desirable to have hybrid applications 261 supporting both of the protocol versions. 263 An alternative approach is to have a "wrapper application" which 264 performs certain tasks (like figures out which protocol version 265 will be used) and calls the IPv4/IPv6-only applications as 266 necessary. However, these wrapper applications will actually 267 probably have to do more than just perform a DNS lookup or figure 268 out the literal IP address given. Thus, they may get complex, and 269 only work for certain kinds of, usually simple, applications. 271 Nonetheless, there should be some reasonable logic to enable the 272 users to use the applications with any supported protocol version; 273 the users should not have to select from various versions of 274 applications, some supporting only IPv4, others only IPv6, and yet 275 some both versions by themselves. 277 4. Description of transition scenarios and guidelines 279 Once the IPv6 network is deployed, applications supporting IPv6 can 280 use IPv6 network services and establish IPv6 connections. However, 281 upgrading every node to IPv6 at the same time is not feasible and 282 transition from IPv4 to IPv6 will be a gradual process. 284 Dual-stack nodes are one of the ways to maintain IPv4 compatibility 285 in unicast communications. In this section we will analyze 286 different application transition scenarios (as introduced in 287 section 2) and guidelines to maintain interoperability between 288 applications running in different types of nodes. 290 4.1 IPv4 applications in a dual-stack node 292 This scenario happens if the IPv6 protocol is added in a node but 293 IPv6-capable applications aren't yet available or installed. 294 Although the node implements the dual stack, IPv4 applications can 295 only manage IPv4 communications. Then, IPv4 applications can only 296 accept/establish connections from/to nodes which implement an IPv4 297 stack. 299 In order to allow an application to communicate with other nodes 300 using IPv6, the first priority is to port applications to IPv6. 302 In some cases (e.g. no source code is available), existing IPv4 303 applications can work if the [BIS] or [BIA] mechanism is installed 304 in the node. However, these mechanisms should not be used when 305 application source code is available to prevent their mis-use, for 306 example, as an excuse not to port software. 308 When [BIA] or [BIS] is used, the problem described in section 3.2 309 becomes an issue --the IPv4 client in a [BIS]/[BIA] node trying to 310 connect to an IPv4 server in a dual stack system-- arises. However, 311 one can rely on the [BIA]/[BIS] mechanism, which should cycle 312 through all the addresses instead of applications. 314 [BIS] or [BIA] does not work with all kinds of applications. In 315 particular, the applications which exchange IP addresses as 316 application data (e.g., FTP). These mechanisms provide IPv4 317 temporary addresses to the applications and locally make a 318 translation between IPv4 and IPv6 communication. Hence, these IPv4 319 temporary addresses are only valid in the node scope." 321 4.2 IPv6 applications in a dual-stack node 323 As we have seen in the previous section, applications should be 324 ported to IPv6. The easiest way to port an IPv4 application is to 325 substitute the old IPv4 API references with the new IPv6 one-to-one 326 API mapping. This way the application will be IPv6-only. This 327 IPv6-only source code can not work in IPv4-only nodes, so the old 328 IPv4 application should be maintained in these nodes. Then, we will 329 get two similar applications working with different protocol 330 versions, depending on the node they are running (e.g., telnet and 331 telnet6). This case is undesirable since maintaining two versions 332 of the same source code per application, could be a difficult task. 333 In addition, this approach would cause problems for the users when 334 having to select which version of the application to use, as 335 described in section 3.3. 337 Most implementations of dual stack allow IPv6-only applications to 338 interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to 339 IPv6 applications on a dual-stack node, reach their destination 340 because their addresses are mapped to IPv6 ones using IPv4-mapped 341 IPv6 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4 342 address x.y.z.w. 344 +----------------------------------------------+ 345 | +------------------------------------------+ | 346 | | | | 347 | | IPv6-only applications | | 348 | | | | 349 | +------------------------------------------+ | 350 | | | 351 | +------------------------------------------+ | 352 | | | | 353 | | TCP / UDP / others (SCTP, DCCP, etc.) | | 354 | | | | 355 | +------------------------------------------+ | 356 | IPv4-mapped | | IPv6 | 357 | IPv6 addresses | | addresses | 358 | +--------------------+ +-------------------+ | 359 | | IPv4 | | IPv6 | | 360 | +--------------------+ +-------------------+ | 361 | IPv4 | | | 362 | adresses | | | 363 +--------------|-----------------|-------------+ 364 | | 365 IPv4 packets IPv6 packets 367 We will analyze the behaviour of IPv6-applications which exchange 368 IPv4 packets with IPv4 applications using the client/server model. 369 We consider the default case when the IPV6_V6ONLY socket option has 370 not been set. This default behavior of IPv6 applications in these 371 dual-stack nodes allows a limited amount of IPv4 communication 372 using the IPv4-mapped IPv6 addresses. 374 IPv6-only server: 375 When an IPv4 client application sends data to an 376 IPv6-only server application running on a dual-stack 377 node using the wildcard address, the IPv4 client address 378 is interpreted as the IPv4-mapped IPv6 address in the 379 dual-stack node. This allows the IPv6 application to 380 manage the communication. The IPv6 server will use this 381 mapped address as if it were a regular IPv6 address, and 382 a usual IPv6 connection. However, IPv4 packets will be 383 exchanged between the nodes. Kernels with dual stack 384 properly interpret IPv4-mapped IPv6 addresses as IPv4 385 ones and vice versa. 387 IPv6-only client: 388 IPv6-only client applications in a dual-stack node will 389 not get IPv4-mapped addresses from the hostname 390 resolution API functions unless a special hint, 391 AI_V4MAPPED, is given. If given, the IPv6 client will 392 use the returned mapped address as if it were a regular 393 IPv6 address, and a usual IPv6 connection. However, again 394 IPv4 packets will be exchanged between applications. 396 Respectively, with IPV6_V6ONLY set, an IPv6-only server application 397 will only communicate with IPv6 nodes, and an IPv6-only client with 398 IPv6 servers, as the mapped addresses have been disabled. This 399 option could be useful if applications use new IPv6 features, such 400 as flowlabel. If communication with IPv4 is needed, either 401 IPV6_V6ONLY must not be used, or dual-stack applications be used, 402 as described in section 4.3. 404 There are some implementations of dual-stack which do not allow 405 IPv4-mapped IPv6 addresses to be used for interoperability between 406 IPv4 and IPv6 applications. In that case, there are two ways to 407 handle the problem: 409 1. deploy two different versions of the application (possibly 410 attached with '6' in the name), or 412 2. deploy just one application supporting both protocol versions 413 as described in the next section. 415 The first method is not recommended because of a significant amount 416 of problems associated with selecting the right applications.This 417 scenario is described in sections 3.2 and 3.3. 419 Therefore, there are actually two distinct cases to consider when 420 writing one application to support both protocols: 422 1. whether the application can (or should) support both IPv4 423 and IPv6 through IPv4-mapped IPv6 addresses, or should the 424 applications support both explicitly (see section 4.3), and 426 2. whether the systems where the applications are used support 427 IPv6 at all or not (see section 4.4). 429 Note that some systems will disable (by default) support for 430 internal IPv4-mapped IPv6 addresses. The security concerns 431 regarding IPv4-mapped IPv6 addresses on the wire are legitimate but 432 disabling it internally breaks one transition mechanism for server 433 apps which were originally written to bind and listen to a single 434 socket using a wildcard address. This forces the software developer 435 to rewrite the daemon to create 2 separate sockets, one for IPv4 436 only and the other for IPv6 only, and then use select(). However, 437 enabling mapping of IPv4 addresses on any particular system is 438 controlled by the OS owner and not necessarilly by a developer. 439 This complicates the developer's work as he now has to rewrite the 440 daemon network code to handle both environments, even for the same 441 OS. 443 4.3 IPv4/IPv6 applications in a dual stack node 445 Applications should be ported to support both IPv4 and IPv6; such 446 applications are sometimes called IP version-independent 447 applications. After that, the existing IPv4-only applications 448 could be removed. Since we have only one version of each 449 application, the source code will be typically easy to maintain and 450 to modify, and there are no problems managing which application to 451 select for which purpose. 453 This transition case is the most advisable. During the IPv6 454 transition period applications supporting both IPv4 and IPv6 should 455 be able to communicate with other applications, irrespective of the 456 versions of the protocol stack or the application in the node. 457 Dual applications allow more interoperability between heterogeneous 458 applications and nodes. 460 If the source code is written in a protocol-independent way, 461 without dependencies on either IPv4 or IPv6, applications will be 462 able to communicate with any combination of applications and types 463 of nodes. 465 Implementations typically by-default prefer IPv6 if the remote node 466 and application support it. However, if IPv6 connections fail, 467 dual applications will automatically try IPv4 ones. The resolver 468 returns a list of valid addresses for the remote node and 469 applications can iterate through all, first trying IPv6 ones, until 470 connection succeeds. 472 Applications writers should be aware of this typical by-default 473 ordering, but the applications themselves typically need not be 474 aware of the the local protocol ordering [RFC 3484]. 476 If the source code is written in a protocol-dependent way, the 477 application will suport IPv4 and IPv6 explicitly using 2 separate 478 sockets. Note that there are some differences in bind() 479 implementation, whether you can first bind to the IPv6 wildcard 480 address, and then the IPv4. It can be a pain to write applications 481 that cope with this. If IPV6_V6ONLY is implemented, this becomes 482 simpler. The reason the IPv4 wildcard bind fails on some systems is 483 that the IPv4 address space is embedded into IPv6 address space 484 when using IPv4-mapped IPv6 addresses. 486 A more detailed porting guideline is described in section 6. 488 4.4. IPv4/IPv6 applications in an IPv4-only node 490 As the transition is likely to happen over a longer timeframe, 491 applications that have already been ported to support both IPv4 and 492 IPv6 may be run on IPv4-only nodes. This would typically be done to 493 avoid having to support two application versions for older and 494 newer operating systems, or to support the case that the user wants 495 to disable IPv6 for some reason. 497 Depending on how application/operating system support is done, some 498 may want to ignore this case, but usually no assumptions can be 499 made and applications should also work in this scenario. 501 An example is an application that issues a socket() command, first 502 trying AF_INET6 and then AF_INET. However, if the kernel does not 503 have IPv6 support, the call will result in an EPROTONOSUPPORT or 504 EAFNOSUPPORT error. Typically, encountering errors like these leads 505 to exiting the socket loop, and AF_INET will not even be tried. 506 The application will need to handle this case or build the loop in 507 such a way that errors are ignored until the last address family. 509 So, this case is just an extension of the IPv4/IPv6 support in the 510 previous case, covering one relatively common but often ignored 511 case. 513 5. Application porting considerations 515 The minimum changes to IPv4 applications to work with IPv6 are 516 based on the different size and format of IPv4 and IPv6 addresses. 518 Applications have been developed with the assumption they would use 519 IPv4 as their network protocol. This assumption results in many IP 520 dependencies through source code. 522 The following list summarizes the more common IP version 523 dependencies in applications: 525 a) Presentation format for an IP address: it is an ASCII string 526 which represents the IP address, dotted-decimal string 527 for IPv4 and hexadecimal string for IPv6. 529 b) Transport layer API: functions to establish communications 530 and to exchange information. 532 c) Name and address resolution: conversion functions between 533 hostnames and IP addresses, and vice versa. 535 d) Specific IP dependencies: more specific IP version 536 dependencies, such as: IP address selection, 537 application framing, storage of IP addresses. 539 e) Multicast applications: one must find the IPv6 equivalents to 540 the IPv4 multicast addresses, and use the right socket 541 configuration options. 543 In the following subsections, the problems with the aforementioned 544 IP version dependencies are analyzed. Although application source 545 code can be ported to IPv6 with minimum changes related to IP 546 addresses, some recommendations are given to modify the source code 547 in a protocol independent way, which will allow applications to 548 work using both IPv4 and IPv6. 550 5.1 Presentation format for an IP address 552 Many applications use IP addresses to identify network nodes and to 553 establish connections to destination addresses. For instance, using 554 the client/server model, clients usually need an IP address as an 555 application parameter to connect to a server. This IP address is 556 usually provided in the presentation format, as a string. There 557 are two problems, when porting the presentation format for an IP 558 address: the allocated memory and the management of the 559 presentation format. 561 Usually, the allocated memory to contain an IPv4 address 562 representation as a string is unable to contain an IPv6 address. 563 Applications should be modified to prevent buffer overflows made 564 possible by the larger IPv6 address. 566 IPv4 and IPv6 do not use the same presentation format. IPv4 uses a 567 dot (.) to separate the four octets written in decimal notation and 568 IPv6 uses a colon (:) to separate each pair of octets written in 569 hexadecimal notation. In order to support both IPv4 and IPv6, the 570 management functions of presentation format, such as IP address 571 parsers, should be changed to be compliant with both of the formats 572 [TextRep]. 574 A particular problem with IP address parsers comes when the input 575 is actually a combination of IP address and port number. With IPv4 576 these are often coupled with a semi-colon such as "192.0.2.1:80". 577 However, such an approach would be ambiguous with IPv6 as colons 578 are already used to structure the address. 580 Therefore, the IP address parsers which take the port number 581 separated with a colon should represent IPv6 addresses somehow. 582 One way is to enclose the address in brackets, as is done with 583 Uniform Resource Locators (URLs) [RFC 2732], like 584 http://[2001:db8::1]:80. 586 Prefix/len format should be also considered if surrounding brackets 587 are used. In order to avoid ambiguity, the format, like 588 [2001:db8::]/64 is recommended. 590 In some specific cases, it may be necessary to give a zone 591 identifier as part of the address, like fe80::1%eth0. In general, 592 applications should not need to parse these identifiers. 594 The IP address parsers should support enclosing the IPv6 address in 595 brackets even when it's not used in conjunction with a port number, 596 but requiring that the user always gives a literal IP address 597 enclosed in brackets is not recommended. 599 There is an another consideration on IPv6 address literals in SMTP 600 commands [RFC 2821], i.e., [IPv6: 2001:db8::1]. 602 Note that the use of address literals is strongly discouraged for 603 general purpose direct input to the applications; host names and 604 DNS should be used instead. 606 5.2 Transport layer API 608 Communication applications often include a transport module that 609 establishes communications. Usually this module manages everything 610 related to communications and uses a transport layer API, typically 611 as a network library. When porting an application to IPv6, most 612 changes should be made in this application transport module in 613 order to be adapted to the new IPv6 API. 615 In the general case, porting an existing application to IPv6 616 requires an examination of the following issues related to the API: 618 - Network information storage: IP address data structures. 619 The new structures must contain 128-bit IP addresses. The use of 620 generic address structures, which can store any address family, 621 is recommended. 622 Sometimes special addresses are hard-coded in the application 623 source; developers should pay attention to them in order to use 624 the new address format. Some of these special IP addresses are: 625 wildcard local, loopback and broadcast. IPv6 does not have 626 the broadcast addresses, so applications can use multicast 627 instead. 629 - Address conversion functions. 630 The address conversion functions convert the binary address 631 representation to the presentation format and vice versa. The 632 new conversion functions are specified to the IPv6 address 633 format. 635 - Communication API functions. 636 These functions manage communications. Their signatures are 637 defined based on a generic socket address structure. The 638 same functions are valid for IPv6, however, the IP address data 639 structures used when calling these functions require the 640 updates. 642 - Network configuration options. 643 They are used when configuring different communication models 644 for Input/Output (I/O) operations (blocking/nonblocking, I/O 645 multiplexing, etc) and should be translated to the IPv6 ones. 647 5.3 Name and address resolution 649 From the application point of view, the name and address resolution 650 is a system-independent process. An application calls functions in 651 a system library, the resolver, which is linked into the 652 application when this is built. However, these functions use IP 653 address structures, which are protocol dependent, and must be 654 reviewed to support the new IPv6 resolution calls. 656 There are two basic resolution functions. The first function 657 returns a list of all configured IP addresses for a hostname. These 658 queries can be constrained to one protocol family, for instance 659 only IPv4 or only IPv6 addresses. However, the recommendation is 660 that all configured IP addresses should be obtained to allow 661 applications to work with every kind of node. And the second 662 function returns the hostname associated to an IP address. 664 5.4.1 IP address selection 666 IPv6 promotes the configuration of multiple IP addresses per node, 667 which is a difference when compared with the IPv4 model; however 668 applications only use a destination/source pair for a 669 communication. Choosing the right IP source and destination 670 addresses is a key factor that may determine the route of IP 671 datagrams. 673 Typically nodes, not applications, automatically solve the source 674 address selection. A node will choose the source address for a 675 communication following some rules of best choice, [RFC 3484], but 676 also allowing applications to make changes in the ordering rules. 678 When selecting the destination address, applications usually ask a 679 resolver for the destination IP address. The resolver returns a set 680 of valid IP addresses from a hostname. Unless applications have a 681 specific reason to select any particular destination address, they 682 should just try each element in the list until the communication 683 succeeds. 685 5.4.2 Application framing 687 The Application Level Framing (ALF) architecture controls 688 mechanisms that traditionally fall within the transport layer. 689 Applications implementing ALF are often responsible for packetizing 690 data into Application Data Units (ADUs). The application problem 691 when using ALF is the ADU size selection to obtain better 692 performance. 694 Application framing is typically needed by applications using 695 connectionless protocols (such as UDP). The application will have 696 to know, or be able to detect, the packet sizes which can be sent 697 and received, end-to-end, on the network. 699 Applications can use 1280 octets as a data length. [RFC 2460] 700 specifies an IPv6 requirement that every link in the Internet have 701 a Maximum Transmission Unit (MTU) of 1280 octets or greater. 702 However, in order to get better performance, ADU size should be 703 calculated based on the length of transmission unit of underlying 704 protocols. 706 FIXME: Application framing has relations e.g. with Path MTU 707 Discovery and application design which need to be analyzed better. 709 5.4.3 Storage of IP addresses 711 Some applications store IP addresses as information of remote 712 peers. For instance, one of the most popular ways to register 713 remote nodes in collaborative applications is based on using IP 714 addresses as registry keys. 716 Although the source code that stores IP addresses can be modified 717 to IPv6 following the previous basic porting recommendations, there 718 are some reasons why applications should not store IP addresses: 720 - IP addresses can change throughout time, for instance 721 after a renumbering process. 723 - The same node can reach a destination host using different 724 IP addresses. 726 When possible, applications should store names, such as FQDNs, 727 instead of storing addresses. In this case applications are only 728 bound to specific addresses at run time, or for the duration of a 729 cache lifetime. Other types of applications, such as massive peer 730 to peer systems with their own rendez-vous and discovery 731 mechanisms, may need to cache addresses for performance reasons, 732 but cached addresses should not be treated as permanent, reliable 733 information. In highly dynamic networks any form of name 734 resolution may be impossible, and here again addresses must be 735 cached. 737 5.5 Multicast applications 739 There is an additional problem in porting multicast applications. 740 When using multicast facilities some changes must be carried out to 741 support IPv6. First, applications must change the IPv4 multicast 742 addresses to IPv6 ones, and second, the socket configuration 743 options must be changed. 745 All the IPv6 multicast addresses encode scope; the scope was only 746 implicit in IPv4 (with multicast groups in 239/8). Also, while a 747 large number of application-specific multicast addresses have been 748 assigned with IPv4, this has been (luckily enough) avoided in IPv6. 749 So, there are no direct equivalents for all the multicast 750 addresses. For link-local multicast, it's possible to pick almost 751 anything within the link-local scope. The global groups could use 752 unicast-prefix-based addresses [RFC 3306]. All in all, this may 753 force the application developers to write more protocol dependent 754 code. 756 Another problem is/has been that IPv6 multicast does not yet have a 757 standardized mechanism for traditional Any Source Multicast for 758 Interdomain multicast. The models for Any Source Multicast (ASM) 759 or Source-Specific Multicast (SSM) are generally similar between 760 IPv4 and IPv6, but it is likely that PIM-SSM will become more 761 widely deployed in IPv6 due to its simpler architecture. 763 So, it might be beneficial to port the applications to use SSM 764 semantics, requiring off-band source discovery mechanisms and the 765 use of a different API [RFC 3678]. Inter-domain ASM service is 766 available only through a method embedding the Rendezvous Point 767 address in the multicast address [Embed-RP]. 769 Another generic problem for multiparty conferencing applications, 770 which is similar to the issues with peer-to-peer applications, is 771 that all the users of the session must use the same protocol 772 version (IPv4 or IPv6), or some form of proxies or translators must 773 be used (e.g., [MUL-GW]). 775 6. Developing IP version-independent applications 777 As we have seen before, dual applications working with both IPv4 778 and IPv6 are recommended. These applications should avoid IP 779 dependencies in the source code. However, if IP dependencies are 780 required, one of the best solutions is based on building a 781 communication library which provides an IP version independent API 782 to applications and hides all dependencies. 784 In order to develop IP version independent applications, the 785 following guidelines should be considered. 787 6.1 IP version-independent structures 789 All of the memory structures and APIs should be IP version- 790 independent. In that sense, one should avoid structs in_addr, 791 in6_addr, sockaddr_in and sockaddr_in6. 793 Suppose you pass a network address to some function, foo(). If you 794 use struct in_addr or struct in6_addr, you will end up with an 795 extra parameter to indicate address family, as below: 797 struct in_addr in4addr; 798 struct in6_addr in6addr; 799 /* IPv4 case */ 800 foo(&in4addr, AF_INET); 801 /* IPv6 case */ 802 foo(&in6addr, AF_INET6); 804 However, this leads to duplicated code and having to consider each 805 scenario from both perspectives independently; this is difficult to 806 maintain. So, we should use struct sockaddr_storage like below. 808 struct sockaddr_storage ss; 809 int sslen; 810 /* AF independent! - use sockaddr when passing a pointer */ 811 /* note: it's typically necessary to also pass the length 812 explicitly */ 813 foo((struct sockaddr *)&ss, sslen); 815 6.2 IP version-independent APIs 817 getaddrinfo() and getnameinfo() are new address independent 818 variants that hide the gory details of name-to-address and 819 address-to-name translations. They implement functionalities of 820 the following functions: 822 gethostbyname() 823 gethostbyaddr() 824 getservbyname() 825 getservbyport() 827 They also obsolete the functionality of gethostbyname2(), defined 828 in [RFC2133]. 830 These can perform hostname/address and service name/port lookups, 831 though the features can be turned off if desirable. getaddrinfo() 832 can return multiple addresses, as below: 834 localhost. IN A 127.0.0.1 835 IN A 127.0.0.2 836 IN AAAA ::1 838 In this example, if IPv6 is preferred, getaddrinfo returns first 839 ::1, and then both 127.0.0.1 and 127.0.0.2 is in a random order. 841 Getaddrinfo() and getnameinfo() can query hostname as well as 842 service name/port at once. 844 As well, it is not preferred to hardcode AF-dependent knowledge 845 into the program. The construct like below should be avoided: 847 /* BAD EXAMPLE */ 848 switch (sa->sa_family) { 849 case AF_INET: 850 salen = sizeof(struct sockaddr_in); 851 break; 852 } 854 Instead, we should use the ai_addrlen member of the addrinfo 855 structure, as returned by getaddrinfo(). 857 The gethostbyname(), gethostbyaddr(), getservbyname(), and 858 getservbyport() are mainly used to get server and client sockets. 859 Following, we will see simple examples to create these sockets 860 using the new IPv6 resolution functions. 862 6.2.1 Example of overly simplistic TCP server application 864 A simple TCP server socket at service name (or port number string) 865 SERVICE: 867 /* 868 * BAD EXAMPLE: does not implement the getaddrinfo loop as 869 * specified in 6.3. This may result in one of the following: 870 * - an IPv6 server, listening at the wildcard address, 871 * allowing IPv4 addresses through IPv4-mapped IPv6 addresses. 872 * - an IPv4 server, if IPv6 is not enabled, 873 * - an IPv6-only server, if IPv6 is enabled but IPv4-mapped IPv6 874 * addresses are not used by default, or 875 * - no server at all, if getaddrinfo supports IPv6, but the 876 * system doesn't, and socket(AF_INET6, ...) exists with an 877 * error. 878 */ 879 struct addrinfo hints, *res; 880 int error, sockfd; 882 memset(&hints, 0, sizeof(hints)); 883 hints.ai_flags = AI_PASSIVE; 884 hints.ai_family = AF_UNSPEC; 885 hints.ai_socktype = SOCK_STREAM; 887 error = getaddrinfo(NULL, SERVICE, &hints, &res); 888 if (error != 0) { 889 /* handle getaddrinfo error */ 890 } 892 sockfd = socket(res->family, res->ai_socktype, res->ai_protocol); 893 if (sockfd < 0) { 894 /* handle socket error */ 895 } 897 if (bind(sockfd, res->ai_addr, res->ai_addrlen) < 0) { 898 /* handle bind error */ 899 } 901 /* ... */ 903 freeaddrinfo(res); 905 6.2.2 Example of overly simplistic TCP client application 907 A simple TCP client socket connecting to a server which is running 908 at node name (or IP address presentation format) SERVER_NODE and 909 service name (or port number string) SERVICE: 911 /* 912 * BAD EXAMPLE: does not implement the getaddrinfo loop as 913 * specified in 6.3. This may result in one of the following: 914 * - an IPv4 connection to the IPv4 destination, 915 * - an IPv6 connection to an IPv6 destination, 916 * - an attempt to try to reach an IPv6 destination (if AAAA 917 * record found), but failing -- without fallbacks -- because: 918 * o getaddrinfo supports IPv6 but the system does not 919 * o IPv6 routing doesn't exist, so falling back to e.g. TCP 920 * timeouts 921 * o IPv6 server reached, but service not IPv6-enabled or 922 * firewalled away 923 * - if the first destination is not reached, there is no 924 * fallback to the next records 925 */ 926 struct addrinfo hints, *res; 927 int error, sockfd; 929 memset(&hints, 0, sizeof(hints)); 930 hints.ai_family = AF_UNSPEC; 931 hints.ai_socktype = SOCK_STREAM; 933 error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res); 934 if (error != 0) { 935 /* handle getaddrinfo error */ 936 } 938 sockfd = socket(res->family, res->ai_socktype, res->ai_protocol); 939 if (sockfd < 0) { 940 /* handle socket error */ 941 } 943 if (connect(sockfd, res->ai_addr, res->ai_addrlen) < 0 ) { 944 /* handle connect error */ 945 } 947 /* ... */ 949 freeaddrinfo(res); 951 6.2.3 Binary/presentation format conversion 953 In addition, we should consider the binary and presentation address 954 format conversion APIs. The following functions convert network 955 address structure in its presentation address format and vice 956 versa: 958 inet_ntop() 959 inet_pton() 961 Both are from the basic socket extensions for IPv6. Since these 962 functions are not protocol independent, we should write code for 963 the different address families. 965 A more detailed examples are described in appendix A. 967 Note that inet_ntop()/inet_pton() lose the scope identifier (if 968 used e.g. with link-local addresses) in the conversions, contrary 969 to the getaddrinfo()/getnameinfo() functions. 971 6.3 Iterated jobs for finding the working address 973 In a client code, when multiple addresses are returned from 974 getaddrinfo(), we should try all of them until connection succeds. 975 When a failure occurs with socket(), connect(), bind(), or some 976 other function, go on to try the next address. 978 In addition, if something is wrong with the socket call because the 979 address family is not supported (i.e., in case of section 4.4), 980 applications should try the next address structure. 982 Note: in the following examples, the socket() return value error 983 handling could be simplied by substituting special checking of 984 specific error numbers by always continuing on with the socket 985 loop. Whether this is a better idea should be considered in more 986 detail. 988 6.3.1 Example of TCP server application 990 The previous example TCP server example should be written: 992 #define MAXSOCK 2 993 struct addrinfo hints, *res; 994 int error, sockfd[MAXSOCK], nsock=0; 996 memset(&hints, 0, sizeof(hints)); 997 hints.ai_flags = AI_PASSIVE; 998 hints.ai_family = AF_UNSPEC; 999 hints.ai_socktype = SOCK_STREAM; 1001 error = getaddrinfo(NULL, SERVICE, &hints, &res); 1002 if (error != 0) { 1003 /* handle getaddrinfo error */ 1004 } 1006 for (aip=res; aip && nsock < MAXSOCK; aip=aip->ai_next) { 1007 sockfd[nsock] = socket(aip->ai_family, 1008 aip->ai_socktype, 1009 aip->ai_protocol); 1011 if (sockfd[nsock] < 0) { 1012 switch errno { 1013 case EAFNOSUPPORT: 1014 case EPROTONOSUPPORT: 1015 /* 1016 * e.g., skip the errors until 1017 * the last address family, 1018 * see section 4.4. 1019 */ 1020 if (aip->ai_next) 1021 continue; 1022 else { 1023 /* handle unknown protocol errors */ 1024 break; 1025 } 1026 default: 1027 /* handle other socket errors */ 1028 ; 1029 } 1031 } else { 1032 int on = 1; 1033 /* optional: works better if dual-binding to wildcard 1034 address */ 1035 if (aip->ai_family == AF_INET6) { 1036 setsockopt(sockfd[nsock], IPPROTO_IPV6, IPV6_V6ONLY, 1037 (char *)&on, sizeof(on)); 1038 /* errors are ignored */ 1039 } 1040 if (bind(sockfd[nsock], aip->ai_addr, 1041 aip->ai_addrlen) < 0 ) { 1042 /* handle bind error */ 1043 close(sockfd[nsock]); 1044 continue; 1045 } 1046 if (listen(sockfd[nsock], SOMAXCONN) < 0) { 1047 /* handle listen errors */ 1048 close(sockfd[nsock]); 1049 continue; 1050 } 1051 } 1052 nsock++; 1053 } 1054 freeaddrinfo(res); 1056 /* check that we were able to obtain the sockets */ 1058 6.3.2 Example of TCP client application 1060 The previous TCP client example should be written: 1062 struct addrinfo hints, *res, *aip; 1063 int sockfd, error; 1065 memset(&hints, 0, sizeof(hints)); 1066 hints.ai_family = AF_UNSPEC; 1067 hints.ai_socktype = SOCK_STREAM; 1069 error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res); 1070 if (error != 0) { 1071 /* handle getaddrinfo error */ 1072 } 1074 for (aip=res; aip; aip=aip->ai_next) { 1076 sockfd = socket(aip->ai_family, 1077 aip->ai_socktype, 1078 aip->ai_protocol); 1080 if (sockfd < 0) { 1081 switch errno { 1082 case EAFNOSUPPORT: 1083 case EPROTONOSUPPORT: 1084 /* 1085 * e.g., skip the errors until 1086 * the last address family, 1087 * see section 4.4. 1088 */ 1089 if (aip->ai_next) 1090 continue; 1091 else { 1092 /* handle unknown protocol errors */ 1093 break; 1094 } 1096 default: 1097 /* handle other socket errors */ 1098 ; 1099 } 1101 } else { 1102 if (connect(sockfd, aip->ai_addr, aip->ai_addrlen) == 0) 1103 break; 1105 /* handle connect errors */ 1106 close(sockfd); 1107 sockfd=-1; 1108 } 1109 } 1111 if (sockfd > 0) { 1112 /* socket connected to server address */ 1114 /* ... */ 1115 } 1117 freeaddrinfo(res); 1119 7. Transition mechanism considerations 1121 A mechanism, [NAT-PT], introduces a special set of addresses, 1122 formed of NAT-PT prefix and an IPv4 address; this refers to IPv4 1123 addresses, translated by NAT-PT DNS-ALG. In some cases, one might 1124 be tempted to handle these differently. 1126 However, IPv6 applications must not be required to distinguish 1127 "normal" and "NAT-PT translated" addresses (or any other kind of 1128 special addresses, including the IPv4-mapped IPv6-addresses): that 1129 would be completely unscalable, and if such distinction must be 1130 made, it must be done elsewhere (e.g. kernel, system libraries). 1132 8. Security considerations 1134 A number of transition mechananisms define ways of constructing 1135 IPv6 adddresses using IPv4 addresses. There are a number of kinds 1136 of IPv4 addresses that require careful treatment due to know 1137 security issues [TRANSEC]. 1139 One particular point about application transition is how IPv4- 1140 mapped IPv6-addresses are handled. The use in the API can be seen 1141 as both a merit (easier application transition) and as a burden 1142 (difficulty in ensuring whether the use was legimate) [V6MAPPED]. 1143 This may have to be considered in more detail. 1145 9. Acknowledgements 1147 We would like to thank the members of the the v6ops working group 1148 and the application area for helpful comments. Special thanks are 1149 due to Brian E. Carpenter, Antonio Querubin, Stig Venaas, and 1150 Chirayu Patel for extensive review of this document. We acknowledge 1151 Ron Pike for proofreading the document. 1153 10. References 1155 Normative References 1157 [RFC 3493] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic 1158 Socket Interface Extensions for IPv6," RFC 3493, February 1159 2003. 1161 [RFC 3542] W. Stevens, M. Thomas, E. Nordmark, T. Jinmei, "Advanced 1162 Sockets Application Program Interface (API) for IPv6," 1163 RFC 3542, May 2003. 1165 [BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts 1166 using the "Bump-In-the-Stack" Technique (BIS)," RFC 2767, 1167 February 2000. 1169 [BIA] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand, 1170 "Dual Stack Hosts using "Bump-in-the-API" (BIA)," RFC 1171 3338, October 2002. 1173 [2893BIS] E. Nordmark, "Transition Mechanisms for IPv6 Hosts and 1174 Routers," , February 2003, 1175 Work-in-progress. 1177 [RFC 2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 1178 (IPv6) Specification,", RFC 2460, December 1998. 1180 [RFC 3484] R. Draves, "Default Address Selection for IPv6," 1181 RFC 3484, February 2003. 1183 Informative References 1185 [RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal 1186 IPv6 Addresses in URL's," RFC 2732, December 1999. 1188 [RFC 2821] J. Klensin, "Simple Mail Transfer Protocol," RFC 2821, 1189 April 2001. 1191 [TextRep] A. Main, "Textual Representation of IPv4 and IPv6 1192 Addresses," , Oct 2003, 1193 Work in Progress. 1195 [NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation 1196 - Protocol Translation (NAT-PT)," RFC 2766, February 2000. 1198 [DNSTRANS] A. Durand, J. Ihren, "DNS IPv6 transport operational 1199 guidelines," , June 2003, Work in Progress. 1202 [DNSOPV6] A. Durand, J. Ihren, P. Savola, "Operational Considerations 1203 and Issues with IPv6 DNS," , November 2003, Work in Progress. 1206 [AF-APP] Jun-ichiro itojun Hagino, "Implementing AF-independent 1207 application", http://www.kame.net/newsletter/19980604/, 1208 2001. 1210 [V6MAPPED] Jun-ichiro itojun Hagino, "IPv4 mapped address 1211 considered harmful", , Apr 2002, Work in Progress. 1214 [IP-GGF] T. Chown, J. Bound, S. Jiang, P. O'Hanlon, "Guidelines for 1215 IP version independence in GGF specifications," Global 1216 Grid Forum(GGF) Documentation, September 2003, Work in 1217 Progress. 1219 [Embed-RP] P. Savola, B. Haberman, "Embedding the Address of RP in 1220 IPv6 Multicast Address," , October 2003, Work in Progress. 1223 [RFC 3306] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 1224 Multicast Addresses," RFC 3306, August 2002. 1226 [RFC 3678] D. Thaler, B. Fenner, B. Quinn, "Socket Interface 1227 Extensions for Multicast Source Filters, RFC 3678, January 1228 2004. 1230 [MUL-GW] S. Venaas, "An IPv4 - IPv6 multicast gateway," , February 2003, 1232 Work in Progress. 1234 [TRANSEC] R. Austein, "IPv6 transition security - problem 1235 statement from a workshop that never happened," 1236 a message on v6ops@ops.ietf.org list on 13 Aug 2003. 1238 Authors' addresses 1239 Myung-Ki Shin 1240 ETRI PEC 1241 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 1242 Tel : +82 42 860 4847 1243 Fax : +82 42 861 5404 1244 E-mail : mkshin@pec.etri.re.kr 1245 Yong-Guen Hong 1246 ETRI PEC 1247 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 1248 Tel : +82 42 860 6447 1249 Fax : +82 42 861 5404 1250 E-mail : yghong@pec.etri.re.kr 1252 Jun-ichiro itojun HAGINO 1253 Research Laboratory, Internet Initiative Japan Inc. 1254 Takebashi Yasuda Bldg., 1255 3-13 Kanda Nishiki-cho, 1256 Chiyoda-ku,Tokyo 101-0054, JAPAN 1257 Tel: +81-3-5259-6350 1258 Fax: +81-3-5259-6351 1259 E-mail: itojun@iijlab.net 1261 Pekka Savola 1262 CSC/FUNET 1263 Espoo, Finland 1264 E-mail: psavola@funet.fi 1266 Eva M. Castro 1267 Rey Juan Carlos University (URJC) 1268 Departamento de Informatica, Estadistica y Telematica 1269 C/Tulipan s/n 1270 28933 Madrid - SPAIN 1271 E-mail: eva@gsyc.escet.urjc.es 1273 Appendix A. Binary/presentation format conversions 1275 The following functions convert network address structure in its 1276 presentation address format and vice versa: 1278 inet_ntop() 1279 inet_pton() 1281 Both are from the basic socket extensions for IPv6. Since these 1282 functions are not protocol independent, we should write code for 1283 the different address families. 1285 A more detailed examples are follows. 1287 A.1 Network address to presentation format 1289 Conversions from network address structure to presentation format 1290 can be written: 1292 struct sockaddr_storage ss; 1293 char addrStr[INET6_ADDRSTRLEN]; 1295 /* fill ss structure */ 1297 switch (ss.ss_family) { 1299 case AF_INET: 1300 inet_ntop(ss.ss_family, 1301 &((struct sockaddr_in *)&ss)->sin_addr, 1302 addrStr, 1303 sizeof(addrStr)); 1304 break; 1306 case AF_INET6: 1307 inet_ntop(ss.ss_family, 1308 &((struct sockaddr_in6 *)&ss)->sin6_addr, 1309 addrStr, 1310 sizeof(addrStr)); 1312 break; 1314 default: 1315 /* handle unknown family */ 1316 } 1318 Note, the destination buffer addrStr should be long enough to 1319 contain the presentation address format: INET_ADDRSTRLEN for IPv4 1320 and INET6_ADDRSTRLEN for IPv6. Since INET6_ADDRSTRLEN is longer 1321 than INET_ADDRSTRLEN, the first one is used as the destination 1322 buffer length. 1324 However, this conversion is protocol dependent. We can write the 1325 same conversion using getnameinfo() in a protocol independent way. 1327 struct sockaddr_storage ss; 1328 char addrStr[INET6_ADDRSTRLEN]; 1329 char servStr[NI_MAXSERV]; 1330 int error; 1332 /* fill ss structure */ 1334 error = getnameinfo((struct sockaddr *)&ss, sizeof(ss), 1335 addrStr, sizeof(addrStr), 1336 servStr, sizeof(servStr), 1337 NI_NUMERICHOST); 1339 A.2 presentation format to network address 1341 Conversions from presentation format to network address structure 1342 can be written as follows: 1344 struct sockaddr_storage ss; 1345 struct sockaddr_in *sin; 1346 struct sockaddr_in6 *sin6; 1347 char addrStr[INET6_ADDRSTRLEN]; 1349 /* fill addrStr buffer and ss.ss_family */ 1351 switch (ss.ss_family) { 1352 case AF_INET: 1353 sin = (struct sockaddr_in *)&ss; 1354 inet_pton(ss.ss_family, 1355 addrStr, 1356 (sockaddr *)&sin->sin_addr)); 1357 break; 1359 case AF_INET6: 1360 sin6 = (struct sockaddr_in6 *)&ss; 1361 inet_pton(ss.ss_family, 1362 addrStr, 1363 (sockaddr *)&sin6->sin6_addr); 1364 break; 1366 default: 1367 /* handle unknown family */ 1368 } 1370 Note, the address family of the presentation format must be known. 1372 This conversion may be also written in a protocol independent way 1373 using getaddrinfo(). 1375 struct addrinfo hints, *res; 1376 char addrStr[INET6_ADDRSTRLEN]; 1377 int error; 1379 /* fill addrStr buffer */ 1381 memset(&hints, 0, sizeof(hints)); 1382 hints.ai_family = AF_UNSPEC; 1384 error = getaddrinfo(addrStr, NULL, &hints, &res); 1385 if (error != 0) { 1386 /* handle getaddrinfo error */ 1387 } 1389 /* res->ai_addr contains the network address structure */ 1390 /* ... */ 1391 freeaddrinfo(res); 1393 Intellectual Property Statement 1395 The IETF takes no position regarding the validity or scope of any 1396 intellectual property or other rights that might be claimed to 1397 pertain to the implementation or use of the technology described in 1398 this document or the extent to which any license under such rights 1399 might or might not be available; neither does it represent that it 1400 has made any effort to identify any such rights. Information on the 1401 IETF's procedures with respect to rights in standards-track and 1402 standards-related documentation can be found in BCP-11. Copies of 1403 claims of rights made available for publication and any assurances 1404 of licenses to be made available, or the result of an attempt made 1405 to obtain a general license or permission for the use of such 1406 proprietary rights by implementors or users of this specification 1407 can be obtained from the IETF Secretariat. 1409 The IETF invites any interested party to bring to its attention any 1410 copyrights, patents or patent applications, or other proprietary 1411 rights which may cover technology that may be required to practice 1412 this standard. Please address the information to the IETF Executive 1413 Director. 1415 Full Copyright Statement 1417 Copyright (C) The Internet Society (2003). All Rights Reserved. 1419 This document and translations of it may be copied and furnished to 1420 others, and derivative works that comment on or otherwise explain 1421 it or assist in its implementation may be prepared, copied, 1422 published and distributed, in whole or in part, without restriction 1423 of any kind, provided that the above copyright notice and this 1424 paragraph are included on all such copies and derivative works. 1425 However, this document itself may not be modified in any way, such 1426 as by removing the copyright notice or references to the Internet 1427 Society or other Internet organizations, except as needed for the 1428 purpose of developing Internet standards in which case the 1429 procedures for copyrights defined in the Internet Standards process 1430 must be followed, or as required to translate it into languages 1431 other than English. 1433 The limited permissions granted above are perpetual and will not be 1434 revoked by the Internet Society or its successors or assignees. 1436 This document and the information contained herein is provided on 1437 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1438 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1439 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1440 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1441 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1443 Acknowledgement 1445 Funding for the RFC Editor function is currently provided by the 1446 Internet Society.