IPv6移行のアプリケーションの側面

英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。

日本語訳

Network Working Group                                     M-K. Shin, Ed.
Request for Comments: 4038                                     ETRI/NIST
Category: Informational                                        Y-G. Hong
                                                                    ETRI
                                                               J. Hagino
                                                                     IIJ
                                                               P. Savola
                                                               CSC/FUNET
                                                            E. M. Castro
                                                               GSYC/URJC
                                                              March 2005


                 Application Aspects of IPv6 Transition

IPv6移行のアプリケーションの側面


Status of This Memo

このメモのステータス


   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。 いかなる種類のインターネット標準も規定していません。 このメモの配布は無制限です。


Copyright Notice

著作権表示


   Copyright (C) The Internet Society (2005).

Copyright(C)The Internet Society(2005)。


Abstract

概要


   As IPv6 networks are deployed and the network transition is
   discussed, one should also consider how to enable IPv6 support in
   applications 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.

IPv6ネットワークが展開され、ネットワークの移行が議論されると、IPv6ホストで実行されているアプリケーションでIPv6サポートを有効にする方法と、アプリケーションでIPプロトコルサポートを開発するための最良の戦略も考慮する必要があります。 このドキュメントでは、アプリケーション移行のシナリオと側面について説明します。 また、移行中のIPバージョンに依存しないアプリケーションの開発方法に関するガイドラインも提案します。


















Shin, Ed., et al.            Informational                      [Page 1]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


Table of Contents

   1.  Introduction .................................................  3
   2.  Overview of IPv6 Application Transition ......................  3
   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 IP Version Will Be Used ....  6
       3.3.  Supporting Many Versions of an Application Is Difficult.  6
   4.  Description of Transition Scenarios and Guidelines ...........  7
       4.1.  IPv4 Applications in a Dual-Stack Node .................  7
       4.2.  IPv6 Applications in a Dual-Stack Node .................  8
       4.3.  IPv4/IPv6 Applications in a Dual-Stack Node ............ 11
       4.4.  IPv4/IPv6 Applications in an IPv4-only Node ............ 12
   5.  Application Porting Considerations ........................... 12
       5.1.  Presentation Format for an IP Address .................. 13
       5.2.  Transport Layer API .................................... 14
       5.3.  Name and Address Resolution ............................ 15
       5.4.  Specific IP Dependencies ............................... 16
             5.4.1.  IP Address Selection ........................... 16
             5.4.2.  Application Framing ............................ 16
             5.4.3.  Storage of IP addresses ........................ 17
       5.5.  Multicast Applications ................................. 17
   6.  Developing IP Version - Independent Applications ............. 18
       6.1.  IP Version - Independent Structures..................... 18
       6.2.  IP Version - Independent APIs........................... 19
             6.2.1.  Example of Overly Simplistic TCP Server
                     Application .................................... 20
             6.2.2.  Example of Overly Simplistic TCP Client
                     Application .................................... 21
             6.2.3.  Binary/Presentation Format Conversion .......... 22
       6.3.  Iterated Jobs for Finding the Working Address .......... 23
             6.3.1.  Example of TCP Server Application .............. 23
             6.3.2.  Example of TCP Client Application .............. 25
   7.  Transition Mechanism Considerations .......................... 26
   8.  Security Considerations ...................................... 26
   9.  Acknowledgments .............................................. 27
   10. References ................................................... 27
   Appendix A.  Other Binary/Presentation Format Conversions ........ 30
       A.1.  Binary to Presentation Using inet_ntop() ............... 30
       A.2.  Presentation to Binary Using inet_pton() ............... 31
   Authors' Addresses ............................................... 32
   Full Copyright Statement ......................................... 33
   1. はじめに............................................... .. 3
   2. IPv6アプリケーション移行の概要...................... 3
   3. IPv6アプリケーション移行の問題.................... 5
       3.1. OSおよびアプリケーションでのIPv6サポートは無関係です... 5
       3.2. DNSは使用されるIPバージョンを示しません.... 6
       3.3.アプリケーションの多くのバージョンをサポートすることは困難です. 6
   4.移行シナリオとガイドラインの説明........... 7
       4.1.デュアルスタックノードでのIPv4アプリケーション................. 7
       4.2.デュアルスタックノードのIPv6アプリケーション................. 8
       4.3.デュアルスタックノードでのIPv4 / IPv6アプリケーション............ 11
       4.4. IPv4のみのノードでのIPv4 / IPv6アプリケーション............ 12
   5.アプリケーションの移植に関する考慮事項........................... 12
       5.1. IPアドレスの表示形式..... 13
       5.2.トランスポート層API ................................................. 14
       5.3.名前とアドレスの解決............................ 15
       5.4.特定のIP依存関係............................... 16
             5.4.1. IPアドレスの選択........................... 16
             5.4.2.アプリケーションのフレーミング............................ 16
             5.4.3. IPアドレスの保存.................................. 17
       5.5.マルチキャストアプリケーション................................. 17
   6. IPバージョンの開発-独立したアプリケーション............. 18
       6.1. IPバージョン-独立した構造.................................. 18
       6.2. IPバージョン-独立したAPI ........................... 19
             6.2.1.過度に単純化したTCPサーバーの例
                     アプリケーション.................................... 20
             6.2.2.過度に単純化したTCPクライアントの例
                     アプリケーション.................................... 21
             6.2.3.バイナリ/プレゼンテーション形式の変換.......... 22
       6.3.現住所を見つけるための反復ジョブ.......... 23
             6.3.1. TCPサーバーアプリケーションの例.............. 23
             6.3.2. TCPクライアントアプリケーションの例.............. 25
   7.移行メカニズムに関する考慮事項.......................... 26
   8.セキュリティに関する考慮事項................................................ 26
   9.謝辞.............................................. 27
   10.参考資料......................................................... .... 27
   付録A.その他のバイナリ/プレゼンテーション形式の変換........ 30
       A.1. inet_ntop()を使用したバイナリからプレゼンテーションへ............... 30
       A.2. inet_pton()を使用したバイナリへのプレゼンテーション............... 31
   著者のアドレス............................................... 32
   完全な著作権表示......................................... 33









Shin, Ed., et al.            Informational                      [Page 2]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


1.  Introduction

1.はじめに


   As IPv6 is introduced in the IPv4-based Internet, several general
   issues will arise, such as routing, addressing, DNS, and scenarios.

IPv4ベースのインターネットでIPv6が導入されると、ルーティング、アドレス指定、DNS、シナリオなど、いくつかの一般的な問題が発生します。


   An important key to a successful IPv6 transition is compatibility
   with the large installed base of IPv4 hosts and routers.  This issue
   has already been extensively studied, and work is still in progress.
   [2893BIS] describes the basic transition mechanisms: dual-stack
   deployment and tunneling.  Various other kinds of mechanisms have
   been developed for the transition to an IPv6 network.  However, these
   transition mechanisms take no stance on whether applications support
   IPv6.

IPv6への移行を成功させるための重要な鍵は、IPv4ホストとルーターの大規模なインストールベースとの互換性です。 この問題はすでに広範囲にわたって研究されており、作業はまだ進行中です。 [2893BIS]は、基本的な移行メカニズムを説明します:デュアルスタック展開とトンネリング。 IPv6ネットワークへの移行のために、他にもさまざまなメカニズムが開発されています。 ただし、これらの移行メカニズムは、アプリケーションがIPv6をサポートしているかどうかについては何のスタンスもありません。


   This document specifies application aspects of IPv6 transition.  Two
   inter-related topics are covered:

このドキュメントでは、IPv6移行のアプリケーションの側面について説明します。 2つの相互に関連するトピックが含まれます。


      1. How different network transition techniques affect
         applications, and strategies for applications to support IPv6
         and IPv4.

1.さまざまなネットワーク移行技術がアプリケーションにどのように影響するか、およびアプリケーションがIPv6とIPv4をサポートするための戦略。


      2. How to develop IPv6-capable or protocol-independent
         applications ("application porting guidelines") using standard
         APIs [RFC3493][RFC3542].

2.標準のAPI [RFC3493] [RFC3542]を使用して、IPv6対応またはプロトコルに依存しないアプリケーション(「アプリケーション移植ガイドライン」)を開発する方法。


   In the context of this document, the term "application" covers all
   kinds of applications, but the focus is on those network applications
   which have been developed using relatively low-level APIs (such as
   the "C" language, using standard libraries).  Many such applications
   could be command-line driven, but that is not a requirement.

このドキュメントのコンテキストでは、「アプリケーション」という用語はすべての種類のアプリケーションをカバーしますが、焦点は比較的低レベルのAPI(「C」言語など、標準ライブラリを使用)を使用して開発されたネットワークアプリケーションです。 このようなアプリケーションの多くはコマンドラインで駆動できますが、これは必須ではありません。


   Applications will have to be modified to support IPv6 (and IPv4) by
   using one of a number of techniques described in sections 2 - 4.
   Guidelines for developing such applications are presented in sections
   5 and 6.

セクション2から4で説明されているいくつかの手法のいずれかを使用して、IPv6(およびIPv4)をサポートするようにアプリケーションを変更する必要があります。 そのようなアプリケーションを開発するためのガイドラインは、セクション5と6に示されています。


2.  Overview of IPv6 Application Transition

2. IPv6アプリケーション移行の概要


   The transition of an application can be classified by using four
   different cases (excluding the first case when there is no IPv6
   support in either the application or the operating system):

アプリケーションの遷移は、4つの異なるケースを使用して分類できます(アプリケーションまたはオペレーティングシステムのいずれかでIPv6がサポートされていない最初のケースを除く)。











Shin, Ed., et al.            Informational                      [Page 3]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


      +-------------------+
      |       appv4       | (appv4 - IPv4-only applications)
      +-------------------+
      | 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.

ケース1.デュアルスタックノードのIPv4アプリケーション。


      +-------------------+ (appv4 - IPv4-only applications)
      |  appv4  |  appv6  | (appv6 - IPv6-only applications)
      +-------------------+
      | 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.

ケース2.デュアルスタックノードのIPv4専用アプリケーションとIPv6専用アプリケーション。


      +-------------------+
      |     appv4/v6      | (appv4/v6 - applications supporting
      +-------------------+             both IPv4 and IPv6)
      | 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.

ケース3.デュアルスタックノードでIPv4とIPv6の両方をサポートするアプリケーション。


      +-------------------+
      |     appv4/v6      | (appv4/v6 - applications supporting
      +-------------------+             both IPv4 and IPv6)
      | 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.

ケース4. IPv4のみのノードでIPv4とIPv6の両方をサポートするアプリケーション。


         Figure 1. Overview of Application Transition

図1.アプリケーション移行の概要


     Figure 1 shows the cases of application transition.

図1は、アプリケーション遷移のケースを示しています。






Shin, Ed., et al.            Informational                      [Page 4]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


      Case 1:  IPv4-only applications in a dual-stack node.
               IPv6 protocol is introduced in a node, but
               applications are not yet ported to support IPv6.

ケース1:デュアルスタックノードのIPv4のみのアプリケーション。 IPv6プロトコルがノードに導入されましたが、アプリケーションはまだ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 similar applications, one for each
               protocol version (e.g., ping and ping6).

