[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-v6ops-application-transition

INTERNET DRAFT                                             Myung-Ki Shin
Expires: April 2003                                       Yong-Guen Hong
                                                                    ETRI
                                                Jun-ichiro itojun HAGINO
                                                                     IIJ
                                                            Pekka Savola
                                                               CSC/FUNET
                                                            October 2002


                 Application Aspects of IPv6 Transition
            <draft-shin-v6ops-application-transition-00.txt>


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.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsolete by other documents
     at anytime. It is inappropriate to use Internet Drafts as reference
     material or to cite them other than as "work in progress."

     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

     The document specifies application aspects of IPv6 transition. As
     IPv6 is deployed, the application developers and the administrators
     will face several problems.  This draft clarifies the problems
     occurring in transition period between IPv4 applications and IPv6
     applications. It also proposes guidelines that help application
     developers understand how to develop IP version-independent
     applications during the transition period.


Table of Contents:

     1. Introduction .............................................. 2
     1.1 Terminology .............................................. 3
     2. Overview of IPv6 application transition ................... 3
     3. Problems with IPv6 application transition ................. 4




Shin et al.                Expires April 2003                   [Page 1]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


     3.1 Dual stack vs. application versions ...................... 4
     3.2  DNS name resolution ..................................... 4
     3.3  Application selection ................................... 4
     4. Description of the guidelines ............................. 5
     4.1 IPv4 applications in a dual stack node ................... 5
     4.2 Separate IPv4 and IPv6 applications in a dual stack node . 6
     4.3 IPv4/IPv6 applications in a dual stack node .............. 6
     4.4 IPv4/IPv6 applications in an IPv4-only node .............. 7
     5. Transition mechanism considerations ....................... 8
     6. Open Issues ............................................... 8
     7. Security considerations ................................... 8
     8. Acknowledgments ........................................... 8
     9. References ................................................ 8
     Appendix .................................................... 10
     Authors' Addresses .......................................... 14


1. Introduction

     As IPv6 is introduced in the IPv4-based Internet, several general
     issues when starting to use IPv6 in a predominant IPv4 world are
     being discussed, such as IPv6 routing, IPv6 addressing, DNS issues,
     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 studied in [TRANS-MECH] and
     [Routing]. In addition, various kinds of transition mechanisms have
     been developed to migrate to IPv6 network ([NAT-PT], [SIIT],
     [6to4], [DSTM], etc.) However, even if these mechanisms are fully
     deployed, we still have problems occuring in the transition period
     between IPv4 applications and IPv6 applications.

     This document specifies application aspects of IPv6 transition. As
     IPv6 networks are deployed and the network transition discussed, we
     should also consider IPv6 application transition in a node.

     [BIS] and [BIA] have been proposed as short-term solutions, but
     these mechanisms SHOULD NOT be used when the application-specific
     source code is available. Ultimately, application developers will
     modify application programs to support both IPv4 and IPv6 (IP
     version-independent program). During the transition period,
     administrators may have various versions of an application (IPv4-
     only, IPv6-only or one supporting both IPv4 and IPv6) in a node.

     This draft clarifies the problems occurring in the transition
     period between IPv4 applications and IPv6 applications. It also
     proposes guidelines that help application developers understand how
     to develop IP version-independent applications during transition
     the period.






Shin et al.                Expires April 2003                   [Page 2]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


1.1 Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
     this document are to be interpreted as described in RFC 2119 [RFC
     2119].


2. Overview of IPv6 application transition

     The transition of an application can be classifed as follows:

      +-------------------+
      |       appv4       | (appv4 - IPv4-only applications)
      +-------------------+
      |     TCP / UDP     |
      +-------------------+
      |    IPv4 | IPv6    |
      +-------------------+
      Case 1. IPv4 applications in a dual stack node

      +-------------------+
      |  appv4  |  appv6  | (appv6 - IPv6-only applications)
      +-------------------+
      |     TCP / UDP     |
      +-------------------+
      |    IPv4 | IPv6    |
      +-------------------+
      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     |
      +-------------------+
      |    IPv4 | IPv6    |
      +-------------------+
      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     |
      +-------------------+
      |       IPv4        |
      +-------------------+
      Case 4. Applications supporting both IPv4 and IPv6
              in an IPv4-only node

        Figure 1. Overview of IPv6 Application Transition




Shin et al.                Expires April 2003                   [Page 3]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


     Figure 1 shows the cases of IPv6 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).

      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 to ease support, the same applications may also
               have to work when IPv6 is not used.



