分享
 
 
 

RFC827 - Exterior Gateway Protocol (EGP)

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

EXTERIOR GATEWAY PROTOCOL (EGP)

Eric C. Rosen

Bolt Beranek and Newman Inc.

October 1982

It is proposed to establish a standard for Gateway to Gateway procedures

that allow the Gateways to be mutually suspicious. This document is a

DRAFT for that standard. Your comments are strongly encouraged.

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

Table of Contents

1 INTRODUCTION.......................................... 1

2 NEIGHBOR ACQUISITION.................................. 8

3 NEIGHBOR REACHABILITY PROTOCOL....................... 11

4 NETWORK REACHABILITY (NR) MESSAGE.................... 15

5 POLLING FOR NR MESSAGES.............................. 22

6 SENDING NR MESSAGES.................................. 25

7 INDIRECT NEIGHBORS................................... 27

8 HOW TO BE A STUB GATEWAY............................. 28

9 LIMITATIONS.......................................... 32

- i -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

1 INTRODUCTION

The DARPA Catenet is eXPected to be a continuously expanding

system, with more and more hosts on more and more networks

participating in it. Of course, this will require more and more

gateways. In the past, such expansion has taken place in a

relatively unstructured manner. New gateways, often containing

radically different software than the existing gateways, would be

added and would immediately begin participating in the common

routing algorithm via the GGP protocol. However, as the internet

grows larger and larger, this simple method of expansion becomes

less and less feasible. There are a number of reasons for this:

- the overhead of the routing algorithm becomes excessively

large;

- the proliferation of radically different gateways

participating in a single common routing algorithm makes

maintenance and fault isolation nearly impossible, since

it becomes impossible to regard the internet as an

integrated communications system;

- the gateway software and algorithms, especially the

routing algorithm, become too rigid and inflexible, since

any proposed change must be made in too many different

places and by too many different people.

- 1 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

In the future, the internet is expected to evolve into a set

of separate domains or "autonomous systems", each of which

consists of a set of one or more relatively homogeneous gateways.

The protocols, and in particular the routing algorithm which

these gateways use among themselves, will be a private matter,

and need never be implemented in gateways outside the particular

domain or system.

In the simplest case, an autonomous system might consist of

just a single gateway connecting, for example, a local network to

the ARPANET. Such a gateway might be called a "stub gateway",

since its only purpose is to interface the local network to the

rest of the internet, and it is not intended to be used for

handling any traffic which neither originated in nor is destined

for that particular local network. In the near-term future, we

will begin to think of the internet as a set of autonomous

systems, one of which consists of the DARPA gateways on ARPANET

and SATNET, and the others of which are stub gateways to local

networks. The former system, which we shall call the "core"

system, will be used as a transport or "long-haul" system by the

latter systems.

Ultimately, however, the internet may consist of a number of

co-equal autonomous systems, any of which may be used (with

certain restrictions which will be discussed later) as a

- 2 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

transport medium for traffic originating in any system and

destined for any system. When this more complex configuration

comes into being, it will be inappropriate to regard any one

autonomous system as a "core" system. For the sake of

concreteness, however, and because the initial implementations of

the Exterior Gateway Protocol are expected to focus on the the

case of connecting "stub gateways" to the DARPA gateways on

ARPANET and SATNET, we will often use the term "core" gateways in

our examples and discussion.

The purpose of the Exterior Gateway Protocol (EGP) is to

enable one or more autonomous systems to be used as transport

media for traffic originating in some other autonomous system and

destined for yet another, while allowing the end-user to see the

composite of all the autonomous systems as a single internet,

with a flat, uniform address space. The route which a datagram

takes through the internet, and the number of autonomous systems

which it traverses, are to be transparent to the end-user

