Network Working Group S. Chakrabarti
Request for Comments: 4584 E. Nordmark
Category: Informational Sun Microsystems
July 2006
Network Working Group S. Chakrabarti
Request for Comments: 4584 E. Nordmark
Category: Informational Sun Microsystems
July 2006
Extension to Sockets API for Mobile 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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes data structures and API support for Mobile IPv6 as an extension to the Advanced Socket API for IPv6.
本文档描述了移动IPv6的数据结构和API支持，作为IPv6高级套接字API的扩展。
Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information for Mobility Header messages, Home Address destination options, and Routing Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications.
正如IPv6的高级套接字API允许访问各种扩展头和ICMPv6协议一样，本文档为移动IPv6组件指定了相同的访问级别。它为应用程序指定了一种机制，用于检索和设置移动头消息、家庭地址目标选项和路由头类型2扩展头的信息。它还指定了某些高级移动IPv6套接字应用程序可能使用的通用数据结构和定义。
Table of Contents
目录
1. Introduction ....................................................3
2. Applicability ...................................................4
3. Overview ........................................................5
4. Common Structures and Definitions ...............................6
4.1. The Mobility Header Data Structures ........................6
4.1.1. The ip6_mh Structure ................................6
4.1.2. Binding Refresh Request Mobility Message ............7
4.1.3. Home Address Test Init (HoTI) Message ...............7
4.1.4. Care-of Address Test Init (CoTI) Message ............7
4.1.5. Home Address Test (HOT) Message .....................8
4.1.6. Care Of Address Test (COT) Message ..................8
4.1.7. Binding Update Mobility Message .....................8
4.1.8. Binding Acknowledgement Mobility Message ............9
4.1.9. Binding Error Mobility Message ......................9
4.1.10. Mobility Option TLV data structure .................9
4.1.11. Mobility Option Data Structures ...................10
4.1.11.1. Binding Refresh Advice ...................10
4.1.11.2. Alternate Care-of Address ................10
4.1.11.3. Nonce Indices ............................10
4.1.11.4. Binding Authorization Data ...............10
4.2. Mobility Header Constants .................................10
4.3. IPv6 Home Address Destination Option ......................12
4.4. Type 2 Routing Header .....................................12
4.5. New ICMP Messages for Mobile IPv6 .........................13
4.6. IPv6 Neighbor Discovery Changes ...........................14
5. Access to Home Address Destination Option and Routing Headers ..15
5.1. Routing Header Access Functions ...........................17
5.2. Content of Type 2 Routing Header ..........................18
5.3. Order of Extension Headers for Home Address
Destination Options .......................................19
5.4. Home Address Destination Option Access Functions ..........20
5.5. Content of Home Address Destination Option ................20
6. Mobility Protocol Headers ......................................21
6.1. Receiving and Sending Mobility Header Messages ............21
7. Protocols File .................................................22
8. IPv4-Mapped IPv6 Addresses .....................................23
9. Security Considerations ........................................23
10. IANA Considerations ...........................................23
11. Acknowledgements ..............................................23
12. References ....................................................24
12.1. Normative References .....................................24
12.2. Informative References ...................................24
1. Introduction ....................................................3
2. Applicability ...................................................4
3. Overview ........................................................5
4. Common Structures and Definitions ...............................6
4.1. The Mobility Header Data Structures ........................6
4.1.1. The ip6_mh Structure ................................6
4.1.2. Binding Refresh Request Mobility Message ............7
4.1.3. Home Address Test Init (HoTI) Message ...............7
4.1.4. Care-of Address Test Init (CoTI) Message ............7
4.1.5. Home Address Test (HOT) Message .....................8
4.1.6. Care Of Address Test (COT) Message ..................8
4.1.7. Binding Update Mobility Message .....................8
4.1.8. Binding Acknowledgement Mobility Message ............9
4.1.9. Binding Error Mobility Message ......................9
4.1.10. Mobility Option TLV data structure .................9
4.1.11. Mobility Option Data Structures ...................10
4.1.11.1. Binding Refresh Advice ...................10
4.1.11.2. Alternate Care-of Address ................10
4.1.11.3. Nonce Indices ............................10
4.1.11.4. Binding Authorization Data ...............10
4.2. Mobility Header Constants .................................10
4.3. IPv6 Home Address Destination Option ......................12
4.4. Type 2 Routing Header .....................................12
4.5. New ICMP Messages for Mobile IPv6 .........................13
4.6. IPv6 Neighbor Discovery Changes ...........................14
5. Access to Home Address Destination Option and Routing Headers ..15
5.1. Routing Header Access Functions ...........................17
5.2. Content of Type 2 Routing Header ..........................18
5.3. Order of Extension Headers for Home Address
Destination Options .......................................19
5.4. Home Address Destination Option Access Functions ..........20
5.5. Content of Home Address Destination Option ................20
6. Mobility Protocol Headers ......................................21
6.1. Receiving and Sending Mobility Header Messages ............21
7. Protocols File .................................................22
8. IPv4-Mapped IPv6 Addresses .....................................23
9. Security Considerations ........................................23
10. IANA Considerations ...........................................23
11. Acknowledgements ..............................................23
12. References ....................................................24
12.1. Normative References .....................................24
12.2. Informative References ...................................24
Mobility Support in IPv6 [2] defines a new Mobility Protocol header, a Home Address destination option and a new Routing Header type. It is expected that Mobile IPv6 user-level implementations and some special applications will need to access and process these IPv6 extension headers. This document is an extension to the existing Advanced Sockets API document [1]; it addresses the Advanced IPv6 Sockets API for these new protocol elements defined by Mobile IPv6.
IPv6[2]中的移动性支持定义了新的移动性协议头、家庭地址目的地选项和新的路由头类型。预计移动IPv6用户级实现和一些特殊应用程序将需要访问和处理这些IPv6扩展头。本文档是现有高级套接字API文档[1]的扩展；它为移动IPv6定义的这些新协议元素提供了高级IPv6套接字API。
The applicability of this API mainly targets user-level applications. However, it has also been shown to be useful within some Mobile IPv6 implementations; for instance, where part of the Mobile IPv6 protocol is implemented at user-level and part in the kernel. It is up to any such implementations to architect which part of the Mobile IPv6 and IP Security (IPSec) packet processing should be done at the user-level in order to meet the design needs of the particular platform and operating system.
此API的适用性主要针对用户级应用程序。然而，它在一些移动IPv6实现中也被证明是有用的；例如，移动IPv6协议的一部分在用户级实现，另一部分在内核中实现。为了满足特定平台和操作系统的设计需求，移动IPv6和IP安全（IPSec）数据包处理的哪一部分应该在用户级别完成，这取决于任何此类实现。
The target user-level applications for this socket API are believed to be debugging and diagnostic applications and some policy applications that would like to receive copies of protocol information at the application layer.
此套接字API的目标用户级应用程序被认为是调试和诊断应用程序，以及一些希望在应用层接收协议信息副本的策略应用程序。
The packet information and access to the extension headers (Routing header 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.1g standard and should therefore be adopted by most vendors. This document is consistent with Advanced Sockets API for IPv6 [1] in structure definitions, header files, and function definitions. Thus, the implementors of this API document are assumed to be familiar with the data structures, data sending and receiving procedures, and the IPv6 extension header access functions described in the Advanced Sockets API for IPv6 [1].
使用1990年添加到4.3BSD Reno sockets API中的“辅助数据”字段指定数据包信息和对扩展头的访问（路由头和目的地选项）。原因是这些辅助数据字段是Posix.1g标准的一部分，因此应该被大多数供应商采用。本文档在结构定义、头文件和函数定义方面与IPv6[1]的高级套接字API一致。因此，假定本API文档的实施者熟悉IPv6的高级套接字API[1]中描述的数据结构、数据发送和接收过程以及IPv6扩展头访问功能。
Non-goals
非目标
This document does not address application access to either the Authentication Header or the Encapsulating Security Payload header. This document also does not address any API that might be necessary for Mobile Network [4] specific needs. Furthermore, note that this API document excludes discussion on application-level API. It assumes that address selection socket API [5] takes care of selection of care-of address or home address as the source address by the application, when source address selection is required due to the nature of the application.
本文档不涉及对身份验证标头或封装安全有效负载标头的应用程序访问。本文档也未涉及移动网络[4]特定需求可能需要的任何API。此外，请注意，此API文档不包括对应用程序级API的讨论。它假设地址选择套接字API[5]负责选择转交地址或家庭地址作为应用程序的源地址，因为应用程序的性质需要选择源地址。
Providing mobility "awareness" to applications, such as applications' being able to tell whether the host is at home or not, is out of scope for this API.
为应用程序提供移动性“感知”，例如应用程序能够判断主机是否在家，这超出了此API的范围。
This API document can be applied in the following cases:
本API文件可应用于以下情况：
1. User-level debugging and monitoring tools: This socket API is useful for accessing Mobility Headers, Home Address destination options and Type 2 Routing Headers . For example, mh-ping might be a monitoring tool that can process mobility headers on the receiving side to check binding status.
1. 用户级调试和监视工具：此套接字API用于访问移动头、家庭地址目标选项和类型2路由头。例如，mh-ping可能是一个监视工具，可以在接收端处理移动头以检查绑定状态。
2. Partial user-level implementation of Mobile IPv6: We assume that some implementations may choose to do the Mobility header processing at user level. In that case, this document recommends implementing at least the handling of Home Address destination options and Type 2 Routing Header in the main IP processing paths in the kernel. The API can then be used to send and receive the Mobility Header packets used for Mobile IPv6 signaling.
2. 移动IPv6的部分用户级实现：我们假设一些实现可能选择在用户级执行移动报头处理。在这种情况下，本文档建议至少在内核的主IP处理路径中实现对Home Address destination选项和Type 2 Routing Header的处理。然后，该API可用于发送和接收用于移动IPv6信令的移动报头分组。
3. Complete header processing at the kernel-level: Many implementations of Mobile IPv6 [2] perform processing of Home Address destination options, Type 2 Routing Headers, and Mobility headers at the kernel level. However, the kernel keeps a copy of the received extension headers and passes them up to the API, which is used by the user-level applications purely for monitoring and debugging Mobile IPv6 packets.
3. 在内核级别完成报头处理：移动IPv6的许多实现[2]在内核级别执行家庭地址目标选项、类型2路由报头和移动报头的处理。但是，内核保留接收到的扩展头的副本，并将其传递给API，用户级应用程序使用API纯粹用于监视和调试移动IPv6数据包。
On an IPv6 host that does not implement Mobile IPv6, the IPv6 specification [3] requires that packets with the Home Address option or Type 2 Routing Header (where segments left is non-zero) be dropped on receipt. This means that it is not possible to implement Mobile IPv6 as an application on such a system. Thus, on such a system, the applicability of this API is limited to the first case above, enabling debugging and monitoring applications (such as tcpdump) to parse and interpret Mobile IPv6 packets.
在未实现移动IPv6的IPv6主机上，IPv6规范[3]要求在接收时丢弃带有Home Address选项或Type 2路由头（其中剩余段为非零）的数据包。这意味着不可能在这样的系统上实现移动IPv6作为应用程序。因此，在这样的系统上，该API的适用性仅限于上述第一种情况，从而使调试和监视应用程序（例如tcpdump）能够解析和解释移动IPv6数据包。
This document can be divided into the following parts:
本文件可分为以下几部分：
1. Definitions of constants and structures for C programs that capture the Mobile IPv6 packet formats on the wire. A common definition of these is useful at least for packet snooping applications. This is captured in Section 4. In addition, Section 4 also defines data structures for Home Address destination option, Type 2 Routing Header, and new ICMPv6 messages related to Mobile IPv6.
1. C程序的常量和结构的定义，这些程序捕获有线移动IPv6数据包格式。至少对于包窥探应用程序来说，这些的通用定义是有用的。这在第4节中有描述。此外，第4节还定义了与移动IPv6相关的家庭地址目标选项、类型2路由头和新ICMPv6消息的数据结构。
2. Notes on how to use the IPv6 Advanced API to access Home Address options and Type 2 Routing Headers. This is captured in Section 5.
2. 有关如何使用IPv6高级API访问家庭地址选项和类型2路由头的说明。这在第5节中有描述。
3. Notes on how user-level applications can observe MH (Mobility Header) packets using raw sockets (in Section 6). The IPv6 RAW socket interface described in this document allows applications to receive MH packets whether or not the system's MH processing takes place in the "kernel" or at the "user space".
3. 关于用户级应用程序如何使用原始套接字观察MH（移动报头）数据包的说明（第6节）。本文档中描述的IPv6原始套接字接口允许应用程序接收MH数据包，无论系统的MH处理是否发生在“内核”或“用户空间”。
4. A name is suggested for IPv6 Mobility Header protocol in /etc/ protocols (in Section 7).
4. 建议在/etc/protocols（第7节）中为IPv6移动头协议命名。
All examples in this document omit error checking in favor of brevity, as it is following the same style as the Advanced Socket API [1].
为了简洁起见，本文中的所有示例都省略了错误检查，因为它遵循与高级套接字API相同的样式[1]。
Note that many of the functions and socket options defined in this document may have error returns that are not defined in this document.
请注意，本文档中定义的许多函数和套接字选项可能具有本文档中未定义的错误返回。
Data types in this document follow the Posix.1g 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.1g格式：intN_t表示正好N位的有符号整数（例如int16_t），uintN_t表示正好N位的无符号整数（例如uint32_t）。
Once the API specification becomes mature and is deployed, it may be formally standardized by a more appropriate body, as has been done with the Basic API [6]. However, since this specification largely builds upon the Advanced Socket API [1], such standardization would make sense only if the Advanced Socket API [1] were also standardized.
一旦API规范变得成熟并部署，它可能会被更合适的机构正式标准化，就像基本API一样[6]。然而，由于该规范主要基于高级套接字API[1]，因此只有在高级套接字API[1]也被标准化的情况下，这种标准化才有意义。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
In this section, the structures are specified in a way so that they maximize the probability that the compiler-layout of data structures are identical to the packet formats on the wire. However, ANSI-C provides few guarantees about the size and alignment of data structures.
在本节中，指定结构的方式应使数据结构的编译器布局与线路上的数据包格式相同的可能性最大化。然而，ANSI-C对数据结构的大小和对齐提供了很少的保证。
The assumption is that the Advanced Socket API [1] will pass up the actual packet content (the wire format) in the buffer and in the ancillary data objects. Thus, if an implementor has to handle a system where the ANSI-C compiler does not and can not lay out these structures to match the wire formats in RFC 3775 [2], the structures defined by this API can not be supported on such a system.
假设高级套接字API[1]将向上传递缓冲区和辅助数据对象中的实际数据包内容（有线格式）。因此，如果实现者必须处理ANSI-C编译器没有且不能布置这些结构以匹配RFC 3775[2]中的wire格式的系统，则此API定义的结构在此类系统上不受支持。
The constants and structures shown below are in network byte order, so an application needs to perform the appropriate byte order conversion (ntohs(), etc) when necessary.
下面显示的常量和结构是按网络字节顺序排列的，因此应用程序需要在必要时执行适当的字节顺序转换（ntohs（），等等）。
The structures and constants below will be included when the (new)
header file is included : <netinet/ip6mh.h>
The structures and constants below will be included when the (new)
header file is included : <netinet/ip6mh.h>
The following structure is defined as a result of including <netinet/ip6mh.h>. This is the fixed part of the Mobility Header. Different Mobility message types are defined in Mobile IPv6 [2]. For portability and alignment reasons, each mobility message type includes the mobility header fields instead of including the ip6_mh structure, followed by the message-specific fields.
以下结构定义为包含<netinet/ip6mh.h>的结果。这是移动报头的固定部分。移动IPv6中定义了不同的移动消息类型[2]。出于可移植性和对齐的原因，每种移动消息类型都包括移动报头字段，而不包括ip6_mh结构，然后是消息特定字段。
struct ip6_mh {
uint8_t ip6mh_proto; /* NO_NXTHDR by default */
uint8_t ip6mh_hdrlen; /* Header Len in unit of 8 Octets
excluding the first 8 Octets */
uint8_t ip6mh_type; /* Type of Mobility Header */
uint8_t ip6mh_reserved; /* Reserved */
uint16_t ip6mh_cksum; /* Mobility Header Checksum */
/* Followed by type specific messages */
};
struct ip6_mh {
uint8_t ip6mh_proto; /* NO_NXTHDR by default */
uint8_t ip6mh_hdrlen; /* Header Len in unit of 8 Octets
excluding the first 8 Octets */
uint8_t ip6mh_type; /* Type of Mobility Header */
uint8_t ip6mh_reserved; /* Reserved */
uint16_t ip6mh_cksum; /* Mobility Header Checksum */
/* Followed by type specific messages */
};
struct ip6_mh_binding_request {
uint8_t ip6mhbr_proto;
uint8_t ip6mhbr_hdrlen;
uint8_t ip6mhbr_type;
uint8_t ip6mhbr_reserved;
uint16_t ip6mhbr_cksum;
uint16_t ip6mhbr_reserved2;
/* Followed by optional Mobility Options */
};
struct ip6_mh_binding_request {
uint8_t ip6mhbr_proto;
uint8_t ip6mhbr_hdrlen;
uint8_t ip6mhbr_type;
uint8_t ip6mhbr_reserved;
uint16_t ip6mhbr_cksum;
uint16_t ip6mhbr_reserved2;
/* Followed by optional Mobility Options */
};
struct ip6_mh_home_test_init {
uint8_t ip6mhhti_proto;
uint8_t ip6mhhti_hdrlen;
uint8_t ip6mhhti_type;
uint8_t ip6mhhti_reserved;
uint16_t ip6mhhti_cksum;
uint16_t ip6mhhti_reserved2;
uint32_t ip6mhhti_cookie[2]; /* 64 bit Cookie by MN */
/* Followed by optional Mobility Options */
};
struct ip6_mh_home_test_init {
uint8_t ip6mhhti_proto;
uint8_t ip6mhhti_hdrlen;
uint8_t ip6mhhti_type;
uint8_t ip6mhhti_reserved;
uint16_t ip6mhhti_cksum;
uint16_t ip6mhhti_reserved2;
uint32_t ip6mhhti_cookie[2]; /* 64 bit Cookie by MN */
/* Followed by optional Mobility Options */
};
struct ip6_mh_careof_test_init {
uint8_t ip6mhcti_proto;
uint8_t ip6mhcti_hdrlen;
uint8_t ip6mhcti_type;
uint8_t ip6mhcti_reserved;
uint16_t ip6mhcti_cksum;
uint16_t ip6mhcti_reserved2;
uint32_t ip6mhcti_cookie[2]; /* 64 bit Cookie by MN */
/* Followed by optional Mobility Options */
};
struct ip6_mh_careof_test_init {
uint8_t ip6mhcti_proto;
uint8_t ip6mhcti_hdrlen;
uint8_t ip6mhcti_type;
uint8_t ip6mhcti_reserved;
uint16_t ip6mhcti_cksum;
uint16_t ip6mhcti_reserved2;
uint32_t ip6mhcti_cookie[2]; /* 64 bit Cookie by MN */
/* Followed by optional Mobility Options */
};
struct ip6_mh_home_test {
uint8_t ip6mhht_proto;
uint8_t ip6mhht_hdrlen;
uint8_t ip6mhht_type;
uint8_t ip6mhht_reserved;
uint16_t ip6mhht_cksum;
uint16_t ip6mhht_nonce_index;
uint32_t ip6mhht_cookie[2]; /* Cookie from HOTI msg */
uint32_t ip6mhht_keygen[2]; /* 64 Bit Key by CN */
/* Followed by optional Mobility Options */
};
struct ip6_mh_home_test {
uint8_t ip6mhht_proto;
uint8_t ip6mhht_hdrlen;
uint8_t ip6mhht_type;
uint8_t ip6mhht_reserved;
uint16_t ip6mhht_cksum;
uint16_t ip6mhht_nonce_index;
uint32_t ip6mhht_cookie[2]; /* Cookie from HOTI msg */
uint32_t ip6mhht_keygen[2]; /* 64 Bit Key by CN */
/* Followed by optional Mobility Options */
};
struct ip6_mh_careof_test {
uint8_t ip6mhct_proto;
uint8_t ip6mhct_hdrlen;
uint8_t ip6mhct_type;
uint8_t ip6mhct_reserved;
uint16_t ip6mhct_cksum;
uint16_t ip6mhct_nonce_index;
uint32_t ip6mhct_cookie[2]; /* Cookie from COTI message */
uint32_t ip6mhct_keygen[2]; /* 64bit key by CN */
/* Followed by optional Mobility Options */
};
struct ip6_mh_careof_test {
uint8_t ip6mhct_proto;
uint8_t ip6mhct_hdrlen;
uint8_t ip6mhct_type;
uint8_t ip6mhct_reserved;
uint16_t ip6mhct_cksum;
uint16_t ip6mhct_nonce_index;
uint32_t ip6mhct_cookie[2]; /* Cookie from COTI message */
uint32_t ip6mhct_keygen[2]; /* 64bit key by CN */
/* Followed by optional Mobility Options */
};
struct ip6_mh_binding_update {
uint8_t ip6mhbu_proto;
uint8_t ip6mhbu_hdrlen;
uint8_t ip6mhbu_type;
uint8_t ip6mhbu_reserved;
uint16_t ip6mhbu_cksum;
uint16_t ip6mhbu_seqno; /* Sequence Number */
uint16_t ip6mhbu_flags;
uint16_t ip6mhbu_lifetime; /* Time in unit of 4 sec */
/* Followed by optional Mobility Options */
};
struct ip6_mh_binding_update {
uint8_t ip6mhbu_proto;
uint8_t ip6mhbu_hdrlen;
uint8_t ip6mhbu_type;
uint8_t ip6mhbu_reserved;
uint16_t ip6mhbu_cksum;
uint16_t ip6mhbu_seqno; /* Sequence Number */
uint16_t ip6mhbu_flags;
uint16_t ip6mhbu_lifetime; /* Time in unit of 4 sec */
/* Followed by optional Mobility Options */
};
/* Binding Update Flags, in network byte-order */
#define IP6_MH_BU_ACK 0x8000 /* Request a binding ack */
#define IP6_MH_BU_HOME 0x4000 /* Home Registration */
#define IP6_MH_BU_LLOCAL 0x2000 /* Link-local compatibility */
#define IP6_MH_BU_KEYM 0x1000 /* Key management mobility */
/* Binding Update Flags, in network byte-order */
#define IP6_MH_BU_ACK 0x8000 /* Request a binding ack */
#define IP6_MH_BU_HOME 0x4000 /* Home Registration */
#define IP6_MH_BU_LLOCAL 0x2000 /* Link-local compatibility */
#define IP6_MH_BU_KEYM 0x1000 /* Key management mobility */
struct ip6_mh_binding_ack {
uint8_t ip6mhba_proto;
uint8_t ip6mhba_hdrlen;
uint8_t ip6mhba_type;
uint8_t ip6mhba_reserved;
uint16_t ip6mhba_cksum;
uint8_t ip6mhba_status; /* Status code */
uint8_t ip6mhba_flags;
uint16_t ip6mhba_seqno;
uint16_t ip6mhba_lifetime;
/* Followed by optional Mobility Options */
};
struct ip6_mh_binding_ack {
uint8_t ip6mhba_proto;
uint8_t ip6mhba_hdrlen;
uint8_t ip6mhba_type;
uint8_t ip6mhba_reserved;
uint16_t ip6mhba_cksum;
uint8_t ip6mhba_status; /* Status code */
uint8_t ip6mhba_flags;
uint16_t ip6mhba_seqno;
uint16_t ip6mhba_lifetime;
/* Followed by optional Mobility Options */
};
/* Binding Acknowledgement Flags */
#define IP6_MH_BA_KEYM 0x80 /* Key management mobility */
/* Binding Acknowledgement Flags */
#define IP6_MH_BA_KEYM 0x80 /* Key management mobility */
struct ip6_mh_binding_error {
uint8_t ip6mhbe_proto;
uint8_t ip6mhbe_hdrlen;
uint8_t ip6mhbe_type;
uint8_t ip6mhbe_reserved;
uint16_t ip6mhbe_cksum;
uint8_t ip6mhbe_status; /* Error Status */
uint8_t ip6mhbe_reserved2;
struct in6_addr ip6mhbe_homeaddr;
/* Followed by optional Mobility Options */
};
struct ip6_mh_binding_error {
uint8_t ip6mhbe_proto;
uint8_t ip6mhbe_hdrlen;
uint8_t ip6mhbe_type;
uint8_t ip6mhbe_reserved;
uint16_t ip6mhbe_cksum;
uint8_t ip6mhbe_status; /* Error Status */
uint8_t ip6mhbe_reserved2;
struct in6_addr ip6mhbe_homeaddr;
/* Followed by optional Mobility Options */
};
struct ip6_mh_opt {
uint8_t ip6mhopt_type; /* Option Type */
uint8_t ip6mhopt_len; /* Option Length */
/* Followed by variable length Option Data in bytes */
};
struct ip6_mh_opt {
uint8_t ip6mhopt_type; /* Option Type */
uint8_t ip6mhopt_len; /* Option Length */
/* Followed by variable length Option Data in bytes */
};
struct ip6_mh_opt_refresh_advice {
uint8_t ip6mora_type;
uint8_t ip6mora_len;
uint16_t ip6mora_interval; /* Refresh interval in 4 sec */
};
struct ip6_mh_opt_refresh_advice {
uint8_t ip6mora_type;
uint8_t ip6mora_len;
uint16_t ip6mora_interval; /* Refresh interval in 4 sec */
};
struct ip6_mh_opt_altcoa {
uint8_t ip6moa_type;
uint8_t ip6moa_len;
struct in6_addr ip6moa_addr; /* Alternate CoA */
};
struct ip6_mh_opt_altcoa {
uint8_t ip6moa_type;
uint8_t ip6moa_len;
struct in6_addr ip6moa_addr; /* Alternate CoA */
};
struct ip6_mh_opt_nonce_index {
uint8_t ip6moni_type;
uint8_t ip6moni_len;
uint16_t ip6moni_home_nonce;
uint16_t ip6moni_coa_nonce;
};
struct ip6_mh_opt_nonce_index {
uint8_t ip6moni_type;
uint8_t ip6moni_len;
uint16_t ip6moni_home_nonce;
uint16_t ip6moni_coa_nonce;
};
struct ip6_mh_opt_auth_data {
uint8_t ip6moad_type;
uint8_t ip6moad_len;
uint8_t ip6moad_data[12];
};
struct ip6_mh_opt_auth_data {
uint8_t ip6moad_type;
uint8_t ip6moad_len;
uint8_t ip6moad_data[12];
};
IPv6 Next Header Value for Mobility:
用于移动性的IPv6下一个标头值：
<netinet/in.h>
<netinet/in.h>
#define IPPROTO_MH 135 /* IPv6 Mobility Header: IANA */
#define IPPROTO_MH 135 /* IPv6 Mobility Header: IANA */
Mobility Header Message Types:
移动头消息类型：
<netinet/ip6mh.h>
<netinet/ip6mh.h>
#define IP6_MH_TYPE_BRR 0 /* Binding Refresh Request */
#define IP6_MH_TYPE_HOTI 1 /* HOTI Message */
#define IP6_MH_TYPE_COTI 2 /* COTI Message */
#define IP6_MH_TYPE_HOT 3 /* HOT Message */
#define IP6_MH_TYPE_COT 4 /* COT Message */
#define IP6_MH_TYPE_BU 5 /* Binding Update */
#define IP6_MH_TYPE_BACK 6 /* Binding ACK */
#define IP6_MH_TYPE_BERROR 7 /* Binding Error */
#define IP6_MH_TYPE_BRR 0 /* Binding Refresh Request */
#define IP6_MH_TYPE_HOTI 1 /* HOTI Message */
#define IP6_MH_TYPE_COTI 2 /* COTI Message */
#define IP6_MH_TYPE_HOT 3 /* HOT Message */
#define IP6_MH_TYPE_COT 4 /* COT Message */
#define IP6_MH_TYPE_BU 5 /* Binding Update */
#define IP6_MH_TYPE_BACK 6 /* Binding ACK */
#define IP6_MH_TYPE_BERROR 7 /* Binding Error */
Mobility Header Message Option Types:
移动头消息选项类型：
<netinet/ip6mh.h>
<netinet/ip6mh.h>
#define IP6_MHOPT_PAD1 0x00 /* PAD1 */
#define IP6_MHOPT_PADN 0x01 /* PADN */
#define IP6_MHOPT_BREFRESH 0x02 /* Binding Refresh */
#define IP6_MHOPT_ALTCOA 0x03 /* Alternate COA */
#define IP6_MHOPT_NONCEID 0x04 /* Nonce Index */
#define IP6_MHOPT_BAUTH 0x05 /* Binding Auth Data */
#define IP6_MHOPT_PAD1 0x00 /* PAD1 */
#define IP6_MHOPT_PADN 0x01 /* PADN */
#define IP6_MHOPT_BREFRESH 0x02 /* Binding Refresh */
#define IP6_MHOPT_ALTCOA 0x03 /* Alternate COA */
#define IP6_MHOPT_NONCEID 0x04 /* Nonce Index */
#define IP6_MHOPT_BAUTH 0x05 /* Binding Auth Data */
Status values accompanied with Mobility Binding Acknowledgement:
带有移动性绑定确认的状态值：
<netinet/ip6mh.h>
<netinet/ip6mh.h>
#define IP6_MH_BAS_ACCEPTED 0 /* BU accepted */
#define IP6_MH_BAS_PRFX_DISCOV 1 /* Accepted, but prefix
discovery Required */
#define IP6_MH_BAS_UNSPECIFIED 128 /* Reason unspecified */
#define IP6_MH_BAS_PROHIBIT 129 /* Administratively
prohibited */
#define IP6_MH_BAS_INSUFFICIENT 130 /* Insufficient
resources */
#define IP6_MH_BAS_HA_NOT_SUPPORTED 131 /* HA registration not
supported */
#define IP6_MH_BAS_NOT_HOME_SUBNET 132 /* Not Home subnet */
#define IP6_MH_BAS_NOT_HA 133 /* Not HA for this
mobile node */
#define IP6_MH_BAS_DAD_FAILED 134 /* DAD failed */
#define IP6_MH_BAS_SEQNO_BAD 135 /* Sequence number out
of range */
#define IP6_MH_BAS_ACCEPTED 0 /* BU accepted */
#define IP6_MH_BAS_PRFX_DISCOV 1 /* Accepted, but prefix
discovery Required */
#define IP6_MH_BAS_UNSPECIFIED 128 /* Reason unspecified */
#define IP6_MH_BAS_PROHIBIT 129 /* Administratively
prohibited */
#define IP6_MH_BAS_INSUFFICIENT 130 /* Insufficient
resources */
#define IP6_MH_BAS_HA_NOT_SUPPORTED 131 /* HA registration not
supported */
#define IP6_MH_BAS_NOT_HOME_SUBNET 132 /* Not Home subnet */
#define IP6_MH_BAS_NOT_HA 133 /* Not HA for this
mobile node */
#define IP6_MH_BAS_DAD_FAILED 134 /* DAD failed */
#define IP6_MH_BAS_SEQNO_BAD 135 /* Sequence number out
of range */
#define IP6_MH_BAS_HOME_NI_EXPIRED 136 /* Expired Home nonce
index */
#define IP6_MH_BAS_COA_NI_EXPIRED 137 /* Expired Care-of
nonce index */
#define IP6_MH_BAS_NI_EXPIRED 138 /* Expired Nonce
Indices */
#define IP6_MH_BAS_REG_NOT_ALLOWED 139 /* Registration type
change disallowed */
#define IP6_MH_BAS_HOME_NI_EXPIRED 136 /* Expired Home nonce
index */
#define IP6_MH_BAS_COA_NI_EXPIRED 137 /* Expired Care-of
nonce index */
#define IP6_MH_BAS_NI_EXPIRED 138 /* Expired Nonce
Indices */
#define IP6_MH_BAS_REG_NOT_ALLOWED 139 /* Registration type
change disallowed */
Status values for the Binding Error mobility messages:
绑定错误移动消息的状态值：
<netinet/ip6mh.h>
<netinet/ip6mh.h>
#define IP6_MH_BES_UNKNOWN_HAO 1 /* Unknown binding for HOA */
#define IP6_MH_BES_UNKNOWN_MH 2 /* Unknown MH Type */
#define IP6_MH_BES_UNKNOWN_HAO 1 /* Unknown binding for HOA */
#define IP6_MH_BES_UNKNOWN_MH 2 /* Unknown MH Type */
Due to alignment issues in the compiler, and the alignment requirements for this option, the included IPv6 address must be specified as an array of 16 octets.
由于编译器中存在对齐问题以及此选项的对齐要求，必须将包含的IPv6地址指定为16个八位字节的数组。
<netinet/ip6.h>
<netinet/ip6.h>
/* Home Address Destination Option */
struct ip6_opt_home_address {
uint8_t ip6oha_type;
uint8_t ip6oha_len;
uint8_t ip6oha_addr[16]; /* Home Address */
};
/* Home Address Destination Option */
struct ip6_opt_home_address {
uint8_t ip6oha_type;
uint8_t ip6oha_len;
uint8_t ip6oha_addr[16]; /* Home Address */
};
Option Type Definition:
选项类型定义：
#define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */
#define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */
<netinet/ip6.h>
<netinet/ip6.h>
/* Type 2 Routing header for Mobile IPv6 */
struct ip6_rthdr2 {
uint8_t ip6r2_nxt; /* next header */
uint8_t ip6r2_len; /* length : always 2 */
uint8_t ip6r2_type; /* always 2 */
uint8_t ip6r2_segleft; /* segments left: always 1 */
uint32_t ip6r2_reserved; /* reserved field */
struct in6_addr ip6r2_homeaddr; /* Home Address */
};
/* Type 2 Routing header for Mobile IPv6 */
struct ip6_rthdr2 {
uint8_t ip6r2_nxt; /* next header */
uint8_t ip6r2_len; /* length : always 2 */
uint8_t ip6r2_type; /* always 2 */
uint8_t ip6r2_segleft; /* segments left: always 1 */
uint32_t ip6r2_reserved; /* reserved field */
struct in6_addr ip6r2_homeaddr; /* Home Address */
};
ICMP message types and definitions for Mobile IPv6 are defined in <netinet/icmp6.h>.
移动IPv6的ICMP消息类型和定义在<netinet/icmp6.h>中定义。
#define MIP6_HA_DISCOVERY_REQUEST 144 #define MIP6_HA_DISCOVERY_REPLY 145 #define MIP6_PREFIX_SOLICIT 146 #define MIP6_PREFIX_ADVERT 147
#定义MIP6_HA_DISCOVERY_请求144#定义MIP6_HA_DISCOVERY_回复145#定义MIP6_前缀(请求146#定义MIP6_前缀)广告147
The following data structures can be used for the ICMP message types discussed in Sections 6.5 through 6.8 in the base Mobile IPv6 [2] specification.
以下数据结构可用于基本移动IPv6[2]规范第6.5节至第6.8节中讨论的ICMP消息类型。
struct mip6_dhaad_req { /* Dynamic HA Address Discovery */
struct icmp6_hdr mip6_dhreq_hdr;
};
struct mip6_dhaad_req { /* Dynamic HA Address Discovery */
struct icmp6_hdr mip6_dhreq_hdr;
};
#define mip6_dhreq_type mip6_dhreq_hdr.icmp6_type #define mip6_dhreq_code mip6_dhreq_hdr.icmp6_code #define mip6_dhreq_cksum mip6_dhreq_hdr.icmp6_cksum #define mip6_dhreq_id mip6_dhreq_hdr.icmp6_data16[0] #define mip6_dhreq_reserved mip6_dhreq_hdr.icmp6_data16[1]
#定义mip6_dhreq_类型mip6_dhreq_hdr.icmp6_类型#定义mip6_dhreq_hdr.icmp6_代码#定义mip6_dhreq_cksum mip6_dhreq_hdr.icmp6_cksum#定义mip6_dhreq_id mip6_dhreq_hdr.icmp6_数据16[0]#定义mip6_dhreq_保留数据(
struct mip6_dhaad_rep { /* HA Address Discovery Reply */
struct icmp6_hdr mip6_dhrep_hdr;
/* Followed by Home Agent IPv6 addresses */
};
struct mip6_dhaad_rep { /* HA Address Discovery Reply */
struct icmp6_hdr mip6_dhrep_hdr;
/* Followed by Home Agent IPv6 addresses */
};
#define mip6_dhrep_type mip6_dhrep_hdr.icmp6_type #define mip6_dhrep_code mip6_dhrep_hdr.icmp6_code #define mip6_dhrep_cksum mip6_dhrep_hdr.icmp6_cksum #define mip6_dhrep_id mip6_dhrep_hdr.icmp6_data16[0] #define mip6_dhrep_reserved mip6_dhrep_hdr.icmp6_data16[1]
#定义mip6_dhrep_类型mip6_dhrep_hdr.icmp6_类型#定义mip6_dhrep_hdr.icmp6_代码#定义mip6_dhrep u cksum mip6_dhrep u hdr.icmp6_cksum#定义mip6_dhrep id mip6_dhrep hdr.icmp6_数据16[0]#定义mip6_dhrep u保留的数据(
struct mip6_prefix_solicit { /* Mobile Prefix Solicitation */
struct icmp6_hdr mip6_ps_hdr;
};
struct mip6_prefix_solicit { /* Mobile Prefix Solicitation */
struct icmp6_hdr mip6_ps_hdr;
};
#define mip6_ps_type mip6_ps_hdr.icmp6_type #define mip6_ps_code mip6_ps_hdr.icmp6_code #define mip6_ps_cksum mip6_ps_hdr.icmp6_cksum #define mip6_ps_id mip6_ps_hdr.icmp6_data16[0] #define mip6_ps_reserved mip6_ps_hdr.icmp6_data16[1]
#定义mip6_ps_类型mip6_ps_hdr.icmp6_类型定义mip6_ps_代码mip6_ps_hdr.icmp6_代码定义mip6_ps_cksum mip6_ps_hdr.icmp6_cksum定义mip6_id mip6_ps_hdr.icmp6_数据16[0]#定义6_ps_保留的mip6_hdr.icmp6数据icmp6[1]
struct mip6_prefix_advert { /* Mobile Prefix Advertisements */
struct icmp6_hdr mip6_pa_hdr;
/* Followed by one or more PI options */
};
struct mip6_prefix_advert { /* Mobile Prefix Advertisements */
struct icmp6_hdr mip6_pa_hdr;
/* Followed by one or more PI options */
};
#define mip6_pa_type mip6_pa_hdr.icmp6_type #define mip6_pa_code mip6_pa_hdr.icmp6_code #define mip6_pa_cksum mip6_pa_hdr.icmp6_cksum #define mip6_pa_id mip6_pa_hdr.icmp6_data16[0] #define mip6_pa_flags_reserved mip6_pa_hdr.icmp6_data16[1]
#定义mip6_pa_类型mip6_pa_hdr.icmp6_类型#定义mip6_pa_代码mip6_pa_hdr.icmp6_代码#定义mip6_pa_cksum mip6_hdr.icmp6_cksum#定义mip6_pa id mip6_pa_hdr.icmp6_数据16[0]#定义6_pa标志6保留数据[icmp1]
/* Mobile Prefix Advertisement Flags in network-byte order */
#define MIP6_PA_FLAG_MANAGED 0x8000
#define MIP6_PA_FLAG_OTHER 0x4000
/* Mobile Prefix Advertisement Flags in network-byte order */
#define MIP6_PA_FLAG_MANAGED 0x8000
#define MIP6_PA_FLAG_OTHER 0x4000
Prefix options are defined in IPv6 Advanced Socket API [1]. The Mobile IPv6 Base specification [2] describes the modified behavior in the 'Modifications to IPv6 Neighbor Discovery' section. Prefix Options for Mobile IP are defined in the following section.
前缀选项在IPv6高级套接字API[1]中定义。移动IPv6基本规范[2]在“修改IPv6邻居发现”部分中描述了修改后的行为。移动IP的前缀选项在下一节中定义。
IPv6 Neighbor Discovery changes are also defined in <netinet/icmp6.h>.
IPv6邻居发现更改也在<netinet/icmp6.h>中定义。
New 'Home Agent' flag in router advertisement: #define
ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */
New 'Home Agent' flag in router advertisement: #define
ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */
New Router flag with prefix information of the home agent:
#define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */
New Router flag with prefix information of the home agent:
#define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */
As per the Mobile IPv6 specification [2], Section 7.2, a Home Agent MUST include at least one prefix option with the Router Address (R) bit set. Advanced Socket API [1] defines data structure for prefix option as follows:
根据移动IPv6规范[2]，第7.2节，归属代理必须包括至少一个路由器地址（R）位设置的前缀选项。高级套接字API[1]定义前缀选项的数据结构如下：
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;
};
New advertisement interval option and home agent information options are defined in Mobile IPv6 [2] base specification.
移动IPv6[2]基本规范中定义了新的广告间隔选项和归属代理信息选项。
struct nd_opt_adv_interval { /* Advertisement interval option */
uint8_t nd_opt_ai_type;
uint8_t nd_opt_ai_len;
uint16_t nd_opt_ai_reserved;
uint32_t nd_opt_ai_interval;
};
struct nd_opt_adv_interval { /* Advertisement interval option */
uint8_t nd_opt_ai_type;
uint8_t nd_opt_ai_len;
uint16_t nd_opt_ai_reserved;
uint32_t nd_opt_ai_interval;
};
The option types for the new Mobile IPv6 specific options:
新的移动IPv6特定选项的选项类型：
#define ND_OPT_ADV_INTERVAL 7 /* Adv Interval Option */
#define ND_OPT_HA_INFORMATION 8 /* HA Information option */
#define ND_OPT_ADV_INTERVAL 7 /* Adv Interval Option */
#define ND_OPT_HA_INFORMATION 8 /* HA Information option */
struct nd_opt_homeagent_info { /* Home Agent information */
uint8_t nd_opt_hai_type;
uint8_t nd_opt_hai_len;
uint16_t nd_opt_hai_reserved;
uint16_t nd_opt_hai_preference;
uint16_t nd_opt_hai_lifetime;
};
struct nd_opt_homeagent_info { /* Home Agent information */
uint8_t nd_opt_hai_type;
uint8_t nd_opt_hai_len;
uint16_t nd_opt_hai_reserved;
uint16_t nd_opt_hai_preference;
uint16_t nd_opt_hai_lifetime;
};
Applications that need to be able to access Home Address destination option and Type 2 Routing Header information can do so by setting the appropriate setsockopt option and using ancillary data objects. The order of extension headers is defined in Mobile IPv6 [2] when an IPv6 packet with a Home Address Destination Option is sent with other possible extension headers. Section 5.3 elaborates on the extension header order when all possible cases are present.
需要能够访问Home Address destination option和Type 2路由头信息的应用程序可以通过设置适当的setsockopt选项并使用辅助数据对象来实现。在移动IPv6[2]中定义了扩展头的顺序，即当带有“家庭地址目的地”选项的IPv6数据包与其他可能的扩展头一起发送时。第5.3节详细说明了在所有可能的情况下，扩展标题顺序。
This document does not recommend that the user-level program set the Home Address destination option or Type 2 Routing Header option; however, for clarity it defines the order of extension headers. See Section 2 of this document for appropriate usage of sending and receiving of Home Address destination options and Type 2 Routing Header extension headers.
本文件不建议用户级程序设置Home Address destination（家庭地址目的地）选项或Type 2 Routing Header（类型2路由头）选项；然而，为了清楚起见，它定义了扩展头的顺序。有关发送和接收家庭地址目的地选项和类型2路由标头扩展标头的适当用法，请参阅本文档第2节。
This document defines a new socket option, IPV6_MIPDSTOPTS for sending Home Address destination options. In order to receive a Home Address destination option or Type 2 Route Header, applications must call setsockopt() to turn on the corresponding flag as described in IPv6 Advanced Socket API [1] ( for brevity, error checking is not performed in the examples):
本文档定义了一个新的套接字选项IPV6_MIPDSTOPTS，用于发送家庭地址目标选项。为了接收家庭地址目的地选项或类型2路由标头，应用程序必须调用setsockopt（）以打开IPv6高级套接字API[1]中所述的相应标志（为简洁起见，示例中不执行错误检查）：
int on = 1;
int on=1；
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS,
&on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS,
&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. Receiving the above information for TCP applications is not defined in this document (see Section 4.1 of Advanced Sockets API for IPv6 [1]).
当启用这些选项中的任何一个时，recvmsg（）将相应的数据作为一个或多个辅助数据对象作为控制信息返回。本文档中未定义接收TCP应用程序的上述信息（请参阅IPv6[1]的高级套接字API第4.1节）。
Note that if the IP implementation on the host does not implement the handling of Type 2 Routing Headers or Home Address options, per RFC 2460 [3] the IP stack is required to drop the packet. Thus, receiving Home Address destination option and Type 2 Routing Header at the application layer requires implementation of respective extension headers at the IP layer in the kernel, as defined in RFC3775 [2].
请注意，如果主机上的IP实现未实现类型2路由头或主地址选项的处理，则根据RFC 2460[3]，需要IP堆栈来丢弃数据包。因此，在应用层接收Home Address destination option和Type 2路由报头需要在内核的IP层实现相应的扩展报头，如RFC3775[2]中所定义。
For receiving the Home Address destination option header, the Mobile IPv6 implementation SHOULD follow the initial processing rules of the Home Address destination option (Section 9.3.1 of Mobile IPv6 [2]) before passing the information to the API level. This includes initial processing of IPSec authentication data in a packet when it exists. 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.
为了接收家庭地址目的地选项报头，移动IPv6实现应遵循家庭地址目的地选项的初始处理规则（移动IPv6[2]第9.3.1节），然后再将信息传递到API级别。这包括在数据包中存在IPSec身份验证数据时对其进行初始处理。每个目的地选项报头作为cmsghdr结构描述的一个辅助数据对象返回，cmsg_级别设置为IPPROTO_IPV6，cmsg_类型设置为IPV6_选项。
For sending the Home Address destination option, ancillary data can be used to specify the option content for a single datagram. This applies only to datagram and raw sockets, not to TCP sockets. The Advanced API [1] document restricts one IPV6_xxx ancillary data object for a particular extension header in the control buffer. Thus, there would be a single ancillary data object for the Home address destination option in an ancillary data buffer. If multiple destination options are present, then the header order should be in compliance with Section 6.3 and 9.3.2 of the Mobile IPv6 [2] base specification.
为了发送Home Address destination选项，可以使用辅助数据指定单个数据报的选项内容。这只适用于数据报和原始套接字，不适用于TCP套接字。高级API[1]文档为控制缓冲区中的特定扩展标头限制一个IPV6_xxx辅助数据对象。因此，在辅助数据缓冲器中将存在用于家庭地址目的地选项的单个辅助数据对象。如果存在多个目的地选项，则报头顺序应符合移动IPv6[2]基本规范第6.3节和第9.3.2节的规定。
For TCP data packets with the Home Address destination option, the "sticky" option may be used for all transmitted packets. The application can remove the sticky Home Destination option header by calling setsockopt() for IPV6_MIPDSTOPTS with a zero option length.
对于具有Home Address destination选项的TCP数据包，“sticky”选项可用于所有传输的数据包。应用程序可以通过调用选项长度为零的IPV6_MIPDSTOPTS的setsockopt（）来删除粘性Home Destination选项头。
Note that Section 2 of this document does not encourage setting the Home Address destination option at the user level. A Mobile IPv6 implementation should set and process the Home Address destination
请注意，本文档第2节不鼓励在用户级别设置Home Address destination选项。移动IPv6实现应设置和处理家庭地址目标
option and Routing Header Type 2 at the kernel level. The setting of Routing Header Type 2 and the Home Address destination option are described in this document for completeness and flexibility to use them in the future, if there is a need.
内核级别的选项和路由头类型2。本文档中描述了路由头类型2和家庭地址目的地选项的设置，以确保将来在需要时使用它们的完整性和灵活性。
The following socket option parameters and cmsghdr fields may be used for sending (although not a recommended usage):
以下套接字选项参数和cmsghdr字段可用于发送（尽管不建议使用）：
opt level/ optname/ optval/
cmsg_level cmsg_type cmsg_data[]
------------ ------------ ------------------------
IPPROTO_IPV6 IPV6_MIPDSTOPTS ip6_dest structure
IPPROTO_IPV6 IPV6_RTHDR ip6_rthdr structure
opt level/ optname/ optval/
cmsg_level cmsg_type cmsg_data[]
------------ ------------ ------------------------
IPPROTO_IPV6 IPV6_MIPDSTOPTS ip6_dest structure
IPPROTO_IPV6 IPV6_RTHDR ip6_rthdr structure
Some IPv6 implementations may support "sticky" options [1] for the IPv6 destination option for datagram and RAW sockets.
某些IPv6实现可能支持数据报和原始套接字的IPv6目标选项的“粘性”选项[1]。
Behavior of Legacy IPv6 Socket Applications:
旧版IPv6套接字应用程序的行为：
Legacy IPv6 applications/implementations using the Advanced Socket API [1] mechanisms, upon receiving Home Address destination options or Routing headers(Type 2), will discard the packet as per Sections 4.2 and 4.4 of IPV6 Protocol [3] specification, respectively; otherwise, they should properly handle the Home Address destination option and the Routing Header Type 2 specified in this document.
使用高级套接字API[1]机制的旧式IPv6应用程序/实现，在收到家庭地址目标选项或路由报头（类型2）后，将分别按照IPv6协议[3]规范第4.2节和第4.4节丢弃数据包；否则，他们应该正确处理本文档中指定的Home Address destination选项和Routing Header Type 2。
IPV6 Protocol [3] defines a Routing header extension header for Type 0. Thus, in order to access the IPv6 Routing header Type 2 extension header, one MUST use type = 2 and segment = 1. The following existing functions defined in Advanced API for IPv6 Sockets [1] are supported for Mobile IPv6 applications for sending and receiving Routing Header Type 2 headers:
IPV6协议[3]为类型0定义路由标头扩展标头。因此，为了访问IPv6路由头Type 2扩展头，必须使用Type=2和segment=1。移动IPv6应用程序支持在IPv6套接字的高级API[1]中定义的以下现有函数，用于发送和接收路由标头类型2标头：
For Sending:
发送：
size_t inet6_rth_space(int type, int segments);
void *inet6_rth_init(void *bp, int bp_len, int type, int segments);
int inet6_rth_add(void *bp, const struct in6_addr *addr);
size_t inet6_rth_space(int type, int segments);
void *inet6_rth_init(void *bp, int bp_len, int type, int segments);
int inet6_rth_add(void *bp, const struct in6_addr *addr);
For Receiving:
接收：
int inet6_rth_segments(const void *bp);
struct in6_addr *inet6_rth_getaddr(const void *bp, int index);
int inet6_rth_segments(const void *bp);
struct in6_addr *inet6_rth_getaddr(const void *bp, int index);
NOTE: Reversing operation is not possible using the Route Header Type 2 extension header. Thus, inet6_rth_reverse() is not used.
注意：使用2型延伸收割台的路线收割台不可能进行倒车操作。因此，不使用inet6_rth_reverse（）。
Detailed descriptions and examples of accessing an IPv6 Routing Header are discussed in the Advanced Sockets API for IPv6 [1]. However, Section 7 of Advanced API for IPv6 Sockets [1] indicates that multiple types of routing headers can be received as multiple ancillary data objects to the application (with cmsg_type set to IPV6_RTHDR). Currently, there are no API functions defined to return the routing header type. However, this document does not define a helper function, since it is easy to access the Routing Header Type field just as easily as the ip6r_segleft field. An excerpt of a code sample is provided for extracting the type of the received routing header:
访问IPv6路由头的详细描述和示例在IPv6的高级套接字API[1]中进行了讨论。但是，IPv6套接字的高级API[1]第7节指出，多种类型的路由头可以作为应用程序的多个辅助数据对象接收（cmsg_type设置为IPv6_RTHDR）。目前，没有定义用于返回路由头类型的API函数。但是，本文档没有定义帮助函数，因为它与ip6r_segleft字段一样容易访问Routing Header Type字段。提供代码示例的摘录，用于提取接收到的路由头的类型：
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;
int segments, route_type;
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;
int segments, route_type;
rthdr = (struct ip6_rthdr *)extptr;
segments = inet6_rth_segments(extptr);
printf("route (%d segments, %d left): ",
segments, rthdr->ip6r_segleft);
route_type = rthdr->ip6r_type;
if (route_type == 2) {
printf ("Routing header Type 2 present\n");
}
}
rthdr = (struct ip6_rthdr *)extptr;
segments = inet6_rth_segments(extptr);
printf("route (%d segments, %d left): ",
segments, rthdr->ip6r_segleft);
route_type = rthdr->ip6r_type;
if (route_type == 2) {
printf ("Routing header Type 2 present\n");
}
}
It is recommended that no portable applications send Type 2 Routing Header ancillary data from the application layer, since many implementations take care of that at the kernel layer and may not support the API for sending Type 2 Routing Header.
建议任何便携式应用程序都不要从应用层发送类型2路由头辅助数据，因为许多实现在内核层处理这些数据，并且可能不支持用于发送类型2路由头的API。
Mobile IPv6 [2] defines the Type 2 Routing Header to allow the packet to be routed directly from a correspondent to the mobile node's care-of address. The mobile node's care-of address is inserted into the IPv6 Destination Address field. Once the packet arrives at the care-of address, the mobile node retrieves its home address from the routing header, and this is used as the final destination address for the received IPv6 packet.
移动IPv6[2]定义了类型2路由报头，以允许数据包直接从通信方路由到移动节点的转交地址。移动节点的转交地址插入到IPv6目标地址字段中。一旦数据包到达转交地址，移动节点从路由报头检索其家庭地址，并将其用作所接收IPv6数据包的最终目的地地址。
For user-level applications that receive Type 2 Routing Header, inet6_rth_getaddr() returns the care-of address or on-the-wire destination address of the received packet. This complies with the existing Routing header Type=0 processing for IPv6 [1].
对于接收类型2路由报头的用户级应用程序，inet6_rth_getaddr（）返回接收数据包的转交地址或在线目标地址。这符合IPv6[1]的现有路由头类型=0处理。
Thus, on the receive side, the socket application will always receive data packets at its original home address. The implementations are responsible for processing the Type 2 Routing Header packet as per Mobile IPv6 RFC [2] before passing the Type 2 Routing Header information to the Socket API.
因此，在接收端，套接字应用程序将始终在其原始家庭地址接收数据包。这些实现负责在将类型2路由报头信息传递给套接字API之前，按照移动IPv6 RFC[2]处理类型2路由报头数据包。
If a pure IPv6 [3] system receives the Routing Header Type 2 packets, it will follow the process described in Section 4.4 of the IPv6 [3] base specification.
如果纯IPv6[3]系统接收到路由报头类型2数据包，它将遵循IPv6[3]基本规范第4.4节中描述的过程。
Section 6.3 of Mobile IPV6 [2] defines the extension header order for the Home address destination option.
移动IPV6[2]的第6.3节定义了Home address destination选项的扩展头顺序。
Routing Header Home Address Destination Option Fragment Header AH/ESP Header
路由头Home Address Destination选项片段头AH/ESP头
IPv6 [3] specifies that the destination header can be either before the Routing header or after the AH/ESP header if they are all present.
IPv6[3]指定目标标头可以位于路由标头之前，也可以位于AH/ESP标头之后（如果它们都存在）。
Thus, when the Home Address destination option is present along with other extension headers, the order will be:
因此，当Home Address destination选项与其他扩展头一起出现时，顺序为：
Hop-by-Hop Options header Destination Options header Routing header Destination Options [Home Address Option] Fragment header Authentication header Encapsulating Security Payload header Destination Options header upper-layer header
逐跳选项标头目的地选项标头路由标头目的地选项[家庭地址选项]片段标头身份验证标头封装安全有效负载标头目的地选项标头上层标头
Any user-level implementation or application that sends the Home address destination option through ancillary data objects should follow the order extension header defined in this document when using IPV6_MIPDSTOPTS socket options.
使用IPV6_MIPDSTOPTS套接字选项时，通过辅助数据对象发送Home address destination选项的任何用户级实现或应用程序都应遵循本文档中定义的订单扩展标题。
The application must enable the IPV6_RECVDSTOPTS socket option in order to receive the Home Address destination option (error checking is not performed in the example for brevity):
应用程序必须启用IPV6_RECVDSTOPTS套接字选项，才能接收家庭地址目标选项（为了简洁起见，本示例中不执行错误检查）：
int on = 1;
int on=1；
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));
Each Destination option 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_选项。
The received side Home Address destination option is further processed by calling the inet6_opt_next(), inet6_opt_find(), and inet6_opt_get_value() functions as defined in Advanced API for IPv6 sockets [1].
通过调用IPv6套接字的高级API中定义的inet6_opt_next（）、inet6_opt_find（）和inet6_opt_get_value（）函数，进一步处理接收端的Home Address destination选项[1]。
This document assumes that portable Mobile IPv6 applications will not send a Home Address Destination Option from the application level, as the Mobile IPv6 implementation underneath takes care of sending the Home Address option and the routing header type 2 at the kernel. However, some embedded software implementations may implement the IPv6 packet processing/sending at the user-level; those implementations may choose to provide the API support for sending a home-address option at the application layer. In this case, the Home Address destination options are normally constructed by using the inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and inet6_opt_set_val() functions, described in Section 10 of the Advanced sockets API for IPv6 [1].
本文档假设便携式移动IPv6应用程序不会从应用程序级别发送家庭地址目标选项，因为下面的移动IPv6实现负责在内核发送家庭地址选项和路由头类型2。然而，一些嵌入式软件实现可以在用户级实现IPv6分组处理/发送；这些实现可以选择为在应用层发送家庭地址选项提供API支持。在这种情况下，通常通过使用IPv6的高级套接字API[1]第10节中描述的inet6_opt_init（）、inet6_opt_append（）、inet6_opt_finish（）和inet6_opt_set_val（）函数来构造家庭地址目标选项。
The received ancillary data object for the Home Address destination option SHOULD contain the care-of address of the mobile node. It is assumed that the initial processing of the Home Address destination option will verify the validity of the home address, as described in Sections 6.3 and 9.5 of the Mobile IPv6 Specification [2], and swap the source address of the packet (COA) with the contents of Home Address destination option.
家庭地址目的地选项的接收辅助数据对象应包含移动节点的转交地址。如移动IPv6规范[2]第6.3节和第9.5节所述，假设初始处理家庭地址目的地选项将验证家庭地址的有效性，并将数据包（COA）的源地址与家庭地址目的地选项的内容交换。
Note that whether or not these new APIs are used, the sender's home address is contained in the source address (which is passed to the application using the socket-level functions recvfrom(), recvmsg(), accept(), and getpeername()). This is necessary for:
请注意，无论是否使用这些新API，发送方的家庭地址都包含在源地址中（使用套接字级别的函数recvfrom（）、recvmsg（）、accept（）和getpeername（）传递给应用程序）。这对于：
maintaining consistency between simple user-level applications running between mobile nodes and the diagnostic applications on the home agent or correspondent node that use this API;
在移动节点之间运行的简单用户级应用程序与使用此API的归属代理或对应节点上的诊断应用程序之间保持一致性；
obtaining the COA address of the mobile node when the Home Address destination option is used; and
当使用归属地址目的地选项时，获取移动节点的COA地址；和
maintaining consistency of existing IPv6 Socket APIs and processing of the Home Address destination option.
保持现有IPv6套接字API的一致性，并处理家庭地址目标选项。
If an implementation supports send-side Home Address destination API, then it must follow the same rule for data content as specified in Mobile IPv6 RFC [2] for sending a home-address option. Thus, the home-address option will contain the home address, and the implementation will use the care-of address as the source address of the outgoing packet. If the implementation uses IPSec, then it should use the content of Home Address destination option as the source address of the packet for security association. Note that regular user applications must not set the home address destination option.
如果实现支持发送端家庭地址目标API，则必须遵循移动IPv6 RFC[2]中指定的发送家庭地址选项的数据内容规则。因此，home address选项将包含home address，并且实现将使用care-of-address作为传出分组的源地址。如果实现使用IPSec，那么它应该使用Home Address destination选项的内容作为安全关联数据包的源地址。请注意，常规用户应用程序不得设置“家庭地址目标”选项。
Mobile IPv6 [2] defines a new IPv6 protocol header to carry mobility messages between Mobile Nodes, Home Agents and Correspondent Nodes. These protocol headers carry Mobile IPv6 Binding messages as well as Return Routability [2] messages. Currently the specification [2] does not allow transport packets (piggybacking) along with the mobility messages. Thus the mobility protocol header can be accessed through an IPv6 RAW socket. An IPv6 RAW socket that is opened for protocol IPPROTO_MH should always be able to see all the MH (Mobility Header) packets. It is possible that future applications may implement part of Mobile IPv6 signal processing at the application level. Having a RAW socket interface may also enable an application to execute the Return Routability protocol or other future authentication protocol involving the mobility header at the user-level.
移动IPv6[2]定义了一个新的IPv6协议头，用于在移动节点、归属代理和对应节点之间传输移动消息。这些协议头包含移动IPv6绑定消息以及返回可路由性[2]消息。目前规范[2]不允许传输数据包（搭载）和移动消息。因此，可以通过IPv6原始套接字访问移动协议头。为协议IPPROTO_MH打开的IPv6原始套接字应始终能够看到所有MH（移动头）数据包。未来的应用程序可能在应用程序级别实现移动IPv6信号处理的一部分。具有原始套接字接口还可以使应用程序能够在用户级别执行返回路由协议或涉及移动报头的其他未来认证协议。
This specification recommends that the IPv6 RAW sockets mechanism send and receive Mobility Header (MH) packets. The behavior is similar to ICMPV6 processing, where the kernel passes a copy of the mobility header packet to the receiving socket. Depending on the implementation, the kernel may process the mobility header in addition to passing the mobility header to the application. In order to comply with the restriction in the Advanced Sockets API for IPv6 [1], applications should set the IPV6_CHECKSUM socket option with
本规范建议IPv6原始套接字机制发送和接收移动头（MH）数据包。该行为类似于ICMPV6处理，内核将移动头数据包的副本传递给接收套接字。根据实现，内核除了将移动报头传递给应用程序之外，还可以处理移动报头。为了遵守IPv6[1]的高级套接字API中的限制，应用程序应将IPv6_校验和套接字选项设置为
IPPROTO_MH protocol RAW Sockets. A Mobile IPv6 implementation that supports the Mobile IPv6 API must implement Mobility Header API checksum calculations by default at the kernel for both incoming and outbound paths. A Mobile IPv6 implementation must not return error on the IPV6_CHECKSUM socket option setting, even if the socket option is a NO-OP function for that implementation because it verifies the checksum at the kernel level. The Mobility Header checksum procedure is described in the Mobile IPv6 Protocol [2] specification. Again, for application portability it is recommended that the applications set the IPV6_CHECKSUM socket option along with the RAW sockets for IPPROTO_MH protocol.
IPPROTO_MH协议原始套接字。默认情况下，支持移动IPv6 API的移动IPv6实现必须在内核中为传入和传出路径实现移动报头API校验和计算。移动IPv6实现不得在IPv6_校验和套接字选项设置上返回错误，即使套接字选项是该实现的NO-OP函数，因为它在内核级别验证校验和。移动协议校验和规范[2]中描述了移动协议的校验和过程。同样，为了应用程序的可移植性，建议应用程序设置IPV6_校验和套接字选项以及IPPROTO_MH协议的原始套接字。
As an example, a program that wants to send or receive a mobility header protocol(MH) could open a socket as follows (for brevity, the error checking is not performed in the example below):
例如，希望发送或接收移动报头协议（MH）的程序可以按如下方式打开套接字（为简洁起见，在下面的示例中不执行错误检查）：
fd = socket(AF_INET6, SOCK_RAW, IPPROTO_MH);
fd = socket(AF_INET6, SOCK_RAW, IPPROTO_MH);
int offset = 4;
setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset,
sizeof(offset));
int offset = 4;
setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset,
sizeof(offset));
For example, if an implementation likes to handle HOTI/HOT and COTI/ COT message processing, it can do so by using IPv6 RAW Sockets for IPPROTO_MH at the application layer. The same application may also set the IPV6_RECVDSTOPTS socket option for receiving Home Address destination option in a binding update [2] from the mobile node.
例如，如果一个实现喜欢处理HOTI/HOT和COTI/COT消息处理，那么它可以通过在应用层为IPPROTO_MH使用IPv6原始套接字来实现。同一应用程序还可以设置IPV6_RECVDSTOPTS套接字选项，用于在来自移动节点的绑定更新[2]中接收家庭地址目的地选项。
IPv6 RAW sockets are described in Section 3 of the IPv6 Advanced Socket API [1] specification. All data sent and received via raw sockets must be in network byte order. The data structures that are defined in this document are in network byte order, and they are believed to be supported by most compilers to hold packet formats directly for transmission on the wire.
IPv6原始套接字在IPv6高级套接字API[1]规范的第3节中进行了描述。通过原始套接字发送和接收的所有数据必须按网络字节顺序。本文档中定义的数据结构是按网络字节顺序排列的，大多数编译器都支持这些数据结构，以便直接保存数据包格式，以便在线路上传输。
The usual send/recv functions for datagram should be used for the Mobile IPv6 RAW sockets in order to send and receive data, respectively.
通常的数据报发送/接收功能应用于移动IPv6原始套接字，以便分别发送和接收数据。
Many hosts provide the file /etc/protocols, which contains the names of the various IP protocols and their protocol numbers. The protocol numbers are obtained through function getprotoXXX() functions.
许多主机提供文件/etc/protocols，其中包含各种IP协议的名称及其协议号。协议编号通过函数getprotoXXX（）获得。
The following addition should be made to the /etc/protocols file, in addition to what is defined in Section 2.4 of the Advanced Sockets API for IPv6 [1].
除了IPv6的高级套接字API[1]第2.4节中定义的内容外，还应向/etc/protocols文件添加以下内容。
The protocol number for Mobility Header:
(http://www.iana.org/assignments/protocol-numbers)
The protocol number for Mobility Header:
(http://www.iana.org/assignments/protocol-numbers)
ipv6-mh 135 # Mobility Protocol Header
ipv6 mh 135#移动协议头
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. The above statement is in compliance with Section 13 of the IPv6 Socket API [1].
本文档中定义的各种套接字选项和辅助数据规范仅适用于真正的IPv6套接字。可以使用IPv4映射的IPv6地址创建实际发送和接收IPv4数据包的IPv6套接字，但本文档中定义的选项到IPv4数据报的映射超出了本文档的范围。上述声明符合IPv6套接字API[1]第13节的规定。
The setting of the Home Address Destination option and Route Header Type 2 IPV6_RTHDR socket option may not be allowed at the application level in order to prevent denial-of-service attacks or man-in-the-middle attacks by hackers. Sending and receiving of mobility header messages are possible by IPv6 RAW sockets. Thus, it is assumed that this operation is only possible by privileged users. However, this API does not prevent the existing security threat from a hacker sending a bogus mobility header or other IPv6 packets using the Home Address option and Type 2 Routing Header extensions.
为防止黑客的拒绝服务攻击或中间人攻击，可能不允许在应用程序级别设置Home Address Destination（家庭地址目标）选项和Route Header Type 2 IPV6_RTHDR socket（路由头类型2 IPV6_RTHDR套接字）选项。IPv6原始套接字可以发送和接收移动头消息。因此，假设只有特权用户才能执行此操作。但是，此API无法防止黑客使用Home Address选项和Type 2路由报头扩展发送虚假移动报头或其他IPv6数据包所造成的现有安全威胁。
This document does not define a new protocol. However, it uses the
Mobility Header Protocol for IPv6 to define an API for the
/etc/protocols file. (ref: http://www.iana.org/assignments/protocol-
numbers)
This document does not define a new protocol. However, it uses the
Mobility Header Protocol for IPv6 to define an API for the
/etc/protocols file. (ref: http://www.iana.org/assignments/protocol-
numbers)
Thanks to Brian Haley for the thorough review of this document and many helpful comments. Keiichi Shima, Alexandru Petrescu, Ryuji Wakikawa, Vijay Devarapalli, Jim Bound, Suvidh Mathur, Karen Nielsen, Mark Borst, Vladislav Yasevich, and other mobile-ip working group members provided valuable input. Antti Tuominen suggested the routing header type function for this API document. During IESG review, Bill Fenner suggested accessing the routing header type directly for being consistent with RFC3542. A new socket option for Home Address Destination Option is added per Bill Fenner's suggestion for clarity of extension header orders. Thanks to Thomas Narten and Jari Arkko for the review of this document.
感谢Brian Haley对本文档的全面审阅和许多有用的评论。Shima Keichi、Alexandru Petrescu、Ryuji Wakikawa、Vijay Devarapalli、Jim Bound、Suvidh Mathur、Karen Nielsen、Mark Borst、Vladislav Yasevich和其他移动ip工作组成员提供了宝贵的意见。Antti Tuominen建议此API文档使用路由头类型函数。在IESG审查期间，Bill Fenner建议直接访问路由标头类型，以便与RFC3542保持一致。根据Bill Fenner的建议，添加了一个新的用于家庭地址目的地选项的套接字选项，以清晰地显示扩展标头顺序。感谢Thomas Narten和Jari Arkko对本文件的审阅。
[1] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[1] Stevens，W.，Thomas，M.，Nordmark，E.，和T.Jinmei，“IPv6的高级套接字应用程序接口（API）”，RFC 3542，2003年5月。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[2] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[3] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[4] Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[5] Nordmark, E., "IPv6 Socket API for source address selection", Work in Progress, July 2005.
[5] Nordmark，E.，“用于源地址选择的IPv6套接字API”，正在进行的工作，2005年7月。
[6] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[6] Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
Authors' Addresses
作者地址
Samita Chakrabarti
萨米塔查克拉巴蒂
EMail: samitac2@gmail.com
EMail: samitac2@gmail.com
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94025 USA
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park，加利福尼亚州94025
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。