RFC relevance of compression

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

Network Working Group G.
Request for Comments: 1332
Obsoletes: RFC 1172 May 1992

The PPP Internet Protocol Control Protocol (IPCP

Status of this

This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited

The Point-to-Point Protocol (PPP) [1] provides a standard method
encapsulating Network Layer protocol information over point-to-
links. PPP also defines an extensible Link Control Protocol,
proposes a family of Network Control Protocols (NCPs)
establishing and configuring different network-layer protocols

This document defines the NCP for establishing and configuring
Internet Protocol [2] over PPP, and a method to negotiate and use
Jacobson TCP/IP header compression [3] with PPP

This RFC is a product of the Point-to-Point Protocol Working Group
the Internet Engineering Task Force (IETF).

McGregor [Page i

RFC 1332 PPP IPCP May 1992

Table of

1. Introduction .......................................... 1

2. A PPP Network Control Protocol (NCP) for IP ........... 2
2.1 Sending IP Datagrams ............................ 2

3. IPCP Configuration Options ............................ 4
3.1 IP-Addresses .................................... 5
3.2 IP-Compression-Protocol ......................... 6
3.3 IP-Address ...................................... 8

4. Van Jacobson TCP/IP header compression ................ 9
4.1 Configuration Option Format ..................... 9

APPENDICES ................................................... 11

A. IPCP Recommended Options .............................. 11

SECURITY CONSIDERATIONS ...................................... 11

REFERENCES ................................................... 11

ACKNOWLEDGEMENTS ............................................. 11

CHAIR'S ADDRESS .............................................. 12

AUTHOR'S ADDRESS ............................................. 12

McGregor [Page ii

RFC 1332 PPP IPCP May 1992

1.

PPP has three main components

1. A method for encapsulating datagrams over serial links

2. A Link Control Protocol (LCP) for establishing, configuring
and testing the data-link connection

3. A family of Network Control Protocols (NCPs) for
and configuring different network-layer protocols

In order to establish communications over a point-to-point link,
end of the PPP link must first send LCP packets to configure and
the data link. After the link has been established and
facilities have been negotiated as needed by the LCP, PPP must
NCP packets to choose and configure one or more network-
protocols. Once each of the chosen network-layer protocols has
configured, datagrams from each network-layer protocol can be
over the link

The link will remain configured for communications until explicit
or NCP packets close the link down, or until some external
occurs (an inactivity timer expires or network
intervention).

McGregor [Page 1]

RFC 1332 PPP IPCP May 1992

2. A PPP Network Control Protocol (NCP) for

The IP Control Protocol (IPCP) is responsible for configuring
enabling, and disabling the IP protocol modules on both ends of
point-to-point link. IPCP uses the same packet exchange machanism
the Link Control Protocol (LCP). IPCP packets may not be
until PPP has reached the Network-Layer Protocol phase. IPCP
received before this phase is reached should be silently discarded

The IP Control Protocol is exactly the same as the Link
Protocol [1] with the following exceptions

Data Link Layer Protocol

Exactly one IPCP packet is encapsulated in the Information
of PPP Data Link Layer frames where the Protocol field
type hex 8021 (IP Control Protocol).

Code

Only Codes 1 through 7 (Configure-Request, Configure-Ack
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-
and Code-Reject) are used. Other Codes should be treated
unrecognized and should result in Code-Rejects

IPCP packets may not be exchanged until PPP has reached
Network-Layer Protocol phase. An implementation should
prepared to wait for Authentication and Link Quality
to finish before timing out waiting for a Configure-Ack or
response. It is suggested that an implementation give up
after user intervention or a configurable amount of time

Configuration Option

IPCP has a distinct set of Configuration Options, which
defined below

2.1. Sending IP

Before any IP packets may be communicated, PPP must reach
Network-Layer Protocol phase, and the IP Control Protocol must
the Opened state

Exactly one IP packet is encapsulated in the Information field of
Data Link Layer frames where the Protocol field indicates type
0021 (Internet Protocol).

McGregor [Page 2]

RFC 1332 PPP IPCP May 1992

The maximum length of an IP packet transmitted over a PPP link is
same as the maximum length of the Information field of a PPP
link layer frame. Larger IP datagrams must be fragmented
necessary. If a system wishes to avoid fragmentation and reassembly
it should use the TCP Maximum Segment Size option [4], and
discovery [5].

McGregor [Page 3]

RFC 1332 PPP IPCP May 1992

3. IPCP Configuration

IPCP Configuration Options allow negotiatiation of desirable
Protocol parameters. IPCP uses the same Configuration Option
defined for LCP [1], with a separate set of Options

The most up-to-date values of the IPCP Option Type field are
in the most recent "Assigned Numbers" RFC [6]. Current values
assigned as follows

1 IP-
2 IP-Compression-
3 IP-

McGregor [Page 4]

RFC 1332 PPP IPCP May 1992

3.1. IP-

The use of the Configuration Option IP-Addresses has
deprecated. It has been determined through
experience that it is difficult to ensure negotiation
in all cases using this option. RFC 1172 [7] provides
for implementations requiring backwards compatability. The IP
Address Configuration Option replaces this option, and its use
preferred

This option SHOULD NOT be sent in a Configure-Request if
Configure-Request has been received which includes either an IP
Addresses or IP-Address option. This option MAY be sent if
Configure-Reject is received for the IP-Address option, or
Configure-Nak is received with an IP-Addresses option as
appended option

Support for this option MAY be removed after the IPCP
status advances to Internet Draft Standard

McGregor [Page 5]

RFC 1332 PPP IPCP May 1992

3.2. IP-Compression-

This Configuration Option provides a way to negotiate the use of
specific compression protocol. By default, compression is
enabled

A summary of the IP-Compression-Protocol Configuration Option
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 | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+

2

>= 4

IP-Compression-

The IP-Compression-Protocol field is two octets and indicates
compression protocol desired. Values for this field are
the same as the PPP Data Link Layer Protocol field values for
same compression protocol

The most up-to-date values of the IP-Compression-Protocol
are specified in the most recent "Assigned Numbers" RFC [6].
Current values are assigned as follows

Value (in hex)

002d Van Jacobson Compressed TCP/

The Data field is zero or more octets and contains additional
as determined by the particular compression protocol

McGregor [Page 6]

RFC 1332 PPP IPCP May 1992

No compression protocol enabled

McGregor [Page 7]

RFC 1332 PPP IPCP May 1992

3.3. IP-

This Configuration Option provides a way to negotiate the
address to be used on the local end of the link. It allows
sender of the Configure-Request to state which IP-address
desired, or to request that the peer provide the information.
peer can provide this information by NAKing the option,
returning a valid IP-address

If negotiation about the remote IP-address is required, and
peer did not provide the option in its Configure-Request,
option SHOULD be appended to a Configure-Nak. The value of
IP-address given must be acceptable as the remote IP-address,
indicate a request that the peer provide the information

By default, no IP address is assigned

A summary of the IP-Address Configuration Option format is
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 | IP-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3

6

IP-

The four octet IP-Address is the desired local address of
sender of a Configure-Request. If all four octets are set
zero, it indicates a request that the peer provide the IP-
information

No IP address is assigned

McGregor [Page 8]

RFC 1332 PPP IPCP May 1992

4. Van Jacobson TCP/IP header

Van Jacobson TCP/IP header compression reduces the size of the TCP/
headers to as few as three bytes. This can be a significant
on slow serial lines, particularly for interactive traffic

The IP-Compression-Protocol Configuration Option is used to indicate
ability to receive compressed packets. Each end of the link
separately request this option if bi-directional compression is desired

The PPP Protocol field is set to the following values when
IP packets

Value (in hex

0021 Type IP. The IP protocol is not TCP, or the packet is
fragment, or cannot be compressed

002d Compressed TCP. The TCP/IP headers are replaced by
compressed header

002f Uncompressed TCP. The IP protocol field is replaced
the slot identifier

4.1. Configuration Option

A summary of the IP-Compression-Protocol Configuration Option
to negotiate Van Jacobson TCP/IP header compression 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 | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-Slot-Id | Comp-Slot-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2

6

McGregor [Page 9]

RFC 1332 PPP IPCP May 1992

IP-Compression-

002d (hex) for Van Jacobson Compressed TCP/IP headers

Max-Slot-

The Max-Slot-Id field is one octet and indicates the maximum
identifier. This is one less than the actual number of slots;
slot identifier has values from zero to Max-Slot-Id

Note: There may be implementations that have problems with
one slot (Max-Slot-Id = 0). See the discussion in
[3]. The example implementation in [3] will only work with 3
through 254 slots

Comp-Slot-

The Comp-Slot-Id field is one octet and indicates whether the
identifier field may be compressed

0 The slot identifier must not be compressed. All
TCP packets must set the C bit in every change mask,
must include the slot identifier

1 The slot identifer may be compressed

The slot identifier must not be compressed if there is no
for the PPP link level to indicate an error in reception to
decompression module. Synchronization after errors depends
receiving a packet with the slot identifier. See the
in reference [3].

McGregor [Page 10]

RFC 1332 PPP IPCP May 1992

A. IPCP Recommended

The following Configurations Options are recommended

IP-Compression-Protocol -- with at least 4 slots, usually 16
slots

IP-Address -- only on dial-up lines

Security

Security issues are not discussed in this memo

[1] Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.

[2] Postel, J., "Internet Protocol", RFC 791, USC/
Sciences Institute, September 1981.

[3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144,
1990.

[4] Postel, J., "The TCP Maximum Segment Size Option and
Topics", RFC 879, USC/Information Sciences Institute,
1983.

[5] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.

[6] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.

[7] Perkins, D., and R. Hobby, "Point-to-Point Protocol (PPP
initial configuration options", RFC 1172, August 1990.

Some of the text in this document is taken from RFCs 1171 & 1172,
Drew Perkins of Carnegie Mellon University, and by Russ Hobby of
University of California at Davis

Information leading to the expanded IP-Compression option provided
Van Jacobson at SIGCOMM '90.

McGregor [Page 11]

RFC 1332 PPP IPCP May 1992

Bill Simpson helped with the document formatting

Chair's

The working group can be contacted via the current chair

Brian
Lloyd &
3420 Sudbury
Cameron Park, California 95682

Phone: (916) 676-1147

EMail: brian@ray.lloyd.

Author's

Questions about this memo can also be directed to

Glenn
Merit Network, Inc
1071 Beal
Ann Arbor, MI 48109-2103

Phone: (313) 763-1203

EMail: Glenn.McGregor@Merit.

McGregor [Page 12]

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