この文書はRFC3493の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                        R. Gilligan
Request for Comments: 3493                                Intransa, Inc.
Obsoletes: 2553                                               S. Thomson
Category: Informational                                            Cisco
                                                                J. Bound
                                                               J. McCann
                                                         Hewlett-Packard
                                                              W. Stevens
                                                           February 2003


               Basic Socket Interface Extensions for IPv6
            IPv6のための基本ソケットインターフェース拡張


Status of this Memo
この文書の状態


   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.
   このメモはインターネット共同体のための情報を供給します。これはイン
   ターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice
著作権表示

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract
概要

   The de facto standard Application Program Interface (API) for TCP/IP
   applications is the "sockets" interface.  Although this API was
   developed for Unix in the early 1980s it has also been implemented on
   a wide variety of non-Unix systems.  TCP/IP applications written
   using the sockets API have in the past enjoyed a high degree of
   portability and we would like the same portability with IPv6
   applications.  But changes are required to the sockets API to support
   IPv6 and this memo describes these changes.  These include a new
   socket address structure to carry IPv6 addresses, new address
   conversion functions, and some new socket options.  These extensions
   are designed to provide access to the basic IPv6 features required by
   TCP and UDP applications, including multicasting, while introducing a
   minimum of change into the system and providing complete
   compatibility for existing IPv4 applications.  Additional extensions
   for advanced IPv6 features (raw sockets and access to the IPv6
   extension headers) are defined in another document.
   TCP/IPアプリケーションのためのデファクトの標準アプリケーション
   プログラムインタフェース(API)は「ソケット」インタフェースです。
   このAPIが1980年代初期にUNIXのために開発されたけれども、多
   種多様な非UNIXのシステム上に実装されました。ソケットAPIを使っ
   て書かれたTCP/IPアプリケーションが過去に高度のポータビリティを
   享受しました、そして我々はIPv6アプリケーションで同じポータビリ
   ティを欲します。けれどもIPv6をサポートするのにソケットAPIの変
   更が要求され、そしてこのメモはこれらの変更を記述します。これらはIP
   v6アドレス、新しいアドレス変換機能とある新しいソケットオプションを
   伴うための新しいソケットアドレス構造を含みます。これらの拡張は、既存
   のIPv4アプリケーションに完全な互換性を提供したまま、導入のための
   変更を最小限に抑えて、TCPとUDPアプリケーションに必要な基本的な
   IPv6機能へのアクセスを供給するよう意図されます。高等IPv6機能
   のための追加の拡張(生ソケットとIPv6拡張ヘッダーへのアクセス)が
   他の文書で定義されます。


Table of Contents
目次


   1.  Introduction
   1.  はじめに
   2.  Design Considerations
   2.  デザイン考察
       2.1  What Needs to be Changed
       2.1  どのような変更が必要か
       2.2  Data Types
       2.2  データタイプ
       2.3  Headers
       2.3  ヘッダ
       2.4  Structures
       2.4  構造体
   3.  Socket Interface
   3.  ソケットインタフェース
       3.1  IPv6 Address Family and Protocol Family
       3.1  IPv6 アドレスファミリとプロトコルファミリ
       3.2  IPv6 Address Structure
       3.2  IPv6アドレス構造体
       3.3  Socket Address Structure for 4.3BSD-Based Systems
       3.3  4.3BSDベースシステムのソケットアドレス構造体
       3.4  Socket Address Structure for 4.4BSD-Based Systems
       3.4  4.4BSDベースシステムのソケットアドレス構造体
       3.5  The Socket Functions
       3.5  ソケット関数
       3.6  Compatibility with IPv4 Applications
       3.6  IPv4アプリケーションとの互換性
       3.7  Compatibility with IPv4 Nodes
       3.7  IPv4ノードとの互換性
       3.8  IPv6 Wildcard Address
       3.8  IPv6ワイルドカードアドレス
       3.9  IPv6 Loopback Address
       3.9  IPv6ループバックアドレス
       3.10 Portability Additions
       3.10 ポータビリティ追加
   4.  Interface Identification
   4.  インタフェース識別子
       4.1  Name-to-Index
       4.1  Name-to-Index
       4.2  Index-to-Name
       4.2  Index-to-Name
       4.3  Return All Interface Names and Indexes
       4.3  全インタフェース名とインデックスを返す
       4.4  Free Memory
       4.4  メモリ開放
   5.  Socket Options
   5.  ソケットオプション
       5.1  Unicast Hop Limit
       5.1  ユニキャストホップ限界
       5.2  Sending and Receiving Multicast Packets
       5.2  マルチキャストパケットの送受信
       5.3  IPV6_V6ONLY option for AF_INET6 Sockets
       5.3  AF_INET6ソケットのIPV6_V6ONLYオプション
   6.  Library Functions
   6.  ライブラリ関数
       6.1  Protocol-Independent Nodename and
            Service Name Translation
       6.1  プロトコルに依存しないノード名とサービス名翻訳
       6.2  Socket Address Structure to Node Name
            and  Service Name
       6.2  ノード名とサービス名へのソケットアドレス構造体
       6.3  Address Conversion Functions
       6.3  アドレス変換関数
       6.4  Address Testing Macros
       6.4  アドレステストマクロ
   7.  Summary of New Definitions
   7.  新しい定義の要約
   8.  Security Considerations
   8.  セキュリティの考察
   9.  Changes from RFC 2553
   9.  RFC2553からの変更
   10. Acknowledgments
   10. 謝辞
   11. References
   11. 参考文献
   12. Authors' Addresses
   12. 著者のアドレス
   13. Full Copyright Statement
   13. 著作権表示全文


1. Introduction
1. はじめに

   While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits
   long.  The socket interface makes the size of an IP address quite
   visible to an application; virtually all TCP/IP applications for
   BSD-based systems have knowledge of the size of an IP address.  Those
   parts of the API that expose the addresses must be changed to
   accommodate the larger IPv6 address size.  IPv6 also introduces new
   features, some of which must be made visible to applications via the
   API.  This memo defines a set of extensions to the socket interface
   to support the larger address size and new features of IPv6.  It
   defines "basic" extensions that are of use to a broad range of
   applications.  A companion document, the "advanced" API [4], covers
   extensions that are of use to more specialized applications, examples
   of which include routing daemons, and the "ping" and "traceroute"
   utilities.
   IPv4アドレスが長さが32ビットであるが、IPv6インタフェースが
   128ビットのアドレスです。ソケットインタフェースはIPアドレスの大
   きさをアプリケーションにはっきり見せます;ほとんどすべてのTCP/B
   SDベースのシステムのIPアプリケーションがIPアドレスの大きさの知
   識を持っています。アドレスを露出するAPIのそれらの部分がより大きい
   IPv6アドレス大きさを収容するために変えなくてはなりません。IPv6
   が新しい機能を導入します、そしてそのいくつかはAPIによってアプリケー
   ションに見えなくてはなりません。このメモはより大きいアドレスサイズと
   IPv6の新しい機能をサポートするためのソケットインタフェースへの拡
   張を定義します。これは広い範囲のアプリケーションに役に立つ「基本」拡
   張を定義します。関連文書、「高等」API[4]が、例えばルーティングデー
   モンや「ping」と「traceroute」ユーティリティーを含む、
   より専門的アプリケーションに役つ拡張をカバーします。

   The development of this API was started in 1994 in the IETF IPng
   working group.  The API has evolved over the years, published first
   in RFC 2133, then again in RFC 2553, and reaching its final form in
   this document.
   このAPIの開発はIETFのIPngワーキンググループで1994年に
   始められました。APIは数年間かけて進展し、RFC2133で最初に、
   そしてRFC2553で再び発表され、そしてこの文書で最終形式になりま
   した。

   As the API matured and stabilized, it was incorporated into the Open
   Group's Networking Services (XNS) specification, issue 5.2, which was
   subsequently incorporated into a joint Open Group/IEEE/ISO standard
   [3].
   APIが成熟し安定したので、こはオープングループのネットワーキングサー
   ビス(XNS)仕様書、5.2版、に取り入れられ、その後共同オープングルー
   プ/IEEE/ISO標準[3]に取り入れられました。

   Effort has been made to ensure that this document and [3] contain the
   same information with regard to the API definitions.  However, the
   reader should note that this document is for informational purposes
   only, and that the official standard specification of the sockets API
   is [3].
   この文書と[3]がAPI定義に関して同じ情報を含んでいることを保証するた
   めの取り組みがされました。しかしながら、読者はこの文書が情報的な目的
   のみのためであるり、そしてソケットAPIの公式標準仕様書が[3]であるこ
   とを指摘するべきです。

   It is expected that any future standardization work on this API would
   be done by the Open Group Base Working Group [6].
   このAPIの未来の標準化の仕事がオープングループベースワーキンググルー
   プ[6]によってされるであろうと思われます。

   It should also be noted that this document describes only those
   portions of the API needed for IPv4 and IPv6 communications.  Other
   potential uses of the API, for example the use of getaddrinfo() and
   getnameinfo() with the AF_UNIX address family, are beyond the scope
   of this document.
   この文書がただIPv4とIPv6通信に必要とされるAPIの部分だけを
   記述することは同じく指摘されるべきです。APIの他の可能性がある使用、
   例えばAF_UNIXアドレスファミリのgetaddrinfo()とgetnameinfo()はこの文書
   の範囲外です。

2. Design Considerations
2. デザイン考察

   There are a number of important considerations in designing changes
   to this well-worn API:
   この使い古されたAPIに対する変更を設計する際に多くの重要な考慮点が
   あります:

   -  The API changes should provide both source and binary
      compatibility for programs written to the original API.  That is,
      existing program binaries should continue to operate when run on a
      system supporting the new API.  In addition, existing applications
      that are re-compiled and run on a system supporting the new API
      should continue to operate.  Simply put, the API changes for IPv6
      should not break existing programs.  An additional mechanism for
      implementations to verify this is to verify the new symbols are
      protected by Feature Test Macros as described in [3].  (Such
      Feature Test Macros are not defined by this RFC.)
   -  APIの変更はオリジナルのAPIで書かれたプログラムに対してソース
      レベルとバイナリレベルの両方の互換性を提供するべきです。すなわち、
      既存のバイナリプログラムを新しいAPIをサポートしているシステム上
      で動かす時、動くべきです。加えて、再コンパイルされた既存のアプリケー
      ションを新しいAPIをサポートしているシステムで動き続けるべきです。
      単純言うと、APIの変更は既存のプログラムを壊すべきではありません。
      実装の検証のための追加メカニズムが[3]で記述される機能試験マクロで、
      新しいシンボルが保護されるか検証します。(このような機能テストマク
      ロはこのRFCで定義されません。)

   -  The changes to the API should be as small as possible in order to
      simplify the task of converting existing IPv4 applications to
      IPv6.
   -  APIの変更は既存のIPv4アプリケーションをIPv6対応に変換す
      る仕事を単純化するため、可能な限り少なくするべきです。

   -  Where possible, applications should be able to use this API to
      interoperate with both IPv6 and IPv4 hosts.  Applications should
      not need to know which type of host they are communicating with.
   -  可能な場合は、アプリケーションがIPv6ホストとIPv4ホストの両
      方と通信するのにこのAPIをえるべきです。アプリケーションがどのタ
      イプのホストと通信しているか知る必要があるべきではありません。

   -  IPv6 addresses carried in data structures should be 64-bit
      aligned.  This is necessary in order to obtain optimum performance
      on 64-bit machine architectures.
   -  データ構造体で運ばれたIPv6アドレスが64ビット整列であるべきで
      す。これは64ビットのマシンアーキテクチャ上で最適なパフォーマンス
      を得るために必要です。

   Because of the importance of providing IPv4 compatibility in the API,
   these extensions are explicitly designed to operate on machines that
   provide complete support for both IPv4 and IPv6.  A subset of this
   API could probably be designed for operation on systems that support
   only IPv6.  However, this is not addressed in this memo.
   APIがIPv4互換性を供給する重要性のため、これらの拡張は明示的に
   IPv4とIPv6両方に対する完全なサポートを供給するマシン上に働く
   よう意図されます。IPv6だけをサポートするシステムのオペレーション
   のために、このAPIのサブセットが多分設計できます。しかし、これはこ
   のメモで扱われません。

2.1 What Needs to be Changed
2.1 どのような変更が必要か

   The socket interface API consists of a few distinct components:
   ソケットインタフェースAPIは以下の異なる要素から成り立ちます:

   -  Core socket functions.
   -  コアソケット機能。

   -  Address data structures.
   -  アドレスデータ構造体。

   -  Name-to-address translation functions.
   -  名前からアドレスへの翻訳関数。

   -  Address conversion functions.
   -  アドレス変換関数。

   The core socket functions -- those functions that deal with such
   things as setting up and tearing down TCP connections, and sending
   and receiving UDP packets -- were designed to be transport
   independent.  Where protocol addresses are passed as function
   arguments, they are carried via opaque pointers.  A protocol-specific
   address data structure is defined for each protocol that the socket
   functions support.  Applications must cast pointers to these
   protocol-specific address structures into pointers to the generic
   "sockaddr" address structure when using the socket functions.  These
   functions need not change for IPv6, but a new IPv6-specific address
   data structure is needed.
   コアソケット関数−TCP接続の設定と削除や、UDPパケットの送信と受
   信を扱う関数−はトランスポートに依存しないよう設計されました。プロト
   コルアドレスが関数の引数として渡されるところで、それらは不透明なポイ
   ンタで運ばれます。プロトコル特定のアドレスデータ構造体がソケット関数
   がサポートするそれぞれのプロトコルのために定義されます。アプリケーショ
   ンがソケット関数を使う時、これらのプロトコル特定のアドレス構造体への
   ポインタは一般的な「sockaddr」アドレス構造体へのポインタにキャストし
   なければなりません。これらの関数はIPv6で変更不要ですが、新しいI
   Pv6特定のアドレスデータ構造体が必要です。

   The "sockaddr_in" structure is the protocol-specific data structure
   for IPv4.  This data structure actually includes 8-octets of unused
   space, and it is tempting to try to use this space to adapt the
   sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
   structure is not large enough to hold the 16-octet IPv6 address as
   well as the other information (address family and port number) that
   is needed.  So a new address data structure must be defined for IPv6.
   「sockaddr_in」構造体はIPv4プロトコル特有のデータ構造体です。この
   データ構造体は実際は未使用の8オクテットスペースを含み、sockaddr_in構
   造体をIPv6に適合させるのにこのスペースを使う誘惑があります。不幸
   にもsockaddr_in構造体は16オクテットのIPv6アドレスと他に必要な情
   報を保持できるほど十分大きくありません。それで新しいアドレスデータ構
   造体がIPv6のために定義されなくてはなりません。

   IPv6 addresses are scoped [2] so they could be link-local, site,
   organization, global, or other scopes at this time undefined.  To
   support applications that want to be able to identify a set of
   interfaces for a specific scope, the IPv6 sockaddr_in structure must
   support a field that can be used by an implementation to identify a
   set of interfaces identifying the scope for an IPv6 address.
   IPv6アドレスは範囲[2]を持ち、それはリンクローカルかサイトか組織か
   グローバルか、現在は不確定な範囲です。特定の範囲のインタフェースを識
   別可能であることを望むアプリケーションをサポートするために、IPv6
   のsockaddr_in構造体はIPv6アドレスの範囲を示すインタフェース集合を
   識別するために実装が使えるフィールドをサポートしなくてはなりません。

   The IPv4 name-to-address translation functions in the socket
   interface are gethostbyname() and gethostbyaddr().  These are left as
   is, and new functions are defined which support both IPv4 and IPv6.
   IPv4のソケットインタフェースでの名前からアドレスへの翻訳関数は
   gethostbyname()とgethostbyaddr()です。これらはそのままで、IPv4と
   IPv6の両方をサポートするために新しい関数が定義されます。

   The IPv4 address conversion functions -- inet_ntoa() and inet_addr()
   -- convert IPv4 addresses between binary and printable form.  These
   functions are quite specific to 32-bit IPv4 addresses.  We have
   designed two analogous functions that convert both IPv4 and IPv6
   addresses, and carry an address type parameter so that they can be
   extended to other protocol families as well.
   IPv4アドレス変換関数−inet_ntoa()とinet_addr()−はIPv4アドレ
   スのバイナリと印刷可能な形の間の変換をします。これらの関数は32ビッ
   トのIPv4アドレスに非常に特有です。我々はIPv4とIPv6アドレ
   スの両方を変換し、それらが同様に他のプロトコルファミリーにも拡張でき
   るように、アドレスタイプパラメータを伴う2つの類似した関数を設計しま
   した。

   Finally, a few miscellaneous features are needed to support IPv6.  A
   new interface is needed to support the IPv6 hop limit header field.
   New socket options are needed to control the sending and receiving of
   IPv6 multicast packets.
   最終的に、少数の雑多な機能がIPv6をサポートするために必要です。新
   しいインタフェースがIPv6ホップ限界ヘッダーフィールドをサポートす
   るために必要です。新しいソケットオプションがIPv6マルチキャストパ
   ケットの送受信を制御するために必要です。

   The socket interface will be enhanced in the future to provide access
   to other IPv6 features.  Some of these extensions are described in
   [4].
   ソケットインタフェースは他のIPv6機能へのアクセスを供給するために
   将来拡張されるでしょう。いくつかの拡張は[4]で記述されます。