3. Problems with IPv6 application transition

     As IPv6 is deployed, the application developers and the
     administrators will face several problems.


3.1 Dual stack vs. application versions

     Considering the cases above, IPv4 and IPv6 protocol stack in a node
     is likely to co-exist for a long time. During this period,
     applications are expected to be able to handle IPv6 over some time
     period, not at the same time as IPv6 protocol is introduced.  That
     is, operating system being dual stack does not mean having both
     IPv4 and IPv6 applications. Therefore, application introduction 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 IPv4-only nodes (whether IPv6 protocol
     is completely disabled or there is no IPv6 connectivity at all).


3.2 DNS name resolution

     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
     IPv4 transport, even though IPv6 addresses are being resolved, or




Shin et al.                Expires April 2003                   [Page 4]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


     using IPv6 transport. This issue has been already discussed in
     [DNS].

     The issue of DNS name resolving related to application transition
     is that a client application can not know 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 a
     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).

     It is bad practise to add an AAAA record for node that does not
     support all the services using IPv6 (rather, a AAAA record for the
     specific service name and address should be used), but the
     application cannot depend on "good practise", and this must be
     handled.

     In consequence, the application has to try both protocol versions,
     and if the first to try fails, detect the failure and try using the
     other protocol version.


3.3 Application selection

     During the application transition period, system administrators may
     have various versions of the same application (an IPv4-only
     application, an IPv6-only application, or an application supporting
     both IPv4 and IPv6). Therefore, the users may be confused by their
     various application versions, because they don't know the version
     of peer application by DNS query results.

     To avoid problems with mismatching DNS query results, it is
     desirable to have hybrid applications, supporting both protocol
     versions. 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 (these kind of "wrapper applications" only work for
     certain kinds of, usually simple, applications).  Nonetheless,
     there should be some reasonable logic on how to perform application
     selection.


4. Description of the guidelines

4.1 IPv4 applications in a dual-stack node

     This scenario happens if IPv6 protocol is added in a node but
     IPv6-capable applications aren't yet available or installed.

     In order to allow an application to communicate with other IPv6




Shin et al.                Expires April 2003                   [Page 5]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


     nodes, the first priority is to convert the applications to use
     IPv6.  In some cases (e.g. no source code), one may have to manage
     with existing IPv4 applications: then [BIA] can be installed in the
     node.

     The main difference between [BIS] and [BIA] is that while [BIS] is
     for systems with no IPv6 stack, [BIA] is for systems with an IPv6
     stack. However, [BIA] SHOULD NOT be used only when an application
     source code is available to prevent the mis-use of [BIA], for
     example, an excuse not to port software.

     Considering the applicability of [BIA], it's good for early
     adopters who do not have all applications handy, but not for
     mainstream production usage.

     A client application running [BIA] may have the issues mentioned in
     section 3.1 and 3.2.  That is, if a client node running BIA tries
     to contact a dual stack node on a port number that is only
     associated to an IPv4 application, the attempt will fail.

     In order to solve the problem, there are 2 approaches. It may very
     well be application dependent.

      1 - the client node should cycle through all the addresses and
          end up trying the IPv4 one.
          getaddrinfo() returns a list of addresses (tokens) to the
          application that cycles through the list.

      2 - BIA SHOULD do the work.