(unless, of course, the end-user makes use of the IP "source

route" option).

In describing the Exterior Gateway Protocol, we have

deliberately left a great deal of latitude to the designers and

implementers of particular autonomous systems, particularly with

regard to timer values. We have done this because we expect that

- 3 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

different gateway implementations and different internet

environments may just have different requirements and goals, so

that no single strict implementation specification could apply to

all. However, this does NOT mean that ANY implementation which

conforms to the specification will work well, or that the areas

in which we have left latitude are not crucial to performance.

The fact that some time-out value, for example, is not specified

here does not mean that everything will work no matter what value

is assigned.

Autonomous systems will be assigned 16-bit identification

numbers (in much the same ways as network and protocol numbers

are now assigned), and every EGP message header contains one Word

for this number. Zero will not be assigned to any autonomous

system; rather, the presence of a zero in this field will

indicate that no number is present.

We need to introduce the concept of one gateway being a

NEIGHBOR of another. In the simplest and most common case, we

call two gateways "neighbors" if there is a network to which each

has an interface. However, we will need a somewhat more general

notion of "neighbor" to allow the following two cases:

a) Two gateways may be regarded as neighbors if they are

directly connected not by a network (in the usual sense

- 4 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

of the term), but by a simple wire, or HDLC line, or some

similar means of "direct connection".

b) Two gateways may be regarded as neighbors if they are

connected by an "internet" which is transparent to them.

That is, we would like to be able to say that two

gateways are neighbors even if they are connected by an

internet, as long as the gateways utilize no knowledge of

the internal structure of that internet in their own

packet-forwarding algorithms.

In order to handle all these cases, let us say that two gateways

are NEIGHBORS if they are connected by some communications medium

whose internal structure is transparent to them. (See IEN 184

for a more general discussion of this notion of neighbor.)

If two neighbors are part of the same autonomous system, we

call them INTERIOR NEIGHBORS; if two neighbors are not part of

the same autonomous system, we call them EXTERIOR NEIGHBORS. In

order for one system to use another as a transport medium,

gateways which are exterior neighbors of each other must be able

to find out which networks can be reached through the other. The

Exterior Gateway Protocol enables this information to be passed

between exterior neighbors. Since it is a polling protocol, it

also enables each gateway to control the rate at which it sends

- 5 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

and receives network reachability information, allowing each

system to control its own overhead. It also enables each system

to have an independent routing algorithm whose operation cannot

be disrupted by failures of other systems.

It must be clearly understood that any autonomous system in

which routing needs to be performed among gateways within that

system must implement its own routing algorithm. (A routing

algorithm is not generally necessary for a simple autonomous

system which consists of a single stub gateway.) The Exterior

Gateway Protocol is NOT a routing algorithm. It enables exterior

neighbors to exchange information which is likely to be needed by

any routing algorithm, but it does NOT specify what the gateways

are to do with this information. The "routing updates" of some

autonomous system's interior routing algorithm may or may not be

similar in format to the messages of the exterior gateway

protocol. The gateways in the DARPA "core" system will initially

use the GGP protocol (the old Gateway-Gateway protocol) as their

routing algorithm, but this will be subject to change. Gateways

in other autonomous systems may use their own Interior Gateway

Protocols (IGPs), which may or may not be similar to the IGP of

any other autonomous system. They may, of course, use GGP, but

will not be permitted to exchange GGP messages with gateways in

other autonomous systems.

- 6 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

It must also be clearly understood that the Exterior Gateway

Protocol is NOT intended to provide information which could be

used as input to a completely general area or hierarchical

routing algorithm. It is intended for a set of autonomous

systems which are connected in a tree, with no cycles. It does

not enable the passing of sufficient information to prevent

routing loops if cycles in the topology do exist.

The Exterior Gateway Protocol has three parts: (a) Neighbor

Acquisition Protocol, (b) Neighbor Reachability Protocol, and (c)

Network Reachability determination. Note that all messages

defined by EGP are intended to travel only a single "hop". That

is, they originate at one gateway and are sent to a neighboring

gateway without the mediation of any intervening gateway.

Therefore, the time-to-live field should be set to a very small

value. Gateways which encounter EGP messages in their message

streams which are not addressed to them may discard them.

- 7 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

2 NEIGHBOR ACQUISITION

Before it is possible to oBTain routing information from an

exterior gateway, it is necessary to acquire that gateway as a

direct neighbor. (The distinction between direct and indirect

neighbors will be made in a later section.) In order for two

gateways to become direct neighbors, they must be neighbors, in

the sense defined above, and they must execute the NEIGHBOR

ACQUISITION PROTOCOL, which is simply a standard three-way

handshake.

A gateway that wishes to initiate neighbor acquisition with