2.2 Data Types
2.2 データタイプ

   The data types of the structure elements given in this memo are
   intended to track the relevant standards.  uintN_t means an unsigned
   integer of exactly N bits (e.g., uint16_t).  The sa_family_t and
   in_port_t types are defined in [3].
   このメモで与えられた構造体要素のデータタイプは適切な標準を追跡するよ
   うに意図されます。uintN_tが正確にNビットの符号なしの整数を意味します
   (例えば、uint16_t)。sa_family_tとin_port_tタイプは[3]で定義されます。

2.3 Headers
2.3 ヘッダ

   When function prototypes and structures are shown we show the headers
   that must be #included to cause that item to be defined.
   関数の原型と構造体を示すとき、項目を定義するため#includeするヘッダを示
   します。 

2.4 Structures
2.4 構造体

   When structures are described the members shown are the ones that
   must appear in an implementation.  Additional, nonstandard members
   may also be defined by an implementation.  As an additional
   precaution nonstandard members could be verified by Feature Test
   Macros as described in [3].  (Such Feature Test Macros are not
   defined by this RFC.)
   構造体を示す場合、記述したメンバは実装で存在しなければならないもので
   す。追加の非標準メンバが実装で定義されるかもしれません。追加の用心と
   して、[3]で記述されように、機能テストマクロで非標準メンバーを検査でき
   ます(こうした機能テストマクロはこのRFCで定義しません)。 

   The ordering shown for the members of a structure is the recommended
   ordering, given alignment considerations of multibyte members, but an
   implementation may order the members differently.
   構造体のメンバが表れる順序は、マルチバイトメンバーの整列を考慮した推
   奨された順序です。しかし、実装はメンバを異なる順序にしてもかまいませ
   ん。 

3. Socket Interface
3. ソケットインタフェース

   This section specifies the socket interface changes for IPv6.
   この章はIPv6のためにソケットインタフェース変更を指定します。

3.1 IPv6 Address Family and Protocol Family
3.1 IPv6 アドレスファミリとプロトコルファミリ

   A new address family name, AF_INET6, is defined in <sys/socket.h>.
   The AF_INET6 definition distinguishes between the original
   sockaddr_in address data structure, and the new sockaddr_in6 data
   structure.
   新しいアドレスファミリ名AF_INET6が、<sys/socket.h>で定義されます。
   AF_INET6の定義は、元のsockaddr_inアドレスデータ構造体と新規の
   sockaddr_in6データ構造体とを区別します。

   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
   Like most of the other protocol family names, this will usually be
   defined to have the same value as the corresponding address family
   name:
   新しいプロトコルファミリ名PF_INET6が<sys/socket.h>で定義されます。他
   のプロトコルファミリ名の多くと同じく、これは通常対応するアドレスファ
   ミリと同じ値を持ように定義されるでしょう:

      #define PF_INET6        AF_INET6

   The AF_INET6 is used in the first argument to the socket() function
   to indicate that an IPv6 socket is being created.
   PF_INET6はsocket()関数の最初の引数で使われ、IPv6ソケットの生成
   を示します。

3.2 IPv6 Address Structure
3.2 IPv6アドレス構造体

   A new in6_addr structure holds a single IPv6 address and is defined
   as a result of including <netinet/in.h>:
   新規のin6_addr構造体がひとつのIPv6アドレスを保持し、
   <netinet/in.h>で定義されます:

      struct in6_addr {
          uint8_t  s6_addr[16];      /* IPv6 address */
      };

   This data structure contains an array of sixteen 8-bit elements,
   which make up one 128-bit IPv6 address.  The IPv6 address is stored
   in network byte order.
   このデータ構造は16個の8ビット要素の配列で、1つの128ビットのI
   Pv6アドレスを示します。IPv6アドレスはネットワークバイト順に設
   定されます。

   The structure in6_addr above is usually implemented with an embedded
   union with extra fields that force the desired alignment level in a
   manner similar to BSD implementations of "struct in_addr".  Those
   additional implementation details are omitted here for simplicity.
   上記in6_addr構造体は通常通ましい整列レベルを強制する余分のフィールド
   込みの共用体で、"in_addr構造体"のBSD実装に似た方法で実装されます。
   これらの追加の実装の細部は単純さのためにここでは省略します。 

   An example is as follows:
   以下に例を示します:

   struct in6_addr {
        union {
            uint8_t  _S6_u8[16];
            uint32_t _S6_u32[4];
            uint64_t _S6_u64[2];
        } _S6_un;
   };
   #define s6_addr _S6_un._S6_u8

3.3 Socket Address Structure for 4.3BSD-Based Systems
3.3 4.3BSDベースシステムのソケットアドレス構造体

   In the socket interface, a different protocol-specific data structure
   is defined to carry the addresses for each protocol suite.  Each
   protocol-specific data structure is designed so it can be cast into a
   protocol-independent data structure -- the "sockaddr" structure.
   Each has a "family" field that overlays the "sa_family" of the
   sockaddr data structure.  This field identifies the type of the data
   structure.
   ソケットインタフェースで、異なるプロトコル特有のデータ構造体が各プロ
   トコルのアドレスを運ぶため定義されます。各プロトコル特有データ構造体
   は、プロトコルに依存しないデータ構造体である"sockaddr"構造体にキャス
   トできるよう設計されています。それぞれは"family" フィールドを持ち、
   sockaddrデータ構造体の"sa_family"を上書きします。このフィールドはデー
   タ構造体の型を識別します。 

   The sockaddr_in structure is the protocol-specific address data
   structure for IPv4.  It is used to pass addresses between
   applications and the system in the socket functions.  The following
   sockaddr_in6 structure holds IPv6 addresses and is defined as a
   result of including the <netinet/in.h> header:
   sockaddr_in構造体はIPv4プロトコル特有のアドレスデータ構造体です。
   これはソケット関数でアプリケーションとシステムの間にアドレスを渡すた
   めに使われます。次のsockaddr_in6構造体はIPv6アドレスを持ち、
   <netinet/in.h>で定義されます:。

struct sockaddr_in6 {
    sa_family_t     sin6_family;    /* AF_INET6 */
                                    /* AF_INET6 */
    in_port_t       sin6_port;      /* transport layer port # */
                                    /* トランスポートレイヤ番号 */
    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
                                    /* IPv6フロー情報 */
    struct in6_addr sin6_addr;      /* IPv6 address */
                                    /* IPv6アドレス */
    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
                                    /* 範囲に対するインターフェース */
};

   This structure is designed to be compatible with the sockaddr data
   structure used in the 4.3BSD release.
   この構造体は 4.3BSDリリースで使われたsockaddrデータ構造体と両立でき
   るよう意図されます。

   The sin6_family field identifies this as a sockaddr_in6 structure.
   This field overlays the sa_family field when the buffer is cast to a
   sockaddr data structure.  The value of this field must be AF_INET6.
   sin6_family フィールドはsockaddr_in6構造体を識別します。バッファを
   sockaddrデータ構造体にキャストする時、このフィールドはsa_familyフィー
   ルドを上書きします。このフィールドの値はAF_INET6であるに違いありま
   せん。

   The sin6_port field contains the 16-bit UDP or TCP port number.  This
   field is used in the same way as the sin_port field of the
   sockaddr_in structure.  The port number is stored in network byte
   order.
   sin6_port フィールドは16ビットのUDPかTCPポート番号を含んでい
   ます。このフィールドはsockaddr_in構造体のsin_portフィールドと同じよう
   に使われます。ポート番号はネットワークバイト順で設定されます。

   The sin6_flowinfo field is a 32-bit field intended to contain flow-
   related information.  The exact way this field is mapped to or from a
   packet is not currently specified.  Until such time as its use is
   specified, applications should set this field to zero when
   constructing a sockaddr_in6, and ignore this field in a sockaddr_in6
   structure constructed by the system.
   sin6_flowinfoフィールドはフロー関連の情報を含むように意図される32ビッ
   トのフィールドです。このフィールドがパケットに、あるいはパケットから
   マップされる正確な方法は現在指定されません。その使用法が指定される時
   まで、アプリケーションがsockaddr_in6を組み立てる時、このフィールドを
   ゼロに設定して、そしてシステムによって構築されたsockaddr_in6構造体で
   のこのフィールドを無視するべきです。

   The sin6_addr field is a single in6_addr structure (defined in the
   previous section).  This field holds one 128-bit IPv6 address.  The
   address is stored in network byte order.
   sin6_addrフィールドは(前の章で定義された)ひとつのin6_addr構造体です。
   このフィールドは1つの128ビットIPv6アドレスを持ちます。アドレ
   スはネットワークバイト順に設定されます。

   The ordering of elements in this structure is specifically designed
   so that when sin6_addr field is aligned on a 64-bit boundary, the
   start of the structure will also be aligned on a 64-bit boundary.
   This is done for optimum performance on 64-bit architectures.
   この構造体での要素の順序は、 sin6_addrフィールドが64ビットの境界上
   に並べられる時、構造体の開始が同じく64ビット境界になるように設計さ
   れます。これは64ビットアーキテクチャ上での最適なパフォーマンスのた
   めにされます。

   The sin6_scope_id field is a 32-bit integer that identifies a set of
   interfaces as appropriate for the scope [2] of the address carried in
   the sin6_addr field.  The mapping of sin6_scope_id to an interface or
   set of interfaces is left to implementation and future specifications
   on the subject of scoped addresses.
   sin6_scope_idフィールドはsin6_addrフィールドで運ばれたアドレスの範囲
   [2]に対応するインタフェース集合を識別する32ビット整数です。
   sin6_scope_idからインターフェースへの変換は実装依存で、範囲アドレスの
   問題は将来の仕様書に残されます。

   Notice that the sockaddr_in6 structure will normally be larger than
   the generic sockaddr structure.  On many existing implementations the
   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
   being 16 bytes.  Any existing code that makes this assumption needs
   to be examined carefully when converting to IPv6.
   sockaddr_in6構造体が通常一般的なsockaddr構造体よりも大きくなることに
   注意して下さい。多くの既存の実装で、sizeof(struct sockaddr_in)と
   sizeof(struct sockaddr)は等しく、両方16バイトです。これを想定して
   作成している既存のコードは、IPv6に移行する際、慎重に調べる必要が
   あります。 

3.4 Socket Address Structure for 4.4BSD-Based Systems
3.4 4.4BSDベースシステムのソケットアドレス構造体

   The 4.4BSD release includes a small, but incompatible change to the
   socket interface.  The "sa_family" field of the sockaddr data
   structure was changed from a 16-bit value to an 8-bit value, and the
   space saved used to hold a length field, named "sa_len".  The
   sockaddr_in6 data structure given in the previous section cannot be
   correctly cast into the newer sockaddr data structure.  For this
   reason, the following alternative IPv6 address data structure is
   provided to be used on systems based on 4.4BSD.  It is defined as a
   result of including the <netinet/in.h> header.
   4.4BSDリリースはソケットインタフェースに対する小さいが、互換性が
   ない変更を含みます。sockaddrデータ構造体の"sa_family"フィールドは16
   ビット値から8ビット値に変えられ、空いたスペースは"sa_len"という名前
   の長さフィールドになりました。前の章で示したsockaddr_in6データ構造体
   は新しいsockaddrデータ構造体に正しくキャストできません。この理由のた
   めに、次の代わりのIPv6アドレスデータ構造体が4.4BSDに基くシス
   テムで供給されます。これは<netinet/in.h>で定義されます。

struct sockaddr_in6 {
    uint8_t         sin6_len;       /* length of this struct */
                                    /* 構造体の長さ */
    sa_family_t     sin6_family;    /* AF_INET6 */
                                    /* AF_INET6 */
    in_port_t       sin6_port;      /* transport layer port # */
                                    /* トランスポート層のポート番号 */
    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
                                    /* IPv6フロー情報 */
    struct in6_addr sin6_addr;      /* IPv6 address */
                                    /* IPv6アドレス */
    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
                                    /* 範囲のインターフェース集合 */
};

   The only differences between this data structure and the 4.3BSD
   variant are the inclusion of the length field, and the change of the
   family field to a 8-bit data type.  The definitions of all the other
   fields are identical to the structure defined in the previous
   section.
   このデータ構造体と4.3BSDの間の唯一の相違は長さフィールドの包含で、
   8ビットのデータタイプに対するファミリーフィールドの変更です。すべて
   の他のフィールドの定義は前の章で定義された構造体とまったく同じです。

   Systems that provide this version of the sockaddr_in6 data structure
   must also declare SIN6_LEN as a result of including the
   <netinet/in.h> header.  This macro allows applications to determine
   whether they are being built on a system that supports the 4.3BSD or
   4.4BSD variants of the data structure.
   sockaddr_in6データ構造体のこの版を提供するシステムは、<netinet/in.h>
   ヘッダでSIN6_LENの宣言をしなければならなりません。このマクロはアプリ
   ケーションにシステムが4.3BSDデータ構造体に基づくか、4.4BSD
   データ構造体の基づくのか決定することを許します。

