Network Working Group R. Gilligan
Request for Comments: 2553 FreeGate
Obsoletes: 2133 S. Thomson
Category: Informational Bellcore
J. Bound
Compaq
W. Stevens
Consultant
March 1999
Basic Socket Interface Extensions for 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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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 [4].
TCP / IPアプリケーションのための事実上の標準アプリケーション・プログラム・インターフェース（API）は、「ソケット」のインターフェースです。このAPIは、1980年代初頭のUnix用に開発されましたが、それはまた、非Unixシステムの多種多様に実装されています。ソケットAPIを使って書かれたTCP / IPアプリケーションは、過去に移植性の高い学位を享受してきたし、我々は、IPv6アプリケーションと同じポータビリティをしたいと思います。しかし、変更はIPv6をサポートするためのソケットAPIに必要とこのメモは、これらの変更について説明しています。これらは、IPv6アドレス、新しいアドレス変換機能、およびいくつかの新しいソケットオプションを運ぶために新しいソケットアドレス構造体が含まれます。システムへの変更の最小値を導入し、既存のIPv4アプリケーションのための完全な互換性を提供しながら、これらの拡張機能は、マルチキャストなどのTCPおよびUDPアプリケーションで必要な機能の基本的なIPv6へのアクセスを提供するように設計されています。高度なIPv6機能（生のソケットとIPv6拡張ヘッダへのアクセス）のための追加の拡張は、別のドキュメントで定義されている[4]。
Table of Contents
目次
1. Introduction.................................................3
2. Design Considerations........................................3
2.1 What Needs to be Changed....................................4
2.2 Data Types..................................................5
2.3 Headers.....................................................5
2.4 Structures..................................................5
3. Socket Interface.............................................6
3.1 IPv6 Address Family and Protocol Family.....................6
3.2 IPv6 Address Structure......................................6
3.3 Socket Address Structure for 4.3BSD-Based Systems...........7
3.4 Socket Address Structure for 4.4BSD-Based Systems...........8
3.5 The Socket Functions........................................9
3.6 Compatibility with IPv4 Applications.......................10
3.7 Compatibility with IPv4 Nodes..............................10
3.8 IPv6 Wildcard Address......................................11
3.9 IPv6 Loopback Address......................................12
3.10 Portability Additions.....................................13
4. Interface Identification....................................16
4.1 Name-to-Index..............................................16
4.2 Index-to-Name..............................................17
4.3 Return All Interface Names and Indexes.....................17
4.4 Free Memory................................................18
5. Socket Options..............................................18
5.1 Unicast Hop Limit..........................................18
5.2 Sending and Receiving Multicast Packets....................19
6. Library Functions...........................................21
6.1 Nodename-to-Address Translation............................21
6.2 Address-To-Nodename Translation............................24
6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....26
6.4 Protocol-Independent Nodename and Service Name Translation.26
6.5 Socket Address Structure to Nodename and Service Name......29
6.6 Address Conversion Functions...............................31
6.7 Address Testing Macros.....................................32
7. Summary of New Definitions..................................33
8. Security Considerations.....................................35
9. Year 2000 Considerations....................................35
Changes From RFC 2133..........................................35
Acknowledgments................................................38
References.....................................................39
Authors' Addresses.............................................40
Full Copyright Statement.......................................41
While IPv4 addresses are 32 bits long, IPv6 interfaces are identified by 128-bit addresses. 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 (e.g., traffic class and flowlabel), 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.
IPv4アドレスは32ビット長であるが、IPv6インタフェースは128ビットのアドレスによって識別されます。ソケットインタフェースは、アプリケーションへのIPアドレスのサイズが非常に見えます。 BSDベースのシステムのため、事実上すべてのTCP / IPアプリケーションは、IPアドレスのサイズの知識を持っています。アドレスを公開するAPIの部分は、より大きなIPv6アドレスのサイズに適応するように変更する必要があります。 IPv6はまた、APIを介してアプリケーションに見えるようにしなければならないそのうちのいくつかの新機能（例えば、トラフィッククラスとフローラベル）を、紹介します。このメモは、より大きなアドレスサイズとIPv6の新機能をサポートするためにソケットインタフェースへの拡張機能のセットを定義します。
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 additonal mechanism for implementations to verify this is to verify the new symbols are protected by Feature Test Macros as described in IEEE Std 1003.1. (Such Feature Test Macros are not defined by this RFC.)
- APIの変更は、元のAPIに書き込まれたプログラムのソースとバイナリ互換性の両方を提供しなければなりません。これは、既存のプログラムのバイナリは、新しいAPIをサポートするシステム上で実行したときに作動し続ける必要があります。また、再コンパイルして、新しいAPIをサポートするシステム上で実行されている既存のアプリケーションは動作を継続する必要があります。簡単に言えば、IPv6のためのAPIの変更は、既存のプログラムを壊すべきではありません。これを確認するために実装するためのadditonal機構は、IEEE STD 1003.1に記載されているように、新しいシンボルが機能テストマクロによって保護されていることを確認することです。 （このような機能試験マクロはこの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の変更は、IPv6に既存のIPv4アプリケーションを変換するタスクを簡単にするためにできるだけ小さくすべきです。
- 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の両方のための完全なサポートを提供するマシン上で動作するように設計されています。このAPIのサブセットは、おそらく唯一のIPv6をサポートするシステム上で動作するように設計することができます。しかし、これはこのメモで扱われていません。
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のために変更する必要はありませんが、新しいIPv6固有のアドレスデータ構造が必要とされています。
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オクテットを含み、そしてIPv6へのsockaddr_in構造体を適応させるために、このスペースを使用しようとする魅力的です。残念ながら、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 name-to-address translation functions in the socket interface are gethostbyname() and gethostbyaddr(). These are left as is and new functions are defined to support IPv4 and IPv6. Additionally, the POSIX 1003.g draft [3] specifies a new nodename-to-address translation function which is protocol independent. This function can also be used with IPv4 and IPv6.
ソケットインタフェースの名前からアドレスへの変換機能は、gethostbyname（）とgethostbyaddr（）をしています。これらはそのまま残されており、新しい機能は、IPv4とIPv6をサポートするために定義されています。また、POSIX 1003.gドラフトは、[3]プロトコルに依存しない新しいノード名からアドレスへの変換機能を指定します。この機能は、IPv4とIPv6で使用することができます。
The 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.
アドレス変換関数 - inet_ntoa（）とinet_addrは（） - バイナリと印刷可能な形式の間でIPv4アドレスを変換します。これらの関数は、32ビットのIPv4アドレスに非常に特異的です。私たちは、IPv4とIPv6の両方のアドレスを変換する2つの類似の機能を設計し、そして、彼らは同様に他のプロトコルファミリに拡張することができるように、アドレスタイプパラメータを運ぶしています。
Finally, a few miscellaneous features are needed to support IPv6. New interfaces are needed to support the IPv6 traffic class, flow label, and hop limit header fields. 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. These extensions are described in [4].
ソケットインタフェースは、他のIPv6機能へのアクセスを提供するために、将来的に強化されます。これらの拡張機能は、[4]に記載されています。
The data types of the structure elements given in this memo are intended to be examples, not absolute requirements. Whenever possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g are used: uintN_t means an unsigned integer of exactly N bits (e.g., uint16_t). We also assume the argument data types from 1003.1g when possible (e.g., the final argument to setsockopt() is a size_t value). Whenever buffer sizes are specified, the POSIX 1003.1 size_t data type is used (e.g., the two length arguments to getnameinfo()).
この文書で与えられる構造要素のデータ型は、実施例ではなく、絶対的な要件であることが意図されます。 POSIXのドラフト6.6から可能な限り、データ型（1997年3月）1003.1グラムを使用する：uintN_tは正確にNビット（例えば、uint16_t）の符号なし整数を意味します。可能な場合、我々はまた、（例えば、SETSOCKOPTする最後の引数は（）size_tの値）1003.1グラムからの引数データ型をとります。バッファサイズが指定されるたびに、POSIX 1003.1 size_tのデータ型は（例えば2つの長さの引数は（てgetnameinfoする））が使用されます。
When function prototypes and structures are shown we show the headers that must be #included to cause that item to be defined.
関数のプロトタイプと構造が示されている場合、我々はその項目が定義させるようにインクルードされなければならないヘッダを示しています。
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 IEEE Std 1003.1. (Such Feature Test Macros are not defined by this RFC.)
構造が説明されているときに示した部材は実装に現れなければならないものです。追加の、非標準のメンバーも実装によって定義することができます。 IEEE STD 1003.1に記載されているように、追加の予防措置として、非標準メンバーが機能テストマクロによって確認することができます。 （このような機能試験マクロはこの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.
構造体のメンバーのために示す順序が推奨順序、マルチバイトメンバーの所定のアライメントの考慮であるが、実装が異なるメンバーを命ずることができます。
This section specifies the socket interface changes for IPv6.
このセクションでは、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
#define PF_INET6 AF_INET6
The PF_INET6 is used in the first argument to the socket() function to indicate that an IPv6 socket is being created.
PF_INET6は、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.
このデータ構造は、1つの128ビットのIPv6アドレスを構成する16個の8ビット要素のアレイを含んでいます。 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
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」構造を。それぞれが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 */
in_port_t sin6_port; /* transport layer port # */
uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */
struct in6_addr sin6_addr; /* IPv6 address */
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 that contains two pieces of information: the traffic class and the flow label. The contents and interpretation of this member is specified in [1]. The sin6_flowinfo field SHOULD be set to zero by an implementation prior to using the sockaddr_in6 structure by an application on receive operations.
トラフィッククラスとフローラベル：sin6_flowinfoフィールドは、2つの情報を含んでいる32ビットのフィールドです。コンテンツ及びこのメンバーの解釈は[1]で指定されています。 sin6_flowinfoフィールドは、前に受信動作上のアプリケーションによって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 of the address carried in the sin6_addr field. For a link scope sin6_addr sin6_scope_id would be an interface index. For a site scope sin6_addr, sin6_scope_id would be a site identifier. The mapping of sin6_scope_id to an interface or set of interfaces is left to implementation and future specifications on the subject of site identifiers.
ではsin6_scope_idフィールドはsin6_addrではフィールドで運ばれたアドレスの範囲に応じて、インタフェースのセットを識別する32ビットの整数です。ではsin6_scope_idのsin6_addrリンクスコープのインターフェイスインデックスになります。サイトスコープのsin6_addrではsin6_scope_idはサイト識別子になります。インターフェイスのインターフェイスまたはセットへでは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（構造体のsockaddr_in）は両方とも16バイトで、はsizeof（いるsockaddr）に等しいです。この仮定を作る任意の既存のコードは、IPv6に変換するときに慎重に検討する必要があります。
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」フィールドは、8ビット値に16-ビット値から変更、及び空間「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 */
in_port_t sin6_port; /* transport layer port # */
uint32_t sin6_flowinfo; /* IPv6 flow information */
struct in6_addr sin6_addr; /* IPv6 address */
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変種をサポートするシステム上に構築されているかどうかを判断することができます。
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:
アプリケーションは、通信エンドポイントを表しソケット記述子を作成するためのソケット（）関数を呼び出します。ソケット（）関数の引数は、プロトコルを使用するようにシステムに指示し、どのような形式のアドレス構造は、後続の関数で使用されるであろう。例えば、IPv4 / TCPソケットを作成するには、アプリケーションは電話をかけます：
s = socket(PF_INET, SOCK_STREAM, 0);
S =ソケット（PF_INET、SOCK_STREAM、0）;
To create an IPv4/UDP socket, applications make the call:
IPv4の/ UDPソケットを作成するには、アプリケーションは電話をかけます：
s = socket(PF_INET, SOCK_DGRAM, 0);
S =ソケット（PF_INET、SOCK_DGRAM、0）;
Applications may create IPv6/TCP and IPv6/UDP sockets by simply using the constant PF_INET6 instead of PF_INET in the first argument. For example, to create an IPv6/TCP socket, applications make the call:
アプリケーションは、単に最初の引数に代わりPF_INETの定数PF_INET6を使用して、IPv6 / TCPとIPv6 / UDPソケットを作成することができます。例えば、IPv6 / TCPソケットを作成するには、アプリケーションは電話をかけます：
s = socket(PF_INET6, SOCK_STREAM, 0);
S =ソケット（PF_INET6、SOCK_STREAM、0）;
To create an IPv6/UDP socket, applications make the call:
IPv6の/ UDPソケットを作成するには、アプリケーションは電話をかけます：
s = socket(PF_INET6, SOCK_DGRAM, 0);
S =ソケット（PF_INET6、SOCK_DGRAM、0）;
Once the application has created a PF_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:
アプリケーションがPF_INET6ソケットを作成した後は、システムにアドレスを渡すとき、それはSOCKADDR_IN6アドレス構造体を使用する必要があります。アプリケーションがシステムにアドレスを渡すために使用する機能は以下のとおりです。
bind() connect() sendmsg() sendto()
バインド（）（接続）にsendmsg（）はsendto（）
The system will use the sockaddr_in6 address structure to return addresses to applications that are using PF_INET6 sockets. The functions that return an address from the system to an application are:
システムは、PF_INET6ソケットを使っているアプリケーションにアドレスを返すためにSOCKADDR_IN6アドレス構造を使用します。システムからアプリケーションにアドレスを返す関数は以下のとおりです。
accept() recvfrom() recvmsg() getpeername() getsockname()
受け入れる（）の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をサポートするために必要ではありません。
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 PF_INET sockets and the sockaddr_in address structure. Applications must be able to create IPv4/TCP and IPv4/UDP sockets using the PF_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との完全なソースおよびバイナリ互換性を提供しなければなりません。これは、システムがPF_INETソケットとsockaddr_inアドレス構造体をサポートし続けなければならないことを意味します。アプリケーションは、前のセクションで説明したように、ソケット（）関数でPF_INET定数を用いたIPv4 / TCPとIPv4 / UDPソケットを作成することができなければなりません。アプリケーションは、同じプロセス内で同時に、IPv4の/ UDP、IPv6の/ TCPとIPv6 / UDPソケットのIPv4 / TCPの組み合わせを保持することができるはずです。
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ノードと相互運用を継続する必要があります。
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
IPv4アプリケーションと相互運用するIPv6アプリケーションのための能力：APIも互換性の異なる種類を提供します。この機能は、IPv6アドレス体系仕様[2]で定義されたIPv4マップIPv6アドレス形式を使用します。このアドレス形式
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:
IPv4ノードのIPv4アドレスは、IPv6アドレスとして表現することが可能になります。 IPv4アドレスは、IPv6アドレスの下位32ビットと上位96ビットに符号化された固定プレフィックス0ホールド：0：0：0：0 FFFFを。 IPv4-は、次のようにアドレスが書かれているマップされました：
::FFFF:<IPv4-address>
:: FFFF：<IPv4のアドレス>
These addresses can be generated automatically by the getipnodebyname() function when the specified host has only IPv4 addresses (as described in Section 6.1).
これらのアドレスは（セクション6.1で説明したように）指定されたホストがただIPv4アドレスを持つgetipnodebyname（）関数によって自動的に生成することができます。
Applications may use PF_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 PF_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.
アプリケーションは、（Connectで、sockaddr_in6構造体の中に、IPv4ノードへのTCP接続を開く、または単にIPv4射影IPv6アドレスとして送信先のIPv4アドレスをコードし、そのアドレスを渡すことによって、IPv4ノードにUDPパケットを送信するためにPF_INET6ソケットを使用することができます）またはのsendto（）呼び出し。アプリケーションがIPv4ノードからのTCP接続を受け入れる、またはIPv4ノードからのUDPパケットを受信するPF_INET6ソケットを使用する場合、システムは、符号化されたsockaddr_in6構造体を使用して、）（の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.7, is provided.
いくつかのアプリケーションは、おそらく、彼らがと相互運用されているノードの種類を知っておく必要があります。しかし、知っておく必要がありますそれらのアプリケーションのために、6.7節で定義されたIN6_IS_ADDR_V4MAPPED（）マクロは、提供されます。
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.
バインド（）関数は、アプリケーションがUDPパケットやTCPコネクションの送信元IPアドレスを選択することができますが、アプリケーションは多くの場合、システムはそれらの送信元アドレスを選択します。 IPv4では、1はバインド（）の呼び出しで（「ワイルドカード」と呼ばれるアドレス）シンボリック定数INADDR_ANYとしてアドレスを指定する、または単に完全に）（バインドを省略します。
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アドレスタイプは構造体（構造体の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>:
最初のバージョンは、in6_addr構造体である「IN6ADDR_ANY」という名前のグローバル変数です。この変数のextern宣言は、<netinetの/ in.h>で定義されています。
extern const struct in6_addr in6addr_any;
IN6ADDR_ANYのin6_addrにextern constの構造体。
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;
構造体の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:
この定数はONLY宣言時に使用できることに注意してください。以前の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定数とIPv6 in6addr_xxx外部宣言は、ネットワークバイト順で定義されていることに注意してください。
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.
アプリケーションは、ローカル・ノード上にあるサービスへのTCP接続をするUDPパケットを送信し、または発信する必要があるかもしれません。 IPv4では、彼らは彼らの接続（）、のsendto（）、またはにsendmsg（）呼び出しで一定のIPv4アドレスINADDR_LOOPBACKを使用してこれを行うことができます。
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>:
グローバル変数は、名前のin6_addr構造体である「in6addr_loopback。」この変数のextern宣言は、<netinetの/ in.h>で定義されています。
extern const struct in6_addr in6addr_loopback;
in6addr_loopbackのin6_addrにextern constの構造体。
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;
構造体の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アドレス変数への代入に使用することはできません。
One simple addition to the sockets API that can help application writers is the "struct sockaddr_storage". This data structure can simplify writing code portable across multiple address families and platforms. This data structure is designed with the following goals.
アプリケーション作成者を助けることができるソケットAPIへの一つの簡単な追加は、「構造体SOCKADDR_STORAGE」です。このデータ構造は、複数のアドレスファミリーとプラットフォーム間で書き込みコードポータブルを簡素化することができます。このデータ構造は、以下の目的で設計されています。
- It has a large enough implementation specific maximum size to store the desired set of protocol specific socket address data structures. Specifically, it is at least large enough to accommodate sockaddr_in and sockaddr_in6 and possibly other protocol specific socket addresses too. - It is aligned at an appropriate boundary so protocol specific socket address data structure pointers can be cast to it and access their fields without alignment problems. (e.g. pointers to sockaddr_in6 and/or sockaddr_in can be cast to it and access fields without alignment problems).
- それは、プロトコル固有のソケットアドレスデータ構造の所望のセットを格納するために十分な大きさの実装固有の最大サイズを有します。具体的には、あまりにものsockaddr_inとSOCKADDR_IN6およびおそらくは他のプロトコル固有のソケットアドレスを収容するのに十分な少なくとも大です。 - プロトコル固有のソケットアドレスデータ構造ポインタがそれにキャストし、アライメントの問題もなく自分のフィールドにアクセスすることができますので、それは適切な境界で整列されます。 （例えばポインタがSOCKADDR_IN6および/またはのsockaddr_in位置合わせの問題なしで、アクセスフィールドにキャストすることができます）。
- It has the initial field(s) isomorphic to the fields of the "struct sockaddr" data structure on that implementation which can be used as a discriminants for deriving the protocol in use. These initial field(s) would on most implementations either be a single field of type "sa_family_t" (isomorphic to sa_family field, 16 bits) or two fields of type uint8_t and sa_family_t respectively, (isomorphic to sa_len and sa_family_t, 8 bits each).
- それは、使用中のプロトコルを導出するための判別式として使用することができ、その実装の「構造体のsockaddr」データ構造のフィールドと同形初期フィールド（複数可）を有します。これらの最初のフィールド（複数可）は、ほとんどの実装でタイプ（sa_familyにフィールドに同形、16ビット）「sa_family_t」またはタイプuint8_tとsa_family_tの二つのフィールドをそれぞれ、（SA_LENとsa_family_tと同形、各8ビット）の単一のフィールドであろういずれか。
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.
*/
#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 */
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 */
};
On implementations where 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.
*/
#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
(sizeof (uint8_t) + sizeof (sa_family_t))
#define _SS_PAD2SIZE (_SS_MAXSIZE - (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 */
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 */
};
The above example implementation illustrates a data structure which will align on a 64 bit boundary. An implementation specific field "__ss_align" along "__ss_pad1" is used to force a 64-bit alignment which covers proper alignment good enough for needs of sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures. The size of padding fields __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_ALIGNMENT (with chosen value 8). Constants _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112) are also for illustration and not required. 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_pad1」に沿って「__ss_align」はSOCKADDR_IN6（IPv6）のニーズには十分適切な整列をカバーする64ビットのアライメントを強制するために使用される、のsockaddr_in（IPv4）のアドレスデータ構造。選択した整列境界に依存__ss_pad1パディングフィールドのサイズ。パディングフィールド__ss_pad2のサイズは、構造体の合計サイズのために選択された全体的な大きさの値に依存します。このサイズとアライメントは、実装特定することにより、上記の例に示されている（必須ではない）_SS_MAXSIZE（選択された値128）と_SS_ALIGNMENT（選択された値8を有する）を定数。定数_SS_PAD1SIZE（派生値6）と_SS_PAD2SIZE（派生値112）は説明のためでもあるし、必要ではありません。実装プライベート名前空間を表すために、アンダースコアで開始上記の実装固有の定義と構造体のフィールド名。ポータブルコードがアクセスしたり、それらのフィールドまたは定数を参照することが期待されていません。
The sockaddr_storage structure solves the problem of declaring storage for automatic variables which is large enough and aligned enough for storing socket address data structure of any family. For example, code with a file descriptor and without the context of the address family can pass a pointer to a variable of this type where a pointer to a socket address structure is expected in calls such as getpeername() and determine the address family by accessing the received content after the call.
SOCKADDR_STORAGE構造が十分に大きくし、任意の家族のソケットアドレスデータ構造を格納するために十分揃っている自動変数用のストレージを宣言するという問題を解決します。例えば、ファイルディスクリプタと、アドレスファミリのコンテキストなしコードは、ソケットアドレス構造体へのポインタは、例えばgetpeername（ASコールに予想されるこのタイプの変数へのポインタを渡すことができる）とアクセスすることにより、アドレスファミリを決定しますコールの後に受信したコンテンツ。
The sockaddr_storage structure may also be useful and applied to certain other interfaces where a generic socket address large enough and aligned for use with multiple address families may be needed. A discussion of those interfaces is outside the scope of this document.
SOCKADDR_STORAGE構造も有用と十分な大きさと複数のアドレスファミリで使用するために整列され、一般的なソケットアドレスが必要とされ得る他の特定のインターフェイスに適用されてもよいです。これらのインタフェースの説明は、この文書の範囲外です。
Also, much existing code assumes that any socket address structure can fit in a generic sockaddr structure. While this has been true for IPv4 socket address structures, it has always been false for Unix domain socket address structures (but in practice this has not been a problem) and it is also false for IPv6 socket address structures (which can be a problem).
また、多くの既存のコードは、任意のソケットアドレス構造体は、一般的なsockaddr構造体に合うことができることを前提としています。これは、IPv4ソケットアドレス構造体のために真となっているが、それは常にUnixドメインソケットアドレス構造体のために偽されている（実際には、これは問題ではなかった）、それはまた、（問題になる可能性があります）IPv6のソケットアドレス構造体のために偽であります。
So now an application can do the following:
だから今のアプリケーションには、次の操作を実行できます。
struct sockaddr_storage __ss;
struct sockaddr_in6 *sin6;
sin6 = (struct sockaddr_in6 *) &__ss;
This API uses an interface index (a small positive integer) to identify the local interface on which a multicast group is joined (Section 5.3). 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.3節）を識別するために、インターフェイスインデックス（小さな正の整数）を使用します。また、高度な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つのインタフェース名とインデックスとの間のマッピング関数は、全てのインターフェイス名とインデックスを返す第三の機能、及び第4の機能を定義します。どのようにこれらの機能が実装されていることは実装に任されています。 4.4BSDの実装はNET_RT_IFLISTコマンドで既存のsysctl（）関数を使用してこれらの機能を実現することができます。他の実装は、この目的のためにioctl（）を使用することをお勧めします。
The first function maps an interface name into its corresponding index.
最初の関数は、対応するインデックスにインタフェース名をマッピングします。
#include <net/if.h>
書式#include <ネット/ if.h>
unsigned int if_nametoindex(const char *ifname);
unsigned int型if_nametoindex（のconst char型*のifnameの）;
If the specified interface name does not exist, the return value is 0, and errno is set to ENXIO. If there was a system error (such as running out of memory), the return value is 0 and errno is set to the proper value (e.g., ENOMEM).
指定されたインタフェース名が存在しない場合、戻り値は0で、errnoはENXIOに設定されています。 （そのようなメモリの不足など）、システムエラーが発生した場合、戻り値は0であり、errnoが適切な値（例えば、ENOMEM）に設定されています。
The second function maps an interface index into its corresponding name.
第二の機能は、対応する名前にインタフェースインデックスをマッピングします。
#include <net/if.h>
書式#include <ネット/ if.h>
char *if_indextoname(unsigned int ifindex, char *ifname);
CHAR * if_indextoname（unsigned int型のifIndex、のchar *のifnameの）;
The ifname argument must point to a buffer of at least IF_NAMESIZE bytes into which the interface name corresponding to the specified index is returned. (IF_NAMESIZE is also defined in <net/if.h> and its value includes a terminating null byte at the end of the interface name.) This pointer is also the return value of the function. If there is no interface corresponding to the specified index, NULL is returned, and errno is set to ENXIO, if there was a system error (such as running out of memory), if_indextoname returns NULL and errno would be set to the proper value (e.g., ENOMEM).
ifName引数が指定されたインデックスに対応するインタフェース名が返されるに少なくともIF_NAMESIZEバイトのバッファを指していなければなりません。 （IF_NAMESIZEも<ネット/ if.h>で定義され、その値はインタフェース名の末尾に終端のNULLバイトを含む。）、このポインタは、関数の戻り値です。指定されたインデックスに対応するインターフェイスがない場合、NULLが返され、errnoはENXIOに設定されている（例えば、メモリの不足など）、システムエラーが発生した場合、（if_indextonameはNULLを返し、errnoには適切な値に設定されます例えば、ENOMEM）。
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構造体は、単一のインタフェースに関する情報を保持し、<ネット/ if.h>ヘッダを含めた結果として定義されます。
struct if_nameindex {
unsigned int if_index; /* 1, 2, ... */
char *if_name; /* null terminated name: "le0", ... */
};
The final function returns an array of if_nameindex structures, one structure per interface.
最終的な関数は、if_nameindex構造、インタフェースごとに構造体の配列を返します。
struct if_nameindex *if_nameindex(void);
構造体if_nameindex * if_nameindex（無効）。
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た構造で示されています。関数は、エラー時にNULLポインタを返し、適切な値を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メンバによって指さインタフェース名と共に構造のこのアレイに使用されるメモリが動的に取得されます。このメモリは次の関数によって解放されます。
The following function frees the dynamic memory that was allocated by if_nameindex().
以下の関数は）if_nameindex（によって割り当てられた動的メモリを解放します。
#include <net/if.h>
書式#include <ネット/ if.h>
void if_freenameindex(struct if_nameindex *ptr);
空if_freenameindex（構造体if_nameindexの*のPTR）;
The argument to this function must be a pointer that was returned by if_nameindex().
この関数の引数はif_nameindex（）で返されたポインタでなければなりません。
Currently net/if.h doesn't have prototype definitions for functions and it is recommended that these definitions be defined in net/if.h as well and the struct if_nameindex{}.
現在/ネットif.hには関数のプロトタイプの定義を持っていない、これらの定義は/ if.hだけでなく、ネットで定義することを推奨して構造体if_nameindex {}されます。
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（）で、これらのオプションを使用するときに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>を含むことによって得られます。
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;
hoplimit INT = 10;
if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, (char *) &hoplimit, sizeof(hoplimit)) == -1) perror("setsockopt IPV6_UNICAST_HOPS");
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
X <-1：使用のカーネルのデフォルト0 <= xの<= 255：使用X X> = 256：EINVALのx == -1のエラーを返す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;
size_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);
IPv6 applications may send UDP multicast packets by simply specifying an IPv6 multicast address in the address argument of the sendto() function.
IPv6アプリケーションは、sendto（）関数のアドレス引数にIPv6マルチキャストアドレスを指定することで、UDPマルチキャストパケットを送信することができます。
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.
送出マルチキャストパケットに使用するインターフェイスを設定します。引数は、使用するインタフェースのインデックスです。
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 x == -1: use kernel default 0 <= x <= 255: use x x >= 256: return an error of EINVAL
X <-1：使用のカーネルのデフォルト0 <= xの<= 255：使用X X> = 256：EINVALのx == -1のエラーを返すEINVALのエラーを返します
If IPV6_MULTICAST_HOPS is not set, the default is 1 (same as IPv4 today)
IPV6_MULTICAST_HOPSが設定されていない場合、デフォルトは1（今日はIPv4と同じ）であります
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が設定されていない場合、デフォルトは1（;はIPv4と同じ今日ループバック）です。
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（）オプションによって制御されます。これら二つのオプションが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 using the resulting interface.
指定されたローカルインタフェース上のマルチキャストグループに参加。インタフェースインデックスに0が指定されている場合は、カーネルは、ローカルインタフェースを選択します。例えば、いくつかのカーネルは通常のIPv6ルーティングテーブルにマルチキャストグループを検索し、得られたインタフェースを使用して。
Argument type: struct ipv6_mreq
引数のタイプ：構造体ipv6_mreq
IPV6_LEAVE_GROUP
IPV6_LEAVE_GROUP
Leave a multicast group on a specified interface.
指定されたインターフェイス上でマルチキャストグループを脱退。
Argument type: struct ipv6_mreq
引数のタイプ：構造体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;
これらのオプションの両方の引数の型は、<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 and 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ポートをバインドする必要がありますデータグラムを受信することに注意してください。いくつかのプロセスはまた、ソケットに配信され、同じポート宛他のデータグラムを防止するために、ポートに加えて、ソケットにマルチキャストグループアドレスをバインドします。
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.
一般的に使用される関数のgethostbyname（）は、所望のアドレスの種類について何も指定し、発信者のための方法を提供していない最初のため、多くの用途には不十分である（IPv4のみのIPv6のみ、IPv4マップのIPv6等、OKである）、及び二本機能の多くの実装は、スレッドセーフではありませんので。 RFC 2133は、gethostbyname2（）という関数を定義したが、この関数は、その使用は、フラグ引数をより詳細に制御して、発信者に提供するために必要とされるため、IPv6アドレスが二必要とされたときに、グローバルオプション（RES_USE_INET6）の設定に必要な最初のため、また、不十分でした必要なアドレスの種類。
The following function is new and must be thread safe:
次の関数は新しく、スレッドセーフである必要があります。
#include <sys/socket.h> #include <netdb.h>
書式#include <sysの/ socket.h>にする#include <netdb.h>
struct hostent *getipnodebyname(const char *name, int af, int flags int *error_num);
構造体たhostent * getipnodebyname（のconstのchar *名、int型のAF、int型のフラグは* error_numにINT）;
The name argument can be either a node name or a numeric address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address). The af argument specifies the address family, either AF_INET or
name引数は、ノード名または数値アドレス文字列（すなわち、ドット付き10進数のIPv4アドレスまたはIPv6 16進数アドレス）のいずれかであり得ます。 AF引数は、アドレスファミリを指定するいずれかAF_INETか
AF_INET6. The error_num value is returned to the caller, via a pointer, with the appropriate error code in error_num, to support thread safe error code returns. error_num will be set to one of the following values:
AF_INET6。 error_numに値がスレッドセーフエラーコードのリターンをサポートするために、error_numにに適切なエラーコードで、ポインタを介して、呼び出し元に返されます。 error_numには、次のいずれかの値に設定されます。
HOST_NOT_FOUND
ホストが見つかりません
No such host is known.
そのようなホストは知られていません。
NO_ADDRESS
NO_ADDRESS
The server recognised the request and the name but no address is available. Another type of request to the name server for the domain might return an answer.
サーバは要求と名前を認識したが、アドレスがありません。ドメインのネームサーバへの要求のもう一つのタイプは、答えを返すことがあります。
NO_RECOVERY
NO_RECOVERY
An unexpected server failure occurred which cannot be recovered.
予期しないサーバーの障害を回復することはできないが発生しました。
TRY_AGAIN
再試行する
A temporary and possibly transient error occurred, such as a failure of a server to respond.
おそらく一時的かつ一時的なエラーは、対応するサーバの障害として、発生しました。
The flags argument specifies the types of addresses that are searched for, and the types of addresses that are returned. We note that a special flags value of AI_DEFAULT (defined below) should handle most applications.
flags引数は、検索されたアドレスの種類、および返されるアドレスのタイプを指定します。我々はAI_DEFAULT（以下に定義）の特別なフラグ値は、ほとんどのアプリケーションを処理する必要があることに注意してください。
That is, porting simple applications to use IPv6 replaces the call
つまり、IPv6を使用するための簡単なアプリケーションを移植すると、呼び出しを置き換えます
hptr = gethostbyname(name);
HPTR =のgethostbyname（名）;
with
とともに
hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num);
HPTR = getipnodebyname（名前、AF_INET6、AI_DEFAULT、＆error_numに）。
and changes any subsequent error diagnosis code to use error_num instead of externally declared variables, such as h_errno.
そのようはh_errnoなどの変数を宣言し、外部error_numに使う代わりにするために、任意の後続のエラー診断コードを変更します。
Applications desiring finer control over the types of addresses searched for and returned, can specify other combinations of the flags argument.
アドレスの種類をより細かく制御を希望するアプリケーションを検索して返され、flags引数の他の組み合わせを指定することができます。
A flags of 0 implies a strict interpretation of the af argument:
0のフラグはAF引数の厳密な解釈を意味します：
- If flags is 0 and af is AF_INET, then the caller wants only IPv4 addresses. A query is made for A records. If successful, the IPv4 addresses are returned and the h_length member of the hostent structure will be 4, else the function returns a NULL pointer.
- フラグが0で、afがAF_INETの場合、呼び出し側はIPv4アドレスのみを望んでいます。クエリは、レコードのために作られています。成功した場合、他の関数はNULLポインタを返し、IPv4アドレスが返され、hostent構造体のh_lengthメンバは4になります。
- If flags is 0 and if af is AF_INET6, then the caller wants only IPv6 addresses. A query is made for AAAA records. If successful, the IPv6 addresses are returned and the h_length member of the hostent structure will be 16, else the function returns a NULL pointer.
- フラグが0で、afがAF_INET6であるならば、呼び出し側がIPv6のみのアドレスを望んでいる場合。問い合わせはAAAAレコードのために作られています。成功した場合、他の関数はNULLポインタを返し、IPv6アドレスが返され、hostent構造体のh_lengthメンバは16になります。
Other constants can be logically-ORed into the flags argument, to modify the behavior of the function.
その他の定数は、関数の動作を変更するために、flags引数に論理的論理和することができます。
- If the AI_V4MAPPED flag is specified along with an af of AF_INET6, then the caller will accept IPv4-mapped IPv6 addresses. That is, if no AAAA records are found then a query is made for A records and any found are returned as IPv4-mapped IPv6 addresses (h_length will be 16). The AI_V4MAPPED flag is ignored unless af equals AF_INET6.
- AI_V4MAPPEDフラグがAF_INET6のAFと共に指定されている場合、発信者は、IPv4射影IPv6アドレスを受け入れます。何AAAAレコードがレコードに対してクエリが行われる見出されず、任意の（h_length 16になる）IPv4射影IPv6アドレスとして返される発見された場合には、です。 afがAF_INET6に等しくない限り、AI_V4MAPPEDフラグは無視されます。
- The AI_ALL flag is used in conjunction with the AI_V4MAPPED flag, and is only used with the IPv6 address family. When AI_ALL is logically or'd with AI_V4MAPPED flag then the caller wants all addresses: IPv6 and IPv4-mapped IPv6. A query is first made for AAAA records and if successful, the IPv6 addresses are returned. Another query is then made for A records and any found are returned as IPv4-mapped IPv6 addresses. h_length will be 16. Only if both queries fail does the function return a NULL pointer. This flag is ignored unless af equals AF_INET6.
- AI_ALLフラグはAI_V4MAPPEDフラグと一緒に使用され、そしてのみIPv6アドレスファミリで使用されています。 IPv6とIPv4マップIPv6：AI_ALLが論理的にAI_V4MAPPEDフラグとOR演算された場合、その後の発信者は、すべてのアドレスを望んでいます。クエリは、最初のAAAAレコードのために作られ、成功した場合は、IPv6アドレスが返されます。別のクエリが、その後の記録のために作られ、見つかったIPv4マップIPv6アドレスとして返されます。 h_lengthは、関数がNULLポインタを返すん両方のクエリが失敗した場合のみ16となります。 afがAF_INET6に等しくなければ、このフラグは無視されます。
- The AI_ADDRCONFIG flag specifies that a query for AAAA records should occur only if the node has at least one IPv6 source address configured and a query for A records should occur only if the node has at least one IPv4 source address configured.
- AI_ADDRCONFIGフラグは、ノードが、少なくとも1つのIPv6ソースアドレスが設定している場合にのみ、AAAAレコードのクエリが発生することを指定し、ノードが構成された少なくとも1つのIPv4ソースアドレスを持つ場合にのみ、レコードのクエリが発生しました。
For example, if the node has no IPv6 source addresses configured, and af equals AF_INET6, and the node name being looked up has both AAAA and A records, then:
例えば、ノードは、設定なしIPv6ソースアドレスを持っていない場合、及びAFはAF_INET6に等しく、ルックアップされたノード名は、次に、AAAAレコードの両方を有します。
(a) if only AI_ADDRCONFIG is specified, the function
returns a NULL pointer;
(b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A
records are returned as IPv4-mapped IPv6 addresses;
The special flags value of AI_DEFAULT is defined as
AI_DEFAULTの特別なフラグ値は以下のように定義されます
#define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG)
#define AI_DEFAULT（AI_V4MAPPED | AI_ADDRCONFIG）
We noted that the getipnodebyname() function must allow the name argument to be either a node name or a literal address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address). This saves applications from having to call inet_pton() to handle literal address strings.
我々はgetipnodebyname（）関数は、name引数は、ノード名またはリテラルアドレス文字列（すなわち、ドット付き10進数のIPv4アドレスまたはIPv6 16進数アドレス）のいずれかであることを可能にしなければならないことに注意しました。これは、リテラルアドレス文字列を処理するために）（はinet_ptonコールすることからアプリケーションを保存します。
There are four scenarios based on the type of literal address string and the value of the af argument.
リテラルアドレス文字列の種類とAF引数の値に基づいて、4つのシナリオがあります。
The two simple cases are:
2つの簡単な例は以下のとおりです。
When name is a dotted-decimal IPv4 address and af equals AF_INET, or when name is an IPv6 hex address and af equals AF_INET6. The members of the returned hostent structure are: h_name points to a copy of the name argument, h_aliases is a NULL pointer, h_addrtype is a copy of the af argument, h_length is either 4 (for AF_INET) or 16 (for AF_INET6), h_addr_list[0] is a pointer to the 4-byte or 16-byte binary address, and h_addr_list[1] is a NULL pointer.
名前がある場合にはドット区切りのIPv4アドレスとAFはAF_INETに等しい、または名前があるとき、IPv6の16進数アドレスとAFはAF_INET6に等しいです。返されるhostent構造体のメンバは次のとおり、h_aliasesがNULLポインタであるh_nameポイント名引数のコピーに、h_addrtypeはAF引数のコピーであり、h_lengthは（AF_INET6用）4（AF_INETの場合）または16のいずれかである、h_addr_list [0]は4バイトまたは16バイトのバイナリアドレスへのポインタであり、h_addr_list [1]がNULLポインタです。
When name is a dotted-decimal IPv4 address and af equals AF_INET6, and flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is returned: h_name points to an IPv6 hex address containing the IPv4- mapped IPv6 address, h_aliases is a NULL pointer, h_addrtype is AF_INET6, h_length is 16, h_addr_list[0] is a pointer to the 16-byte binary address, and h_addr_list[1] is a NULL pointer. If AI_V4MAPPED is set (with or without AI_ALL) return IPv4-mapped otherwise return NULL.
名前は、ドット付き10進数のIPv4アドレスであり、afがAF_INET6に等しく、そしてフラグがAI_V4MAPPEDに等しい場合、IPv4射影IPv6アドレスが返される：IPv4- IPv6アドレスをマッピングされた含有のIPv6 16進数アドレスにh_name点は、h_aliases NULLポインタは、h_addrtype AF_INET6であり、h_lengthは16、h_addr_list [0] 16バイトのバイナリアドレスへのポインタであり、h_addr_list [1]がNULLポインタです。 AI_V4MAPPEDは（またはAI_ALLなし）に設定されている場合はIPv4マップがそれ以外の場合はNULLを返す返します。
It is an error when name is an IPv6 hex address and af equals AF_INET. The function's return value is a NULL pointer and error_num equals HOST_NOT_FOUND.
名前がIPv6 16進数アドレスでafがAF_INETに等しいとき、それはエラーです。関数の戻り値はNULLポインタとerror_numにHOST_NOT_FOUNDに等しいです。
The following function has the same arguments as the existing gethostbyaddr() function, but adds an error number.
次の関数は、既存のgethostbyaddr（）関数と同じ引数を持っていますが、エラー番号を追加します。
#include <sys/socket.h> #include <netdb.h>
書式#include <sysの/ socket.h>にする#include <netdb.h>
struct hostent *getipnodebyaddr(const void *src, size_t len, int af, int *error_num);
構造体たhostent * getipnodebyaddr（定数ボイド*のSRC、size_tのLEN、int型AF、int型* error_numに）;
As with getipnodebyname(), getipnodebyaddr() must be thread safe. The error_num value is returned to the caller with the appropriate error code, to support thread safe error code returns. The following error conditions may be returned for error_num:
getipnodebyname（）と同様、getipnodebyaddr（）スレッドセーフでなければなりません。 error_numに値は、スレッドセーフエラーコードのリターンをサポートするために、適切なエラーコードを呼び出し側に返されます。以下のエラー条件がerror_numにするために返されることがあります。
HOST_NOT_FOUND
ホストが見つかりません
No such host is known.
そのようなホストは知られていません。
NO_ADDRESS
NO_ADDRESS
The server recognized the request and the name but no address is available. Another type of request to the name server for the domain might return an answer.
サーバは要求と名前を認識したが、アドレスがありません。ドメインのネームサーバへの要求のもう一つのタイプは、答えを返すことがあります。
NO_RECOVERY
NO_RECOVERY
An unexpected server failure occurred which cannot be recovered.
予期しないサーバーの障害を回復することはできないが発生しました。
TRY_AGAIN
再試行する
A temporary and possibly transient error occurred, such as a failure of a server to respond.
おそらく一時的かつ一時的なエラーは、対応するサーバの障害として、発生しました。
One possible source of confusion is the handling of IPv4-mapped IPv6 addresses and IPv4-compatible IPv6 addresses, but the following logic should apply.
混乱の一つの可能なソースは、IPv4射影IPv6アドレスとIPv4互換IPv6アドレスの処理であるが、次の論理が適用されるべきです。
1. If af is AF_INET6, and if len equals 16, and if the IPv6 address is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, then skip over the first 12 bytes of the IPv6 address, set af to AF_INET, and set len to 4.
1. afがAF_INET6であり、lenが16に等しく、IPv6アドレスがIPv4マップIPv6アドレスまたはIPv4互換IPv6アドレスである場合には、IPv6アドレスの最初の12のバイトをスキップした場合、AF AF_INETに設定した場合、および4にlenを設定します。
2. If af is AF_INET, lookup the name for the given IPv4 address (e.g., query for a PTR record in the in-addr.arpa domain).
2. afがAF_INETであるならば、与えられたIPv4アドレスの名前をルックアップ（例えば、in-addr.arpaドメイン内のPTRレコードに対する問い合わせ）。
3. If af is AF_INET6, lookup the name for the given IPv6 address (e.g., query for a PTR record in the ip6.int domain).
afがAF_INET6である3.場合は、与えられたIPv6アドレスの名前を検索（例えば、ip6.intドメインのPTRレコードに対する問い合わせ）。
4. If the function is returning success, then the single address that is returned in the hostent structure is a copy of the first argument to the function with the same address family that was passed as an argument to this function.
4.関数が成功を返している場合は、hostent構造体に返された単一のアドレスは、この関数の引数として渡されたのと同じアドレスファミリを持つ関数の最初の引数のコピーです。
All four steps listed are performed, in order. Also note that the IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4- compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST be returned and a query of the address not performed.
記載されているすべての4つのステップを順に実行されます。また、IPv6の六角アドレス「::」と「:: 1」IPv4-互換アドレスとして扱われてはならない、とアドレスがある場合は、「::」、HOST_NOT_FOUNDが返さなければならないとアドレスのクエリが実行されないことに注意してください。
Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return false for "::" and "::1".
また、セクション6.7 IN6_IS_ADDR_V4COMPATでマクロの「::」と「:: 1」のためにfalseを返す必要があります。
The hostent structure does not change from its existing definition. This structure, and the information pointed to by this structure, are dynamically allocated by getipnodebyname and getipnodebyaddr. The following function frees this memory:
hostent構造体は、その既存の定義から変更されません。この構成によれば、この構造によって指される情報は、動的getipnodebyname関数とgetipnodebyaddrによって割り当てられます。次の関数は、このメモリを解放します。
#include <netdb.h>
書式#include <netdb.h>
void freehostent(struct hostent *ptr);
空freehostent（構造体たhostent *のPTR）;
Nodename-to-address translation is done in a protocol-independent fashion using the getaddrinfo() function that is taken from the Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g (Protocol Independent Interfaces) draft specification [3].
ノード名からアドレスへの変換は、電気電子学会から取られるのgetaddrinfo（）関数を使用して、プロトコルに依存しない方法で行われる（IEEE）POSIX 1003.1グラム（プロトコル独立インタフェース）ドラフト仕様[3]。
The official specification for this function will be the final POSIX standard, with the following additional requirements:
この機能のための正式な仕様は、以下の追加要件を、最終POSIX標準になります。
- getaddrinfo() (along with the getnameinfo() function described in the next section) must be thread safe.
- （次のセクションで説明してgetnameinfo（）関数とともに）のgetaddrinfo（）は、スレッドセーフでなければなりません。
- The AI_NUMERICHOST is new with this document.
- AI_NUMERICHOSTは、この文書で新しく追加されました。
- All fields in socket address structures returned by getaddrinfo() that are not filled in through an explicit argument (e.g., sin6_flowinfo and sin_zero) must be set to 0. (This makes it easier to compare socket address structures.)
- （例えば、sin6_flowinfoとsin_zero）明示的な引数経由で充填されていないのgetaddrinfo（）によって返されたソケットアドレス構造体のすべてのフィールドは0に設定する必要があります（これは、それが簡単にソケットアドレス構造を比較することができます。）
- getaddrinfo() must fill in the length field of a socket address structure (e.g., sin6_len) on systems that support this field.
- のgetaddrinfo（）は、このフィールドをサポートしているシステム上のソケットアドレス構造体（例えば、sin6_len）の長さフィールドに記入しなければなりません。
We are providing this independent description of the function because POSIX standards are not freely available (as are IETF documents).
POSIX標準は（IETF文書であるとして）、自由に利用できませんので、我々は、関数のこの独立した記述を提供しています。
#include <sys/socket.h> #include <netdb.h> int getaddrinfo(const char *nodename, const char *servname, const struct addrinfo *hints, struct addrinfo **res);
（構造体ADDRINFO CONSTチャー*ノード名、CONSTするchar * servnameの、CONST構造体のaddrinfo *ヒント、** RES）の#includeは<sys / socket.h>にする#include <netdb.h> INTのgetaddrinfo。
The addrinfo structure is defined as a result of including the <netdb.h> header.
addrinfo構造体は、<netdb.h>ヘッダを含めた結果として定義されます。
struct addrinfo {
int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
int ai_family; /* PF_xxx */
int ai_socktype; /* SOCK_xxx */
int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
size_t ai_addrlen; /* length of 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 return value from the function is 0 upon success or a nonzero error code. The following names are the nonzero error codes from getaddrinfo(), and are defined in <netdb.h>:
関数からの戻り値が成功またはゼロ以外のエラーコード時に0です。次の名前は、のgetaddrinfo（）から非ゼロのエラーコードであり、<netdb.h>で定義されています。
EAI_ADDRFAMILY address family for nodename not supported EAI_AGAIN temporary failure in name resolution EAI_BADFLAGS invalid value for ai_flags EAI_FAIL non-recoverable failure in name resolution EAI_FAMILY ai_family not supported EAI_MEMORY memory allocation failure EAI_NODATA no address associated with nodename EAI_NONAME nodename nor servname provided, or not known EAI_SERVICE servname not supported for ai_socktype EAI_SOCKTYPE ai_socktype not supported EAI_SYSTEM system error returned in errno
ノード名のためEAI_ADDRFAMILYアドレスファミリは、名前解決にEAI_AGAIN一時的な失敗をサポートしていませんai_flagsに対して無効な値が名前解決にノード名のEAI_NONAMEノード名もservnameの関連付けられたアドレスが設けられていない、またはEAI_SERVICEを知られていないEAI_NODATA EAI_FAMILY ai_familyがサポートされていないEAI_MEMORYメモリ割り当ての失敗を回復不能の障害をEAI_FAIL EAI_BADFLAGS ai_socktype EAI_SOCKTYPEのai_socktypeのためにサポートされていないservnameのサポートされていないEAI_SYSTEMシステムエラーがerrnoに返されます
The nodename and servname arguments are pointers to null-terminated strings or NULL. One or both of these two arguments must be a non-NULL pointer. In the normal client scenario, both the nodename and servname are specified. In the normal server scenario, only the servname is specified. A non-NULL nodename string can be either a node name or a numeric host address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address). A non-NULL servname string can be either a service name or a decimal port number.
ノード名とservnameの引数はnull終端文字列またはNULLへのポインタです。 1つまたは複数のこれらの二つの引数の両方が非NULLポインタでなければなりません。通常のクライアントのシナリオでは、ノード名とservnameの両方が指定されています。通常のサーバーのシナリオでは、servnameだけが指定されています。非NULLノード名文字列は、ノード名または数値ホストアドレス文字列（すなわち、ドット付き10進数のIPv4アドレスまたはIPv6 16進数アドレス）のいずれかであり得ます。非NULLでないservname文字列はサービス名または10進数のポート番号のいずれかになります。
The caller can optionally pass an addrinfo structure, pointed to by the third argument, to provide hints concerning the type of socket that the caller supports. In this hints structure all members other than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or a NULL pointer. A value of PF_UNSPEC for ai_family means the caller will accept any protocol family. A value of 0 for ai_socktype means the caller will accept any socket type. A value of 0 for ai_protocol means the caller will accept any protocol. For example, if the caller handles only TCP and not UDP, then the ai_socktype member of the hints structure should be set to SOCK_STREAM when getaddrinfo() is called. If the caller handles only IPv4 and not IPv6, then the ai_family member of the hints structure should be set to PF_INET when getaddrinfo() is called. If the third argument to getaddrinfo() is a NULL pointer, this is the same as if the caller had filled in an addrinfo structure initialized to zero with ai_family set to PF_UNSPEC.
必要に応じてaddrinfo構造体を渡すことができ、発信者は、発信者がサポートするソケットの種類に関するヒントを提供するために、第三の引数によって指さ。この構造をai_flags以外のすべてのメンバーをヒント、ai_familyが、ai_socktype、およびai_protocolは、ゼロまたはNULLポインタでなければなりません。 ai_familyがためPF_UNSPECの値は、呼び出し側がどのプロトコルファミリを受け入れることを意味します。 ai_socktypeのための0の値は、呼び出し元が任意のソケットタイプを受け入れることを意味します。 ai_protocol 0の値は、呼び出し元が、任意のプロトコルを受け入れることを意味します。発信者がTCPだけではなくUDPを処理する場合はgetaddrinfo（）が呼び出されたとき、例えば、次にヒント構造体のai_socktype部材はSOCK_STREAMに設定されるべきです。発信者がIPv4のみとしないIPv6を処理する場合はgetaddrinfo（）が呼び出されたとき、その後、ヒント構造体のai_familyがメンバーはPF_INETに設定されるべきです。 （）をのgetaddrinfoする3番目の引数がNULLポインタである場合、発信者がPF_UNSPECにai_familyがセットでゼロに初期化addrinfo構造体に充填されたかのように、これは同じです。
Upon successful return a pointer to a linked list of one or more addrinfo structures is returned through the final argument. The caller can process each addrinfo structure in this list by following the ai_next pointer, until a NULL pointer is encountered. In each returned addrinfo structure the three members ai_family, ai_socktype, and ai_protocol are the corresponding arguments for a call to the socket() function. In each addrinfo structure the ai_addr member points to a filled-in socket address structure whose length is specified by the ai_addrlen member.
正常終了時に1つの以上のaddrinfo構造体のリンクリストへのポインタが最後の引数によって返されます。呼び出し側はNULLポインタに遭遇するまで、のai_nextポインタに従うことによって、このリスト内の各addrinfo構造体を処理することができます。それぞれにおいてai_socktype三人のメンバーai_familyがADDRINFO構造を戻し、ai_protocolは、ソケット（）関数の呼び出しのために対応する引数です。長ai_addrlen部材によって指定された塗りつぶされたソケットアドレス構造にai_addr部材ポイントは各addrinfo構造体です。
If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, then the caller plans to use the returned socket address structure in a call to bind(). In this case, if the nodename argument is a NULL pointer, then the IP address portion of the socket address structure will be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address.
AI_PASSIVEビットがヒント構造体のai_flagsメンバーに設定されている場合、呼び出し側は）（バインドする呼び出しで返されたソケットアドレス構造体を使用することを計画しています。ノード名引数がNULLポインタである場合は、この場合には、次にソケットアドレス構造体のIPアドレス部分はIPv6アドレスのIPv4アドレスまたはIN6ADDR_ANY_INITためINADDR_ANYに設定されます。
If the AI_PASSIVE bit is not set in the ai_flags member of the hints structure, then the returned socket address structure will be ready for a call to connect() (for a connection-oriented protocol) or either connect(), sendto(), or sendmsg() (for a connectionless protocol). In this case, if the nodename argument is a NULL pointer, then the IP address portion of the socket address structure will be set to the loopback address.
AI_PASSIVEビットがヒント構造体のai_flagsメンバーに設定されていない場合、返されるソケットアドレス構造体は、（接続する呼のために準備ができて）（コネクション指向プロトコルの場合）またはいずれか（接続）、（）のsendtoまたはsendmsgの（）（コネクションレス型プロトコルの場合）。ノード名引数がNULLポインタである場合は、この場合には、次にソケットアドレス構造体のIPアドレス部分は、ループバックアドレスに設定されます。
If the AI_CANONNAME bit is set in the ai_flags member of the hints structure, then upon successful return the ai_canonname member of the first addrinfo structure in the linked list will point to a null-terminated string containing the canonical name of the specified nodename.
AI_CANONNAMEビットがヒント構造体のai_flagsメンバーに設定されている場合は、正常終了時に、リンクされたリストの最初のaddrinfo構造体のAI_CANONNAMEメンバーは、指定されたノード名の正規名を含む、NULLで終了する文字列を指します。
If the AI_NUMERICHOST bit is set in the ai_flags member of the hints structure, then a non-NULL nodename string must be a numeric host address string. Otherwise an error of EAI_NONAME is returned. This flag prevents any type of name resolution service (e.g., the DNS) from being called.
AI_NUMERICHOSTビットがヒント構造体のai_flagsメンバーに設定されている場合は、非NULLノード名の文字列が数値ホストアドレス文字列でなければなりません。それ以外の場合はEAI_NONAMEのエラーが返されます。このフラグは、呼び出されるから名前解決サービス（例えば、DNS）の任意のタイプのを防止します。
All of the information returned by getaddrinfo() is dynamically allocated: the addrinfo structures, and the socket address structures and canonical node name strings pointed to by the addrinfo structures. To return this information to the system the function freeaddrinfo() is called:
getaddrinfo（）によって返されたすべての情報は、動的に割り当てられている：addrinfo構造体、およびソケットアドレス構造と正規のノード名の文字列はaddrinfo構造体が指します。システムにこの情報を返すには、関数freeaddrinfo（）が呼び出されます。
#include <sys/socket.h> #include <netdb.h>
書式#include <sysの/ socket.h>にする#include <netdb.h>
void freeaddrinfo(struct addrinfo *ai);
空freeaddrinfo（構造体のaddrinfo * AI）。
The addrinfo structure pointed to by the ai argument is freed, along with any dynamic storage pointed to by the structure. This operation is repeated until a NULL ai_next pointer is encountered.
addrinfo構造体は、構造によって指される任意の動的記憶とともに、AI引数が解放されることによって指さ。 NULLのai_nextポインタに出会うまでこの動作を繰り返します。
To aid applications in printing error messages based on the EAI_xxx codes returned by getaddrinfo(), the following function is defined.
）のgetaddrinfo（によって返さEAI_xxxコードに基づいて印刷エラーメッセージでアプリケーションを助けるために、以下の関数が定義されます。
#include <sys/socket.h> #include <netdb.h>
書式#include <sysの/ socket.h>にする#include <netdb.h>
char *gai_strerror(int ecode);
CHAR * gai_strerror（int型ECODE）。
The argument is one of the EAI_xxx values defined earlier and 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.
引数はエラーを記述する文字列の前に定義EAI_xxx値と戻り値のポイントの一つです。引数がEAI_xxx値の一つではない場合、この関数は、まだその内容が不明なエラーを示す文字列へのポインタを返します。
The POSIX 1003.1g specification includes no function to perform the reverse conversion from getaddrinfo(): to look up a nodename and service name, given the binary address and port. Therefore, we define the following function:
POSIX 1003.1グラム仕様は）はgetaddrinfo（からの逆変換を実行するために何の機能が含まれていないバイナリアドレスとポート与えられ、ノード名とサービス名をルックアップします。したがって、我々は次の関数を定義します。
#include <sys/socket.h> #include <netdb.h>
書式#include <sysの/ socket.h>にする#include <netdb.h>
int getnameinfo(const struct sockaddr *sa, socklen_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags);
int型てgetnameinfo（constのsockaddr構造体の*のSA、socklen_tをサレン、CHAR *ホスト、size_tのhostlen、するchar * SERV、size_tのservlenの、フラグをint型）;
This function looks up an IP address and port number provided by the caller in the DNS and system-specific database, and returns text strings for both in buffers provided by the caller. The function indicates successful completion by a zero return value; a non-zero return value indicates failure.
この機能は、DNSおよびシステム固有のデータベースに、呼び出し側が提供するIPアドレスとポート番号を検索し、呼び出し側が提供するバッファの両方のためにテキスト文字列を返します。関数はゼロの戻り値によって正常に完了したことを示しています。ゼロ以外の戻り値は失敗を示します。
The first argument, sa, points to either a sockaddr_in structure (for IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP address and port number. The salen argument gives the length of the sockaddr_in or sockaddr_in6 structure.
最初の引数は、SA、IPアドレスとポート番号を保持している（IPv4の場合）sockaddr_in構造体または（IPv6の場合）sockaddr_in6構造体のいずれかを指します。サレン引数は、sockaddr_in構造体またはSOCKADDR_IN6構造の長さを与えます。
The function returns the nodename associated with the IP address in the buffer pointed to by the host argument. The caller provides the size of this buffer via the hostlen argument. The service name associated with the port number is returned in the buffer pointed to by serv, and the servlen argument gives the length of this buffer. The caller specifies not to return either string by providing a zero value for the hostlen or servlen arguments. Otherwise, the caller must provide buffers large enough to hold the nodename and the service name, including the terminating null characters.
この関数は、ホスト引数によって指さバッファ内のIPアドレスに関連付けられたノード名を返します。呼び出し側はhostlen引数を経由して、このバッファのサイズを提供します。ポート番号に関連付けられているサービス名はSERVによって指されるバッファに返され、そしてservlenの引数は、このバッファの長さを与えます。呼び出し側はhostlenまたはservlenの引数のゼロ値を提供することにより、いずれかの文字列を返すことがありません指定します。それ以外の場合、呼び出し側は、終端のNULL文字を含むノード名およびサービス名は、保持するのに十分な大きさのバッファを提供しなければなりません。
Unfortunately most systems do not provide constants that specify the maximum size of either a fully-qualified domain name or a service name. Therefore to aid the application in allocating buffers for these two returned strings the following constants are defined in <netdb.h>:
残念ながら、ほとんどのシステムは、完全修飾ドメイン名またはサービス名のいずれかの最大サイズを指定する定数を提供していません。したがって、次の定数は、<netdb.h>で定義されているこれら二つの返される文字列のために割り当てるバッファにアプリケーションを助けるために：
#define NI_MAXHOST 1025 #define NI_MAXSERV 32
#define NI_MAXHOST 1025の#define NI_MAXSERV 32
The first value is actually defined as the constant MAXDNAME in recent versions of BIND's <arpa/nameser.h> header (older versions of BIND define this constant to be 256) and the second is a guess based on the services listed in the current Assigned Numbers RFC.
最初の値は、実際にBINDの<ARPA / nameser.h>ヘッダの最近のバージョンの定数MAXDNAMEとして定義される（BINDの古いバージョンでは、この定数は256であると定義）と第二は、割り当てられた現在に記載されているサービスに基づいて推測され番号RFC。
The final argument is a flag that changes the default actions of this function. By default the fully-qualified domain name (FQDN) for the host is looked up in the DNS and returned. If the flag bit NI_NOFQDN is set, only the nodename portion of the FQDN is returned for local hosts.
最後の引数は、この関数のデフォルトアクションを変更するフラグです。デフォルトでは、ホストの完全修飾ドメイン名（FQDN）がDNSで検索して返します。フラグビットNI_NOFQDNが設定されている場合、FQDNのノード名のみが部分は、ローカルホストのために戻されます。
If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be located in the DNS, the numeric form of the host's address is returned instead of its name (e.g., by calling inet_ntop() instead of getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is returned if the host's name cannot be located in the DNS.
フラグビットNI_NUMERICHOSTが設定されている場合、またはホスト名がDNSに位置することができない場合は、ホストのアドレスの数値形式ではなく、（代わりにgetipnodebyaddrの、例えば、（inet_ntopを呼び出すことによって）（））にその名を返します。フラグビットNI_NAMEREQDが設定されている場合は、ホストの名前がDNSに位置することができない場合は、エラーが返されます。
If the flag bit NI_NUMERICSERV is set, the numeric form of the service address is returned (e.g., its port number) instead of its name. The two NI_NUMERICxxx flags are required to support the "-n" flag that many commands provide.
フラグビットNI_NUMERICSERVが設定されている場合、サービスアドレスの数値形式ではなく、その名前（例えば、ポート番号）を返します。 2つのNI_NUMERICxxxフラグは、多くのコマンドが提供する「-n」フラグをサポートする必要があります。
A fifth flag bit, NI_DGRAM, specifies that the service is a datagram service, and causes getservbyport() to be called with a second argument of "udp" instead of its default of "tcp". This is required for the few ports (e.g. 512-514) that have different services for UDP and TCP.
第五のフラグビット、NI_DGRAMは、サービスがデータグラムサービスであり、その代わりに「TCP」のデフォルトの「UDP」の第2引数で呼び出されるgetservbyport（）を引き起こすことを指定します。これは、UDPとTCPで異なるサービスを持っているいくつかのポート（例えば、512-514）のために必要とされます。
These NI_xxx flags are defined in <netdb.h> along with the AI_xxx flags already defined for getaddrinfo().
これらNI_xxxフラグは既にのgetaddrinfoのために定義されAI_xxxフラグ（）と一緒に<netdb.h>で定義されています。
The two 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つの関数のinet_addr（）とINET_NTOA（）はバイナリとテキスト形式の間でIPv4アドレスを変換します。 IPv6アプリケーションは、同様の機能を必要とします。次の2つの関数は、IPv6とIPv4の両方のアドレスを変換します。
#include <sys/socket.h> #include <arpa/inet.h>
書式#include <sysの/ socket.h>にする#include <ARPA / inet.h>
int inet_pton(int af, const char *src, void *dst);
int型はinet_pton（int型AF、CONSTするchar * SRC、void *型DST）;
const char *inet_ntop(int af, const void *src, char *dst, size_t size);
constのchar * inet_ntop（int型AF、CONSTのvoid *のSRC、するchar * DST、size_tのサイズ）;
The inet_pton() function converts an address in its standard text presentation form into its numeric binary form. The af argument specifies the family of the address. Currently the AF_INET and AF_INET6 address families are 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. The address is returned in network byte order. Inet_pton() returns 1 if the conversion succeeds, 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. The calling application must ensure that the buffer referred to by dst is large enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16 bytes for AF_INET6).
inet_pton（）関数は、その数値バイナリ形式にその標準テキストプレゼンテーション形式のアドレスに変換します。 af引数はアドレスファミリを指定します。現在、AF_INETとAF_INET6アドレスファミリがサポートされています。文字列の引数srcポイントが渡されている。dst引数はポイントを関数が数値アドレスを格納するバッファへ。アドレスは、ネットワークバイト順で返されます。入力が有効なIPv4のドット付き十進数文字列または有効なIPv6アドレス文字列、または-1 AF引数が不明な場合EAFNOSUPPORTに設定errnoにしない場合、変換は、0を成功した場合はinet_pton（）は1を返します。呼び出し元のアプリケーションがDSTによって参照されるバッファが数値アドレス（例えば、AF_INETのための4バイトまたはAF_INET6のために16バイト）を保持するのに十分な大きさであることを保証しなければなりません。
If the af argument is AF_INET, the function accepts a string in the standard IPv4 dotted-decimal form:
AF引数がAF_INETであるならば、この関数は標準IPv4のドット-進形式の文字列を受け付けます。
ddd.ddd.ddd.ddd
ddd.ddd.ddd.ddd
where ddd is a one to three digit decimal number between 0 and 255. Note that many implementations of the existing inet_addr() and inet_aton() functions accept nonstandard input: octal numbers, hexadecimal numbers, and fewer than four numbers. inet_pton() does not accept these formats.
8進数、16進数、およびより少ない4つの数字：DDDは0と255の間注1〜3個の桁の10進数である既存のinet_addr（）とINET_ATON（）関数の多くの実装は、非標準の入力を受け付けること。 inet_pton（）これらのフォーマットを受け付けません。
If the af argument is AF_INET6, then the function accepts a string in one of the standard IPv6 text forms defined in Section 2.2 of the addressing architecture specification [2].
AF引数がAF_INET6である場合、関数はアドレッシングアーキテクチャ仕様のセクション2.2で定義された標準のIPv6テキスト形式のいずれかの文字列を受け付ける[2]。
The inet_ntop() function converts a numeric address into a text string suitable for presentation. The af argument specifies 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 will store the resulting text string. The size argument specifies the size of this buffer. The application must specify a non-NULL dst argument. For IPv6 addresses, the buffer must be at least 46-octets. For IPv4 addresses, the buffer must be at least 16-octets. 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>:
inet_ntop（）関数は、プレゼンテーションに適したテキスト文字列に数値アドレスに変換します。 af引数はアドレスファミリを指定します。これは、AF_INETまたはAF_INET6ことができます。 AF引数がAF引数がAF_INET6である場合、アドレスは、ネットワークバイト順でなければならないAF_INET、またはIPv6アドレスである場合、IPv4アドレスを保持しているバッファへのsrc引数ポイント。関数は結果のテキスト文字列を格納するバッファへのDST引数ポイント。サイズ引数は、このバッファのサイズを指定します。アプリケーションが非NULL DSTの引数を指定する必要があります。 IPv6アドレスの場合、バッファは少なくとも46オクテットでなければなりません。 IPv4アドレスの場合、バッファは少なくとも16オクテットでなければなりません。アプリケーションが容易に文字列形式でIPv4とIPv6のアドレスを格納するために適切なサイズのバッファを宣言することを可能にするために、以下の2つの定数は、<netinetの/ in.h>で定義されています。
#define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46
#define INET_ADDRSTRLEN 16の#define INET6_ADDRSTRLEN 46
The inet_ntop() function returns 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（）関数は、そうでない場合、変換が成功した場合、テキスト文字列を含むバッファへのポインタを返し、NULL。故障時には、errnoは結果バッファのサイズが不十分な場合、AF引数が無効またはENOSPCある場合EAFNOSUPPORTに設定されています。
The following macros can be used to test for special IPv6 addresses.
次のマクロは、特別なIPv6アドレスをテストするために使用することができます。
#include <netinet/in.h>
書式#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. Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for the two local-use IPv6 unicast addresses. These two macros do not return true for IPv6 multicast addresses of either link-local scope or site-local scope.
アドレスが指定された型であるか、そうでない場合はfalse場合は最初の7つのマクロはtrueを返します。最後の5つのテストのマルチキャストアドレスの範囲やアドレスが指定された範囲または偽のマルチキャストアドレスである場合にはアドレスが指定されたスコープのマルチキャストアドレスかどうかのどちらかでない場合はtrueを返します。 IN6_IS_ADDR_LINKLOCALとIN6_IS_ADDR_SITELOCALは2つだけのローカル使用IPv6ユニキャストアドレスのためにtrueを返すことに注意してください。これら二つのマクロは、リンクローカルスコープまたはサイトローカルスコープのいずれかのIPv6マルチキャストアドレスにはtrueを返しません。
The following list summarizes the constants, structure, and extern definitions discussed in this memo, sorted by header.
以下のリストは、定数、構造、およびヘッダでソートこのメモで議論のextern定義をまとめたものです。
<net/if.h> IF_NAMESIZE <net/if.h> struct if_nameindex{};
<ネット/ if.h> IF_NAMESIZE <ネット/ if.h>構造体if_nameindex {}。
<netdb.h> AI_ADDRCONFIG <netdb.h> AI_DEFAULT <netdb.h> AI_ALL <netdb.h> AI_CANONNAME <netdb.h> AI_NUMERICHOST <netdb.h> AI_PASSIVE <netdb.h> AI_V4MAPPED <netdb.h> EAI_ADDRFAMILY <netdb.h> EAI_AGAIN <netdb.h> EAI_BADFLAGS <netdb.h> EAI_FAIL <netdb.h> EAI_FAMILY <netdb.h> EAI_MEMORY <netdb.h> EAI_NODATA <netdb.h> EAI_NONAME <netdb.h> EAI_SERVICE <netdb.h> EAI_SOCKTYPE <netdb.h> EAI_SYSTEM <netdb.h> NI_DGRAM <netdb.h> NI_MAXHOST <netdb.h> NI_MAXSERV <netdb.h> NI_NAMEREQD <netdb.h> NI_NOFQDN <netdb.h> NI_NUMERICHOST <netdb.h> NI_NUMERICSERV <netdb.h> struct addrinfo{};
<Netdb.h> AI_ADDRCONFIG <netdb.h> AI_DEFAULT <netdb.h> AI_ALL <netdb.h> AI_CANONNAME <netdb.h> AI_NUMERICHOST <netdb.h> AI_PASSIVE <netdb.h> AI_V4MAPPED <netdb.h> EAI_ADDRFAMILY <netdb .H> EAI_AGAIN <netdb.h> EAI_BADFLAGS <netdb.h> EAI_FAIL <netdb.h> EAI_FAMILY <netdb.h> EAI_MEMORY <netdb.h> EAI_NODATA <netdb.h> EAI_NONAME <netdb.h> EAI_SERVICE <netdb.h > EAI_SOCKTYPE <netdb.h> EAI_SYSTEM <netdb.h> NI_DGRAM <netdb.h> NI_MAXHOST <netdb.h> NI_MAXSERV <netdb.h> NI_NAMEREQD <netdb.h> NI_NOFQDN <netdb.h> NI_NUMERICHOST <netdb.h> NI_NUMERICSERV <netdb.h>構造体のaddrinfo {}。
<netinet/in.h> IN6ADDR_ANY_INIT <netinet/in.h> IN6ADDR_LOOPBACK_INIT <netinet/in.h> INET6_ADDRSTRLEN
<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> 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;
<sys / socket.h>にAF_INET6は<sys / socket.h>にPF_INET6は<sys / socket.h>に構造体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 *, size_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 *, size_t, char *, size_t, int);
<netdb.h> void freeaddrinfo(struct addrinfo *);
<netdb.h> char *gai_strerror(int);
<netdb.h> struct hostent *getipnodebyname(const char *, int, int,
int *);
<netdb.h> struct hostent *getipnodebyaddr(const void *, size_t,
int, int *);
<netdb.h> void freehostent(struct hostent *);
<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 *);
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のセキュリティをサポートするために、ソケットインタフェースへの拡張を詳述コンパニオンメモが書かれています。
There are no issues for this memo concerning the Year 2000 issue regarding the use of dates.
日付の使用に関する2000年問題に関するこのメモには問題はありません。
Changes From RFC 2133
RFC 2133からの変更点
Changes made in the March 1998 Edition (-01 draft):
1998年3月版（-01ドラフト）で行われた変更：
Changed all "hostname" to "nodename" for consistency with other IPv6 documents.
他のIPv6文書との整合性を保つために、「ノード名」に、すべての「ホスト名」を変更しました。
Section 3.3: changed comment for sin6_flowinfo to be "traffic class & flow info" and updated corresponding text description to current definition of these two fields.
3.3節：「トラフィッククラス＆情報を流し」であることをsin6_flowinfoのためのコメントを変更し、これらの二つのフィールドの現在の定義に対応するテキスト記述を更新しました。
Section 3.10 ("Portability Additions") is new.
3.10節（「移植性の追加」）が新たに追加されました。
Section 6: a new paragraph was added reiterating that the existing gethostbyname() and gethostbyaddr() are not changed.
6章：新しい段落は、既存のgethostbyname（）とgethostbyaddr（）反復する追加されましたが変更されていません。
Section 6.1: change gethostbyname3() to getnodebyname(). Add AI_DEFAULT to handle majority of applications. Renamed AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and IPv4 addresses too. Defined exactly what getnodebyname() must return if the name argument is a numeric address string.
6.1節：変更gethostbyname3（）（getnodebynameします）。アプリケーションの大部分を処理するためにAI_DEFAULTを追加します。 AI_V6ADDRCONFIGはAI_ADDRCONFIGに改名し、記録のためにそれを定義し、IPv4も対応しています。 name引数が数値アドレス文字列である場合getnodebyname（）が返す必要があります正確に何を定義しました。
Section 6.2: change gethostbyaddr() to getnodebyaddr(). Reword items 2 and 3 in the description of how to handle IPv4-mapped and IPv4- compatible addresses to "lookup a name" for a given address, instead of specifying what type of DNS query to issue.
セクション6.2：変更はgethostbyaddr（）（getnodebyaddrします）。代わりに、問題にDNSクエリの種類を指定するので、与えられたアドレスに対して、「名前をルックアップ」するために、IPv4マップを処理する方法の説明とIPv4-互換アドレスにアイテム2と3を言い替えます。
Section 6.3: added two more requirements to getaddrinfo().
6.3節は：のgetaddrinfoするために、2つの以上の要件を追加しました（）。
Section 7: added the following constants to the list for <netdb.h>: AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED. Add union sockaddr_union and SA_LEN to the lists for <sys/socket.h>.
第7節は：AI_ADDRCONFIG、AI_ALLとAI_V4MAPPED：<netdb.h>のためのリストに次の定数を追加しました。 <sys / socket.h>にのためのリストに組合sockaddr_unionとSA_LENを追加します。
Updated references.
更新参照。
Changes made in the November 1997 Edition (-00 draft):
1997年11月版（-00ドラフト）で行われた変更：
The data types have been changed to conform with Draft 6.6 of the Posix 1003.1g standard.
データタイプは、POSIX 1003.1グラム標準のドラフト6.6に準拠するように変更されました。
Section 3.2: data type of s6_addr changed to "uint8_t".
セクション3.2：s6_addrのデータ・タイプは、「uint8_t」に変更しました。
Section 3.3: data type of sin6_family changed to "sa_family_t". data type of sin6_port changed to "in_port_t", data type of sin6_flowinfo changed to "uint32_t".
3.3節：sin6_familyのデータ・タイプは、「sa_family_t」に変更しました。 sin6_portのデータ型は、sin6_flowinfoのデータ型は「のuint32_t」に変更し、「in_port_t」に変更しました。
Section 3.4: same as Section 3.3, plus data type of sin6_len changed to "uint8_t".
3.4：3.3節、プラスsin6_lenのデータ型と同じで、「uint8_t」に変更しました。
Section 6.2: first argument of gethostbyaddr() changed from "const char *" to "const void *" and second argument changed from "int" to "size_t".
6.2節：のgethostbyaddrの最初の引数は（） "のconstのchar *" を "CONSTのvoid *" から変更し、第二引数は "INT" に "size_t型" から変更しました。
Section 6.4: second argument of getnameinfo() changed from "size_t" to "socklen_t".
セクション6.4：getnameinfoはの第2引数は（） "のsocklen_t" に "size_t型" から変更しました。
The wording was changed when new structures were defined, to be more explicit as to which header must be included to define the structure:
文言は、新しい構造を定義した場合、これにヘッダ構造を定義するために含まれなければならないように、より明示的に変更されました。
Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section 3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3 (ipv6_mreq{}), and Section 6.3 (addrinfo{}).
セクション3.2（のin6_addr {}）、3.3項（SOCKADDR_IN6 {}）、セクション3.4（SOCKADDR_IN6 {}）、4.3項（if_nameindex {}）、5.3項（ipv6_mreq {}）、および6.3（ADDRINFO {}）。
Section 4: NET_RT_LIST changed to NET_RT_IFLIST.
第4章：NET_RT_LISTはNET_RT_IFLISTに変更。
Section 5.1: The IPV6_ADDRFORM socket option was removed.
セクション5.1：IPV6_ADDRFORMソケットオプションが削除されました。
Section 5.3: Added a note that an option value other than 0 or 1 for IPV6_MULTICAST_LOOP returns an error. Added a note that IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP cannot be used with getsockopt().
5.3節は：IPV6_MULTICAST_LOOP 0または1以外のオプション値がエラーを返すことに注意してくださいを追加しました。 ）（）（IPV6_MULTICAST_IF、IPV6_MULTICAST_HOPS、およびIPV6_MULTICAST_LOOPはgetsockoptのにも使用できることに注意してくださいを追加しましたが、IPV6_ADD_MEMBERSHIPとIPV6_DROP_MEMBERSHIPはgetsockoptのに使用することはできません。
Section 6.1: Removed the description of gethostbyname2() and its associated RES_USE_INET6 option, replacing it with gethostbyname3().
6.1節は：gethostbyname3に置き換える、gethostbyname2（）とその関連RES_USE_INET6オプションの記述を削除しました（）。
Section 6.2: Added requirement that gethostbyaddr() be thread safe. Reworded step 4 to avoid using the RES_USE_INET6 option.
6.2節：（）、スレッドセーフであるとはgethostbyaddrを追加しました要件。 RES_USE_INET6オプションを使用しないようにステップ4を言い換えました。
Section 6.3: Added the requirement that getaddrinfo() and getnameinfo() be thread safe. Added the AI_NUMERICHOST flag.
6.3節は：getaddrinfo（）とgetnameinfo（）は、スレッドセーフである要件を追加しました。 AI_NUMERICHOSTフラグを追加しました。
Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL macros.
セクション6.6：IN6_IS_ADDR_LINKLOCALとIN6_IS_ADDR_SITELOCALマクロについて説明を追加しました。
Changes made to the draft -01 specification Sept 98
9月98ドラフト-01仕様への変更
Changed priority to traffic class in the spec.
スペックでトラフィッククラスに優先順位を変更しました。
Added the need for scope identification in section 2.1.
セクション2.1でスコープを識別するための必要性を追加しました。
Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and 3.4.
追加しましたではsin6_scope_idは、セクション3.3と3.4でのsockaddr_in6を構造体へ。
Changed 3.10 to use generic storage structure to support holding IPv6 addresses and removed the SA_LEN macro.
IPv6アドレスを保持してサポートするために、一般的なストレージ構造を使用するために3.10を変更し、SA_LENマクロを削除しました。
Distinguished between invalid input parameters and system failures for Interface Identification in Section 4.1 and 4.2.
セクション4.1及び4.2にインタフェース識別のための無効な入力パラメータとシステム障害を区別。
Added defaults for multicast operations in section 5.2 and changed the names from ADD to JOIN and DROP to LEAVE to be consistent with IPv6 multicast terminology.
5.2節では、マルチキャストオペレーションのデフォルトを追加しましたし、IPv6マルチキャスト用語と一致するように残すために参加するにはADDとDROPから名前を変えました。
Changed getnodebyname to getipnodebyname, getnodebyaddr to getipnodebyaddr, and added MT safe error code to function parameters in section 6.
変更getnodebynameは、getipnodebyname getipnodebyaddrするgetnodebyaddr、及びセクション6のパラメータを機能するようにMT安全なエラーコードを追加します。
Moved freehostent to its own sub-section after getipnodebyaddr now 6.3 (so this bumps all remaining sections in section 6.
6.3今getipnodebyaddr後、自身のサブセクションにfreehostentを移動（これはセクション6内のすべての残りのセクションをバンプ。
Clarified the use of AI_ALL and AI_V4MAPPED that these are dependent on the AF parameter and must be used as a conjunction in section 6.1.
これらは、AFパラメータに依存していることAI_ALLとAI_V4MAPPEDの使用を明確にし、セクション6.1で組み合わせとして使用されなければなりません。
Removed the restriction that literal addresses cannot be used with a flags argument in section 6.1.
リテラルアドレスは、セクション6.1でflags引数で使用することはできません制限を削除しました。
Added Year 2000 Section to the draft
ドラフトに2000年セクションを追加しました
Deleted Reference to the following because the attached is deleted from the ID directory and has expired. But the logic from the aforementioned draft still applies, so that was kept in Section 6.2 bullets after 3rd paragraph.
付属するので、次への参照を削除したが、IDディレクトリから削除され、有効期限が切れています。それは6.2箇条書き3番目の段落の後のセクションに保管されたように、しかし、前述のドラフトからのロジックはまだ適用されます。
[7] P. Vixie, "Reverse Name Lookups of Encapsulated IPv4 Addresses in IPv6", Internet-Draft, <draft-vixie-ipng-ipv4ptr-00.txt>, May 1996.
[7] P.いるVixie、インターネットドラフト、<ドラフトいるVixie-のIPng-ipv4ptr-00.txt>、1996年5月の "カプセル化のIPv4の逆引き参照の名前は、IPv6のアドレス"。
Deleted the following reference as it is no longer referenced. And the draft has expired.
それは、もはや参照されていないとして、次の参照を削除しました。そして、ドラフトの有効期限が切れています。
[3] D. McDonald, "A Simple IP Security API Extension to BSD Sockets", Internet-Draft, <draft-mcdonald-simple-ipsec-api-01.txt>, March 1997.
[3] D.マクドナルド、インターネットドラフト、<ドラフト・マクドナルド・シンプル-のipsec-API-01.txt> "BSDソケットへの簡単なIPセキュリティAPIの拡張"、1997年3月。
Deleted the following reference as it is no longer referenced.
それは、もはや参照されていないとして、次の参照を削除しました。
[4] C. Metz, "Network Security API for Sockets", Internet-Draft, <draft-metz-net-security-api-01.txt>, January 1998.
[4] C.メッツ、 "ソケットのためのネットワークセキュリティAPI"、インターネットドラフト、<ドラフト - メッツ - ネットセキュリティ-API-01.txt>、1998年1月。
Update current references to current status.
現在の状態への現在の参照を更新します。
Added alignment notes for in6_addr and sin6_addr.
in6_addrとのsin6_addr用のアライメントノートを追加しました。
Clarified further that AI_V4MAPPED must be used with a dotted IPv4 literal address for getipnodebyname(), when address family is AF_INET6.
AI_V4MAPPEDは、アドレスファミリがAF_INET6であるgetipnodebynameための点線のIPv4リテラルアドレス（）と一緒に使用しなければならないことをさらに明らかにしました。
Added text to clarify "::" and "::1" when used by getipnodebyaddr().
追加されたテキストは、「::」を明確関数とgetipnodebyaddrによって使用される「:: 1」（）します。
Acknowledgments
謝辞
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, 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, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl Williams, and Kazu Yamamoto,
含め、提案を行い、このドキュメントにフィードバックを提供し、多くの人々に感謝します：ワーナー・アルムズバーガーは、アトキンソン、フレッド・ベイカー、デイブ・ボーマン、アンドリューCherenson、アレックスコンタ、Alan Cox氏、スティーブデアリング、リチャードDraves、フランシスデュポン、ロバート・エルツ蘭マルク・Hasson、トム・ハーバート、ボブHindenとWAN-円・スー、クリスチャンのHuitema、今田耕司、マルクスJorkの、ロン・リー、アラン・ロイド、チャールズ・リン、ダン・マクドナルド、デイブ・ミトン、トーマスNarten氏、ジョシュ・オズボーン、クレイグ・パートリッジ、ジャン・リュックリシエ、エリックScoredos、キースSklower、マット・トーマス、ハーヴェイ・トンプソン、ディーンD. Throop、カレン・トレイシー、グレンTrewitt、ポール・ヴィクシー、デビッドWaitzman、カール・ウィリアムズ、そしてカズ山本、
The getaddrinfo() and getnameinfo() functions are taken from an earlier Internet Draft by Keith Sklower. As noted in that draft, 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（）関数は、キースSklowerによって以前インターネットドラフトから取られます。その草案で述べたように、ウィリアム・ダースト、スティーブン・ワイズ、マイケルKarels、そしてエリック・オールマンは、プロトコルに依存しない名前からアドレスへの変換をテーマに多くの有用な議論を提供し、そしてキースSklowerの当初の提案の初期バージョンを検討しました。エリック・オールマンは）（のgetaddrinfoの最初のプロトタイプを実装しました。名前とサービスのペアを指定すると、プロトコルの詳細の独立したサービスに接続するために十分であるという観察は、「統一ネットワーク・インタフェース」の提案には、X / Openにマーシャルローズによって作られました。
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.
クレイグ・メッツ、ジャック・マッキャン、エリックNordmarkと、ティムHartrick、およびムケシュKackerは、この文書に多くの貢献をしました。ラメシュ・ガバインダンは貢献の数を作り、このメモの以前のバージョンを共同執筆しました。
References
リファレンス
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[1]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[2] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[2] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[3] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT 6.6, March 1997.
[3] IEEE、 "プロトコル独立インタフェース"、IEEE規格の1003.1グラム、DRAFT 6.6、1997年3月。
[4] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC 2292, February 1998.
[4]スティーブンス、W。およびM.トーマス、 "IPv6用の拡張ソケットAPI"、RFC 2292、1998年2月。
Authors' Addresses
著者のアドレス
Robert E. Gilligan FreeGate Corporation 1208 E. Arques Ave. Sunnyvale, CA 94086
ロバートE.ギリガン自由門株式会社1208 E.アルクアベニュー。サニーベール、CA 94086
Phone: +1 408 617 1004 EMail: gilligan@freegate.com
電話：+1 408 617 1004 Eメール：gilligan@freegate.com
Susan Thomson Bell Communications Research MRE 2P-343, 445 South Street Morristown, NJ 07960
スーザン・トムソンベルコミュニケーションズリサーチMRE 2P-343、445サウスストリートモリスタウン、NJ 07960
Phone: +1 201 829 4514 EMail: set@thumper.bellcore.com
電話：+1 201 829 4514 Eメール：set@thumper.bellcore.com
Jim Bound Compaq Computer Corporation 110 Spitbrook Road ZK3-3/U14 Nashua, NH 03062-2698
ジム・コンパックコンピュータ株式会社110 SpitbrookロードZK3-3 / U14ナシュア、ニューハンプシャー03062から2698バウンド
Phone: +1 603 884 0400 EMail: bound@zk3.dec.com
電話：+1 603 884 0400 Eメール：bound@zk3.dec.com
W. Richard Stevens 1202 E. Paseo del Zorro Tucson, AZ 85718-2826
Ｗ。 りちゃｒｄ Ｓてゔぇんｓ １２０２ え。 ぱせお でｌ ぞっろ つｃそん、 あＺ ８５７１８ー２８２６
Phone: +1 520 297 9416 EMail: rstevens@kohala.com
電話：+1 520 297 9416 Eメール：rstevens@kohala.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。