another sends it a Neighbor Acquisition Request. This message

should be repeatedly transmitted (at a reasonable rate, perhaps

once every 30 seconds or so) until a Neighbor Acquisition Reply

is received. The Request will contain an identification number

which is copied into the reply so that request and reply can be

matched up.

A gateway receiving a Neighbor Acquisition Request must

determine whether it wishes to become a direct neighbor of the

source of the Request. If not, it may, at its option, respond

with a Neighbor Acquisition Refusal message, optionally

specifying the reason for refusal. Otherwise, it should send a

Neighbor Acquisition Reply message. It must also send a Neighbor

- 8 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

Acquisition Request message, unless it has done so already.

Two gateways become direct neighbors when each has sent a

Neighbor Acquisition Message to, and received the corresponding

Neighbor Acquisition Reply from, the other.

Unmatched Replies or Refusals should be discarded after a

reasonable period of time. However, information about any such

unmatched messages may be useful for diagnostic purposes.

A Neighbor Acquisition Message from a gateway which is

already a direct neighbor should be responded to with a Reply and

a Neighbor Acquisition Message.

If a Neighbor Acquisition Reply is received from a

prospective neighbor, but a period of time passes during which no

Neighbor Acquisition Message is received from that prospective

neighbor, the neighbor acquisition protocol shall be deemed

incomplete. A Neighbor Cease message (see below) should then be

sent. If one gateway still desires to acquire the other as a

neighbor, the protocol must be repeated from the beginning.

If a gateway wishes to cease being a neighbor of a

particular exterior gateway, it sends a Neighbor Cease message.

A gateway receiving a Neighbor Cease message should always

respond with a Neighbor Cease Acknowledgment. It should cease to

- 9 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

treat the sender of the message as a neighbor in any way. Since

there is a significant amount of protocol run between direct

neighbors (see below), if some gateway no longer needs to be a

direct neighbor of some other, it is "polite" to indicate this

fact with a Neighbor Cease Message. The Neighbor Cease Message

should be retransmitted (up to some number of times) until an

acknowledgment for it is received.

Once a Neighbor Cease message has been received, the

Neighbor Reachability Protocol (below) should cease to be

executed.

NOTE THAT WE HAVE NOT SPECIFIED THE WAY IN WHICH ONE GATEWAY

INITIALLY DECIDES THAT IT WANTS TO BECOME A NEIGHBOR OF ANOTHER.

While this is hardly a trivial problem, it is not part of the

External Gateway Protocol.

- 10 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

3 NEIGHBOR REACHABILITY PROTOCOL

It is important for a gateway to keep real-time information

as to the reachability of its neighbors. If a gateway concludes

that a particular neighbor cannot be reached, it should cease

forwarding traffic to that gateway. To make that determination,

a NEIGHBOR REACHABILITY protocol is needed. The EGP protocol

provides two messages types for this purpose -- a "Hello" message

and an "I Heard You" message.

When a "Hello" message is received from a direct neighbor,

an "I Heard You" must be returned to that neighbor "immediately".

The delay between receiving a "Hello" and returning an "I Heard

You" should never be more than a few seconds.

At the current time, the reachability determination

algorithm is left to the designers of a particular gateway. We

have in mind algorithms like the following:

A reachable neighbor shall be declared unreachable if,

during the time in which we sent our last n "Hello"s, we received

fewer than k "I Heard You"s in return. An unreachable neighbor

shall be declared reachable if, during the time in which we sent

our last m "Hello"s, we received at least j "I Heard You"s in

return.

- 11 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

However, the frequency with which the "Hello"s are sent, and

the values of the parameters k, n, j, and m cannot be specified

here. For best results, this will depend on the characteristics

of the neighbor and of the network which the neighbors have in

common. THIS IMPLIES THAT THE PROPER PARAMETERS MAY NEED TO BE

DETERMINED JOINTLY BY THE DESIGNERS AND IMPLEMENTERS OF THE TWO

NEIGHBORING GATEWAYS; choosing algorithms and parameters in

isolation, without considering the characteristics of the

neighbor and the connecting network, would not be expected to

result in optimum reachability determinations.

The "Hello" and "I Heard You" messages have a status field

which the sending gateway uses to indicate whether it thinks the

receiving gateway is reachable or not. This information can be

useful for diagnostic purposes. It also allows one gateway to

make its reachability determination parasitic on the other: only

one gateway actually needs to send "Hello" messages, and the

other can declare it up or down based on the status field in the

"Hello". That is, the "passive" gateway (which sends only "I

Heard You"s) declares the "active" one (which sends only

"Hello"s) to be reachable when the "Hello"s from the active one

indicate that it has declared the passive one to be reachable.

Of course, this can only work if there is prior agreement as to

which neighbor is to be the active one. (Ways of coming to this

- 12 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

"prior agreement" are not part of the Exterior Gateway Protocol.)

A direct neighbor gateway should also be declared

unreachable if the network connecting it supplies lower level

protocol information from which this can be deduced. Thus, for

example, if a gateway receives an 1822 Destination Dead message

from the ARPANET which indicates that a direct neighbor is dead,

it should declare that neighbor unreachable. The neighbor should

not be declared reachable again until the requisite number of

Hello/I-Heard-You packets have been exchanged.

A direct neighbor which has become unreachable does not

thereby cease to be a direct neighbor. The neighbor can be

declared reachable again without any need to go through the

neighbor acquisition protocol again. However, if the neighbor

remains unreachable for an extremely long period of time, such as

an hour, the gateway should cease to treat it as a neighbor,

i.e., should cease sending Hello messages to it. The neighbor

acquisition protocol would then need to be repeated before it

could become a direct neighbor again.

"Hello" and "I Heard You" messages from gateway G to gateway

G' also carry the identification number of the NR poll message

(see below) which G has most recently received from G'.

- 13 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

"Hello" and "I Heard You" messages from gateway G to gateway

G' also carry the minimum interval in minutes with which G is

willing to be polled by G' for NR messages (see below).

"Hello" messages from sources other than direct neighbors

should simply be ignored. However, logging the presence of any

such messages might provide useful diagnostic information.

A gateway which is going down, or whose interface to the

network which connects it to a particular neighbor is going down,

should send a Gateway Going Down message to all direct neighbors

which will no longer be able to reach it. It should retransmit

that message (up to some number of times) until it receives a

Gateway Going Down Acknowledgment. This provides the neighbors

with an advance warning of an outage, and enables them to prepare

for it in a way which will minimize disruption to existing

traffic.

- 14 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

4 NETWORK REACHABILITY (NR) MESSAGE

Terminology: Let gateway G have an interface to network N.

We say that G is AN APPROPRIATE FIRST HOP to network M relative

to network N (where M and N are distinct networks) if and only if

the following condition holds:

Traffic which is destined for network M, and which arrives

at gateway G over its network N interface, will be forwarded

to M by G over a path which does not include any other

gateway with an interface to network N.

In short, G is an appropriate first hop for network M

relative to network N just in case there is no better gateway on

network N through which to route traffic which is destined for

network M. For optimal routing, traffic in network N which is

destined for network M ought always to be forwarded to a gateway

which is an appropriate first hop.

In order for exterior neighbors G and G' (which are

neighbors over network N) to be able to use each other as packet

switches for forwarding traffic to remote networks, each needs to

know the list of networks for which the other is an appropriate

first hop. The Exterior Gateway Protocol defines a message,

called the Network Reachability Message (or NR message), for

transferring this information.

- 15 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

Let G be a gateway on network N. Then the NR message which

G sends about network N must contain the following information:

A list of all the networks for which G is an appropriate

first hop relative to network N.

If G' can obtain this information from exterior neighbor G, then

it knows that no traffic destined for networks which are NOT in

that list should be forwarded to G. (It cannot simply conclude,

however, that all traffic for any networks in that list ought to

be forwarded via G, since G' may also have other neighbors which

are also appropriate first hops to network N. For example, G and

G'' might each be neighbors of G', but might be "equidistant"

from some network M. Then each could be an appropriate first

hop.)

For each network in the list, the NR message also contains a

byte which specifies the "distance" (according to some metric

whose definition is left to the designers of the autonomous

system of which gateway G is a member) from G to that network.

This information might (or might not) be useful in the interior

routing algorithm of gateway G', or for diagnostic purposes.

The maximum value of distance (255.) shall be taken to mean

that the network is UNREACHABLE. ALL OTHER VALUES WILL BE TAKEN

TO MEAN THAT THE NETWORK IS REACHABLE.

- 16 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

If an NR message from some gateway G fails to mention some

network N which was mentioned in the previous NR message from G,

it shall be assumed that N is still reachable from G. HOWEVER,

IF N IS NOT MENTIONED IN TWO SUCCESSIVE NR MESSAGES FROM G, THAT

SHALL BE TAKEN TO MEAN THAT N IS NO LONGER REACHABLE FROM G.

This procedure is necessary to ensure that networks which can no

longer be reached, but which are never explicitly declared

unreachable, are timed out and removed from the list of reachable

networks.

It may often be the case that where G and G' are exterior

neighbors on network N, G knows of many more gateway neighbors on

network N, and knows for which networks those other neighbors are

the appropriate first hop. Since G' may not know about all these

other neighbors, it is convenient and often more efficient for it

to be able to obtain this information from G. Therefore, the EGP

NR message also contains fields which allow G to specify the

following information:

a) A list of all neighbors (both interior and exterior) of G

(on network N) which G has reliably determined to be

reachable. Gateways should be included in this list only

if G is actively running its neighbor reachability

protocol with them.

- 17 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

b) For each of those neighbors, the list of networks for

which that neighbor is an appropriate first hop (relative

to network N).

c) For each such <neighbor, network> pair, the "distance"

from that neighbor to that network.

Thus the NR message provides a means of allowing a gateway

to "discover" new neighbors by seeing whether a neighbor that it

already knows of has any additional neighbors on the same

network. This information also makes possible the implementation

of the INDIRECT NEIGHBOR strategy defined below.

A more precise description of the NR message is the

following.

The data portion of the message will consist largely of

blocks of data. Each block will be headed by a gateway address,

which will be the address either of the gateway sending the

message or of one of that gateway's neighbors. Each gateway

address will be followed by a list of the networks for which that

gateway is an appropriate first hop, and the distance from that

gateway to each network.

Preceding the list of data blocks is:

a) The address of the network which this message is about.

- 18 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

If G and G' are neighbors on network N, then in the NR

message going from G to G', this is the address of

network N. For convenience, four bytes have been

allocated for this address -- the trailing one, two, or

three bytes should be zero.

b) The count (one byte) of the number of interior neighbors

of G for which this message contains data blocks. By

convention, this count will include the data block for G

itself, which should be the first one to appear.

c) The count (one byte) of the number of exterior neighbors

of G for which this message contains data blocks.

Then follow the data blocks themselves, first the block for

G itself, then the blocks for all the interior neighbors of G (if

any), then the blocks for the exterior neighbors. Since all

gateways mentioned are on the same network, whose address has

already been given, the gateway addresses are given with the

network address part (one, two, or three bytes) omitted, to save

space.

Each block includes a one-byte count of the number of

networks for which that gateway is the appropriate first hop. In

the list of networks, each network address is either one, two, or

three bytes, depending on whether it is a class A, class B, or

- 19 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

class C network. No trailing bytes are used.

It may sometimes be necessary to fragment the NR message.

The NR message contains a byte indicating the number of this

fragment (fragments will be numbered from zero), and a byte

containing the number of the last fragment (NOT the number of

fragments). If fragmentation is not used, these bytes must both

be zero. EACH FRAGMENT MUST BE A FULLY SELF-CONTAINED NR

MESSAGE. That is, each fragment will begin with a count of

interior and exterior neighbors, and will have some integral

number of gateway data blocks. The number of data blocks in each

fragment must correspond to the neighbor counts at the beginning

of that fragment. However, only the first fragment should begin

with a data block describing the sending gateway.

This scheme enables each fragment to be processed

independently, and requires no complex reassembly mechanisms. It

also enables processing of a message all of whose fragments have

not been received. If, after some amount of time and some number

of retransmissions of a poll, not all fragments have been

received, the fragments which are present shall be processed as

if they constituted the complete NR message. (This means that

networks mentioned only in the missing fragment will retain the

"distance" values they had in the previous NR message from that

gateway. However, if no new value for a particular network is

- 20 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

received in the next NR message from that gateway, the network

will be declared unreachable.)

- 21 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

5 POLLING FOR NR MESSAGES

No gateway is required to send NR messages to any other

gateway, except as a response to an NR Poll from a direct

neighbor. However, a gateway is required to respond to an NR

Poll from a direct neighbor within several seconds (subject to

the qualification two paragraphs hence), even if the gateway

believes that neighbor to be down.

The EGP NR Poll message is defined for this purpose. No

gateway may poll another for an NR message more often than once

per minute. A gateway receiving more than one poll per minute

may simply ignore the excess polls, or may return an error

message. The Hello and I Heard You messages which gateway G

sends to gateway G' indicate the minimum interval which G will

accept as the polling interval from G'. That is, G' will not

guarantee to respond to polls from G that arrive less than that

interval apart.

Polls must only be sent to direct neighbors which are

declared reachable by the neighbor reachability protocol.

An NR Poll message contains an identification number chosen

by the polling gateway. The polled gateway will return this

number in the NR message it sends in response to the poll, to

enable the polling gateway to match up received NR messages with

- 22 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

polls. It will be the responsibility of the polling gateway to

choose an identification number which is sufficiently "unique" to

allow detection of out-of-date NR messages which may still be

floating around the network. Since polls are relatively

infrequent, this is not expected to be much of a problem.

However, to aid in choosing an identification number, the Hello

and I Heard You messages carry the identification number of the

last NR poll received from the neighbor to which they are being

sent.

In general, a poll should be retransmitted some number of

times (with a reasonable interval between retransmissions) until

an NR message is received. IF NO NR MESSAGE IS RECEIVED AFTER

THE MAXIMUM NUMBER OF RETRANSMISSIONS, THE POLLING GATEWAY SHOULD

ASSUME THAT THE POLLED GATEWAY IS NOT AN APPROPRIATE FIRST HOP

FOR ANY NETWORK WHATSOEVER. The optimum parameters for the

polling/retransmission algorithm will be dependent on the

characteristics of the two neighbors and of the network

connecting them.

If only some fragments of an NR message are received after

the maximum number of retransmissions, the fragments that are

present shall be treated as constituting the whole of the NR

message.

- 23 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

Received NR messages whose identification numbers do not

match the identification number of the most recently sent poll

shall be ignored. There is no provision for multiple outstanding

polls to the same neighbor.

- 24 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

6 SENDING NR MESSAGES

In general, NR messages are to be sent only in response to a

poll. However, between two successive polls from an exterior

neighbor, a gateway may send one and only one unsolicited NR

message to that neighbor. This gives it limited ability to

quickly announce network reachability changes that may have

occurred in the interval since the last poll. Excess unsolicited

NR messages may be ignored, or an error message may be returned.

An NR message should be sent within several seconds after

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 -

RFC827 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 -

RFC827 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 -

RFC827 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 -

RFC827 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 -

RFC827 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 -

RFC827 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 -

RFC827 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 -

RFC827 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 -

RFC827 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:

0 Unspecified

1 Going down

2 No longer needed

Otherwise, this field MUST be zero.

Identification Number

An identification number to aid in matching requests and

replies.

- 34 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

NEIGHBOR HELLO/I HEARD YOU 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 ! Status !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Checksum ! Autonomous System # !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Sequence # !Min Poll Intvl ! Zero !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Last Poll Id # !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Description:

Exterior neighbors use EGP Neighbor Hello and I Heard You

Messages to determine neighbor connectivity. When a gateway

receives an EGP Neighbor Hello message from a neighbor it

should respond with an EGP I Heard You message.

EGP Version #

1

Type

5

Code

Code = 0 for Hello

Code = 1 for I Heard you

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.

- 35 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

Sequence Number

A sequence number to aid in matching requests and replies.

Status

0 No status given

1 You appear reachable to me

2 You appear unreachable to me due to neighbor

reachability protocol

3 You appear unreachable to me due to network

reachability information (such as 1822 "destination

dead" messages from ARPANET)

4 You appear unreachable to me due to problems

with my network interface

Last Poll Id Number

The identification number of the most recently received

NR poll message from the neighbor to which this message

is being sent.

Minimum Polling Interval

This gateway should not be polled for NR messages more

often than once in this number of minutes.

- 36 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

NR POLL 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 ! Unused !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Checksum ! Autonomous System # !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! IP Source Network ! Interval !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Identification # !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Description:

A gateway that wants to receive an NR message from an

Exterior Gateway will send an NR Poll message. Each gateway

mentioned in the NR message will have an interface on the

network that is in the IP source network field.

EGP Version #

1

Type

2

Code

0

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.

- 37 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

Identification Number

An identification number to aid in matching requests and

replies.

IP Source Network

Each gateway mentioned in the NR message will have an

interface on the network that is in the IP source network

field. The IP source network is coded as one byte of

network number followed by two bytes of zero for class A

networks, two bytes of network number followed by one byte

of zero for class B networks, and three bytes of network

number for class C networks.

Interval

The polling interval in minutes.

- 38 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

NETWORK REACHABILITY 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 !U! Zeroes !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Checksum ! Autonomous System # !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Fragment # !# of last frg. ! Identification # !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! IP Source Network !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! # of Int Gwys ! # of Ext Gwys !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! # of Nets ! ; # of nets for

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gateway 1

! Gateway 1 IP address (without network #) ! ; 1, 2 or 3 bytes

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! net 1,1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! distance !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! net 1,2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! distance !

+-+-+-+-+-+-+-+-+

.

.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! net 1,m !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; m nets reachable

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; via Gateway 1

.

.

+-+-+-+-+-+-+-+-+

! # of nets ! ;number of nets for Gateway n

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Gateway n IP address (without network #) !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! net n,1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! distance !

+-+-+-+-+-+-+-+-+

- 39 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! net n,2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes

+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! distance ! .

+-+-+-+-+-+-+-+-+ .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! net n,m !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; m nets reachable

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; via Gateway n

! distance !

+-+-+-+-+-+-+-+-+

- 40 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

Description:

The Network Reachability message (NR) is used to discover

which networks may be reached through Exterior Gateways. The NR

message is sent in response to an NR Poll message.

EGP Version #

1

Type

1

Code

0

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.

U (Unsolicited) bit

This bit is set if the NR message is being sent unsolicited.

Identification Number

The identification number of the last NR poll message

received from the neighbor to whom this NR message is being

sent. This number is used to aid in matching polls and

replies.

Fragment Number

Which Fragment this is in the NR Message. Zero, if

fragmentation is not used.

- 41 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

Number of Last Fragment

Number of the last fragment in the NR Message. Zero, if

fragmentation is not used.

IP Source Network

Each gateway mentioned in the NR message will have an

interface on the network that is in the IP source network

field.

# of Interior Gateways

The number of interior gateways that are mentioned in this

message.

# of Exterior Gateways

The number of exterior gateways that are mentioned in this

message.

# of Networks

The number of networks for which the gateway whose IP

address immediately follows is the appropriate first hop.

Gateway IP address

1, 2 or 3 bytes of Gateway IP address (without network #).

Network address

1, 2, or 3 bytes of network address of network which can be

reached via the preceding gateway.

Distance

1 byte of distance in # of hops.

- 42 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

EGP ERROR 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 ! Unused !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Checksum ! Autonomous System # !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Error Type ! Error Code ! Id. # of Erroneous Msg. !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Sequence # !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Description:

An EGP Error Message is sent in response to an EGP Message

that has a bad checksum or has an incorrect value in one of

its fields.

EGP Version #

1

Type

8

Code

0

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.

- 43 -

RFC827 Bolt Beranek and Newman Inc.

Eric C. Rosen

Sequence Number

A sequence number assigned by the gateway sending the error

message.

Error Type

The Type of the EGP message that was in error.

Error Code

The Code of the EGP message that was in error.

Identification number of erroneous message

The Sequence number of the EGP message that was in error.

Reason

The reason that the EGP message was in error. The following reasons

are defined:

0 - unspecified

1 - Bad EGP checksum

2 - Bad IP Source address in NR Poll or Response

3 - Undefined EGP Type or Code

4 - Received poll from non-neighbor

5 - Received excess unsolicted NR message

6 - Received excess poll

7 - Erroneous counts in received NR message

8 - No response received to NR poll

9 - Not all fragments of NR message received

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有