ケース2:デュアルスタックノードのIPv4専用アプリケーションとIPv6専用アプリケーション。 アプリケーションはIPv6専用に移植されます。 したがって、2つの類似したアプリケーションがあり、各プロトコルバージョンに1つ(pingと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.

ケース3:デュアルスタックノードでIPv4とIPv6の両方をサポートするアプリケーション。 アプリケーションは、IPv4とIPv6の両方のサポート用に移植されています。 したがって、既存のIPv4アプリケーションを削除できます。


      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).

ケース4:IPv4のみのノードでIPv4とIPv6の両方をサポートするアプリケーション。 アプリケーションはIPv4とIPv6の両方のサポート用に移植されていますが、IPv6が使用されていない(OSから無効にされているなど)場合にも同じアプリケーションが機能する必要があります。


   The first two cases are not interesting in the longer term; only few
   applications are inherently IPv4- or IPv6-specific, and should work
   with both protocols without having to care about which one is being
   used.

最初の2つのケースは、長期的には興味深いものではありません。 本質的にIPv4またはIPv6固有のアプリケーションはほとんどなく、どちらが使用されているかを気にする必要なく、両方のプロトコルで動作するはずです。


3.  Problems with IPv6 Application Transition

3. IPv6アプリケーションの移行に関する問題


   There are several reasons why the transition period between IPv4 and
   IPv6 applications may not be straightforward.  These issues are
   described in this section.

IPv4とIPv6アプリケーションの間の移行期間が簡単ではない理由はいくつかあります。 このセクションでは、これらの問題について説明します。


3.1.  IPv6 Support in the OS and Applications Are Unrelated

3.1。 OSおよびアプリケーションでのIPv6サポートは無関係です


   Considering the cases described in the previous section, IPv4 and
   IPv6 protocol stacks are likely to co-exist in a node for a long
   time.

前のセクションで説明したケースを考慮すると、IPv4およびIPv6プロトコルスタックは、ノード内で長期間共存する可能性があります。


   Similarly, most applications are expected to be able to handle both
   IPv4 and IPv6 during another long period.  A dual-stack operating
   system is not intended to have both IPv4 and IPv6 applications.
   Therefore, IPv6-capable application transition may be independent of
   protocol stacks in a node.

同様に、ほとんどのアプリケーションは、別の長期間にわたってIPv4とIPv6の両方を処理できることが期待されています。 デュアルスタックオペレーティングシステムは、IPv4とIPv6の両方のアプリケーションを持つことを意図していません。 したがって、IPv6対応のアプリケーション移行は、ノードのプロトコルスタックとは無関係である可能性があります。


   Applications capable of both IPv4 and IPv6 will  probably have to
   work properly in IPv4-only nodes (whether the IPv6 protocol is
   completely disabled or there is no IPv6 connectivity at all).

IPv4とIPv6の両方に対応するアプリケーションは、おそらくIPv4のみのノードで適切に動作する必要があります(IPv6プロトコルが完全に無効になっているか、IPv6接続がまったくないか)。




Shin, Ed., et al.            Informational                      [Page 5]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


3.2.  DNS Does Not Indicate Which IP Version Will Be Used

3.2。 DNSは、使用されるIPバージョンを示しません


   In a node, the DNS name resolver gathers the list of destination
   addresses.  DNS queries and responses are sent by using either IPv4
   or IPv6 to carry the queries, regardless of the protocol version of
   the data records [DNSTRANS].

ノードでは、DNS名前リゾルバーが宛先アドレスのリストを収集します。 データレコードのプロトコルバージョン[DNSTRANS]に関係なく、IPv4またはIPv6を使用してクエリを運ぶことにより、DNSクエリと応答が送信されます。


   The DNS name resolution issue related to application transition is
   that by only doing a DNS name lookup a client application can not be
   certain of the version of the peer application.  For example, if a
   server application does not support IPv6 yet but runs on a dual-stack
   machine for other IPv6 services, and this host 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 mismatch between the DNS
   query result (i.e., IPv6 addresses) and a server application version
   (i.e., IPv4).

アプリケーションの移行に関連するDNS名前解決の問題は、DNS名のルックアップを実行するだけでは、クライアントアプリケーションがピアアプリケーションのバージョンを特定できないことです。 たとえば、サーバーアプリケーションがIPv6をまだサポートしていないが、他のIPv6サービスのデュアルスタックマシンで実行されており、このホストがDNSのAAAAレコードにリストされている場合、クライアントアプリケーションはサーバーアプリケーションへの接続に失敗します。 これは、DNSクエリの結果(IPv6アドレスなど)とサーバーアプリケーションのバージョン(IPv4など)の不一致が原因です。


   Using SRV records would avoid these problems.  Unfortunately, they
   are not used widely enough to be applicable in most cases.  Hence an
   operational solution is to use "service names" in the DNS.  If a node
   offers multiple services, but only some of them over IPv6, a DNS name
   may be added for each of these services or group of services (with
   the associated A/AAAA records), not just a single name for the
   physical machine, also including the AAAA records.  However, the
   applications cannot depend on this operational practice.

SRVレコードを使用すると、これらの問題を回避できます。 残念ながら、それらはほとんどの場合に適用できるほど広く使用されていません。 したがって、運用ソリューションはDNSで「サービス名」を使用することです。 ノードが複数のサービスを提供しているが、IPv6を介してそれらの一部のみを提供している場合、物理マシンの単一の名前だけでなく、これらのサービスまたはサービスのグループごとに(関連するA / AAAAレコードとともに)DNS名を追加できます。 AAAAレコードも含まれます。 ただし、アプリケーションはこの運用慣行に依存できません。


   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.  This issue is discussed in more detail in [DNSOPV6].

アプリケーションは、アドレスファミリの制約なしにすべてのIPアドレスを要求し、DNSから返されたすべてのレコードを、有効なアドレスが見つかるまで、ある順序で試行する必要があります。 特に、アプリケーションはDNSから返されたすべてのIPバージョンを処理できる必要があります。 この問題は、[DNSOPV6]で詳細に説明されています。


3.3.  Supporting Many Versions of an Application is Difficult

3.3。 アプリケーションの多くのバージョンをサポートすることは難しい


   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).