3.5 The Socket Functions
3.5 ソケット関数

   Applications call the socket() function to create a socket descriptor
   that represents a communication endpoint.  The arguments to the
   socket() function tell the system which protocol to use, and what
   format address structure will be used in subsequent functions.  For
   example, to create an IPv4/TCP socket, applications make the call:
   アプリケーションはsocket()関数を呼んで、通信末端を表すソケットディス
   クプリタを作ります。socket()関数への引数はシステムにどのプロトコルを
   使うべきか言い、そのプロトコルのアドレス構造体が後の関数で使われるで
   しょう。例えば、IPv4/TCPソケットを作るために、アプリケーショ
   ンが以下を呼びます:

      s = socket(AF_INET, SOCK_STREAM, 0);

   To create an IPv4/UDP socket, applications make the call:
   IPv4/UDPソケットを作るためアプリケーションが以下を呼びます:

      s = socket(AF_INET, SOCK_DGRAM, 0);

   Applications may create IPv6/TCP and IPv6/UDP sockets (which may also
   handle IPv4 communication as described in section 3.7) by simply
   using the constant AF_INET6 instead of AF_INET in the first argument.
   For example, to create an IPv6/TCP socket, applications make the
   call:
   アプリケーションが最初の引数に定数AF_INETの代わりに定数AF_INET6を使う
   ことでIPv6/TCPとIPv6/UDPソケットを作ります。例えば、
   IPv6/TCPソケットを作るためアプリケーションが以下を呼びます:

      s = socket(AF_INET6, SOCK_STREAM, 0);

   To create an IPv6/UDP socket, applications make the call:
   IPv6/UDPソケットを作るためアプリケーションは以下を呼びます:

      s = socket(AF_INET6, SOCK_DGRAM, 0);

   Once the application has created a AF_INET6 socket, it must use the
   sockaddr_in6 address structure when passing addresses in to the
   system.  The functions that the application uses to pass addresses
   into the system are:
   アプリケーションがAF_INET6ソケットを作ると、システムにアドレスを提示
   する際に、sockaddr_in6アドレス構造体を使わなくてはなりません。アプリ
   ケーションがシステムにアドレスを渡す関数は以下です:

      bind()
      connect()
      sendmsg()
      sendto()

   The system will use the sockaddr_in6 address structure to return
   addresses to applications that are using AF_INET6 sockets.  The
   functions that return an address from the system to an application
   are:
   システムはPF_INET6ソケットを使っているアプリケーションにアドレスを返
   すためsockaddr_in6アドレス構造体を使うでしょう。システムからアプリケー
   ションまでアドレスを返す関数は以下です:

      accept()
      recvfrom()
      recvmsg()
      getpeername()
      getsockname()

   No changes to the syntax of the socket functions are needed to
   support IPv6, since all of the "address carrying" functions use an
   opaque address pointer, and carry an address length as a function
   argument.
   「アドレスを運ぶ」関数のすべてが不透明なアドレスポインタを使い、アド
   レス長を関数の引数で運ぶので、IPv6対応にソケットの構文に対する変
   更が必要ありません。

3.6 Compatibility with IPv4 Applications
3.6 IPv4アプリケーションとの互換性

   In order to support the large base of applications using the original
   API, system implementations must provide complete source and binary
   compatibility with the original API.  This means that systems must
   continue to support AF_INET sockets and the sockaddr_in address
   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
   sockets using the AF_INET constant in the socket() function, as
   described in the previous section.  Applications should be able to
   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
   sockets simultaneously within the same process.
   多くのオリジナルのAPIを使っているアプリケーションをサポートするた
   めに、システム実装がオリジナルAPIのソースとバイナリの完全な互換性
   に提供しなくてはなりません。これはシステムがAF_INETソケットとsockaddr_in
   アドレス構造体をサポートし続けなくてはならないことを意味します。前章
   で記述されるように、アプリケーションがsocket()関数でAF_INET定数を使っ
   てIPv4/TCPとIPv4/UDPソケットを作れなければなりません。
   アプリケーションは同じプロセスので同時にIPv4/TCPとIPv4/
   UDPとIPv6/TCPとIPv6/UDPソケットの組合せを持つこと
   が可能であるべきです。

   Applications using the original API should continue to operate as
   they did on systems supporting only IPv4.  That is, they should
   continue to interoperate with IPv4 nodes.
   オリジナルの APIを使っているアプリケーションは、それらがIPv4だ
   けをサポートしているシステム上で動作したのと同様に、動作し続けるべき
   です。すなわち、それらはIPv4ノードと通信できるべきです。

3.7 Compatibility with IPv4 Nodes
3.7 IPv4ノードとの互換性


   The API also provides a different type of compatibility: the ability
   for IPv6 applications to interoperate with IPv4 applications.  This
   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
   addressing architecture specification [2].  This address format
   allows the IPv4 address of an IPv4 node to be represented as an IPv6
   address.  The IPv4 address is encoded into the low-order 32 bits of
   the IPv6 address, and the high-order 96 bits hold the fixed prefix
   0:0:0:0:0:FFFF.  IPv4-mapped addresses are written as follows:
   API異なるタイプの互換性を供給します:IPv6アプリケーションがI
   Pv4アプリケーションと通信する能力。この機能はIPv6アドレスアー
   キテクチャ仕様書[2]で定義されたIPv4マップIPv6アドレスフォー
   マットを使います。このアドレスフォーマットはIPv4ノードのIPv4
   アドレスをIPv6アドレス表現で記述するのを許します。IPv4アドレ
   スはIPv6アドレスの下位32ビットにコード化され、上位96ビットは
   固定プレフィックス0:0:0:0:0:FFFFです。IPv4マップのアドレスが次の
   ように書かれます:

      ::FFFF:<IPv4-address>

   These addresses can be generated automatically by the getaddrinfo()
   function, as described in Section 6.1.
   これらのアドレスは6.1章で記述されるようにgetaddrinfo()関数によって
   自動的に生成できます。

   Applications may use AF_INET6 sockets to open TCP connections to IPv4
   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
   destination's IPv4 address as an IPv4-mapped IPv6 address, and
   passing that address, within a sockaddr_in6 structure, in the
   connect() or sendto() call.  When applications use AF_INET6 sockets
   to accept TCP connections from IPv4 nodes, or receive UDP packets
   from IPv4 nodes, the system returns the peer's address to the
   application in the accept(), recvfrom(), or getpeername() call using
   a sockaddr_in6 structure encoded this way.
   アプリケーションがIPv4マップIPv6アドレスとして宛先IPv4ア
   ドレスをコード化し、sockaddr_in6構造体でconnect()かsendto()に渡すこと
   で、IPv4ノードにTCP接続を開くかUDPパケットを送るのに
   AF_INET6ソケットを使うかもしれません。アプリケーションがAF_INET6ソケッ
   トを使用してIPv4ノードからのTCP接続を受けるか、UDPパケット
   を受信する時、システムはこの方法でコード化したsockaddr_in6構造体を使
   用してaccept()やrecvfrom()やgetpeername()呼び出しで相手のアドレスをア
   プリケーションに返します。

   Few applications will likely need to know which type of node they are
   interoperating with.  However, for those applications that do need to
   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.4, is
   provided.
   ほとんどアプリケーションが多分どのタイプのノードと通信しているか知る
   必要がないでしょう。しかしながら、知る必要があるアプリケーションのた
   めに、6.7章で定義されたIN6_IS_ADDR_V4MAPPED()マクロが供給されます。

3.8 IPv6 Wildcard Address
3.8 IPv6ワイルドカードアドレス

   While the bind() function allows applications to select the source IP
   address of UDP packets and TCP connections, applications often want
   the system to select the source address for them.  With IPv4, one
   specifies the address as the symbolic constant INADDR_ANY (called the
   "wildcard" address) in the bind() call, or simply omits the bind()
   entirely.
   bind()関数がアプリケーションにUDPパケットとTCP接続のソースIP
   アドレスを選択を許しますが、アプリケーションはしばしばシステムにソー
   スアドレスを選ぶのを望みます。IPv4で、bind()呼び出しで象徴的定数
   INADDR_ANY(「ワイルドカード」アドレスと呼ばれる)を使うか、bind()を
   省略することでこれをします。

   Since the IPv6 address type is a structure (struct in6_addr), a
   symbolic constant can be used to initialize an IPv6 address variable,
   but cannot be used in an assignment.  Therefore systems provide the
   IPv6 wildcard address in two forms.
   IPv6アドレスタイプが構造体(struct in6_addr)であるので、象徴的定
   数がIPv6アドレス変数を初期化するために使うことができますが、代入
   で使うことができません。それ故にシステムが2つの形式でIPv6ワイル
   ドカードアドレスを供給します。

   The first version is a global variable named "in6addr_any" that is an
   in6_addr structure.  The extern declaration for this variable is
   defined in <netinet/in.h>:
   最初の版は「in6addr_any」という名前のin6_addr構造体グローバル変数です。
   この変数のextern宣言が<netinet/in.h>で行われます:

      extern const struct in6_addr in6addr_any;

   Applications use in6addr_any similarly to the way they use INADDR_ANY
   in IPv4.  For example, to bind a socket to port number 23, but let
   the system select the source address, an application could use the
   following code:
   アプリケーションはIPv4でINADDR_ANYを使うのと同様にin6addr_anyを使
   います。例えば、ポート番号23にソケットをバインドするがシステムにソー
   スアドレスを選ばせるため、アプリケーションが次のコードを使うことがで
   きます:

      struct sockaddr_in6 sin6;
       . . .
      sin6.sin6_family = AF_INET6;
      sin6.sin6_flowinfo = 0;
      sin6.sin6_port = htons(23);
      sin6.sin6_addr = in6addr_any;  /* structure assignment */
                                     /* 構造体代入 */
       . . .
      if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
              . . .

   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
   is defined in <netinet/in.h>.  This constant can be used to
   initialize an in6_addr structure:
   他の版はIN6ADDR_ANY_INITという名前の象徴的な定数で、<netinet/in.h>で
   定義されます。この定数はin6_addr構造体を初期化するために使うことがで
   きます:

      struct in6_addr anyaddr = IN6ADDR_ANY_INIT;

   Note that this constant can be used ONLY at declaration time.  It can
   not be used to assign a previously declared in6_addr structure.  For
   example, the following code will not work:
   この定数が宣言でだけ使うことができるのに注意してください。これは前に
   宣言したin6_addr構造体に代入するために使うことができません。例えば、
   次のコードは動かないでしょう:

      /* This is the WRONG way to assign an unspecified address */
      /* これは特定されていないアドレスを割り当てる間違った方法である */
      struct sockaddr_in6 sin6;
       . . .
      sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
                                         /* コンパイルできないでしょう */

   Be aware that the IPv4 INADDR_xxx constants are all defined in host
   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
   in6addr_xxx externals are defined in network byte order.
   IPv4のINADDR_xxx定数がすべてホストバイトオーダーで定義されますが、
   IPv6のIN6ADDR_xxx定数とin6addr_xxx外部変数がネットワークバイト順
   で定義されることを知っていてください。

3.9 IPv6 Loopback Address
3.9 IPv6ループバックアドレス

   Applications may need to send UDP packets to, or originate TCP
   connections to, services residing on the local node.  In IPv4, they
   can do this by using the constant IPv4 address INADDR_LOOPBACK in
   their connect(), sendto(), or sendmsg() call.
   アプリケーションがローカルノード上のサービスにUDPパケット送信やT
   CP接続をする必要があるかもしれません。IPv4でこれはIPv4アド
   レス定数INADDR_LOOPBACKをconnect()とsendto()とsendmsg()呼び出しで使
   うことでできます。

   IPv6 also provides a loopback address to contact local TCP and UDP
   services.  Like the unspecified address, the IPv6 loopback address is
   provided in two forms -- a global variable and a symbolic constant.
   IPv6はローカルなTCPとUDPサービスと通信をするためのループバッ
   クアドレスを供給します。特定されていないアドレスのように、IPv6ルー
   プバックアドレスの2つの形式−グローバル変数とシンボリックな定数−が
   供給されます。

   The global variable is an in6_addr structure named
   "in6addr_loopback."  The extern declaration for this variable is
   defined in <netinet/in.h>:
   グローバル変数は「in6addr_loopback」という名前のin6_addr構造体です。
   この変数のextern 宣言が<netinet/in.h>で定義されます:

      extern const struct in6_addr in6addr_loopback;

   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
   in IPv4 applications (but beware of the byte ordering difference
   mentioned at the end of the previous section).  For example, to open
   a TCP connection to the local telnet server, an application could use
   the following code:
   アプリケーションが、IPv4アプリケーションでINADDR_LOOPBACKを使うよ
   うにin6addr_loopbackを使います(前章の終わりで示したバイト順序に注意)。
   例えば、ローカルなtelnetサーバーにTCP接続をするために、アプリケー
   ションが次のコードを使えます:

   struct sockaddr_in6 sin6;
    . . .
   sin6.sin6_family = AF_INET6;
   sin6.sin6_flowinfo = 0;
   sin6.sin6_port = htons(23);
   sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
                                          /* 構造体代入 */
    . . .
   if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
           . . .

   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
   in <netinet/in.h>.  It can be used at declaration time ONLY; for
   example:
   象徴的定数はIN6ADDR_LOOPBACK_INITと命名され、<netinet/in.h>で定義され
   ます。これは宣言時にだけ使うことができます:

      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;

   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
   to a previously declared IPv6 address variable.
   IN6ADDR_ANY_INITのように、この定数は前に宣言されたIPv6アドレス変
   数への代入に使えません。

3.10 Portability Additions
3.10 ポータビリティ追加

   One simple addition to the sockets API that can help application
   writers is the "struct sockaddr_storage".  This data structure can
   simplify writing code that is portable across multiple address
   families and platforms.  This data structure is designed with the
   following goals.
   アプリケーション製作者に手助けできるソケットAPIへの1つの単純な追
   加は「struct sockaddr_storage」です。このデータ構造は多数のアドレスファ
   ミリーとプラットホーム間で移植性があるコードを書くことを簡単にします。
   このデータ構造は次の目的で設計されます。

   - Large enough to accommodate all supported protocol-specific address
      structures.
   - すべてのサポートされたプロトコル特有のアドレス構造体を受け入れるの
      に十分な大きさ。

   - Aligned at an appropriate boundary so that pointers to it can be
      cast as pointers to protocol specific address structures and used
      to access the fields of those structures without alignment
      problems.
   - 適切な境界に整列し、そのポインタがプロトコル特有のアドレス構造体へ
      のポインタにキャストでき、整列問題なしで、それらの構造体のフィール
      ドにアクセスするのに使用できる。

   The sockaddr_storage structure contains field ss_family which is of
   type sa_family_t.  When a sockaddr_storage structure is cast to a
   sockaddr structure, the ss_family field of the sockaddr_storage
   structure maps onto the sa_family field of the sockaddr structure.
   When a sockaddr_storage structure is cast as a protocol specific
   address structure, the ss_family field maps onto a field of that
   structure that is of type sa_family_t and that identifies the
   protocol's address family.
   sockaddr_storage構造体はsa_family_tタイプのフィールドss_familyを含ん
   でいます。sockaddr_storage構造体がsockaddr構造体にキャストされる時、
   sockaddr_storage構造体のss_familyフィールドはsockaddr構造体のsa_family
   フィールドをマップされます。sockaddr_storage構造体がプロトコル特有ア
   ドレス構造体いキャストされる時、ss_familyフィールドはsa_family_tタイ
   プの構造体のフィールドにマップされ、そしてプロトコルのアドレスファミ
   リーを識別します。

   An example implementation design of such a data structure would be as
   follows.
   このようなデータ構造の実装設計の例が以下です。

