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: SIMON_SHEN SHEN_JIN@263.net)
Translation time: 2001-8-14
Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but must
Keep the translation and copyright information of this document.
Network Working Group Finlayson, Mann, Mogul, THEMER
REQUEST for Comments: 903 Stanford University
June 1984
Reverse address conversion protocol
(RFC903 - a Reverse Address Resolution Protocol)
Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin THEIMER
Computer science department departments
Stanford University
June 1984
This memo state:
This RFC document describes the dynamic when the workstation only knows the hardware address (for example: their physical network address)
A method of discovering an agreement address (for example: Internet address).
This RFC document describes a suggested agreement in the ARPA network community, which requires discussions and recommendations to strengthen.
table of Contents
Introduction 1
2. Design consideration 2
3. Recommended Agreement 2
4. Reference 3
Appendix A. Two Implementation Examples of 4.2bsd UNIX 3
1 Introduction
Some network hosts, such as diskless workstations, usually don't know the address of the agreement when starting, they only know
Hardware interface address. In order to communicate with high-level protocols such as IP, they must find them from the outside.
Agreement address. Our problem is that there is no standard mechanism to do this.
Plummer 's "Address Translation Protocol" (ARP) [1] is designed to solve a related problem: a given host
The protocol address gets its hardware address. This RFC proposes the "reverse address conversion protocol". Like ARP,
We assume a broadcast medium such as Ethernet.
2. Design consideration
The following considerations guide our design to the RARP protocol.
A. ARP and RARP are different operations. ARP assumes that every host knows its hardware address and association
Mapping between addresses. A small buffer stores information collected about other hosts. All hosts
The state is equal, there is no difference between the client and the server.
On the other hand, RARP requires one or more server hosts to maintain a slave hardware address.
Go to the map of the protocol address, and respond to the client's request.
B. Previous mentioned RARP needs to maintain large database server hosts, this is not hoped, in a certain
In some cases it is impossible to maintain such a database in the kernel of the operating system. Therefore, most implementation needs
And the procedures outside the kernel do some form of interoperability.
C. Simples for implementations and the minimum of the existing host software, design one requires changing each one
The protocol for the host's software (regardless of whether it is involved) is wrong.
D. In order to minimize development costs and costs, it is desirable to consider the possibility of sharing code with existing software.
3. Recommended agreement
We recommend RARP as a separate protocol for the data link layer. For example, if the medium uses Ethernet, RARP
Packages and ARP packs will have different Ethernet types. This means that ARP and RARP are two different operations, and all hosts are not equal to them. The impact on existing systems is also the smallest, existing ARP servers will not be
ARP package is confused. It treats RARP as a common manager that maps hardware addresses to any high-level protocol address.
.
This method makes the RARP client host implementation, but also makes the RARP server host
It is difficult to achieve. However, this difficulty is no way, two possible under the 4.2BSD UNIX described in Appendix A
It can be seen in the implementation.
RARP uses the same package format as ARP.
AR $ HRD (Hardware Address Space) 16 Bit
Ar $ pro (protocol address space) 16 bits
AR $ HLN (Hardware Address Length) 8 bits
AR $ PLN (Protocol Address Length) 8 bits
AR $ OP (opcode) 16 bits
AR $ SHA (source hardware address) N bits, n from Ar $ HLN field
AR $ SPA (Source Protocol Address) M Bits, M from Ar $ PLN field
AR $ THA (Destination Hardware Address) N-bit
AR $ TPA (Purpose Agreement Address) M Bit
Ar $ HRD, AR $ PRO, AR $ HLN and AR $ PLN are the same as ARP (see [1]).
For example, suppose the hardware address is 48-bit Ethernet address, the protocol address is a 32-bit Internet address, I
We hope to decide to determine the Internet address of the known Ethernet address, then in each RARP package, Ar $ hrd = 1
(Ethernet), Ar $ pro = 2048 (IP package Ethernet type), Ar $ HLN = 6, AR $ PLN = 4.
There are two opcodes: 3 (request) and 4 (response). 1 or 2 has the same meaning in [1], with this operation
The coded package is used as an ARP package. Package with other opcode is not defined. Like ARP, RARP
No "can't find" and "wrong" package because many RARP servers are free to answer requests. If
After a period of time, no response is received, the sender of the RARP request will time out.
The interpretation of Ar $ SHA, AR $ SPA, AR $ THA and AR $ TPA fields in RARP package is as follows:
When the opcode is 3 (request):
AR $ SHA is the sender's hardware address
AR $ SPA is not defined
AR $ THA is a destination hardware address
When the sender wants to know the address of his protocol, it will be the sender like Ar $ SHA.
Hardware address.
AR $ TPA is not defined
When the operator is 4 (answer):
Ar $ SHA is the hardware address of the responder (the sender of the answering package)
AR $ SPA is the responsive address of the responder (see note below)
AR $ THA is a destination hardware address, must be the same as the requested package
AR $ TPA is the address of the destination protocol, that is, the address you need.
Note: The protocol address of the AR $ SPA field fill in the package of 4 is 4, just for convenience. E.g,
The system uses ARP and RARP, effective protocols - hardware pairs (AR $ SPA, AR $ SHA) will reduce ARP later
Request.
4. Reference
[1] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826, MIT-LCS, November 1982.
Appendix A. Two implementations under 4.2BSD UNIX
The following implementation description summarizes two different methods of implementing the RARP server under 4.2BSD UNIX.
A. Provides an internal access data link layer package. The RARP server is implemented outside the kernel, only RARP only
The package and kernel are interoperable. The kernel is modified to provide an interface to access these packages, currently 4.2 kernel only
Allow access to the IP package. The CMU's "package filter" pseudo-drive is an existing mechanism for providing this feature. It in CMU
The "user-level" network server is sorted by Hustangford, which is very successful.
B. Maintain a cache of a database table item in the kernel. The entire RARP server database passes a user process
Internal maintenance. The RARP server itself is implemented directly in the kernel, and a small data is maintained for answering.
The entry cache. This cache and the transmission of ARP are the same. This cache is controlled by two new input and output control.
The RARP database is obtained (this is like Siociful, because they do not directly and specific sockets).
One is: "Sleep until you need to convert the address conversion, then output the request to the user process"; another
Yes: "Convert the Add Address Enter Core". Therefore, when the kernel cannot find an entry in the cache,
Put this request in the queue and call Wakeup (). The implementation of the first input and output control is SLEEP (),
Remove the first item from the queue to the user process, because the kernel can't wait until the user process back
Should be, it or abandoned (assuming that the host will retransmit the request package after a certain time), or if the second input
The control copies the request to the kernel, and answers at that time.
RFC903 - A Reverse Address Resolution Protocol Reverse Address Translation Protocol
1
RFC Document Chinese Translation Program
