rfc1661.txt

最近的中文RFC文档

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 代码 | 标识符 | 长度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 数据 ...
+-+-+-+-+
代码
　　11 为Discard-Request
　　标识符
　　每个Discard-Request发送，标识符域必须改变。
　　Magic-Number
　　Magic-Number域为四个八位字节，对检测处于looped-back条件下的链路有帮助。在该Magic-Number配置选项被成功的协商之前，Magic-Number必须被以零传送。在Magic-Number配置选项中由更详细的说明。
　　数据
　　数据域是零或者多个八位字节，包含被发送方使用的未解释的数据。该数据可以由任何二进制值组成。该域的结束由长度指出。
6. LCP配置选项
　　LCP配置选项允许点对点链路的默认特征的更改的协商。如果一个配置选项不包含在Configure-Request包中，配置选项被假定为默认值。
　　一些配置选项可以被列出超过一次。配置选项详细的效果，由每一个配置选项描述所指出。（该说明书内的配置选项均不能被列出超过一次。）
　　列表最后的配置选项由LCP包的长度域所指出。
　　若不另外指定，所有的配置选项由半双工方式支持：典型的，线路的接收方是来自Configure-Request发送者的观点。
　　设计思想
　　选项指出另外的性能和提出选项的执行的要求。不了解任何选项的执行应该与实现每一个选项的操作交互执行。
　　对每一个允许链路没有选项协商的正确功能的每一个选项指定默认值，尽管低于最佳性能。
　　除非明确的指出，一个选项的确认并不需要peer来比默认附加任何动作。
　　没有必要为Configure-Request中的选项发送默认值。
　　配置选项格式如下。域从左到右传送。

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 类型 | 长度 | 数据 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
　　类型
　　类型域是一个八位字节，指出配置选项的类型。LCP选项类型域的Up-to-date值在大多数当前的"Assigned 　　Numbers" RFC [2]中被指定。
　　该文档涉及以下值：

0 RESERVED（保留）
1 Maximum-Receive-Unit（最大-接收-单元）
3 Authentication-Protocol（鉴定-协议）
4 Quality-Protocol（质量-协议）
5 Magic-Number
7 Protocol-Field-Compression（协议-域-压缩）
8 Address-and-Control-Field-Compression（地址-和-控制-域-压缩）

　　长度
　　长度域是一个八位字节，并且指出该配置选项，包括类型、长度和数据域的长度。
　　如果在一个Configure-Request中收到了一个可通过谈判解决的配置选项，但是带有一个非法的或者未被承认的长度，Configure-Nak应该被传送包括带有适当的长度和数据的想得到的配置选项。
　　数据
　　数据域是零个或者更多的八位字节，并且包含配置选项的特殊详细信息。数据域的类型和长度由类型和长度域所决定。
　　当数据域由长度到扩充超过信息域的结束所指出，整个包被不通知自动机制静静的丢弃。
6-1. Maximum-Receive-Unit (MRU)
　　描述
　　该配置选项可以被发送到通知peer该执行可以接收更大的包，或者请求peer发送小一点的包。
　　默认值是1500个八位字节。如果请求小一点的包，万一链路同步丢失，一个执行必须仍然能够接收整个1500个八位字节的全部信息域。
　　执行记录：
　　该选项用于指出一个执行的容量。peer不必需要最大容量的使用。例如，当一个2048个八位字节MRU被指出，　　peer不需要用2048个八位字节发送每个包。peer不需要Configure-Nak指出它将仅发送小一点的包，既然该执行将总是需要对至少1500八位字节的支持。
　　Maximum-Receive-Unit配置选项格式如下。域从左到右传送。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 类型 | 长度 | Maximum-Receive-Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