4.2 Separate IPv4 and IPv6 applications in a dual-stack node

     As applications are converted to IPv6-only, there can be two same
     applications with different protocol versions (e.g., ping and
     ping6).

     In fact, this transition case is undesirable (the best solution is
     to go to case 3), but IPv6-only applications will exist for several
     reasons (it is easy to modify, early version of an IPv6
     application, etc.).  In this case, there are two same applications
     with different names (possibly attached with '6'). Simple
     application selection rule is as follows :

      rule 1 - default application selection is the application
               for IPv6, only if IPv6 connectivity is provided.

      rule 2 - if it fails, then the IPv4 application is tried.

     IPv6-only application programs can be converted easily from the
     existing same IPv4 applications by means of one-to-one API mapping.
     For examples, IPv6-only applications will be implemented using




Shin et al.                Expires April 2003                   [Page 6]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


     gethostbyname2(), getipnodebyname(), or getaddrinfo(), instead of
     gethostbyname() for IPv4. Note that with getipnodebyname() or
     gethostbyname2(), scoped IPv6 addresses can't be supported.  See
     the appendix for more information.


4.3 IPv4/IPv6 applications in a dual stack node

     As applications are ported for both IPv4 and IPv6 support, the
     existing IPv4 applications are removed.

     This transition case is advisable. During IPv6 transition periods,
     applications supporting both IPv4 and IPv6 should be able to
     communicate with an application in a node irrespective of the
     versions of the protocol stack or the application in the node with
     the node name. The applications assume that a node, which the
     application wants to communicate with, can have various
     combinations of the protocol stacks and the applicaions. Under this
     assumption, the applications supporting both IPv4 and IPv6 SHOULD
     be ported to do the iterated job, which tries to create the
     connection with the node iteratively through all results from DNS
     queries.

     Ultimately, a well-behaved application should be able to
     communicate with a peer application in another node even though
     they don't know which type of application is supported in the node.
     For this, the application developers SHOULD do iterated jobs for
     finding the working address used by the other application out of
     addresses returned by the API, getaddrinfo() which supports the
     IPv4 and IPv6 DNS query results simultaneously (see Appendix).


4.4. IPv4/IPv6 applications in an IPv4-only node

     As the transition is likely to happen over a longer timeframe, the
     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.

     Depending on how application/operating system support is done, some
     may want to ignore this case, but usually no assumptions can be
     made and applications should work in this scenario too.

     An example is an application that issues a socket() command, first
     trying AF_INET6 and then AF_INET.  However, if the kernel does not
     have IPv6 support, the call will result in a EPROTONOSUPPORT or
     EAFNOSUPPORT error.  Typically, if errors are encountered, this
     leads 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




Shin et al.                Expires April 2003                   [Page 7]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


     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. Transition mechanism considerations

     Under [NAT-PT] mechanism, a pair of IPv6-only and IPv4-only
     applications could be enough but one should note one special case
     (NAT-PT prefix + IPv4 address) which one might be tempted to handle
     differently.  This is an IPv4 addresses, translated by NAT-PT DNS
     ALG [DNS-ALG].  IPv6 applications, in general, MUST NOT be required
     to distinguish "normal" and "NAT-PT translated" addresses:  that
     woould be completely unscalable, and if such distinction must be
     made, it must be done elsewhere (e.g. kernel, system libraries).


6. Open Issues

     Some, perhaps even all, RFC2119 keywords may have to be changed as
     this has not been intended as a normative reference.

     Examples should be replaced by very short working applications, as
     they are incomplete and difficult to understand.

     Should there be a case for IPv6-only nodes (note: this adds very
     little new if AF_INET6 is always tried first in hybrid apps).


7. Security considerations

     See the each security consideration section listed in section 9 -
     References.

     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.


8. Acknowledgments

     Authors would like to acknowledge the idea sharing contributions by
     Erik Nordmark (nordmark@sun.com).


9. References

 Normative References




