--- 1/draft-ietf-v6ops-application-transition-00.txt 2006-02-05 02:07:12.000000000 +0100 +++ 2/draft-ietf-v6ops-application-transition-01.txt 2006-02-05 02:07:13.000000000 +0100 @@ -1,24 +1,24 @@ v6ops Working Group M-K. Shin (ed.) INTERNET DRAFT Y-G. Hong -Expires: April 2004 ETRI +Expires: August 2004 ETRI J. Hagino IIJ P. Savola CSC/FUNET E. M. Castro GSYC/URJC - December 2003 + February 2004 Application Aspects of IPv6 Transition - + Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -30,69 +30,70 @@ The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract As IPv6 networks are deployed and the network transition discussed, one should also consider how to enable IPv6 support in applications - running on IPv6 hosts, and what is the best strategy to develop IP - protocol support in applications. This document specifies - scenarios and aspects of application transition. It also proposes - guidelines on how to develop IP version-independent applications - during the transition period. + running on IPv6 hosts, and the best strategy to develop IP protocol + support in applications. This document specifies scenarios and + aspects of application transition. It also proposes guidelines on + how to develop IP version-independent applications during the + transition period. Table of Contents: - 1. Introduction .............................................. 2 + 1. Introduction .............................................. 3 2. Overview of IPv6 application transition ................... 3 - 3. Problems with IPv6 application transition ................. 4 - 3.1 IPv6 support in the OS and applications are unrelated.... 4 + 3. Problems with IPv6 application transition ................. 5 + 3.1 IPv6 support in the OS and applications are unrelated.... 5 3.2 DNS does not indicate which the IP version will be used . 5 - 3.3 Supporting many versions of an application is difficult ..5 + 3.3 Supporting many versions of an application is difficult ..6 4. Description of transition scenarios and guidelines ........ 6 - 4.1 IPv4 applications in a dual-stack node .................. 6 + 4.1 IPv4 applications in a dual-stack node .................. 7 4.2 IPv6 applications in a dual-stack node .................. 7 4.3 IPv4/IPv6 applications in a dual stack node ............. 9 - 4.4 IPv4/IPv6 applications in an IPv4-only node ............. 9 + 4.4 IPv4/IPv6 applications in an IPv4-only node .............10 5. Application porting considerations ........................10 - 5.1 Presentation format for an IP address ...................10 - 5.2 Transport layer API .....................................11 - 5.3 Name and address resolution .............................12 - 5.4 Specific IP dependencies ............................... 12 + 5.1 Presentation format for an IP address ...................11 + 5.2 Transport layer API .....................................12 + 5.3 Name and address resolution .............................13 + 5.4 Specific IP dependencies ............................... 13 5.4.1 IP address selection .................................13 5.4.2 Application framing ..................................13 5.4.3 Storage of IP addresses ..............................14 - 6. Developing IP version-independent applications ............14 - 6.1 IP version-independent structures .......................14 - 6.2 IP version-independent APIs .............................15 - 6.2.1 Example of overly simplistic TCP server application ..16 - 6.2.2 Example of overly simplistic TCP client application ..17 - 6.2.3 Binary/presentation format conversion ................17 - 6.3 Iterated jobs for finding the working address ...........18 - 6.3.1 Example of TCP server application ....................18 - 6.3.2 Example of TCP client application ....................20 - 7. Transition mechanism considerations .......................21 - 8. Security considerations ...................................21 - 9. References ................................................21 - Authors' addresses ...........................................23 - Appendix A. Binary/presentation format conversions ...........23 - A.1 Network address to presentation format ..................23 - A.2 Presentation format to network address ..................24 + 5.5 Multicast applications ..................................15 + 6. Developing IP version-independent applications ............16 + 6.1 IP version-independent structures .......................16 + 6.2 IP version-independent APIs .............................17 + 6.2.1 Example of overly simplistic TCP server application ..18 + 6.2.2 Example of overly simplistic TCP client application ..18 + 6.2.3 Binary/presentation format conversion ................19 + 6.3 Iterated jobs for finding the working address ...........20 + 6.3.1 Example of TCP server application ....................20 + 6.3.2 Example of TCP client application ....................21 + 7. Transition mechanism considerations .......................23 + 8. Security considerations ...................................23 + 9. Acknowledgements .........................................23 + 10. References ...............................................23 + Authors' addresses ...........................................25 + Appendix A. Binary/presentation format conversions ...........26 + A.1 Network address to presentation format ..................26 + A.2 Presentation format to network address ..................28 1. Introduction As IPv6 is introduced in the IPv4-based Internet, several general - issues when starting to use IPv6 in a world dominated by IPv4 are - being discussed, such as routing, addressing, DNS, scenarios, etc. + issues arise such as routing, addressing, DNS, scenarios, etc. One important key to a successful IPv6 transition is the compatibility with the large installed base of IPv4 hosts and routers. This issue had been already been extensively studied, and the work is still in progress. In particular, [2893BIS] describes the basic transition mechanisms, dual-stack deployment and tunneling. In addition, various kinds of transition mechanisms have been developed to migrate to IPv6 network. However, these transition mechanisms take no stance on whether applications support IPv6 or not. @@ -115,131 +116,133 @@ 2. Overview of IPv6 application transition The transition of an application can be classifed using four different cases (excluding the first case when there is no IPv6 support either in the application or the operating system), as follows: +-------------------+ | appv4 | (appv4 - IPv4-only applications) +-------------------+ - | TCP / UDP | (transport protocols) - +-------------------+ + | TCP / UDP / others| (transport protocols - TCP, UDP, + +-------------------+ SCTP, DCCP, etc.) | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) +-------------------+ Case 1. IPv4 applications in a dual-stack node - +-------------------+ (appv4 - IPv4-only applications) | appv4 | appv6 | (appv6 - IPv6-only applications) +-------------------+ - | TCP / UDP | (transport protocols) - +-------------------+ + | TCP / UDP / others| (transport protocols - TCP, UDP, + +-------------------+ SCTP, DCCP, etc.) | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) +-------------------+ Case 2. IPv4-only applications and IPv6-only applications in a dual-stack node +-------------------+ | appv4/v6 | (appv4/v6 - applications supporting +-------------------+ both IPv4 and IPv6) - | TCP / UDP | (transport protocols) - +-------------------+ + | TCP / UDP / others| (transport protocols - TCP, UDP, + +-------------------+ SCTP, DCCP, etc.) | IPv4 | IPv6 | (IP protocols supported/enabled in the OS) +-------------------+ Case 3. Applications supporting both IPv4 and IPv6 in a dual-stack node + +-------------------+ | appv4/v6 | (appv4/v6 - applications supporting +-------------------+ both IPv4 and IPv6) - | TCP / UDP | (transport protocols) - +-------------------+ + | TCP / UDP / others| (transport protocols - TCP, UDP, + +-------------------+ SCTP, DCCP, etc.) | IPv4 | (IP protocols supported/enabled in the OS) +-------------------+ Case 4. Applications supporting both IPv4 and IPv6 in an IPv4-only node Figure 1. Overview of Application Transition Figure 1 shows the cases of application transition. Case 1 : IPv4-only applications in a dual-stack node. IPv6 protocol is introduced in a node, but applications are not yet ported to IPv6. Case 2 : IPv4-only applications and IPv6-only applications in a dual-stack node. - Applications are ported for IPv6-only. Therefore, - there are two same applications for different - protocol versions (e.g., ping and ping6). + Applications are ported for IPv6-only. Therefore + there are two similar applications, one for each + protocol version (e.g., ping and ping6). Case 3 : Applications supporting both IPv4 and IPv6 in a dual stack node. Applications are ported for both IPv4 and IPv6 support. Therefore, the existing IPv4 applications can be removed. Case 4 : Applications supporting both IPv4 and IPv6 in an IPv4-only node. Applications are ported for both IPv4 and IPv6 support, but the same applications may also have to work when IPv6 is not being used (e.g. disabled from the OS). + Note that this draft does not address DCCP and SCTP considerations + at this phase. + 3. Problems with IPv6 application transition There are several reasons why the transition period between IPv4 and IPv6 applications may not be straightforward. These issues are described in this section. 3.1 IPv6 support in the OS and applications are unrelated Considering the cases described in the previous section, IPv4 and IPv6 protocol stacks in a node is likely to co-exist for a long time. Similarly, most applications are expected to be able to handle both IPv4 and IPv6 during another, unrelated long time period. That is, - operating system being dual stack does not mean having both IPv4 - and IPv6 applications. Therefore, IPv6-capable application + the operating system being dual stack does not mean having both + IPv4 and IPv6 applications. Therefore, IPv6-capable application transition may be independent of protocol stacks in a node. It is even probable that applications capable of both IPv4 and IPv6 - will have to work properly in IPv4-only nodes (whether IPv6 + will have to work properly in IPv4-only nodes (whether the IPv6 protocol is completely disabled or there is no IPv6 connectivity at all). 3.2 DNS does not indicate which the IP version will be used The role of the DNS name resolver in a node is to get the list of destination addresses. DNS queries and responses are sent using either IPv4 or IPv6 to carry the queries, regardless of the protocol version of the data records [DNSTRANS]. - The issue of DNS name resolving related to application transition + The issue of DNS name resolution related to application transition, is that a client application can not be certain of the version of - peer application by only doing a DNS name lookup. For example, if a - server application does not support IPv6 yet, but runs on a dual- - stack machine for other IPv6 services and this is listed with an - AAAA record in the DNS, the client application will fail to connect - to the server application, because there is a mis-match between the - DNS query result (i.e. IPv6 addresses) and a server application - version (i.e. IPv4). + the peer application by only doing a DNS name lookup. For example, + if a server application does not support IPv6 yet, but runs on a + dual-stack machine for other IPv6 services, and this is listed with + an AAAA record in the DNS, the client application will fail to + connect to the server application. This is caused by a mis-match + between the DNS query result (i.e. IPv6 addresses) and a server + application version (i.e. IPv4). - It is bad practise to add an AAAA record for node that does not + It is bad practise to add an AAAA record for a node that does not support all the services using IPv6 (rather, an AAAA record for the - specific service name and address should be used), but the + specific service name and address should be used). However, the application cannot depend on "good practise", and this must be - handled. Operational considerations and issues with IPv6 DNS are - described at more length in [DNSOPV6]. + handled. In consequence, the application should request all IP addresses without address family constraints and try all the records returned from the DNS, in some order, until a working address is found. In particular, the application has to be able to handle all IP versions returned from the DNS. 3.3 Supporting many versions of an application is difficult During the application transition period, system administrators may @@ -247,24 +250,24 @@ application, an IPv6-only application, or an application supporting both IPv4 and IPv6). Typically one cannot know which IP versions must be supported prior to doing a DNS lookup *and* trying (see section 3.2) the addresses returned. Therefore, the users have a difficulty selecting the right application version supporting the exact IP version required if multiple versions of the same application are available. To avoid problems with one application not supporting the specified - protocol version, it is desirable to have hybrid applications, - supporting both the protocol versions. + protocol version, it is desirable to have hybrid applications + supporting both of the protocol versions. - Alternative approach is to have a "wrapper application" which + An alternative approach is to have a "wrapper application" which performs certain tasks (like figures out which protocol version will be used) and calls the IPv4/IPv6-only applications as necessary. However, these wrapper applications will actually probably have to do more than just perform a DNS lookup or figure out the literal IP address given. Thus, they may get complex, and only work for certain kinds of, usually simple, applications. Nonetheless, there should be some reasonable logic to enable the users to use the applications with any supported protocol version; the users should not have to select from various versions of @@ -279,171 +282,214 @@ transition from IPv4 to IPv6 will be a gradual process. Dual-stack nodes are one of the ways to maintain IPv4 compatibility in unicast communications. In this section we will analyze different application transition scenarios (as introduced in section 2) and guidelines to maintain interoperability between applications running in different types of nodes. 4.1 IPv4 applications in a dual-stack node - This scenario happens if IPv6 protocol is added in a node but + This scenario happens if the IPv6 protocol is added in a node but IPv6-capable applications aren't yet available or installed. Although the node implements the dual stack, IPv4 applications can only manage IPv4 communications. Then, IPv4 applications can only - accept/establish connections from/to nodes which implement IPv4 + accept/establish connections from/to nodes which implement an IPv4 stack. In order to allow an application to communicate with other nodes using IPv6, the first priority is to port applications to IPv6. In some cases (e.g. no source code is available), existing IPv4 applications can work if the [BIS] or [BIA] mechanism is installed in the node. However, these mechanisms should not be used when - application source code is available to prevent the mis-use of - them, for example, as an excuse not to port software. + application source code is available to prevent their mis-use, for + example, as an excuse not to port software. - When [BIA] or [BIS] is used, the same previous problem as described - in section 3.2 --the IPv4 client in a [BIS]/[BIA] node trying to + When [BIA] or [BIS] is used, the problem described in section 3.2 + becomes an issue --the IPv4 client in a [BIS]/[BIA] node trying to connect to an IPv4 server in a dual stack system-- arises. However, - one can rely on [BIA]/[BIS] mechanism, which should cycle through - all the addresses instead of applications. + one can rely on the [BIA]/[BIS] mechanism, which should cycle + through all the addresses instead of applications. + + [BIS] or [BIA] does not work with all kinds of applications. In + particular, the applications which exchange IP addresses as + application data (e.g., FTP). These mechanisms provide IPv4 + temporary addresses to the applications and locally make a + translation between IPv4 and IPv6 communication. Hence, these IPv4 + temporary addresses are only valid in the node scope." 4.2 IPv6 applications in a dual-stack node As we have seen in the previous section, applications should be ported to IPv6. The easiest way to port an IPv4 application is to - substitute the old IPv4 API references by the new IPv6, one-to-one - API mapping. That way, the application would be IPv6-only. This + substitute the old IPv4 API references with the new IPv6 one-to-one + API mapping. This way the application will be IPv6-only. This IPv6-only source code can not work in IPv4- only nodes, so the old IPv4 application should be maintained in these nodes. Then, we will - get two same applications working with different protocol versions, - depending on the node they are running (e.g., telnet and telnet6). - This case is undesirable since maintaining two versions of the same - source code per application, could be a difficult task. In - addition, this approach would cause problems for the users when + get two similar applications working with different protocol + versions, depending on the node they are running (e.g., telnet and + telnet6). This case is undesirable since maintaining two versions + of the same source code per application, could be a difficult task. + In addition, this approach would cause problems for the users when having to select which version of the application to use, as described in section 3.3. Most implementations of dual stack allow IPv6-only applications to interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to IPv6 applications on a dual-stack node, reach their destination because their addresses are mapped to IPv6 ones using IPv4-mapped IPv6 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4 address x.y.z.w. +----------------------------------------------+ | +------------------------------------------+ | | | | | | | IPv6-only applications | | | | | | | +------------------------------------------+ | | | | | +------------------------------------------+ | | | | | - | | TCP/UDP | | + | | TCP / UDP / others (SCTP, DCCP, etc.) | | | | | | | +------------------------------------------+ | | IPv4-mapped | | IPv6 | | IPv6 addresses | | addresses | | +--------------------+ +-------------------+ | | | IPv4 | | IPv6 | | | +--------------------+ +-------------------+ | | IPv4 | | | | adresses | | | +--------------|-----------------|-------------+ | | IPv4 packets IPv6 packets - When an IPv4 client application sends data to an IPv6-only server - application, running on a dual-stack node using the wildcard (but - without the IPV6_V6ONLY socket option) address, the IPv4 client - address is interpreted as the IPv4-mapped IPv6 address in the - dual-stack node to allow IPv6 application to manage this - communication. The IPv6 server will use this mapped address as if - it were a regular IPv6 address, and a usual IPv6 connection. - However, IPv4 packets will be exchanged between the nodes. Kernels - with dual stack properly interpret IPv4-mapped IPv6 addresses as - IPv4 ones and vice versa. + We will analyze the behaviour of IPv6-applications which exchange + IPv4 packets with IPv4 applications using the client/server model. + We consider the default case when the IPV6_V6ONLY socket option has + not been set. This default behavior of IPv6 applications in these + dual-stack nodes allows a limited amount of IPv4 communication + using the IPv4-mapped IPv6 addresses. - IPv6-only client application in a dual-stack node will not get - IPv4-mapped addresses from the hostname resolution API functions - unless a special hint, AI_V4MAPPED, is given. If given, the IPv6 - client will use the returned mapped address as if it were a regular - IPv6 address, and a usual IPv6 connection. However, again IPv4 - packets will be exchanged between applications. + IPv6-only server: + When an IPv4 client application sends data to an + IPv6-only server application running on a dual-stack + node using the wildcard address, the IPv4 client address + is interpreted as the IPv4-mapped IPv6 address in the + dual-stack node. This allows the IPv6 application to + manage the communication. The IPv6 server will use this + mapped address as if it were a regular IPv6 address, and + a usual IPv6 connection. However, IPv4 packets will be + exchanged between the nodes. Kernels with dual stack + properly interpret IPv4-mapped IPv6 addresses as IPv4 + ones and vice versa. - The default behavior of IPv6 applications in these dual-stack nodes - allows a limited amount of IPv4 communication using the IPv4-mapped - IPv6 addresses. However, it is possible for IPv6 applications to - allow connections only with IPv6 nodes (e.g. IPv6_V6ONLY socket - option), so the interoperability with IPv4 nodes is broken. This + IPv6-only client: + IPv6-only client applications in a dual-stack node will + not get IPv4-mapped addresses from the hostname + resolution API functions unless a special hint, + AI_V4MAPPED, is given. If given, the IPv6 client will + use the returned mapped address as if it were a regular + IPv6 address, and a usual IPv6 connection. However, again + IPv4 packets will be exchanged between applications. + + Respectively, with IPV6_V6ONLY set, an IPv6-only server application + will only communicate with IPv6 nodes, and an IPv6-only client with + IPv6 servers, as the mapped addresses have been disabled. This option could be useful if applications use new IPv6 features, such - as flowlabel. + as flowlabel. If communication with IPv4 is needed, either + IPV6_V6ONLY must not be used, or dual-stack applications be used, + as described in section 4.3. There are some implementations of dual-stack which do not allow IPv4-mapped IPv6 addresses to be used for interoperability between IPv4 and IPv6 applications. In that case, there are two ways to handle the problem: - 1. deploy two different versions of applications (possibly + 1. deploy two different versions of the application (possibly attached with '6' in the name), or - 2. deploy just one application supporting both protocol versions, + 2. deploy just one application supporting both protocol versions as described in the next section. - The first method is not recommended, because of significant amount - of problems of problems associated with selecting the right - applications, as described in sections 3.2 and 3.3. + The first method is not recommended because of a significant amount + of problems associated with selecting the right applications.This + scenario is described in sections 3.2 and 3.3. Therefore, there are actually two distinct cases to consider when writing one application to support both protocols: 1. whether the application can (or should) support both IPv4 and IPv6 through IPv4-mapped IPv6 addresses, or should the applications support both explicitly (see section 4.3), and + 2. whether the systems where the applications are used support IPv6 at all or not (see section 4.4). + Note that some systems will disable (by default) support for + internal IPv4-mapped IPv6 addresses. The security concerns + regarding IPv4-mapped IPv6 addresses on the wire are legitimate but + disabling it internally breaks one transition mechanism for server + apps which were originally written to bind and listen to a single + socket using a wildcard address. This forces the software developer + to rewrite the daemon to create 2 separate sockets, one for IPv4 + only and the other for IPv6 only, and then use select(). However, + enabling mapping of IPv4 addresses on any particular system is + controlled by the OS owner and not necessarilly by a developer. + This complicates the developer's work as he now has to rewrite the + daemon network code to handle both environments, even for the same + OS. + 4.3 IPv4/IPv6 applications in a dual stack node Applications should be ported to support both IPv4 and IPv6; such applications are sometimes called IP version-independent applications. After that, the existing IPv4-only applications could be removed. Since we have only one version of each application, the source code will be typically easy to maintain and to modify, and there are no problems managing which application to select for which purpose. - This transition case is the most advisable. During IPv6 transition - period, applications supporting both IPv4 and IPv6 should be able - to communicate with other applications, irrespective of the - versions of the protocol stack or the application in the node. Dual - applications allow more interoperability between heterogeneous + This transition case is the most advisable. During the IPv6 + transition period applications supporting both IPv4 and IPv6 should + be able to communicate with other applications, irrespective of the + versions of the protocol stack or the application in the node. + Dual applications allow more interoperability between heterogeneous applications and nodes. If the source code is written in a protocol-independent way, without dependencies on either IPv4 or IPv6, applications will be able to communicate with any combination of applications and types of nodes. Implementations typically by-default prefer IPv6 if the remote node and application support it. However, if IPv6 connections fail, dual applications will automatically try IPv4 ones. The resolver returns a list of valid addresses for the remote node and applications can iterate through all, first trying IPv6 ones, until connection succeeds. Applications writers should be aware of this typical by-default ordering, but the applications themselves typically need not be aware of the the local protocol ordering [RFC 3484]. + If the source code is written in a protocol-dependent way, the + application will suport IPv4 and IPv6 explicitly using 2 separate + sockets. Note that there are some differences in bind() + implementation, whether you can first bind to the IPv6 wildcard + address, and then the IPv4. It can be a pain to write applications + that cope with this. If IPV6_V6ONLY is implemented, this becomes + simpler. The reason the IPv4 wildcard bind fails on some systems is + that the IPv4 address space is embedded into IPv6 address space + when using IPv4-mapped IPv6 addresses. + A more detailed porting guideline is described in section 6. 4.4. IPv4/IPv6 applications in an IPv4-only node As the transition is likely to happen over a longer timeframe, applications that have already been ported to support both IPv4 and IPv6 may be run on IPv4-only nodes. This would typically be done to avoid having to support two application versions for older and newer operating systems, or to support the case that the user wants to disable IPv6 for some reason. @@ -459,134 +505,144 @@ to exiting the socket loop, and AF_INET will not even be tried. The application will need to handle this case or build the loop in such a way that errors are ignored until the last address family. So, this case is just an extension of the IPv4/IPv6 support in the previous case, covering one relatively common but often ignored case. 5. Application porting considerations - The minimum changes in IPv4 applications to work using IPv6 are - basically based on the different size and format of IPv4 and IPv6 - addresses. + The minimum changes to IPv4 applications to work with IPv6 are + based on the different size and format of IPv4 and IPv6 addresses. Applications have been developed with the assumption they would use - IPv4 as network protocol. This assumption results in many IP + IPv4 as their network protocol. This assumption results in many IP dependencies through source code. The following list summarizes the more common IP version dependencies in applications: a) Presentation format for an IP address: it is an ASCII string which represents the IP address, dotted-decimal string for IPv4 and hexadecimal string for IPv6. b) Transport layer API: functions to establish communications and to exchange information. c) Name and address resolution: conversion functions between hostnames and IP addresses, and vice versa. d) Specific IP dependencies: more specific IP version dependencies, such as: IP address selection, application framing, storage of IP addresses. + e) Multicast applications: one must find the IPv6 equivalents to + the IPv4 multicast addresses, and use the right socket + configuration options. + In the following subsections, the problems with the aforementioned IP version dependencies are analyzed. Although application source code can be ported to IPv6 with minimum changes related to IP addresses, some recommendations are given to modify the source code in a protocol independent way, which will allow applications to work using both IPv4 and IPv6. 5.1 Presentation format for an IP address Many applications use IP addresses to identify network nodes and to establish connections to destination addresses. For instance, using the client/server model, clients usually need an IP address as an application parameter to connect to a server. This IP address is usually provided in the presentation format, as a string. There are two problems, when porting the presentation format for an IP address: the allocated memory and the management of the presentation format. Usually, the allocated memory to contain an IPv4 address - representation as string is not enough to contain an IPv6 one. - Applications should be modified to prevent from overflowing the - buffer holding the presentation format for an IP address, now - larger in IPv6. + representation as a string is unable to contain an IPv6 address. + Applications should be modified to prevent buffer overflows made + possible by the larger IPv6 address. - IPv4 and IPv6 do not use the same presentation format. IPv4 uses + IPv4 and IPv6 do not use the same presentation format. IPv4 uses a dot (.) to separate the four octets written in decimal notation and - IPv6 uses colon (:) to separate each pair of octets written in - hexadecimal notation. In order to support both, IPv4 and IPv6, the + IPv6 uses a colon (:) to separate each pair of octets written in + hexadecimal notation. In order to support both IPv4 and IPv6, the management functions of presentation format, such as IP address - parsers, should be changed to be compliant with both the formats. + parsers, should be changed to be compliant with both of the formats + [TextRep]. A particular problem with IP address parsers comes when the input - is actually a combination of IP address and port. With IPv4, these - are often coupled with a semi-colon, like "192.0.2.1:80". However, - such an approach would be ambiguous with IPv6, as semi-colons are - already used to structure the address. + is actually a combination of IP address and port number. With IPv4 + these are often coupled with a semi-colon such as "192.0.2.1:80". + However, such an approach would be ambiguous with IPv6 as colons + are already used to structure the address. Therefore, the IP address parsers which take the port number - separated with a semi-colon should represent IPv6 addresses - somehow. One way is to enclose the address in brackets, as is done - with Uniform Resource Locators (URLs) [RFC 2732], like + separated with a colon should represent IPv6 addresses somehow. + One way is to enclose the address in brackets, as is done with + Uniform Resource Locators (URLs) [RFC 2732], like http://[2001:db8::1]:80. + Prefix/len format should be also considered if surrounding brackets + are used. In order to avoid ambiguity, the format, like + [2001:db8::]/64 is recommended. + In some specific cases, it may be necessary to give a zone identifier as part of the address, like fe80::1%eth0. In general, applications should not need to parse these identifiers. The IP address parsers should support enclosing the IPv6 address in brackets even when it's not used in conjunction with a port number, but requiring that the user always gives a literal IP address enclosed in brackets is not recommended. + There is an another consideration on IPv6 address literals in SMTP + commands [RFC 2821], i.e., [IPv6: 2001:db8::1]. + Note that the use of address literals is strongly discouraged for general purpose direct input to the applications; host names and DNS should be used instead. 5.2 Transport layer API Communication applications often include a transport module that - establishes communications. Usually, this module manages everything + establishes communications. Usually this module manages everything related to communications and uses a transport layer API, typically - as a network library. When porting an application to IPv6 most - changes should be made in this application transport module, in + as a network library. When porting an application to IPv6, most + changes should be made in this application transport module in order to be adapted to the new IPv6 API. In the general case, porting an existing application to IPv6 - requires to examine the following issues related to the API: + requires an examination of the following issues related to the API: - Network information storage: IP address data structures. The new structures must contain 128-bit IP addresses. The use of generic address structures, which can store any address family, is recommended. Sometimes special addresses are hard-coded in the application source; developers should pay attention to them in order to use the new address format. Some of these special IP addresses are: wildcard local, loopback and broadcast. IPv6 does not have the broadcast addresses, so applications can use multicast instead. - Address conversion functions. The address conversion functions convert the binary address representation to the presentation format and vice versa. The new conversion functions are specified to the IPv6 address format. - Communication API functions. These functions manage communications. Their signatures are - defined based on generic socket address structure. Then, the - same functions are valid for IPv6. However, the IP address data + defined based on a generic socket address structure. The + same functions are valid for IPv6, however, the IP address data structures used when calling these functions require the updates. - Network configuration options. They are used when configuring different communication models for Input/Output (I/O) operations (blocking/nonblocking, I/O multiplexing, etc) and should be translated to the IPv6 ones. 5.3 Name and address resolution @@ -594,33 +650,32 @@ is a system-independent process. An application calls functions in a system library, the resolver, which is linked into the application when this is built. However, these functions use IP address structures, which are protocol dependent, and must be reviewed to support the new IPv6 resolution calls. There are two basic resolution functions. The first function returns a list of all configured IP addresses for a hostname. These queries can be constrained to one protocol family, for instance only IPv4 or only IPv6 addresses. However, the recommendation is - that all configured IP addresses should be got to allow - applications to work to every kind of node. And the second function - returns the hostname associated to an IP address. - -5.4. Specific IP dependencies + that all configured IP addresses should be obtained to allow + applications to work with every kind of node. And the second + function returns the hostname associated to an IP address. 5.4.1 IP address selection - IPv6 promotes the configuration from multiple IP addresses per - node, which is a different model of IPv4; however applications only - use a destination/source pair for a communication. Choosing the - right IP source and destination addresses is a key factor that may - determine the route of IP datagrams. + IPv6 promotes the configuration of multiple IP addresses per node, + which is a difference when compared with the IPv4 model; however + applications only use a destination/source pair for a + communication. Choosing the right IP source and destination + addresses is a key factor that may determine the route of IP + datagrams. Typically nodes, not applications, automatically solve the source address selection. A node will choose the source address for a communication following some rules of best choice, [RFC 3484], but also allowing applications to make changes in the ordering rules. When selecting the destination address, applications usually ask a resolver for the destination IP address. The resolver returns a set of valid IP addresses from a hostname. Unless applications have a specific reason to select any particular destination address, they @@ -631,75 +686,120 @@ The Application Level Framing (ALF) architecture controls mechanisms that traditionally fall within the transport layer. Applications implementing ALF are often responsible for packetizing data into Application Data Units (ADUs). The application problem when using ALF is the ADU size selection to obtain better performance. Application framing is typically needed by applications using connectionless protocols (such as UDP). The application will have - to know, or be able to detect, what are the packet sizes which can - be sent and received, end-to-end, on the network. + to know, or be able to detect, the packet sizes which can be sent + and received, end-to-end, on the network. - Applications can use 1280 octets as data length. [RFC 2460] - specifies IPv6 requires that every link in the Internet have an - Maximum Transmission Unit (MTU) of 1280 octets or greater. However, - in order to get better performance ADU size should be calculated - based on the length of transmission unit of underlying protocols. + Applications can use 1280 octets as a data length. [RFC 2460] + specifies an IPv6 requirement that every link in the Internet have + a Maximum Transmission Unit (MTU) of 1280 octets or greater. + However, in order to get better performance, ADU size should be + calculated based on the length of transmission unit of underlying + protocols. FIXME: Application framing has relations e.g. with Path MTU Discovery and application design which need to be analyzed better. 5.4.3 Storage of IP addresses Some applications store IP addresses as information of remote peers. For instance, one of the most popular ways to register remote nodes in collaborative applications is based on using IP addresses as registry keys. Although the source code that stores IP addresses can be modified to IPv6 following the previous basic porting recommendations, there are some reasons why applications should not store IP addresses: - - IP addresses can change throughout the time, for instance + - IP addresses can change throughout time, for instance after a renumbering process. - The same node can reach a destination host using different IP addresses. - Instead of using IP addresses, applications should use FQDNs. - Hence, applications delegate the resolution of the IP addresses to - the name resolution system, which will return the associated IP - address at the moment of the query. + When possible, applications should store names, such as FQDNs, + instead of storing addresses. In this case applications are only + bound to specific addresses at run time, or for the duration of a + cache lifetime. Other types of applications, such as massive peer + to peer systems with their own rendez-vous and discovery + mechanisms, may need to cache addresses for performance reasons, + but cached addresses should not be treated as permanent, reliable + information. In highly dynamic networks any form of name + resolution may be impossible, and here again addresses must be + cached. + +5.5 Multicast applications + + There is an additional problem in porting multicast applications. + When using multicast facilities some changes must be carried out to + support IPv6. First, applications must change the IPv4 multicast + addresses to IPv6 ones, and second, the socket configuration + options must be changed. + + All the IPv6 multicast addresses encode scope; the scope was only + implicit in IPv4 (with multicast groups in 239/8). Also, while a + large number of application-specific multicast addresses have been + assigned with IPv4, this has been (luckily enough) avoided in IPv6. + So, there are no direct equivalents for all the multicast + addresses. For link-local multicast, it's possible to pick almost + anything within the link-local scope. The global groups could use + unicast-prefix-based addresses [RFC 3306]. All in all, this may + force the application developers to write more protocol dependent + code. + + Another problem is/has been that IPv6 multicast does not yet have a + standardized mechanism for traditional Any Source Multicast for + Interdomain multicast. The models for Any Source Multicast (ASM) + or Source-Specific Multicast (SSM) are generally similar between + IPv4 and IPv6, but it is likely that PIM-SSM will become more + widely deployed in IPv6 due to its simpler architecture. + + So, it might be beneficial to port the applications to use SSM + semantics, requiring off-band source discovery mechanisms and the + use of a different API [RFC 3678]. Inter-domain ASM service is + available only through a method embedding the Rendezvous Point + address in the multicast address [Embed-RP]. + + Another generic problem for multiparty conferencing applications, + which is similar to the issues with peer-to-peer applications, is + that all the users of the session must use the same protocol + version (IPv4 or IPv6), or some form of proxies or translators must + be used (e.g., [MUL-GW]). 6. Developing IP version-independent applications As we have seen before, dual applications working with both IPv4 and IPv6 are recommended. These applications should avoid IP - dependencies in the source code. However if IP dependencies are + dependencies in the source code. However, if IP dependencies are required, one of the best solutions is based on building a communication library which provides an IP version independent API to applications and hides all dependencies. In order to develop IP version independent applications, the following guidelines should be considered. 6.1 IP version-independent structures All of the memory structures and APIs should be IP version- independent. In that sense, one should avoid structs in_addr, in6_addr, sockaddr_in and sockaddr_in6. Suppose you pass a network address to some function, foo(). If you - use struct in_addr or struct in6_addr, you will end up with extra - parameter to indicate address family, as below: + use struct in_addr or struct in6_addr, you will end up with an + extra parameter to indicate address family, as below: struct in_addr in4addr; struct in6_addr in6addr; /* IPv4 case */ foo(&in4addr, AF_INET); /* IPv6 case */ foo(&in6addr, AF_INET6); However, this leads to duplicated code and having to consider each scenario from both perspectives independently; this is difficult to @@ -1016,35 +1117,46 @@ 7. Transition mechanism considerations A mechanism, [NAT-PT], introduces a special set of addresses, formed of NAT-PT prefix and an IPv4 address; this refers to IPv4 addresses, translated by NAT-PT DNS-ALG. In some cases, one might be tempted to handle these differently. However, IPv6 applications must not be required to distinguish "normal" and "NAT-PT translated" addresses (or any other kind of - special addresses, including the IPv6-mapped IPv4-addresses): that + special addresses, including the IPv4-mapped IPv6-addresses): that would be completely unscalable, and if such distinction must be made, it must be done elsewhere (e.g. kernel, system libraries). 8. Security considerations - TBD. + A number of transition mechananisms define ways of constructing + IPv6 adddresses using IPv4 addresses. There are a number of kinds + of IPv4 addresses that require careful treatment due to know + security issues [TRANSEC]. One particular point about application transition is how IPv4- mapped IPv6-addresses are handled. The use in the API can be seen as both a merit (easier application transition) and as a burden (difficulty in ensuring whether the use was legimate) [V6MAPPED]. This may have to be considered in more detail. -9. References +9. Acknowledgements + + We would like to thank the members of the the v6ops working group + and the application area for helpful comments. Special thanks are + due to Brian E. Carpenter, Antonio Querubin, Stig Venaas, and + Chirayu Patel for extensive review of this document. We acknowledge + Ron Pike for proofreading the document. + +10. References Normative References [RFC 3493] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket Interface Extensions for IPv6," RFC 3493, February 2003. [RFC 3542] W. Stevens, M. Thomas, E. Nordmark, T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6," RFC 3542, May 2003. @@ -1065,20 +1177,27 @@ (IPv6) Specification,", RFC 2460, December 1998. [RFC 3484] R. Draves, "Default Address Selection for IPv6," RFC 3484, February 2003. Informative References [RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal IPv6 Addresses in URL's," RFC 2732, December 1999. + [RFC 2821] J. Klensin, "Simple Mail Transfer Protocol," RFC 2821, + April 2001. + + [TextRep] A. Main, "Textual Representation of IPv4 and IPv6 + Addresses," , Oct 2003, + Work in Progress. + [NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)," RFC 2766, February 2000. [DNSTRANS] A. Durand, J. Ihren, "DNS IPv6 transport operational guidelines," , June 2003, Work in Progress. [DNSOPV6] A. Durand, J. Ihren, P. Savola, "Operational Considerations and Issues with IPv6 DNS," , November 2003, Work in Progress. @@ -1089,28 +1208,46 @@ [V6MAPPED] Jun-ichiro itojun Hagino, "IPv4 mapped address considered harmful", , Apr 2002, Work in Progress. [IP-GGF] T. Chown, J. Bound, S. Jiang, P. O'Hanlon, "Guidelines for IP version independence in GGF specifications," Global Grid Forum(GGF) Documentation, September 2003, Work in Progress. + [Embed-RP] P. Savola, B. Haberman, "Embedding the Address of RP in + IPv6 Multicast Address," , October 2003, Work in Progress. + + [RFC 3306] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 + Multicast Addresses," RFC 3306, August 2002. + + [RFC 3678] D. Thaler, B. Fenner, B. Quinn, "Socket Interface + Extensions for Multicast Source Filters, RFC 3678, January + 2004. + + [MUL-GW] S. Venaas, "An IPv4 - IPv6 multicast gateway," , February 2003, + Work in Progress. + + [TRANSEC] R. Austein, "IPv6 transition security - problem + statement from a workshop that never happened," + a message on v6ops@ops.ietf.org list on 13 Aug 2003. + Authors' addresses Myung-Ki Shin ETRI PEC 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea Tel : +82 42 860 4847 Fax : +82 42 861 5404 E-mail : mkshin@pec.etri.re.kr - Yong-Guen Hong ETRI PEC 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea Tel : +82 42 860 6447 Fax : +82 42 861 5404 E-mail : yghong@pec.etri.re.kr Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., @@ -1120,20 +1257,23 @@ Fax: +81-3-5259-6351 E-mail: itojun@iijlab.net Pekka Savola CSC/FUNET Espoo, Finland E-mail: psavola@funet.fi Eva M. Castro Rey Juan Carlos University (URJC) + Departamento de Informatica, Estadistica y Telematica + C/Tulipan s/n + 28933 Madrid - SPAIN E-mail : eva@gsyc.escet.urjc.es Appendix A. Binary/presentation format conversions The following functions convert network address structure in its presentation address format and vice versa: inet_ntop() inet_pton()