　　类型
　　1
　　长度
　　4
　　Maximum-Receive-Unit
　　Maximum-Receive-Unit域是二个八位字节，在信息和填料域中指定最大字节数。它并不包括帧、协议域、FCS也不包括任何透明位或字节。
6-2. Authentication-Protocol
　　描述
　　一些链路可能想要peer在允许网络层协议包被交换之前鉴别它自己。
　　该配置选项提供一种使用详细而准确的协议进行鉴定的方法。默认的，不需要鉴定。
　　一个执行必须不在Configure-Request包中包含多重鉴定协议配置选项。代替的，应该首先尝试配置最值得要的协议。如果协议是Configure-Nak的，那么该执行应该在下一个Configure-Request中尝试下一个最值得要的协议。
　　该执行发送Configure-Request指出它所期待的来自它的peer的鉴定。如果一个执行发送一个Configure-Ack ，那么它同意进行指定协议的鉴定。一个执行接收一个Configure-Ack应该期待peer用公认协议进行鉴别。
没有必要采用全双工或者将同一个协议用于两个方向。允许每个方向采用不同的协议是极好的。这将，当然，取决于协商的详细协议。
　　Authentication-Protocol配置选项格式如下。域从左到右传送。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 类型 | 长度 | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 数据 ...
+-+-+-+-+
　　类型
　　3
　　长度
　　>=4
　　Authentication-Protocol
　　Authentication-Protocol域是两个八位字节，指出想要鉴定的协议。该域的值总是与PPP协议域值一样用于同样的鉴定协议。
　　Authentication-Protocol域的Up-to-date值在最近的"Assigned Numbers" RFC [2]中被指定。
　　当前的值被赋值如下：
　　值（十六进制） 协议
　　c023 　　　　　密码证明协议
　　c223　　　　　　挑战握手验证协议
　　数据
　　数据域是零或多个八位字节，包含作为由详细协议决定了的附加数据。
6-3. Quality-Protocol
　　描述
　　一些链路上可能想要决定何时，和间隔多长时间，该链路丢弃数据。该过程被叫做链路质量监测。
　　该配置选项提供一种用于链路质量监测的使用详细协议的商议方法。默认的，禁止链路质量监测。
　　该执行发送的Configure-Request指出它希望接收的来自它的peer的监测信息。
　　如果一个执行发送一个Configure-Ack，那么它同意使用详细协议。一个协议接收一个Configure-Ack应该等待peer发送确认协议。
　　不必要进行全双工或双方都使用同样的协议的质量监测。最好两端使用不同的可接受的协议。这将，当然，取决于商议的详细的协议。
　　Quality-Protocol配置选项格式如下。域从左到右传送。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 类型 | 长度 | Quality-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 数据 ...
+-+-+-+-+

　　类型
　　4
　　长度
　　>=4
　　Quality-Protocol
　　Quality-Protocol域是两个八位字节，指出链路想要的质量监测协议。该域的值总是与用于相同的监测协议的PPP协议域值相同。
　　Quality-Protocol域的Up-to-date值在最近的"Assigned Numbers" RFC [2]中指定。当前值的赋值如下：
　　值（十六进制） 协议
　　c025 　　　　链路质量报告
　　数据
　　数据域是零或者多个八位字节，包含由详细协议决定的附加数据。
6-4. Magic-Number
　　描述
　　该配置选项提供一种侦测looped-back链路和其他数据链路层异常的方法。该配置选项可以被一些其他配置选项例如Quality-Protocol配置选项所需求。默认的，该Magic-Number并不协商，并且零被插入到Magic-Number 可能用到的其他地方。
　　请求该配置选项之前，一个执行必须选择它的Magic-Number。推荐Magic-Number使用在大多数随机的方式可能性为了保证一个执行有一个唯一的号码的可能性高。选择唯一号码的好方法是用一个唯一的种子开始。建议使用唯一包含的机器序列号，其他网络硬件地址，当时的时钟，等等。独特的好的随机种子是物理事件的inter-arrival时间的精确测量，比如其他连接网络的接收包，服务器响应时间，或者人类用户的键入速率。它也建议尽可能的多的来源被同步。
　　当接收到一个带有Magic-Number配置选项的Configure-Request时候，接收到的Magic-Number与最后一个发送给peer的Configure-Request的Magic-Number相比较。如果两个Magic-Number不同，则该链路不被looped-back，而且Magic-Number应该被确认。如果两个Magic-Number相等，那么有可能，但是不确定，该线路是looped-back，并且该Configure-Request实际上是上一次发送的。为了确认它，必须发送一个Configure-Nak指定一个不同的Magic-Number值。一个新的Configure-Request应该不被发送到peer，直到一般处理导致它的发送（那就是说，直到收到一个Configure-Nak或者Restart计时器溢出）。
　　接收到一个带有Magic-Number的Configure-Nak与最后发送给peer的Configure-Nak不同，这就证明该链路不是looped-back，并且指出唯一的一个Magic-Number。如果该Magic-Number等于最后发送的Configure-Nak，有可能增加了一条looped-back链路，必须选择一个新的Magic-Number。其他情况，应该发送一个新的带有新的Magic-Number的Configure-Request。
　　如果该链路确实是looped-back，该次序（传送Configure-Request,接收Configure-Request, 传送Configure-Nak, 接收Configure-Nak）将被重复做下去。若该链路不是looped-back，该次序将发生很少的几次，但是它非常不像能再三的重复。更像，所选择的Magic-Number很快会跳出，结束该顺序。下面的表格表明了链路的两端带有统一分配的Magic-Number冲突的可能性：

　　碰撞次数 可能性
-------------------- ---------------------
1 1/2**32 = 2.3 E-10
2 1/2**32**2 = 5.4 E-20
3 1/2**32**3 = 1.3 E-29

　　唯一的或者随机的好的源被发生的分歧所需要。如果一个唯一的好的源不能被找到，推荐配置选项不能被激活：带有该选项的Configure-Requests应该不被传送并且peer发送的任何Magic-Number配置选项应该既被确认也被拒绝。在这种情况下，looped-back链路不能通过执行被可靠的监测出来，虽然peer仍然可以察觉他们。
　　如果一个执行传送一个带有Magic-Number配置选项的Configure-Request，那么当它接收一个带有Magic-Number配置选项的Configure-Request时它必须不响应。那就是说，如果一个执行想使用Magic Numbers，那么它必须也允许它的peer这样做。如果一个执行确实接收一个Configure-Request对Configure-Request的响应，只能表示该链路不是loop-back，并且它的peer将不使用Magic-Number。在这种情况下，一个执行应该行动好像协商已经成功（好像它真的收到了一个Configure-Ack）。
　　Magic-Number也可以被用于监测通常操作的looped-back链路，正如经过配置选项协商。所有的LCPEcho-Request, Echo-Reply, 和 Discard-Request 包都有一个Magic-Number域。如果Magic-Number被成功的协商，一个执行必须传送那些带有Magic-Number域的包的域到协商的Magic-Number。
　　这些包的Magic-Number域应该被接收的时候检查。所有收到的Magic-Number域必须等于零或者peer的唯一的Magic-Number，取决于是不是peer协商了Magic-Number。
　　一个Magic-Number域的接收等于协商本地Magic-Number指出一个loop-back链路。一个Magic-Number的接收或者协商本地Magic-Number，该peer的协商Magic-Number，或者零如果peer不协商一个，指出一个被（漏）配置用于与一个不同的peer通讯。
　　情况未指明的任一事例恢复程序，和任何执行到执行的不同，一个稍微保守式程序被假定一个LCP关闭时间。一个更开放事件将开始重新设置链路的处理，直到looped-back条件被终止才完成，并且Magic-Numbers被成功的协商。一个更开放式的程序（在looped-back链路情况下）开始传送LCPEcho-Request包，直到收到适当的Echo-Reply，指出looped-back条件的终止。
　　Magic-Number配置选项格式如下。域从左到右传送。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 类型 | 长度 | Magic-Number
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Magic-Number (内容) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

　　类型
　　5
　　长度
　　6
　　Magic-Number
　　Magic-Number域是四个八位字节，指出一个很像链路结尾唯一指定的号码。零的Magic-Number是违法的，必须总是没有应答，如果不被彻底拒绝。

6-5. Protocol-Field-Compression (PFC)
　　描述
　　该配置选项提供一种PPP协议域的压缩协商方法。默认的，所有执行必须