rfc760.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 2,014 行 · 第 1/5 页
TXT
2,014 行
RFC: 760
IEN: 128
DOD STANDARD
INTERNET PROTOCOL
January 1980
prepared for
Defense Advanced Research Projects Agency
Information Processing Techniques Office
1400 Wilson Boulevard
Arlington, Virginia 22209
by
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
January 1980
Internet Protocol
TABLE OF CONTENTS
PREFACE ........................................................ iii
1. INTRODUCTION ..................................................... 1
1.1 Motivation .................................................... 1
1.2 Scope ......................................................... 1
1.3 Interfaces .................................................... 1
1.4 Operation ..................................................... 2
2. OVERVIEW ......................................................... 5
2.1 Relation to Other Protocols ................................... 5
2.2 Model of Operation ............................................ 5
2.3 Function Description .......................................... 7
3. SPECIFICATION ................................................... 11
3.1 Internet Header Format ....................................... 11
3.2 Discussion ................................................... 21
3.3 Examples & Scenarios ......................................... 30
3.4 Interfaces ................................................... 34
GLOSSARY ............................................................ 37
REFERENCES .......................................................... 41
[Page i]
January 1980
Internet Protocol
[Page ii]
January 1980
Internet Protocol
PREFACE
This document specifies the DoD Standard Internet Protocol. This
document is based on five earlier editions of the ARPA Internet Protocol
Specification, and the present text draws heavily from them. There have
been many contributors to this work both in terms of concepts and in
terms of text. This edition revises the details security,
compartmentation, and precedence features of the internet protocol.
Jon Postel
Editor
[Page iii]
January 1980
RFC: 760
IEN: 128
Replaces: IENs 123, 111,
80, 54, 44, 41, 28, 26
DOD STANDARD
INTERNET PROTOCOL
1. INTRODUCTION
1.1. Motivation
The Internet Protocol is designed for use in interconnected systems of
packet-switched computer communication networks. Such a system has
been called a "catenet" [1]. The internet protocol provides for
transmitting blocks of data called datagrams from sources to
destinations, where sources and destinations are hosts identified by
fixed length addresses. The internet protocol also provides for
fragmentation and reassembly of long datagrams, if necessary, for
transmission through "small packet" networks.
1.2. Scope
The internet protocol is specifically limited in scope to provide the
functions necessary to deliver a package of bits (an internet
datagram) from a source to a destination over an interconnected system
of networks. There are no mechanisms to promote data reliability,
flow control, sequencing, or other services commonly found in
host-to-host protocols.
1.3. Interfaces
This protocol is called on by host-to-host protocols in an internet
environment. This protocol calls on local network protocols to carry
the internet datagram to the next gateway or destination host.
For example, a TCP module would call on the internet module to take a
TCP segment (including the TCP header and user data) as the data
portion of an internet datagram. The TCP module would provide the
addresses and other parameters in the internet header to the internet
module as arguments of the call. The internet module would then
create an internet datagram and call on the local network interface to
transmit the internet datagram.
In the ARPANET case, for example, the internet module would call on a
local net module which would add the 1822 leader [2] to the internet
datagram creating an ARPANET message to transmit to the IMP. The
ARPANET address would be derived from the internet address by the
local network interface and would be the address of some host in the
ARPANET, that host might be a gateway to other networks.
[Page 1]
January 1980
Internet Protocol
Introduction
1.4. Operation
The internet protocol implements two basic functions: addressing and
fragmentation.
The internet modules use the addresses carried in the internet header
to transmit internet datagrams toward their destinations. The
selection of a path for transmission is called routing.
The internet modules use fields in the internet header to fragment and
reassemble internet datagrams when necessary for transmission through
"small packet" networks.
The model of operation is that an internet module resides in each host
engaged in internet communication and in each gateway that
interconnects networks. These modules share common rules for
interpreting address fields and for fragmenting and assembling
internet datagrams. In addition, these modules (especially in
gateways) may have procedures for making routing decisions and other
functions.
The internet protocol treats each internet datagram as an independent
entity unrelated to any other internet datagram. There are no
connections or logical circuits (virtual or otherwise).
The internet protocol uses four key mechanisms in providing its
service: Type of Service, Time to Live, Options, and Header Checksum.
The Type of Service is used to indicate the quality of the service
desired; this may be thought of as selecting among Interactive, Bulk,
or Real Time, for example. The type of service is an abstract or
generalized set of parameters which characterize the service choices
provided in the networks that make up the internet. This type of
service indication is to be used by gateways to select the actual
transmission parameters for a particular network, the network to be
used for the next hop, or the next gateway when routing an internet
datagram.
The Time to Live is an indication of the lifetime of an internet
datagram. It is set by the sender of the datagram and reduced at the
points along the route where it is processed. If the time to live
reaches zero before the internet datagram reaches its destination, the
internet datagram is destroyed. The time to live can be thought of as
a self destruct time limit.
The Options provide for control functions needed or useful in some
situations but unnecessary for the most common communications. The
[Page 2]
January 1980
Internet Protocol
Introduction
options include provisions for timestamps, error reports, and special
routing.
The Header Checksum provides a verification that the information used
in processing internet datagram has been transmitted correctly. The
data may contain errors. If the header checksum fails, the internet
datagram is discarded at once by the entity which detects the error.
The internet protocol does not provide a reliable communication
facility. There are no acknowledgments either end-to-end or
hop-by-hop. There is no error control for data, only a header
checksum. There are no retransmissions. There is no flow control.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?