この文書はRFC3493の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
Network Working Group R. Gilligan Request for Comments: 3493 Intransa, Inc. Obsoletes: 2553 S. Thomson Category: Informational Cisco J. Bound J. McCann Hewlett-Packard W. Stevens February 2003 Basic Socket Interface Extensions for IPv6 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 (2003). All Rights Reserved. Abstract 概要 The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. TCP/IPアプリケーションのためのデファクトの標準アプリケーション プログラムインタフェース(API)は「ソケット」インタフェースです。 このAPIが1980年代初期にUNIXのために開発されたけれども、多 種多様な非UNIXのシステム上に実装されました。ソケットAPIを使っ て書かれたTCP/IPアプリケーションが過去に高度のポータビリティを 享受しました、そして我々はIPv6アプリケーションで同じポータビリ ティを欲します。けれどもIPv6をサポートするのにソケットAPIの変 更が要求され、そしてこのメモはこれらの変更を記述します。これらはIP v6アドレス、新しいアドレス変換機能とある新しいソケットオプションを 伴うための新しいソケットアドレス構造を含みます。これらの拡張は、既存 のIPv4アプリケーションに完全な互換性を提供したまま、導入のための 変更を最小限に抑えて、TCPとUDPアプリケーションに必要な基本的な IPv6機能へのアクセスを供給するよう意図されます。高等IPv6機能 のための追加の拡張(生ソケットとIPv6拡張ヘッダーへのアクセス)が 他の文書で定義されます。 Table of Contents 目次 1. Introduction 1. はじめに 2. Design Considerations 2. デザイン考察 2.1 What Needs to be Changed 2.1 どのような変更が必要か 2.2 Data Types 2.2 データタイプ 2.3 Headers 2.3 ヘッダ 2.4 Structures 2.4 構造体 3. Socket Interface 3. ソケットインタフェース 3.1 IPv6 Address Family and Protocol Family 3.1 IPv6 アドレスファミリとプロトコルファミリ 3.2 IPv6 Address Structure 3.2 IPv6アドレス構造体 3.3 Socket Address Structure for 4.3BSD-Based Systems 3.3 4.3BSDベースシステムのソケットアドレス構造体 3.4 Socket Address Structure for 4.4BSD-Based Systems 3.4 4.4BSDベースシステムのソケットアドレス構造体 3.5 The Socket Functions 3.5 ソケット関数 3.6 Compatibility with IPv4 Applications 3.6 IPv4アプリケーションとの互換性 3.7 Compatibility with IPv4 Nodes 3.7 IPv4ノードとの互換性 3.8 IPv6 Wildcard Address 3.8 IPv6ワイルドカードアドレス 3.9 IPv6 Loopback Address 3.9 IPv6ループバックアドレス 3.10 Portability Additions 3.10 ポータビリティ追加 4. Interface Identification 4. インタフェース識別子 4.1 Name-to-Index 4.1 Name-to-Index 4.2 Index-to-Name 4.2 Index-to-Name 4.3 Return All Interface Names and Indexes 4.3 全インタフェース名とインデックスを返す 4.4 Free Memory 4.4 メモリ開放 5. Socket Options 5. ソケットオプション 5.1 Unicast Hop Limit 5.1 ユニキャストホップ限界 5.2 Sending and Receiving Multicast Packets 5.2 マルチキャストパケットの送受信 5.3 IPV6_V6ONLY option for AF_INET6 Sockets 5.3 AF_INET6ソケットのIPV6_V6ONLYオプション 6. Library Functions 6. ライブラリ関数 6.1 Protocol-Independent Nodename and Service Name Translation 6.1 プロトコルに依存しないノード名とサービス名翻訳 6.2 Socket Address Structure to Node Name and Service Name 6.2 ノード名とサービス名へのソケットアドレス構造体 6.3 Address Conversion Functions 6.3 アドレス変換関数 6.4 Address Testing Macros 6.4 アドレステストマクロ 7. Summary of New Definitions 7. 新しい定義の要約 8. Security Considerations 8. セキュリティの考察 9. Changes from RFC 2553 9. RFC2553からの変更 10. Acknowledgments 10. 謝辞 11. References 11. 参考文献 12. Authors' Addresses 12. 著者のアドレス 13. Full Copyright Statement 13. 著作権表示全文 1. Introduction 1. はじめに While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits long. The socket interface makes the size of an IP address quite visible to an application; virtually all TCP/IP applications for BSD-based systems have knowledge of the size of an IP address. Those parts of the API that expose the addresses must be changed to accommodate the larger IPv6 address size. IPv6 also introduces new features, some of which must be made visible to applications via the API. This memo defines a set of extensions to the socket interface to support the larger address size and new features of IPv6. It defines "basic" extensions that are of use to a broad range of applications. A companion document, the "advanced" API [4], covers extensions that are of use to more specialized applications, examples of which include routing daemons, and the "ping" and "traceroute" utilities. IPv4アドレスが長さが32ビットであるが、IPv6インタフェースが 128ビットのアドレスです。ソケットインタフェースはIPアドレスの大 きさをアプリケーションにはっきり見せます;ほとんどすべてのTCP/B SDベースのシステムのIPアプリケーションがIPアドレスの大きさの知 識を持っています。アドレスを露出するAPIのそれらの部分がより大きい IPv6アドレス大きさを収容するために変えなくてはなりません。IPv6 が新しい機能を導入します、そしてそのいくつかはAPIによってアプリケー ションに見えなくてはなりません。このメモはより大きいアドレスサイズと IPv6の新しい機能をサポートするためのソケットインタフェースへの拡 張を定義します。これは広い範囲のアプリケーションに役に立つ「基本」拡 張を定義します。関連文書、「高等」API[4]が、例えばルーティングデー モンや「ping」と「traceroute」ユーティリティーを含む、 より専門的アプリケーションに役つ拡張をカバーします。 The development of this API was started in 1994 in the IETF IPng working group. The API has evolved over the years, published first in RFC 2133, then again in RFC 2553, and reaching its final form in this document. このAPIの開発はIETFのIPngワーキンググループで1994年に 始められました。APIは数年間かけて進展し、RFC2133で最初に、 そしてRFC2553で再び発表され、そしてこの文書で最終形式になりま した。 As the API matured and stabilized, it was incorporated into the Open Group's Networking Services (XNS) specification, issue 5.2, which was subsequently incorporated into a joint Open Group/IEEE/ISO standard [3]. APIが成熟し安定したので、こはオープングループのネットワーキングサー ビス(XNS)仕様書、5.2版、に取り入れられ、その後共同オープングルー プ/IEEE/ISO標準[3]に取り入れられました。 Effort has been made to ensure that this document and [3] contain the same information with regard to the API definitions. However, the reader should note that this document is for informational purposes only, and that the official standard specification of the sockets API is [3]. この文書と[3]がAPI定義に関して同じ情報を含んでいることを保証するた めの取り組みがされました。しかしながら、読者はこの文書が情報的な目的 のみのためであるり、そしてソケットAPIの公式標準仕様書が[3]であるこ とを指摘するべきです。 It is expected that any future standardization work on this API would be done by the Open Group Base Working Group [6]. このAPIの未来の標準化の仕事がオープングループベースワーキンググルー プ[6]によってされるであろうと思われます。 It should also be noted that this document describes only those portions of the API needed for IPv4 and IPv6 communications. Other potential uses of the API, for example the use of getaddrinfo() and getnameinfo() with the AF_UNIX address family, are beyond the scope of this document. この文書がただIPv4とIPv6通信に必要とされるAPIの部分だけを 記述することは同じく指摘されるべきです。APIの他の可能性がある使用、 例えばAF_UNIXアドレスファミリのgetaddrinfo()とgetnameinfo()はこの文書 の範囲外です。 2. Design Considerations 2. デザイン考察 There are a number of important considerations in designing changes to this well-worn API: この使い古されたAPIに対する変更を設計する際に多くの重要な考慮点が あります: - The API changes should provide both source and binary compatibility for programs written to the original API. That is, existing program binaries should continue to operate when run on a system supporting the new API. In addition, existing applications that are re-compiled and run on a system supporting the new API should continue to operate. Simply put, the API changes for IPv6 should not break existing programs. An additional mechanism for implementations to verify this is to verify the new symbols are protected by Feature Test Macros as described in [3]. (Such Feature Test Macros are not defined by this RFC.) - APIの変更はオリジナルのAPIで書かれたプログラムに対してソース レベルとバイナリレベルの両方の互換性を提供するべきです。すなわち、 既存のバイナリプログラムを新しいAPIをサポートしているシステム上 で動かす時、動くべきです。加えて、再コンパイルされた既存のアプリケー ションを新しいAPIをサポートしているシステムで動き続けるべきです。 単純言うと、APIの変更は既存のプログラムを壊すべきではありません。 実装の検証のための追加メカニズムが[3]で記述される機能試験マクロで、 新しいシンボルが保護されるか検証します。(このような機能テストマク ロはこのRFCで定義されません。) - The changes to the API should be as small as possible in order to simplify the task of converting existing IPv4 applications to IPv6. - APIの変更は既存のIPv4アプリケーションをIPv6対応に変換す る仕事を単純化するため、可能な限り少なくするべきです。 - Where possible, applications should be able to use this API to interoperate with both IPv6 and IPv4 hosts. Applications should not need to know which type of host they are communicating with. - 可能な場合は、アプリケーションがIPv6ホストとIPv4ホストの両 方と通信するのにこのAPIをえるべきです。アプリケーションがどのタ イプのホストと通信しているか知る必要があるべきではありません。 - IPv6 addresses carried in data structures should be 64-bit aligned. This is necessary in order to obtain optimum performance on 64-bit machine architectures. - データ構造体で運ばれたIPv6アドレスが64ビット整列であるべきで す。これは64ビットのマシンアーキテクチャ上で最適なパフォーマンス を得るために必要です。 Because of the importance of providing IPv4 compatibility in the API, these extensions are explicitly designed to operate on machines that provide complete support for both IPv4 and IPv6. A subset of this API could probably be designed for operation on systems that support only IPv6. However, this is not addressed in this memo. APIがIPv4互換性を供給する重要性のため、これらの拡張は明示的に IPv4とIPv6両方に対する完全なサポートを供給するマシン上に働く よう意図されます。IPv6だけをサポートするシステムのオペレーション のために、このAPIのサブセットが多分設計できます。しかし、これはこ のメモで扱われません。 2.1 What Needs to be Changed 2.1 どのような変更が必要か The socket interface API consists of a few distinct components: ソケットインタフェースAPIは以下の異なる要素から成り立ちます: - Core socket functions. - コアソケット機能。 - Address data structures. - アドレスデータ構造体。 - Name-to-address translation functions. - 名前からアドレスへの翻訳関数。 - Address conversion functions. - アドレス変換関数。 The core socket functions -- those functions that deal with such things as setting up and tearing down TCP connections, and sending and receiving UDP packets -- were designed to be transport independent. Where protocol addresses are passed as function arguments, they are carried via opaque pointers. A protocol-specific address data structure is defined for each protocol that the socket functions support. Applications must cast pointers to these protocol-specific address structures into pointers to the generic "sockaddr" address structure when using the socket functions. These functions need not change for IPv6, but a new IPv6-specific address data structure is needed. コアソケット関数−TCP接続の設定と削除や、UDPパケットの送信と受 信を扱う関数−はトランスポートに依存しないよう設計されました。プロト コルアドレスが関数の引数として渡されるところで、それらは不透明なポイ ンタで運ばれます。プロトコル特定のアドレスデータ構造体がソケット関数 がサポートするそれぞれのプロトコルのために定義されます。アプリケーショ ンがソケット関数を使う時、これらのプロトコル特定のアドレス構造体への ポインタは一般的な「sockaddr」アドレス構造体へのポインタにキャストし なければなりません。これらの関数はIPv6で変更不要ですが、新しいI Pv6特定のアドレスデータ構造体が必要です。 The "sockaddr_in" structure is the protocol-specific data structure for IPv4. This data structure actually includes 8-octets of unused space, and it is tempting to try to use this space to adapt the sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in structure is not large enough to hold the 16-octet IPv6 address as well as the other information (address family and port number) that is needed. So a new address data structure must be defined for IPv6. 「sockaddr_in」構造体はIPv4プロトコル特有のデータ構造体です。この データ構造体は実際は未使用の8オクテットスペースを含み、sockaddr_in構 造体をIPv6に適合させるのにこのスペースを使う誘惑があります。不幸 にもsockaddr_in構造体は16オクテットのIPv6アドレスと他に必要な情 報を保持できるほど十分大きくありません。それで新しいアドレスデータ構 造体がIPv6のために定義されなくてはなりません。 IPv6 addresses are scoped [2] so they could be link-local, site, organization, global, or other scopes at this time undefined. To support applications that want to be able to identify a set of interfaces for a specific scope, the IPv6 sockaddr_in structure must support a field that can be used by an implementation to identify a set of interfaces identifying the scope for an IPv6 address. IPv6アドレスは範囲[2]を持ち、それはリンクローカルかサイトか組織か グローバルか、現在は不確定な範囲です。特定の範囲のインタフェースを識 別可能であることを望むアプリケーションをサポートするために、IPv6 のsockaddr_in構造体はIPv6アドレスの範囲を示すインタフェース集合を 識別するために実装が使えるフィールドをサポートしなくてはなりません。 The IPv4 name-to-address translation functions in the socket interface are gethostbyname() and gethostbyaddr(). These are left as is, and new functions are defined which support both IPv4 and IPv6. IPv4のソケットインタフェースでの名前からアドレスへの翻訳関数は gethostbyname()とgethostbyaddr()です。これらはそのままで、IPv4と IPv6の両方をサポートするために新しい関数が定義されます。 The IPv4 address conversion functions -- inet_ntoa() and inet_addr() -- convert IPv4 addresses between binary and printable form. These functions are quite specific to 32-bit IPv4 addresses. We have designed two analogous functions that convert both IPv4 and IPv6 addresses, and carry an address type parameter so that they can be extended to other protocol families as well. IPv4アドレス変換関数−inet_ntoa()とinet_addr()−はIPv4アドレ スのバイナリと印刷可能な形の間の変換をします。これらの関数は32ビッ トのIPv4アドレスに非常に特有です。我々はIPv4とIPv6アドレ スの両方を変換し、それらが同様に他のプロトコルファミリーにも拡張でき るように、アドレスタイプパラメータを伴う2つの類似した関数を設計しま した。 Finally, a few miscellaneous features are needed to support IPv6. A new interface is needed to support the IPv6 hop limit header field. New socket options are needed to control the sending and receiving of IPv6 multicast packets. 最終的に、少数の雑多な機能がIPv6をサポートするために必要です。新 しいインタフェースがIPv6ホップ限界ヘッダーフィールドをサポートす るために必要です。新しいソケットオプションがIPv6マルチキャストパ ケットの送受信を制御するために必要です。 The socket interface will be enhanced in the future to provide access to other IPv6 features. Some of these extensions are described in [4]. ソケットインタフェースは他のIPv6機能へのアクセスを供給するために 将来拡張されるでしょう。いくつかの拡張は[4]で記述されます。 2.2 Data Types 2.2 データタイプ The data types of the structure elements given in this memo are intended to track the relevant standards. uintN_t means an unsigned integer of exactly N bits (e.g., uint16_t). The sa_family_t and in_port_t types are defined in [3]. このメモで与えられた構造体要素のデータタイプは適切な標準を追跡するよ うに意図されます。uintN_tが正確にNビットの符号なしの整数を意味します (例えば、uint16_t)。sa_family_tとin_port_tタイプは[3]で定義されます。 2.3 Headers 2.3 ヘッダ When function prototypes and structures are shown we show the headers that must be #included to cause that item to be defined. 関数の原型と構造体を示すとき、項目を定義するため#includeするヘッダを示 します。 2.4 Structures 2.4 構造体 When structures are described the members shown are the ones that must appear in an implementation. Additional, nonstandard members may also be defined by an implementation. As an additional precaution nonstandard members could be verified by Feature Test Macros as described in [3]. (Such Feature Test Macros are not defined by this RFC.) 構造体を示す場合、記述したメンバは実装で存在しなければならないもので す。追加の非標準メンバが実装で定義されるかもしれません。追加の用心と して、[3]で記述されように、機能テストマクロで非標準メンバーを検査でき ます(こうした機能テストマクロはこのRFCで定義しません)。 The ordering shown for the members of a structure is the recommended ordering, given alignment considerations of multibyte members, but an implementation may order the members differently. 構造体のメンバが表れる順序は、マルチバイトメンバーの整列を考慮した推 奨された順序です。しかし、実装はメンバを異なる順序にしてもかまいませ ん。 3. Socket Interface 3. ソケットインタフェース This section specifies the socket interface changes for IPv6. この章はIPv6のためにソケットインタフェース変更を指定します。 3.1 IPv6 Address Family and Protocol Family 3.1 IPv6 アドレスファミリとプロトコルファミリ A new address family name, AF_INET6, is defined in <sys/socket.h>. The AF_INET6 definition distinguishes between the original sockaddr_in address data structure, and the new sockaddr_in6 data structure. 新しいアドレスファミリ名AF_INET6が、<sys/socket.h>で定義されます。 AF_INET6の定義は、元のsockaddr_inアドレスデータ構造体と新規の sockaddr_in6データ構造体とを区別します。 A new protocol family name, PF_INET6, is defined in <sys/socket.h>. Like most of the other protocol family names, this will usually be defined to have the same value as the corresponding address family name: 新しいプロトコルファミリ名PF_INET6が<sys/socket.h>で定義されます。他 のプロトコルファミリ名の多くと同じく、これは通常対応するアドレスファ ミリと同じ値を持ように定義されるでしょう: #define PF_INET6 AF_INET6 The AF_INET6 is used in the first argument to the socket() function to indicate that an IPv6 socket is being created. PF_INET6はsocket()関数の最初の引数で使われ、IPv6ソケットの生成 を示します。 3.2 IPv6 Address Structure 3.2 IPv6アドレス構造体 A new in6_addr structure holds a single IPv6 address and is defined as a result of including <netinet/in.h>: 新規のin6_addr構造体がひとつのIPv6アドレスを保持し、 <netinet/in.h>で定義されます: struct in6_addr { uint8_t s6_addr[16]; /* IPv6 address */ }; This data structure contains an array of sixteen 8-bit elements, which make up one 128-bit IPv6 address. The IPv6 address is stored in network byte order. このデータ構造は16個の8ビット要素の配列で、1つの128ビットのI Pv6アドレスを示します。IPv6アドレスはネットワークバイト順に設 定されます。 The structure in6_addr above is usually implemented with an embedded union with extra fields that force the desired alignment level in a manner similar to BSD implementations of "struct in_addr". Those additional implementation details are omitted here for simplicity. 上記in6_addr構造体は通常通ましい整列レベルを強制する余分のフィールド 込みの共用体で、"in_addr構造体"のBSD実装に似た方法で実装されます。 これらの追加の実装の細部は単純さのためにここでは省略します。 An example is as follows: 以下に例を示します: struct in6_addr { union { uint8_t _S6_u8[16]; uint32_t _S6_u32[4]; uint64_t _S6_u64[2]; } _S6_un; }; #define s6_addr _S6_un._S6_u8 3.3 Socket Address Structure for 4.3BSD-Based Systems 3.3 4.3BSDベースシステムのソケットアドレス構造体 In the socket interface, a different protocol-specific data structure is defined to carry the addresses for each protocol suite. Each protocol-specific data structure is designed so it can be cast into a protocol-independent data structure -- the "sockaddr" structure. Each has a "family" field that overlays the "sa_family" of the sockaddr data structure. This field identifies the type of the data structure. ソケットインタフェースで、異なるプロトコル特有のデータ構造体が各プロ トコルのアドレスを運ぶため定義されます。各プロトコル特有データ構造体 は、プロトコルに依存しないデータ構造体である"sockaddr"構造体にキャス トできるよう設計されています。それぞれは"family" フィールドを持ち、 sockaddrデータ構造体の"sa_family"を上書きします。このフィールドはデー タ構造体の型を識別します。 The sockaddr_in structure is the protocol-specific address data structure for IPv4. It is used to pass addresses between applications and the system in the socket functions. The following sockaddr_in6 structure holds IPv6 addresses and is defined as a result of including the <netinet/in.h> header: sockaddr_in構造体はIPv4プロトコル特有のアドレスデータ構造体です。 これはソケット関数でアプリケーションとシステムの間にアドレスを渡すた めに使われます。次のsockaddr_in6構造体はIPv6アドレスを持ち、 <netinet/in.h>で定義されます:。 struct sockaddr_in6 { sa_family_t sin6_family; /* AF_INET6 */ /* AF_INET6 */ in_port_t sin6_port; /* transport layer port # */ /* トランスポートレイヤ番号 */ uint32_t sin6_flowinfo; /* IPv6 flow information */ /* IPv6フロー情報 */ struct in6_addr sin6_addr; /* IPv6 address */ /* IPv6アドレス */ uint32_t sin6_scope_id; /* set of interfaces for a scope */ /* 範囲に対するインターフェース */ }; This structure is designed to be compatible with the sockaddr data structure used in the 4.3BSD release. この構造体は 4.3BSDリリースで使われたsockaddrデータ構造体と両立でき るよう意図されます。 The sin6_family field identifies this as a sockaddr_in6 structure. This field overlays the sa_family field when the buffer is cast to a sockaddr data structure. The value of this field must be AF_INET6. sin6_family フィールドはsockaddr_in6構造体を識別します。バッファを sockaddrデータ構造体にキャストする時、このフィールドはsa_familyフィー ルドを上書きします。このフィールドの値はAF_INET6であるに違いありま せん。 The sin6_port field contains the 16-bit UDP or TCP port number. This field is used in the same way as the sin_port field of the sockaddr_in structure. The port number is stored in network byte order. sin6_port フィールドは16ビットのUDPかTCPポート番号を含んでい ます。このフィールドはsockaddr_in構造体のsin_portフィールドと同じよう に使われます。ポート番号はネットワークバイト順で設定されます。 The sin6_flowinfo field is a 32-bit field intended to contain flow- related information. The exact way this field is mapped to or from a packet is not currently specified. Until such time as its use is specified, applications should set this field to zero when constructing a sockaddr_in6, and ignore this field in a sockaddr_in6 structure constructed by the system. sin6_flowinfoフィールドはフロー関連の情報を含むように意図される32ビッ トのフィールドです。このフィールドがパケットに、あるいはパケットから マップされる正確な方法は現在指定されません。その使用法が指定される時 まで、アプリケーションがsockaddr_in6を組み立てる時、このフィールドを ゼロに設定して、そしてシステムによって構築されたsockaddr_in6構造体で のこのフィールドを無視するべきです。 The sin6_addr field is a single in6_addr structure (defined in the previous section). This field holds one 128-bit IPv6 address. The address is stored in network byte order. sin6_addrフィールドは(前の章で定義された)ひとつのin6_addr構造体です。 このフィールドは1つの128ビットIPv6アドレスを持ちます。アドレ スはネットワークバイト順に設定されます。 The ordering of elements in this structure is specifically designed so that when sin6_addr field is aligned on a 64-bit boundary, the start of the structure will also be aligned on a 64-bit boundary. This is done for optimum performance on 64-bit architectures. この構造体での要素の順序は、 sin6_addrフィールドが64ビットの境界上 に並べられる時、構造体の開始が同じく64ビット境界になるように設計さ れます。これは64ビットアーキテクチャ上での最適なパフォーマンスのた めにされます。 The sin6_scope_id field is a 32-bit integer that identifies a set of interfaces as appropriate for the scope [2] of the address carried in the sin6_addr field. The mapping of sin6_scope_id to an interface or set of interfaces is left to implementation and future specifications on the subject of scoped addresses. sin6_scope_idフィールドはsin6_addrフィールドで運ばれたアドレスの範囲 [2]に対応するインタフェース集合を識別する32ビット整数です。 sin6_scope_idからインターフェースへの変換は実装依存で、範囲アドレスの 問題は将来の仕様書に残されます。 Notice that the sockaddr_in6 structure will normally be larger than the generic sockaddr structure. On many existing implementations the sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both being 16 bytes. Any existing code that makes this assumption needs to be examined carefully when converting to IPv6. sockaddr_in6構造体が通常一般的なsockaddr構造体よりも大きくなることに 注意して下さい。多くの既存の実装で、sizeof(struct sockaddr_in)と sizeof(struct sockaddr)は等しく、両方16バイトです。これを想定して 作成している既存のコードは、IPv6に移行する際、慎重に調べる必要が あります。 3.4 Socket Address Structure for 4.4BSD-Based Systems 3.4 4.4BSDベースシステムのソケットアドレス構造体 The 4.4BSD release includes a small, but incompatible change to the socket interface. The "sa_family" field of the sockaddr data structure was changed from a 16-bit value to an 8-bit value, and the space saved used to hold a length field, named "sa_len". The sockaddr_in6 data structure given in the previous section cannot be correctly cast into the newer sockaddr data structure. For this reason, the following alternative IPv6 address data structure is provided to be used on systems based on 4.4BSD. It is defined as a result of including the <netinet/in.h> header. 4.4BSDリリースはソケットインタフェースに対する小さいが、互換性が ない変更を含みます。sockaddrデータ構造体の"sa_family"フィールドは16 ビット値から8ビット値に変えられ、空いたスペースは"sa_len"という名前 の長さフィールドになりました。前の章で示したsockaddr_in6データ構造体 は新しいsockaddrデータ構造体に正しくキャストできません。この理由のた めに、次の代わりのIPv6アドレスデータ構造体が4.4BSDに基くシス テムで供給されます。これは<netinet/in.h>で定義されます。 struct sockaddr_in6 { uint8_t sin6_len; /* length of this struct */ /* 構造体の長さ */ sa_family_t sin6_family; /* AF_INET6 */ /* AF_INET6 */ in_port_t sin6_port; /* transport layer port # */ /* トランスポート層のポート番号 */ uint32_t sin6_flowinfo; /* IPv6 flow information */ /* IPv6フロー情報 */ struct in6_addr sin6_addr; /* IPv6 address */ /* IPv6アドレス */ uint32_t sin6_scope_id; /* set of interfaces for a scope */ /* 範囲のインターフェース集合 */ }; The only differences between this data structure and the 4.3BSD variant are the inclusion of the length field, and the change of the family field to a 8-bit data type. The definitions of all the other fields are identical to the structure defined in the previous section. このデータ構造体と4.3BSDの間の唯一の相違は長さフィールドの包含で、 8ビットのデータタイプに対するファミリーフィールドの変更です。すべて の他のフィールドの定義は前の章で定義された構造体とまったく同じです。 Systems that provide this version of the sockaddr_in6 data structure must also declare SIN6_LEN as a result of including the <netinet/in.h> header. This macro allows applications to determine whether they are being built on a system that supports the 4.3BSD or 4.4BSD variants of the data structure. sockaddr_in6データ構造体のこの版を提供するシステムは、<netinet/in.h> ヘッダでSIN6_LENの宣言をしなければならなりません。このマクロはアプリ ケーションにシステムが4.3BSDデータ構造体に基づくか、4.4BSD データ構造体の基づくのか決定することを許します。 3.5 The Socket Functions 3.5 ソケット関数 Applications call the socket() function to create a socket descriptor that represents a communication endpoint. The arguments to the socket() function tell the system which protocol to use, and what format address structure will be used in subsequent functions. For example, to create an IPv4/TCP socket, applications make the call: アプリケーションはsocket()関数を呼んで、通信末端を表すソケットディス クプリタを作ります。socket()関数への引数はシステムにどのプロトコルを 使うべきか言い、そのプロトコルのアドレス構造体が後の関数で使われるで しょう。例えば、IPv4/TCPソケットを作るために、アプリケーショ ンが以下を呼びます: s = socket(AF_INET, SOCK_STREAM, 0); To create an IPv4/UDP socket, applications make the call: IPv4/UDPソケットを作るためアプリケーションが以下を呼びます: s = socket(AF_INET, SOCK_DGRAM, 0); Applications may create IPv6/TCP and IPv6/UDP sockets (which may also handle IPv4 communication as described in section 3.7) by simply using the constant AF_INET6 instead of AF_INET in the first argument. For example, to create an IPv6/TCP socket, applications make the call: アプリケーションが最初の引数に定数AF_INETの代わりに定数AF_INET6を使う ことでIPv6/TCPとIPv6/UDPソケットを作ります。例えば、 IPv6/TCPソケットを作るためアプリケーションが以下を呼びます: s = socket(AF_INET6, SOCK_STREAM, 0); To create an IPv6/UDP socket, applications make the call: IPv6/UDPソケットを作るためアプリケーションは以下を呼びます: s = socket(AF_INET6, SOCK_DGRAM, 0); Once the application has created a AF_INET6 socket, it must use the sockaddr_in6 address structure when passing addresses in to the system. The functions that the application uses to pass addresses into the system are: アプリケーションがAF_INET6ソケットを作ると、システムにアドレスを提示 する際に、sockaddr_in6アドレス構造体を使わなくてはなりません。アプリ ケーションがシステムにアドレスを渡す関数は以下です: bind() connect() sendmsg() sendto() The system will use the sockaddr_in6 address structure to return addresses to applications that are using AF_INET6 sockets. The functions that return an address from the system to an application are: システムはPF_INET6ソケットを使っているアプリケーションにアドレスを返 すためsockaddr_in6アドレス構造体を使うでしょう。システムからアプリケー ションまでアドレスを返す関数は以下です: accept() recvfrom() recvmsg() getpeername() getsockname() No changes to the syntax of the socket functions are needed to support IPv6, since all of the "address carrying" functions use an opaque address pointer, and carry an address length as a function argument. 「アドレスを運ぶ」関数のすべてが不透明なアドレスポインタを使い、アド レス長を関数の引数で運ぶので、IPv6対応にソケットの構文に対する変 更が必要ありません。 3.6 Compatibility with IPv4 Applications 3.6 IPv4アプリケーションとの互換性 In order to support the large base of applications using the original API, system implementations must provide complete source and binary compatibility with the original API. This means that systems must continue to support AF_INET sockets and the sockaddr_in address structure. Applications must be able to create IPv4/TCP and IPv4/UDP sockets using the AF_INET constant in the socket() function, as described in the previous section. Applications should be able to hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets simultaneously within the same process. 多くのオリジナルのAPIを使っているアプリケーションをサポートするた めに、システム実装がオリジナルAPIのソースとバイナリの完全な互換性 に提供しなくてはなりません。これはシステムがAF_INETソケットとsockaddr_in アドレス構造体をサポートし続けなくてはならないことを意味します。前章 で記述されるように、アプリケーションがsocket()関数でAF_INET定数を使っ てIPv4/TCPとIPv4/UDPソケットを作れなければなりません。 アプリケーションは同じプロセスので同時にIPv4/TCPとIPv4/ UDPとIPv6/TCPとIPv6/UDPソケットの組合せを持つこと が可能であるべきです。 Applications using the original API should continue to operate as they did on systems supporting only IPv4. That is, they should continue to interoperate with IPv4 nodes. オリジナルの APIを使っているアプリケーションは、それらがIPv4だ けをサポートしているシステム上で動作したのと同様に、動作し続けるべき です。すなわち、それらはIPv4ノードと通信できるべきです。 3.7 Compatibility with IPv4 Nodes 3.7 IPv4ノードとの互換性 The API also provides a different type of compatibility: the ability for IPv6 applications to interoperate with IPv4 applications. This feature uses the IPv4-mapped IPv6 address format defined in the IPv6 addressing architecture specification [2]. This address format allows the IPv4 address of an IPv4 node to be represented as an IPv6 address. The IPv4 address is encoded into the low-order 32 bits of the IPv6 address, and the high-order 96 bits hold the fixed prefix 0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows: API異なるタイプの互換性を供給します:IPv6アプリケーションがI Pv4アプリケーションと通信する能力。この機能はIPv6アドレスアー キテクチャ仕様書[2]で定義されたIPv4マップIPv6アドレスフォー マットを使います。このアドレスフォーマットはIPv4ノードのIPv4 アドレスをIPv6アドレス表現で記述するのを許します。IPv4アドレ スはIPv6アドレスの下位32ビットにコード化され、上位96ビットは 固定プレフィックス0:0:0:0:0:FFFFです。IPv4マップのアドレスが次の ように書かれます: ::FFFF:<IPv4-address> These addresses can be generated automatically by the getaddrinfo() function, as described in Section 6.1. これらのアドレスは6.1章で記述されるようにgetaddrinfo()関数によって 自動的に生成できます。 Applications may use AF_INET6 sockets to open TCP connections to IPv4 nodes, or send UDP packets to IPv4 nodes, by simply encoding the destination's IPv4 address as an IPv4-mapped IPv6 address, and passing that address, within a sockaddr_in6 structure, in the connect() or sendto() call. When applications use AF_INET6 sockets to accept TCP connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the system returns the peer's address to the application in the accept(), recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded this way. アプリケーションがIPv4マップIPv6アドレスとして宛先IPv4ア ドレスをコード化し、sockaddr_in6構造体でconnect()かsendto()に渡すこと で、IPv4ノードにTCP接続を開くかUDPパケットを送るのに AF_INET6ソケットを使うかもしれません。アプリケーションがAF_INET6ソケッ トを使用してIPv4ノードからのTCP接続を受けるか、UDPパケット を受信する時、システムはこの方法でコード化したsockaddr_in6構造体を使 用してaccept()やrecvfrom()やgetpeername()呼び出しで相手のアドレスをア プリケーションに返します。 Few applications will likely need to know which type of node they are interoperating with. However, for those applications that do need to know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.4, is provided. ほとんどアプリケーションが多分どのタイプのノードと通信しているか知る 必要がないでしょう。しかしながら、知る必要があるアプリケーションのた めに、6.7章で定義されたIN6_IS_ADDR_V4MAPPED()マクロが供給されます。 3.8 IPv6 Wildcard Address 3.8 IPv6ワイルドカードアドレス While the bind() function allows applications to select the source IP address of UDP packets and TCP connections, applications often want the system to select the source address for them. With IPv4, one specifies the address as the symbolic constant INADDR_ANY (called the "wildcard" address) in the bind() call, or simply omits the bind() entirely. bind()関数がアプリケーションにUDPパケットとTCP接続のソースIP アドレスを選択を許しますが、アプリケーションはしばしばシステムにソー スアドレスを選ぶのを望みます。IPv4で、bind()呼び出しで象徴的定数 INADDR_ANY(「ワイルドカード」アドレスと呼ばれる)を使うか、bind()を 省略することでこれをします。 Since the IPv6 address type is a structure (struct in6_addr), a symbolic constant can be used to initialize an IPv6 address variable, but cannot be used in an assignment. Therefore systems provide the IPv6 wildcard address in two forms. IPv6アドレスタイプが構造体(struct in6_addr)であるので、象徴的定 数がIPv6アドレス変数を初期化するために使うことができますが、代入 で使うことができません。それ故にシステムが2つの形式でIPv6ワイル ドカードアドレスを供給します。 The first version is a global variable named "in6addr_any" that is an in6_addr structure. The extern declaration for this variable is defined in <netinet/in.h>: 最初の版は「in6addr_any」という名前のin6_addr構造体グローバル変数です。 この変数のextern宣言が<netinet/in.h>で行われます: extern const struct in6_addr in6addr_any; Applications use in6addr_any similarly to the way they use INADDR_ANY in IPv4. For example, to bind a socket to port number 23, but let the system select the source address, an application could use the following code: アプリケーションはIPv4でINADDR_ANYを使うのと同様にin6addr_anyを使 います。例えば、ポート番号23にソケットをバインドするがシステムにソー スアドレスを選ばせるため、アプリケーションが次のコードを使うことがで きます: struct sockaddr_in6 sin6; . . . sin6.sin6_family = AF_INET6; sin6.sin6_flowinfo = 0; sin6.sin6_port = htons(23); sin6.sin6_addr = in6addr_any; /* structure assignment */ /* 構造体代入 */ . . . if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) . . . The other version is a symbolic constant named IN6ADDR_ANY_INIT and is defined in <netinet/in.h>. This constant can be used to initialize an in6_addr structure: 他の版はIN6ADDR_ANY_INITという名前の象徴的な定数で、<netinet/in.h>で 定義されます。この定数はin6_addr構造体を初期化するために使うことがで きます: struct in6_addr anyaddr = IN6ADDR_ANY_INIT; Note that this constant can be used ONLY at declaration time. It can not be used to assign a previously declared in6_addr structure. For example, the following code will not work: この定数が宣言でだけ使うことができるのに注意してください。これは前に 宣言したin6_addr構造体に代入するために使うことができません。例えば、 次のコードは動かないでしょう: /* This is the WRONG way to assign an unspecified address */ /* これは特定されていないアドレスを割り当てる間違った方法である */ struct sockaddr_in6 sin6; . . . sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */ /* コンパイルできないでしょう */ Be aware that the IPv4 INADDR_xxx constants are all defined in host byte order but the IPv6 IN6ADDR_xxx constants and the IPv6 in6addr_xxx externals are defined in network byte order. IPv4のINADDR_xxx定数がすべてホストバイトオーダーで定義されますが、 IPv6のIN6ADDR_xxx定数とin6addr_xxx外部変数がネットワークバイト順 で定義されることを知っていてください。 3.9 IPv6 Loopback Address 3.9 IPv6ループバックアドレス Applications may need to send UDP packets to, or originate TCP connections to, services residing on the local node. In IPv4, they can do this by using the constant IPv4 address INADDR_LOOPBACK in their connect(), sendto(), or sendmsg() call. アプリケーションがローカルノード上のサービスにUDPパケット送信やT CP接続をする必要があるかもしれません。IPv4でこれはIPv4アド レス定数INADDR_LOOPBACKをconnect()とsendto()とsendmsg()呼び出しで使 うことでできます。 IPv6 also provides a loopback address to contact local TCP and UDP services. Like the unspecified address, the IPv6 loopback address is provided in two forms -- a global variable and a symbolic constant. IPv6はローカルなTCPとUDPサービスと通信をするためのループバッ クアドレスを供給します。特定されていないアドレスのように、IPv6ルー プバックアドレスの2つの形式−グローバル変数とシンボリックな定数−が 供給されます。 The global variable is an in6_addr structure named "in6addr_loopback." The extern declaration for this variable is defined in <netinet/in.h>: グローバル変数は「in6addr_loopback」という名前のin6_addr構造体です。 この変数のextern 宣言が<netinet/in.h>で定義されます: extern const struct in6_addr in6addr_loopback; Applications use in6addr_loopback as they would use INADDR_LOOPBACK in IPv4 applications (but beware of the byte ordering difference mentioned at the end of the previous section). For example, to open a TCP connection to the local telnet server, an application could use the following code: アプリケーションが、IPv4アプリケーションでINADDR_LOOPBACKを使うよ うにin6addr_loopbackを使います(前章の終わりで示したバイト順序に注意)。 例えば、ローカルなtelnetサーバーにTCP接続をするために、アプリケー ションが次のコードを使えます: struct sockaddr_in6 sin6; . . . sin6.sin6_family = AF_INET6; sin6.sin6_flowinfo = 0; sin6.sin6_port = htons(23); sin6.sin6_addr = in6addr_loopback; /* structure assignment */ /* 構造体代入 */ . . . if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) . . . The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined in <netinet/in.h>. It can be used at declaration time ONLY; for example: 象徴的定数はIN6ADDR_LOOPBACK_INITと命名され、<netinet/in.h>で定義され ます。これは宣言時にだけ使うことができます: struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT; Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to a previously declared IPv6 address variable. IN6ADDR_ANY_INITのように、この定数は前に宣言されたIPv6アドレス変 数への代入に使えません。 3.10 Portability Additions 3.10 ポータビリティ追加 One simple addition to the sockets API that can help application writers is the "struct sockaddr_storage". This data structure can simplify writing code that is portable across multiple address families and platforms. This data structure is designed with the following goals. アプリケーション製作者に手助けできるソケットAPIへの1つの単純な追 加は「struct sockaddr_storage」です。このデータ構造は多数のアドレスファ ミリーとプラットホーム間で移植性があるコードを書くことを簡単にします。 このデータ構造は次の目的で設計されます。 - Large enough to accommodate all supported protocol-specific address structures. - すべてのサポートされたプロトコル特有のアドレス構造体を受け入れるの に十分な大きさ。 - Aligned at an appropriate boundary so that pointers to it can be cast as pointers to protocol specific address structures and used to access the fields of those structures without alignment problems. - 適切な境界に整列し、そのポインタがプロトコル特有のアドレス構造体へ のポインタにキャストでき、整列問題なしで、それらの構造体のフィール ドにアクセスするのに使用できる。 The sockaddr_storage structure contains field ss_family which is of type sa_family_t. When a sockaddr_storage structure is cast to a sockaddr structure, the ss_family field of the sockaddr_storage structure maps onto the sa_family field of the sockaddr structure. When a sockaddr_storage structure is cast as a protocol specific address structure, the ss_family field maps onto a field of that structure that is of type sa_family_t and that identifies the protocol's address family. sockaddr_storage構造体はsa_family_tタイプのフィールドss_familyを含ん でいます。sockaddr_storage構造体がsockaddr構造体にキャストされる時、 sockaddr_storage構造体のss_familyフィールドはsockaddr構造体のsa_family フィールドをマップされます。sockaddr_storage構造体がプロトコル特有ア ドレス構造体いキャストされる時、ss_familyフィールドはsa_family_tタイ プの構造体のフィールドにマップされ、そしてプロトコルのアドレスファミ リーを識別します。 An example implementation design of such a data structure would be as follows. このようなデータ構造の実装設計の例が以下です。 /* * Desired design of maximum size and alignment * 最大サイズと整列の望ましい設計 */ #define _SS_MAXSIZE 128 /* Implementation specific max size */ /* 実装特有の最大サイズ */ #define _SS_ALIGNSIZE (sizeof (int64_t)) /* Implementation specific desired alignment */ /* 実行特有の望ましい整列 */ /* * Definitions used for sockaddr_storage structure paddings design. * sockaddr_storage構造体のパディング設計で使う定義 */ #define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) #define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t) + _SS_PAD1SIZE + _SS_ALIGNSIZE)) struct sockaddr_storage { sa_family_t ss_family; /* address family */ /* アドレスファミリー */ /* Following fields are implementation specific */ /* 次のフィールドは実装特有である */ char __ss_pad1[_SS_PAD1SIZE]; /* 6 byte pad, this is to make implementation /* specific pad up to alignment field that */ /* follows explicit in the data structure */ /* 6バイトパッド、これはフィールド整列のため、 */ /* データ構造体の後に、実装特有パッドを作ります。 */ int64_t __ss_align; /* field to force desired structure */ /* 望ましい構造体を強制するためのフィールド */ /* storage alignment */ /* 貯蔵代入 */ char __ss_pad2[_SS_PAD2SIZE]; /* 112 byte pad to achieve desired size, */ /* _SS_MAXSIZE value minus size of ss_family */ /* __ss_pad1, __ss_align fields is 112 */ /* 望ましい大きさにするための112のバイトパッド、 */ /* _SS_MAXSIZE値引くss_familyのサイズ、 */ /* __ss_pad1と__ss_alignフィールドは112 */ }; The above example implementation illustrates a data structure which will align on a 64-bit boundary. An implementation-specific field "__ss_align" along with "__ss_pad1" is used to force a 64-bit alignment which covers proper alignment good enough for the needs of sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures. The size of padding field __ss_pad1 depends on the chosen alignment boundary. The size of padding field __ss_pad2 depends on the value of overall size chosen for the total size of the structure. This size and alignment are represented in the above example by implementation specific (not required) constants _SS_MAXSIZE (chosen value 128) and _SS_ALIGNSIZE (with chosen value 8). Constants _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112) are also for illustration and not required. The derived values assume sa_family_t is 2 bytes. The implementation specific definitions and structure field names above start with an underscore to denote implementation private namespace. Portable code is not expected to access or reference those fields or constants. 上記の例の実装は64ビット境界上に整列するデータ構造を例示します。実 装特有のフィールド「__ss_align」と「__ss_pad1」は64ビット整列を強制 するために使われ、これはsockaddr_in6(IPv6)とsockaddr_in(IPv 4)アドレスデータ構造体の要求する適切な整列を十分満足します。穴埋め フィールド__ss_pad1の大きさは選ばれた整列境界に依存します。穴埋め フィールド__ss_pad2は構造体の完全な大きさに選ばれた全体的な大きさの 値に依存します。上記の例の実装特有の大きさと整列が(必須ではない)定 数_SS_MAXSIZE(選択された値は128)と_SS_ALIGNSIZE(選択された値は 8)で表現されます。同じく例示した定数_SS_PAD1SIZE(派生する値6)と _SS_PAD2SIZE(派生する値112)は必須ではありません。派生した値は sa_family_tが2バイトであると想定します。上記の実装特有の定義と構造 体フィールド名が実装固有の名前空間を意味する下線で始まります。移植可 能コードがこれらのフィールドや定数をアクセスするか参照することが期待 されません。 On implementations where the sockaddr data structure includes a "sa_len" field this data structure would look like this: sockaddrデータ構造体が"sa_len"を含む実装で、このデータ構造体のフィー ルドが以下の様でしょう: /* * Definitions used for sockaddr_storage structure paddings design. * sockaddr_storage構造体のパッドデザインに使う定義 */ #define _SS_PAD1SIZE (_SS_ALIGNSIZE - (sizeof (uint8_t) + sizeof (sa_family_t)) #define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (uint8_t) + sizeof (sa_family_t) + _SS_PAD1SIZE + _SS_ALIGNSIZE)) struct sockaddr_storage { uint8_t ss_len; /* address length */ /* アドレス長 */ sa_family_t ss_family; /* address family */ /* アドレスファミリー */ /* Following fields are implementation specific */ /* 次のフィールドは実装特有である */ char __ss_pad1[_SS_PAD1SIZE]; /* 6 byte pad, this is to make implementation /* specific pad up to alignment field that */ /* follows explicit in the data structure */ /* 6バイトパッド、これはフィールド整列のため、 */ /* データ構造体の後に、実装特有パッドを作ります。 */ int64_t __ss_align; /* field to force desired structure */ /* 望ましい構造体を強制するためのフィールド */ /* storage alignment */ /* 貯蔵代入 */ char __ss_pad2[_SS_PAD2SIZE]; /* 112 byte pad to achieve desired size, */ /* _SS_MAXSIZE value minus size of ss_len, */ /* __ss_family, __ss_pad1, __ss_align fields is 112 */ /* 望ましい大きさにするための112のバイトパッド、 */ /* _SS_MAXSIZE値引くss_familyのサイズ、 */ /* __ss_pad1と__ss_alignフィールドは112 */ }; 4. Interface Identification 4. インタフェース識別子 This API uses an interface index (a small positive integer) to identify the local interface on which a multicast group is joined (Section 5.2). Additionally, the advanced API [4] uses these same interface indexes to identify the interface on which a datagram is received, or to specify the interface on which a datagram is to be sent. このAPIはマルチキャストグループが加入するローカルインタフェースを 識別するためにインタフェースインデックス(小さい正の整数)を使います (5.2章)。さらに、高等API[4]はデータグラムを受信するインタフェー スを識別するか、データグラムを送るインタフェースを指定するために同じ インタフェースインデックスを使います。 Interfaces are normally known by names such as "le0", "sl1", "ppp2", and the like. On Berkeley-derived implementations, when an interface is made known to the system, the kernel assigns a unique positive integer value (called the interface index) to that interface. These are small positive integers that start at 1. (Note that 0 is never used for an interface index.) There may be gaps so that there is no current interface for a particular positive interface index. インタフェースが通常"le0"や"sl1"や"ppp2"の様な名前で知られています。 バークレー系の実装で、インタフェースをシステムが知る時、カーネルはそ のインタフェースに(インタフェースインデックスと呼ばれる)ユニークな 正の整数値を割り当てます。これらは1から始まる小さい正の整数です。 (0が決してインタフェースインデックスで使われないことに注意してくだ さい。)特定の正のインタフェースインデックスで現在のインタフェースが ないような隙間があるかもしれません。 This API defines two functions that map between an interface name and index, a third function that returns all the interface names and indexes, and a fourth function to return the dynamic memory allocated by the previous function. How these functions are implemented is left up to the implementation. 4.4BSD implementations can implement these functions using the existing sysctl() function with the NET_RT_IFLIST command. Other implementations may wish to use ioctl() for this purpose. このAPIはインタフェース名とインデックスを対応付ける2つの関数と、 すべてのインタフェース名を返す3番目の関数と、前の関数が割り当てられ たダイナミックメモリを返す4番目の関数を定義します。これらの関数が実 装される方法は実装依存です。4.4BSD実装が、NET_RT_IFLISTコマンド と既存のsysctl()関数を使って、これらの関数を実装できます。他の実装が この目的のためにioctl()を使うことを望むかもしれません。 4.1 Name-to-Index 4.1 Name-to-Index The first function maps an interface name into its corresponding index. 最初の関数はインタフェース名を対応するインデックスに変換します。 #include <net/if.h> unsigned int if_nametoindex(const char *ifname); If ifname is the name of an interface, the if_nametoindex() function shall return the interface index corresponding to name ifname; otherwise, it shall return zero. No errors are defined. もしifnameがインタフェース名なら、if_nametoindex()関数が名前ifnameに 対応しているインタフェースインデックスを返すべきです、さもなければ、 ゼロを返すべきです。エラーが定義されません。 4.2 Index-to-Name 4.2 Index-to-Name The second function maps an interface index into its corresponding name. 2番目の関数はインタフェースインデックスを対応する名前に変換します。 #include <net/if.h> char *if_indextoname(unsigned int ifindex, char *ifname); When this function is called, the ifname argument shall point to a buffer of at least IF_NAMESIZE bytes. The function shall place in this buffer the name of the interface with index ifindex. (IF_NAMESIZE is also defined in <net/if.h> and its value includes a terminating null byte at the end of the interface name.) If ifindex is an interface index, then the function shall return the value supplied in ifname, which points to a buffer now containing the interface name. Otherwise, the function shall return a NULL pointer and set errno to indicate the error. If there is no interface corresponding to the specified index, errno is set to ENXIO. If there was a system error (such as running out of memory), errno would be set to the proper value (e.g., ENOMEM). この関数が呼び出される時、ifname引数は少なくともIF_NAMESIZEバイトのバッ ファを指し示すべきです。関数はインデックスifindexのインタフェースの名 前をこのバッファに置くべきです。(IF_NAMESIZEは<net/if.h>で同じく定義 され、その値はインタフェース名の終わりに、終了のヌルバイトを含みます) もしifindexがインタフェースインデックスであるなら、関数は、今はインタ フェース名を含んでいる、ifnameで供給されたバッファを指し示す値を返す べきです。さもなければ、関数はヌルポインタを返し、そしてエラーを示す errnoを設定するべきです。もし指定されたインデックスに対応しているイン タフェースがないなら、errnoにENXIOが設定されます。もし(メモリ不足の ような)システムエラーがあったなら、errnoが適切な値に設定されるでしょ う(例えば、ENOMEM)。 4.3 Return All Interface Names and Indexes 4.3 全インタフェース名とインデックスを返す The if_nameindex structure holds the information about a single interface and is defined as a result of including the <net/if.h> header. if_nameindex構造体はひとつのインタフェースの情報を持ち、<net/if.h> で定義されます。 struct if_nameindex { unsigned int if_index; /* 1, 2, ... */ /* 1, 2, ... */ char *if_name; /* null terminated name: "le0", ... */ /* ヌルで終わる名前: "le0", ... */ }; The final function returns an array of if_nameindex structures, one structure per interface. 最後の関数はif_nameindex構造体の配列、インタフェース毎に1つの構造体、 を返します。 #include <net/if.h> struct if_nameindex *if_nameindex(void); The end of the array of structures is indicated by a structure with an if_index of 0 and an if_name of NULL. The function returns a NULL pointer upon an error, and would set errno to the appropriate value. 構造体の配列の終わりは0のif_indexとNULLのif_nameの構造体で示されます。 関数はエラーの場合に空のポインタを返し、errnoに適切な値を設定します。 The memory used for this array of structures along with the interface names pointed to by the if_name members is obtained dynamically. This memory is freed by the next function. if_nameメンバーにで指し示されたインタフェース名とこの構造体の配列で使 われたメモリは動的に得られます。このメモリは次の関数で解放されます。 4.4 Free Memory 4.4 メモリ開放 The following function frees the dynamic memory that was allocated by if_nameindex(). 次の関数はif_nameindex()の割り当てたダイナミックなメモリを解放します。 #include <net/if.h> void if_freenameindex(struct if_nameindex *ptr); The ptr argument shall be a pointer that was returned by if_nameindex(). After if_freenameindex() has been called, the application shall not use the array of which ptr is the address. ptr引数はif_nameindex()によって返されたポインタであるべきです。 if_freenameindex()が呼ばれた後、アプリケーションはptrが示す配列を使う べきではありません。 5. Socket Options 5. ソケットオプション A number of new socket options are defined for IPv6. All of these new options are at the IPPROTO_IPV6 level. That is, the "level" parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 when using these options. The constant name prefix IPV6_ is used in all of the new socket options. This serves to clearly identify these options as applying to IPv6. 多くの新しいソケットオプションがIPv6で定義されます。これらすべて の新しいオプションはIPPROTO_IPV6レベルにあります。すなわち、 getsockopt()とsetsockopt()呼び出しでの"level"パラメータは、これらの オプションを使う時、 IPPROTO_IPV6です。定数名プレフィックス、IPV6_が 新しいソケットオプションのすべてで使われます。これは明らかにIPv6 に適用するオプションを識別するのに役立ちます。 The declaration for IPPROTO_IPV6, the new IPv6 socket options, and related constants defined in this section are obtained by including the header <netinet/in.h>. IPPROTO_IPV6の宣言と、新しいIPv6ソケットオプションと、この章で定 義された関連した定数が<netinet/in.h>ヘッダで得られます。 5.1 Unicast Hop Limit 5.1 ユニキャストホップ限界 A new setsockopt() option controls the hop limit used in outgoing unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, and it is used at the IPPROTO_IPV6 layer. The following example illustrates how it is used: 新しいsetsockopt()オプションが外向ユニキャストIPv6パケットで使わ れたホップ限界を制御します。このオプションの名前はIPV6_UNICAST_HOPSで、 これはIPPROTO_IPV6レイヤで使われます。次の例は使い方法を例示します: int hoplimit = 10; if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, (char *) &hoplimit, sizeof(hoplimit)) == -1) perror("setsockopt IPV6_UNICAST_HOPS"); When the IPV6_UNICAST_HOPS option is set with setsockopt(), the option value given is used as the hop limit for all subsequent unicast packets sent via that socket. If the option is not set, the system selects a default value. The integer hop limit value (called x) is interpreted as follows: IPV6_UNICAST_HOPSオプションがsetsockopt()で設定される時、与えられたオ プション値はすべてのそのソケットから送らるユニキャストパケットでホッ プ限界として使われます。もしオプションが設定されないなら、システムは デフォルト値を選択します。(xと呼ばれる)整数ホップ限界値は次のように 翻訳されます: x < -1: return an error of EINVAL x == -1: use kernel default 0 <= x <= 255: use x x >= 256: return an error of EINVAL The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine the hop limit value that the system will use for subsequent unicast packets sent via that socket. For example: IPV6_UNICAST_HOPSオプションは、システムがそのソケットから次に送るユニ キャストパケットに使うであろうホップ限界値を決定するためgetsockopt() で使われるかもしれません。例えば: int hoplimit; socklen_t len = sizeof(hoplimit); if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, (char *) &hoplimit, &len) == -1) perror("getsockopt IPV6_UNICAST_HOPS"); else printf("Using %d for hop limit.\n", hoplimit); 5.2 Sending and Receiving Multicast Packets 5.2 マルチキャストパケットの送受信 IPv6 applications may send multicast packets by simply specifying an IPv6 multicast address as the destination address, for example in the destination address argument of the sendto() function. IPv6アプリケーションが、例えばsendto()関数の宛先アドレス引数で、 ただIPv6マルチキャストアドレスを宛先アドレスとして明示することに よってマルチキャストパケットを送るかもしれません。 Three socket options at the IPPROTO_IPV6 layer control some of the parameters for sending multicast packets. Setting these options is not required: applications may send multicast packets without using these options. The setsockopt() options for controlling the sending of multicast packets are summarized below. These three options can also be used with getsockopt(). IPPROTO_IPV6レイヤで3つのソケットオプションがマルチキャストパケット を送る際のパラメータのいくつかを制御します。これらのオプションを設定 することは必須でありません:アプリケーションがこれらのオプションを使 わないでマルチキャストパケットを送るかもしれません。マルチキャストパ ケットの送信制御のsetsockopt()オプションを下に要約します。これらの3 つのオプションはgetsockopt()で使うこともできます。 IPV6_MULTICAST_IF IPV6_MULTICAST_IF Set the interface to use for outgoing multicast packets. The argument is the index of the interface to use. If the interface index is specified as zero, the system selects the interface (for example, by looking up the address in a routing table and using the resulting interface). 外向マルチキャストパケットで使うインタフェースを指定。引数は使 用するインタフェースのインデックスです。もしインタフェースイン デックスがゼロと明示されるなら、システムはインタフェースを選び ます(例えば、アドレスをルーティングテーブルで調べて、そして結 果得られたインタフェースを使うことで)。 Argument type: unsigned int 引数タイプ : unsigned int IPV6_MULTICAST_HOPS IPV6_MULTICAST_HOPS Set the hop limit to use for outgoing multicast packets. (Note a separate option - IPV6_UNICAST_HOPS - is provided to set the hop limit to use for outgoing unicast packets.) 外向マルチキャストパケットのに使うホップ限界を設定。(外向ユニ キャストパケットに使うホップ限界を設定する別のオプション −IPV6_UNICAST_HOPS−が供給されることに注意してください。) The interpretation of the argument is the same as for the IPV6_UNICAST_HOPS option: 引数の解釈はIPV6_UNICAST_HOPSオプションと同じです: x < -1: return an error of EINVAL EINVALのエラーを返す x == -1: use kernel default カーネルデフォルトを使用 0 <= x <= 255: use x xを使用 x >= 256: return an error of EINVAL EINVALエラーを返す If IPV6_MULTICAST_HOPS is not set, the default is 1 (same as IPv4 today) もしIPV6_MULTICAST_HOPSが設定されないなら、デフォルトは (今日のIPv4と同じく)1です。 Argument type: int 引数タイプ : int IPV6_MULTICAST_LOOP IPV6_MULTICAST_LOOP If a multicast datagram is sent to a group to which the sending host itself belongs (on the outgoing interface), a copy of the datagram is looped back by the IP layer for local delivery if this option is set to 1. If this option is set to 0 a copy is not looped back. Other option values return an error of EINVAL. もしこのオプションが1に設定されたら、マルチキャストデータグラ ムが(外向インタフェース上の)送信ホスト自身が属するグループに 送られた時、データグラムのコピーがローカルな配達のためにIPレ イヤによってループバックされます。もしこのオプションが0に設定 されるなら、コピーがループバックされません。他のオプション値が EINVALエラーを返します。 If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same as IPv4 today). もしIPV6_MULTICAST_LOOPが設定されないなら、デフォルトは (今日のIPv4と同じく)1です。 Argument type: unsigned int 引数タイプ : unsigned int The reception of multicast packets is controlled by the two setsockopt() options summarized below. An error of EOPNOTSUPP is returned if these two options are used with getsockopt(). マルチキャストパケットの受信は下に要約した2つのsetsockopt()オプショ ンで制御されます。もしこれらの2つのオプションがgetsockopt()で使われ るなら、EOPNOTSUPPエラーが返されます。 IPV6_JOIN_GROUP IPV6_JOIN_GROUP Join a multicast group on a specified local interface. If the interface index is specified as 0, the kernel chooses the local interface. For example, some kernels look up the multicast group in the normal IPv6 routing table and use the resulting interface. 指定されたローカルインタフェース上のマルチキャストグループに加 入してください。もしインタフェースインデックスが0と明示される なら、カーネルはローカルインタフェースを選択します。例えば、あ るカーネルが標準的なIPv6ルーティングテーブルでマルチキャス トグループを検索し、得られたインタフェースを使います。 Argument type: struct ipv6_mreq 引数タイプ : struct ipv6_mreq IPV6_LEAVE_GROUP IPV6_LEAVE_GROUP Leave a multicast group on a specified interface. If the interface index is specified as 0, the system may choose a multicast group membership to drop by matching the multicast address only. 指定インタフェース上のマルチキャストグループから離脱。もしイン タフェースインデックスが0と明示されるなら、システムはマルチ キャストに一致するアドレスのみを捨てるためにマルチキャストグ ループメンバーシップを選択するかもしれません。 Argument type: struct ipv6_mreq 引数タイプ : struct ipv6_mreq The argument type of both of these options is the ipv6_mreq structure, defined as a result of including the <netinet/in.h> header; これらのオプションの両方の引数タイプはthe <netinet/in.h>ヘッダで定義 されたipv6_mreq構造体です; struct ipv6_mreq { struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ unsigned int ipv6mr_interface; /* interface index */ }; Note that to receive multicast datagrams a process must join the multicast group to which datagrams will be sent. UDP applications must also bind the UDP port to which datagrams will be sent. Some processes also bind the multicast group address to the socket, in addition to the port, to prevent other datagrams destined to that same port from being delivered to the socket. マルチキャストデータグラムを受け取るために、プロセスがデータグラムが 送られるであろうマルチキャストグループに加入しなくてはならないことに 注意してください。UDPアプリケーションが同じくデータグラムが送られ るであろうUDPポートをバインドしなくてはなりません。。あるプロセス が、その同じポート宛の他のデータグラムがソケットに配達されるのを阻止 するために、ポートに加えてマルチキャストグループアドレスをソケットに バインドします。 5.3 IPV6_V6ONLY option for AF_INET6 Sockets 5.3 AF_INET6ソケットのIPV6_V6ONLYオプション This socket option restricts AF_INET6 sockets to IPv6 communications only. As stated in section <3.7 Compatibility with IPv4 Nodes>, AF_INET6 sockets may be used for both IPv4 and IPv6 communications. Some applications may want to restrict their use of an AF_INET6 socket to IPv6 communications only. For these applications the IPV6_V6ONLY socket option is defined. When this option is turned on, the socket can be used to send and receive IPv6 packets only. This is an IPPROTO_IPV6 level option. This option takes an int value. This is a boolean option. By default this option is turned off. このソケットオプションはAF_INET6ソケットをIPv6通信のみに制限しま す。<3.7 IPv4ノードとの互換性>章で述べられるように、AF_INET6ソ ケットがIPv4とIPv6通信の両方で使われるかもしれません。あるア プリケーションがIPv6通信のみにAF_INET6ソケットの用途を限定するこ とを望むかもしれません。これらのアプリケーションのためにIPV6_V6ONLYソ ケットオプションが定義されます。このオプションがオンになっている時、 ソケットは送受信にIPv6パケットのみを使うことができます。これは IPPROTO_IPV6レベルオプションです。このオプションはint値をとります。 これはブールオプションです。デフォルトでこの選択はオフです。 Here is an example of setting this option: ここにこのオプションを設定することの例があります: int on = 1; if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&on, sizeof(on)) == -1) perror("setsockopt IPV6_V6ONLY"); else printf("IPV6_V6ONLY set\n"); Note - This option has no effect on the use of IPv4 Mapped addresses which enter a node as a valid IPv6 addresses for IPv6 communications as defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5]. ノート−このオプションは、IPv6がステートレスIP/ICMP翻訳ア ルゴリズム(SIIT)[5]で定義されるIPv6通信のための正しいIPv 6アドレスとしてノードに入力されたIPv4マップアドレスの使用に対す る効果を持っていません。 An example use of this option is to allow two versions of the same server process to run on the same port, one providing service over IPv6, the other providing the same service over IPv4. このオプションの使用の例は、同じサーバの同じポート上の2つのバージョ ンのプロセスが、一方がIPv6上のサービスを供給し、他方がIPv4の サービスを供給する、動作を許します。 6. Library Functions 6. ライブラリ関数 New library functions are needed to perform a variety of operations with IPv6 addresses. Functions are needed to lookup IPv6 addresses in the Domain Name System (DNS). Both forward lookup (nodename-to- address translation) and reverse lookup (address-to-nodename translation) need to be supported. Functions are also needed to convert IPv6 addresses between their binary and textual form. 新しいライブラリ関数がIPv6アドレスでいろいろな操作を実行するため に必要とされます。関数がドメインネームシステム(DNS)でIPv6ア ドレスを検索するために必要とされます。前方検索(ノード名からアドレス への翻訳)と逆検索(アドレスからノード名への翻訳)の両方がサポートさ れる必要があります。バイナリ形式とテキスト形式のIPv6アドレス間の 翻訳関数が同じく必要です。 We note that the two existing functions, gethostbyname() and gethostbyaddr(), are left as-is. New functions are defined to handle both IPv4 and IPv6 addresses. 我々は2つの既存の関数、gethostbyname()とgethostbyaddr()、が現状のま ま残ることを指摘します。新しい関数がIPv4とIPv6アドレス両方を 処理するために定義されます。 The commonly used function gethostbyname() is inadequate for many applications, first because it provides no way for the caller to specify anything about the types of addresses desired (IPv4 only, IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many implementations of this function are not thread safe. RFC 2133 defined a function named gethostbyname2() but this function was also inadequate, first because its use required setting a global option (RES_USE_INET6) when IPv6 addresses were required, and second because a flag argument is needed to provide the caller with additional control over the types of addresses required. The gethostbyname2() function was deprecated in RFC 2553 and is no longer part of the basic API. 一般に使われる関数gethostbyname()は多くのアプリケーションに対して不十 分です、第一に関数が要望されるアドレスタイプ(IPv4のみ、IPv6 のみの、IPv4マップIPv6がOKなど)について呼び出し人が指定する 方法を供給しないし、第二にこの関数の多くの実装がスレッドに安全ではな いからです。RFC2133がgethostbyname2()という名前の機能を定義し ましたが、この関数は、第一にIPv6アドレスが必要な時にグローバルオ プション(RES_USE_INET6)の設定が必要で、第二にフラグ引数が必要なタイ プのアドレスの追加の制御を呼び出し人に提供するために必要なため、同じ く不適当です。gethostbyname2()関数はRFC2553で廃止されれ、そし てもう基本API の一部ではありません。 6.1 Protocol-Independent Nodename and Service Name Translation 6.1 プロトコルに依存しないノード名とサービス名翻訳 Nodename-to-address translation is done in a protocol-independent fashion using the getaddrinfo() function. ノード名からアドレスへの翻訳がgetaddrinfo()関数を使ってプロトコルに依 存しない方法でされます。 #include <sys/socket.h> #include <netdb.h> int getaddrinfo(const char *nodename, const char *servname, const struct addrinfo *hints, struct addrinfo **res); void freeaddrinfo(struct addrinfo *ai); struct addrinfo { int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, .. */ int ai_family; /* AF_xxx */ int ai_socktype; /* SOCK_xxx */ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ socklen_t ai_addrlen; /* length of ai_addr */ /* ai_addrの長さ */ char *ai_canonname; /* canonical name for nodename */ /* ノード名の正規化名 */ struct sockaddr *ai_addr; /* binary address */ /* バイナリアドレス */ struct addrinfo *ai_next; /* next structure in linked list */ /* リンクしたリストの次の要素 */ }; The getaddrinfo() function translates the name of a service location (for example, a host name) and/or a service name and returns a set of socket addresses and associated information to be used in creating a socket with which to address the specified service. getaddrinfo()関数はサービスの場所の名前(例えば、ホスト名)とサービス 名を翻訳して、そして指定されたサービスへのソケットを作り、使われるべ きソケットアドレスと関連づけられた情報を返します。 The nodename and servname arguments are either null pointers or pointers to null-terminated strings. One or both of these two arguments must be a non-null pointer. nodenameとservname引数はヌルポインタあるいはヌルで終了する文字列への ポインタです。これらの2つの引数の1つあるいは両方がゼロでないポイン タであるに違いありません。 The format of a valid name depends on the address family or families. If a specific family is not given and the name could be interpreted as valid within multiple supported families, the implementation will attempt to resolve the name in all supported families and, in absence of errors, one or more results shall be returned. 正当な名前のフォーマットはアドレスファミリーに依存します。もし特定の ファミリーが与えられず、そして多数のサポートされたファミリーで名前が 正当であると解釈されるなら、実装はすべてのサポートされたファミリーで 名前の変換を試み、そして、エラーがなければ、1つ以上の結果が返される べきです。 If the nodename argument is not null, it can be a descriptive name or can be an address string. If the specified address family is AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host names. If the specified address family is AF_INET or AF_UNSPEC, address strings using Internet standard dot notation as specified in inet_addr() are valid. If the specified address family is AF_INET6 or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are valid. もしnodename引数がヌルでないなら、それは記述的名前か、アドレス文字列 です。もし指定されたアドレスファミリーがAF_INETかAF_INET6かAF_UNSPEC であるなら、正当な記述的名前がホスト名を含みます。もし指定されたアド レスファミリーがAF_INETあるいはAF_UNSPECであるなら、インターネット標 準表記法を使っているアドレス文字列はinet_addr()で指定されるように正当 です。もし指定されたアドレスファミリーがAF_INET6あるいはAF_UNSPECであ るなら、inet_pton()で記述された標準的なIPv6テキスト書式は正当です。 If nodename is not null, the requested service location is named by nodename; otherwise, the requested service location is local to the caller. もしnodenameがヌルでないなら、求められたサービスの場所はnodenameで指 定されます;さもなければ、求められたサービスの場所は呼び出し人にロー カルです。 If servname is null, the call shall return network-level addresses for the specified nodename. If servname is not null, it is a null- terminated character string identifying the requested service. This can be either a descriptive name or a numeric representation suitable for use with the address family or families. If the specified address family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be specified as a string specifying a decimal port number. もしservnameがヌルであるなら、呼び出しは指定されたnodenameのネットワー クレベルアドレスを返すべきです。もしservnameがヌルでないなら、それは 求められたサービスを識別するヌルで終了する文字列です。これはアドレス ファミリーで使用が適切な、記述的名前か数値表現です。もし指定されたア ドレスファミリーがAF_INETかAF_INET6かAF_UNSPECであるなら、サービスは 10進法のポート番号を指定する文字列として明示できます。 If the argument hints is not null, it refers to a structure containing input values that may direct the operation by providing options and by limiting the returned information to a specific socket type, address family and/or protocol. In this hints structure every member other than ai_flags, ai_family, ai_socktype and ai_protocol shall be set to zero or a null pointer. A value of AF_UNSPEC for ai_family means that the caller shall accept any address family. A value of zero for ai_socktype means that the caller shall accept any socket type. A value of zero for ai_protocol means that the caller shall accept any protocol. If hints is a null pointer, the behavior shall be as if it referred to a structure containing the value zero for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC for the ai_family field. もし引数hintsがヌルでなければ、入力値を含む構造体を参照します、入力値 はオプションで供給され、返す情報を特定のソケットタイプやアドレスファ ミリーやプロトコルに制限する、操作を指揮します。このhints構造体で、 ai_flagsとai_familyとai_socktypeとai_protocol以外のメンバーがゼロかヌ ルポインタを設定されるべきです。ai_familyのAF_UNSPEC値が呼び出し人が どんなアドレスファミリーでも受け入れることを意味します。ai_socktypeの ゼロの値が呼び出し人がどんなソケットタイプでも受け入れることを意味し ます。ai_protocolのゼロの値が呼び出し人がどんなプロトコルでも受け入れ ることを意味します。もしhintsがヌルなら、ai_flagsとai_socktypeと ai_protocolフィールドがゼロでai_familyフィールドがAF_UNSPECである構造 体を参照するかのようにふるまうべきです。 Note: ノート: 1. If the caller handles only TCP and not UDP, for example, then the ai_protocol member of the hints structure should be set to IPPROTO_TCP when getaddrinfo() is called. 1. 例えば、もし呼び出し人がUDPではなくTCPだけを扱うなら、hints 構造体のai_protocolメンバーは、getaddrinfo()が呼ばれる時、 IPPROTO_TCPを設定されるべきです。 2. If the caller handles only IPv4 and not IPv6, then the ai_family member of the hints structure should be set to AF_INET when getaddrinfo() is called. 2. もし呼び出し人がIPv6ではなくIPv4だけを処理するなら、 getaddrinfo()が呼ばれるときにhints構造体のai_familyメンバーは AF_INETが設定されるべきです。 The ai_flags field to which hints parameter points shall be set to zero or be the bitwise-inclusive OR of one or more of the values AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG. hintsパラメータが示すai_flagsフィールドはゼロが設定されるか、 AI_PASSIVEとAI_CANONNAMEとAI_NUMERICHOSTとAI_NUMERICSERVとAI_V4MAPPED とAI_ALLとAI_ADDRCONFIGの1つ以上の値のビット単位の包含ORです。 If the AI_PASSIVE flag is specified, the returned address information shall be suitable for use in binding a socket for accepting incoming connections for the specified service (i.e., a call to bind()). In this case, if the nodename argument is null, then the IP address portion of the socket address structure shall be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the AI_PASSIVE flag is not specified, the returned address information shall be suitable for a call to connect() (for a connection-mode protocol) or for a call to connect(), sendto() or sendmsg() (for a connectionless protocol). In this case, if the nodename argument is null, then the IP address portion of the socket address structure shall be set to the loopback address. This flag is ignored if the nodename argument is not null. もしAI_PASSIVEフラグが指定されるなら、返されたアドレス情報は指定サー ビスの接続を受け付けるソケットに使用する(つまりbind())に適するべき です。この場合、もしnodename引数がヌルであるなら、ソケットアドレス構 造体のIPアドレス部は、IPv4アドレスではINADDR_ANYで、IPv6ア ドレスではIN6ADDR_ANY_INITになるべきです。もしAI_PASSIVEフラグが指定 されないなら、返されたアドレス情報はconnect()呼出(接続モードプロトコ ルで)や、 connect()やsendto()やsendmsg()呼び出し(コネクションレスプ ロトコルのために)で、適するべきです。この場合、もしnodename引数がヌ ルであるなら、ソケットアドレス構造体のIPアドレス部はループバックア ドレスが設定されるべきです。このフラグは、もしnodename引数がヌルでな いなら、無視されます。 If the AI_CANONNAME flag is specified and the nodename argument is not null, the function shall attempt to determine the canonical name corresponding to nodename (for example, if nodename is an alias or shorthand notation for a complete name). もしAI_CANONNAMEフラグが指定され、nodename引数がヌルでないなら、関数 はnodenameに対応している規準名を決定しようと試みるべきです(例えば、 もしnodenameが別名や完全名の省略表記の場合)。 If the AI_NUMERICHOST flag is specified, then a non-null nodename string supplied shall be a numeric host address string. Otherwise, an [EAI_NONAME] error is returned. This flag shall prevent any type of name resolution service (for example, the DNS) from being invoked. もしAI_NUMERICHOSTフラグが設定されるなら、文字列が供給したヌルでない nodenameが数値ホストアドレス文字列であるべきです。さもなければ、 [EAI_NONAME]エラーが返されます。このフラグは呼び出された時に、いかな る名前解決サービス(例えば、DNS)も妨げるべきです。 If the AI_NUMERICSERV flag is specified, then a non-null servname string supplied shall be a numeric port string. Otherwise, an [EAI_NONAME] error shall be returned. This flag shall prevent any type of name resolution service (for example, NIS+) from being invoked. もしAI_NUMERICSERVフラグが指定されるなら、供給されたヌルでない servname文字列が数値ポート文字列であるべきです。さもなければ、 [EAI_NONAME]エラーが返されるべきです。このフラグは名前解決サービス (例えば、NIS+)が呼ばれるのを阻止するべきです。 If the AI_V4MAPPED flag is specified along with an ai_family of AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses on finding no matching IPv6 addresses (ai_addrlen shall be 16). もしAI_V4MAPPEDフラグがAF_INET6のai_familyとともに指定されるなら、 getaddrinfo()が一致するIPv6アドレスが見つけられない場合にIPv4 マップIPv6アドレスを返すべきです(ai_addrlenは16であるべきです)。 For example, when using the DNS, if no AAAA records are found then a query is made for A records and any found are returned as IPv4- mapped IPv6 addresses. 例えば、DNSを使う時、もしAAAAレコードが見つからないなら、 Aレコード問合せがなされ、そして見つかったものがIPv4マップ IPv6アドレスとして返されます。 The AI_V4MAPPED flag shall be ignored unless ai_family equals AF_INET6. AI_V4MAPPEDフラグは、ai_familyがAF_INET6でないなら無視されるべきです。 If the AI_ALL flag is used with the AI_V4MAPPED flag, then getaddrinfo() shall return all matching IPv6 and IPv4 addresses. もしAI_ALLフラグがAI_V4MAPPEDフラグと共に使われるなら、getaddrinfo() がすべての一致するIPv6とIPv4アドレスを返すべきです。 For example, when using the DNS, queries are made for both AAAA records and A records, and getaddrinfo() returns the combined results of both queries. Any IPv4 addresses found are returned as IPv4-mapped IPv6 addresses. 例えば、DNSを使う時、問合せがAAAAレコードとAレコードの両方 でされ、そしてgetaddrinfo()が両方の問合せの結合結果を返します。見 つかったIPv4アドレスはIPv4マップIPv6アドレスとして返さ れます。 The AI_ALL flag without the AI_V4MAPPED flag is ignored. AI_V4MAPPEDフラグがないAI_ALLフラグは無視されます。 Note: ノート: When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and AI_ALL flags will only be used if AF_INET6 is supported. ai_familyが指定されない時、もしAF_INET6がサポートされるなら、 (AF_UNSPECと)AI_V4MAPPEDとAI_ALLフラグだけが使われるでしょう。 If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system. The loopback address is not considered for this case as valid as a configured address. もしAI_ADDRCONFIGフラグが指定されるなら、IPv4アドレスがローカルシ ステムで設定される場合に限りIPv4アドレスが返されるべきです、そし てIPv6アドレスがローカルシステム上に設定される場合に限りIPv6 アドレスが返されるべきです。ループバックアドレスはこの場合効力がある 設定と考えられません。 For example, when using the DNS, a query for AAAA records should occur only if the node has at least one IPv6 address configured (other than IPv6 loopback) and a query for A records should occur only if the node has at least one IPv4 address configured (other than the IPv4 loopback). 例えば、 DNSを使う時にAAAAレコードの質問はノードが少なくと も1つの(IPv6ループバック以外の)設定されたIPv6アドレス を持っている場合に限り起こり、そしてAレコードの質問がノードが少 なくとも1つの(IPv4ループバック以外の)設定されたIPv4ア ドレスを持っている場合に限り起こるべきです。 The ai_socktype field to which argument hints points specifies the socket type for the service, as defined for socket(). If a specific socket type is not given (for example, a value of zero) and the service name could be interpreted as valid with multiple supported socket types, the implementation shall attempt to resolve the service name for all supported socket types and, in the absence of errors, all possible results shall be returned. A non-zero socket type value shall limit the returned information to values with the specified socket type. hints引数が示すai_socktypeフィールドは、socket()のために定義されるサー ビスのためのソケットタイプを指定します。もし特定のソケットタイプが与 えられなければ(例えば、ゼロの値)、そしてサービス名が多数のサポート されたソケットタイプで正当であると解釈できたなら、実装はすべてのサポー トされたソケットタイプのためにサービス名を変換しようと試みるべきです、 そして、エラーがなければ、すべての可能な結果は返されるべきです。ゼロ 以外のソケットタイプ値は、返される情報を指定されたソケットタイプの値 を持つものに制限するべきです。 If the ai_family field to which hints points has the value AF_UNSPEC, addresses shall be returned for use with any address family that can be used with the specified nodename and/or servname. Otherwise, addresses shall be returned for use only with the specified address family. If ai_family is not AF_UNSPEC and ai_protocol is not zero, then addresses are returned for use only with the specified address family and protocol; the value of ai_protocol shall be interpreted as in a call to the socket() function with the corresponding values of ai_family and ai_protocol. もしhintsが示すai_familyフィールドがAF_UNSPECであるなら、指定された ノード名とサービス名が使えるアドレスファミリーで使うためのアドレスが 返されるべきです。さもなければ、指定されたアドレスファミリーでだけ使 用するためのアドレスが返されるべきです。もしai_familyがAF_UNSPECでな く、ai_protocolがゼロでないなら、指定されたアドレスファミリーとプロト コルでだけ使用のためのアドレスが返されます;ai_protocol値はsocket()呼 出でai_familyとai_protocolの対応する値に翻訳されるべきです。 The freeaddrinfo() function frees one or more addrinfo structures returned by getaddrinfo(), along with any additional storage associated with those structures (for example, storage pointed to by the ai_canonname and ai_addr fields; an application must not reference this storage after the associated addrinfo structure has been freed). If the ai_next field of the structure is not null, the entire list of structures is freed. The freeaddrinfo() function must support the freeing of arbitrary sublists of an addrinfo list originally returned by getaddrinfo(). freeaddrinfo()関数はgetaddrinfo()で返された1つ以上のアドレス構造体を 構造体に関連する追加の記憶領域と共に開放します(例えば、ai_canonname とai_addrフィールドの示すメモリ;アプリケーションが関連したaddrinfo構 造体が開放された後でこのメモリを参照してはなりません)。もし構造体の ai_nextフィールドがゼロではないなら、構造体の全部のリストが開放されま す。freeaddrinfo()関数はgetaddrinfo()によって返されたaddrinfoリストの 任意の部分リストの開放をサポートしなくてはなりません。 Functions getaddrinfo() and freeaddrinfo() must be thread-safe. getaddrinfo()とfreeaddrinfo()関数がスレッドで安全に違いありません。 A zero return value for getaddrinfo() indicates successful completion; a non-zero return value indicates failure. The possible values for the failures are listed below under Error Return Values. getaddrinfo()のゼロの戻り値が成功した完了を示します;ゼロ以外の戻り値 が失敗を示します。失敗の可能な値はエラーリターン値の下でリストアップ されます。 Upon successful return of getaddrinfo(), the location to which res points shall refer to a linked list of addrinfo structures, each of which shall specify a socket address and information for use in creating a socket with which to use that socket address. The list shall include at least one addrinfo structure. The ai_next field of each structure contains a pointer to the next structure on the list, or a null pointer if it is the last structure on the list. Each structure on the list shall include values for use with a call to the socket() function, and a socket address for use with the connect() function or, if the AI_PASSIVE flag was specified, for use with the bind() function. The fields ai_family, ai_socktype, and ai_protocol shall be usable as the arguments to the socket() function to create a socket suitable for use with the returned address. The fields ai_addr and ai_addrlen are usable as the arguments to the connect() or bind() functions with such a socket, according to the AI_PASSIVE flag. getaddrinfo()が成功して戻ると、resの示す場所はaddrinfo構造体リンクリ ストを参照し、それぞれのaddrinfo構造体はソケットを作るのに使うソケッ トアドレスと情報を指定するべきです。リストは少なくとも1つのaddrinfo 構造体を含むべきです。それぞれの構造体のai_nextフィールドはリストの 次の構造体を示し、もしそれがリストの上に最後の構造体であるならヌルポ インタです。リスト上の各構造体がsocket()関数で使用するための値、と connect()関数で使うための、または、もしAI_PASSIVEフラグが指定される なら、bind()関数で使用するためのソケットアドレスを含むべきです。 ai_familyとai_socktypeとai_protocolフィールドは、返されたアドレスで 使用するに適したソケットを作るsocket()関数の引数として有用であるべき です。AI_PASSIVEフラグに依存して、ai_addrとai_addrlenフィールドは各 ソケットのconnect()かbind()関数の引数に有用です。 If nodename is not null, and if requested by the AI_CANONNAME flag, the ai_canonname field of the first returned addrinfo structure shall point to a null-terminated string containing the canonical name corresponding to the input nodename; if the canonical name is not available, then ai_canonname shall refer to the nodename argument or a string with the same contents. The contents of the ai_flags field of the returned structures are undefined. もしノード名がヌルでなく、そしてもしAI_CANONNAMEフラグによって求めら れる、最初の返されたaddrinfo構造体のai_canonnameフィールドが入力ノー ド名に対応した規準名を含むヌルで終わる文字列を示します;もし規準名が 利用可能ではないなら、ai_canonnameがノード名引数か同じ中身での文字列 を参照するべきです。返された構造体のai_flagsフィールドの内容は不確定 です。 All fields in socket address structures returned by getaddrinfo() that are not filled in through an explicit argument (for example, sin6_flowinfo) shall be set to zero. 明示的な引数(例えば、sin6_flowinfo)を通して記入されたの以外のすべて のgetaddrinfo()によって返されたソケットアドレス構造体のフィールドはゼ ロに設定されるべきです。 Note: This makes it easier to compare socket address structures. メモ:これはソケットアドレス構造体を比較することをより容易にします。 Error Return Values: エラーリターン値: The getaddrinfo() function shall fail and return the corresponding value if: getaddrinfo()関数は次の場合失敗し、対応する値を返すべきです: [EAI_AGAIN] The name could not be resolved at this time. Future attempts may succeed. 現在名前解決ができませんでした。将来の試みが成功する かもしれません。 [EAI_BADFLAGS] The flags parameter had an invalid value. フラグパラメータは無効な値を持っていました。 [EAI_FAIL] A non-recoverable error occurred when attempting to resolve the name. 名前を変換しようと試みる時に回復可能でないエラーが起 こりました。 [EAI_FAMILY] The address family was not recognized. アドレスファミリーは認識できませんでした。 [EAI_MEMORY] There was a memory allocation failure when trying to allocate storage for the return value. 戻り値のメモリを割り当てようとする時、メモリ障害があ りました。 [EAI_NONAME] The name does not resolve for the supplied parameters. Neither nodename nor servname were supplied. At least one of these must be supplied. 供給されたパラメータのための名前が解決できません。ノー ド名とサービス名のいずれも供給されませんでした。少な くともこれらの1つが供給されなくてはなりません。 [EAI_SERVICE] The service passed was not recognized for the specified socket type. 渡されたサービスは指定されたソケットタイプに対して認 識できませんでした。 [EAI_SOCKTYPE] The intended socket type was not recognized. 意図するソケットタイプは認識できませんでした。 [EAI_SYSTEM] A system error occurred; the error code can be found in errno. システムエラーが起こりました;エラーコードはerrnoで見 つかります。 The gai_strerror() function provides a descriptive text string corresponding to an EAI_xxx error value. gai_strerror()関数はEAI_xxx エラー値に対応している記述的なテキスト文 字列を供給します。 #include <netdb.h> const char *gai_strerror(int ecode); The argument is one of the EAI_xxx values defined for the getaddrinfo() and getnameinfo() functions. The return value points to a string describing the error. If the argument is not one of the EAI_xxx values, the function still returns a pointer to a string whose contents indicate an unknown error. 引数はgetaddrinfo()とgetnameinfo()関数のために定義されたEAI_xxx値の 1つです。戻り値はエラーを記述している文字列を指し示します。もし引数 がEAI_xxx値の1つではないなら、関数は未知のエラーを示す文字列へのポ インタを返します。 6.2 Socket Address Structure to Node Name and Service Name 6.2 ノード名とサービス名へのソケットアドレス構造体 The getnameinfo() function is used to translate the contents of a socket address structure to a node name and/or service name. getnameinfo()関数はソケットアドレス構造体の内容をノード名やサービス 名に翻訳するために使われます。 #include <sys/socket.h> #include <netdb.h> int getnameinfo(const struct sockaddr *sa, socklen_t salen, char *node, socklen_t nodelen, char *service, socklen_t servicelen, int flags); The getnameinfo() function shall translate a socket address to a node name and service location, all of which are defined as in getaddrinfo(). getnameinfo()関数はソケットアドレスをノード名前とサービスの場所に翻訳 するべきです、そしてそのすべてはgetaddrinfo() のように定義されます。 The sa argument points to a socket address structure to be translated. sa引数は翻訳されるソケットアドレス構造体を示します。 The salen argument holds the size of the socket address structure pointed to by sa. salen引数はsaで示されたソケットアドレス構造体の大きさを示します。 If the socket address structure contains an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, the implementation shall extract the embedded IPv4 address and lookup the node name for that IPv4 address. もしソケットアドレス構造体がIPv4マップIPv6アドレスあるいはI Pv4互換IPv6アドレスを含んでいるなら、実装は埋め込みIPv4ア ドレスを引き抜いて、そしてそのIPv4アドレスのノード名を検索するべ きです。 Note: The IPv6 unspecified address ("::") and the IPv6 loopback address ("::1") are not IPv4-compatible addresses. If the address is the IPv6 unspecified address ("::"), a lookup is not performed, and the [EAI_NONAME] error is returned. ノート:特定されていないIPv6アドレス("::")そしてIPv6ルー プバックアドレス("::1")はIPv4互換アドレスでありません。もし アドレスがIPv6の特定されていないアドレスであるなら("::")、検 索行われず、そして[EAI_NONAME]エラーが返されます。 If the node argument is non-NULL and the nodelen argument is nonzero, then the node argument points to a buffer able to contain up to nodelen characters that receives the node name as a null-terminated string. If the node argument is NULL or the nodelen argument is zero, the node name shall not be returned. If the node's name cannot be located, the numeric form of the node's address is returned instead of its name. もしnode引数がヌルではなく、そしてnodelen引数がゼロ以外であるなら、 node引数はnodelen文字以下のヌルで終了する文字列としてノード名を受け取 ることが可能なバッファを指し示します。もしnode引数が空であるか、ある いはnodelen引数がゼロであるなら、ノード名は返されるべきではありません。 もしノードの名前がなければ、ノードのアドレスの数値形式が名前の代わり に返されます。 If the service argument is non-NULL and the servicelen argument is non-zero, then the service argument points to a buffer able to contain up to servicelen bytes that receives the service name as a null-terminated string. If the service argument is NULL or the servicelen argument is zero, the service name shall not be returned. If the service's name cannot be located, the numeric form of the service address (for example, its port number) shall be returned instead of its name. もしservice引数がヌルではなく、servicelen引数がゼロ以外であるなら、 service引数はservicelen文字以下のヌルで終了する文字列のサービス名を受 け取ることが可能なバッファを指し示します。もしservice引数がヌルである か、あるいはservicelen引数がゼロであるなら、サービス名は返されるべき ではありません。もしサービス名が見つからないなら、サービスアドレスの 数値形式(例えば、そのポート番号)がその名前の代わりに返されるべきで す。 The arguments node and service cannot both be NULL. node引数とservice引数が共にヌルであるはずがありません。 The flags argument is a flag that changes the default actions of the function. By default the fully-qualified domain name (FQDN) for the host shall be returned, but: flags引数は関数のデフォルト行動を変えるフラグです。デフォルトで、ホス トの完全修飾ドメイン名(FQDN)が返されるべきです、しかし: - If the flag bit NI_NOFQDN is set, only the node name portion of the FQDN shall be returned for local hosts. - もしflagビットNI_NOFQDNが設定されるなら、ローカルホストについて、 ただFQDNのノード名の部分だけが返されるべきです。 - If the flag bit NI_NUMERICHOST is set, the numeric form of the host's address shall be returned instead of its name, under all circumstances. - もしflagビットNI_NUMERICHOSTが設定されるなら、ホストアドレスの数値 形式が名前の代わりにすべての状況下で返されるべきです。 - If the flag bit NI_NAMEREQD is set, an error shall be returned if the host's name cannot be located. - もしflagビットNI_NAMEREQDが設定され、もしホスト名が見つからないな ら、エラーが返されるべきです。 - If the flag bit NI_NUMERICSERV is set, the numeric form of the service address shall be returned (for example, its port number) instead of its name, under all circumstances. - もしflagビットNI_NUMERICSERVが設定されるなら、全ての状況下で名前の 代わりにサービスアドレスの数値形式が返されるべきです(例えばポート 番号)。 - If the flag bit NI_DGRAM is set, this indicates that the service is a datagram service (SOCK_DGRAM). The default behavior shall assume that the service is a stream service (SOCK_STREAM). - もしflagビットNI_DGRAMが設定されるなら、これはサービスがデータグラ ムサービス(SOCK_DGRAM)であることを示します。デフォルト行動はサー ビスがフローサービス(SOCK_STREAM)であると想定するべきです。 Note: ノート: 1. The NI_NUMERICxxx flags are required to support the "-n" flags that many commands provide. 1. NI_NUMERICxxxフラグは多くのコマンドが供給する"-n"フラグをサポート するように要求されます。 2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6 port numbers (for example, [512,514]) that represent different services for UDP and TCP. 2. NI_DGRAMフラグはUDPとTCPで異なったサービス表現を務める少数 のAF_INETとAF_INET6ポート番号(例えば、[512,514])のために必要と されます。 The getnameinfo() function shall be thread safe. getnameinfo()関数はスレッドで安全であるべきです。 A zero return value for getnameinfo() indicates successful completion; a non-zero return value indicates failure. getnameinfo()のゼロの返り値が成功した終了を示します;ゼロ以外の返り値 が失敗を示します。 Upon successful completion, getnameinfo() shall return the node and service names, if requested, in the buffers provided. The returned names are always null-terminated strings. 成功した場合、getnameinfo()は、もし求められるなら、供給されたバッファ でノード名とサービス名を提供するべきです。返された名前は常にヌルで終 了する文字列です。 Error Return Values: エラー返り値: The getnameinfo() function shall fail and return the corresponding value if: getnameinfo()関数は以下の場合に失敗し、対応する値を返すべきです: [EAI_AGAIN] The name could not be resolved at this time. Future attempts may succeed. 名前は今は解決できませんでした。将来の試みが成功するか もしれません。 [EAI_BADFLAGS] The flags had an invalid value. フラグは無効な値です。 [EAI_FAIL] A non-recoverable error occurred. 回復可能でないエラーが起こりました。 [EAI_FAMILY] The address family was not recognized or the address length was invalid for the specified family. アドレスファミリーは認識できませんでした、あるいはアド レス長は指定されたファミリーで無効でした。 [EAI_MEMORY] There was a memory allocation failure. メモリ割当て障害がありました。 [EAI_NONAME] The name does not resolve for the supplied parameters. NI_NAMEREQD is set and the host's name cannot be located, or both nodename and servname were null. 供給されたパラメータのための名前は認識できません。 NI_NAMEREQDが設定され、ホスト名がないか、nodenameと servnameの両方がヌルでした。 [EAI_OVERFLOW] An argument buffer overflowed. 引数バッファがあふれました。 [EAI_SYSTEM] A system error occurred. The error code can be found in errno. システムエラーが起こりました。エラーコードはerrnoで見 いださます。 6.3 Address Conversion Functions 6.3 アドレス変換関数 The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4 address between binary and text form. IPv6 applications need similar functions. The following two functions convert both IPv6 and IPv4 addresses: 2つのIPv4関数inet_addr()とinet_ntoa()はバイナリとテキスト形式の 間でIPv4アドレスを変えます。IPv6アプリケーションが類似の関数 を必要とします。次の2つの関数はIPv6とIPv4アドレスの両方を変 換します: #include <arpa/inet.h> int inet_pton(int af, const char *src, void *dst); const char *inet_ntop(int af, const void *src, char *dst, socklen_t size); The inet_pton() function shall convert an address in its standard text presentation form into its numeric binary form. The af argument shall specify the family of the address. The AF_INET and AF_INET6 address families shall be supported. The src argument points to the string being passed in. The dst argument points to a buffer into which the function stores the numeric address; this shall be large enough to hold the numeric address (32 bits for AF_INET, 128 bits for AF_INET6). The inet_pton() function shall return 1 if the conversion succeeds, with the address pointed to by dst in network byte order. It shall return 0 if the input is not a valid IPv4 dotted-decimal string or a valid IPv6 address string, or -1 with errno set to EAFNOSUPPORT if the af argument is unknown. inet_pton()関数は標準テキスト表現形式でのアドレスをその数値バイナリー 形式に変換するべきです。af引数はアドレスファミリーを指定するべきです。 AF_INETとAF_INET6アドレスファミリーがサポートされるべきです。文字列を 示すsrc引数が渡されます。dst引数は関数が数値アドレスを記載するバッファ を指し示します;これは数値アドレス(AF_INETで32ビット、AF_INET6 で 128ビット)を持つのに十分な大きさであるべきです。inet_pton()関数は、 もし変換が、ネットワークバイト順でdstによって指し示されたアドレスで、 成功するなら、1を返すべきです。それは、もし入力が正当なIPv4ドッ ト区切り10進数文字列か正当なIPv6アドレス文字列でないなら0を返 し、引数が未知ならかerrnoにEAFNOSUPPORTを設定し−1を返すべきです。 If the af argument of inet_pton() is AF_INET, the src string shall be in the standard IPv4 dotted-decimal form: もしinet_pton()のaf引数がAF_INETであるなら、src文字列は標準的IPv4 ドット区切り形式であるべきです: ddd.ddd.ddd.ddd where "ddd" is a one to three digit decimal number between 0 and 255. The inet_pton() function does not accept other formats (such as the octal numbers, hexadecimal numbers, and fewer than four numbers that inet_addr() accepts). 「ddd」が0と255の間の1桁から3桁の数です。inet_pton()関数は (inet_addr()が受け入れる、8進数や16進数や4つ未満の数など)他の フォーマットを受け入れません。 If the af argument of inet_pton() is AF_INET6, the src string shall be in one of the standard IPv6 text forms defined in Section 2.2 of the addressing architecture specification [2]. もしinet_pton()のaf引数がAF_INET6であるなら、src文字列がアドレス体系 仕様[2]の2.2章で定義される標準IPv6テキスト形式の1つであるべき です。 The inet_ntop() function shall convert a numeric address into a text string suitable for presentation. The af argument shall specify the family of the address. This can be AF_INET or AF_INET6. The src argument points to a buffer holding an IPv4 address if the af argument is AF_INET, or an IPv6 address if the af argument is AF_INET6; the address must be in network byte order. The dst argument points to a buffer where the function stores the resulting text string; it shall not be NULL. The size argument specifies the size of this buffer, which shall be large enough to hold the text string (INET_ADDRSTRLEN characters for IPv4, INET6_ADDRSTRLEN characters for IPv6). inet_ntop()関数は数値アドレスを表示に適したテキスト文字列に変換するべ きです。af引数はアドレスファミリーを指定するべきです。これはAF_INETや AF_INET6であり得ます。src引数は、もしaf引数がAF_INETならばIPv4ア ドレスを設定したバッファを示し、af引数がAF_INET6であるならIPv6ア ドレスを設定したバッファを示します;アドレスはネットワークバイト順で あるに違いありません。dst引数は関数が生成するテキスト文字列をストアす るバッファを指し示します;それはヌルであるべきではありません。size引 数はこのバッファの大きさを指定し、これはテキスト文字列を持つのに十分 な大きさであるべきです(IPv4でINET_ADDRSTRLEN文字、IPv6で INET6_ADDRSTRLEN文字)。 In order to allow applications to easily declare buffers of the proper size to store IPv4 and IPv6 addresses in string form, the following two constants are defined in <netinet/in.h>: アプリケーションが容易にIPv4とIPv6アドレスの文字列形式に適切 な大きさのバッファを宣言することを許すために、次の2つの定数が <netinet/in.h>で定義されます: #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 The inet_ntop() function shall return a pointer to the buffer containing the text string if the conversion succeeds, and NULL otherwise. Upon failure, errno is set to EAFNOSUPPORT if the af argument is invalid or ENOSPC if the size of the result buffer is inadequate. inet_ntop()関数は、もし変換が成功するなら、テキスト文字列を含むバッ ファへのポインタを返し、さもなければヌルを返すべきです。失敗した場合、 もしaf引数が不適当ならerrnoにEAFNOSUPPORTが設定され、もし結果バッファ のサイズが不適当であるならerrnoにENOSPCが設定されます。 6.4 Address Testing Macros 6.4 アドレステストマクロ The following macros can be used to test for special IPv6 addresses. 次のマクロは特別なIPv6アドレスのテストをするために使うことができ ます。 #include <netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *); int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *); int IN6_IS_ADDR_MULTICAST (const struct in6_addr *); int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *); int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *); int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *); int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *); int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *); int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *); The first seven macros return true if the address is of the specified type, or false otherwise. The last five test the scope of a multicast address and return true if the address is a multicast address of the specified scope or false if the address is either not a multicast address or not of the specified scope. 最初の7つのマクロはもしアドレスが指定されたタイプのであるなら真で、 さもなければ偽で戻ります。後の5つがマルチキャストアドレスの範囲をテ ストし、そしてもしアドレスが指定された範囲のマルチキャストアドレスで あるなら真で、もしアドレスがマルチキャストアドレスでないか指定された 範囲でなければ偽です。 Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for the two types of local-use IPv6 unicast addresses (Link- Local and Site-Local) defined in [2], and that by this definition, the IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback address (::1). These two macros do not return true for IPv6 multicast addresses of either link-local scope or site-local scope. IN6_IS_ADDR_LINKLOCALとIN6_IS_ADDR_SITELOCALは[2]で定義される2種類の ローカル使用のIPv6ユニキャストアドレス(リンクローカルとサイトロー カル)でだけ真で、定義からIN6_IS_ADDR_LINKLOCALまくりはIPv6ループ バックアドレス(::1)に対して偽である事に注してください。これらの2つ のマクロはリンクローカル範囲あるいはサイトローカル範囲のIPv6マル チキャストアドレスについて、真ではありません。 7. Summary of New Definitions 7. 新しい定義の要約 The following list summarizes the constants, structure, and extern definitions discussed in this memo, sorted by header. 次のリストはこの文書で論じた定数と構造体と外部定義をヘッダ順で要約し ます。 <net/if.h> IF_NAMESIZE <net/if.h> struct if_nameindex{}; <netdb.h> AI_ADDRCONFIG <netdb.h> AI_ALL <netdb.h> AI_CANONNAME <netdb.h> AI_NUMERICHOST <netdb.h> AI_NUMERICSERV <netdb.h> AI_PASSIVE <netdb.h> AI_V4MAPPED <netdb.h> EAI_AGAIN <netdb.h> EAI_BADFLAGS <netdb.h> EAI_FAIL <netdb.h> EAI_FAMILY <netdb.h> EAI_MEMORY <netdb.h> EAI_NONAME <netdb.h> EAI_OVERFLOW <netdb.h> EAI_SERVICE <netdb.h> EAI_SOCKTYPE <netdb.h> EAI_SYSTEM <netdb.h> NI_DGRAM <netdb.h> NI_NAMEREQD <netdb.h> NI_NOFQDN <netdb.h> NI_NUMERICHOST <netdb.h> NI_NUMERICSERV <netdb.h> struct addrinfo{}; <netinet/in.h> IN6ADDR_ANY_INIT <netinet/in.h> IN6ADDR_LOOPBACK_INIT <netinet/in.h> INET6_ADDRSTRLEN <netinet/in.h> INET_ADDRSTRLEN <netinet/in.h> IPPROTO_IPV6 <netinet/in.h> IPV6_JOIN_GROUP <netinet/in.h> IPV6_LEAVE_GROUP <netinet/in.h> IPV6_MULTICAST_HOPS <netinet/in.h> IPV6_MULTICAST_IF <netinet/in.h> IPV6_MULTICAST_LOOP <netinet/in.h> IPV6_UNICAST_HOPS <netinet/in.h> IPV6_V6ONLY <netinet/in.h> SIN6_LEN <netinet/in.h> extern const struct in6_addr in6addr_any; <netinet/in.h> extern const struct in6_addr in6addr_loopback; <netinet/in.h> struct in6_addr{}; <netinet/in.h> struct ipv6_mreq{}; <netinet/in.h> struct sockaddr_in6{}; <sys/socket.h> AF_INET6 <sys/socket.h> PF_INET6 <sys/socket.h> struct sockaddr_storage; The following list summarizes the function and macro prototypes discussed in this memo, sorted by header. 次のリストはこの文書で論じられた関数とマクロプロトタイプをヘッダ順に 要約します。 <arpa/inet.h> int inet_pton(int, const char *, void *); <arpa/inet.h> const char *inet_ntop(int, const void *, char *, socklen_t); <net/if.h> char *if_indextoname(unsigned int, char *); <net/if.h> unsigned int if_nametoindex(const char *); <net/if.h> void if_freenameindex(struct if_nameindex *); <net/if.h> struct if_nameindex *if_nameindex(void); <netdb.h> int getaddrinfo(const char *, const char *, const struct addrinfo *, struct addrinfo **); <netdb.h> int getnameinfo(const struct sockaddr *, socklen_t, char *, socklen_t, char *, socklen_t, int); <netdb.h> void freeaddrinfo(struct addrinfo *); <netdb.h> const char *gai_strerror(int); <netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *); 8. Security Considerations 8. セキュリティの考察 IPv6 provides a number of new security mechanisms, many of which need to be accessible to applications. Companion memos detailing the extensions to the socket interfaces to support IPv6 security are being written. IPv6が多くの新しいセキュリティ機構を供給し、その多くはアプリケー ションでアクセスできる必要があります。IPv6セキュリティをサポート するためにソケットインタフェースへの拡張を詳述している関連文書が書か れています。 9. Changes from RFC 2553 9. RFC2553からの変更 1. Add brief description of the history of this API and its relation to the Open Group/IEEE/ISO standards. 1. このAPIの歴史とオープングループ/IEEE/ISO標準にの短い記 述を追加。 2. Alignments with [3]. 2. [3]の整列。 3. Removed all references to getipnodebyname() and getipnodebyaddr(), which are deprecated in favor of getaddrinfo() and getnameinfo(). 3. getaddrinfo()とgetnameinfo()の支持に伴い不要になった getipnodebyname()とgetipnodebyaddr()への参照を廃止。 4. Added IPV6_V6ONLY IP level socket option to permit nodes to not process IPv4 packets as IPv4 Mapped addresses in implementations. 4. ノードが実装でIPv4としてIPv4パケットを処理しないのを許す IPレベルのIPV6_V6ONLYソケットオプションを追加。 5. Added SIIT to references and added new contributors. 5. SIITへの参照の追加と、新しい貢献者を追加。 6. In previous versions of this specification, the sin6_flowinfo field was associated with the IPv6 traffic class and flow label, but its usage was not completely specified. The complete definition of the sin6_flowinfo field, including its association with the traffic class or flow label, is now deferred to a future specification. 6. この仕様書の前の版でsin6_flowinfoフィールドはIPv6トラフィック クラスとフローラベルに結び付けられました、しかしその使用法は完全に 指定されませんでした。sin6_flowinfoフィールドの完全な定義は、その トラフィッククラスあるいはフローラベルとの連想を含めて、未来の仕様 書に今延期されます。 10. Acknowledgments 10. 謝辞 This specification's evolution and completeness were significantly influenced by the efforts of Richard Stevens, who has passed on. Richard's wisdom and talent made the specification what it is today. The co-authors will long think of Richard with great respect. この仕様書の進展と完全性はとてもリチャード・スティーブンスの努力によっ て影響を与えられました。リチャードの賢明さと才能は仕様書を今日あるも のにしました。共著者は大きい敬意でリチャードについて考えるでしょう。 Thanks to the many people who made suggestions and provided feedback to this document, including: この文書の提案とフィードバックを供給した多くの人々に感謝します: Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino, Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos, Keith Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl Williams, Kazu Yamamoto, Vlad Yasevich, Stig Venaas, and Brian Zill. The getaddrinfo() and getnameinfo() functions are taken from an earlier document by Keith Sklower. As noted in that document, William Durst, Steven Wise, Michael Karels, and Eric Allman provided many useful discussions on the subject of protocol-independent name- to-address translation, and reviewed early versions of Keith Sklower's original proposal. Eric Allman implemented the first prototype of getaddrinfo(). The observation that specifying the pair of name and service would suffice for connecting to a service independent of protocol details was made by Marshall Rose in a proposal to X/Open for a "Uniform Network Interface". getaddrinfo()とgetnameinfo()関数はKeith Sklowerによる古い文書からとら れます。その文書で述べたように、William DurstとSteven WiseとMichael KarelsとEric Allmanはプロトコルに依存しない名前−アドレス翻訳問題につ いて多くの有用な論議を供給し、Keith Sklowerのオリジナルの提案の古い バージョンを再検討しました。Eric Allmanはgetaddrinfo()の最初のプロト タイプを実装しました。プロトコル詳細から独立してサービス接続すること に対して、名前とサービスの2つを指定することで十分であろうという発言 は「一様ネットワークインタフェース」のためのX/Open提案でMarshall Rose によってされました。 Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh Kacker made many contributions to this document. Ramesh Govindan made a number of contributions and co-authored an earlier version of this memo. Craig MetzとJack McCannとErik NordmarkとTim HartrickとMukesh Kackerは この文書に多くの貢献をしました。Ramesh Govindanは多くの貢献をして、こ の文書の前の版を共同執筆しました。 11. References 11. 参考文献 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [2] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [3] IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX). Open Group Technical Standard: Base Specifications, Issue 6, December 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin [4] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC 2292, February 1998. [5] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [6] The Open Group Base Working Group http://www.opengroup.org/platform/base.html 12. Authors' Addresses 12. 著者のアドレス Bob Gilligan Intransa, Inc. 2870 Zanker Rd. San Jose, CA 95134 Phone: 408-678-8647 EMail: gilligan@intransa.com Susan Thomson Cisco Systems 499 Thornall Street, 8th floor Edison, NJ 08837 Phone: 732-635-3086 EMail: sethomso@cisco.com Jim Bound Hewlett-Packard Company 110 Spitbrook Road ZKO3-3/W20 Nashua, NH 03062 Phone: 603-884-0062 EMail: Jim.Bound@hp.com Jack McCann Hewlett-Packard Company 110 Spitbrook Road ZKO3-3/W20 Nashua, NH 03062 Phone: 603-884-2608 EMail: Jack.McCann@hp.com 13. Full Copyright Statement 13. 著作権表示全文 Copyright (C) The Internet Society (2003). All Rights Reserved. 著作権(C)インターネット学会(2003)。すべての権利は保留される。 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、 この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装 を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出 版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ ンターネット標準を開発する目的で必要な場合以外は、インターネット学会 や他のインターネット組織は著作権表示や参照を削除されるような変更がで きません、インターネット標準を開発する場合はインターネット標準化プロ セスで定義された著作権の手順に従われます。 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 上に与えられた限定された許可は永久で、インターネット学会やその後継者 や譲渡者によって無効にされません。 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. この文書とここに含む情報は無保証で供給され、そしてインターネット学会 とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情 報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で ある事の保障を含め、すべての保証を拒否します。 Acknowledgement 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society. RFCエディタ機能のための資金供給が現在インターネット学会によって 供給されます。