/*
 * Desired design of maximum size and alignment
 * 最大サイズと整列の望ましい設計
 */
#define _SS_MAXSIZE    128  /* Implementation specific max size */
                            /* 実装特有の最大サイズ */
#define _SS_ALIGNSIZE  (sizeof (int64_t))
                         /* Implementation specific desired alignment */
                         /* 実行特有の望ましい整列 */
/*
 * Definitions used for sockaddr_storage structure paddings design.
 * sockaddr_storage構造体のパディング設計で使う定義
 */
#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t) +
                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
struct sockaddr_storage {
    sa_family_t  ss_family;     /* address family */
                                  /* アドレスファミリー */
    /* Following fields are implementation specific */
    /* 次のフィールドは実装特有である */
    char      __ss_pad1[_SS_PAD1SIZE];
              /* 6 byte pad, this is to make implementation
              /* specific pad up to alignment field that */
              /* follows explicit in the data structure */
              /* 6バイトパッド、これはフィールド整列のため、 */
              /* データ構造体の後に、実装特有パッドを作ります。 */
    int64_t   __ss_align;     /* field to force desired structure */
                              /* 望ましい構造体を強制するためのフィールド */
               /* storage alignment */
               /* 貯蔵代入 */
    char      __ss_pad2[_SS_PAD2SIZE];
              /* 112 byte pad to achieve desired size, */
              /* _SS_MAXSIZE value minus size of ss_family */
              /* __ss_pad1, __ss_align fields is 112 */
              /* 望ましい大きさにするための112のバイトパッド、 */
              /* _SS_MAXSIZE値引くss_familyのサイズ、 */
              /* __ss_pad1と__ss_alignフィールドは112 */
};

   The above example implementation illustrates a data structure which
   will align on a 64-bit boundary.  An implementation-specific field
   "__ss_align" along with "__ss_pad1" is used to force a 64-bit
   alignment which covers proper alignment good enough for the needs of
   sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures.  The
   size of padding field __ss_pad1 depends on the chosen alignment
   boundary.  The size of padding field __ss_pad2 depends on the value
   of overall size chosen for the total size of the structure.  This
   size and alignment are represented in the above example by
   implementation specific (not required) constants _SS_MAXSIZE (chosen
   value 128) and _SS_ALIGNSIZE (with chosen value 8).  Constants
   _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112)
   are also for illustration and not required.  The derived values
   assume sa_family_t is 2 bytes.  The implementation specific
   definitions and structure field names above start with an underscore
   to denote implementation private namespace.  Portable code is not
   expected to access or reference those fields or constants.
   上記の例の実装は64ビット境界上に整列するデータ構造を例示します。実
   装特有のフィールド「__ss_align」と「__ss_pad1」は64ビット整列を強制
   するために使われ、これはsockaddr_in6(IPv6)とsockaddr_in(IPv
   4)アドレスデータ構造体の要求する適切な整列を十分満足します。穴埋め
   フィールド__ss_pad1の大きさは選ばれた整列境界に依存します。穴埋め
   フィールド__ss_pad2は構造体の完全な大きさに選ばれた全体的な大きさの
   値に依存します。上記の例の実装特有の大きさと整列が(必須ではない)定
   数_SS_MAXSIZE(選択された値は128)と_SS_ALIGNSIZE(選択された値は
   8)で表現されます。同じく例示した定数_SS_PAD1SIZE(派生する値6)と
   _SS_PAD2SIZE(派生する値112)は必須ではありません。派生した値は
   sa_family_tが2バイトであると想定します。上記の実装特有の定義と構造
   体フィールド名が実装固有の名前空間を意味する下線で始まります。移植可
   能コードがこれらのフィールドや定数をアクセスするか参照することが期待
   されません。

   On implementations where the sockaddr data structure includes a
   "sa_len" field this data structure would look like this:
   sockaddrデータ構造体が"sa_len"を含む実装で、このデータ構造体のフィー
   ルドが以下の様でしょう:

/*
 * Definitions used for sockaddr_storage structure paddings design.
 * sockaddr_storage構造体のパッドデザインに使う定義
 */
#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
                            (sizeof (uint8_t) + sizeof (sa_family_t))
#define _SS_PAD2SIZE (_SS_MAXSIZE -
                            (sizeof (uint8_t) + sizeof (sa_family_t) +
                             _SS_PAD1SIZE + _SS_ALIGNSIZE))
struct sockaddr_storage {
    uint8_t      ss_len;        /* address length */
                                  /* アドレス長 */
    sa_family_t  ss_family;     /* address family */
                                  /* アドレスファミリー */
    /* Following fields are implementation specific */
    /* 次のフィールドは実装特有である */
    char         __ss_pad1[_SS_PAD1SIZE];
                  /* 6 byte pad, this is to make implementation
                  /* specific pad up to alignment field that */
                  /* follows explicit in the data structure */
                  /* 6バイトパッド、これはフィールド整列のため、 */
                  /* データ構造体の後に、実装特有パッドを作ります。 */
    int64_t      __ss_align;  /* field to force desired structure */
                              /* 望ましい構造体を強制するためのフィールド */
                  /* storage alignment */
                  /* 貯蔵代入 */
    char         __ss_pad2[_SS_PAD2SIZE];
                  /* 112 byte pad to achieve desired size, */
                  /* _SS_MAXSIZE value minus size of ss_len, */
                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
                  /* 望ましい大きさにするための112のバイトパッド、 */
                  /* _SS_MAXSIZE値引くss_familyのサイズ、 */
                  /* __ss_pad1と__ss_alignフィールドは112 */
};

4. Interface Identification
4. インタフェース識別子

   This API uses an interface index (a small positive integer) to
   identify the local interface on which a multicast group is joined
   (Section 5.2).  Additionally, the advanced API [4] uses these same
   interface indexes to identify the interface on which a datagram is
   received, or to specify the interface on which a datagram is to be
   sent.
   このAPIはマルチキャストグループが加入するローカルインタフェースを
   識別するためにインタフェースインデックス(小さい正の整数)を使います
   (5.2章)。さらに、高等API[4]はデータグラムを受信するインタフェー
   スを識別するか、データグラムを送るインタフェースを指定するために同じ
   インタフェースインデックスを使います。

   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
   and the like.  On Berkeley-derived implementations, when an interface
   is made known to the system, the kernel assigns a unique positive
   integer value (called the interface index) to that interface.  These
   are small positive integers that start at 1.  (Note that 0 is never
   used for an interface index.)  There may be gaps so that there is no
   current interface for a particular positive interface index.
   インタフェースが通常"le0"や"sl1"や"ppp2"の様な名前で知られています。
   バークレー系の実装で、インタフェースをシステムが知る時、カーネルはそ
   のインタフェースに(インタフェースインデックスと呼ばれる)ユニークな
   正の整数値を割り当てます。これらは1から始まる小さい正の整数です。
   (0が決してインタフェースインデックスで使われないことに注意してくだ
   さい。)特定の正のインタフェースインデックスで現在のインタフェースが
   ないような隙間があるかもしれません。

   This API defines two functions that map between an interface name and
   index, a third function that returns all the interface names and
   indexes, and a fourth function to return the dynamic memory allocated
   by the previous function.  How these functions are implemented is
   left up to the implementation.  4.4BSD implementations can implement
   these functions using the existing sysctl() function with the
   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
   for this purpose.
   このAPIはインタフェース名とインデックスを対応付ける2つの関数と、
   すべてのインタフェース名を返す3番目の関数と、前の関数が割り当てられ
   たダイナミックメモリを返す4番目の関数を定義します。これらの関数が実
   装される方法は実装依存です。4.4BSD実装が、NET_RT_IFLISTコマンド
   と既存のsysctl()関数を使って、これらの関数を実装できます。他の実装が
   この目的のためにioctl()を使うことを望むかもしれません。

4.1 Name-to-Index
4.1 Name-to-Index

   The first function maps an interface name into its corresponding
   index.
   最初の関数はインタフェース名を対応するインデックスに変換します。

      #include <net/if.h>

      unsigned int  if_nametoindex(const char *ifname);

   If ifname is the name of an interface, the if_nametoindex() function
   shall return the interface index corresponding to name ifname;
   otherwise, it shall return zero.  No errors are defined.
   もしifnameがインタフェース名なら、if_nametoindex()関数が名前ifnameに
   対応しているインタフェースインデックスを返すべきです、さもなければ、
   ゼロを返すべきです。エラーが定義されません。

4.2 Index-to-Name
4.2 Index-to-Name

   The second function maps an interface index into its corresponding
   name.
   2番目の関数はインタフェースインデックスを対応する名前に変換します。

      #include <net/if.h>

      char  *if_indextoname(unsigned int ifindex, char *ifname);

   When this function is called, the ifname argument shall point to a
   buffer of at least IF_NAMESIZE bytes.  The function shall place in
   this buffer the name of the interface with index ifindex.
   (IF_NAMESIZE is also defined in <net/if.h> and its value includes a
   terminating null byte at the end of the interface name.)  If ifindex
   is an interface index, then the function shall return the value
   supplied in ifname, which points to a buffer now containing the
   interface name.  Otherwise, the function shall return a NULL pointer
   and set errno to indicate the error.  If there is no interface
   corresponding to the specified index, errno is set to ENXIO.  If
   there was a system error (such as running out of memory), errno would
   be set to the proper value (e.g., ENOMEM).
   この関数が呼び出される時、ifname引数は少なくともIF_NAMESIZEバイトのバッ
   ファを指し示すべきです。関数はインデックスifindexのインタフェースの名
   前をこのバッファに置くべきです。(IF_NAMESIZEは<net/if.h>で同じく定義
   され、その値はインタフェース名の終わりに、終了のヌルバイトを含みます)
   もしifindexがインタフェースインデックスであるなら、関数は、今はインタ
   フェース名を含んでいる、ifnameで供給されたバッファを指し示す値を返す
   べきです。さもなければ、関数はヌルポインタを返し、そしてエラーを示す
   errnoを設定するべきです。もし指定されたインデックスに対応しているイン
   タフェースがないなら、errnoにENXIOが設定されます。もし(メモリ不足の
   ような)システムエラーがあったなら、errnoが適切な値に設定されるでしょ
   う(例えば、ENOMEM)。

4.3 Return All Interface Names and Indexes
4.3 全インタフェース名とインデックスを返す

   The if_nameindex structure holds the information about a single
   interface and is defined as a result of including the <net/if.h>
   header.
   if_nameindex構造体はひとつのインタフェースの情報を持ち、<net/if.h>
   で定義されます。

   struct if_nameindex {
     unsigned int   if_index;  /* 1, 2, ... */
                                  /* 1, 2, ... */
     char          *if_name;   /* null terminated name: "le0", ... */
                                  /* ヌルで終わる名前:    "le0", ... */
   };

   The final function returns an array of if_nameindex structures, one
   structure per interface.
   最後の関数はif_nameindex構造体の配列、インタフェース毎に1つの構造体、
   を返します。

      #include <net/if.h>

      struct if_nameindex  *if_nameindex(void);

   The end of the array of structures is indicated by a structure with
   an if_index of 0 and an if_name of NULL.  The function returns a NULL
   pointer upon an error, and would set errno to the appropriate value.
   構造体の配列の終わりは0のif_indexとNULLのif_nameの構造体で示されます。
   関数はエラーの場合に空のポインタを返し、errnoに適切な値を設定します。

   The memory used for this array of structures along with the interface
   names pointed to by the if_name members is obtained dynamically.
   This memory is freed by the next function.
   if_nameメンバーにで指し示されたインタフェース名とこの構造体の配列で使
   われたメモリは動的に得られます。このメモリは次の関数で解放されます。

4.4 Free Memory
4.4 メモリ開放

   The following function frees the dynamic memory that was allocated by
   if_nameindex().
   次の関数はif_nameindex()の割り当てたダイナミックなメモリを解放します。

      #include <net/if.h>

      void  if_freenameindex(struct if_nameindex *ptr);

   The ptr argument shall be a pointer that was returned by
   if_nameindex().  After if_freenameindex() has been called, the
   application shall not use the array of which ptr is the address.
   ptr引数はif_nameindex()によって返されたポインタであるべきです。
   if_freenameindex()が呼ばれた後、アプリケーションはptrが示す配列を使う
   べきではありません。

5. Socket Options
5. ソケットオプション

   A number of new socket options are defined for IPv6.  All of these
   new options are at the IPPROTO_IPV6 level.  That is, the "level"
   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
   when using these options.  The constant name prefix IPV6_ is used in
   all of the new socket options.  This serves to clearly identify these
   options as applying to IPv6.
   多くの新しいソケットオプションがIPv6で定義されます。これらすべて
   の新しいオプションはIPPROTO_IPV6レベルにあります。すなわち、
   getsockopt()とsetsockopt()呼び出しでの"level"パラメータは、これらの
   オプションを使う時、 IPPROTO_IPV6です。定数名プレフィックス、IPV6_が
   新しいソケットオプションのすべてで使われます。これは明らかにIPv6
   に適用するオプションを識別するのに役立ちます。

   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
   related constants defined in this section are obtained by including
   the header <netinet/in.h>.
   IPPROTO_IPV6の宣言と、新しいIPv6ソケットオプションと、この章で定
   義された関連した定数が<netinet/in.h>ヘッダで得られます。

5.1 Unicast Hop Limit
5.1 ユニキャストホップ限界

   A new setsockopt() option controls the hop limit used in outgoing
   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
   and it is used at the IPPROTO_IPV6 layer.  The following example
   illustrates how it is used:
   新しいsetsockopt()オプションが外向ユニキャストIPv6パケットで使わ
   れたホップ限界を制御します。このオプションの名前はIPV6_UNICAST_HOPSで、
   これはIPPROTO_IPV6レイヤで使われます。次の例は使い方法を例示します:

   int  hoplimit = 10;

   if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
                  (char *) &hoplimit, sizeof(hoplimit)) == -1)
       perror("setsockopt IPV6_UNICAST_HOPS");

   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
   option value given is used as the hop limit for all subsequent
   unicast packets sent via that socket.  If the option is not set, the
   system selects a default value.  The integer hop limit value (called
   x) is interpreted as follows:
   IPV6_UNICAST_HOPSオプションがsetsockopt()で設定される時、与えられたオ
   プション値はすべてのそのソケットから送らるユニキャストパケットでホッ
   プ限界として使われます。もしオプションが設定されないなら、システムは
   デフォルト値を選択します。(xと呼ばれる)整数ホップ限界値は次のように
   翻訳されます:

      x < -1:        return an error of EINVAL
      x == -1:       use kernel default
      0 <= x <= 255: use x
      x >= 256:      return an error of EINVAL

   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
   determine the hop limit value that the system will use for subsequent
   unicast packets sent via that socket.  For example:
   IPV6_UNICAST_HOPSオプションは、システムがそのソケットから次に送るユニ
   キャストパケットに使うであろうホップ限界値を決定するためgetsockopt()
   で使われるかもしれません。例えば:

      int  hoplimit;
      socklen_t  len = sizeof(hoplimit);

      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
                     (char *) &hoplimit, &len) == -1)
          perror("getsockopt IPV6_UNICAST_HOPS");
      else
          printf("Using %d for hop limit.\n", hoplimit);

