|
Network Working Group Request for Comments: 887 |
M. Accetta Carnegie-Mellon University December 1983 |
<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.
<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.
<Who-Provides?> and <Do-You-Provide?> request messages and supplies
<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.
+--------+--------+--------+--------+
| | | |
| Type | Flags | Message-ID |
| | | |
+--------+--------+--------+--------+
| -
| Resource-List -
| -
+--------+--------+--------+---\\---+
- +
- Resource-List |
- |
+--------+--------+--------+---\\---+
<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.
<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.
+--------+--------+--------+---\\---+
| | | |
|Protocol|IDLength| Resource-ID |
| | | |
+--------+--------+--------+---\\---+
<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.
<Does-Anyone-Provide?> and <They-Provide> messages also contain an
+--------+--------+--------+--------+---//---+
| | |
|IPLength| IP-Address-List |
| | |
+--------+--------+--------+--------+---//---+
<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.
<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 used
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.
<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"]}
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.
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 UDP
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 message
+-----+-----+-----+-----+-----+-----+-----+-----+
| 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 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
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.
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.