[要約] RFC 2553は、IPv6に対する基本的なソケットインターフェースの拡張に関する規格です。その目的は、IPv6をサポートするために既存のソケットインターフェースを拡張し、IPv6ネットワーク上での通信を可能にすることです。
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
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.
Copyright（c）The Internet Society（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システムにも実装されています。Sockets APIを使用して記述されたTCP/IPアプリケーションは、過去に高度な携帯性を享受しており、IPv6アプリケーションでも同じ移植性を希望しています。ただし、IPv6をサポートするにはSockets APIに変更が必要であり、このメモはこれらの変更について説明しています。これらには、IPv6アドレスを運ぶための新しいソケットアドレス構造、新しいアドレス変換関数、およびいくつかの新しいソケットオプションが含まれます。これらの拡張機能は、マルチキャストを含むTCPおよびUDPアプリケーションで必要な基本的なIPv6機能へのアクセスを提供するように設計されており、システムに最小限の変更を導入し、既存のIPv4アプリケーションに完全な互換性を提供します。高度な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変更は既存のプログラムを壊すべきではありません。これを検証するための実装の追加メカニズムは、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の変更は、既存のIPv4アプリケーションをIPv6に変換するタスクを簡素化するために、できるだけ小さくする必要があります。
- Where possible, applications should be able to use this API to interoperate with both IPv6 and IPv4 hosts. Applications should not need to know which type of host they are communicating with.
- 可能であれば、アプリケーションはこのAPIを使用して、IPv6ホストとIPv4ホストの両方と相互運用できる必要があります。アプリケーションは、どのタイプのホストと通信しているかを知る必要はありません。
- 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:
Socket Interface 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パケットの送信と受信などの機能を扱う機能は、独立しているように設計されています。プロトコルアドレスが関数引数として渡される場合、それらは不透明なポインターを介して運ばれます。ソケット機能がサポートするプロトコルごとに、プロトコル固有のアドレスデータ構造が定義されます。アプリケーションは、ソケット機能を使用する場合、これらのプロトコル固有のアドレス構造にポインターをキャストする必要があります。これらの関数は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オクテットが含まれており、このスペースを使用してSockaddr_in構造をIPv6に適応させようとするのは魅力的です。残念ながら、Sockaddr_in構造は、16オクテットのIPv6アドレスと、必要な他の情報（アドレスファミリ番号）を保持するのに十分な大きさではありません。したがって、IPv6に対して新しいアドレスデータ構造を定義する必要があります。
IPv6 addresses are scoped [2] so they could be link-local, site, organization, global, or other scopes at this time undefined. To support applications that want to be able to identify a set of interfaces for a specific scope, the IPv6 sockaddr_in structure must support a field that can be used by an implementation to identify a set of interfaces identifying the scope for an IPv6 address.
IPv6アドレスはスコープ[2]であるため、現時点ではリンクローカル、サイト、組織、グローバル、またはその他のスコープにすることができます。特定の範囲のインターフェイスのセットを識別できるようにするアプリケーションをサポートするには、IPv6 Sockaddr_in構造は、IPv6アドレスの範囲を識別する一連のインターフェイスを識別するために実装によって使用できるフィールドをサポートする必要があります。
The 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 1003.1gのドラフト6.6（1997年3月）のデータ型が使用されます。UINTN_Tは、正確なnビット（UINT16_Tなど）の署名されていない整数を意味します。また、可能な場合は1003.1gから引数データ型を想定しています（たとえば、SetSockopt（）に対する最終的な引数はSIZE_T値です）。バッファサイズが指定されるたびに、POSIX 1003.1 size_tデータ型が使用されます（たとえば、getNameInfo（）の2つの長さの引数）。
When function prototypes and structures are shown we show the headers that must be #included to cause that item to be defined.
関数のプロトタイプと構造が示されている場合、そのアイテムを定義するために#includedでなければならないヘッダーを表示します。
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は、Socket（）関数の最初の引数で使用され、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は通常、「struct 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構造です（前のセクションで定義されています）。このフィールドには、128ビットIPv6アドレスが1つあります。アドレスはネットワークバイトの順序で保存されます。
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_addr sin6_scope_idはインターフェイスインデックスになります。サイトスコープ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（struct sockaddr_in）はsizeof（struct sockaddr）に等しく、どちらも16バイトです。この仮定を作成する既存のコードは、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」フィールドは、16ビット値から8ビット値に変更され、「SA_LEN」という名前の長さフィールドを保持するために使用されるスペースが節約されました。前のセクションに記載されているSockaddr_in6データ構造は、新しいSockaddrデータ構造に正しくキャストすることはできません。このため、4.4BSDに基づいてシステムで使用するために、次の代替IPv6アドレスデータ構造が提供されます。<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:
アプリケーションはSocket（）関数を呼び出して、通信エンドポイントを表すソケット記述子を作成します。Socket（）関数の引数は、使用するプロトコルと、後続の関数で使用されるどの形式アドレス構造をシステムに伝えます。たとえば、IPv4/TCPソケットを作成するには、アプリケーションが呼び出します。
s = socket(PF_INET, SOCK_STREAM, 0);
To create an IPv4/UDP socket, applications make the call:
IPv4/UDPソケットを作成するには、アプリケーションが呼び出します。
s = socket(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);
To create an IPv6/UDP socket, applications make the call:
IPv6/UDPソケットを作成するには、アプリケーションが呼び出します。
s = socket(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()
bind（）connect（）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:
システムは、Sockaddr_in6アドレス構造を使用して、PF_INET6ソケットを使用しているアプリケーションにアドレスを返します。システムからアプリケーションにアドレスを返す機能は次のとおりです。
accept() recvfrom() recvmsg() getpeername() getsockname()
Accept（）recvfrom（）recvmsg（）getPeername（）getSockName（）
No changes to the syntax of the socket functions are needed to support IPv6, since all of the "address carrying" functions use an opaque address pointer, and carry an address length as a function argument.
すべての「アドレスを伝える」関数のすべてが不透明なアドレスポインターを使用し、関数引数としてアドレス長を運ぶため、IPv6をサポートするためにソケット関数の構文に変更は必要ありません。
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アドレス構造を引き続きサポートする必要があることを意味します。前のセクションで説明したように、アプリケーションはSocket（）関数のPF_INET定数を使用してIPv4/TCPおよびIPv4/UDPソケットを作成できる必要があります。アプリケーションは、同じプロセス内でIPv4/TCP、IPv4/UDP、IPv6/TCP、IPv6/UDPソケットの組み合わせを同時に保持できる必要があります。
Applications using the original API should continue to operate as they did on systems supporting only IPv4. That is, they should continue to interoperate with IPv4 nodes.
元のAPIを使用したアプリケーションは、IPv4のみをサポートするシステムで行ったように、引き続き動作します。つまり、IPv4ノードと相互運用し続ける必要があります。
The API also provides a different type of compatibility: the ability for IPv6 applications to interoperate with IPv4 applications. This feature uses the IPv4-mapped IPv6 address format defined in the IPv6 addressing architecture specification [2]. This address format allows the IPv4 address of an IPv4 node to be represented as an IPv6 address. The IPv4 address is encoded into the low-order 32 bits of the IPv6 address, and the high-order 96 bits hold the fixed prefix 0:0:0:0:0:FFFF. IPv4- mapped addresses are written as follows:
APIは、異なるタイプの互換性も提供します。IPv6アプリケーションがIPv4アプリケーションと相互操作する機能です。この機能では、IPv6アドレス指定のアーキテクチャ仕様[2]で定義されているIPv4-Mapped IPv6アドレス形式を使用します。このアドレス形式により、IPv4ノードのIPv4アドレスをIPv6アドレスとして表現できます。IPv4アドレスは、IPv6アドレスの低次の32ビットにエンコードされ、高次の96ビットは固定プレフィックス0：0：0：0：0：FFFFを保持します。IPv4-マッピングされたアドレスは次のように記述されています。
::FFFF:<IPv4-address>
These addresses can be generated automatically by the getipnodebyname() function when the specified host has only IPv4 addresses (as described in Section 6.1).
これらのアドレスは、指定されたホストにIPv4アドレスのみを持っている場合、getIpNodeByName（）関数によって自動的に生成できます（セクション6.1で説明されています）。
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.
アプリケーションは、PF_INET6ソケットを使用して、IPv4ノードへのTCP接続を開き、IPv4ノードにUDPパケットを送信します。これは、宛先のIPv4アドレスをIPv4-Mapped IPv6アドレスとしてエンコードし、ソッカドドラ_IN6構造内でそのアドレスを渡すだけで、そのアドレスを接続します（）またはsendto（）call。アプリケーションがPF_INET6ソケットを使用してIPv4ノードからTCP接続を受け入れるか、IPv4ノードからUDPパケットを受信する場合、システムは、sockaddr_in6構造を使用してaccept（）、recvfrom（）、またはgetPeername（）コールのアプリケーションにピアのアドレスを返します。こちらです。
Few applications will likely need to know which type of node they are interoperating with. However, for those applications that do need to know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is provided.
どのタイプのノードが相互運用しているかを知る必要があるアプリケーションはほとんどありません。ただし、知る必要があるアプリケーションの場合、セクション6.7で定義されているIN6_IS_ADDR_V4MAPPENT（）マクロが提供されます。
While the bind() function allows applications to select the source IP address of UDP packets and TCP connections, applications often want the system to select the source address for them. With IPv4, one specifies the address as the symbolic constant INADDR_ANY (called the "wildcard" address) in the bind() call, or simply omits the bind() entirely.
BIND（）関数により、アプリケーションはUDPパケットとTCP接続のソースIPアドレスを選択できますが、アプリケーションはシステムのソースアドレスを選択することを望んでいます。IPv4を使用すると、bind（）呼び出しのシンボリック定数inaddr_any（「wildcard」アドレスと呼ばれる）としてアドレスを指定するか、単にbind（）を完全に省略します。
Since the IPv6 address type is a structure (struct in6_addr), a symbolic constant can be used to initialize an IPv6 address variable, but cannot be used in an assignment. Therefore systems provide the IPv6 wildcard address in two forms.
IPv6アドレスタイプは構造（struct in6_addr）であるため、シンボリック定数を使用してIPv6アドレス変数を初期化できますが、割り当てでは使用できません。したがって、システムは2つの形式でIPv6ワイルドカードアドレスを提供します。
The first version is a global variable named "in6addr_any" that is an in6_addr structure. The extern declaration for this variable is defined in <netinet/in.h>:
最初のバージョンは、in6_addr構造である「in6addr_any」という名前のグローバル変数です。この変数のextern宣言は、<netinet/in.h>で定義されています。
extern const struct in6_addr in6addr_any;
extern const struct in6_addr in6addr_any;
Applications use in6addr_any similarly to the way they use INADDR_ANY in IPv4. For example, to bind a socket to port number 23, but let the system select the source address, an application could use the following code:
アプリケーションは、IPv4でINADDR_ANYを使用する方法と同様に、IN6ADDR_ANYを使用します。たとえば、ソケットをポート番号23にバインドするには、システムにソースアドレスを選択できるようにするため、アプリケーションは次のコードを使用できます。
struct sockaddr_in6 sin6;
. . .
sin6.sin6_family = AF_INET6;
sin6.sin6_flowinfo = 0;
sin6.sin6_port = htons(23);
sin6.sin6_addr = in6addr_any; /* structure assignment */
. . .
if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
. . .
The other version is a symbolic constant named IN6ADDR_ANY_INIT and is defined in <netinet/in.h>. This constant can be used to initialize an in6_addr structure:
他のバージョンは、in6addr_any_initという名前の象徴的な定数であり、<netinet/in.h>で定義されています。この定数は、IN6_ADDR構造を初期化するために使用できます。
struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
struct in6_addr anyaddr = in6addr_any_init;
Note that this constant can be used ONLY at declaration time. It can not be used to assign a previously declared in6_addr structure. For example, the following code will not work:
この定数は、宣言時にのみ使用できることに注意してください。以前に宣言されたIN6_ADDR構造を割り当てるために使用できません。たとえば、次のコードは機能しません。
/* This is the WRONG way to assign an unspecified address */
struct sockaddr_in6 sin6;
. . .
sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
Be aware that the IPv4 INADDR_xxx constants are all defined in host byte order but the IPv6 IN6ADDR_xxx constants and the IPv6 in6addr_xxx externals are defined in network byte order.
IPv4 INADDR_XXX定数はすべてホストバイトの順序で定義されているが、IPv6 IN6ADDR_XXX定数と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.
アプリケーションは、ローカルノードに存在するサービスにUDPパケットを送信、またはTCP接続を送信する必要がある場合があります。IPv4では、connect（）、sendto（）、またはsendmsg（）callで定数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>:
グローバル変数は、「in6addr_loopback」という名前のIN6_ADDR構造です。この変数のextern宣言は、<netinet/in.h>で定義されています。
extern const struct in6_addr in6addr_loopback;
extern const struct in6_addr in6addr_loopback;
Applications use in6addr_loopback as they would use INADDR_LOOPBACK in IPv4 applications (but beware of the byte ordering difference mentioned at the end of the previous section). For example, to open a TCP connection to the local telnet server, an application could use the following code:
アプリケーションは、IN6ADDR_LOOPBACKを使用して、IPv4アプリケーションでINADDR_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;
struct in6_addr loopbackaddr = in6addr_loopback_init;
Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to a previously declared IPv6 address variable.
IN6ADDR_ANY_INITと同様に、この定数は、以前に宣言されたIPv6アドレス変数への割り当てで使用することはできません。
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に追加された1つの単純な追加は、「struct 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).
- 使用中のプロトコルを導出するための判別因子として使用できる、その実装の「struct sockaddr」データ構造のフィールドに対する初期フィールドの等分率を持っています。これらの初期フィールドは、ほとんどの実装では、それぞれタイプ「SA_FAMILY_T」（SA_FAMILYフィールドから16ビット、16ビット）のタイプ「SA_FAMILY_T」（16ビット）の2つのフィールド（sa_lenおよびsa_family_tへの同型）の単一フィールドです。。
An example implementation design of such a data structure would be as follows.
このようなデータ構造の実装設計の例は次のとおりです。
/*
* Desired design of maximum size and alignment
*/
#define _SS_MAXSIZE 128 /* Implementation specific max size */
#define _SS_ALIGNSIZE (sizeof (int64_t))
/* Implementation specific desired alignment */
/*
* Definitions used for sockaddr_storage structure paddings design.
*/
#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）、Sockaddr_in（IPV4）のアドレスデータ構造のニーズに合わせて十分な適切なアライメントをカバーする64ビットアライメントを強制するために使用されます。パディングフィールドのサイズ__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（）などの呼び出しでソケットアドレス構造へのポインターが予想され、アクセスしてアドレスファミリを決定するこのタイプの変数にポインターを渡すことができます。通話後の受信コンテンツ。
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ドメインソケットアドレス構造では常に誤っています（ただし、実際にはこれは問題ではありませんでした）。。
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）。さらに、Advanced API [4]は、これらの同じインターフェイスインデックスを使用して、データグラムが受信されるインターフェイスを識別するか、データグラムを送信するインターフェイスを指定します。
Interfaces are normally known by names such as "le0", "sl1", "ppp2", and the like. On Berkeley-derived implementations, when an interface is made known to the system, the kernel assigns a unique positive integer value (called the interface index) to that interface. These are small positive integers that start at 1. (Note that 0 is never used for an interface index.) There may be gaps so that there is no current interface for a particular positive interface index.
インターフェイスは通常、「LE0」、「SL1」、「PPP2」などの名前で知られています。バークレー由来の実装では、インターフェイスがシステムに知られている場合、カーネルはそのインターフェイスに一意の正の整数値（インターフェイスインデックスと呼ばれる）を割り当てます。これらは、1から始まる小さな正の整数です（0はインターフェイスインデックスに使用されないことに注意してください。）特定のポジティブインターフェイスインデックスの現在のインターフェイスがないようにギャップがある可能性があります。
This API defines two functions that map between an interface name and index, a third function that returns all the interface names and indexes, and a fourth function to return the dynamic memory allocated by the previous function. How these functions are implemented is left up to the implementation. 4.4BSD implementations can implement these functions using the existing sysctl() function with the NET_RT_IFLIST command. Other implementations may wish to use ioctl() for this purpose.
このAPIは、インターフェイス名とインデックスの間にマッピングされる2つの関数、すべてのインターフェイス名とインデックスを返す3番目の関数、および前の関数によって割り当てられた動的メモリを返す4番目の関数を定義します。これらの機能がどのように実装されるかは、実装に任されています。4.4BSD実装は、net_rt_iflistコマンドを使用して既存のsysctl（）関数を使用してこれらの関数を実装できます。他の実装では、この目的のためにIOCTL（）を使用する場合があります。
The first function maps an interface name into its corresponding index.
最初の関数は、インターフェイス名を対応するインデックスにマップします。
#include <net/if.h>
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.
2番目の関数は、インターフェイスインデックスを対応する名前にマッピングします。
#include <net/if.h>
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は<net/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構造は、単一のインターフェイスに関する情報を保持し、<net/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構造の配列を返します。これは、インターフェイスごとに1つの構造です。
struct if_nameindex *if_nameindex(void);
The end of the array of structures is indicated by a structure with an if_index of 0 and an if_name of NULL. The function returns a NULL pointer upon an error, and would set errno to the appropriate value.
構造の配列の終了は、0のif_indexとnullのif_nameを持つ構造によって示されます。この関数は、エラー時に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>
void if_freenameindex(struct 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{}.
現在、net/if.hは関数のプロトタイプ定義を持っていません。これらの定義は、net/if.hおよびstruct 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ソケットオプション、およびこのセクションで定義された関連定数は、Header <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;
int hoplimit = 10;
if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
(char *) &hoplimit, sizeof(hoplimit)) == -1)
perror("setsockopt IPV6_UNICAST_HOPS");
When the IPV6_UNICAST_HOPS option is set with setsockopt(), the option value given is used as the hop limit for all subsequent unicast packets sent via that socket. If the option is not set, the system selects a default value. The integer hop limit value (called x) is interpreted as follows:
IPv6_unicast_hopsオプションがsetSockopt（）で設定されている場合、与えられたオプション値は、そのソケットを介して送信されるすべての後続のユニキャストパケットのホップ制限として使用されます。オプションが設定されていない場合、システムはデフォルト値を選択します。整数ホップ制限値（xと呼ばれる）は、次のように解釈されます。
x < -1: return an error of EINVAL
x == -1: use kernel default
0 <= x <= 255: use x
x >= 256: return an error of EINVAL
The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine the hop limit value that the system will use for subsequent unicast packets sent via that socket. For example:
IPv6_unicast_hopsオプションは、getSockopt（）で使用して、システムがそのソケットを介して送信される後続のユニキャストパケットに使用するホップ制限値を決定できます。例えば：
int hoplimit;
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
引数タイプ：署名されていない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
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
引数タイプ：署名されていないint
The reception of multicast packets is controlled by the two setsockopt() options summarized below. An error of EOPNOTSUPP is returned if these two options are used with getsockopt().
マルチキャストパケットの受信は、以下にまとめた2つのSetSockopt（）オプションによって制御されます。これらの2つのオプションがgetSockopt（）で使用される場合、eopnotsuppのエラーが返されます。
IPV6_JOIN_GROUP
ipv6_join_group
Join a multicast group on a specified local interface. If the interface index is specified as 0, the kernel chooses the local interface. For example, some kernels look up the multicast group in the normal IPv6 routing table and using the resulting interface.
指定されたローカルインターフェイスでマルチキャストグループに参加します。インターフェイスインデックスが0として指定されている場合、カーネルはローカルインターフェイスを選択します。たとえば、一部のカーネルは、通常のIPv6ルーティングテーブルと結果のインターフェイスを使用して、マルチキャストグループを検索します。
Argument type: struct ipv6_mreq
引数タイプ：struct ipv6_mreq
IPV6_LEAVE_GROUP
ipv6_leave_group
Leave a multicast group on a specified interface.
指定されたインターフェイスにマルチキャストグループを残します。
Argument type: struct ipv6_mreq
引数タイプ：struct ipv6_mreq
The argument type of both of these options is the ipv6_mreq structure, defined as a result of including the <netinet/in.h> header;
これらの両方のオプションの両方の引数タイプは、<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アドレスを検索するには、関数が必要です。フォワードルックアップ（Nodename-to-Addressからの翻訳）とリバースルックアップ（アドレス間翻訳）の両方をサポートする必要があります。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-Mapped IPv6は大丈夫です）、および第二に、この関数の多くの実装はスレッド安全ではないためです。RFC 2133はgethostbyname2（）という名前の関数を定義しましたが、この関数も不十分でした。1つ目は、IPv6アドレスが必要なときにグローバルオプション（RES_USE_INET6）を設定する必要があるため、2つ目は、発信者に追加の制御を提供するためにFLAG引数が必要なためです。必要なアドレスの種類。
The following function is new and must be thread safe:
次の関数は新しく、スレッドセーフでなければなりません：
#include <sys/socket.h>
#include <netdb.h>
struct hostent *getipnodebyname(const char *name, int af, int flags
int *error_num);
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 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:
名前の引数は、ノード名または数値アドレス文字列（つまり、点線程度のIPv4アドレスまたはIPv6 HEXアドレス）のいずれかです。AF引数は、AF_INETまたはAF_INET6のいずれかのアドレスファミリを指定します。ERROR_NUM値は、ポインターを介して、ERRO_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);
with
ととともに共に共といっしょに以て
hptr = getipnodebyname(name, 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.
検索および返されるアドレスの種類をより細かい制御する必要があるアプリケーションは、フラグの引数の他の組み合わせを指定できます。
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アドレスのみを必要とします。レコードのクエリが作成されます。成功した場合、IPv4アドレスが返され、ホステント構造のh_lengthメンバーは4になり、その場合、関数はnullポインターを返します。
- 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レコードのクエリが作成されます。成功した場合、IPv6アドレスが返され、ホステント構造のH_Lengthメンバーが16になり、その場合、関数はnullポインターを返します。
Other constants can be logically-ORed into the flags argument, to modify the behavior of the function.
他の定数は、関数の動作を変更するために、フラグの引数に論理的に操作できます。
- 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-Mapped IPv6アドレスを受け入れます。つまり、AAAAレコードが見つからない場合、レコードに対してクエリが作成され、IPv4-Mapped IPv6アドレス（H_LENGTHは16）として見つかったものが返されます。AI_V4MAPPEDフラグは、AFがAF_INET6に等しい場合を除き、無視されます。
- 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アドレスファミリでのみ使用されます。AI_ALLがAI_V4Mappedフラグを使用して論理的にORである場合、発信者はすべてのアドレスを必要とします：IPv6およびIPv4-Mapped IPv6。AAAAレコードに対して最初にクエリが作成され、成功した場合、IPv6アドレスが返されます。次に、レコードに対して別のクエリが作成され、見つかったすべてのクエリがIPv4マップIPv6アドレスとして返されます。h_lengthは16になります。両方のクエリが失敗した場合にのみ、関数がnullポインターを返します。このフラグは、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_ADDRDRCONFIGフラグは、AAAAレコードのクエリが少なくとも1つのIPv6ソースアドレスが構成されている場合にのみ発生することを指定し、レコードのクエリは、ノードに少なくとも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;
(a) ai_addrconfigのみが指定されている場合、関数はnullポインターを返します。（b）ai_addrconfigの場合|AI_V4Mappedが指定され、AレコードはIPv4マップIPv6アドレスとして返されます。
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（）関数は、名前引数がノード名またはリテラルアドレス文字列（つまり、点線デシマルIPv4アドレスまたはIPv6 HEXアドレス）のいずれかであることを許可する必要があることに注意しました。これにより、リテラルアドレス文字列を処理するために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 HEXアドレスであり、AFがAF_INET6に等しい場合。返されたホステント構造のメンバーは次のとおりです。H_NAMEが名前引数のコピーを指し、H_Aliaseはヌルポインターであり、H_ADDRTYPEはAF引数のコピーです。[0]は4バイトまたは16バイトのバイナリアドレスへのポインターであり、h_addr_list [1]はヌルポインターです。
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.
名前が点線程度のIPv4アドレスであり、AFがAF_INET6に等しく、フラグがAI_V4Mappedに等しい場合、IPv4-Mapped IPv6アドレスが返されます。H_NAMEはIPv4マッピングIPv6アドレスを含むIPv6 HEXアドレスを指します、H_Aliaseはnull pointerです。is af_inet6、h_lengthは16、h_addr_list [0]は16バイトのバイナリアドレスへのポインターであり、h_addr_list [1]はヌルポインターです。ai_v4mappが設定されている場合（ai_allの有無にかかわらず）ipv4-mappを返します。それ以外は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 HEXアドレスであり、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>
struct hostent *getipnodebyaddr(const void *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.
混乱の可能性のある原因の1つは、IPv4-Mapped 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-Mapped IPv6アドレスまたはIPv4互換IPv6アドレスである場合、IPv6アドレスの最初の12バイトをスキップし、AF_INETに設定し、設定し、設定します4から4。
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).
3. AFがAF_INET6の場合、指定された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. 関数が成功を返している場合、ホステント構造で返される単一のアドレスは、この関数の引数として渡された同じアドレスファミリを持つ関数への最初の引数のコピーです。
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 HEXアドレスは「:: "および" :: 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のマクロについては、 "::" and ":: 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:
ホステント構造は、既存の定義から変化しません。この構造と、この構造によって指摘された情報は、getipnodebynameとgetipnodebyaddrによって動的に割り当てられます。次の関数はこのメモリを解放します：
#include <netdb.h>
void freehostent(struct 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].
Nodename-to-Addressからの翻訳は、電気および電子エンジニア研究所（IEEE）POSIX 1003.1g（プロトコル独立インターフェイス）ドラフト仕様[3]から取得されるgetAddrinfo（）関数を使用して、プロトコルに依存しない方法で行われます。
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.
- getaddrinfo（）（次のセクションで説明したgetnameInfo（）関数とともに）はスレッド安全でなければなりません。
- 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.)
- getaddrinfo（）によって返されるソケットアドレス構造のすべてのフィールドは、明示的な引数（sin6_flowinfoやsin_zeroなど）を通じて入力されていません。
- 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);
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 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_SERVICEservname ai_socktype eai_socktype ai_socktypeサポートされていないERNOで返されたEAI_SYSTEMエラーがサポートされていません
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.
nodenameおよびservnameの引数は、ヌル終端文字列またはnullのポインターです。これら2つの引数の1つまたは両方は、非ヌルポインターでなければなりません。通常のクライアントシナリオでは、ノデナムとサーブ名の両方が指定されています。通常のサーバーシナリオでは、ServNameのみが指定されています。非null nodename文字列は、ノード名または数値ホストアドレス文字列（つまり、点線程度のIPv4アドレスまたはIPv6 HEXアドレス）のいずれかです。非ヌルサーブ名文字列は、サービス名または小数ポート番号のいずれかです。
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.
発信者は、オプションで、3番目の引数に指摘されたAddRINFO構造を通過し、発信者がサポートするソケットの種類に関するヒントを提供することができます。このヒント構造では、ai_flags、ai_family、ai_socktype、およびai_protocol以外のすべてのメンバーがゼロまたはnullポインターでなければなりません。AI_FamilyのPF_UNSPECの値は、発信者がプロトコルファミリーを受け入れることを意味します。AI_SockTypeの値は0の値を意味します。AI_Protocolの値0は、発信者がプロトコルを受け入れることを意味します。たとえば、発信者がUDPではなくTCPのみを処理する場合、getaddrinfo（）が呼び出された場合、ヒント構造のAI_SOCKTYPEメンバーはSOCK_STREAMに設定する必要があります。発信者がIPv4のみをIPv6ではなく処理する場合、getaddrinfo（）が呼び出された場合、ヒント構造のAI_FamilyメンバーをPF_INETに設定する必要があります。getaddrinfo（）に対する3番目の引数がヌルポインターである場合、これは、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構造を処理できます。返された各addRinfo構造において、3人のメンバーAI_Family、AI_SOCKTYPE、およびAI_Protocolは、Socket（）関数への呼び出しの対応する引数です。各addRinfo構造では、AI_ADDRメンバーがAI_ADDRLENメンバーによって指定されている長さが記入されたソケットアドレス構造を指します。
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メンバーに設定されている場合、発信者はbind（）の呼び出しで返されたソケットアドレス構造を使用する予定です。この場合、nodename引数がnullポインターである場合、ソケットアドレス構造のIPアドレス部分は、IPv4アドレスの場合は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メンバーに設定されていない場合、返されたソケットアドレス構造は、接続指向のプロトコルの場合（）connect（）またはconnect（）、send（）、connect（）の呼び出しの準備ができています。またはsendmsg（）（Connectionless Protocolの場合）。この場合、nodename引数が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メンバーは、指定されたノデナメの正規名を含むヌル終端文字列を指します。
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メンバーに設定されている場合、非ヌルnodename文字列は数値ホストアドレス文字列でなければなりません。それ以外の場合、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>
void freeaddrinfo(struct 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.
AI引数によって指されたAddRinfo構造は、構造によって指された動的ストレージとともに解放されます。この操作は、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>
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値の1つであり、リターン値はエラーを説明する文字列を指します。引数がEAI_XXX値の1つではない場合、関数は、内容が不明な誤差を示す文字列へのポインターを返します。
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.1g仕様には、getaddrinfo（）からの逆変換を実行する機能が含まれていません。したがって、次の関数を定義します。
#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 struct sockaddr *sa、socklen_t salen、char *host、size_t hostlen、char *serv、size_t servlen、int flags）;
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アドレスとポート番号を保持するSockaddr_in構造（IPv4の場合）またはSockaddr_in6構造（IPv6用）を指しています。Salen引数は、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>:
残念ながら、ほとんどのシステムは、完全に資格のあるドメイン名またはサービス名のいずれかの最大サイズを指定する定数を提供しません。したがって、これらの2つの戻りの文字列にバッファーを割り当てるのにアプリケーションを支援するために、次の定数は<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のnodename部分のみがローカルホストに対して返されます。
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が設定されている場合、その名前の代わりに、サービスアドレスの数値形式が返されます（ポート番号など）。多くのコマンドが提供する「-N」フラグをサポートするには、2つのNi_Numericxxxフラグが必要です。
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.
5番目のフラグビット、Ni_dgramは、サービスがDatagramサービスであることを指定し、getservbyport（）がデフォルトの「TCP」の代わりに「UDP」の2番目の引数で呼び出されます。これは、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フラグは、<NetDB.H>で定義され、getAddrinfo（）で既に定義されているAI_XXXフラグが定義されています。
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>
int inet_pton(int af, const char *src, void *dst);
const char *inet_ntop(int af, const void *src,
char *dst, size_t size);
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引数は、関数が数値アドレスを格納するバッファーを指します。アドレスはネットワークバイトの順序で返されます。INET_PTON（）は、変換が成功した場合に1、入力が有効なIPv4ドットドシマル文字列または有効なIPv6アドレス文字列である場合は0、またはAF引数が不明の場合はERRNOをeAfNoSupportに設定した-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.
ここで、DDDは0〜255の間の1〜3桁の小数点数です。既存のINET_ADDR（）およびINET_ATON（）関数の多くの実装は、標準以外の入力を受け入れることに注意してください：オクタル数、16進数、および4つの数値未満。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テキストフォームの1つの文字列を受け入れます[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です。SRC引数は、AF引数がAF_INETの場合はIPv4アドレスを保持しているバッファーを指します。AF引数がAF_INET6の場合、IPv6アドレスを指します。アドレスはネットワークバイトの順序でなければなりません。DST引数は、関数が結果のテキスト文字列を保存するバッファーを指します。サイズ引数は、このバッファのサイズを指定します。アプリケーションは、非ヌル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です。障害時に、AF引数が無効である場合、ERRNOは、結果バッファーのサイズが不十分な場合はENOSPCの場合、EafnoSupportに設定されます。
The following macros can be used to test for special IPv6 addresses.
次のマクロを使用して、特別なIPv6アドレスをテストできます。
#include <netinet/in.h>
int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *);
int IN6_IS_ADDR_MULTICAST (const struct in6_addr *);
int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *);
int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *);
int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *);
int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);
int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);
The first seven macros return true if the address is of the specified type, or false otherwise. The last five test the scope of a multicast address and return true if the address is a multicast address of the specified scope or false if the address is either not a multicast address or not of the specified scope. 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.
最初の7つのマクロは、アドレスが指定されたタイプの場合、またはそれ以外の場合はfalseの場合にtrueを返します。最後の5つのテストマルチキャストアドレスの範囲をテストし、アドレスが指定されたスコープのマルチキャストアドレスである場合、またはアドレスが指定されたスコープのマルチキャストアドレスではない場合はfalseの場合はtrueを返します。IN6_IS_ADDR_LINKLOCALおよびIN6_IS_ADDR_SITELOCALは、2つのローカル使用IPv6ユニキャストアドレスに対してのみTrueを返すことに注意してください。これらの2つのマクロは、Link-Local ScopeまたはSite-Local ScopeのいずれかのIPv6マルチキャストアドレスに対して真実ではありません。
The following list summarizes the constants, structure, and extern definitions discussed in this memo, sorted by header.
次のリストは、このメモで説明されている定数、構造、および外部定義を、ヘッダーでソートしたものをまとめたものです。
<net/if.h> IF_NAMESIZE
<net/if.h> struct if_nameindex{};
<netdb.h> AI_ADDRCONFIG
<netdb.h> AI_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{};
<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;
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ドキュメントとの一貫性を得るために、すべての「ホスト名」を「nodename」に変更しました。
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のコメントを「トラフィッククラスとフロー情報」に変更し、これら2つのフィールドの現在の定義に対応するテキストの説明を更新しました。
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_ADDRDRCONFIGに変更し、レコードとIPv4アドレスについても定義します。名前の引数が数値アドレス文字列である場合、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（）に変更します。項目2と3は、発行するDNSクエリのタイプを指定する代わりに、特定のアドレスの「名前を表示」するIPv4マップとIPv4-互換アドレスを処理する方法の説明で説明します。
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：<netdb.h>：ai_addrconfig、ai_all、およびai_v4mappのために、次の定数をリストに追加しました。Union Sockaddr_unionとSa_lenを<sys/socket.h>のリストに追加します。
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.1g標準のドラフト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のデータ型は「in_port_t」に変更され、sin6_flowinfoのデータ型は「uint32_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 *」に変更され、2番目の引数は「int」から「size_t」に変更されました。
Section 6.4: second argument of getnameinfo() changed from "size_t" to "socklen_t".
セクション6.4：getnameInfo（）の2番目の引数は、「size_t」から「socklen_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：gethostbyname2（）とそれに関連するres_use_inet6オプションの説明を削除し、gethostbyname3（）に置き換えました。
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 MACROSに関する説明を追加しました。
Changes made to the draft -01 specification Sept 98
ドラフト-01仕様9月98日に変更された変更
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.
セクション3.3および3.4にstruct sockaddr_in6にsin6_scope_idを追加しました。
Changed 3.10 to use generic storage structure to support holding IPv6 addresses and removed the SA_LEN macro.
3.10を変更して、一般的なストレージ構造を使用してIPv6アドレスの保持をサポートし、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 and Dropに名前をJoin and Dropに変更しました。
Changed getnodebyname to getipnodebyname, getnodebyaddr to getipnodebyaddr, and added MT safe error code to function parameters in section 6.
getNodeByNameをgetIpNodeByNameに変更し、getNodeByAddrにgetIpNodeByAddrに変更し、セクション6の機能パラメーターにMTセーフエラーコードを追加しました。
Moved freehostent to its own sub-section after getipnodebyaddr now 6.3 (so this bumps all remaining sections in section 6.
Getipnodebyaddr 6.3の後、フリーホステントを独自のサブセクションに移動しました（したがって、これはセクション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パラメーターに依存しており、セクション6.1の接続詞として使用する必要があることをAI_ALLおよびAI_V4Mappedの使用を明確にしました。
Removed the restriction that literal addresses cannot be used with a flags argument in section 6.1.
セクション6.1のフラグ引数では、文字通りのアドレスを使用できないという制限を削除しました。
Added Year 2000 Section to the draft 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ディレクトリから削除され、有効期限が切れているため、ドラフトドラフトに2000年のセクションが削除された参照を削除しました。しかし、前述のドラフトからのロジックは依然として適用されているため、3番目の段落の後にセクション6.2の弾丸に保持されていました。
[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、「IPv6のカプセル化されたIPv4アドレスのリバースネームルックアップ」、Internet-Draft、<draft-vixie-ipng-ipv4ptr-00.txt>、1996年5月。
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.マクドナルド、「BSDソケットへの単純なIPセキュリティAPI拡張」、インターネットドラフト、<Draft-McDonald-Simple-IPSEC-API-01.TXT>、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. Metz、「ソケットのネットワークセキュリティ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（）で使用する場合、 "::" and ":: 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, 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".
Werner Almesberger、Ran Atkinson、Fred Baker、Dave Borman、Andrew Cherenson、Alex Conta、Alan Cox、Steve Deering、Richard Draves、Francis Dupont、Robert Elz、Ran Atkinson、Fred Baker、Dave Borman、Ran Atkinson、Fred Baker、Dave Borman、Ran Atkinson、Ran Atkinson、Fred Baker、Dave Borman、Ran Atkinson、Ran Atkinson、Fred Baker、Andrew Cherensonなど、多くの人々に感謝します。マーク・ハッソン、トム・ハーバート、ボブ・ヒンデン、ワン・ヘン・フスー、クリスチャン・フイテマ、コジ・イマーダ、マルクス・ジョーク、ロン・リー、アラン・ロイド、チャールズ・リン、ダン・マクドナルド、デイブ・ミットン、トーマス・ナーテン、ジョシュ・オズボーン、クレイグ・パートリッジ、リッチャー、エリック・スコアドス、キース・スキロワー、マット・トーマス、ハーヴェイ・トンプソン、ディーン・D・スループ、カレン・トレーシー、グレン・トレウィット、ポール・ビクシー、デビッド・ウェイツマン、カール・ウィリアムズ、ヤモモト、getaddrinfo（）およびgetnameinfo（）の作品はKeith Sklowerによる以前のインターネットドラフト。そのドラフトで述べたように、ウィリアム・ダースト、スティーブン・ワイズ、マイケル・カレル、およびエリック・オールマンは、プロトコルに依存しない名前からアドレスへの翻訳の主題について多くの有用な議論を提供し、キース・スクラワーの元の提案の初期バージョンをレビューしました。Eric Allmanは、getaddrinfo（）の最初のプロトタイプを実装しました。名前とサービスのペアを指定するだけで十分であるという観察は、プロトコルの詳細とは独立したサービスに接続するのに十分であるという観察は、「均一なネットワークインターフェイス」のX/Openの提案でMarshall Roseによって行われました。
Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh Kacker made many contributions to this document. Ramesh Govindan made a number of contributions and co-authored an earlier version of this memo.
クレイグ・メッツ、ジャック・マッキャン、エリック・ノードマーク、ティム・ハートリック、ムケシュ・カッカーは、この文書に多くの貢献をしました。Ramesh Govindanは多くの貢献をし、このメモの以前のバージョンを共著しました。
References
参考文献
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[1] Deering、S。and 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。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[3] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT 6.6, March 1997.
[3] IEEE、「プロトコル独立インターフェイス」、IEEE STD 1003.1G、ドラフト6.6、1997年3月。
[4] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC 2292, February 1998.
[4] Stevens、W。およびM. Thomas、「IPv6のAdvanced Sockets API」、RFC 2292、1998年2月。
Authors' Addresses
著者のアドレス
Robert E. Gilligan FreeGate Corporation 1208 E. Arques Ave. Sunnyvale, CA 94086
ロバートE.ギリガンフリーゲートコーポレーション1208 E.アルケスアベニュー、サニーベール、カリフォルニア94086
Phone: +1 408 617 1004
EMail: gilligan@freegate.com
Susan Thomson Bell Communications Research MRE 2P-343, 445 South Street Morristown, NJ 07960
スーザントムソンベルコミュニケーションリサーチMRE 2P-343、445サウスストリートモリスタウン、ニュージャージー07960
Phone: +1 201 829 4514
EMail: set@thumper.bellcore.com
Jim Bound Compaq Computer Corporation 110 Spitbrook Road ZK3-3/U14 Nashua, NH 03062-2698
ジムバウンドコンパックコンピューターコーポレーション110スピットブルックロードZK3-3/U14ナシュア、NH 03062-2698
Phone: +1 603 884 0400
EMail: bound@zk3.dec.com
W. Richard Stevens 1202 E. Paseo del Zorro Tucson, AZ 85718-2826
W.リチャードスティーブンス1202 E. Paseo del Zorro Tucson、AZ 85718-2826
Phone: +1 520 297 9416
EMail: rstevens@kohala.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。