Shin et al.                Expires April 2003                   [Page 8]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


 [NAT-PT]    Tsirtsis, G. and P. Srisuresh, "Network Address
             Translation - Protocol Translation (NAT-PT)", RFC 2766,
             February 2000.

 [SIIT]      Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC
             2765, February 2000.

 [6to4]      B. Carpenter, K. Moore, "Connection of IPv6 Domains via
             IPv4 Clouds", RFC 3056, February 2001

 [DSTM]      Jim Bound et al., Dual Stack Transition Mechanism (DSTM),
             <draft-ietf-ngtrans-dstm-08.txt>, July 2001,
              Work in Progress.

 [BIS]       K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts
             using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767,
             February 2000.

 [BIA]       Seungyun Lee et al, "Dual Stack Hosts using "Bump-in-the
             -API" (BIA)", RFC 3338, October 2002.

 [SOCK-EXT]  R. Gilligan, S. Thomson, J. Bound and W. Stevens, "Basic
             Socket Interface Extensions for IPv6", RFC2553, March
             1999.

 [RFC 2119]   Bradner S., Key words for use in RFCs to indicate
              Requirement Levels, RFC 2119, March 1997.


 Informative References

 [TANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
             IPv6 Hosts and Routers", RFC 2893, August 2000.

 [Routing]   R. Callon, D. Haskin, "Routing Aspects Of IPv6
             Transition", RFC 2185, September 1997.

 [DEFAULT]   Richard Draves, "Default Address Selection for IPv6",
             <draft-ietf-ipngwg-default-addr-select-06.txt>, September,
             2001, Work in Progress.

 [DNS-ALG]   A. Durand, "Issues with NAT-PT DNS ALG in RFC2766",
             <draft-durand-natpt-dns-alg-issues-00.txt>,
             February 2002, Work in Progress.

 [DNS]       A. Durand, J. Ihren, "NGtrans IPv6 DNS operational requir-
             ements and roadmap", <draft-ietf-ngtrans-dns-ops-req-
             04.txt>, March, 2002, Work in Progress.

 [Y2K-SOFT]  Erik Nordmark, "IPv6: Another Y2K for Software",
             IPv4 to IPv6 Migration, IPv6 Summit, September 2001.





Shin et al.                Expires April 2003                   [Page 9]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


 [PORT-NET]  Sun Microsystem, Inc. "Porting Networking Application
             to the IPv6 APIs, Solaris Version 8", 2001.

 [AF-APP]    Jun-ichiro itojun Itoh, "Implementing AF-independent
             application", http://www.kame.net/newsletter/19980604/,
             2001.

 [V6MAPPED]  Jun-ichiro itojun Hagino, "IPv4 mapped address
             considered harmful", <draft-itojun-v6ops-v4mapped-
             harmful-00.txt>, work-in-progress, Apr 2002.




Appendix

     Implementing an application supporting both IPv4 and IPv6 ([Y2K-
     SOFT],[PORT-NET] and [AF-APP]).

      Rule 1 - Modifying codes to support both IPv4 and IPv6.
               so called, AF-independent code.

      1. Avoid IPv4-only or IPv6-only structures and APIs.

       o IPv4-only and IPv6-only structures
          IPv4                 IPv6
        -----------------------------------------
         AF_INET/PF_INET      AF_INET6/PF_INET6
         AF_INET              AF_INET6
         struct sockaddr_in   struct sockaddr_in6
         struct in_addr       struct in6_addr

       o IPv4-only and IPv6-only APIs
          IPv4                IPv6
        ---------------------------------------
          gethostbyname()     getipnodebyname()
          gethostbyaddr()     getipnodebyaddr()
          inet_addr()         inet_pton()
          inet_ntoa()         inet_ntop()

      2. Instead, use structures and APIs supporting both
         IPv4 and IPv6.

       o struct sockaddr_storage
           (Note: when porting software, one should be aware that
            some systems have "ss_len" member in the structure while
            others do not; there will be clarifications on this.)

       o getaddrinfo() and getnameinfo()


      Rule 2 - Trying all addresses for finding working address.




Shin et al.                Expires April 2003                  [Page 10]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


      1. Compare operation sequences.

      2. Do iterated jobs ('for' or 'while' statement) for finding
         the working address used by the other application out of
         addresses returned by the getaddrinfo().


      <Examples of client codes>

      Example 1 (IPv4-only client code) and example 2 (IPv6-only
      client code) should be modified to example 3.

      o example 1 (IPv4-only client code)

      int myconnect(char *hostname, int port)
      {
       sock = socket(AF_INET, SOCK_STREAM, 0);
       if (sock == -1)
       { /* Handle errors */  }
       hp = gethostbyname(hostname);
        if (hp == NULL || hp->h_addrtype != AF_INET
            || hp->h_length != 4)
       { /* Handle errors */  }
       sin.sin_family = AF_INET;
       sin.sin_port = htons(port);
       (void) memcpy((void *)&sin.sin_addr,
                   (void *)hp->h_addr, hp->h_length);
       sock = socket(AF_INET, SOCK_STREAM, 0);
       if (sock == -1)
        { /* Handle errors */  }
       if (connect(sock, (struct sockaddr *)&sin,
            sizeof (sin)) == -1)
         { /* Handle errors */  }
       return (sock);
      }

      o example 2 (IPv6-only client code)

      int myconnect2(char *hostname, int port)
      {
       sock = socket(AF_INET6, SOCK_STREAM, 0);
       if (sock == -1)
       { /* Handle errors */  }
       hp = getipnodebyname(hostname, AF_INET6,
                          AI_DEFAULT, &errnum);
       if (hp == NULL)
          { /* Handle errors */  }
       bzero(&sin, sizeof (sin));
       sin.sin6_family = hp->h_addrtype;
       sin.sin6_port = htons(port);
       (void) memcpy((void *)&sin.sin6_addr,
                   (void *)hp->h_addr, hp->h_length);




Shin et al.                Expires April 2003                  [Page 11]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


       freehostent(hp);
       if (connect(sock, (struct sockaddr *)&sin,
                         sizeof (sin)) == -1)
         { /* Handle errors */  }
       return (sock);
      }

      o example 3 (client code supporting both IPv4 and IPv6)

      int myconnect3(char *hostname, char *servicename)
       {
       /* Get host address. Any type of address will do. */
        bzero(&hints, sizeof (hints));
        hints.ai_socktype = SOCK_STREAM;
        error = getaddrinfo(hostname, servicename,
                           &hints, &res);
        if (error != 0)          { /* Handle errors */  }
        /* Try all returned addresses until one works */
        for (aip = res; aip != NULL; aip = aip->ai_next) {
          sock = socket(aip->ai_family, aip->ai_socktype,
               aip->ai_protocol);
          if (sock == -1)
          { /* Handle errors: in particular, note case 4.4 */; }
        if (connect(sock, aip->ai_addr,
                   aip->ai_addrlen) == -1)
          { /* Handle errors */; continue; }
        break;
         }
        return (sock);
       }

      <Examples of server codes>

       As well, example 4 IPv4-only server code) and example 5
       (IPv6-only server code) should be modified to example 6.

      o example 4 (IPv4-only server code)

      int myserver(int port)
      {
       laddr.sin_family = AF_INET;
       laddr.sin_port = htons(port);
       laddr.sin_addr.s_addr = INADDR_ANY;
       sock = socket(AF_INET, SOCK_STREAM, 0);
       if (sock == -1)
       { /* Handle errors */  }
       sock_opt = 1;
       if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR,
               (void *)&sock_opt, sizeof
       (sock_opt)) == -1)
       { /* Handle errors */  }
       if (bind(sock, (struct sockaddr *)&laddr,




Shin et al.                Expires April 2003                  [Page 12]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


                   sizeof (laddr)) == -1)
       { /* Handle errors */  }
       if (listen(sock, BACKLOG) == -1)
       { /* Handle errors */  }
       for (;;) {
        faddrlen = sizeof (faddr);
        new_sock = accept(sock, (struct sockaddr *)&faddr,
                       &faddrlen);
        if (new_sock == -1) {
         if (errno != EINTR && errno != ECONNABORTED)
           { /* Handle errors */  }
         continue;
        }
       inet_ntoa(faddr.sin_addr),
                ntohs(faddr.sin_port));
       do_work(new_sock);/* do some work */
       }
      }

      o example 5 (IPv6-only server code)

      int myserver2(int port)
      {
       bzero(&laddr, sizeof (laddr));
       laddr.sin6_family = AF_INET6;
       laddr.sin6_port = htons(port);
       laddr.sin6_addr = in6addr_any;
         /* structure assignment */
       sock = socket(AF_INET6, SOCK_STREAM, 0);
       if (sock == -1)
       { /* Handle errors */  }
        sock_opt = 1;
       if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR,
               (void *)&sock_opt, sizeof
               (sock_opt)) == -1)
        { /* Handle errors */  }
       if (bind(sock, (struct sockaddr *)&laddr,
         sizeof (laddr)) == -1)
        { /* Handle errors */  }
       if (listen(sock, BACKLOG) == -1)
        { /* Handle errors */  }
       for (;;) {
        faddrlen = sizeof (faddr);
        new_sock = accept(sock, (struct sockaddr *)&faddr,
                           &faddrlen);
       if (new_sock == -1) {
         if (errno != EINTR && errno != ECONNABORTED)
           { /* Handle errors */  }
         continue;
        }
        do_work(new_sock);/* do some work */
       }




