Network Working Group D. Haskin
Request for Comments: 2472 E. Allen
Obsoletes: 2023 Bay Networks, Inc.
Category: Standards Track December 1998
Network Working Group D. Haskin
Request for Comments: 2472 E. Allen
Obsoletes: 2023 Bay Networks, Inc.
Category: Standards Track December 1998
IP Version 6 over PPP
PPP上的IP版本6
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
点到点协议（PPP）[1]提供了通过点到点链路封装网络层协议信息的标准方法。PPP还定义了一个可扩展的链路控制协议，并提出了一系列网络控制协议（NCP），用于建立和配置不同的网络层协议。
This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links.
本文件定义了通过PPP链路传输IP版本6[2]数据包的方法，以及用于通过PPP建立和配置IPv6的网络控制协议（NCP）。它还指定了在PPP链路上形成IPv6链路本地地址的方法。
Table of Contents
目录
1. Introduction .......................................... 2
1.1. Specification of Requirements ..................... 2
2. Sending IPv6 Datagrams ................................ 2
3. A PPP Network Control Protocol for IPv6 ............... 3
4. IPV6CP Configuration Options .......................... 4
4.1. Interface-Identifier .............................. 4
4.2. IPv6-Compression-Protocol.......................... 9
5. Stateless Autoconfiguration and Link-Local Addresses .. 10
6 Security Considerations ............................... 11
7 Acknowledgments ....................................... 11
8 Changes from RFC-2023 ................................. 11
9 References ............................................ 12
10 Authors' Addresses .................................... 13
1. Introduction .......................................... 2
1.1. Specification of Requirements ..................... 2
2. Sending IPv6 Datagrams ................................ 2
3. A PPP Network Control Protocol for IPv6 ............... 3
4. IPV6CP Configuration Options .......................... 4
4.1. Interface-Identifier .............................. 4
4.2. IPv6-Compression-Protocol.......................... 9
5. Stateless Autoconfiguration and Link-Local Addresses .. 10
6 Security Considerations ............................... 11
7 Acknowledgments ....................................... 11
8 Changes from RFC-2023 ................................. 11
9 References ............................................ 12
10 Authors' Addresses .................................... 13
11 Full Copyright Statement .............................. 14
11 Full Copyright Statement .............................. 14
PPP has three main components:
PPP有三个主要组成部分：
1) A method for encapsulating datagrams over serial links.
1) 一种通过串行链路封装数据报的方法。
2) A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
2) 一种链路控制协议（LCP），用于建立、配置和测试数据链路连接。
3) A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
3) 用于建立和配置不同网络层协议的一系列网络控制协议（NCP）。
In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link.
为了在点到点链路上建立通信，PPP链路的每一端必须首先发送LCP数据包以配置和测试数据链路。链路建立并根据LCP的需要协商可选设施后，PPP必须发送NCP数据包以选择和配置一个或多个网络层协议。一旦配置了所选的每个网络层协议，就可以通过链路发送来自每个网络层协议的数据报。
In this document, the NCP for establishing and configuring the IPv6 over PPP is referred as the IPv6 Control Protocol (IPV6CP).
在本文档中，用于通过PPP建立和配置IPv6的NCP称为IPv6控制协议（IPV6CP）。
The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (power failure at the other end, carrier drop, etc.).
链路将保持通信配置，直到显式LCP或NCP数据包关闭链路，或者直到发生某些外部事件（另一端断电、载波掉线等）。
In this document, several words are used to signify the requirements of the specification.
在本文件中，使用了几个词来表示规范的要求。
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 [7].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[7]中所述进行解释。
Before any IPv6 packets may be communicated, PPP MUST reach the Network-Layer Protocol phase, and the IPv6 Control Protocol MUST reach the Opened state.
在传输任何IPv6数据包之前，PPP必须达到网络层协议阶段，并且IPv6控制协议必须达到打开状态。
Exactly one IPv6 packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0057 (Internet Protocol Version 6).
PPP数据链路层帧的信息字段中封装了一个IPv6数据包，其中协议字段指示hex 0057类型（互联网协议版本6）。
The maximum length of an IPv6 packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. PPP links supporting IPv6 MUST allow the information field at least as large as the minimum link MTU size required for IPv6 [2].
通过PPP链路传输的IPv6数据包的最大长度与PPP数据链路层帧的信息字段的最大长度相同。支持IPv6的PPP链路必须允许信息字段至少与IPv6所需的最小链路MTU大小相同[2]。
The IPv6 Control Protocol (IPV6CP) is responsible for configuring, enabling, and disabling the IPv6 protocol modules on both ends of the point-to-point link. IPV6CP uses the same packet exchange mechanism as the Link Control Protocol (LCP). IPV6CP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. IPV6CP packets received before this phase is reached should be silently discarded.
IPv6控制协议（IPV6CP）负责配置、启用和禁用点到点链路两端的IPv6协议模块。IPV6CP使用与链路控制协议（LCP）相同的数据包交换机制。IPV6CP数据包在PPP达到网络层协议阶段之前不得交换。在到达此阶段之前收到的IPV6CP数据包应自动丢弃。
The IPv6 Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions:
IPv6控制协议与链路控制协议[1]完全相同，但有以下例外：
Data Link Layer Protocol Field
数据链路层协议字段
Exactly one IPV6CP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8057 (IPv6 Control Protocol).
PPP数据链路层帧的信息字段中封装了一个IPV6CP数据包，其中协议字段指示hex 8057类型（IPv6控制协议）。
Code field
代码字段
Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects.
仅使用代码1至7（配置请求、配置确认、配置Nak、配置拒绝、终止请求、终止确认和代码拒绝）。其他代码应视为无法识别，并应导致代码拒绝。
Timeouts
超时
IPV6CP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time.
IPV6CP数据包在PPP达到网络层协议阶段之前不得交换。在等待配置Ack或其他响应超时之前，实现应该准备等待身份验证和链路质量确定完成。建议只有在用户干预或可配置的时间量之后，实现才会放弃。
Configuration Option Types
配置选项类型
IPV6CP has a distinct set of Configuration Options.
IPV6CP有一组独特的配置选项。
IPV6CP Configuration Options allow negotiation of desirable IPv6 parameters. IPV6CP uses the same Configuration Option format defined for LCP [1], with a separate set of Options. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed.
IPV6CP配置选项允许协商理想的IPv6参数。IPV6CP使用为LCP[1]定义的相同配置选项格式，并带有一组单独的选项。如果配置请求数据包中未包含配置选项，则假定该配置选项的默认值。
Up-to-date values of the IPV6CP Option Type field are specified in the most recent "Assigned Numbers" RFC [4]. Current values are assigned as follows:
IPV6CP选项类型字段的最新值在最新的“分配编号”RFC[4]中指定。当前值分配如下：
1 Interface-Identifier 2 IPv6-Compression-Protocol
1接口标识符2 IPv6压缩协议
The only IPV6CP options defined in this document are Interface-Identifier and IPv6-Compression-Protocol. Any other IPV6CP configuration options that can be defined over time are to be defined in separate documents.
本文档中定义的唯一IPV6CP选项是接口标识符和IPv6压缩协议。可以随时间定义的任何其他IPV6CP配置选项将在单独的文档中定义。
Description
描述
This Configuration Option provides a way to negotiate a unique 64- bit interface identifier to be used for the address autoconfiguration [3] at the local end of the link (see section 5). A Configure-Request MUST contain exactly one instance of the Interface-Identifier option [1]. The interface identifier MUST be unique within the PPP link; i.e. upon completion of the negotiation different Interface-Identifier values are to be selected for the ends of the PPP link. The interface identifier MAY also be unique over a broader scope.
此配置选项提供了一种协商唯一64位接口标识符的方法，该标识符将用于链路本地端的地址自动配置[3]（参见第5节）。配置请求必须仅包含接口标识符选项[1]的一个实例。接口标识符在PPP链路中必须是唯一的；i、 e.协商完成后，将为PPP链路的末端选择不同的接口标识符值。接口标识符在更大范围内也可能是唯一的。
Before this Configuration Option is requested, an implementation chooses its tentative Interface-Identifier. The non-zero value of the tentative Interface-Identifier SHOULD be chosen such that the value is both unique to the link and, if possible, consistently reproducible across initializations of the IPV6CP finite state machine (administrative Close and reOpen, reboots, etc). The rationale for preferring a consistently reproducible unique interface identifier to a completely random interface identifier is to provide stability to global scope addresses that can be formed from the interface identifier.
在请求此配置选项之前，实现选择其暂定接口标识符。应选择暂定接口标识符的非零值，以便该值对于链路是唯一的，并且如果可能，在IPV6CP有限状态机的初始化过程中（管理关闭和重新打开、重新启动等）始终可重复。与完全随机的接口标识符相比，首选一致可再现的唯一接口标识符的基本原理是为可由接口标识符形成的全局范围地址提供稳定性。
Assuming that interface identifier bits are numbered from 0 to 63 in canonical bit order where the most significant bit is the bit number 0, the bit number 6 is the "u" bit (universal/local bit
假设接口标识符位按规范位顺序从0到63编号，其中最高有效位为位号0，位号6为“u”位（通用/本地位
in IEEE EUI-64 [5] terminology) which indicates whether or not the interface identifier is based on a globally unique IEEE identifier (EUI-48 or EUI-64 [5]) (see the case 1 below). It is set to one (1) if a globally unique IEEE identifier is used to derive the interface identifier, and it is set to zero (0) otherwise.
在IEEE EUI-64[5]术语中，表示接口标识符是否基于全局唯一的IEEE标识符（EUI-48或EUI-64[5]）（见下面的案例1）。如果使用全局唯一的IEEE标识符派生接口标识符，则将其设置为一（1），否则将其设置为零（0）。
The following are methods for choosing the tentative Interface Identifier in the preference order:
以下是按首选项顺序选择暂定接口标识符的方法：
1) If an IEEE global identifier (EUI-48 or EUI-64) is available anywhere on the node, it should be used to construct the tentative Interface-Identifier due to its uniqueness properties. When extracting an IEEE global identifier from another device on the node, care should be taken to that the extracted identifier is presented in canonical ordering [8].
1) 如果IEEE全局标识符（EUI-48或EUI-64）在节点上的任何位置都可用，则由于其唯一性属性，应使用它来构造暂定接口标识符。从节点上的另一个设备提取IEEE全局标识符时，应注意提取的标识符以规范顺序呈现[8]。
The only transformation from an EUI-64 identifier is to invert the "u" bit (universal/local bit in IEEE EUI-64 terminology). For example, for a globally unique EUI-64 identifier of the form:
EUI-64标识符的唯一转换是反转“u”位（IEEE EUI-64术语中的通用/本地位）。例如，对于表单的全局唯一EUI-64标识符：
most-significant least-significant
bit bit
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
most-significant least-significant
bit bit
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
where "c" are the bits of the assigned company_id, "0" is the value of the universal/local bit to indicate global scope, "g" is group/individual bit, and "e" are the bits of the extension identifier,
其中，“c”是分配的公司id的位，“0”是表示全局范围的通用/本地位的值，“g”是组/单个位，“e”是扩展标识符的位，
the IPv6 interface identifier would be of the form:
IPv6接口标识符的格式为：
most-significant least-significant
bit bit
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
most-significant least-significant
bit bit
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
The only change is inverting the value of the universal/local bit.
唯一的变化是反转通用/本地位的值。
In the case of a EUI-48 identifier, it is first converted to the EUI-64 format by inserting two bytes, with hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the company_id and extension-identifier portions of the EUI-48 value). For example, for a globally unique 48 bit EUI-48 identifier of the form:
在EUI-48标识符的情况下，首先通过在48位MAC的中间插入两个字节（具有0xFF和0xFE的十六进制值）（UEY-YID和EUI-48值的扩展标识符部分之间），将其转换为EUI64格式。例如，对于表单的全局唯一48位EUI-48标识符：
most-significant least-significant
bit bit
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+
most-significant least-significant
bit bit
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+
where "c" are the bits of the assigned company_id, "0" is the value of the universal/local bit to indicate global scope, "g" is group/individual bit, and "e" are the bits of the extension identifier, the IPv6 interface identifier would be of the form:
其中，“c”是分配的公司id的位，“0”是表示全局范围的通用/本地位的值，“g”是组/单个位，“e”是扩展标识符的位，IPv6接口标识符的形式如下：
most-significant least-significant
bit bit
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
most-significant least-significant
bit bit
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
2) If an IEEE global identifier is not available a different source of uniqueness should be used. Suggested sources of uniqueness include link-layer addresses, machine serial numbers, et cetera.
2) 如果IEEE全局标识符不可用，则应使用不同的唯一性源。建议的唯一性来源包括链路层地址、机器序列号等。
In this case the "u" bit of the interface identifier MUST be set to zero (0).
在这种情况下，接口标识符的“u”位必须设置为零（0）。
3) If a good source of uniqueness cannot be found, it is recommended that a random number be generated. In this case the "u" bit of the interface identifier MUST be set to zero (0).
3) 如果无法找到良好的唯一性来源，建议生成一个随机数。在这种情况下，接口标识符的“u”位必须设置为零（0）。
Good sources [1] of uniqueness or randomness are required for the Interface-Identifier negotiation to succeed. If neither a unique number or a random number can be generated it is recommended that a zero value be used for the Interface-Identifier transmitted in the Configure-Request. In this case the PPP peer may provide a valid non-zero Interface-Identifier in its response as described below. Note that if at least one of the PPP peers is able to generate separate non-zero numbers for itself and its peer, the identifier negotiation will succeed.
接口标识符协商要成功，需要具有唯一性或随机性的良好来源[1]。如果无法生成唯一数或随机数，建议在配置请求中传输的接口标识符使用零值。在这种情况下，PPP对等方可在其响应中提供有效的非零接口标识符，如下所述。请注意，如果至少一个PPP对等方能够为其自身及其对等方生成单独的非零编号，则标识符协商将成功。
When a Configure-Request is received with the Interface-Identifier Configuration Option and the receiving peer implements this option, the received Interface-Identifier is compared with the Interface-Identifier of the last Configure-Request sent to the peer. Depending on the result of the comparison an implementation MUST respond in one of the following ways:
当使用Interface Identifier Configuration（接口标识符配置）选项接收到配置请求且接收对等方实现此选项时，将接收到的接口标识符与发送给对等方的最后一个配置请求的接口标识符进行比较。根据比较结果，实现必须以以下方式之一作出响应：
If the two Interface-Identifiers are different but the received Interface-Identifier is zero, a Configure-Nak is sent with a non-zero Interface-Identifier value suggested for use by the remote peer. Such a suggested Interface-Identifier MUST be different from the Interface-Identifier of the last Configure-Request sent to the peer. It is recommended that the value suggested be consistently reproducible across initializations of the IPV6CP finite state machine (administrative Close and reOpen, reboots, etc). The "u" universal/local) bit of the suggested identifier MUST be set to zero (0) regardless of its source unless the globally unique EUI-48/EUI-64 derived identifier is provided for the exclusive use by the remote peer.
如果两个接口标识符不同，但接收到的接口标识符为零，则发送带有非零接口标识符值的Configure Nak，该值建议远程对等方使用。这种建议的接口标识符必须不同于发送给对等方的最后一个配置请求的接口标识符。建议建议的值在IPV6CP有限状态机的初始化（管理关闭和重新打开、重新启动等）过程中始终可重复。建议标识符的“u”通用/本地）位必须设置为零（0），无论其来源如何，除非提供全局唯一的EUI-48/EUI-64派生标识符供远程对等方专用。
If the two Interface-Identifiers are different and the received Interface-Identifier is not zero, the Interface-Identifier MUST be acknowledged, i.e. a Configure-Ack is sent with the requested Interface-Identifier, meaning that the responding peer agrees with the Interface-Identifier requested.
如果两个接口标识符不同且接收到的接口标识符不为零，则必须确认接口标识符，即，发送带有请求的接口标识符的配置确认，这意味着响应的对等方同意请求的接口标识符。
If the two Interface-Identifiers are equal and are not zero, a Configure-Nak MUST be sent specifying a different non-zero Interface-Identifier value suggested for use by the remote peer. It is recommended that the value suggested be consistently reproducible across initializations of the IPV6CP finite state machine (administrative Close and reOpen, reboots, etc). The "u" universal/local) bit of the suggested identifier MUST be set to zero (0) regardless of its source unless the globally unique EUI-48/EUI-64 derived identifier is provided for the exclusive use by the remote peer.
如果两个接口标识符相等且不为零，则必须发送配置Nak，指定建议远程对等方使用的不同非零接口标识符值。建议建议的值在IPV6CP有限状态机的初始化（管理关闭和重新打开、重新启动等）过程中始终可重复。建议标识符的“u”通用/本地）位必须设置为零（0），无论其来源如何，除非提供全局唯一的EUI-48/EUI-64派生标识符供远程对等方专用。
If the two Interface-Identifiers are equal to zero, the Interface-Identifiers negotiation MUST be terminated by transmitting the Configure-Reject with the Interface-Identifier value set to zero. In this case a unique Interface-Identifier can not be negotiated.
如果两个接口标识符等于零，则必须在接口标识符值设置为零的情况下通过传输配置拒绝来终止接口标识符协商。在这种情况下，无法协商唯一的接口标识符。
If a Configure-Request is received with the Interface-Identifier Configuration Option and the receiving peer does not implement this option, Configure-Rej is sent.
如果使用Interface Identifier Configuration（接口标识符配置）选项接收到配置请求，并且接收端未实现此选项，则发送Configure Rej。
A new Configure-Request SHOULD NOT be sent to the peer until normal processing would cause it to be sent (that is, until a Configure-Nak is received or the Restart timer runs out).
在正常处理将导致发送新的配置请求之前（即，在收到配置Nak或重启计时器用完之前），不应将新的配置请求发送给对等方。
A new Configure-Request MUST NOT contain the Interface-Identifier option if a valid Interface-Identifier Configure-Reject is received.
如果收到有效的接口标识符配置拒绝，则新的配置请求不得包含接口标识符选项。
Reception of a Configure-Nak with a suggested Interface-Identifier different from that of the last Configure-Nak sent to the peer indicates a unique Interface-Identifier. In this case a new Configure-Request MUST be sent with the identifier value suggested in the last Configure-Nak from the peer. But if the received Interface-Identifier is equal to the one sent in the last Configure-Nak, a new Interface-Identifier MUST be chosen. In this case, a new Configure-Request SHOULD be sent with the new tentative Interface-Identifier. This sequence (transmit Configure-Request, receive Configure-Request, transmit Configure-Nak, receive Configure-Nak) might occur a few times, but it is extremely unlikely to occur repeatedly. More likely, the Interface-Identifiers chosen at either end will quickly diverge, terminating the sequence.
接收到具有不同于发送给对等方的最后一个Configure Nak的建议接口标识符的Configure Nak指示唯一接口标识符。在这种情况下，必须发送一个新的配置请求，该请求必须具有来自对等方的上一次配置Nak中建议的标识符值。但是，如果接收到的接口标识符等于上次配置Nak中发送的接口标识符，则必须选择新的接口标识符。在这种情况下，应使用新的暂定接口标识符发送新的配置请求。此序列（发送配置请求、接收配置请求、发送配置Nak、接收配置Nak）可能会出现几次，但不太可能重复出现。更可能的是，在两端选择的接口标识符将迅速发散，从而终止序列。
If negotiation of the Interface-Identifier is required, and the peer did not provide the option in its Configure-Request, the option SHOULD be appended to a Configure-Nak. The tentative value of the Interface-Identifier given must be acceptable as the remote Interface-Identifier; i.e. it should be different from the identifier value selected for the local end of the PPP link. The next Configure-Request from the peer may include this option. If the next Configure-Request does not include this option the peer MUST NOT send another Configure-Nak with this option included. It should assume that the peer's implementation does not support this option.
如果需要协商接口标识符，并且对等方未在其配置请求中提供该选项，则该选项应附加到配置Nak。给出的接口标识符的暂定值必须可接受为远程接口标识符；i、 e.它应该不同于为PPP链路的本地端选择的标识符值。来自对等方的下一个配置请求可能包括此选项。如果下一个配置请求不包含此选项，则对等方不得发送包含此选项的另一个配置Nak。它应该假设对等方的实现不支持此选项。
By default, an implementation SHOULD attempt to negotiate the Interface-Identifier for its end of the PPP connection.
默认情况下，实现应尝试协商其PPP连接端的接口标识符。
A summary of the Interface-Identifier Configuration Option format is shown below. The fields are transmitted from left to right.
接口标识符配置选项格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Interface-Identifier (MS Bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Identifier (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Identifier (LS Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Interface-Identifier (MS Bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Identifier (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Identifier (LS Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
1
1.
Length
长
10
10
Interface-Identifier
接口标识符
The 64-bit Interface-Identifier which is very likely to be unique on the link or zero if a good source of uniqueness can not be found.
64位接口标识符，在链路上很可能是唯一的，如果找不到良好的唯一性源，则为零。
Default
违约
If no valid interface identifier can be successfully negotiated, no default Interface-Identifier value should be assumed. The procedures for recovering from such a case are unspecified. One approach is to manually configure the interface identifier of the interface.
如果无法成功协商有效的接口标识符，则不应假定默认的接口标识符值。从此类案件中恢复的程序尚未明确。一种方法是手动配置接口的接口标识符。
Description
描述
This Configuration Option provides a way to negotiate the use of a specific IPv6 packet compression protocol. The IPv6-Compression-Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must separately request this option if bi-directional compression is desired. By default, compression is not enabled.
此配置选项提供了协商使用特定IPv6数据包压缩协议的方法。IPv6压缩协议配置选项用于指示接收压缩数据包的能力。如果需要双向压缩，链路的每一端都必须单独请求此选项。默认情况下，不启用压缩。
IPv6 compression negotiated with this option is specific to IPv6 datagrams and is not to be confused with compression resulting from negotiations via Compression Control Protocol (CCP), which potentially effect all datagrams.
使用此选项协商的IPv6压缩特定于IPv6数据报，不能与通过压缩控制协议（CCP）协商产生的压缩混淆，这可能会影响所有数据报。
A summary of the IPv6-Compression-Protocol Configuration Option format is shown below. The fields are transmitted from left to right.
IPv6压缩协议配置选项格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv6-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv6-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Type
类型
2
2.
Length
长
>= 4
>= 4
IPv6-Compression-Protocol
IPv6压缩协议
The IPv6-Compression-Protocol field is two octets and indicates the compression protocol desired. Values for this field are always the same as the PPP Data Link Layer Protocol field values for that same compression protocol.
IPv6压缩协议字段是两个八位字节，表示所需的压缩协议。此字段的值始终与同一压缩协议的PPP数据链路层协议字段值相同。
No IPv6-Compression-Protocol field values are currently assigned. Specific assignments will be made in documents that define specific compression algorithms.
当前未分配IPv6压缩协议字段值。将在定义特定压缩算法的文档中进行特定分配。
Data
数据
The Data field is zero or more octets and contains additional data as determined by the particular compression protocol.
数据字段为零个或多个八位字节，包含由特定压缩协议确定的附加数据。
Default
违约
No IPv6 compression protocol enabled.
未启用IPv6压缩协议。
The Interface Identifier of IPv6 unicast addresses [6] of a PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP connection setup (see section 4.1). If no valid Interface Identifier has been successfully negotiated, procedures for recovering from such a case are unspecified. One approach is to manually configure the Interface Identifier of the interface.
PPP接口的IPv6单播地址[6]的接口标识符应在PPP连接设置的IPV6CP阶段协商（见第4.1节）。如果未成功协商有效的接口标识符，则未指定从此类情况中恢复的过程。一种方法是手动配置接口的接口标识符。
As long as the Interface Identifier is negotiated in the IPV6CP phase of the PPP connection setup, it is redundant to perform duplicate address detection as a part of the IPv6 Stateless Autoconfiguration
只要在PPP连接设置的IPV6CP阶段协商接口标识符，作为IPv6无状态自动配置的一部分执行重复地址检测是多余的
protocol [3]. Therefore it is recommended that for PPP links with the IPV6CP Interface-Identifier option enabled the default value of the DupAddrDetectTransmits autoconfiguration variable [3] be zero.
协议[3]。因此，建议对于启用IPV6CP接口标识符选项的PPP链路，DupAddrDetectTransmissions自动配置变量[3]的默认值为零。
Link-local addresses of PPP interfaces have the following format:
PPP接口的链路本地地址具有以下格式：
| 10 bits | 54 bits | 64 bits |
+----------+------------------------+-----------------------------+
|1111111010| 0 | Interface Identifier |
+----------+------------------------+-----------------------------+
| 10 bits | 54 bits | 64 bits |
+----------+------------------------+-----------------------------+
|1111111010| 0 | Interface Identifier |
+----------+------------------------+-----------------------------+
The most significant 10 bits of the address is the Link-Local prefix FE80::. 54 zero bits pad out the address between the Link-Local prefix and the Interface Identifier fields.
地址的最高有效10位是链路本地前缀FE80:：。54个零位填充链路本地前缀和接口标识符字段之间的地址。
The IPv6 Control Protocol extension to PPP can be used with all defined PPP authentication and encryption mechanisms.
PPP的IPv6控制协议扩展可用于所有定义的PPP身份验证和加密机制。
This document borrows from the Magic-Number LCP option and as such is partially based on previous work done by the PPP working group.
本文件借鉴了幻数LCP选项，因此部分基于PPP工作组之前完成的工作。
The following changes were made from RFC-2023 "IP Version 6 over PPP":
RFC-2023“PPP上的IP版本6”进行了以下更改：
- Changed to use "Interface Identifier" instead of the "Interface Token" term according to the terminology adopted in [6].
- 根据[6]中采用的术语，更改为使用“接口标识符”而不是“接口令牌”术语。
- Increased the size of Interface Identifier to 64 bits according to the newly adopted IPv6 addressing architecture [6].
- 根据新采用的IPv6寻址体系结构，将接口标识符的大小增加到64位[6]。
- Added methods for selection of an interface identifier that is consistently reproducible across initializations of the IPV6CP finite state machine.
- 增加了选择接口标识符的方法，该标识符在IPV6CP有限状态机的初始化过程中始终可重复。
- Added the interface identifier selection methods for generating globally unique interface identifier from an unique an IEEE global identifier when it is available anywhere on the node.
- 添加了接口标识符选择方法，用于从节点上任何位置可用的唯一IEEE全局标识符生成全局唯一的接口标识符。
- Changed to send a Configure-Nak instead a Configure-Ack in response to receiving a Configure-Request with a zero Interface-Identifier value.
- 更改为发送配置Nak而不是配置Ack，以响应接收到接口标识符值为零的配置请求。
- Replaced the value assignment of the IPv6-Compression-Protocol field of the IPv6-Compression-Protocol Configuration option with the text stating that no IPv6-Compression-Protocol field values are currently assigned and that specific assignments will be made in documents that define specific compression algorithms.
- 将IPv6压缩协议配置选项的IPv6压缩协议字段的值分配替换为文本，说明当前未分配IPv6压缩协议字段值，并且将在定义特定压缩算法的文档中进行特定分配。
- Added new and updated references.
- 添加了新的和更新的引用。
- Minor text clarifications and improvements.
- 次要的文本澄清和改进。
[1] Simpson, W., "The Point-to-Point Protocol", STD 51, RFC 1661, July 1994.
[1] 辛普森，W.，“点对点协议”，STD 51，RFC 1661994年7月。
[2] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2] Deering，S.和R.Hinden，编辑，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[3] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[3] Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also: http://www.iana.org/numbers.html
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also: http://www.iana.org/numbers.html
[5] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997.
[5] IEEE，“64位全局标识符（EUI-64）注册机构指南”，http://standards.ieee.org/db/oui/tutorials/EUI64.html，1997年3月。
[6] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[6] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[8] Narten T., and C. Burton, "A Caution On The Canonical Ordering Of Link-Layer Addresses", RFC 2469, December 1998.
[8] Narten T.和C.Burton，“链路层地址规范排序的注意事项”，RFC 2469，1998年12月。
Dimitry Haskin Bay Networks, Inc. 600 Technology Park Billerica, MA 01821
Dimitry Haskin Bay Networks，Inc.马萨诸塞州比尔里卡科技园600号，邮编01821
EMail: dhaskin@baynetworks.com
EMail: dhaskin@baynetworks.com
Ed Allen Bay Networks, Inc. 600 Technology Park Billerica, MA 01821
爱德艾伦湾网络有限公司，地址：马萨诸塞州比尔里卡科技园600号，邮编：01821
EMail: eallen@baynetworks.com
EMail: eallen@baynetworks.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。