この文書はRFC3493の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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
ＩＰｖ６のための基本ソケットインターフェース拡張
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.
ＴＣＰ／ＩＰアプリケーションのためのデファクトの標準アプリケーション
プログラムインタフェース（ＡＰＩ）は「ソケット」インタフェースです。
このＡＰＩが１９８０年代初期にＵＮＩＸのために開発されたけれども、多
種多様な非ＵＮＩＸのシステム上に実装されました。ソケットＡＰＩを使っ
て書かれたＴＣＰ／ＩＰアプリケーションが過去に高度のポータビリティを
享受しました、そして我々はＩＰｖ６アプリケーションで同じポータビリ
ティを欲します。けれどもＩＰｖ６をサポートするのにソケットＡＰＩの変
更が要求され、そしてこのメモはこれらの変更を記述します。これらはＩＰ
ｖ６アドレス、新しいアドレス変換機能とある新しいソケットオプションを
伴うための新しいソケットアドレス構造を含みます。これらの拡張は、既存
のＩＰｖ４アプリケーションに完全な互換性を提供したまま、導入のための
変更を最小限に抑えて、ＴＣＰとＵＤＰアプリケーションに必要な基本的な
ＩＰｖ６機能へのアクセスを供給するよう意図されます。高等ＩＰｖ６機能
のための追加の拡張（生ソケットとＩＰｖ６拡張ヘッダーへのアクセス）が
他の文書で定義されます。
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 ＩＰｖ６アドレス構造体
3.3 Socket Address Structure for 4.3BSD-Based Systems
3.3 ４.３ＢＳＤベースシステムのソケットアドレス構造体
3.4 Socket Address Structure for 4.4BSD-Based Systems
3.4 ４.４ＢＳＤベースシステムのソケットアドレス構造体
3.5 The Socket Functions
3.5 ソケット関数
3.6 Compatibility with IPv4 Applications
3.6 ＩＰｖ４アプリケーションとの互換性
3.7 Compatibility with IPv4 Nodes
3.7 ＩＰｖ４ノードとの互換性
3.8 IPv6 Wildcard Address
3.8 ＩＰｖ６ワイルドカードアドレス
3.9 IPv6 Loopback Address
3.9 ＩＰｖ６ループバックアドレス
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. ＲＦＣ２５５３からの変更
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.
ＩＰｖ４アドレスが長さが３２ビットであるが、ＩＰｖ６インタフェースが
１２８ビットのアドレスです。ソケットインタフェースはＩＰアドレスの大
きさをアプリケーションにはっきり見せます；ほとんどすべてのＴＣＰ／Ｂ
ＳＤベースのシステムのＩＰアプリケーションがＩＰアドレスの大きさの知
識を持っています。アドレスを露出するＡＰＩのそれらの部分がより大きい
ＩＰｖ６アドレス大きさを収容するために変えなくてはなりません。ＩＰｖ６
が新しい機能を導入します、そしてそのいくつかはＡＰＩによってアプリケー
ションに見えなくてはなりません。このメモはより大きいアドレスサイズと
ＩＰｖ６の新しい機能をサポートするためのソケットインタフェースへの拡
張を定義します。これは広い範囲のアプリケーションに役に立つ「基本」拡
張を定義します。関連文書、「高等」ＡＰＩ[4]が、例えばルーティングデー
モンや「ｐｉｎｇ」と「ｔｒａｃｅｒｏｕｔｅ」ユーティリティーを含む、
より専門的アプリケーションに役つ拡張をカバーします。
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.
このＡＰＩの開発はＩＥＴＦのＩＰｎｇワーキンググループで１９９４年に
始められました。ＡＰＩは数年間かけて進展し、ＲＦＣ２１３３で最初に、
そしてＲＦＣ２５５３で再び発表され、そしてこの文書で最終形式になりま
した。
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].
ＡＰＩが成熟し安定したので、こはオープングループのネットワーキングサー
ビス（ＸＮＳ）仕様書、５.２版、に取り入れられ、その後共同オープングルー
プ／ＩＥＥＥ／ＩＳＯ標準[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]がＡＰＩ定義に関して同じ情報を含んでいることを保証するた
めの取り組みがされました。しかしながら、読者はこの文書が情報的な目的
のみのためであるり、そしてソケットＡＰＩの公式標準仕様書が[3]であるこ
とを指摘するべきです。
It is expected that any future standardization work on this API would
be done by the Open Group Base Working Group [6].
このＡＰＩの未来の標準化の仕事がオープングループベースワーキンググルー
プ[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.
この文書がただＩＰｖ４とＩＰｖ６通信に必要とされるＡＰＩの部分だけを
記述することは同じく指摘されるべきです。ＡＰＩの他の可能性がある使用、
例えばAF_UNIXアドレスファミリのgetaddrinfo()とgetnameinfo()はこの文書
の範囲外です。
2. Design Considerations
2. デザイン考察
There are a number of important considerations in designing changes
to this well-worn 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.)
- ＡＰＩの変更はオリジナルのＡＰＩで書かれたプログラムに対してソース
レベルとバイナリレベルの両方の互換性を提供するべきです。すなわち、
既存のバイナリプログラムを新しいＡＰＩをサポートしているシステム上
で動かす時、動くべきです。加えて、再コンパイルされた既存のアプリケー
ションを新しいＡＰＩをサポートしているシステムで動き続けるべきです。
単純言うと、ＡＰＩの変更は既存のプログラムを壊すべきではありません。
実装の検証のための追加メカニズムが[3]で記述される機能試験マクロで、
新しいシンボルが保護されるか検証します。（このような機能テストマク
ロはこのＲＦＣで定義されません。）
- The changes to the API should be as small as possible in order to
simplify the task of converting existing IPv4 applications to
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 addresses carried in data structures should be 64-bit
aligned. This is necessary in order to obtain optimum performance
on 64-bit machine architectures.
- データ構造体で運ばれたＩＰｖ６アドレスが６４ビット整列であるべきで
す。これは６４ビットのマシンアーキテクチャ上で最適なパフォーマンス
を得るために必要です。
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.
ＡＰＩがＩＰｖ４互換性を供給する重要性のため、これらの拡張は明示的に
ＩＰｖ４とＩＰｖ６両方に対する完全なサポートを供給するマシン上に働く
よう意図されます。ＩＰｖ６だけをサポートするシステムのオペレーション
のために、このＡＰＩのサブセットが多分設計できます。しかし、これはこ
のメモで扱われません。
2.1 What Needs to be Changed
2.1 どのような変更が必要か
The socket interface API consists of a few distinct components:
ソケットインタフェースＡＰＩは以下の異なる要素から成り立ちます：
- 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.
コアソケット関数−ＴＣＰ接続の設定と削除や、ＵＤＰパケットの送信と受
信を扱う関数−はトランスポートに依存しないよう設計されました。プロト
コルアドレスが関数の引数として渡されるところで、それらは不透明なポイ
ンタで運ばれます。プロトコル特定のアドレスデータ構造体がソケット関数
がサポートするそれぞれのプロトコルのために定義されます。アプリケーショ
ンがソケット関数を使う時、これらのプロトコル特定のアドレス構造体への
ポインタは一般的な「sockaddr」アドレス構造体へのポインタにキャストし
なければなりません。これらの関数はＩＰｖ６で変更不要ですが、新しいＩ
Ｐｖ６特定のアドレスデータ構造体が必要です。
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」構造体はＩＰｖ４プロトコル特有のデータ構造体です。この
データ構造体は実際は未使用の８オクテットスペースを含み、sockaddr_in構
造体をＩＰｖ６に適合させるのにこのスペースを使う誘惑があります。不幸
にもsockaddr_in構造体は１６オクテットのＩＰｖ６アドレスと他に必要な情
報を保持できるほど十分大きくありません。それで新しいアドレスデータ構
造体がＩＰｖ６のために定義されなくてはなりません。
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.
ＩＰｖ６アドレスは範囲[2]を持ち、それはリンクローカルかサイトか組織か
グローバルか、現在は不確定な範囲です。特定の範囲のインタフェースを識
別可能であることを望むアプリケーションをサポートするために、ＩＰｖ６
のsockaddr_in構造体はＩＰｖ６アドレスの範囲を示すインタフェース集合を
識別するために実装が使えるフィールドをサポートしなくてはなりません。
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.
ＩＰｖ４のソケットインタフェースでの名前からアドレスへの翻訳関数は
gethostbyname()とgethostbyaddr()です。これらはそのままで、ＩＰｖ４と
ＩＰｖ６の両方をサポートするために新しい関数が定義されます。
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.
ＩＰｖ４アドレス変換関数−inet_ntoa()とinet_addr()−はＩＰｖ４アドレ
スのバイナリと印刷可能な形の間の変換をします。これらの関数は３２ビッ
トのＩＰｖ４アドレスに非常に特有です。我々はＩＰｖ４とＩＰｖ６アドレ
スの両方を変換し、それらが同様に他のプロトコルファミリーにも拡張でき
るように、アドレスタイプパラメータを伴う２つの類似した関数を設計しま
した。
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.
最終的に、少数の雑多な機能がＩＰｖ６をサポートするために必要です。新
しいインタフェースがＩＰｖ６ホップ限界ヘッダーフィールドをサポートす
るために必要です。新しいソケットオプションがＩＰｖ６マルチキャストパ
ケットの送受信を制御するために必要です。
The socket interface will be enhanced in the future to provide access
to other IPv6 features. Some of these extensions are described in
[4].
ソケットインタフェースは他のＩＰｖ６機能へのアクセスを供給するために
将来拡張されるでしょう。いくつかの拡張は[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が正確にＮビットの符号なしの整数を意味します
（例えば、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]で記述されように、機能テストマクロで非標準メンバーを検査でき
ます(こうした機能テストマクロはこのＲＦＣで定義しません)。
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.
この章はＩＰｖ６のためにソケットインタフェース変更を指定します。
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()関数の最初の引数で使われ、ＩＰｖ６ソケットの生成
を示します。
3.2 IPv6 Address Structure
3.2 ＩＰｖ６アドレス構造体
A new in6_addr structure holds a single IPv6 address and is defined
as a result of including <netinet/in.h>:
新規のin6_addr構造体がひとつのＩＰｖ６アドレスを保持し、
<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.
このデータ構造は１６個の８ビット要素の配列で、１つの１２８ビットのＩ
Ｐｖ６アドレスを示します。ＩＰｖ６アドレスはネットワークバイト順に設
定されます。
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構造体"のＢＳＤ実装に似た方法で実装されます。
これらの追加の実装の細部は単純さのためにここでは省略します。
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 ４.３ＢＳＤベースシステムのソケットアドレス構造体
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構造体はＩＰｖ４プロトコル特有のアドレスデータ構造体です。
これはソケット関数でアプリケーションとシステムの間にアドレスを渡すた
めに使われます。次のsockaddr_in6構造体はＩＰｖ６アドレスを持ち、
<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 */
/* ＩＰｖ６フロー情報 */
struct in6_addr sin6_addr; /* IPv6 address */
/* ＩＰｖ６アドレス */
uint32_t sin6_scope_id; /* set of interfaces for a scope */
/* 範囲に対するインターフェース */
};
This structure is designed to be compatible with the sockaddr data
structure used in the 4.3BSD release.
この構造体は ４.３BSDリリースで使われた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 フィールドは１６ビットのＵＤＰかＴＣＰポート番号を含んでい
ます。このフィールドは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フィールドはフロー関連の情報を含むように意図される３２ビッ
トのフィールドです。このフィールドがパケットに、あるいはパケットから
マップされる正確な方法は現在指定されません。その使用法が指定される時
まで、アプリケーションが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構造体です。
このフィールドは１つの１２８ビットＩＰｖ６アドレスを持ちます。アドレ
スはネットワークバイト順に設定されます。
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フィールドが６４ビットの境界上
に並べられる時、構造体の開始が同じく６４ビット境界になるように設計さ
れます。これは６４ビットアーキテクチャ上での最適なパフォーマンスのた
めにされます。
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]に対応するインタフェース集合を識別する３２ビット整数です。
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)は等しく、両方１６バイトです。これを想定して
作成している既存のコードは、ＩＰｖ６に移行する際、慎重に調べる必要が
あります。
3.4 Socket Address Structure for 4.4BSD-Based Systems
3.4 ４.４ＢＳＤベースシステムのソケットアドレス構造体
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.
４.４ＢＳＤリリースはソケットインタフェースに対する小さいが、互換性が
ない変更を含みます。sockaddrデータ構造体の"sa_family"フィールドは１６
ビット値から８ビット値に変えられ、空いたスペースは"sa_len"という名前
の長さフィールドになりました。前の章で示したsockaddr_in6データ構造体
は新しいsockaddrデータ構造体に正しくキャストできません。この理由のた
めに、次の代わりのＩＰｖ６アドレスデータ構造体が４.４ＢＳＤに基くシス
テムで供給されます。これは<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 */
/* ＩＰｖ６フロー情報 */
struct in6_addr sin6_addr; /* IPv6 address */
/* ＩＰｖ６アドレス */
uint32_t sin6_scope_id; /* set of interfaces for a scope */
/* 範囲のインターフェース集合 */
};
The only differences between this data structure and the 4.3BSD
variant are the inclusion of the length field, and the change of the
family field to a 8-bit data type. The definitions of all the other
fields are identical to the structure defined in the previous
section.
このデータ構造体と４.３ＢＳＤの間の唯一の相違は長さフィールドの包含で、
８ビットのデータタイプに対するファミリーフィールドの変更です。すべて
の他のフィールドの定義は前の章で定義された構造体とまったく同じです。
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の宣言をしなければならなりません。このマクロはアプリ
ケーションにシステムが４.３ＢＳＤデータ構造体に基づくか、４.４ＢＳＤ
データ構造体の基づくのか決定することを許します。
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()関数への引数はシステムにどのプロトコルを
使うべきか言い、そのプロトコルのアドレス構造体が後の関数で使われるで
しょう。例えば、ＩＰｖ４／ＴＣＰソケットを作るために、アプリケーショ
ンが以下を呼びます：
s = socket(AF_INET, SOCK_STREAM, 0);
To create an IPv4/UDP socket, applications make the call:
ＩＰｖ４／ＵＤＰソケットを作るためアプリケーションが以下を呼びます：
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を使う
ことでＩＰｖ６／ＴＣＰとＩＰｖ６／ＵＤＰソケットを作ります。例えば、
ＩＰｖ６／ＴＣＰソケットを作るためアプリケーションが以下を呼びます：
s = socket(AF_INET6, SOCK_STREAM, 0);
To create an IPv6/UDP socket, applications make the call:
ＩＰｖ６／ＵＤＰソケットを作るためアプリケーションは以下を呼びます：
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.
「アドレスを運ぶ」関数のすべてが不透明なアドレスポインタを使い、アド
レス長を関数の引数で運ぶので、ＩＰｖ６対応にソケットの構文に対する変
更が必要ありません。
3.6 Compatibility with IPv4 Applications
3.6 ＩＰｖ４アプリケーションとの互換性
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.
多くのオリジナルのＡＰＩを使っているアプリケーションをサポートするた
めに、システム実装がオリジナルＡＰＩのソースとバイナリの完全な互換性
に提供しなくてはなりません。これはシステムがAF_INETソケットとsockaddr_in
アドレス構造体をサポートし続けなくてはならないことを意味します。前章
で記述されるように、アプリケーションがsocket()関数でAF_INET定数を使っ
てＩＰｖ４／ＴＣＰとＩＰｖ４／ＵＤＰソケットを作れなければなりません。
アプリケーションは同じプロセスので同時にＩＰｖ４／ＴＣＰとＩＰｖ４／
ＵＤＰとＩＰｖ６／ＴＣＰとＩＰｖ６／ＵＤＰソケットの組合せを持つこと
が可能であるべきです。
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.
オリジナルの ＡＰＩを使っているアプリケーションは、それらがＩＰｖ４だ
けをサポートしているシステム上で動作したのと同様に、動作し続けるべき
です。すなわち、それらはＩＰｖ４ノードと通信できるべきです。
3.7 Compatibility with IPv4 Nodes
3.7 ＩＰｖ４ノードとの互換性
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:
ＡＰＩ異なるタイプの互換性を供給します：ＩＰｖ６アプリケーションがＩ
Ｐｖ４アプリケーションと通信する能力。この機能はＩＰｖ６アドレスアー
キテクチャ仕様書[2]で定義されたＩＰｖ４マップＩＰｖ６アドレスフォー
マットを使います。このアドレスフォーマットはＩＰｖ４ノードのＩＰｖ４
アドレスをＩＰｖ６アドレス表現で記述するのを許します。ＩＰｖ４アドレ
スはＩＰｖ６アドレスの下位３２ビットにコード化され、上位９６ビットは
固定プレフィックス0:0:0:0:0:FFFFです。ＩＰｖ４マップのアドレスが次の
ように書かれます：
::FFFF:<IPv4-address>
These addresses can be generated automatically by the getaddrinfo()
function, as described in Section 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.
アプリケーションがＩＰｖ４マップＩＰｖ６アドレスとして宛先ＩＰｖ４ア
ドレスをコード化し、sockaddr_in6構造体でconnect()かsendto()に渡すこと
で、ＩＰｖ４ノードにＴＣＰ接続を開くかＵＤＰパケットを送るのに
AF_INET6ソケットを使うかもしれません。アプリケーションがAF_INET6ソケッ
トを使用してＩＰｖ４ノードからのＴＣＰ接続を受けるか、ＵＤＰパケット
を受信する時、システムはこの方法でコード化した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.
ほとんどアプリケーションが多分どのタイプのノードと通信しているか知る
必要がないでしょう。しかしながら、知る必要があるアプリケーションのた
めに、６.７章で定義されたIN6_IS_ADDR_V４MAPPED()マクロが供給されます。
3.8 IPv6 Wildcard Address
3.8 ＩＰｖ６ワイルドカードアドレス
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()関数がアプリケーションにＵＤＰパケットとＴＣＰ接続のソースＩＰ
アドレスを選択を許しますが、アプリケーションはしばしばシステムにソー
スアドレスを選ぶのを望みます。ＩＰｖ４で、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.
ＩＰｖ６アドレスタイプが構造体（struct in6_addr）であるので、象徴的定
数がＩＰｖ６アドレス変数を初期化するために使うことができますが、代入
で使うことができません。それ故にシステムが２つの形式でＩＰｖ６ワイル
ドカードアドレスを供給します。
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:
アプリケーションはＩＰｖ４でINADDR_ANYを使うのと同様にin6addr_anyを使
います。例えば、ポート番号２３にソケットをバインドするがシステムにソー
スアドレスを選ばせるため、アプリケーションが次のコードを使うことがで
きます：
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.
ＩＰｖ４のINADDR_xxx定数がすべてホストバイトオーダーで定義されますが、
ＩＰｖ６のIN６ADDR_xxx定数とin6addr_xxx外部変数がネットワークバイト順
で定義されることを知っていてください。
3.9 IPv6 Loopback Address
3.9 ＩＰｖ６ループバックアドレス
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.
アプリケーションがローカルノード上のサービスにＵＤＰパケット送信やＴ
ＣＰ接続をする必要があるかもしれません。ＩＰｖ４でこれはＩＰｖ４アド
レス定数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.
ＩＰｖ６はローカルなＴＣＰとＵＤＰサービスと通信をするためのループバッ
クアドレスを供給します。特定されていないアドレスのように、ＩＰｖ６ルー
プバックアドレスの２つの形式−グローバル変数とシンボリックな定数−が
供給されます。
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:
アプリケーションが、ＩＰｖ４アプリケーションでINADDR_LOOPBACKを使うよ
うにin6addr_loopbackを使います（前章の終わりで示したバイト順序に注意）。
例えば、ローカルなtelnetサーバーにＴＣＰ接続をするために、アプリケー
ションが次のコードを使えます：
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のように、この定数は前に宣言されたＩＰｖ６アドレス変
数への代入に使えません。
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.
アプリケーション製作者に手助けできるソケットＡＰＩへの１つの単純な追
加は「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 */
/* ６バイトパッド、これはフィールド整列のため、 */
/* データ構造体の後に、実装特有パッドを作ります。 */
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 */
/* 望ましい大きさにするための１１２のバイトパッド、 */
/* _SS_MAXSIZE値引くss_familyのサイズ、 */
/* __ss_pad1と__ss_alignフィールドは１１２ */
};
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.
上記の例の実装は６４ビット境界上に整列するデータ構造を例示します。実
装特有のフィールド「__ss_align」と「__ss_pad1」は６４ビット整列を強制
するために使われ、これはsockaddr_in6（ＩＰｖ６）とsockaddr_in（ＩＰｖ
４）アドレスデータ構造体の要求する適切な整列を十分満足します。穴埋め
フィールド__ss_pad1の大きさは選ばれた整列境界に依存します。穴埋め
フィールド__ss_pad2は構造体の完全な大きさに選ばれた全体的な大きさの
値に依存します。上記の例の実装特有の大きさと整列が（必須ではない）定
数_SS_MAXSIZE（選択された値は１２８）と_SS_ALIGNSIZE（選択された値は
８）で表現されます。同じく例示した定数_SS_PAD1SIZE（派生する値６）と
_SS_PAD2SIZE（派生する値１１２）は必須ではありません。派生した値は
sa_family_tが２バイトであると想定します。上記の実装特有の定義と構造
体フィールド名が実装固有の名前空間を意味する下線で始まります。移植可
能コードがこれらのフィールドや定数をアクセスするか参照することが期待
されません。
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 */
/* ６バイトパッド、これはフィールド整列のため、 */
/* データ構造体の後に、実装特有パッドを作ります。 */
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 */
/* 望ましい大きさにするための１１２のバイトパッド、 */
/* _SS_MAXSIZE値引くss_familyのサイズ、 */
/* __ss_pad1と__ss_alignフィールドは１１２ */
};
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.
このＡＰＩはマルチキャストグループが加入するローカルインタフェースを
識別するためにインタフェースインデックス（小さい正の整数）を使います
（５.２章）。さらに、高等ＡＰＩ[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"の様な名前で知られています。
バークレー系の実装で、インタフェースをシステムが知る時、カーネルはそ
のインタフェースに（インタフェースインデックスと呼ばれる）ユニークな
正の整数値を割り当てます。これらは１から始まる小さい正の整数です。
（０が決してインタフェースインデックスで使われないことに注意してくだ
さい。）特定の正のインタフェースインデックスで現在のインタフェースが
ないような隙間があるかもしれません。
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.
このＡＰＩはインタフェース名とインデックスを対応付ける２つの関数と、
すべてのインタフェース名を返す３番目の関数と、前の関数が割り当てられ
たダイナミックメモリを返す４番目の関数を定義します。これらの関数が実
装される方法は実装依存です。４.４ＢＳＤ実装が、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.
２番目の関数はインタフェースインデックスを対応する名前に変換します。
#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構造体の配列、インタフェース毎に１つの構造体、
を返します。
#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.
構造体の配列の終わりは０の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.
多くの新しいソケットオプションがＩＰｖ６で定義されます。これらすべて
の新しいオプションはIPPROTO_IPV6レベルにあります。すなわち、
getsockopt()とsetsockopt()呼び出しでの"level"パラメータは、これらの
オプションを使う時、 IPPROTO_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の宣言と、新しいＩＰｖ６ソケットオプションと、この章で定
義された関連した定数が<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_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.
ＩＰｖ６アプリケーションが、例えばsendto()関数の宛先アドレス引数で、
ただＩＰｖ６マルチキャストアドレスを宛先アドレスとして明示することに
よってマルチキャストパケットを送るかもしれません。
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レイヤで３つのソケットオプションがマルチキャストパケット
を送る際のパラメータのいくつかを制御します。これらのオプションを設定
することは必須でありません：アプリケーションがこれらのオプションを使
わないでマルチキャストパケットを送るかもしれません。マルチキャストパ
ケットの送信制御のsetsockopt()オプションを下に要約します。これらの３
つのオプションは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 >= 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が設定されないなら、デフォルトは
（今日のＩＰｖ４と同じく）１です。
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.
もしこのオプションが１に設定されたら、マルチキャストデータグラ
ムが（外向インタフェース上の）送信ホスト自身が属するグループに
送られた時、データグラムのコピーがローカルな配達のためにＩＰレ
イヤによってループバックされます。もしこのオプションが０に設定
されるなら、コピーがループバックされません。他のオプション値が
EINVALエラーを返します。
If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
same as IPv4 today).
もしIPV6_MULTICAST_LOOPが設定されないなら、デフォルトは
（今日のＩＰｖ４と同じく）１です。
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().
マルチキャストパケットの受信は下に要約した２つのsetsockopt()オプショ
ンで制御されます。もしこれらの２つのオプションがgetsockopt()で使われ
るなら、EOPNOTSUPPエラーが返されます。
IPV6_JOIN_GROUP
IPV6_JOIN_GROUP
Join a multicast group on a specified local interface.
If the interface index is specified as 0,
the kernel chooses the local interface.
For example, some kernels look up the multicast group
in the normal IPv6 routing table and use the resulting
interface.
指定されたローカルインタフェース上のマルチキャストグループに加
入してください。もしインタフェースインデックスが０と明示される
なら、カーネルはローカルインタフェースを選択します。例えば、あ
るカーネルが標準的なＩＰｖ６ルーティングテーブルでマルチキャス
トグループを検索し、得られたインタフェースを使います。
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.
指定インタフェース上のマルチキャストグループから離脱。もしイン
タフェースインデックスが０と明示されるなら、システムはマルチ
キャストに一致するアドレスのみを捨てるためにマルチキャストグ
ループメンバーシップを選択するかもしれません。
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.
マルチキャストデータグラムを受け取るために、プロセスがデータグラムが
送られるであろうマルチキャストグループに加入しなくてはならないことに
注意してください。ＵＤＰアプリケーションが同じくデータグラムが送られ
るであろうＵＤＰポートをバインドしなくてはなりません。。あるプロセス
が、その同じポート宛の他のデータグラムがソケットに配達されるのを阻止
するために、ポートに加えてマルチキャストグループアドレスをソケットに
バインドします。
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ソケットをＩＰｖ６通信のみに制限しま
す。＜3.7 ＩＰｖ４ノードとの互換性＞章で述べられるように、AF_INET6ソ
ケットがＩＰｖ４とＩＰｖ６通信の両方で使われるかもしれません。あるア
プリケーションがＩＰｖ６通信のみにAF_INET6ソケットの用途を限定するこ
とを望むかもしれません。これらのアプリケーションのためにIPV6_V6ONLYソ
ケットオプションが定義されます。このオプションがオンになっている時、
ソケットは送受信にＩＰｖ６パケットのみを使うことができます。これは
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].
ノート−このオプションは、ＩＰｖ６がステートレスＩＰ／ＩＣＭＰ翻訳ア
ルゴリズム（ＳＩＩＴ）[5]で定義されるＩＰｖ６通信のための正しいＩＰｖ
６アドレスとしてノードに入力されたＩＰｖ４マップアドレスの使用に対す
る効果を持っていません。
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.
このオプションの使用の例は、同じサーバの同じポート上の２つのバージョ
ンのプロセスが、一方がＩＰｖ６上のサービスを供給し、他方がＩＰｖ４の
サービスを供給する、動作を許します。
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.
新しいライブラリ関数がＩＰｖ６アドレスでいろいろな操作を実行するため
に必要とされます。関数がドメインネームシステム（ＤＮＳ）でＩＰｖ６ア
ドレスを検索するために必要とされます。前方検索（ノード名からアドレス
への翻訳）と逆検索（アドレスからノード名への翻訳）の両方がサポートさ
れる必要があります。バイナリ形式とテキスト形式のＩＰｖ６アドレス間の
翻訳関数が同じく必要です。
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.
我々は２つの既存の関数、gethostbyname()とgethostbyaddr()、が現状のま
ま残ることを指摘します。新しい関数がＩＰｖ４とＩＰｖ６アドレス両方を
処理するために定義されます。
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()は多くのアプリケーションに対して不十
分です、第一に関数が要望されるアドレスタイプ（ＩＰｖ４のみ、ＩＰｖ６
のみの、ＩＰｖ４マップＩＰｖ６がOKなど）について呼び出し人が指定する
方法を供給しないし、第二にこの関数の多くの実装がスレッドに安全ではな
いからです。ＲＦＣ２１３３がgethostbyname2()という名前の機能を定義し
ましたが、この関数は、第一にＩＰｖ６アドレスが必要な時にグローバルオ
プション（RES_USE_INET6）の設定が必要で、第二にフラグ引数が必要なタイ
プのアドレスの追加の制御を呼び出し人に提供するために必要なため、同じ
く不適当です。gethostbyname2()関数はＲＦＣ２５５３で廃止されれ、そし
てもう基本ＡＰＩ の一部ではありません。
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引数はヌルポインタあるいはヌルで終了する文字列への
ポインタです。これらの２つの引数の１つあるいは両方がゼロでないポイン
タであるに違いありません。
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.
正当な名前のフォーマットはアドレスファミリーに依存します。もし特定の
ファミリーが与えられず、そして多数のサポートされたファミリーで名前が
正当であると解釈されるなら、実装はすべてのサポートされたファミリーで
名前の変換を試み、そして、エラーがなければ、１つ以上の結果が返される
べきです。
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()で記述された標準的なＩＰｖ６テキスト書式は正当です。
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であるなら、サービスは
１０進法のポート番号を指定する文字列として明示できます。
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. 例えば、もし呼び出し人がＵＤＰではなくＴＣＰだけを扱うなら、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. もし呼び出し人がＩＰｖ６ではなくＩＰｖ４だけを処理するなら、
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の１つ以上の値のビット単位の包含ＯＲです。
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引数がヌルであるなら、ソケットアドレス構
造体のＩＰアドレス部は、ＩＰｖ４アドレスではINADDR_ANYで、ＩＰｖ６ア
ドレスではIN6ADDR_ANY_INITになるべきです。もしAI_PASSIVEフラグが指定
されないなら、返されたアドレス情報はconnect()呼出（接続モードプロトコ
ルで）や、 connect()やsendto()やsendmsg()呼び出し（コネクションレスプ
ロトコルのために）で、適するべきです。この場合、もしnodename引数がヌ
ルであるなら、ソケットアドレス構造体のＩＰアドレス部はループバックア
ドレスが設定されるべきです。このフラグは、もし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]エラーが返されます。このフラグは呼び出された時に、いかな
る名前解決サービス（例えば、ＤＮＳ）も妨げるべきです。
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]エラーが返されるべきです。このフラグは名前解決サービス
（例えば、ＮＩＳ＋）が呼ばれるのを阻止するべきです。
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()が一致するＩＰｖ６アドレスが見つけられない場合にＩＰｖ４
マップＩＰｖ６アドレスを返すべきです（ai_addrlenは１６であるべきです）。
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.
例えば、ＤＮＳを使う時、もしＡＡＡＡレコードが見つからないなら、
Ａレコード問合せがなされ、そして見つかったものがＩＰｖ４マップ
ＩＰｖ６アドレスとして返されます。
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()
がすべての一致するＩＰｖ６とＩＰｖ４アドレスを返すべきです。
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.
例えば、ＤＮＳを使う時、問合せがＡＡＡＡレコードとＡレコードの両方
でされ、そしてgetaddrinfo()が両方の問合せの結合結果を返します。見
つかったＩＰｖ４アドレスはＩＰｖ４マップＩＰｖ６アドレスとして返さ
れます。
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_V４MAPPEDと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フラグが指定されるなら、ＩＰｖ４アドレスがローカルシ
ステムで設定される場合に限りＩＰｖ４アドレスが返されるべきです、そし
てＩＰｖ６アドレスがローカルシステム上に設定される場合に限りＩＰｖ６
アドレスが返されるべきです。ループバックアドレスはこの場合効力がある
設定と考えられません。
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).
例えば、 ＤＮＳを使う時にＡＡＡＡレコードの質問はノードが少なくと
も１つの（ＩＰｖ６ループバック以外の）設定されたＩＰｖ６アドレス
を持っている場合に限り起こり、そしてＡレコードの質問がノードが少
なくとも１つの（ＩＰｖ４ループバック以外の）設定されたＩＰｖ４ア
ドレスを持っている場合に限り起こるべきです。
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()で返された１つ以上のアドレス構造体を
構造体に関連する追加の記憶領域と共に開放します（例えば、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構造体はソケットを作るのに使うソケッ
トアドレスと情報を指定するべきです。リストは少なくとも１つの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.
供給されたパラメータのための名前が解決できません。ノー
ド名とサービス名のいずれも供給されませんでした。少な
くともこれらの１つが供給されなくてはなりません。
[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値の
１つです。戻り値はエラーを記述している文字列を指し示します。もし引数
がEAI_xxx値の１つではないなら、関数は未知のエラーを示す文字列へのポ
インタを返します。
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.
もしソケットアドレス構造体がＩＰｖ４マップＩＰｖ６アドレスあるいはＩ
Ｐｖ４互換ＩＰｖ６アドレスを含んでいるなら、実装は埋め込みＩＰｖ４ア
ドレスを引き抜いて、そしてそのＩＰｖ４アドレスのノード名を検索するべ
きです。
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.
ノート：特定されていないＩＰｖ６アドレス（"::"）そしてＩＰｖ６ルー
プバックアドレス（"::1"）はＩＰｖ４互換アドレスでありません。もし
アドレスがＩＰｖ６の特定されていないアドレスであるなら（"::"）、検
索行われず、そして[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引数は関数のデフォルト行動を変えるフラグです。デフォルトで、ホス
トの完全修飾ドメイン名（ＦＱＤＮ）が返されるべきです、しかし：
- 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が設定されるなら、ローカルホストについて、
ただＦＱＤＮのノード名の部分だけが返されるべきです。
- 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フラグはＵＤＰとＴＣＰで異なったサービス表現を務める少数
の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:
２つのＩＰｖ４関数inet_addr()とinet_ntoa()はバイナリとテキスト形式の
間でＩＰｖ４アドレスを変えます。ＩＰｖ６アプリケーションが類似の関数
を必要とします。次の２つの関数はＩＰｖ６とＩＰｖ４アドレスの両方を変
換します：
#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で３２ビット、AF_INET6 で
１２８ビット）を持つのに十分な大きさであるべきです。inet_pton()関数は、
もし変換が、ネットワークバイト順でdstによって指し示されたアドレスで、
成功するなら、１を返すべきです。それは、もし入力が正当なＩＰｖ４ドッ
ト区切り１０進数文字列か正当なＩＰｖ６アドレス文字列でないなら０を返
し、引数が未知ならかerrnoにEAFNOSUPPORTを設定し−１を返すべきです。
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文字列は標準的ＩＰｖ４
ドット区切り形式であるべきです：
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」が０と２５５の間の１桁から３桁の数です。inet_pton()関数は
（inet_addr()が受け入れる、８進数や１６進数や４つ未満の数など）他の
フォーマットを受け入れません。
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]の２.２章で定義される標準ＩＰｖ６テキスト形式の１つであるべき
です。
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ならばＩＰｖ４ア
ドレスを設定したバッファを示し、af引数がAF_INET6であるならＩＰｖ６ア
ドレスを設定したバッファを示します；アドレスはネットワークバイト順で
あるに違いありません。dst引数は関数が生成するテキスト文字列をストアす
るバッファを指し示します；それはヌルであるべきではありません。size引
数はこのバッファの大きさを指定し、これはテキスト文字列を持つのに十分
な大きさであるべきです（ＩＰｖ４でINET_ADDRSTRLEN文字、ＩＰｖ６で
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>:
アプリケーションが容易にＩＰｖ４とＩＰｖ６アドレスの文字列形式に適切
な大きさのバッファを宣言することを許すために、次の２つの定数が
<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.
次のマクロは特別なＩＰｖ６アドレスのテストをするために使うことができ
ます。
#include <netinet/in.h>
int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *);
int IN6_IS_ADDR_MULTICAST (const struct in6_addr *);
int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *);
int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *);
int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *);
int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);
int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);
The first seven macros return true if the address is of the specified
type, or false otherwise. The last five test the scope of a
multicast address and return true if the address is a multicast
address of the specified scope or false if the address is either not
a multicast address or not of the specified scope.
最初の７つのマクロはもしアドレスが指定されたタイプのであるなら真で、
さもなければ偽で戻ります。後の５つがマルチキャストアドレスの範囲をテ
ストし、そしてもしアドレスが指定された範囲のマルチキャストアドレスで
あるなら真で、もしアドレスがマルチキャストアドレスでないか指定された
範囲でなければ偽です。
Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true
only for the two 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]で定義される２種類の
ローカル使用のＩＰｖ６ユニキャストアドレス（リンクローカルとサイトロー
カル）でだけ真で、定義からIN6_IS_ADDR_LINKLOCALまくりはＩＰｖ６ループ
バックアドレス（::1）に対して偽である事に注してください。これらの２つ
のマクロはリンクローカル範囲あるいはサイトローカル範囲のＩＰｖ６マル
チキャストアドレスについて、真ではありません。
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.
ＩＰｖ６が多くの新しいセキュリティ機構を供給し、その多くはアプリケー
ションでアクセスできる必要があります。ＩＰｖ６セキュリティをサポート
するためにソケットインタフェースへの拡張を詳述している関連文書が書か
れています。
9. Changes from RFC 2553
9. ＲＦＣ２５５３からの変更
1. Add brief description of the history of this API and its relation
to the Open Group/IEEE/ISO standards.
1. このＡＰＩの歴史とオープングループ／ＩＥＥＥ／ＩＳＯ標準にの短い記
述を追加。
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. ノードが実装でＩＰｖ４としてＩＰｖ４パケットを処理しないのを許す
ＩＰレベルのIPV6_V6ONLYソケットオプションを追加。
5. Added SIIT to references and added new contributors.
5. ＳＩＩＴへの参照の追加と、新しい貢献者を追加。
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フィールドはＩＰｖ６トラフィック
クラスとフローラベルに結び付けられました、しかしその使用法は完全に
指定されませんでした。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()の最初のプロト
タイプを実装しました。プロトコル詳細から独立してサービス接続すること
に対して、名前とサービスの２つを指定することで十分であろうという発言
は「一様ネットワークインタフェース」のための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.
著作権（Ｃ）インターネット学会（２００３）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。