Shin et al.                Expires April 2003                  [Page 13]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


      }

      o example 6 (server code supporting both IPv4 and IPv6)

      int myserver3(char *servicename)
      {
       struct sockaddr_storage faddr;
       /* Set up a socket to listen on for connections. */
       bzero(&hints, sizeof (hints));
       hints.ai_flags = AI_PASSIVE;
       hints.ai_socktype = SOCK_STREAM;
       error = getaddrinfo(NULL, servicename,
                      &hints, &aip);
       if (error != 0)
       { /* Handle errors */  }
       sock = socket(aip->ai_family, aip->ai_socktype,
                      aip->ai_protocol);
       if (sock == -1)
       { /* Handle errors: in particular, note case 4.4 */  }
        sock_opt = 1;
       if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR,
              (void *)&sock_opt,
        sizeof (sock_opt)) == -1)
        { /* Handle errors */  }
       if (bind(sock, aip->ai_addr, aip->ai_addrlen) == -1)
        { /* Handle errors */  }
       if (listen(sock, BACKLOG) == -1)
        { /* Handle errors */  }
       for (;;) {
        new_sock = accept(sock, (struct sockaddr *)&faddr,
                        &faddrlen);
       if (new_sock == -1) {
         if (errno != EINTR && errno != ECONNABORTED)
           { /* Handle errors */  }
         continue;
         }
       do_work(new_sock);/* do some work */
       }
      }



Authors' Addresses
  Myung-Ki Shin
  ETRI PEC
  161 Kajong-Dong, Yusong-Gu, Taejon 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




Shin et al.                Expires April 2003                  [Page 14]


INTERNET-DRAFT   Application Aspects of IPv6 Transition     October 2002


  161 Kajong-Dong, Yusong-Gu, Taejon 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.,
  3-13 Kanda Nishiki-cho,
  Chiyoda-ku,Tokyo 101-0054, JAPAN
  Tel: +81-3-5259-6350
  Fax: +81-3-5259-6351
  E-mail: itojun@iijlab.net

  Pekka Savola
  CSC/FUNET
  E-mail : psavola@funet.fi







































Shin et al.                Expires April 2003                  [Page 15]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/