RFC relevance of implementation

As per Relevance of the word implementation, we have this rfc below:

Network Working Group W. Simpson,
Request for Comments: 1570
Updates: 1548 January 1994
Category: Standards

PPP LCP

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links.
defines an extensible Link Control Protocol (LCP) for establishing
configuring, and testing the data-link connection. This
defines several additional LCP features which have been
over the past few years

This document is the product of the Point-to-Point Protocol
Group of the Internet Engineering Task Force (IETF). Comments
be submitted to the ietf-ppp@ucdavis.edu mailing list

Table of

1. Additional LCP Packets ................................ 1
1.1 Identification .................................. 1
1.2 Time-Remaining .................................. 3
2. Additional LCP Configuration Options .................. 6
2.1 FCS-Alternatives ................................ 6
2.1.1 LCP considerations .............................. 7
2.1.2 Null FCS ........................................ 8
2.2 Self-Describing-Padding ......................... 9
2.3 Callback ........................................ 11
2.4 Compound-Frames ................................. 12
2.4.1 LCP considerations .............................. 14
APPENDICES ................................................... 15
A. Fast Frame Check Sequence (FCS) Implementation ........ 15
A.1 32-bit FCS Computation Method ................... 15
SECURITY CONSIDERATIONS ...................................... 17
REFERENCES ................................................... 17
ACKNOWLEDGEMENTS ............................................. 18
CHAIR'S ADDRESS .............................................. 18
EDITOR'S ADDRESS ............................................. 18

Simpson [Page i
RFC 1570 PPP LCP extensions January 1994

1. Additional LCP

The Packet format and basic facilities are already defined for
[1].

Up-to-date values of the LCP Code field are specified in the
recent "Assigned Numbers" RFC [2]. This specification concerns
following values

12
13 Time-

1.1.

This Code provides a method for an implementation to
itself to its peer. This Code might be used for many
purposes, such as link troubleshooting, license enforcement, etc

Identification is a Link Maintenance packet.
packets MAY be sent at any time, including before LCP has
the Opened state

The sender transmits a LCP packet with the Code field set to 12
(Identification), the Identifier field set, the local Magic-
(if any) inserted, and the Message field filled with any
data, but not exceeding the default MRU minus eight

Receipt of an Identification packet causes the RXR or RUC event
There is no response to the Identification packet

Receipt of a Code-Reject for the Identification packet
generate the RXJ+ (permitted) event

Rationale

This feature is defined as part of LCP, rather than as
separate PPP Protocol, in order that its benefits may
available during the earliest possible stage of the
Establishment phase. It allows an operator to learn
identification of the peer even when negotiation is
converging. Non-LCP packets cannot be sent during the
Establishment phase

Simpson [Page 1]
RFC 1570 PPP LCP extensions January 1994

This feature is defined as a separate LCP Code, rather than
Configuration-Option, so that the peer need not include it
other items in configuration packet exchanges, and
"corrected" values or "rejection", since its generation is
rare and in one direction. It is recommended
Identification packets be sent whenever a Configure-Reject
sent or received, as a final message when negotiation fails
converge, and when LCP reaches the Opened state

A summary of the Identification packet format is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+

12 for

The Identifier field MUST be changed for each Identification sent

>= 8

Magic-

The Magic-Number field is four octets and aids in detecting
which are in the looped-back condition. Until the Magic-
Configuration Option has been successfully negotiated, the Magic
Number MUST be transmitted as zero. See the Magic-
Configuration Option for further explanation

The Message field is zero or more octets, and its contents
implementation dependent. It is intended to be human readable
and MUST NOT affect operation of the protocol. It is

Simpson [Page 2]
RFC 1570 PPP LCP extensions January 1994

that the message contain displayable ASCII characters 32
126 decimal. Mechanisms for extension to other character sets
the topic of future research. The size is determined from
Length field

Implementation Note

The Message will usually contain such things as the sender'
hardware type, PPP software revision level, and PPP
serial number, MIB information such as link speed and
name, and any other information that the sender thinks might
useful in debugging connections. The format is likely to
different for each implementor, so that those doing
number tracking can validate their numbers. A
implementation SHOULD treat the Message as displayable text
and SHOULD be able to receive and display a very long Message

1.2. Time-

This Code provides a mechanism for notifying the peer of the
remaining in this session

The nature of this information is advisory only. It is
that only one side of the connection will send this
(generally a "network access server"). The session is
concluded by the Terminate-Request packet

Time-Remaining is a Link Maintenance packet. Time-
packets may only be sent in the LCP Opened state

The sender transmits a LCP packet with the Code field set to 13
(Time-Remaining), the Identifier field set, the local Magic-
(if any) inserted, and the Message field filled with any
data, but not exceeding the peer's established MRU minus twelve

Receipt of an Time-Remaining packet causes the RXR or RUC event
There is no response to the Time-Remaining packet

Receipt of a Code-Reject for the Time-Remaining packet
generate the RXJ+ (permitted) event

Rationale

This notification is defined as a separate LCP Code,

Simpson [Page 3]
RFC 1570 PPP LCP extensions January 1994

than a Configuration-Option, in order that changes and
messages may occur dynamically during the session, and that
information might be determined after Authentication
occurred. Typically, this packet is sent when the link
Network-Layer Protocol phase, and at regular
throughout the session, particularly near the end of
session

A summary of the Time-Remaining packet format is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds-Remaining |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+

13 for Time-

The Identifier field MUST be changed for each Time-Remaining sent

>= 12

Magic-

The Magic-Number field is four octets and aids in detecting
which are in the looped-back condition. Until the Magic-
Configuration Option has been successfully negotiated, the Magic
Number MUST be transmitted as zero. See the Magic-
Configuration Option for further explanation

Seconds-

The Seconds-Remaining field is four octets and indicates
number of integral seconds remaining in this session. This 32

Simpson [Page 4]
RFC 1570 PPP LCP extensions January 1994

unsigned value is sent most significant octet first. A value
0xffffffff (all ones) represents no timeout, or "forever".

The Message field is zero or more octets, and its contents
implementation dependent. It is intended to be human readable
and MUST NOT affect operation of the protocol. It is
that the message contain displayable ASCII characters 32
126 decimal. Mechanisms for extension to other character sets
the topic of future research. The size is determined from
Length field

Simpson [Page 5]
RFC 1570 PPP LCP extensions January 1994

2. Additional LCP Configuration

The Configuration Option format and basic options are already
for LCP [1].

Up-to-date values of the LCP Option Type field are specified in
most recent "Assigned Numbers" RFC [2]. This document concerns
following values

9 FCS-
10 Self-Describing-
13
15 Compound-

2.1. FCS-

This Configuration Option provides a method for an
to specify another FCS format to be sent by the peer, or
negotiate away the FCS altogether

This option is negotiated separately in each direction. However
it is not required that an implementation be capable
concurrently generating a different FCS on each side of the link

The negotiated FCS values take effect only during
and Network-Layer Protocol phases. Frames sent during any
phase MUST contain the default FCS

A summary of the FCS-Alternatives Configuration Option format
shown below. The fields are transmitted from left to right

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9

Simpson [Page 6]
RFC 1570 PPP LCP extensions January 1994

3

This field is one octet, and is comprised of the "logical or"
the following values

1 Null
2 CCITT 16-bit
4 CCITT 32-bit

Implementation Note

For most PPP HDLC framed links, the default FCS is the CCITT 16-
bit FCS. Some framing techniques and high speed links may
another format as the default FCS

2.1.1. LCP

The link can be subject to loss of state, and the LCP can re
negotiate at any time. When the LCP begins renegotiation
termination, it is recommended that the LCP Configure-Request
Terminate-Request packet be sent with the last negotiated FCS,
change to the default FCS, and a duplicate LCP packet is sent
the default FCS. The Identifier field SHOULD NOT be incremented
each such duplicate packet

On receipt of a LCP Configure-Request or Terminate-Request packet
the implementation MUST change to the default FCS for
transmission and reception. If a Request packet is received
contains a duplicate Identifier field, a new reply MUST be generated

Implementation Notes

The need to send two packets is only necessary after
Alternative-FCS has already been negotiated. It need not
during state transitions when there is a natural indication
the default FCS is in effect, such as the Down and Up events.
is necessary to send two packets in the Ack-Sent and
states, since the peer could mistakenly believe that the link
Opened

It is possible to send a single 48-bit FCS which is a
of the 16-bit and 32-bit FCS. This may be sent instead of

Simpson [Page 7]
RFC 1570 PPP LCP extensions January 1994

the two packets described above. We have not standardized
procedure because of intellectual property concerns. If such
48-bit FCS is used, it MUST only be used for LCP packets

2.1.2. Null

The Null FCS SHOULD only be used for those network-layer
transport protocols which have an end-to-end checksum available,
as TCP/IP, or UDP/IP with the checksum enabled. That is, the
FCS option SHOULD be negotiated together with another non-null
option in a heterogeneous environment

When a configuration (LCP or NCP) or authentication packet is sent
the FCS MUST be included. When a configuration (LCP or NCP)
authentication packet is received, the FCS MUST be verified

There are several cases to be considered

Null FCS

The sender generates the FCS for those frames which require
FCS before sending the frame

When a frame is received, it is not necessary to check the
before demultiplexing. Any FCS is treated as padding

Receipt of an Authentication or Control packet would be
after passing the frame to the demultiplexer. Verification of
FCS can easily be accomplished using one of the
algorithms defined in "PPP in HDLC Framing" [3] (16-bit FCS)
Appendix A (32-bit FCS).

Null FCS with another FCS, using

This is similar to the above case

Those packets which are required to have the FCS (Authentication
Control, or Network-Protocols lacking a checksum) are
using software after demultiplexing. Packets which fail the
test are discarded as usual

Null FCS with another FCS, using

A flag is passed with the frame, indicating whether or not it
passed the hardware FCS check. The incorrect FCS MUST be
with the rest of the data. The frame MUST NOT be discarded
after demultiplexing, and only those frames that require the

Simpson [Page 8]
RFC 1570 PPP LCP extensions January 1994

are discarded

All three FCS forms (Null, 16 and 32) may be used concurrently
different frames when using software. That is probably not
with most current hardware

2.2. Self-Describing-

This Configuration Option provides a method for an
to indicate to the peer that it understands self-describing
when padding is added at the end of the PPP Information field

This option is most likely to be used when some protocols, such
network-layer or compression protocols, are configured
require detection and removal of any trailing padding.
special protocols are identified in their respective documents

If the option is Rejected, the peer MUST NOT add any padding
the identified special protocols, but MAY add padding to
protocols

If the option is Ack'd, the peer MUST follow the procedures
adding self-describing pads, but only to the
identified protocols. The peer is not required to add any
to other protocols

Implementation Notes

This is defined so that the Reject handles either case
the peer does not generate self-describing pads. When the
never generates padding, it may safely Reject the option.
the peer does not understand the option, it also will
successfully configure a special protocol which
elimination of pads

While some senders might only be capable of adding padding
every protocol or not adding padding to any protocol, by
the receiver need not examine those protocols which do not
the padding stripped

To avoid unnecessary configuration handshakes,
implementation which generates padding, and has a
configured which requires the padding to be known,
include this Option in its Configure-Request, and

Simpson [Page 9]
RFC 1570 PPP LCP extensions January 1994

Configure-Nak with this Option when it is not present in
peer's Request

Each octet of self-describing pad contains the index of
octet. The first pad octet MUST contain the value one (1),
indicates the Padding Protocol to the Compound-Frames option
After removing the FCS, the final pad octet indicates the
of pad octets to remove. For example, three pad octets
contain the values 1, 2, 3.

The Maximum-Pad-Value (MPV) is also negotiated. Only the values 1
through MPV are used. When no padding would otherwise
required, but the final octet of the PPP Information
contains the value 1 through MPV, at least one self-describing
octet MUST be added to the frame. If the final octet is
than MPV, no additional padding is required

Implementation Notes

If any of the pad octets contain an incorrect index value,
entire frame SHOULD be silently discarded. This is intended
prevent confusion with the FCS-Alternatives option, but
not be necessary in robust implementations

Since this option is intended to support compression protocols
the Maximum-Pad-Value is specified to limit the likelihood
a frame may actually become longer

A summary of the Self-Describing-Padding Configuration Option
is shown below. The fields are transmitted from left to right

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Maximum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

10

3

Simpson [Page 10]
RFC 1570 PPP LCP extensions January 1994

This field specifies the largest number of padding octets
may be added to the frame. The value may range from 1 to 255,
values of 2, 4, or 8 are most likely

2.3.

This Configuration Option provides a method for an
to request a dial-up peer to call back. This option might be
for many diverse purposes, such as savings on toll charges

When Callback is successfully negotiated, and authentication
complete, the Authentication phase proceeds directly to
Termination phase, and the link is disconnected

Then, the peer re-establishes the link, without
Callback

Implementation Notes

A peer which agrees to this option SHOULD request
Authentication-Protocol Configuration Option. The
information learned during authentication can be used
determine the user location, or to limit a user to
locations, or merely to determine whom to bill for the service

Authentication SHOULD be requested in turn by
implementation when it is called back, if mutual
is desired

A summary of the Callback Option format is shown below. The
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 | Operation | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

13

Simpson [Page 11]
RFC 1570 PPP LCP extensions January 1994

>= 3

The Operation field is one octet and indicates the contents of
Message field

0 location is determined by user

1 Dialing string, the format and contents of which
configuration knowledge of the specific device which
making the callback

2 Location identifier, which may or may not be
readable, to be used together with the
information for a database lookup to determine
callback location

3 E.164 number

4 Distinguished name

The Message field is zero or more octets, and its general
are determined by the Operation field. The actual format of
information is site or application specific, and a
implementation SHOULD support the field as undistinguished octets
The size is determined from the Length field

It is intended that only an authorized user will have correct
specific information to make use of the Callback.
codification of the range of allowed usage of this field
outside the scope of this specification

2.4. Compound-

This Configuration Option provides a method for an
to send multiple PPP encapsulated packets within the same frame
This option might be used for many diverse purposes, such
savings on toll charges

Simpson [Page 12]
RFC 1570 PPP LCP extensions January 1994

Only those PPP Protocols which have determinate lengths
integral length fields may be aggregated into a compound frame

When Compound-Frames is successfully negotiated, the sender
add additional packets to the same frame. Each packet
immediately followed by another Protocol field, with its
datagram

When padding is added to the end of the Information field,
procedure described in Self-Describing-Padding is used
Therefore, this option MUST be negotiated together with the Self
Describing-Padding option

If the FCS-Alternatives option has been negotiated,
describing padding MUST always be added. That is, the
packet MUST be followed by a series of octets, the first of
contains the value one (1).

On receipt, the first Protocol field is examined, and the
is processed as usual. For those datagrams which have
determinate length, the remainder of the frame is returned to
demultiplexor. Each succeeding Protocol field is processed as
separate packet. This processing is complete when a packet
processed which does not have a determinate length, when
remainder of the frame is empty, or when the Protocol field
determined to have a value of one (1).

The PPP Protocol value of one (1) is reserved as the
Protocol. Any following octets are removed as padding

A summary of the Compound-Frames Option format is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

15

2

Simpson [Page 13]
RFC 1570 PPP LCP extensions January 1994

2.4.1. LCP

During initial negotiation, the Compound-Frames option can be used
minimize the negotiation latency, by reducing the number of
exchanged

The first LCP Configure-Request packet is sent as usual in a
frame, including the Self-Describing-Padding and Compound-
options

The peer SHOULD respond with a Configure-Ack, followed in a
frame by its LCP Configure-Request, and any NCP Configure-
desired

Upon receipt, the local implementation SHOULD process the Configure
Ack as usual. Since the peer has agreed to send compound frames,
implementation MUST examine the remainder of the frame for
packets. If the peer also specified the Self-Describing-Padding
Compound-Frames options in its Configure-Request, the
implementation SHOULD retain its Configure-Ack, and further
configuration packets SHOULD be added to the return frame

Together with the peer's final return frame, the minimum number
frames to complete configuration is 4.

Simpson [Page 14]
RFC 1570 PPP LCP extensions January 1994

A. Fast Frame Check Sequence (FCS)

A.1. 32-bit FCS Computation

The following code provides a table lookup computation
calculating the 32-bit Frame Check Sequence as data arrives at
interface

/*
* u32 represents an unsigned 32-bit number. Adjust the typedef
* your hardware
*/
typedef unsigned long u32;

static u32 fcstab_32[256] =
{
0x00000000, 0x77073096, 0xee0e612c, 0x990951ba
0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de
0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec
0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b
0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f
0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d
0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a
0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e
0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c
0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb
0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f
0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad

Simpson [Page 15]
RFC 1570 PPP LCP extensions January 1994

0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a
0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe
0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc
0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b
0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f
0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d
0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a
0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e
0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c
0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db
0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf
0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8
};

#define PPPINITFCS32 0xffffffff /* Initial FCS value */
#define PPPGOODFCS32 0xdebb20e3 /* Good final FCS value */

/*
* Calculate a new FCS given the current FCS and the new data
*/
u32 pppfcs32(fcs, cp, len
register u32 fcs
register unsigned char *cp
register int len
{
ASSERT(sizeof (u32) == 4);
ASSERT(((u32) -1) > 0);
while (len--)

Simpson [Page 16]
RFC 1570 PPP LCP extensions January 1994

fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]);

return (fcs);
}

/*
* How to use the
*/
tryfcs32(cp, len
register unsigned char *cp
register int len
{
u32 trialfcs

/* add on output */
trialfcs = pppfcs32( PPPINITFCS32, cp, len );
trialfcs ^= 0xffffffff; /* complement */
cp[len] = (trialfcs & 0x00ff); /* Least significant byte first */
cp[len+1] = ((trialfcs >>= 8) & 0x00ff);
cp[len+2] = ((trialfcs >>= 8) & 0x00ff);
cp[len+3] = ((trialfcs >> 8) & 0x00ff);

/* check on input */
trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 );
if ( trialfcs == PPPGOODFCS32 )
printf("Good FCS\n");
}

Security

Security issues are briefly discussed in sections concerning
Callback Configuration Option

[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
1548, Daydreamer, December 1993.

[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1340, USC/Information Sciences Institute, July 1992.

[3] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549,
Daydreamer, December 1993.

Simpson [Page 17]
RFC 1570 PPP LCP extensions January 1994

The Identification feature was suggested by Bob Sutterfield (
Star Technologies).

The Time-Remaining feature was suggested by Brad Parker (FCR).

Some of the original text for FCS-Alternatives was provided by
Harvey (then of DEC). The Null FCS was requested by Peter
(UMich). The 32-bit FCS example code was provided by Karl
(Morning Star Technologies).

Self-Describing-Padding was suggested and named by Fred Baker (ACC).

Compound-Frames was suggested by Keith Sklower (Berkeley).

Special thanks to Morning Star Technologies for providing
resources and network access support for writing this specification

Chair's

The working group can be contacted via the current chair

Fred
Advanced Computer
315 Bollay
Santa Barbara, California 93117

EMail: fbaker@acc.

Editor's

Questions about this memo can also be directed to

William Allen

Computer Systems Consulting
1384
Madison Heights, Michigan 48071

EMail: Bill.Simpson@um.cc.umich.
bsimpson@MorningStar.

Simpson [Page 18]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX