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
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).
著作権（C）インターネット協会（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バージョンに依存しないアプリケーションを開発する方法に関するガイドラインも提案しています。
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
As IPv6 is introduced in the IPv4-based Internet, several general issues will arise, such as routing, addressing, DNS, and scenarios.
IPv6がIPv4ベースのインターネットに導入されると、ルーティング、アドレス指定、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）をサポートするようにアプリケーションを変更する必要があります。
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がサポートされていない最初のケースを除く）。
+-------------------+
| 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は、アプリケーションの移行の例を示しています。
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つの類似したアプリケーションがあり、各プロトコルバージョン（pingとping6など）に1つずつあります。
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固有のアプリケーションはわずかであり、どちらが使用されているかを気にせずに両方のプロトコルで動作するはずです。
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アプリケーション間の移行期間が簡単ではない理由はいくつかあります。 このセクションでは、これらの問題について説明します。
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接続がまったくないか）。
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名前リゾルバーは宛先アドレスのリストを収集します。 DNSクエリと応答は、データレコードのプロトコルバージョン[DNSTRANS]に関係なく、IPv4またはIPv6を使用して送信され、クエリを実行します。
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]で詳細に説明されています。
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バージョンをサポートする必要があるかを知ることはできません。 したがって、同じアプリケーションの複数のバージョンが利用可能な場合、ローカルユーザーは、必要な正確なIPバージョンをサポートする適切なバージョンを選択するのが困難です。
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-onlyアプリケーションを呼び出す「ラッパーアプリケーション」を使用することができます。 このアプリケーションは、接続の確立（または同様のタスク）を実行し、開いたソケットを別のアプリケーションに渡します。 ただし、このようなアプリケーションは、単にDNSルックアップを実行したり、与えられたリテラルIPアドレスを決定したりする以上のことを行う必要があるため、ハイブリッドアプリケーションよりもはるかに複雑になります。 さらに、IPアドレス（FTPクライアントなど）を使用して複雑な操作を実行する「ラッピング」アプリケーションを作成することは、さらに困難または不可能になる可能性があります。 つまり、ラッパーアプリケーションは、アプリケーション移行のための堅牢なアプローチのようには見えません。
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固有のアプリケーションはわずかであり、どちらが使用されているかを気にせずに両方のプロトコルで動作するはずです。
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に移植することが最優先事項です。
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]は、すべての種類のアプリケーション、特に、アプリケーションデータとしてFTPアドレスなどのIPアドレスを交換するアプリケーションでは機能しません。 これらのメカニズムは、アプリケーションにIPv4一時アドレスを提供し、IPv4通信とIPv6通信の間の変換をローカルで行います。 したがって、これらのIPv4一時アドレスは、ノードスコープでのみ有効です。
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アプリケーションを移植する最も簡単な方法は、1対1のマッピングで古いIPv4 API参照を新しいIPv6 APIに置き換えることです。 これにより、アプリケーションは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-mapped IPv6アドレスを使用してマップされるため、宛先に到達します。IPv6アドレス:: FFFF：x.y.z.wは、IPv4アドレスx.y.z.wを表します。
+----------------------------------------------+
| +------------------------------------------+ |
| | | |
| | 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: 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.
IPv6-onlyサーバー：IPv4クライアントアプリケーションが、ワイルドカードアドレスを使用してデュアルスタックノードで実行されているIPv6-onlyサーバーアプリケーションにデータを送信すると、IPv4クライアントアドレスはデュアルスタックのIPv4-mapped IPv6アドレスとして解釈されます。 ノード。 これにより、IPv6アプリケーションが通信を管理できます。 IPv6サーバーは、このマッピングアドレスを通常のIPv6アドレスであるかのように使用し、通常のIPv6接続を使用します。 ただし、IPv4パケットはノード間で交換されます。 デュアルスタックのカーネルは、IPv4にマップされたIPv6アドレスをIPv4アドレスとして正しく解釈し、その逆も同様です。
IPv6-only client: 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 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専用クライアント：デュアルスタックノードの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サーバーとのみ通信します。これは、マッピングアドレスが無効になっているためです。 このオプションは、アプリケーションがFlow Labelなどの新しい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 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-mapped IPv6アドレスのサポートが（デフォルトで）無効になることに注意してください。 これらに関するセキュリティ上の懸念は正当なものですが、それらを内部的に無効にすると、ワイルドカードアドレスを使用して単一のソケットにbind（）およびlisten（）するために最初に記述されたサーバーアプリケーションの移行メカニズムが壊れます。 これにより、ソフトウェア開発者はデーモンを書き直して、IPv4専用とIPv6専用の2つのソケットを作成し、select（）を使用するように強制します。 ただし、特定のシステムでのIPv4アドレスのマッピング対応は、OS所有者によって制御され、必ずしも開発者によって制御されるわけではありません。 これは、同じOSであっても両方の環境を処理するためにデーモンネットワークコードを書き換える必要があるため、開発者の作業を複雑にします。
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で説明します。
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が有効にならない状況を処理できる必要があります。 もう1つのシナリオは、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.
例は、最初にAF_INET6を試し、次にAF_INETを試し、socket（）コマンドを発行するアプリケーションです。 ただし、カーネルが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サポートの単なる拡張であり、比較的よくあるがしばしば無視されるケースをカバーしています。
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バージョンの依存関係をまとめたものです。
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の両方で動作できます。
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]内にアドレスを配置することが望ましい場合があります。
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を使用する必要があります。
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に適応させるために、このアプリケーショントランスポートモジュールでほとんどの変更を行う必要があります。
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用に変換する必要がある場合に使用されます。
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
IPv6には、getaddrinfo（）とgetnameinfo（）の2つの新しい基本解決関数があります。 1つ目は、ホスト名に設定されたすべてのIPアドレスのリストを返します。 これらのクエリは、1つのプロトコルファミリに制限できます。 たとえば、IPv4のみまたは
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アドレス。 ただし、アプリケーションがすべての種類のノードで動作できるように、構成されたすべてのIPアドレスを取得することをお勧めします。 2番目の関数は、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バージョンの複雑さが増す可能性があることに注意してください-独立したアプリケーションはソースアドレスを指定する必要があります（特にクライアントアプリケーションの場合）。 必須）。
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.
Application Level Framing（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
コネクションレスプロトコル（UDPなど）を使用するアプリケーションでは、通常、アプリケーションのフレーミングが必要です。 これらのアプリケーションには、3つの選択肢があります。（1）IPv6の最大伝送単位（MTU）1280バイト[RFC2460]以下のパケットサイズを使用する、（2）任意の
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.
パケットサイズ、ただし必要に応じて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のIPv6トンネリングオーバーヘッドなど）。 アプリケーションのフレーミングを実装する場合、これらの要因を考慮する必要があります。
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などの名前を保存する必要があります。 この場合、アプリケーションは、実行時またはキャッシュの有効期間中のみ特定のアドレスにバインドされます。 独自のランデブーおよびディスカバリメカニズムを備えた大規模なピアツーピアシステムなど、他の種類のアプリケーションでは、パフォーマンス上の理由からアドレスをキャッシュする必要がありますが、キャッシュされたアドレスは永続的で信頼できる情報として扱われるべきではありません。 非常に動的なネットワークでは、どのような名前解決も不可能な場合があり、ここでもアドレスをキャッシュする必要があります。
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に変更する必要があり、2番目に、ソケット構成オプションを変更する必要があります。
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.
もう1つの問題は、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サービスは、マルチキャストアドレス[ランディング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]）。
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つは、アプリケーションに独立したAPIを提供し、すべての依存関係を隠すIPバージョンを提供する通信ライブラリを構築することです。
To develop IP version - independent applications, the following guidelines should be considered.
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バージョンに依存しません。 構造体in_addr、in6_addr、sockaddr_in、およびsockaddr_in6は避けてください。
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);
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()
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 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の両方がランダムな順序になります。
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解決関数を使用してこれらのソケットを作成する簡単な例を見ていきます。
A simple TCP server socket at service name (or port number string) SERVICE:
サービス名（またはポート番号文字列）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 */
}
}
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);
freeaddrinfo（res）;
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 */
} 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);
freeaddrinfo（res）;
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()
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);
エラー= getnameinfo（（struct sockaddr *）＆ss、sizeof（ss）、addrStr、sizeof（addrStr）、servStr、sizeof（servStr）、NI_NUMERICHOST）;
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);
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（）戻り値のエラー処理を簡素化できます。
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; 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);
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;
} 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 */
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) {
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;
}
}
default:
/* handle other socket errors */
;
}
} else { if (connect(sockfd, aip->ai_addr, aip->ai_addrlen) == 0) break;
} 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);
freeaddrinfo（res）;
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プレフィックスとIPv4アドレスで構成される特別なアドレスのセットを導入します。これらはNAT-PT DNS-ALGによって変換された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アドレスを含む他の種類のアドレス）を区別する必要はありません：これは完全に非実用的です。 作成する場合は、他の場所（カーネル、システムライブラリなど）で実行する必要があります。
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に移行する場合でもサービスの可用性と堅牢性を確保するために、このメモでは、動作中のアドレスが見つかるまでアドレスを循環することにより、アプリケーションを障害に対してより耐性にするいくつかの方法について説明します。 これを適切に行うことは、可用性を維持し、サービスの損失を回避するために重要です。
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アドレスのサポートが（デフォルトで）無効になることに注意してください。 ワイヤ上のこれらに関するセキュリティ上の懸念は正当ですが、内部的に無効にすると、ワイルドカードアドレス[V6MAPPED]を使用して単一のソケットにbind（）およびlisten（）するために最初に記述されたサーバーアプリケーションの1つの移行メカニズムが破損します。 これは、アプリケーションを設計するときに、より詳細に検討する必要があります。
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.
IPバージョンに依存しないアプリケーションの開発に関するガイドラインのいくつか（セクション6）は、最初に[AF-APP]によって提起されました。 アプリケーションの移植ガイドラインを文書化する他の作業も進行中です。 たとえば、[IP-GGF]および[PRT]。 v6opsワーキンググループのメンバーとアプリケーションエリアに有益なコメントをありがとう。 ブライアン・E・カーペンター、アントニオ・ケルビン、スティグ・ヴェナアス、チラユ・パテル、ジョルディ・パレット、ジェイソン・リンに感謝します。 ドキュメントの校正については、Ron Pikeに感謝します。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]ギリガン、R。、トムソン、S。、バウンド、J。、マッキャン、J。、およびW.スティーブンス、「IPv6の基本ソケットインターフェイス拡張」、RFC 3493、2003年2月。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[RFC3542] Stevens、W.、Thomas、M.、Nordmark、E。、およびT. Jinmei、「IPv6用の高度なソケットアプリケーションプログラムインターフェイス（API）」、RFC 3542、2003年5月。
[BIS] Tsuchiya, K., Higuchi, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000.
[BIS]土屋K.、Hi口H.、およびY. Atarashi、「 "Bump-In-the-Stack"テクニック（BIS）を使用したデュアルスタックホスト」、RFC 2767、2000年2月。
[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.
[BIA] Lee、S.、Shin、MK。、Kim、YJ。、Nordmark、E。、およびA.Durand、「Bump-in-the-API（BIA）を使用するデュアルスタックホスト」、RFC 3338、 2002年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden、R。、およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[2893BIS] Nordmark, E. and R. E. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", Work in Progress, June 2004.
[2893BIS] Nordmark、E。、およびR. E. Gilligan、「IPv6ホストおよびルーターの基本的な移行メカニズム」、Work in Progress、2004年6月。
[RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2133, April 1997.
[RFC2133]ギリガン、R。、トムソン、S。、バウンド、J。、およびW.スティーブンス、「IPv6の基本的なソケットインターフェイス拡張」、RFC 2133、1997年4月。
[RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[RFC2732] Hinden、R.、Carpenter、B。、およびL. Masinter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[TextRep] Main, A., "Textual Representation of IPv4 and IPv6 Addresses", Work in Progress, October 2003.
[TextRep] Main、A。、「IPv4およびIPv6アドレスのテキスト表現」、Work in Progress、2003年10月。
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[NAT-PT] Tsirtsis、G.およびP. Srisuresh、「ネットワークアドレス変換-プロトコル変換（NAT-PT）」、RFC 2766、2000年2月。
[DNSTRANS] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational Guidelines", BCP 91, RFC 3901, September 2004.
[DNSTRANS] Durand、A.およびJ. Ihren、「DNS IPv6 Transport Operational Guidelines」、BCP 91、RFC 3901、2004年9月。
[DNSOPV6] Durand, A., Ihren, J. and P. Savola, "Operational Considerations and Issues with IPv6 DNS", Work in Progress, May 2004.
[DNSOPV6] Durand、A.、Ihren、J。、およびP. Savola、「IPv6 DNSの運用上の考慮事項と問題」、Work in Progress、2004年5月。
[AF-APP] Hagino, J., "Implementing AF-independent application", http://www.kame.net/newsletter/19980604/, 2001.
[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.
[V6MAPPED] Hagino、J.、「有害と考えられるIPv4マッピングアドレス」、Work in Progress、2002年4月。
[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.
[IP-GGF] Chown、T.、Bound、J.、Jiang、S.、P。O'Hanlon、「GGF仕様におけるIPバージョンの独立性に関するガイドライン」、Global Grid Forum（GGF）Documentation、work in Progress、9月 2003年。
[Embed-RP] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[Embed-RP] Savola、P。、およびB. Haberman、「ランデブーポイント（RP）アドレスをIPv6マルチキャストアドレスに埋め込む」、RFC 3956、2004年11月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]ハーバーマン、B。、およびD.タラー、「ユニキャストプレフィックスベースのIPv6マルチキャストアドレス」、RFC 3306、2002年8月。
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters, RFC 3678, January 2004.
[RFC3678] Thaler、D.、Fenner、B。、およびB. Quinn、「マルチキャストソースフィルタのソケットインターフェイス拡張、RFC 3678、2004年1月。
[MUL-GW] Venaas, S., "An IPv4 - IPv6 multicast gateway", Work in Progress, February 2003.
[MUL-GW] Venaas、S。、「IPv4-IPv6マルチキャストゲートウェイ」、Work in Progress、2003年2月。
[PRT] Castro, E. M., "Programming guidelines on transition to IPv6 LONG project", Work in Progress, January 2003.
[PRT] Castro、E。M。、「IPv6 LONGプロジェクトへの移行に関するプログラミングガイドライン」、Work in Progress、2003年1月。
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) {
スイッチ（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));
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つが宛先バッファー長として使用されます。
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.
プレゼンテーション形式のアドレスファミリを知っている必要があることに注意してください。
Authors' Addresses
著者のアドレス
Myung-Ki Shin ETRI/NIST 820 West Diamond Avenue Gaithersburg, MD 20899, USA
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
電話：+1 301 975-3613ファックス：+1 301 590-0932電子メール：mshin@nist.gov
Yong-Guen Hong ETRI PEC 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
ヨングンホンETRI PEC 161 305-350大田ユソン区ガジョンドン
Phone: +82 42 860 6447 Fax: +82 42 861 5404 EMail: yghong@pec.etri.re.kr
電話：+82 42860 6447ファックス：+82 42 861 5404電子メール：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
インターネットイニシアティブジャパン株式会社GI野純一郎〒101-0054東京都千代田区神田錦町3-13竹橋安田ビル
Phone: +81-3-5259-6350 Fax: +81-3-5259-6351 EMail: itojun@iijlab.net
電話：03-5259-6350 FAX：03-5259-6351電子メール：itojun@iijlab.net
Pekka Savola CSC/FUNET Espoo, Finland
Pekka Savola CSC / FUNET Espoo、フィンランド
EMail: psavola@funet.fi
メール：psavola@funet.fi
Eva M. Castro Rey Juan Carlos University (URJC) Departamento de Informatica, Estadistica y Telematica C/Tulipan s/n 28933 Madrid - SPAIN
エヴァ・M・カストロ・レイ・フアン・カルロス大学（URJC）エスタディスティカ・イ・テレマティカC / Tulipan s / n 28933マドリード-スペイン
EMail: eva@gsyc.escet.urjc.es
メール：eva@gsyc.escet.urjc.es
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
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.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78および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.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（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.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。