アプリケーションの移行期間中、システム管理者は同じアプリケーション(IPv4のみのアプリケーション、IPv6のみのアプリケーション、またはIPv4と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 if multiple versions of the same application are
   available, the local users have difficulty selecting the right
   version supporting the exact IP version required.

通常、DNSルックアップを実行する前に、どのIPバージョンをサポートする必要があるかを知ることができず、返されたアドレスを試行(セクション3.2を参照)します。 したがって、同じアプリケーションの複数のバージョンが使用可能な場合、ローカルユーザーは、必要な正確なIPバージョンをサポートする適切なバージョンを選択することが困難になります。








Shin, Ed., et al.            Informational                      [Page 6]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   To avoid problems with one application not supporting the specified
   protocol version, it is desirable to have hybrid applications
   supporting both.

特定のプロトコルバージョンをサポートしていない1つのアプリケーションに関する問題を回避するには、両方をサポートするハイブリッドアプリケーションを用意することが望ましいです。


   An alternative approach for local client applications could be to
   have a "wrapper application" that performs certain tasks (such as
   figuring out which protocol version will be used) and calls the
   IPv4/IPv6-only applications as necessary.  This application would
   perform connection establishment (or similar tasks) and pass the
   opened socket to another application.  However, as applications such
   as this would have to do more than just perform a DNS lookup or
   determine the literal IP address given, they will become complex --
   likely much more so than a hybrid application.  Furthermore, writing
   "wrapping" applications that perform complex operations with IP
   addresses (such as FTP clients) might be even more challenging or
   even impossible.  In short, wrapper applications do not look like a
   robust approach for application transition.

ローカルクライアントアプリケーションの代替アプローチは、特定のタスク(使用するプロトコルバージョンの決定など)を実行し、必要に応じてIPv4 / IPv6専用アプリケーションを呼び出す「ラッパーアプリケーション」を用意することです。 このアプリケーションは、接続の確立(または同様のタスク)を実行し、開いているソケットを別のアプリケーションに渡します。 ただし、このようなアプリケーションは、DNSルックアップを実行したり、与えられたリテラルIPアドレスを決定したりするだけでなく、ハイブリッドアプリケーションよりも複雑になる可能性があります。 さらに、IPアドレス(FTPクライアントなど)で複雑な操作を実行する「ラッピング」アプリケーションを作成することは、さらに困難であるか、不可能でさえあります。 つまり、ラッパーアプリケーションは、アプリケーション移行のための堅牢なアプローチのようには見えません。


4.  Description of Transition Scenarios and Guidelines

4.移行シナリオとガイドラインの説明


   Once the IPv6 network is deployed, applications supporting IPv6 can
   use IPv6 network services to establish IPv6 connections.  However,
   upgrading every node to IPv6 at the same time is not feasible, and
   transition from IPv4 to IPv6 will be a gradual process.

IPv6ネットワークが展開されると、IPv6をサポートするアプリケーションはIPv6ネットワークサービスを使用してIPv6接続を確立できます。 ただし、すべてのノードを同時にIPv6にアップグレードすることは不可能であり、IPv4からIPv6への移行は段階的なプロセスになります。


   Dual-stack nodes provide one solution to maintaining IPv4
   compatibility in unicast communications.  In this section we will
   analyze different application transition scenarios (as introduced in
   section 2) and guidelines for maintaining interoperability between
   applications running in different types of nodes.

デュアルスタックノードは、ユニキャスト通信でIPv4互換性を維持するための1つのソリューションを提供します。 このセクションでは、さまざまなアプリケーション移行シナリオ(セクション2で紹介)と、さまざまなタイプのノードで実行されているアプリケーション間の相互運用性を維持するためのガイドラインを分析します。


   Note that the first two cases, IPv4-only and IPv6-only applications,
   are not interesting in the longer term; only few applications are
   inherently IPv4- or IPv6-specific, and should work with both
   protocols without having to care about which one is being used.

最初の2つのケース、IPv4のみのアプリケーションとIPv6のみのアプリケーションは、長期的には興味がないことに注意してください。 本質的にIPv4またはIPv6固有のアプリケーションはほとんどなく、どちらが使用されているかを気にする必要なく、両方のプロトコルで動作するはずです。


4.1.  IPv4 Applications in a Dual-Stack Node

4.1。 デュアルスタックノードのIPv4アプリケーション


   In this scenario, 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 and accept/establish connections from/to nodes
   that implement an IPv4 stack.

このシナリオでは、IPv6プロトコルがノードに追加されていますが、IPv6対応のアプリケーションはまだ利用できないか、インストールされていません。 ノードはデュアルスタックを実装しますが、IPv4アプリケーションはIPv4通信を管理し、IPv4スタックを実装するノードとの間の接続を受け入れ/確立することしかできません。


   To allow an application to communicate with other nodes using IPv6,
   the first priority is to port applications to IPv6.

アプリケーションがIPv6を使用して他のノードと通信できるようにするために、最優先事項はアプリケーションをIPv6に移植することです。






Shin, Ed., et al.            Informational                      [Page 7]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   In some cases (e.g., when no source code is available), existing IPv4
   applications can work if the Bump-in-the-Stack [BIS] or Bump-in-the-
   API [BIA] mechanism is installed in the node.  We strongly recommend
   that application developers not use these mechanisms when application
   source code is available.  Also, they should not be used as an excuse
   not to port software or to delay porting.

場合によっては(たとえば、ソースコードが利用できない場合)、Bump-in-the-Stack [BIS]またはBump-in-the-API [BIA]メカニズムがノードにインストールされている場合、既存のIPv4アプリケーションが機能することがあります。 アプリケーションのソースコードが利用可能な場合は、アプリケーション開発者がこれらのメカニズムを使用しないことを強くお勧めします。 また、ソフトウェアを移植したり、移植を遅らせたりする言い訳として使用しないでください。


   When [BIA] or [BIS] is used, the problem described in section 3.2
   arises - (the IPv4 client in a [BIS]/[BIA] node tries to connect to
   an IPv4 server in a dual stack system).  However, one can rely on the
   [BIA]/[BIS] mechanism, which should cycle through all the addresses
   instead of applications.

[BIA]または[BIS]を使用すると、セクション3.2で説明されている問題が発生します([BIS] / [BIA]ノードのIPv4クライアントがデュアルスタックシステムのIPv4サーバーに接続しようとする)。 ただし、[BIA] / [BIS]メカニズムに依存することができます。これは、アプリケーションの代わりにすべてのアドレスを循環する必要があります。


   [BIS] and [BIA] do not work with all kinds of applications - in
   particular, with applications that 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.  Therefore, these
   IPv4 temporary addresses are only valid in the node scope.

[BIS]と[BIA]は、すべての種類のアプリケーション、特にアプリケーションデータとしてIPアドレスを交換するアプリケーション(FTPなど)では機能しません。 これらのメカニズムは、IPv4一時アドレスをアプリケーションに提供し、ローカルでIPv4とIPv6通信間の変換を行います。 したがって、これらのIPv4一時アドレスはノードスコープでのみ有効です。


4.2.  IPv6 Applications in a Dual-Stack Node

4.2。 デュアルスタックノードのIPv6アプリケーション


   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 with the new IPv6 APIs with
   one-to-one mapping.  This way the application will be IPv6-only.
   This IPv6-only source code cannot work in IPv4-only nodes, so the old
   IPv4 application should be maintained in these nodes.  This
   necessitates having two similar applications working with different
   protocol versions, depending on the node they are running (e.g.,
   telnet and telnet6).  This case is undesirable, as maintaining two
   versions of the same source code per application could be difficult.
   This approach would also cause problems for users having to select
   which version of the application to use, as described in section 3.3.

前のセクションで説明したように、アプリケーションはIPv6に移植する必要があります。 IPv4アプリケーションを移植する最も簡単な方法は、古いIPv4 APIリファレンスを新しいIPv6 APIで1対1のマッピングに置き換えることです。 このようにして、アプリケーションはIPv6のみになります。 このIPv6のみのソースコードはIPv4のみのノードでは機能しないため、古いIPv4アプリケーションをこれらのノードで維持する必要があります。 これには、実行しているノード(telnetやtelnet6など)に応じて、2つの類似したアプリケーションが異なるプロトコルバージョンで動作する必要があります。 アプリケーションごとに同じソースコードの2つのバージョンを維持することは困難なため、このケースは望ましくありません。 このアプローチでは、セクション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 by using IPv4-mapped IPv6
   addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4
   address x.y.z.w.

デュアルスタックのほとんどの実装では、IPv6のみのアプリケーションをIPv4ノードとIPv6ノードの両方と相互運用できます。 デュアルスタックノード上のIPv6アプリケーションに送信されるIPv4パケットは、IPv4にマップされたIPv6アドレスを使用してアドレスがマップされるため、宛先に到達します。IPv6アドレス:: FFFF:x.y.z.wは、IPv4アドレスx.y.z.wを表します。











Shin, Ed., et al.            Informational                      [Page 8]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


      +----------------------------------------------+
      | +------------------------------------------+ |
      | |                                          | |
      | |        IPv6-only applications            | |
      | |                                          | |
      | +------------------------------------------+ |
      |                      |                       |
      | +------------------------------------------+ |
      | |                                          | |
      | |   TCP / UDP / others (SCTP, DCCP, etc.)  | |
      | |                                          | |
      | +------------------------------------------+ |
      |    IPv4-mapped    |        |    IPv6         |
      |  IPv6 addresses   |        |   addresses     |
      | +--------------------+ +-------------------+ |
      | |        IPv4        | |      IPv6         | |
      | +--------------------+ +-------------------+ |
      |   IPv4       |                 |             |
      |   addresses  |                 |             |
      +--------------|-----------------|-------------+
                     |                 |
                IPv4 packets      IPv6 packets

   We will analyze the behaviour of IPv6-applications that exchange IPv4
   packets with IPv4 applications by using the client/server model.  We
   consider the default case to be when the IPV6_V6ONLY socket option
   has not been set.  In these dual-stack nodes, this default behavior
   allows a limited amount of IPv4 communication using the IPv4-mapped
   IPv6 addresses.

クライアント/サーバーモデルを使用して、IPv4パケットをIPv4アプリケーションと交換するIPv6-アプリケーションの動作を分析します。 デフォルトのケースは、IPV6_V6ONLYソケットオプションが設定されていない場合であると見なします。 これらのデュアルスタックノードでは、このデフォルトの動作により、IPv4にマップされたIPv6アドレスを使用して、限られた量のIPv4通信が可能になります。


      IPv6-only server:

IPv6のみのサーバー:

         When an IPv4 client application sends data to an IPv6-only
         server application running on a dual-stack node by 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.

ワイルドカードアドレスを使用して、IPv4クライアントアプリケーションがデュアルスタックノードで実行されているIPv6のみのサーバーアプリケーションにデータを送信すると、IPv4クライアントアドレスは、デュアルスタックノードでIPv4にマップされたIPv6アドレスとして解釈されます。 これにより、IPv6アプリケーションで通信を管理できます。 IPv6サーバーは、通常のIPv6アドレスであり、通常のIPv6接続であるかのように、このマッピングされたアドレスを使用します。 ただし、IPv4パケットはノード間で交換されます。 デュアルスタックのカーネルは、IPv4にマップされたIPv6アドレスをIPv4のアドレスとして正しく解釈し、その逆も同様です。


      IPv6-only client:

IPv6のみのクライアント:

         IPv6-only client applications in a dual-stack node will not
         receive IPv4-mapped addresses from the hostname resolution API
         functions unless a special hint, AI_V4MAPPED, is given.  If it





Shin, Ed., et al.            Informational                      [Page 9]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


         is, the IPv6 client will use the returned mapped address as if
         it were a regular IPv6 address, and a usual IPv6 connection.
         However, IPv4 packets will be exchanged between applications.

デュアルスタックノードのIPv6のみのクライアントアプリケーションは、特別なヒントAI_V4MAPPEDが指定されない限り、ホスト名解決API関数からIPv4にマップされたアドレスを受け取りません。 そうである場合、IPv6クライアントは、返されたマッピングアドレスを通常のIPv6アドレスであるかのように使用し、通常のIPv6接続を使用します。 ただし、IPv4パケットはアプリケーション間で交換されます。


   Respectively, with IPV6_V6ONLY set, an IPv6-only server application
   will only communicate with IPv6 nodes, and an IPv6-only client only
   with IPv6 servers, as the mapped addresses have been disabled.  This
   option could be useful if applications use new IPv6 features such as
   Flow Label.  If communication with IPv4 is needed, either IPV6_V6ONLY
   must not be used, or dual-stack applications must be used, as
   described in section 4.3.

それぞれIPV6_V6ONLYを設定すると、IPv6専用サーバーアプリケーションはIPv6ノードとのみ通信し、IPv6専用クライアントはIPv6サーバーのみと通信します。これは、マッピングアドレスが無効になっているためです。 このオプションは、アプリケーションがフローラベルなどの新しいIPv6機能を使用する場合に役立ちます。 IPv4との通信が必要な場合、セクション4.3で説明されているように、IPV6_V6ONLYを使用しないか、デュアルスタックアプリケーションを使用する必要があります。


   Some implementations of dual-stack do not allow IPv4-mapped IPv6
   addresses to be used for interoperability between IPv4 and IPv6
   applications.  In these cases, there are two ways to handle the
   problem:

デュアルスタックの一部の実装では、IPv4にマップされたIPv6アドレスを使用して、IPv4アプリケーションとIPv6アプリケーション間の相互運用性を実現できません。 このような場合、問題を処理する方法は2つあります。


      1. Deploy two different versions of the application (possibly
         attached with '6' in the name).

1. 2つの異なるバージョンのアプリケーションをデプロイします(名前に「6」が付いている可能性があります)。


      2. Deploy just one application supporting both protocol versions
         as described in the next section.

2.次のセクションで説明するように、両方のプロトコルバージョンをサポートする1つのアプリケーションのみをデプロイします。


   The first method is not recommended because of a significant number
   of problems associated with selecting the right applications.  These
   problems are described in sections 3.2 and 3.3.

最初の方法は、適切なアプリケーションの選択に関連する多くの問題のため、推奨されません。 これらの問題については、セクション3.2および3.3で説明します。


   Therefore, there are two distinct cases to consider when writing one
   application to support both protocols:

したがって、1つのアプリケーションを作成して両方のプロトコルをサポートする場合は、2つの異なるケースを検討する必要があります。


      1. Whether the application can (or should) support both IPv4 and
         IPv6 through IPv4-mapped IPv6 addresses or the applications
         should support both explicitly (see section 4.3), and

1.アプリケーションがIPv4とIPv6の両方をIPv4でマップされたIPv6アドレスでサポートできる(またはサポートする必要がある)か、アプリケーションが両方を明示的にサポートする必要があるか(セクション4.3を参照)、および


      2. Whether the systems in which the applications are used support
         IPv6 (see section 4.4).

2.アプリケーションが使用されるシステムがIPv6をサポートするかどうか(セクション4.4を参照)。


   Note that some systems will disable (by default) support for internal
   IPv4-mapped IPv6 addresses.  The security concerns regarding these
   are legitimate, but disabling them internally breaks one transition
   mechanism for server applications originally written to bind() and
   listen() to a single socket by using a wildcard address.  This forces
   the software developer to rewrite the daemon to create two separate
   sockets, one for IPv4 only and the other for IPv6 only, and then to
   use select().  However, mapping-enabling of IPv4 addresses on any
   particular system is controlled by the OS owner and not necessarily





Shin, Ed., et al.            Informational                     [Page 10]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   by a developer.  This complicates developers' work, as they now have
   to rewrite the daemon network code to handle both environments, even
   for the same OS.

一部のシステムでは、内部IPv4マップIPv6アドレスのサポートが(デフォルトで)無効になることに注意してください。 これらに関するセキュリティ上の懸念は正当ですが、これらを無効にすると、ワイルドカードアドレスを使用して最初にbind()およびlisten()に書き込まれたサーバーアプリケーションの1つの遷移メカニズムが機能しなくなります。 これにより、ソフトウェア開発者はデーモンを書き換えて、IPv4専用とIPv6専用の2つの別々のソケットを作成し、select()を使用するように強制します。 ただし、特定のシステムでのIPv4アドレスのマッピング有効化は、OS所有者によって制御され、必ずしも開発者によって制御されるわけではありません。 同じOSであっても、両方の環境を処理するためにデーモンネットワークコードを書き直す必要があるため、これは開発者の作業を複雑にします。


4.3.  IPv4/IPv6 Applications in a Dual-Stack Node

4.3。 デュアルスタックノードのIPv4 / IPv6アプリケーション


   Applications should be ported to support both IPv4 and IPv6.  Over
   time, the existing IPv4-only applications could be removed.  As we
   have only one version of each application, the source code will
   typically be easy to maintain and to modify, and there are no
   problems managing which application to select for which
   communication.

アプリケーションは、IPv4とIPv6の両方をサポートするように移植する必要があります。 時間の経過とともに、既存のIPv4専用アプリケーションは削除される可能性があります。 各アプリケーションのバージョンは1つしかないため、通常、ソースコードの保守と変更は簡単で、どの通信用にどのアプリケーションを選択するかを管理するのに問題はありません。


   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
   version of the protocol stack or the application in the node.  Dual
   applications allow more interoperability between heterogeneous
   applications and nodes.

この移行ケースが最も推奨されます。 IPv6移行期間中、IPv4とIPv6の両方をサポートするアプリケーションは、プロトコルスタックのバージョンやノード内のアプリケーションに関係なく、他のアプリケーションと通信できる必要があります。 デュアルアプリケーションにより、異種アプリケーションとノード間の相互運用性が向上します。


   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.

ソースコードがプロトコルに依存しない方法で記述されていて、IPv4またはIPv6に依存していない場合、アプリケーションはアプリケーションとノードのタイプの任意の組み合わせと通信できます。


   Implementations typically prefer IPv6 by default if the remote node
   and application support it.  However, if IPv6 connections fail,
   version-independent applications will automatically try IPv4 ones.
   The resolver returns a list of valid addresses for the remote node,
   and applications can iterate through all of them until connection
   succeeds.

リモートノードとアプリケーションがIPv6をサポートしている場合、実装は通常、デフォルトでIPv6を優先します。 ただし、IPv6接続が失敗した場合、バージョンに依存しないアプリケーションは自動的にIPv4接続を試行します。 リゾルバーはリモートノードの有効なアドレスのリストを返し、アプリケーションは接続が成功するまですべてのアドレスを反復処理できます。


   Application writers should be aware of this protocol ordering, which
   is typically the default, but the applications themselves usually
   need not be [RFC3484].

アプリケーションの作成者は、通常はデフォルトであるこのプロトコルの順序に注意する必要がありますが、アプリケーション自体は通常[RFC3484]である必要はありません。


   If the source code is written in a protocol-dependent way, the
   application will support IPv4 and IPv6 explicitly by using two
   separate sockets.  Note that there are some differences in bind()
   implementation - that is,  in whether one can first bind to IPv6
   wildcard addresses, and then to those for IPv4.  Writing applications
   that cope with this can be a pain.  Implementing IPV6_V6ONLY
   simplifies this.  The IPv4 wildcard bind fails on some systems
   because the IPv4 address space is embedded into IPv6 address space
   when IPv4-mapped IPv6 addresses are used.

ソースコードがプロトコルに依存する方法で記述されている場合、アプリケーションは2つの個別のソケットを使用してIPv4およびIPv6を明示的にサポートします。 bind()の実装にはいくつかの違いがあることに注意してください。つまり、最初にIPv6ワイルドカードアドレスにバインドでき、次にIPv4のワイルドカードアドレスにバインドできるかどうかです。 これに対応するアプリケーションを作成するのは面倒です。 IPV6_V6ONLYを実装すると、これが簡単になります。 一部のシステムでは、IPv4にマッピングされたIPv6アドレスが使用されるとIPv4アドレススペースがIPv6アドレススペースに埋め込まれるため、IPv4ワイルドカードバインドが失敗します。


   A more detailed porting guideline is described in section 6.

より詳細な移植ガイドラインについては、セクション6で説明します。






Shin, Ed., et al.            Informational                     [Page 11]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


4.4.  IPv4/IPv6 Applications in an IPv4-Only Node

4.4。 IPv4のみのノードでのIPv4 / IPv6アプリケーション


   As the transition is likely to take place over a longer time frame,
   applications already ported to support both IPv4 and IPv6 may be run
   on IPv4-only nodes.  This would typically be done to avoid supporting
   two application versions for older and newer operating systems, or to
   support a case in which the user wants to disable IPv6 for some
   reason.

移行はより長い時間枠で行われる可能性が高いため、IPv4とIPv6の両方をサポートするように移植されたアプリケーションは、IPv4のみのノードで実行できます。 これは通常、古いオペレーティングシステムと新しいオペレーティングシステムの2つのアプリケーションバージョンのサポートを回避するため、またはユーザーが何らかの理由でIPv6を無効にしたい場合をサポートするために行われます。


   The most important case is the application support on systems where
   IPv6 support can be dynamically enabled or disabled by the users.
   Applications on such a system should be able to handle a situation
   IPv6 would not be enabled.  Another scenario is when an application
   is deployed on older systems that do not support IPv6 at all (even
   the basic APIs such as getaddrinfo).  In this case, the application
   designer has to make a case-by-case judgment call as to whether it
   makes sense to have compile-time toggle between an older and a newer
   API (having to support both in the code), or whether to provide
   getaddrinfo etc. function support on older platforms as part of the
   application libraries.

最も重要なケースは、ユーザーがIPv6サポートを動的に有効または無効にできるシステムでのアプリケーションサポートです。 このようなシステム上のアプリケーションは、IPv6が有効になっていない状況を処理できる必要があります。 別のシナリオは、IPv6をまったくサポートしていない古いシステム(getaddrinfoなどの基本的なAPIも含む)にアプリケーションがデプロイされている場合です。 この場合、アプリケーション設計者は、コンパイル時に古いAPIと新しいAPI(コードで両方をサポートする必要がある)を切り替えることが理にかなっているか、または getaddrinfoなどを提供します。 アプリケーションライブラリの一部として、古いプラットフォームでの機能サポート。


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

アプリケーション/オペレーティングシステムのサポートによっては、このケースを無視したい場合もありますが、通常は想定を行うことができず、アプリケーションもこのシナリオで機能するはずです。


   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 an EPROTONOSUPPORT or
   EAFNOSUPPORT error.  Typically, errors like these lead 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 so that errors are
   ignored until the last address family.

たとえば、socket()コマンドを発行するアプリケーションで、最初にAF_INET6を試行し、次にAF_INETを試行します。 ただし、カーネルがIPv6をサポートしていない場合、呼び出しはEPROTONOSUPPORTまたはEAFNOSUPPORTエラーになります。 通常、このようなエラーはソケットループの終了につながり、AF_INETも試行されません。 アプリケーションはこのケースを処理するか、ループを構築して、最後のアドレスファミリまでエラーが無視されるようにする必要があります。


   This case is just an extension of the IPv4/IPv6 support in the
   previous case, covering one relatively common but often-ignored case.

このケースは、前のケースでのIPv4 / IPv6サポートの拡張にすぎず、比較的一般的だが無視されることが多いケースをカバーしています。


5.  Application Porting Considerations

5.アプリケーションの移植に関する考慮事項


   The minimum changes for IPv4 applications to work with IPv6 are based
   on the different size and format of IPv4 and IPv6 addresses.

IPv4アプリケーションがIPv6と連携するための最小限の変更は、IPv4アドレスとIPv6アドレスの異なるサイズとフォーマットに基づいています。


   Applications have been developed with IPv4 network protocol in mind.
   This assumption has resulted in many IP dependencies through source
   code.

アプリケーションは、IPv4ネットワークプロトコルを考慮して開発されています。 この仮定により、ソースコードを通じて多くのIP依存関係が発生しました。


   The following list summarizes the more common IP version dependencies
   in applications:

次のリストは、アプリケーションでのより一般的なIPバージョンの依存関係をまとめたものです。





Shin, Ed., et al.            Informational                     [Page 12]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


      a) Presentation format for an IP address:  An ASCII string that
         represents the IP address, a dotted-decimal string for IPv4,
         and a hexadecimal string for IPv6.