5.2 Sending and Receiving Multicast Packets
5.2 マルチキャストパケットの送受信

   IPv6 applications may send multicast packets by simply specifying an
   IPv6 multicast address as the destination address, for example in the
   destination address argument of the sendto() function.
   IPv6アプリケーションが、例えばsendto()関数の宛先アドレス引数で、
   ただIPv6マルチキャストアドレスを宛先アドレスとして明示することに
   よってマルチキャストパケットを送るかもしれません。

   Three socket options at the IPPROTO_IPV6 layer control some of the
   parameters for sending multicast packets.  Setting these options is
   not required: applications may send multicast packets without using
   these options.  The setsockopt() options for controlling the sending
   of multicast packets are summarized below.  These three options can
   also be used with getsockopt().
   IPPROTO_IPV6レイヤで3つのソケットオプションがマルチキャストパケット
   を送る際のパラメータのいくつかを制御します。これらのオプションを設定
   することは必須でありません:アプリケーションがこれらのオプションを使
   わないでマルチキャストパケットを送るかもしれません。マルチキャストパ
   ケットの送信制御のsetsockopt()オプションを下に要約します。これらの3
   つのオプションはgetsockopt()で使うこともできます。

      IPV6_MULTICAST_IF
      IPV6_MULTICAST_IF

         Set the interface to use for outgoing multicast packets.  The
         argument is the index of the interface to use.  If the
         interface index is specified as zero, the system selects the
         interface (for example, by looking up the address in a routing
         table and using the resulting interface).
         外向マルチキャストパケットで使うインタフェースを指定。引数は使
         用するインタフェースのインデックスです。もしインタフェースイン
         デックスがゼロと明示されるなら、システムはインタフェースを選び
         ます(例えば、アドレスをルーティングテーブルで調べて、そして結
         果得られたインタフェースを使うことで)。

         Argument type: unsigned int
         引数タイプ   : unsigned int

      IPV6_MULTICAST_HOPS
      IPV6_MULTICAST_HOPS

         Set the hop limit to use for outgoing multicast packets.  (Note
         a separate option - IPV6_UNICAST_HOPS - is provided to set the
         hop limit to use for outgoing unicast packets.)
         外向マルチキャストパケットのに使うホップ限界を設定。(外向ユニ
         キャストパケットに使うホップ限界を設定する別のオプション
         −IPV6_UNICAST_HOPS−が供給されることに注意してください。)

         The interpretation of the argument is the same as for the
         IPV6_UNICAST_HOPS option:
         引数の解釈はIPV6_UNICAST_HOPSオプションと同じです:

            x < -1:        return an error of EINVAL
                          EINVALのエラーを返す
            x == -1:       use kernel default
                          カーネルデフォルトを使用
            0 <= x <= 255: use x
                          xを使用
            x >= 256:      return an error of EINVAL
                          EINVALエラーを返す

            If IPV6_MULTICAST_HOPS is not set, the default is 1
            (same as IPv4 today)
           もしIPV6_MULTICAST_HOPSが設定されないなら、デフォルトは
           (今日のIPv4と同じく)1です。

         Argument type: int
         引数タイプ   : int

      IPV6_MULTICAST_LOOP
      IPV6_MULTICAST_LOOP

         If a multicast datagram is sent to a group to which the sending
         host itself belongs (on the outgoing interface), a copy of the
         datagram is looped back by the IP layer for local delivery if
         this option is set to 1.  If this option is set to 0 a copy is
         not looped back.  Other option values return an error of
         EINVAL.
         もしこのオプションが1に設定されたら、マルチキャストデータグラ
         ムが(外向インタフェース上の)送信ホスト自身が属するグループに
         送られた時、データグラムのコピーがローカルな配達のためにIPレ
         イヤによってループバックされます。もしこのオプションが0に設定
         されるなら、コピーがループバックされません。他のオプション値が
         EINVALエラーを返します。

         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
         same as IPv4 today).
         もしIPV6_MULTICAST_LOOPが設定されないなら、デフォルトは
         (今日のIPv4と同じく)1です。

         Argument type: unsigned int
         引数タイプ   : unsigned int

   The reception of multicast packets is controlled by the two
   setsockopt() options summarized below.  An error of EOPNOTSUPP is
   returned if these two options are used with getsockopt().
   マルチキャストパケットの受信は下に要約した2つのsetsockopt()オプショ
   ンで制御されます。もしこれらの2つのオプションがgetsockopt()で使われ
   るなら、EOPNOTSUPPエラーが返されます。

      IPV6_JOIN_GROUP
      IPV6_JOIN_GROUP

         Join a multicast group on a specified local interface.
         If the interface index is specified as 0,
         the kernel chooses the local interface.
         For example, some kernels look up the multicast group
         in the normal IPv6 routing table and use the resulting
         interface.
         指定されたローカルインタフェース上のマルチキャストグループに加
         入してください。もしインタフェースインデックスが0と明示される
         なら、カーネルはローカルインタフェースを選択します。例えば、あ
         るカーネルが標準的なIPv6ルーティングテーブルでマルチキャス
         トグループを検索し、得られたインタフェースを使います。

         Argument type: struct ipv6_mreq
         引数タイプ   : struct ipv6_mreq

      IPV6_LEAVE_GROUP
      IPV6_LEAVE_GROUP

         Leave a multicast group on a specified interface.
         If the interface index is specified as 0, the system
         may choose a multicast group membership to drop by
         matching the multicast address only.
         指定インタフェース上のマルチキャストグループから離脱。もしイン
         タフェースインデックスが0と明示されるなら、システムはマルチ
         キャストに一致するアドレスのみを捨てるためにマルチキャストグ
         ループメンバーシップを選択するかもしれません。

         Argument type: struct ipv6_mreq
         引数タイプ   : struct ipv6_mreq

   The argument type of both of these options is the ipv6_mreq
   structure, defined as a result of including the <netinet/in.h>
   header;
   これらのオプションの両方の引数タイプはthe <netinet/in.h>ヘッダで定義
   されたipv6_mreq構造体です;

   struct ipv6_mreq {
       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
       unsigned int    ipv6mr_interface; /* interface index */
   };

   Note that to receive multicast datagrams a process must join the
   multicast group to which datagrams will be sent.  UDP applications
   must also bind the UDP port to which datagrams will be sent.  Some
   processes also bind the multicast group address to the socket, in
   addition to the port, to prevent other datagrams destined to that
   same port from being delivered to the socket.
   マルチキャストデータグラムを受け取るために、プロセスがデータグラムが
   送られるであろうマルチキャストグループに加入しなくてはならないことに
   注意してください。UDPアプリケーションが同じくデータグラムが送られ
   るであろうUDPポートをバインドしなくてはなりません。。あるプロセス
   が、その同じポート宛の他のデータグラムがソケットに配達されるのを阻止
   するために、ポートに加えてマルチキャストグループアドレスをソケットに
   バインドします。

5.3 IPV6_V6ONLY option for AF_INET6 Sockets
5.3 AF_INET6ソケットのIPV6_V6ONLYオプション

   This socket option restricts AF_INET6 sockets to IPv6 communications
   only.  As stated in section <3.7 Compatibility with IPv4 Nodes>,
   AF_INET6 sockets may be used for both IPv4 and IPv6 communications.
   Some applications may want to restrict their use of an AF_INET6
   socket to IPv6 communications only.  For these applications the
   IPV6_V6ONLY socket option is defined.  When this option is turned on,
   the socket can be used to send and receive IPv6 packets only.  This
   is an IPPROTO_IPV6 level option.  This option takes an int value.
   This is a boolean option.  By default this option is turned off.
   このソケットオプションはAF_INET6ソケットをIPv6通信のみに制限しま
   す。<3.7 IPv4ノードとの互換性>章で述べられるように、AF_INET6ソ
   ケットがIPv4とIPv6通信の両方で使われるかもしれません。あるア
   プリケーションがIPv6通信のみにAF_INET6ソケットの用途を限定するこ
   とを望むかもしれません。これらのアプリケーションのためにIPV6_V6ONLYソ
   ケットオプションが定義されます。このオプションがオンになっている時、
   ソケットは送受信にIPv6パケットのみを使うことができます。これは
   IPPROTO_IPV6レベルオプションです。このオプションはint値をとります。
   これはブールオプションです。デフォルトでこの選択はオフです。

   Here is an example of setting this option:
   ここにこのオプションを設定することの例があります:

      int on = 1;

      if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,
                     (char *)&on, sizeof(on)) == -1)
          perror("setsockopt IPV6_V6ONLY");
      else
          printf("IPV6_V6ONLY set\n");

   Note - This option has no effect on the use of IPv4 Mapped addresses
   which enter a node as a valid IPv6 addresses for IPv6 communications
   as defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5].
   ノート−このオプションは、IPv6がステートレスIP/ICMP翻訳ア
   ルゴリズム(SIIT)[5]で定義されるIPv6通信のための正しいIPv
   6アドレスとしてノードに入力されたIPv4マップアドレスの使用に対す
   る効果を持っていません。

   An example use of this option is to allow two versions of the same
   server process to run on the same port, one providing service over
   IPv6, the other providing the same service over IPv4.
   このオプションの使用の例は、同じサーバの同じポート上の2つのバージョ
   ンのプロセスが、一方がIPv6上のサービスを供給し、他方がIPv4の
   サービスを供給する、動作を許します。

