As per Relevance of the word datagram, we have this rfc below:
Network Working Group Internet Engineering Task
Request for Comments: 1122 R. Braden,
October 1989
Requirements for Internet Hosts -- Communication
Status of This
This RFC is an official specification for the Internet community.
incorporates by reference, amends, corrects, and supplements
primary protocol standards documents relating to hosts.
of this document is unlimited
This is one RFC of a pair that defines and discusses the
for Internet host software. This RFC covers the
protocol layers: link layer, IP layer, and transport layer;
companion RFC-1123 covers the application and support protocols
Table of
1. INTRODUCTION ............................................... 5
1.1 The Internet Architecture .............................. 6
1.1.1 Internet Hosts .................................... 6
1.1.2 Architectural Assumptions ......................... 7
1.1.3 Internet Protocol Suite ........................... 8
1.1.4 Embedded Gateway Code ............................. 10
1.2 General Considerations ................................. 12
1.2.1 Continuing Internet Evolution ..................... 12
1.2.2 Robustness Principle .............................. 12
1.2.3 Error Logging ..................................... 13
1.2.4 Configuration ..................................... 14
1.3 Reading this Document .................................. 15
1.3.1 Organization ...................................... 15
1.3.2 Requirements ...................................... 16
1.3.3 Terminology ....................................... 17
1.4 Acknowledgments ........................................ 20
2. LINK LAYER .................................................. 21
2.1 INTRODUCTION ........................................... 21
Internet Engineering Task Force [Page 1]
RFC1122 INTRODUCTION October 1989
2.2 PROTOCOL WALK-THROUGH .................................. 21
2.3 SPECIFIC ISSUES ........................................ 21
2.3.1 Trailer Protocol Negotiation ...................... 21
2.3.2 Address Resolution Protocol -- ARP ................ 22
2.3.2.1 ARP Cache Validation ......................... 22
2.3.2.2 ARP Packet Queue ............................. 24
2.3.3 Ethernet and IEEE 802 Encapsulation ............... 24
2.4 LINK/INTERNET LAYER INTERFACE .......................... 25
2.5 LINK LAYER REQUIREMENTS SUMMARY ........................ 26
3. INTERNET LAYER PROTOCOLS .................................... 27
3.1 INTRODUCTION ............................................ 27
3.2 PROTOCOL WALK-THROUGH .................................. 29
3.2.1 Internet Protocol -- IP ............................ 29
3.2.1.1 Version Number ............................... 29
3.2.1.2 Checksum ..................................... 29
3.2.1.3 Addressing ................................... 29
3.2.1.4 Fragmentation and Reassembly ................. 32
3.2.1.5 Identification ............................... 32
3.2.1.6 Type-of-Service .............................. 33
3.2.1.7 Time-to-Live ................................. 34
3.2.1.8 Options ...................................... 35
3.2.2 Internet Control Message Protocol -- ICMP .......... 38
3.2.2.1 Destination Unreachable ...................... 39
3.2.2.2 Redirect ..................................... 40
3.2.2.3 Source Quench ................................ 41
3.2.2.4 Time Exceeded ................................ 41
3.2.2.5 Parameter Problem ............................ 42
3.2.2.6 Echo Request/Reply ........................... 42
3.2.2.7 Information Request/Reply .................... 43
3.2.2.8 Timestamp and Timestamp Reply ................ 43
3.2.2.9 Address Mask Request/Reply ................... 45
3.2.3 Internet Group Management Protocol IGMP ........... 47
3.3 SPECIFIC ISSUES ........................................ 47
3.3.1 Routing Outbound Datagrams ........................ 47
3.3.1.1 Local/Remote Decision ........................ 47
3.3.1.2 Gateway Selection ............................ 48
3.3.1.3 Route Cache .................................. 49
3.3.1.4 Dead Gateway Detection ....................... 51
3.3.1.5 New Gateway Selection ........................ 55
3.3.1.6 Initialization ............................... 56
3.3.2 Reassembly ........................................ 56
3.3.3 Fragmentation ..................................... 58
3.3.4 Local Multihoming ................................. 60
3.3.4.1 Introduction ................................. 60
3.3.4.2 Multihoming Requirements ..................... 61
3.3.4.3 Choosing a Source Address .................... 64
3.3.5 Source Route Forwarding ........................... 65
Internet Engineering Task Force [Page 2]
RFC1122 INTRODUCTION October 1989
3.3.6 Broadcasts ........................................ 66
3.3.7 IP Multicasting ................................... 67
3.3.8 Error Reporting ................................... 69
3.4 INTERNET/TRANSPORT LAYER INTERFACE ..................... 69
3.5 INTERNET LAYER REQUIREMENTS SUMMARY .................... 72
4. TRANSPORT PROTOCOLS ......................................... 77
4.1 USER DATAGRAM PROTOCOL -- UDP .......................... 77
4.1.1 INTRODUCTION ...................................... 77
4.1.2 PROTOCOL WALK-THROUGH ............................. 77
4.1.3 SPECIFIC ISSUES ................................... 77
4.1.3.1 Ports ........................................ 77
4.1.3.2 IP Options ................................... 77
4.1.3.3 ICMP Messages ................................ 78
4.1.3.4 UDP Checksums ................................ 78
4.1.3.5 UDP Multihoming .............................. 79
4.1.3.6 Invalid Addresses ............................ 79
4.1.4 UDP/APPLICATION LAYER INTERFACE ................... 79
4.1.5 UDP REQUIREMENTS SUMMARY .......................... 80
4.2 TRANSMISSION CONTROL PROTOCOL -- TCP ................... 82
4.2.1 INTRODUCTION ...................................... 82
4.2.2 PROTOCOL WALK-THROUGH ............................. 82
4.2.2.1 Well-Known Ports ............................. 82
4.2.2.2 Use of Push .................................. 82
4.2.2.3 Window Size .................................. 83
4.2.2.4 Urgent Pointer ............................... 84
4.2.2.5 TCP Options .................................. 85
4.2.2.6 Maximum Segment Size Option .................. 85
4.2.2.7 TCP Checksum ................................. 86
4.2.2.8 TCP Connection State Diagram ................. 86
4.2.2.9 Initial Sequence Number Selection ............ 87
4.2.2.10 Simultaneous Open Attempts .................. 87
4.2.2.11 Recovery from Old Duplicate SYN ............. 87
4.2.2.12 RST Segment ................................. 87
4.2.2.13 Closing a Connection ........................ 87
4.2.2.14 Data Communication .......................... 89
4.2.2.15 Retransmission Timeout ...................... 90
4.2.2.16 Managing the Window ......................... 91
4.2.2.17 Probing Zero Windows ........................ 92
4.2.2.18 Passive OPEN Calls .......................... 92
4.2.2.19 Time to Live ................................ 93
4.2.2.20 Event Processing ............................ 93
4.2.2.21 Acknowledging Queued Segments ............... 94
4.2.3 SPECIFIC ISSUES ................................... 95
4.2.3.1 Retransmission Timeout Calculation ........... 95
4.2.3.2 When to Send an ACK Segment .................. 96
4.2.3.3 When to Send a Window Update ................. 97
4.2.3.4 When to Send Data ............................ 98
Internet Engineering Task Force [Page 3]
RFC1122 INTRODUCTION October 1989
4.2.3.5 TCP Connection Failures ...................... 100
4.2.3.6 TCP Keep-Alives .............................. 101
4.2.3.7 TCP Multihoming .............................. 103
4.2.3.8 IP Options ................................... 103
4.2.3.9 ICMP Messages ................................ 103
4.2.3.10 Remote Address Validation ................... 104
4.2.3.11 TCP Traffic Patterns ........................ 104
4.2.3.12 Efficiency .................................. 105
4.2.4 TCP/APPLICATION LAYER INTERFACE ................... 106
4.2.4.1 Asynchronous Reports ......................... 106
4.2.4.2 Type-of-Service .............................. 107
4.2.4.3 Flush Call ................................... 107
4.2.4.4 Multihoming .................................. 108
4.2.5 TCP REQUIREMENT SUMMARY ........................... 108
5. REFERENCES ................................................. 112
Internet Engineering Task Force [Page 4]
RFC1122 INTRODUCTION October 1989
1.
This document is one of a pair that defines and discusses
requirements for host system implementations of the Internet
suite. This RFC covers the communication protocol layers:
layer, IP layer, and transport layer. Its companion RFC
"Requirements for Internet Hosts -- Application and Support
[INTRO:1], covers the application layer protocols. This
should also be read in conjunction with "Requirements for
Gateways" [INTRO:2].
These documents are intended to provide guidance for vendors
implementors, and users of Internet communication software.
represent the consensus of a large body of technical experience
wisdom, contributed by the members of the Internet research
vendor communities
This RFC enumerates standard protocols that a host connected to
Internet must use, and it incorporates by reference the RFCs
other documents describing the current specifications for
protocols. It corrects errors in the referenced documents and
additional discussion and guidance for an implementor
For each protocol, this document also contains an explicit set
requirements, recommendations, and options. The reader
understand that the list of requirements in this document
incomplete by itself; the complete set of requirements for
Internet host is primarily defined in the standard
specification documents, with the corrections, amendments,
supplements contained in this RFC
A good-faith implementation of the protocols that was produced
careful reading of the RFC's and with some interaction with
Internet technical community, and that followed good
software engineering practices, should differ from the
of this document in only minor ways. Thus, in many cases,
"requirements" in this RFC are already stated or implied in
standard protocol documents, so that their inclusion here is, in
sense, redundant. However, they were included because some
implementation has made the wrong choice, causing problems
interoperability, performance, and/or robustness
This document includes discussion and explanation of many of
requirements and recommendations. A simple list of
would be dangerous, because
o Some required features are more important than others, and
features are optional
Internet Engineering Task Force [Page 5]
RFC1122 INTRODUCTION October 1989
o There may be valid reasons why particular vendor products
are designed for restricted contexts might choose to
different specifications
However, the specifications of this document must be followed to
the general goal of arbitrary host interoperation across
diversity and complexity of the Internet system. Although
current implementations fail to meet these requirements in
ways, some minor and some major, this specification is the
towards which we need to move
These requirements are based on the current level of
architecture. This document will be updated as required to
additional clarifications or to include additional information
those areas in which specifications are still evolving
This introductory section begins with a brief overview of
Internet architecture as it relates to hosts, and then gives
general advice to host software vendors. Finally, there is
guidance on reading the rest of the document and some terminology
1.1 The Internet
General background and discussion on the Internet architecture
supporting protocol suite can be found in the DDN
Handbook [INTRO:3]; for background see for example [INTRO:9],
[INTRO:10], and [INTRO:11]. Reference [INTRO:5] describes
procedure for obtaining Internet protocol documents,
[INTRO:6] contains a list of the numbers assigned within
protocols
1.1.1 Internet
A host computer, or simply "host," is the ultimate consumer
communication services. A host generally executes
programs on behalf of user(s), employing network and/
Internet communication services in support of this function
An Internet host corresponds to the concept of an "End-System
used in the OSI protocol suite [INTRO:13].
An Internet communication system consists of
packet networks supporting communication among host
using the Internet protocols. The networks are
using packet-switching computers called "gateways" or "
routers" by the Internet community, and "Intermediate Systems
by the OSI world [INTRO:13]. The RFC "Requirements
Internet Gateways" [INTRO:2] contains the
specifications for Internet gateways. That RFC together
Internet Engineering Task Force [Page 6]
RFC1122 INTRODUCTION October 1989
the present document and its companion [INTRO:1] define
rules for the current realization of the Internet architecture
Internet hosts span a wide range of size, speed, and function
They range in size from small microprocessors
workstations to mainframes and supercomputers. In function
they range from single-purpose hosts (such as terminal servers
to full-service hosts that support a variety of online
services, typically including remote login, file transfer,
electronic mail
A host is generally said to be multihomed if it has more
one interface to the same or to different networks.
Section 1.1.3 on "Terminology".
1.1.2 Architectural
The current Internet architecture is based on a set
assumptions about the communication system. The
most relevant to hosts are as follows
(a) The Internet is a network of networks
Each host is directly connected to some
network(s); its connection to the Internet is
conceptual. Two hosts on the same network
with each other using the same set of protocols that
would use to communicate with hosts on distant networks
(b) Gateways don't keep connection state information
To improve robustness of the communication system
gateways are designed to be stateless, forwarding each
datagram independently of other datagrams. As a result
redundant paths can be exploited to provide robust
in spite of failures of intervening gateways and networks
All state information required for end-to-end flow
and reliability is implemented in the hosts, in
transport layer or in application programs.
connection control information is thus co-located with
end points of the communication, so it will be lost
if an end point fails
(c) Routing complexity should be in the gateways
Routing is a complex and difficult problem, and ought
be performed by the gateways, not the hosts. An
Internet Engineering Task Force [Page 7]
RFC1122 INTRODUCTION October 1989
objective is to insulate host software from changes
by the inevitable evolution of the Internet
architecture
(d) The System must tolerate wide network variation
A basic objective of the Internet design is to tolerate
wide range of network characteristics -- e.g., bandwidth
delay, packet loss, packet reordering, and maximum
size. Another objective is robustness against failure
individual networks, gateways, and hosts, using
bandwidth is still available. Finally, the goal is
"open system interconnection": an Internet host must
able to interoperate robustly and effectively with
other Internet host, across diverse Internet paths
Sometimes host implementors have designed for
ambitious goals. For example, the LAN environment
typically much more benign than the Internet as a whole
LANs have low packet loss and delay and do not
packets. Some vendors have fielded host
that are adequate for a simple LAN environment, but
badly for general interoperation. The vendor
such a product as being economical within the
LAN market. However, isolated LANs seldom stay
for long; they are soon gatewayed to each other,
organization-wide internets, and eventually to the
Internet system. In the end, neither the customer nor
vendor is served by incomplete or substandard
host software
The requirements spelled out in this document are
for a full-function Internet host, capable of
interoperation over an arbitrary Internet path
1.1.3 Internet Protocol
To communicate using the Internet system, a host must
the layered set of protocols comprising the Internet
suite. A host typically must implement at least one
from each layer
The protocol layers used in the Internet architecture are
follows [INTRO:4]:
o Application
Internet Engineering Task Force [Page 8]
RFC1122 INTRODUCTION October 1989
The application layer is the top layer of the
protocol suite. The Internet suite does not
subdivide the application layer, although some of
Internet application layer protocols do contain
internal sub-layering. The application layer of
Internet suite essentially combines the functions of
top two layers -- Presentation and Application -- of
OSI reference model
We distinguish two categories of application
protocols: user protocols that provide service
to users, and support protocols that provide common
functions. Requirements for user and support
will be found in the companion RFC [INTRO:1].
The most common Internet user protocols are
o Telnet (remote login
o FTP (file transfer
o SMTP (electronic mail delivery
There are a number of other standardized user
[INTRO:4] and many private user protocols
Support protocols, used for host name mapping, booting
and management, include SNMP, BOOTP, RARP, and the
Name System (DNS) protocols
o Transport
The transport layer provides end-to-end
services for applications. There are two
transport layer protocols at present
o Transmission Control Protocol (TCP
o User Datagram Protocol (UDP
TCP is a reliable connection-oriented transport
that provides end-to-end reliability, resequencing,
flow control. UDP is a connectionless ("datagram")
transport service
Other transport protocols have been developed by
research community, and the set of official
transport protocols may be expanded in the future
Transport layer protocols are discussed in Chapter 4.
Internet Engineering Task Force [Page 9]
RFC1122 INTRODUCTION October 1989
o Internet
All Internet transport protocols use the Internet
(IP) to carry data from source host to destination host
IP is a connectionless or datagram internetwork service
providing no end-to-end delivery guarantees. Thus,
datagrams may arrive at the destination host damaged
duplicated, out of order, or not at all. The layers
IP are responsible for reliable delivery service when
is required. The IP protocol includes provision
addressing, type-of-service specification,
and reassembly, and security information
The datagram or connectionless nature of the IP
is a fundamental and characteristic feature of
Internet architecture. Internet IP was the model for
OSI Connectionless Network Protocol [INTRO:12].
ICMP is a control protocol that is considered to be
integral part of IP, although it is
layered upon IP, i.e., it uses IP to carry its data end
to-end just as a transport protocol like TCP or UDP does
ICMP provides error reporting, congestion reporting,
first-hop gateway redirection
IGMP is an Internet layer protocol used for
dynamic host groups for IP multicasting
The Internet layer protocols IP, ICMP, and IGMP
discussed in Chapter 3.
o Link
To communicate on its directly-connected network, a
must implement the communication protocol used
interface to that network. We call this a link layer
media-access layer protocol
There is a wide variety of link layer protocols
corresponding to the many different types of networks
See Chapter 2.
1.1.4 Embedded Gateway
Some Internet host software includes embedded
functionality, so that these hosts can forward packets as
Internet Engineering Task Force [Page 10]
RFC1122 INTRODUCTION October 1989
gateway would, while still performing the application
functions of a host
Such dual-purpose systems must follow the Gateway
RFC [INTRO:2] with respect to their gateway functions,
must follow the present document with respect to their
functions. In all overlapping cases, the two
should be in agreement
There are varying opinions in the Internet community
embedded gateway functionality. The main arguments are
follows
o Pro: in a local network environment where networking
informal, or in isolated internets, it may be
and economical to use existing host systems as gateways
There is also an architectural argument for
gateway functionality: multihoming is much more
than originally foreseen, and multihoming forces a host
make routing decisions as if it were a gateway. If
multihomed host contains an embedded gateway, it
have full routing knowledge and as a result will be
to make more optimal routing decisions
o Con: Gateway algorithms and protocols are still changing
and they will continue to change as the Internet
grows larger. Attempting to include a general
function within the host IP layer will force host
maintainers to track these (more frequent) changes. Also
a larger pool of gateway implementations will
coordinating the changes more difficult. Finally,
complexity of a gateway IP layer is somewhat greater
that of a host, making the implementation and
tasks more complex
In addition, the style of operation of some hosts is
appropriate for providing stable and robust
service
There is considerable merit in both of these viewpoints.
conclusion can be drawn: an host administrator must
conscious control over whether or not a given host acts as
gateway. See Section 3.1 for the detailed requirements
Internet Engineering Task Force [Page 11]
RFC1122 INTRODUCTION October 1989
1.2 General
There are two important lessons that vendors of Internet
software have learned and which a new vendor should
seriously
1.2.1 Continuing Internet
The enormous growth of the Internet has revealed problems
management and scaling in a large datagram-based
communication system. These problems are being addressed,
as a result there will be continuing evolution of
specifications described in this document. These changes
be carefully planned and controlled, since there is
participation in this planning by the vendors and by
organizations responsible for operations of the networks
Development, evolution, and revision are characteristic
computer network protocols today, and this situation
persist for some years. A vendor who develops
communication software for the Internet protocol suite (or
other protocol suite!) and then fails to maintain and
that software for changing specifications is going to leave
trail of unhappy customers. The Internet is a
communication network, and the users are in constant
through it. Experience has shown that knowledge
deficiencies in vendor software propagates quickly through
Internet technical community
1.2.2 Robustness
At every layer of the protocols, there is a general rule
application can lead to enormous benefits in robustness
interoperability [IP:1]:
"Be liberal in what you accept,
conservative in what you send
Software should be written to deal with every
error, no matter how unlikely; sooner or later a packet
come in with that particular combination of errors
attributes, and unless the software is prepared, chaos
ensue. In general, it is best to assume that the network
filled with malevolent entities that will send in
designed to have the worst possible effect. This
will lead to suitable protective design, although the
serious problems in the Internet have been caused
unenvisaged mechanisms triggered by low-probability events
Internet Engineering Task Force [Page 12]
RFC1122 INTRODUCTION October 1989
mere human malice would never have taken so devious a course
Adaptability to change must be designed into all levels
Internet host software. As a simple example, consider
protocol specification that contains an enumeration of
for a particular header field -- e.g., a type field, a
number, or an error code; this enumeration must be assumed
be incomplete. Thus, if a protocol specification defines
possible error codes, the software must not break when a
code shows up. An undefined code might be logged (see below),
but it must not cause a failure
The second part of the principle is almost as important
software on other hosts may contain deficiencies that make
unwise to exploit legal but obscure protocol features. It
unwise to stray far from the obvious and simple, lest
effects result elsewhere. A corollary of this is "watch
for misbehaving hosts"; host software should be prepared,
just to survive other misbehaving hosts, but also to
to limit the amount of disruption such hosts can cause to
shared communication facility
1.2.3 Error
The Internet includes a great variety of host and
systems, each implementing many protocols and protocol layers
and some of these contain bugs and mis-features in
Internet protocol software. As a result of complexity
diversity, and distribution of function, the diagnosis
Internet problems is often very difficult
Problem diagnosis will be aided if host implementations
a carefully designed facility for logging erroneous
"strange" protocol events. It is important to include as
diagnostic information as possible when an error is logged.
particular, it is often useful to record the header(s) of
packet that caused an error. However, care must be taken
ensure that error logging does not consume prohibitive
of resources or otherwise interfere with the operation of
host
There is a tendency for abnormal but harmless protocol
to overflow error logging files; this can be avoided by using
"circular" log, or by enabling logging only while diagnosing
known failure. It may be useful to filter and count
successive messages. One strategy that seems to work well is
(1) always count abnormalities and make such counts
through the management protocol (see [INTRO:1]); and (2)
Internet Engineering Task Force [Page 13]
RFC1122 INTRODUCTION October 1989
the logging of a great variety of events to be
enabled. For example, it might useful to be able to "
everything" or to "log everything for host X".
Note that different managements may have differing
about the amount of error logging that they want
enabled in a host. Some will say, "if it doesn't hurt me,
don't want to know about it", while others will want to take
more watchful and aggressive attitude about detecting
removing protocol abnormalities
1.2.4
It would be ideal if a host implementation of the
protocol suite could be entirely self-configuring. This
allow the whole suite to be implemented in ROM or cast
silicon, it would simplify diskless workstations, and it
be an immense boon to harried LAN administrators as well
system vendors. We have not reached this ideal; in fact,
are not even close
At many points in this document, you will find a
that a parameter be a configurable option. There are
different reasons behind such requirements. In a few cases
there is current uncertainty or disagreement about the
value, and it may be necessary to update the recommended
in the future. In other cases, the value really depends
external factors -- e.g., the size of the host and
distribution of its communication load, or the speeds
topology of nearby networks -- and self-tuning algorithms
unavailable and may be insufficient. In some cases
configurability is needed because of
requirements
Finally, some configuration options are required to
with obsolete or incorrect implementations of the protocols
distributed without sources, that unfortunately persist in
parts of the Internet. To make correct systems coexist
these faulty systems, administrators often have to "mis
configure" the correct systems. This problem will
itself gradually as the faulty systems are retired, but
cannot be ignored by vendors
When we say that a parameter must be configurable, we do
intend to require that its value be explicitly read from
configuration file at every boot time. We recommend
implementors set up a default for each parameter, so
configuration file is only necessary to override those
Internet Engineering Task Force [Page 14]
RFC1122 INTRODUCTION October 1989
that are inappropriate in a particular installation. Thus,
configurability requirement is an assurance that it will
POSSIBLE to override the default when necessary, even in
binary-only or ROM-based product
This document requires a particular value for such defaults
some cases. The choice of default is a sensitive issue
the configuration item controls the accommodation to
faulty systems. If the Internet is to converge successfully
complete interoperability, the default values built
implementations must implement the official protocol,
"mis-configurations" to accommodate faulty implementations
Although marketing considerations have led some vendors
choose mis-configuration defaults, we urge vendors to
defaults that will conform to the standard
Finally, we note that a vendor needs to provide
documentation on all configuration parameters, their limits
effects
1.3 Reading this
1.3.1
Protocol layering, which is generally used as an
principle in implementing network software, has also been
to organize this document. In describing the rules, we
that an implementation does strictly mirror the layering of
protocols. Thus, the following three major sections
the requirements for the link layer, the internet layer,
the transport layer, respectively. A companion RFC [INTRO:1]
covers application level software. This layerist
was chosen for simplicity and clarity
However, strict layering is an imperfect model, both for
protocol suite and for recommended implementation approaches
Protocols in different layers interact in complex and
subtle ways, and particular functions often involve
layers. There are many design choices in an implementation
many of which involve creative "breaking" of strict layering
Every implementor is urged to read references [INTRO:7]
[INTRO:8].
This document describes the conceptual service
between layers using a functional ("procedure call") notation
like that used in the TCP specification [TCP:1]. A
implementation must support the logical information
Internet Engineering Task Force [Page 15]
RFC1122 INTRODUCTION October 1989
implied by these calls, but need not literally implement
calls themselves. For example, many implementations
the coupling between the transport layer and the IP layer
giving them shared access to common data structures.
data structures, rather than explicit procedure calls, are
the agency for passing much of the information that
required
In general, each major section of this document is
into the following subsections
(1)
(2) Protocol Walk-Through -- considers the
specification documents section-by-section,
errors, stating requirements that may be ambiguous
ill-defined, and providing further clarification
explanation
(3) Specific Issues -- discusses protocol design
implementation issues that were not included in the walk
through
(4) Interfaces -- discusses the service interface to the
higher layer
(5) Summary -- contains a summary of the requirements of
section
Under many of the individual topics in this document, there
parenthetical material labeled "DISCUSSION"
"IMPLEMENTATION". This material is intended to
clarification and explanation of the preceding
text. It also includes some suggestions on possible
directions or developments. The implementation
contains suggested approaches that an implementor may want
consider
The summary sections are intended to be guides and indexes
the text, but are necessarily cryptic and incomplete.
summaries should never be used or referenced separately
the complete RFC
1.3.2
In this document, the words that are used to define
significance of each particular requirement are capitalized
Internet Engineering Task Force [Page 16]
RFC1122 INTRODUCTION October 1989
These words are
* "MUST
This word or the adjective "REQUIRED" means that the
is an absolute requirement of the specification
* "SHOULD
This word or the adjective "RECOMMENDED" means that
may exist valid reasons in particular circumstances
ignore this item, but the full implications should
understood and the case carefully weighed before
a different course
* "MAY
This word or the adjective "OPTIONAL" means that this
is truly optional. One vendor may choose to include
item because a particular marketplace requires it
because it enhances the product, for example;
vendor may omit the same item
An implementation is not compliant if it fails to satisfy
or more of the MUST requirements for the protocols
implements. An implementation that satisfies all the MUST
all the SHOULD requirements for its protocols is said to
"unconditionally compliant"; one that satisfies all the
requirements but not all the SHOULD requirements for
protocols is said to be "conditionally compliant".
1.3.3
This document uses the following technical terms
A segment is the unit of end-to-end transmission in
TCP protocol. A segment consists of a TCP header
by application data. A segment is transmitted
encapsulation inside an IP datagram
In this description of the lower-layer protocols,
message is the unit of transmission in a transport
protocol. In particular, a TCP segment is a message.
message consists of a transport protocol header
by application protocol data. To be transmitted end-to
Internet Engineering Task Force [Page 17]
RFC1122 INTRODUCTION October 1989
end through the Internet, a message must be
inside a datagram
IP
An IP datagram is the unit of end-to-end transmission
the IP protocol. An IP datagram consists of an IP
followed by transport layer data, i.e., of an IP
followed by a message
In the description of the internet layer (Section 3),
unqualified term "datagram" should be understood to
to an IP datagram
A packet is the unit of data passed across the
between the internet layer and the link layer.
includes an IP header and data. A packet may be
complete IP datagram or a fragment of an IP datagram
A frame is the unit of transmission in a link
protocol, and consists of a link-layer header followed
a packet
Connected
A network to which a host is interfaced is often known
the "local network" or the "subnetwork" relative to
host. However, these terms can cause confusion,
therefore we use the term "connected network" in
document
A host is said to be multihomed if it has multiple
addresses. For a discussion of multihoming, see
3.3.4 below
Physical network
This is a physical interface to a connected network
has a (possibly unique) link-layer address.
physical network interfaces on a single host may share
same link-layer address, but the address must be
for different hosts on the same physical network
Logical [network]
We define a logical [network] interface to be a
path, distinguished by a unique IP address, to a
network. See Section 3.3.4.
Internet Engineering Task Force [Page 18]
RFC1122 INTRODUCTION October 1989
Specific-destination
This is the effective destination address of a datagram
even if it is broadcast or multicast; see Section 3.2.1.3.
At a given moment, all the IP datagrams from a
source host to a particular destination host
typically traverse the same sequence of gateways. We
the term "path" for this sequence. Note that a path
uni-directional; it is not unusual to have different
in the two directions between a given host pair
The maximum transmission unit, i.e., the size of
largest packet that can be transmitted
The terms frame, packet, datagram, message, and segment
illustrated by the following schematic diagrams
A. Transmission on connected network
_______________________________________________
| LL hdr | IP hdr | (data) |
|________|________|_____________________________|
<---------- Frame ----------------------------->
<----------Packet -------------------->
B. Before IP fragmentation or after IP reassembly
______________________________________
| IP hdr | transport| Application Data |
|________|____hdr___|__________________|
<-------- Datagram ------------------>
<-------- Message ----------->
or, for TCP
______________________________________
| IP hdr | TCP hdr | Application Data |
|________|__________|__________________|
<-------- Datagram ------------------>
<-------- Segment ----------->
Internet Engineering Task Force [Page 19]
RFC1122 INTRODUCTION October 1989
1.4
This document incorporates contributions and comments from a
group of Internet protocol experts, including representatives
university and research labs, vendors, and government agencies
It was assembled primarily by the Host Requirements Working
of the Internet Engineering Task Force (IETF).
The Editor would especially like to acknowledge the
dedication of the following people, who attended many
meetings and generated 3 million bytes of electronic mail over
past 18 months in pursuit of this document: Philip Almquist,
Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC),
Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig
(BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
In addition, the following people made major contributions to
effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike
(BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA),
Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff
(DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (
Technology), and Mike StJohns (DCA). The following also
significant contributions to particular areas: Eric
(Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith
(Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt
(IBM), Erik Naggum (Naggum Software, Norway), Robert
(Prime Computer), David Waitzman (BBN), Frank Wancho (USA),
Welch (Ohio State), Bill Westfield (Cisco), and Rayan
(Toronto).
We are grateful to all, including any contributors who may
been inadvertently omitted from this list
Internet Engineering Task Force [Page 20]
RFC1122 LINK LAYER October 1989
2. LINK
2.1
All Internet systems, both hosts and gateways, have the
requirements for link layer protocols. These requirements
given in Chapter 3 of "Requirements for Internet Gateways
[INTRO:2], augmented with the material in this section
2.2 PROTOCOL WALK-
None
2.3 SPECIFIC
2.3.1 Trailer Protocol
The trailer protocol [LINK:1] for link-layer encapsulation
be used, but only when it has been verified that both
(host or gateway) involved in the link-layer
implement trailers. If the system does not
negotiate use of the trailer protocol on a per-
basis, the default configuration MUST disable the protocol
DISCUSSION
The trailer protocol is a link-layer
technique that rearranges the data contents of
sent on the physical network. In some cases,
improve the throughput of higher layer protocols
reducing the amount of data copying within the
system. Higher layer protocols are unaware of
use, but both the sending and receiving host
understand the protocol if it is used
Improper use of trailers can result in very
symptoms. Only packets with specific size attributes
encapsulated using trailers, and typically only a
fraction of the packets being exchanged have
attributes. Thus, if a system using trailers
packets with a system that does not, some
disappear into a black hole while others are
successfully
IMPLEMENTATION
On an Ethernet, packets encapsulated with trailers use
distinct Ethernet type [LINK:1], and trailer
is performed at the time that ARP is used to discover
link-layer address of a destination system
Internet Engineering Task Force [Page 21]
RFC1122 LINK LAYER October 1989
Specifically, the ARP exchange is completed in the
manner using the normal IP protocol type, but a host
wants to speak trailers will send an additional "
ARP reply" packet, i.e., an ARP reply that specifies
trailer encapsulation protocol type but otherwise has
format of a normal ARP reply. If a host configured to
trailers receives a trailer ARP reply message from
remote machine, it can add that machine to the list
machines that understand trailers, e.g., by marking
corresponding entry in the ARP cache
Hosts wishing to receive trailer encapsulations
trailer ARP replies whenever they complete exchanges
normal ARP messages for IP. Thus, a host that received
ARP request for its IP protocol address would send
trailer ARP reply in addition to the normal IP ARP reply
a host that sent the IP ARP request would send a
ARP reply when it received the corresponding IP ARP reply
In this way, either the requesting or responding host
an IP ARP exchange may request that it receive
encapsulations
This scheme, using extra trailer ARP reply packets
than sending an ARP request for the trailer protocol type
was designed to avoid a continuous exchange of ARP
with a misbehaving host that, contrary to
specification or common sense, responded to an ARP
for trailers with another ARP reply for IP. This
is avoided by sending a trailer ARP reply in response
an IP ARP reply only when the IP ARP reply answers
outstanding request; this is true when the
address for the host is still unknown when the IP
reply is received. A trailer ARP reply may always be
along with an IP ARP reply responding to an IP
request
2.3.2 Address Resolution Protocol --
2.3.2.1 ARP Cache
An implementation of the Address Resolution Protocol (ARP
[LINK:2] MUST provide a mechanism to flush out-of-date
entries. If this mechanism involves a timeout, it SHOULD
possible to configure the timeout value
A mechanism to prevent ARP flooding (repeatedly sending
ARP Request for the same IP address, at a high rate) MUST
included. The recommended maximum rate is 1 per second
Internet Engineering Task Force [Page 22]
RFC1122 LINK LAYER October 1989
destination
DISCUSSION
The ARP specification [LINK:2] suggests but does
require a timeout mechanism to invalidate cache
when hosts change their Ethernet addresses.
prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
has significantly increased the likelihood that
entries in hosts will become invalid, and
some ARP-cache invalidation mechanism is now
for hosts. Even in the absence of proxy ARP, a long
period cache timeout is useful in order
automatically correct any bad ARP data that might
been cached
IMPLEMENTATION
Four mechanisms have been used, sometimes
combination, to flush out-of-date cache entries
(1) Timeout -- Periodically time out cache entries
even if they are in use. Note that this
should be restarted when the cache entry
"refreshed" (by observing the source fields
regardless of target address, of an ARP
from the system in question). For proxy
situations, the timeout needs to be on the
of a minute
(2) Unicast Poll -- Actively poll the remote host
periodically sending a point-to-point ARP
to it, and delete the entry if no ARP Reply
received from N successive polls. Again,
timeout should be on the order of a minute,
typically N is 2.
(3) Link-Layer Advice -- If the link-layer
detects a delivery problem, flush
corresponding ARP cache entry
(4) Higher-layer Advice -- Provide a call from
Internet layer to the link layer to indicate
delivery problem. The effect of this call
be to invalidate the corresponding cache entry
This call would be analogous to
"ADVISE_DELIVPROB()" call from the transport
to the Internet layer (see Section 3.4), and
fact the ADVISE_DELIVPROB routine might in
call the link-layer advice routine to
Internet Engineering Task Force [Page 23]
RFC1122 LINK LAYER October 1989
the ARP cache entry
Approaches (1) and (2) involve ARP cache timeouts
the order of a minute or less. In the absence of
ARP, a timeout this short could create
overhead traffic on a very large Ethernet. Therefore
it may be necessary to configure a host to lengthen
ARP cache timeout
2.3.2.2 ARP Packet
The link layer SHOULD save (rather than discard) at
one (the latest) packet of each set of packets destined
the same unresolved IP address, and transmit the
packet when the address has been resolved
DISCUSSION
Failure to follow this recommendation causes the
packet of every exchange to be lost. Although higher
layer protocols can generally cope with packet loss
retransmission, packet loss does impact performance
For example, loss of a TCP open request causes
initial round-trip time estimate to be inflated. UDP
based applications such as the Domain Name System
more seriously affected
2.3.3 Ethernet and IEEE 802
The IP encapsulation for Ethernets is described in RFC-894
[LINK:3], while RFC-1042 [LINK:4] describes the
encapsulation for IEEE 802 networks. RFC-1042 elaborates
replaces the discussion in Section 3.4 of [INTRO:2].
Every Internet host connected to a 10Mbps Ethernet cable
o MUST be able to send and receive packets using RFC-894
encapsulation
o SHOULD be able to receive RFC-1042 packets,
with RFC-894 packets;
o MAY be able to send packets using RFC-1042 encapsulation
An Internet host that implements sending both the RFC-894
the RFC-1042 encapsulations MUST provide a configuration
to select which is sent, and this switch MUST default to RFC
894.
Internet Engineering Task Force [Page 24]
RFC1122 LINK LAYER October 1989
Note that the standard IP encapsulation in RFC-1042 does
use the protocol id value (K1=6) that IEEE reserved for IP
instead, it uses a value (K1=170) that implies an
(the "SNAP") which can be used to hold the Ether-Type field
An Internet system MUST NOT send 802 packets using K1=6.
Address translation from Internet addresses to link-
addresses on Ethernet and IEEE 802 networks MUST be managed
the Address Resolution Protocol (ARP).
The MTU for an Ethernet is 1500 and for 802.3 is 1492.
DISCUSSION
The IEEE 802.3 specification provides for operation over
10Mbps Ethernet cable, in which case Ethernet and
802.3 frames can be physically intermixed. A receiver
distinguish Ethernet and 802.3 frames by the value of
802.3 Length field; this two-octet field coincides in
header with the Ether-Type field of an Ethernet frame.
particular, the 802.3 Length field must be less than
equal to 1500, while all valid Ether-Type values
greater than 1500.
Another compatibility problem arises with link-
broadcasts. A broadcast sent with one framing will not
seen by hosts that can receive only the other framing
The provisions of this section were designed to
direct interoperation between 894-capable and 1042-
systems on the same cable, to the maximum extent possible
It is intended to support the present situation
894-only systems predominate, while providing an
transition to a possible future in which 1042-
systems become common
Note that 894-only systems cannot interoperate
with 1042-only systems. If the two system types are
up as two different logical networks on the same cable
they can communicate only through an IP gateway
Furthermore, it is not useful or even possible for
dual-format host to discover automatically which format
send, because of the problem of link-layer broadcasts
2.4 LINK/INTERNET LAYER
The packet receive interface between the IP layer and the
layer MUST include a flag to indicate whether the incoming
was addressed to a link-layer broadcast address
Internet Engineering Task Force [Page 25]
RFC1122 LINK LAYER October 1989
Although the IP layer does not generally know link
addresses (since every different network medium typically
a different address format), the broadcast address on
broadcast-capable medium is an important special case.
Section 3.2.2, especially the DISCUSSION concerning
storms
The packet send interface between the IP and link layers
include the 5-bit TOS field (see Section 3.2.1.6).
The link layer MUST NOT report a Destination Unreachable error
IP solely because there is no ARP cache entry for a destination
2.5 LINK LAYER REQUIREMENTS
| | | | |S| |
| | | | |H| |
| | | | |O|M|
| | |S| |U|U|
| | |H| |L|S|
| |M|O| |D|T|
| |U|U|M| | |
| |S|L|A|N|N|
| |T|D|Y|O|O|
FEATURE |SECTION| | | |T|T|
--------------------------------------------------|-------|-|-|-|-|-|--
| | | | | | |
Trailer encapsulation |2.3.1 | | |x| | |
Send Trailers by default without negotiation |2.3.1 | | | | |x
ARP |2.3.2 | | | | | |
Flush out-of-date ARP cache entries |2.3.2.1|x| | | | |
Prevent ARP floods |2.3.2.1|x| | | | |
Cache timeout configurable |2.3.2.1| |x| | | |
Save at least one (latest) unresolved pkt |2.3.2.2| |x| | | |
Ethernet and IEEE 802 Encapsulation |2.3.3 | | | | | |
Host able to: |2.3.3 | | | | | |
Send & receive RFC-894 encapsulation |2.3.3 |x| | | | |
Receive RFC-1042 encapsulation |2.3.3 | |x| | | |
Send RFC-1042 encapsulation |2.3.3 | | |x| | |
Then config. sw. to select, RFC-894 dflt |2.3.3 |x| | | | |
Send K1=6 encapsulation |2.3.3 | | | | |x
Use ARP on Ethernet and IEEE 802 nets 