a)IPアドレスの表示形式:IPアドレスを表すASCII文字列、IPv4の場合はドット付き10進文字列、IPv6の場合は16進文字列。


      b) Transport layer API: Functions to establish communications and
         to exchange information.

b)トランスポート層API:通信を確立し、情報を交換するための関数。


      c) Name and address resolution: Conversion functions between
         hostnames and IP addresses.

c)名前とアドレスの解決:ホスト名とIPアドレス間の変換機能。


      d) Specific IP dependencies: More specific IP version
         dependencies, such as IP address selection, application
         framing, and storage of IP addresses.

d)特定のIP依存関係:IPアドレスの選択、アプリケーションのフレーミング、IPアドレスの格納など、より具体的なIPバージョンの依存関係。


      e) Multicast applications: One must find the IPv6 equivalents to
         the IPv4 multicast addresses and use the right socket
         configuration options.

e)マルチキャストアプリケーション:IPv4マルチキャストアドレスに相当するIPv6を見つけ、適切なソケット構成オプションを使用する必要があります。


   The following subsections describe the problems with the
   aforementioned IP version dependencies.  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
   with both IPv4 and IPv6.

以下のサブセクションでは、前述のIPバージョンの依存関係に関する問題について説明します。 アプリケーションのソースコードは、IPアドレスに関連する最小限の変更でIPv6に移植できますが、プロトコルに依存しない方法でソースコードを変更して、アプリケーションがIPv4とIPv6の両方で動作できるようにするための推奨事項がいくつかあります。


5.1.  Presentation Format for an IP Address

5.1。 IPアドレスの表示形式


   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.

多くのアプリケーションはIPアドレスを使用してネットワークノードを識別し、宛先アドレスへの接続を確立します。 たとえば、クライアント/サーバーモデルを使用する場合、クライアントは通常、サーバーに接続するためのアプリケーションパラメーターとしてIPアドレスを必要とします。 このIPアドレスは通常、文字列としてプレゼンテーション形式で提供されます。 IPアドレスのプレゼンテーション形式を移植する場合、割り当てられたメモリとプレゼンテーション形式の管理という2つの問題があります。


   Usually, the memory allocated to contain an IPv4 address
   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アドレス表現を文字列として格納するために割り当てられたメモリは、IPv6アドレスを格納できません。 より大きなIPv6アドレスによって可能になるバッファオーバーフローを防ぐために、アプリケーションを変更する必要があります。


   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 a colon (:) to separate each pair of octets written in
   hexadecimal notation [RFC3513].  In cases where one must be able to
   specify, for example, port numbers with the address (see below), it
   may be desirable to require placing the address inside the square
   brackets [TextRep].

IPv4とIPv6は同じ表示形式を使用しません。 IPv4はドット(.)を使用して10進表記で記述された4つのオクテットを区切り、IPv6はコロン(:)を使用して16進表記で記述されたオクテットの各ペアを区切ります[RFC3513]。 たとえば、アドレス(以下を参照)でポート番号を指定できる必要がある場合は、角かっこ[TextRep]内にアドレスを配置する必要がある場合があります。