6. Library Functions
6. ライブラリ関数

   New library functions are needed to perform a variety of operations
   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
   address translation) and reverse lookup (address-to-nodename
   translation) need to be supported.  Functions are also needed to
   convert IPv6 addresses between their binary and textual form.
   新しいライブラリ関数がIPv6アドレスでいろいろな操作を実行するため
   に必要とされます。関数がドメインネームシステム(DNS)でIPv6ア
   ドレスを検索するために必要とされます。前方検索(ノード名からアドレス
   への翻訳)と逆検索(アドレスからノード名への翻訳)の両方がサポートさ
   れる必要があります。バイナリ形式とテキスト形式のIPv6アドレス間の
   翻訳関数が同じく必要です。

   We note that the two existing functions, gethostbyname() and
   gethostbyaddr(), are left as-is.  New functions are defined to handle
   both IPv4 and IPv6 addresses.
   我々は2つの既存の関数、gethostbyname()とgethostbyaddr()、が現状のま
   ま残ることを指摘します。新しい関数がIPv4とIPv6アドレス両方を
   処理するために定義されます。

   The commonly used function gethostbyname() is inadequate for many
   applications, first because it provides no way for the caller to
   specify anything about the types of addresses desired (IPv4 only,
   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
   implementations of this function are not thread safe.  RFC 2133
   defined a function named gethostbyname2() but this function was also
   inadequate, first because its use required setting a global option
   (RES_USE_INET6) when IPv6 addresses were required, and second because
   a flag argument is needed to provide the caller with additional
   control over the types of addresses required.  The gethostbyname2()
   function was deprecated in RFC 2553 and is no longer part of the
   basic API.
   一般に使われる関数gethostbyname()は多くのアプリケーションに対して不十
   分です、第一に関数が要望されるアドレスタイプ(IPv4のみ、IPv6
   のみの、IPv4マップIPv6がOKなど)について呼び出し人が指定する
   方法を供給しないし、第二にこの関数の多くの実装がスレッドに安全ではな
   いからです。RFC2133がgethostbyname2()という名前の機能を定義し
   ましたが、この関数は、第一にIPv6アドレスが必要な時にグローバルオ
   プション(RES_USE_INET6)の設定が必要で、第二にフラグ引数が必要なタイ
   プのアドレスの追加の制御を呼び出し人に提供するために必要なため、同じ
   く不適当です。gethostbyname2()関数はRFC2553で廃止されれ、そし
   てもう基本API の一部ではありません。

6.1 Protocol-Independent Nodename and Service Name Translation
6.1 プロトコルに依存しないノード名とサービス名翻訳

   Nodename-to-address translation is done in a protocol-independent
   fashion using the getaddrinfo() function.
   ノード名からアドレスへの翻訳がgetaddrinfo()関数を使ってプロトコルに依
   存しない方法でされます。

#include <sys/socket.h>
#include <netdb.h>

int getaddrinfo(const char *nodename, const char *servname,
                const struct addrinfo *hints, struct addrinfo **res);

void freeaddrinfo(struct addrinfo *ai);

struct addrinfo {
  int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME,
                           AI_NUMERICHOST, .. */
  int     ai_family;    /* AF_xxx */
  int     ai_socktype;  /* SOCK_xxx */
  int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
  socklen_t  ai_addrlen;   /* length of ai_addr */
                           /* ai_addrの長さ */
  char   *ai_canonname; /* canonical name for nodename */
                        /* ノード名の正規化名 */
  struct sockaddr  *ai_addr; /* binary address */
                             /* バイナリアドレス */
  struct addrinfo  *ai_next; /* next structure in linked list */
                             /* リンクしたリストの次の要素 */
};

   The getaddrinfo() function translates the name of a service location
   (for example, a host name) and/or a service name and returns a set of
   socket addresses and associated information to be used in creating a
   socket with which to address the specified service.
   getaddrinfo()関数はサービスの場所の名前(例えば、ホスト名)とサービス
   名を翻訳して、そして指定されたサービスへのソケットを作り、使われるべ
   きソケットアドレスと関連づけられた情報を返します。

   The nodename and servname arguments are either null pointers or
   pointers to null-terminated strings.  One or both of these two
   arguments must be a non-null pointer.
   nodenameとservname引数はヌルポインタあるいはヌルで終了する文字列への
   ポインタです。これらの2つの引数の1つあるいは両方がゼロでないポイン
   タであるに違いありません。

   The format of a valid name depends on the address family or families.
   If a specific family is not given and the name could be interpreted
   as valid within multiple supported families, the implementation will
   attempt to resolve the name in all supported families and, in absence
   of errors, one or more results shall be returned.
   正当な名前のフォーマットはアドレスファミリーに依存します。もし特定の
   ファミリーが与えられず、そして多数のサポートされたファミリーで名前が
   正当であると解釈されるなら、実装はすべてのサポートされたファミリーで
   名前の変換を試み、そして、エラーがなければ、1つ以上の結果が返される
   べきです。

   If the nodename argument is not null, it can be a descriptive name or
   can be an address string.  If the specified address family is
   AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host
   names. If the specified address family is AF_INET or AF_UNSPEC,
   address strings using Internet standard dot notation as specified in
   inet_addr() are valid.  If the specified address family is AF_INET6
   or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are
   valid.
   もしnodename引数がヌルでないなら、それは記述的名前か、アドレス文字列
   です。もし指定されたアドレスファミリーがAF_INETかAF_INET6かAF_UNSPEC
   であるなら、正当な記述的名前がホスト名を含みます。もし指定されたアド
   レスファミリーがAF_INETあるいはAF_UNSPECであるなら、インターネット標
   準表記法を使っているアドレス文字列はinet_addr()で指定されるように正当
   です。もし指定されたアドレスファミリーがAF_INET6あるいはAF_UNSPECであ
   るなら、inet_pton()で記述された標準的なIPv6テキスト書式は正当です。

   If nodename is not null, the requested service location is named by
   nodename; otherwise, the requested service location is local to the
   caller.
   もしnodenameがヌルでないなら、求められたサービスの場所はnodenameで指
   定されます;さもなければ、求められたサービスの場所は呼び出し人にロー
   カルです。

   If servname is null, the call shall return network-level addresses
   for the specified nodename.  If servname is not null, it is a null-
   terminated character string identifying the requested service.  This
   can be either a descriptive name or a numeric representation suitable
   for use with the address family or families.  If the specified
   address family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be
   specified as a string specifying a decimal port number.
   もしservnameがヌルであるなら、呼び出しは指定されたnodenameのネットワー
   クレベルアドレスを返すべきです。もしservnameがヌルでないなら、それは
   求められたサービスを識別するヌルで終了する文字列です。これはアドレス
   ファミリーで使用が適切な、記述的名前か数値表現です。もし指定されたア
   ドレスファミリーがAF_INETかAF_INET6かAF_UNSPECであるなら、サービスは
   10進法のポート番号を指定する文字列として明示できます。

   If the argument hints is not null, it refers to a structure
   containing input values that may direct the operation by providing
   options and by limiting the returned information to a specific socket
   type, address family and/or protocol.  In this hints structure every
   member other than ai_flags, ai_family, ai_socktype and ai_protocol
   shall be set to zero or a null pointer.  A value of AF_UNSPEC for
   ai_family means that the caller shall accept any address family.  A
   value of zero for ai_socktype means that the caller shall accept any
   socket type.  A value of zero for ai_protocol means that the caller
   shall accept any protocol.  If hints is a null pointer, the behavior
   shall be as if it referred to a structure containing the value zero
   for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
   for the ai_family field.
   もし引数hintsがヌルでなければ、入力値を含む構造体を参照します、入力値
   はオプションで供給され、返す情報を特定のソケットタイプやアドレスファ
   ミリーやプロトコルに制限する、操作を指揮します。このhints構造体で、
   ai_flagsとai_familyとai_socktypeとai_protocol以外のメンバーがゼロかヌ
   ルポインタを設定されるべきです。ai_familyのAF_UNSPEC値が呼び出し人が
   どんなアドレスファミリーでも受け入れることを意味します。ai_socktypeの
   ゼロの値が呼び出し人がどんなソケットタイプでも受け入れることを意味し
   ます。ai_protocolのゼロの値が呼び出し人がどんなプロトコルでも受け入れ
   ることを意味します。もしhintsがヌルなら、ai_flagsとai_socktypeと
   ai_protocolフィールドがゼロでai_familyフィールドがAF_UNSPECである構造
   体を参照するかのようにふるまうべきです。

   Note:
   ノート:

   1. If the caller handles only TCP and not UDP, for example, then the
      ai_protocol member of the hints structure should be set to
      IPPROTO_TCP when getaddrinfo() is called.
   1. 例えば、もし呼び出し人がUDPではなくTCPだけを扱うなら、hints
      構造体のai_protocolメンバーは、getaddrinfo()が呼ばれる時、
      IPPROTO_TCPを設定されるべきです。

   2. If the caller handles only IPv4 and not IPv6, then the ai_family
      member of the hints structure should be set to AF_INET when
      getaddrinfo() is called.
   2. もし呼び出し人がIPv6ではなくIPv4だけを処理するなら、
      getaddrinfo()が呼ばれるときにhints構造体のai_familyメンバーは
      AF_INETが設定されるべきです。

   The ai_flags field to which hints parameter points shall be set to
   zero or be the bitwise-inclusive OR of one or more of the values
   AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
   AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
   hintsパラメータが示すai_flagsフィールドはゼロが設定されるか、
   AI_PASSIVEとAI_CANONNAMEとAI_NUMERICHOSTとAI_NUMERICSERVとAI_V4MAPPED
   とAI_ALLとAI_ADDRCONFIGの1つ以上の値のビット単位の包含ORです。

   If the AI_PASSIVE flag is specified, the returned address information
   shall be suitable for use in binding a socket for accepting incoming
   connections for the specified service (i.e., a call to bind()).  In
   this case, if the nodename argument is null, then the IP address
   portion of the socket address structure shall be set to INADDR_ANY
   for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address.  If the
   AI_PASSIVE flag is not specified, the returned address information
   shall be suitable for a call to connect() (for a connection-mode
   protocol) or for a call to connect(), sendto() or sendmsg() (for a
   connectionless protocol).  In this case, if the nodename argument is
   null, then the IP address portion of the socket address structure
   shall be set to the loopback address.  This flag is ignored if the
   nodename argument is not null.
   もしAI_PASSIVEフラグが指定されるなら、返されたアドレス情報は指定サー
   ビスの接続を受け付けるソケットに使用する(つまりbind())に適するべき
   です。この場合、もしnodename引数がヌルであるなら、ソケットアドレス構
   造体のIPアドレス部は、IPv4アドレスではINADDR_ANYで、IPv6ア
   ドレスではIN6ADDR_ANY_INITになるべきです。もしAI_PASSIVEフラグが指定
   されないなら、返されたアドレス情報はconnect()呼出(接続モードプロトコ
   ルで)や、 connect()やsendto()やsendmsg()呼び出し(コネクションレスプ
   ロトコルのために)で、適するべきです。この場合、もしnodename引数がヌ
   ルであるなら、ソケットアドレス構造体のIPアドレス部はループバックア
   ドレスが設定されるべきです。このフラグは、もしnodename引数がヌルでな
   いなら、無視されます。

   If the AI_CANONNAME flag is specified and the nodename argument is
   not null, the function shall attempt to determine the canonical name
   corresponding to nodename (for example, if nodename is an alias or
   shorthand notation for a complete name).
   もしAI_CANONNAMEフラグが指定され、nodename引数がヌルでないなら、関数
   はnodenameに対応している規準名を決定しようと試みるべきです(例えば、
   もしnodenameが別名や完全名の省略表記の場合)。

   If the AI_NUMERICHOST flag is specified, then a non-null nodename
   string supplied shall be a numeric host address string.  Otherwise,
   an [EAI_NONAME] error is returned.  This flag shall prevent any type
   of name resolution service (for example, the DNS) from being invoked.
   もしAI_NUMERICHOSTフラグが設定されるなら、文字列が供給したヌルでない
   nodenameが数値ホストアドレス文字列であるべきです。さもなければ、
   [EAI_NONAME]エラーが返されます。このフラグは呼び出された時に、いかな
   る名前解決サービス(例えば、DNS)も妨げるべきです。

   If the AI_NUMERICSERV flag is specified, then a non-null servname
   string supplied shall be a numeric port string.  Otherwise, an
   [EAI_NONAME] error shall be returned.  This flag shall prevent any
   type of name resolution service (for example, NIS+) from being
   invoked.
   もしAI_NUMERICSERVフラグが指定されるなら、供給されたヌルでない
   servname文字列が数値ポート文字列であるべきです。さもなければ、
   [EAI_NONAME]エラーが返されるべきです。このフラグは名前解決サービス
   (例えば、NIS+)が呼ばれるのを阻止するべきです。

   If the AI_V4MAPPED flag is specified along with an ai_family of
   AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses
   on finding no matching IPv6 addresses (ai_addrlen shall be 16).
   もしAI_V4MAPPEDフラグがAF_INET6のai_familyとともに指定されるなら、
   getaddrinfo()が一致するIPv6アドレスが見つけられない場合にIPv4
   マップIPv6アドレスを返すべきです(ai_addrlenは16であるべきです)。

      For example, when using the DNS, if no AAAA records are found then
      a query is made for A records and any found are returned as IPv4-
      mapped IPv6 addresses.
      例えば、DNSを使う時、もしAAAAレコードが見つからないなら、
      Aレコード問合せがなされ、そして見つかったものがIPv4マップ
      IPv6アドレスとして返されます。

   The AI_V4MAPPED flag shall be ignored unless ai_family equals
   AF_INET6.
   AI_V4MAPPEDフラグは、ai_familyがAF_INET6でないなら無視されるべきです。

   If the AI_ALL flag is used with the AI_V4MAPPED flag, then
   getaddrinfo() shall return all matching IPv6 and IPv4 addresses.
   もしAI_ALLフラグがAI_V4MAPPEDフラグと共に使われるなら、getaddrinfo()
   がすべての一致するIPv6とIPv4アドレスを返すべきです。

      For example, when using the DNS, queries are made for both AAAA
      records and A records, and getaddrinfo() returns the combined
      results of both queries.  Any IPv4 addresses found are returned as
      IPv4-mapped IPv6 addresses.
      例えば、DNSを使う時、問合せがAAAAレコードとAレコードの両方
      でされ、そしてgetaddrinfo()が両方の問合せの結合結果を返します。見
      つかったIPv4アドレスはIPv4マップIPv6アドレスとして返さ
      れます。

   The AI_ALL flag without the AI_V4MAPPED flag is ignored.
   AI_V4MAPPEDフラグがないAI_ALLフラグは無視されます。

      Note:
      ノート:

      When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and
      AI_ALL flags will only be used if AF_INET6 is supported.
      ai_familyが指定されない時、もしAF_INET6がサポートされるなら、
      (AF_UNSPECと)AI_V4MAPPEDとAI_ALLフラグだけが使われるでしょう。

   If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
   returned only if an IPv4 address is configured on the local system,
   and IPv6 addresses shall be returned only if an IPv6 address is
   configured on the local system.  The loopback address is not
   considered for this case as valid as a configured address.
   もしAI_ADDRCONFIGフラグが指定されるなら、IPv4アドレスがローカルシ
   ステムで設定される場合に限りIPv4アドレスが返されるべきです、そし
   てIPv6アドレスがローカルシステム上に設定される場合に限りIPv6
   アドレスが返されるべきです。ループバックアドレスはこの場合効力がある
   設定と考えられません。

      For example, when using the DNS, a query for AAAA records should
      occur only if the node has at least one IPv6 address configured
      (other than IPv6 loopback) and a query for A records should occur
      only if the node has at least one IPv4 address configured (other
      than the IPv4 loopback).
      例えば、 DNSを使う時にAAAAレコードの質問はノードが少なくと
      も1つの(IPv6ループバック以外の)設定されたIPv6アドレス
      を持っている場合に限り起こり、そしてAレコードの質問がノードが少
      なくとも1つの(IPv4ループバック以外の)設定されたIPv4ア
      ドレスを持っている場合に限り起こるべきです。

   The ai_socktype field to which argument hints points specifies the
   socket type for the service, as defined for socket().  If a specific
   socket type is not given (for example, a value of zero) and the
   service name could be interpreted as valid with multiple supported
   socket types, the implementation shall attempt to resolve the service
   name for all supported socket types and, in the absence of errors,
   all possible results shall be returned.  A non-zero socket type value
   shall limit the returned information to values with the specified
   socket type.
   hints引数が示すai_socktypeフィールドは、socket()のために定義されるサー
   ビスのためのソケットタイプを指定します。もし特定のソケットタイプが与
   えられなければ(例えば、ゼロの値)、そしてサービス名が多数のサポート
   されたソケットタイプで正当であると解釈できたなら、実装はすべてのサポー
   トされたソケットタイプのためにサービス名を変換しようと試みるべきです、
   そして、エラーがなければ、すべての可能な結果は返されるべきです。ゼロ
   以外のソケットタイプ値は、返される情報を指定されたソケットタイプの値
   を持つものに制限するべきです。

   If the ai_family field to which hints points has the value AF_UNSPEC,
   addresses shall be returned for use with any address family that can
   be used with the specified nodename and/or servname.  Otherwise,
   addresses shall be returned for use only with the specified address
   family.  If ai_family is not AF_UNSPEC and ai_protocol is not zero,
   then addresses are returned for use only with the specified address
   family and protocol; the value of ai_protocol shall be interpreted as
   in a call to the socket() function with the corresponding values of
   ai_family and ai_protocol.
   もしhintsが示すai_familyフィールドがAF_UNSPECであるなら、指定された
   ノード名とサービス名が使えるアドレスファミリーで使うためのアドレスが
   返されるべきです。さもなければ、指定されたアドレスファミリーでだけ使
   用するためのアドレスが返されるべきです。もしai_familyがAF_UNSPECでな
   く、ai_protocolがゼロでないなら、指定されたアドレスファミリーとプロト
   コルでだけ使用のためのアドレスが返されます;ai_protocol値はsocket()呼
   出でai_familyとai_protocolの対応する値に翻訳されるべきです。

   The freeaddrinfo() function frees one or more addrinfo structures
   returned by getaddrinfo(), along with any additional storage
   associated with those structures (for example, storage pointed to by
   the ai_canonname and ai_addr fields; an application must not
   reference this storage after the associated addrinfo structure has
   been freed).  If the ai_next field of the structure is not null, the
   entire list of structures is freed.  The freeaddrinfo() function must
   support the freeing of arbitrary sublists of an addrinfo list
   originally returned by getaddrinfo().
   freeaddrinfo()関数はgetaddrinfo()で返された1つ以上のアドレス構造体を
   構造体に関連する追加の記憶領域と共に開放します(例えば、ai_canonname
   とai_addrフィールドの示すメモリ;アプリケーションが関連したaddrinfo構
   造体が開放された後でこのメモリを参照してはなりません)。もし構造体の
   ai_nextフィールドがゼロではないなら、構造体の全部のリストが開放されま
   す。freeaddrinfo()関数はgetaddrinfo()によって返されたaddrinfoリストの
   任意の部分リストの開放をサポートしなくてはなりません。

   Functions getaddrinfo() and freeaddrinfo() must be thread-safe.
   getaddrinfo()とfreeaddrinfo()関数がスレッドで安全に違いありません。

   A zero return value for getaddrinfo() indicates successful
   completion; a non-zero return value indicates failure.  The possible
   values for the failures are listed below under Error Return Values.
   getaddrinfo()のゼロの戻り値が成功した完了を示します;ゼロ以外の戻り値
   が失敗を示します。失敗の可能な値はエラーリターン値の下でリストアップ
   されます。

   Upon successful return of getaddrinfo(), the location to which res
   points shall refer to a linked list of addrinfo structures, each of
   which shall specify a socket address and information for use in
   creating a socket with which to use that socket address.  The list
   shall include at least one addrinfo structure.  The ai_next field of
   each structure contains a pointer to the next structure on the list,
   or a null pointer if it is the last structure on the list.  Each
   structure on the list shall include values for use with a call to the
   socket() function, and a socket address for use with the connect()
   function or, if the AI_PASSIVE flag was specified, for use with the
   bind() function.  The fields ai_family, ai_socktype, and ai_protocol
   shall be usable as the arguments to the socket() function to create a
   socket suitable for use with the returned address.  The fields
   ai_addr and ai_addrlen are usable as the arguments to the connect()
   or bind() functions with such a socket, according to the AI_PASSIVE
   flag.
   getaddrinfo()が成功して戻ると、resの示す場所はaddrinfo構造体リンクリ
   ストを参照し、それぞれのaddrinfo構造体はソケットを作るのに使うソケッ
   トアドレスと情報を指定するべきです。リストは少なくとも1つのaddrinfo
   構造体を含むべきです。それぞれの構造体のai_nextフィールドはリストの
   次の構造体を示し、もしそれがリストの上に最後の構造体であるならヌルポ
   インタです。リスト上の各構造体がsocket()関数で使用するための値、と
   connect()関数で使うための、または、もしAI_PASSIVEフラグが指定される
   なら、bind()関数で使用するためのソケットアドレスを含むべきです。
   ai_familyとai_socktypeとai_protocolフィールドは、返されたアドレスで
   使用するに適したソケットを作るsocket()関数の引数として有用であるべき
   です。AI_PASSIVEフラグに依存して、ai_addrとai_addrlenフィールドは各
   ソケットのconnect()かbind()関数の引数に有用です。

   If nodename is not null, and if requested by the AI_CANONNAME flag,
   the ai_canonname field of the first returned addrinfo structure shall
   point to a null-terminated string containing the canonical name
   corresponding to the input nodename; if the canonical name is not
   available, then ai_canonname shall refer to the nodename argument or
   a string with the same contents.  The contents of the ai_flags field
   of the returned structures are undefined.
   もしノード名がヌルでなく、そしてもしAI_CANONNAMEフラグによって求めら
   れる、最初の返されたaddrinfo構造体のai_canonnameフィールドが入力ノー
   ド名に対応した規準名を含むヌルで終わる文字列を示します;もし規準名が
   利用可能ではないなら、ai_canonnameがノード名引数か同じ中身での文字列
   を参照するべきです。返された構造体のai_flagsフィールドの内容は不確定
   です。

   All fields in socket address structures returned by getaddrinfo()
   that are not filled in through an explicit argument (for example,
   sin6_flowinfo) shall be set to zero.
   明示的な引数(例えば、sin6_flowinfo)を通して記入されたの以外のすべて
   のgetaddrinfo()によって返されたソケットアドレス構造体のフィールドはゼ
   ロに設定されるべきです。

   Note: This makes it easier to compare socket address structures.
   メモ:これはソケットアドレス構造体を比較することをより容易にします。

   Error Return Values:
   エラーリターン値:

   The getaddrinfo() function shall fail and return the corresponding
   value if:
   getaddrinfo()関数は次の場合失敗し、対応する値を返すべきです:

   [EAI_AGAIN]     The name could not be resolved at this time.  Future
                   attempts may succeed.
                   現在名前解決ができませんでした。将来の試みが成功する
                   かもしれません。

   [EAI_BADFLAGS]  The flags parameter had an invalid value.
                   フラグパラメータは無効な値を持っていました。

   [EAI_FAIL]      A non-recoverable error occurred when attempting to
                   resolve the name.
                   名前を変換しようと試みる時に回復可能でないエラーが起
                   こりました。

   [EAI_FAMILY]    The address family was not recognized.
                   アドレスファミリーは認識できませんでした。

   [EAI_MEMORY]    There was a memory allocation failure when trying to
                   allocate storage for the return value.
                   戻り値のメモリを割り当てようとする時、メモリ障害があ
                   りました。

   [EAI_NONAME]    The name does not resolve for the supplied
                   parameters.  Neither nodename nor servname were
                   supplied.  At least one of these must be supplied.
                   供給されたパラメータのための名前が解決できません。ノー
                   ド名とサービス名のいずれも供給されませんでした。少な
                   くともこれらの1つが供給されなくてはなりません。

   [EAI_SERVICE]   The service passed was not recognized for the
                   specified socket type.
                   渡されたサービスは指定されたソケットタイプに対して認
                   識できませんでした。

   [EAI_SOCKTYPE]  The intended socket type was not recognized.
                   意図するソケットタイプは認識できませんでした。

   [EAI_SYSTEM]    A system error occurred; the error code can be found
                   in errno.
                   システムエラーが起こりました;エラーコードはerrnoで見
                   つかります。

   The gai_strerror() function provides a descriptive text string
   corresponding to an EAI_xxx error value.
   gai_strerror()関数はEAI_xxx エラー値に対応している記述的なテキスト文
   字列を供給します。

      #include <netdb.h>

      const char *gai_strerror(int ecode);

   The argument is one of the EAI_xxx values defined for the
   getaddrinfo() and getnameinfo() functions.  The return value points
   to a string describing the error.  If the argument is not one of the
   EAI_xxx values, the function still returns a pointer to a string
   whose contents indicate an unknown error.
   引数はgetaddrinfo()とgetnameinfo()関数のために定義されたEAI_xxx値の
   1つです。戻り値はエラーを記述している文字列を指し示します。もし引数
   がEAI_xxx値の1つではないなら、関数は未知のエラーを示す文字列へのポ
   インタを返します。

6.2 Socket Address Structure to Node Name and Service Name
6.2 ノード名とサービス名へのソケットアドレス構造体

   The getnameinfo() function is used to translate the contents of a
   socket address structure to a node name and/or service name.
   getnameinfo()関数はソケットアドレス構造体の内容をノード名やサービス
   名に翻訳するために使われます。

   #include <sys/socket.h>
   #include <netdb.h>

   int getnameinfo(const struct sockaddr *sa, socklen_t salen,
                       char *node, socklen_t nodelen,
                       char *service, socklen_t servicelen,
                         int flags);

   The getnameinfo() function shall translate a socket address to a node
   name and service location, all of which are defined as in
   getaddrinfo().
   getnameinfo()関数はソケットアドレスをノード名前とサービスの場所に翻訳
   するべきです、そしてそのすべてはgetaddrinfo() のように定義されます。

   The sa argument points to a socket address structure to be
   translated.
   sa引数は翻訳されるソケットアドレス構造体を示します。

   The salen argument holds the size of the socket address structure
   pointed to by sa.
   salen引数はsaで示されたソケットアドレス構造体の大きさを示します。

   If the socket address structure contains an IPv4-mapped IPv6 address
   or an IPv4-compatible IPv6 address, the implementation shall extract
   the embedded IPv4 address and lookup the node name for that IPv4
   address.
   もしソケットアドレス構造体がIPv4マップIPv6アドレスあるいはI
   Pv4互換IPv6アドレスを含んでいるなら、実装は埋め込みIPv4ア
   ドレスを引き抜いて、そしてそのIPv4アドレスのノード名を検索するべ
   きです。

      Note: The IPv6 unspecified address ("::") and the IPv6 loopback
      address ("::1") are not IPv4-compatible addresses.  If the address
      is the IPv6 unspecified address ("::"), a lookup is not performed,
      and the [EAI_NONAME] error is returned.
      ノート:特定されていないIPv6アドレス("::")そしてIPv6ルー
      プバックアドレス("::1")はIPv4互換アドレスでありません。もし
      アドレスがIPv6の特定されていないアドレスであるなら("::")、検
      索行われず、そして[EAI_NONAME]エラーが返されます。

   If the node argument is non-NULL and the nodelen argument is nonzero,
   then the node argument points to a buffer able to contain up to
   nodelen characters that receives the node name as a null-terminated
   string.  If the node argument is NULL or the nodelen argument is
   zero, the node name shall not be returned.  If the node's name cannot
   be located, the numeric form of the node's address is returned
   instead of its name.
   もしnode引数がヌルではなく、そしてnodelen引数がゼロ以外であるなら、
   node引数はnodelen文字以下のヌルで終了する文字列としてノード名を受け取
   ることが可能なバッファを指し示します。もしnode引数が空であるか、ある
   いはnodelen引数がゼロであるなら、ノード名は返されるべきではありません。
   もしノードの名前がなければ、ノードのアドレスの数値形式が名前の代わり
   に返されます。

   If the service argument is non-NULL and the servicelen argument is
   non-zero, then the service argument points to a buffer able to
   contain up to servicelen bytes that receives the service name as a
   null-terminated string.  If the service argument is NULL or the
   servicelen argument is zero, the service name shall not be returned.
   If the service's name cannot be located, the numeric form of the
   service address (for example, its port number) shall be returned
   instead of its name.
   もしservice引数がヌルではなく、servicelen引数がゼロ以外であるなら、
   service引数はservicelen文字以下のヌルで終了する文字列のサービス名を受
   け取ることが可能なバッファを指し示します。もしservice引数がヌルである
   か、あるいはservicelen引数がゼロであるなら、サービス名は返されるべき
   ではありません。もしサービス名が見つからないなら、サービスアドレスの
   数値形式(例えば、そのポート番号)がその名前の代わりに返されるべきで
   す。

   The arguments node and service cannot both be NULL.
   node引数とservice引数が共にヌルであるはずがありません。

   The flags argument is a flag that changes the default actions of the
   function.  By default the fully-qualified domain name (FQDN) for the
   host shall be returned, but:
   flags引数は関数のデフォルト行動を変えるフラグです。デフォルトで、ホス
   トの完全修飾ドメイン名(FQDN)が返されるべきです、しかし:

   -  If the flag bit NI_NOFQDN is set, only the node name portion of
      the FQDN shall be returned for local hosts.
   -  もしflagビットNI_NOFQDNが設定されるなら、ローカルホストについて、
      ただFQDNのノード名の部分だけが返されるべきです。

   -  If the flag bit NI_NUMERICHOST is set, the numeric form of the
      host's address shall be returned instead of its name, under all
      circumstances.
   -  もしflagビットNI_NUMERICHOSTが設定されるなら、ホストアドレスの数値
      形式が名前の代わりにすべての状況下で返されるべきです。

   -  If the flag bit NI_NAMEREQD is set, an error shall be returned if
      the host's name cannot be located.
   -  もしflagビットNI_NAMEREQDが設定され、もしホスト名が見つからないな
      ら、エラーが返されるべきです。

   -  If the flag bit NI_NUMERICSERV is set, the numeric form of the
      service address shall be returned (for example, its port number)
      instead of its name, under all circumstances.
   -  もしflagビットNI_NUMERICSERVが設定されるなら、全ての状況下で名前の
      代わりにサービスアドレスの数値形式が返されるべきです(例えばポート
      番号)。

   -  If the flag bit NI_DGRAM is set, this indicates that the service
      is a datagram service (SOCK_DGRAM).  The default behavior shall
      assume that the service is a stream service (SOCK_STREAM).
   -  もしflagビットNI_DGRAMが設定されるなら、これはサービスがデータグラ
      ムサービス(SOCK_DGRAM)であることを示します。デフォルト行動はサー
      ビスがフローサービス(SOCK_STREAM)であると想定するべきです。

   Note:
   ノート:

   1. The NI_NUMERICxxx flags are required to support the "-n" flags
      that many commands provide.
   1. NI_NUMERICxxxフラグは多くのコマンドが供給する"-n"フラグをサポート
      するように要求されます。

   2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6
      port numbers (for example, [512,514]) that represent different
      services for UDP and TCP.
   2. NI_DGRAMフラグはUDPとTCPで異なったサービス表現を務める少数
      のAF_INETとAF_INET6ポート番号(例えば、[512,514])のために必要と
      されます。

   The getnameinfo() function shall be thread safe.
   getnameinfo()関数はスレッドで安全であるべきです。

   A zero return value for getnameinfo() indicates successful
   completion; a non-zero return value indicates failure.
   getnameinfo()のゼロの返り値が成功した終了を示します;ゼロ以外の返り値
   が失敗を示します。

   Upon successful completion, getnameinfo() shall return the node and
   service names, if requested, in the buffers provided.  The returned
   names are always null-terminated strings.
   成功した場合、getnameinfo()は、もし求められるなら、供給されたバッファ
   でノード名とサービス名を提供するべきです。返された名前は常にヌルで終
   了する文字列です。

   Error Return Values:
   エラー返り値:

   The getnameinfo() function shall fail and return the corresponding
   value if:
   getnameinfo()関数は以下の場合に失敗し、対応する値を返すべきです:

   [EAI_AGAIN]    The name could not be resolved at this time.
                  Future attempts may succeed.
                  名前は今は解決できませんでした。将来の試みが成功するか
                  もしれません。

   [EAI_BADFLAGS] The flags had an invalid value.
                  フラグは無効な値です。

   [EAI_FAIL]     A non-recoverable error occurred.
                  回復可能でないエラーが起こりました。

   [EAI_FAMILY]   The address family was not recognized or the address
                  length was invalid for the specified family.
                  アドレスファミリーは認識できませんでした、あるいはアド
                  レス長は指定されたファミリーで無効でした。

   [EAI_MEMORY]   There was a memory allocation failure.
                  メモリ割当て障害がありました。

   [EAI_NONAME]   The name does not resolve for the supplied parameters.
                  NI_NAMEREQD is set and the host's name cannot be
                  located, or both nodename and servname were null.
                  供給されたパラメータのための名前は認識できません。
                  NI_NAMEREQDが設定され、ホスト名がないか、nodenameと
                  servnameの両方がヌルでした。

   [EAI_OVERFLOW] An argument buffer overflowed.
                  引数バッファがあふれました。

   [EAI_SYSTEM]   A system error occurred.  The error code can be found
                  in errno.
                  システムエラーが起こりました。エラーコードはerrnoで見
                  いださます。

6.3 Address Conversion Functions
6.3 アドレス変換関数

   The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4
   address between binary and text form.  IPv6 applications need similar
   functions.  The following two functions convert both IPv6 and IPv4
   addresses:
   2つのIPv4関数inet_addr()とinet_ntoa()はバイナリとテキスト形式の
   間でIPv4アドレスを変えます。IPv6アプリケーションが類似の関数
   を必要とします。次の2つの関数はIPv6とIPv4アドレスの両方を変
   換します:

   #include <arpa/inet.h>

   int inet_pton(int af, const char *src, void *dst);

   const char *inet_ntop(int af, const void *src,
                            char *dst, socklen_t size);

   The inet_pton() function shall convert an address in its standard
   text presentation form into its numeric binary form.  The af argument
   shall specify the family of the address.  The AF_INET and AF_INET6
   address families shall be supported.  The src argument points to the
   string being passed in.  The dst argument points to a buffer into
   which the function stores the numeric address; this shall be large
   enough to hold the numeric address (32 bits for AF_INET, 128 bits for
   AF_INET6).  The inet_pton() function shall return 1 if the conversion
   succeeds, with the address pointed to by dst in network byte order.
   It shall return 0 if the input is not a valid IPv4 dotted-decimal
   string or a valid IPv6 address string, or -1 with errno set to
   EAFNOSUPPORT if the af argument is unknown.
   inet_pton()関数は標準テキスト表現形式でのアドレスをその数値バイナリー
   形式に変換するべきです。af引数はアドレスファミリーを指定するべきです。
   AF_INETとAF_INET6アドレスファミリーがサポートされるべきです。文字列を
   示すsrc引数が渡されます。dst引数は関数が数値アドレスを記載するバッファ
   を指し示します;これは数値アドレス(AF_INETで32ビット、AF_INET6 で
   128ビット)を持つのに十分な大きさであるべきです。inet_pton()関数は、
   もし変換が、ネットワークバイト順でdstによって指し示されたアドレスで、
   成功するなら、1を返すべきです。それは、もし入力が正当なIPv4ドッ
   ト区切り10進数文字列か正当なIPv6アドレス文字列でないなら0を返
   し、引数が未知ならかerrnoにEAFNOSUPPORTを設定し−1を返すべきです。

   If the af argument of inet_pton() is AF_INET, the src string shall be
   in the standard IPv4 dotted-decimal form:
   もしinet_pton()のaf引数がAF_INETであるなら、src文字列は標準的IPv4
   ドット区切り形式であるべきです:

      ddd.ddd.ddd.ddd

   where "ddd" is a one to three digit decimal number between 0 and 255.
   The inet_pton() function does not accept other formats (such as the
   octal numbers, hexadecimal numbers, and fewer than four numbers that
   inet_addr() accepts).
   「ddd」が0と255の間の1桁から3桁の数です。inet_pton()関数は
   (inet_addr()が受け入れる、8進数や16進数や4つ未満の数など)他の
   フォーマットを受け入れません。

   If the af argument of inet_pton() is AF_INET6, the src string shall
   be in one of the standard IPv6 text forms defined in Section 2.2 of
   the addressing architecture specification [2].
   もしinet_pton()のaf引数がAF_INET6であるなら、src文字列がアドレス体系
   仕様[2]の2.2章で定義される標準IPv6テキスト形式の1つであるべき
   です。

   The inet_ntop() function shall convert a numeric address into a text
   string suitable for presentation.  The af argument shall specify the
   family of the address.  This can be AF_INET or AF_INET6.  The src
   argument points to a buffer holding an IPv4 address if the af
   argument is AF_INET, or an IPv6 address if the af argument is
   AF_INET6; the address must be in network byte order.  The dst
   argument points to a buffer where the function stores the resulting
   text string; it shall not be NULL.  The size argument specifies the
   size of this buffer, which shall be large enough to hold the text
   string (INET_ADDRSTRLEN characters for IPv4, INET6_ADDRSTRLEN
   characters for IPv6).
   inet_ntop()関数は数値アドレスを表示に適したテキスト文字列に変換するべ
   きです。af引数はアドレスファミリーを指定するべきです。これはAF_INETや
   AF_INET6であり得ます。src引数は、もしaf引数がAF_INETならばIPv4ア
   ドレスを設定したバッファを示し、af引数がAF_INET6であるならIPv6ア
   ドレスを設定したバッファを示します;アドレスはネットワークバイト順で
   あるに違いありません。dst引数は関数が生成するテキスト文字列をストアす
   るバッファを指し示します;それはヌルであるべきではありません。size引
   数はこのバッファの大きさを指定し、これはテキスト文字列を持つのに十分
   な大きさであるべきです(IPv4でINET_ADDRSTRLEN文字、IPv6で
   INET6_ADDRSTRLEN文字)。

   In order to allow applications to easily declare buffers of the
   proper size to store IPv4 and IPv6 addresses in string form, the
   following two constants are defined in <netinet/in.h>:
   アプリケーションが容易にIPv4とIPv6アドレスの文字列形式に適切
   な大きさのバッファを宣言することを許すために、次の2つの定数が
   <netinet/in.h>で定義されます:

      #define INET_ADDRSTRLEN    16
      #define INET6_ADDRSTRLEN   46

   The inet_ntop() function shall return a pointer to the buffer
   containing the text string if the conversion succeeds, and NULL
   otherwise.  Upon failure, errno is set to EAFNOSUPPORT if the af
   argument is invalid or ENOSPC if the size of the result buffer is
   inadequate.
   inet_ntop()関数は、もし変換が成功するなら、テキスト文字列を含むバッ
   ファへのポインタを返し、さもなければヌルを返すべきです。失敗した場合、
   もしaf引数が不適当ならerrnoにEAFNOSUPPORTが設定され、もし結果バッファ
   のサイズが不適当であるならerrnoにENOSPCが設定されます。

6.4 Address Testing Macros
6.4 アドレステストマクロ

   The following macros can be used to test for special IPv6 addresses.
   次のマクロは特別なIPv6アドレスのテストをするために使うことができ
   ます。

   #include <netinet/in.h>

   int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
   int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
   int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
   int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
   int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
   int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
   int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);

   int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
   int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
   int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
   int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
   int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);

   The first seven macros return true if the address is of the specified
   type, or false otherwise.  The last five test the scope of a
   multicast address and return true if the address is a multicast
   address of the specified scope or false if the address is either not
   a multicast address or not of the specified scope.
   最初の7つのマクロはもしアドレスが指定されたタイプのであるなら真で、
   さもなければ偽で戻ります。後の5つがマルチキャストアドレスの範囲をテ
   ストし、そしてもしアドレスが指定された範囲のマルチキャストアドレスで
   あるなら真で、もしアドレスがマルチキャストアドレスでないか指定された
   範囲でなければ偽です。

   Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true
   only for the two types of local-use IPv6 unicast addresses (Link-
   Local and Site-Local) defined in [2], and that by this definition,
   the IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback
   address (::1).  These two macros do not return true for IPv6
   multicast addresses of either link-local scope or site-local scope.
   IN6_IS_ADDR_LINKLOCALとIN6_IS_ADDR_SITELOCALは[2]で定義される2種類の
   ローカル使用のIPv6ユニキャストアドレス(リンクローカルとサイトロー
   カル)でだけ真で、定義からIN6_IS_ADDR_LINKLOCALまくりはIPv6ループ
   バックアドレス(::1)に対して偽である事に注してください。これらの2つ
   のマクロはリンクローカル範囲あるいはサイトローカル範囲のIPv6マル
   チキャストアドレスについて、真ではありません。

