Network Working Group S. Varada, Ed.
Request for Comments: 5072 Transwitch
Obsoletes: 2472 D. Haskins
Category: Standards Track E. Allen
September 2007
Network Working Group S. Varada, Ed.
Request for Comments: 5072 Transwitch
Obsoletes: 2472 D. Haskins
Category: Standards Track E. Allen
September 2007
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）。本备忘录的分发不受限制。
Abstract
摘要
The Point-to-Point Protocol (PPP) 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）提供了通过点到点链路封装网络层协议信息的标准方法。PPP还定义了一个可扩展的链路控制协议，并提出了一系列网络控制协议（NCP），用于建立和配置不同的网络层协议。
This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links.
本文档定义了通过PPP链路发送IPv6数据包的方法、通过PPP建立和配置IPv6的NCP以及在PPP链路上形成IPv6链路本地地址的方法。
It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration.
它还指定了通过有状态或无状态地址自动配置对为PPP链路配置的IPv6全局单播地址执行重复地址检测的条件。
This document obsoletes RFC 2472.
本文件废除RFC 2472。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................3
2. Sending IPv6 Datagrams ..........................................3
3. A PPP Network Control Protocol for IPv6 .........................3
4. IPV6CP Configuration Options ....................................4
4.1. Interface Identifier .......................................4
5. Stateless Autoconfiguration and Link-Local Addresses ............9
6. Security Considerations ........................................11
7. IANA Considerations ............................................11
8. Acknowledgments ................................................11
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative references ....................................12
Appendix A: Global Scope Addresses................................14
Appendix B: Changes from RFC-2472.................................14
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................3
2. Sending IPv6 Datagrams ..........................................3
3. A PPP Network Control Protocol for IPv6 .........................3
4. IPV6CP Configuration Options ....................................4
4.1. Interface Identifier .......................................4
5. Stateless Autoconfiguration and Link-Local Addresses ............9
6. Security Considerations ........................................11
7. IANA Considerations ............................................11
8. Acknowledgments ................................................11
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative references ....................................12
Appendix A: Global Scope Addresses................................14
Appendix B: Changes from RFC-2472.................................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 to 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数据包关闭链路，或者直到发生某些外部事件（另一端断电、载波掉线等）。
This document obsoletes the earlier specification from RFC 2472 [7]. Changes from RFC 2472 are listed in Appendix B.
本文件废弃了RFC 2472[7]中的早期规范。附录B中列出了RFC 2472的变更。
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 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[6]中所述进行解释。
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 to be 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 LCP. IPV6CP packets may not be exchanged until PPP has reached the network-layer protocol phase. IPV6CP packets that are 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 LCP [1] with the following exceptions:
IPv6控制协议与LCP[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] but 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 online database of "Assigned Numbers" maintained at IANA [9]. The current value assignment is as follows:
IPV6CP选项类型字段的最新值在IANA维护的“分配编号”在线数据库中指定[9]。当前值分配如下所示：
1 Interface-Identifier
1接口标识符
The only IPV6CP option defined in this document is the interface identifier. Any other IPV6CP configuration options that can be defined over time are to be defined in separate documents.
本文档中定义的唯一IPV6CP选项是接口标识符。可以随时间定义的任何其他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
此配置选项提供了一种协商唯一的64位接口标识符的方法，该标识符将用于链路本地端的地址自动配置[3]（参见第5节）。配置请求必须仅包含接口标识符选项[1]的一个实例。接口标识符在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.
链接i、 例如，协商完成后，将为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 unique to the link and, preferably, 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 (see Appendix A) that can be formed from the interface identifier.
在请求此配置选项之前，实现选择其暂定接口标识符。应选择暂定接口标识符的非零值，以便该值对于链路是唯一的，并且最好在IPV6CP有限状态机的初始化（管理关闭和重新打开、重新启动等）过程中始终可重复。与完全随机的接口标识符相比，首选一致可再现的唯一接口标识符的基本原理是为可由接口标识符形成的全局范围地址（见附录a）提供稳定性。
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 in IEEE EUI-64 [4] terminology), which indicates whether or not the interface identifier is based on a globally unique IEEE identifier (EUI-48 or EUI-64 [4])(see 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.
假设接口标识符位按规范位顺序从0到63编号，其中最高有效位是位号0，位号6是“u”位（IEEE EUI-64[4]术语中的通用/本地位），它指示接口标识符是否基于全局唯一的IEEE标识符（EUI-48或EUI-64）[4] ）（请参见下面的案例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 that the extracted identifier is presented in canonical ordering [14].
1) 如果IEEE全局标识符（EUI-48或EUI-64）在节点上的任何位置都可用，则由于其唯一性属性，应使用它来构造暂定接口标识符。从节点上的另一个设备提取IEEE全局标识符时，应注意提取的标识符以规范顺序呈现[14]。
The only transformation from an EUI-64 identifier is to invert the "u" bit (universal/local bit in IEEE EUI-64 terminology).
EUI-64标识符的唯一转换是反转“u”位（IEEE EUI-64术语中的通用/本地位）。
For example, for a globally unique EUI-64 identifier of the form:
例如，对于表单的全局唯一EUI-64标识符：
most-significant least-significant
bit bit
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
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|
+----------------+----------------+----------------+----------------+
|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 the group/individual bit, and "e" are the bits of the extension identifier, the IPv6 interface identifier would be of the form:
其中，“c”是分配的公司标识的位，“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|
+----------------+----------------+----------------+----------------+
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|
+----------------+----------------+----------------+----------------+
|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 hexa-decimal 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的六进制值（在EUYY-ID和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 the group/individual bit, and "e" are the bits of the extension identifier, the IPv6 interface identifier would be of the form:
其中，“c”是分配的公司标识的位，“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|
+----------------+----------------+----------------+----------------+
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|
+----------------+----------------+----------------+----------------+
|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 nor 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, 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
如果两个接口标识符相等且不为零，则必须发送Configure Nak，指定建议远程对等方使用的不同非零接口标识符值。建议建议的值在IPV6CP有限状态机的初始化过程中始终可重复
(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.
（管理关闭和重新打开、重新启动等）。建议标识符的“u”（通用/本地）位必须设置为零（0），无论其来源如何，除非提供全局唯一的EUI-48/EUI-64派生标识符供远程对等方专用。
If the two interface identifiers are equal to zero, the interface identifier's negotiation MUST be terminated by transmitting the Configure-Reject with the interface-identifier value set to zero. In this case, a unique interface identifier cannot be negotiated.
如果两个接口标识符等于零，则必须通过传输接口标识符值设置为零的配置拒绝来终止接口标识符的协商。在这种情况下，无法协商唯一的接口标识符。
If a Configure-Request is received with the Interface-Identifier Configuration Option and the receiving peer does not implement this option, Configure-Reject is sent.
如果使用Interface Identifier Configuration（接口标识符配置）选项接收到配置请求，并且接收对等方未实现此选项，则会发送Configure Reject（配置拒绝）。
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 [1]).
在正常处理将导致发送新的配置请求之前（即，在接收到配置Nak或重启计时器耗尽之前[1]），不应将新的配置请求发送给对等方。
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、 例如，它应该不同于为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 cannot 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.
如果无法成功协商有效的接口标识符，则不应假定默认的接口标识符值。从此类案件中恢复的程序尚未明确。一种方法是手动配置接口的接口标识符。
The interface identifier of IPv6 unicast addresses [5] 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单播地址[5]的接口标识符应在PPP连接设置的IPV6CP阶段协商（见第4.1节）。如果未成功协商有效的接口标识符，则未指定从此类情况中恢复的过程。一种方法是手动配置接口的接口标识符。
The negotiated interface identifier is used by the local end of the PPP link to autoconfigure an IPv6 link-local unicast address for the PPP interface. However, it SHOULD NOT be assumed that the same interface identifier is used in configuring global unicast addresses for the PPP interface using IPv6 stateless address autoconfiguration [3]. The PPP peer MAY generate one or more interface identifiers, for instance, using a method described in [8], to autoconfigure one or more global unicast addresses.
PPP链路的本地端使用协商接口标识符为PPP接口自动配置IPv6链路本地单播地址。但是，不应假设在使用IPv6无状态地址自动配置为PPP接口配置全局单播地址时使用了相同的接口标识符[3]。PPP对等方可以例如使用[8]中描述的方法生成一个或多个接口标识符，以自动配置一个或多个全局单播地址。
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 (DAD) as a part of the IPv6 Stateless Address Autoconfiguration protocol [3] on the IPv6 link-local address generated by the PPP peer. It may also be redundant to perform DAD on any global unicast addresses configured (using an interface identifier that is either negotiated during IPV6CP or generated, for instance, as per [8]) for the interface as part of the IPv6 Stateless Address Autoconfiguration protocol [3] provided that the following two conditions are met:
只要在PPP连接设置的IPV6CP阶段协商接口标识符，在PPP对等方生成的IPv6链路本地地址上执行重复地址检测（DAD）作为IPv6无状态地址自动配置协议[3]的一部分是多余的。如果满足以下两个条件，则在为接口配置的任何全局单播地址上执行DAD（使用在IPV6CP期间协商的或根据[8]生成的接口标识符）也可能是多余的，作为IPv6无状态地址自动配置协议[3]的一部分：
1) The prefixes advertised through the Router Advertisement messages by the access router terminating the PPP link are exclusive to the PPP link.
1) 终止PPP链路的接入路由器通过路由器公告消息公告的前缀是PPP链路专有的。
2) The access router terminating the PPP link does not autoconfigure any IPv6 global unicast addresses from the prefixes that it advertises.
2) 终止PPP链路的接入路由器不会根据其播发的前缀自动配置任何IPv6全局单播地址。
Therefore, it is RECOMMENDED that for PPP links with the IPV6CP interface-identifier option enabled and satisfying the aforementioned two conditions, the default value of the DupAddrDetectTransmits autoconfiguration variable [3] is set to zero by the system management. 3GPP2 networks are an example of a technology that uses PPP to enable a host to obtain an IPv6 global unicast address and satisfies the aforementioned two conditions [10]. 3GPP networks are another example ([11] [13]).
因此，建议对于启用IPV6CP接口标识符选项并满足上述两个条件的PPP链路，系统管理将DupAddrDetectTransmists自动配置变量[3]的默认值设置为零。3GPP2网络是使用PPP使主机能够获得IPv6全局单播地址并满足上述两个条件的技术示例[10]。3GPP网络是另一个例子（[11][13]）。
Link-local addresses
链接本地地址
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个零位填充链路本地前缀和接口标识符字段之间的地址。
Lack of link security, such as authentication, trigger the security concerns raised in [3] when the stateless address autoconfiguration method is employed for the generation of global unicast IPv6 addresses out of interface identifiers that are either negotiated through the IPV6CP or generated, for instance, using a method described in [8]. Thus, the mechanisms that are appropriate for ensuring PPP link security are addressed below, together with the reference to a generic threat model.
当无状态地址自动配置方法用于在接口标识符之外生成全局单播IPv6地址时，缺乏链路安全性（如身份验证）会引发[3]中提出的安全问题，该标识符通过IPV6CP协商或使用[8]中描述的方法生成。因此，下文将介绍适用于确保PPP链路安全的机制，并参考通用威胁模型。
The mechanisms that are appropriate for ensuring PPP link Security are: 1) Access Control Lists that apply filters on traffic received over the link for enforcing admission policy, 2) an Authentication protocol that facilitates negotiations between peers [15] to select an authentication method (e.g., MD5 [16]) for validation of the peer, and 3) an Encryption protocol that facilitates negotiations between peers to select encryption algorithms (or crypto-suites) to ensure data confidentiality [17].
适合于确保PPP链路安全的机制包括：1）对通过链路接收的流量应用过滤器的访问控制列表，以强制实施准入策略；2）促进对等方之间协商的认证协议[15]，以选择验证对等方的认证方法（例如，MD5[16]），以及3）一种加密协议，该协议促进对等方之间的协商，以选择加密算法（或加密套件），确保数据机密性[17]。
There are certain threats associated with peer interactions on a PPP link even with one or more of the above security measures in place. For instance, using the MD5 authentication method [16] exposes one to replay attack, where an attacker could intercept and replay a station's identity and password hash to get access to a network. The user of this specification is advised to refer to [15], which presents a generic threat model, for an understanding of the threats posed to the security of a link. The reference [15] also gives a framework to specify requirements for the selection of an authentication method for a given application.
即使有一个或多个以上的安全措施，PPP链路上的对等交互也存在一定的威胁。例如，使用MD5身份验证方法[16]会使一个站点遭受重播攻击，攻击者可以拦截并重播站点的身份和密码散列以访问网络。建议本规范的用户参考[15]，其中提供了一个通用的威胁模型，以了解对链路安全构成的威胁。参考文献[15]还提供了一个框架，规定了为给定应用选择认证方法的要求。
The IANA has assigned value 1 for the Type field of the IPv6 datagram interface-identifier option specified in this document. The current assignment is up-to-date at [9].
IANA为本文档中指定的IPv6数据报接口标识符选项的类型字段分配了值1。当前分配是最新的，位于[9]。
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 editor is grateful for the input provided by members of the IPv6 community in the spirit of updating RFC 2472. Thanks, in particular,
编辑非常感谢IPv6社区成员本着更新RFC 2472的精神提供的意见。特别感谢,，
go to Pete Barany and Karim El Malki for their technical contributions. Also, thanks to Alex Conta for a thorough review, Stephen Kent for helping with security aspects, and Spencer Dawkins and Pekka Savola for the nits. Finally, the author is grateful to Jari Arkko for his initiation to bring closure to this specification.
请向皮特·巴拉尼和卡里姆·马尔基咨询他们的技术贡献。另外，感谢Alex Conta的全面审查，感谢Stephen Kent在安全方面的帮助，感谢Spencer Dawkins和Pekka Savola在nits方面的帮助。最后，作者感谢Jari Arkko主动结束本规范。
[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[3] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[3] Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[4] IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
[4] IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
[5] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[5] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[7] Haskin，D.和E.Allen，“PPP上的IP版本6”，RFC 24721998年12月。
[8] Narten T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[8] Narten T.，Draves，R.和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[9] IANA, "Assigned Numbers," http://www.iana.org/numbers.html
[9] IANA, "Assigned Numbers," http://www.iana.org/numbers.html
[10] 3GPP2 X.S0011-002-C v1.0, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services," September 2003.
[10] 3GPP2 X.S0011-002-C v1.0，“cdma2000无线IP网络标准：简单IP和移动IP接入服务”，2003年9月。
[11] 3GPP TS 29.061 V6.4.0, "Interworking between the Public Land Mobile Network (PLMN) Supporting packet based services and Packet Data Networks (PDN) (Release 6)," April 2005.
[11] 3GPP TS 29.061 V6.4.0，“支持分组业务的公共陆地移动网络（PLMN）与分组数据网络（PDN）（第6版）之间的互通”，2005年4月。
[12] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[12] Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[13] 3GPP TS 23.060 v6.8.0, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 6)," March 2005.
[13] 3GPP TS 23.060 v6.8.0，“通用分组无线业务（GPRS）；服务说明；第2阶段（第6版）”，2005年3月。
[14] Narten, T. and C. Burton, "A Caution On The Canonical Ordering Of Link-Layer Addresses", RFC 2469, December 1998.
[14] Narten，T.和C.Burton，“链路层地址规范排序的注意事项”，RFC 2469，1998年12月。
[15] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[15] Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[16] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[17] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[17] Meyer，G.，“PPP加密控制协议（ECP）”，RFC 1968，1996年6月。
Appendix A: Global Scope Addresses
附录A：全球范围地址
A node on the PPP link creates global unicast addresses either through stateless or stateful address autoconfiguration mechanisms. In the stateless address autoconfiguration [3], the node relies on sub-net prefixes advertised by the router via the Router Advertisement messages to obtain global unicast addresses from an interface identifier. In the stateful address autoconfiguration, the host relies on a Stateful Server, like DHCPv6 [12], to obtain global unicast addresses.
PPP链路上的节点通过无状态或有状态地址自动配置机制创建全局单播地址。在无状态地址自动配置[3]中，节点依靠路由器通过路由器公告消息公告的子网前缀从接口标识符获取全局单播地址。在有状态地址自动配置中，主机依赖有状态服务器（如DHCPv6[12]）来获取全局单播地址。
Appendix B: Changes from RFC 2472
附录B：RFC 2472的变更
The following changes were made from RFC 2472 "IPv6 over PPP":
RFC 2472“PPP上的IPv6”进行了以下更改：
- Minor updates to Sections 3 and 4
- 第3节和第4节的小更新
- Updated the text in Section 4.1 to include the reference to Appendix A and minor text clarifications.
- 更新了第4.1节中的文本，包括对附录A的引用和次要文本澄清。
- Removed Section 4.2 on IPv6-Compression-Protocol based on IESG recommendation, and created a new standards-track document to cover negotiation of the IPv6 datagram compression protocol using IPV6CP.
- 根据IESG建议删除了关于IPv6压缩协议的第4.2节，并创建了一份新的标准跟踪文件，以涵盖使用IPV6CP的IPv6数据报压缩协议的协商。
- Updated the text in Section 5 to: (a) allow the use of one or more interface identifiers generated by a peer, in addition to the use of interface identifier negotiated between peers of the link, in the creation of global unicast addresses for the local PPP interface, and (b) identify cases against the DAD of created non-link-local addresses.
- 将第5节中的文本更新为：（a）在为本地PPP接口创建全局单播地址时，除了使用链路对等方之间协商的接口标识符外，还允许使用对等方生成的一个或多个接口标识符；（b）识别创建的非链路本地地址的DAD案例。
- Added new and updated references.
- 添加了新的和更新的引用。
- Added Appendix A
- 增加附录A
Authors' Addresses
作者地址
Dimitry Haskin Ed Allen
迪米特里·哈斯金·埃德·艾伦
Srihari Varada (Editor) TranSwitch Corporation 3 Enterprise Dr. Shelton, CT 06484. US.
Srihari Varada（编辑）TranSwitch Corporation 3 Enterprise Shelton博士，CT 06484。我们
Phone: +1 203 929 8810
EMail: varada@ieee.org
Phone: +1 203 929 8810
EMail: varada@ieee.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.