Shin, Ed., et al.            Informational                     [Page 13]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   A particular problem with IP address parsers comes when the input is
   actually a combination of IP address and port number.  With IPv4
   these are often coupled with a colon; for example, "192.0.2.1:80".
   However, this approach would be ambiguous with IPv6, as colons are
   already used to structure the address.

入力が実際にIPアドレスとポート番号の組み合わせである場合、IPアドレスパーサーの特定の問題が発生します。 IPv4では、これらはしばしばコロンと結合されます。 たとえば、「192.0.2.1:80」です。 ただし、コロンはアドレスの構造化にすでに使用されているため、このアプローチはIPv6ではあいまいになります。


   Therefore, the IP address parsers that take the port number separated
   with a colon should distinguish IPv6 addresses somehow.  One way is
   to enclose the address in brackets, as is done with Uniform Resource
   Locators (URLs) [RFC2732]; for example, http://[2001:db8::1]:80.

したがって、コロンで区切られたポート番号を取得するIPアドレスパーサーは、IPv6アドレスを何らかの方法で区別する必要があります。 1つの方法は、Uniform Resource Locator(URL)[RFC2732]で行われるように、アドレスを角括弧で囲むことです。 たとえば、http:// [2001:db8 :: 1]:80です。


   Some applications also need to specify IPv6 prefixes and lengths:
   The prefix length should be inserted outside of the square brackets,
   if used; for example, [2001:db8::]/64 or 2001:db8::/64 and not
   [2001:db8::/64].  Note that prefix/length notation is syntactically
   indistinguishable from a legal URI; therefore, the prefix/length
   notation must not be used when it isn't clear from the context that
   it's used to specify the prefix and length and not, for example, a
   URI.

一部のアプリケーションでは、IPv6プレフィックスと長さも指定する必要があります。プレフィックスの長さは、角括弧の外側に挿入する必要があります(使用する場合)。 たとえば、[2001:db8 ::] / 64または2001:db8 :: / 64であり、[2001:db8 :: / 64]ではありません。 接頭辞/長さの表記は、構文的には正当なURIと区別できないことに注意してください。 したがって、URIなどではなく、接頭辞と長さの指定に使用されていることがコンテキストから明らかでない場合は、接頭辞/長さの表記を使用しないでください。


   In some specific cases, it may be necessary to give a zone identifier
   as part of the address; for example, fe80::1%eth0.  In general,
   applications should not need to parse these identifiers.

特定のケースでは、アドレスの一部としてゾーン識別子を指定する必要がある場合があります。 たとえば、fe80 :: 1%eth0です。 一般に、アプリケーションはこれらの識別子を解析する必要はありません。


   The IP address parsers should support enclosing the IPv6 address in
   brackets, even when the address is not used in conjunction with a
   port number.  Requiring that the user always give a literal IP
   address enclosed in brackets is not recommended.

IPアドレスパーサーは、アドレスがポート番号と共に使用されない場合でも、IPv6アドレスを角かっこで囲むことをサポートする必要があります。 ユーザーが常に括弧で囲まれたリテラルIPアドレスを提供することを要求することはお勧めできません。


   Note that some applications may also represent IPv6 address literals
   differently; for example, SMTP [RFC2821] uses [IPv6:2001:db8::1].

一部のアプリケーションではIPv6アドレスリテラルの表現が異なる場合があることに注意してください。 たとえば、SMTP [RFC2821]は[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.

アプリケーションへの汎用直接入力では、アドレスリテラルを使用しないことを強くお勧めします。 代わりにホスト名とDNSを使用する必要があります。


5.2.  Transport Layer API

5.2。 トランスポート層API


   Communication applications often include a transport module that
   establishes communications.  Usually this module manages everything
   related to communications and uses a transport-layer API, typically
   as a network library.  When an application is ported to IPv6, most
   changes should be made in this application transport module in order
   to be adapted to the new IPv6 API.

通信アプリケーションには、通信を確立するトランスポートモジュールが含まれていることがよくあります。 通常、このモジュールは通信に関連するすべてのものを管理し、通常はネットワークライブラリとしてトランスポート層APIを使用します。 アプリケーションをIPv6に移植する場合、新しいIPv6 APIに適合させるために、このアプリケーショントランスポートモジュールでほとんどの変更を行う必要があります。








Shin, Ed., et al.            Informational                     [Page 14]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   In the general case, porting an existing application to IPv6 requires
   an examination of the following issues related to the API:

一般的なケースでは、既存のアプリケーションをIPv6に移植するには、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.

ネットワーク情報ストレージ:IPアドレスデータ構造新しい構造には、128ビットのIPアドレスが含まれている必要があります。 任意のアドレスファミリを格納できる汎用アドレス構造の使用をお勧めします。


         Sometimes special addresses are hard-coded in the application
         source code.  Developers should pay attention to these 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.

時々、アプリケーションのソースコードに特別なアドレスがハードコーディングされています。 開発者は、新しいアドレス形式を使用するためにこれらに注意を払う必要があります。 これらの特別なIPアドレスの一部は、ワイルドカードローカル、ループバック、およびブロードキャストです。 IPv6にはブロードキャストアドレスがないため、アプリケーションは代わりにマルチキャストを使用できます。


      -  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.

アドレス変換関数

アドレス変換関数は、バイナリアドレス表現をプレゼンテーション形式に、またはその逆に変換します。 新しい変換関数は、IPv6アドレス形式に指定されています。


      -  Communication API Functions
         These functions manage communications.  Their signatures are
         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.

通信API関数

これらの機能は通信を管理します。 それらの署名は、一般的なソケットアドレス構造に基づいて定義されます。 同じ機能がIPv6にも有効です。 ただし、これらの関数を呼び出すときに使用されるIPアドレスデータ構造には、更新が必要です。


      -  Network Configuration Options
         These are used when different communication models are
         configured for Input/Output (I/O) operations
         (blocking/nonblocking, I/O multiplexing, etc.) and should be
         translated for IPv6.

ネットワーク構成オプション

これらは、さまざまな通信モデルが入出力(I / O)操作(ブロッキング/ノンブロッキング、I / O多重化など)用に構成されている場合に使用され、IPv6に変換する必要があります。


5.3.  Name and Address Resolution

5.3。 名前とアドレスの解決


   From the application point of view, the name and address resolution
   is a system-independent process.  An application calls functions in a
   system library, the resolver, which is linked into the application
   when it is built.  However, these functions use IP address
   structures, that are protocol dependent and must be reviewed to
   support the new IPv6 resolution calls.

アプリケーションの観点から見ると、名前とアドレスの解決はシステムに依存しないプロセスです。 アプリケーションは、ビルド時にアプリケーションにリンクされているシステムライブラリ、リゾルバーの関数を呼び出します。 ただし、これらの関数はIPアドレス構造を使用します。これはプロトコルに依存しており、新しいIPv6解決呼び出しをサポートするために確認する必要があります。


   With IPv6, there are two new basic resolution functions,
   getaddrinfo() and getnameinfo().  The first 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




Shin, Ed., et al.            Informational                     [Page 15]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   IPv6 addresses.  However, it is recommended that all configured IP
   addresses be obtained to allow applications to work with every kind
   of node.  The second function returns the hostname associated to an
   IP address.

IPv6では、getaddrinfo()とgetnameinfo()という2つの新しい基本的な解決関数があります。 1つ目は、ホスト名に設定されたすべてのIPアドレスのリストを返します。 これらのクエリは、1つのプロトコルファミリに制限できます。 たとえば、IPv4アドレスのみ、またはIPv6アドレスのみ。 ただし、アプリケーションがあらゆる種類のノードで動作できるように、すべての構成済みIPアドレスを取得することをお勧めします。 2番目の関数は、IPアドレスに関連付けられたホスト名を返します。


5.4.  Specific IP Dependencies

5.4。 特定のIP依存関係


5.4.1.  IP Address Selection

5.4.1。 IPアドレスの選択


   Unlike the IPv4 model, IPv6 promotes the configuration of multiple IP
   addresses per node, 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.

IPv4モデルとは異なり、IPv6はノードごとに複数のIPアドレスの構成を促進しますが、アプリケーションは通信に宛先/ソースのペアのみを使用します。 適切なIP送信元アドレスと宛先アドレスを選択することは、IPデータグラムのルートを決定する重要な要素です。


   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, per [RFC3484], but
   will also allow applications to make changes in the ordering rules.

通常、アプリケーションではなくノードが送信元アドレスの選択を自動的に解決します。 ノードは、[RFC3484]に従って、最良の選択のいくつかのルールに従って通信の送信元アドレスを選択しますが、アプリケーションが順序付けルールを変更することもできます。


   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
   should try each element in the list until the communication succeeds.

宛先アドレスを選択するとき、アプリケーションは通常、リゾルバーに宛先IPアドレスを要求します。 リゾルバーは、ホスト名から一連の有効なIPアドレスを返します。 アプリケーションが特定の宛先アドレスを選択する特別な理由がない限り、通信が成功するまで、リスト内の各要素を試す必要があります。


   In some cases, the application may need to specify its source
   address.  The destination address selection process picks the best
   destination for the source address (instead of picking the best
   source address for the chosen destination address).  Note that if it
   is not yet known which protocol will be used for communication there
   may be an increase in complexity for IP version - independent
   applications that have to specify the source address (especially for
   client applications.  Fortunately, specifying the source address is
   not typically required).

場合によっては、アプリケーションで送信元アドレスを指定する必要があります。 宛先アドレス選択プロセスでは、(選択した宛先アドレスに最適な送信元アドレスを選択するのではなく)送信元アドレスに最適な宛先を選択します。 通信にどのプロトコルが使用されるかがまだわからない場合は、IPバージョン-送信元アドレスを指定する必要がある独立したアプリケーション(特にクライアントアプリケーションの場合)の複雑さが増す可能性があることに注意してください。 必須)。


5.4.2.  Application Framing

5.4.2。 アプリケーションのフレーミング


   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 with ALF
   arrives from the ADU size selection to obtain better performance.

アプリケーションレベルフレーミング(ALF)アーキテクチャは、従来トランスポート層に含まれるメカニズムを制御します。 多くの場合、ALFを実装するアプリケーションは、データをアプリケーションデータユニット(ADU)にパケット化する責任があります。 ALFに関するアプリケーションの問題は、より良いパフォーマンスを得るためにADUサイズの選択から生じます。


   Applications using connectionless protocols (such as UDP) typically
   need application framing.  These applications have three choices: (1)
   to use packet sizes no larger than the IPv6 minimum Maximum
   Transmission Unit (MTU) of 1280 bytes [RFC2460], (2) to use any



Shin, Ed., et al.            Informational                     [Page 16]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   packet sizes, but to force IPv6 fragmentation/reassembly when
   necessary, or (3) to optimize the packet size and avoid unnecessary
   fragmentation/reassembly, and to guess or find out the optimal packet
   sizes that can be sent and received, end-to-end, on the network.
   This memo takes no stance on that approach is best.

コネクションレス型プロトコル(UDPなど)を使用するアプリケーションは、通常、アプリケーションフレーミングを必要とします。 これらのアプリケーションには3つの選択肢があります:(1)1280バイトのIPv6最小最大転送単位(MTU)以下のパケットサイズを使用する[RFC2460]、(2)パケットサイズを使用するが、必要に応じてIPv6フラグメンテーション/再構成を強制する 、または(3)パケットサイズを最適化して不要な断片化/再構成を回避し、ネットワーク上でエンドツーエンドで送受信できる最適なパケットサイズを推測または検出します。 このメモは、そのアプローチが最善であるという立場をとりません。


   Note that the most optimal ALF depends on dynamic factors such as
   Path MTU or whether IPv4 or IPv6 is being used (due to different
   header sizes, possible IPv6-in-IPv4 tunneling overhead, etc.).  These
   factors have to be taken into consideration when application framing
   is implemented.

最も最適なALFは、パスMTUまたはIPv4またはIPv6が使用されているかどうかなどの動的な要因に依存することに注意してください(ヘッダーサイズが異なる、IPv6-in-IPv4トンネリングオーバーヘッドなどが原因)。 アプリケーションフレーミングを実装する場合は、これらの要素を考慮する必要があります。


5.4.3.  Storage of IP Addresses

5.4.3。 IPアドレスの保存


   Some applications store IP addresses as remote peer information.  For
   instance, one of the most popular ways to register remote nodes in
   collaborative applications uses IP addresses as registry keys.

一部のアプリケーションは、IPアドレスをリモートピア情報として保存します。 たとえば、共同アプリケーションにリモートノードを登録する最も一般的な方法の1つは、IPアドレスをレジストリキーとして使用します。


   Although the source code that stores IP addresses can be modified to
   IPv6 by following the previous basic porting recommendations,
   applications should not store IP addresses for the following reasons:

IPアドレスを格納するソースコードは、以前の基本的な移植の推奨事項に従ってIPv6に変更できますが、アプリケーションは次の理由でIPアドレスを格納しないでください。


      -  IP addresses can change throughout time; for instance, after a
         renumbering process.

IPアドレスは常に変化する可能性があります。 たとえば、再番号付けプロセスの後。


      -  The same node can reach a destination host using different IP
         addresses, possibly with a different protocol version.

同じノードが、場合によってはプロトコルバージョンが異なる、異なるIPアドレスを使用して宛先ホストに到達できます。


   When possible, applications should store names such as FQDNs or other
   protocol-independent identities instead of 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 rendezvous 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.

可能な場合、アプリケーションは、アドレスの代わりにFQDNまたはその他のプロトコルに依存しないIDなどの名前を保存する必要があります。 この場合、アプリケーションは、実行時、またはキャッシュの存続期間中、特定のアドレスにのみバインドされます。 独自のランデブーおよび検出メカニズムを備えた大規模なピアツーピアシステムなどの他のタイプのアプリケーションでは、パフォーマンス上の理由からアドレスをキャッシュする必要がある場合がありますが、キャッシュされたアドレスは永続的で信頼できる情報として扱われるべきではありません。 非常に動的なネットワークでは、どのような形式の名前解決も不可能であり、ここでもアドレスをキャッシュする必要があります。


5.5.  Multicast Applications

5.5。 マルチキャストアプリケーション


   There is an additional problem in porting multicast applications.
   When multicast facilities are used 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.

マルチキャストアプリケーションの移植には、さらに別の問題があります。 マルチキャスト機能を使用する場合、IPv6をサポートするためにいくつかの変更を行う必要があります。 まず、アプリケーションはIPv4マルチキャストアドレスをIPv6アドレスに変更する必要があります。次に、ソケット構成オプションを変更する必要があります。






Shin, Ed., et al.            Informational                     [Page 17]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   All IPv6 multicast addresses encode scope; the scope was only
   implicit in IPv4 (with multicast groups in 239/8).  Also, although a
   large number of application-specific multicast addresses have been
   assigned with IPv4, this has been (luckily enough) avoided with 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 [RFC3306].  All in all, this may force the
   application developers to write more protocol-dependent code.

すべてのIPv6マルチキャストアドレスはスコープをエンコードします。 スコープはIPv4でのみ暗黙的でした(239/8のマルチキャストグループを使用)。 また、IPv4では多数のアプリケーション固有のマルチキャストアドレスが割り当てられていますが、これは(幸いなことに)IPv6では回避されています。 したがって、すべてのマルチキャストアドレスに直接対応するものはありません。 リンクローカルマルチキャストの場合、リンクローカルスコープ内のほとんどすべてを選択できます。 グローバルグループは、ユニキャストプレフィックスベースのアドレスを使用できます[RFC3306]。 全体として、これにより、アプリケーション開発者はよりプロトコルに依存するコードを書く必要があります。


   Another problem is 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 possible that PIM-SSM will become more widely
   deployed in IPv6 due to its simpler architecture.

別の問題は、IPv6マルチキャストには、ドメイン間マルチキャストの従来のAny Source Multicastの標準化されたメカニズムがまだないことです。 Any Source Multicast(ASM)またはSource-Specific Multicast(SSM)のモデルは、一般的にIPv4とIPv6の間で類似していますが、PIM-SSMは、その単純なアーキテクチャーにより、IPv6でより広く展開される可能性があります。


   It might be beneficial to port the applications to use SSM semantics,
   requiring off-band source discovery mechanisms and a different API
   [RFC3678].  Inter-domain ASM service is available only through a
   method embedding the Rendezvous Point address in the multicast
   address [Embed-RP].

アプリケーションをSSMセマンティクスを使用するように移植すると、オフバンドソース検出メカニズムと異なるAPI [RFC3678]が必要になる場合があります。 ドメイン間ASMサービスは、ランデブーポイントアドレスをマルチキャストアドレス[Embed-RP]に埋め込む方法でのみ利用できます。


   Another generic problem with multiparty conferencing applications,
   similar to the issues with peer-to-peer applications, is that all
   users of the session must use the same protocol version (IPv4 or
   IPv6), or some form of proxy or translator (e.g., [MUL-GW]).

ピアツーピアアプリケーションの問題と同様に、マルチパーティ会議アプリケーションのもう1つの一般的な問題は、セッションのすべてのユーザーが同じプロトコルバージョン(IPv4またはIPv6)、または何らかの形式のプロキシまたはトランスレータ(たとえば[ MUL-GW])。


6.  Developing IP Version - Independent Applications

6. IPバージョンの開発-独立したアプリケーション


   As stated, 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 required, one of the
   better solutions would be to build a communication library that
   provides an IP version -  independent API to applications and that
   hides all dependencies.

前述のように、IPv4とIPv6の両方で動作するデュアルアプリケーションをお勧めします。 これらのアプリケーションは、ソースコードのIP依存関係を回避する必要があります。 ただし、IPの依存関係が必要な場合、優れたソリューションの1つは、IPバージョン-アプリケーションに独立したAPIを提供し、すべての依存関係を隠す通信ライブラリを構築することです。


   To develop IP version - independent applications, the following
   guidelines should be considered.

IPバージョン-独立したアプリケーションを開発するには、次のガイドラインを考慮する必要があります。


6.1.  IP Version - Independent Structures

6.1。 IPバージョン-独立した構造


   All memory structures and APIs should be IP version-independent.  One
   should avoid structs in_addr, in6_addr, sockaddr_in, and
   sockaddr_in6.

すべてのメモリ構造とAPIは、IPバージョンに依存しない必要があります。 struct in_addr、in6_addr、sockaddr_in、sockaddr_in6は避けてください。







Shin, Ed., et al.            Informational                     [Page 18]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   Suppose a network address is passed to some function, foo().  If one
   uses struct in_addr or struct in6_addr, results an extra parameter to
   indicate address family, as below:

ネットワークアドレスが関数foo()に渡されたとします。 struct in_addrまたはstruct in6_addrを使用すると、以下のように、アドレスファミリを示す追加のパラメータが生成されます。


      struct in_addr in4addr;
      struct in6_addr in6addr;
       /* IPv4 case */
      foo(&in4addr, AF_INET);
       /* IPv6 case */
      foo(&in6addr, AF_INET6);

   This leads to duplicated code and having to consider each scenario
   from both perspectives independently, which is difficult to maintain.
   So we should use struct sockaddr_storage, as below:

これにより、コードが重複し、両方の観点から独立して各シナリオを考慮する必要があり、維持が困難になります。 したがって、以下のようにstruct sockaddr_storageを使用する必要があります。


      struct sockaddr_storage ss;
      int sslen;
      /* AF independent! - use sockaddr when passing a pointer */
      /* note: it's typically necessary to also pass the length
         explicitly */
      foo((struct sockaddr *)&ss, sslen);

6.2.  IP Version - Independent APIs

6.2。 IPバージョン-独立したAPI


   The new address independent variants getaddrinfo() and getnameinfo()
   hide the gory details of name-to-address and address-to-name
   translations.  They implement functionalities of the following
   functions:

新しいアドレスに依存しないバリアントgetaddrinfo()とgetnameinfo()は、名前からアドレスへの変換とアドレスから名前への変換の詳細を隠します。 次の機能の機能を実装します。


      gethostbyname()
      gethostbyaddr()
      getservbyname()
      getservbyport()

   They also obsolete the functionality of gethostbyname2(), defined in
   [RFC2133].

また、[RFC2133]で定義されているgethostbyname2()の機能も廃止しました。


   The new variants can perform hostname/address and service name/port
   lookups, though the features can be turned off, if desired.
   Getaddrinfo() can return multiple addresses, as below:

新しいバリアントはホスト名/アドレスとサービス名/ポートのルックアップを実行できますが、必要に応じて機能をオフにすることもできます。 Getaddrinfo()は、以下のように複数のアドレスを返すことができます。


      localhost.      IN A    127.0.0.1
                      IN A    127.0.0.2
                      IN AAAA ::1

   In this example, if IPv6 is preferred, getaddrinfo first returns ::1;
   then both 127.0.0.1 and 127.0.0.2 are in a random order.

この例では、IPv6が優先される場合、getaddrinfoは最初に:: 1を返します。 次に、127.0.0.1と127.0.0.2の両方がランダムな順序になります。





Shin, Ed., et al.            Informational                     [Page 19]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   Getaddrinfo() and getnameinfo() can query hostname and service
   name/port at once.

getaddrinfo()とgetnameinfo()は、ホスト名とサービス名/ポートを同時に照会できます。


   Hardcoding AF-dependent knowledge is not preferred in the program.
   Constructs such as that below should be avoided:

AF依存の知識をハードコーディングすることは、プログラムでは推奨されません。 以下のような構成は避けてください。


       /* BAD EXAMPLE */
       switch (sa->sa_family) {
       case AF_INET:
               salen = sizeof(struct sockaddr_in);
               break;
      }

   Instead, we should use the ai_addrlen member of the addrinfo
   structure, as returned by getaddrinfo().

代わりに、getaddrinfo()から返されるaddrinfo構造体のai_addrlenメンバーを使用する必要があります。


   The gethostbyname(), gethostbyaddr(), getservbyname(), and
   getservbyport() are mainly used to get server and client sockets.  In
   the following sections, we will see simple examples creating these
   sockets by using the new IPv6 resolution functions.

gethostbyname()、gethostbyaddr()、getservbyname()、およびgetservbyport()は、主にサーバーとクライアントのソケットを取得するために使用されます。 次のセクションでは、新しいIPv6解決関数を使用してこれらのソケットを作成する簡単な例を示します。


6.2.1.  Example of Overly Simplistic TCP Server Application

6.2.1。 過度に単純化したTCPサーバーアプリケーションの例


   A simple TCP server socket at service name (or port number string)
   SERVICE:

サービス名(またはポート番号文字列)の単純なTCPサーバーソケットサービス:


      /*
       * BAD EXAMPLE: does not implement the getaddrinfo loop as
       * specified in 6.3.  This may result in one of the following:
       *  - an IPv6 server, listening at the wildcard address,
       *    allowing IPv4 addresses through IPv4-mapped IPv6 addresses.
       *  - an IPv4 server, if IPv6 is not enabled,
       *  - an IPv6-only server, if IPv6 is enabled but IPv4-mapped IPv6
       *    addresses are not used by default, or
       *  - no server at all, if getaddrinfo supports IPv6, but the
       *    system doesn't, and socket(AF_INET6, ...) exits with an
       *    error.
       */
      struct addrinfo hints, *res;
      int error, sockfd;

      memset(&hints, 0, sizeof(hints));
      hints.ai_flags = AI_PASSIVE;
      hints.ai_family = AF_UNSPEC;
      hints.ai_socktype = SOCK_STREAM;
      error = getaddrinfo(NULL, SERVICE, &hints, &res);
      if (error != 0) {
         /* handle getaddrinfo error */



Shin, Ed., et al.            Informational                     [Page 20]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


      }

      sockfd = socket(res->family, res->ai_socktype, res->ai_protocol);
      if (sockfd < 0) {
         /* handle socket error */
      }

      if (bind(sockfd, res->ai_addr, res->ai_addrlen) < 0) {
         /* handle bind error */
      }

      /* ... */

      freeaddrinfo(res);

6.2.2.  Example of Overly Simplistic TCP Client Application

6.2.2。 過度に単純化したTCPクライアントアプリケーションの例


   A simple TCP client socket connecting to a server running at node
   name (or IP address presentation format) SERVER_NODE and service name
   (or port number string) SERVICE follows:

ノード名(またはIPアドレス表示形式)SERVER_NODEおよびサービス名(またはポート番号文字列)SERVICEで実行されているサーバーに接続する単純なTCPクライアントソケットは次のとおりです。


      /*
       * BAD EXAMPLE: does not implement the getaddrinfo loop as
       * specified in 6.3.  This may result in one of the following:
       *  - an IPv4 connection to an IPv4 destination,
       *  - an IPv6 connection to an IPv6 destination,
       *  - an attempt to try to reach an IPv6 destination (if AAAA
       *    record found), but failing -- without fallbacks -- because:
       *     o getaddrinfo supports IPv6 but the system does not
       *     o IPv6 routing doesn't exist, so falling back to e.g., TCP
       *       timeouts
       *     o IPv6 server reached, but service not IPv6-enabled or
       *       firewalled away
       *  - if the first destination is not reached, there is no
       *    fallback to the next records
       */
      struct addrinfo hints, *res;
      int error, sockfd;

      memset(&hints, 0, sizeof(hints));
      hints.ai_family = AF_UNSPEC;
      hints.ai_socktype = SOCK_STREAM;

      error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res);
      if (error != 0) {
           /* handle getaddrinfo error */
      }




Shin, Ed., et al.            Informational                     [Page 21]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


      sockfd = socket(res->family, res->ai_socktype, res->ai_protocol);
      if (sockfd < 0) {
           /* handle socket error */
      }

      if (connect(sockfd, res->ai_addr, res->ai_addrlen) < 0 ) {
           /* handle connect error */
      }

      /* ... */

      freeaddrinfo(res);

6.2.3.  Binary/Presentation Format Conversion

6.2.3。 バイナリ/プレゼンテーション形式の変換


   We should consider the binary and presentation address format
   conversion APIs.  The following functions convert network address
   structure in its presentation address format and vice versa:

バイナリおよびプレゼンテーションアドレス形式変換APIを検討する必要があります。 次の関数は、ネットワークアドレス構造をプレゼンテーションアドレス形式に、またはその逆に変換します。


      inet_ntop()
      inet_pton()

   Both are from the basic socket extensions for IPv6.  However, these
   conversion functions are protocol-dependent.  It is better to use
   getnameinfo()/getaddrinfo() (inet_pton and inet_ntop equivalents are
   described in Appendix A).

どちらもIPv6の基本的なソケット拡張からのものです。 ただし、これらの変換関数はプロトコルに依存します。 getnameinfo()/ getaddrinfo()を使用することをお勧めします(inet_ptonおよびinet_ntopの同等物については、付録Aで説明しています)。


   Conversion from network address structure to presentation format can
   be written as follows:

ネットワークアドレス構造から表示形式への変換は、次のように記述できます。


      struct sockaddr_storage ss;
      char addrStr[INET6_ADDRSTRLEN];
      char servStr[NI_MAXSERV];
      int error;

      /* fill ss structure */

      error = getnameinfo((struct sockaddr *)&ss, sizeof(ss),
                          addrStr, sizeof(addrStr),
                          servStr, sizeof(servStr),
                          NI_NUMERICHOST);










Shin, Ed., et al.            Informational                     [Page 22]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   Conversions from presentation format to network address structure can
   be written as follows:

表示形式からネットワークアドレス構造への変換は、次のように記述できます。


      struct addrinfo hints, *res;
      char addrStr[INET6_ADDRSTRLEN];
      int error;

      /* fill addrStr buffer */

      memset(&hints, 0, sizeof(hints));
      hints.ai_family = AF_UNSPEC;

      error = getaddrinfo(addrStr, NULL, &hints, &res);
      if (error != 0) {
          /* handle getaddrinfo error */
      }

      /* res->ai_addr contains the network address structure */
      /* ... */
      freeaddrinfo(res);

6.3.  Iterated Jobs for Finding the Working Address

6.3。 ワーキングアドレスを見つけるための反復ジョブズ


   In a client code, when multiple addresses are returned from
   getaddrinfo(), we should try all of them until connection succeeds.
   When a failure occurs with socket(), connect(), bind(), or some other
   function, the code should go on to try the next address.

クライアントコードでは、getaddrinfo()から複数のアドレスが返された場合、接続が成功するまですべてのアドレスを試す必要があります。 socket()、connect()、bind()、またはその他の関数で障害が発生した場合、コードは次のアドレスを試す必要があります。


   In addition, if something is wrong with the socket call because the
   address family is not supported (i.e., in case of section 4.4),
   applications should try the next address structure.

さらに、アドレスファミリがサポートされていないためにソケット呼び出しに問題がある場合(セクション4.4の場合など)、アプリケーションは次のアドレス構造を試す必要があります。


   Note: In the following examples, the socket() return value error
   handling could be simplified by always continuing on with the socket
   loop instead of performing special checking of specific error
   numbers.

注:次の例では、特定のエラー番号の特別なチェックを実行する代わりに、常にソケットループを継続することにより、socket()の戻り値のエラー処理を簡略化できます。


6.3.1.  Example of TCP Server Application

6.3.1。 TCPサーバーアプリケーションの例


   The previous TCP server example should be written as follows:

前のTCPサーバーの例は、次のように書く必要があります。


      #define MAXSOCK 2
      struct addrinfo hints, *res;
      int error, sockfd[MAXSOCK], nsock=0;

      memset(&hints, 0, sizeof(hints));
      hints.ai_flags = AI_PASSIVE;
      hints.ai_family = AF_UNSPEC;



Shin, Ed., et al.            Informational                     [Page 23]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


      hints.ai_socktype = SOCK_STREAM;

      error = getaddrinfo(NULL, SERVICE, &hints, &res);
      if (error != 0) {
          /* handle getaddrinfo error */
      }

      for (aip=res; aip && nsock < MAXSOCK; aip=aip->ai_next) {
          sockfd[nsock] = socket(aip->ai_family,
                                 aip->ai_socktype,
                                 aip->ai_protocol);

          if (sockfd[nsock] < 0) {
              switch errno {
                   case EAFNOSUPPORT:
                   case EPROTONOSUPPORT:
                       /*
                        *  e.g., skip the errors until
                        *  the last address family,
                        *  see section 4.4.
                        */
                        if (aip->ai_next)
                                continue;

                        else {
                               /* handle unknown protocol errors */
                                break;
                        }
                   default:
                        /* handle other socket errors */
                        ;
               }

          } else {
              int on = 1;
              /* optional: works better if dual-binding to wildcard
                 address */
              if (aip->ai_family == AF_INET6) {
                  setsockopt(sockfd[nsock], IPPROTO_IPV6, IPV6_V6ONLY,
                             (char *)&on, sizeof(on));
                  /* errors are ignored */
              }
              if (bind(sockfd[nsock], aip->ai_addr,
                                      aip->ai_addrlen) < 0 ) {
                  /* handle bind error */
                  close(sockfd[nsock]);
                  continue;
              }



Shin, Ed., et al.            Informational                     [Page 24]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


              if (listen(sockfd[nsock], SOMAXCONN) < 0) {
                  /* handle listen errors */
                  close(sockfd[nsock]);
                  continue;
              }
          }
          nsock++;
      }
      freeaddrinfo(res);

      /* check that we were able to obtain the sockets */

6.3.2.  Example of TCP Client Application

6.3.2。 TCPクライアントアプリケーションの例


   The previous TCP client example should be written as follows:

前のTCPクライアントの例は、次のように書く必要があります。


      struct addrinfo hints, *res, *aip;
      int sockfd, error;

      memset(&hints, 0, sizeof(hints));
      hints.ai_family   = AF_UNSPEC;
      hints.ai_socktype = SOCK_STREAM;

      error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res);
      if (error != 0) {
          /* handle getaddrinfo error */
      }

      for (aip=res; aip; aip=aip->ai_next) {

          sockfd = socket(aip->ai_family,
                          aip->ai_socktype,
                          aip->ai_protocol);

          if (sockfd < 0) {
              switch errno {
                   case EAFNOSUPPORT:
                   case EPROTONOSUPPORT:
                       /*
                        *  e.g., skip the errors until
                        *  the last address family,
                        *  see section 4.4.
                        */
                        if (aip->ai_next)
                                continue;
                        else {
                               /* handle unknown protocol errors */
                                break;



Shin, Ed., et al.            Informational                     [Page 25]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


                        }

                   default:
                        /* handle other socket errors */
                        ;
               }

          } else {
              if (connect(sockfd, aip->ai_addr, aip->ai_addrlen) == 0)
                  break;

              /* handle connect errors */
              close(sockfd);
              sockfd=-1;
          }
      }

      if (sockfd > 0) {
          /* socket connected to server address */

          /* ... */
      }

      freeaddrinfo(res);

7.  Transition Mechanism Considerations

7.移行メカニズムに関する考慮事項


   The mechanism [NAT-PT] introduces a special set of addresses, formed
   of an NAT-PT prefix and an IPv4 address these refer to IPv4 addresses
   translated by NAT-PT DNS-ALG.  In some cases, one might be tempted to
   handle these differently.

[NAT-PT]メカニズムは、NAT-PT DNS-ALGによって変換されたIPv4アドレスを参照する、NAT-PTプレフィックスとIPv4アドレスで構成される特別なアドレスセットを導入します。 場合によっては、これらを異なる方法で処理したくなるかもしれません。


   However, IPv6 applications must not be required to distinguish
   "normal" and "NAT-PT translated" addresses (or any other kind of
   special addresses, including the IPv4-mapped IPv6 addresses): This
   would be completely impractical, and if the distinction must be made,
   it must be done elsewhere (e.g., kernel, system libraries).

ただし、IPv6アプリケーションは、「通常の」アドレスと「NAT-PT変換された」アドレス(またはIPv4にマップされたIPv6アドレスを含む他の種類の特別なアドレス)を区別する必要はありません。これは完全に非実用的であり、 作成する必要がある場合は、他の場所(カーネル、システムライブラリなど)で行う必要があります。


8.  Security Considerations

8.セキュリティに関する考慮事項


   There are a number of security considerations for IPv6 transition,
   but those are outside the scope of this memo.

IPv6の移行にはセキュリティに関する考慮事項がいくつかありますが、それらはこのメモの範囲外です。


   To ensure the availability and robustness of the service even when
   transitioning to IPv6, this memo describes a number of ways to make
   applications more resistant to failures by cycling through addresses
   until a working one is found.  Doing this properly is critical to
   maintain availability and to avoid loss of service.

IPv6への移行時にもサービスの可用性と堅牢性を確保するために、このメモでは、機能しているアドレスが見つかるまでアドレスを循環させることにより、アプリケーションを障害に対してより耐性にするいくつかの方法について説明します。 これを適切に行うことは、可用性を維持し、サービスの損失を回避するために重要です。




Shin, Ed., et al.            Informational                     [Page 26]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   A special consideration about application transition is how IPv4-
   mapped IPv6 addresses are handled.  The use in the API can be seen
   both as a merit (easier application transition) and as a burden
   (difficulty in ensuring whether the use was legitimate).  Note that
   some systems will disable (by default) support for internal IPv4-
   mapped IPv6 addresses.  The security concerns regarding these on the
   wire are legitimate, but disabling it internally breaks one
   transition mechanism for server applications originally written to
   bind() and listen() to a single socket by using a wildcard address
   [V6MAPPED].  This should be considered in more detail when
   applications are designed.

アプリケーションの移行に関する特別な考慮事項は、IPv4にマップされたIPv6アドレスの処理方法です。 APIでの使用は、メリット(アプリケーションの移行が容易)と負担(使用が正当であるかどうかを確認するのが困難)の両方と見なすことができます。 一部のシステムでは、内部IPv4マップIPv6アドレスのサポートが(デフォルトで)無効になることに注意してください。 回線上のこれらに関するセキュリティ上の懸念は正当ですが、それを無効にすると、ワイルドカードアドレスを使用して最初にbind()およびlisten()に書き込まれたサーバーアプリケーションの1つの遷移メカニズムが壊れます[V6MAPPED]。 これは、アプリケーションを設計するときに、より詳細に検討する必要があります。


9.  Acknowledgments

9.謝辞


   Some of guidelines for development of IP version-independent
   applications (section 6) were first brought up by [AF-APP].  Other
   work to document application porting guidelines has also been in
   progress; for example, [IP-GGF] and [PRT].  We would like to thank
   the members of the v6ops working group and the application area for
   helpful comments.  Special thanks are due to Brian E.  Carpenter,
   Antonio Querubin, Stig Venaas, Chirayu Patel, Jordi Palet, and Jason
   Lin for extensive review of this document.  We acknowledge Ron Pike
   for proofreading the document.

10.  References

10.リファレンス


10.1.  Normative References

10.1 規範的な参考文献


   [RFC3493]   Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
               Stevens, "Basic Socket Interface Extensions for IPv6",
               RFC 3493, February 2003.

   [RFC3542]   Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
               "Advanced Sockets Application Program Interface (API) for
               IPv6", RFC 3542, May 2003.

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

   [BIA]       Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A.
               Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)",
               RFC 3338, October 2002.

   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.





Shin, Ed., et al.            Informational                     [Page 27]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   [RFC3484]   Draves, R., "Default Address Selection for Internet
               Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC3513]   Hinden, R. and S. Deering, "Internet Protocol Version 6
               (IPv6) Addressing Architecture", RFC 3513, April 2003.

10.2.  Informative References

10.2 参考情報


   [2893BIS]   Nordmark, E. and R. E. Gilligan, "Basic Transition
               Mechanisms for IPv6 Hosts and Routers", Work in Progress,
               June 2004.

   [RFC2133]   Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
               "Basic Socket Interface Extensions for IPv6", RFC 2133,
               April 1997.

   [RFC2732]   Hinden, R., Carpenter, B., and L. Masinter, "Format for
               Literal IPv6 Addresses in URL's", RFC 2732, December
               1999.

   [RFC2821]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
               April 2001.

   [TextRep]   Main, A., "Textual Representation of IPv4 and IPv6
               Addresses", Work in Progress, October 2003.

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

   [DNSTRANS]  Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
               Guidelines", BCP 91, RFC 3901, September 2004.

   [DNSOPV6]   Durand, A., Ihren, J. and P. Savola, "Operational
               Considerations and Issues with IPv6 DNS", Work in
               Progress, May 2004.

   [AF-APP]    Hagino, J., "Implementing AF-independent application",
               http://www.kame.net/newsletter/19980604/, 2001.

   [V6MAPPED]  Hagino, J., "IPv4 mapped address considered harmful",
               Work in Progress, April 2002.

   [IP-GGF]    Chown, T., Bound, J., Jiang, S. and P. O'Hanlon,
               "Guidelines for IP version independence in GGF
               specifications", Global Grid Forum(GGF) Documentation,
               work in Progress, September 2003.




Shin, Ed., et al.            Informational                     [Page 28]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


   [Embed-RP]  Savola, P. and B. Haberman, "Embedding the Rendezvous
               Point (RP) Address in an IPv6 Multicast Address", RFC
               3956, November 2004.

   [RFC3306]   Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
               Multicast Addresses", RFC 3306, August 2002.

   [RFC3678]   Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
               Extensions for Multicast Source Filters, RFC 3678,
               January 2004.

   [MUL-GW]    Venaas, S., "An IPv4 - IPv6 multicast gateway", Work in
               Progress, February 2003.

   [PRT]       Castro, E. M., "Programming guidelines on transition to
               IPv6 LONG project", Work in Progress, January 2003.



































Shin, Ed., et al.            Informational                     [Page 29]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


Appendix A.  Other Binary/Presentation Format Conversions

付録A.その他のバイナリ/プレゼンテーション形式の変換


   Section 6.2.3 describes the preferred way to perform
   binary/presentation format conversions; these can also be done by
   using inet_pton() and inet_ntop() and by writing protocol-dependent
   code.  This approach is not recommended, but it is provided here for
   reference and comparison.

セクション6.2.3では、バイナリ/プレゼンテーション形式の変換を実行するための推奨方法について説明します。 これらは、inet_pton()およびinet_ntop()を使用して、プロトコルに依存するコードを記述することによっても実行できます。 このアプローチはお勧めしませんが、参照と比較のためにここに示します。


   Note that inet_ntop()/inet_pton() lose the scope identifier (if used,
   e.g., with link-local addresses) in the conversions, contrary to the
   getaddrinfo()/getnameinfo() functions.

inet_ntop()/ inet_pton()は、getaddrinfo()/ getnameinfo()関数とは逆に、変換でスコープ識別子(リンクローカルアドレスなどで使用されている場合)を失うことに注意してください。


A.1.  Binary to Presentation Using inet_ntop()

A.1。 inet_ntop()を使用したバイナリからプレゼンテーションへ


   Conversions from network address structure to presentation format can
   be written as follows:

ネットワークアドレス構造から表示形式への変換は、次のように記述できます。


      struct sockaddr_storage ss;
      char addrStr[INET6_ADDRSTRLEN];

      /* fill ss structure */

      switch (ss.ss_family) {

           case AF_INET:
                inet_ntop(ss.ss_family,
                         &((struct sockaddr_in *)&ss)->sin_addr,
                         addrStr,
                         sizeof(addrStr));
                break;

           case AF_INET6:
                inet_ntop(ss.ss_family,
                          &((struct sockaddr_in6 *)&ss)->sin6_addr,
                          addrStr,
                          sizeof(addrStr));

                break;

           default:
                /* handle unknown family */
      }

   Note that, the destination buffer addrStr should be long enough to
   contain the presentation address format: INET_ADDRSTRLEN for IPv4 and
   INET6_ADDRSTRLEN for IPv6.  As INET6_ADDRSTRLEN is longer than
   INET_ADDRSTRLEN, the first one is used as the destination buffer
   length.

宛先バッファーaddrStrは、プレゼンテーションアドレス形式(IPv4の場合はINET_ADDRSTRLEN、IPv6の場合はINET6_ADDRSTRLEN)を含めるのに十分な長さにする必要があることに注意してください。 INET6_ADDRSTRLENはINET_ADDRSTRLENよりも長いため、最初の1つが宛先バッファーの長さとして使用されます。




Shin, Ed., et al.            Informational                     [Page 30]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


A.2.  Presentation to Binary Using inet_pton()

A.2。 inet_pton()を使用したバイナリへのプレゼンテーション


   Conversions from presentation format to network address structure can
   be written as follows:

表示形式からネットワークアドレス構造への変換は、次のように記述できます。


      struct sockaddr_storage ss;
      struct sockaddr_in *sin;
      struct sockaddr_in6 *sin6;
      char addrStr[INET6_ADDRSTRLEN];

      /* fill addrStr buffer and ss.ss_family */

      switch (ss.ss_family) {
            case AF_INET:
                  sin = (struct sockaddr_in *)&ss;
                  inet_pton(ss.ss_family,
                            addrStr,
                            (sockaddr *)&sin->sin_addr));
                  break;

            case AF_INET6:
                  sin6 = (struct sockaddr_in6 *)&ss;
                  inet_pton(ss.ss_family,
                            addrStr,
                            (sockaddr *)&sin6->sin6_addr);
                  break;

            default:
                /* handle unknown family */
      }

   Note that, the address family of the presentation format must be
   known.

表示形式のアドレスファミリがわかっている必要があることに注意してください。



















Shin, Ed., et al.            Informational                     [Page 31]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


Authors' Addresses

   Myung-Ki Shin
   ETRI/NIST
   820 West Diamond Avenue
   Gaithersburg, MD 20899, USA

   Phone: +1 301 975-3613
   Fax:   +1 301 590-0932
   EMail: mshin@nist.gov


   Yong-Guen Hong
   ETRI PEC
   161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea

   Phone: +82 42 860 6447
   Fax:   +82 42 861 5404
   EMail: 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

   Phone: +81-3-5259-6350
   Fax:   +81-3-5259-6351
   EMail: itojun@iijlab.net


   Pekka Savola
   CSC/FUNET
   Espoo, Finland

   EMail: psavola@funet.fi


   Eva M. Castro
   Rey Juan Carlos University (URJC)
   Departamento de Informatica, Estadistica y Telematica
   C/Tulipan s/n
   28933 Madrid - SPAIN

   EMail: eva@gsyc.escet.urjc.es





Shin, Ed., et al.            Informational                     [Page 32]

RFC 4038         Application Aspects of IPv6 Transition       March 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Shin, Ed., et al.            Informational                     [Page 33]