7. Summary of New Definitions
7. 新しい定義の要約

   The following list summarizes the constants, structure, and extern
   definitions discussed in this memo, sorted by header.
   次のリストはこの文書で論じた定数と構造体と外部定義をヘッダ順で要約し
   ます。

<net/if.h>      IF_NAMESIZE
<net/if.h>      struct if_nameindex{};

<netdb.h>       AI_ADDRCONFIG
<netdb.h>       AI_ALL
<netdb.h>       AI_CANONNAME
<netdb.h>       AI_NUMERICHOST
<netdb.h>       AI_NUMERICSERV
<netdb.h>       AI_PASSIVE
<netdb.h>       AI_V4MAPPED

<netdb.h>       EAI_AGAIN
<netdb.h>       EAI_BADFLAGS
<netdb.h>       EAI_FAIL
<netdb.h>       EAI_FAMILY
<netdb.h>       EAI_MEMORY
<netdb.h>       EAI_NONAME
<netdb.h>       EAI_OVERFLOW
<netdb.h>       EAI_SERVICE
<netdb.h>       EAI_SOCKTYPE
<netdb.h>       EAI_SYSTEM
<netdb.h>       NI_DGRAM
<netdb.h>       NI_NAMEREQD
<netdb.h>       NI_NOFQDN
<netdb.h>       NI_NUMERICHOST
<netdb.h>       NI_NUMERICSERV
<netdb.h>       struct addrinfo{};

