Network Working Group W. Simpson, Editor
Internet Draft Daydreamer
expires in six months February 1996
PPP LCP Extensions
draft-ietf-pppext-lcpext-ds-00.txt
Status of this Memo
This document is a submission to the the Point-to-Point Protocol
Working Group of the Internet Engineering Task Force (IETF). Com-
ments should be submitted to the ietf-ppp@merit.edu mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute work-
ing documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as refer-
ence material, or to cite them other than as a ``working draft'' or
``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
Directories on:
ftp.is.co.za (Africa)
nic.nordu.net (Europe)
ds.internic.net (US East Coast)
ftp.isi.edu (US West Coast)
munnari.oz.au (Pacific Rim)
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol (LCP) for establishing,
configuring, and testing the data-link connection. This document
defines several additional LCP features that have been suggested over
the past few years.
Simpson expires in six months [Page i]
DRAFT PPP LCP extensions February 1996
1. Additional LCP Packets
The Packet format and basic facilities are already defined for LCP
[1].
Up-to-date values of the LCP Code field are specified in the most
recent "Assigned Numbers" RFC [2]. This document concerns the fol-
lowing values:
12 Identification
13 Time-Remaining
1.1. Identification
Description
This Code provides a method for an implementation to identify
itself to its peer. This Code might be used for many diverse pur-
poses, such as link troubleshooting, license enforcement, etc.
Identification is a Link Maintenance packet. Identification pack-
ets MAY be sent at any time, including before LCP has reached the
Opened state.
The sender transmits a LCP packet with the Code field set to 12
(Identification), the Identifier field set, the local Magic-Number
(if any) inserted, and the Message field filled with any desired
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 SHOULD gen-
erate the RXJ+ (permitted) event.
Rationale:
This feature is defined as part of LCP, rather than as a sepa-
rate PPP Protocol, in order that its benefits may be available
during the earliest possible stage of the Link Establishment
phase. It allows an operator to learn the identification of
the peer even when negotiation is not converging. Non-LCP
packets cannot be sent during the Link Establishment phase.
This feature is defined as a separate LCP Code, rather than a
Configuration-Option, so that the peer need not include it with
Simpson expires in six months [Page 1]
DRAFT PPP LCP extensions February 1996
other items in configuration packet exchanges, and handle "cor-
rected" values or "rejection", since its generation is both
rare and in one direction. It is recommended that Identifica-
tion packets be sent whenever a Configure-Reject is sent or
received, as a final message when negotiation fails to con-
verge, and when LCP reaches the Opened state.
A summary of the Identification packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+
Code
12 for Identification
Identifier
The Identifier field MUST be changed for each Identification sent.
Length
>= 8
Magic-Number
The Magic-Number field is four octets and aids in detecting links
which are in the looped-back condition. Until the Magic-Number
Configuration Option has been successfully negotiated, the Magic-
Number MUST be transmitted as zero. See the Magic-Number Configu-
ration Option for further explanation.
Message
The Message field is zero or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
that the message contain displayable ASCII characters 32 through
126 decimal. Mechanisms for extension to other character sets are
the topic of future research. The size is determined from the
Simpson expires in six months [Page 2]
DRAFT PPP LCP extensions February 1996
Length field.
Implementation Note:
The Message will usually contain such things as the sender's
hardware type, PPP software revision level, and PPP product
serial number, MIB information such as link speed and interface
name, and any other information that the sender thinks might be
useful in debugging connections. The format is likely to be
different for each implementor, so that those doing serial num-
ber tracking can validate their numbers. A robust implementa-
tion SHOULD treat the Message as displayable text, and SHOULD
be able to receive and display a very long Message.
1.2. Time-Remaining
Description
This Code provides a mechanism for notifying the peer of the time
remaining in this session.
The nature of this information is advisory only. It is intended
that only one side of the connection will send this packet (gener-
ally a "network access server"). The session is actually con-
cluded by the Terminate-Request packet.
Time-Remaining is a Link Maintenance packet. Time-Remaining pack-
ets 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-Number
(if any) inserted, and the Message field filled with any desired
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 SHOULD gen-
erate the RXJ+ (permitted) event.
Rationale:
This notification is defined as a separate LCP Code, rather
than a Configuration-Option, in order that changes and warning
messages may occur dynamically during the session, and that the
information might be determined after Authentication has
occurred. Typically, this packet is sent when the link enters
Simpson expires in six months [Page 3]
DRAFT PPP LCP extensions February 1996
Network-Layer Protocol phase, and at regular intervals through-
out the session, particularly near the end of the session.
A summary of the Time-Remaining packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds-Remaining |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+
Code
13 for Time-Remaining
Identifier
The Identifier field MUST be changed for each Time-Remaining sent.
Length
>= 12
Magic-Number
The Magic-Number field is four octets and aids in detecting links
which are in the looped-back condition. Until the Magic-Number
Configuration Option has been successfully negotiated, the Magic-
Number MUST be transmitted as zero. See the Magic-Number Configu-
ration Option for further explanation.
Seconds-Remaining
The Seconds-Remaining field is four octets and indicates the num-
ber of integral seconds remaining in this session. This 32 bit
unsigned value is sent most significant octet first. A value of
0xffffffff (all ones) represents no timeout, or "forever".
Simpson expires in six months [Page 4]
DRAFT PPP LCP extensions February 1996
Message
The Message field is zero or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
that the message contain displayable ASCII characters 32 through
126 decimal. Mechanisms for extension to other character sets are
the topic of future research. The size is determined from the
Length field.
Simpson expires in six months [Page 5]
DRAFT PPP LCP extensions February 1996
2. Additional LCP Configuration Options
The Configuration Option format and basic options are already defined
for LCP [1].
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:
10 Self-Describing-Padding
13 Callback
2.1. Self-Describing-Padding
Description
This Configuration Option provides a method for an implementation
to indicate to the peer that it understands self-describing pads
when padding is added at the end of the PPP Information field.
This option is most likely to be used when some protocols, such as
network-layer or compression protocols, are configured which
require detection and removal of any trailing padding. Such spe-
cial protocols are identified in their respective documents.
If the option is Rejected, the peer MUST NOT add any padding to
any identified special protocols, but MAY add padding to other
protocols.
If the option is Ack'd, the peer MUST follow the procedures for
adding self-describing pads, but only to the specifically identi-
fied protocols. The peer is not required to add any padding to
other protocols.
Implementation Notes:
This is defined so that the Reject handles either case where
the peer does not generate self-describing pads. When the peer
never generates padding, it may safely Reject the option. When
the peer does not understand the option, it also will not suc-
cessfully configure a special protocol which requires elimina-
tion of pads.
While some senders might only be capable of adding padding to
every protocol or not adding padding to any protocol, by design
the receiver need not examine those protocols which do not need
Simpson expires in six months [Page 6]
DRAFT PPP LCP extensions February 1996
the padding stripped.
To avoid unnecessary configuration handshakes, an implementa-
tion which generates padding, and has a protocol configured
which requires the padding to be known, SHOULD include this
Option in its Configure-Request, and SHOULD Configure-Nak with
this Option when it is not present in the peer's Request.
Each octet of self-describing pad contains the index of that
octet. The first pad octet MUST contain the value one (1), which
indicates the Padding Protocol to the Compound-Frames option.
After removing the FCS, the final pad octet indicates the number
of pad octets to remove. For example, three pad octets would con-
tain 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 be
required, but the final octet of the PPP Information field con-
tains the value 1 through MPV, at least one self-describing pad
octet MUST be added to the frame. If the final octet is greater
than MPV, no additional padding is required.
Implementation Notes:
If any of the pad octets contain an incorrect index value, the
entire frame SHOULD be silently discarded. This is intended to
prevent confusion with the FCS-Alternatives option, but might
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 that
a frame may actually become longer.
A summary of the Self-Describing-Padding Configuration Option format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
10
Simpson expires in six months [Page 7]
DRAFT PPP LCP extensions February 1996
Length
3
Maximum
This field specifies the largest number of padding octets which
may be added to the frame. The value may range from 0 to 255.
The value 0 indicates that Self-Defining-Padding is understood,
but no padding is expected. Values of 2, 4, or 8 are most likely.
2.2. Callback
Description
This Configuration Option provides a method for an implementation
to request a dial-up peer to call back. This option might be used
for many diverse purposes, such as savings on toll charges.
When Callback is successfully negotiated, and authentication is
complete, the Authentication phase proceeds directly to the Termi-
nation phase, and the link is disconnected.
Then, the peer re-establishes the link, without negotiating Call-
back.
Implementation Notes:
A peer which agrees to this option SHOULD request the Authenti-
cation-Protocol Configuration Option. The user information
learned during authentication can be used to determine the user
location, or to limit a user to certain locations, or merely to
determine whom to bill for the service.
Authentication SHOULD be requested in turn by the implementa-
tion when it is called back, if mutual authentication is
desired.
A summary of the Callback Option format is shown below. The fields
are transmitted from left to right.
Simpson expires in six months [Page 8]
DRAFT PPP LCP extensions February 1996
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
13
Length
>= 3
Operation
The Operation field is one octet and indicates the contents of the
Message field.
0 location is determined by user authentication
1 Dialing string, the format and contents of which assumes
configuration knowledge of the specific device which is
making the callback.
2 Location identifier, which may or may not be human read-
able, to be used together with the authentication informa-
tion for a database lookup to determine the callback loca-
tion.
3 E.164 number.
4 Distinguished name.
Message
The Message field is zero or more octets, and its general contents
are determined by the Operation field. The actual format of the
information is site or application specific, and a robust imple-
mentation 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 site
specific information to make use of the Callback. The codifica-
tion of the range of allowed usage of this field is outside the
scope of this specification.
Simpson expires in six months [Page 9]
DRAFT PPP LCP extensions February 1996
Security Considerations
Security issues are briefly discussed in sections concerning the
Callback Configuration Option.
Acknowledgements
The Identification feature was suggested by Bob Sutterfield (Morning
Star Technologies).
The Time-Remaining feature was suggested by Brad Parker (FCR).
Self-Describing-Padding was suggested and named by Fred Baker
(Cisco).
Special thanks to Morning Star Technologies for providing computing
resources and network access support for writing this specification.
References
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
1661, December 1993.
[2] Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC 1700,
July 1992.
[3] Simpson, W., Editor, "PPP in HDLC-like Framing", RFC 1662,
December 1993.
Chair's Address
The working group can be contacted via the current chair:
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117
EMail: fbaker@acc.com
Editor's Address
Simpson expires in six months [Page 10]
DRAFT PPP LCP extensions February 1996
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com (prefered)
Simpson expires in six months [Page 11]
