📄 rfc827.txt
字号:
receipt of a poll. Failure to respond in a timely manner to an
NR poll may result in the polling gateway's deciding that the
polled gateway is not an appropriate first hop to any network.
NR messages sent in response to polls carry the
identification number of the poll message in their
"identification number" fields. Unsolicited NR messages carry
the identification number of the last poll received, and have the
"unsolicited" bit set. (Note that this allows for only a single
unsolicited NR message per polling period.)
To facilitate the sending of unsolicited NR messages, the NR
poll message has a byte indicating the polling interval in
minutes.
- 25 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
Polls from non-neighbors, from neighbors which are not
declared reachable, or with bad IP source network fields, should
be responded to with an EGP error message with the appropriate
"reason" field. If G sends an NR poll to G' with IP source
network N, and G' is not a neighbor of G on its interface to
network N (or G' does not have an interface to network N), then
the source network field is considered "bad".
Duplicated polls (successive polls with the same
identification number) should be responded to with duplicates of
the same NR message. If that message is fragmented, the same
fragments shall be sent each time. Note that there is no
provision for handling multiple outstanding polls from a single
neighbor. NOTE THAT IF THE SAME FRAGMENTS ARE NOT SENT IN
RESPONSE TO DUPLICATED POLLS, INCORRECT REASSEMBLY WILL BE THE
PROBABLE RESULT. If fragmentation is not being used, however,
then no harm should result from responding to a duplicate poll
with a different (presumably more recent) NR message.
- 26 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
7 INDIRECT NEIGHBORS
Becoming a "direct neighbor" of an exterior gateway requires
three steps: (a) neighbor acquisition, (b) running a neighbor
reachability protocol, and (c) polling the neighbor periodically
for NR messages. Suppose, however, that gateway G receives an NR
message from G', in which G' indicates the presence of other
neighbors G1, ..., Gn, each of which is an appropriate first hop
for some set of networks to which G' itself is not an appropriate
first hop. Then G should be allowed to forward traffic for those
networks directly to the appropriate one of G1, ..., Gn, without
having to send it to G' first. In this case, G may be considered
an INDIRECT NEIGHBOR of G1, ..., Gn, since it is a neighbor of
these other gateways for the purpose of forwarding traffic, but
does not perform neighbor acquisition, neighbor reachability, or
exchange of NR messages with them. Neighbor and network
reachability information is obtained indirectly via G', hence the
designation "indirect neighbor". We say that G is an indirect
neighbor of G1, ..., Gn VIA G'.
If G is an indirect neighbor of G' via G'', and then G
receives an NR message from G'' which does not mention G', G
should treat G' as having become unreachable.
- 27 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
8 HOW TO BE A STUB GATEWAY
The most common application of EGP will probably be its use
to enable a stub gateway to communicate with one of the DARPA
core gateways, so as to enable data flow between networks
accessible only via the stub and networks accessible only via the
system of core gateways. As discussed previously, a stub gateway
can be considered to be a one-gateway internet system with no
interior neighbors. It is probably used to interface a local
network or networks to a long range transport network (such as
ARPANET or SATNET) on which there is a core gateway. In this
case, the stub will not want the core gateways to forward it any
traffic other than traffic which is destined for the network or
networks which can be reached only via the stub. In general, the
stub will not want to perform any services for the internet
transport system which are not needed in order to be able to pass
traffic to and from the networks that cannot be otherwise
reached.
The stub should have tables configured in with the addresses
of a small number of the core gateways (no more than two or
three) with which it has a common network. It will be the
responsibility of the stub to initiate neighbor acquisition with
these gateways. When a stub and a core gateway become direct
neighbors, the core gateway will begin sending Hello messages.
- 28 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
When the stub declares the core gateways which are direct
neighbors to be reachable, it should poll those gateways for NR
messages at a rate not to exceed once per minute (or as specified
in the Hello messages from the core gateways). The core gateways
will also poll the stub for NR messages.
The NR message sent by the stub should be the simplest
allowable. That is, it should have only a single data block,
headed by its own address (on the network it has in common with
the neighboring core gateway), listing just the networks to which
it is an appropriate first hop. These will be just the networks
that can be reached no other way, in general.
The core gateways will send complete NR messages, containing
information about all other gateways on the common networks, both
core gateways (which shall be listed as interior neighbors) and
other gateways (which shall be listed as exterior neighbors, and
may include the stub itself). This information will enable the
stub to become an indirect neighbor of all these other gateways.
That is, the stub shall forward traffic directly to these other
gateways as appropriate, but shall not become direct neighbors
with them.
The core gateways will report distances less than 128 if the
network can be reached without leaving the core system (i.e.,
- 29 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
without traversing any gateway other than a core gateway), and
greater than or equal to 128 otherwise.
The stub should NEVER forward to any (directly or
indirectly) neighboring core gateway any traffic for which that
gateway is not an appropriate first hop, as indicated in an NR
message. Of course, this does not apply to datagrams which are
using the source route option; any such datagrams should always
be forwarded as indicated in the source route option field, even
if that requires forwarding to a gateway which is not an
appropriate first hop.
If the direct neighbors of a stub should all fail, it will
be the responsibility of the stub to acquire at least one new
direct neighbor. It can do so by choosing one of the core
gateways which it has had as an indirect neighbor, and executing
the neighbor acquisition protocol with it. (It is possible that
no more than one core gateway will ever agree to become a direct
neighbor with any given stub gateway at any one time.)
If the stub gateway does not respond in a timely manner to
Hello messages from the core gateway, it may be declared
unreachable. If it does not respond to NR poll messages in a
timely manner, its networks may be declared unreachable. In both
these cases, the core gateways may discard traffic destined for
- 30 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
those networks, returning ICMP "destination network unreachable"
to the source hosts.
The stub gateway is expected to fully execute the ICMP
protocol, as well as the EGP protocol. In particular, it must
respond to ICMP echo requests, and must send ICMP destination
dead messages as appropriate. It is also required to send ICMP
Redirect messages as appropriate.
- 31 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
9 LIMITATIONS
It must be clearly understood that the Exterior Gateway
Protocol does not in itself constitute a network routing
algorithm. In addition, it does not provide all the information
needed to implement a general area routing algorithm. If the
topology of the set of autonomous systems is not tree-structured
(i.e., if it has cycles), the Exterior Gateway Protocol does not
provide enough topological information to prevent loops.
If any gateway sends an NR message with false information,
claiming to be an appropriate first hop to a network which it in
fact cannot even reach, traffic destined to that network may
never be delivered. Implementers must bear this in mind.
- 32 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
NEIGHBOR ACQUISITION MESSAGE
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! EGP Version # ! Type ! Code ! Info !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Checksum ! Autonomous System # !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Identification # !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description:
The Neighbor Acquisition messages are used by interior and
exterior gateways to become neighbors of each other.
EGP Version #
1
Type
3
Code
Code = 0 Neighbor Acquisition Request
Code = 1 Neighbor Acquisition Reply
Code = 2 Neighbor Acquisition Refusal (see Info field)
Code = 3 Neighbor Cease Message (see Info field)
Code = 4 Neighbor Cease Acknowledgment
Checksum
The EGP checksum is the 16-bit one's complement of the one's
complement sum of the EGP message starting with the EGP
version number field. For computing the checksum, the
checksum field should be zero.
Autonomous System #
This 16-bit number identifies the autonomous system
containing the gateway which is the source of this message.
- 33 -
RFC 827 Bolt Beranek and Newman Inc.
Eric C. Rosen
Info
For Refusal message, gives reason for refusal:
0 Unspecified
1 Out of table space
2 Administrative prohibition
For Cease message, gives reason for ceasing to be neighbor:
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -