Network Working Group M. Engan
INTERNET-DRAFT Lulea University of Technology
Expire in six months January 1997
Header Compression for IPv6 over PPP
<draft-engan-ipv6-hc-00.txt>
Status of this Memo
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working 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 inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``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),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The Point-to-Point Protocol [RFC1548] provides a standard method of
encapsulating Network Layer protocol information over point-to-point
links.
Header Compression for IPv6 [IPv6HC] is a method to compress IPv6
datagram headers (any combination of IPv6, IPv4, TCP and UDP headers
can be compressed).
This document describes methods for transmission of datagrams with
headers compressed by IPv6 Header Compression over point-to-point
links.
Engan [Page 1]
INTERNET-DRAFT Januari 14, 1997
1. Introduction
In order to establish IPv6 Header Compression (IPv6HC) over a PPP
link each end of the link must agree on a set of configuration
parameters for IPv6HC. The process of negotiating link parameters
for network layer protocols is handled by a family of network control
protocols (NCPs).
IPv6HC is not limited to compression of only IPv6 datagram headers
but can also compress IPv4 headers. Header Compression for IPv6 can
be negotiated by either one of the two NCPs that control link
parameters for IPv6 and IPv4. In this document the configuration
option that is used by an NCP to negotiate parameters for IPv6 Header
Compression is defined.
IPv6HC relies on the link layers ability to indicate the types of
datagrams carried in the link layer frames. New PPP Data Link Layer
Protocol Field values need to be allocated to IPv6 Header Compression
otherwise the efficiency of the compression scheme will be lower than
what can be achieved. In this document four new values for the PPP
ProtoID along with their meaning are defined.
2. Configuration Option Format
The IPv6 Header Compression is useful for compression of both IPv4
and IPv6 datagram headers. Therefore both the network control
protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2023]
may be able to negotiate IPv6 Header Compression parameters. The
format of the configuration option is the same for both IPCP and
IPV6CP.
Engan [Page 2]
INTERNET-DRAFT Januari 14, 1997
Description
This NCP configuration option is used to negotiate parameters for
IPv6 Header Compression. The option format is summarized below.
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 | IPV6-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F_MAX_PERIOD | F_MAX_TIME | MAX_HEADER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP_SPACE | NON_TCP_SPACE | FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
2
Length
12
IPV6-Compression-Protocol
TO BE ASSIGNED
F_MAX_PERIOD
Maximum interval between full headers. No more than F_MAX_PERIOD
compressed headers may be sent between full headers.
Default: 256
F_MAX_PERIOD must be at least 1 and at most 65535.
F_MAX_TIME
Maximum time interval between full headers. Compressed headers
may not be sent more than F_MAX_TIME seconds after sending last
full header.
Default: 5 seconds
F_MAX_TIME must be at least 1 and at most 255.
MAX_HEADER
The largest header size in 8-octet units that may be compressed.
Default: 21 (168 octets)
MAX_HEADER must be at least 13 (120 octets) and at most 125 (1000)
Engan [Page 3]
INTERNET-DRAFT Januari 14, 1997
octets.
TCP_SPACE
The TCP_SPACE field is one octet and indicates the maximum value
of a connection identifier in the space of connection identifiers
allocated for TCP.
Default: 16
TCP_SPACE must be at least 3 and at most 255.
NON_TCP_SPACE
The NON_TCP_SPACE field is two octets and indicates the maximum
value of a connection identifier in the space of connection
identifiers allocated for non-TCP.
Default: 15
NON_TCP_SPACE must be at least 3 and at most 65535.
FLAGS
The FLAGS field consists of eight one bit flags. Only one is
currently defined.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R| |
+-+-+-+-+-+-+-+-+
[R] EXPECT_REORDERING
Use mechanisms that protect from link-layer reordering of
datagrams.
Default: 0
3. Multiple Network Control Protocols
The IPv6 Header Compression protocol compresses both IPv6 and IPv4
datagrams. Thus IPv6HC may be useful even if only IPv4 is used on a
link. Therefore both IPCP and IPV6CP should be able to negotiate
option values for IPv6 Header Compression. If a node is capable of
using both IPv6 and IPv4 and is configured to use IPv6 Header
Compression for both network layer protocols over one link, the
header compression option values negotiated by IPV6CP should have
absolute precedence over option values negotiated by IPCP.
If IPCP has completed negotiation of link parameters for IPv4 and
Engan [Page 4]
INTERNET-DRAFT Januari 14, 1997
has applied the IPv6 Header Compression configuration parameters
before IPV6CP has done the same, the parameters negotiated by
IPV6CP should take precedence and the IPv6 Header Compression
should be reinitialized.
If IPV6CP has completed negotiation of link parameters for IPv6
and has applied the IPv6 Header Compression comfiguration
parameters before IPCP has done the same, the parameters
negotiated by IPCP should be discarded.
4. Demultiplexing of Datagrams
The specification of IPv6 Header Compression [IPv6HC] defines four
header formats for different types of compressed headers. They are
compressed TCP, compressed TCP with no delta encoding, compressed
non-TCP with 8 bit CID and compressed non-TCP with 16 bit CID. A
fifth header format, the full header (distinct from a regular header)
is also defined.
For correct decompression the link layer must be able to indicate
that the type of a received datagram is either a full header,
compressed TCP, compressed TCP with no delta encoding or compressed
non-TCP.
Four PPP Data Link Layer Protocol Field values are specified
FULL_HEADER
The frame contains a full header as specified in [IPv6HC] Section
5.3.
Value: TO BE ASSIGNED 1
COMPRESSED_TCP
The frame contains a datagram with a compressed header with the
format as specified in [IPv6HC] Section 6a.
Value: TO BE ASSIGNED 2
COMPRESSED_TCP_NODELTA
The frame contains a datagram with a compressed header with the
format as specified in [IPv6HC] Section 6b.
Value: TO BE ASSIGNED 3
COMPRESSED_NON_TCP
The frame contains a datagram with a compressed header with the
format as specified in either Section 6c or Section 6d of
[IPv6HC].
Value: TO BE ASSIGNED 4
Engan [Page 5]
INTERNET-DRAFT Januari 14, 1997
NOTE:
IPv6 Header Compression should be the only header compression
protocol for compression of IPv6 and IPv4 datagram header used
over a given point-to-point link at a given time. It is not
impossible to use IPv6HC and Van Jacobson header compression at
the same time, but there is no reason to.
The following proposal makes it impossible to use both IPv6HC
and Van Jacobson header compression at the same time:
PROPOSAL
Two PPP Data Link Layer Protocol Field values can be reused if the
two Protocol Field values used by Van Jacobson header compression
are also used by IPv6HC. In addition to the two Van Jacobson
Protocol Field values two more need to be assigned to IPv6HC. At
least one unique Protocol Field value must be assigned to IPv6HC,
otherwise current specifications [RFC2023] will make it impossible
to negotiate configuration parameters for IPv6 Header Compression.
5. References
[RFC1548] Simpson, W., "The Point-To-Point Protocol (PPP)", RFC
1548, December 1993.
[IPv6HC] Degermark, M., Nordgren, B., Pink, S., "Header Compression
for IPv6", Internet-Draft (work in progress), November 26,
1996, expires May 1997.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC2023] Haskin, E., Allan, E., "IP Version 6 over PPP", RFC 2023,
October 1996.
[RFC1144] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
Engan [Page 6]
INTERNET-DRAFT Januari 14, 1997
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Mathias Engan Tel: +46 920 72288
CDT/Dept of Computer Communication Fax: +46 920 72801
Lulea University of Technology Mobile: +46 70 522 8109
S-971 87 Lulea, Sweden EMail: engan@cdt.luth.se
Engan [Page 7]