RFC4038 日本語訳
4038 Application Aspects of IPv6 Transition. M-K. Shin, Ed., Y-G.Hong, J. Hagino, P. Savola, E. M. Castro. March 2005. (Format: TXT=69727 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループM Kをネットワークでつないでください。 エド、よじ登ってください。コメントのために以下を要求してください。 4038年のETRI/NISTカテゴリ: 情報のY-G。 商館ETRI J.Hagino IIJ P.Savola CSC/FUNET E.M.カストロのGSYC/URJC行進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)インターネット協会(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ネットワークが配布されて、ネットワーク変遷について議論するとき、IPプロトコルサポートを開発するIPv6ホスト、およびアプリケーションで最も良い戦略で動きながらアプリケーションでIPv6サポートを可能にする方法を考えるべきです。 このドキュメントはアプリケーション変遷のシナリオと局面を指定します。 また、それは過渡期の間どうIPのバージョンから独立しているアプリケーションを開発するかに関するガイドラインを提案します。
Shin, Ed., et al. Informational [Page 1] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[1ページ]のRFC4038アプリケーション局面
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。 Presentation Using inet_ntop()へのバイナリー… 30 A.2。 Binary Using inet_pton()へのプレゼンテーション… 31人の作者のアドレス… 32 完全な著作権宣言文… 33
Shin, Ed., et al. Informational [Page 2] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[2ページ]のRFC4038アプリケーション局面
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.
アプリケーションは、セクションで説明された多くのテクニックの1つを使用するのによるIPv6(そして、IPv4)が4 2--歳であるとサポートするように変更されなければならないでしょう。 そのようなアプリケーションを開発するためのガイドラインはセクション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
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[3ページ]のRFC4038アプリケーション局面
+-------------------+
| appv4 | (appv4 - IPv4-only applications)
+-------------------+
| TCP / UDP / others| (transport protocols - TCP, UDP,
+-------------------+ SCTP, DCCP, etc.)
| IPv4 | IPv6 | (IP protocols supported/enabled in the OS)
+-------------------+
+-------------------+ | appv4| (appv4--IPv4だけアプリケーション) +-------------------+ | TCP / UDP /他のもの| (トランスポート・プロトコル--TCP、UDP、+、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、+ SCTP、DCCPなど) | IPv4| IPv6| (OSでサポートされるか、または可能にされたIPプロトコル) +-------------------+
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)
+-------------------+
+-------------------+(appv4--IPv4だけアプリケーション)| appv4| appv6| (appv6--IPv6だけアプリケーション) +-------------------+ | TCP / UDP /他のもの| (トランスポート・プロトコル--TCP、UDP、+、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、+ SCTP、DCCPなど) | IPv4| IPv6| (OSでサポートされるか、または可能にされたIPプロトコル) +-------------------+
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)
+-------------------+
+-------------------+ | appv4/v6| (appv4/v6、アプリケーションが+をサポートする、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、+、IPv4とIPv6の両方) | TCP / UDP /他のもの| (トランスポート・プロトコル--TCP、UDP、+、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、+ SCTP、DCCPなど) | IPv4| IPv6| (OSでサポートされるか、または可能にされたIPプロトコル) +-------------------+
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)
+-------------------+
+-------------------+ | appv4/v6| (appv4/v6、アプリケーションが+をサポートする、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、+、IPv4とIPv6の両方) | TCP / UDP /他のもの| (トランスポート・プロトコル--TCP、UDP、+、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、+ SCTP、DCCPなど) | IPv4| (OSでサポートされるか、または可能にされたIPプロトコル) +-------------------+
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
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[4ページ]のRFC4038アプリケーション局面
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つ(例えば、ピングと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
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[5ページ]のRFC4038アプリケーション局面
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ネーム・リゾルバは送付先アドレスのリストを集めます。 質問を運ぶのにIPv4かIPv6のどちらかを使用することによって、DNS質問と応答を送ります、データレコード[DNSTRANS]のプロトコルバージョンにかかわらず。
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サービスのためのデュアルスタックマシンで動いて、AAAA記録がDNSにある状態でこのホストが記載されると、クライアントアプリケーションはサーバ・アプリケーションに接続しないでしょう。 これは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の上のそれらのいくつかだけを提供するなら、DNS名は物理的なマシンのためのただ一つの名前だけではなく、それぞれのこれらのサービス(関連A/AAAA記録がある)のサービスかグループのために加えられるかもしれません、また、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. ApplicationのバージョンをManyにサポートするのは、Difficultです。
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
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[6ページ]のRFC4038アプリケーション局面
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
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[7ページ]のRFC4038アプリケーション局面
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.
いくつかの場合(例えば、どんなソースコードもいつ利用可能ではありませんか)、既存のIPv4アプリケーションがスタックのBump[BIS]か中のBumpであるなら動作できる、-、-API[BIA]メカニズムはノードにインストールされます。 私たちは、アプリケーションソースコードが利用可能であるときに、アプリケーション開発者がこれらのメカニズムを使用しないことを強く勧めます。 また、ソフトウェアを移植しないか、または移植するのを遅らせる口実としてそれらを使用するべきではありません。
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で説明された問題は起こります--(デュアルスタックシステムのIPv4サーバに接続する[BIS]/[BIA]ノードトライにおける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仮の住所は単にノード範囲で有効です。
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アプリケーションを移植する最も簡単な方法は1〜1つのマッピングで新しいIPv6APIとの古いIPv4APIリファレンスを代入することです。 このように、アプリケーションはIPv6になるでしょう。 このIPv6だけソースコードがIPv4だけノードで働くことができないので、古いIPv4アプリケーションはこれらのノードで維持されるべきです。 これは、異なったプロトコルバージョンで動作する2つの同様のアプリケーションを持っているのを必要とします、それらが実行しているノード(例えば、telnetとtelnet6)によって。 同じ1アプリケーションあたりのソースコードの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ノードの両方で共同利用します。 それらのアドレスがIPv4によって写像されたIPv6アドレスを使用することによって写像されるので、デュアルスタックノードにおけるIPv6アプリケーションに行くIPv4パケットは目的地に到着します: 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変遷行進2005年の情報[8ページ]のRFC4038アプリケーション局面
+----------------------------------------------+
| +------------------------------------------+ |
| | | |
| | IPv6-only applications | |
| | | |
| +------------------------------------------+ |
| | |
| +------------------------------------------+ |
| | | |
| | TCP / UDP / others (SCTP, DCCP, etc.) | |
| | | |
| +------------------------------------------+ |
| IPv4-mapped | | IPv6 |
| IPv6 addresses | | addresses |
| +--------------------+ +-------------------+ |
| | IPv4 | | IPv6 | |
| +--------------------+ +-------------------+ |
| IPv4 | | |
| addresses | | |
+--------------|-----------------|-------------+
| |
IPv4 packets IPv6 packets
+----------------------------------------------+ | +------------------------------------------+ | | | | | | | IPv6だけアプリケーション| | | | | | | +------------------------------------------+ | | | | | +------------------------------------------+ | | | | | | | TCP / UDP /他のもの(SCTP、DCCPなど) | | | | | | | +------------------------------------------+ | | IPv4によって写像されています。| | IPv6| | IPv6アドレス| | アドレス| | +--------------------+ +-------------------+ | | | IPv4| | IPv6| | | +--------------------+ +-------------------+ | | IPv4| | | | アドレス| | | +--------------|-----------------|-------------+ | | IPv4パケットIPv6パケット
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だけサーバ: IPv4クライアントアプリケーションがワイルドカードアドレスを使用することによってデュアルスタックノードで動くIPv6だけサーバ・アプリケーションにデータを送るとき、IPv4クライアントアドレスはデュアルスタックノードのIPv4によって写像されたIPv6アドレスとして解釈されます。 これで、IPv6アプリケーションはコミュニケーションを管理できます。 IPv6サーバはまるでそれが通常のIPv6アドレスと、普通のIPv6接続であるかのようにこの写像しているアドレスを使用するでしょう。 しかしながら、ノードの間でIPv4パケットを交換するでしょう。 デュアルスタックがあるカーネルはIPv4ものとして適切にIPv4によって写像されたIPv6アドレスを解釈します、そして、逆もまた同様です。
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
IPv6だけクライアント: 特別なヒント(AI_V4MAPPED)が与えられないと、デュアルスタックノードにおけるIPv6だけクライアントアプリケーションはホスト名解決API機能からIPv4によって写像されたアドレスを受け取らないでしょう。 それです。
Shin, Ed., et al. Informational [Page 9] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[9ページ]のRFC4038アプリケーション局面
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アドレスと、普通の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.
それぞれ、V6ONLYが設定するIPV6_で、IPv6だけサーバ・アプリケーションはIPv6ノード、およびIPv6サーバだけをもっているIPv6だけクライアントとコミュニケートするだけでしょう、写像しているアドレスが無効にされたとき。 アプリケーションがFlow Labelなどの新しいIPv6の特徴を使用するなら、このオプションは役に立つかもしれません。 IPv4とのコミュニケーションが必要であるなら、IPV6_V6ONLYを使用してはいけませんか、またはデュアルスタックアプリケーションを使用しなければなりません、セクション4.3で説明されるように。
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. アプリケーション(ことによると、'6'で、名前で付く)の2つの異なった見解を配布してください。
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. そしてアプリケーション缶の(or should)が、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
いくつかのシステムが内部のIPv4によって写像されたIPv6アドレスのサポートを無効にすることに(デフォルトで)注意してください。 これらに関する安全上の配慮は正統ですが、内部的にそれらを無効にするのは元々ワイルドカードアドレスを使用することによって単一のソケットまで()を縛って、()を聴くために書かれたサーバ・アプリケーションのために1つの変遷メカニズムを壊します。 これによって、ソフトウェア開発者は2個の別々のソケット(IPv6のためのIPv4だけともう片方だけ、そして、選んだ()を使用する1)を作成するためにやむを得ずデーモンを書き直します。 しかしながら、どんな特定のシステムの上もIPv4アドレスをマッピング可能にすることは必ずではなくOS所有者によって制御されます。
Shin, Ed., et al. Informational [Page 10] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[10ページ]のRFC4038アプリケーション局面
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.
開発者で。 これは開発者の仕事を複雑にします、彼らが現在両方の環境を扱うためにデーモンネットワークコードを書き直さなければならないとき、同じ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接続が失敗するならアプリケーションは自動的に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をサポートするでしょう。 ひも()実装のいくつかの違いがすなわち、1つが最初に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
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[11ページ]のRFC4038アプリケーション局面
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.
最初に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サポートの拡大です、1つの比較的一般的な、しかし、しばしば無視されたケースをカバーしていて。
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
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[12ページ]のRFC4038アプリケーション局面
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進法、およびIPv6に書かれていた状態で4つの八重奏を切り離すのがコロンを使用する、(:、)、16進法[RFC3513]に書かれたそれぞれの組の八重奏を切り離すために。 アドレスで例えばポートナンバーを指定できなければならない場合(以下を見る)では、角括弧[TextRep]でアドレスを置くのが必要であるのは望ましいかもしれません。
Shin, Ed., et al. Informational [Page 13] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[13ページ]のRFC4038アプリケーション局面
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に移植するとき、新しいIPv6APIに適合させられるためにこのアプリケーション輸送モジュールでほとんどの変更を行うべきです。
Shin, Ed., et al. Informational [Page 14] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[14ページ]のRFC4038アプリケーション局面
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アドレスData Structuresは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.
- 逆もまた同様にプレゼンテーション形式への2進のアドレス表現をアドレス変換機能が変換するConversion Functionsに扱ってください。 新しい変換機能は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 Functions These機能はコミュニケーションを管理します。 彼らの署名はジェネリックソケットアドレス構造に基づいて定義されます。 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.
- そして、異なったコミュニケーションモデルがInput/出力のために構成されるとき、ネットワークConfiguration Options Theseが使用されている、(入出力) 操作(ブロッキング/「非-妨げ」、入出力マルチプレクシングなど)、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
IPv6と共に、2ニュー・ベーシックの解決機能、getaddrinfo()、およびgetnameinfo()があります。 1番目はホスト名のためのすべての構成されたIPアドレスのリストを返します。 1つのプロトコルファミリーにこれらの質問を抑制できます。 例えば、IPv4だけか唯一です。
Shin, Ed., et al. Informational [Page 15] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[15ページ]のRFC4038アプリケーション局面
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アドレスに関連づけられたホスト名を返します。
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は複数の1ノードあたりの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アドレスをレゾルバに求めます。 レゾルバはホスト名から1セットの有効な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.
Application Level Framing(ALF)アーキテクチャはトランスポート層の中に伝統的に落ちるメカニズムを制御します。 ALFを実装するアプリケーションはしばしばApplication Data Units(ADUs)にデータをpacketizingするのに原因となります。 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) いずれも使用するために1280バイト[RFC2460]、(2)のIPv6の最小のMaximum Transmission Unit(MTU)ほど大きくないパケットサイズを使用するために
Shin, Ed., et al. Informational [Page 16] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[16ページ]のRFC4038アプリケーション局面
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がPath MTUなどの荷重倍数かそれともIPv4かIPv6が使用されているかどうかに(異なったヘッダーサイズ、可能なIPv4のIPv6トンネリングオーバーヘッドなどによる)依存することに注意してください。 アプリケーション縁どりが実装されるとき、これらの要素は考慮に入れられなければなりません。
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.
可能であるときに、アプリケーションはアドレスの代わりにFQDNsか他のプロトコルから独立しているアイデンティティなどの名前を保存するべきです。 この場合、アプリケーションは特有へのバウンドだけがランタイム、またはキャッシュの持続時間のために生涯を扱うということです。 他のタイプのそれら自身のランデブーと発見メカニズムがある大規模なピアツーピアシステムなどの応用は、性能理由でアドレスをキャッシュする必要があるかもしれませんが、永久的で、信頼できる情報としてキャッシュされたアドレスを扱うべきではありません。 非常にダイナミックなネットワークでは、どんな形式の名前解決も不可能であるかもしれません、そして、ここで、一方、アドレスをキャッシュしなければなりません。
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ものに変えなければなりません、そして、2番目に、ソケット設定オプションを変えなければなりません。
Shin, Ed., et al. Informational [Page 17] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[17ページ]のRFC4038アプリケーション局面
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マルチキャストにはInterdomainマルチキャストのための伝統的なAny Source Multicastのための標準化されたメカニズムがまだないということです。 Any Source Multicast(ASM)かSource特有の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サービスは単にRendezvous Pointアドレスをマルチキャストアドレスに埋め込むメソッドで利用可能です[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]).
「マルチ-パーティー」会議アプリケーションに関する別のピアツーピアアプリケーションの問題と同様のジェネリック問題はセッションのすべてのユーザが何らかのフォームの同じプロトコルバージョン(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の依存を避けるべきです。 しかしながら、より良いソリューションの1つはIPの依存が必要であるなら、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バージョン独立者であるべきです。 _addrのstructs、中にsockaddr_があるin6_addr、およびsockaddr_in6を避けるべきです。
Shin, Ed., et al. Informational [Page 18] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[18ページ]のRFC4038アプリケーション局面
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()に通過されると仮定してください。 1つは_addrでstructを使用するか、そして、struct in6_addr、示す付加的なパラメタがファミリーに演説するという以下の結果:
struct in_addr in4addr;
struct in6_addr in6addr;
/* IPv4 case */
foo(&in4addr, AF_INET);
/* IPv6 case */
foo(&in6addr, AF_INET6);
_addr in4addrのstruct。 struct in6_addr in6addr。 /*IPv4は*/foo(in4addr、AF_INET)をケースに入れます。 /*IPv6は*/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_ストレージを使用するべきです:
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);
struct sockaddr_ストレージss。 int sslen。 /*AF独立者! - 指針*//*メモを渡すときにはsockaddrを使用してください: それがまた、明らかに*/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()
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
localhost。 IN A127.0.0.1IN A127.0.0、AAAAの.2:、: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
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[19ページ]のRFC4038アプリケーション局面
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:
Hardcoding AF依存する知識はプログラムで好まれません。 以下のそれなどの構造物は避けられるべきです:
/* BAD EXAMPLE */
switch (sa->sa_family) {
case AF_INET:
salen = sizeof(struct sockaddr_in);
break;
}
/*BAD EXAMPLE*/スイッチ(sa>のsa_ファミリー)AF_INETをケースに入れてください: salenはsizeof(中にstruct sockaddr_がある状態で)と等しいです; 壊れてください;。
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:
サービス名(または、数が結ぶポート)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;
/**悪例: *が6.3で指定したようにgetaddrinfo輪を実装しません。 これは以下の1つをもたらすかもしれません: * - IPv6サーバ、ワイルドカードアドレスで聴くIPv4を許容する*がIPv4によって写像されたIPv6を通してアドレスを扱います。 * - IPv4サーバ、IPv6が有効にされないなら、*--IPv6だけサーバ、IPv6は有効にされますが、IPv4によって写像されたIPv6*アドレスがデフォルトで使用されないか、そして、または*--すべての*システムだけでgetaddrinfoがIPv6をサポートするならサーバがないのは有効にされないで、ソケット(AF_INET6、…)は*誤りと共に出ます。 */struct addrinfoヒント、*res。 int誤り、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 */
memset(ヒント、0、sizeof(ヒント))。 hints.ai_旗はAI_PASSIVEと等しいです。 hints.ai_ファミリーはAF_UNSPECと等しいです。 hints.ai_socktypeはSOCK_STREAMと等しいです。 誤りはgetaddrinfo(NULL、SERVICE、ヒント、およびres)と等しいです。 (誤り!=0)である、/*ハンドルgetaddrinfo誤り*/
Shin, Ed., et al. Informational [Page 20] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[20ページ]のRFC4038アプリケーション局面
}
}
sockfd = socket(res->family, res->ai_socktype, res->ai_protocol);
if (sockfd < 0) {
/* handle socket error */
}
sockfdはソケット(res>のファミリー、res>のai_socktypeであって、res>のai_プロトコル)と等しいです。 (sockfd<0)です。/*ハンドルソケット誤り*/
if (bind(sockfd, res->ai_addr, res->ai_addrlen) < 0) {
/* handle bind error */
}
(ひも(sockfdであって、res>のai_addr、res>のai_addrlen)の<0)です。/*ハンドルひも誤り*/
/* ... */
/* ... */
freeaddrinfo(res);
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;
/**悪例: *が6.3で指定したようにgetaddrinfo輪を実装しません。 これは以下の1つをもたらすかもしれません: * - *--IPv6の目的地、*とのIPv6接続--しかし、IPv4の目的地とのIPv4接続、IPv6の目的地に達しようとする試み(見つけられて、AAAA*が記録するなら)、後退のない失敗、: * o getaddrinfoはIPv6をサポートしますが、システムはどんな*もしません。IPv6によって可能にされなく、存在していないので低下しながら掘るo IPv6がo IPv6サーバが達したタイムアウト*、しかし、サービスを例えば、TCP*に支持するか、または*は遠くで*をfirewalledしました。--最初の目的地に達していないなら、次の記録*/struct addrinfoヒントへの*後退が全くありません、*res。 int誤り、sockfd。
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
memset(ヒント、0、sizeof(ヒント))。 hints.ai_ファミリーはAF_UNSPECと等しいです。 hints.ai_socktypeはSOCK_STREAMと等しいです。
error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}
誤りはgetaddrinfoと等しいです(SERVER_NODE、SERVICE、ヒント、およびres)。 (誤り!=0)です。/*ハンドルgetaddrinfo誤り*/
Shin, Ed., et al. Informational [Page 21] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[21ページ]のRFC4038アプリケーション局面
sockfd = socket(res->family, res->ai_socktype, res->ai_protocol);
if (sockfd < 0) {
/* handle socket error */
}
sockfdはソケット(res>のファミリー、res>のai_socktypeであって、res>のai_プロトコル)と等しいです。 (sockfd<0)です。/*ハンドルソケット誤り*/
if (connect(sockfd, res->ai_addr, res->ai_addrlen) < 0 ) {
/* handle connect error */
}
(<0を接続します(sockfdであって、res>のai_addr、res>のai_addrlen))/*ハンドルは誤り*/を接続します。
/* ... */
/* ... */
freeaddrinfo(res);
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()
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同等物はAppendix 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;
struct sockaddr_ストレージss。 addrStr[INET6_ADDRSTRLEN]を炭にしてください。 servStr[NI_MAXSERV]を炭にしてください。 int誤り。
/* fill ss structure */
/*中詰めss構造*/
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)。
Shin, Ed., et al. Informational [Page 22] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[22ページ]のRFC4038アプリケーション局面
Conversions from presentation format to network address structure can be written as follows:
以下の通りプレゼンテーション形式からネットワーク・アドレス構造までの変換を書くことができます:
struct addrinfo hints, *res;
char addrStr[INET6_ADDRSTRLEN];
int error;
struct addrinfoヒント、*res。 addrStr[INET6_ADDRSTRLEN]を炭にしてください。 int誤り。
/* fill addrStr buffer */
/*中詰めaddrStrバッファ*/
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
memset(ヒント、0、sizeof(ヒント))。 hints.ai_ファミリーはAF_UNSPECと等しいです。
error = getaddrinfo(addrStr, NULL, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}
誤りはgetaddrinfo(addrStr、NULL、ヒント、およびres)と等しいです。 (誤り!=0)です。/*ハンドルgetaddrinfo誤り*/
/* res->ai_addr contains the network address structure */
/* ... */
freeaddrinfo(res);
/*res>のai_addrはネットワーク・アドレス構造*//*を含んでいます… */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()から複数のアドレスを返すとき、接続が成功するまで、私たちはそれらを皆、試みるべきです。 失敗がソケット()で起こるときには、()(()、またはある他の機能、コードが次のアドレスを試みに行くべきであるひも)を接続してください。
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.
以下に注意してください。 以下の例、値のエラー処理を簡素化できるだろうソケット()リターンでは、いつも続いて、特定のエラー番号の特別な照合を実行することの代わりにソケット輪を続けましょう。
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;
#MAXSOCK2struct addrinfoヒント、*resを定義してください。 int誤り、sockfd[MAXSOCK]、nsock=0。
memset(&hints, 0, sizeof(hints));
hints.ai_flags = AI_PASSIVE;
hints.ai_family = AF_UNSPEC;
memset(ヒント、0、sizeof(ヒント))。 hints.ai_旗はAI_PASSIVEと等しいです。 hints.ai_ファミリーはAF_UNSPECと等しいです。
Shin, Ed., et al. Informational [Page 23] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[23ページ]のRFC4038アプリケーション局面
hints.ai_socktype = SOCK_STREAM;
hints.ai_socktypeはSOCK_STREAMと等しいです。
error = getaddrinfo(NULL, SERVICE, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}
誤りはgetaddrinfo(NULL、SERVICE、ヒント、およびres)と等しいです。 (誤り!=0)です。/*ハンドルgetaddrinfo誤り*/
for (aip=res; aip && nsock < MAXSOCK; aip=aip->ai_next) {
sockfd[nsock] = socket(aip->ai_family,
aip->ai_socktype,
aip->ai_protocol);
(aip=res; aipする、<MAXSOCK; aip=aip->aiな_次をnsockする、)、sockfd[nsock]はソケット(aip>のaiの_家族の、そして、aip>のai_socktypeであって、aip>のai_プロトコル)と等しいです。
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;
(sockfd[nsock]<0)である、errnoを切り換えてください、ケースEAFNOSUPPORT: EPROTONOSUPPORTをケースに入れてください: /**、例えば、*(aip>のai_次)が続くなら最後のアドレスファミリー、*がセクション4.4*/を見るまでの誤りをサボってください、。
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;
}
ほか、=1のint。 /*任意: (aip>のai_ファミリー=AF_INET6)であるなら、より良い、しかし、二元的にワイルドカードアドレスに拘束力がある*/を扱う、setsockopt、(sockfd[nsock]、IPPROTO_IPV6、(炭*)の、そして、オンなIPV6_V6ONLY、sizeof(on))、;、/*誤りが無視された*/である (ひも(sockfdの[nsock]の、そして、aip>のai_addr、aip>のai_addrlen)の<0)です。/*はひもの誤り*/閉鎖(sockfd[nsock])を扱います; 続いてください;。
Shin, Ed., et al. Informational [Page 24] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[24ページ]のRFC4038アプリケーション局面
if (listen(sockfd[nsock], SOMAXCONN) < 0) {
/* handle listen errors */
close(sockfd[nsock]);
continue;
}
}
nsock++;
}
freeaddrinfo(res);
(<0を聴きます(sockfd[nsock]、SOMAXCONN))、/*ハンドルが誤り*/閉鎖([nsock]をsockfdします)を聴く、; 続いてください;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;
struct addrinfoヒント、*res、*aip。 int sockfd、誤り。
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
memset(ヒント、0、sizeof(ヒント))。 hints.ai_ファミリーはAF_UNSPECと等しいです。 hints.ai_socktypeはSOCK_STREAMと等しいです。
error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}
誤りはgetaddrinfoと等しいです(SERVER_NODE、SERVICE、ヒント、およびres)。 (誤り!=0)です。/*ハンドルgetaddrinfo誤り*/
for (aip=res; aip; aip=aip->ai_next) {
(次のaip=res; aip;aip=aip->ai_)
sockfd = socket(aip->ai_family,
aip->ai_socktype,
aip->ai_protocol);
sockfdはソケット(aip>のaiの_家族の、そして、aip>のai_socktypeであって、aip>のai_プロトコル)と等しいです。
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;
(sockfd<0)である、errnoを切り換えてください、EAFNOSUPPORTをケースに入れてください: ほかにEPROTONOSUPPORTをケースに入れてください: /**、例えば、*(aip>のai_次)が続くなら最後のアドレスファミリー、*がセクション4.4*/を見るまでの誤りをサボってください、/*は未知のプロトコル誤り*/中断を扱います。
Shin, Ed., et al. Informational [Page 25] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[25ページ]のRFC4038アプリケーション局面
}
}
default:
/* handle other socket errors */
;
}
デフォルト: /*ハンドル他のソケット誤り*/。 }
} else {
if (connect(sockfd, aip->ai_addr, aip->ai_addrlen) == 0)
break;
ほか、((sockfdであって、aip>のai_addr、aip>のai_addrlen)=0を接続します)中断であるなら。
/* handle connect errors */
close(sockfd);
sockfd=-1;
}
}
/*ハンドルは誤り*/閉鎖(sockfd)を接続します。 sockfd=-1。 } }
if (sockfd > 0) {
/* socket connected to server address */
(sockfd>0)である、/*ソケットはサーバアドレス*/に接続しました。
/* ... */
}
/* ... */ }
freeaddrinfo(res);
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]は太平洋標準時のNAT接頭語について形成された特別なアドレスとNAT-PT DNS-ALGによってIPv4アドレスに翻訳されて、これらが参照するIPv4アドレスを紹介します。 いくつかの場合、1つがこれらを異なって扱うように誘惑されるかもしれません。
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は翻訳したこと」が以下を扱います(または、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
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[26ページ]のRFC4038アプリケーション局面
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]を使用することによって単一のソケットまで()を縛って、()を聴くために書かれたサーバ・アプリケーションのために1つの変遷メカニズムを壊します。 アプリケーションが設計されているとき、これはさらに詳細に考えられるべきです。
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.
IPのバージョンから独立しているアプリケーション(セクション6)の開発のためのガイドラインのいくつかが最初に、[AF-APP]によって持って来られました。 また、ドキュメントアプリケーションポーティングガイドラインに対する他の仕事は進行していました。 例えば、[IP-GGF]と[PRT。] 役に立つコメントについてv6opsワーキンググループとアプリケーション部のメンバーに感謝申し上げます。 特別な感謝はこのドキュメントの大量のレビューのためのブライアンE.Carpenter、アントニオQuerubin、スティVenaas、Chirayuパテル、ジョルディPalet、およびジェイソン・リンのためです。 私たちは、ドキュメントを校正するためにロンPikeを承認します。
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.
[RFC3493] ギリガンとR.とトムソンとS.とバウンドとJ.とマッキャン、J.とW.スティーブンス、「IPv6"、RFC3493、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]スティーブンス(W.、トーマス、M.、Nordmark、E.、およびT.Jinmei)は、「2003年5月にIPv6"、RFC3542年のソケット適用業務プログラム・インタフェース(API)を進めました」。
[BIS] Tsuchiya, K., Higuchi, H., and Y. Atarashi, "Dual Stack
Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC
2767, February 2000.
[BIS]Tsuchiya、K.、Higuchi、H.、およびY.Atarashi、「(2回)「スタックでの隆起」のテクニックを使用しているデュアルスタックホスト」、RFC2767、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] リー、S.はよじ登られます、M K.、キム、Nordmark、E.とA.ジュランド、「「APIでの隆起」(BIA)を使用しているデュアルスタックホスト」RFC3338、Y-J.、2002年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
Shin, Ed., et al. Informational [Page 27] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[27ページ]のRFC4038アプリケーション局面
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
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.
[2893BIS] 「IPv6ホストとルータのための基本的な変遷メカニズム」というNordmark、E.、およびR.E.ギリガンは進歩、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"、RFC2133、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.、大工、B.、およびL.Masinter、「URLの文字通りのIPv6アドレスのための形式」、RFC2732、1999年12月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[TextRep] Main, A., "Textual Representation of IPv4 and IPv6
Addresses", Work in Progress, October 2003.
[TextRep] メイン、A.、「IPv4とIPv6アドレスの原文の表現」が進歩、2003年10月に働いています。
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[太平洋標準時のNAT]TsirtsisとG.とP.Srisuresh、「アドレス変換をネットワークでつないでください--翻訳(太平洋標準時のNAT)について議定書の中で述べる」、RFC2766、2000年2月。
[DNSTRANS] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
Guidelines", BCP 91, RFC 3901, September 2004.
[DNSTRANS]ジュランドとA.とJ.Ihren、「DNS IPv6輸送運用指針」、BCP91、RFC3901、2004年9月。
[DNSOPV6] Durand, A., Ihren, J. and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", Work in
Progress, May 2004.
[DNSOPV6] 「IPv6 DNSの操作上の問題と問題」というジュランド、A.、Ihren、J.、およびP.Savolaは進歩、2004年5月に働いています。
[AF-APP] Hagino, J., "Implementing AF-independent application",
http://www.kame.net/newsletter/19980604/, 2001.
J. [AF-APP]Hagino、 http://www.kame.net/newsletter/19980604/ 、「AFから独立しているアプリケーションを実装する」2001。
[V6MAPPED] Hagino, J., "IPv4 mapped address considered harmful",
Work in Progress, April 2002.
[V6MAPPED] Hagino、J.、「IPv4は有害であると考えられたアドレスを写像した」Progress、2002年4月のWork。
[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.、江、S.、およびP.オーハンロン(「GGF仕様によるIPバージョン独立のためのガイドライン」、Global Grid Forum(GGF)ドキュメンテーション)はProgress(2003年9月)で働いています。
Shin, Ed., et al. Informational [Page 28] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[28ページ]のRFC4038アプリケーション局面
[Embed-RP] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", RFC
3956, November 2004.
[RPを埋め込みます]のSavola、P.、およびB.ハーバーマン、「ランデブーポイントを埋め込んで、(RP)はIPv6でマルチキャストアドレスを扱います」、RFC3956、2004年11月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3306] ハーバーマンとB.とD.ターレル、「ユニキャスト接頭語ベースのIPv6マルチキャストアドレス」、RFC3306、2002年8月。
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters, RFC 3678,
January 2004.
[RFC3678] ターレルとD.とフェナー、B.とB.クイン、「マルチキャストソースフィルタのためのソケットインタフェース拡大、RFC3678、2004年1月。」
[MUL-GW] Venaas, S., "An IPv4 - IPv6 multicast gateway", Work in
Progress, February 2003.
[MUL-GW]Venaas、S.、「IPv4--、IPv6マルチキャストゲートウェイ、」、Progress、2月2003日のWork
[PRT] Castro, E. M., "Programming guidelines on transition to
IPv6 LONG project", Work in Progress, January 2003.
[PRT]カストロ、E.M.、「IPv6 LONGへの変遷に関するガイドラインが映し出すプログラミング」、ProgressのWork、2003年1月。
Shin, Ed., et al. Informational [Page 29] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[29ページ]のRFC4038アプリケーション局面
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.
getaddrinfo()/getnameinfo()機能とは逆にinet_ntop()/inet_pton()が変換で範囲識別子を失うことに(例えば、リンクローカルのアドレスと共に使用されるなら)注意してください。
A.1. Binary to Presentation Using inet_ntop()
A.1。 Presentation Using inet_ntopに、2進です。()
Conversions from network address structure to presentation format can be written as follows:
以下の通りネットワーク・アドレス構造からプレゼンテーション形式までの変換を書くことができます:
struct sockaddr_storage ss;
char addrStr[INET6_ADDRSTRLEN];
struct sockaddr_ストレージss。 addrStr[INET6_ADDRSTRLEN]を炭にしてください。
/* fill ss structure */
/*中詰めss構造*/
switch (ss.ss_family) {
スイッチ(ss.ss_ファミリー)
case AF_INET:
inet_ntop(ss.ss_family,
&((struct sockaddr_in *)&ss)->sin_addr,
addrStr,
sizeof(addrStr));
break;
AF_INETをケースに入れてください: inet_ntop(ss.ss_ファミリー、(*のstruct sockaddr_)、およびss)>は_addr、addrStr、sizeof(addrStr)を犯します。 壊れてください。
case AF_INET6:
inet_ntop(ss.ss_family,
&((struct sockaddr_in6 *)&ss)->sin6_addr,
addrStr,
sizeof(addrStr));
AF_INET6をケースに入れてください: sin6_がaddrするinet_ntop(ss.ss_ファミリー、(struct sockaddr_in6*)、およびss)>、addrStrは(addrStr)をsizeofします。
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より長いので、最初のものは目的地バッファ長として使用されます。
Shin, Ed., et al. Informational [Page 30] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[30ページ]のRFC4038アプリケーション局面
A.2. Presentation to Binary Using inet_pton()
A.2。 Binary Using 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];
struct sockaddr_ストレージss。 *罪におけるstruct sockaddr_。 struct sockaddr_in6*sin6。 addrStr[INET6_ADDRSTRLEN]を炭にしてください。
/* fill addrStr buffer and ss.ss_family */
/*中詰めaddrStrバッファとss.ss_ファミリー*/
switch (ss.ss_family) {
case AF_INET:
sin = (struct sockaddr_in *)&ss;
inet_pton(ss.ss_family,
addrStr,
(sockaddr *)&sin->sin_addr));
break;
スイッチ(ss.ss_ファミリー)、ケースAF_INET: 罪=(*のstruct sockaddr_)とss; inet_pton(ss.ss_ファミリー、addrStr、(sockaddr*)、および罪->は_addrを犯す); 壊れてください。
case AF_INET6:
sin6 = (struct sockaddr_in6 *)&ss;
inet_pton(ss.ss_family,
addrStr,
(sockaddr *)&sin6->sin6_addr);
break;
AF_INET6をケースに入れてください: sin6は(struct sockaddr_in6*)とssと等しいです。 inet_は(ss.ss_ファミリー、addrStr、(sockaddr*)、およびsin6_がaddrするsin6->)をptonします。 壊れてください。
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
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[31ページ]のRFC4038アプリケーション局面
Authors' Addresses
作者のアドレス
Myung-Ki Shin ETRI/NIST 820 West Diamond Avenue Gaithersburg, MD 20899, USA
ゲイザースバーグ、ミュング-気向こうずねのETRI/NIST820の西ダイヤモンドのAvenue MD 20899、米国
Phone: +1 301 975-3613 Fax: +1 301 590-0932 EMail: mshin@nist.gov
以下に電話をしてください。 +1 301 975-3613Fax: +1 301 590-0932 メールしてください: mshin@nist.gov
Yong-Guen Hong ETRI PEC 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
ヤング-Guen商館ETRI胸筋161Gajeong-ドング、Yuseong-Gu、大田305-350、韓国
Phone: +82 42 860 6447 Fax: +82 42 861 5404 EMail: yghong@pec.etri.re.kr
以下に電話をしてください。 +82 42 860 6447Fax: +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
インターネットイニシアティブ株式会社竹橋安田Bldg、6月-ichiro itojun HAGINOが研究所について研究する、3-13 神田西木町、千代田区、東京101-0054(日本)
Phone: +81-3-5259-6350 Fax: +81-3-5259-6351 EMail: itojun@iijlab.net
以下に電話をしてください。 +81-3-5259-6350 Fax: +81-3-5259-6351 メールしてください: itojun@iijlab.net
Pekka Savola CSC/FUNET Espoo, Finland
ペッカ・Savola CSC/FUNETエスポー(フィンランド)
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)Departamento de Informatica、Estadistica y Telematica C/Tulipan s/n28933マドリード--スペイン
EMail: eva@gsyc.escet.urjc.es
メール: eva@gsyc.escet.urjc.es
Shin, Ed., et al. Informational [Page 32] RFC 4038 Application Aspects of IPv6 Transition March 2005
エド、よじ登ってください、他 IPv6変遷行進2005年の情報[32ページ]のRFC4038アプリケーション局面
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Shin, Ed., et al. Informational [Page 33]
エド、よじ登ってください、他 情報[33ページ]
一覧
スポンサーリンク
