Справочник по сетевым протоколам


RFC1661 - часть 33

Unless otherwise specified, all Configuration Options apply in a

half-duplex fashion; typically, in the receive direction of the link

from the point of view of the Configure-Request sender.

Design Philosophy

The options indicate additional capabilities or requirements of

the implementation that is requesting the option. An

implementation which does not understand any option SHOULD

interoperate with one which implements every option.

A default is specified for each option which allows the link to

correctly function without negotiation of the option, although

perhaps with less than optimal performance.

Except where explicitly specified, acknowledgement of an option

does not require the peer to take any additional action other than

the default.

It is not necessary to send the default values for the options in

a Configure-Request.

A summary of the Configuration Option format is shown below. The

fields are transmitted from left to right.

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9


| Type | Length | Data ...


Simpson [Page 39]

RFC 1661 Point-to-Point Protocol July 1994


The Type field is one octet, and indicates the type of

Configuration Option. Up-to-date values of the LCP Option Type

field are specified in the most recent "Assigned Numbers" RFC [2].

This document concerns the following values:


1 Maximum-Receive-Unit

3 Authentication-Protocol

4 Quality-Protocol

5 Magic-Number

7 Protocol-Field-Compression

8 Address-and-Control-Field-Compression


The Length field is one octet, and indicates the length of this

Configuration Option including the Type, Length and Data fields.

If a negotiable Configuration Option is received in a Configure-

Request, but with an invalid or unrecognized Length, a Configure-

Nak SHOULD be transmitted which includes the desired Configuration

Option with an appropriate Length and Data.


The Data field is zero or more octets, and contains information

Содержание  Назад  Вперед