📄 rfc917.txt
字号:
request message is zero, then the destination address for the reply message should denote a broadcast. ICMP Fields: Type A1 for address format request message A2 for address format reply message Code 0 for address format request message Width of subnet field, in bits, for address format reply message Checksum The checksum is the 16-bit one's complement of the one'sMogul [Page 17]RFC 917 October 1984Internet Subnets complement sum of the ICMP message starting with the ICMP Type. For computing the checksum, the checksum field should be zero. This checksum may be replaced in the future. Identifier An identifier to aid in matching request and replies, may be zero. Sequence Number A sequence number to aid in matching request and replies, may be zero. Description A gateway receiving an address format request should return it with the Code field set to the number of bits of Subnet number in IP addresses for the network to which the datagram was addressed. If the request was broadcast, the destination network is "this network". The Subnet field width may be from 0 to (31 - N), where N is the width in bits of the IP net number field (i.e., 8, 16, or 24). If the requesting host does not know its own IP address, it may leave the source field zero; the reply should then be broadcast. Since there is only one possible address format for a network, there is no need to match requests with replies. However, this approach should be avoided if at all possible, since it increases the superfluous broadcast load on the network. Type A1 may be received from a gateway or a host. Type A2 may be received from a gateway, or a host acting in lieu of a gateway.Mogul [Page 18]RFC 917 October 1984Internet SubnetsII. Examples For these examples, we assume that the requesting host has address 36.40.0.123, that there is a gateway at 36.40.0.62, and that on network 36.0.0.0, an 8-bit wide subnet field is in use. First, suppose that broadcasting is allowed, and that 36.40.0.123 knows its own address. It sends the following datagram: Source address: 36.40.0.123 Destination address: 36.255.255.255 Protocol: ICMP = 1 Type: Address Format Request = A1 Code: 0 36.40.0.62 will hear the datagram, and should respond with this datagram: Source address: 36.40.0.62 Destination address: 36.40.0.123 Protocol: ICMP = 1 Type: Address Format Reply = A2 Code: 8 For the following examples, assume that address 255.255.255.255 denotes "broadcast to this physical network", as described in [6]. The previous example is inefficient, because it potentially broadcasts the request on many subnets. The most efficient method, and the one we recommend, is for a host to first discover its own address (perhaps using the "Reverse ARP" protocol described in [4]), and then to send the ICMP request to 255.255.255.255: Source address: 36.40.0.123 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Format Request = A1 Code: 0 The gateway can then respond directly to the requesting host. Suppose that 36.40.0.123 is a diskless workstation, and does not know even its own host number. It could send the following datagram:Mogul [Page 19]RFC 917 October 1984Internet Subnets Source address: 0.0.0.0 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Format Request = A1 Code: 0 36.40.0.62 will hear the datagram, and should respond with this datagram: Source address: 36.40.0.62 Destination address: 36.40.255.255 Protocol: ICMP = 1 Type: Address Format Reply = A2 Code: 8 Note that the gateway uses the narrowest possible broadcast to reply (i.e., sending the reply to 36.255.255.255 would mean that it is transmitted on many subnets, not just the one on which it is needed.) Even so, the overuse of broadcasts presents an unnecessary load to all hosts on the subnet, and so we recommend that use of the "anonymous" (0.0.0.0) source address be kept to a minimum. If broadcasting is not allowed, we assume that hosts have wired-in information about neighbor gateways; thus, 36.40.0.123 might send this datagram: Source address: 36.40.0.123 Destination address: 36.40.0.62 Protocol: ICMP = 1 Type: Address Format Request = A1 Code: 0 36.40.0.62 should respond exactly as in the previous case.Mogul [Page 20]RFC 917 October 1984Internet SubnetsNotes <1> For example, some host have addresses assigned by concatenating their Class A network number with the low-order 24 bits of a 48-bit Ethernet hardware address. <2> Our discussion of Internet broadcasting is based on [6]. <3> If broadcasting is not supported, them presumably a host "knows" the address of a neighbor gateway, and should send the ICMP to that gateway. <4> This is what was referred to earlier as the coexistence of transparent and explicit subnets on a single network.Mogul [Page 21]RFC 917 October 1984Internet SubnetsReferences 1. D.R. Boggs, J.F. Shoch, E.A. Taft, and R.M. Metcalfe. "Pup: An Internetwork Architecture." IEEE Transactions on Communications COM-28, 4, pp612-624, April 1980. 2. David D. Clark. Names, Addresses, Ports, and Routes. RFC-814, MIT-LCS, July 1982. 3. Yogan K. Dalal and Robert M. Metcalfe. "Reverse Path Forwarding of Broadcast Packets." Comm. ACM 21, 12, pp1040-1048, December 1978. 4. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A Reverse Address Resolution Protocol. RFC-903, Stanford University, June 1984. 5. R.M. Metcalfe and D.R. Boggs. "Ethernet: Distributed Packet Switching for Local Computer Networks." Comm. ACM 19, 7, pp395-404, July 1976. Also CSL-75-7, Xerox Palo Alto Research Center, reprinted in CSL-80-2. 6. Jeffrey Mogul. Broadcasting Internet Datagrams. RFC-919, Stanford University, October 1984. 7. David Plummer. An Ethernet Address Resolution Protocol. RFC-826, Symbolics, September 1982. 8. Jon Postel. Internet Protocol. RFC-791, USC-ISI, September 1981. 9. Jon Postel. Internet Control Message Protocol. RFC-792, USC-ISI, September 1981.Mogul [Page 22]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -