Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
EXPERIMENTAL
Network Working Group M. AccettaRequest for Comments: 887 Carnegie-Mellon University December 1983RESOURCE LOCATION PROTOCOLThis note describes a resource location protocol for use in the ARPAInternet. It is most useful on networks employing technologies whichsupport some method of broadcast addressing, however it may also be usedon other types of networks. For maximum benefit, all hosts whichprovide significant resources or services to other hosts on the Internetshould implement this protocol. Hosts failing to implement the ResourceLocation Protocol risk being ignored by other hosts which are attemptingto locate resources on the Internet. This RFC specifies a draftstandard for the ARPA Internet community.The Resource Location Protocol (RLP) utilizes the User Datagram Protocol(UDP) [1] which in turn calls on the Internet Protocol (IP) [3] todeliver its datagrams. SeeAppendix A and [6] for the appropriate portand protocol number assignments.Unless otherwise indicated, all numeric quantities in this document aredecimal numbers.1. IntroductionFrom time to time, Internet hosts are faced with the problem ofdetermining where on the Internet some particular network service orresource is being provided. For example, this situation will arise whena host needs to send a packet destined for some external network to agateway on its directly connected network and does not know of anygateways. In another case, a host may need to translate a domain nameto an Internet address and not know of any name servers which it can askto perform the translation. In these situations a host may use theResource Location Protocol to determine this information.In almost all cases the resource location problem is simply a matter offinding the IP address of some one (usually any) host, either on thedirectly connected network or elsewhere on the Internet, whichunderstands a given protocol. Most frequently, the querying host itselfunderstands the protocol in question. Typically (as in the case oflocating a name server), the querying host subsequently intends toemploy that protocol to communicate with the located host once itsaddress is known (e.g. to request name to address translations). Lessfrequently, the querying host itself does not necessarily understand theprotocol in question. Instead (as in the case of locating a gateway),it is simply attempting to find some other host which does (e.g. todetermine an appropriate place to forward a packet which cannot bedelivered locally).Accetta [Page 1]
RFC 887 December 1983Resource Location Protocol2. Resource NamingAlthough the resource location problem can, in most cases, be reduced tothe problem of finding a host which implements a given Internet basedprotocol, locating only a particular lowest level Internet protocol(i.e. one assigned a protocol number for transport using IP) is notcompletely sufficient. Many significant network services and resourcesare provided through higher level protocols which merely utilize thevarious lower level protocols for their own transport purposes (e.g. theFTP protocol [2] employs the TCP protocol [4] for its lower leveltransport). Conceptually, this protocol nesting may even be carried outto arbitrary levels.Consequently, the Resource Location Protocol names a resource by theprotocol number assigned to its lowest level Internet transport protocoland by a variable length protocol/resource specific identifier. Forexample, the UDP based Echo Protocol can be named by its assignedprotocol number (17) and its assigned 16-bit "well-known" port number(7). Alternatively, the Internet Control Message Protocol [5] (lackingany higher level client protocols) would be named simply by its assignedprotocol number (1) and an empty protocol specific identifier. On theother hand, some as yet undefined resource protocol (provided via sayTCP), might be named by the assigned protocol number (6), its 16-bit"well-known" TCP port number, and then some additional fixed or variablelength identifier specific to that TCP port.In general, the components of the protocol/resource specific identifierare defined to be the "natural" quantities used to successivelyde-multiplex the protocol at each next highest protocol level. Seesection 5 for some sample assignments.3. Protocol SummaryThe Resource Location Protocol is a simple request/reply procedure. Thequerying host constructs a list of resources which it would like tolocate and sends a request message on the network. A request messagemay be sent either to a particular IP address and host or, on networkswhich provide broadcast address capability, to the IP address whichrefers to all hosts on that network (see [7]). For example, a hostattempting to locate a domain name server might construct a requestcontaining the resource name [17, 53] (referring to the Domain NameServer protocol provided at "well-known" UDP port 53) and then broadcastthat request on its local network.Each receiving host examines the list of resources named in the requestpacket, determines which of the resources it provides, and returns areply message to the querying host in confirmation. The receiving hostdetermines whether or not it provides a resource by successivedecomposition of the resource name until either the name is exhausted orit encounters a component which is not supported. In the previousAccetta [Page 2]
RFC 887 December 1983Resource Location Protocolexample, each host on the network receiving the broadcast request wouldexamine the resource name by first consulting its tables to determine ifit provided UDP service. If this was successful, it would then examinethe UDP port component of the name and consult its UDP table todetermine if it provided service on UDP port 53. At this point the namewould be exhausted and if both checks were successful the host wouldreturn a reply message to the querying host indicating support for thatresource.3.1. Request MessagesRLP provides two basic types of request messages which may betransmitted by a querying host. The first type requires any hostreceiving the request message to return a reply message only if itprovides at least one of the resources named in the request list. Thesecond type requires any host receiving the message to always return areply message even if it provides none of the resources named in therequest list.These two types of request messages are:<Who-Provides?> This type requires any host receiving the message to return an appropriate reply message which names all of the resources from the request list which it provides. If the receiving host provides none of the named resources, no reply may be returned.<Do-You-Provide?> This type is identical to the <Who-Provides?> message but with the extra requirement that a reply must always be returned. When a receiving host provides none of the requested resources, it simply returns an empty reply list. This empty reply list allows the querying host to immediately detect that the confirming host provides none of the named resources without having to timeout after repeatedly retransmitting the request.The <Who-Provides?> request message is most typically used whenbroadcasting requests to an entire IP network. The <Do-You-Provide?>request message, on the other hand, is most typically used whenconfirming that a particular host does or does not provide one or morespecific resources. It may not be broadcast (since such a request wouldflood the querying host with reply messages from all hosts on thenetwork).In addition to the two basic types of request messages, an additionaltwo variant types of request messages may also be transmitted by aquerying host. These message types provide a "third-party" resourcelocation capability. They differ from the basic message types byAccetta [Page 3]
RFC 887 December 1983Resource Location Protocolproviding space for an additional qualifier with each listed resource toidentify "third-party" hosts which the confirming host believes mayprovide the resource. As before, the first type requires any hostreceiving the request message to return a reply message only if it knowsof some host which provides at least one of the resources named in therequest list. The second type requires any host receiving the messageto always return a reply message even if it knows of no hosts whichprovide any of the resources named in the request list.These two remaining types of request messages are:<Who-Anywhere-Provides?> This message parallels the <Who-Provides?> message with the "third-party" variant described above. The confirming host is required to return at least its own IP address (if it provides the named resource) as well as the IP addresses of any other hosts it believes may provide the named resource. The confirming host though, may never return an IP address for a resource which is the same as an IP address listed with the resource name in the request message. In this case it must treat the resource as if it was unsupported at that IP address and omit it from any reply list.<Does-Anyone-Provide?> This message parallels the <Do-You-Provide?> message again with the "third-party" variant described above. As before, the confirming host is required to return its own IP address as well as the IP addresses of any other hosts it believes may provide the named resource and is prohibited from returning the same IP address in the reply resource specifier as was listed in the request resource specifier. As in the <Do-You-Provide?> case and for the same reason, this message also may not be broadcast.These variant request messages permit "smart" hosts to supply resourcelocation information for networks without broadcast capability (providedthat all hosts on the network always "know" the address of one or moresuch "smart" hosts). They also permit resource location information forservices which are not provided anywhere on a directly connected networkto be provided by "smart" gateways which have perhaps queried othernetworks to which they are attached or have somehow otherwise acquiredthe information.The restriction against returning the same IP address in a reply as wasspecified in the request provides a primitive mechanism for excludingcertain known addresses from consideration in a reply (seesection 5,example 3). It may also be used to override the receiving host'spreference for its own IP address in "third-party" replies when this isrequired.Accetta [Page 4]
RFC 887 December 1983Resource Location Protocol3.2. Reply MessagesEach of the types of request messages has an associated type of replymessage. The basic reply message type is returned in response to both<Who-Provides?> and <Do-You-Provide?> request messages and suppliesinformation about the resources provided by the confirming host. Theother reply message type is the "third-party" variant returned inresponse to both <Who-Anywhere-Provides?> and <Does-Anyone-Provide?>request messages and supplies information about resources provided byhosts known to the confirming host.These two types of reply messages are:<I-Provide> This reply message contains a list of exactly those resources from the request list which the confirming host provides. These resources must occur in the reply list in precisely the same order as they were listed in the request message.<They-Provide> This reply message similarly contains a list of exactly those resources from the request list (appropriately qualified with IP addresses) which the confirming host provides or believes another host provides. These resources again must occur in the reply list in precisely the same order as they were listed in the request message.Neither type of reply message may be broadcast.A querying host which receives a <They-Provide> reply message from aconfirming host on behalf of a third host is not required tounquestioningly rely on the indirectly provided information. Thisinformation should usually be regarded simply as a hint. In most cases,the querying host should transmit a specific <Do-You-Provide?> requestto the third host and confirm that the resource is indeed provided atthat IP address before proceeding.4. Message FormatsRLP messages are encapsulated in UDP packets to take advantage of themultiplexing capability provided by the UDP source and destination portsand the extra reliability provided by the UDP checksum. Requestmessages are sent from a convenient source port on the querying host tothe assigned RLP destination port of a receiving host. Reply messagesare returned from the assigned RLP source port of the confirming host tothe appropriate destination port of the querying host as determined bythe source port in the request message.The format of the various RLP messages is described in the followingdiagrams. All numeric quantities which occupy more than one octet areAccetta [Page 5]
RFC 887 December 1983Resource Location Protocolstored in the messages from the high order octet to the low order octetas per the usual Internet protocol standard. All packet diagramsindicate the octets of the message from left to right and then top tobottom as they occur in the data portion of the encapsulating UDPpacket.Each RLP packet has the general format +--------+--------+--------+--------+ | | | | | Type | Flags | Message-ID | | | | | +--------+--------+--------+--------+ | - | Resource-List - | - +--------+--------+--------+---\\---+ - + - Resource-List | - | +--------+--------+--------+---\\---+where<Type> is a single octet which identifies the message type. The currently defined types are: 0 <Who-Provides?> 1 <Do-You-Provide?> 2 <Who-Anywhere-Provides?> 3 <Does-Anyone-Provide?> 4 <I-Provide> 5 <They-Provide> 6-255 Reserved.Accetta [Page 6]
RFC 887 December 1983Resource Location Protocol<Flags> is a single octet specifying possible modifications to the standard interpretation of <Type>. Bits in this field are numbered from left to right (from most significant to least significant) beginning with bit 1. The currently defined flag bits are: Bit 1 <Local-Only>. Requires that any reply message generated in response to a request message with this flag bit set may only name IP addresses which are on the same IP network as the sender of the request message. This flag also requires that multi-homed hosts answering broadcast <Who-Provides?> requests use the appropriate local network IP source address in the returned reply. This bit must be zero in reply messages. Bits 2-8 Reserved. Must be zero.<Message-ID> is a two octet (16-bit) value which identifies the request message. It is used simply to aid in matching requests with replies. The sending host should initialize this field to some convenient value when constructing a request message. The receiving host must return this same value in the <Message-ID> field of any reply message generated in response to that request.<Resource-List> is the list of resources being queried or for which location information is being supplied. This list is a sequence of octets beginning at the octet following the <Message-ID> and extending through the end of the UDP packet. The format of this field is explained more fully in the following section. The size of this list is implicitly specified by the length of the encapsulating UDP datagram.4.1. Resource ListsA <Resource-List> consists of zero or more resource specifiers. Eachresource specifier is simply a sequence of octets. All resourcespecifiers have a common resource name initial format +--------+--------+--------+---\\---+ | | | | |Protocol|IDLength| Resource-ID | | | | | +--------+--------+--------+---\\---+whereAccetta [Page 7]
RFC 887 December 1983Resource Location Protocol<Protocol> is the protocol number assigned to the lowest level Internet protocol utilized for accessing the resource.<IDLength> is the length of the resource identifier associated with this <Protocol>. This length may be a fixed or variable value depending on the particular resource. It is included so that specifiers which refer to resources which a host may not provide can be skipped over without needing to know the specific structure of the particular resource identifier. If the <Protocol> has no associated natural identifier, this length is 0.<Resource-ID> is the qualifying identifier used to further refine the resource being queried. If the <IDLength> field was 0, then this field is empty and occupies no space in the resource specifier.In addition, resource specifiers in all <Who-Anywhere-Provides?>,<Does-Anyone-Provide?> and <They-Provide> messages also contain anadditional qualifier following the <Protocol-ID>. This qualifier hasthe format +--------+--------+--------+--------+---//---+ | | | |IPLength| IP-Address-List | | | | +--------+--------+--------+--------+---//---+whereAccetta [Page 8]
RFC 887 December 1983Resource Location Protocol<IPLength> is the number of IP addresses containing in the following <IP-Address-List> (the <IP-Address-List> field thus occupies the last 4*<IPLength> octets in its resource specifier). In request messages, this is the maximum number of qualifying addresses which may be included in the corresponding reply resource specifier. Although not particularly useful, it may be 0 and in that case provides no space for qualifying the resource name with IP addresses in the returned specifier. In reply messages, this is the number of qualifying addresses known to provide the resource. It may not exceed the number specified in the corresponding request specifier. This field may not be 0 in a reply message unless it was supplied as 0 in the request message and the confirming host would have returned one or more IP addresses had any space been provided.<IP-Address-List> is a list of four-octet IP addresses used to qualify the resource specifier with respect to those particular addresses. In reply messages, these are the IP addresses of the confirming host (when appropriate) and the addresses of any other hosts known to provide that resource (subject to the list length limitations). In request messages, these are the IP addresses of hosts for which resource information may not be returned. In such messages, these addresses should normally be initialized to some "harmless" value (such as the address of the querying host) unless it is intended to specifically exclude the supplied addresses from consideration in any reply messages.The receiving host determines if it provides any of the resources namedin the request list by successively decomposing each resource name. Thefirst level of decomposition is the Internet protocol number which canpresumably be looked up in a table to determine if that protocol issupported on the host. Subsequent decompositions are based on previouscomponents until one of three events occur: 1. the current component identifies some aspect of the previous components which the host does not support, 2. the resource name from the request list is exhausted, or 3. the resource name from the request list is not exhausted but the host does not expect any further components in the name given the previous componentsIn case 1, the receiving host has determined that it does not providethe named resource. The resource specifier may not be included in anyreply message returned.In case 2, the receiving host has determined that it does indeed providethe named resource (note: this may occur even if the receiving hostAccetta [Page 9]
RFC 887 December 1983Resource Location Protocolwould have expected the resource name to contain more components thanwere actually present). The resource specifier must be included (moduloIP address prohibitions) in any reply message returned.In case 3, the receiving host has determined that it does not completelyprovide the named resource since name components remain which it doesnot understand (this might occur with specializations of or extensionsto a known protocol which are not universally recognized). The resourcespecifier may not be included in any reply message returned.5. Sample UsageThe following scenarios illustrate some typical uses of RLP. In allcases the indicated messages are encapsulated in a UDP datagram with theappropriate source and destination port numbers, message length, andchecksum. This datagram is further encapsulated in an IP datagram withthe appropriate source address of the sending host and destinationaddress (either broadcast or individual) for the receiving host.All numeric protocol examples are as specified in the appropriateprotocol description documents listed in the references. 1. Suppose a freshly rebooted host H wishes to find some gateway on its directly connected network to which it can send its first external packet. It then broadcasts the request <Who-Provides?> <Flags>=<Local-Only> <Message-ID>=12345 <Resource-List>={[GGP], [EGP]} encoded as the 8 octet message +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 128 | 12345 | 3 | 0 | 8 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ on its local network. - Gateway G1 (which understands EGP) receives the request and returns the reply <I-Provide> <Flags>=none <Message-ID>=12345 <Resource-List>={[EGP]} encoded as the 6 octet message +-----+-----+-----+-----+-----+-----+ | 4 | 0 | 12345 | 8 | 0 | +-----+-----+-----+-----+-----+-----+ to host H which then remembers that gateway G1 may be usedAccetta [Page 10]
RFC 887 December 1983Resource Location Protocol to route traffic to the rest of the Internet. - At the same time, gateway G2 (which understands both GGP and EGP) might also receive the request and return the reply <I-Provide> <Flags>=none <Message-ID>=12345 <Resource-List>={[GGP], [EGP]} encoded as the 8 octet message +-----+-----+-----+-----+-----+-----+-----+-----+ | 4 | 0 | 12345 | 3 | 0 | 8 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ to host H which might then also add gateway G2 to its list if it chooses. 2. Assume instead that host H is a stand-alone system which has just encountered some fatal software error and wishes to locate a crash dump server to save its state before reloading. Suppose that the crash dump protocol on the host's local network is implemented using the Trivial File Transfer Protocol (TFTP) [8]. Furthermore, suppose that the special file name "CRASH-DUMP" is used to indicate crash dump processing (e.g. the server might locally generate a unique file name to hold each dump that it receives from a host). Then host H might broadcast the request <Who-Provides?> <Flags>=none <Message-ID>=54321 <Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]} encoded as the 21 octet message +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 0 | 54321 | 17 | 15 | 69 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 2 | 'C' 'R' 'A' 'S' 'H' '-' | +-----+-----+-----+-----+-----+-----+-----+-----+ | 'D' 'U' 'M' 'P' 0 | +-----+-----+-----+-----+-----+ to its local network (note that the file name component is explicitly terminated by a null so as not to exclude future further specialization of the crash dump protocol). - Host C (which supports this specialization of the TFTP protocol) receives the request and returns the reply <I-Provide> <Flags>=none <Message-ID>=54321 <Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]}Accetta [Page 11]
RFC 887 December 1983Resource Location Protocol encoded as the 21 octet message +-----+-----+-----+-----+-----+-----+-----+-----+ | 4 | 0 | 54321 | 17 | 15 | 69 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 2 | 'C' 'R' 'A' 'S' 'H' '-' | +-----+-----+-----+-----+-----+-----+-----+-----+ | 'D' 'U' 'M' 'P' 0 | +-----+-----+-----+-----+-----+ to host H which may then proceed to send its crash dump to host C and reload. - Host D (which provides TFTP service but not the crash dump specialization), however, might receive the request and determine that it provides no support for the resource (since the resource name contains components following the UDP port number which it does not understand). It would therefore return no reply to host H. 3. Finally, suppose host M wishes to locate some domain name translation server (either UDP or TCP based) anywhere on the Internet. Furthermore, suppose that host M is on a IP network which does not provide broadcast address capabilities and that host R is a "known" resource location server for that network. First, since host M prefers to find a domain name server on its own locally connected network if possible, it sends the request <Does-Anyone-Provide?> <Flags>=<Local-Only> <Message-ID>=12321 <Resource-List>= {[TCP, <DOMAIN-NAME-SERVER-PORT>] {M}, [UDP, <DOMAIN-NAME-SERVER-PORT>] {M}} encoded as the 22 octet message +-----+-----+-----+-----+ | 3 | 128 | 12321 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 6 | 2 | 53 | 1 | M | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 17 | 2 | 53 | 1 | M | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ to host R. Host R receives the request and consults its tables for any hosts known to support either variety of domain name service. It finds entries indicating that both hosts S and T provide UDPAccetta [Page 12]
RFC 887 December 1983Resource Location Protocol based domain name service but that neither host is on the same IP network as host H. It must then send the negative confirmation reply <They-Provide> <Flags>=none <Message-ID>=12321 <Resource-List>={} encoded as the 4 octet message +-----+-----+-----+-----+ | 5 | 0 | 12321 | +-----+-----+-----+-----+ back to host M. Host M, receiving this reply, might now abandon any hope of finding a server on its own network, reformat its request to permit any host address, and resend <Does-Anyone-Provide?> <Flags>=none <Message-ID>=12322 <Resource-List>= {[TCP, <DOMAIN-NAME-SERVER-PORT>] {M}, [UDP, <DOMAIN-NAME-SERVER-PORT>] {M}} encoded as the 22 octet message +-----+-----+-----+-----+ | 3 | 0 | 12322 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 6 | 2 | 53 | 1 | M | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 17 | 2 | 53 | 1 | M | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ again to host R. Host R receives this new request and is no longer constrained to return only local addresses. However, since only space for a single qualifying IP address was provided in each request resource specifier, it may not immediately return both addresses. Instead, it is forced to return only the first address and replies <They-Provide> <Flags>=none <Message-ID>=12322 <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>] {S}} encoded as the 13 octet messageAccetta [Page 13]
RFC 887 December 1983Resource Location Protocol +-----+-----+-----+-----+-----+-----+-----+-----+ | 5 | 0 | 12322 | 17 | 2 | 53 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 1 | S | +-----+-----+-----+-----+-----+ to Host M. Host M receives the reply and (being the suspicious sort) decides to confirm it with host S. It then sends <Do-You-Provide?> <Flags>=none <Message-ID>=12323 <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>]} encoded as the 8 octet message +-----+-----+-----+-----+-----+-----+-----+-----+ | 1 | 0 | 12323 | 17 | 2 | 53 | +-----+-----+-----+-----+-----+-----+-----+-----+ to host S and receives back from host S the reply <I-Provide> <Flags>=none <Message-ID>=12323 <Resource-List>={} encoded as the 4 octet message +-----+-----+-----+-----+ | 4 | 0 | 12323 | +-----+-----+-----+-----+ denying any support for UDP based domain name service. In desperation host M again queries host R, this time excluding host S from consideration, and sends the request <Does-Anyone-Provide?> <Flags>=none <Message-ID>=12324 <Resource-List>= {[TCP, <DOMAIN-NAME-SERVER-PORT>] {S}, [UDP, <DOMAIN-NAME-SERVER-PORT>] {S}} encoded as the 22 octet message +-----+-----+-----+-----+ | 3 | 0 | 12324 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 6 | 2 | 53 | 1 | S | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 17 | 2 | 53 | 1 | S | +-----+-----+-----+-----+-----+-----+-----+-----+-----+Accetta [Page 14]
RFC 887 December 1983Resource Location Protocol and this time receives the reply <They-Provide> <Flags>=none <Message-ID>=12324 <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>] {T}} encoded as the 13 octet message +-----+-----+-----+-----+-----+-----+-----+-----+ | 5 | 0 | 12324 | 17 | 2 | 53 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 1 | T | +-----+-----+-----+-----+-----+ from host R which of course host M again insists on confirming by sending the request <Do-You-Provide?> <Flags>=none <Message-ID>=12325 <Resource-List>= {[UDP, <DOMAIN-NAME-SERVER-PORT>]} encoded as the 8 octet message +-----+-----+-----+-----+-----+-----+-----+-----+ | 1 | 0 | 12325 | 17 | 2 | 53 | +-----+-----+-----+-----+-----+-----+-----+-----+ to host T and finally receives confirmation from host T with the reply <I-Provide> <Flags>=none <Message-ID>=12325 <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>]} encoded as the 8 octet message +-----+-----+-----+-----+-----+-----+-----+-----+ | 4 | 0 | 12325 | 17 | 2 | 53 | +-----+-----+-----+-----+-----+-----+-----+-----+ that it indeed provides domain name translation service at UDP port 53.A. Assigned NumbersThe "well-known" UDP port number for the Resource Location Protocol is39 (47 octal).Accetta [Page 15]
RFC 887 December 1983Resource Location Protocol REFERENCES[1] Postel, J. User Datagram Protocol.RFC 768, USC/Information Sciences Institute, August, 1980.[2] Postel, J. File Transfer Protocol.RFC 765, USC/Information Sciences Institute, June, 1980.[3] Postel, J. Internet Protocol - DARPA Internet Program Protocol Specification.RFC 791, USC/Information Sciences Institute, September, 1981.[4] Postel, J. Transmission Control Protocol- DARPA Internet Program Protocol Specification.RFC 793, USC/Information Sciences Institute, September, 1981.[5] Postel, J. Internet Control Message Protocol - DARPA Internet Program Protocol Specification.RFC 792, USC/Information Sciences Institute, September, 1981.[6] Reynolds, J., and J. Postel. Assigned Numbers.RFC 870, USC/Information Sciences Institute, October, 1983.[7] Gurwitz, R., and R. Hinden. IP - Local Area Network Addressing Issues. IEN 212, Bolt Beranek and Newman, September, 1982.[8] Sollins, K. The TFTP Protocol (revision 2).RFC 783, MIT/Laboratory for Computer Science, June, 1981.Accetta [Page 16]
[8]ページ先頭