idnits 2.17.1 draft-shin-v6ops-application-transition-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 26 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 (October 2003) is 7500 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 743, but not defined ** Obsolete undefined reference: RFC 2133 (Obsoleted by RFC 2553) == Missing Reference: 'MAXSOCK' is mentioned on line 907, but not defined == Unused Reference: 'RFC 3493' is defined on line 1059, but no explicit reference was found in the text == Unused Reference: 'RFC 3542' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'AF-APP' is defined on line 1097, 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 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Myung-Ki Shin (ed.) 3 Expires: April 2004 Yong-Guen Hong 4 ETRI 5 Jun-ichiro itojun Hagino 6 IIJ 7 Pekka Savola 8 CSC/FUNET 9 Eva M. Castro 10 GSYC/URJC 11 October 2003 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 what is the best strategy to develop IP 41 protocol support in applications. This document specifies 42 scenarios and aspects of application transition. It also proposes 43 guidelines on how to develop IP version-independent applications 44 during the transition period. 46 Table of Contents: 48 1. Introduction .............................................. 2 49 2. Overview of IPv6 application transition ................... 3 50 3. Problems with IPv6 application transition ................. 4 51 3.1 IPv6 support in the OS and applications are unrelated.... 4 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 ..5 54 4. Description of transition scenarios and guidelines ........ 6 55 4.1 IPv4 applications in a dual-stack node .................. 6 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 ............. 9 59 5. Application porting considerations ........................10 60 5.1 Presentation format for an IP address ...................10 61 5.2 Transport layer API .....................................11 62 5.3 Name and address resolution .............................12 63 5.4 Specific IP dependencies ............................... 12 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 6. Developing IP version-independent applications ............14 68 6.1 IP version-independent structures .......................14 69 6.2 IP version-independent APIs .............................15 70 6.2.1 Example of overly simplistic TCP server application ..16 71 6.2.2 Example of overly simplistic TCP client application ..17 72 6.2.3 Binary/Presentation format conversion ................17 73 6.3 Iterated jobs for finding the working address ...........18 74 6.3.1 Example of TCP server application ....................18 75 6.3.2 Example of TCP client application ....................20 76 7. Transition mechanism considerations .......................21 77 8. Security considerations ...................................21 78 9. References ................................................21 79 Authors' Addresses ...........................................23 80 Appendix A. Binary/Presentation Format Conversions ...........23 81 A.1 Network Address to Presentation Format ..................23 82 A.2 Presentation Format to Network Address ..................24 84 1. Introduction 86 As IPv6 is introduced in the IPv4-based Internet, several general 87 issues when starting to use IPv6 in a world dominated by IPv4 are 88 being discussed, such as routing, addressing, DNS, scenarios, etc. 90 One important key to a successful IPv6 transition is the 91 compatibility with the large installed base of IPv4 hosts and 92 routers. This issue had been already been extensively studied, and 93 the work is still in progress. In particular, [2893BIS] describes 94 the basic transition mechanisms, dual-stack deployment and 95 tunneling. In addition, various kinds of transition mechanisms 96 have been developed to migrate to IPv6 network. However, these 97 transition mechanisms take no stance on whether applications 98 support IPv6 or not. 100 This document specifies application aspects of IPv6 transition. 101 That is, two inter-related topics are covered: 103 1. How different network transition techniques affect 104 applications, and what are the strategies for applications 105 to support IPv6 and IPv4. 107 2. How to develop IPv6-capable or protocol-independent 108 applications ("application porting guidelines"). 110 Applications will need to be modified to support IPv6 (and IPv4), 111 using one of a number of techniques described in sections 2-4. 112 Some guidelines to develop such application are then presented in 113 sections 5 and 6. 115 2. Overview of IPv6 application transition 117 The transition of an application can be classifed using four 118 different cases (excluding the first step when there is no IPv6 119 support either in the application or the operating system), as 120 follows: 122 +-------------------+ 123 | appv4 | (appv4 - IPv4-only applications) 124 +-------------------+ 125 | TCP / UDP | (transport protocols) 126 +-------------------+ 127 | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) 128 +-------------------+ 130 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 | (transport protocols) 136 +-------------------+ 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 | (transport protocols) 147 +-------------------+ 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 | (transport protocols) 158 +-------------------+ 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 same applications for different 177 protocol versions (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 3. Problems with IPv6 application transition 193 There are several reasons why the transition period between IPv4 194 and IPv6 applications may not be straightforward. These issues are 195 described in this section. 197 3.1 IPv6 support in the OS and applications are unrelated 199 Considering the cases described in the previous section, IPv4 and 200 IPv6 protocol stacks in a node is likely to co-exist for a long 201 time. 203 Similarly, most applications are expected to be able to handle both 204 IPv4 and IPv6 during another, unrelated long time period. That is, 205 operating system being dual stack does not mean having both IPv4 206 and IPv6 applications. Therefore, application introduction may be 207 independent of protocol stacks in a node. 209 It is even probable that applications capable of both IPv4 and IPv6 210 will have to work properly in IPv4-only nodes (whether IPv6 211 protocol is completely disabled or there is no IPv6 connectivity at 212 all). 214 3.2 DNS does not indicate which the IP version will be used 216 The role of the DNS name resolver in a node is to get the list of 217 destination addresses. DNS queries and responses are sent using 218 either IPv4 or IPv6 to carry the queries, regardless of the 219 protocol version of the data records [DNS]. 221 The issue of DNS name resolving related to application transition 222 is that a client application can not be certain of the version of 223 peer application by only doing a DNS name lookup. For example, if a 224 server application does not support IPv6 yet, but runs on a dual- 225 stack machine for other IPv6 services and this is listed with an 226 AAAA record in the DNS, the client application will fail to connect 227 to the server application, because there is a mis-match between the 228 DNS query result (i.e. IPv6 addresses) and a server application 229 version (i.e. IPv4). 231 It is bad practise to add an AAAA record for node that does not 232 support all the services using IPv6 (rather, an AAAA record for the 233 specific service name and address should be used), but the 234 application cannot depend on "good practise", and this must be 235 handled. 237 In consequence, the application has to try all the records returned 238 from the DNS, in some order, until a working address is found. In 239 particular, the application has to be able to handle all IP 240 versions returned from the DNS. 242 3.3 Supporting many versions of an application is difficult 244 During the application transition period, system administrators may 245 have various versions of the same application (an IPv4-only 246 application, an IPv6-only application, or an application supporting 247 both IPv4 and IPv6). 249 Typically one cannot know which IP versions must be supported prior 250 to doing a DNS lookup *and* trying (see section 3.2) the addresses 251 returned. Therefore, the users have a difficulty selecting the 252 right application version supporting the exact IP version required 253 if multiple versions of the same application are available. 255 To avoid problems with one application not supporting the specified 256 protocol version, it is desirable to have hybrid applications, 257 supporting both the protocol versions. 259 Alternative approach is to have a "wrapper application" which 260 performs certain tasks (like figures out which protocol version 261 will be used) and calls the IPv4/IPv6-only applications as 262 necessary. However, as noted above, these wrapper applications 263 will actually probably have to do more than just perform a DNS 264 lookup or figure out the literal IP address given. Thus, they may 265 get complex, and only work for certain kinds of, usually simple, 266 applications. 268 Nonetheless, there should be some reasonable logic on how to the 269 users are able to just use the applications with any supported 270 protocol version; the users should not have to select from various 271 versions of applications, some supporting only IPv4, others only 272 IPv6, and yet some both versions by themselves. 274 4. Description of transition scenarios and guidelines 276 Once the IPv6 network is deployed, applications supporting IPv6 can 277 use IPv6 network services and establish IPv6 connections. However, 278 upgrading every node to IPv6 at the same time is not feasible and 279 transition from IPv4 to IPv6 will be a gradual process. 281 Dual-stack nodes are one of the ways to maintain IPv4 compatibility 282 in unicast communications. In this section we will analyze 283 different application transition scenarios (as introduced in 284 section 2) and guidelines to maintain interoperability between 285 applications running in different types of nodes. 287 4.1 IPv4 applications in a dual-stack node 289 This scenario happens if IPv6 protocol is added in a node but 290 IPv6-capable applications aren't yet available or installed. 291 Although the node implements the dual stack, IPv4 applications can 292 only manage IPv4 communications. Then, IPv4 applications can only 293 accept/establish connections from/to nodes which implement IPv4 294 stack. 296 In order to allow an application to communicate with other nodes 297 using IPv6, the first priority is to port applications to IPv6. 299 In some cases (e.g. no source code is available), existing IPv4 300 applications can work if the [BIS] or [BIA] mechanism is installed 301 in the node. However, these mechanisms should not be used when 302 application source code is available to prevent the mis-use of 303 them, for example, as an excuse not to port software. 305 When [BIA] or [BIS] is used, the same previous problem --the IPv4 306 client in a [BIS]/[BIA] node trying to connect to an IPv4 server in 307 a dual stack system-- arises. However, one can rely on [BIA]/[BIS] 308 mechanism, which should cycle through all the addresses instead of 309 applications. 311 4.2 IPv6 applications in a dual-stack node 313 As we have seen in the previous section, applications should be 314 ported to IPv6. The easiest way to port an IPv4 application is to 315 substitute the old IPv4 API references by the new IPv6, one-to-one 316 API mapping. That way, the application would be IPv6-only. This 317 IPv6-only source code can not work in IPv4- only nodes, so the old 318 IPv4 application should be maintained in these nodes. Then, we will 319 get two same applications working with different protocol versions, 320 depending on the node they are running (e.g., telnet and telnet6). 321 This case is undesirable since maintaining two versions of the same 322 source code per application, could be a difficult task. In 323 addition, this approach would cause problems for the users when 324 having to select which version of the application to use, as 325 described in section 3.3. 327 Most implementations of dual stack allow IPv6-only applications 328 interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to 329 IPv6 applications on a dual-stack node, reach their destination 330 because their addresses are mapped to IPv6 ones using IPv4-mapped 331 IPv6 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4 332 address x.y.z.w. 334 +----------------------------------------------+ 335 | +------------------------------------------+ | 336 | | | | 337 | | IPv6-only applications | | 338 | | | | 339 | +------------------------------------------+ | 340 | | | 341 | +------------------------------------------+ | 342 | | | | 343 | | TCP/UDP | | 344 | | | | 345 | +------------------------------------------+ | 346 | IPv4-mapped | | IPv6 | 347 | IPv6 addresses | | addresses | 348 | +--------------------+ +-------------------+ | 349 | | IPv4 | | IPv6 | | 350 | +--------------------+ +-------------------+ | 351 | IPv4 | | | 352 | adresses | | | 353 +--------------|-----------------|-------------+ 354 | | 355 IPv4 packets IPv6 packets 357 When an IPv4 client application sends data to an IPv6-only server 358 application, running on a dual-stack node using the wildcard (but 359 without the IPV6_V6ONLY socket option) address, the IPv4 client 360 address is interpreted as the IPv4-mapped IPv6 address in the 361 dual-stack node to allow IPv6 application to manage this 362 communication. The IPv6 server will use this mapped address as if 363 it were a regular IPv6 address, and a usual IPv6 connection. 364 However, IPv4 packets will be exchanged between the nodes. Kernels 365 with dual stack properly interpret IPv4-mapped IPv6 addresses as 366 IPv4 ones and vice versa. 368 IPv6-only client application in a dual-stack node will not get 369 IPv4-mapped addresses from the hostname resolution API functions 370 unless a special hint, AI_V4MAPPED, is given. If given, the IPv6 371 client will use the returned mapped address as if it were a regular 372 IPv6 address, and a usual IPv6 connection. However, again IPv4 373 packets will be exchanged between applications. 375 The default behavior of IPv6 applications in these dual-stack nodes 376 allows a limited amount of IPv4 communication using the IPv4-mapped 377 IPv6 addresses. However, it is possible for IPv6 applications to 378 allow connections only with IPv6 nodes (e.g. IPv6_V6ONLY socket 379 option), so the interoperability with IPv4 nodes is broken. This 380 option could be useful if applications use new IPv6 features, such 381 as flowlabel. 383 There are some implementations of dual-stack which do not allow 384 IPv4-mapped IPv6 addresses to be used for interoperability between 385 IPv4 and IPv6 applications. In that case, there are two ways to 386 handle the problem: 388 1. deploy two different versions of applications (possibly 389 attached with '6' in the name), or 391 2. deploy just one application supporting both protocol versions, 392 as described in the next section. 394 The first method is not recommended, because of significant amount 395 of problems of problems associated with selecting the right 396 applications, as described in sections 3.2 and 3.3. 398 Therefore, there are actually two distinct cases to consider: 400 1. whether the systems where the applications are used support 401 IPv6 at all or not, and 403 2. whether the application can (or should) support both IPv4 404 and IPv6 through IPv4-mapped IPv6 addresses, or should the 405 applications support both explicitly, as described in the 406 next section. 408 4.3 IPv4/IPv6 applications in a dual stack node 410 Applications should be ported to support both IPv4 and IPv6; such 411 applications are sometimes called IP version-independent 412 applications. After that, the existing IPv4-only applications 413 could be removed. Since we have only one version of each 414 application, the source code will be typically easy to maintain and 415 to modify, and there are no problems managing which application to 416 select for which purpose. 418 This transition case is the most advisable. During IPv6 transition 419 period, applications supporting both IPv4 and IPv6 should be able 420 to communicate with other applications, irrespective of the 421 versions of the protocol stack or the application in the node. Dual 422 applications allow more interoperability between heterogeneous 423 applications and nodes. 425 If the source code is written in a protocol-independent way, 426 without dependencies on either IPv4 or IPv6, applications will be 427 able to communicate with any combination of applications and types 428 of nodes. 430 Implementations typically by-default prefer IPv6 if the remote node 431 and application support it. However, if IPv6 connections fail, 432 dual applications will automatically try IPv4 ones. The resolver 433 returns a list of valid addresses for the remote node and 434 applications can iterate through all, first trying IPv6 ones, until 435 connection succeeds. 437 Applications writers should be aware of this typical by-default 438 ordering, but the applications themselves typically need not be 439 aware of the the local protocol ordering [RFC 3484]. 441 A more detailed porting guideline is described in section 6. 443 4.4. IPv4/IPv6 applications in an IPv4-only node 445 As the transition is likely to happen over a longer timeframe, 446 applications that have already been ported to support both IPv4 and 447 IPv6 may be run on IPv4-only nodes. This would typically be done to 448 avoid having to support two application versions for older and 449 newer operating systems, or to support the case that the user wants 450 to disable IPv6 for some reason. 452 Depending on how application/operating system support is done, some 453 may want to ignore this case, but usually no assumptions can be 454 made and applications should also work in this scenario. 456 An example is an application that issues a socket() command, first 457 trying AF_INET6 and then AF_INET. However, if the kernel does not 458 have IPv6 support, the call will result in an EPROTONOSUPPORT or 459 EAFNOSUPPORT error. Typically, encountering errors like these leads 460 to exiting the socket loop, and AF_INET will not even be tried. 461 The application will need to handle this case or build the loop in 462 such a way that errors are ignored until the last address family. 464 So, this case is just an extension of the IPv4/IPv6 support in the 465 previous case, covering one relatively common but often ignored 466 case. 468 5. Application porting considerations 470 The minimum changes in IPv4 applications to work using IPv6 are 471 basically based on the different size and format of IPv4 and IPv6 472 addresses. 474 Applications have been developed with the assumption they would use 475 IPv4 as network protocol. This assumption results in many IP 476 dependencies through source code. 478 The following list summarizes the more common IP version 479 dependencies in applications: 481 a) Presentation format for an IP address: it is an ASCII string 482 which represents the IP address, dotted-decimal string 483 for IPv4 and hexadecimal string for IPv6. 485 b) Transport layer API: functions to establish communications 486 and to exchange information. 488 c) Name and address resolution: conversion functions between 489 hostnames and IP addresses, and vice versa. 491 d) Specific IP dependencies: more specific IP version 492 dependencies, such as: IP address selection, 493 application framing, storage of IP addresses. 495 Next, the problems with the aforementioned IP version dependencies 496 are analyzed. Although application source code can be ported to 497 IPv6 with minimum changes related to IP addresses, some 498 recommendations are given to modify the source code in a protocol 499 independent way, which will allow applications to work using both 500 IPv4 and IPv6. 502 5.1 Presentation format for an IP address 504 Many applications use IP addresses to identify network nodes and to 505 establish connections to destination addresses. For instance, using 506 the client/server model, clients usually need an IP address as an 507 application parameter to connect to a server. This IP address is 508 usually provided in the presentation format, as a string. There 509 are two problems, when porting the presentation format for an IP 510 address: the allocated memory and the management of the 511 presentation format. 513 Usually, the allocated memory to contain an IPv4 address 514 representation as string is not enough to contain an IPv6 one. 515 Applications should be modified to prevent from overflowing the 516 buffer holding the presentation format for an IP address, now 517 larger in IPv6. 519 IPv4 and IPv6 do not use the same presentation format. IPv4 uses 520 dot (.) to separate the four octets written in decimal notation and 521 IPv6 uses colon (:) to separate each pair of octets written in 522 hexadecimal notation. In order to support both, IPv4 and IPv6, the 523 management functions of presentation format, such as IP address 524 parsers, should be changed to be compliant with both the formats. 526 A particular problem with IP address parsers comes when the input 527 is actually a combination of IP address and port. With IPv4, these 528 are often coupled with a semi-colon, like "192.0.2.1:80". However, 529 such an approach would be ambiguous with IPv6, as semi-colons are 530 already used to structure the address. 532 Therefore, the IP address parsers which take the port number 533 separated with a semi-colon should represent IPv6 addresses 534 somehow. One way is to enclose the address in brackets, as is done 535 with Uniform Resource Locators (URLs) [RFC 2732], like 536 http://[2001:db8::1]:80. 538 In some specific cases, it may be necessary to give a zone 539 identifier as part of the address, like fe80::1%eth0. In general, 540 applications should not need to parse these identifiers. 542 The IP address parsers should support enclosing the IPv6 address in 543 brackets even when it's not used in conjunction with a port number, 544 but requiring that the user always gives a literal IP address 545 enclosed in brackets is not recommended. 547 Note that the use of address literals is strongly discouraged for 548 general purpose direct input to the applications; host names and 549 DNS should be used instead. 551 5.2 Transport layer API 553 Communication applications often include a transport module that 554 establishes communications. Usually, this module manages everything 555 related to communications and uses a transport layer API, typically 556 as a network library. When porting an application to IPv6 most 557 changes should be made in this application transport module, in 558 order to be adapted to the new IPv6 API. 560 In the general case, porting an existing application to IPv6 561 requires to examine the following issues related to the API: 563 - Network information storage: IP address data structures. 564 The new structures must contain 128-bit IP addresses. The use of 565 generic address structures, which can store any address family, 566 is recommended. 567 Sometimes special addresses are hard-coded in the application 568 source; developers should pay attention to them in order to use 569 the new address format. Some of these special IP addresses are: 570 wildcard local, loopback and broadcast. IPv6 does not have 571 the broadcast addresses, so applications can use multicast 572 instead. 574 - Address conversion functions. 575 The address conversion functions convert the binary address 576 representation to the presentation format and vice versa. The 577 new conversion functions are specified to the IPv6 address 578 format. 580 - Communication API functions. 581 These functions manage communications. Their signatures are 582 defined based on generic socket address structure. Then, the 583 same functions are valid for IPv6. However, the IP address data 584 structures used when calling these functions require the 585 updates. 587 - Network configuration options. 588 They are used when configuring different communication models 589 for Input/Output (I/O) operations (blocking/nonblocking, I/O 590 multiplexing, etc) and should be translated to the IPv6 ones. 592 5.3 Name and address resolution 594 From the application point of view, the name and address resolution 595 is a system-independent process. An application calls functions in 596 a system library, the resolver, which is linked into the 597 application when this is built. However, these functions use IP 598 address structures, which are protocol dependent, and must be 599 reviewed to support the new IPv6 resolution calls. 601 There are two basic resolution functions. The first function 602 returns a list of all configured IP addresses for a hostname. These 603 queries can be constrained to one protocol family, for instance 604 only IPv4 or only IPv6 addresses. However, the recommendation is 605 that all configured IP addresses should be got to allow 606 applications to work to every kind of node. And the second function 607 returns the hostname associated to an IP address. 609 5.4. Specific IP dependencies 610 Applications usually call functions in a system library, known as 611 the resolver, to realize the name and address resolution. Since 612 these functions use IP address structures, which are protocol 613 dependent, not only the functions but also the structures must be 614 reviewed to support IPv6. 616 There are new resolution functions that provide protocol 617 independence for applications, since knowing the address family is 618 not required to carry out the resolution. 620 Resolution queries should not be constrained to one address family, 621 IPv4 or IPv6 addresses. For intance, when getting IP addresses for 622 a hostname, applications should ask for all configured IP addresses 623 to allow applications to communicate to every kind of node. 625 5.4.1 IP address selection 627 IPv6 promotes the configuration from multiple IP addresses per 628 node, which is a different model of IPv4; however applications only 629 use a destination/source pair for a communication. Choosing the 630 right IP source and destination addresses is a key factor that may 631 determine the route of IP datagrams. 633 Typically nodes, not applications, automatically solve the source 634 address selection. A node will choose the source address for a 635 communication following some rules of best choice, [RFC 3484], but 636 also allowing applications to make changes in the ordering rules. 638 When selecting the destination address, applications usually ask a 639 resolver for the destination IP address. The resolver returns a set 640 of valid IP addresses from a hostname. Unless applications have a 641 specific reason to select any particular destination address, they 642 should just try each element in the list until the communication 643 succeeds. 645 5.4.2 Application framing 647 The Application Level Framing (ALF) architecture controls 648 mechanisms that traditionally fall within the transport layer. 649 Applications implementing ALF are often responsible for packetizing 650 data into Application Data Units (ADUs). The application problem 651 when using ALF is the ADU size selection to obtain better 652 performance. 654 Application framing is typically needed by applications using 655 connectionless protocols (such as UDP). The application will have 656 to know, or be able to detect, what are the packet sizes which can 657 be sent and received, end-to-end, on the network. 659 Applications can use 1280 octets as data length. [RFC 2460] 660 specifies IPv6 requires that every link in the Internet have an 661 Maximum Transmission Unit (MTU) of 1280 octets or greater. However, 662 in order to get better performance ADU size should be calculated 663 based on the length of transmission unit of underlying protocols. 665 FIXME: Application framing has relations e.g. with Path MTU 666 Discovery and application design which need to be analyzed better. 668 5.4.3 Storage of IP addresses 670 Some applications store IP addresses as information of remote 671 peers. For instance, one of the most popular ways to register 672 remote nodes in collaborative applications is based on using IP 673 addresses as registry keys. 675 Although the source code that stores IP addresses can be modified 676 to IPv6 following the previous basic porting recommendations, there 677 are some reasons why applications should not store IP addresses: 679 - IP addresses can change throughout the time, for instance 680 after a renumbering process. 682 - The same node can reach a destination host using different 683 IP addresses. 685 Instead of using IP addresses, applications should use FQDNs. 686 Hence, applications delegate the resolution of the IP addresses to 687 the name resolution system, which will return the associated IP 688 address at the moment of the query. 690 6. Developing IP version-independent applications 692 As we have seen before, dual applications working with both IPv4 693 and IPv6 are recommended. These applications should avoid IP 694 dependencies in the source code. However if IP dependencies are 695 required, one of the best solutions is based on building a 696 communication library which provides an IP version independent API 697 to applications and hides all dependencies. 699 In order to develop IP version independent applications, the 700 following guidelines should be considered. 702 6.1 IP version-independent structures 704 All of the memory structures and APIs should be IP version- 705 independent. In that sense, one should avoid structs in_addr, 706 in6_addr, sockaddr_in and sockaddr_in6. 708 Suppose you pass a network address to some function, foo(). If you 709 use struct in_addr or struct in6_addr, you will end up with extra 710 parameter to indicate address family, as below: 712 struct in_addr in4addr; 713 struct in6_addr in6addr; 714 /* IPv4 case */ 715 foo(&in4addr, AF_INET); 716 /* IPv6 case */ 717 foo(&in6addr, AF_INET6); 719 However, this leads to duplicated code and having to consider each 720 scenario from both perspectives independently; this is difficult to 721 maintain. So, we should use struct sockaddr_storage like below. 723 struct sockaddr_storage ss; 724 int sslen; 725 /* AF independent! - use sockaddr when passing a pointer */ 726 /* note: it's typically necessary to also pass the length 727 explicitly */ 728 foo((struct sockaddr *)&ss, sslen); 730 6.2 IP version-independent APIs 732 getaddrinfo() and getnameinfo() are new address independent 733 variants that hide the gory details of name-to-address and 734 address-to-name translations. They implement functionalities of 735 the following functions: 737 gethostbyname() 738 gethostbyaddr() 739 getservbyname() 740 getservbyport() 742 They also obsolete the functionality of gethostbyname2(), defined 743 in [RFC2133]. 745 These can perform hostname/address and service name/port lookups, 746 though the features can be turned off if desirable. getaddrinfo() 747 can return multiple addresses, as below: 749 localhost. IN A 127.0.0.1 750 IN A 127.0.0.2 751 IN AAAA ::1 753 In this example, if IPv6 is preferred, getaddrinfo returns first 754 ::1, and then both 127.0.0.1 and 127.0.0.2 is in a random order. 756 Getaddrinfo() and getnameinfo() can query hostname as well as 757 service name/port at once. 759 As well, it is not preferred to hardcode AF-dependent knowledge 760 into the program. The construct like below should be avoided: 762 /* BAD EXAMPLE */ 763 switch (sa->sa_family) { 764 case AF_INET: 765 salen = sizeof(struct sockaddr_in); 766 break; 767 } 769 Instead, we should use the ai_addrlen member of the addrinfo 770 structure, as returned by getaddrinfo(). 772 The gethostbyname(), gethostbyaddr(), getservbyname(), and 773 getservbyport() are mainly used to get server and client sockets. 774 Following, we will see simple examples to create these sockets 775 using the new IPv6 resolution functions. 777 6.2.1 Example of overly simplistic TCP server application 779 A simple TCP server socket at service name (or port number string) 780 SERVICE: 782 /* 783 * BAD EXAMPLE: does not implement the getaddrinfo loop as 784 * specified in 6.3. This may result in one of the following: 785 * - an IPv6 server, listening at the wildcard address, 786 * allowing IPv4 addresses through IPv4-mapped IPv6 addresses. 787 * - an IPv4 server, if IPv6 is not enabled, 788 * - an IPv6-only server, if IPv6 is enabled but IPv4-mapped IPv6 789 * addresses are not used by default, or 790 * - no server at all, if getaddrinfo supports IPv6, but the 791 * system doesn't, and socket(AF_INET6, ...) exists with an 792 * error. 793 */ 794 struct addrinfo hints, *res; 795 int error, sockfd; 797 memset(&hints, 0, sizeof(hints)); 798 hints.ai_flags = AI_PASSIVE; 799 hints.ai_family = AF_UNSPEC; 800 hints.ai_socktype = SOCK_STREAM; 802 error = getaddrinfo(NULL, SERVICE, &hints, &res); 803 if (error != 0) { 804 /* handle getaddrinfo error */ 805 } 807 sockfd = socket(res->family, res->ai_socktype, res->ai_protocol); 808 if (sockfd < 0) { 809 /* handle socket error */ 810 } 811 if (bind(sockfd, res->ai_addr, res->ai_addrlen) < 0) { 812 /* handle bind error */ 813 } 815 /* ... */ 817 freeaddrinfo(res); 819 6.2.2 Example of overly simplistic TCP client application 821 A simple TCP client socket connecting to a server which is running 822 at node name (or IP address presentation format) SERVER_NODE and 823 service name (or port number string) SERVICE: 825 /* 826 * BAD EXAMPLE: does not implement the getaddrinfo loop as 827 * specified in 6.3. This may result in one of the following: 828 * - an IPv4 connection to the IPv4 destination, 829 * - an IPv6 connection to an IPv6 destination, 830 * - an attempt to try to reach an IPv6 destination (if AAAA 831 * record found), but failing -- without fallbacks -- because: 832 * o getaddrinfo supports IPv6 but the system does not 833 * o IPv6 routing doesn't exist, so falling back to e.g. TCP 834 * timeouts 835 * o IPv6 server reached, but service not IPv6-enabled or 836 * firewalled away 837 * - if the first destination is not reached, there is no 838 * fallback to the next records 839 */ 840 struct addrinfo hints, *res; 841 int error, sockfd; 843 memset(&hints, 0, sizeof(hints)); 844 hints.ai_family = AF_UNSPEC; 845 hints.ai_socktype = SOCK_STREAM; 847 error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res); 848 if (error != 0) { 849 /* handle getaddrinfo error */ 850 } 852 sockfd = socket(res->family, res->ai_socktype, res->ai_protocol); 853 if (sockfd < 0) { 854 /* handle socket error */ 855 } 857 if (connect(sockfd, res->ai_addr, res->ai_addrlen) < 0 ) { 858 /* handle connect error */ 859 } 861 /* ... */ 862 freeaddrinfo(res); 864 6.2.3 Binary/Presentation format conversion 866 In addition, we should consider the binary and presentation address 867 format conversion APIs. The following functions convert network 868 address structure in its presentation address format and vice 869 versa: 871 inet_ntop() 872 inet_pton() 874 Both are from the basic socket extensions for IPv6. Since these 875 functions are not protocol independent, we should write code for 876 the different address families. 878 A more detailed examples are described in appendix A. 880 Note that inet_ntop()/inet_pton() lose the scope identifier (if 881 used e.g. with link-local addresses) in the conversions, contrary 882 to the getaddrinfo()/getnameinfo() functions. 884 6.3 Iterated jobs for finding the working address 886 In a client code, when multiple addresses are returned from 887 getaddrinfo(), we should try all of them until connection succeds. 888 When a failure occurs with socket(), connect(), bind(), or some 889 other function, go on to try the next address. 891 In addition, if something is wrong with the socket call because the 892 address family is not supported (i.e., in case of section 4.4), 893 applications should try the next address structure. 895 Note: in the following examples, the socket() return value error 896 handling could be simplied by substituting special checking of 897 specific error numbers by always continuing on with the socket 898 loop. Whether this is a better idea should be considered in more 899 detail. 901 6.3.1 Example of TCP server application 903 The previous example TCP server example should be written: 905 #define MAXSOCK 2 906 struct addrinfo hints, *res; 907 int error, sockfd[MAXSOCK], nsock=0; 909 memset(&hints, 0, sizeof(hints)); 910 hints.ai_flags = AI_PASSIVE; 911 hints.ai_family = AF_UNSPEC; 912 hints.ai_socktype = SOCK_STREAM; 914 error = getaddrinfo(NULL, SERVICE, &hints, &res); 915 if (error != 0) { 916 /* handle getaddrinfo error */ 917 } 919 for (aip=res; aip && nsock < MAXSOCK; aip=aip->ai_next) { 920 sockfd[nsock] = socket(aip->ai_family, 921 aip->ai_socktype, 922 aip->ai_protocol); 924 if (sockfd[nsock] < 0) { 925 switch errno { 926 case EAFNOSUPPORT: 927 case EPROTONOSUPPORT: 928 /* 929 * e.g., skip the errors until 930 * the last address family, 931 * see section 4.4. 932 */ 933 if (aip->ai_next) 934 continue; 935 else { 936 /* handle unknown protocol errors */ 937 break; 938 } 939 default: 940 /* handle other socket errors */ 941 ; 942 } 944 } else { 945 int on = 1; 946 /* optional: works better if dual-binding to wildcard 947 address */ 948 if (aip->ai_family == AF_INET6) { 949 setsockopt(sockfd[nsock], IPPROTO_IPV6, IPV6_V6ONLY, 950 (char *)&on, sizeof(on)); 951 /* errors are ignored */ 952 } 953 if (bind(sockfd[nsock], aip->ai_addr, 954 aip->ai_addrlen) < 0 ) { 955 /* handle bind error */ 956 close(sockfd[nsock]); 957 continue; 958 } 959 if (listen(sockfd[nsock], SOMAXCONN) < 0) { 960 /* handle listen errors */ 961 close(sockfd[nsock]); 962 continue; 963 } 964 } 965 nsock++; 966 } 967 freeaddrinfo(res); 969 /* check that we were able to obtain the sockets */ 971 6.3.2 Example of TCP client application 973 The previous TCP client example should be written: 975 struct addrinfo hints, *res, *aip; 976 int sockfd, error, afNotSupp; 978 memset(&hints, 0, sizeof(hints)); 979 hints.ai_family = AF_UNSPEC; 980 hints.ai_socktype = SOCK_STREAM; 982 error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res); 983 if (error != 0) { 984 /* handle getaddrinfo error */ 985 } 987 for (aip=res; aip; aip=aip->ai_next) { 989 sockfd = socket(aip->ai_family, 990 aip->ai_socktype, 991 aip->ai_protocol); 993 if (sockfd < 0) { 994 switch errno { 995 case EAFNOSUPPORT: 996 case EPROTONOSUPPORT: 997 /* 998 * e.g., skip the errors until 999 * the last address family, 1000 * see section 4.4. 1001 */ 1002 if (aip->ai_next) 1003 continue; 1004 else { 1005 /* handle unknown protocol errors */ 1006 break; 1007 } 1009 default: 1010 /* handle other socket errors */ 1011 ; 1012 } 1014 } else { 1015 if (connect(sockfd, aip->ai_addr, aip->ai_addrlen) == 0) 1016 break; 1018 /* handle connect errors */ 1019 close(sockfd); 1020 sockfd=-1; 1021 } 1022 } 1024 if (sockfd > 0) { 1025 /* socket connected to server address */ 1027 /* ... */ 1028 } 1030 freeaddrinfo(res); 1032 7. Transition mechanism considerations 1034 A mechanism, [NAT-PT], introduces a special set of addresses, 1035 formed of NAT-PT prefix and an IPv4 address; this refers to IPv4 1036 addresses, translated by NAT-PT DNS-ALG. In some cases, one might 1037 be tempted to handle these differently. 1039 However, IPv6 applications must not be required to distinguish 1040 "normal" and "NAT-PT translated" addresses (or any other kind of 1041 special addresses, including the IPv6-mapped IPv4-addresses): that 1042 would be completely unscalable, and if such distinction must be 1043 made, it must be done elsewhere (e.g. kernel, system libraries). 1045 8. Security considerations 1047 TBD. 1049 One particular point about application transition is how IPv4- 1050 mapped IPv6-addresses are handled. The use in the API can be seen 1051 as both a merit (easier application transition) and as a burden 1052 (difficulty in ensuring whether the use was legimate) [V6MAPPED]. 1053 This may have to be considered in more detail. 1055 9. References 1057 Normative References 1059 [RFC 3493] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic 1060 Socket Interface Extensions for IPv6," RFC 3493, February 1061 2003. 1063 [RFC 3542] W. Stevens, M. Thomas, E. Nordmark, T. Jinmei, "Advanced 1064 Sockets Application Program Interface (API) for IPv6," 1065 RFC 3542, May 2003. 1067 [BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts 1068 using the "Bump-In-the-Stack" Technique (BIS)," RFC 2767, 1069 February 2000. 1071 [BIA] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand, 1072 "Dual Stack Hosts using "Bump-in-the-API" (BIA)," RFC 1073 3338, October 2002. 1075 [2893BIS] E. Nordmark, "Transition Mechanisms for IPv6 Hosts and 1076 Routers," , February 2003, 1077 Work-in-progress. 1079 [RFC 2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 1080 (IPv6) Specification,", RFC 2460, December 1998. 1082 [RFC 3484] R. Draves, "Default Address Selection for IPv6," 1083 RFC 3484, February 2003. 1085 Informative References 1087 [RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal 1088 IPv6 Addresses in URL's," RFC 2732, December 1999. 1090 [NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation 1091 - Protocol Translation (NAT-PT)," RFC 2766, February 2000. 1093 [DNS] A. Durand, J. Ihren, "DNS IPv6 transport operational 1094 guidelines," , June 2003, Work in Progress. 1097 [AF-APP] Jun-ichiro itojun Hagino, "Implementing AF-independent 1098 application", http://www.kame.net/newsletter/19980604/, 1099 2001. 1101 [V6MAPPED] Jun-ichiro itojun Hagino, "IPv4 mapped address 1102 considered harmful", , work-in-progress, Apr 2002. 1105 Authors' Addresses 1106 Myung-Ki Shin 1107 ETRI PEC 1108 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea 1109 Tel : +82 42 860 4847 1110 Fax : +82 42 861 5404 1111 E-mail : mkshin@pec.etri.re.kr 1112 Yong-Guen Hong 1113 ETRI PEC 1114 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea 1115 Tel : +82 42 860 6447 1116 Fax : +82 42 861 5404 1117 E-mail : yghong@pec.etri.re.kr 1119 Jun-ichiro itojun HAGINO 1120 Research Laboratory, Internet Initiative Japan Inc. 1121 Takebashi Yasuda Bldg., 1122 3-13 Kanda Nishiki-cho, 1123 Chiyoda-ku,Tokyo 101-0054, JAPAN 1124 Tel: +81-3-5259-6350 1125 Fax: +81-3-5259-6351 1126 E-mail: itojun@iijlab.net 1128 Pekka Savola 1129 CSC/FUNET 1130 Espoo, Finland 1131 E-mail: psavola@funet.fi 1133 Eva M. Castro 1134 Rey Juan Carlos University (URJC) 1135 E-mail : eva@gsyc.escet.urjc.es 1137 Appendix A. Binary/Presentation format conversions 1139 The following functions convert network address structure in its 1140 presentation address format and vice versa: 1142 inet_ntop() 1143 inet_pton() 1145 Both are from the basic socket extensions for IPv6. Since these 1146 functions are not protocol independent, we should write code for 1147 the different address families. 1149 A more detailed examples are follows. 1151 A.1 Network address to presentation format 1153 Conversions from network address structure to presentation format 1154 can be written: 1156 struct sockaddr_storage ss; 1157 char addrStr[INET6_ADDRSTRLEN]; 1159 /* fill ss structure */ 1160 switch (ss.ss_family) { 1162 case AF_INET: 1163 inet_ntop(ss.ss_family, 1164 &((struct sockaddr_in *)&ss)->sin_addr, 1165 addrStr, 1166 sizeof(addrStr)); 1167 break; 1169 case AF_INET6: 1170 inet_ntop(ss.ss_family, 1171 &((struct sockaddr_in6 *)&ss)->sin6_addr, 1172 addrStr, 1173 sizeof(addrStr)); 1175 break; 1177 default: 1178 /* handle unknown family */ 1179 } 1181 Note, the destination buffer addrStr should be long enough to 1182 contain the presentation address format: INET_ADDRSTRLEN for IPv4 1183 and INET6_ADDRSTRLEN for IPv6. Then, INET_ADDR_STRLEN should be at 1184 least the maximum between them. 1186 However, this conversion is protocol dependent. We can write the 1187 same conversion using getnameinfo() in a protocol independent way. 1189 struct sockaddr_storage ss; 1190 char addrStr[INET6_ADDRSTRLEN]; 1191 char servStr[NI_MAXSERV]; 1192 int error; 1194 /* fill ss structure */ 1196 error = getnameinfo((struct sockaddr *)&ss, sizeof(ss), 1197 addrStr, sizeof(addrStr), 1198 servStr, sizeof(servStr), 1199 NI_NUMERICHOST); 1201 A.2 presentation format to network address 1203 Conversions from presentation format to network address structure 1204 can be written as follows: 1206 struct sockaddr_storage ss; 1207 struct sockaddr_in *sin; 1208 struct sockaddr_in6 *sin6; 1209 char addrStr[INET6_ADDRSTRLEN]; 1210 /* fill addrStr buffer and ss.ss_family */ 1212 switch (ss.ss_family) { 1213 case AF_INET: 1214 sin = (struct sockaddr_in *)&ss; 1215 inet_pton(ss.ss_family, 1216 addrStr, 1217 (sockaddr *)&sin->sin_addr)); 1218 break; 1220 case AF_INET6: 1221 sin6 = (struct sockaddr_in6 *)&ss; 1222 inet_pton(ss.ss_family, 1223 addrStr, 1224 (sockaddr *)&sin6->sin6_addr); 1225 break; 1227 default: 1228 /* handle unknown family */ 1229 } 1231 Note, the address family of the presentation format must be known. 1233 This conversion may be also written in a protocol independent way 1234 using getaddrinfo(). 1236 struct addrinfo hints, *res; 1237 char addrStr[INET6_ADDRSTRLEN]; 1238 int error; 1240 /* fill addrStr buffer */ 1242 memset(&hints, 0, sizeof(hints)); 1243 hints.ai_family = AF_UNSPEC; 1245 error = getaddrinfo(addrStr, NULL, &hints, &res); 1246 if (error != 0) { 1247 /* handle getaddrinfo error */ 1248 } 1250 /* res->ai_addr contains the network address structure */ 1251 /* ... */ 1253 freeaddrinfo(res); 1255 Intellectual Property Statement 1257 The IETF takes no position regarding the validity or scope of any 1258 intellectual property or other rights that might be claimed to 1259 pertain to the implementation or use of the technology described in 1260 this document or the extent to which any license under such rights 1261 might or might not be available; neither does it represent that it 1262 has made any effort to identify any such rights. Information on the 1263 IETF's procedures with respect to rights in standards-track and 1264 standards-related documentation can be found in BCP-11. Copies of 1265 claims of rights made available for publication and any assurances 1266 of licenses to be made available, or the result of an attempt made 1267 to obtain a general license or permission for the use of such 1268 proprietary rights by implementors or users of this specification 1269 can be obtained from the IETF Secretariat. 1271 The IETF invites any interested party to bring to its attention any 1272 copyrights, patents or patent applications, or other proprietary 1273 rights which may cover technology that may be required to practice 1274 this standard. Please address the information to the IETF Executive 1275 Director. 1277 Full Copyright Statement 1279 Copyright (C) The Internet Society (2003). All Rights Reserved. 1281 This document and translations of it may be copied and furnished to 1282 others, and derivative works that comment on or otherwise explain 1283 it or assist in its implementation may be prepared, copied, 1284 published and distributed, in whole or in part, without restriction 1285 of any kind, provided that the above copyright notice and this 1286 paragraph are included on all such copies and derivative works. 1287 However, this document itself may not be modified in any way, such 1288 as by removing the copyright notice or references to the Internet 1289 Society or other Internet organizations, except as needed for the 1290 purpose of developing Internet standards in which case the 1291 procedures for copyrights defined in the Internet Standards process 1292 must be followed, or as required to translate it into languages 1293 other than English. 1295 The limited permissions granted above are perpetual and will not be 1296 revoked by the Internet Society or its successors or assignees. 1298 This document and the information contained herein is provided on 1299 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1300 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1301 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1302 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1303 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1305 Acknowledgement 1307 Funding for the RFC Editor function is currently provided by the 1308 Internet Society.