rfc823.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 2,611 行 · 第 1/5 页
TXT
2,611 行
Request for Comments: 823
Obsoletes IEN-30 and IEN-109
THE DARPA INTERNET GATEWAY
RFC 823
Robert Hinden
Alan Sheltzer
Bolt Beranek and Newman Inc.
10 Moulton St.
Cambridge, Massachusetts 02238
September 1982
Prepared for
Defense Advanced Research Projects Agency
Information Processing Techniques Office
1400 Wilson Boulevard
Arlington, Virginia 22209
This RFC is a status report on the Internet Gateway developed by BBN. It
describes the Internet Gateway as of September 1982. This memo presents
detailed descriptions of message formats and gateway procedures, however
this is not an implementation specification, and such details are
subject to change.
DARPA Internet Gateway September 1982
RFC 823
Table of Contents
1 INTRODUCTION.......................................... 1
2 BACKGROUND............................................ 2
3 FORWARDING INTERNET DATAGRAMS......................... 5
3.1 Input............................................... 5
3.2 IP Header Checks.................................... 6
3.3 Routing............................................. 7
3.4 Redirects........................................... 9
3.5 Fragmentation....................................... 9
3.6 Header Rebuild..................................... 10
3.7 Output............................................. 10
4 PROTOCOLS SUPPORTED BY THE GATEWAY................... 12
4.1 Cross-Net Debugging Protocol....................... 12
4.2 Host Monitoring Protocol........................... 12
4.3 ICMP............................................... 14
4.4 Gateway-to-Gateway Protocol........................ 14
4.4.1 Determining Connectivity to Networks............. 14
4.4.2 Determining Connectivity to Neighbors............ 16
4.4.3 Exchanging Routing Information................... 17
4.4.4 Computing Routes................................. 19
4.4.5 Non-Routing Gateways............................. 22
4.4.6 Adding New Neighbors and Networks................ 23
4.5 Exterior Gateway Protocol.......................... 24
5 GATEWAY SOFTWARE..................................... 26
5.1 Software Structure................................. 26
5.1.1 Device Drivers................................... 27
5.1.2 Network Software................................. 27
5.1.3 Shared Gateway Software.......................... 29
5.2 Gateway Processes.................................. 29
5.2.1 Network Processes................................ 29
5.2.2 GGP Process...................................... 30
5.2.3 HMP Process...................................... 31
APPENDIX A. GGP Message Formats.......................... 32
APPENDIX B. Information Maintained by Gateways........... 39
APPENDIX C. GGP Events and Responses..................... 41
REFERENCES............................................... 43
-i-
DARPA Internet Gateway September 1982
RFC 823
1 INTRODUCTION
This document explains the design of the Internet gateway
used in the Defense Advanced Research Project Agency (DARPA)
Internet program. The gateway design was originally documented
in IEN-30, "Gateway Routing: An Implementation Specification"
[2], and was later updated in IEN-109, "How to Build a Gateway"
[3]. This document reflects changes made both in the internet
protocols and in the gateway design since these documents were
released. It supersedes both IEN-30 and IEN-109.
The Internet gateway described in this document is based on
the work of many people; in particular, special credit is given
to V. Strazisar, M. Brescia, E. Rosen, and J. Haverty.
The gateway's primary purpose is to route internet datagrams
to their destination networks. These datagrams are generated and
processed as described in RFC 791, "Internet Protocol - DARPA
Internet Program Protocol Specification" [1]. This document
describes how the gateway forwards datagrams, the routing
algorithm and protocol used to route them, and the software
structure of the current gateway. The current gateway
implementation is written in macro-11 assembly language and runs
in the DEC PDP-11 or LSI-11 16-bit processor.
-1-
DARPA Internet Gateway September 1982
RFC 823
2 BACKGROUND
The gateway system has undergone a series of changes since
its inception, and it is continuing to evolve as research
proceeds in the Internet community. This document describes the
implementation as of mid-1982.
Early versions of gateway software were implemented using
the BCPL language and the ELF operating system. This
implementation evolved into one which used the MOS operating
system for increased performance. In late 1981, we began an
effort to produce a totally new gateway implementation. The
primary motivation for this was the need for a system oriented
towards the requirements of an operational communications
facility, rather than the research testbed environment which was
associated with the BCPL implementation. In addition, it was
generally recognized that the complexity and buffering
requirements of future gateway configurations were beyond the
capabilities of the PDP-11/LSI-11 and BCPL architecture. The new
gateway implementation therefore had a second goal of producing a
highly space-efficient implementation in order to provide space
for buffers and for the extra mechanisms, such as monitoring,
which are needed for an operational environment.
-2-
DARPA Internet Gateway September 1982
RFC 823
This document describes the implementation of this new
gateway which incorporates several mechanisms for operations
activities, is coded in assembly language for maximum space-
efficiency, but otherwise is fundamentally the same architecture
as the older, research-oriented, implementations.
One of the results of recent research is the thesis that
gateways should be viewed as elements of a gateway system, where
the gateways act as a loosely-coupled packet-switching
communications system. For reasons of maintainability and
operability, it is easiest to build such a system in an
homogeneous fashion where all gateways are under a single
authority and control, as is the practice in other network
implementations.
In order to create a system architecture that permitted
multiple sets of gateways with each set under single control but
acting together to implement a composite single Internet System,
new protocols needed to be developed. These protocols, such as
the "Exterior Gateway Protocol," will be introduced in the later
releases of the gateway implementation.
We also anticipate further changes to the gateway
architecture and implementation to introduce support for new
-3-
DARPA Internet Gateway September 1982
RFC 823
capabilities, such as large numbers of networks, access control,
and other requirements which have been proposed by the Internet
research community. This document represents a snapshot of the
current implementation, rather than a specification.
-4-
DARPA Internet Gateway September 1982
RFC 823
3 FORWARDING INTERNET DATAGRAMS
This section describes how the gateway forwards datagrams
between networks. A host computer that wants an IP datagram to
reach a host on another network must send the datagram to a
gateway to be forwarded. Before it is sent into the network, the
host attaches to the datagram a local network header containing
the address of the gateway.
3.1 Input
When a gateway receives a message, the gateway checks the
message's local network header for possible errors and performs
any actions required by the host-to-network protocol. This
processing involves functions such as verifying the local network
header checksum or generating a local network acknowledgment
message. If the header indicates that the message contains an
Internet datagram, the datagram is passed to the Internet header
check routine. All other messages received that do not pass
these tests are discarded.
-5-
DARPA Internet Gateway September 1982
RFC 823
3.2 IP Header Checks
The Internet header check routine performs a number of
validity tests on the IP header. Datagrams that fail these tests
are discarded causing an HMP trap to be sent to the Internet
Network Operations Center (INOC) [7]. The following checks are
currently performed:
o Proper IP Version Number
o Valid IP Header Length ( >= 20 bytes)
o Valid IP Message Length
o Valid IP Header Checksum
o Non-Zero Time to Live field
After a datagram passes these checks, its Internet destination
address is examined to determine if the datagram is addressed to
the gateway. Each of the gateway's internet addresses (one for
each network interface) is checked against the destination
address in the datagram. If a match is not found, the datagram
is passed to the forwarding routine.
If the datagram is addressed to the gateway itself, the IP
options in the IP header are processed. Currently, the gateway
supports the following IP options:
-6-
DARPA Internet Gateway September 1982
RFC 823
o NOP
o End of Option List
o Loose Source and Record Route
o Strict Source and Record Route
The datagram is next processed according to the protocol in the
IP header. If the protocol is not supported by the gateway, it
replies with an ICMP error message and discards the datagram.
The gateway does not support IP reassembly, so fragmented
datagrams which are addressed to the gateway are discarded.
3.3 Routing
The gateway must make a routing decision for all datagrams
that are to be to forwarded. The routing algorithm provides two
pieces of information for the gateway: 1) the network interface
that should be used to send this datagram and 2) the destination
address that should be put in the local network header of the
datagram.
The gateway maintains a dynamic Routing Table which contains
an entry for each reachable network. The entry consists of a
network number and the address of the neighbor gateway on the
shortest route to the network, or else an indication that the
-7-
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?