RFC2553 日本語訳
2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S.Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes) (Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Gilligan
Request for Comments: 2553 FreeGate
Obsoletes: 2133 S. Thomson
Category: Informational Bellcore
J. Bound
Compaq
W. Stevens
Consultant
March 1999
コメントを求めるワーキンググループR.ギリガンの要求をネットワークでつないでください: 2553FreeGateは以下を時代遅れにします。 2133秒間トムソンCategory: 1999年の情報のBellcoreの制限されたコンパックW.スティーブンスコンサルタントJ.行進
Basic Socket Interface Extensions for IPv6
IPv6に、基本的なソケットインタフェース拡大
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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 [4].
TCP/IPアプリケーションのためのデファクトスタンダード適用業務プログラム・インタフェース(API)は「ソケット」インタフェースです。 このAPIは1980年代前半のUnixのために開発されましたが、また、それはさまざまな非unixシステムの上で実装されました。ソケットAPIを使用することで書かれたTCP/IPアプリケーションは過去に高度合いの移植性を楽しみました、そして、私たちはIPv6アプリケーションがある同じ移植性が欲しいと思います。 しかし、変化はソケットAPIにIPv6をサポートしなければなりません、そして、このメモはこれらの変化について説明します。 これらは、IPv6アドレス、新しいアドレス変換機能、およびいくつかの新しいソケットオプションを運ぶために新しいソケットアドレス構造を含んでいます。 これらの拡大はTCPとUDPアプリケーションで必要である基本のIPv6の特徴へのアクセスを提供するように設計されています、マルチキャスティングを含んでいて最小変化をシステムに取り入れて、既存のIPv4アプリケーションに完全な両立性を提供していて。 高度なIPv6の特徴(生のソケットとIPv6拡張ヘッダーへのアクセス)のための追加拡大は別のドキュメント[4]で定義されます。
Gilligan, et. al. Informational [Page 1] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[1ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
Table of Contents
目次
1. Introduction.................................................3 2. Design Considerations........................................3 2.1 What Needs to be Changed....................................4 2.2 Data Types..................................................5 2.3 Headers.....................................................5 2.4 Structures..................................................5 3. Socket Interface.............................................6 3.1 IPv6 Address Family and Protocol Family.....................6 3.2 IPv6 Address Structure......................................6 3.3 Socket Address Structure for 4.3BSD-Based Systems...........7 3.4 Socket Address Structure for 4.4BSD-Based Systems...........8 3.5 The Socket Functions........................................9 3.6 Compatibility with IPv4 Applications.......................10 3.7 Compatibility with IPv4 Nodes..............................10 3.8 IPv6 Wildcard Address......................................11 3.9 IPv6 Loopback Address......................................12 3.10 Portability Additions.....................................13 4. Interface Identification....................................16 4.1 Name-to-Index..............................................16 4.2 Index-to-Name..............................................17 4.3 Return All Interface Names and Indexes.....................17 4.4 Free Memory................................................18 5. Socket Options..............................................18 5.1 Unicast Hop Limit..........................................18 5.2 Sending and Receiving Multicast Packets....................19 6. Library Functions...........................................21 6.1 Nodename-to-Address Translation............................21 6.2 Address-To-Nodename Translation............................24 6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....26 6.4 Protocol-Independent Nodename and Service Name Translation.26 6.5 Socket Address Structure to Nodename and Service Name......29 6.6 Address Conversion Functions...............................31 6.7 Address Testing Macros.....................................32 7. Summary of New Definitions..................................33 8. Security Considerations.....................................35 9. Year 2000 Considerations....................................35 Changes From RFC 2133..........................................35 Acknowledgments................................................38 References.....................................................39 Authors' Addresses.............................................40 Full Copyright Statement.......................................41
1. 序論…3 2. 問題を設計してください…3 2.1 ことは、Changedである必要があります…4 2.2のデータ型…5 2.3個のヘッダー…5 2.4 構造化します。5 3. ソケットインタフェース…6 3.1 IPv6はファミリーとプロトコルファミリーに演説します…6 3.2 IPv6は構造を扱います…6 3.3 4.3BSDベースのシステムのためのソケットアドレス構造…7 3.4 4.4BSDベースのシステムのためのソケットアドレス構造…8 3.5 ソケットは機能します…9 IPv4アプリケーションとの3.6の互換性…10 IPv4ノードとの3.7の互換性…10 3.8 IPv6ワイルドカードアドレス…11 3.9IPv6ループバックアドレス…12 3.10 移植性追加…13 4. 識別を連結してください…16 4.1 索引をつける名前…16 4.2 名前に索引をつけてください…17 4.3 名前とインデックスをすべてのインタフェースに返してください…17 4.4 メモリを解放してください…18 5. ソケットオプション…18 5.1ユニキャストホップ限界…18 5.2 送受信マルチキャストパケット…19 6. 図書館は機能します…21 6.1 Nodenameからアドレス翻訳…21 6.2 アドレスからNodenameへの翻訳…24 6.3 getipnodebynameとgetipnodebyaddrのためのメモリを解放します…26 6.4 プロトコルから独立しているNodenameとサービス名翻訳.26 6.5ソケットはNodenameとサービス名に構造を扱います…29 6.6 変換が機能であると扱ってください…31 6.7 テストマクロを扱ってください…32 7. 新しい定義の概要…33 8. セキュリティ問題…35 9. Y2K問題…35 RFC2133から、変化します…35の承認…38の参照箇所…39人の作者のアドレス…40 完全な著作権宣言文…41
Gilligan, et. al. Informational [Page 2] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[2ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
1. Introduction
1. 序論
While IPv4 addresses are 32 bits long, IPv6 interfaces are identified by 128-bit addresses. The socket interface makes the size of an IP address quite visible to an application; virtually all TCP/IP applications for BSD-based systems have knowledge of the size of an IP address. Those parts of the API that expose the addresses must be changed to accommodate the larger IPv6 address size. IPv6 also introduces new features (e.g., traffic class and flowlabel), some of which must be made visible to applications via the API. This memo defines a set of extensions to the socket interface to support the larger address size and new features of IPv6.
IPv4アドレスが長さ32ビットである間、IPv6インタフェースは128ビットのアドレスによって特定されます。 ソケットインタフェースで、IPアドレスのサイズはアプリケーションにかなり目に見えるようになります。 BSDベースのシステムのほとんどすべてのTCP/IPアプリケーションには、IPアドレスのサイズに関する知識があります。 より大きいIPv6アドレスサイズを収容するためにアドレスを暴露するAPIのそれらの部分を変えなければなりません。 また、IPv6は新機能(例えば、トラフィックのクラスとflowlabel)を導入します。その或るものをAPIを通してアプリケーションに目に見えるようにしなければなりません。 このメモは、より大きいアドレスがIPv6に関するサイズと新機能であるとサポートするために1セットの拡大をソケットインタフェースと定義します。
2. Design Considerations
2. デザイン問題
There are a number of important considerations in designing changes to this well-worn API:
この陳腐なAPIへの変化を設計するのにおいて多くの重要な問題があります:
- The API changes should provide both source and binary
compatibility for programs written to the original API. That
is, existing program binaries should continue to operate when
run on a system supporting the new API. In addition, existing
applications that are re-compiled and run on a system supporting
the new API should continue to operate. Simply put, the API
changes for IPv6 should not break existing programs. An
additonal mechanism for implementations to verify this is to
verify the new symbols are protected by Feature Test Macros as
described in IEEE Std 1003.1. (Such Feature Test Macros are not
defined by this RFC.)
- API変化はオリジナルのAPIに書かれたプログラムにソースとバイナリ互換性の両方を供給するはずです。 新しいAPIをサポートするシステムに実行されると、すなわち、既存のプログラム2種混合毒ガスは、作動し続けるべきです。 新しいAPIをサポートする再コンパイルされて、システムで動く既存のアプリケーションは、さらに、作動し続けるべきです。 単に、置かれます、IPv6のためのAPI変化は既存のプログラムを壊すはずがありません。実装がこれについて確かめるadditonalメカニズムは新しいシンボルについて確かめるのがIEEE Std1003.1で説明されるようにFeature Test Macrosによって保護されるということです。 (そのようなFeature Test MacrosはこのRFCによって定義されません。)
- The changes to the API should be as small as possible in order
to simplify the task of converting existing IPv4 applications to
IPv6.
- APIへの変化は、タスクを単純化するためにできるだけ既存のIPv4アプリケーションをIPv6に変換するのにおいて小さいはずです。
- Where possible, applications should be able to use this API to
interoperate with both IPv6 and IPv4 hosts. Applications should
not need to know which type of host they are communicating with.
- 可能であるところでは、アプリケーションが、IPv6とIPv4ホストの両方で共同利用するのにこのAPIを使用できるべきです。 アプリケーションは、彼らがどのタイプのホストとコミュニケートしているかを知る必要はないはずです。
- IPv6 addresses carried in data structures should be 64-bit
aligned. This is necessary in order to obtain optimum
performance on 64-bit machine architectures.
- 並べられた状態で、データ構造で運ばれたIPv6アドレスは64ビットであるべきです。 これが、64ビットのマシンアーキテクチャに関する最適な性能を得るのに必要です。
Because of the importance of providing IPv4 compatibility in the API, these extensions are explicitly designed to operate on machines that provide complete support for both IPv4 and IPv6. A subset of this API could probably be designed for operation on systems that support only IPv6. However, this is not addressed in this memo.
APIで互換性をIPv4に供給する重要性のために、これらの拡大は、IPv4とIPv6の両方の完全なサポートを提供するマシンを作動させるように明らかに設計されています。 操作のためにたぶんIPv6だけをサポートするシステムにこのAPIの部分集合を設計できました。 しかしながら、これはこのメモで扱われません。
Gilligan, et. al. Informational [Page 3] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[3ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
2.1 What Needs to be Changed
2.1 Changedである必要があること
The socket interface API consists of a few distinct components:
ソケットインタフェースAPIはいくつかの異なったコンポーネントから成ります:
- Core socket functions.
- コアソケットは機能します。
- Address data structures.
- データ構造を扱ってください。
- Name-to-address translation functions.
- 名前からアドレス変換は機能します。
- Address conversion functions.
- 変換が機能であると扱ってください。
The core socket functions -- those functions that deal with such things as setting up and tearing down TCP connections, and sending and receiving UDP packets -- were designed to be transport independent. Where protocol addresses are passed as function arguments, they are carried via opaque pointers. A protocol-specific address data structure is defined for each protocol that the socket functions support. Applications must cast pointers to these protocol-specific address structures into pointers to the generic "sockaddr" address structure when using the socket functions. These functions need not change for IPv6, but a new IPv6-specific address data structure is needed.
コアソケット機能(TCP接続をセットアップして、取りこわすようなもの、および送受信UDPパケットに対処するそれらの機能)は、輸送独立者になるように設計されました。 プロトコルアドレスが機能議論として通過されるところに、それらは不透明な指針で運ばれます。 プロトコル特有のアドレスデータ構造はソケット機能がサポートする各プロトコルのために定義されます。 ソケット機能を使用するとき、アプリケーションはジェネリック"sockaddr"アドレス構造への指針へのこれらのプロトコル特有のアドレス構造に指針を投げかけなければなりません。 これらの機能はIPv6のために変化する必要はありませんが、新しいIPv6特有のアドレスデータ構造が必要です。
The "sockaddr_in" structure is the protocol-specific data structure for IPv4. This data structure actually includes 8-octets of unused space, and it is tempting to try to use this space to adapt the sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in structure is not large enough to hold the 16-octet IPv6 address as well as the other information (address family and port number) that is needed. So a new address data structure must be defined for IPv6.
「_中のsockaddr」構造はIPv4のためのプロトコル特有のデータ構造です。 このデータ構造は実際に未使用のスペースの8八重奏を含んでいます、そして、それは構造でsockaddr_をIPv6に適合させるのにこのスペースを使用しようとするのに誘惑しています。 残念ながら、構造のsockaddr_は必要であるもう片方の情報(アドレスファミリーとポートナンバー)と同様に16八重奏のIPv6アドレスを保持できるくらいには大きくはありません。 それで、IPv6のために新しいアドレスデータ構造を定義しなければなりません。
IPv6 addresses are scoped [2] so they could be link-local, site, organization, global, or other scopes at this time undefined. To support applications that want to be able to identify a set of interfaces for a specific scope, the IPv6 sockaddr_in structure must support a field that can be used by an implementation to identify a set of interfaces identifying the scope for an IPv6 address.
IPv6アドレスは[2] リンク地方であることができるために見られて、サイト、グローバルであるか、または他の組織はこのとき、未定義の状態で見られます。 1セットのインタフェースを特定の範囲に特定できるようになりたがっているアプリケーションをサポートするために、構造のIPv6 sockaddr_は実装によって使用される、IPv6アドレスのために範囲を特定する1セットのインタフェースを特定できる分野をサポートしなければなりません。
The name-to-address translation functions in the socket interface are gethostbyname() and gethostbyaddr(). These are left as is and new functions are defined to support IPv4 and IPv6. Additionally, the POSIX 1003.g draft [3] specifies a new nodename-to-address translation function which is protocol independent. This function can also be used with IPv4 and IPv6.
ソケットインタフェースでの名前からアドレス変換への機能は、gethostbyname()とgethostbyaddr()です。 これらはそのままなままにされます、そして、新しい機能は、IPv4とIPv6をサポートするために定義されます。 さらに、POSIX 1003.g草稿[3]はnodenameからアドレス変換へのプロトコル独立者である新しい機能を指定します。 また、IPv4とIPv6と共にこの機能を使用できます。
Gilligan, et. al. Informational [Page 4] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[4ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
The address conversion functions -- inet_ntoa() and inet_addr() -- convert IPv4 addresses between binary and printable form. These functions are quite specific to 32-bit IPv4 addresses. We have designed two analogous functions that convert both IPv4 and IPv6 addresses, and carry an address type parameter so that they can be extended to other protocol families as well.
アドレス変換機能(inet_ntoa()とinet_addr())は2進の、そして、印刷可能なフォームの間のIPv4アドレスを変換します。 これらの機能は32ビットのIPv4アドレスにかなり特定です。 私たちはIPv4とIPv6アドレスの両方を変換して、また、他のプロトコルファミリーにそれらを広げることができるようにアドレス型引数を運ぶ2つの類似の機能を設計しました。
Finally, a few miscellaneous features are needed to support IPv6. New interfaces are needed to support the IPv6 traffic class, flow label, and hop limit header fields. New socket options are needed to control the sending and receiving of IPv6 multicast packets.
最終的に、いくつかの種々雑多な特徴が、IPv6をサポートするのに必要です。 新しいインタフェースが、IPv6トラフィックのクラス、流れラベル、およびホップ限界ヘッダーフィールドを支えるのに必要です。 新しいソケットオプションが、IPv6マルチキャストパケットの送受信を制御するのに必要です。
The socket interface will be enhanced in the future to provide access to other IPv6 features. These extensions are described in [4].
ソケットインタフェースは、将来、他のIPv6の特徴へのアクセスを提供するために高められるでしょう。 これらの拡大は[4]で説明されます。
2.2 Data Types
2.2 データ型
The data types of the structure elements given in this memo are intended to be examples, not absolute requirements. Whenever possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g are used: uintN_t means an unsigned integer of exactly N bits (e.g., uint16_t). We also assume the argument data types from 1003.1g when possible (e.g., the final argument to setsockopt() is a size_t value). Whenever buffer sizes are specified, the POSIX 1003.1 size_t data type is used (e.g., the two length arguments to getnameinfo()).
このメモで与えられた構造要素に関するデータ型は絶対条件ではなく、例であることを意図します。 可能であるときはいつも、POSIX1003.1gのDraft6.6(1997年3月)からのデータ型は使用されています: uintN_tはちょうどNビット(例えば、uint16_t)の符号のない整数を意味します。 また、可能であるときに、私たちは、議論が1003.1gからのデータ型であると思います(例えば、setsockopt()への最終弁論はサイズ_t値です)。 バッファサイズが指定されるときはいつも、POSIX1003.1サイズ_tデータ型は使用されています。(例えば、getnameinfo())への2つの長さの議論。
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.
関数原型と構造が私たちがヘッダーを見せるのが示されると、それはその項目が定義されることを引き起こすために含まれていた#、に違いありません。
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 IEEE Std 1003.1. (Such Feature Test Macros are not defined by this RFC.)
構造が説明されるとき、見せられたメンバーは実装に現れなければならないものです。 また、追加していて、標準的でないメンバーは実装によって定義されるかもしれません。 追加注意として、標準的でないメンバーはIEEE Std1003.1で説明されるようにFeature Test Macrosによって確かめられるかもしれません。 (そのようなFeature Test MacrosはこのRFCによって定義されません。)
The ordering shown for the members of a structure is the recommended ordering, given alignment considerations of multibyte members, but an implementation may order the members differently.
「マルチ-バイト」メンバーの整列問題を考えて、構造の部材のために示された注文はお勧めの注文ですが、実装はメンバーを異なって命令するかもしれません。
Gilligan, et. al. Informational [Page 5] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[5ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
3. Socket Interface
3. ソケットインタフェース
This section specifies the socket interface changes for IPv6.
このセクションはソケットインタフェース変化をIPv6に指定します。
3.1 IPv6 Address Family and Protocol Family
3.1 IPv6アドレスファミリーとプロトコルファミリー
A new address family name, AF_INET6, is defined in <sys/socket.h>. The AF_INET6 definition distinguishes between the original sockaddr_in address data structure, and the new sockaddr_in6 data structure.
新しいアドレス姓(AF_INET6)は<sys/socket.h>で定義されます。 AF_INET6定義はアドレスデータ構造、および新しいsockaddr_in6データ構造でオリジナルのsockaddr_を見分けます。
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
#PF_INET6 AF_INET6を定義してください。
The PF_INET6 is used in the first argument to the socket() function to indicate that an IPv6 socket is being created.
PF_INET6は、IPv6ソケットが作成されているのを示すのに最初の議論にソケット()機能に使用されます。
3.2 IPv6 Address Structure
3.2 IPv6アドレス構造
A new in6_addr structure holds a single IPv6 address and is defined as a result of including <netinet/in.h>:
新しいin6_addr構造は、ただ一つのIPv6アドレスを保持して、<netinet/in.h>を含んでいることの結果、定義されます:
struct in6_addr {
uint8_t s6_addr[16]; /* IPv6 address */
};
uint8_t s6_addr[16]; /*IPv6が*/を扱うstruct in6_addr。
This data structure contains an array of sixteen 8-bit elements, which make up one 128-bit IPv6 address. The IPv6 address is stored in network byte order.
このデータ構造は16の8ビットの要素の配列を含んでいます。(要素は1つの128ビットのIPv6アドレスを作ります)。 IPv6アドレスはネットワークバイトオーダーで保存されます。
The structure in6_addr above is usually implemented with an embedded union with extra fields that force the desired alignment level in a manner similar to BSD implementations of "struct in_addr". Those additional implementation details are omitted here for simplicity.
通常、上の構造in6_addrは埋め込まれた組合と共に「_addrのstruct」のBSD実装と同様の方法で必要な整列レベルを強制する付加的な分野で実装されます。 それらの追加実装の詳細は簡単さのためにここで省略されます。
An example is as follows:
例は以下の通りです:
Gilligan, et. al. Informational [Page 6] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[6ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
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
struct in6_addr、組合uint8_t_S6_u8[16]; _uint32_t_S6_u32[4]; uint64_t S6_u64[2];_S6_、不-、;、。 #s6_addr_S6_を定義してください、不-. _S6_u8
3.3 Socket Address Structure for 4.3BSD-Based Systems
3.3 4.3BSDベースのシステムのためのソケットアドレス構造
In the socket interface, a different protocol-specific data structure is defined to carry the addresses for each protocol suite. Each protocol- specific data structure is designed so it can be cast into a protocol- independent data structure -- the "sockaddr" structure. Each has a "family" field that overlays the "sa_family" of the sockaddr data structure. This field identifies the type of the data structure.
ソケットインタフェースでは、異なったプロトコル特有のデータ構造は、各プロトコル群へのアドレスを運ぶために定義されます。 それぞれのプロトコルの特定のデータ構造はプロトコルの独立しているデータ構造にそれを投げかけることができるように設計されています--"sockaddr"構造。 それぞれには、sockaddrデータ構造の「sa_ファミリー」をかぶせる「ファミリー」分野があります。 この分野はデータ構造のタイプを特定します。
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:
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:
struct sockaddr_in6 {
sa_family_t sin6_family; /* AF_INET6 */
in_port_t sin6_port; /* transport layer port # */
uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */
struct in6_addr sin6_addr; /* IPv6 address */
uint32_t sin6_scope_id; /* set of interfaces for a scope */
};
struct sockaddr_in6 { sa_family_t sin6_family; /* AF_INET6 */ in_port_t sin6_port; /* transport layer port # */ uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */ struct in6_addr sin6_addr; /* IPv6 address */ uint32_t sin6_scope_id; /* set of interfaces for a scope */ };
This structure is designed to be compatible with the sockaddr data structure used in the 4.3BSD release.
This structure is designed to be compatible with the sockaddr data structure used in the 4.3BSD release.
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.
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.
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.
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.
Gilligan, et. al. Informational [Page 7] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
Gilligan, et. al. Informational [Page 7] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
The sin6_flowinfo field is a 32-bit field that contains two pieces of information: the traffic class and the flow label. The contents and interpretation of this member is specified in [1]. The sin6_flowinfo field SHOULD be set to zero by an implementation prior to using the sockaddr_in6 structure by an application on receive operations.
The sin6_flowinfo field is a 32-bit field that contains two pieces of information: the traffic class and the flow label. The contents and interpretation of this member is specified in [1]. The sin6_flowinfo field SHOULD be set to zero by an implementation prior to using the sockaddr_in6 structure by an application on receive operations.
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.
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.
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.
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.
The sin6_scope_id field is a 32-bit integer that identifies a set of interfaces as appropriate for the scope of the address carried in the sin6_addr field. For a link scope sin6_addr sin6_scope_id would be an interface index. For a site scope sin6_addr, sin6_scope_id would be a site identifier. The mapping of sin6_scope_id to an interface or set of interfaces is left to implementation and future specifications on the subject of site identifiers.
The sin6_scope_id field is a 32-bit integer that identifies a set of interfaces as appropriate for the scope of the address carried in the sin6_addr field. For a link scope sin6_addr sin6_scope_id would be an interface index. For a site scope sin6_addr, sin6_scope_id would be a site identifier. The mapping of sin6_scope_id to an interface or set of interfaces is left to implementation and future specifications on the subject of site identifiers.
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.
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.
3.4 Socket Address Structure for 4.4BSD-Based Systems
3.4 Socket Address Structure for 4.4BSD-Based Systems
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.
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.
Gilligan, et. al. Informational [Page 8] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
Gilligan, et. al. Informational [Page 8] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
struct sockaddr_in6 {
uint8_t sin6_len; /* length of this struct */
sa_family_t sin6_family; /* AF_INET6 */
in_port_t sin6_port; /* transport layer port # */
uint32_t sin6_flowinfo; /* IPv6 flow information */
struct in6_addr sin6_addr; /* IPv6 address */
uint32_t sin6_scope_id; /* set of interfaces for a scope */
};
struct sockaddr_in6 { uint8_t sin6_len; /* length of this struct */ sa_family_t sin6_family; /* AF_INET6 */ in_port_t sin6_port; /* transport layer port # */ uint32_t sin6_flowinfo; /* IPv6 flow information */ struct in6_addr sin6_addr; /* IPv6 address */ uint32_t sin6_scope_id; /* set of interfaces for a scope */ };
The only differences between this data structure and the 4.3BSD variant are the inclusion of the length field, and the change of the family field to a 8-bit data type. The definitions of all the other fields are identical to the structure defined in the previous section.
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.
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.
3.5 The Socket Functions
3.5 The Socket Functions
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:
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:
s = socket(PF_INET, SOCK_STREAM, 0);
s = socket(PF_INET, SOCK_STREAM, 0);
To create an IPv4/UDP socket, applications make the call:
To create an IPv4/UDP socket, applications make the call:
s = socket(PF_INET, SOCK_DGRAM, 0);
s = socket(PF_INET, SOCK_DGRAM, 0);
Applications may create IPv6/TCP and IPv6/UDP sockets by simply using the constant PF_INET6 instead of PF_INET in the first argument. For example, to create an IPv6/TCP socket, applications make the call:
Applications may create IPv6/TCP and IPv6/UDP sockets by simply using the constant PF_INET6 instead of PF_INET in the first argument. For example, to create an IPv6/TCP socket, applications make the call:
s = socket(PF_INET6, SOCK_STREAM, 0);
s = socket(PF_INET6, SOCK_STREAM, 0);
To create an IPv6/UDP socket, applications make the call:
To create an IPv6/UDP socket, applications make the call:
s = socket(PF_INET6, SOCK_DGRAM, 0);
s = socket(PF_INET6, SOCK_DGRAM, 0);
Gilligan, et. al. Informational [Page 9] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
Gilligan, et. al. Informational [Page 9] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
Once the application has created a PF_INET6 socket, it must use the sockaddr_in6 address structure when passing addresses in to the system. The functions that the application uses to pass addresses into the system are:
Once the application has created a PF_INET6 socket, it must use the sockaddr_in6 address structure when passing addresses in to the system. The functions that the application uses to pass addresses into the system are:
bind()
connect()
sendmsg()
sendto()
bind() connect() sendmsg() sendto()
The system will use the sockaddr_in6 address structure to return addresses to applications that are using PF_INET6 sockets. The functions that return an address from the system to an application are:
The system will use the sockaddr_in6 address structure to return addresses to applications that are using PF_INET6 sockets. The functions that return an address from the system to an application are:
accept()
recvfrom()
recvmsg()
getpeername()
getsockname()
accept() recvfrom() recvmsg() getpeername() getsockname()
No changes to the syntax of the socket functions are needed to support IPv6, since all of the "address carrying" functions use an opaque address pointer, and carry an address length as a function argument.
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 Compatibility with IPv4 Applications
In order to support the large base of applications using the original API, system implementations must provide complete source and binary compatibility with the original API. This means that systems must continue to support PF_INET sockets and the sockaddr_in address structure. Applications must be able to create IPv4/TCP and IPv4/UDP sockets using the PF_INET constant in the socket() function, as described in the previous section. Applications should be able to hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets simultaneously within the same process.
In order to support the large base of applications using the original API, system implementations must provide complete source and binary compatibility with the original API. This means that systems must continue to support PF_INET sockets and the sockaddr_in address structure. Applications must be able to create IPv4/TCP and IPv4/UDP sockets using the PF_INET constant in the socket() function, as described in the previous section. Applications should be able to hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets simultaneously within the same process.
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.
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 Compatibility with IPv4 Nodes
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
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
Gilligan, et. al. Informational [Page 10] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
Gilligan, et. al. Informational [Page 10] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
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:
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:
::FFFF:<IPv4-address>
::FFFF:<IPv4-address>
These addresses can be generated automatically by the getipnodebyname() function when the specified host has only IPv4 addresses (as described in Section 6.1).
These addresses can be generated automatically by the getipnodebyname() function when the specified host has only IPv4 addresses (as described in Section 6.1).
Applications may use PF_INET6 sockets to open TCP connections to IPv4 nodes, or send UDP packets to IPv4 nodes, by simply encoding the destination's IPv4 address as an IPv4-mapped IPv6 address, and passing that address, within a sockaddr_in6 structure, in the connect() or sendto() call. When applications use PF_INET6 sockets to accept TCP connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the system returns the peer's address to the application in the accept(), recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded this way.
Applications may use PF_INET6 sockets to open TCP connections to IPv4 nodes, or send UDP packets to IPv4 nodes, by simply encoding the destination's IPv4 address as an IPv4-mapped IPv6 address, and passing that address, within a sockaddr_in6 structure, in the connect() or sendto() call. When applications use PF_INET6 sockets to accept TCP connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the system returns the peer's address to the application in the accept(), recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded this way.
Few applications will likely need to know which type of node they are interoperating with. However, for those applications that do need to know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is provided.
Few applications will likely need to know which type of node they are interoperating with. However, for those applications that do need to know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is provided.
3.8 IPv6 Wildcard Address
3.8 IPv6 Wildcard Address
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.
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.
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.
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.
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>:
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>:
extern const struct in6_addr in6addr_any;
extern const struct in6_addr in6addr_any;
Gilligan, et. al. Informational [Page 11] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
Gilligan, et. al. Informational [Page 11] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
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:
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:
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)
. . .
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:
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:
struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
Note that this constant can be used ONLY at declaration time. It can not be used to assign a previously declared in6_addr structure. For example, the following code will not work:
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:
/* This is the WRONG way to assign an unspecified address */
struct sockaddr_in6 sin6;
. . .
sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
/* 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.
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.
3.9 IPv6 Loopback Address
3.9 IPv6 Loopback Address
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.
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.
IPv6 also provides a loopback address to contact local TCP and UDP services. Like the unspecified address, the IPv6 loopback address is provided in two forms -- a global variable and a symbolic constant.
IPv6 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.
Gilligan, et. al. Informational [Page 12] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
Gilligan, et. al. Informational [Page 12] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
The global variable is an in6_addr structure named "in6addr_loopback." The extern declaration for this variable is defined in <netinet/in.h>:
The global variable is an in6_addr structure named "in6addr_loopback." The extern declaration for this variable is defined in <netinet/in.h>:
extern const struct in6_addr in6addr_loopback;
extern const struct in6_addr in6addr_loopback;
Applications use in6addr_loopback as they would use INADDR_LOOPBACK in IPv4 applications (but beware of the byte ordering difference mentioned at the end of the previous section). For example, to open a TCP connection to the local telnet server, an application could use the following code:
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:
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)
. . .
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:
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:
struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to a previously declared IPv6 address variable.
Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to a previously declared IPv6 address variable.
3.10 Portability Additions
3.10 Portability Additions
One simple addition to the sockets API that can help application writers is the "struct sockaddr_storage". This data structure can simplify writing code portable across multiple address families and platforms. This data structure is designed with the following goals.
One simple addition to the sockets API that can help application writers is the "struct sockaddr_storage". This data structure can simplify writing code portable across multiple address families and platforms. This data structure is designed with the following goals.
- It has a large enough implementation specific maximum size to
store the desired set of protocol specific socket address data
structures. Specifically, it is at least large enough to
accommodate sockaddr_in and sockaddr_in6 and possibly other
protocol specific socket addresses too.
- It is aligned at an appropriate boundary so protocol specific
socket address data structure pointers can be cast to it and
access their fields without alignment problems. (e.g. pointers
to sockaddr_in6 and/or sockaddr_in can be cast to it and access
fields without alignment problems).
- It has a large enough implementation specific maximum size to store the desired set of protocol specific socket address data structures. Specifically, it is at least large enough to accommodate sockaddr_in and sockaddr_in6 and possibly other protocol specific socket addresses too. - It is aligned at an appropriate boundary so protocol specific socket address data structure pointers can be cast to it and access their fields without alignment problems. (e.g. pointers to sockaddr_in6 and/or sockaddr_in can be cast to it and access fields without alignment problems).
Gilligan, et. al. Informational [Page 13] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
Gilligan, et. al. Informational [Page 13] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
- It has the initial field(s) isomorphic to the fields of the
"struct sockaddr" data structure on that implementation which
can be used as a discriminants for deriving the protocol in use.
These initial field(s) would on most implementations either be a
single field of type "sa_family_t" (isomorphic to sa_family
field, 16 bits) or two fields of type uint8_t and sa_family_t
respectively, (isomorphic to sa_len and sa_family_t, 8 bits
each).
- それで、初期の分野は使用中のプロトコルを引き出すのに判別式として使用できるその実装で"struct sockaddr"データ構造の分野に同型になります。 これらはタイプ「sa_ファミリー_t」(sa_ファミリー分野、16ビットへの同型の)のただ一つの分野かタイプuint8_tとsa_の2つの分野がファミリー_tであったならそれぞれ(s)がほとんどの実装でそうする分野に頭文字をつけます、(それぞれ8ビットのsa_lenとsa_ファミリー_tにおける同型。)です。
An example implementation design of such a data structure would be as follows.
そのようなデータ構造の例の実装デザインは以下の通りでしょう。
/*
* Desired design of maximum size and alignment
*/
#define _SS_MAXSIZE 128 /* Implementation specific max size */
#define _SS_ALIGNSIZE (sizeof (int64_t))
/* Implementation specific desired alignment */
/*
* Definitions used for sockaddr_storage structure paddings design.
*/
#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t))
#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+
_SS_PAD1SIZE + _SS_ALIGNSIZE))
struct sockaddr_storage {
sa_family_t __ss_family; /* address family */
/* Following fields are implementation specific */
char __ss_pad1[_SS_PAD1SIZE];
/* 6 byte pad, this is to make implementation
/* specific pad up to alignment field that */
/* follows explicit in the data structure */
int64_t __ss_align; /* field to force desired structure */
/* storage alignment */
char __ss_pad2[_SS_PAD2SIZE];
/* 112 byte pad to achieve desired size, */
/* _SS_MAXSIZE value minus size of ss_family */
/* __ss_pad1, __ss_align fields is 112 */
};
/**は最大サイズのデザインを望んでいました、そして、整列*/#、は_SS_MAXSIZE128/*を定義します。実装の特定の最大サイズ*/#、は_sockaddr_格納構造詰め物デザインに使用される*実装SS_ALIGNSIZE(sizeof(int64_t))/特有の必要な整列*//**定義を定義します。 */ #define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) #define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+ _SS_PAD1SIZE + _SS_ALIGNSIZE)) struct sockaddr_storage { sa_family_t __ss_family; /* address family */ /* Following fields are implementation specific */ char __ss_pad1[_SS_PAD1SIZE]; /* 6 byte pad, this is to make implementation /* specific pad up to alignment field that */ /* follows explicit in the data structure */ int64_t __ss_align; /* field to force desired structure */ /* storage alignment */ char __ss_pad2[_SS_PAD2SIZE]; /* 112 byte pad to achieve desired size, */ /* _SS_MAXSIZE value minus size of ss_family */ /* __ss_pad1, __ss_align fields is 112 */ };
On implementations where sockaddr data structure includes a "sa_len", field this data structure would look like this:
sockaddrデータ構造が「sa_len」、分野を含んでいる実装では、このデータ構造はこれに似ているでしょう:
/*
* Definitions used for sockaddr_storage structure paddings design.
*/
#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
(sizeof (uint8_t) + sizeof (sa_family_t))
#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+
sockaddr_格納構造詰め物デザインに使用される/**定義。 */#が_SS_PAD1SIZEを定義する、(_SS_ALIGNSIZE、--、(sizeof(uint8_t)+sizeof(_ファミリー_tをsaする))#、が_SS_PAD2SIZEを定義する(_SS_MAXSIZE--、((sa_ファミリー_t)+をsizeofします。
Gilligan, et. al. Informational [Page 14] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[14ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
_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 */
};
{ uint8_t__の*アドレスファミリー*//*ss_len; /*アドレス長さの*/sa_ファミリー_t__ss_ファミリー;/次の分野は__実装の特定の*/炭のss_pad1_SS_PAD1SIZE; /の*の6バイトのパッド、これが*//*が続く整列野原までの実装/*特定のパッドをt__ss_が並べるデータ構造*/int64_で明白にするためのものであるということです; } 。
The above example implementation illustrates a data structure which will align on a 64 bit boundary. An implementation specific field "__ss_align" along "__ss_pad1" is used to force a 64-bit alignment which covers proper alignment good enough for needs of sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures. The size of padding fields __ss_pad1 depends on the chosen alignment boundary. The size of padding field __ss_pad2 depends on the value of overall size chosen for the total size of the structure. This size and alignment are represented in the above example by implementation specific (not required) constants _SS_MAXSIZE (chosen value 128) and _SS_ALIGNMENT (with chosen value 8). Constants _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112) are also for illustration and not required. The implementation specific definitions and structure field names above start with an underscore to denote implementation private namespace. Portable code is not expected to access or reference those fields or constants.
上の例の実装は64ビット境界に並ぶデータ構造を例証します。 「」 __ss_が並べる実装の特定の分野」は、sockaddr_in6(IPv6)((IPv4)アドレスデータ構造におけるsockaddr_)の必要性のために十分良い適切な整列をカバーする64ビットの整列を強制するのに」 __ss_pad1"に沿って使用されます。 分野__ss_pad1を水増しするサイズは選ばれた整列境界に依存します。 分野__ss_pad2を水増しするサイズは値に依存します。 このサイズと整列は上記の例に実装の特定(必要でない)の定数の_SS_MAXSIZE(値128を選ぶ)と_SS_ALIGNMENT(選ばれた値8がある)によって表されます。 定数の_SS_PAD1SIZE(値6を引き出す)と_SS_PAD2SIZE(値112を引き出す)はイラストのためにもあって、必要ではありません。 実装の特定の定義と上の構造フィールド名は強調から実装の個人的な名前空間を指示し始めます。 携帯用のコードはアクセス、ものがさばく参照または定数まで予想されません。
The sockaddr_storage structure solves the problem of declaring storage for automatic variables which is large enough and aligned enough for storing socket address data structure of any family. For example, code with a file descriptor and without the context of the address family can pass a pointer to a variable of this type where a pointer to a socket address structure is expected in calls such as getpeername() and determine the address family by accessing the received content after the call.
sockaddr_格納構造はどんなファミリーのソケットアドレスデータ構造も保存するために十分十分大きくて自動的変数のために並べられたストレージを宣言するという問題を解決します。 例えば、ファイルディスクリプタとアドレスファミリーの文脈のないコードは、ソケットアドレス構造への指針がgetpeername()などの呼び出しで予想されるこのタイプの変数に指針を通過して、呼び出しの後に受信された内容にアクセスすることによって、アドレスファミリーを決定できます。
The sockaddr_storage structure may also be useful and applied to certain other interfaces where a generic socket address large enough and aligned for use with multiple address families may be needed. A discussion of those interfaces is outside the scope of this document.
また、sockaddr_格納構造も、役に立って十分大きくて使用のために複数のアドレスファミリーと提携しているジェネリックソケットアドレスが必要であるかもしれない他のあるインタフェースに付けられるかもしれません。 このドキュメントの範囲の外にそれらのインタフェースの議論があります。
Gilligan, et. al. Informational [Page 15] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[15ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
Also, much existing code assumes that any socket address structure can fit in a generic sockaddr structure. While this has been true for IPv4 socket address structures, it has always been false for Unix domain socket address structures (but in practice this has not been a problem) and it is also false for IPv6 socket address structures (which can be a problem).
また、多くの既存のコードが、どんなソケットアドレス構造もジェネリックsockaddr構造をうまくはめ込むことができると仮定します。 IPv4ソケットアドレス構造に、これは本当ですが、Unixドメインソケットアドレス構造において、それはいつも誤っています、そして、(実際には、これは問題ではありません)また、IPv6ソケットアドレス構造(問題であるかもしれない)において、誤っています。
So now an application can do the following:
それで、今、アプリケーションは以下ができます:
struct sockaddr_storage __ss;
struct sockaddr_in6 *sin6;
sin6 = (struct sockaddr_in6 *) &__ss;
__struct sockaddr_ストレージss。 struct sockaddr_in6*sin6。 sin6は__(struct sockaddr_in6*)とssと等しいです。
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.3). Additionally, the advanced API [4] uses these same interface indexes to identify the interface on which a datagram is received, or to specify the interface on which a datagram is to be sent.
このAPIは、マルチキャストグループが加わられる局所界面(セクション5.3)を特定するのに、インタフェースインデックス(わずかな正の整数)を使用します。 さらに、高度なAPI[4]は、データグラムが受け取られているインタフェースを特定するか、またはデータグラムが送られることになっているインタフェースを指定するのにこれらの同じインタフェースインデックスを使用します。
Interfaces are normally known by names such as "le0", "sl1", "ppp2", and the like. On Berkeley-derived implementations, when an interface is made known to the system, the kernel assigns a unique positive integer value (called the interface index) to that interface. These are small positive integers that start at 1. (Note that 0 is never used for an interface index.) There may be gaps so that there is no current interface for a particular positive interface index.
インタフェース、通常、知られている名前がそのようである、「le0"、「sl1"と、「ppp2"、および同様のもの。」 インタフェースがシステムに明らかにされるとき、バークレーによって派生させられた実装では、カーネルはユニークな正の整数値(インタフェースインデックスと呼ばれる)をそのインタフェースに割り当てます。 これらは1時に始まるわずかな正の整数です。 (インタフェースインデックスにおいて、0が決して使用されていないことに注意してください。) ギャップが、特定の陽のインタフェースインデックスのためのどんな現在のインタフェースもないように、あるかもしれません。
This API defines two functions that map between an interface name and index, a third function that returns all the interface names and indexes, and a fourth function to return the dynamic memory allocated by the previous function. How these functions are implemented is left up to the implementation. 4.4BSD implementations can implement these functions using the existing sysctl() function with the NET_RT_IFLIST command. Other implementations may wish to use ioctl() for this purpose.
このAPIはそれがインタフェース名とインデックスの間で写像する2つの機能を定義します、前の機能によって割り当てられたダイナミックメモリを返すために名前、インデックス、および4番目の機能をすべてのインタフェースに返す3番目の機能。 これらの機能がどう実装されるかは実装に任せられます。 4.4BSD実装は、ネット_RT_IFLISTコマンドがある既存のsysctl()機能を使用することでこれらの機能を実装することができます。 他の実装はこのためにioctl()を使用したがっているかもしれません。
4.1 Name-to-Index
4.1 索引をつける名前
The first function maps an interface name into its corresponding index.
最初の機能はインタフェース名を対応するインデックスに写像します。
#include <net/if.h>
#<ネット/if.h>を含めてください。
unsigned int if_nametoindex(const char *ifname);
未署名のintは_であるなら(const炭*ifname)をnametoindexします。
Gilligan, et. al. Informational [Page 16] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[16ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
If the specified interface name does not exist, the return value is 0, and errno is set to ENXIO. If there was a system error (such as running out of memory), the return value is 0 and errno is set to the proper value (e.g., ENOMEM).
指定されたインタフェース名が存在していないなら、リターン値は0です、そして、errnoはENXIOに用意ができています。 システム・エラー(メモリを使い果たすことなどの)があったなら、リターン値は0です、そして、errnoは固有値(例えば、ENOMEM)に用意ができています。
4.2 Index-to-Name
4.2 命名するインデックス
The second function maps an interface index into its corresponding name.
2番目の機能はインタフェースインデックスを対応する名前に写像します。
#include <net/if.h>
#<ネット/if.h>を含めてください。
char *if_indextoname(unsigned int ifindex, char *ifname);
*_indextoname(未署名のint ifindex、炭*のifname)であるなら、焦げてください。
The ifname argument must point to a buffer of at least IF_NAMESIZE bytes into which the interface name corresponding to the specified index is returned. (IF_NAMESIZE is also defined in <net/if.h> and its value includes a terminating null byte at the end of the interface name.) This pointer is also the return value of the function. If there is no interface corresponding to the specified index, NULL is returned, and errno is set to ENXIO, if there was a system error (such as running out of memory), if_indextoname returns NULL and errno would be set to the proper value (e.g., ENOMEM).
_インタフェースが指定との対応を命名するNAMESIZEバイトが索引をつけるなら、少なくとも必須がバッファに指すifname議論を返します。 (_また、NAMESIZEが<ネット/if.hで定義されるなら、>とその値はインタフェース名の終わりに終わりのヌルバイトを含んでいます。) また、この指針は機能のリターン値です。 指定されたインデックスに対応するどんなインタフェースもなければ、NULLを返します、そして、errnoはENXIOに用意ができています、システム・エラー(メモリを使い果たすことなどの)があったなら、_indextonameがNULLを返して、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.
_nameindex構造が単一のインタフェースの周りに情報を保持して、<ネット/if.h>ヘッダーを含んでいることの結果、定義されるなら。
struct if_nameindex {
unsigned int if_index; /* 1, 2, ... */
char *if_name; /* null terminated name: "le0", ... */
};
_nameindexであるならstructする、未署名のintは_であるなら索引をつけます; … /*1、2、*/炭は*_名; /*ヌルであるなら名前を終えました:、「le0"、…*/、」、。
The final function returns an array of if_nameindex structures, one structure per interface.
機能が_nameindex構造、1インタフェースあたり1つの構造であるなら配列を返す決勝。
struct if_nameindex *if_nameindex(void);
structは_であるなら*_nameindexであるなら(空の)nameindexされます。
The end of the array of structures is indicated by a structure with an if_index of 0 and an if_name of NULL. The function returns a NULL pointer upon an error, and would set errno to the appropriate value.
そして、構造体の配列の端が構造によって示される、_索引をつけることである、0について_NULLという名前であるなら。 機能は、NULL指針を誤りに返して、適切な値にerrnoを設定するでしょう。
The memory used for this array of structures along with the interface names pointed to by the if_name members is obtained dynamically. This memory is freed by the next function.
メモリが示されたインタフェース名に伴うこの構造体の配列に使用した、_ダイナミックに名義のメンバーを得るなら。 このメモリは次の機能によって解放されます。
Gilligan, et. al. Informational [Page 17] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[17ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
4.4 Free Memory
4.4 無料の記憶
The following function frees the dynamic memory that was allocated by if_nameindex().
以下の機能はそれが_nameindex()であるなら割り当てられたダイナミックメモリを解放します。
#include <net/if.h>
#<ネット/if.h>を含めてください。
void if_freenameindex(struct if_nameindex *ptr);
_freenameindexであるなら(_nameindex*ptrであるなら、structします)、欠如します。
The argument to this function must be a pointer that was returned by if_nameindex().
この機能への議論はそれが_nameindex()であるなら返された指針であるに違いありません。
Currently net/if.h doesn't have prototype definitions for functions
and it is recommended that these definitions be defined in net/if.h
as well and the struct if_nameindex{}.
現在の、ネット/if.hには、機能のためのプロトタイプ定義がありません、そして、これらの定義が_nameindexであるならまた、ネット/if.hとstructで定義されるのは、お勧めです。
5. Socket Options
5. ソケットオプション
A number of new socket options are defined for IPv6. All of these new options are at the IPPROTO_IPV6 level. That is, the "level" parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 when using these options. The constant name prefix IPV6_ is used in all of the new socket options. This serves to clearly identify these options as applying to IPv6.
多くの新しいソケットオプションがIPv6のために定義されます。 これらの新しいオプションのすべてがIPPROTO_IPV6レベルにあります。 これらのオプションを使用するとき、すなわち、getsockopt()とsetsockopt()呼び出しにおける「平らな」パラメタはIPPROTO_IPV6です。 一定の名前接頭語IPV6_は新しいソケットオプションのすべてで使用されます。 これは、これらのオプションがIPv6に適用することであると明確に認識するのに役立ちます。
The declaration for IPPROTO_IPV6, the new IPv6 socket options, and related constants defined in this section are obtained by including the header <netinet/in.h>.
ヘッダー<netinet/in.h>を含んでいることによって、IPPROTO_IPV6のための宣言、新しいIPv6ソケットオプション、およびこのセクションで定義された関連する定数を得ます。
5.1 Unicast Hop Limit
5.1 ユニキャストホップ限界
A new setsockopt() option controls the hop limit used in outgoing unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, and it is used at the IPPROTO_IPV6 layer. The following example illustrates how it is used:
新しいsetsockopt()オプションは出発しているユニキャストIPv6パケットで使用されるホップ限界を制御します。 このオプションの名前はIPV6_UNICAST_ホップスです、そして、それはIPPROTO_IPV6層で使用されます。 以下の例はそれがどう使用されているかを例証します:
int hoplimit = 10;
int hoplimit=10。
if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
(char *) &hoplimit, sizeof(hoplimit)) == -1)
perror("setsockopt IPV6_UNICAST_HOPS");
(setsockopt(sとIPPROTO_IPV6とIPV6_UNICAST_ホップスと(炭*)とhoplimit、sizeof(hoplimit))=-1)perror(「setsockopt IPV6_UNICAST_ホップス」)であるなら。
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_ホップスのオプションがsetsockopt()で設定されるとき、すべてのその後のユニキャストパケットのためのホップ限界がそのソケットを通って発信したので、与えられたオプション価値は使用されています。 オプションが設定されないなら、システムはデフォルト値を選択します。 整数ホップ制限値(xと呼ばれる)は以下の通り解釈されます:
Gilligan, et. al. Informational [Page 18] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[18ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
x < -1: return an error of EINVAL
x == -1: use kernel default
0 <= x <= 255: use x
x >= 256: return an error of EINVAL
x<-1: EINVAL x=-1の誤りを返してください: カーネルデフォルト0<=x<=255を使用してください: x x>=256を使用してください: 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_ホップスのオプションは、システムがそのソケットを通して送られたその後のユニキャストパケットに使用するホップ制限値を決定するのにgetsockopt()と共に使用されるかもしれません。 例えば:
int hoplimit;
size_t len = sizeof(hoplimit);
int hoplimit。 サイズ_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);
(getsockopt(s、IPPROTO_IPV6、IPV6_UNICAST_ホップス、(炭*)、hoplimit、およびlen)=-1)perror(「getsockopt IPV6_UNICAST_ホップス」)であるなら。 ほかのprintf(「ホップ限界\nに%dを使用します」、hoplimit)。
5.2 Sending and Receiving Multicast Packets
5.2 送受信マルチキャストパケット
IPv6 applications may send UDP multicast packets by simply specifying an IPv6 multicast address in the address argument of the sendto() function.
IPv6アプリケーションは、単にsendto()機能のアドレス議論におけるIPv6マルチキャストアドレスを指定することによって、マルチキャストパケットをUDPに送るかもしれません。
Three socket options at the IPPROTO_IPV6 layer control some of the parameters for sending multicast packets. Setting these options is not required: applications may send multicast packets without using these options. The setsockopt() options for controlling the sending of multicast packets are summarized below. These three options can also be used with getsockopt().
IPPROTO_IPV6層の3つのソケットオプションが送付マルチキャストパケットのためのパラメタのいくつかを制御します。 これらのオプションを設定するのは必要ではありません: これらのオプションを使用しないで、アプリケーションはマルチキャストパケットを送るかもしれません。 マルチキャストパケットの発信を制御するためのsetsockopt()オプションは以下へまとめられます。 また、getsockopt()と共にこれらの3つのオプションを使用できます。
IPV6_MULTICAST_IF
IPV6_マルチキャスト_
Set the interface to use for outgoing multicast packets. The
argument is the index of the interface to use.
出発しているマルチキャストパケットの使用にインタフェースを設定してください。 議論は使用するインタフェースのインデックスです。
Argument type: unsigned int
議論タイプ: 未署名のint
IPV6_MULTICAST_HOPS
IPV6_マルチキャスト_ホップ
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_ホップス)が出発しているユニキャストパケットの使用にホップ限界を設定するために提供されることに注意してください。)
The interpretation of the argument is the same as for the
IPV6_UNICAST_HOPS option:
議論の解釈はIPV6_UNICAST_ホップスのオプションのように同じです:
Gilligan, et. al. Informational [Page 19] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[19ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
x < -1: return an error of EINVAL
x == -1: use kernel default
0 <= x <= 255: use x
x >= 256: return an error of EINVAL
x<-1: EINVAL x=-1の誤りを返してください: カーネルデフォルト0<=x<=255を使用してください: x x>=256を使用してください: EINVALの誤りを返してください。
If IPV6_MULTICAST_HOPS is not set, the default is 1
(same as IPv4 today)
IPV6_MULTICAST_ホップスが設定されないなら、デフォルトは1です。(今日のIPv4と同じこと)
Argument type: int
議論タイプ: int
IPV6_MULTICAST_LOOP
IPV6_マルチキャスト_輪
If a multicast datagram is sent to a group to which the sending
host itself belongs (on the outgoing interface), a copy of the
datagram is looped back by the IP layer for local delivery if
this option is set to 1. If this option is set to 0 a copy
is not looped back. Other option values return an error of
EINVAL.
送付ホスト自身が属する(外向的なインタフェースで)グループにマルチキャストデータグラムを送るなら、このオプションを1に設定するなら、地方の配送のためにIP層でデータグラムのコピーを輪にします。 このオプションが0に設定されるなら、コピーは輪にし返されません。 他のオプション価値はEINVALの誤りを返します。
If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
same as IPv4 today).
IPV6_MULTICAST_LOOPが用意ができていないなら、デフォルトは1(ループバック; 今日のIPv4と同じこと)です。
Argument type: unsigned int
議論タイプ: 未署名のint
The reception of multicast packets is controlled by the two setsockopt() options summarized below. An error of EOPNOTSUPP is returned if these two options are used with getsockopt().
マルチキャストパケットのレセプションは以下へまとめられた2つのsetsockopt()オプションで制御されます。 これらの2つのオプションがgetsockopt()と共に使用されるなら、EOPNOTSUPPの誤りは返されます。
IPV6_JOIN_GROUP
IPV6_は_グループに加わります。
Join a multicast group on a specified local interface. If the
interface index is specified as 0, the kernel chooses the local
interface. For example, some kernels look up the multicast
group in the normal IPv6 routing table and using the resulting
interface.
Argument type: struct ipv6_mreq
IPV6_LEAVE_GROUP
Leave a multicast group on a specified interface.
Argument type: 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;
Gilligan, et. al. Informational [Page 20] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
struct ipv6_mreq {
struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
unsigned int ipv6mr_interface; /* interface index */
};
Note that to receive multicast datagrams a process must join the multicast group and bind the UDP port to which datagrams will be sent. Some processes also bind the multicast group address to the socket, in addition to the port, to prevent other datagrams destined to that same port from being delivered to the socket.
6. Library Functions
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.
6.1 Nodename-to-Address Translation
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 following function is new and must be thread safe:
#include <sys/socket.h> #include <netdb.h>
struct hostent *getipnodebyname(const char *name, int af, int flags
int *error_num);
The name argument can be either a node name or a numeric address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address). The af argument specifies the address family, either AF_INET or
Gilligan, et. al. Informational [Page 21] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
AF_INET6. The error_num value is returned to the caller, via a pointer, with the appropriate error code in error_num, to support thread safe error code returns. error_num will be set to one of the following values:
HOST_NOT_FOUND
No such host is known.
NO_ADDRESS
The server recognised the request and the name but no address is
available. Another type of request to the name server for the
domain might return an answer.
NO_RECOVERY
An unexpected server failure occurred which cannot be recovered.
TRY_AGAIN
A temporary and possibly transient error occurred, such as a
failure of a server to respond.
The flags argument specifies the types of addresses that are searched for, and the types of addresses that are returned. We note that a special flags value of AI_DEFAULT (defined below) should handle most applications.
That is, porting simple applications to use IPv6 replaces the call
hptr = gethostbyname(name);
with
hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num);
and changes any subsequent error diagnosis code to use error_num instead of externally declared variables, such as h_errno.
Applications desiring finer control over the types of addresses searched for and returned, can specify other combinations of the flags argument.
Gilligan, et. al. Informational [Page 22] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
A flags of 0 implies a strict interpretation of the af argument:
- If flags is 0 and af is AF_INET, then the caller wants only
IPv4 addresses. A query is made for A records. If successful,
the IPv4 addresses are returned and the h_length member of the
hostent structure will be 4, else the function returns a NULL
pointer.
- If flags is 0 and if af is AF_INET6, then the caller wants only
IPv6 addresses. A query is made for AAAA records. If
successful, the IPv6 addresses are returned and the h_length
member of the hostent structure will be 16, else the function
returns a NULL pointer.
Other constants can be logically-ORed into the flags argument, to modify the behavior of the function.
- If the AI_V4MAPPED flag is specified along with an af of
AF_INET6, then the caller will accept IPv4-mapped IPv6
addresses. That is, if no AAAA records are found then a query
is made for A records and any found are returned as IPv4-mapped
IPv6 addresses (h_length will be 16). The AI_V4MAPPED flag is
ignored unless af equals AF_INET6.
- The AI_ALL flag is used in conjunction with the AI_V4MAPPED
flag, and is only used with the IPv6 address family. When AI_ALL
is logically or'd with AI_V4MAPPED flag then the caller wants
all addresses: IPv6 and IPv4-mapped IPv6. A query is first made
for AAAA records and if successful, the IPv6 addresses are
returned. Another query is then made for A records and any found
are returned as IPv4-mapped IPv6 addresses. h_length will be 16.
Only if both queries fail does the function return a NULL pointer.
This flag is ignored unless af equals AF_INET6.
- The AI_ADDRCONFIG flag specifies that a query for AAAA records
should occur only if the node has at least one IPv6 source
address configured and a query for A records should occur only
if the node has at least one IPv4 source address configured.
For example, if the node has no IPv6 source addresses
configured, and af equals AF_INET6, and the node name being
looked up has both AAAA and A records, then:
(a) if only AI_ADDRCONFIG is specified, the function
returns a NULL pointer;
(b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A
records are returned as IPv4-mapped IPv6 addresses;
Gilligan, et. al. Informational [Page 23] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
The special flags value of AI_DEFAULT is defined as
#define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG)
We noted that the getipnodebyname() function must allow the name argument to be either a node name or a literal address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address). This saves applications from having to call inet_pton() to handle literal address strings.
There are four scenarios based on the type of literal address string and the value of the af argument.
The two simple cases are:
When name is a dotted-decimal IPv4 address and af equals AF_INET, or when name is an IPv6 hex address and af equals AF_INET6. The members of the returned hostent structure are: h_name points to a copy of the name argument, h_aliases is a NULL pointer, h_addrtype is a copy of the af argument, h_length is either 4 (for AF_INET) or 16 (for AF_INET6), h_addr_list[0] is a pointer to the 4-byte or 16-byte binary address, and h_addr_list[1] is a NULL pointer.
When name is a dotted-decimal IPv4 address and af equals AF_INET6, and flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is returned: h_name points to an IPv6 hex address containing the IPv4- mapped IPv6 address, h_aliases is a NULL pointer, h_addrtype is AF_INET6, h_length is 16, h_addr_list[0] is a pointer to the 16-byte binary address, and h_addr_list[1] is a NULL pointer. If AI_V4MAPPED is set (with or without AI_ALL) return IPv4-mapped otherwise return NULL.
It is an error when name is an IPv6 hex address and af equals AF_INET. The function's return value is a NULL pointer and error_num equals HOST_NOT_FOUND.
6.2 Address-To-Nodename Translation
The following function has the same arguments as the existing gethostbyaddr() function, but adds an error number.
#include <sys/socket.h> #include <netdb.h>
struct hostent *getipnodebyaddr(const void *src, size_t len,
int af, int *error_num);
Gilligan, et. al. Informational [Page 24] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
As with getipnodebyname(), getipnodebyaddr() must be thread safe. The error_num value is returned to the caller with the appropriate error code, to support thread safe error code returns. The following error conditions may be returned for error_num:
HOST_NOT_FOUND
No such host is known.
NO_ADDRESS
The server recognized the request and the name but no address
is available. Another type of request to the name server for
the domain might return an answer.
NO_RECOVERY
An unexpected server failure occurred which cannot be
recovered.
TRY_AGAIN
A temporary and possibly transient error occurred, such as a
failure of a server to respond.
One possible source of confusion is the handling of IPv4-mapped IPv6 addresses and IPv4-compatible IPv6 addresses, but the following logic should apply.
1. If af is AF_INET6, and if len equals 16, and if the IPv6
address is an IPv4-mapped IPv6 address or an IPv4-compatible
IPv6 address, then skip over the first 12 bytes of the IPv6
address, set af to AF_INET, and set len to 4.
2. If af is AF_INET, lookup the name for the given IPv4 address
(e.g., query for a PTR record in the in-addr.arpa domain).
3. If af is AF_INET6, lookup the name for the given IPv6 address
(e.g., query for a PTR record in the ip6.int domain).
4. If the function is returning success, then the single address
that is returned in the hostent structure is a copy of the
first argument to the function with the same address family
that was passed as an argument to this function.
Gilligan, et. al. Informational [Page 25] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
All four steps listed are performed, in order. Also note that the IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4- compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST be returned and a query of the address not performed.
Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return false for "::" and "::1".
6.3 Freeing memory for getipnodebyname and getipnodebyaddr
The hostent structure does not change from its existing definition. This structure, and the information pointed to by this structure, are dynamically allocated by getipnodebyname and getipnodebyaddr. The following function frees this memory:
#include <netdb.h>
void freehostent(struct hostent *ptr);
6.4 Protocol-Independent Nodename and Service Name Translation
Nodename-to-address translation is done in a protocol-independent fashion using the getaddrinfo() function that is taken from the Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g (Protocol Independent Interfaces) draft specification [3].
The official specification for this function will be the final POSIX standard, with the following additional requirements:
- getaddrinfo() (along with the getnameinfo() function described
in the next section) must be thread safe.
- The AI_NUMERICHOST is new with this document.
- All fields in socket address structures returned by
getaddrinfo() that are not filled in through an explicit
argument (e.g., sin6_flowinfo and sin_zero) must be set to 0.
(This makes it easier to compare socket address structures.)
- getaddrinfo() must fill in the length field of a socket address
structure (e.g., sin6_len) on systems that support this field.
We are providing this independent description of the function because POSIX standards are not freely available (as are IETF documents).
#include <sys/socket.h>
#include <netdb.h>
Gilligan, et. al. Informational [Page 26] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
int getaddrinfo(const char *nodename, const char *servname,
const struct addrinfo *hints,
struct addrinfo **res);
The addrinfo structure is defined as a result of including the <netdb.h> header.
struct addrinfo {
int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
int ai_family; /* PF_xxx */
int ai_socktype; /* SOCK_xxx */
int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
size_t ai_addrlen; /* length of ai_addr */
char *ai_canonname; /* canonical name for nodename */
struct sockaddr *ai_addr; /* binary address */
struct addrinfo *ai_next; /* next structure in linked list */
};
The return value from the function is 0 upon success or a nonzero error code. The following names are the nonzero error codes from getaddrinfo(), and are defined in <netdb.h>:
EAI_ADDRFAMILY address family for nodename not supported
EAI_AGAIN temporary failure in name resolution
EAI_BADFLAGS invalid value for ai_flags
EAI_FAIL non-recoverable failure in name resolution
EAI_FAMILY ai_family not supported
EAI_MEMORY memory allocation failure
EAI_NODATA no address associated with nodename
EAI_NONAME nodename nor servname provided, or not known
EAI_SERVICE servname not supported for ai_socktype
EAI_SOCKTYPE ai_socktype not supported
EAI_SYSTEM system error returned in errno
nodenameがai_のために名前解決のEAI_BADFLAGSの無効の価値におけるEAI_AGAIN一時障害を支持しなかったので、EAI_ADDRFAMILYアドレス家がどんなアドレスもnodename EAI_NONAME nodenameに関連づけないで、servnameが提供したどんな名前解決EAI_FAMILY ai_家の支持されたEAI_MEMORYメモリ割り振りの失敗EAI_NODATAでもEAI_FAILの非回復可能な故障に旗を揚げさせないか、またはai_socktype EAI_SOCKTYPE ai_socktypeのために支持されなかったどんな知られているEAI_SERVICE servnameもerrnoで返されたEAI_SYSTEMシステム誤りを支持しませんでした。
The nodename and servname arguments are pointers to null-terminated strings or NULL. One or both of these two arguments must be a non- NULL pointer. In the normal client scenario, both the nodename and servname are specified. In the normal server scenario, only the servname is specified. A non-NULL nodename string can be either a node name or a numeric host address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address). A non-NULL servname string can be either a service name or a decimal port number.
nodenameとservname議論はヌルで終えられたストリングかNULLへのポインタです。 これらの2つの議論の1か両方が非NULLのポインタであるに違いありません。 正常なクライアントシナリオでは、nodenameとservnameの両方が指定されます。 正常なサーバシナリオでは、servnameだけが指定されます。 非NULL nodenameストリングは、ノード名か数値ホスト・アドレスストリングのどちらかであるかもしれません(すなわち、ドット付き10進法IPv4アドレスかIPv6十六進法アドレス)。 非NULL servnameストリングは、サービス名か10進ポートナンバーのどちらかであるかもしれません。
The caller can optionally pass an addrinfo structure, pointed to by the third argument, to provide hints concerning the type of socket that the caller supports. In this hints structure all members other than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or a NULL pointer. A value of PF_UNSPEC for ai_family means the
訪問者は、訪問者が支えるソケットのタイプに関してヒントを提供するために任意に3番目の議論で示されたaddrinfo構造を通り過ぎることができます。 これのai_旗以外のすべてのメンバー、ai_家族、ai_socktype、およびai_が議定書の中で述べる構造がゼロであるに違いないというヒントかNULLポインタ。 ai_家族平均のためのPF_UNSPECの値
Gilligan, et. al. Informational [Page 27] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[27ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
caller will accept any protocol family. A value of 0 for ai_socktype means the caller will accept any socket type. A value of 0 for ai_protocol means the caller will accept any protocol. For example, if the caller handles only TCP and not UDP, then the ai_socktype member of the hints structure should be set to SOCK_STREAM when getaddrinfo() is called. If the caller handles only IPv4 and not IPv6, then the ai_family member of the hints structure should be set to PF_INET when getaddrinfo() is called. If the third argument to getaddrinfo() is a NULL pointer, this is the same as if the caller had filled in an addrinfo structure initialized to zero with ai_family set to PF_UNSPEC.
訪問者はどんなプロトコル家族も受け入れるでしょう。 ai_socktypeのための0の値は、訪問者がどんなソケットタイプも受け入れることを意味します。 ai_プロトコルのための0の値は、訪問者がどんなプロトコルも受け入れることを意味します。 getaddrinfo()が呼ばれるとき、例えば、訪問者がUDPではなく、TCPだけを扱うなら、構造があるはずであるというヒントのai_socktypeメンバーはSOCK_STREAMにセットしました。 getaddrinfo()が呼ばれるとき、訪問者がIPv6ではなく、IPv4だけを扱うなら、構造があるはずであるというヒントのai_親族はPF_INETにセットしました。 getaddrinfo()への3番目の議論がNULLポインタであるなら、これは、_家族がPF_UNSPECに設定するaiでゼロに合わせるために訪問者が構造が初期化したaddrinfoに記入したのと同じです。
Upon successful return a pointer to a linked list of one or more addrinfo structures is returned through the final argument. The caller can process each addrinfo structure in this list by following the ai_next pointer, until a NULL pointer is encountered. In each returned addrinfo structure the three members ai_family, ai_socktype, and ai_protocol are the corresponding arguments for a call to the socket() function. In each addrinfo structure the ai_addr member points to a filled-in socket address structure whose length is specified by the ai_addrlen member.
うまくいっているリターンのときに、最終弁論を通して1つ以上のaddrinfo構造の繋がっているリストへのポインタを返します。 訪問者はこのリストでai_次ポインタに続くことによって、それぞれのaddrinfo構造を処理できます、NULLポインタが遭遇するまで。 それぞれの返されたaddrinfo構造では、ai_家族、ai_socktype、およびai_が議定書の中で述べる3人のメンバーがソケット()機能への呼び出しのための対応する議論です。 それぞれのaddrinfo構造では、ai_addrメンバーは長さがai_addrlenメンバーによって指定される記入しているソケットアドレス構造を示します。
If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, then the caller plans to use the returned socket address structure in a call to bind(). In this case, if the nodename argument is a NULL pointer, then the IP address portion of the socket address structure will be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address.
AI_PASSIVEビットがaiのヒントが構造化する_がメンバーに旗を揚げさせるセットであるなら、訪問者は、()を縛るという要求に返されたソケットアドレス構造を使用するのを計画しています。 この場合、ソケットアドレス構造のIPアドレスの部分はnodename議論がNULLポインタであるならIPv6アドレスのためにIPv4のためのいずれも記述するINADDR_かIN6ADDR_にどんな_INITも設定するためにことになるでしょう。
If the AI_PASSIVE bit is not set in the ai_flags member of the hints structure, then the returned socket address structure will be ready for a call to connect() (for a connection-oriented protocol) or either connect(), sendto(), or sendmsg() (for a connectionless protocol). In this case, if the nodename argument is a NULL pointer, then the IP address portion of the socket address structure will be set to the loopback address.
AI_PASSIVEビットがaiのヒントが構造化する_がメンバーに旗を揚げさせるセットでないなら、返されたソケットアドレス構造は()を接続するか(接続指向のプロトコルのために)、または()、sendto()、またはsendmsg()を接続するという(コネクションレスプロトコルのために)要求の準備ができるでしょう。 この場合、ソケットアドレス構造のIPアドレスの部分はnodename議論がNULLポインタであるならループバックアドレスに設定されるでしょう。
If the AI_CANONNAME bit is set in the ai_flags member of the hints structure, then upon successful return the ai_canonname member of the first addrinfo structure in the linked list will point to a null- terminated string containing the canonical name of the specified nodename.
AI_CANONNAMEビットがaiのヒントが構造化する_がメンバーに旗を揚げさせるセットであるなら、うまくいっているリターンのときに、繋がっているリストにおける最初のaddrinfo構造のai_canonname部材は指定されたnodenameの正準な名前を含むヌルの終えられたストリングを示すでしょう。
If the AI_NUMERICHOST bit is set in the ai_flags member of the hints structure, then a non-NULL nodename string must be a numeric host address string. Otherwise an error of EAI_NONAME is returned. This flag prevents any type of name resolution service (e.g., the DNS) from being called.
AI_NUMERICHOSTビットがaiのヒントが構造化する_がメンバーに旗を揚げさせるセットであるなら、非NULL nodenameストリングは数値ホスト・アドレスストリングであるに違いありません。 さもなければ、EAI_NONAMEの誤りは返されます。 この旗は、どんなタイプの名前解決サービス(例えば、DNS)も呼ばれるのを防ぎます。
Gilligan, et. al. Informational [Page 28] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[28ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
All of the information returned by getaddrinfo() is dynamically allocated: the addrinfo structures, and the socket address structures and canonical node name strings pointed to by the addrinfo structures. To return this information to the system the function freeaddrinfo() is called:
ダイナミックにgetaddrinfo()によって返された情報のすべてを割り当てます: addrinfo構造によって示されたaddrinfo構造、ソケットアドレス構造、および正準なノード名ストリング。 この情報をシステムに返すために、機能freeaddrinfo()は呼ばれます:
#include <sys/socket.h> #include <netdb.h>
#<sys/socket.h>#インクルード<netdb.h>を含めてください。
void freeaddrinfo(struct addrinfo *ai);
freeaddrinfo(struct addrinfo*ai)を欠如させてください。
The addrinfo structure pointed to by the ai argument is freed, along with any dynamic storage pointed to by the structure. This operation is repeated until a NULL ai_next pointer is encountered.
ai議論で示されたaddrinfo構造は解放されます、構造によって示されたどんなダイナミックストレージと共にも。 この操作は_NULL aiまで繰り返されて、次のポインタが遭遇するということです。
To aid applications in printing error messages based on the EAI_xxx codes returned by getaddrinfo(), the following function is defined.
getaddrinfo()によって返されたEAI_xxxコードに基づく印刷エラーメッセージでアプリケーションを支援するために、以下の機能は定義されます。
#include <sys/socket.h> #include <netdb.h>
#<sys/socket.h>#インクルード<netdb.h>を含めてください。
char *gai_strerror(int ecode);
*gai_strerror(int ecode)を炭にしてください。
The argument is one of the EAI_xxx values defined earlier and the return value points to a string describing the error. If the argument is not one of the EAI_xxx values, the function still returns a pointer to a string whose contents indicate an unknown error.
議論は、より早く定義されたEAI_xxx値の1つです、そして、リターン値は誤りについて説明するストリングを示します。 議論がEAI_xxx値の1つでないなら、機能はまだコンテンツが未知の誤りを示すストリングにポインタを返しています。
6.5 Socket Address Structure to Nodename and Service Name
6.5 Nodenameとサービス名へのソケットアドレス構造
The POSIX 1003.1g specification includes no function to perform the reverse conversion from getaddrinfo(): to look up a nodename and service name, given the binary address and port. Therefore, we define the following function:
POSIX1003.1g仕様はgetaddrinfo()からリバース・コンバージョンを実行するために機能を全く含んでいません: 2進のアドレスとポートを考えて、nodenameとサービス名を調べるために。 したがって、私たちは以下の機能を定義します:
#include <sys/socket.h>
#include <netdb.h>
#<sys/socket.h>#インクルード<netdb.h>を含めてください。
int getnameinfo(const struct sockaddr *sa, socklen_t salen,
char *host, size_t hostlen,
char *serv, size_t servlen,
int flags);
int getnameinfo(サイズ_t servlen、const struct sockaddr*sa、socklen_t salenは*ホスト(サイズ_t hostlen)炭*servを炭にして、intは弛みます)。
This function looks up an IP address and port number provided by the caller in the DNS and system-specific database, and returns text strings for both in buffers provided by the caller. The function indicates successful completion by a zero return value; a non-zero return value indicates failure.
この機能は、DNSとシステム特有のデータベースで訪問者によって提供されたIPアドレスとポートナンバーを調べて、両方のために訪問者によって提供されたバッファでテキスト文字列を返します。 機能は原点復帰値で無事終了を示します。 非原点復帰値は失敗を示します。
Gilligan, et. al. Informational [Page 29] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[29ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
The first argument, sa, points to either a sockaddr_in structure (for IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP address and port number. The salen argument gives the length of the sockaddr_in or sockaddr_in6 structure.
最初の主張(sa)はIPアドレスとポートナンバーを保持する構造のsockaddr_(IPv4のための)かsockaddr_in6構造(IPv6のための)のどちらかを示します。 議論がsockaddr_の長さを与えるか、またはsockaddr_in6が構造化するsalen。
The function returns the nodename associated with the IP address in the buffer pointed to by the host argument. The caller provides the size of this buffer via the hostlen argument. The service name associated with the port number is returned in the buffer pointed to by serv, and the servlen argument gives the length of this buffer. The caller specifies not to return either string by providing a zero value for the hostlen or servlen arguments. Otherwise, the caller must provide buffers large enough to hold the nodename and the service name, including the terminating null characters.
機能はホスト議論で示されたバッファのIPアドレスに関連しているnodenameを返します。 訪問者はhostlen議論でこのバッファのサイズを提供します。 servによって示されたバッファでポートナンバーに関連しているサービス名を返します、そして、servlen議論はこのバッファの長さを与えます。 訪問者は、ゼロがhostlenのために評価する提供かservlen議論でどちらのストリングも返さないように指定します。 さもなければ、訪問者はnodenameとサービス名を保持できるくらい大きいバッファを提供しなければなりません、終端空文字を含んでいて。
Unfortunately most systems do not provide constants that specify the maximum size of either a fully-qualified domain name or a service name. Therefore to aid the application in allocating buffers for these two returned strings the following constants are defined in <netdb.h>:
残念ながらほとんどのシステムは完全修飾ドメイン名かサービス名のどちらかの最大サイズを指定する定数を提供しません。 したがって、これらの2個の返されたストリングのためのバッファを割り当てる際にアプリケーションを支援するために、以下の定数は<netdb.h>で定義されます:
#define NI_MAXHOST 1025
#define NI_MAXSERV 32
#定義、NI_MAXHOST1025#、はNI_MAXSERV32を定義します。
The first value is actually defined as the constant MAXDNAME in recent versions of BIND's <arpa/nameser.h> header (older versions of BIND define this constant to be 256) and the second is a guess based on the services listed in the current Assigned Numbers RFC.
最初の値は実際にBINDの<アルパ/nameser.h>ヘッダーの最近のバージョンで一定のMAXDNAMEと定義されます、そして、(BINDの旧式のバージョンは256になるようにこの定数を定義します)2番目は現在のAssigned民数記RFCに記載されたサービスに基づく推測です。
The final argument is a flag that changes the default actions of this function. By default the fully-qualified domain name (FQDN) for the host is looked up in the DNS and returned. If the flag bit NI_NOFQDN is set, only the nodename portion of the FQDN is returned for local hosts.
最終弁論はこの機能のデフォルト動作を変える旗です。 デフォルトで、ホストへの完全修飾ドメイン名(FQDN)をDNSで調べて、返します。 フラグビットNI_NOFQDNが用意ができているなら、ローカル・ホストのためにFQDNのnodename部分だけを返します。
If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be located in the DNS, the numeric form of the host's address is returned instead of its name (e.g., by calling inet_ntop() instead of getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is returned if the host's name cannot be located in the DNS.
ホストの名前がDNSに位置できないならフラグビットNI_NUMERICHOSTが用意ができているなら、名前の代わりに数値フォームのホストのアドレスを返します。(例えば、inet_をgetipnodebyaddr())の代わりにntop()と呼ぶことによって。 フラグビットNI_NAMEREQDが用意ができて、ホストの名前がDNSに位置できないなら、誤りは返されます。
If the flag bit NI_NUMERICSERV is set, the numeric form of the service address is returned (e.g., its port number) instead of its name. The two NI_NUMERICxxx flags are required to support the "-n" flag that many commands provide.
フラグビットNI_NUMERICSERVが用意ができているなら、名前の代わりにサービスアドレスの数値フォームを返します(例えば、ポートナンバー)。 2個のNI_NUMERICxxx旗が、多くのコマンドが提供する「-n」旗を支えるのに必要です。
Gilligan, et. al. Informational [Page 30] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[30ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
A fifth flag bit, NI_DGRAM, specifies that the service is a datagram service, and causes getservbyport() to be called with a second argument of "udp" instead of its default of "tcp". This is required for the few ports (e.g. 512-514) that have different services for UDP and TCP.
5番目のフラグビット(NI_DGRAM)で、サービスがデータグラムサービスであると指定して、"tcp"のデフォルトの代わりに"udp"の2番目の議論でgetservbyport()を呼びます。 これがUDPとTCPのための異なったサービスを持っているわずかなポート(例えば、512-514)に必要です。
These NI_xxx flags are defined in <netdb.h> along with the AI_xxx flags already defined for getaddrinfo().
これらのNI_xxx旗はgetaddrinfoのために既に定義されたAI_xxx旗に伴う<netdb.h>で定義されます。().
6.6 Address Conversion Functions
6.6 アドレス変換機能
The two functions inet_addr() and inet_ntoa() convert an IPv4 address between binary and text form. IPv6 applications need similar functions. The following two functions convert both IPv6 and IPv4 addresses:
2機能inet_addr() そして、inet_ntoa() バイナリーとテキストフォームの間のIPv4アドレスを変換してください。 IPv6アプリケーションは同様の機能を必要とします。 以下の2つの機能がIPv6とIPv4アドレスの両方を変換します:
#include <sys/socket.h>
#include <arpa/inet.h>
#<sys/socket.h>#インクルード<アルパ/inet.h>を含めてください。
int inet_pton(int af, const char *src, void *dst);
int inet_pton(int af、const炭*srcは*dstを欠如させます)。
const char *inet_ntop(int af, const void *src,
char *dst, size_t size);
const炭*のinet_ntop(int af、const空間*srcは*dst、サイズ_tサイズを炭にします)。
The inet_pton() function converts an address in its standard text presentation form into its numeric binary form. The af argument specifies the family of the address. Currently the AF_INET and AF_INET6 address families are supported. The src argument points to the string being passed in. The dst argument points to a buffer into which the function stores the numeric address. The address is returned in network byte order. Inet_pton() returns 1 if the conversion succeeds, 0 if the input is not a valid IPv4 dotted- decimal string or a valid IPv6 address string, or -1 with errno set to EAFNOSUPPORT if the af argument is unknown. The calling application must ensure that the buffer referred to by dst is large enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16 bytes for AF_INET6).
inet_pton()機能は標準のテキスト表示形で数値二部形式にアドレスを変換します。 af議論はアドレスの家族を指定します。 現在の、AF_INETとAF_INET6アドレス家は養われます。 src議論は渡されるストリングを示します。 dst議論は機能が数値アドレスを格納するバッファを示します。 ネットワークバイトオーダーでアドレスを返します。 変換が成功するなら、Inet_pton()が1を返すか、0が入力が有効なIPv4でないなら10進ストリングか有効なIPv6アドレスストリングに点を打たせたか、またはaf議論が未知であるなら、errnoがある-1はEAFNOSUPPORTにセットしました。 呼ぶアプリケーションはdstによって示されたバッファが確実に数値アドレス(例えば、AF_INETのための4バイトかAF_INET6のための16バイト)を保持できるくらい大きくなるようにしなければなりません。
If the af argument is AF_INET, the function accepts a string in the standard IPv4 dotted-decimal form:
af議論がAF_INETであるなら、機能は標準のIPv4ドット付き10進法フォームでストリングを受け入れます:
ddd.ddd.ddd.ddd
ddd.ddd.ddd.ddd
where ddd is a one to three digit decimal number between 0 and 255. Note that many implementations of the existing inet_addr() and inet_aton() functions accept nonstandard input: octal numbers, hexadecimal numbers, and fewer than four numbers. inet_pton() does not accept these formats.
dddでは、1〜3ケタは0〜255の10進数ですか? 既存のinet_addr()とinet_aton()機能の多くの実現が標準的でない入力を受け入れることに注意してください: 8進数、16進数、および4つ未満の番号inet_pton()はこれらの形式を受け入れません。
Gilligan, et. al. Informational [Page 31] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[31ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
If the af argument is AF_INET6, then the function accepts a string in one of the standard IPv6 text forms defined in Section 2.2 of the addressing architecture specification [2].
af議論がAF_INET6であるなら、機能はアドレッシング体系仕様[2]のセクション2.2で定義された標準のIPv6テキストフォームの1つでストリングを受け入れます。
The inet_ntop() function converts a numeric address into a text string suitable for presentation. The af argument specifies the family of the address. This can be AF_INET or AF_INET6. The src argument points to a buffer holding an IPv4 address if the af argument is AF_INET, or an IPv6 address if the af argument is AF_INET6, the address must be in network byte order. The dst argument points to a buffer where the function will store the resulting text string. The size argument specifies the size of this buffer. The application must specify a non-NULL dst argument. For IPv6 addresses, the buffer must be at least 46-octets. For IPv4 addresses, the buffer must be at least 16-octets. In order to allow applications to easily declare buffers of the proper size to store IPv4 and IPv6 addresses in string form, the following two constants are defined in <netinet/in.h>:
inet_ntop()機能はプレゼンテーションに適したテキスト文字列に数値アドレスを変換します。 af議論はアドレスの家族を指定します。 これは、AF_INETかAF_INET6であるかもしれません。 議論がaf議論がAF_INET6であるならaf議論がAF_INETであるならIPv4アドレスを保持するバッファ、またはIPv6アドレスに指すsrc、ネットワークバイトオーダーにはアドレスがあるに違いありません。 dst議論は機能が結果として起こるテキスト文字列を格納するバッファを示します。 サイズ議論はこのバッファのサイズを指定します。 アプリケーションは非NULL dst議論を指定しなければなりません。 IPv6アドレスのために、少なくともバッファは46八重奏でなければなりません。 IPv4アドレスのために、少なくともバッファは16八重奏でなければなりません。 アプリケーションが、適切なサイズに関するバッファがストリングフォームにIPv4とIPv6アドレスを格納すると容易に宣言するのを許容するために、以下の2つの定数が<netinet/in.h>で定義されます:
#define INET_ADDRSTRLEN 16
#define INET6_ADDRSTRLEN 46
#定義、INET_ADDRSTRLEN16#、はINET6_ADDRSTRLEN46を定義します。
The inet_ntop() function returns a pointer to the buffer containing the text string if the conversion succeeds, and NULL otherwise. Upon failure, errno is set to EAFNOSUPPORT if the af argument is invalid or ENOSPC if the size of the result buffer is inadequate.
そうでなければ、inet_ntop()機能は変換が成功するならテキスト文字列を入れてあるバッファ、およびNULLにポインタを返します。 失敗では、errnoは結果バッファのサイズが不十分であるなら、af議論が病人かENOSPCであるならEAFNOSUPPORTに用意ができています。
6.7 Address Testing Macros
6.7 アドレステストマクロ
The following macros can be used to test for special IPv6 addresses.
特別なIPv6アドレスがないかどうかテストするのに以下のマクロを使用できます。
#include <netinet/in.h>
#<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_は_ADDR_UNSPECIFIED(const struct in6_addr*)です。 int IN6_は_ADDR_LOOPBACK(const struct in6_addr*)です。 int IN6_は_ADDR_MULTICAST(const struct in6_addr*)です。 int IN6_は_ADDR_LINKLOCAL(const struct in6_addr*)です。 int IN6_は_ADDR_SITELOCAL(const struct in6_addr*)です。 int IN6_は_ADDR_V4MAPPED(const struct in6_addr*)です。 int IN6_は_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 *);
int IN6_は__NODELOCAL ADDR_M.C.(const struct in6_addr*)です。 int IN6_は__LINKLOCAL ADDR_M.C.(const struct in6_addr*)です。 int IN6_は__SITELOCAL ADDR_M.C.(const struct in6_addr*)です。 int IN6_は__ORGLOCAL ADDR_M.C.(const struct in6_addr*)です。 int IN6_は__GLOBAL ADDR_M.C.(const struct in6_addr*)です。
Gilligan, et. al. Informational [Page 32] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[32ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
The first seven macros return true if the address is of the specified type, or false otherwise. The last five test the scope of a multicast address and return true if the address is a multicast address of the specified scope or false if the address is either not a multicast address or not of the specified scope. Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for the two local-use IPv6 unicast addresses. These two macros do not return true for IPv6 multicast addresses of either link-local scope or site-local scope.
そうでなければ、アドレスが指定されたタイプにはあるか、または誤っているなら、最初の7つのマクロが本当に戻ります。 最後の5は、マルチキャストアドレスの範囲を検査して、アドレスがマルチキャストアドレスでないならアドレスが指定された範囲の指定された範囲か誤ることのマルチキャストアドレスであるなら本当に戻ります。 IN6_が_ADDR_LINKLOCALとIN6_であるというメモはADDR_SITELOCALが2つの地方の使用IPv6ユニキャストアドレスのためだけに本当に返す_です。 これらの2つのマクロは本当にリンク地方の範囲かサイト地方の範囲のどちらかのIPv6マルチキャストアドレスのお返しをしません。
7. Summary of New Definitions
7. 新しい定義の概要
The following list summarizes the constants, structure, and extern definitions discussed in this memo, sorted by header.
以下のリストはヘッダーによって分類されたこのメモで議論した定数、構造、および通いの人定義をまとめます。
<net/if.h> IF_NAMESIZE
<net/if.h> struct if_nameindex{};
<ネット/if.h>が_NAMESIZE<ネット/if.h>であるなら_nameindexであるならstructされる、。
<netdb.h> AI_ADDRCONFIG
<netdb.h> AI_DEFAULT
<netdb.h> AI_ALL
<netdb.h> AI_CANONNAME
<netdb.h> AI_NUMERICHOST
<netdb.h> AI_PASSIVE
<netdb.h> AI_V4MAPPED
<netdb.h> EAI_ADDRFAMILY
<netdb.h> EAI_AGAIN
<netdb.h> EAI_BADFLAGS
<netdb.h> EAI_FAIL
<netdb.h> EAI_FAMILY
<netdb.h> EAI_MEMORY
<netdb.h> EAI_NODATA
<netdb.h> EAI_NONAME
<netdb.h> EAI_SERVICE
<netdb.h> EAI_SOCKTYPE
<netdb.h> EAI_SYSTEM
<netdb.h> NI_DGRAM
<netdb.h> NI_MAXHOST
<netdb.h> NI_MAXSERV
<netdb.h> NI_NAMEREQD
<netdb.h> NI_NOFQDN
<netdb.h> NI_NUMERICHOST
<netdb.h> NI_NUMERICSERV
<netdb.h> struct addrinfo{};
_受け身の<netdb.h>AI_ADDRCONFIG<netdb.h>AI_デフォルト<netdb.h>AIのEAI_ADDRFAMILY<netdb.h>EAI_<netdb.h>AI_CANONNAME<netdb.h>AI_NUMERICHOST<netdb.h>AI<netdb.h>AI_V4MAPPED<netdb.h>_、一方、<netdb.h>EAI_BADFLAGS<netdb.h>EAI_やり損ない<netdb.h>EAI_家族<netdb.h>EAI_メモリ<はnetdbします; h>EAI_NODATA<netdb.h>EAI_NONAME<netdb.h>EAI_SERVICE<netdb.h>EAI_SOCKTYPE<netdb.h>EAI_SYSTEM<netdb.h>NI_DGRAM<netdb.h>NI_MAXHOST<netdb.h>NI_MAXSERV<netdb.h>NI_NAMEREQD<netdb.h>NI_NOFQDN<netdb.h>NI_NUMERICHOST<netdb.h>NI_NUMERICSERV<netdb.h>struct addrinfo、。
<netinet/in.h> IN6ADDR_ANY_INIT
<netinet/in.h> IN6ADDR_LOOPBACK_INIT
<netinet/in.h> INET6_ADDRSTRLEN
_<netinet/in.h>IN6ADDRは_どんな_イニット<netinet/in.h>IN6ADDR_ループバックイニット<netinet/in.h>INET6_ADDRSTRLENです。
Gilligan, et. al. Informational [Page 33] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[33ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
<netinet/in.h> INET_ADDRSTRLEN
<netinet/in.h> IPPROTO_IPV6
<netinet/in.h> IPV6_JOIN_GROUP
<netinet/in.h> IPV6_LEAVE_GROUP
<netinet/in.h> IPV6_MULTICAST_HOPS
<netinet/in.h> IPV6_MULTICAST_IF
<netinet/in.h> IPV6_MULTICAST_LOOP
<netinet/in.h> IPV6_UNICAST_HOPS
<netinet/in.h> SIN6_LEN
<netinet/in.h> extern const struct in6_addr in6addr_any;
<netinet/in.h> extern const struct in6_addr in6addr_loopback;
<netinet/in.h> struct in6_addr{};
<netinet/in.h> struct ipv6_mreq{};
<netinet/in.h> struct sockaddr_in6{};
<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_ホップス<netinet/in.h>IPV6_MULTICAST_、<netinet/in.h>IPV6_MULTICAST_LOOP<netinet/in.h>IPV6_UNICAST_ホップス<netinet/in.h>SIN6_LEN<netinet/in.h>通いの人const struct in6_addr in6addr_である、いずれも。 <netinet/in.h>通いの人const struct in6_addr in6addr_ループバック。 <netinet/in.h>struct in6_addr、。 <netinet/in.h>struct ipv6_mreq、。 <netinet/in.h>struct sockaddr_in6、。
<sys/socket.h> AF_INET6
<sys/socket.h> PF_INET6
<sys/socket.h> struct sockaddr_storage;
<sys/socket.h>AF_INET6<sys/socket.h>PF_INET6<sys/socket.h>struct sockaddr_格納。
The following list summarizes the function and macro prototypes discussed in this memo, sorted by header.
以下のリストはヘッダーによって分類されたこのメモで議論した機能とマクロ原型をまとめます。
<arpa/inet.h> int inet_pton(int, const char *, void *);
<arpa/inet.h> const char *inet_ntop(int, const void *,
char *, size_t);
<アルパ/inet.h>int inet_pton(int、const炭*は*を欠如させます)。 <アルパ/inet.hの>のconst炭*のinet_ntop(intであって、constな空間*、炭*、サイズ_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);
<ネット/if.h>は*_indextoname(無記名のint、炭の*)であるなら焦げます。 <ネット/if.hの>の無記名のintは_であるなら(const炭*)をnametoindexします。 _freenameindexであるなら(_nameindex*であるなら、structします)>が欠如させる<ネット/if.h。 _nameindexであるなら、*_nameindexであるなら(空の)、<ネット/if.h>はstructされます。
<netdb.h> int getaddrinfo(const char *, const char *,
const struct addrinfo *,
struct addrinfo **);
<netdb.h> int getnameinfo(const struct sockaddr *, socklen_t,
char *, size_t, char *, size_t, int);
<netdb.h> void freeaddrinfo(struct addrinfo *);
<netdb.h> char *gai_strerror(int);
<netdb.h> struct hostent *getipnodebyname(const char *, int, int,
int *);
<netdb.h> struct hostent *getipnodebyaddr(const void *, size_t,
int, int *);
<netdb.h> void freehostent(struct hostent *);
<netdb.h>int getaddrinfo(const炭*、const炭*、const struct addrinfo*、struct addrinfo**)。 <netdb.h>int getnameinfo(const struct sockaddr*、socklen_t、炭*、サイズ_tは*、サイズ_t、intを炭にします)。 <のnetdb.hの>の空のfreeaddrinfo(struct addrinfo*)。 <netdb.h>炭*のgai_strerror(int)。 <netdb.h>struct hostent*getipnodebyname(const炭*、int、int、int*)。 <netdb.h>struct hostent*getipnodebyaddr(const空間*、サイズ_t、int、int*)。 <のnetdb.hの>の空のfreehostent(struct hostent*)。
<netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); <netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
<netinet/in.h>int IN6_は_ADDR_LINKLOCAL(const struct in6_addr*)です。 <netinet/in.h>int IN6_は_ADDR_LOOPBACK(const struct in6_addr*)です。 <netinet/in.h>int IN6_は__GLOBAL ADDR_M.C.(const struct in6_addr*)です。 <netinet/in.h>int IN6_は__LINKLOCAL ADDR_M.C.(const struct in6_addr*)です。
Gilligan, et. al. Informational [Page 34] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[34ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
<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 *);
<netinet/in.h>int IN6_は__NODELOCAL ADDR_M.C.(const struct in6_addr*)です。 <netinet/in.h>int IN6_は__ORGLOCAL ADDR_M.C.(const struct in6_addr*)です。 <netinet/in.h>int IN6_は__SITELOCAL ADDR_M.C.(const struct in6_addr*)です。 <netinet/in.h>int IN6_は_ADDR_MULTICAST(const struct in6_addr*)です。 <netinet/in.h>int IN6_は_ADDR_SITELOCAL(const struct in6_addr*)です。 <netinet/in.h>int IN6_は_ADDR_UNSPECIFIED(const struct in6_addr*)です。 <netinet/in.h>int IN6_は_ADDR_V4COMPAT(const struct in6_addr*)です。 <netinet/in.h>int IN6_は_ADDR_V4MAPPED(const struct in6_addr*)です。
8. Security Considerations
8. セキュリティ問題
IPv6 provides a number of new security mechanisms, many of which need to be accessible to applications. Companion memos detailing the extensions to the socket interfaces to support IPv6 security are being written.
IPv6は多くの新しいセキュリティー対策を提供します。その多くがアプリケーションにアクセスしやすい必要があります。 IPv6セキュリティを支持するためにソケットインタフェースに拡大を詳しく述べる仲間メモが書かれています。
9. Year 2000 Considerations
9. Y2K問題
There are no issues for this memo concerning the Year 2000 issue regarding the use of dates.
日付の使用に関するY2K問題に関してこのメモのための問題が全くありません。
Changes From RFC 2133
RFC2133からの変化
Changes made in the March 1998 Edition (-01 draft):
変化は3月に1998Editionを(-01草稿)にしました:
Changed all "hostname" to "nodename" for consistency with other
IPv6 documents.
一貫性のために他のIPv6ドキュメントですべての「ホスト名」を"nodename"に変えました。
Section 3.3: changed comment for sin6_flowinfo to be "traffic
class & flow info" and updated corresponding text description to
current definition of these two fields.
セクション3.3: sin6_flowinfoが「交通クラスと流れインフォメーション」であるためにコメントを変えて、これらの2つの分野の現在の定義に対応するテキスト記述をアップデートしました。
Section 3.10 ("Portability Additions") is new.
セクション3.10(「携帯性追加」)は新しいです。
Section 6: a new paragraph was added reiterating that the existing
gethostbyname() and gethostbyaddr() are not changed.
セクション6: 既存のgethostbyname()とgethostbyaddr()が変えられないのを繰り返しながら、新しいパラグラフは加えられました。
Section 6.1: change gethostbyname3() to getnodebyname(). Add
AI_DEFAULT to handle majority of applications. Renamed
AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and
IPv4 addresses too. Defined exactly what getnodebyname() must
return if the name argument is a numeric address string.
セクション6.1: gethostbyname3()をgetnodebyname()に変えてください。 AI_DEFAULTを加えて、アプリケーションの大多数を扱ってください。 AI_ADDRCONFIGへのAI_V6ADDRCONFIGに改名されて、A記録とIPv4アドレスのためにもそれを定義してください。 名前引数が数値アドレスストリングであるならgetnodebyname()がまさに何を返さなければならないかを定義しました。
Section 6.2: change gethostbyaddr() to getnodebyaddr(). Reword
items 2 and 3 in the description of how to handle IPv4-mapped and
IPv4- compatible addresses to "lookup a name" for a given address,
instead of specifying what type of DNS query to issue.
セクション6.2: gethostbyaddr()をgetnodebyaddr()に変えてください。 当然のことのアドレスのためにどう「ルックアップa名」にIPv4によって写像されてIPv4コンパチブルアドレスを扱うかに関する記述で項目2と3を言い換えてください、DNSのタイプが質問することを指定すること発行するの代わりに。
Gilligan, et. al. Informational [Page 35] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[35ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
Section 6.3: added two more requirements to getaddrinfo().
セクション6.3: もう2つの要件をgetaddrinfo()に加えました。
Section 7: added the following constants to the list for
<netdb.h>: AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED. Add union
sockaddr_union and SA_LEN to the lists for <sys/socket.h>.
セクション7: <netdb.h>のためのリストに以下の定数を追加します: AI_ADDRCONFIG、AI、_すべて、そして、AI_V4MAPPED。 組合sockaddr_組合とSA_LENを<sys/socket.h>のためのリストに追加してください。
Updated references.
参照をアップデートしました。
Changes made in the November 1997 Edition (-00 draft):
変化は11月に1997Editionを(-00草稿)にしました:
The data types have been changed to conform with Draft 6.6 of the
Posix 1003.1g standard.
Posix1003.1g規格のDraft6.6に従うためにデータ型を変えました。
Section 3.2: data type of s6_addr changed to "uint8_t".
セクション3.2: s6_addrに関するデータ型は「uint8_t」に変化しました。
Section 3.3: data type of sin6_family changed to "sa_family_t".
data type of sin6_port changed to "in_port_t", data type of
sin6_flowinfo changed to "uint32_t".
セクション3.3: sin6_家族のデータ型は「sa_家族_t」に変化しました。sin6_ポートに関するデータ型は「_ポート_t」で変化しました、「uint32_t」に変わるsin6_flowinfoに関するデータ型。
Section 3.4: same as Section 3.3, plus data type of sin6_len
changed to "uint8_t".
セクション3.4: セクション3.3と同じであることで、sin6_lenに関するプラスデータ型は「uint8_t」に変化しました。
Section 6.2: first argument of gethostbyaddr() changed from "const
char *" to "const void *" and second argument changed from "int"
to "size_t".
セクション6.2: まず最初に、gethostbyaddr()の議論は「const炭*」から「const空間*」に変化しました、そして、2番目の議論は"int"から「サイズ_t」に変化しました。
Section 6.4: second argument of getnameinfo() changed from
"size_t" to "socklen_t".
セクション6.4: getnameinfo()の2番目の議論は、「_tをsocklenする」ように「サイズ_t」から変化しました。
The wording was changed when new structures were defined, to be
more explicit as to which header must be included to define the
structure:
構造を定義するためにどのヘッダーを含まなければならないかに関して、より明白になるように新しい構造を定義したとき、言葉遣いを変えました:
Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section
3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3
(ipv6_mreq{}), and Section 6.3 (addrinfo{}).
Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section 3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3 (ipv6_mreq{}), and Section 6.3 (addrinfo{}).
Section 4: NET_RT_LIST changed to NET_RT_IFLIST.
セクション4: ネット_RT_LISTは_ネットRT_IFLISTに変化しました。
Section 5.1: The IPV6_ADDRFORM socket option was removed.
セクション5.1: IPV6_ADDRFORMソケットオプションを取り除きました。
Section 5.3: Added a note that an option value other than 0 or 1
for IPV6_MULTICAST_LOOP returns an error. Added a note that
IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP
can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and
IPV6_DROP_MEMBERSHIP cannot be used with getsockopt().
セクション5.3: IPV6_MULTICAST_LOOPのための0か1以外のオプション価値が誤りを返すというメモを加えました。 aがそれに注意すると言い足す、IPV6_MULTICAST_、また、IPV6_MULTICAST_ホップス、およびIPV6_MULTICAST_LOOP缶がgetsockopt()と共に使用されて、getsockopt()と共にIPV6_ADD_MEMBERSHIPとIPV6_DROP_MEMBERSHIPだけを使用できません。
Gilligan, et. al. Informational [Page 36] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[36ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
Section 6.1: Removed the description of gethostbyname2() and its
associated RES_USE_INET6 option, replacing it with
gethostbyname3().
セクション6.1: それをgethostbyname3()に取り替えて、gethostbyname2()の記述とその関連RES_USE_INET6オプションを取り除きました。
Section 6.2: Added requirement that gethostbyaddr() be thread
safe. Reworded step 4 to avoid using the RES_USE_INET6 option.
セクション6.2: gethostbyaddr()が糸の金庫であるという要件を加えました。 RES_USE_INET6オプションを使用するのを避けるためにステップ4を言い換えました。
Section 6.3: Added the requirement that getaddrinfo() and
getnameinfo() be thread safe. Added the AI_NUMERICHOST flag.
セクション6.3: getaddrinfo()とgetnameinfo()が糸の金庫であるという要件を加えました。 AI_NUMERICHOST旗を加えました。
Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and
IN6_IS_ADDR_SITELOCAL macros.
セクション6.6: IN6_の周りの加えられた明確化は_ADDR_LINKLOCALです、そして、IN6_は_ADDR_SITELOCALマクロです。
Changes made to the draft -01 specification Sept 98
変化は9月98日に-01仕様を草稿にしました。
Changed priority to traffic class in the spec.
仕様の交通のクラスの優先権を変えました。
Added the need for scope identification in section 2.1.
セクション2.1で範囲識別の必要性を加えました。
Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and
3.4.
セクション3.3と3.4でsin6_範囲_イドをstruct sockaddr_in6に加えました。
Changed 3.10 to use generic storage structure to support holding
IPv6 addresses and removed the SA_LEN macro.
IPv6アドレスを保持するのを支持するのに一般的な格納構造を使用するために3.10を変えて、SA_LENマクロを取り除きました。
Distinguished between invalid input parameters and system failures
for Interface Identification in Section 4.1 and 4.2.
セクション4.1と4.2でInterface Identificationのための無効の入力パラメタとシステム障害の間で顕著です。
Added defaults for multicast operations in section 5.2 and changed
the names from ADD to JOIN and DROP to LEAVE to be consistent with
IPv6 multicast terminology.
IPv6マルチキャスト用語と一致しているようにセクション5.2でマルチキャスト操作のためのデフォルトを加えて、ADDからJOINとDROPからLEAVEに改称しました。
Changed getnodebyname to getipnodebyname, getnodebyaddr to
getipnodebyaddr, and added MT safe error code to function
parameters in section 6.
getipnodebynameへの変えられたgetnodebyname、getipnodebyaddrへのgetnodebyaddr、および加えられたMT安全な誤りはセクション6でパラメタを機能にコード化します。
Moved freehostent to its own sub-section after getipnodebyaddr now
6.3 (so this bumps all remaining sections in section 6.
freehostentに現在6.3にそれ自身の小区分後getipnodebyaddrに動かされました。(これはセクション6ですべての残っているセクションに突き当たります。
Clarified the use of AI_ALL and AI_V4MAPPED that these are
dependent on the AF parameter and must be used as a conjunction in
section 6.1.
接続詞としてセクション6.1で使用されていた状態でこれらがAFパラメタに依存していて、あるに違いないAIの_すべてと_AI V4MAPPEDの使用をはっきりさせました。
Removed the restriction that literal addresses cannot be used with
a flags argument in section 6.1.
旗の議論と共にセクション6.1で文字通りのアドレスを使用できないという制限を取り除きました。
Added Year 2000 Section to the draft
草稿への加えられたY2Kセクション
Gilligan, et. al. Informational [Page 37] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[37ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
Deleted Reference to the following because the attached is deleted
from the ID directory and has expired. But the logic from the
aforementioned draft still applies, so that was kept in Section
6.2 bullets after 3rd paragraph.
付属がIDディレクトリから削除されて、期限が切れたので、Referenceを以下に削除しました。 しかし、前述の草稿からの論理がまだ適用されているので、それは第3パラグラフの後にセクション6.2 弾丸に保たれました。
[7] P. Vixie, "Reverse Name Lookups of Encapsulated IPv4
Addresses in IPv6", Internet-Draft, <draft-vixie-ipng-
ipv4ptr-00.txt>, May 1996.
[7] P.Vixie、「要約のIPv4の逆の名前ルックアップは1996年5月にIPv6"、インターネット草稿、<草稿-vixie-ipng- ipv4ptr-00.txtに>を記述します」。
Deleted the following reference as it is no longer referenced.
And the draft has expired.
それがもう参照をつけられないので、以下の参照を削除しました。 そして、草稿は期限が切れました。
[3] D. McDonald, "A Simple IP Security API Extension to BSD
Sockets", Internet-Draft, <draft-mcdonald-simple-ipsec-api-
01.txt>, March 1997.
[3] D.マクドナルド、「BSDソケットへの簡単なIPセキュリティAPI拡大」、インターネット草稿、<草稿-mcdonald簡単なipsec-api-01.txtの>、1997年3月。
Deleted the following reference as it is no longer referenced.
それがもう参照をつけられないので、以下の参照を削除しました。
[4] C. Metz, "Network Security API for Sockets",
Internet-Draft, <draft-metz-net-security-api-01.txt>, January
1998.
[4] C.メス、「ソケットのためのネットワークセキュリティAPI」、インターネット草稿、<草稿-metzネットのセキュリティ-api-01.txtの>、1998年1月。
Update current references to current status.
現在の状態の現在の参照をアップデートしてください。
Added alignment notes for in6_addr and sin6_addr.
加えられた整列はin6_addrとsin6_によってaddrに注意します。
Clarified further that AI_V4MAPPED must be used with a dotted IPv4
literal address for getipnodebyname(), when address family is
AF_INET6.
アドレス家族がAF_INET6であるときに、さらにはっきりさせられて、getipnodebyname()に点を打たされたIPv4文字通りのアドレスと共にそのAI_V4MAPPEDを使用しなければなりません。
Added text to clarify "::" and "::1" when used by
getipnodebyaddr().
「はっきりさせるテキストは加えた」:、:、」 そして、「」、:、:1インチgetipnodebyaddr()によって使用されると。
Acknowledgments
承認
Thanks to the many people who made suggestions and provided feedback to this document, including: Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave Mitton, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl Williams, and Kazu Yamamoto,
多くの人々のおかげで、以下を含んでいて、だれが、このドキュメントに提案をして、フィードバックを供給しましたか? アトキンソン、フレッド・ベイカー、デーヴ・ボーマン、アンドリューCherenson、アレックス・コンタ、アランCox、スティーブ・デアリング、リチャードDraves、フランシス・デュポン、ロバートElz、マークHasson、トム・ハーバートは、ヴェルナーAlmesbergerがHinden、青白いYenシュー、クリスチャンのHuitema、Koji Imada、マーカスJork、ロンリー、アラン・ロイド、チャールズリン、ダン・マクドナルド、デーヴ・ミットン、トーマスNarten、ジョッシュ・オズボーン、クレイグPartridge、ジャンリュック・リシェ、エリックScoredos、キースSklower、マット・トーマス、ハーヴェイトンプソン(ディーンD)をたたくと述べました; Throop、カレン・トレーシー、グレンTrewitt、ポールVixie、デヴィッドWaitzman、カール・ウィリアムズ、およびKazu山本
Gilligan, et. al. Informational [Page 38] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[38ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
The getaddrinfo() and getnameinfo() functions are taken from an earlier Internet Draft by Keith Sklower. As noted in that draft, William Durst, Steven Wise, Michael Karels, and Eric Allman provided many useful discussions on the subject of protocol-independent name- to-address translation, and reviewed early versions of Keith Sklower's original proposal. Eric Allman implemented the first prototype of getaddrinfo(). The observation that specifying the pair of name and service would suffice for connecting to a service independent of protocol details was made by Marshall Rose in a proposal to X/Open for a "Uniform Network Interface".
getaddrinfo()とgetnameinfo()機能はキースSklowerによって以前のインターネットDraftから取られます。 その草稿で注意されるように、ウィリアムDurst、スティーブンWise、マイケルKarels、およびエリック・オールマンはキースSklowerの起案のプロトコルから独立している名前アドレス変換の、そして、見直された早めのバージョンの問題についての多くの役に立つ議論を提供しました。 エリック・オールマンはgetaddrinfo()の最初の原型を実行しました。 名前の、そして、サービスの組を指定するのがプロトコルの詳細の如何にかかわらずサービスに接続するのに十分であるだろうという観測は「一定のネットワーク・インターフェース」のためにマーシャル・ローズによって提案でX/Openにされました。
Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh Kacker made many contributions to this document. Ramesh Govindan made a number of contributions and co-authored an earlier version of this memo.
クレイグ・メス、ジャック・マッキャン、エリックNordmark、ティムHartrick、およびMukesh Kackerはこのドキュメントへの多くの貢献をしました。 Ramesh Govindanは多くの貢献をして、このメモの以前のバージョンについて共同執筆しました。
References
参照
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[1] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[2] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[2]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[3] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
6.6, March 1997.
[3] IEEE(「プロトコルインディペンデント・インタフェース」、IEEE Std1003.1g)は6.6、1997年3月を作成します。
[4] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
2292, February 1998.
[4] スティーブンス(W.とM.トーマス)は、「1998年2月にIPv6"、RFC2292年のソケットAPIを進めました」。
Gilligan, et. al. Informational [Page 39] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[39ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
Authors' Addresses
作者のアドレス
Robert E. Gilligan FreeGate Corporation 1208 E. Arques Ave. Sunnyvale, CA 94086
ロバートE.ギリガンFreeGate社1208のE.Arques Ave。 サニーベル、カリフォルニア 94086
Phone: +1 408 617 1004 EMail: gilligan@freegate.com
以下に電話をしてください。 +1 1004年の408 617メール: gilligan@freegate.com
Susan Thomson Bell Communications Research MRE 2P-343, 445 South Street Morristown, NJ 07960
モリスタウン、スーザントムソンベルコミュニケーションズ・リサーチMRE 2P-343、445のSouth通りニュージャージー 07960
Phone: +1 201 829 4514 EMail: set@thumper.bellcore.com
以下に電話をしてください。 +1 4514年の201 829メール: set@thumper.bellcore.com
Jim Bound Compaq Computer Corporation 110 Spitbrook Road ZK3-3/U14 Nashua, NH 03062-2698
ジム・制限されたコンパックコンピュータ社110のSpitbrook道路ZK3-3/U14ナッシュア、ニューハンプシャー03062-2698
Phone: +1 603 884 0400 EMail: bound@zk3.dec.com
以下に電話をしてください。 +1 0400年の603 884メール: bound@zk3.dec.com
W. Richard Stevens 1202 E. Paseo del Zorro Tucson, AZ 85718-2826
W.リチャード・スティーブンス1202・E.Paseo delゾロ・ツーソン、アリゾナ85718-2826
Phone: +1 520 297 9416 EMail: rstevens@kohala.com
以下に電話をしてください。 +1 9416年の520 297メール: rstevens@kohala.com
Gilligan, et. al. Informational [Page 40] RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
etギリガン、アル。 情報[40ページ]のRFC2553のIPv6 March 1999に、基本的なソケットインタフェース拡張子
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Gilligan, et. al. Informational [Page 41]
etギリガン、アル。 情報[41ページ]
一覧
スポンサーリンク
