Network Working Group W. Stevens
Request for Comments: 3542 M. Thomas
Obsoletes: 2292 Consultant
Category: Informational E. Nordmark
Sun
T. Jinmei
Toshiba
May 2003
Network Working Group W. Stevens
Request for Comments: 3542 M. Thomas
Obsoletes: 2292 Consultant
Category: Informational E. Nordmark
Sun
T. Jinmei
Toshiba
May 2003
Advanced Sockets Application Program Interface (API) for IPv6
用于IPv6的高级套接字应用程序接口（API）
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable.
本文档提供了支持“高级”IPv6应用程序的套接字应用程序接口（API），作为单独规范RFC 3493的补充。预期的应用程序包括Ping、Traceroute、路由守护进程等，它们通常使用原始套接字访问IPv6或ICMPv6头字段。本文档为在IPv6下使用原始套接字的应用程序提供了一些可移植接口。有些应用程序需要访问IPv6的其他功能：接口标识（指定传出接口并确定传入接口）、IPv6扩展头和路径最大传输单元（MTU）信息。本文档还提供了对这些功能的API访问。此外，还定义了“r”命令库的一些扩展接口。该扩展将为不支持IPv6的现有实现提供更好的向后兼容性。
Table of Contents
目录
1. Introduction .............................................. 3
2. Common Structures and Definitions ......................... 5
2.1 The ip6_hdr Structure ................................ 6
2.1.1 IPv6 Next Header Values ....................... 6
2.1.2 IPv6 Extension Headers ........................ 7
2.1.3 IPv6 Options .................................. 8
2.2 The icmp6_hdr Structure .............................. 10
2.2.1 ICMPv6 Type and Code Values ................... 10
2.2.2 ICMPv6 Neighbor Discovery Definitions ......... 11
2.2.3 Multicast Listener Discovery Definitions ...... 14
2.2.4 ICMPv6 Router Renumbering Definitions ......... 14
2.3 Address Testing Macros ............................... 16
2.4 Protocols File ....................................... 16
3. IPv6 Raw Sockets .......................................... 17
3.1 Checksums ............................................ 18
3.2 ICMPv6 Type Filtering ................................ 19
3.3 ICMPv6 Verification of Received Packets .............. 22
4. Access to IPv6 and Extension Headers ...................... 22
4.1 TCP Implications ..................................... 24
4.2 UDP and Raw Socket Implications ...................... 25
5. Extensions to Socket Ancillary Data ....................... 26
5.1 CMSG_NXTHDR .......................................... 26
5.2 CMSG_SPACE ........................................... 26
5.3 CMSG_LEN ............................................. 27
6. Packet Information ........................................ 27
6.1 Specifying/Receiving the Interface ................... 28
6.2 Specifying/Receiving Source/Destination Address ...... 29
6.3 Specifying/Receiving the Hop Limit ................... 29
6.4 Specifying the Next Hop Address ...................... 30
6.5 Specifying/Receiving the Traffic Class value ......... 31
6.6 Additional Errors with sendmsg() and setsockopt() .... 32
6.7 Summary of Outgoing Interface Selection .............. 32
7. Routing Header Option ..................................... 33
7.1 inet6_rth_space ...................................... 35
7.2 inet6_rth_init ....................................... 35
7.3 inet6_rth_add ........................................ 36
7.4 inet6_rth_reverse .................................... 36
7.5 inet6_rth_segments ................................... 36
7.6 inet6_rth_getaddr .................................... 36
8. Hop-By-Hop Options ........................................ 37
8.1 Receiving Hop-by-Hop Options ......................... 38
8.2 Sending Hop-by-Hop Options ........................... 38
9. Destination Options ....................................... 39
9.1 Receiving Destination Options ........................ 39
9.2 Sending Destination Options .......................... 39
10. Hop-by-Hop and Destination Options Processing ............. 40
1. Introduction .............................................. 3
2. Common Structures and Definitions ......................... 5
2.1 The ip6_hdr Structure ................................ 6
2.1.1 IPv6 Next Header Values ....................... 6
2.1.2 IPv6 Extension Headers ........................ 7
2.1.3 IPv6 Options .................................. 8
2.2 The icmp6_hdr Structure .............................. 10
2.2.1 ICMPv6 Type and Code Values ................... 10
2.2.2 ICMPv6 Neighbor Discovery Definitions ......... 11
2.2.3 Multicast Listener Discovery Definitions ...... 14
2.2.4 ICMPv6 Router Renumbering Definitions ......... 14
2.3 Address Testing Macros ............................... 16
2.4 Protocols File ....................................... 16
3. IPv6 Raw Sockets .......................................... 17
3.1 Checksums ............................................ 18
3.2 ICMPv6 Type Filtering ................................ 19
3.3 ICMPv6 Verification of Received Packets .............. 22
4. Access to IPv6 and Extension Headers ...................... 22
4.1 TCP Implications ..................................... 24
4.2 UDP and Raw Socket Implications ...................... 25
5. Extensions to Socket Ancillary Data ....................... 26
5.1 CMSG_NXTHDR .......................................... 26
5.2 CMSG_SPACE ........................................... 26
5.3 CMSG_LEN ............................................. 27
6. Packet Information ........................................ 27
6.1 Specifying/Receiving the Interface ................... 28
6.2 Specifying/Receiving Source/Destination Address ...... 29
6.3 Specifying/Receiving the Hop Limit ................... 29
6.4 Specifying the Next Hop Address ...................... 30
6.5 Specifying/Receiving the Traffic Class value ......... 31
6.6 Additional Errors with sendmsg() and setsockopt() .... 32
6.7 Summary of Outgoing Interface Selection .............. 32
7. Routing Header Option ..................................... 33
7.1 inet6_rth_space ...................................... 35
7.2 inet6_rth_init ....................................... 35
7.3 inet6_rth_add ........................................ 36
7.4 inet6_rth_reverse .................................... 36
7.5 inet6_rth_segments ................................... 36
7.6 inet6_rth_getaddr .................................... 36
8. Hop-By-Hop Options ........................................ 37
8.1 Receiving Hop-by-Hop Options ......................... 38
8.2 Sending Hop-by-Hop Options ........................... 38
9. Destination Options ....................................... 39
9.1 Receiving Destination Options ........................ 39
9.2 Sending Destination Options .......................... 39
10. Hop-by-Hop and Destination Options Processing ............. 40
10.1 inet6_opt_init ...................................... 41
10.2 inet6_opt_append .................................... 41
10.3 inet6_opt_finish .................................... 42
10.4 inet6_opt_set_val ................................... 42
10.5 inet6_opt_next ...................................... 42
10.6 inet6_opt_find ...................................... 43
10.7 inet6_opt_get_val ................................... 43
11. Additional Advanced API Functions ......................... 44
11.1 Sending with the Minimum MTU ........................ 44
11.2 Sending without Fragmentation ....................... 45
11.3 Path MTU Discovery and UDP .......................... 46
11.4 Determining the Current Path MTU .................... 47
12. Ordering of Ancillary Data and IPv6 Extension Headers ..... 48
13. IPv6-Specific Options with IPv4-Mapped IPv6 Addresses ..... 50
14. Extended interfaces for rresvport, rcmd and rexec ......... 51
14.1 rresvport_af ........................................ 51
14.2 rcmd_af ............................................. 51
14.3 rexec_af ............................................ 52
15. Summary of New Definitions ................................ 52
16. Security Considerations ................................... 56
17. Changes from RFC 2292 ..................................... 57
18. References ................................................ 59
19. Acknowledgments ........................................... 59
20. Appendix A: Ancillary Data Overview ....................... 60
20.1 The msghdr Structure ................................ 60
20.2 The cmsghdr Structure ............................... 61
20.3 Ancillary Data Object Macros ........................ 62
20.3.1 CMSG_FIRSTHDR ............................... 63
20.3.2 CMSG_NXTHDR ................................. 64
20.3.3 CMSG_DATA ................................... 65
20.3.4 CMSG_SPACE .................................. 65
20.3.5 CMSG_LEN .................................... 65
21. Appendix B: Examples Using the inet6_rth_XXX() Functions .. 65
21.1 Sending a Routing Header ............................ 65
21.2 Receiving Routing Headers ........................... 70
22. Appendix C: Examples Using the inet6_opt_XXX() Functions .. 72
22.1 Building Options .................................... 72
22.2 Parsing Received Options ............................ 74
23. Authors' Addresses ........................................ 76
24. Full Copyright Statement .................................. 77
10.1 inet6_opt_init ...................................... 41
10.2 inet6_opt_append .................................... 41
10.3 inet6_opt_finish .................................... 42
10.4 inet6_opt_set_val ................................... 42
10.5 inet6_opt_next ...................................... 42
10.6 inet6_opt_find ...................................... 43
10.7 inet6_opt_get_val ................................... 43
11. Additional Advanced API Functions ......................... 44
11.1 Sending with the Minimum MTU ........................ 44
11.2 Sending without Fragmentation ....................... 45
11.3 Path MTU Discovery and UDP .......................... 46
11.4 Determining the Current Path MTU .................... 47
12. Ordering of Ancillary Data and IPv6 Extension Headers ..... 48
13. IPv6-Specific Options with IPv4-Mapped IPv6 Addresses ..... 50
14. Extended interfaces for rresvport, rcmd and rexec ......... 51
14.1 rresvport_af ........................................ 51
14.2 rcmd_af ............................................. 51
14.3 rexec_af ............................................ 52
15. Summary of New Definitions ................................ 52
16. Security Considerations ................................... 56
17. Changes from RFC 2292 ..................................... 57
18. References ................................................ 59
19. Acknowledgments ........................................... 59
20. Appendix A: Ancillary Data Overview ....................... 60
20.1 The msghdr Structure ................................ 60
20.2 The cmsghdr Structure ............................... 61
20.3 Ancillary Data Object Macros ........................ 62
20.3.1 CMSG_FIRSTHDR ............................... 63
20.3.2 CMSG_NXTHDR ................................. 64
20.3.3 CMSG_DATA ................................... 65
20.3.4 CMSG_SPACE .................................. 65
20.3.5 CMSG_LEN .................................... 65
21. Appendix B: Examples Using the inet6_rth_XXX() Functions .. 65
21.1 Sending a Routing Header ............................ 65
21.2 Receiving Routing Headers ........................... 70
22. Appendix C: Examples Using the inet6_opt_XXX() Functions .. 72
22.1 Building Options .................................... 72
22.2 Parsing Received Options ............................ 74
23. Authors' Addresses ........................................ 76
24. Full Copyright Statement .................................. 77
A separate specification [RFC-3493] contains changes to the sockets API to support IP version 6. Those changes are for TCP and UDP-based applications. This document defines some of the "advanced" features of the sockets API that are required for applications to take advantage of additional features of IPv6.
单独的规范[RFC-3493]包含对套接字API的更改，以支持IP版本6。这些更改适用于基于TCP和UDP的应用程序。本文档定义了套接字API的一些“高级”功能，应用程序需要这些功能才能利用IPv6的其他功能。
Today, the portability of applications using IPv4 raw sockets is quite high, but this is mainly because most IPv4 implementations started from a common base (the Berkeley source code) or at least started with the Berkeley header files. This allows programs such as Ping and Traceroute, for example, to compile with minimal effort on many hosts that support the sockets API. With IPv6, however, there is no common source code base that implementors are starting from, and the possibility for divergence at this level between different implementations is high. To avoid a complete lack of portability amongst applications that use raw IPv6 sockets, some standardization is necessary.
如今，使用IPv4原始套接字的应用程序的可移植性相当高，但这主要是因为大多数IPv4实现都是从公共基础（Berkeley源代码）开始的，或者至少是从Berkeley头文件开始的。例如，这允许Ping和Traceroute等程序在许多支持socketsapi的主机上以最小的工作量进行编译。然而，在IPv6中，实现者并没有共同的源代码基础，不同实现之间在这一级别上出现差异的可能性很高。为了避免使用原始IPv6套接字的应用程序之间完全缺乏可移植性，需要进行一些标准化。
There are also features from the basic IPv6 specification that are not addressed in [RFC-3493]: sending and receiving Routing headers, Hop-by-Hop options, and Destination options, specifying the outgoing interface, being told of the receiving interface, and control of path MTU information.
[RFC-3493]中还没有涉及到基本IPv6规范中的一些功能：发送和接收路由头、逐跳选项和目标选项、指定传出接口、告知接收接口以及控制路径MTU信息。
This document updates and replaces RFC 2292. This revision is based on implementation experience of RFC 2292, as well as some additional extensions that have been found to be useful through the IPv6 deployment. Note, however, that further work on this document may still be needed. Once the API specification becomes mature and is deployed among implementations, it may be formally standardized by a more appropriate body, such as has been done with the Basic API [RFC-3493].
本文档更新并替换RFC 2292。此修订版基于RFC2292的实施经验，以及一些通过IPv6部署发现有用的附加扩展。但是，请注意，可能仍需要对本文件进行进一步的工作。一旦API规范成熟并在实现之间部署，它可能会由一个更合适的机构进行正式标准化，如基本API[RFC-3493]。
This document can be divided into the following main sections.
本文件可分为以下主要部分。
1. Definitions of the basic constants and structures required for applications to use raw IPv6 sockets. This includes structure definitions for the IPv6 and ICMPv6 headers and all associated constants (e.g., values for the Next Header field).
1. 应用程序使用原始IPv6套接字所需的基本常量和结构的定义。这包括IPv6和ICMPv6标头的结构定义以及所有相关常量（例如，下一个标头字段的值）。
2. Some basic semantic definitions for IPv6 raw sockets. For example, a raw ICMPv4 socket requires the application to calculate and store the ICMPv4 header checksum. But with IPv6 this would require the application to choose the source IPv6 address because the source address is part of the pseudo header that ICMPv6 now uses for its checksum computation. It should be defined that with a raw ICMPv6 socket the kernel always calculates and stores the ICMPv6 header checksum.
2. IPv6原始套接字的一些基本语义定义。例如，原始ICMPv4套接字要求应用程序计算并存储ICMPv4头校验和。但对于IPv6，这将要求应用程序选择源IPv6地址，因为源地址是ICMPv6现在用于校验和计算的伪报头的一部分。应该定义，对于原始ICMPv6套接字，内核始终计算并存储ICMPv6头校验和。
3. Packet information: how applications can obtain the received interface, destination address, and received hop limit, along with specifying these values on a per-packet basis. There are a class of applications that need this capability and the technique should be portable.
3. 数据包信息：应用程序如何获得接收接口、目标地址和接收的跃点限制，以及在每个数据包的基础上指定这些值。有一类应用程序需要这种功能，而且这种技术应该是可移植的。
4. Access to the optional Routing header, Hop-by-Hop options, and Destination options extension headers.
4. 访问可选路由头、逐跳选项和目标选项扩展头。
5. Additional features required for improved IPv6 application portability.
5. 提高IPv6应用程序可移植性所需的其他功能。
The packet information along with access to the extension headers (Routing header, Hop-by-Hop options, and Destination options) are specified using the "ancillary data" fields that were added to the 4.3BSD Reno sockets API in 1990. The reason is that these ancillary data fields are part of the Posix standard [POSIX] and should therefore be adopted by most vendors.
使用1990年添加到4.3BSD Reno sockets API中的“辅助数据”字段指定数据包信息以及对扩展头的访问（路由头、逐跳选项和目的地选项）。原因是这些辅助数据字段是Posix标准[Posix]的一部分，因此应该被大多数供应商采用。
This document does not address application access to either the authentication header or the encapsulating security payload header.
本文档不涉及对身份验证标头或封装安全有效负载标头的应用程序访问。
Many examples in this document omit error checking in favor of brevity and clarity.
为了简洁明了，本文中的许多示例省略了错误检查。
We note that some of the functions and socket options defined in this document may have error returns that are not defined in this document. Some of these possible error returns will be recognized only as implementations proceed.
我们注意到，本文档中定义的某些函数和套接字选项可能具有本文档中未定义的错误返回。其中一些可能的错误返回只有在实现继续进行时才会被识别。
Datatypes in this document follow the Posix format: intN_t means a signed integer of exactly N bits (e.g., int16_t) and uintN_t means an unsigned integer of exactly N bits (e.g., uint32_t).
本文档中的数据类型遵循Posix格式：intN_t表示正好N位的有符号整数（例如int16_t），uintN_t表示正好N位的无符号整数（例如uint32_t）。
Note that we use the (unofficial) terminology ICMPv4, IGMPv4, and ARPv4 to avoid any confusion with the newer ICMPv6 protocol.
请注意，我们使用（非官方）术语ICMPv4、IGMPv4和ARPv4，以避免与较新的ICMPv6协议混淆。
Many advanced applications examine fields in the IPv6 header and set and examine fields in the various ICMPv6 headers. Common structure definitions for these protocol headers are required, along with common constant definitions for the structure members.
许多高级应用程序检查IPv6标头中的字段，并设置和检查各种ICMPv6标头中的字段。需要这些协议头的公共结构定义，以及结构成员的公共常量定义。
This API assumes that the fields in the protocol headers are left in the network byte order, which is big-endian for the Internet protocols. If not, then either these constants or the fields being tested must be converted at run-time, using something like htons() or htonl().
此API假定协议头中的字段按网络字节顺序保留，这是Internet协议的大端。如果不是，则必须在运行时使用诸如htons（）或htonl（）之类的方法转换这些常量或正在测试的字段。
Two new header files are defined: <netinet/ip6.h> and <netinet/icmp6.h>.
定义了两个新的头文件：<netinet/ip6.h>和<netinet/icmp6.h>。
When an include file is specified, that include file is allowed to include other files that do the actual declaration or definition.
指定包含文件时，该包含文件允许包含执行实际声明或定义的其他文件。
The following structure is defined as a result of including <netinet/ip6.h>. Note that this is a new header.
以下结构定义为包含<netinet/ip6.h>的结果。请注意，这是一个新标题。
struct ip6_hdr {
union {
struct ip6_hdrctl {
uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 20 bits
flow-ID */
uint16_t ip6_un1_plen; /* payload length */
uint8_t ip6_un1_nxt; /* next header */
uint8_t ip6_un1_hlim; /* hop limit */
} ip6_un1;
uint8_t ip6_un2_vfc; /* 4 bits version, top 4 bits
tclass */
} ip6_ctlun;
struct in6_addr ip6_src; /* source address */
struct in6_addr ip6_dst; /* destination address */
};
struct ip6_hdr {
union {
struct ip6_hdrctl {
uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 20 bits
flow-ID */
uint16_t ip6_un1_plen; /* payload length */
uint8_t ip6_un1_nxt; /* next header */
uint8_t ip6_un1_hlim; /* hop limit */
} ip6_un1;
uint8_t ip6_un2_vfc; /* 4 bits version, top 4 bits
tclass */
} ip6_ctlun;
struct in6_addr ip6_src; /* source address */
struct in6_addr ip6_dst; /* destination address */
};
#define ip6_vfc ip6_ctlun.ip6_un2_vfc #define ip6_flow ip6_ctlun.ip6_un1.ip6_un1_flow #define ip6_plen ip6_ctlun.ip6_un1.ip6_un1_plen #define ip6_nxt ip6_ctlun.ip6_un1.ip6_un1_nxt #define ip6_hlim ip6_ctlun.ip6_un1.ip6_un1_hlim #define ip6_hops ip6_ctlun.ip6_un1.ip6_un1_hlim
#定义ip6。定义ip6。定义ip6。ip6。定义ip6。定义ip6。定义ip6。定义ip6。定义ip6。定义ip6。定义ip6。定义ip6。定义ip6。定义ip6。定义ip6。定义ip6。vvvvvv6。定义ip6。定义ip6。定义ip6。定义1。ip6（1）全会（1）全会）定义，定义ip6。定义ip6。定义ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6。ip6 ip6_un1.ip6_un1_hlim
IPv6 defines many new values for the Next Header field. The following constants are defined as a result of including <netinet/in.h>.
IPv6为下一个标头字段定义了许多新值。以下常量是由于包含<netinet/in.h>而定义的。
#define IPPROTO_HOPOPTS 0 /* IPv6 Hop-by-Hop options */
#define IPPROTO_IPV6 41 /* IPv6 header */
#define IPPROTO_ROUTING 43 /* IPv6 Routing header */
#define IPPROTO_FRAGMENT 44 /* IPv6 fragment header */
#define IPPROTO_ESP 50 /* encapsulating security payload */
#define IPPROTO_AH 51 /* authentication header */
#define IPPROTO_ICMPV6 58 /* ICMPv6 */
#define IPPROTO_NONE 59 /* IPv6 no next header */
#define IPPROTO_DSTOPTS 60 /* IPv6 Destination options */
#define IPPROTO_HOPOPTS 0 /* IPv6 Hop-by-Hop options */
#define IPPROTO_IPV6 41 /* IPv6 header */
#define IPPROTO_ROUTING 43 /* IPv6 Routing header */
#define IPPROTO_FRAGMENT 44 /* IPv6 fragment header */
#define IPPROTO_ESP 50 /* encapsulating security payload */
#define IPPROTO_AH 51 /* authentication header */
#define IPPROTO_ICMPV6 58 /* ICMPv6 */
#define IPPROTO_NONE 59 /* IPv6 no next header */
#define IPPROTO_DSTOPTS 60 /* IPv6 Destination options */
Berkeley-derived IPv4 implementations also define IPPROTO_IP to be 0. This should not be a problem since IPPROTO_IP is used only with IPv4 sockets and IPPROTO_HOPOPTS only with IPv6 sockets.
Berkeley派生的IPv4实现还将IPPROTO_IP定义为0。这应该不是问题，因为IPPROTO_IP仅用于IPv4套接字，而IPPROTO_hopts仅用于IPv6套接字。
Six extension headers are defined for IPv6. We define structures for all except the Authentication header and Encapsulating Security Payload header, both of which are beyond the scope of this document. The following structures are defined as a result of including <netinet/ip6.h>.
为IPv6定义了六个扩展标头。我们为除身份验证头和封装安全负载头之外的所有头定义了结构，这两个头都超出了本文的范围。以下结构定义为包含<netinet/ip6.h>的结果。
/* Hop-by-Hop options header */
struct ip6_hbh {
uint8_t ip6h_nxt; /* next header */
uint8_t ip6h_len; /* length in units of 8 octets */
/* followed by options */
};
/* Hop-by-Hop options header */
struct ip6_hbh {
uint8_t ip6h_nxt; /* next header */
uint8_t ip6h_len; /* length in units of 8 octets */
/* followed by options */
};
/* Destination options header */
struct ip6_dest {
uint8_t ip6d_nxt; /* next header */
uint8_t ip6d_len; /* length in units of 8 octets */
/* followed by options */
};
/* Destination options header */
struct ip6_dest {
uint8_t ip6d_nxt; /* next header */
uint8_t ip6d_len; /* length in units of 8 octets */
/* followed by options */
};
/* Routing header */
struct ip6_rthdr {
uint8_t ip6r_nxt; /* next header */
uint8_t ip6r_len; /* length in units of 8 octets */
uint8_t ip6r_type; /* routing type */
uint8_t ip6r_segleft; /* segments left */
/* followed by routing type specific data */
};
/* Routing header */
struct ip6_rthdr {
uint8_t ip6r_nxt; /* next header */
uint8_t ip6r_len; /* length in units of 8 octets */
uint8_t ip6r_type; /* routing type */
uint8_t ip6r_segleft; /* segments left */
/* followed by routing type specific data */
};
/* Type 0 Routing header */
struct ip6_rthdr0 {
uint8_t ip6r0_nxt; /* next header */
uint8_t ip6r0_len; /* length in units of 8 octets */
uint8_t ip6r0_type; /* always zero */
uint8_t ip6r0_segleft; /* segments left */
uint32_t ip6r0_reserved; /* reserved field */
/* followed by up to 127 struct in6_addr */
};
/* Type 0 Routing header */
struct ip6_rthdr0 {
uint8_t ip6r0_nxt; /* next header */
uint8_t ip6r0_len; /* length in units of 8 octets */
uint8_t ip6r0_type; /* always zero */
uint8_t ip6r0_segleft; /* segments left */
uint32_t ip6r0_reserved; /* reserved field */
/* followed by up to 127 struct in6_addr */
};
/* Fragment header */
struct ip6_frag {
uint8_t ip6f_nxt; /* next header */
uint8_t ip6f_reserved; /* reserved field */
uint16_t ip6f_offlg; /* offset, reserved, and flag */
uint32_t ip6f_ident; /* identification */
};
/* Fragment header */
struct ip6_frag {
uint8_t ip6f_nxt; /* next header */
uint8_t ip6f_reserved; /* reserved field */
uint16_t ip6f_offlg; /* offset, reserved, and flag */
uint32_t ip6f_ident; /* identification */
};
#if BYTE_ORDER == BIG_ENDIAN
#define IP6F_OFF_MASK 0xfff8 /* mask out offset from
ip6f_offlg */
#define IP6F_RESERVED_MASK 0x0006 /* reserved bits in
ip6f_offlg */
#define IP6F_MORE_FRAG 0x0001 /* more-fragments flag */
#else /* BYTE_ORDER == LITTLE_ENDIAN */
#define IP6F_OFF_MASK 0xf8ff /* mask out offset from
ip6f_offlg */
#define IP6F_RESERVED_MASK 0x0600 /* reserved bits in
ip6f_offlg */
#define IP6F_MORE_FRAG 0x0100 /* more-fragments flag */
#endif
#if BYTE_ORDER == BIG_ENDIAN
#define IP6F_OFF_MASK 0xfff8 /* mask out offset from
ip6f_offlg */
#define IP6F_RESERVED_MASK 0x0006 /* reserved bits in
ip6f_offlg */
#define IP6F_MORE_FRAG 0x0001 /* more-fragments flag */
#else /* BYTE_ORDER == LITTLE_ENDIAN */
#define IP6F_OFF_MASK 0xf8ff /* mask out offset from
ip6f_offlg */
#define IP6F_RESERVED_MASK 0x0600 /* reserved bits in
ip6f_offlg */
#define IP6F_MORE_FRAG 0x0100 /* more-fragments flag */
#endif
Several options are defined for IPv6, and we define structures and macro definitions for some of them below. The following structures are defined as a result of including <netinet/ip6.h>.
IPv6定义了几个选项，下面我们为其中一些定义了结构和宏定义。以下结构定义为包含<netinet/ip6.h>的结果。
/* IPv6 options */
struct ip6_opt {
uint8_t ip6o_type;
uint8_t ip6o_len;
};
/* IPv6 options */
struct ip6_opt {
uint8_t ip6o_type;
uint8_t ip6o_len;
};
/*
* The high-order 3 bits of the option type define the behavior
* when processing an unknown option and whether or not the option
* content changes in flight.
*/
#define IP6OPT_TYPE(o) ((o) & 0xc0)
#define IP6OPT_TYPE_SKIP 0x00
#define IP6OPT_TYPE_DISCARD 0x40
#define IP6OPT_TYPE_FORCEICMP 0x80
#define IP6OPT_TYPE_ICMP 0xc0
#define IP6OPT_MUTABLE 0x20
/*
* The high-order 3 bits of the option type define the behavior
* when processing an unknown option and whether or not the option
* content changes in flight.
*/
#define IP6OPT_TYPE(o) ((o) & 0xc0)
#define IP6OPT_TYPE_SKIP 0x00
#define IP6OPT_TYPE_DISCARD 0x40
#define IP6OPT_TYPE_FORCEICMP 0x80
#define IP6OPT_TYPE_ICMP 0xc0
#define IP6OPT_MUTABLE 0x20
#define IP6OPT_PAD1 0x00 /* 00 0 00000 */
#define IP6OPT_PADN 0x01 /* 00 0 00001 */
#define IP6OPT_PAD1 0x00 /* 00 0 00000 */
#define IP6OPT_PADN 0x01 /* 00 0 00001 */
#define IP6OPT_JUMBO 0xc2 /* 11 0 00010 */
#define IP6OPT_NSAP_ADDR 0xc3 /* 11 0 00011 */
#define IP6OPT_TUNNEL_LIMIT 0x04 /* 00 0 00100 */
#define IP6OPT_ROUTER_ALERT 0x05 /* 00 0 00101 */
#define IP6OPT_JUMBO 0xc2 /* 11 0 00010 */
#define IP6OPT_NSAP_ADDR 0xc3 /* 11 0 00011 */
#define IP6OPT_TUNNEL_LIMIT 0x04 /* 00 0 00100 */
#define IP6OPT_ROUTER_ALERT 0x05 /* 00 0 00101 */
/* Jumbo Payload Option */
struct ip6_opt_jumbo {
uint8_t ip6oj_type;
uint8_t ip6oj_len;
uint8_t ip6oj_jumbo_len[4];
};
#define IP6OPT_JUMBO_LEN 6
/* Jumbo Payload Option */
struct ip6_opt_jumbo {
uint8_t ip6oj_type;
uint8_t ip6oj_len;
uint8_t ip6oj_jumbo_len[4];
};
#define IP6OPT_JUMBO_LEN 6
/* NSAP Address Option */
struct ip6_opt_nsap {
uint8_t ip6on_type;
uint8_t ip6on_len;
uint8_t ip6on_src_nsap_len;
uint8_t ip6on_dst_nsap_len;
/* followed by source NSAP */
/* followed by destination NSAP */
};
/* NSAP Address Option */
struct ip6_opt_nsap {
uint8_t ip6on_type;
uint8_t ip6on_len;
uint8_t ip6on_src_nsap_len;
uint8_t ip6on_dst_nsap_len;
/* followed by source NSAP */
/* followed by destination NSAP */
};
/* Tunnel Limit Option */
struct ip6_opt_tunnel {
uint8_t ip6ot_type;
uint8_t ip6ot_len;
uint8_t ip6ot_encap_limit;
};
/* Tunnel Limit Option */
struct ip6_opt_tunnel {
uint8_t ip6ot_type;
uint8_t ip6ot_len;
uint8_t ip6ot_encap_limit;
};
/* Router Alert Option */
struct ip6_opt_router {
uint8_t ip6or_type;
uint8_t ip6or_len;
uint8_t ip6or_value[2];
};
/* Router Alert Option */
struct ip6_opt_router {
uint8_t ip6or_type;
uint8_t ip6or_len;
uint8_t ip6or_value[2];
};
/* Router alert values (in network byte order) */
#ifdef _BIG_ENDIAN
#define IP6_ALERT_MLD 0x0000
#define IP6_ALERT_RSVP 0x0001
#define IP6_ALERT_AN 0x0002
#else
#define IP6_ALERT_MLD 0x0000
#define IP6_ALERT_RSVP 0x0100
#define IP6_ALERT_AN 0x0200
#endif
/* Router alert values (in network byte order) */
#ifdef _BIG_ENDIAN
#define IP6_ALERT_MLD 0x0000
#define IP6_ALERT_RSVP 0x0001
#define IP6_ALERT_AN 0x0002
#else
#define IP6_ALERT_MLD 0x0000
#define IP6_ALERT_RSVP 0x0100
#define IP6_ALERT_AN 0x0200
#endif
The ICMPv6 header is needed by numerous IPv6 applications including Ping, Traceroute, router discovery daemons, and neighbor discovery daemons. The following structure is defined as a result of including <netinet/icmp6.h>. Note that this is a new header.
许多IPv6应用程序（包括Ping、Traceroute、路由器发现守护程序和邻居发现守护程序）都需要ICMPv6报头。以下结构定义为包含<netinet/icmp6.h>的结果。请注意，这是一个新标题。
struct icmp6_hdr {
uint8_t icmp6_type; /* type field */
uint8_t icmp6_code; /* code field */
uint16_t icmp6_cksum; /* checksum field */
union {
uint32_t icmp6_un_data32[1]; /* type-specific field */
uint16_t icmp6_un_data16[2]; /* type-specific field */
uint8_t icmp6_un_data8[4]; /* type-specific field */
} icmp6_dataun;
};
struct icmp6_hdr {
uint8_t icmp6_type; /* type field */
uint8_t icmp6_code; /* code field */
uint16_t icmp6_cksum; /* checksum field */
union {
uint32_t icmp6_un_data32[1]; /* type-specific field */
uint16_t icmp6_un_data16[2]; /* type-specific field */
uint8_t icmp6_un_data8[4]; /* type-specific field */
} icmp6_dataun;
};
#define icmp6_data32 icmp6_dataun.icmp6_un_data32
#define icmp6_data16 icmp6_dataun.icmp6_un_data16
#define icmp6_data8 icmp6_dataun.icmp6_un_data8
#define icmp6_pptr icmp6_data32[0] /* parameter prob */
#define icmp6_mtu icmp6_data32[0] /* packet too big */
#define icmp6_id icmp6_data16[0] /* echo request/reply */
#define icmp6_seq icmp6_data16[1] /* echo request/reply */
#define icmp6_maxdelay icmp6_data16[0] /* mcast group
membership */
#define icmp6_data32 icmp6_dataun.icmp6_un_data32
#define icmp6_data16 icmp6_dataun.icmp6_un_data16
#define icmp6_data8 icmp6_dataun.icmp6_un_data8
#define icmp6_pptr icmp6_data32[0] /* parameter prob */
#define icmp6_mtu icmp6_data32[0] /* packet too big */
#define icmp6_id icmp6_data16[0] /* echo request/reply */
#define icmp6_seq icmp6_data16[1] /* echo request/reply */
#define icmp6_maxdelay icmp6_data16[0] /* mcast group
membership */
In addition to a common structure for the ICMPv6 header, common definitions are required for the ICMPv6 type and code fields. The following constants are also defined as a result of including <netinet/icmp6.h>.
除了ICMPv6头的通用结构外，ICMPv6类型和代码字段还需要通用定义。以下常量也是由于包含<netinet/icmp6.h>而定义的。
#define ICMP6_DST_UNREACH 1 #define ICMP6_PACKET_TOO_BIG 2 #define ICMP6_TIME_EXCEEDED 3 #define ICMP6_PARAM_PROB 4
#定义ICMP6未读1定义ICMP6数据包太大2定义ICMP6时间超过3定义ICMP6参数问题4
#define ICMP6_INFOMSG_MASK 0x80 /* all informational
messages */
#define ICMP6_INFOMSG_MASK 0x80 /* all informational
messages */
#define ICMP6_ECHO_REQUEST 128 #define ICMP6_ECHO_REPLY 129
#定义ICMP6_ECHO_请求128#定义ICMP6_ECHO_回复129
#define ICMP6_DST_UNREACH_NOROUTE 0 /* no route to
destination */
#define ICMP6_DST_UNREACH_NOROUTE 0 /* no route to
destination */
#define ICMP6_DST_UNREACH_ADMIN 1 /* communication with
destination */
/* admin. prohibited */
#define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source
address */
#define ICMP6_DST_UNREACH_ADDR 3 /* address unreachable */
#define ICMP6_DST_UNREACH_NOPORT 4 /* bad port */
#define ICMP6_DST_UNREACH_ADMIN 1 /* communication with
destination */
/* admin. prohibited */
#define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source
address */
#define ICMP6_DST_UNREACH_ADDR 3 /* address unreachable */
#define ICMP6_DST_UNREACH_NOPORT 4 /* bad port */
#define ICMP6_TIME_EXCEED_TRANSIT 0 /* Hop Limit == 0 in
transit */
#define ICMP6_TIME_EXCEED_REASSEMBLY 1 /* Reassembly time out */
#define ICMP6_TIME_EXCEED_TRANSIT 0 /* Hop Limit == 0 in
transit */
#define ICMP6_TIME_EXCEED_REASSEMBLY 1 /* Reassembly time out */
#define ICMP6_PARAMPROB_HEADER 0 /* erroneous header
field */
#define ICMP6_PARAMPROB_NEXTHEADER 1 /* unrecognized
Next Header */
#define ICMP6_PARAMPROB_OPTION 2 /* unrecognized
IPv6 option */
#define ICMP6_PARAMPROB_HEADER 0 /* erroneous header
field */
#define ICMP6_PARAMPROB_NEXTHEADER 1 /* unrecognized
Next Header */
#define ICMP6_PARAMPROB_OPTION 2 /* unrecognized
IPv6 option */
The five ICMP message types defined by IPv6 neighbor discovery (133- 137) are defined in the next section.
IPv6邻居发现（133-137）定义的五种ICMP消息类型将在下一节中定义。
The following structures and definitions are defined as a result of including <netinet/icmp6.h>.
以下结构和定义是包含<netinet/icmp6.h>的结果。
#define ND_ROUTER_SOLICIT 133 #define ND_ROUTER_ADVERT 134 #define ND_NEIGHBOR_SOLICIT 135 #define ND_NEIGHBOR_ADVERT 136 #define ND_REDIRECT 137
#定义NDU路由器请求133#定义NDU路由器请求134#定义NDU邻居请求135#定义NDU邻居请求136#定义NDU重定向137
struct nd_router_solicit { /* router solicitation */
struct icmp6_hdr nd_rs_hdr;
/* could be followed by options */
};
struct nd_router_solicit { /* router solicitation */
struct icmp6_hdr nd_rs_hdr;
/* could be followed by options */
};
#define nd_rs_type nd_rs_hdr.icmp6_type #define nd_rs_code nd_rs_hdr.icmp6_code #define nd_rs_cksum nd_rs_hdr.icmp6_cksum #define nd_rs_reserved nd_rs_hdr.icmp6_data32[0]
#定义nd_rs_类型nd_rs_hdr.icmp6_类型#定义nd_rs_hdr.icmp6_代码#定义nd_rs_校验和nd_rs_hdr.icmp6#定义nd_rs_保留nd_rs_hdr.icmp6#数据32[0]
struct nd_router_advert { /* router advertisement */
struct icmp6_hdr nd_ra_hdr;
uint32_t nd_ra_reachable; /* reachable time */
uint32_t nd_ra_retransmit; /* retransmit timer */
/* could be followed by options */
};
struct nd_router_advert { /* router advertisement */
struct icmp6_hdr nd_ra_hdr;
uint32_t nd_ra_reachable; /* reachable time */
uint32_t nd_ra_retransmit; /* retransmit timer */
/* could be followed by options */
};
#define nd_ra_type nd_ra_hdr.icmp6_type
#define nd_ra_code nd_ra_hdr.icmp6_code
#define nd_ra_cksum nd_ra_hdr.icmp6_cksum
#define nd_ra_curhoplimit nd_ra_hdr.icmp6_data8[0]
#define nd_ra_flags_reserved nd_ra_hdr.icmp6_data8[1]
#define ND_RA_FLAG_MANAGED 0x80
#define ND_RA_FLAG_OTHER 0x40
#define nd_ra_router_lifetime nd_ra_hdr.icmp6_data16[1]
#define nd_ra_type nd_ra_hdr.icmp6_type
#define nd_ra_code nd_ra_hdr.icmp6_code
#define nd_ra_cksum nd_ra_hdr.icmp6_cksum
#define nd_ra_curhoplimit nd_ra_hdr.icmp6_data8[0]
#define nd_ra_flags_reserved nd_ra_hdr.icmp6_data8[1]
#define ND_RA_FLAG_MANAGED 0x80
#define ND_RA_FLAG_OTHER 0x40
#define nd_ra_router_lifetime nd_ra_hdr.icmp6_data16[1]
struct nd_neighbor_solicit { /* neighbor solicitation */
struct icmp6_hdr nd_ns_hdr;
struct in6_addr nd_ns_target; /* target address */
/* could be followed by options */
};
struct nd_neighbor_solicit { /* neighbor solicitation */
struct icmp6_hdr nd_ns_hdr;
struct in6_addr nd_ns_target; /* target address */
/* could be followed by options */
};
#define nd_ns_type nd_ns_hdr.icmp6_type #define nd_ns_code nd_ns_hdr.icmp6_code #define nd_ns_cksum nd_ns_hdr.icmp6_cksum #define nd_ns_reserved nd_ns_hdr.icmp6_data32[0]
#定义nd_ns_类型nd_ns_hdr.icmp6_类型#定义nd_ns_hdr.icmp6_代码#定义nd_ns_校验和nd_ns_hdr.icmp6_校验和#定义nd_ns_保留的nd_ns_hdr.icmp6_数据32[0]
struct nd_neighbor_advert { /* neighbor advertisement */
struct icmp6_hdr nd_na_hdr;
struct in6_addr nd_na_target; /* target address */
/* could be followed by options */
};
struct nd_neighbor_advert { /* neighbor advertisement */
struct icmp6_hdr nd_na_hdr;
struct in6_addr nd_na_target; /* target address */
/* could be followed by options */
};
#define nd_na_type nd_na_hdr.icmp6_type
#define nd_na_code nd_na_hdr.icmp6_code
#define nd_na_cksum nd_na_hdr.icmp6_cksum
#define nd_na_flags_reserved nd_na_hdr.icmp6_data32[0]
#if BYTE_ORDER == BIG_ENDIAN
#define ND_NA_FLAG_ROUTER 0x80000000
#define ND_NA_FLAG_SOLICITED 0x40000000
#define ND_NA_FLAG_OVERRIDE 0x20000000
#else /* BYTE_ORDER == LITTLE_ENDIAN */
#define ND_NA_FLAG_ROUTER 0x00000080
#define ND_NA_FLAG_SOLICITED 0x00000040
#define ND_NA_FLAG_OVERRIDE 0x00000020
#endif
#define nd_na_type nd_na_hdr.icmp6_type
#define nd_na_code nd_na_hdr.icmp6_code
#define nd_na_cksum nd_na_hdr.icmp6_cksum
#define nd_na_flags_reserved nd_na_hdr.icmp6_data32[0]
#if BYTE_ORDER == BIG_ENDIAN
#define ND_NA_FLAG_ROUTER 0x80000000
#define ND_NA_FLAG_SOLICITED 0x40000000
#define ND_NA_FLAG_OVERRIDE 0x20000000
#else /* BYTE_ORDER == LITTLE_ENDIAN */
#define ND_NA_FLAG_ROUTER 0x00000080
#define ND_NA_FLAG_SOLICITED 0x00000040
#define ND_NA_FLAG_OVERRIDE 0x00000020
#endif
struct nd_redirect { /* redirect */
struct icmp6_hdr nd_rd_hdr;
struct in6_addr nd_rd_target; /* target address */
struct in6_addr nd_rd_dst; /* destination address */
/* could be followed by options */
};
struct nd_redirect { /* redirect */
struct icmp6_hdr nd_rd_hdr;
struct in6_addr nd_rd_target; /* target address */
struct in6_addr nd_rd_dst; /* destination address */
/* could be followed by options */
};
#define nd_rd_type nd_rd_hdr.icmp6_type #define nd_rd_code nd_rd_hdr.icmp6_code #define nd_rd_cksum nd_rd_hdr.icmp6_cksum #define nd_rd_reserved nd_rd_hdr.icmp6_data32[0]
#定义nd#rd#U类型nd#rd#U hdr.icmp6#U类型#定义nd#rd#U代码nd#U hdr.icmp6#定义nd#rd#U保留nd#rd#U hdr.icmp6#U数据32[0]
struct nd_opt_hdr { /* Neighbor discovery option header */
uint8_t nd_opt_type;
uint8_t nd_opt_len; /* in units of 8 octets */
/* followed by option specific data */
};
struct nd_opt_hdr { /* Neighbor discovery option header */
uint8_t nd_opt_type;
uint8_t nd_opt_len; /* in units of 8 octets */
/* followed by option specific data */
};
#define ND_OPT_SOURCE_LINKADDR 1 #define ND_OPT_TARGET_LINKADDR 2 #define ND_OPT_PREFIX_INFORMATION 3 #define ND_OPT_REDIRECTED_HEADER 4 #define ND_OPT_MTU 5
#定义ND选项源链接地址1#定义ND选项目标链接地址2#定义ND选项前缀信息3#定义ND选项重定向标题4#定义ND选项MTU 5
struct nd_opt_prefix_info { /* prefix information */
uint8_t nd_opt_pi_type;
uint8_t nd_opt_pi_len;
uint8_t nd_opt_pi_prefix_len;
uint8_t nd_opt_pi_flags_reserved;
uint32_t nd_opt_pi_valid_time;
uint32_t nd_opt_pi_preferred_time;
uint32_t nd_opt_pi_reserved2;
struct in6_addr nd_opt_pi_prefix;
};
struct nd_opt_prefix_info { /* prefix information */
uint8_t nd_opt_pi_type;
uint8_t nd_opt_pi_len;
uint8_t nd_opt_pi_prefix_len;
uint8_t nd_opt_pi_flags_reserved;
uint32_t nd_opt_pi_valid_time;
uint32_t nd_opt_pi_preferred_time;
uint32_t nd_opt_pi_reserved2;
struct in6_addr nd_opt_pi_prefix;
};
#define ND_OPT_PI_FLAG_ONLINK 0x80 #define ND_OPT_PI_FLAG_AUTO 0x40
#定义ND_OPT_PI_FLAG_ONLINK 0x80#定义ND_OPT_PI_FLAG_AUTO 0x40
struct nd_opt_rd_hdr { /* redirected header */
uint8_t nd_opt_rh_type;
uint8_t nd_opt_rh_len;
uint16_t nd_opt_rh_reserved1;
uint32_t nd_opt_rh_reserved2;
/* followed by IP header and data */
};
struct nd_opt_rd_hdr { /* redirected header */
uint8_t nd_opt_rh_type;
uint8_t nd_opt_rh_len;
uint16_t nd_opt_rh_reserved1;
uint32_t nd_opt_rh_reserved2;
/* followed by IP header and data */
};
struct nd_opt_mtu { /* MTU option */
uint8_t nd_opt_mtu_type;
uint8_t nd_opt_mtu_len;
uint16_t nd_opt_mtu_reserved;
uint32_t nd_opt_mtu_mtu;
};
struct nd_opt_mtu { /* MTU option */
uint8_t nd_opt_mtu_type;
uint8_t nd_opt_mtu_len;
uint16_t nd_opt_mtu_reserved;
uint32_t nd_opt_mtu_mtu;
};
We note that the nd_na_flags_reserved flags have the same byte ordering problems as we showed with ip6f_offlg.
我们注意到，nd_na_标志(reserved flags)与我们在ip6f_offlg中显示的字节排序问题相同。
The following structures and definitions are defined as a result of including <netinet/icmp6.h>.
以下结构和定义是包含<netinet/icmp6.h>的结果。
#define MLD_LISTENER_QUERY 130 #define MLD_LISTENER_REPORT 131 #define MLD_LISTENER_REDUCTION 132
#定义MLD_侦听器_查询130#定义MLD_侦听器_报告131#定义MLD_侦听器_缩减132
struct mld_hdr {
struct icmp6_hdr mld_icmp6_hdr;
struct in6_addr mld_addr; /* multicast address */
};
#define mld_type mld_icmp6_hdr.icmp6_type
#define mld_code mld_icmp6_hdr.icmp6_code
#define mld_cksum mld_icmp6_hdr.icmp6_cksum
#define mld_maxdelay mld_icmp6_hdr.icmp6_data16[0]
#define mld_reserved mld_icmp6_hdr.icmp6_data16[1]
struct mld_hdr {
struct icmp6_hdr mld_icmp6_hdr;
struct in6_addr mld_addr; /* multicast address */
};
#define mld_type mld_icmp6_hdr.icmp6_type
#define mld_code mld_icmp6_hdr.icmp6_code
#define mld_cksum mld_icmp6_hdr.icmp6_cksum
#define mld_maxdelay mld_icmp6_hdr.icmp6_data16[0]
#define mld_reserved mld_icmp6_hdr.icmp6_data16[1]
The following structures and definitions are defined as a result of including <netinet/icmp6.h>.
以下结构和定义是包含<netinet/icmp6.h>的结果。
#define ICMP6_ROUTER_RENUMBERING 138 /* router renumbering */
#define ICMP6_ROUTER_RENUMBERING 138 /* router renumbering */
struct icmp6_router_renum { /* router renumbering header */
struct icmp6_hdr rr_hdr;
uint8_t rr_segnum;
uint8_t rr_flags;
uint16_t rr_maxdelay;
uint32_t rr_reserved;
};
#define rr_type rr_hdr.icmp6_type
#define rr_code rr_hdr.icmp6_code
#define rr_cksum rr_hdr.icmp6_cksum
#define rr_seqnum rr_hdr.icmp6_data32[0]
struct icmp6_router_renum { /* router renumbering header */
struct icmp6_hdr rr_hdr;
uint8_t rr_segnum;
uint8_t rr_flags;
uint16_t rr_maxdelay;
uint32_t rr_reserved;
};
#define rr_type rr_hdr.icmp6_type
#define rr_code rr_hdr.icmp6_code
#define rr_cksum rr_hdr.icmp6_cksum
#define rr_seqnum rr_hdr.icmp6_data32[0]
/* Router renumbering flags */
#define ICMP6_RR_FLAGS_TEST 0x80
#define ICMP6_RR_FLAGS_REQRESULT 0x40
#define ICMP6_RR_FLAGS_FORCEAPPLY 0x20
#define ICMP6_RR_FLAGS_SPECSITE 0x10
#define ICMP6_RR_FLAGS_PREVDONE 0x08
/* Router renumbering flags */
#define ICMP6_RR_FLAGS_TEST 0x80
#define ICMP6_RR_FLAGS_REQRESULT 0x40
#define ICMP6_RR_FLAGS_FORCEAPPLY 0x20
#define ICMP6_RR_FLAGS_SPECSITE 0x10
#define ICMP6_RR_FLAGS_PREVDONE 0x08
struct rr_pco_match { /* match prefix part */
uint8_t rpm_code;
uint8_t rpm_len;
uint8_t rpm_ordinal;
uint8_t rpm_matchlen;
uint8_t rpm_minlen;
uint8_t rpm_maxlen;
uint16_t rpm_reserved;
struct in6_addr rpm_prefix;
};
struct rr_pco_match { /* match prefix part */
uint8_t rpm_code;
uint8_t rpm_len;
uint8_t rpm_ordinal;
uint8_t rpm_matchlen;
uint8_t rpm_minlen;
uint8_t rpm_maxlen;
uint16_t rpm_reserved;
struct in6_addr rpm_prefix;
};
/* PCO code values */
#define RPM_PCO_ADD 1
#define RPM_PCO_CHANGE 2
#define RPM_PCO_SETGLOBAL 3
/* PCO code values */
#define RPM_PCO_ADD 1
#define RPM_PCO_CHANGE 2
#define RPM_PCO_SETGLOBAL 3
struct rr_pco_use { /* use prefix part */
uint8_t rpu_uselen;
uint8_t rpu_keeplen;
uint8_t rpu_ramask;
uint8_t rpu_raflags;
uint32_t rpu_vltime;
uint32_t rpu_pltime;
uint32_t rpu_flags;
struct in6_addr rpu_prefix;
};
#define ICMP6_RR_PCOUSE_RAFLAGS_ONLINK 0x20
#define ICMP6_RR_PCOUSE_RAFLAGS_AUTO 0x10
struct rr_pco_use { /* use prefix part */
uint8_t rpu_uselen;
uint8_t rpu_keeplen;
uint8_t rpu_ramask;
uint8_t rpu_raflags;
uint32_t rpu_vltime;
uint32_t rpu_pltime;
uint32_t rpu_flags;
struct in6_addr rpu_prefix;
};
#define ICMP6_RR_PCOUSE_RAFLAGS_ONLINK 0x20
#define ICMP6_RR_PCOUSE_RAFLAGS_AUTO 0x10
#if BYTE_ORDER == BIG_ENDIAN
#define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80000000
#define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40000000
#elif BYTE_ORDER == LITTLE_ENDIAN
#define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80
#define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40
#endif
#if BYTE_ORDER == BIG_ENDIAN
#define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80000000
#define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40000000
#elif BYTE_ORDER == LITTLE_ENDIAN
#define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80
#define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40
#endif
struct rr_result { /* router renumbering result message */
uint16_t rrr_flags;
uint8_t rrr_ordinal;
uint8_t rrr_matchedlen;
uint32_t rrr_ifid;
struct in6_addr rrr_prefix;
};
struct rr_result { /* router renumbering result message */
uint16_t rrr_flags;
uint8_t rrr_ordinal;
uint8_t rrr_matchedlen;
uint32_t rrr_ifid;
struct in6_addr rrr_prefix;
};
#if BYTE_ORDER == BIG_ENDIAN
#define ICMP6_RR_RESULT_FLAGS_OOB 0x0002
#define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0001
#elif BYTE_ORDER == LITTLE_ENDIAN
#define ICMP6_RR_RESULT_FLAGS_OOB 0x0200
#define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0100
#endif
#if BYTE_ORDER == BIG_ENDIAN
#define ICMP6_RR_RESULT_FLAGS_OOB 0x0002
#define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0001
#elif BYTE_ORDER == LITTLE_ENDIAN
#define ICMP6_RR_RESULT_FLAGS_OOB 0x0200
#define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0100
#endif
The basic API ([RFC-3493]) defines some macros for testing an IPv6 address for certain properties. This API extends those definitions with additional address testing macros, defined as a result of including <netinet/in.h>.
基本API（[RFC-3493]）定义了一些宏，用于测试IPv6地址的某些属性。此API使用附加的地址测试宏扩展了这些定义，这些宏是由于包含<netinet/in.h>而定义的。
int IN6_ARE_ADDR_EQUAL(const struct in6_addr *,
const struct in6_addr *);
int IN6_ARE_ADDR_EQUAL(const struct in6_addr *,
const struct in6_addr *);
This macro returns non-zero if the addresses are equal; otherwise it returns zero.
如果地址相等，此宏返回非零；否则返回零。
Many hosts provide the file /etc/protocols that contains the names of the various IP protocols and their protocol number (e.g., the value of the protocol field in the IPv4 header for that protocol, such as 1 for ICMP). Some programs then call the function getprotobyname() to obtain the protocol value that is then specified as the third argument to the socket() function. For example, the Ping program contains code of the form
许多主机提供文件/etc/协议，其中包含各种IP协议的名称及其协议号（例如，该协议的IPv4报头中的协议字段值，如ICMP的1）。然后，一些程序调用函数getprotobyname（）以获取协议值，该值随后被指定为socket（）函数的第三个参数。例如，Ping程序包含表单的代码
struct protoent *proto;
结构-原型*proto；
proto = getprotobyname("icmp");
proto = getprotobyname("icmp");
s = socket(AF_INET, SOCK_RAW, proto->p_proto);
s = socket(AF_INET, SOCK_RAW, proto->p_proto);
Common names are required for the new IPv6 protocols in this file, to provide portability of applications that call the getprotoXXX() functions.
此文件中的新IPv6协议需要通用名称，以提供调用getprotoXXX（）函数的应用程序的可移植性。
We define the following protocol names with the values shown. These are taken under http://www.iana.org/numbers.html.
我们使用显示的值定义以下协议名称。这些都是根据http://www.iana.org/numbers.html.
hopopt 0 # hop-by-hop options for ipv6 ipv6 41 # ipv6 ipv6-route 43 # routing header for ipv6 ipv6-frag 44 # fragment header for ipv6 esp 50 # encapsulating security payload for ipv6 ah 51 # authentication header for ipv6 ipv6-icmp 58 # icmp for ipv6 ipv6-nonxt 59 # no next header for ipv6 ipv6-opts 60 # destination options for ipv6
hopopt 0#ipv6的逐跳选项41#ipv6的路由43#ipv6的路由头frag 44#ipv6的片段头esp 50#ipv6的封装安全负载ah 51#ipv6的身份验证头icmp 58#ipv6的icmp非文本59#ipv6的无下一个头选项60#ipv6的目标选项
Raw sockets bypass the transport layer (TCP or UDP). With IPv4, raw sockets are used to access ICMPv4, IGMPv4, and to read and write IPv4 datagrams containing a protocol field that the kernel does not process. An example of the latter is a routing daemon for OSPF, since it uses IPv4 protocol field 89. With IPv6 raw sockets will be used for ICMPv6 and to read and write IPv6 datagrams containing a Next Header field that the kernel does not process. Examples of the latter are a routing daemon for OSPF for IPv6 and RSVP (protocol field 46).
原始套接字绕过传输层（TCP或UDP）。对于IPv4，原始套接字用于访问ICMPv4、IGMPv4，以及读写包含内核不处理的协议字段的IPv4数据报。后者的一个例子是OSPF的路由守护进程，因为它使用IPv4协议字段89。对于IPv6，原始套接字将用于ICMPv6，并用于读写包含内核不处理的下一个标头字段的IPv6数据报。后者的示例是用于IPv6和RSVP的OSPF路由守护进程（协议字段46）。
All data sent via raw sockets must be in network byte order and all data received via raw sockets will be in network byte order. This differs from the IPv4 raw sockets, which did not specify a byte ordering and used the host's byte order for certain IP header fields.
通过原始套接字发送的所有数据必须按网络字节顺序，通过原始套接字接收的所有数据将按网络字节顺序。这与IPv4原始套接字不同，后者未指定字节顺序，并对某些IP头字段使用主机的字节顺序。
Another difference from IPv4 raw sockets is that complete packets (that is, IPv6 packets with extension headers) cannot be sent or received using the IPv6 raw sockets API. Instead, ancillary data objects are used to transfer the extension headers and hoplimit information, as described in Section 6. Should an application need access to the complete IPv6 packet, some other technique, such as the datalink interfaces BPF or DLPI, must be used.
与IPv4原始套接字的另一个区别是，不能使用IPv6原始套接字API发送或接收完整的数据包（即具有扩展头的IPv6数据包）。相反，辅助数据对象用于传输扩展头和hoplimit信息，如第6节所述。如果应用程序需要访问完整的IPv6数据包，则必须使用其他一些技术，例如数据链路接口BPF或DLPI。
All fields except the flow label in the IPv6 header that an application might want to change (i.e., everything other than the version number) can be modified using ancillary data and/or socket options by the application for output. All fields except the flow label in a received IPv6 header (other than the version number and Next Header fields) and all extension headers that an application might want to know are also made available to the application as ancillary data on input. Hence there is no need for a socket option
应用程序可以使用辅助数据和/或套接字选项修改除IPv6标头中应用程序可能要更改的流标签以外的所有字段（即版本号以外的所有内容），以进行输出。除了接收到的IPv6标头中的流标签（版本号和下一个标头字段除外）以及应用程序可能希望知道的所有扩展标头之外，所有字段都作为输入上的辅助数据提供给应用程序。因此，不需要套接字选项
similar to the IPv4 IP_HDRINCL socket option and on receipt the application will only receive the payload i.e., the data after the IPv6 header and all the extension headers.
与IPv4 IP_HDRINCL套接字选项类似，收到时，应用程序将只接收有效负载，即IPv6头和所有扩展头之后的数据。
This API does not define access to the flow label field, because today there is no standard usage of the field.
此API未定义对flow label字段的访问，因为目前没有该字段的标准用法。
When writing to a raw socket the kernel will automatically fragment the packet if its size exceeds the path MTU, inserting the required fragment headers. On input the kernel reassembles received fragments, so the reader of a raw socket never sees any fragment headers.
当写入原始套接字时，如果数据包的大小超过路径MTU，内核将自动对数据包进行分段，插入所需的分段头。在输入时，内核重新组装接收到的片段，因此原始套接字的读取器永远不会看到任何片段头。
When we say "an ICMPv6 raw socket" we mean a socket created by calling the socket function with the three arguments AF_INET6, SOCK_RAW, and IPPROTO_ICMPV6.
当我们说“一个ICMPv6原始套接字”时，我们指的是通过调用socket函数来创建的套接字，该函数有三个参数AF_INET6、SOCK_raw和IPPROTO_ICMPv6。
Most IPv4 implementations give special treatment to a raw socket created with a third argument to socket() of IPPROTO_RAW, whose value is normally 255, to have it mean that the application will send down complete packets including the IPv4 header. (Note: This feature was added to IPv4 in 1988 by Van Jacobson to support traceroute, allowing a complete IP header to be passed by the application, before the IP_HDRINCL socket option was added.) We note that IPPROTO_RAW has no special meaning to an IPv6 raw socket (and the IANA currently reserves the value of 255 when used as a next-header field).
大多数IPv4实现对使用IPPROTO_raw的socket（）的第三个参数创建的原始套接字进行了特殊处理，该参数的值通常为255，这意味着应用程序将发送包括IPv4标头在内的完整数据包。（注意：Van Jacobson于1988年将此功能添加到IPv4中，以支持跟踪路由，允许应用程序在添加IP_HDRINCL套接字选项之前传递完整的IP头。）我们注意到IPPROTO_RAW对IPv6 RAW套接字没有特殊意义（当用作下一个头字段时，IANA当前保留255的值）.
The kernel will calculate and insert the ICMPv6 checksum for ICMPv6 raw sockets, since this checksum is mandatory.
内核将计算并插入ICMPv6原始套接字的ICMPv6校验和，因为该校验和是必需的。
For other raw IPv6 sockets (that is, for raw IPv6 sockets created with a third argument other than IPPROTO_ICMPV6), the application must set the new IPV6_CHECKSUM socket option to have the kernel (1) compute and store a checksum for output, and (2) verify the received checksum on input, discarding the packet if the checksum is in error. This option prevents applications from having to perform source address selection on the packets they send. The checksum will incorporate the IPv6 pseudo-header, defined in Section 8.1 of [RFC-2460]. This new socket option also specifies an integer offset into the user data of where the checksum is located.
对于其他原始IPv6套接字（即，对于使用IPPROTO_ICMPV6以外的第三个参数创建的原始IPv6套接字），应用程序必须设置新的IPv6_校验和套接字选项，以使内核（1）计算并存储输出校验和，（2）在输入时验证收到的校验和，如果校验和出错，则丢弃数据包。此选项防止应用程序必须对其发送的数据包执行源地址选择。校验和将包含[RFC-2460]第8.1节中定义的IPv6伪报头。这个新的套接字选项还指定校验和所在的用户数据的整数偏移量。
int offset = 2;
setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset,
sizeof(offset));
int offset = 2;
setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset,
sizeof(offset));
By default, this socket option is disabled. Setting the offset to -1 also disables the option. By disabled we mean (1) the kernel will not calculate and store a checksum for outgoing packets, and (2) the kernel will not verify a checksum for received packets.
默认情况下，此套接字选项处于禁用状态。将偏移设置为-1也会禁用该选项。所谓禁用，我们的意思是（1）内核不会计算和存储传出数据包的校验和，（2）内核不会验证接收到的数据包的校验和。
This option assumes the use of the 16-bit one's complement of the one's complement sum as the checksum algorithm and that the checksum field is aligned on a 16-bit boundary. Thus, specifying a positive odd value as offset is invalid, and setsockopt() will fail for such offset values.
此选项假定使用16位1的补码和中的16位1的补码作为校验和算法，并且校验和字段在16位边界上对齐。因此，将正奇数值指定为偏移量是无效的，对于此类偏移量值，setsockopt（）将失败。
An attempt to set IPV6_CHECKSUM for an ICMPv6 socket will fail. Also, an attempt to set or get IPV6_CHECKSUM for a non-raw IPv6 socket will fail.
尝试为ICMPv6套接字设置IPV6_校验和将失败。此外，为非原始IPV6套接字设置或获取IPV6_校验和的尝试也将失败。
(Note: Since the checksum is always calculated by the kernel for an ICMPv6 socket, applications are not able to generate ICMPv6 packets with incorrect checksums (presumably for testing purposes) using this API.)
（注意：由于内核总是为ICMPv6套接字计算校验和，因此应用程序无法使用此API生成校验和不正确的ICMPv6数据包（可能是出于测试目的）
ICMPv4 raw sockets receive most ICMPv4 messages received by the kernel. (We say "most" and not "all" because Berkeley-derived kernels never pass echo requests, timestamp requests, or address mask requests to a raw socket. Instead these three messages are processed entirely by the kernel.) But ICMPv6 is a superset of ICMPv4, also including the functionality of IGMPv4 and ARPv4. This means that an ICMPv6 raw socket can potentially receive many more messages than would be received with an ICMPv4 raw socket: ICMP messages similar to ICMPv4, along with neighbor solicitations, neighbor advertisements, and the three multicast listener discovery messages.
ICMPv4原始套接字接收内核接收的大多数ICMPv4消息。（我们说“大多数”而不是“全部”，因为Berkeley派生的内核从不向原始套接字传递回显请求、时间戳请求或地址掩码请求。相反，这三条消息完全由内核处理。）但ICMPv6是ICMPv4的超集，还包括IGMPv4和ARPv4的功能。这意味着ICMPv6原始套接字可能接收到比ICMPv4原始套接字更多的消息：类似于ICMPv4的ICMP消息，以及邻居请求、邻居播发和三个多播侦听器发现消息。
Most applications using an ICMPv6 raw socket care about only a small subset of the ICMPv6 message types. To transfer extraneous ICMPv6 messages from the kernel to user can incur a significant overhead. Therefore this API includes a method of filtering ICMPv6 messages by the ICMPv6 type field.
大多数使用ICMPv6原始套接字的应用程序只关心ICMPv6消息类型的一小部分。将无关的ICMPv6消息从内核传输到用户可能会产生很大的开销。因此，此API包含一种通过ICMPv6类型字段过滤ICMPv6消息的方法。
Each ICMPv6 raw socket has an associated filter whose datatype is defined as
每个ICMPv6原始套接字都有一个关联的筛选器，其数据类型定义为
struct icmp6_filter;
结构icmp6_过滤器；
This structure, along with the macros and constants defined later in this section, are defined as a result of including the <netinet/icmp6.h>.
此结构以及本节后面定义的宏和常量是由于包含了<netinet/icmp6.h>而定义的。
The current filter is fetched and stored using getsockopt() and setsockopt() with a level of IPPROTO_ICMPV6 and an option name of ICMP6_FILTER.
使用getsockopt（）和setsockopt（）获取和存储当前筛选器，级别为IPPROTO_ICMPV6，选项名称为ICMP6_filter。
Six macros operate on an icmp6_filter structure:
六个宏在icmp6_过滤器结构上运行：
void ICMP6_FILTER_SETPASSALL (struct icmp6_filter *);
void ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *);
void ICMP6_FILTER_SETPASSALL (struct icmp6_filter *);
void ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *);
void ICMP6_FILTER_SETPASS ( int, struct icmp6_filter *);
void ICMP6_FILTER_SETBLOCK( int, struct icmp6_filter *);
void ICMP6_FILTER_SETPASS ( int, struct icmp6_filter *);
void ICMP6_FILTER_SETBLOCK( int, struct icmp6_filter *);
int ICMP6_FILTER_WILLPASS (int,
const struct icmp6_filter *);
int ICMP6_FILTER_WILLBLOCK(int,
const struct icmp6_filter *);
int ICMP6_FILTER_WILLPASS (int,
const struct icmp6_filter *);
int ICMP6_FILTER_WILLBLOCK(int,
const struct icmp6_filter *);
The first argument to the last four macros (an integer) is an ICMPv6 message type, between 0 and 255. The pointer argument to all six macros is a pointer to a filter that is modified by the first four macros and is examined by the last two macros.
最后四个宏（整数）的第一个参数是ICMPv6消息类型，介于0和255之间。指向所有六个宏的指针参数是指向过滤器的指针，该过滤器由前四个宏修改，并由最后两个宏检查。
The first two macros, SETPASSALL and SETBLOCKALL, let us specify that all ICMPv6 messages are passed to the application or that all ICMPv6 messages are blocked from being passed to the application.
前两个宏SETPASSALL和SETBLOCKALL允许我们指定将所有ICMPv6消息传递给应用程序，或者阻止所有ICMPv6消息传递给应用程序。
The next two macros, SETPASS and SETBLOCK, let us specify that messages of a given ICMPv6 type should be passed to the application or not passed to the application (blocked).
接下来的两个宏SETPASS和SETBLOCK让我们指定给定ICMPv6类型的消息应该传递给应用程序，或者不传递给应用程序（阻塞）。
The final two macros, WILLPASS and WILLBLOCK, return true or false depending whether the specified message type is passed to the application or blocked from being passed to the application by the filter pointed to by the second argument.
最后两个宏WILLPASS和WILLBLOCK返回true或false，具体取决于指定的消息类型是传递给应用程序还是被第二个参数指向的筛选器阻止传递给应用程序。
When an ICMPv6 raw socket is created, it will by default pass all ICMPv6 message types to the application.
创建ICMPv6原始套接字时，默认情况下，它会将所有ICMPv6消息类型传递给应用程序。
As an example, a program that wants to receive only router advertisements could execute the following:
例如，只希望接收路由器广告的程序可以执行以下操作：
struct icmp6_filter myfilt;
结构icmp6_过滤器myfilt；
fd = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
fd = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
ICMP6_FILTER_SETBLOCKALL(&myfilt);
ICMP6_FILTER_SETPASS(ND_ROUTER_ADVERT, &myfilt);
setsockopt(fd, IPPROTO_ICMPV6, ICMP6_FILTER, &myfilt,
ICMP6_FILTER_SETBLOCKALL(&myfilt);
ICMP6_FILTER_SETPASS(ND_ROUTER_ADVERT, &myfilt);
setsockopt(fd, IPPROTO_ICMPV6, ICMP6_FILTER, &myfilt,
sizeof(myfilt));
sizeof（myfilt））；
The filter structure is declared and then initialized to block all messages types. The filter structure is then changed to allow router advertisement messages to be passed to the application and the filter is installed using setsockopt().
声明并初始化筛选器结构以阻止所有消息类型。然后更改筛选器结构，以允许将路由器广告消息传递给应用程序，并使用setsockopt（）安装筛选器。
In order to clear an installed filter the application can issue a setsockopt for ICMP6_FILTER with a zero length. When no such filter has been installed, getsockopt() will return the kernel default filter.
为了清除已安装的筛选器，应用程序可以为ICMP6_筛选器发出一个长度为零的setsockopt。当没有安装这样的过滤器时，getsockopt（）将返回内核默认过滤器。
The icmp6_filter structure is similar to the fd_set datatype used with the select() function in the sockets API. The icmp6_filter structure is an opaque datatype and the application should not care how it is implemented. All the application does with this datatype is allocate a variable of this type, pass a pointer to a variable of this type to getsockopt() and setsockopt(), and operate on a variable of this type using the six macros that we just defined.
icmp6_过滤器结构类似于sockets API中select（）函数使用的fd_集合数据类型。icmp6_筛选器结构是一种不透明的数据类型，应用程序不应该关心它是如何实现的。应用程序对该数据类型所做的只是分配一个该类型的变量，将指向该类型变量的指针传递给getsockopt（）和setsockopt（），并使用我们刚才定义的六个宏对该类型的变量进行操作。
Nevertheless, it is worth showing a simple implementation of this datatype and the six macros.
不过，值得展示此数据类型和六个宏的简单实现。
struct icmp6_filter {
uint32_t icmp6_filt[8]; /* 8*32 = 256 bits */
};
struct icmp6_filter {
uint32_t icmp6_filt[8]; /* 8*32 = 256 bits */
};
#define ICMP6_FILTER_WILLPASS(type, filterp) \
((((filterp)->icmp6_filt[(type) >> 5]) & \
(1 << ((type) & 31))) != 0)
#define ICMP6_FILTER_WILLBLOCK(type, filterp) \
((((filterp)->icmp6_filt[(type) >> 5]) & \
(1 << ((type) & 31))) == 0)
#define ICMP6_FILTER_SETPASS(type, filterp) \
((((filterp)->icmp6_filt[(type) >> 5]) |= \
(1 << ((type) & 31))))
#define ICMP6_FILTER_SETBLOCK(type, filterp) \
((((filterp)->icmp6_filt[(type) >> 5]) &= \
~(1 << ((type) & 31))))
#define ICMP6_FILTER_SETPASSALL(filterp) \
memset((filterp), 0xFF, sizeof(struct icmp6_filter))
#define ICMP6_FILTER_SETBLOCKALL(filterp) \
memset((filterp), 0, sizeof(struct icmp6_filter))
#define ICMP6_FILTER_WILLPASS(type, filterp) \
((((filterp)->icmp6_filt[(type) >> 5]) & \
(1 << ((type) & 31))) != 0)
#define ICMP6_FILTER_WILLBLOCK(type, filterp) \
((((filterp)->icmp6_filt[(type) >> 5]) & \
(1 << ((type) & 31))) == 0)
#define ICMP6_FILTER_SETPASS(type, filterp) \
((((filterp)->icmp6_filt[(type) >> 5]) |= \
(1 << ((type) & 31))))
#define ICMP6_FILTER_SETBLOCK(type, filterp) \
((((filterp)->icmp6_filt[(type) >> 5]) &= \
~(1 << ((type) & 31))))
#define ICMP6_FILTER_SETPASSALL(filterp) \
memset((filterp), 0xFF, sizeof(struct icmp6_filter))
#define ICMP6_FILTER_SETBLOCKALL(filterp) \
memset((filterp), 0, sizeof(struct icmp6_filter))
(Note: These sample definitions have two limitations that an implementation may want to change. The first four macros evaluate their first argument two times. The second two macros require the inclusion of the <string.h> header for the memset() function.)
（注意：这些示例定义有两个实现可能需要更改的限制。前四个宏对其第一个参数求值两次。后两个宏要求包含memset（）函数的<string.h>头。）
The protocol stack will verify the ICMPv6 checksum and discard any packets with invalid checksums.
协议栈将验证ICMPv6校验和，并丢弃任何校验和无效的数据包。
An implementation might perform additional validity checks on the ICMPv6 message content and discard malformed packets. However, a portable application must not assume that such validity checks have been performed.
实现可能会对ICMPv6消息内容执行额外的有效性检查，并丢弃格式错误的数据包。但是，便携式应用程序不能假设已经执行了此类有效性检查。
The protocol stack should not automatically discard packets if the ICMP type is unknown to the stack. For extensibility reasons received ICMP packets with any type (informational or error) must be passed to the applications (subject to ICMP6_FILTER filtering on the type value and the checksum verification).
如果协议栈不知道ICMP类型，则协议栈不应自动丢弃数据包。出于扩展性原因，必须将接收到的任何类型（信息或错误）的ICMP数据包传递给应用程序（根据ICMP6_过滤器对类型值进行过滤并进行校验和验证）。
Applications need to be able to control IPv6 header and extension header content when sending as well as being able to receive the content of these headers. This is done by defining socket option types which can be used both with setsockopt and with ancillary data. Ancillary data is discussed in Appendix A. The following optional information can be exchanged between the application and the kernel:
应用程序需要能够在发送时控制IPv6标头和扩展标头内容，并且能够接收这些标头的内容。这是通过定义套接字选项类型来实现的，该类型可与setsockopt和辅助数据一起使用。附录A中讨论了辅助数据。应用程序和内核之间可以交换以下可选信息：
1. The send/receive interface and source/destination address, 2. The hop limit, 3. Next hop address, 4. The traffic class, 5. Routing header, 6. Hop-by-Hop options header, and 7. Destination options header.
1. 发送/接收接口和源/目标地址，2。跳跃限制，3。下一跳地址，4。交通等级，5。路由头，6。逐跳选项标题和7。目的地选项标题。
First, to receive any of this optional information (other than the next hop address, which can only be set) on a UDP or raw socket, the application must call setsockopt() to turn on the corresponding flag:
首先，要在UDP或原始套接字上接收任何此可选信息（下一跳地址除外，该地址只能设置），应用程序必须调用setsockopt（）以打开相应的标志：
int on = 1;
int on=1；
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVTCLASS, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVTCLASS, &on, sizeof(on));
When any of these options are enabled, the corresponding data is returned as control information by recvmsg(), as one or more ancillary data objects.
当启用这些选项中的任何一个时，recvmsg（）将相应的数据作为一个或多个辅助数据对象作为控制信息返回。
This document does not define how to receive the optional information on a TCP socket. See Section 4.1 for more details.
本文档未定义如何接收TCP套接字上的可选信息。详见第4.1节。
Two different mechanisms exist for sending this optional information:
发送此可选信息有两种不同的机制：
1. Using setsockopt to specify the option content for a socket. These are known "sticky" options since they affect all transmitted packets on the socket until either a new setsockopt is done or the options are overridden using ancillary data.
1. 使用setsockopt指定套接字的选项内容。这些是已知的“粘性”选项，因为它们影响套接字上所有传输的数据包，直到完成新的setsockopt或使用辅助数据覆盖这些选项。
2. Using ancillary data to specify the option content for a single datagram. This only applies to datagram and raw sockets; not to TCP sockets.
2. 使用辅助数据指定单个数据报的选项内容。这仅适用于数据报和原始套接字；不支持TCP套接字。
The three socket option parameters and the three cmsghdr fields that describe the options/ancillary data objects are summarized as:
描述选项/辅助数据对象的三个套接字选项参数和三个cmsghdr字段总结如下：
opt level/ optname/ optval/
cmsg_level cmsg_type cmsg_data[]
------------ ------------ ------------------------
IPPROTO_IPV6 IPV6_PKTINFO in6_pktinfo structure
IPPROTO_IPV6 IPV6_HOPLIMIT int
IPPROTO_IPV6 IPV6_NEXTHOP socket address structure
IPPROTO_IPV6 IPV6_RTHDR ip6_rthdr structure
IPPROTO_IPV6 IPV6_HOPOPTS ip6_hbh structure
IPPROTO_IPV6 IPV6_DSTOPTS ip6_dest structure
IPPROTO_IPV6 IPV6_RTHDRDSTOPTS ip6_dest structure
IPPROTO_IPV6 IPV6_TCLASS int
opt level/ optname/ optval/
cmsg_level cmsg_type cmsg_data[]
------------ ------------ ------------------------
IPPROTO_IPV6 IPV6_PKTINFO in6_pktinfo structure
IPPROTO_IPV6 IPV6_HOPLIMIT int
IPPROTO_IPV6 IPV6_NEXTHOP socket address structure
IPPROTO_IPV6 IPV6_RTHDR ip6_rthdr structure
IPPROTO_IPV6 IPV6_HOPOPTS ip6_hbh structure
IPPROTO_IPV6 IPV6_DSTOPTS ip6_dest structure
IPPROTO_IPV6 IPV6_RTHDRDSTOPTS ip6_dest structure
IPPROTO_IPV6 IPV6_TCLASS int
(Note: IPV6_HOPLIMIT can be used as ancillary data items only)
（注意：IPV6_HOPLIMIT只能用作辅助数据项）
All these options are described in detail in Section 6, 7, 8 and 9. All the constants beginning with IPV6_ are defined as a result of including <netinet/in.h>.
第6、7、8和9节详细介绍了所有这些选项。所有以IPV6开头的常量都是由于包含<netinet/in.h>而定义的。
Note: We intentionally use the same constant for the cmsg_level member as is used as the second argument to getsockopt() and setsockopt() (what is called the "level"), and the same constant for the cmsg_type member as is used as the third argument to getsockopt() and setsockopt() (what is called the "option name").
注意：我们有意为cmsg_级别成员使用与getsockopt（）和setsockopt（）的第二个参数相同的常量（称为“级别”），为cmsg_类型成员使用与getsockopt（）和setsockopt（）的第三个参数相同的常量（称为“选项名称”）。
Issuing getsockopt() for the above options will return the sticky option value i.e., the value set with setsockopt(). If no sticky option value has been set getsockopt() will return the following values:
为上述选项发出getsockopt（）将返回粘性选项值，即使用setsockopt（）设置的值。如果未设置粘性选项值，getsockopt（）将返回以下值：
- For the IPV6_PKTINFO option, it will return an in6_pktinfo structure with ipi6_addr being in6addr_any and ipi6_ifindex being zero.
- 对于IPV6_PKTINFO选项，它将返回一个in6_PKTINFO结构，其中ipi6_addr为in6addr_any，ipi6_iIndex为零。
- For the IPV6_TCLASS option, it will return the kernel default value.
- 对于IPV6_TCLASS选项，它将返回内核默认值。
- For other options, it will indicate the lack of the option value with optlen being zero.
- 对于其他选项，它将指示缺少optlen为零的选项值。
The application does not explicitly need to access the data structures for the Routing header, Hop-by-Hop options header, and Destination options header, since the API to these features is through a set of inet6_rth_XXX() and inet6_opt_XXX() functions that we define in Section 7 and Section 10. Those functions simplify the interface to these features instead of requiring the application to know the intimate details of the extension header formats.
应用程序不需要显式访问路由头、逐跳选项头和目的地选项头的数据结构，因为这些功能的API是通过我们在第7节和第10节中定义的一组inet6_rth_XXX（）和inet6_opt_XXX（）函数实现的。这些函数简化了这些特性的接口，而不需要应用程序了解扩展头格式的详细信息。
When specifying extension headers, this API assumes the header ordering and the number of occurrences of each header as described in [RFC-2460]. More details about the ordering issue will be discussed in Section 12.
指定扩展标头时，此API假定标头顺序和每个标头的出现次数如[RFC-2460]中所述。有关订购问题的更多详细信息将在第12节中讨论。
It is not possible to use ancillary data to transmit the above options for TCP since there is not a one-to-one mapping between send operations and the TCP segments being transmitted. Instead an application can use setsockopt to specify them as sticky options. When the application uses setsockopt to specify the above options it is expected that TCP will start using the new information when sending segments. However, TCP may or may not use the new information when retransmitting segments that were originally sent when the old sticky options were in effect.
由于发送操作和正在传输的TCP段之间没有一对一的映射，因此无法使用辅助数据传输TCP的上述选项。相反，应用程序可以使用setsockopt将它们指定为粘性选项。当应用程序使用setsockopt指定上述选项时，TCP在发送段时将开始使用新信息。但是，在重新传输旧的粘性选项生效时最初发送的段时，TCP可能会也可能不会使用新信息。
It is unclear how a TCP application can use received information (such as extension headers) due to the lack of mapping between received TCP segments and receive operations. In particular, the received information could not be used for access control purposes like on UDP and raw sockets.
由于接收到的TCP段和接收操作之间缺乏映射，TCP应用程序如何使用接收到的信息（如扩展头）尚不清楚。特别是，接收到的信息不能用于访问控制目的，如UDP和原始套接字。
This specification therefore does not define how to get the received information on TCP sockets. The result of the IPV6_RECVxxx options on a TCP socket is undefined as well.
因此，本规范没有定义如何获取TCP套接字上接收到的信息。TCP套接字上IPV6_RECVxxx选项的结果也未定义。
The receive behavior for UDP and raw sockets is quite straightforward. After the application has enabled an IPV6_RECVxxx socket option it will receive ancillary data items for every recvmsg() call containing the requested information. However, if the information is not present in the packet the ancillary data item will not be included. For example, if the application enables IPV6_RECVRTHDR and a received datagram does not contain a Routing header there will not be an IPV6_RTHDR ancillary data item. Note that due to buffering in the socket implementation there might be some packets queued when an IPV6_RECVxxx option is enabled and they might not have the ancillary data information.
UDP和原始套接字的接收行为非常简单。应用程序启用IPV6_RECVxxx套接字选项后，它将为每个包含请求信息的recvmsg（）调用接收辅助数据项。然而，如果信息不存在于分组中，则辅助数据项将不被包括。例如，如果应用程序启用IPV6_RECVRTHDR，并且接收到的数据报不包含路由标头，则不会有IPV6_rchdr辅助数据项。请注意，由于套接字实现中的缓冲，当启用IPV6_RECVxxx选项时，可能会有一些数据包排队，并且它们可能没有辅助数据信息。
For sending the application has the choice between using sticky options and ancillary data. The application can also use both having the sticky options specify the "default" and using ancillary data to override the default options.
对于发送，应用程序可以选择使用粘性选项和辅助数据。应用程序还可以使用粘性选项指定“默认”和使用辅助数据覆盖默认选项。
When an ancillary data item is specified in a call to sendmsg(), the item will override an existing sticky option of the same name (if previously specified). For example, if the application has set IPV6_RTHDR using a sticky option and later passes IPV6_RTHDR as ancillary data this will override the IPV6_RTHDR sticky option and the routing header of the outgoing packet will be from the ancillary data item, not from the sticky option. Note, however, that other sticky options than IPV6_RTHDR will not be affected by the IPV6_RTHDR ancillary data item; the overriding mechanism only works for the same type of sticky options and ancillary data items.
当在对sendmsg（）的调用中指定辅助数据项时，该项将覆盖同名的现有粘性选项（如果以前指定）。例如，如果应用程序使用粘性选项设置了IPV6\u RTHDR，然后将IPV6\u RTHDR作为辅助数据传递，这将覆盖IPV6\u RTHDR粘性选项，并且传出数据包的路由头将来自辅助数据项，而不是粘性选项。但是，请注意，除IPV6_RTHDR之外的其他粘性选项将不受IPV6_RTHDR辅助数据项的影响；覆盖机制仅适用于相同类型的粘性选项和辅助数据项。
(Note: the overriding rule is different from the one in RFC 2292. In RFC 2292, an ancillary data item overrode all sticky options previously defined. This was reasonable, because sticky options could only be specified as a set by a single socket option. However, in this API, each option is separated so that it can be specified as a single sticky option. Additionally, there are much more ancillary data items and sticky options than in RFC 2292, including ancillary-only one. Thus, it should be natural for application programmers to separate the overriding rule as well.)
（注意：覆盖规则不同于RFC 2292中的规则。在RFC 2292中，辅助数据项覆盖了先前定义的所有粘性选项。这是合理的，因为粘性选项只能由单个套接字选项指定为一个集合。但是，在此API中，每个选项是分开的，因此可以将其指定为单个粘性选项。）此外，与RFC 2292相比，有更多的辅助数据项和粘性选项，只包括一个辅助数据项和粘性选项。因此，应用程序程序员也应该很自然地分离覆盖规则。）
An application can also temporarily disable a particular sticky option by specifying a corresponding ancillary data item that could disable the sticky option when being used as an argument for a socket option. For example, if the application has set IPV6_HOPOPTS as a
应用程序还可以通过指定相应的辅助数据项暂时禁用特定的粘性选项，该辅助数据项可以在用作套接字选项的参数时禁用粘性选项。例如，如果应用程序已将IPV6_HOPOPTS设置为
sticky option and later passes IPV6_HOPOPTS with a zero length as an ancillary data item, the packet will not have a Hop-by-Hop options header.
sticky选项，然后将长度为零的IPV6_HOPOPTS作为辅助数据项传递，则数据包将不具有逐跳选项标头。
This specification uses ancillary data as defined in Posix with some compatible extensions, which are described in the following subsections. Section 20 will provide a detailed overview of ancillary data and related structures and macros, including the extensions.
本规范使用Posix中定义的辅助数据以及一些兼容的扩展，这些扩展将在以下小节中描述。第20节将提供辅助数据、相关结构和宏（包括扩展）的详细概述。
struct cmsghdr *CMSG_NXTHDR(const struct msghdr *mhdr,
const struct cmsghdr *cmsg);
struct cmsghdr *CMSG_NXTHDR(const struct msghdr *mhdr,
const struct cmsghdr *cmsg);
CMSG_NXTHDR() returns a pointer to the cmsghdr structure describing the next ancillary data object. Mhdr is a pointer to a msghdr structure and cmsg is a pointer to a cmsghdr structure. If there is not another ancillary data object, the return value is NULL.
CMSG_NXTHDR（）返回指向描述下一个辅助数据对象的cmsghdr结构的指针。Mhdr是指向msghdr结构的指针，cmsg是指向cmsghdr结构的指针。如果没有其他辅助数据对象，则返回值为NULL。
The following behavior of this macro is new to this API: if the value of the cmsg pointer is NULL, a pointer to the cmsghdr structure describing the first ancillary data object is returned. That is, CMSG_NXTHDR(mhdr, NULL) is equivalent to CMSG_FIRSTHDR(mhdr). If there are no ancillary data objects, the return value is NULL.
此宏的以下行为对此API来说是新的：如果cmsg指针的值为NULL，则返回一个指向描述第一个辅助数据对象的cmsghdr结构的指针。也就是说，CMSG_NXTHDR（mhdr，NULL）等同于CMSG_FIRSTHDR（mhdr）。如果没有辅助数据对象，则返回值为NULL。
socklen_t CMSG_SPACE(socklen_t length);
socklen_t CMSG_空间（socklen_t长度）；
This macro is new with this API. Given the length of an ancillary data object, CMSG_SPACE() returns an upper bound on the space required by the object and its cmsghdr structure, including any padding needed to satisfy alignment requirements. This macro can be used, for example, when allocating space dynamically for the ancillary data. This macro should not be used to initialize the cmsg_len member of a cmsghdr structure; instead use the CMSG_LEN() macro.
此宏是此API新增的。给定辅助数据对象的长度，CMSG_SPACE（）返回该对象及其cmsghdr结构所需空间的上限，包括满足对齐要求所需的任何填充。例如，在为辅助数据动态分配空间时，可以使用此宏。此宏不应用于初始化cmsghdr结构的cmsg_len成员；而是使用CMSG_LEN（）宏。
socklen_t CMSG_LEN(socklen_t length);
承插长度（承插长度）；
This macro is new with this API. Given the length of an ancillary data object, CMSG_LEN() returns the value to store in the cmsg_len member of the cmsghdr structure, taking into account any padding needed to satisfy alignment requirements.
此宏是此API新增的。给定辅助数据对象的长度，CMSG_LEN（）返回要存储在cmsghdr结构的CMSG_LEN成员中的值，同时考虑满足对齐要求所需的任何填充。
Note the difference between CMSG_SPACE() and CMSG_LEN(), shown also in the figure in Section 20.2: the former accounts for any required padding at the end of the ancillary data object and the latter is the actual length to store in the cmsg_len member of the ancillary data object.
注意CMSG_SPACE（）和CMSG_LEN（）之间的差异，如第20.2节中的图所示：前者用于在辅助数据对象的末尾进行任何所需的填充，后者是存储在辅助数据对象的CMSG_LEN成员中的实际长度。
There are five pieces of information that an application can specify for an outgoing packet using ancillary data:
应用程序可以使用辅助数据为传出数据包指定五条信息：
1. the source IPv6 address, 2. the outgoing interface index, 3. the outgoing hop limit, 4. the next hop address, and 5. the outgoing traffic class value.
1. 源IPv6地址，2。传出接口索引，3。传出跃点限制为4。下一个跃点地址，以及5。传出流量类别值。
Four similar pieces of information can be returned for a received packet as ancillary data:
对于接收到的数据包，可以返回四条类似的信息作为辅助数据：
1. the destination IPv6 address, 2. the arriving interface index, 3. the arriving hop limit, and 4. the arriving traffic class value.
1. 目标IPv6地址，2。到达界面指数，3。到达跳数限制，以及4。到达的交通等级值。
The first two pieces of information are contained in an in6_pktinfo structure that is set with setsockopt() or sent as ancillary data with sendmsg() and received as ancillary data with recvmsg(). This structure is defined as a result of including <netinet/in.h>.
前两条信息包含在in6_pktinfo结构中，该结构使用setsockopt（）设置，或使用sendmsg（）作为辅助数据发送，使用recvmsg（）作为辅助数据接收。此结构定义为包含<netinet/in.h>的结果。
struct in6_pktinfo {
struct in6_addr ipi6_addr; /* src/dst IPv6 address */
unsigned int ipi6_ifindex; /* send/recv interface index */
};
struct in6_pktinfo {
struct in6_addr ipi6_addr; /* src/dst IPv6 address */
unsigned int ipi6_ifindex; /* send/recv interface index */
};
In the socket option and cmsghdr level will be IPPROTO_IPV6, the type will be IPV6_PKTINFO, and the first byte of the option value and cmsg_data[] will be the first byte of the in6_pktinfo structure. An application can clear any sticky IPV6_PKTINFO option by doing a
在套接字中，选项和cmsghdr级别将为IPPROTO_IPV6，类型将为IPV6_PKTINFO，选项值和cmsg_data[]的第一个字节将是in6_PKTINFO结构的第一个字节。应用程序可以通过执行
"regular" setsockopt with ipi6_addr being in6addr_any and ipi6_ifindex being zero.
“常规”setsockopt，ipi6地址在6addr\u any中，ipi6\u iIndex为零。
This information is returned as ancillary data by recvmsg() only if the application has enabled the IPV6_RECVPKTINFO socket option:
仅当应用程序已启用IPV6_RECVPKTINFO套接字选项时，recvmsg（）才会将此信息作为辅助数据返回：
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on));
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on));
(Note: The hop limit is not contained in the in6_pktinfo structure for the following reason. Some UDP servers want to respond to client requests by sending their reply out the same interface on which the request was received and with the source IPv6 address of the reply equal to the destination IPv6 address of the request. To do this the application can enable just the IPV6_RECVPKTINFO socket option and then use the received control information from recvmsg() as the outgoing control information for sendmsg(). The application need not examine or modify the in6_pktinfo structure at all. But if the hop limit were contained in this structure, the application would have to parse the received control information and change the hop limit member, since the received hop limit is not the desired value for an outgoing packet.)
（注意：in6_pktinfo结构中不包含跃点限制，原因如下。某些UDP服务器希望通过将其回复发送到接收请求的同一接口来响应客户端请求，并且回复的源IPv6地址等于请求的目标IPv6地址。为此，应用程序on可以仅启用IPV6_RECVPKTINFO套接字选项，然后使用从recvmsg（）接收的控制信息作为sendmsg（）的传出控制信息。应用程序根本不需要检查或修改in6_pktinfo结构。但是，如果此结构中包含跃点限制，则应用程序必须解析接收到的控制信息并更改跃点限制成员，因为接收到的跃点限制不是传出数据包的所需值。）
Interfaces on an IPv6 node are identified by a small positive integer, as described in Section 4 of [RFC-3493]. That document also describes a function to map an interface name to its interface index, a function to map an interface index to its interface name, and a function to return all the interface names and indexes. Notice from this document that no interface is ever assigned an index of 0.
IPv6节点上的接口由一个小的正整数标识，如[RFC-3493]第4节所述。该文档还描述了将接口名称映射到其接口索引的函数、将接口索引映射到其接口名称的函数以及返回所有接口名称和索引的函数。请注意，在此文档中，从未为任何接口分配索引0。
When specifying the outgoing interface, if the ipi6_ifindex value is 0, the kernel will choose the outgoing interface.
指定传出接口时，如果ipi6_iIndex值为0，内核将选择传出接口。
The ordering among various options that can specify the outgoing interface, including IPV6_PKTINFO, is defined in Section 6.7.
第6.7节定义了可指定传出接口（包括IPV6_PKTINFO）的各种选项之间的顺序。
When the IPV6_RECVPKTINFO socket option is enabled, the received interface index is always returned as the ipi6_ifindex member of the in6_pktinfo structure.
启用IPV6_RECVPKTINFO套接字选项时，收到的接口索引始终作为in6_pktinfo结构的ipi6_iIndex成员返回。
The source IPv6 address can be specified by calling bind() before each output operation, but supplying the source address together with the data requires less overhead (i.e., fewer system calls) and requires less state to be stored and protected in a multithreaded application.
可以通过在每次输出操作之前调用bind（）来指定源IPv6地址，但是提供源地址和数据需要更少的开销（即更少的系统调用），并且需要在多线程应用程序中存储和保护的状态更少。
When specifying the source IPv6 address as ancillary data, if the ipi6_addr member of the in6_pktinfo structure is the unspecified address (IN6ADDR_ANY_INIT or in6addr_any), then (a) if an address is currently bound to the socket, it is used as the source address, or (b) if no address is currently bound to the socket, the kernel will choose the source address. If the ipi6_addr member is not the unspecified address, but the socket has already bound a source address, then the ipi6_addr value overrides the already-bound source address for this output operation only.
将源IPv6地址指定为辅助数据时，如果in6_pktinfo结构的ipi6_addr成员是未指定的地址（IN6ADDR_ANY_INIT或IN6ADDR_ANY），则（a）如果某个地址当前绑定到套接字，则将其用作源地址，或者（b）如果当前没有地址绑定到套接字，内核将选择源地址。如果ipi6_addr成员不是未指定的地址，但套接字已绑定源地址，则ipi6_addr值仅覆盖此输出操作的已绑定源地址。
The kernel must verify that the requested source address is indeed a unicast address assigned to the node. When the address is a scoped one, there may be ambiguity about its scope zone. This is particularly the case for link-local addresses. In such a case, the kernel must first determine the appropriate scope zone based on the zone of the destination address or the outgoing interface (if known), then qualify the address. This also means that it is not feasible to specify the source address for a non-binding socket by the IPV6_PKTINFO sticky option, unless the outgoing interface is also specified. The application should simply use bind() for such purposes.
内核必须验证请求的源地址确实是分配给节点的单播地址。当地址是作用域地址时，其作用域区域可能存在歧义。链路本地地址尤其如此。在这种情况下，内核必须首先根据目标地址或传出接口（如果已知）的区域确定适当的作用域区域，然后限定地址。这也意味着通过IPV6_PKTINFO sticky选项为非绑定套接字指定源地址是不可行的，除非还指定了传出接口。应用程序只需使用bind（）即可实现此目的。
IPV6_PKTINFO can also be used as a sticky option for specifying the socket's default source address. However, the ipi6_addr member must be the unspecified address for TCP sockets, because it is not possible to dynamically change the source address of a TCP connection. When the IPV6_PKTINFO option is specified for a TCP socket with a non-unspecified address, the call will fail. This restriction should be applied even before the socket binds a specific address.
IPV6_PKTINFO还可以用作指定套接字默认源地址的粘性选项。但是，ipi6_addr成员必须是TCP套接字的未指定地址，因为无法动态更改TCP连接的源地址。如果为具有非指定地址的TCP套接字指定了IPV6_PKTINFO选项，则调用将失败。即使在套接字绑定特定地址之前，也应该应用此限制。
When the in6_pktinfo structure is returned as ancillary data by recvmsg(), the ipi6_addr member contains the destination IPv6 address from the received packet.
当recvmsg（）将in6_pktinfo结构作为辅助数据返回时，ipi6_addr成员包含来自接收数据包的目标IPv6地址。
The outgoing hop limit is normally specified with either the IPV6_UNICAST_HOPS socket option or the IPV6_MULTICAST_HOPS socket option, both of which are described in [RFC-3493]. Specifying the
传出跃点限制通常通过IPV6_单播_跃点套接字选项或IPV6_多播_跃点套接字选项指定，这两个选项在[RFC-3493]中均有描述。指定
hop limit as ancillary data lets the application override either the kernel's default or a previously specified value, for either a unicast destination or a multicast destination, for a single output operation. Returning the received hop limit is useful for IPv6 applications that need to verify that the received hop limit is 255 (e.g., that the packet has not been forwarded).
对于单播目的地或多播目的地，作为辅助数据的跃点限制允许应用程序为单个输出操作覆盖内核的默认值或以前指定的值。返回接收到的跃点限制对于需要验证接收到的跃点限制是否为255（例如，数据包尚未转发）的IPv6应用程序非常有用。
The received hop limit is returned as ancillary data by recvmsg() only if the application has enabled the IPV6_RECVHOPLIMIT socket option:
仅当应用程序已启用IPV6_RECVHOPLIMIT套接字选项时，recvmsg（）才会将收到的跃点限制作为辅助数据返回：
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on));
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on));
In the cmsghdr structure containing this ancillary data, the cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be IPV6_HOPLIMIT, and the first byte of cmsg_data[] will be the first byte of the integer hop limit.
在包含此辅助数据的cmsghdr结构中，cmsg_级成员将是IPPROTO_IPV6，cmsg_类型成员将是IPV6_hopflimit，cmsg_data[]的第一个字节将是整数hop limit的第一个字节。
Nothing special need be done to specify the outgoing hop limit: just specify the control information as ancillary data for sendmsg(). As specified in [RFC-3493], the interpretation of the integer hop limit value is
无需执行任何特殊操作来指定传出跃点限制：只需将控制信息指定为sendmsg（）的辅助数据。如[RFC-3493]所述，整数跃点限制值的解释为
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: return an error of EINVAL
x == -1: use kernel default
0 <= x <= 255: use x
x >= 256: return an error of EINVAL
This API defines IPV6_HOPLIMIT as an ancillary-only option, that is, the option name cannot be used as a socket option. This is because [RFC-3493] has more fine-grained socket options; IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS.
此API将IPV6_HOPLIMIT定义为仅辅助选项，即选项名称不能用作套接字选项。这是因为[RFC-3493]有更多细粒度的套接字选项；IPV6_单播_跃点和IPV6_多播_跃点。
The IPV6_NEXTHOP ancillary data object specifies the next hop for the datagram as a socket address structure. In the cmsghdr structure containing this ancillary data, the cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be IPV6_NEXTHOP, and the first byte of cmsg_data[] will be the first byte of the socket address structure.
IPV6_NEXTHOP辅助数据对象将数据报的下一个跃点指定为套接字地址结构。在包含此辅助数据的cmsghdr结构中，cmsg_级成员将是IPPROTO_IPV6，cmsg_类型成员将是IPV6_NEXTHOP，cmsg_data[]的第一个字节将是套接字地址结构的第一个字节。
This is a privileged option. (Note: It is implementation defined and beyond the scope of this document to define what "privileged" means. Unix systems use this term to mean the process must have an effective user ID of 0.)
这是一个特权选项。（注意：定义“特权”的含义是实现定义的，超出了本文档的范围。Unix系统使用此术语表示进程的有效用户ID必须为0。）
This API only defines the case where the socket address contains an IPv6 address (i.e., the sa_family member is AF_INET6). And, in this case, the node identified by that address must be a neighbor of the sending host. If that address equals the destination IPv6 address of the datagram, then this is equivalent to the existing SO_DONTROUTE socket option.
此API仅定义套接字地址包含IPv6地址的情况（即，sa_家族成员为AF_INET6）。在这种情况下，由该地址标识的节点必须是发送主机的邻居。如果该地址等于数据报的目标IPv6地址，则这相当于现有的SO_DONTROUTE套接字选项。
This option does not have any meaning for multicast destinations. In such a case, the specified next hop will be ignored.
此选项对于多播目标没有任何意义。在这种情况下，将忽略指定的下一跳。
When the outgoing interface is specified by IPV6_PKTINFO as well, the next hop specified by this option must be reachable via the specified interface.
如果IPV6_PKTINFO也指定了传出接口，则此选项指定的下一个跃点必须可以通过指定的接口访问。
In order to clear a sticky IPV6_NEXTHOP option the application must issue a setsockopt for IPV6_NEXTHOP with a zero length.
为了清除粘性IPV6_NEXTHOP选项，应用程序必须为IPV6_NEXTHOP发出一个长度为零的setsockopt。
The outgoing traffic class is normally set to 0. Specifying the traffic class as ancillary data lets the application override either the kernel's default or a previously specified value, for either a unicast destination or a multicast destination, for a single output operation. Returning the received traffic class is useful for programs such as a diffserv debugging tool and for user level ECN (explicit congestion notification) implementation.
传出流量类别通常设置为0。对于单播目的地或多播目的地，对于单个输出操作，将流量类指定为辅助数据可以让应用程序覆盖内核的默认值或以前指定的值。返回接收到的流量类对于diffserv调试工具等程序以及用户级ECN（显式拥塞通知）实现非常有用。
The received traffic class is returned as ancillary data by recvmsg() only if the application has enabled the IPV6_RECVTCLASS socket option:
仅当应用程序已启用IPV6_RECVTCLASS套接字选项时，recvmsg（）才会将收到的流量类作为辅助数据返回：
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVTCLASS, &on, sizeof(on));
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVTCLASS, &on, sizeof(on));
In the cmsghdr structure containing this ancillary data, the cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be IPV6_TCLASS, and the first byte of cmsg_data[] will be the first byte of the integer traffic class.
在包含此辅助数据的cmsghdr结构中，cmsg_级别的成员将是IPPROTO_IPV6，cmsg_类型的成员将是IPV6_TCLASS，cmsg_数据[]的第一个字节将是整数流量类的第一个字节。
To specify the outgoing traffic class value, just specify the control information as ancillary data for sendmsg() or using setsockopt(). Just like the hop limit value, the interpretation of the integer traffic class value is
要指定传出流量类值，只需将控制信息指定为sendmsg（）的辅助数据或使用setsockopt（）。与跃点限制值一样，整数流量类值的解释是
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: return an error of EINVAL
x == -1: use kernel default
0 <= x <= 255: use x
x >= 256: return an error of EINVAL
In order to clear a sticky IPV6_TCLASS option the application can specify -1 as the value.
为了清除粘性IPV6_TCLASS选项，应用程序可以指定-1作为值。
There are cases where the kernel needs to control the traffic class value and conflicts with the user-specified value on the outgoing traffic. An example is an implementation of ECN in the kernel, setting 2 bits of the traffic class value. In such cases, the kernel should override the user-specified value. On the incoming traffic, the kernel may mask some of the bits in the traffic class field.
在某些情况下，内核需要控制流量类值，并与传出流量上用户指定的值冲突。一个例子是在内核中实现ECN，设置流量类值的2位。在这种情况下，内核应该覆盖用户指定的值。对于传入的流量，内核可能会屏蔽流量类字段中的一些位。
With the IPV6_PKTINFO socket option there are no additional errors possible with the call to recvmsg(). But when specifying the outgoing interface or the source address, additional errors are possible from sendmsg() or setsockopt(). Note that some implementations might only be able to return this type of errors for setsockopt(). The following are examples, but some of these may not be provided by some implementations, and some implementations may define additional errors:
使用IPV6_PKTINFO socket选项，调用recvmsg（）不会出现其他错误。但在指定传出接口或源地址时，sendmsg（）或setsockopt（）可能会出现其他错误。请注意，某些实现可能只能为setsockopt（）返回此类错误。以下是一些示例，但其中一些可能不是由某些实现提供的，某些实现可能会定义其他错误：
ENXIO The interface specified by ipi6_ifindex does not exist.
ENXIO ipi6_iIndex指定的接口不存在。
ENETDOWN The interface specified by ipi6_ifindex is not enabled for IPv6 use.
ENETDOWN ipi6\u iIndex指定的接口未启用IPv6使用。
EADDRNOTAVAIL ipi6_ifindex specifies an interface but the address ipi6_addr is not available for use on that interface.
EADDRNOTAVAIL ipi6_iIndex指定了一个接口，但地址ipi6_addr在该接口上不可用。
EHOSTUNREACH No route to the destination exists over the interface specified by ipi6_ifindex.
EHOSTUNREACH在ipi6_iIndex指定的接口上不存在到目标的路由。
This document and [RFC-3493] specify various methods that affect the selection of the packet's outgoing interface. This subsection summarizes the ordering among those in order to ensure deterministic behavior.
本文件和[RFC-3493]规定了影响数据包输出接口选择的各种方法。本小节总结了这些规则之间的顺序，以确保确定性行为。
For a given outgoing packet on a given socket, the outgoing interface is determined in the following order:
对于给定套接字上的给定传出数据包，按照以下顺序确定传出接口：
1. if an interface is specified in an IPV6_PKTINFO ancillary data item, the interface is used.
1. 如果在IPV6_PKTINFO辅助数据项中指定了接口，则使用该接口。
2. otherwise, if an interface is specified in an IPV6_PKTINFO sticky option, the interface is used.
2. 否则，如果在IPV6_PKTINFO sticky选项中指定了接口，则将使用该接口。
3. otherwise, if the destination address is a multicast address and the IPV6_MULTICAST_IF socket option is specified for the socket, the interface is used.
3. 否则，如果目标地址是多播地址，并且为套接字指定了IPV6_multicast_if socket选项，则使用该接口。
4. otherwise, if an IPV6_NEXTHOP ancillary data item is specified, the interface to the next hop is used.
4. 否则，如果指定了IPV6_NEXTHOP辅助数据项，则使用到下一个跃点的接口。
5. otherwise, if an IPV6_NEXTHOP sticky option is specified, the interface to the next hop is used.
5. 否则，如果指定了IPV6_NEXTHOP sticky选项，则使用到下一个跃点的接口。
6. otherwise, the outgoing interface should be determined in an implementation dependent manner.
6. 否则，应以依赖于实现的方式确定传出接口。
The ordering above particularly means if the application specifies an interface by the IPV6_MULTICAST_IF socket option (described in [RFC-3493]) as well as specifying a different interface by the IPV6_PKTINFO sticky option, the latter will override the former for every multicast packet on the corresponding socket. The reason for the ordering comes from expectation that the source address is specified as well and that the pair of the address and the outgoing interface should be preferred.
上述顺序特别意味着，如果应用程序通过IPV6_MULTICAST_if socket选项（如[RFC-3493]所述）指定接口，以及通过IPV6_PKTINFO sticky选项指定不同的接口，则后者将覆盖相应套接字上每个多播包的前一个接口。排序的原因来自于这样的期望：源地址也被指定，并且地址和输出接口对应该是首选的。
In any case, the kernel must also verify that the source and destination addresses do not break their scope zones with regard to the outgoing interface.
在任何情况下，内核还必须验证源地址和目标地址是否没有打破它们与传出接口相关的作用域。
Source routing in IPv6 is accomplished by specifying a Routing header as an extension header. There can be different types of Routing headers, but IPv6 currently defines only the Type 0 Routing header [RFC-2460]. This type supports up to 127 intermediate nodes (limited by the length field in the extension header). With this maximum number of intermediate nodes, a source, and a destination, there are 128 hops.
IPv6中的源路由是通过将路由标头指定为扩展标头来完成的。可以有不同类型的路由头，但IPv6当前仅定义类型0路由头[RFC-2460]。此类型最多支持127个中间节点（受扩展标头中的长度字段限制）。中间节点、源和目标的最大数量为128跳。
Source routing with the IPv4 sockets API (the IP_OPTIONS socket option) requires the application to build the source route in the format that appears as the IPv4 header option, requiring intimate knowledge of the IPv4 options format. This IPv6 API, however, defines six functions that the application calls to build and examine a Routing header, and the ability to use sticky options or ancillary data to communicate this information between the application and the kernel using the IPV6_RTHDR option.
使用IPv4套接字API（IP_选项套接字选项）的源路由要求应用程序以显示为IPv4标头选项的格式构建源路由，这需要熟悉IPv4选项格式。但是，此IPv6 API定义了应用程序为构建和检查路由头而调用的六个函数，以及使用粘性选项或辅助数据在应用程序和内核之间使用IPv6_RTHDR选项传递此信息的能力。
Three functions build a Routing header:
三个功能用于构建路由标头：
inet6_rth_space() - return #bytes required for Routing header
inet6_rth_init() - initialize buffer data for Routing header
inet6_rth_add() - add one IPv6 address to the Routing header
inet6_rth_space() - return #bytes required for Routing header
inet6_rth_init() - initialize buffer data for Routing header
inet6_rth_add() - add one IPv6 address to the Routing header
Three functions deal with a returned Routing header:
三个函数处理返回的路由标头：
inet6_rth_reverse() - reverse a Routing header
inet6_rth_segments() - return #segments in a Routing header
inet6_rth_getaddr() - fetch one address from a Routing header
inet6_rth_reverse() - reverse a Routing header
inet6_rth_segments() - return #segments in a Routing header
inet6_rth_getaddr() - fetch one address from a Routing header
The function prototypes for these functions are defined as a result of including <netinet/in.h>.
这些函数的函数原型定义为包含<netinet/in.h>的结果。
To receive a Routing header the application must enable the IPV6_RECVRTHDR socket option:
要接收路由标头，应用程序必须启用IPV6_RECVRTHDR套接字选项：
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
Each received Routing header is returned as one ancillary data object described by a cmsghdr structure with cmsg_type set to IPV6_RTHDR. When multiple Routing headers are received, multiple ancillary data objects (with cmsg_type set to IPV6_RTHDR) will be returned to the application.
每个接收到的路由报头作为一个辅助数据对象返回，该辅助数据对象由cmsghdr结构描述，cmsg_类型设置为IPV6_RTHDR。当接收到多个路由头时，多个辅助数据对象（cmsg_type设置为IPV6_RTHDR）将返回给应用程序。
To send a Routing header the application specifies it either as ancillary data in a call to sendmsg() or using setsockopt(). For the sending side, this API assumes the number of occurrences of the Routing header as described in [RFC-2460]. That is, applications can only specify at most one outgoing Routing header.
要发送路由标头，应用程序将其指定为调用sendmsg（）的辅助数据或使用setsockopt（）。对于发送端，此API假定路由报头的出现次数如[RFC-2460]中所述。也就是说，应用程序最多只能指定一个传出路由头。
The application can remove any sticky Routing header by calling setsockopt() for IPV6_RTHDR with a zero option length.
应用程序可以通过使用零选项长度调用IPV6的setsockopt（）删除任何粘性路由头。
When using ancillary data a Routing header is passed between the application and the kernel as follows: The cmsg_level member has a value of IPPROTO_IPV6 and the cmsg_type member has a value of IPV6_RTHDR. The contents of the cmsg_data[] member is implementation dependent and should not be accessed directly by the application, but should be accessed using the six functions that we are about to describe.
使用辅助数据时，在应用程序和内核之间传递路由头，如下所示：cmsg_级别成员的值为IPPROTO_IPV6，cmsg_类型成员的值为IPV6_RTHDR。cmsg_data[]成员的内容取决于实现，不应由应用程序直接访问，但应使用我们将要描述的六个函数进行访问。
The following constant is defined as a result of including the <netinet/in.h>:
以下常数定义为包含<netinet/in.h>的结果：
#define IPV6_RTHDR_TYPE_0 0 /* IPv6 Routing header type 0 */
#define IPV6_RTHDR_TYPE_0 0 /* IPv6 Routing header type 0 */
When a Routing header is specified, the destination address specified for connect(), sendto(), or sendmsg() is the final destination address of the datagram. The Routing header then contains the addresses of all the intermediate nodes.
指定路由标头时，为connect（）、sendto（）或sendmsg（）指定的目标地址是数据报的最终目标地址。然后，路由报头包含所有中间节点的地址。
socklen_t inet6_rth_space(int type, int segments);
socklen_t inet6_rth_空间（int类型，int段）；
This function returns the number of bytes required to hold a Routing header of the specified type containing the specified number of segments (addresses). For an IPv6 Type 0 Routing header, the number of segments must be between 0 and 127, inclusive. The return value is just the space for the Routing header. When the application uses ancillary data it must pass the returned length to CMSG_SPACE() to determine how much memory is needed for the ancillary data object (including the cmsghdr structure).
此函数返回保存包含指定数量段（地址）的指定类型路由标头所需的字节数。对于IPv6类型0路由标头，段数必须介于0和127之间（包括0和127）。返回值只是路由头的空间。当应用程序使用辅助数据时，它必须将返回的长度传递给CMSG_SPACE（），以确定辅助数据对象（包括cmsghdr结构）需要多少内存。
If the return value is 0, then either the type of the Routing header is not supported by this implementation or the number of segments is invalid for this type of Routing header.
如果返回值为0，则此实现不支持路由标头的类型，或者此类型路由标头的段数无效。
(Note: This function returns the size but does not allocate the space required for the ancillary data. This allows an application to allocate a larger buffer, if other ancillary data objects are desired, since all the ancillary data objects must be specified to sendmsg() as a single msg_control buffer.)
（注意：此函数返回大小，但不分配辅助数据所需的空间。如果需要其他辅助数据对象，则允许应用程序分配更大的缓冲区，因为必须将所有辅助数据对象指定给sendmsg（），作为单个msg_控制缓冲区。）
void *inet6_rth_init(void *bp, socklen_t bp_len, int type,
int segments);
void *inet6_rth_init(void *bp, socklen_t bp_len, int type,
int segments);
This function initializes the buffer pointed to by bp to contain a Routing header of the specified type and sets ip6r_len based on the segments parameter. bp_len is only used to verify that the buffer is large enough. The ip6r_segleft field is set to zero; inet6_rth_add() will increment it.
此函数初始化bp指向的缓冲区，以包含指定类型的路由标头，并根据segments参数设置ip6r_len。bp_len仅用于验证缓冲区是否足够大。ip6r_segleft字段设置为零；inet6\u rth\u add（）将使其递增。
When the application uses ancillary data the application must initialize any cmsghdr fields.
当应用程序使用辅助数据时，应用程序必须初始化任何cmsghdr字段。
The caller must allocate the buffer and its size can be determined by calling inet6_rth_space().
调用者必须分配缓冲区，其大小可以通过调用inet6\u rth\u space（）来确定。
Upon success the return value is the pointer to the buffer (bp), and this is then used as the first argument to the inet6_rth_add() function. Upon an error the return value is NULL.
成功后，返回值是指向缓冲区（bp）的指针，然后将其用作inet6_rth_add（）函数的第一个参数。出现错误时，返回值为空。
int inet6_rth_add(void *bp, const struct in6_addr *addr);
int inet6_rth_add(void *bp, const struct in6_addr *addr);
This function adds the IPv6 address pointed to by addr to the end of the Routing header being constructed.
此函数用于将addr指向的IPv6地址添加到正在构造的路由标头的末尾。
If successful, the segleft member of the Routing Header is updated to account for the new address in the Routing header and the return value of the function is 0. Upon an error the return value of the function is -1.
如果成功，将更新路由标头的segleet成员以说明路由标头中的新地址，函数的返回值为0。出现错误时，函数的返回值为-1。
int inet6_rth_reverse(const void *in, void *out);
int inet6_rth_reverse(const void *in, void *out);
This function takes a Routing header extension header (pointed to by the first argument) and writes a new Routing header that sends datagrams along the reverse of that route. The function reverses the order of the addresses and sets the segleft member in the new Routing header to the number of segments. Both arguments are allowed to point to the same buffer (that is, the reversal can occur in place).
此函数接受路由标头扩展标头（由第一个参数指向），并写入一个新的路由标头，该标头沿该路由的相反方向发送数据报。该函数反转地址顺序，并将新路由标头中的segleft成员设置为段数。这两个参数都可以指向同一个缓冲区（也就是说，反转可以就地发生）。
The return value of the function is 0 on success, or -1 upon an error.
函数的返回值在成功时为0，或在错误时为-1。
int inet6_rth_segments(const void *bp);
int inet6_rth_segments(const void *bp);
This function returns the number of segments (addresses) contained in the Routing header described by bp. On success the return value is zero or greater. The return value of the function is -1 upon an error.
此函数返回bp描述的路由标头中包含的段数（地址）。成功时，返回值为零或更大。出现错误时，函数的返回值为-1。
struct in6_addr *inet6_rth_getaddr(const void *bp, int index);
struct in6_addr *inet6_rth_getaddr(const void *bp, int index);
This function returns a pointer to the IPv6 address specified by index (which must have a value between 0 and one less than the value returned by inet6_rth_segments()) in the Routing header described by bp. An application should first call inet6_rth_segments() to obtain the number of segments in the Routing header.
此函数返回一个指针，指向由bp描述的路由标头中的索引指定的IPv6地址（该索引的值必须小于inet6_rth_segments（）返回的值，介于0和1之间）。应用程序应首先调用inet6_rth_segments（），以获取路由标头中的段数。
Upon an error the return value of the function is NULL.
出现错误时，函数的返回值为NULL。
A variable number of Hop-by-Hop options can appear in a single Hop-by-Hop options header. Each option in the header is TLV-encoded with a type, length, and value. This IPv6 API defines seven functions that the application calls to build and examine a Hop-by_Hop options header, and the ability to use sticky options or ancillary data to communicate this information between the application and the kernel. This uses the IPV6_HOPOPTS for a Hop-by-Hop options header.
单个逐跳选项标题中可以显示数量可变的逐跳选项。标头中的每个选项都使用类型、长度和值进行TLV编码。此IPv6 API定义了应用程序调用的七个函数，用于构建和检查逐跳选项标头，以及使用粘性选项或辅助数据在应用程序和内核之间传递此信息的能力。这将IPV6_HOPOPTS用于逐跳选项标头。
Today several Hop-by-Hop options are defined for IPv6. Two pad options, Pad1 and PadN, are for alignment purposes and are automatically inserted by the inet6_opt_XXX() routines and ignored by the inet6_opt_XXX() routines on the receive side. This section of the API is therefore defined for other (and future) Hop-by-Hop options that an application may need to specify and receive.
如今，IPv6定义了几个逐跳选项。两个pad选项Pad1和PadN用于对齐目的，由inet6_opt_XXX（）例程自动插入，并由接收端的inet6_opt_XXX（）例程忽略。因此，API的这一部分是为应用程序可能需要指定和接收的其他（以及将来的）逐跳选项定义的。
Four functions build an options header:
四个功能构建选项标题：
inet6_opt_init() - initialize buffer data for options header
inet6_opt_append() - add one TLV option to the options header
inet6_opt_finish() - finish adding TLV options to the options
header
inet6_opt_set_val() - add one component of the option content to
the option
inet6_opt_init() - initialize buffer data for options header
inet6_opt_append() - add one TLV option to the options header
inet6_opt_finish() - finish adding TLV options to the options
header
inet6_opt_set_val() - add one component of the option content to
the option
Three functions deal with a returned options header:
三个函数处理返回的选项标题：
inet6_opt_next() - extract the next option from the options header inet6_opt_find() - extract an option of a specified type from the header inet6_opt_get_val() - retrieve one component of the option content
inet6_opt_next（）-从选项标题inet6_opt_find（）提取下一个选项-从标题inet6_opt_get_val（）提取指定类型的选项-检索选项内容的一个组件
Individual Hop-by-Hop options (and Destination options, which are described in Section 9 and are very similar to the Hop-by-Hop options) may have specific alignment requirements. For example, the 4-byte Jumbo Payload length should appear on a 4-byte boundary, and IPv6 addresses are normally aligned on an 8-byte boundary. These requirements and the terminology used with these options are discussed in Section 4.2 and Appendix B of [RFC-2460]. The alignment of first byte of each option is specified by two values, called x and y, written as "xn + y". This states that the option must appear at an integer multiple of x bytes from the beginning of the options header (x can have the values 1, 2, 4, or 8), plus y bytes (y can have a value between 0 and 7, inclusive). The Pad1 and PadN options are inserted as needed to maintain the required alignment. The
单个逐跳选项（和目的地选项，如第9节所述，与逐跳选项非常相似）可能具有特定的对齐要求。例如，4字节的巨型有效负载长度应出现在4字节边界上，IPv6地址通常在8字节边界上对齐。[RFC-2460]第4.2节和附录B中讨论了这些要求和与这些选项一起使用的术语。每个选项的第一个字节的对齐方式由两个值指定，称为x和y，写为“xn+y”。这表示该选项必须以x字节的整数倍显示，从选项标题的开头开始（x可以具有值1、2、4或8），再加上y字节（y可以具有介于0和7之间的值，包括0和7）。根据需要插入Pad1和PadN选项，以保持所需的对齐。这个
functions below need to know the alignment of the end of the option (which is always in the form "xn," where x can have the values 1, 2, 4, or 8) and the total size of the data portion of the option. These are passed as the "align" and "len" arguments to inet6_opt_append().
下面的函数需要知道选项末端的对齐方式（始终为“xn”形式，其中x可以有值1、2、4或8）以及选项数据部分的总大小。这些参数作为“align”和“len”参数传递给inet6_opt_append（）。
Multiple Hop-by-Hop options must be specified by the application by placing them in a single extension header.
应用程序必须通过将多个逐跳选项放置在单个扩展标头中来指定它们。
Finally, we note that use of some Hop-by-Hop options or some Destination options, might require special privilege. That is, normal applications (without special privilege) might be forbidden from setting certain options in outgoing packets, and might never see certain options in received packets.
最后，我们注意到使用某些逐跳选项或某些目的地选项可能需要特殊权限。也就是说，普通应用程序（没有特殊权限）可能被禁止在传出数据包中设置某些选项，并且可能永远不会在接收到的数据包中看到某些选项。
To receive a Hop-by-Hop options header the application must enable the IPV6_RECVHOPOPTS socket option:
要接收逐跳选项标头，应用程序必须启用IPV6_Recvhopts套接字选项：
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on));
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on));
When using ancillary data a Hop-by-hop options header is passed between the application and the kernel as follows: The cmsg_level member will be IPPROTO_IPV6 and the cmsg_type member will be IPV6_HOPOPTS. These options are then processed by calling the inet6_opt_next(), inet6_opt_find(), and inet6_opt_get_val() functions, described in Section 10.
使用辅助数据时，会在应用程序和内核之间传递一个逐跳选项标头，如下所示：cmsg_级别的成员将是IPPROTO_IPV6，cmsg_类型的成员将是IPV6_HOPOPTS。然后通过调用第10节中描述的inet6_opt_next（）、inet6_opt_find（）和inet6_opt_get_val（）函数来处理这些选项。
To send a Hop-by-Hop options header, the application specifies the header either as ancillary data in a call to sendmsg() or using setsockopt().
要发送逐跳选项标头，应用程序在调用sendmsg（）或使用setsockopt（）时将标头指定为辅助数据。
The application can remove any sticky Hop-by-Hop options header by calling setsockopt() for IPV6_HOPOPTS with a zero option length.
应用程序可以通过调用选项长度为零的IPV6_HOPOPTS的setsockopt（）来删除任何粘性逐跳选项标头。
All the Hop-by-Hop options must be specified by a single ancillary data object. The cmsg_level member is set to IPPROTO_IPV6 and the cmsg_type member is set to IPV6_HOPOPTS. The option is normally constructed using the inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and inet6_opt_set_val() functions, described in Section 10.
所有逐跳选项必须由单个辅助数据对象指定。cmsg_级别成员设置为IPPROTO_IPV6，cmsg_类型成员设置为IPV6_HOPOPTS。该选项通常使用第10节所述的inet6_opt_init（）、inet6_opt_append（）、inet6_opt_finish（）和inet6_opt_set_val（）函数构造。
Additional errors may be possible from sendmsg() and setsockopt() if the specified option is in error.
如果指定的选项出错，sendmsg（）和setsockopt（）可能会出现其他错误。
A variable number of Destination options can appear in one or more Destination options headers. As defined in [RFC-2460], a Destination options header appearing before a Routing header is processed by the first destination plus any subsequent destinations specified in the Routing header, while a Destination options header that is not followed by a Routing header is processed only by the final destination. As with the Hop-by-Hop options, each option in a Destination options header is TLV-encoded with a type, length, and value.
一个或多个目标选项标题中可以出现数量可变的目标选项。如[RFC-2460]中所定义，在路由报头之前出现的目的地选项报头由第一个目的地加上路由报头中指定的任何后续目的地处理，而不后跟路由报头的目的地选项报头仅由最终目的地处理。与逐跳选项一样，目标选项标头中的每个选项都使用类型、长度和值进行TLV编码。
To receive Destination options header the application must enable the IPV6_RECVDSTOPTS socket option:
要接收目标选项标头，应用程序必须启用IPV6_RECVDSTOPTS套接字选项：
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));
Each Destination options header is returned as one ancillary data object described by a cmsghdr structure with cmsg_level set to IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS.
每个目的地选项报头作为cmsghdr结构描述的一个辅助数据对象返回，cmsg_级别设置为IPPROTO_IPV6，cmsg_类型设置为IPV6_选项。
These options are then processed by calling the inet6_opt_next(), inet6_opt_find(), and inet6_opt_get_value() functions.
然后通过调用inet6_opt_next（）、inet6_opt_find（）和inet6_opt_get_value（）函数来处理这些选项。
To send a Destination options header, the application specifies it either as ancillary data in a call to sendmsg() or using setsockopt().
要发送目标选项标头，应用程序将其指定为对sendmsg（）的调用中的辅助数据或使用setsockopt（）。
The application can remove any sticky Destination options header by calling setsockopt() for IPV6_RTHDRDSTOPTS/IPV6_DSTOPTS with a zero option length.
应用程序可以通过调用选项长度为零的IPV6_RTHDRDSTOPTS/IPV6_DSTOPTS的setsockopt（）来删除任何粘性目标选项标头。
This API assumes the ordering about extension headers as described in [RFC-2460]. Thus, one set of Destination options can only appear before a Routing header, and one set can only appear after a Routing header (or in a packet with no Routing header). Each set can consist of one or more options but each set is a single extension header.
此API假定扩展头的排序如[RFC-2460]中所述。因此，一组目的地选项只能出现在路由报头之前，一组只能出现在路由报头之后（或在没有路由报头的数据包中）。每个集合可以包含一个或多个选项，但每个集合都是一个扩展标题。
Today all destination options that an application may want to specify can be put after (or without) a Routing header. Thus, applications should usually need IPV6_DSTOPTS only and should avoid using IPV6_RTHDRDSTOPTS whenever possible.
现在，应用程序可能希望指定的所有目标选项都可以放在路由头之后（或不放在路由头之后）。因此，应用程序通常只需要IPV6选项，并且应尽可能避免使用IPV6选项。
When using ancillary data a Destination options header is passed between the application and the kernel as follows: The set preceding a Routing header are specified with the cmsg_level member set to IPPROTO_IPV6 and the cmsg_type member set to IPV6_RTHDRDSTOPTS. Any setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently ignored when sending packets unless a Routing header is also specified. Note that the "Routing header" here means the one specified by this API. Even when the kernel inserts a routing header in its internal routine (e.g., in a mobile IPv6 stack), the Destination options header specified by IPV6_RTHDRDSTOPTS will still be ignored unless the application explicitly specifies its own Routing header.
使用辅助数据时，在应用程序和内核之间传递一个目的地选项标头，如下所示：路由标头之前的集合指定为cmsg_级别成员集为IPPROTO_IPV6，cmsg_类型成员集为IPV6_RTHDRDSTOPTS。除非还指定了路由标头，否则在发送数据包时，IPV6_RTHDRDSTOPTS的任何setsockopt或辅助数据都将被静默忽略。请注意，此处的“路由头”是指此API指定的头。即使内核在其内部例程（例如，在移动IPv6堆栈中）中插入路由头，由IPv6_RTHDRDSTOPTS指定的目标选项头仍将被忽略，除非应用程序明确指定其自己的路由头。
The set of Destination options after a Routing header, which are also used when no Routing header is present, are specified with the cmsg_level member is set to IPPROTO_IPV6 and the cmsg_type member is set to IPV6_DSTOPTS.
当cmsg_级别成员设置为IPPROTO_IPV6且cmsg_类型成员设置为ipv6dstopts时，指定路由标头后的目标选项集（也在不存在路由标头时使用）。
The Destination options are normally constructed using the inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and inet6_opt_set_val() functions, described in Section 10.
目标选项通常使用第10节中描述的inet6_opt_init（）、inet6_opt_append（）、inet6_opt_finish（）和inet6_opt_set_val（）函数构造。
Additional errors may be possible from sendmsg() and setsockopt() if the specified option is in error.
如果指定的选项出错，sendmsg（）和setsockopt（）可能会出现其他错误。
Building and parsing the Hop-by-Hop and Destination options is complicated for the reasons given earlier. We therefore define a set of functions to help the application. These functions assume the formatting rules specified in Appendix B in [RFC-2460] i.e., that the largest field is placed last in the option.
由于前面给出的原因，逐跳和目的地选项的构建和解析非常复杂。因此，我们定义了一组函数来帮助应用程序。这些函数采用[RFC-2460]附录B中规定的格式规则，即最大字段位于选项的最后。
The function prototypes for these functions are defined as a result of including <netinet/in.h>.
这些函数的函数原型定义为包含<netinet/in.h>的结果。
The first 3 functions (init, append, and finish) are used both to calculate the needed buffer size for the options, and to actually encode the options once the application has allocated a buffer for the header. In order to only calculate the size the application must pass a NULL extbuf and a zero extlen to those functions.
前3个函数（init、append和finish）用于计算选项所需的缓冲区大小，并在应用程序为标头分配缓冲区后对选项进行实际编码。为了只计算大小，应用程序必须向这些函数传递NULL extbuf和零extlen。
int inet6_opt_init(void *extbuf, socklen_t extlen);
int inet6_opt_init(void *extbuf, socklen_t extlen);
This function returns the number of bytes needed for the empty extension header i.e., without any options. If extbuf is not NULL it also initializes the extension header to have the correct length field. In that case if the extlen value is not a positive (i.e., non-zero) multiple of 8 the function fails and returns -1.
此函数返回空扩展标题所需的字节数，即不带任何选项。如果extbuf不为NULL，它还将初始化扩展标头以具有正确的长度字段。在这种情况下，如果extlen值不是8的正（即非零）倍数，函数将失败并返回-1。
(Note: since the return value on success is based on a "constant" parameter, i.e., the empty extension header, an implementation may return a constant value. However, this specification does not require the value be constant, and leaves it as implementation dependent. The application should not assume a particular constant value as a successful return value of this function.)
（注意：由于成功时的返回值基于“常量”参数，即空扩展标头，实现可能返回常量值。但是，本规范不要求该值为常量，并将其保留为依赖于实现的值。应用程序不应假定某个特定常量值为此函数的成功返回值。）
int inet6_opt_append(void *extbuf, socklen_t extlen, int offset,
uint8_t type, socklen_t len, uint_t align,
void **databufp);
int inet6_opt_append(void *extbuf, socklen_t extlen, int offset,
uint8_t type, socklen_t len, uint_t align,
void **databufp);
Offset should be the length returned by inet6_opt_init() or a previous inet6_opt_append(). This function returns the updated total length taking into account adding an option with length 'len' and alignment 'align'. If extbuf is not NULL then, in addition to returning the length, the function inserts any needed pad option, initializes the option (setting the type and length fields) and returns a pointer to the location for the option content in databufp. If the option does not fit in the extension header buffer the function returns -1.
偏移量应该是inet6_opt_init（）或以前的inet6_opt_append（）返回的长度。此函数返回更新后的总长度，并考虑添加长度为“len”和对齐方式为“align”的选项。如果extbuf不为NULL，那么除了返回长度外，该函数还插入任何所需的pad选项，初始化该选项（设置类型和长度字段），并返回指向databufp中选项内容位置的指针。如果该选项不适合扩展标头缓冲区，则函数返回-1。
Type is the 8-bit option type. Len is the length of the option data (i.e., excluding the option type and option length fields).
类型是8位选项类型。Len是选项数据的长度（即，不包括选项类型和选项长度字段）。
Once inet6_opt_append() has been called the application can use the databuf directly, or use inet6_opt_set_val() to specify the content of the option.
调用inet6_opt_append（）后，应用程序可以直接使用databuf，或者使用inet6_opt_set_val（）指定选项的内容。
The option type must have a value from 2 to 255, inclusive. (0 and 1 are reserved for the Pad1 and PadN options, respectively.)
选项类型的值必须介于2和255之间（含2和255）。（0和1分别为Pad1和PadN选项保留。）
The option data length must have a value between 0 and 255, inclusive, and is the length of the option data that follows.
选项数据长度的值必须介于0和255（含0和255）之间，并且是后面选项数据的长度。
The align parameter must have a value of 1, 2, 4, or 8. The align value can not exceed the value of len.
“对齐”参数的值必须为1、2、4或8。对齐值不能超过len的值。
int inet6_opt_finish(void *extbuf, socklen_t extlen, int offset);
int inet6_opt_finish(void *extbuf, socklen_t extlen, int offset);
Offset should be the length returned by inet6_opt_init() or inet6_opt_append(). This function returns the updated total length taking into account the final padding of the extension header to make it a multiple of 8 bytes. If extbuf is not NULL the function also initializes the option by inserting a Pad1 or PadN option of the proper length.
偏移量应为inet6_opt_init（）或inet6_opt_append（）返回的长度。此函数返回更新后的总长度，并考虑扩展标头的最终填充，使其为8字节的倍数。如果extbuf不为NULL，该函数还通过插入适当长度的Pad1或PadN选项来初始化该选项。
If the necessary pad does not fit in the extension header buffer the function returns -1.
如果扩展标头缓冲区中不适合必要的填充，则函数返回-1。
int inet6_opt_set_val(void *databuf, int offset, void *val,
socklen_t vallen);
int inet6_opt_set_val(void *databuf, int offset, void *val,
socklen_t vallen);
Databuf should be a pointer returned by inet6_opt_append(). This function inserts data items of various sizes in the data portion of the option. Val should point to the data to be inserted. Offset specifies where in the data portion of the option the value should be inserted; the first byte after the option type and length is accessed by specifying an offset of zero.
Databuf应该是inet6_opt_append（）返回的指针。此函数用于在选项的数据部分插入各种大小的数据项。Val应指向要插入的数据。偏移量指定在选项的数据部分插入值的位置；通过指定零偏移量访问选项类型和长度后的第一个字节。
The caller should ensure that each field is aligned on its natural boundaries as described in Appendix B of [RFC-2460], but the function must not rely on the caller's behavior. Even when the alignment requirement is not satisfied, inet6_opt_set_val should just copy the data as required.
调用者应确保每个字段在其自然边界上对齐，如[RFC-2460]附录B所述，但函数不得依赖调用者的行为。即使不满足对齐要求，inet6_opt_set_val也应根据需要复制数据。
The function returns the offset for the next field (i.e., offset + vallen) which can be used when composing option content with multiple fields.
该函数返回下一个字段的偏移量（即，偏移量+值），在用多个字段组成选项内容时可以使用该字段。
int inet6_opt_next(void *extbuf, socklen_t extlen, int offset,
uint8_t *typep, socklen_t *lenp,
void **databufp);
int inet6_opt_next(void *extbuf, socklen_t extlen, int offset,
uint8_t *typep, socklen_t *lenp,
void **databufp);
This function parses received option extension headers returning the next option. Extbuf and extlen specifies the extension header. Offset should either be zero (for the first option) or the length returned by a previous call to inet6_opt_next() or inet6_opt_find(). It specifies the position where to continue scanning the extension buffer. The next option is returned by updating typep, lenp, and
此函数解析接收到的返回下一个选项的选项扩展标题。Extbuf和extlen指定扩展标头。偏移量应为零（对于第一个选项）或上一次调用inet6_opt_next（）或inet6_opt_find（）返回的长度。它指定继续扫描扩展缓冲区的位置。下一个选项是通过更新typep、lenp和
databufp. Typep stores the option type, lenp stores the length of the option data (i.e., excluding the option type and option length fields), and databufp points the data field of the option. This function returns the updated "previous" length computed by advancing past the option that was returned. This returned "previous" length can then be passed to subsequent calls to inet6_opt_next(). This function does not return any PAD1 or PADN options. When there are no more options or if the option extension header is malformed the return value is -1.
数据缓冲。Typep存储选项类型，lenp存储选项数据的长度（即，不包括选项类型和选项长度字段），DataBuff指向选项的数据字段。此函数返回更新后的“previous”长度，该长度是通过前进超过返回的选项计算得出的。然后可以将返回的“previous”长度传递给对inet6_opt_next（）的后续调用。此函数不返回任何PAD1或PADN选项。当没有更多选项或选项扩展标题格式不正确时，返回值为-1。
int inet6_opt_find(void *extbuf, socklen_t extlen, int offset,
uint8_t type, socklen_t *lenp,
void **databufp);
int inet6_opt_find(void *extbuf, socklen_t extlen, int offset,
uint8_t type, socklen_t *lenp,
void **databufp);
This function is similar to the previously described inet6_opt_next() function, except this function lets the caller specify the option type to be searched for, instead of always returning the next option in the extension header.
此函数类似于前面描述的inet6_opt_next（）函数，只是此函数允许调用方指定要搜索的选项类型，而不是总是在扩展标题中返回下一个选项。
If an option of the specified type is located, the function returns the updated "previous" total length computed by advancing past the option that was returned and past any options that didn't match the type. This returned "previous" length can then be passed to subsequent calls to inet6_opt_find() for finding the next occurrence of the same option type.
如果找到指定类型的选项，则函数将返回更新后的“previous”总长度，该总长度是通过超出返回的选项和与该类型不匹配的任何选项计算得出的。然后可以将返回的“previous”长度传递给对inet6_opt_find（）的后续调用，以查找同一选项类型的下一个匹配项。
If an option of the specified type is not located, the return value is -1. If the option extension header is malformed, the return value is -1.
如果未找到指定类型的选项，则返回值为-1。如果选项扩展标题格式不正确，则返回值为-1。
int inet6_opt_get_val(void *databuf, int offset, void *val,
socklen_t vallen);
int inet6_opt_get_val(void *databuf, int offset, void *val,
socklen_t vallen);
Databuf should be a pointer returned by inet6_opt_next() or inet6_opt_find(). This function extracts data items of various sizes in the data portion of the option. Val should point to the destination for the extracted data. Offset specifies from where in the data portion of the option the value should be extracted; the first byte after the option type and length is accessed by specifying an offset of zero.
Databuf应该是inet6_opt_next（）或inet6_opt_find（）返回的指针。此函数用于提取选项数据部分中各种大小的数据项。Val应指向提取数据的目标。偏移量指定从选项的数据部分中提取值的位置；通过指定零偏移量访问选项类型和长度后的第一个字节。
It is expected that each field is aligned on its natural boundaries as described in Appendix B of [RFC-2460], but the function must not rely on the alignment.
按照[RFC-2460]附录B中的描述，预计每个油田都会在其自然边界上对齐，但功能不得依赖对齐。
The function returns the offset for the next field (i.e., offset + vallen) which can be used when extracting option content with multiple fields.
该函数返回下一个字段的偏移量（即偏移量+值），可在提取多个字段的选项内容时使用。
Unicast applications should usually let the kernel perform path MTU discovery [RFC-1981], as long as the kernel supports it, and should not care about the path MTU. Some applications, however, might not want to incur the overhead of path MTU discovery, especially if the applications only send a single datagram to a destination. A potential example is a DNS server.
单播应用程序通常应该让内核执行路径MTU发现[RFC-1981]，只要内核支持它，并且不应该关心路径MTU。但是，有些应用程序可能不希望产生路径MTU发现的开销，特别是当应用程序只向目标发送单个数据报时。一个潜在的例子是DNS服务器。
[RFC-1981] describes how path MTU discovery works for multicast destinations. From practice in using IPv4 multicast, however, many careless applications that send large multicast packets on the wire have caused implosion of ICMPv4 error messages. The situation can be worse when there is a filtering node that blocks the ICMPv4 messages. Though the filtering issue applies to unicast as well, the impact is much larger in the multicast cases.
[RFC-1981]描述了路径MTU发现如何为多播目的地工作。然而，从使用IPv4多播的实践来看，许多粗心的应用程序在线路上发送大型多播数据包，导致ICMPv4错误消息内爆。当存在阻止ICMPv4消息的筛选节点时，情况可能更糟。虽然过滤问题也适用于单播，但在多播情况下影响要大得多。
Thus, applications sending multicast traffic should explicitly enable path MTU discovery only when they understand that the benefit of possibly larger MTU usage outweighs the possible impact of MTU discovery for active sources across the delivery tree(s). This default behavior is based on the today's practice with IPv4 multicast and path MTU discovery. The behavior may change in the future once it is found that path MTU discovery effectively works with actual multicast applications and network configurations.
因此，只有当发送多播通信量的应用程序了解到可能更大的MTU使用的好处超过了MTU发现对传递树上的活动源可能产生的影响时，才应该显式启用路径MTU发现。此默认行为基于当前IPv4多播和路径MTU发现的实践。一旦发现路径MTU发现能够有效地与实际的多播应用程序和网络配置配合使用，这种行为在将来可能会发生变化。
This specification defines a mechanism to avoid path MTU discovery by sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger than the minimum MTU and this feature has been enabled the IP layer will fragment to the minimum MTU. To control the policy about path MTU discovery, applications can use the IPV6_USE_MIN_MTU socket option.
本规范定义了一种通过以最小IPv6 MTU[RFC-2460]发送来避免路径MTU发现的机制。如果数据包大于最小MTU且此功能已启用，则IP层将分段为最小MTU。要控制有关路径MTU发现的策略，应用程序可以使用IPV6\u use\u MIN\u MTU套接字选项。
As described above, the default policy should depend on whether the destination is unicast or multicast. For unicast destinations path MTU discovery should be performed by default. For multicast destinations path MTU discovery should be disabled by default. This option thus takes the following three types of integer arguments:
如上所述，默认策略应取决于目标是单播还是多播。对于单播目的地，默认情况下应执行路径MTU发现。对于多播目标，默认情况下应禁用路径MTU发现。因此，此选项采用以下三种类型的整数参数：
-1: perform path MTU discovery for unicast destinations but do not perform it for multicast destinations. Packets to multicast destinations are therefore sent with the minimum MTU.
-1：对单播目的地执行路径MTU发现，但不对多播目的地执行路径MTU发现。因此，发送到多播目的地的数据包使用最小MTU。
0: always perform path MTU discovery.
0:始终执行路径MTU发现。
1: always disable path MTU discovery and send packets at the minimum MTU.
1：始终禁用路径MTU发现，并以最小MTU发送数据包。
The default value of this option is -1. Values other than -1, 0, and 1 are invalid, and an error EINVAL will be returned for those values.
此选项的默认值为-1。除-1、0和1以外的值无效，将为这些值返回错误EINVAL。
As an example, if a unicast application intentionally wants to disable path MTU discovery, it will add the following lines:
例如，如果单播应用程序有意禁用路径MTU发现，它将添加以下行：
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on));
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on));
Note that this API intentionally excludes the case where the application wants to perform path MTU discovery for multicast but to disable it for unicast. This is because such usage is not feasible considering a scale of performance issues around whether to do path MTU discovery or not. When path MTU discovery makes sense to a destination but not to a different destination, regardless of whether the destination is unicast or multicast, applications either need to toggle the option between sending such packets on the same socket, or use different sockets for the two classes of destinations.
请注意，此API有意排除应用程序希望对多播执行路径MTU发现，但对单播禁用路径MTU发现的情况。这是因为考虑到围绕是否进行路径MTU发现的一系列性能问题，这种使用是不可行的。当路径MTU发现对一个目的地有意义，但对另一个目的地没有意义时，无论目的地是单播还是多播，应用程序都需要在同一套接字上发送此类数据包之间切换选项，或者对两类目的地使用不同的套接字。
This option can also be sent as ancillary data. In the cmsghdr structure containing this ancillary data, the cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be IPV6_USE_MIN_MTU, and the first byte of cmsg_data[] will be the first byte of the integer.
此选项也可以作为辅助数据发送。在包含此辅助数据的cmsghdr结构中，cmsg_级成员将是IPPROTO_IPV6，cmsg_类型成员将是IPV6_USE_MIN_MTU，cmsg_data[]的第一个字节将是整数的第一个字节。
In order to provide for easy porting of existing UDP and raw socket applications IPv6 implementations will, when originating packets, automatically insert a fragment header in the packet if the packet is too big for the path MTU.
为了方便移植现有UDP和原始套接字应用程序，IPv6实现将在发起数据包时，如果数据包对于路径MTU来说太大，则会自动在数据包中插入一个片段头。
Some applications might not want this behavior. An example is traceroute which might want to discover the actual path MTU.
某些应用程序可能不希望出现这种行为。traceroute就是一个例子，它可能希望发现MTU的实际路径。
This specification defines a mechanism to turn off the automatic inserting of a fragment header for UDP and raw sockets. This can be enabled using the IPV6_DONTFRAG socket option.
该规范定义了一种机制，用于关闭UDP和原始套接字片段头的自动插入。这可以使用IPV6\u DONTFRAG套接字选项启用。
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(on));
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(on));
By default, this socket option is disabled. Setting the value to 0 also disables the option i.e., reverts to the default behavior of automatic inserting. This option can also be sent as ancillary data. In the cmsghdr structure containing this ancillary data, the cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be IPV6_DONTFRAG, and the first byte of cmsg_data[] will be the first byte of the integer. This API only specifies the use of this option for UDP and raw sockets, and does not define the usage for TCP sockets.
默认情况下，此套接字选项处于禁用状态。将该值设置为0也会禁用该选项，即恢复为自动插入的默认行为。此选项也可以作为辅助数据发送。在包含此辅助数据的cmsghdr结构中，cmsg_级别成员将是IPPROTO_IPV6，cmsg_类型成员将是IPV6_DONTFRAG，cmsg_data[]的第一个字节将是整数的第一个字节。此API仅指定UDP和原始套接字使用此选项，而不定义TCP套接字的用法。
When the data size is larger than the MTU of the outgoing interface, the packet will be discarded. Applications can know the result by enabling the IPV6_RECVPATHMTU option described below and receiving the corresponding ancillary data items. An additional error EMSGSIZE may also be returned in some implementations. Note, however, that some other implementations might not be able to return this additional error when sending a message.
当数据大小大于传出接口的MTU时，数据包将被丢弃。应用程序可以通过启用下面描述的IPV6_RECVPATHMTU选项并接收相应的辅助数据项来了解结果。在某些实现中还可能返回额外的错误EMSGSIZE。但是，请注意，某些其他实现在发送消息时可能无法返回此附加错误。
UDP and raw socket applications need to be able to determine the "maximum send transport-message size" (Section 5.1 of [RFC-1981]) to a given destination so that those applications can participate in path MTU discovery. This lets those applications send smaller datagrams to the destination, avoiding fragmentation.
UDP和原始套接字应用程序需要能够确定到给定目的地的“最大发送传输消息大小”（RFC-1981第5.1节），以便这些应用程序能够参与路径MTU发现。这使得这些应用程序可以向目标发送较小的数据报，从而避免碎片。
This is accomplished using a new ancillary data item (IPV6_PATHMTU) which is delivered to recvmsg() without any actual data. The application can enable the receipt of IPV6_PATHMTU ancillary data items by setting the IPV6_RECVPATHMTU socket option.
这是通过使用一个新的辅助数据项（IPV6_PATHMTU）实现的，该数据项在没有任何实际数据的情况下交付给recvmsg（）。应用程序可以通过设置IPV6_RECVPATHMTU套接字选项来启用IPV6_PATHMTU辅助数据项的接收。
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPATHMTU, &on, sizeof(on));
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPATHMTU, &on, sizeof(on));
By default, this socket option is disabled. Setting the value to 0 also disables the option. This API only specifies the use of this option for UDP and raw sockets, and does not define the usage for TCP sockets.
默认情况下，此套接字选项处于禁用状态。将该值设置为0也会禁用该选项。此API仅指定UDP和原始套接字使用此选项，而不定义TCP套接字的用法。
When the application is sending packets too big for the path MTU recvmsg() will return zero (indicating no data) but there will be a cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will indicate that cmsg_data is sizeof(struct ip6_mtuinfo) bytes long. This can happen when the sending node receives a corresponding ICMPv6 packet too big error, or when the packet is sent from a socket with the IPV6_DONTFRAG option being on and the packet size is larger than the MTU of the outgoing interface. This indication is considered as an ancillary data item for a separate (empty) message. Thus, when
当应用程序发送路径太大的数据包时，MTU recvmsg（）将返回零（表示没有数据），但将有一个cmsghdr，cmsg_类型设置为IPV6_PATHMTU，cmsg_len将指示cmsg_数据的大小为（struct ip6_mtuinfo）字节长。当发送节点接收到相应的ICMPv6数据包太大错误时，或者当数据包从启用IPV6_DONTFRAG选项的套接字发送且数据包大小大于传出接口的MTU时，可能会发生这种情况。此指示被视为单独（空）消息的辅助数据项。因此，当
there are buffered messages (i.e., messages that the application has not received yet) on the socket the application will first receive the buffered messages and then receive the indication.
套接字上有缓冲消息（即应用程序尚未接收到的消息），应用程序将首先接收缓冲消息，然后接收指示。
The first byte of cmsg_data[] will point to a struct ip6_mtuinfo carrying the path MTU to use together with the IPv6 destination address.
cmsg_data[]的第一个字节将指向一个结构ip6_mtuinfo，其中包含要与IPv6目标地址一起使用的路径MTU。
struct ip6_mtuinfo {
struct sockaddr_in6 ip6m_addr; /* dst address including
zone ID */
uint32_t ip6m_mtu; /* path MTU in host byte order */
};
struct ip6_mtuinfo {
struct sockaddr_in6 ip6m_addr; /* dst address including
zone ID */
uint32_t ip6m_mtu; /* path MTU in host byte order */
};
This cmsghdr will be passed to every socket that sets the IPV6_RECVPATHMTU socket option, even if the socket is non-connected. Note that this also means an application that sets the option may receive an IPV6_MTU ancillary data item for each ICMP too big error the node receives, including such ICMP errors caused by other applications on the node. Thus, an application that wants to perform the path MTU discovery by itself needs to keep history of destinations that it has actually sent to and to compare the address returned in the ip6_mtuinfo structure to the history. An implementation may choose not to delivery data to a connected socket that has a foreign address that is different than the address specified in the ip6m_addr structure.
此cmsghdr将传递给设置IPV6_RECVPATHMTU套接字选项的每个套接字，即使该套接字未连接。请注意，这也意味着设置该选项的应用程序可能会针对节点接收到的每个ICMP过大错误接收IPV6_MTU辅助数据项，包括由节点上的其他应用程序引起的此类ICMP错误。因此，希望自己执行路径MTU发现的应用程序需要保留其实际发送到的目的地的历史记录，并将IP6MTUINFO结构中返回的地址与历史记录进行比较。实现可以选择不将数据传递到具有不同于ip6m_addr结构中指定地址的外部地址的连接套接字。
When an application sends a packet with a routing header, the final destination stored in the ip6m_addr member does not necessarily contain complete information of the entire path.
当应用程序发送带有路由头的数据包时，存储在ip6m_addr成员中的最终目的地不一定包含整个路径的完整信息。
Some applications might need to determine the current path MTU e.g., applications using IPV6_RECVPATHMTU might want to pick a good starting value.
某些应用程序可能需要确定当前路径MTU，例如，使用IPV6的应用程序可能希望选择一个好的起始值。
This specification defines a get-only socket option to retrieve the current path MTU value for the destination of a given connected socket. If the IP layer does not have a cached path MTU value it will return the interface MTU for the interface that will be used when sending to the destination address.
此规范定义了一个仅获取套接字选项，用于检索给定连接套接字的目标的当前路径MTU值。如果IP层没有缓存路径MTU值，它将返回发送到目标地址时将使用的接口的接口MTU。
This information is retrieved using the IPV6_PATHMTU socket option. This option takes a pointer to the ip6_mtuinfo structure as the fourth argument, and the size of the structure should be passed as a value-result parameter in the fifth argument.
使用IPV6_PATHMTU套接字选项检索此信息。此选项将指向ip6_mtuinfo结构的指针作为第四个参数，结构的大小应作为第五个参数中的值结果参数传递。
struct ip6_mtuinfo mtuinfo;
socklen_t infolen = sizeof(mtuinfo);
struct ip6_mtuinfo mtuinfo;
socklen_t infolen = sizeof(mtuinfo);
getsockopt(fd, IPPROTO_IPV6, IPV6_PATHMTU, &mtuinfo, &infolen);
getsockopt（fd、IPPROTO\u IPV6、IPV6\u路径、mtuinfo和infolen）；
When the call succeeds, the path MTU value is stored in the ip6m_mtu member of the ip6_mtuinfo structure. Since the socket is connected, the ip6m_addr member is meaningless and should not be referred to by the application.
调用成功时，路径MTU值存储在ip6_mtuinfo结构的ip6m_MTU成员中。由于套接字已连接，因此ip6m_addr成员没有意义，应用程序不应引用它。
This option can only be used for a connected socket, because a non-connected socket does not have the information of the destination and there is no way to pass the destination via getsockopt(). When getsockopt() for this option is issued on a non-connected socket, the call will fail. Despite this limitation, this option is still useful from a practical point of view, because applications that care about the path MTU tend to send a lot of packets to a single destination and to connect the socket to the destination for performance reasons. If the application needs to get the MTU value in a more generic way, it should use a more generic interface, such as routing sockets [TCPIPILLUST].
此选项只能用于已连接的套接字，因为未连接的套接字没有目标的信息，并且无法通过getsockopt（）传递目标。在未连接的套接字上发出此选项的getsockopt（）时，调用将失败。尽管存在此限制，但从实际角度来看，此选项仍然有用，因为关心路径MTU的应用程序往往会向单个目的地发送大量数据包，并出于性能原因将套接字连接到目的地。如果应用程序需要以更通用的方式获取MTU值，则应使用更通用的接口，如路由套接字[TCPIPILLUST]。
Three IPv6 extension headers can be specified by the application and returned to the application using ancillary data with sendmsg() and recvmsg(): the Routing header, Hop-by-Hop options header, and Destination options header. When multiple ancillary data objects are transferred via recvmsg() and these objects represent any of these three extension headers, their placement in the control buffer is directly tied to their location in the corresponding IPv6 datagram. For example, when the application has enabled the IPV6_RECVRTHDR and IPV6_RECVDSTOPTS options and later receives an IPv6 packet with extension headers in the following order:
应用程序可以指定三个IPv6扩展头，并使用sendmsg（）和recvmsg（）的辅助数据将其返回给应用程序：路由头、逐跳选项头和目标选项头。当多个辅助数据对象通过recvmsg（）传输，并且这些对象表示这三个扩展头中的任何一个时，它们在控制缓冲区中的位置将直接绑定到它们在相应IPv6数据报中的位置。例如，当应用程序已启用IPV6_RECVRTHDR和IPV6_RECVDSTOPTS选项，并随后按以下顺序接收带有扩展标头的IPV6数据包时：
The IPv6 header A Hop-by-Hop options header A Destination options header (1) A Routing header An Authentication header A Destination options header (2) A UDP header and UDP data
IPv6标头逐跳选项标头目标选项标头（1）路由标头身份验证标头目标选项标头（2）UDP标头和UDP数据
then the application will receive three ancillary data objects in the following order:
然后，应用程序将按以下顺序接收三个辅助数据对象：
an object with cmsg_type set to IPV6_DSTOPTS, which represents the destination options header (1) an object with cmsg_type set to IPV6_RTHDR, which represents the Routing header an object with cmsg_type set to IPV6_DSTOPTS, which represents the destination options header (2)
cmsg_类型设置为IPV6_DSTOPTS的对象，表示目标选项标头（1）cmsg_类型设置为IPV6_RTHDR的对象，表示路由标头cmsg_类型设置为IPV6_DSTOPTS的对象，表示目标选项标头（2）
This example follows the header ordering described in [RFC-2460], but the receiving side of this specification does not assume the ordering. Applications may receive any numbers of objects in any order according to the ordering of the received IPv6 datagram.
本例遵循[RFC-2460]中所述的报头顺序，但本规范的接收端不承担该顺序。根据接收到的IPv6数据报的顺序，应用程序可以以任何顺序接收任意数量的对象。
For the sending side, however, this API imposes some ordering constraints according to [RFC-2460]. Applications using this API cannot make a packet with extension headers that do not follow the ordering. Note, however, that this does not mean applications must always follow the restriction. This is just a limitation in this API in order to give application programmers a guideline to construct headers in a practical manner. Should an application need to make an outgoing packet in an arbitrary order about the extension headers, some other technique, such as the datalink interfaces BPF or DLPI, must be used.
然而，对于发送端，该API根据[RFC-2460]施加了一些排序约束。使用此API的应用程序无法生成具有不遵循顺序的扩展头的数据包。但是，请注意，这并不意味着应用程序必须始终遵循该限制。这只是此API中的一个限制，目的是为应用程序程序员提供一个以实际方式构造头的指南。如果应用程序需要按照扩展头的任意顺序生成传出数据包，则必须使用其他一些技术，例如数据链路接口BPF或DLPI。
The followings are more details about the constraints:
以下是有关约束的更多详细信息：
- Each IPV6_xxx ancillary data object for a particular type of extension header can be specified at most once in a single control buffer.
- 特定类型扩展头的每个IPV6_xxx辅助数据对象最多只能在单个控制缓冲区中指定一次。
- IPV6_xxx ancillary data objects can appear in any order in a control buffer, because there is no ambiguity of the ordering.
- IPV6_xxx辅助数据对象可以以任何顺序出现在控制缓冲区中，因为顺序不存在歧义。
- Each set of IPV6_xxx ancillary data objects and sticky options will be put in the outgoing packet along with the header ordering described in [RFC-2460].
- 每组IPV6_xxx辅助数据对象和粘性选项将与[RFC-2460]中所述的报头顺序一起放入传出数据包中。
- An ancillary data object or a sticky option of IPV6_RTHDRDSTOPTS will affect the outgoing packet only when a Routing header is specified as an ancillary data object or a sticky option. Otherwise, the specified value for IPV6_RTHDRDSTOPTS will be ignored.
- 只有当路由头被指定为辅助数据对象或粘性选项时，IPV6的辅助数据对象或粘性选项才会影响传出数据包。否则，将忽略IPV6_RTHDRDSTOPTS的指定值。
For example, when an application sends a UDP datagram with a control data buffer containing ancillary data objects in the following order:
例如，当应用程序发送UDP数据报时，控制数据缓冲区包含以下顺序的辅助数据对象：
an object with cmsg_type set to IPV6_DSTOPTS an object with cmsg_type set to IPV6_RTHDRDSTOPTS an object with cmsg_type set to IPV6_HOPOPTS
cmsg_类型设置为IPV6_的对象选择cmsg_类型设置为IPV6_RthDrd的对象选择cmsg_类型设置为IPV6_的对象
and the sending socket does not have any sticky options, then the outgoing packet would be constructed as follows:
并且发送套接字没有任何粘性选项，那么传出包的构造如下：
The IPv6 header A Hop-by-Hop options header A Destination options header A UDP header and UDP data
IPv6标头逐跳选项标头目标选项标头UDP标头和UDP数据
where the destination options header corresponds to the ancillary data object with the type IPV6_DSTOPTS.
其中，目标选项标头对应于IPv6DStopts类型的辅助数据对象。
Note that the constraints above do not necessarily mean that the outgoing packet sent on the wire always follows the header ordering specified in this API document. The kernel may insert additional headers that break the ordering as a result. For example, if the kernel supports Mobile IPv6, an additional destination options header may be inserted before an authentication header, even without a routing header.
请注意，上述约束并不一定意味着在线路上发送的传出数据包始终遵循本API文档中指定的报头顺序。内核可能会插入额外的头，从而破坏排序。例如，如果内核支持移动IPv6，则可以在身份验证头之前插入附加的目的地选项头，即使没有路由头。
This API does not provide access to any other extension headers than the supported three types of headers. In particular, no information is provided about the IP security headers on an incoming packet, nor can be specified for an outgoing packet. This API is for applications that do not care about the existence of IP security headers.
除了支持的三种类型的头之外，此API不提供对任何其他扩展头的访问。特别是，没有提供关于传入数据包上的IP安全头的信息，也不能为传出数据包指定信息。此API适用于不关心IP安全头是否存在的应用程序。
The various socket options and ancillary data specifications defined in this document apply only to true IPv6 sockets. It is possible to create an IPv6 socket that actually sends and receives IPv4 packets, using IPv4-mapped IPv6 addresses, but the mapping of the options defined in this document to an IPv4 datagram is beyond the scope of this document.
本文档中定义的各种套接字选项和辅助数据规范仅适用于真正的IPv6套接字。可以使用IPv4映射的IPv6地址创建实际发送和接收IPv4数据包的IPv6套接字，但本文档中定义的选项到IPv4数据报的映射超出了本文档的范围。
In general, attempting to specify an IPv6-only option, such as the Hop-by-Hop options, Destination options, or Routing header on an IPv6 socket that is using IPv4-mapped IPv6 addresses, will probably result in an error. Some implementations, however, may provide access to
通常，尝试在使用IPv4映射IPv6地址的IPv6套接字上指定仅限IPv6的选项（例如逐跳选项、目标选项或路由标头）可能会导致错误。但是，某些实现可能提供对
the packet information (source/destination address, send/receive interface, and hop limit) on an IPv6 socket that is using IPv4-mapped IPv6 addresses.
使用IPv4映射IPv6地址的IPv6套接字上的数据包信息（源/目标地址、发送/接收接口和跃点限制）。
Library functions that support the "r" commands hide the creation of a socket and the name resolution procedure from an application. When the libraries return an AF_INET6 socket to an application that do not support the address family, the application may encounter an unexpected result when, e.g., calling getpeername() for the socket. In order to support AF_INET6 sockets for the "r" commands while keeping backward compatibility, this section defines some extensions to the libraries.
支持“r”命令的库函数对应用程序隐藏套接字的创建和名称解析过程。当库向不支持地址族的应用程序返回AF_INET6套接字时，应用程序可能会在调用套接字的getpeername（）时遇到意外结果。为了支持“r”命令的AF_INET6套接字，同时保持向后兼容性，本节定义了对库的一些扩展。
The rresvport() function is used by the rcmd() function, and this function is in turn called by many of the "r" commands such as rlogin. While new applications are not being written to use the rcmd() function, legacy applications such as rlogin will continue to use it and these will be ported to IPv6.
rcmd（）函数使用rresvport（）函数，许多“r”命令（如rlogin）依次调用该函数。虽然新的应用程序没有编写为使用rcmd（）函数，但传统应用程序（如rlogin）将继续使用它，并将这些应用程序移植到IPv6。
rresvport() creates an IPv4/TCP socket and binds a "reserved port" to the socket. Instead of defining an IPv6 version of this function we define a new function that takes an address family as its argument.
rresvport（）创建IPv4/TCP套接字并将“保留端口”绑定到该套接字。我们没有定义此函数的IPv6版本，而是定义了一个新函数，该函数将地址族作为其参数。
#include <unistd.h>
#include <unistd.h>
int rresvport_af(int *port, int family);
int rresvport_af(int *port, int family);
This function behaves the same as the existing rresvport() function, but instead of creating an AF_INET TCP socket, it can also create an AF_INET6 TCP socket. The family argument is either AF_INET or AF_INET6, and a new error return is EAFNOSUPPORT if the address family is not supported.
此函数的行为与现有的rresvport（）函数相同，但它不创建AF_INET TCP套接字，还可以创建AF_INET6 TCP套接字。family参数为AF_INET或AF_INET6，如果不支持地址族，则新的错误返回为EAFNOSUPPORT。
(Note: There is little consensus on which header defines the rresvport() and rcmd() function prototypes. 4.4BSD defines it in <unistd.h>, others in <netdb.h>, and others don't define the function prototypes at all.)
（注意：对于哪个头定义了rresvport（）和rcmd（）函数原型，几乎没有共识。4.4BSD在<unistd.h>中定义了它，其他头在<netdb.h>中定义了它，而其他头根本不定义函数原型。）
The existing rcmd() function can not transparently use AF_INET6 sockets since an application would not be prepared to handle AF_INET6 addresses returned by e.g., getpeername() on the file descriptor created by rcmd(). Thus a new function is needed.
现有的rcmd（）函数无法透明地使用AF_INET6套接字，因为应用程序不准备处理由rcmd（）创建的文件描述符上的getpeername（）返回的AF_INET6地址。因此，需要一种新的功能。
int rcmd_af(char **ahost, unsigned short rport,
const char *locuser, const char *remuser,
const char *cmd, int *fd2p, int af)
int rcmd_af(char **ahost, unsigned short rport,
const char *locuser, const char *remuser,
const char *cmd, int *fd2p, int af)
This function behaves the same as the existing rcmd() function, but instead of creating an AF_INET TCP socket, it can also create an AF_INET6 TCP socket. The family argument is AF_INET, AF_INET6, or AF_UNSPEC. When either AF_INET or AF_INET6 is specified, this function will create a socket of the specified address family. When AF_UNSPEC is specified, it will try all possible address families until a connection can be established, and will return the associated socket of the connection. A new error EAFNOSUPPORT will be returned if the address family is not supported.
此函数的行为与现有的rcmd（）函数相同，但它不创建AF_INET TCP套接字，还可以创建AF_INET6 TCP套接字。族参数是AF_INET、AF_INET6或AF_unsec。指定AF_INET或AF_INET6时，此函数将创建指定地址族的套接字。当指定AF_unsec时，它将尝试所有可能的地址族，直到可以建立连接，并将返回连接的关联套接字。如果不支持地址族，将返回新错误EAFNOSUPPORT。
The existing rexec() function can not transparently use AF_INET6 sockets since an application would not be prepared to handle AF_INET6 addresses returned by e.g., getpeername() on the file descriptor created by rexec(). Thus a new function is needed.
现有的rexec（）函数无法透明地使用AF_INET6套接字，因为应用程序不准备处理由rexec（）创建的文件描述符上的getpeername（）返回的AF_INET6地址。因此，需要一种新的功能。
int rexec_af(char **ahost, unsigned short rport, const char *name,
const char *pass, const char *cmd, int *fd2p, int af)
int rexec_af(char **ahost, unsigned short rport, const char *name,
const char *pass, const char *cmd, int *fd2p, int af)
This function behaves the same as the existing rexec() function, but instead of creating an AF_INET TCP socket, it can also create an AF_INET6 TCP socket. The family argument is AF_INET, AF_INET6, or AF_UNSPEC. When either AF_INET or AF_INET6 is specified, this function will create a socket of the specified address family. When AF_UNSPEC is specified, it will try all possible address families until a connection can be established, and will return the associated socket of the connection. A new error EAFNOSUPPORT will be returned if the address family is not supported.
此函数的行为与现有的rexec（）函数相同，但它不创建AF_INET TCP套接字，还可以创建AF_INET6 TCP套接字。族参数是AF_INET、AF_INET6或AF_unsec。指定AF_INET或AF_INET6时，此函数将创建指定地址族的套接字。当指定AF_unsec时，它将尝试所有可能的地址族，直到可以建立连接，并将返回连接的关联套接字。如果不支持地址族，将返回新错误EAFNOSUPPORT。
The following list summarizes the constants and structure, definitions discussed in this memo, sorted by header.
以下列表总结了本备忘录中讨论的常量和结构、定义，并按标题排序。
<netinet/icmp6.h> ICMP6_DST_UNREACH
<netinet/icmp6.h> ICMP6_DST_UNREACH_ADDR
<netinet/icmp6.h> ICMP6_DST_UNREACH_ADMIN
<netinet/icmp6.h> ICMP6_DST_UNREACH_BEYONDSCOPE
<netinet/icmp6.h> ICMP6_DST_UNREACH_NOPORT
<netinet/icmp6.h> ICMP6_DST_UNREACH_NOROUTE
<netinet/icmp6.h> ICMP6_ECHO_REPLY
<netinet/icmp6.h> ICMP6_ECHO_REQUEST
<netinet/icmp6.h> ICMP6_INFOMSG_MASK
<netinet/icmp6.h> ICMP6_DST_UNREACH
<netinet/icmp6.h> ICMP6_DST_UNREACH_ADDR
<netinet/icmp6.h> ICMP6_DST_UNREACH_ADMIN
<netinet/icmp6.h> ICMP6_DST_UNREACH_BEYONDSCOPE
<netinet/icmp6.h> ICMP6_DST_UNREACH_NOPORT
<netinet/icmp6.h> ICMP6_DST_UNREACH_NOROUTE
<netinet/icmp6.h> ICMP6_ECHO_REPLY
<netinet/icmp6.h> ICMP6_ECHO_REQUEST
<netinet/icmp6.h> ICMP6_INFOMSG_MASK
<netinet/icmp6.h> ICMP6_PACKET_TOO_BIG
<netinet/icmp6.h> ICMP6_PARAMPROB_HEADER
<netinet/icmp6.h> ICMP6_PARAMPROB_NEXTHEADER
<netinet/icmp6.h> ICMP6_PARAMPROB_OPTION
<netinet/icmp6.h> ICMP6_PARAM_PROB
<netinet/icmp6.h> ICMP6_ROUTER_RENUMBERING
<netinet/icmp6.h> ICMP6_RR_FLAGS_FORCEAPPLY
<netinet/icmp6.h> ICMP6_RR_FLAGS_PREVDONE
<netinet/icmp6.h> ICMP6_RR_FLAGS_REQRESULT
<netinet/icmp6.h> ICMP6_RR_FLAGS_SPECSITE
<netinet/icmp6.h> ICMP6_RR_FLAGS_TEST
<netinet/icmp6.h> ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME
<netinet/icmp6.h> ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME
<netinet/icmp6.h> ICMP6_RR_PCOUSE_RAFLAGS_AUTO
<netinet/icmp6.h> ICMP6_RR_PCOUSE_RAFLAGS_ONLINK
<netinet/icmp6.h> ICMP6_RR_RESULT_FLAGS_FORBIDDEN
<netinet/icmp6.h> ICMP6_RR_RESULT_FLAGS_OOB
<netinet/icmp6.h> ICMP6_TIME_EXCEEDED
<netinet/icmp6.h> ICMP6_TIME_EXCEED_REASSEMBLY
<netinet/icmp6.h> ICMP6_TIME_EXCEED_TRANSIT
<netinet/icmp6.h> MLD_LISTENER_QUERY
<netinet/icmp6.h> MLD_LISTENER_REDUCTION
<netinet/icmp6.h> MLD_LISTENER_REPORT
<netinet/icmp6.h> ND_NA_FLAG_OVERRIDE
<netinet/icmp6.h> ND_NA_FLAG_ROUTER
<netinet/icmp6.h> ND_NA_FLAG_SOLICITED
<netinet/icmp6.h> ND_NEIGHBOR_ADVERT
<netinet/icmp6.h> ND_NEIGHBOR_SOLICIT
<netinet/icmp6.h> ND_OPT_MTU
<netinet/icmp6.h> ND_OPT_PI_FLAG_AUTO
<netinet/icmp6.h> ND_OPT_PI_FLAG_ONLINK
<netinet/icmp6.h> ND_OPT_PREFIX_INFORMATION
<netinet/icmp6.h> ND_OPT_REDIRECTED_HEADER
<netinet/icmp6.h> ND_OPT_SOURCE_LINKADDR
<netinet/icmp6.h> ND_OPT_TARGET_LINKADDR
<netinet/icmp6.h> ND_RA_FLAG_MANAGED
<netinet/icmp6.h> ND_RA_FLAG_OTHER
<netinet/icmp6.h> ND_REDIRECT
<netinet/icmp6.h> ND_ROUTER_ADVERT
<netinet/icmp6.h> ND_ROUTER_SOLICIT
<netinet/icmp6.h> ICMP6_PACKET_TOO_BIG
<netinet/icmp6.h> ICMP6_PARAMPROB_HEADER
<netinet/icmp6.h> ICMP6_PARAMPROB_NEXTHEADER
<netinet/icmp6.h> ICMP6_PARAMPROB_OPTION
<netinet/icmp6.h> ICMP6_PARAM_PROB
<netinet/icmp6.h> ICMP6_ROUTER_RENUMBERING
<netinet/icmp6.h> ICMP6_RR_FLAGS_FORCEAPPLY
<netinet/icmp6.h> ICMP6_RR_FLAGS_PREVDONE
<netinet/icmp6.h> ICMP6_RR_FLAGS_REQRESULT
<netinet/icmp6.h> ICMP6_RR_FLAGS_SPECSITE
<netinet/icmp6.h> ICMP6_RR_FLAGS_TEST
<netinet/icmp6.h> ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME
<netinet/icmp6.h> ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME
<netinet/icmp6.h> ICMP6_RR_PCOUSE_RAFLAGS_AUTO
<netinet/icmp6.h> ICMP6_RR_PCOUSE_RAFLAGS_ONLINK
<netinet/icmp6.h> ICMP6_RR_RESULT_FLAGS_FORBIDDEN
<netinet/icmp6.h> ICMP6_RR_RESULT_FLAGS_OOB
<netinet/icmp6.h> ICMP6_TIME_EXCEEDED
<netinet/icmp6.h> ICMP6_TIME_EXCEED_REASSEMBLY
<netinet/icmp6.h> ICMP6_TIME_EXCEED_TRANSIT
<netinet/icmp6.h> MLD_LISTENER_QUERY
<netinet/icmp6.h> MLD_LISTENER_REDUCTION
<netinet/icmp6.h> MLD_LISTENER_REPORT
<netinet/icmp6.h> ND_NA_FLAG_OVERRIDE
<netinet/icmp6.h> ND_NA_FLAG_ROUTER
<netinet/icmp6.h> ND_NA_FLAG_SOLICITED
<netinet/icmp6.h> ND_NEIGHBOR_ADVERT
<netinet/icmp6.h> ND_NEIGHBOR_SOLICIT
<netinet/icmp6.h> ND_OPT_MTU
<netinet/icmp6.h> ND_OPT_PI_FLAG_AUTO
<netinet/icmp6.h> ND_OPT_PI_FLAG_ONLINK
<netinet/icmp6.h> ND_OPT_PREFIX_INFORMATION
<netinet/icmp6.h> ND_OPT_REDIRECTED_HEADER
<netinet/icmp6.h> ND_OPT_SOURCE_LINKADDR
<netinet/icmp6.h> ND_OPT_TARGET_LINKADDR
<netinet/icmp6.h> ND_RA_FLAG_MANAGED
<netinet/icmp6.h> ND_RA_FLAG_OTHER
<netinet/icmp6.h> ND_REDIRECT
<netinet/icmp6.h> ND_ROUTER_ADVERT
<netinet/icmp6.h> ND_ROUTER_SOLICIT
<netinet/icmp6.h> struct icmp6_filter{};
<netinet/icmp6.h> struct icmp6_hdr{};
<netinet/icmp6.h> struct icmp6_router_renum{};
<netinet/icmp6.h> struct mld_hdr{};
<netinet/icmp6.h> struct nd_neighbor_advert{};
<netinet/icmp6.h> struct nd_neighbor_solicit{};
<netinet/icmp6.h> struct nd_opt_hdr{};
<netinet/icmp6.h> struct icmp6_filter{};
<netinet/icmp6.h> struct icmp6_hdr{};
<netinet/icmp6.h> struct icmp6_router_renum{};
<netinet/icmp6.h> struct mld_hdr{};
<netinet/icmp6.h> struct nd_neighbor_advert{};
<netinet/icmp6.h> struct nd_neighbor_solicit{};
<netinet/icmp6.h> struct nd_opt_hdr{};
<netinet/icmp6.h> struct nd_opt_mtu{};
<netinet/icmp6.h> struct nd_opt_prefix_info{};
<netinet/icmp6.h> struct nd_opt_rd_hdr{};
<netinet/icmp6.h> struct nd_redirect{};
<netinet/icmp6.h> struct nd_router_advert{};
<netinet/icmp6.h> struct nd_router_solicit{};
<netinet/icmp6.h> struct rr_pco_match{};
<netinet/icmp6.h> struct rr_pco_use{};
<netinet/icmp6.h> struct rr_result{};
<netinet/icmp6.h> struct nd_opt_mtu{};
<netinet/icmp6.h> struct nd_opt_prefix_info{};
<netinet/icmp6.h> struct nd_opt_rd_hdr{};
<netinet/icmp6.h> struct nd_redirect{};
<netinet/icmp6.h> struct nd_router_advert{};
<netinet/icmp6.h> struct nd_router_solicit{};
<netinet/icmp6.h> struct rr_pco_match{};
<netinet/icmp6.h> struct rr_pco_use{};
<netinet/icmp6.h> struct rr_result{};
<netinet/in.h> IPPROTO_AH
<netinet/in.h> IPPROTO_DSTOPTS
<netinet/in.h> IPPROTO_ESP
<netinet/in.h> IPPROTO_FRAGMENT
<netinet/in.h> IPPROTO_HOPOPTS
<netinet/in.h> IPPROTO_ICMPV6
<netinet/in.h> IPPROTO_IPV6
<netinet/in.h> IPPROTO_NONE
<netinet/in.h> IPPROTO_ROUTING
<netinet/in.h> IPV6_CHECKSUM
<netinet/in.h> IPV6_DONTFRAG
<netinet/in.h> IPV6_DSTOPTS
<netinet/in.h> IPV6_HOPLIMIT
<netinet/in.h> IPV6_HOPOPTS
<netinet/in.h> IPPROTO_AH
<netinet/in.h> IPPROTO_DSTOPTS
<netinet/in.h> IPPROTO_ESP
<netinet/in.h> IPPROTO_FRAGMENT
<netinet/in.h> IPPROTO_HOPOPTS
<netinet/in.h> IPPROTO_ICMPV6
<netinet/in.h> IPPROTO_IPV6
<netinet/in.h> IPPROTO_NONE
<netinet/in.h> IPPROTO_ROUTING
<netinet/in.h> IPV6_CHECKSUM
<netinet/in.h> IPV6_DONTFRAG
<netinet/in.h> IPV6_DSTOPTS
<netinet/in.h> IPV6_HOPLIMIT
<netinet/in.h> IPV6_HOPOPTS
<netinet/in.h> IPV6_NEXTHOP
<netinet/in.h> IPV6_PATHMTU
<netinet/in.h> IPV6_PKTINFO
<netinet/in.h> IPV6_RECVDSTOPTS
<netinet/in.h> IPV6_RECVHOPLIMIT
<netinet/in.h> IPV6_RECVHOPOPTS
<netinet/in.h> IPV6_RECVPKTINFO
<netinet/in.h> IPV6_RECVRTHDR
<netinet/in.h> IPV6_RECVTCLASS
<netinet/in.h> IPV6_RTHDR
<netinet/in.h> IPV6_RTHDRDSTOPTS
<netinet/in.h> IPV6_RTHDR_TYPE_0
<netinet/in.h> IPV6_RECVPATHMTU
<netinet/in.h> IPV6_TCLASS
<netinet/in.h> IPV6_USE_MIN_MTU
<netinet/in.h> struct in6_pktinfo{};
<netinet/in.h> struct ip6_mtuinfo{};
<netinet/in.h> IPV6_NEXTHOP
<netinet/in.h> IPV6_PATHMTU
<netinet/in.h> IPV6_PKTINFO
<netinet/in.h> IPV6_RECVDSTOPTS
<netinet/in.h> IPV6_RECVHOPLIMIT
<netinet/in.h> IPV6_RECVHOPOPTS
<netinet/in.h> IPV6_RECVPKTINFO
<netinet/in.h> IPV6_RECVRTHDR
<netinet/in.h> IPV6_RECVTCLASS
<netinet/in.h> IPV6_RTHDR
<netinet/in.h> IPV6_RTHDRDSTOPTS
<netinet/in.h> IPV6_RTHDR_TYPE_0
<netinet/in.h> IPV6_RECVPATHMTU
<netinet/in.h> IPV6_TCLASS
<netinet/in.h> IPV6_USE_MIN_MTU
<netinet/in.h> struct in6_pktinfo{};
<netinet/in.h> struct ip6_mtuinfo{};
<netinet/ip6.h> IP6F_MORE_FRAG
<netinet/ip6.h> IP6F_OFF_MASK
<netinet/ip6.h> IP6F_RESERVED_MASK
<netinet/ip6.h> IP6OPT_JUMBO
<netinet/ip6.h> IP6OPT_JUMBO_LEN
<netinet/ip6.h> IP6F_MORE_FRAG
<netinet/ip6.h> IP6F_OFF_MASK
<netinet/ip6.h> IP6F_RESERVED_MASK
<netinet/ip6.h> IP6OPT_JUMBO
<netinet/ip6.h> IP6OPT_JUMBO_LEN
<netinet/ip6.h> IP6OPT_MUTABLE
<netinet/ip6.h> IP6OPT_NSAP_ADDR
<netinet/ip6.h> IP6OPT_PAD1
<netinet/ip6.h> IP6OPT_PADN
<netinet/ip6.h> IP6OPT_ROUTER_ALERT
<netinet/ip6.h> IP6OPT_TUNNEL_LIMIT
<netinet/ip6.h> IP6OPT_TYPE_DISCARD
<netinet/ip6.h> IP6OPT_TYPE_FORCEICMP
<netinet/ip6.h> IP6OPT_TYPE_ICMP
<netinet/ip6.h> IP6OPT_TYPE_SKIP
<netinet/ip6.h> IP6_ALERT_AN
<netinet/ip6.h> IP6_ALERT_MLD
<netinet/ip6.h> IP6_ALERT_RSVP
<netinet/ip6.h> struct ip6_dest{};
<netinet/ip6.h> struct ip6_frag{};
<netinet/ip6.h> struct ip6_hbh{};
<netinet/ip6.h> struct ip6_hdr{};
<netinet/ip6.h> struct ip6_opt{};
<netinet/ip6.h> struct ip6_opt_jumbo{};
<netinet/ip6.h> struct ip6_opt_nsap{};
<netinet/ip6.h> struct ip6_opt_router{};
<netinet/ip6.h> struct ip6_opt_tunnel{};
<netinet/ip6.h> struct ip6_rthdr{};
<netinet/ip6.h> struct ip6_rthdr0{};
<netinet/ip6.h> IP6OPT_MUTABLE
<netinet/ip6.h> IP6OPT_NSAP_ADDR
<netinet/ip6.h> IP6OPT_PAD1
<netinet/ip6.h> IP6OPT_PADN
<netinet/ip6.h> IP6OPT_ROUTER_ALERT
<netinet/ip6.h> IP6OPT_TUNNEL_LIMIT
<netinet/ip6.h> IP6OPT_TYPE_DISCARD
<netinet/ip6.h> IP6OPT_TYPE_FORCEICMP
<netinet/ip6.h> IP6OPT_TYPE_ICMP
<netinet/ip6.h> IP6OPT_TYPE_SKIP
<netinet/ip6.h> IP6_ALERT_AN
<netinet/ip6.h> IP6_ALERT_MLD
<netinet/ip6.h> IP6_ALERT_RSVP
<netinet/ip6.h> struct ip6_dest{};
<netinet/ip6.h> struct ip6_frag{};
<netinet/ip6.h> struct ip6_hbh{};
<netinet/ip6.h> struct ip6_hdr{};
<netinet/ip6.h> struct ip6_opt{};
<netinet/ip6.h> struct ip6_opt_jumbo{};
<netinet/ip6.h> struct ip6_opt_nsap{};
<netinet/ip6.h> struct ip6_opt_router{};
<netinet/ip6.h> struct ip6_opt_tunnel{};
<netinet/ip6.h> struct ip6_rthdr{};
<netinet/ip6.h> struct ip6_rthdr0{};
The following list summarizes the function and macro prototypes discussed in this memo, sorted by header.
下表总结了本备忘录中讨论的功能和宏原型，按标题排序。
<netinet/icmp6.h> void ICMP6_FILTER_SETBLOCK(int, struct
icmp6_filter *);
<netinet/icmp6.h> void
ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *);
<netinet/icmp6.h> void
ICMP6_FILTER_SETPASS(int,
struct icmp6_filter *);
<netinet/icmp6.h> void
ICMP6_FILTER_SETPASSALL(struct icmp6_filter *);
<netinet/icmp6.h> int ICMP6_FILTER_WILLBLOCK(int,
const struct icmp6_filter *);
<netinet/icmp6.h> int ICMP6_FILTER_WILLPASS(int,
const struct icmp6_filter *);
<netinet/icmp6.h> void ICMP6_FILTER_SETBLOCK(int, struct
icmp6_filter *);
<netinet/icmp6.h> void
ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *);
<netinet/icmp6.h> void
ICMP6_FILTER_SETPASS(int,
struct icmp6_filter *);
<netinet/icmp6.h> void
ICMP6_FILTER_SETPASSALL(struct icmp6_filter *);
<netinet/icmp6.h> int ICMP6_FILTER_WILLBLOCK(int,
const struct icmp6_filter *);
<netinet/icmp6.h> int ICMP6_FILTER_WILLPASS(int,
const struct icmp6_filter *);
<netinet/in.h> int IN6_ARE_ADDR_EQUAL(const struct in6_addr *,
const struct in6_addr *);
<netinet/in.h> int IN6_ARE_ADDR_EQUAL(const struct in6_addr *,
const struct in6_addr *);
<netinet/in.h> int inet6_opt_append(void *, socklen_t, int,
uint8_t, socklen_t, uint_t,
void **);
<netinet/in.h> int inet6_opt_append(void *, socklen_t, int,
uint8_t, socklen_t, uint_t,
void **);
<netinet/in.h> int inet6_opt_get_val(void *, int, void *,
socklen_t);
<netinet/in.h> int inet6_opt_find(void *, socklen_t,
int, uint8_t ,
socklen_t *, void **);
<netinet/in.h> int inet6_opt_finish(void *, socklen_t, int);
<netinet/in.h> int inet6_opt_init(void *, socklen_t);
<netinet/in.h> int inet6_opt_next(void *, socklen_t,
int, uint8_t *,
socklen_t *, void **);
<netinet/in.h> int inet6_opt_set_val(void *, int,
void *, socklen_t);
<netinet/in.h> int inet6_opt_get_val(void *, int, void *,
socklen_t);
<netinet/in.h> int inet6_opt_find(void *, socklen_t,
int, uint8_t ,
socklen_t *, void **);
<netinet/in.h> int inet6_opt_finish(void *, socklen_t, int);
<netinet/in.h> int inet6_opt_init(void *, socklen_t);
<netinet/in.h> int inet6_opt_next(void *, socklen_t,
int, uint8_t *,
socklen_t *, void **);
<netinet/in.h> int inet6_opt_set_val(void *, int,
void *, socklen_t);
<netinet/in.h> int inet6_rth_add(void *,
const struct in6_addr *);
<netinet/in.h> struct in6_addr inet6_rth_getaddr(const void *,
int);
<netinet/in.h> void *inet6_rth_init(void *, socklen_t,
int, int);
<netinet/in.h> int inet6_rth_reverse(const void *, void *);
<netinet/in.h> int inet6_rth_segments(const void *);
<netinet/in.h> soccklen_t inet6_rth_space(int, int);
<netinet/in.h> int inet6_rth_add(void *,
const struct in6_addr *);
<netinet/in.h> struct in6_addr inet6_rth_getaddr(const void *,
int);
<netinet/in.h> void *inet6_rth_init(void *, socklen_t,
int, int);
<netinet/in.h> int inet6_rth_reverse(const void *, void *);
<netinet/in.h> int inet6_rth_segments(const void *);
<netinet/in.h> soccklen_t inet6_rth_space(int, int);
<netinet/ip6.h> int IP6OPT_TYPE(uint8_t);
<netinet/ip6.h> int IP6OPT_TYPE(uint8_t);
<sys/socket.h> socklen_t CMSG_LEN(socklen_t);
<sys/socket.h> socklen_t CMSG_SPACE(socklen_t);
<sys/socket.h> socklen_t CMSG_LEN(socklen_t);
<sys/socket.h> socklen_t CMSG_SPACE(socklen_t);
<unistd.h> int rresvport_af(int *, int);
<unistd.h> int rcmd_af(char **, unsigned short,
const char *, const char *,
const char *, int *, int);
<unistd.h> int rexec_af(char **, unsigned short,
const char *, const char *,
const char *, int *, int);
<unistd.h> int rresvport_af(int *, int);
<unistd.h> int rcmd_af(char **, unsigned short,
const char *, const char *,
const char *, int *, int);
<unistd.h> int rexec_af(char **, unsigned short,
const char *, const char *,
const char *, int *, int);
The setting of certain Hop-by-Hop options and Destination options may be restricted to privileged processes. Similarly some Hop-by-Hop options and Destination options may not be returned to non-privileged applications.
某些逐跳选项和目标选项的设置可能仅限于特权进程。类似地，某些逐跳选项和目标选项可能不会返回给非特权应用程序。
The ability to specify an arbitrary source address using IPV6_PKTINFO must be prevented; at least for non-privileged processes.
必须防止使用IPV6_PKTINFO指定任意源地址；至少对于非特权进程。
Significant changes that affect the compatibility to RFC 2292:
影响RFC 2292兼容性的重大变更：
- Removed the IPV6_PKTOPTIONS socket option by allowing sticky options to be set with individual setsockopt() calls.
- 通过允许使用单独的setsockopt（）调用设置粘性选项，删除了IPV6_pktoOptions套接字选项。
- Removed the ability to be able to specify Hop-by-Hop and Destination options using multiple ancillary data items. The application, using the inet6_opt_xxx() routines (see below), is responsible for formatting the whole extension header.
- 删除了使用多个辅助数据项指定逐跳和目标选项的功能。应用程序使用inet6_opt_xxx（）例程（见下文），负责格式化整个扩展头。
- Removed the support for the loose/strict Routing header since that has been removed from the IPv6 specification.
- 删除了对松散/严格路由标头的支持，因为该标头已从IPv6规范中删除。
- Loosened the constraints for jumbo payload option that this option was always hidden from applications.
- 放宽了jumbo有效负载选项的限制，即该选项始终对应用程序隐藏。
- Disabled the use of the IPV6_HOPLIMIT sticky option.
- 已禁用IPV6\u限制粘性选项的使用。
- Removed ip6r0_addr field from the ip6_rthdr structure.
- 已从ip6_rthdr结构中删除ip6r0_addr字段。
- Intentionally unspecified how to get received packet's information on TCP sockets.
- 故意未指明如何在TCP套接字上获取接收到的数据包信息。
New features:
新功能：
- Added IPV6_RTHDRDSTOPTS to specify a Destination Options header before the Routing header.
- 添加了IPV6_rthdrdstops以在路由标头之前指定目标选项标头。
- Added separate IPV6_RECVxxx options to enable the receipt of the corresponding ancillary data items.
- 添加了单独的IPV6_RECVxxx选项，以允许接收相应的辅助数据项。
- Added inet6_rth_xxx() and inet6_opt_xxx() functions to deal with routing or IPv6 options headers.
- 添加了inet6_rth_xxx（）和inet6_opt_xxx（）函数来处理路由或IPv6选项头。
- Added extensions of libraries for the "r" commands.
- 为“r”命令添加了库的扩展。
- Introduced additional IPv6 option definitions such as IP6OPT_PAD1.
- 引入了其他IPv6选项定义，如IP6OPT_PAD1。
- Added MLD and router renumbering definitions.
- 添加了MLD和路由器重新编号定义。
- Added MTU-related socket options and ancillary data items.
- 添加了与MTU相关的插座选项和辅助数据项。
- Added options and ancillary data items to manipulate the traffic class field.
- 添加了选项和辅助数据项以操作“流量类别”字段。
- Changed the name of ICMPv6 unreachable code 2 to be "beyond scope of source address." ICMP6_DST_UNREACH_NOTNEIGHBOR was removed with this change.
- 将ICMPv6不可访问代码2的名称更改为“超出源地址的范围”。ICMP6_DST_UNREACH_NOTNEIGHBOR已随此更改一起删除。
Clarifications:
澄清：
- Added clarifications on extension headers ordering; for the sending side, assume the recommended ordering described in RFC 2460. For the receiving side, do not assume any ordering and pass all headers to the application in the received order.
- 增加了对扩展标题订购的澄清；对于发送端，假设RFC 2460中描述的推荐顺序。对于接收端，不要假设任何顺序，并按照接收的顺序将所有头传递给应用程序。
- Added a summary about the interface selection rule.
- 添加了有关接口选择规则的摘要。
- Clarified the ordering between IPV6_MULTICAST_IF and the IPV6_PKTINFO sticky option for multicast packets.
- 阐明了IPV6_MULTICAST_IF和IPV6_PKTINFO多播数据包粘性选项之间的顺序。
- Clarified how sticky options and the ICMPv6 filter are turned off and that getsockopt() of a sticky option returns what was set with setsockopt().
- 阐明了如何关闭粘滞选项和ICMPv6筛选器，以及粘滞选项的getsockopt（）返回使用setsockopt（）设置的内容。
- Clarified that IPV6_NEXTHOP should be ignored for a multicast destination, that it should not contradict with the specified outgoing interface, and that the next hop should be a sockaddr_in6 structure.
- 阐明了对于多播目标应忽略IPV6_NEXTHOP，它不应与指定的传出接口冲突，并且下一个跃点应为sockaddr_in6结构。
- Clarified corner cases of IPV6_CHECKSUM.
- 澄清了IPV6_校验和的角落案例。
- Aligned with the POSIX standard.
- 与POSIX标准保持一致。
Editorial changes:
编辑更改：
- Replaced MUST with must (since this is an informational document).
- 将“必须”替换为“必须”（因为这是一个信息性文档）。
- Revised abstract to be more clear and concise, particularly concentrating on differences from RFC 2292.
- 修订摘要，使其更加清晰和简洁，特别是集中于与RFC 2292的差异。
- Made the URL of assigned numbers less specific so that it would be more robust for future changes.
- 使分配号码的URL不那么具体，以便在将来的更改中更加可靠。
- Updated the reference to the basic API.
- 更新了对基本API的引用。
- Added a reference to the latest POSIX standard.
- 添加了对最新POSIX标准的引用。
- Moved general specifications of ancillary data and CMSG macros to the appendix.
- 将辅助数据和CMSG宏的一般规范移至附录中。
[RFC-1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC-1981]McCann，J.，Deering，S.和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC-3493] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, March 2003.
[RFC-3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年3月。
[POSIX] IEEE Std. 1003.1-2001 Standard for Information
Technology -- Portable Operating System Interface
(POSIX). Open group Technical Standard: Base
Specifications, Issue 6, December 2001. ISO/IEC
9945:2002. http://www.opengroup.org/austin
[POSIX] IEEE Std. 1003.1-2001 Standard for Information
Technology -- Portable Operating System Interface
(POSIX). Open group Technical Standard: Base
Specifications, Issue 6, December 2001. ISO/IEC
9945:2002. http://www.opengroup.org/austin
[TCPIPILLUST] Wright, G., Stevens, W., "TCP/IP Illustrated, Volume 2: The Implementation", Addison Wesley, 1994.
[TCPIPILLUST]Wright，G.，Stevens，W.，“TCP/IP图解，第2卷：实现”，Addison-Wesley，1994年。
Matt Thomas and Jim Bound have been working on the technical details in this document for over a year. Keith Sklower is the original implementor of ancillary data in the BSD networking code. Craig Metz provided lots of feedback, suggestions, and comments based on his implementing many of these features as the document was being written. Mark Andrews first proposed the idea of the IPV6_USE_MIN_MTU option. Jun-ichiro Hagino contributed text for the traffic class API from a document of his own.
马特·托马斯（Matt Thomas）和吉姆·邦德（Jim Bound）一年多以来一直致力于本文档中的技术细节。Keith Sklower是BSD网络代码中辅助数据的原始实现者。Craig Metz在编写文档时实现了许多这些特性，并根据这些特性提供了大量反馈、建议和评论。马克·安德鲁斯首先提出了IPV6使用MTU选项的想法。Jun ichiro Hagino从他自己的文档中为流量类API提供了文本。
The following provided comments on earlier drafts: Pascal Anelli, Hamid Asayesh, Ran Atkinson, Karl Auerbach, Hamid Asayesh, Don Coolidge, Matt Crawford, Sam T. Denton, Richard Draves, Francis Dupont, Toerless Eckert, Lilian Fernandes, Bob Gilligan, Gerri Harter, Tim Hartrick, Bob Halley, Masaki Hirabaru, Michael Hunter, Yoshinobu Inoue, Mukesh Kacker, A. N. Kuznetsov, Sam Manthorpe, Pedro Marques, Jack McCann, der Mouse, John Moy, Lori Napoli, Thomas Narten, Atsushi Onoe, Steve Parker, Charles Perkins, Ken Powell, Tom Pusateri, Pedro Roque, Sameer Shah, Peter Sjodin, Stephen P. Spackman, Jinmei Tatuya, Karen Tracey, Sowmini Varadhan, Quaizar Vohra, Carl Williams, Steve Wise, Eric Wong, Farrell Woods, Kazu Yamamoto, Vladislav Yasevich, and Yoshifuji Hideaki.
以下提供了对早期草案的评论：帕斯卡·阿内利、哈米德·阿萨耶什、冉·阿特金森、卡尔·奥尔巴赫、哈米德·阿萨耶什、唐·柯立芝、马特·克劳福德、萨姆·丹顿、理查德·德拉维斯、弗朗西斯·杜邦、无趾埃克特、莉莲·费尔南德斯、鲍勃·吉利根、格瑞·哈特、蒂姆·哈特里克、鲍勃·哈雷、平拉巴鲁、迈克尔·亨特、井上吉诺布、，穆克什·卡克尔、A.N.库兹涅佐夫、萨姆·曼索普、佩德罗·马奎斯、杰克·麦肯、德·穆斯、约翰·莫伊、洛里·那不勒斯、托马斯·纳滕、阿图西·奥内、史蒂夫·帕克、查尔斯·帕金斯、肯·鲍威尔、汤姆·普萨特里、佩德罗·罗克、萨米尔·沙阿、彼得·斯乔丁、斯蒂芬·P·斯帕克曼、金美·塔图亚、卡伦·特雷西、索维尼·瓦拉丹、奎泽·沃拉、卡尔·威廉姆斯、史蒂夫·怀斯、，Eric Wong、Farrell Woods、山本和一、Vladislav Yasevich和Yoshifuji Hideaki。
4.2BSD allowed file descriptors to be transferred between separate processes across a UNIX domain socket using the sendmsg() and recvmsg() functions. Two members of the msghdr structure, msg_accrights and msg_accrightslen, were used to send and receive the descriptors. When the OSI protocols were added to 4.3BSD Reno in 1990 the names of these two fields in the msghdr structure were changed to msg_control and msg_controllen, because they were used by the OSI protocols for "control information", although the comments in the source code call this "ancillary data".
4.2BSD允许使用sendmsg（）和recvmsg（）函数在UNIX域套接字上的不同进程之间传输文件描述符。msghdr结构的两个成员msg_accrights和msg_accrightslen用于发送和接收描述符。当OSI协议于1990年添加到4.3BSD Reno时，msghdr结构中这两个字段的名称被更改为msg_control和msg_controllen，因为OSI协议使用它们作为“控制信息”，尽管源代码中的注释称之为“辅助数据”。
Other than the OSI protocols, the use of ancillary data has been rare. In 4.4BSD, for example, the only use of ancillary data with IPv4 is to return the destination address of a received UDP datagram if the IP_RECVDSTADDR socket option is set. With Unix domain sockets ancillary data is still used to send and receive descriptors.
除了OSI协议之外，辅助数据的使用很少。例如，在4.4BSD中，如果设置了IP_RECVDSTADDR socket选项，则IPv4的辅助数据的唯一用途是返回接收到的UDP数据报的目标地址。对于Unix域套接字，辅助数据仍然用于发送和接收描述符。
Nevertheless the ancillary data fields of the msghdr structure provide a clean way to pass information in addition to the data that is being read or written. The inclusion of the msg_control and msg_controllen members of the msghdr structure along with the cmsghdr structure that is pointed to by the msg_control member is required by the Posix sockets API standard.
然而，msghdr结构的辅助数据字段提供了一种干净的方式来传递除正在读取或写入的数据之外的信息。Posix sockets API标准要求将msghdr结构的msg_control和msg_controllen成员以及msg_控件成员指向的cmsghdr结构包含在内。
The msghdr structure is used by the recvmsg() and sendmsg() functions. Its Posix definition is:
msghdr结构由recvmsg（）和sendmsg（）函数使用。其Posix定义为：
struct msghdr {
void *msg_name; /* ptr to socket address
structure */
socklen_t msg_namelen; /* size of socket address
structure */
struct iovec *msg_iov; /* scatter/gather array */
int msg_iovlen; /* # elements in msg_iov */
void *msg_control; /* ancillary data */
socklen_t msg_controllen; /* ancillary data buffer length */
int msg_flags; /* flags on received message */
};
struct msghdr {
void *msg_name; /* ptr to socket address
structure */
socklen_t msg_namelen; /* size of socket address
structure */
struct iovec *msg_iov; /* scatter/gather array */
int msg_iovlen; /* # elements in msg_iov */
void *msg_control; /* ancillary data */
socklen_t msg_controllen; /* ancillary data buffer length */
int msg_flags; /* flags on received message */
};
The structure is declared as a result of including <sys/socket.h>.
该结构声明为包含<sys/socket.h>的结果。
(Note: Before Posix the two "void *" pointers were typically "char *", and the two socklen_t members were typically integers. Earlier drafts of Posix had the two socklen_t members as size_t, but it then changed these to socklen_t to simplify binary portability for 64-bit
（注意：在Posix之前，两个“void*”指针通常是“char*”，两个socklen_t成员通常是整数。Posix的早期草案将两个socklen_t成员作为size_t，但随后将其更改为socklen_t，以简化64位二进制可移植性。）
implementations and to align Posix with X/Open's Networking Services, Issue 5. The change in msg_control to a "void *" pointer affects any code that increments this pointer.)
实现并使Posix与X/Open的网络服务保持一致，第5期。将msg_控件更改为“void*”指针会影响任何增加此指针的代码。）
Most Berkeley-derived implementations limit the amount of ancillary data in a call to sendmsg() to no more than 108 bytes (an mbuf). This API requires a minimum of 10240 bytes of ancillary data, but it is recommended that the amount be limited only by the buffer space reserved by the socket (which can be modified by the SO_SNDBUF socket option). (Note: This magic number 10240 was picked as a value that should always be large enough. 108 bytes is clearly too small as the maximum size of a Routing header is 2048 bytes.)
大多数Berkeley派生的实现将sendmsg（）调用中的辅助数据量限制为不超过108字节（一个mbuf）。此API至少需要10240字节的辅助数据，但建议仅通过套接字保留的缓冲区空间（可通过SO_SNDBUF socket选项修改）来限制该数量。（注意：这个神奇的数字10240被选为一个应该总是足够大的值。108字节显然太小了，因为路由头的最大大小是2048字节。）
The cmsghdr structure describes ancillary data objects transferred by recvmsg() and sendmsg(). Its Posix definition is:
cmsghdr结构描述由recvmsg（）和sendmsg（）传输的辅助数据对象。其Posix定义为：
struct cmsghdr {
socklen_t cmsg_len; /* #bytes, including this header */
int cmsg_level; /* originating protocol */
int cmsg_type; /* protocol-specific type */
/* followed by unsigned char cmsg_data[]; */
};
struct cmsghdr {
socklen_t cmsg_len; /* #bytes, including this header */
int cmsg_level; /* originating protocol */
int cmsg_type; /* protocol-specific type */
/* followed by unsigned char cmsg_data[]; */
};
This structure is declared as a result of including <sys/socket.h>.
声明此结构是因为包含了<sys/socket.h>。
(Note: Before Posix the cmsg_len member was an integer, and not a socklen_t. See the Note in the previous section for why socklen_t is used here.)
（注意：在Posix之前，cmsg_len成员是一个整数，而不是socklen_t。请参阅上一节中的说明，了解此处使用socklen_t的原因。）
As shown in this definition, normally there is no member with the name cmsg_data[]. Instead, the data portion is accessed using the CMSG_xxx() macros, as described in Section 20.3. Nevertheless, it is common to refer to the cmsg_data[] member.
如该定义所示，通常没有名为cmsg_data[]的成员。相反，使用CMSG_xxx（）宏访问数据部分，如第20.3节所述。然而，通常提及cmsg_data[]成员。
When ancillary data is sent or received, any number of ancillary data objects can be specified by the msg_control and msg_controllen members of the msghdr structure, because each object is preceded by a cmsghdr structure defining the object's length (the cmsg_len member). Historically Berkeley-derived implementations have passed only one object at a time, but this API allows multiple objects to be passed in a single call to sendmsg() or recvmsg(). The following example shows two ancillary data objects in a control buffer.
当发送或接收辅助数据时，msghdr结构的msg_control和msg_controllen成员可以指定任意数量的辅助数据对象，因为每个对象前面都有一个定义对象长度的cmsghdr结构（cmsg_len成员）。从历史上看，Berkeley派生的实现一次只传递一个对象，但此API允许在对sendmsg（）或recvmsg（）的单个调用中传递多个对象。以下示例显示控件缓冲区中的两个辅助数据对象。
|<--------------------------- msg_controllen ------------------------->|
| OR |
|<--------------------------- msg_controllen ---------------------->|
| |
|<----- ancillary data object ----->|<---- ancillary data object ----->|
|<------ min CMSG_SPACE() --------->|<----- min CMSG_SPACE() --------->|
| | |
|<---------- cmsg_len ---------->| |<-------- cmsg_len ----------->| |
|<--------- CMSG_LEN() --------->| |<------- CMSG_LEN() ---------->| |
| | | | |
+-----+-----+-----+--+-----------+--+-----+-----+-----+--+----------+--+
|cmsg_|cmsg_|cmsg_|XX| cmsg_ |XX|cmsg_|cmsg_|cmsg_|XX| cmsg_ |XX|
|len |level|type |XX| data[] |XX|len |level|type |XX| data[] |XX|
+-----+-----+-----+--+-----------+--+-----+-----+-----+--+----------+--+
^
|
msg_control
points here
|<--------------------------- msg_controllen ------------------------->|
| OR |
|<--------------------------- msg_controllen ---------------------->|
| |
|<----- ancillary data object ----->|<---- ancillary data object ----->|
|<------ min CMSG_SPACE() --------->|<----- min CMSG_SPACE() --------->|
| | |
|<---------- cmsg_len ---------->| |<-------- cmsg_len ----------->| |
|<--------- CMSG_LEN() --------->| |<------- CMSG_LEN() ---------->| |
| | | | |
+-----+-----+-----+--+-----------+--+-----+-----+-----+--+----------+--+
|cmsg_|cmsg_|cmsg_|XX| cmsg_ |XX|cmsg_|cmsg_|cmsg_|XX| cmsg_ |XX|
|len |level|type |XX| data[] |XX|len |level|type |XX| data[] |XX|
+-----+-----+-----+--+-----------+--+-----+-----+-----+--+----------+--+
^
|
msg_control
points here
The fields shown as "XX" are possible padding, between the cmsghdr structure and the data, and between the data and the next cmsghdr structure, if required by the implementation. While sending an application may or may not include padding at the end of last ancillary data in msg_controllen and implementations must accept both as valid. On receiving a portable application must provide space for padding at the end of the last ancillary data as implementations may copy out the padding at the end of the control message buffer and include it in the received msg_controllen. When recvmsg() is called if msg_controllen is too small for all the ancillary data items including any trailing padding after the last item an implementation may set MSG_CTRUNC.
如果实现需要，显示为“XX”的字段可能是cmsghdr结构和数据之间以及数据和下一个cmsghdr结构之间的填充。发送应用程序时，在msg_controllen中的最后一个辅助数据末尾可能包含填充，也可能不包含填充，并且实现必须接受这两种填充。在接收到便携式应用程序时，必须在最后一个辅助数据的末尾提供填充空间，因为实现可能会复制控制消息缓冲区末尾的填充，并将其包含在接收到的msg_controllen中。当调用recvmsg（）时，如果msg_controllen对于所有辅助数据项（包括最后一项之后的任何尾随填充）来说太小，则实现可能会设置msg_CTRUNC。
To aid in the manipulation of ancillary data objects, three macros from 4.4BSD are defined by Posix: CMSG_DATA(), CMSG_NXTHDR(), and CMSG_FIRSTHDR(). Before describing these macros, we show the following example of how they might be used with a call to recvmsg().
为了帮助操作辅助数据对象，Posix定义了4.4BSD中的三个宏：CMSG_data（）、CMSG_NXTHDR（）和CMSG_FIRSTHDR（）。在描述这些宏之前，我们将展示以下示例，说明如何在调用recvmsg（）时使用这些宏。
struct msghdr msg;
struct cmsghdr *cmsgptr;
struct msghdr msg;
struct cmsghdr *cmsgptr;
/* fill in msg */
/* fill in msg */
/* call recvmsg() */
/* call recvmsg() */
for (cmsgptr = CMSG_FIRSTHDR(&msg); cmsgptr != NULL;
cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) {
if (cmsgptr->cmsg_len == 0) {
/* Error handling */
break;
}
if (cmsgptr->cmsg_level == ... &&
cmsgptr->cmsg_type == ... ) {
u_char *ptr;
for (cmsgptr = CMSG_FIRSTHDR(&msg); cmsgptr != NULL;
cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) {
if (cmsgptr->cmsg_len == 0) {
/* Error handling */
break;
}
if (cmsgptr->cmsg_level == ... &&
cmsgptr->cmsg_type == ... ) {
u_char *ptr;
ptr = CMSG_DATA(cmsgptr);
/* process data pointed to by ptr */
}
}
ptr = CMSG_DATA(cmsgptr);
/* process data pointed to by ptr */
}
}
We now describe the three Posix macros, followed by two more that are new with this API: CMSG_SPACE() and CMSG_LEN(). All these macros are defined as a result of including <sys/socket.h>.
我们现在介绍三个Posix宏，然后介绍另外两个与此API相关的新宏：CMSG_SPACE（）和CMSG_LEN（）。所有这些宏都是由于包含<sys/socket.h>而定义的。
struct cmsghdr *CMSG_FIRSTHDR(const struct msghdr *mhdr);
struct cmsghdr *CMSG_FIRSTHDR(const struct msghdr *mhdr);
CMSG_FIRSTHDR() returns a pointer to the first cmsghdr structure in the msghdr structure pointed to by mhdr. The macro returns NULL if there is no ancillary data pointed to by the msghdr structure (that is, if either msg_control is NULL or if msg_controllen is less than the size of a cmsghdr structure).
CMSG_FIRSTHDR（）返回指向mhdr指向的msghdr结构中的第一个cmsghdr结构的指针。如果没有msghdr结构指向的辅助数据（即，如果msg_control为NULL或msg_controllen小于cmsghdr结构的大小），则宏返回NULL。
One possible implementation could be
一种可能的实施方式是
#define CMSG_FIRSTHDR(mhdr) \
( (mhdr)->msg_controllen >= sizeof(struct cmsghdr) ? \
(struct cmsghdr *)(mhdr)->msg_control : \
(struct cmsghdr *)NULL )
#define CMSG_FIRSTHDR(mhdr) \
( (mhdr)->msg_controllen >= sizeof(struct cmsghdr) ? \
(struct cmsghdr *)(mhdr)->msg_control : \
(struct cmsghdr *)NULL )
(Note: Most existing implementations do not test the value of msg_controllen, and just return the value of msg_control. The value of msg_controllen must be tested, because if the application asks recvmsg() to return ancillary data, by setting msg_control to point to the application's buffer and setting msg_controllen to the length of this buffer, the kernel indicates that no ancillary data is available by setting msg_controllen to 0 on return. It is also easier to put this test into this macro, than making the application perform the test.)
（注意：大多数现有实现不测试msg_controllen的值，只返回msg_control的值。必须测试msg_controllen的值，因为如果应用程序请求recvmsg（）要返回辅助数据，通过将msg_control设置为指向应用程序的缓冲区，并将msg_controllen设置为该缓冲区的长度，内核在返回时将msg_controllen设置为0，表明没有辅助数据可用。将此测试放入此宏也比让应用程序执行测试更容易。）
As described in Section 5.1, CMSG_NXTHDR has been extended to handle a NULL 2nd argument to mean "get the first header". This provides an alternative way of coding the processing loop shown earlier:
如第5.1节所述，CMSG_NXTHDR已扩展为处理表示“获取第一个标头”的空第二个参数。这提供了一种对前面显示的处理循环进行编码的替代方法：
struct msghdr msg;
struct cmsghdr *cmsgptr = NULL;
struct msghdr msg;
struct cmsghdr *cmsgptr = NULL;
/* fill in msg */
/* fill in msg */
/* call recvmsg() */
/* call recvmsg() */
while ((cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) != NULL) {
if (cmsgptr->cmsg_len == 0) {
/* Error handling */
break;
}
if (cmsgptr->cmsg_level == ... &&
cmsgptr->cmsg_type == ... ) {
u_char *ptr;
while ((cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) != NULL) {
if (cmsgptr->cmsg_len == 0) {
/* Error handling */
break;
}
if (cmsgptr->cmsg_level == ... &&
cmsgptr->cmsg_type == ... ) {
u_char *ptr;
ptr = CMSG_DATA(cmsgptr);
/* process data pointed to by ptr */
}
}
ptr = CMSG_DATA(cmsgptr);
/* process data pointed to by ptr */
}
}
One possible implementation could be:
一种可能的实施方式是：
#define CMSG_NXTHDR(mhdr, cmsg) \
(((cmsg) == NULL) ? CMSG_FIRSTHDR(mhdr) : \
(((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len) \
+ ALIGN_D(sizeof(struct cmsghdr)) > \
(u_char *)((mhdr)->msg_control) + (mhdr)->msg_controllen) ? \
(struct cmsghdr *)NULL : \
(struct cmsghdr *)((u_char *)(cmsg) + \
ALIGN_H((cmsg)->cmsg_len))))
#define CMSG_NXTHDR(mhdr, cmsg) \
(((cmsg) == NULL) ? CMSG_FIRSTHDR(mhdr) : \
(((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len) \
+ ALIGN_D(sizeof(struct cmsghdr)) > \
(u_char *)((mhdr)->msg_control) + (mhdr)->msg_controllen) ? \
(struct cmsghdr *)NULL : \
(struct cmsghdr *)((u_char *)(cmsg) + \
ALIGN_H((cmsg)->cmsg_len))))
The macros ALIGN_H() and ALIGN_D(), which are implementation dependent, round their arguments up to the next even multiple of whatever alignment is required for the start of the cmsghdr structure and the data, respectively. (This is probably a multiple of 4 or 8 bytes.) They are often the same macro in implementations platforms where alignment requirement for header and data is chosen to be identical.
依赖于实现的宏ALIGN_H（）和ALIGN_D（），分别将其参数舍入到cmsghdr结构和数据开始时所需的任何对齐的下一个偶数倍。（这可能是4或8字节的倍数。）在选择相同的头和数据对齐要求的平台中，它们通常是相同的宏实现。
unsigned char *CMSG_DATA(const struct cmsghdr *cmsg);
unsigned char *CMSG_DATA(const struct cmsghdr *cmsg);
CMSG_DATA() returns a pointer to the data (what is called the cmsg_data[] member, even though such a member is not defined in the structure) following a cmsghdr structure.
CMSG_DATA（）返回一个指针，指向cmsghdr结构之后的数据（称为CMSG_DATA[]成员，即使该结构中未定义此类成员）。
One possible implementation could be:
一种可能的实施方式是：
#define CMSG_DATA(cmsg) ( (u_char *)(cmsg) + \
ALIGN_D(sizeof(struct cmsghdr)) )
#define CMSG_DATA(cmsg) ( (u_char *)(cmsg) + \
ALIGN_D(sizeof(struct cmsghdr)) )
CMSG_SPACE is new with this API (see Section 5.2). It is used to determine how much space needs to be allocated for an ancillary data item.
CMSG_空间是该API的新增空间（见第5.2节）。它用于确定需要为辅助数据项分配多少空间。
One possible implementation could be:
一种可能的实施方式是：
#define CMSG_SPACE(length) ( ALIGN_D(sizeof(struct cmsghdr)) + \
ALIGN_H(length) )
#define CMSG_SPACE(length) ( ALIGN_D(sizeof(struct cmsghdr)) + \
ALIGN_H(length) )
CMSG_LEN is new with this API (see Section 5.3). It returns the value to store in the cmsg_len member of the cmsghdr structure, taking into account any padding needed to satisfy alignment requirements.
CMSG_LEN是本API的新版本（见第5.3节）。它返回要存储在cmsghdr结构的cmsg_len成员中的值，并考虑满足对齐要求所需的任何填充。
One possible implementation could be:
一种可能的实施方式是：
#define CMSG_LEN(length) ( ALIGN_D(sizeof(struct cmsghdr)) + \
length )
#define CMSG_LEN(length) ( ALIGN_D(sizeof(struct cmsghdr)) + \
length )
Here we show an example for both sending Routing headers and processing and reversing a received Routing header.
这里我们展示了一个发送路由头和处理并反转接收到的路由头的示例。
As an example of these Routing header functions defined in this document, we go through the function calls for the example on p. 17 of [RFC-2460]. The source is S, the destination is D, and the three intermediate nodes are I1, I2, and I3.
作为本文档中定义的这些路由头函数的一个示例，我们将浏览p。[RFC-2460]第17页。源是S，目标是D，三个中间节点是I1、I2和I3。
S -----> I1 -----> I2 -----> I3 -----> D
S -----> I1 -----> I2 -----> I3 -----> D
src: * S S S S S
dst: D I1 I2 I3 D D
A[1]: I1 I2 I1 I1 I1 I1
A[2]: I2 I3 I3 I2 I2 I2
A[3]: I3 D D D I3 I3
#seg: 3 3 2 1 0 3
src: * S S S S S
dst: D I1 I2 I3 D D
A[1]: I1 I2 I1 I1 I1 I1
A[2]: I2 I3 I3 I2 I2 I2
A[3]: I3 D D D I3 I3
#seg: 3 3 2 1 0 3
src and dst are the source and destination IPv6 addresses in the IPv6 header. A[1], A[2], and A[3] are the three addresses in the Routing header. #seg is the Segments Left field in the Routing header.
src和dst是IPv6标头中的源和目标IPv6地址。A[1]、A[2]和A[3]是路由报头中的三个地址#seg是路由标头中的Segments Left字段。
The six values in the column beneath node S are the values in the Routing header specified by the sending application using sendmsg() of setsockopt(). The function calls by the sender would look like:
节点S下方列中的六个值是发送应用程序使用setsockopt（）的sendmsg（）指定的路由头中的值。发送方的函数调用如下所示：
void *extptr;
socklen_t extlen;
struct msghdr msg;
struct cmsghdr *cmsgptr;
int cmsglen;
struct sockaddr_in6 I1, I2, I3, D;
void *extptr;
socklen_t extlen;
struct msghdr msg;
struct cmsghdr *cmsgptr;
int cmsglen;
struct sockaddr_in6 I1, I2, I3, D;
extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3);
cmsglen = CMSG_SPACE(extlen);
cmsgptr = malloc(cmsglen);
cmsgptr->cmsg_len = CMSG_LEN(extlen);
cmsgptr->cmsg_level = IPPROTO_IPV6;
cmsgptr->cmsg_type = IPV6_RTHDR;
extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3);
cmsglen = CMSG_SPACE(extlen);
cmsgptr = malloc(cmsglen);
cmsgptr->cmsg_len = CMSG_LEN(extlen);
cmsgptr->cmsg_level = IPPROTO_IPV6;
cmsgptr->cmsg_type = IPV6_RTHDR;
extptr = CMSG_DATA(cmsgptr);
extptr = inet6_rth_init(extptr, extlen, IPV6_RTHDR_TYPE_0, 3);
extptr = CMSG_DATA(cmsgptr);
extptr = inet6_rth_init(extptr, extlen, IPV6_RTHDR_TYPE_0, 3);
inet6_rth_add(extptr, &I1.sin6_addr);
inet6_rth_add(extptr, &I2.sin6_addr);
inet6_rth_add(extptr, &I3.sin6_addr);
inet6_rth_add(extptr, &I1.sin6_addr);
inet6_rth_add(extptr, &I2.sin6_addr);
inet6_rth_add(extptr, &I3.sin6_addr);
msg.msg_control = cmsgptr;
msg.msg_controllen = cmsglen;
msg.msg_control = cmsgptr;
msg.msg_controllen = cmsglen;
/* finish filling in msg{}, msg_name = D */
/* call sendmsg() */
/* finish filling in msg{}, msg_name = D */
/* call sendmsg() */
We also assume that the source address for the socket is not specified (i.e., the asterisk in the figure).
我们还假设未指定套接字的源地址（即图中的星号）。
The four columns of six values that are then shown between the five nodes are the values of the fields in the packet while the packet is in transit between the two nodes. Notice that before the packet is sent by the source node S, the source address is chosen (replacing the asterisk), I1 becomes the destination address of the datagram, the two addresses A[2] and A[3] are "shifted up", and D is moved to A[3].
然后在五个节点之间显示的六个值的四列是数据包在两个节点之间传输时的字段值。注意，在源节点S发送分组之前，选择源地址（替换星号），I1成为数据报的目的地址，两个地址A[2]和A[3]被“上移”，并且D被移动到A[3]。
The columns of values that are shown beneath the destination node are the values returned by recvmsg(), assuming the application has enabled both the IPV6_RECVPKTINFO and IPV6_RECVRTHDR socket options. The source address is S (contained in the sockaddr_in6 structure pointed to by the msg_name member), the destination address is D (returned as an ancillary data object in an in6_pktinfo structure), and the ancillary data object specifying the Routing header will contain three addresses (I1, I2, and I3). The number of segments in the Routing header is known from the Hdr Ext Len field in the Routing header (a value of 6, indicating 3 addresses).
如果应用程序同时启用了IPV6_RECVPKTINFO和IPV6_RECVRTHDR套接字选项，则目标节点下方显示的值列是recvmsg（）返回的值。源地址是S（包含在msg_name成员指向的sockaddr_in6结构中），目标地址是D（作为in6_pktinfo结构中的辅助数据对象返回），指定路由头的辅助数据对象将包含三个地址（I1、I2和I3）。从路由头中的Hdr Ext Len字段可以知道路由头中的段数（值为6，表示3个地址）。
The return value from inet6_rth_segments() will be 3 and inet6_rth_getaddr(0) will return I1, inet6_rth_getaddr(1) will return I2, and inet6_rth_getaddr(2) will return I3,
inet6_rth_segments（）的返回值将为3，inet6_rth_getaddr（0）将返回I1，inet6_rth_getaddr（1）将返回I2，inet6_rth_getaddr（2）将返回I3，
If the receiving application then calls inet6_rth_reverse(), the order of the three addresses will become I3, I2, and I1.
如果接收应用程序随后调用inet6_rth_reverse（），则三个地址的顺序将变为I3、I2和I1。
We can also show what an implementation might store in the ancillary data object as the Routing header is being built by the sending process. If we assume a 32-bit architecture where sizeof(struct cmsghdr) equals 12, with a desired alignment of 4-byte boundaries, then the call to inet6_rth_space(3) returns 68: 12 bytes for the cmsghdr structure and 56 bytes for the Routing header (8 + 3*16).
我们还可以展示当发送进程正在构建路由头时，实现可能在辅助数据对象中存储的内容。如果我们假设一个32位体系结构，其中sizeof（struct cmsghdr）等于12，并且需要4字节边界对齐，那么对inet6_rth_空间（3）的调用返回68:12字节用于cmsghdr结构，56字节用于路由头（8+3*16）。
The call to inet6_rth_init() initializes the ancillary data object to contain a Type 0 Routing header:
对inet6_rth_init（）的调用初始化辅助数据对象以包含类型0路由头：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_len = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_level = IPPROTO_IPV6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_type = IPV6_RTHDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_len = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_level = IPPROTO_IPV6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_type = IPV6_RTHDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first call to inet6_rth_add() adds I1 to the list.
对inet6\u rth\u add（）的第一个调用将I1添加到列表中。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_len = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_level = IPPROTO_IPV6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_type = IPV6_RTHDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[1] = I1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_len = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_level = IPPROTO_IPV6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_type = IPV6_RTHDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[1] = I1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
cmsg_len is incremented by 16, and the Segments Left field is incremented by 1.
cmsg_len增加16，Segments Left字段增加1。
The next call to inet6_rth_add() adds I2 to the list.
对inet6\u rth\u add（）的下一个调用将I2添加到列表中。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_len = 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_level = IPPROTO_IPV6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_type = IPV6_RTHDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[1] = I1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[2] = I2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_len = 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_level = IPPROTO_IPV6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_type = IPV6_RTHDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[1] = I1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[2] = I2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
cmsg_len is incremented by 16, and the Segments Left field is incremented by 1.
cmsg_len增加16，Segments Left字段增加1。
The last call to inet6_rth_add() adds I3 to the list.
最后一次调用inet6\u rth\u add（）将I3添加到列表中。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_len = 68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_level = IPPROTO_IPV6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_type = IPV6_RTHDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[1] = I1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[2] = I2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[3] = I3 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_len = 68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_level = IPPROTO_IPV6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmsg_type = IPV6_RTHDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[1] = I1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[2] = I2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[3] = I3 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
cmsg_len is incremented by 16, and the Segments Left field is incremented by 1.
cmsg_len增加16，Segments Left字段增加1。
This example assumes that the application has enabled IPV6_RECVRTHDR socket option. The application prints and reverses a source route and uses that to echo the received data.
本示例假设应用程序已启用IPV6\u RECVRTHDR套接字选项。应用程序打印并反转源路由，并使用该路由回显接收到的数据。
struct sockaddr_in6 addr;
struct msghdr msg;
struct iovec iov;
struct cmsghdr *cmsgptr;
socklen_t cmsgspace;
void *extptr;
int extlen;
struct sockaddr_in6 addr;
struct msghdr msg;
struct iovec iov;
struct cmsghdr *cmsgptr;
socklen_t cmsgspace;
void *extptr;
int extlen;
int segments;
int i;
char databuf[8192];
int segments;
int i;
char databuf[8192];
segments = 100; /* Enough */
extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, segments);
cmsgspace = CMSG_SPACE(extlen);
cmsgptr = malloc(cmsgspace);
if (cmsgptr == NULL) {
perror("malloc");
exit(1);
}
extptr = CMSG_DATA(cmsgptr);
segments = 100; /* Enough */
extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, segments);
cmsgspace = CMSG_SPACE(extlen);
cmsgptr = malloc(cmsgspace);
if (cmsgptr == NULL) {
perror("malloc");
exit(1);
}
extptr = CMSG_DATA(cmsgptr);
msg.msg_control = cmsgptr;
msg.msg_controllen = cmsgspace;
msg.msg_name = (struct sockaddr *)&addr;
msg.msg_namelen = sizeof (addr);
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
iov.iov_base = databuf;
iov.iov_len = sizeof (databuf);
msg.msg_flags = 0;
if (recvmsg(s, &msg, 0) == -1) {
perror("recvmsg");
return;
}
if (msg.msg_controllen != 0 &&
cmsgptr->cmsg_level == IPPROTO_IPV6 &&
cmsgptr->cmsg_type == IPV6_RTHDR) {
struct in6_addr *in6;
char asciiname[INET6_ADDRSTRLEN];
struct ip6_rthdr *rthdr;
msg.msg_control = cmsgptr;
msg.msg_controllen = cmsgspace;
msg.msg_name = (struct sockaddr *)&addr;
msg.msg_namelen = sizeof (addr);
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
iov.iov_base = databuf;
iov.iov_len = sizeof (databuf);
msg.msg_flags = 0;
if (recvmsg(s, &msg, 0) == -1) {
perror("recvmsg");
return;
}
if (msg.msg_controllen != 0 &&
cmsgptr->cmsg_level == IPPROTO_IPV6 &&
cmsgptr->cmsg_type == IPV6_RTHDR) {
struct in6_addr *in6;
char asciiname[INET6_ADDRSTRLEN];
struct ip6_rthdr *rthdr;
rthdr = (struct ip6_rthdr *)extptr;
segments = inet6_rth_segments(extptr);
printf("route (%d segments, %d left): ",
segments, rthdr->ip6r_segleft);
for (i = 0; i < segments; i++) {
in6 = inet6_rth_getaddr(extptr, i);
rthdr = (struct ip6_rthdr *)extptr;
segments = inet6_rth_segments(extptr);
printf("route (%d segments, %d left): ",
segments, rthdr->ip6r_segleft);
for (i = 0; i < segments; i++) {
in6 = inet6_rth_getaddr(extptr, i);
if (in6 == NULL)
printf("<NULL> ");
else
printf("%s ", inet_ntop(AF_INET6,
(void *)in6->s6_addr,
asciiname, INET6_ADDRSTRLEN));
}
if (inet6_rth_reverse(extptr, extptr) == -1) {
printf("reverse failed");
return;
}
}
iov.iov_base = databuf;
iov.iov_len = strlen(databuf);
if (sendmsg(s, &msg, 0) == -1)
perror("sendmsg");
if (cmsgptr != NULL)
free(cmsgptr);
if (in6 == NULL)
printf("<NULL> ");
else
printf("%s ", inet_ntop(AF_INET6,
(void *)in6->s6_addr,
asciiname, INET6_ADDRSTRLEN));
}
if (inet6_rth_reverse(extptr, extptr) == -1) {
printf("reverse failed");
return;
}
}
iov.iov_base = databuf;
iov.iov_len = strlen(databuf);
if (sendmsg(s, &msg, 0) == -1)
perror("sendmsg");
if (cmsgptr != NULL)
free(cmsgptr);
Note: The above example is a simple illustration. It skips some error checks, including those involving the MSG_TRUNC and MSG_CTRUNC flags. It also leaves some type mismatches in favor of brevity.
注：以上示例是一个简单的说明。它跳过一些错误检查，包括涉及MSG_TRUNC和MSG_CTRUNC标志的错误检查。为了简洁起见，它还留下了一些类型不匹配。
This shows how Hop-by-Hop and Destination options can be both built as well as parsed using the inet6_opt_XXX() functions. These examples assume that there are defined values for OPT_X and OPT_Y.
这显示了如何使用inet6_opt_XXX（）函数构建和解析逐跳和目标选项。这些示例假设存在OPT_X和OPT_Y的定义值。
Note: The example is a simple illustration. It skips some error checks and leaves some type mismatches in favor of brevity.
注：该示例是一个简单的说明。为了简洁起见，它跳过了一些错误检查并留下了一些类型不匹配。
We now provide an example that builds two Hop-by-Hop options using the example in Appendix B of [RFC-2460].
我们现在提供一个示例，使用[RFC-2460]附录B中的示例构建两个逐跳选项。
void *extbuf;
socklen_t extlen;
int currentlen;
void *databuf;
int offset;
uint8_t value1;
uint16_t value2;
uint32_t value4;
uint64_t value8;
void *extbuf;
socklen_t extlen;
int currentlen;
void *databuf;
int offset;
uint8_t value1;
uint16_t value2;
uint32_t value4;
uint64_t value8;
/* Estimate the length */
/* Estimate the length */
currentlen = inet6_opt_init(NULL, 0);
if (currentlen == -1)
return (-1);
currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_X,
12, 8, NULL);
if (currentlen == -1)
return (-1);
currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_Y,
7, 4, NULL);
if (currentlen == -1)
return (-1);
currentlen = inet6_opt_finish(NULL, 0, currentlen);
if (currentlen == -1)
return (-1);
extlen = currentlen;
currentlen = inet6_opt_init(NULL, 0);
if (currentlen == -1)
return (-1);
currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_X,
12, 8, NULL);
if (currentlen == -1)
return (-1);
currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_Y,
7, 4, NULL);
if (currentlen == -1)
return (-1);
currentlen = inet6_opt_finish(NULL, 0, currentlen);
if (currentlen == -1)
return (-1);
extlen = currentlen;
extbuf = malloc(extlen);
if (extbuf == NULL) {
perror("malloc");
return (-1);
}
currentlen = inet6_opt_init(extbuf, extlen);
if (currentlen == -1)
return (-1);
extbuf = malloc(extlen);
if (extbuf == NULL) {
perror("malloc");
return (-1);
}
currentlen = inet6_opt_init(extbuf, extlen);
if (currentlen == -1)
return (-1);
currentlen = inet6_opt_append(extbuf, extlen, currentlen,
OPT_X, 12, 8, &databuf);
if (currentlen == -1)
return (-1);
/* Insert value 0x12345678 for 4-octet field */
offset = 0;
value4 = 0x12345678;
offset = inet6_opt_set_val(databuf, offset,
&value4, sizeof (value4));
/* Insert value 0x0102030405060708 for 8-octet field */
value8 = 0x0102030405060708;
offset = inet6_opt_set_val(databuf, offset,
&value8, sizeof (value8));
currentlen = inet6_opt_append(extbuf, extlen, currentlen,
OPT_X, 12, 8, &databuf);
if (currentlen == -1)
return (-1);
/* Insert value 0x12345678 for 4-octet field */
offset = 0;
value4 = 0x12345678;
offset = inet6_opt_set_val(databuf, offset,
&value4, sizeof (value4));
/* Insert value 0x0102030405060708 for 8-octet field */
value8 = 0x0102030405060708;
offset = inet6_opt_set_val(databuf, offset,
&value8, sizeof (value8));
currentlen = inet6_opt_append(extbuf, extlen, currentlen,
OPT_Y, 7, 4, &databuf);
if (currentlen == -1)
return (-1);
/* Insert value 0x01 for 1-octet field */
offset = 0;
value1 = 0x01;
offset = inet6_opt_set_val(databuf, offset,
&value1, sizeof (value1));
currentlen = inet6_opt_append(extbuf, extlen, currentlen,
OPT_Y, 7, 4, &databuf);
if (currentlen == -1)
return (-1);
/* Insert value 0x01 for 1-octet field */
offset = 0;
value1 = 0x01;
offset = inet6_opt_set_val(databuf, offset,
&value1, sizeof (value1));
/* Insert value 0x1331 for 2-octet field */
value2 = 0x1331;
offset = inet6_opt_set_val(databuf, offset,
&value2, sizeof (value2));
/* Insert value 0x01020304 for 4-octet field */
value4 = 0x01020304;
offset = inet6_opt_set_val(databuf, offset,
&value4, sizeof (value4));
/* Insert value 0x1331 for 2-octet field */
value2 = 0x1331;
offset = inet6_opt_set_val(databuf, offset,
&value2, sizeof (value2));
/* Insert value 0x01020304 for 4-octet field */
value4 = 0x01020304;
offset = inet6_opt_set_val(databuf, offset,
&value4, sizeof (value4));
currentlen = inet6_opt_finish(extbuf, extlen, currentlen);
if (currentlen == -1)
return (-1);
/* extbuf and extlen are now completely formatted */
currentlen = inet6_opt_finish(extbuf, extlen, currentlen);
if (currentlen == -1)
return (-1);
/* extbuf and extlen are now completely formatted */
This example parses and prints the content of the two options in the previous example.
此示例解析并打印上一示例中两个选项的内容。
int
print_opt(void *extbuf, socklen_t extlen)
{
struct ip6_dest *ext;
int currentlen;
uint8_t type;
socklen_t len;
void *databuf;
int offset;
uint8_t value1;
uint16_t value2;
uint32_t value4;
uint64_t value8;
int
print_opt(void *extbuf, socklen_t extlen)
{
struct ip6_dest *ext;
int currentlen;
uint8_t type;
socklen_t len;
void *databuf;
int offset;
uint8_t value1;
uint16_t value2;
uint32_t value4;
uint64_t value8;
ext = (struct ip6_dest *)extbuf;
printf("nxt %u, len %u (bytes %d)\n", ext->ip6d_nxt,
ext->ip6d_len, (ext->ip6d_len + 1) * 8);
ext = (struct ip6_dest *)extbuf;
printf("nxt %u, len %u (bytes %d)\n", ext->ip6d_nxt,
ext->ip6d_len, (ext->ip6d_len + 1) * 8);
currentlen = 0;
while (1) {
currentlen = inet6_opt_next(extbuf, extlen,
currentlen, &type,
&len, &databuf);
if (currentlen == -1)
break;
printf("Received opt %u len %u\n",
type, len);
switch (type) {
case OPT_X:
currentlen = 0;
while (1) {
currentlen = inet6_opt_next(extbuf, extlen,
currentlen, &type,
&len, &databuf);
if (currentlen == -1)
break;
printf("Received opt %u len %u\n",
type, len);
switch (type) {
case OPT_X:
offset = 0;
offset =
inet6_opt_get_val(databuf, offset,
&value4,
sizeof (value4));
printf("X 4-byte field %x\n", value4);
offset =
inet6_opt_get_val(databuf, offset,
&value8,
sizeof (value8));
printf("X 8-byte field %llx\n", value8);
break;
case OPT_Y:
offset = 0;
offset =
inet6_opt_get_val(databuf, offset,
&value1,
sizeof (value1));
printf("Y 1-byte field %x\n", value1);
offset =
inet6_opt_get_val(databuf, offset,
&value2,
sizeof (value2));
printf("Y 2-byte field %x\n", value2);
offset =
inet6_opt_get_val(databuf, offset,
&value4,
sizeof (value4));
printf("Y 4-byte field %x\n", value4);
break;
default:
printf("Unknown option %u\n", type);
break;
}
}
return (0);
}
offset = 0;
offset =
inet6_opt_get_val(databuf, offset,
&value4,
sizeof (value4));
printf("X 4-byte field %x\n", value4);
offset =
inet6_opt_get_val(databuf, offset,
&value8,
sizeof (value8));
printf("X 8-byte field %llx\n", value8);
break;
case OPT_Y:
offset = 0;
offset =
inet6_opt_get_val(databuf, offset,
&value1,
sizeof (value1));
printf("Y 1-byte field %x\n", value1);
offset =
inet6_opt_get_val(databuf, offset,
&value2,
sizeof (value2));
printf("Y 2-byte field %x\n", value2);
offset =
inet6_opt_get_val(databuf, offset,
&value4,
sizeof (value4));
printf("Y 4-byte field %x\n", value4);
break;
default:
printf("Unknown option %u\n", type);
break;
}
}
return (0);
}
W. Richard Stevens (deceased)
W.理查德·史蒂文斯（已故）
Matt Thomas 3am Software Foundry 8053 Park Villa Circle Cupertino, CA 95014
马特·托马斯3am软件铸造厂，加利福尼亚州库珀蒂诺公园别墅圈8053号，邮编95014
EMail: matt@3am-software.com
EMail: matt@3am-software.com
Erik Nordmark Sun Microsystems Laboratories, Europe 180, avenue de l'Europe 38334 SAINT ISMIER Cedex, France
Erik Nordmark Sun Microsystems Laboratories，欧洲180号，欧洲大道38334号，法国圣伊斯梅尔塞德斯
Phone: +33 (0)4 74 18 88 03
Fax: +33 (0)4 76 18 88 88
EMail: Erik.Nordmark@sun.com
Phone: +33 (0)4 74 18 88 03
Fax: +33 (0)4 76 18 88 88
EMail: Erik.Nordmark@sun.com
Tatuya JINMEI Corporate Research & Development Center, Toshiba Corporation 1 Komukai Toshiba-cho, Kawasaki-shi Kanagawa 212-8582, Japan
Tatuya JINMEI公司研发中心，东芝公司1 Komukai Toshiba cho，川崎市神奈川212-8582，日本
EMail: jinmei@isl.rdc.toshiba.co.jp
EMail: jinmei@isl.rdc.toshiba.co.jp
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。