Organization: China Interactive Publishing Network (http://www.china-pub.com/)
RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail: Ouyang@china-pub.com
Translator: 15222775 @ 61. (15222775 @ 61. Hbzzx2001@yahoo.com.cn)
Translation time: 2002-3-2
Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but the translation and copyright information of this document must be retained.
NetWork Working Group Network Technical Advisory Group
Request for Comments: 985 nsf
May 1986
Internet Gateway Requirements - Draft
(Requirements for Internet Gateways - Draft)
This memo state
This RFC summarizes the need for gateways that support the DARPA Internet Protocol on the network. It also applies to the National Science Foundation Research Procedure, technical requirements for the provision of popular contexts, believe that it can be applied to the entire Internet community. These documents are developed by the gateway requirements of the NSF Network Technology Service Panel and the Internet Engineering Committee, Network Architecture Working Group, and Internet Engineering Working Group. Welcome discussions and recommendations for improvements.
The distribution of this memorandum is not limited.
The purpose of this document is to guide suppliers to provide products that can be used for Internet applications or adaptate products for use in an Internet application. It enumerates some necessary protocols and gives the RFCS reference and other documents that describe the current specification. Because this specification is gradually developing, there may be unclear or incomplete information. This further details given the guidance of the present document. The specific policy issues related to the NSF Scientific network group are summarized into an appendix.
*********************************************************** *******************
This is the draft version of the report of the gateway.
Note can be found on this document and may incorporate the last version. The annotation is from now on the new gateway, the specific supplier of the gateway and the potential supplier. Commentary As of 86 August 15, in 90 days, the revision will allocate a new RFC number during this period.
*********************************************************** *******************
The suggestions and comments of this document can be sent to the Secretary for Dave Mills (Mills @_USC - ISID.ARPA), or the NTAG Board, Dave Farber (Farber@_huey.udel.edu). The member is as follows:
Hank Dardy, NRLDardy@nrl.arpa
Dave Farber, u delawarefarber@huey.udel.edu
Dennis Jennings, Jvncjennings%Pucc.bitnet@wiscvm.wisc.edu
Larry Landweber, u wisconsin landweber@rsch.wisc.edu
Tony Lauck, Decrhea !Bergil !Lauck@decwrl.Arpa
Dave Mills (chairman), LinkAbit Mills@usc-isid.arpa
Dennis Perry, Darpa/iptoperry@ipto.arpa group committee thanked the following contributors and special manuscript reviewers:
Len Bosck, Stanford U / Cisco Bosck@su-score.arpa
Bob Braden, isibraden@isi-braden.arpa
Hans-Werner Braun, u michiganhwb@gw.umich.edu
Noel Chiappa, Mit / Proteon Jnc@proteon.arpa
Doug Comer, purdue udec@cs.purdue.edu
Ira Fuchs, Princeton U fuchs%pucc.bitnet@wiscvm.wisc.edu
Ed Krol, U illinoiskrol%uiucvmd.bitnet@wiscvm.wisc.edu
Barry Leiner, Riacs Leiner@riacs.arpa
Mike muuss, brlmike@brl.arpa
Ron Natalie, BRL RON@brl.arpa
Harvey newman, citnewman@cit-hex.arpa
Jon Postel, isipostel@usc-isib.arpa
Marshall Rose, nrtc mrose@nrtc-gremlin.northrop.com
Jeff Schiller, Mitjis@bitsy.mit.edu
Lixia zhang, mit lixia@xx.lcs.mit.edu
1 Introduction
The following sections provide introductions and background knowledge that is not familiar with people who are not familiar with Darpa Internet Architecture and Internet Gateway Models. Regarding the general background and details of the network architecture and protocol stack support can be found in the DDN protocol [25] and Apa.com, and can be found from the Network Information Center, Sri International, Menlo Park, It is obtained in CA 94025. Readers who are familiar with these concepts can enter Section 2 directly.
1.1. DARPA Internet architecture
The DARPA Internet system consists of a network that is commonly providing package transport for a host that supports the Darpa Internet protocol architecture and many gateways. These protocols include Internet Protocol (IP), Internet Control Message Protocol (ICMP), Transfer Control Protocol (TCP), and application protocols depending on them. All protocols use IP as a basic package-transmitting mechanism. IP is a datagram, or no connection service, including service description, segment / reorganization, and security information.
ICMP is considered to be an ip inseparable portion, although the structure is on IP.
ICMP provides error reporting, traffic control, and initial gateway redirection. Reliable data delivery is provided by TCP in the protocol stack, which provides end-to-end retransmission, reordering and connection control.
No connection services are provided by the User Data News Agreement (UDP).
The Internet community currently includes thousands of hosts connected to more than 400 networks with 120 gateways. Now registering the ARPA separate domain name far more than 2400 and registers the host of other domain names or an unknown number, the total number increases at a speed per month. Many hosts, gateways and networks in the Internet community are managed by civil organizations, including universities, research laboratories and equipment manufacturers. Most of the remaining parts are managed by US DOD and considered as part of the DDN Internet, and DDN Internet is currently consisting of a network system: a test part or arpanet, a non-confidential part or MILNET, and is specified as confidentially no collective name part.
The Internet model contains the component network, called the LAN to distinguish them with the international internet network system, and the latter only needs to provide a datagram (no connection). Only require it to "try to" delivery a package or datagram. Each data is filed with 32-bit source and destination addresses, which encodes three formats, providing an address consisting of two parts, one of which is the network number of the unit and the other is the host number on that local network. . According to the International Internet Service Description, the datagram can disseminate, discard or copy and / or include errors. In the network that provides a connection-oriented service, since the virtual circuit provides additional reliability to improve the end-to-end robustness of the system, it is not absolutely necessary. The interoperability of the local area network in the international Internet model depends on the Internet gateway. These gateways only provide datagram transfer and try to use as little status information to support this service between routing flexibility and robustness. In the traditional model, the gateway has a physical interface and address on each local area, and these LAN provides forwarding services. The gateway is involved in one and multiple distributed routing and accessibility algorithms such as: Routing table gateway to the gateway protocol or external gateway protocol to maintain its routing table.
1.2. Internet gateway model
An Internet gateway is a complete, stand-alone packet group switch to complete the following features:
1. Used to connect two or more packet group switched networks, including packages, address translation, and traffic control.
2. Compliance with the specific DARPA internet protocol specified in this document, including Internet Protocol (IP), Internet Control Message Protocol (ICMP), external gateway protocol, and other protocols required.
3. Supports internal gateway protocols or routing algorithms that run multiple gateways in a system. In order to exchange routing between the system, the external gateway protocol can be supported, especially the core system of the National Defense Advanced Research Project Authority works in BBN.
4. Accept and forward the International Internet Datasters in terms of resource management, congestion control, and fairness. It is possible to distinguish a variety of error conditions and generate an international Internet lettering control protocol error and information packets in accordance with the regulations.
5. Provide system support tools, including loading, commissioning, status reporting, abnormal reporting, and control.
In some cases the gateway may be connected to a packet switching LAN, which has a general local area network route, error control, and resource management capabilities. Other gateways may be connected directly through the serial line, so these functions must be provided by the mesh itself.
Gateway manufacturers provide three typical solutions:
1. National or regional network. This type of gateway should have a plurality of continuous continuous traffic, with a speed of thousands of packets per second per second. They should be high-performance multiprocessor devices that have redundant capabilities, as a system is provided and can operate from a remote or national monitoring center. The design of these gateways emphasize huge throughput, sensitive resource management and very high security for throughput. Typical applications are the National Science Foundation's backbone network or a group or region of network.
2. Campus network. This type of network should be able to handle some 10 megabits of burst traffic exchange processing (Ethernet, etc.) to handle some 64 kits per second, traffic within a speed range of thousands of packages per second. . They are medium-performance equipment that can generally be available from different supply vendors, used for campus networks and control at the campus electronic computer center. The design of these gateways should emphasize lower average delay times and good performance of emergencies, providing resource management that is sensitive to delay and type service. Their main features may be to connect a wide variety of local area networks and campus computing resources, including high-speed Internet countries and regional networks. An important factor is a very flexible routing mechanism because these gateways may choose a certain backbone network based on performance prices.
3. Department network This type of network should be able to deal with a small amount of 10 megabits of burst of burst flow (Ethernet, etc.), handling a small amount of 64 thousands of bits per second, hundreds of packages per second The flow within the range. They may be devices that have moderate performance from many different vendors, while they are used to handle protocol matching, local area relay, and as a general packet group exchange. They may be maintained locally through a variety of users, and cannot be used as a transfer switch. The important point is that the Internet access can be done normally in the case where no one is taken, but the equipment and software failure may affect the entire internet. Although some solutions relate to the absolute control of the gateway from the Supervision Center, it is usually passed by a path including other networks and the Internet gateway, and other control processes may involve less control.
Therefore, the gateway must be very robust and expected, may be able to operate in a deteriorating situation, such as extreme crowd or network resource failure.
⒉ agreement requirements
Internet architecture uses the datagram gateway interconnect network and subnet. These gateways have the effect of the intermediate system (IS), with packet formats corresponding to ISOs and include their defined package, routing algorithms, and related programs. It is assumed below to assume that the protocol implements all protocols, including all required options, and exceptions only as an attachment.
2.1. Internet Protocol (IP)
This is the basic datagram protocol for international interconnected network systems.
It is described in RFC - 791 [1] and MIL - STD - 1777 [5], both of which are used to describe the same standard, but it has used a completely different wording.
Based on the current gateway requirements, the following is overlooked, although they may need them in the future: business domain type, security option, stream ID option, and timestamp options.
However, in order to identify, the interpretation of these parameters must meet the standard specification.
The Internet gateway model does not require the gateway to reload the IP datagram with the destination address rather than the gateway itself. However, as for the protocols participating directly as a homotropic body, including the Routing and Monitor / Control protocols, the gateway may have to reload the data report to IT. This consideration is mostly in the coherence of EGP.
Note that five types of IP addresses. From Class A to Class E, Class D, and E - class addresses for experimental use. Those gateways that do not participate in these experiments should ignore all packages with a D-class or E destination IP address. Receiving such a package will not cause the ICMP Destination Unreachable (dedural) or ICMP redirection packet.
2.2. Internet Control Message Protocol (ICMP)
This is an auxiliary protocol for communicating notifications and error packets, and is described in RFC - 792 [2].
The difference between the subnets of a network depends on an arbitrary mask such as RFC - 950 [21], which is usually invisible to the outside of the network. This difference is important in some ICMP packets, ICMP
The same is true for dedural and ICMP redirect messages. The ICMP destination is not reaching the message by a gateway that responds to a datagram that cannot be forwarded because the destination is not arrival or shutdown. Several types can be selected, including a specified network and then another specified destination owner. However, the former implied that the address range is uncertain, unless the subnet is known as the sender, but in general. It is best to avoid unreachable messages using ICMP destination networks. Alternatively, an ICMP destination host does not reach a message should be sent to each different IP address.
For a specified host or network, the ICMP redirect message is sent by a gateway to a host to change the address used by the host. Depending on it is applied to a specific host, network, or service, you can choose from four packet types.
As in the previous case, these differences may be fixed with the subnet mask. As in the above case, it is best to implies an address range (such as network being unavoidable, network redirection) by using ICMP packets, which is advantageous for implicit specific addresses (eg, the host is not reached, the host redirection). The ICMP source has become an inscription of the provisions. When this message is generated or explained in a host or gateway, it is unrealistic.
The new host and gateway implementation is expected to support ICMP address mask packets, and the ICMP address mask packet is described in detail in RFC - 950. Although it is not necessary to provide correction data function for ICMP timestamp, it is very desirable, because it has been found to provide correction data capabilities for ICMP timestamp, which is very useful for network debugging and network maintenance.
2.3. External Gateway Protocol (EGP)
This is the basic protocol used to exchange information between the Internet of the Internet, which describes the protocol in detail in RFC - 904 [11].
However, EGP is an asymmetric protocol according to the current definition, and only has the "non-kernel" program defined in RFC - 904. There is currently no predetermined "kernel" program, but the "kernel" program is necessary to create a system-independent Internet. RFC - 975 [27] proposes some modifications to generate a symmetric model; however, this is not an official specification.
In principle, an "non-core" EGP gateway can be established, with the operating system independent Internet, which transmits certain metric, such as the number of stations using the EGP distance domain. However, in this approach, the EGP is prohibited as a routing algorithm because the standard implementation uses very slowly change the topology and does not prevent loop characteristics.
The EGP model requires each gateway to belong to a private system for a gateway. If a routing algorithm runs on one or more gateways of a self-governing system, its database must be related to the EGP. At this time, when a network declaration is done by the routing algorithm, the network also passes through EGP to other autonomous The system declares downtime. This is the necessary condition for minimizing communication to "black hole", and guarantees fair use of resources in other systems.
At present, the EGP specification does not define an associated bodies discovery or authentication process and is not defined in the interpretation of the distance field in the update message, which may be defined in the future (see RFC - 975). The current NO has the guidance of polling parameter selection and there is no specific recovery program to prevent certain packet errors.
(For example, "Government Prohibition"). The EGP implementation is preferably included in initializing these parameters as part of monitoring and control program and changing these programs without requiring recompiling. Restart the gateway.
2.4. Address Resolution Protocol (ARP)
This is an auxiliary protocol to manage address conversion functions between machine addresses between a local network environment and the Internet address, which describes the address resolution protocol (ARP) in the RFC - 826 [4]. However, there are many problems associated with the subnet and the response to the address is not in the same subnet or network. This problem is wound with ICMP and a wide variety of gateway models, discussed in detail in Appendix A.
⒊ ⒊ 网 division
The concept of subnet is introduced in order to allow any complex interconnect LAN organization within an organization, although the Internet system has grown rapidly in network numbers and Routing complexity. The subnet network architecture is described in detail in RFC - 950 [21], which is used to specify a standard method. It does not have to be reconfigured for the host, independent of subnet division scheme. This document also provides a new ICMP address mask message, and a gateway can specify the details of some sub-network schemes for the host, which is required in new host and gateway implementation.
Current subnet network specification RFC - 950 is not described in the specific program used by the gateway.
It is best to provide a (sub) network address and address mask for each network interface, and these values are set as part of the gateway configuration process. During any specific gateway operation, these values are usually not required; however, you can add new gateways and / and (sub) networks and modify a gateway configuration without having to stop the entire network.
⒋ Local network interface The package format for transmitting a datagram on a wide variety of subnets is described in detail in the following large number of documents.
4.1. Vital data via X.25
The format specified for the public data network accessed via X.25 is described in detail in RFC - 877 [8]. Data reports are transmitted in accordance with the correct packet sequence through standard 3-layer virtual circuits. Virtual circuits typically have donatedly established as needed and there is still no traffic in a period of time. The network completes retransmission, reordering, and flow control through the LAPB link level protocol to each virtual circuit. In order to improve the utilization of the user inlet line, multiple parallel virtual circuits can be used, those which may cause accidental reordering. The consistency between Internet and X.121 addresses is usually established by a list. It may be replaced by a directory program in the future.
4.2. ARPANET from the 1822 local host or the remote host or HDLC remote host
The format specified in the Apa network accessed via the 1822 is detailed in the BBN Report 1822 [3], including several user access methods. Local host (LH) and very distant host (VDH) methods do not recommend new implementation. Remote Host (DH) method When the host and IMP are used by no more than 2000 mile cables, the HDLC remote host is used for huge distance, which requires a modem. When used, the network completes retransmission, reordering, and flow control through the HDLC link level protocol. The Arpanet 1822 protocol is currently used extensively, and it is expected to ultracence the DDN standard X.25 protocol (see below) and new PSN point-to-point transfer protocols are described in detail in RFC - 979 [29].
The report mentioned to the details of a wide variety of ARPANET user access methods do not specify whether the IP packet packing format is not specified in address transformation. These are usually simple and easy to implement, and the detailed information is outside the scope of the document easily accessible. To request a supplementary information, potential suppliers encourage the initial part of this document.
Gateway connecting to ARPANET / MILNET IMPS must include the failure of avoiding host-port blocking (RFNM calculations) and the failure of the host or gateway for listening and reporting (like ICMP unreachable messages).
4.3. Apa.com of X.25 via DDN
These are in detail in the National Defense Data Network X.25 Host Interface Specification [6] in the format of the Arpanet network via X.25.
This document describes the two groups, DDN Basic X.25 and DDN Standard X.25, but only the latter is suitable for use in the Internet system. In addition to the different address mappings, the DDN Standard X.25 program is similar to the public data subnet X.25, and the network completes retransmission, reordering and flow control for each virtual circuit through the LAPB link level protocol.
4.4. Ethernet
The format specified in Ethernet is described in detail in RFC - 894 [10]. Data report compresses Ethernet packets with 48-bit source and destination address fields and a 16-bit type field. The address translation between the Ethernet address and the Internet address is done through the address resolution protocol, and the address resolution protocol is required in all Ethernet implementations. No explicit retransmission, reorder or flow control. Although most hardware interfaces may be automatically transferred in the case of cable conflicts.
Some modifications for IEEE 802.3 progress may occur. For further discussion and recommendations in this domain, see RFC 948 [20]. Also pay attention to the IP broadcast address, IP broadcast addresses have become an initial application of Ethernet and similar technologies.
The host domain of the IP address has a full value. Some original implementations are selected for this purpose, which is not consistent with the current RFC - 950 [21] defined.
See Appendix a further consideration.
4.5. Serial Line Agreement
In order to establish a network gateway, it may be used as a packet switch. The gateway in some configurations may be connected to each other by means of asynchronous or synchronous serial lines (or no modems), and and some hosts are connected to each other. When it is proven to be correct, it is possible to need a link level protocol on the serial line when it is correct. Although there is no need to use a specific standard statute for this, it is best to use standard hardware and protocol unless it is opposing. In order to support a large difference in configuration, it is best to allow the resources used herein to change in all X.25 (eg, "symmetrical"); however, X.25 LAPB may still accept. In the case of an asynchronous line, it is unclear. ⒌ interdecessibility
In order to ensure the interference between the gateways from different suppliers, the agreement is required. The interoperability of the route selection function is specified in accordance with the EGP. All gateway systems must include one or more gateways (supported with a core gateway), such as RFC - 904 [11]. The gateway is best able to operate in such a mode, this mode does not require a core gateway or core system. Supplementary discourse to these issues can be found in RFC - 975 [27].
With regard to the interoperability of the network layer and the network layer, two protocol boundary points have been specified, and one protocol split point is the Ethernet specified and the other protocol split point is serial line regulations. In the case of Ethernet, those protocols are specified in Section 4.4 and this document Appendix A. For serial lines between the gateways of different suppliers, these protocols are detailed in the 4.5 section of this document.
Sometimes it is also suitable for these requirements.
⒍子 网 architecture
In order to establish a medium-sized network, these gateways may play a normal packet switch. This requires assistance to manage network routing, control, and configuration. While specifying the details of any specific, perhaps the mechanism of the patented architecture exceeds the scope of this document, a large number of basic requirements must be provided by any acceptable architecture.
6.1. Recessor Program
A robust the architecture must provide a robust mechanism to build each link to each link and a node (including various gateways), which connect them and connect these hosts. Typically, these at least one link-level accessibility protocol is required, and this link-level accessibility protocol crosses each link a periodic exchange "Hello" message. These features may be inherent, such as LAPB (Balanced Link Access Items) DDCMP (Digital Data Communication Packet Protocol) for link-level protocols. However, assume that a host or gateway regards whether its link-level reachability protocol operation is correct, it can be used correctly. In addition, it is confirmed that a running routing algorithm or equivalent hierarchy protocol (e.g., for EGP).
A link to / and the faults and recovery of the gateway are often considered a network event and must report to the control center. Although it is not necessary to report that the path itself does not require correctation of the routing algorithm but it is desirable.
6.2. Routing Algorithm
The repetitive experience of participating in the routing mechanism (regardless of static or dynamic) international internet network group is the most important engineering problem lies in network design. In all and usual network topologies, the necessary routing dynamics is indispensable to effectively run, regardless of whether it is affected by manual or automatic approach or both. In particular, if routing changes are manually made, the change must allow for reconfiguration without disassembling the gateway, more ginsen, and changes may come from a remote, for example a remote control center.
Because all networks can be maintained by one business control center, it is not possible, so automatic-replacement or alternative routing features may be required. This is usually considered normal, so the gateway system of the unique packet switch in the network should have a routing algorithm, the routing algorithm is the ability to respond to the link and other gateway failures and automatically evoke changes.
Below is a functional component that is considered necessary:
1. The algorithm must detect a link or other gateway failure or recovery and to go to the appropriate path in a smaller time interval with a standard TCP user (one minute is a reliable assumption). 2. This calculation cannot form a routing loop between adjacent mesh and must include avoiding and changing the routing circuits that may be formed between the non-adjacent mesh gateways. A loop time should never be longer than the standard TCP user timeout interval.
3. Control traffic must operate the routing algorithm. Do not degrade or destroy normal network operations. Changes in a local area may not be destroyed from the network in remote regions that may not be destroyed at any time.
4. If the size of the network increases, resources need to be controlled with an effective way. For example, the reference table should be repeated and the database update fragmentation process, and the change is spread to a wide range of ranges. Reachability and delay metric, if used, can not directly depend on all other gateway connectivity or the application of the specific network broadcast mechanism. The polling process (for example, in order to maintain consistency) should only use a small number of use and can never introduce a constant overhead that exceeds a network layout.
5. By using a default gateway as a method of reducing the route selection data size, given many problems such as multipath, loop, and error-configuring weaknesses. If used, it should be limited to one discovery function, with routes that are stored via a routing algorithm or EGP external or internal database.
6. This document does not limit the type limits of the routing algorithm, and the type is node based, link or any other algorithm, or a metric, such as a delay or road segment. However, the size of the routing database is not allowed to exceed a number of records independent of the network layout calculation time (the average of the average) constant. An advanced design does not require all routing databases to be controlled to any specific gateway, so discovering and cache technology may be required.
⒎ Run and maintenance
Gateway and packet switches are often used as a system, some organizations agreed to operate and maintain these gateways and solve link problems with corresponding telecommunications companies. Note that those network control locations may not be physically connected to the control network. Usually, the necessary conditions are applied:
1. Each gateway must be a stand-alone device for local hardware maintenance purposes. It means that only the site is used in the gateway location (perhaps only one disk tape and the local terminal) can be used to run the diagnostic program. Although not required, it is desirable to automatically restart and dump via the network via network in a fault condition and automatically restart and dump via the network. Usually these require special equipment.
By utilizing a mature transmission service, for example, TCP is usually unwise, if it only needs to restart and dump the gateway. The matter you need to consider should be a given UDP or specific monitoring protocol, such as HMP, for example, the HMP (Host Oversight Protocol) is described in detail in RFC - 869 [7].
2. It must be possible to restart and dump the gateway from the control site. Each gateway must include one or start a restart or remote location signal monitor clock, if the software is not regularly reset. This involves data is best resident in the control site and transmitted via the network; however, by utilizing the local device in the gateway location. However, the operation of starting the reboot or dump must be available via the network, assumes that a path takes effect and the connection link link is running.
⒊ Must provide a mechanism to aggregate communication statistics include, but are not limited to, package labels, error packet tags, and more. The preferred method of retrieving these data is an explicit method, regularly requires the control site to use a UDP or HMP-based standard data report agreement.
By utilizing mature transmission services such as TCP is usually unwise, if only the statistics from the gateway are required. The matter you need to consider should be a given UDP or specific monitoring protocol, such as HMP, for example, the HMP (Host Oversight Protocol) is described in detail in RFC - 869 [7].
4. Abnormal Report ("Trap") Existence as a hardware or software failure, (possibly when batch reduction package overhead) These software failures should be used to use a UDP or HMP-based standard datagram protocol to the control site.
A mechanism must be provided to display a continuous library of link links to the control site and node status. It is best to be a complete mapping of all effective link links and nodes, but only the components used by the route algorithm are also acceptable. This information is usually available locally on the control site, assuming is a location involved in the routing algorithm. The above functions typically require a control site or proxy cooperation. A more desirable way to provide these features is to provide a program that is suitable for running in a standard software environment such as a UNIX operating system. The program may use standard IP protocols such as TCP transmission control protocols, UDP user data packet protocols, and HMP host monitoring protocols to control and monitor those gateways. Host hardware and software that use specialized customized additional investments is strongly blocked; however, certain suppliers may elect the supply control agent as a gateway as the necessary components of the network. If this is, a method that can be used to operate from a remote use Internet protocol and path to operate the control agent and has a function with respect to the local proxy terminal.
Remote control via an international internet pathway may involve a direct means, or an indirect means, where the gateway directly supports TCP and / and UDP, which supports these protocols and controls the gateway itself using proprietary protocols. The former is more desirable, although any way is acceptable.
⒏ Reference and literature directory
[1] Defense Advanced Research Projects Agency, "Internet Protocol", Darpa Network Working Group Report RFC-791, USC Information Sciences Institute, September 1981.
[2] Defense Advanced Research Projects Agency, "Internet Control Message Protocol", Darpa Network Working Group Report RFC-792, USC Information Sciences Institute, September 1981.
[3] Advanced Research Projects Agency, "Interface Message Processor - Specifications for the Interconnection of A Host And An Imp", BBN Report 1822, Bolt BERANEK AND NEWMAN, DECEMBER 1981.
[4] Plummer, D., "An Ethernet Address Resolution Protocol", Darpa Network Working Group Report RFC-826, Symbolics, September 1982.
[5] United States Department of Defense, "Military Standard Internet Protocol", Military Standard Mil-STD-1777, August 1983.
[6] Defense Communications Agency, "Defense Data NetWork X.25 Host Interface Specification", BBN Communications, December 1983.
[7] Hinden, R., "A Host Monitoring Protocol", Darpa Network Working Group Report RFC-869, BBN Communications, December 1983. [8] KORB, JT, "A Standard for the Transmission of IP DataGrams over Public Data Networks ", Darpa Network Working Group Report RFC-877, Purdue University, September 1983.
[9] Nagle, J., "Congestion Control IN IP / TCP InternetWorks", Darpa Network Working Group Report RFC-896, Ford Aerospace, January 1984.
[10] Hornig, C., "A Standard for the Transmission of IP DataGrams over Ethernet Networks", Darpa Network Working Group Report RFC-894, Symbolics, April 1984.
[11] MILLS, D.L., "Exterior Gateway Formal Specification", Darpa Network Working Group Report RFC-904, M / A-COM LinkAbit, April 1984.
[12] Postel, J., And J. Reynolds., "ARPA-Internet Protocol Policy", Darpa Network Working Group Report RFC-902, USC Information Sciences Institute, July 1984.
[13] Kirton, P., "EGP Gateway Under Berkeley Unix 4.2", Darpa Network Working Group Report RFC-911, USC Information Sciences Institute, August 1984.
[14] Postel, J., "Multi-Lan Address Resolution", Darpa Network Working Group Report RFC-925, USC Information Sciences Institute, October 1984.
[15] International Standards Organization, "Protocol for Providing the Connectionless-Mode Network Services", DARPA Network Working Group Report RFC-926, International Standards Organization, December 1984. [16] National Research Council, "Transport Protocols for Department of Defense Data NetWorks, Darpa Network Working Group Report RFC-942, National Research Council, March 1985.
[17] Postel, J., "DoD Statement On NRC Report", Darpa Network Working Group Report RFC-945, USC Information Sciences Institute, April 1985.
[18] International Standards Organization, "Addendum to The Network Service Definition Covering Network Layer Address", Darpa Network Working Group Report RFC-941, International Standards Organization, April 1985.
[19] Leiner, B., J. Postel, R. Cole and D. Mills, "The Darpa Internet Protocol Suite", Proceedings Infocom 85, Washington DC, March 1985] Also IN: IEEE Communications Magazine, March 1985.
[20] Winston, I., "Two Methods for the Transmission of IP DataGrams Over IEEE 802.3 Networks", Darpa Network Working Group Report RFC-948, University of Pennsylvania, June 1985.
[21] Mogul, J., And J. Postel, "Internet Standard Subnetting Procedure", Darpa Network Working Group Report RFC-950, Stanford University, August 1985.
[22] Reynolds, J., And J. Postel, "Official ARPA-Internet Protocols", Darpa Network Working Group Report RFC-961, USC Information Sciences Institute, October 1985. [23] Reynolds, J., And J. Postel , "Assigned Numbers", Darpa Network Working Group Report RFC-960, USC Information Sciences Institute, December 1985.
[24] Nagle, J., "ON Packet Switches with Infinite Storage", Darpa Network Working Group Report RFC-970, Ford Aerospace, December 1985.
[25] Defense Communications Agency, "DDN Protocol Handbook", NIC-50004, NIC-50005, NIC-50006, (Three Volumes), SRI International, December 1985.
[26] Defense Communications Agency, "Arpanet Information Brochure", NIC-50003, Sri International, December 1985.
[27] MILLS, D.L., "Autonomous Confederations", Darpa Network Working Group Report RFC-975, M / A-COM LinkAbit, February 1986.
[28] Jacobsen, O., And J. Postel, "Protocol Document Order Information", Darpa Network Working Group Report RFC-980, SRI International, March 1986.
[29] Malis, A.G., "PSN end-to-end functional specification", Darpa Network Working Group Report RFC-979, BBN Communications, March 1986.
Appendix A. Ethernet Management
Below is the program summary information used in a host and gateway that specifies on the Ethernet.
A.1. Hardware
Only when its destination Ethernet address match allocated interface address or a broadcast / multi-player address, accept a package from the cable. Filter estimation may be done by interface hardware; however, if the hardware does not work software driver should be completed. Some hosts include an optional feature that is associated with a multipoint broadcast address with a specific subnet to limit access to testing, etc. When this feature is activated, the assigned multipoint broadcast address replaces the broadcast address.
A.2. IP Data News
In the case of broadcast / multi-point broadcast (based on the destination Ethernet address decision), an IP datagram is discarded, and if the result of the result of the host IP address and subnet mask, the source IP address is different from subnet. It is best to replace this test by a configuration parameter, in order to support rare cases (more than one subscriber may have a co-existence of the same cable). A.3. ARP (address resolution protocol) Data News
An ARP response is discarded, if the destination IP address does not match the local host address. An ARP request is discarded if the source IP address is different from subnet. Preferably, this test is replaced by a configuration parameter, in order to support rare cases (more than one sub-network may have copied on the same cable), see RFC - 925. An ARP response is only available when the destined protocol IP address is generated from a local host (according to the judgment due to routing algorithm), and the next route is not connected to the same interface. If the local host plays a gateway, this may cause the ARP response that is not destined in the same subnet.
A.4. ICMP redirection
An ICMP redirection is discarded if the destination IP address does not match the local host address or the new target address is not the same subnet. A received redirect update routing database is old target address. If there is no route or related to the old target address, those redirects are ignored.
If the old route is connected to a default gateway, a new route is inserted into the database with the new target address. Note that it is impossible to send an unreasonable redirection unless the sender has considerable imagination.
When using subnets, there are certain blurred redirect range unless all hosts and gateways involved in advance understand the subnet mask. By avoiding the use of ICMP network redirection packets, it is beneficial to the ICMP host redirect packet. This requires the original sender (such as a redirect receiver) supports a normal IP address translation cache, not a usual network list.
However, this is normal in the case of ARP.
An ICMP redirection can only be generated when the destined IP address from the local host (according to the judgment due to routing algorithm), and the target address is defined in the routing database, the next route via the same interface. The redirection will not be sent in response to an IP network or subclass broadcast address or sent to a D class or an E-class IP address response.
ICMP redirects will never forwarded, independent of the address of the destination. ICMP redirection itself The source IP address is not checked because the send gateway may use its address on the universal network. The compressed IP data source IP address is not checked, and it is done by assuming that the host or gateway sends this initial IP datagram.
Appendix B. Policy
The following sections describe some of the issues of a network group specially concerned about NSF science. This problem has the original reference in the policy range and has branches in the technical zone.
B.1. Interconnect Technology B.1. Interconnect Technology
The most important universal interconnect technology between the Internet systems of different suppliers is Ethernet (Ethernet). The reasons are as follows:
1. Ethernet specification has been fully understood and mature
2. Almost all of Ethernet technology is independent of the supplier.
3. Ethernet supporting system is getting more common
These superiority combinations facilitate the use of Ethernet technology as the boundary intersection between NSF network systems, and the NSF network system is supplied by different suppliers, and the network system is independent of technology. An essential condition of the NSF gateway is to use the exchange technology ownership of a given supplier supply network as much as possible, and its gateway must support a gateway Ethernet that connects other vendors.
The NSF gateway requires other interconnect technologies in the future, which may occur. The most likely candidates are those based on X.25 or IEEE 802, but other technologies include broadband cables, fiber, or other protocols such as DDCMP, may also be considered.
Ownership and scalable problem
Internet technology is a developable, adaptable technology. Although the hosts, gateways and networks support these technologies have been continuously running for many years, the supplier users and operators should know that all network issues have been fully understood. Therefore, it is necessary to need a new protocol when the new needs or better solution is developed for use in the NSF network. Generally speaking, these new protocols may be designed to have interoperability with existence protocols in all applications; however, it may occasionally, that is, existing systems must increase to support these protocols. NSF system vendors should understand that they also have to pay attention to the current development of Internet technology and prepare for the products that are upgraded from time to time. Therefore, these suppliers are strongly encouraged to consider the extensibility of the product and upgrade regularly according to the basic performance of their products. A maximum effective way to do so long-term rewards is to participate in the advancing Internet research and development procedures with academia.
B.3. Multi-protocol gateway
Although it is also required for future protocol groups that currently specify only the Internet protocol group, which supports the future protocol group and allows simultaneous operation of more than one protocol group.
Undoubtedly, the ISO protocol stack is one of the original candidates in these groups. Other candidates include XNS and Decnet.
For future needs of NSF gateways, it may include other protocol stacks other than INTERNETs and models and specifications they migrate between them. For example, the ISO group may finally become the biggest one; however, other group.
The current NSF gateway requires not including the above network layer protocol, such as TCP, unless necessary for network monitoring or control. Supply vendors should recognize future demand interact between Internet and ISO applications, such as, may result in a possible-gateway to support multiple protocols at all levels until the application level is supported. The network-level NSF gateway included in this document may be combined to enter the application layer gateway essential document.
B.4. Access control and accounting
There is no requirement to include specific access control and billing mechanisms at the time of design; however, these important issues are currently under research and may have been incorporated into documents that are re-drafted during the recent period. Encourage suppliers to introduce these mechanisms as soon as possible in their products. Although there is no universal mode that has already emerged at the time, these models should be described as the general feature that should have, and some of them should be as follows:
1. The primary access control and management account mechanism may be in the host service itself, not a gateway, a packet switch or a workstation.
2 The stakeholders affecting the access control and management accounts may have to be in the gateway, packet switches or workstations. These may be used to collect, execute password protection or adjust resource priority and rationality. However, the architecture and protocols used for these agents may be partial things but are not possible in advance.
3. The NSF gateway may require access control and accounting mechanism, based on the source / destination address, and other domains, internal priorities, and reasonable in the IP header. However, these mechanisms are extremely generally involved in a user record for the gateway itself.
RFC 985 - Requirements for Internet Gateway - Draft Internet Gateway Requirements - Draft
1
RFC Document Chinese Translation Program