<netinet/in.h>  IN6ADDR_ANY_INIT
<netinet/in.h>  IN6ADDR_LOOPBACK_INIT
<netinet/in.h>  INET6_ADDRSTRLEN
<netinet/in.h>  INET_ADDRSTRLEN
<netinet/in.h>  IPPROTO_IPV6
<netinet/in.h>  IPV6_JOIN_GROUP
<netinet/in.h>  IPV6_LEAVE_GROUP
<netinet/in.h>  IPV6_MULTICAST_HOPS
<netinet/in.h>  IPV6_MULTICAST_IF
<netinet/in.h>  IPV6_MULTICAST_LOOP
<netinet/in.h>  IPV6_UNICAST_HOPS
<netinet/in.h>  IPV6_V6ONLY
<netinet/in.h>  SIN6_LEN
<netinet/in.h>  extern const struct in6_addr in6addr_any;
<netinet/in.h>  extern const struct in6_addr in6addr_loopback;
<netinet/in.h>  struct in6_addr{};
<netinet/in.h>  struct ipv6_mreq{};
<netinet/in.h>  struct sockaddr_in6{};

<sys/socket.h>  AF_INET6
<sys/socket.h>  PF_INET6
<sys/socket.h>  struct sockaddr_storage;

   The following list summarizes the function and macro prototypes
   discussed in this memo, sorted by header.
   次のリストはこの文書で論じられた関数とマクロプロトタイプをヘッダ順に
   要約します。

<arpa/inet.h>   int inet_pton(int, const char *, void *);
<arpa/inet.h>   const char *inet_ntop(int, const void *,
                               char *, socklen_t);

<net/if.h>      char *if_indextoname(unsigned int, char *);
<net/if.h>      unsigned int if_nametoindex(const char *);
<net/if.h>      void if_freenameindex(struct if_nameindex *);

<net/if.h>      struct if_nameindex *if_nameindex(void);

<netdb.h>       int getaddrinfo(const char *, const char *,
                                const struct addrinfo *,
                                struct addrinfo **);
<netdb.h>       int getnameinfo(const struct sockaddr *, socklen_t,
                  char *, socklen_t, char *, socklen_t, int);
<netdb.h>       void freeaddrinfo(struct addrinfo *);
<netdb.h>       const char *gai_strerror(int);

<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);

8. Security Considerations
8. セキュリティの考察

   IPv6 provides a number of new security mechanisms, many of which need
   to be accessible to applications.  Companion memos detailing the
   extensions to the socket interfaces to support IPv6 security are
   being written.
   IPv6が多くの新しいセキュリティ機構を供給し、その多くはアプリケー
   ションでアクセスできる必要があります。IPv6セキュリティをサポート
   するためにソケットインタフェースへの拡張を詳述している関連文書が書か
   れています。

9. Changes from RFC 2553
9. RFC2553からの変更

   1. Add brief description of the history of this API and its relation
      to the Open Group/IEEE/ISO standards.
   1. このAPIの歴史とオープングループ/IEEE/ISO標準にの短い記
      述を追加。

   2. Alignments with [3].
   2. [3]の整列。

   3. Removed all references to getipnodebyname() and getipnodebyaddr(),
      which are deprecated in favor of getaddrinfo() and getnameinfo().
   3. getaddrinfo()とgetnameinfo()の支持に伴い不要になった
      getipnodebyname()とgetipnodebyaddr()への参照を廃止。

   4. Added IPV6_V6ONLY IP level socket option to permit nodes to not
      process IPv4 packets as IPv4 Mapped addresses in implementations.
   4. ノードが実装でIPv4としてIPv4パケットを処理しないのを許す
      IPレベルのIPV6_V6ONLYソケットオプションを追加。

   5. Added SIIT to references and added new contributors.
   5. SIITへの参照の追加と、新しい貢献者を追加。

   6. In previous versions of this specification, the sin6_flowinfo
      field was associated with the IPv6 traffic class and flow label,
      but its usage was not completely specified.  The complete
      definition of the sin6_flowinfo field, including its association
      with the traffic class or flow label, is now deferred to a future
      specification.
   6. この仕様書の前の版でsin6_flowinfoフィールドはIPv6トラフィック
      クラスとフローラベルに結び付けられました、しかしその使用法は完全に
      指定されませんでした。sin6_flowinfoフィールドの完全な定義は、その
      トラフィッククラスあるいはフローラベルとの連想を含めて、未来の仕様
      書に今延期されます。

10. Acknowledgments
10. 謝辞

   This specification's evolution and completeness were significantly
   influenced by the efforts of Richard Stevens, who has passed on.
   Richard's wisdom and talent made the specification what it is today.
   The co-authors will long think of Richard with great respect.
   この仕様書の進展と完全性はとてもリチャード・スティーブンスの努力によっ
   て影響を与えられました。リチャードの賢明さと才能は仕様書を今日あるも
   のにしました。共著者は大きい敬意でリチャードについて考えるでしょう。

   Thanks to the many people who made suggestions and provided feedback
   to this document, including:
   この文書の提案とフィードバックを供給した多くの人々に感謝します:

   Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew
   Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves,
   Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino,
   Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema,
   Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan
   McDonald, Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne,
   Craig Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos,
   Keith Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey
   Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie,
   David Waitzman, Carl Williams, Kazu Yamamoto, Vlad Yasevich, Stig
   Venaas, and Brian Zill.

   The getaddrinfo() and getnameinfo() functions are taken from an
   earlier document by Keith Sklower.  As noted in that document,
   William Durst, Steven Wise, Michael Karels, and Eric Allman provided
   many useful discussions on the subject of protocol-independent name-
   to-address translation, and reviewed early versions of Keith
   Sklower's original proposal.  Eric Allman implemented the first
   prototype of getaddrinfo().  The observation that specifying the pair
   of name and service would suffice for connecting to a service
   independent of protocol details was made by Marshall Rose in a
   proposal to X/Open for a "Uniform Network Interface".
   getaddrinfo()とgetnameinfo()関数はKeith Sklowerによる古い文書からとら
   れます。その文書で述べたように、William DurstとSteven WiseとMichael
   KarelsとEric Allmanはプロトコルに依存しない名前−アドレス翻訳問題につ
   いて多くの有用な論議を供給し、Keith Sklowerのオリジナルの提案の古い
   バージョンを再検討しました。Eric Allmanはgetaddrinfo()の最初のプロト
   タイプを実装しました。プロトコル詳細から独立してサービス接続すること
   に対して、名前とサービスの2つを指定することで十分であろうという発言
   は「一様ネットワークインタフェース」のためのX/Open提案でMarshall Rose
   によってされました。

   Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
   Kacker made many contributions to this document.  Ramesh Govindan
   made a number of contributions and co-authored an earlier version of
   this memo.
   Craig MetzとJack McCannとErik NordmarkとTim HartrickとMukesh Kackerは
   この文書に多くの貢献をしました。Ramesh Govindanは多くの貢献をして、こ
   の文書の前の版を共同執筆しました。

11. References
11. 参考文献

   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

   [3]  IEEE Std. 1003.1-2001 Standard for Information Technology --
        Portable Operating System Interface (POSIX). Open Group
        Technical Standard: Base Specifications, Issue 6, December 2001.
        ISO/IEC 9945:2002.  http://www.opengroup.org/austin

   [4]  Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
        2292, February 1998.

   [5]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
        RFC 2765, February 2000.

   [6]  The Open Group Base Working Group
        http://www.opengroup.org/platform/base.html


12. Authors' Addresses
12. 著者のアドレス

   Bob Gilligan
   Intransa, Inc.
   2870 Zanker Rd.
   San Jose, CA 95134

   Phone: 408-678-8647
   EMail: gilligan@intransa.com


   Susan Thomson
   Cisco Systems
   499 Thornall Street, 8th floor
   Edison, NJ 08837

   Phone: 732-635-3086
   EMail:  sethomso@cisco.com


   Jim Bound
   Hewlett-Packard Company
   110 Spitbrook Road ZKO3-3/W20
   Nashua, NH 03062

   Phone: 603-884-0062
   EMail: Jim.Bound@hp.com


   Jack McCann
   Hewlett-Packard Company
   110 Spitbrook Road ZKO3-3/W20
   Nashua, NH 03062

   Phone: 603-884-2608
   EMail: Jack.McCann@hp.com


13. Full Copyright Statement
13. 著作権表示全文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.
   著作権(C)インターネット学会(2003)。すべての権利は保留される。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
   この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
   を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
   版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
   ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
   や他のインターネット組織は著作権表示や参照を削除されるような変更がで
   きません、インターネット標準を開発する場合はインターネット標準化プロ
   セスで定義された著作権の手順に従われます。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   上に与えられた限定された許可は永久で、インターネット学会やその後継者
   や譲渡者によって無効にされません。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So