idnits 2.17.1 draft-ietf-v6ops-application-transition-00.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 2) being 61 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 (December 2003) is 7438 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 729, but not defined ** Obsolete undefined reference: RFC 2133 (Obsoleted by RFC 2553) == Missing Reference: 'MAXSOCK' is mentioned on line 896, but not defined == Unused Reference: 'RFC 3493' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'RFC 3542' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'AF-APP' is defined on line 1089, but no explicit reference was found in the text == Unused Reference: 'IP-GGF' 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 (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 v6ops Working Group M-K. Shin (ed.) 2 INTERNET DRAFT Y-G. Hong 3 Expires: April 2004 ETRI 4 J. Hagino 5 IIJ 6 P. Savola 7 CSC/FUNET 8 E. M. Castro 9 GSYC/URJC 10 December 2003 12 Application Aspects of IPv6 Transition 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsolete by other documents 26 at anytime. It is inappropriate to use Internet Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 As IPv6 networks are deployed and the network transition discussed, 38 one should also consider how to enable IPv6 support in applications 39 running on IPv6 hosts, and what is the best strategy to develop IP 40 protocol support in applications. This document specifies 41 scenarios and aspects of application transition. It also proposes 42 guidelines on how to develop IP version-independent applications 43 during the transition period. 45 Table of Contents: 47 1. Introduction .............................................. 2 48 2. Overview of IPv6 application transition ................... 3 49 3. Problems with IPv6 application transition ................. 4 50 3.1 IPv6 support in the OS and applications are unrelated.... 4 51 3.2 DNS does not indicate which the IP version will be used . 5 52 3.3 Supporting many versions of an application is difficult ..5 53 4. Description of transition scenarios and guidelines ........ 6 54 4.1 IPv4 applications in a dual-stack node .................. 6 55 4.2 IPv6 applications in a dual-stack node .................. 7 56 4.3 IPv4/IPv6 applications in a dual stack node ............. 9 57 4.4 IPv4/IPv6 applications in an IPv4-only node ............. 9 58 5. Application porting considerations ........................10 59 5.1 Presentation format for an IP address ...................10 60 5.2 Transport layer API .....................................11 61 5.3 Name and address resolution .............................12 62 5.4 Specific IP dependencies ............................... 12 63 5.4.1 IP address selection .................................13 64 5.4.2 Application framing ..................................13 65 5.4.3 Storage of IP addresses ..............................14 66 6. Developing IP version-independent applications ............14 67 6.1 IP version-independent structures .......................14 68 6.2 IP version-independent APIs .............................15 69 6.2.1 Example of overly simplistic TCP server application ..16 70 6.2.2 Example of overly simplistic TCP client application ..17 71 6.2.3 Binary/presentation format conversion ................17 72 6.3 Iterated jobs for finding the working address ...........18 73 6.3.1 Example of TCP server application ....................18 74 6.3.2 Example of TCP client application ....................20 75 7. Transition mechanism considerations .......................21 76 8. Security considerations ...................................21 77 9. References ................................................21 78 Authors' addresses ...........................................23 79 Appendix A. Binary/presentation format conversions ...........23 80 A.1 Network address to presentation format ..................23 81 A.2 Presentation format to network address ..................24 83 1. Introduction 85 As IPv6 is introduced in the IPv4-based Internet, several general 86 issues when starting to use IPv6 in a world dominated by IPv4 are 87 being discussed, such as routing, addressing, DNS, scenarios, etc. 89 One important key to a successful IPv6 transition is the 90 compatibility with the large installed base of IPv4 hosts and 91 routers. This issue had been already been extensively studied, and 92 the work is still in progress. In particular, [2893BIS] describes 93 the basic transition mechanisms, dual-stack deployment and 94 tunneling. In addition, various kinds of transition mechanisms 95 have been developed to migrate to IPv6 network. However, these 96 transition mechanisms take no stance on whether applications 97 support IPv6 or not. 99 This document specifies application aspects of IPv6 transition. 100 That is, two inter-related topics are covered: 102 1. How different network transition techniques affect 103 applications, and what are the strategies for applications 104 to support IPv6 and IPv4. 106 2. How to develop IPv6-capable or protocol-independent 107 applications ("application porting guidelines"). 109 Applications will need to be modified to support IPv6 (and IPv4), 110 using one of a number of techniques described in sections 2-4. 111 Some guidelines to develop such application are then presented in 112 sections 5 and 6. 114 2. Overview of IPv6 application transition 116 The transition of an application can be classifed using four 117 different cases (excluding the first case when there is no IPv6 118 support either in the application or the operating system), as 119 follows: 121 +-------------------+ 122 | appv4 | (appv4 - IPv4-only applications) 123 +-------------------+ 124 | TCP / UDP | (transport protocols) 125 +-------------------+ 126 | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) 127 +-------------------+ 129 Case 1. IPv4 applications in a dual-stack node 131 +-------------------+ (appv4 - IPv4-only applications) 132 | appv4 | appv6 | (appv6 - IPv6-only applications) 133 +-------------------+ 134 | TCP / UDP | (transport protocols) 135 +-------------------+ 136 | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) 137 +-------------------+ 139 Case 2. IPv4-only applications and IPv6-only applications 140 in a dual-stack node 142 +-------------------+ 143 | appv4/v6 | (appv4/v6 - applications supporting 144 +-------------------+ both IPv4 and IPv6) 145 | TCP / UDP | (transport protocols) 146 +-------------------+ 147 | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) 148 +-------------------+ 150 Case 3. Applications supporting both IPv4 and IPv6 151 in a dual-stack node 153 +-------------------+ 154 | appv4/v6 | (appv4/v6 - applications supporting 155 +-------------------+ both IPv4 and IPv6) 156 | TCP / UDP | (transport protocols) 157 +-------------------+ 158 | IPv4 | (IP protocols supported/enabled in the OS) 159 +-------------------+ 161 Case 4. Applications supporting both IPv4 and IPv6 162 in an IPv4-only node 164 Figure 1. Overview of Application Transition 166 Figure 1 shows the cases of application transition. 168 Case 1 : IPv4-only applications in a dual-stack node. 169 IPv6 protocol is introduced in a node, but 170 applications are not yet ported to IPv6. 172 Case 2 : IPv4-only applications and IPv6-only applications 173 in a dual-stack node. 174 Applications are ported for IPv6-only. Therefore, 175 there are two same applications for different 176 protocol versions (e.g., ping and ping6). 178 Case 3 : Applications supporting both IPv4 and IPv6 in a dual 179 stack node. 180 Applications are ported for both IPv4 and IPv6 support. 181 Therefore, the existing IPv4 applications can be 182 removed. 184 Case 4 : Applications supporting both IPv4 and IPv6 in an 185 IPv4-only node. 186 Applications are ported for both IPv4 and IPv6 support, 187 but the same applications may also have to work when 188 IPv6 is not being used (e.g. disabled from the OS). 190 3. Problems with IPv6 application transition 192 There are several reasons why the transition period between IPv4 193 and IPv6 applications may not be straightforward. These issues are 194 described in this section. 196 3.1 IPv6 support in the OS and applications are unrelated 198 Considering the cases described in the previous section, IPv4 and 199 IPv6 protocol stacks in a node is likely to co-exist for a long 200 time. 202 Similarly, most applications are expected to be able to handle both 203 IPv4 and IPv6 during another, unrelated long time period. That is, 204 operating system being dual stack does not mean having both IPv4 205 and IPv6 applications. Therefore, IPv6-capable application 206 transition may be independent of protocol stacks in a node. 208 It is even probable that applications capable of both IPv4 and IPv6 209 will have to work properly in IPv4-only nodes (whether IPv6 210 protocol is completely disabled or there is no IPv6 connectivity at 211 all). 213 3.2 DNS does not indicate which the IP version will be used 215 The role of the DNS name resolver in a node is to get the list of 216 destination addresses. DNS queries and responses are sent using 217 either IPv4 or IPv6 to carry the queries, regardless of the 218 protocol version of the data records [DNSTRANS]. 220 The issue of DNS name resolving related to application transition 221 is that a client application can not be certain of the version of 222 peer application by only doing a DNS name lookup. For example, if a 223 server application does not support IPv6 yet, but runs on a dual- 224 stack machine for other IPv6 services and this is listed with an 225 AAAA record in the DNS, the client application will fail to connect 226 to the server application, because there is a mis-match between the 227 DNS query result (i.e. IPv6 addresses) and a server application 228 version (i.e. IPv4). 230 It is bad practise to add an AAAA record for node that does not 231 support all the services using IPv6 (rather, an AAAA record for the 232 specific service name and address should be used), but the 233 application cannot depend on "good practise", and this must be 234 handled. Operational considerations and issues with IPv6 DNS are 235 described at more length in [DNSOPV6]. 237 In consequence, the application should request all IP addresses 238 without address family constraints and try all the records returned 239 from the DNS, in some order, until a working address is found. In 240 particular, the application has to be able to handle all IP 241 versions returned from the DNS. 243 3.3 Supporting many versions of an application is difficult 245 During the application transition period, system administrators may 246 have various versions of the same application (an IPv4-only 247 application, an IPv6-only application, or an application supporting 248 both IPv4 and IPv6). 250 Typically one cannot know which IP versions must be supported prior 251 to doing a DNS lookup *and* trying (see section 3.2) the addresses 252 returned. Therefore, the users have a difficulty selecting the 253 right application version supporting the exact IP version required 254 if multiple versions of the same application are available. 256 To avoid problems with one application not supporting the specified 257 protocol version, it is desirable to have hybrid applications, 258 supporting both the protocol versions. 260 Alternative approach is to have a "wrapper application" which 261 performs certain tasks (like figures out which protocol version 262 will be used) and calls the IPv4/IPv6-only applications as 263 necessary. However, these wrapper applications will actually 264 probably have to do more than just perform a DNS lookup or figure 265 out the literal IP address given. Thus, they may get complex, and 266 only work for certain kinds of, usually simple, applications. 268 Nonetheless, there should be some reasonable logic to enable the 269 users to use the applications with any supported protocol version; 270 the users should not have to select from various versions of 271 applications, some supporting only IPv4, others only IPv6, and yet 272 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 as described 306 in section 3.2 --the IPv4 client in a [BIS]/[BIA] node trying to 307 connect to an IPv4 server in a dual stack system-- arises. However, 308 one can rely on [BIA]/[BIS] mechanism, which should cycle through 309 all the addresses instead of 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 to 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 when 399 writing one application to support both protocols: 401 1. whether the application can (or should) support both IPv4 402 and IPv6 through IPv4-mapped IPv6 addresses, or should the 403 applications support both explicitly (see section 4.3), and 405 2. whether the systems where the applications are used support 406 IPv6 at all or not (see section 4.4). 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 In the following subsections, the problems with the aforementioned 496 IP version dependencies are analyzed. Although application source 497 code can be ported to IPv6 with minimum changes related to IP 498 addresses, some recommendations are given to modify the source code 499 in a protocol independent way, which will allow applications to 500 work using both 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 611 5.4.1 IP address selection 613 IPv6 promotes the configuration from multiple IP addresses per 614 node, which is a different model of IPv4; however applications only 615 use a destination/source pair for a communication. Choosing the 616 right IP source and destination addresses is a key factor that may 617 determine the route of IP datagrams. 619 Typically nodes, not applications, automatically solve the source 620 address selection. A node will choose the source address for a 621 communication following some rules of best choice, [RFC 3484], but 622 also allowing applications to make changes in the ordering rules. 624 When selecting the destination address, applications usually ask a 625 resolver for the destination IP address. The resolver returns a set 626 of valid IP addresses from a hostname. Unless applications have a 627 specific reason to select any particular destination address, they 628 should just try each element in the list until the communication 629 succeeds. 631 5.4.2 Application framing 633 The Application Level Framing (ALF) architecture controls 634 mechanisms that traditionally fall within the transport layer. 635 Applications implementing ALF are often responsible for packetizing 636 data into Application Data Units (ADUs). The application problem 637 when using ALF is the ADU size selection to obtain better 638 performance. 640 Application framing is typically needed by applications using 641 connectionless protocols (such as UDP). The application will have 642 to know, or be able to detect, what are the packet sizes which can 643 be sent and received, end-to-end, on the network. 645 Applications can use 1280 octets as data length. [RFC 2460] 646 specifies IPv6 requires that every link in the Internet have an 647 Maximum Transmission Unit (MTU) of 1280 octets or greater. However, 648 in order to get better performance ADU size should be calculated 649 based on the length of transmission unit of underlying protocols. 651 FIXME: Application framing has relations e.g. with Path MTU 652 Discovery and application design which need to be analyzed better. 654 5.4.3 Storage of IP addresses 656 Some applications store IP addresses as information of remote 657 peers. For instance, one of the most popular ways to register 658 remote nodes in collaborative applications is based on using IP 659 addresses as registry keys. 661 Although the source code that stores IP addresses can be modified 662 to IPv6 following the previous basic porting recommendations, there 663 are some reasons why applications should not store IP addresses: 665 - IP addresses can change throughout the time, for instance 666 after a renumbering process. 668 - The same node can reach a destination host using different 669 IP addresses. 671 Instead of using IP addresses, applications should use FQDNs. 672 Hence, applications delegate the resolution of the IP addresses to 673 the name resolution system, which will return the associated IP 674 address at the moment of the query. 676 6. Developing IP version-independent applications 678 As we have seen before, dual applications working with both IPv4 679 and IPv6 are recommended. These applications should avoid IP 680 dependencies in the source code. However if IP dependencies are 681 required, one of the best solutions is based on building a 682 communication library which provides an IP version independent API 683 to applications and hides all dependencies. 685 In order to develop IP version independent applications, the 686 following guidelines should be considered. 688 6.1 IP version-independent structures 690 All of the memory structures and APIs should be IP version- 691 independent. In that sense, one should avoid structs in_addr, 692 in6_addr, sockaddr_in and sockaddr_in6. 694 Suppose you pass a network address to some function, foo(). If you 695 use struct in_addr or struct in6_addr, you will end up with extra 696 parameter to indicate address family, as below: 698 struct in_addr in4addr; 699 struct in6_addr in6addr; 700 /* IPv4 case */ 701 foo(&in4addr, AF_INET); 702 /* IPv6 case */ 703 foo(&in6addr, AF_INET6); 705 However, this leads to duplicated code and having to consider each 706 scenario from both perspectives independently; this is difficult to 707 maintain. So, we should use struct sockaddr_storage like below. 709 struct sockaddr_storage ss; 710 int sslen; 711 /* AF independent! - use sockaddr when passing a pointer */ 712 /* note: it's typically necessary to also pass the length 713 explicitly */ 714 foo((struct sockaddr *)&ss, sslen); 716 6.2 IP version-independent APIs 718 getaddrinfo() and getnameinfo() are new address independent 719 variants that hide the gory details of name-to-address and 720 address-to-name translations. They implement functionalities of 721 the following functions: 723 gethostbyname() 724 gethostbyaddr() 725 getservbyname() 726 getservbyport() 728 They also obsolete the functionality of gethostbyname2(), defined 729 in [RFC2133]. 731 These can perform hostname/address and service name/port lookups, 732 though the features can be turned off if desirable. getaddrinfo() 733 can return multiple addresses, as below: 735 localhost. IN A 127.0.0.1 736 IN A 127.0.0.2 737 IN AAAA ::1 739 In this example, if IPv6 is preferred, getaddrinfo returns first 740 ::1, and then both 127.0.0.1 and 127.0.0.2 is in a random order. 742 Getaddrinfo() and getnameinfo() can query hostname as well as 743 service name/port at once. 745 As well, it is not preferred to hardcode AF-dependent knowledge 746 into the program. The construct like below should be avoided: 748 /* BAD EXAMPLE */ 749 switch (sa->sa_family) { 750 case AF_INET: 751 salen = sizeof(struct sockaddr_in); 752 break; 753 } 755 Instead, we should use the ai_addrlen member of the addrinfo 756 structure, as returned by getaddrinfo(). 758 The gethostbyname(), gethostbyaddr(), getservbyname(), and 759 getservbyport() are mainly used to get server and client sockets. 761 Following, we will see simple examples to create these sockets 762 using the new IPv6 resolution functions. 764 6.2.1 Example of overly simplistic TCP server application 766 A simple TCP server socket at service name (or port number string) 767 SERVICE: 769 /* 770 * BAD EXAMPLE: does not implement the getaddrinfo loop as 771 * specified in 6.3. This may result in one of the following: 772 * - an IPv6 server, listening at the wildcard address, 773 * allowing IPv4 addresses through IPv4-mapped IPv6 addresses. 774 * - an IPv4 server, if IPv6 is not enabled, 775 * - an IPv6-only server, if IPv6 is enabled but IPv4-mapped IPv6 776 * addresses are not used by default, or 777 * - no server at all, if getaddrinfo supports IPv6, but the 778 * system doesn't, and socket(AF_INET6, ...) exists with an 779 * error. 780 */ 781 struct addrinfo hints, *res; 782 int error, sockfd; 784 memset(&hints, 0, sizeof(hints)); 785 hints.ai_flags = AI_PASSIVE; 786 hints.ai_family = AF_UNSPEC; 787 hints.ai_socktype = SOCK_STREAM; 789 error = getaddrinfo(NULL, SERVICE, &hints, &res); 790 if (error != 0) { 791 /* handle getaddrinfo error */ 792 } 794 sockfd = socket(res->family, res->ai_socktype, res->ai_protocol); 795 if (sockfd < 0) { 796 /* handle socket error */ 797 } 799 if (bind(sockfd, res->ai_addr, res->ai_addrlen) < 0) { 800 /* handle bind error */ 801 } 803 /* ... */ 805 freeaddrinfo(res); 807 6.2.2 Example of overly simplistic TCP client application 809 A simple TCP client socket connecting to a server which is running 810 at node name (or IP address presentation format) SERVER_NODE and 811 service name (or port number string) SERVICE: 813 /* 814 * BAD EXAMPLE: does not implement the getaddrinfo loop as 815 * specified in 6.3. This may result in one of the following: 816 * - an IPv4 connection to the IPv4 destination, 817 * - an IPv6 connection to an IPv6 destination, 818 * - an attempt to try to reach an IPv6 destination (if AAAA 819 * record found), but failing -- without fallbacks -- because: 820 * o getaddrinfo supports IPv6 but the system does not 821 * o IPv6 routing doesn't exist, so falling back to e.g. TCP 822 * timeouts 823 * o IPv6 server reached, but service not IPv6-enabled or 824 * firewalled away 825 * - if the first destination is not reached, there is no 826 * fallback to the next records 827 */ 828 struct addrinfo hints, *res; 829 int error, sockfd; 831 memset(&hints, 0, sizeof(hints)); 832 hints.ai_family = AF_UNSPEC; 833 hints.ai_socktype = SOCK_STREAM; 835 error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res); 836 if (error != 0) { 837 /* handle getaddrinfo error */ 838 } 840 sockfd = socket(res->family, res->ai_socktype, res->ai_protocol); 841 if (sockfd < 0) { 842 /* handle socket error */ 843 } 845 if (connect(sockfd, res->ai_addr, res->ai_addrlen) < 0 ) { 846 /* handle connect error */ 847 } 849 /* ... */ 851 freeaddrinfo(res); 853 6.2.3 Binary/presentation format conversion 855 In addition, we should consider the binary and presentation address 856 format conversion APIs. The following functions convert network 857 address structure in its presentation address format and vice 858 versa: 860 inet_ntop() 861 inet_pton() 863 Both are from the basic socket extensions for IPv6. Since these 864 functions are not protocol independent, we should write code for 865 the different address families. 867 A more detailed examples are described in appendix A. 869 Note that inet_ntop()/inet_pton() lose the scope identifier (if 870 used e.g. with link-local addresses) in the conversions, contrary 871 to the getaddrinfo()/getnameinfo() functions. 873 6.3 Iterated jobs for finding the working address 875 In a client code, when multiple addresses are returned from 876 getaddrinfo(), we should try all of them until connection succeds. 877 When a failure occurs with socket(), connect(), bind(), or some 878 other function, go on to try the next address. 880 In addition, if something is wrong with the socket call because the 881 address family is not supported (i.e., in case of section 4.4), 882 applications should try the next address structure. 884 Note: in the following examples, the socket() return value error 885 handling could be simplied by substituting special checking of 886 specific error numbers by always continuing on with the socket 887 loop. Whether this is a better idea should be considered in more 888 detail. 890 6.3.1 Example of TCP server application 892 The previous example TCP server example should be written: 894 #define MAXSOCK 2 895 struct addrinfo hints, *res; 896 int error, sockfd[MAXSOCK], nsock=0; 898 memset(&hints, 0, sizeof(hints)); 899 hints.ai_flags = AI_PASSIVE; 900 hints.ai_family = AF_UNSPEC; 901 hints.ai_socktype = SOCK_STREAM; 903 error = getaddrinfo(NULL, SERVICE, &hints, &res); 904 if (error != 0) { 905 /* handle getaddrinfo error */ 906 } 908 for (aip=res; aip && nsock < MAXSOCK; aip=aip->ai_next) { 909 sockfd[nsock] = socket(aip->ai_family, 910 aip->ai_socktype, 911 aip->ai_protocol); 913 if (sockfd[nsock] < 0) { 914 switch errno { 915 case EAFNOSUPPORT: 916 case EPROTONOSUPPORT: 917 /* 918 * e.g., skip the errors until 919 * the last address family, 920 * see section 4.4. 921 */ 922 if (aip->ai_next) 923 continue; 924 else { 925 /* handle unknown protocol errors */ 926 break; 927 } 928 default: 929 /* handle other socket errors */ 930 ; 931 } 933 } else { 934 int on = 1; 935 /* optional: works better if dual-binding to wildcard 936 address */ 937 if (aip->ai_family == AF_INET6) { 938 setsockopt(sockfd[nsock], IPPROTO_IPV6, IPV6_V6ONLY, 939 (char *)&on, sizeof(on)); 940 /* errors are ignored */ 941 } 942 if (bind(sockfd[nsock], aip->ai_addr, 943 aip->ai_addrlen) < 0 ) { 944 /* handle bind error */ 945 close(sockfd[nsock]); 946 continue; 947 } 948 if (listen(sockfd[nsock], SOMAXCONN) < 0) { 949 /* handle listen errors */ 950 close(sockfd[nsock]); 951 continue; 952 } 953 } 954 nsock++; 955 } 956 freeaddrinfo(res); 958 /* check that we were able to obtain the sockets */ 960 6.3.2 Example of TCP client application 962 The previous TCP client example should be written: 964 struct addrinfo hints, *res, *aip; 965 int sockfd, error; 967 memset(&hints, 0, sizeof(hints)); 968 hints.ai_family = AF_UNSPEC; 969 hints.ai_socktype = SOCK_STREAM; 971 error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res); 972 if (error != 0) { 973 /* handle getaddrinfo error */ 974 } 976 for (aip=res; aip; aip=aip->ai_next) { 978 sockfd = socket(aip->ai_family, 979 aip->ai_socktype, 980 aip->ai_protocol); 982 if (sockfd < 0) { 983 switch errno { 984 case EAFNOSUPPORT: 985 case EPROTONOSUPPORT: 986 /* 987 * e.g., skip the errors until 988 * the last address family, 989 * see section 4.4. 990 */ 991 if (aip->ai_next) 992 continue; 993 else { 994 /* handle unknown protocol errors */ 995 break; 996 } 998 default: 999 /* handle other socket errors */ 1000 ; 1001 } 1003 } else { 1004 if (connect(sockfd, aip->ai_addr, aip->ai_addrlen) == 0) 1005 break; 1007 /* handle connect errors */ 1008 close(sockfd); 1009 sockfd=-1; 1010 } 1011 } 1013 if (sockfd > 0) { 1014 /* socket connected to server address */ 1015 /* ... */ 1016 } 1018 freeaddrinfo(res); 1020 7. Transition mechanism considerations 1022 A mechanism, [NAT-PT], introduces a special set of addresses, 1023 formed of NAT-PT prefix and an IPv4 address; this refers to IPv4 1024 addresses, translated by NAT-PT DNS-ALG. In some cases, one might 1025 be tempted to handle these differently. 1027 However, IPv6 applications must not be required to distinguish 1028 "normal" and "NAT-PT translated" addresses (or any other kind of 1029 special addresses, including the IPv6-mapped IPv4-addresses): that 1030 would be completely unscalable, and if such distinction must be 1031 made, it must be done elsewhere (e.g. kernel, system libraries). 1033 8. Security considerations 1035 TBD. 1037 One particular point about application transition is how IPv4- 1038 mapped IPv6-addresses are handled. The use in the API can be seen 1039 as both a merit (easier application transition) and as a burden 1040 (difficulty in ensuring whether the use was legimate) [V6MAPPED]. 1041 This may have to be considered in more detail. 1043 9. References 1045 Normative References 1047 [RFC 3493] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic 1048 Socket Interface Extensions for IPv6," RFC 3493, February 1049 2003. 1051 [RFC 3542] W. Stevens, M. Thomas, E. Nordmark, T. Jinmei, "Advanced 1052 Sockets Application Program Interface (API) for IPv6," 1053 RFC 3542, May 2003. 1055 [BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts 1056 using the "Bump-In-the-Stack" Technique (BIS)," RFC 2767, 1057 February 2000. 1059 [BIA] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand, 1060 "Dual Stack Hosts using "Bump-in-the-API" (BIA)," RFC 1061 3338, October 2002. 1063 [2893BIS] E. Nordmark, "Transition Mechanisms for IPv6 Hosts and 1064 Routers," , February 2003, 1065 Work-in-progress. 1067 [RFC 2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 1068 (IPv6) Specification,", RFC 2460, December 1998. 1070 [RFC 3484] R. Draves, "Default Address Selection for IPv6," 1071 RFC 3484, February 2003. 1073 Informative References 1075 [RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal 1076 IPv6 Addresses in URL's," RFC 2732, December 1999. 1078 [NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation 1079 - Protocol Translation (NAT-PT)," RFC 2766, February 2000. 1081 [DNSTRANS] A. Durand, J. Ihren, "DNS IPv6 transport operational 1082 guidelines," , June 2003, Work in Progress. 1085 [DNSOPV6] A. Durand, J. Ihren, P. Savola, "Operational Considerations 1086 and Issues with IPv6 DNS," , November 2003, Work in Progress. 1089 [AF-APP] Jun-ichiro itojun Hagino, "Implementing AF-independent 1090 application", http://www.kame.net/newsletter/19980604/, 1091 2001. 1093 [V6MAPPED] Jun-ichiro itojun Hagino, "IPv4 mapped address 1094 considered harmful", , Apr 2002, Work in Progress. 1097 [IP-GGF] T. Chown, J. Bound, S. Jiang, P. O'Hanlon, "Guidelines for 1098 IP version independence in GGF specifications," Global 1099 Grid Forum(GGF) Documentation, September 2003, Work in 1100 Progress. 1102 Authors' addresses 1103 Myung-Ki Shin 1104 ETRI PEC 1105 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 1106 Tel : +82 42 860 4847 1107 Fax : +82 42 861 5404 1108 E-mail : mkshin@pec.etri.re.kr 1110 Yong-Guen Hong 1111 ETRI PEC 1112 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 1113 Tel : +82 42 860 6447 1114 Fax : +82 42 861 5404 1115 E-mail : yghong@pec.etri.re.kr 1117 Jun-ichiro itojun HAGINO 1118 Research Laboratory, Internet Initiative Japan Inc. 1119 Takebashi Yasuda Bldg., 1120 3-13 Kanda Nishiki-cho, 1121 Chiyoda-ku,Tokyo 101-0054, JAPAN 1122 Tel: +81-3-5259-6350 1123 Fax: +81-3-5259-6351 1124 E-mail: itojun@iijlab.net 1126 Pekka Savola 1127 CSC/FUNET 1128 Espoo, Finland 1129 E-mail: psavola@funet.fi 1131 Eva M. Castro 1132 Rey Juan Carlos University (URJC) 1133 E-mail : eva@gsyc.escet.urjc.es 1135 Appendix A. Binary/presentation format conversions 1137 The following functions convert network address structure in its 1138 presentation address format and vice versa: 1140 inet_ntop() 1141 inet_pton() 1143 Both are from the basic socket extensions for IPv6. Since these 1144 functions are not protocol independent, we should write code for 1145 the different address families. 1147 A more detailed examples are follows. 1149 A.1 Network address to presentation format 1151 Conversions from network address structure to presentation format 1152 can be written: 1154 struct sockaddr_storage ss; 1155 char addrStr[INET6_ADDRSTRLEN]; 1157 /* fill ss structure */ 1159 switch (ss.ss_family) { 1160 case AF_INET: 1161 inet_ntop(ss.ss_family, 1162 &((struct sockaddr_in *)&ss)->sin_addr, 1163 addrStr, 1164 sizeof(addrStr)); 1165 break; 1167 case AF_INET6: 1168 inet_ntop(ss.ss_family, 1169 &((struct sockaddr_in6 *)&ss)->sin6_addr, 1170 addrStr, 1171 sizeof(addrStr)); 1173 break; 1175 default: 1176 /* handle unknown family */ 1177 } 1179 Note, the destination buffer addrStr should be long enough to 1180 contain the presentation address format: INET_ADDRSTRLEN for IPv4 1181 and INET6_ADDRSTRLEN for IPv6. Since INET6_ADDRSTRLEN is longer 1182 than INET_ADDRSTRLEN, the first one is used as the destination 1183 buffer length. 1185 However, this conversion is protocol dependent. We can write the 1186 same conversion using getnameinfo() in a protocol independent way. 1188 struct sockaddr_storage ss; 1189 char addrStr[INET6_ADDRSTRLEN]; 1190 char servStr[NI_MAXSERV]; 1191 int error; 1193 /* fill ss structure */ 1195 error = getnameinfo((struct sockaddr *)&ss, sizeof(ss), 1196 addrStr, sizeof(addrStr), 1197 servStr, sizeof(servStr), 1198 NI_NUMERICHOST); 1200 A.2 presentation format to network address 1202 Conversions from presentation format to network address structure 1203 can be written as follows: 1205 struct sockaddr_storage ss; 1206 struct sockaddr_in *sin; 1207 struct sockaddr_in6 *sin6; 1208 char addrStr[INET6_ADDRSTRLEN]; 1210 /* fill addrStr buffer and ss.ss_family */ 1211 switch (ss.ss_family) { 1212 case AF_INET: 1213 sin = (struct sockaddr_in *)&ss; 1214 inet_pton(ss.ss_family, 1215 addrStr, 1216 (sockaddr *)&sin->sin_addr)); 1217 break; 1219 case AF_INET6: 1220 sin6 = (struct sockaddr_in6 *)&ss; 1221 inet_pton(ss.ss_family, 1222 addrStr, 1223 (sockaddr *)&sin6->sin6_addr); 1224 break; 1226 default: 1227 /* handle unknown family */ 1228 } 1230 Note, the address family of the presentation format must be known. 1232 This conversion may be also written in a protocol independent way 1233 using getaddrinfo(). 1235 struct addrinfo hints, *res; 1236 char addrStr[INET6_ADDRSTRLEN]; 1237 int error; 1239 /* fill addrStr buffer */ 1241 memset(&hints, 0, sizeof(hints)); 1242 hints.ai_family = AF_UNSPEC; 1244 error = getaddrinfo(addrStr, NULL, &hints, &res); 1245 if (error != 0) { 1246 /* handle getaddrinfo error */ 1247 } 1249 /* res->ai_addr contains the network address structure */ 1250 /* ... */ 1252 freeaddrinfo(res); 1254 Intellectual Property Statement 1256 The IETF takes no position regarding the validity or scope of any 1257 intellectual property or other rights that might be claimed to 1258 pertain to the implementation or use of the technology described in 1259 this document or the extent to which any license under such rights 1260 might or might not be available; neither does it represent that it 1261 has made any effort to identify any such rights. Information on the 1262 IETF's procedures with respect to rights in standards-track and 1263 standards-related documentation can be found in BCP-11. Copies of 1264 claims of rights made available for publication and any assurances 1265 of licenses to be made available, or the result of an attempt made 1266 to obtain a general license or permission for the use of such 1267 proprietary rights by implementors or users of this specification 1268 can be obtained from the IETF Secretariat. 1270 The IETF invites any interested party to bring to its attention any 1271 copyrights, patents or patent applications, or other proprietary 1272 rights which may cover technology that may be required to practice 1273 this standard. Please address the information to the IETF Executive 1274 Director. 1276 Full Copyright Statement 1278 Copyright (C) The Internet Society (2003). All Rights Reserved. 1280 This document and translations of it may be copied and furnished to 1281 others, and derivative works that comment on or otherwise explain 1282 it or assist in its implementation may be prepared, copied, 1283 published and distributed, in whole or in part, without restriction 1284 of any kind, provided that the above copyright notice and this 1285 paragraph are included on all such copies and derivative works. 1286 However, this document itself may not be modified in any way, such 1287 as by removing the copyright notice or references to the Internet 1288 Society or other Internet organizations, except as needed for the 1289 purpose of developing Internet standards in which case the 1290 procedures for copyrights defined in the Internet Standards process 1291 must be followed, or as required to translate it into languages 1292 other than English. 1294 The limited permissions granted above are perpetual and will not be 1295 revoked by the Internet Society or its successors or assignees. 1297 This document and the information contained herein is provided on 1298 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1299 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1300 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1301 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1302 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1304 Acknowledgement 1306 Funding for the RFC Editor function is currently provided by the 1307 Internet Society.