ICMP type 18, Address mask reply |
Description | Glossary | RFCs | Publications | Obsolete RFCs |
Protocol suite: | TCP/IP. |
Protocol type: | Transport layer control protocol. |
Base protocol: | ICMP, Internet Control Message Protocol. |
Related ICMP message: | Address mask request. |
Host implementation: | Optional. |
Router implementation: | Mandatory. |
Links: | IANA: ICMP parameters. |
The ICMP Address reply message is generated in response to an ICMP Address mask request message.
The address mask reply may be received from a gateway, or a host acting in lieu of a gateway.
RFC 950, page 11:
A gateway receiving an address mask request should return it with the address mask field set to the 32-bit mask of the bits identifying the subnet and network, for the subnet on which the request was received.
If the requesting host does not know its own IP address, it may leave the source field zero; the reply should then be broadcast. However, this approach should be avoided if at all possible, since it increases the superfluous broadcast load on the network. Even when the replies are broadcast, since there is only one possible address mask for a subnet, there is no need to match requests with replies. The "Identifier" and "Sequence Number" fields can be ignored.
Host Implementation:
RFC 1122, pages 45 and 46:
A host MUST support the first, and MAY implement all three, of the following methods for determining the address mask(s) corresponding to its IP address(es): (1) static configuration information; (2) obtaining the address mask(s) dynamically as a side-effect of the system initialization process; and (3) sending ICMP Address Mask Request(s) and receiving ICMP Address Mask Reply(s).
The choice of method to be used in a particular host MUST be configurable.
When method (3), the use of Address Mask messages, is enabled, then: (a) When it initializes, the host MUST broadcast an Address Mask Request message on the connected network corresponding to the IP address. It MUST retransmit this message a small number of times if it does not receive an immediate Address Mask Reply. (b) Until it has received an Address Mask Reply, the host SHOULD assume a mask appropriate for the address class of the IP address, i.e., assume that the connected network is not subnetted. (c) The first Address Mask Reply message received MUST be used to set the address mask corresponding to the particular local IP address. This is true even if the first Address Mask Reply message is "unsolicited", in which case it will have been broadcast and may arrive after the host has ceased to retransmit Address Mask Requests. Once the mask has been set by an Address Mask Reply, later Address Mask Reply messages MUST be (silently) ignored.
Conversely, if Address Mask messages are disabled, then no ICMP Address Mask Requests will be sent, and any ICMP Address Mask Replies received for that local IP address MUST be (silently) ignored.
A host SHOULD make some reasonableness check on any address mask it installs.
A system MUST NOT send an Address Mask Reply unless it is an authoritative agent for address masks. An authoritative agent may be a host or a gateway, but it MUST be explicitly configured as a address mask agent. Receiving an address mask via an Address Mask Reply does not give the receiver authority and MUST NOT be used as the basis for issuing Address Mask Replies.
If it is configured as an agent, the host MUST broadcast an Address Mask Reply for the mask on the appropriate interface when it initializes.
Router Implementation:
RFC 1812, pages 61 and 62:
A router SHOULD examine all ICMP Address Mask Replies that it receives to determine whether the information it contains matches the router's knowledge of the address mask. If the ICMP Address Mask Reply appears to be in error, the router SHOULD log the address mask and the sender's IP address. A router MUST NOT use the contents of an ICMP Address Mask Reply to determine the correct address mask.
Because hosts may not be able to learn the address mask if a router is down when the host boots up, a router MAY broadcast a gratuitous ICMP Address Mask Reply on each of its logical interfaces after it has configured its own address masks. However, this feature can be dangerous in environments that use variable length address masks. Therefore, if this feature is implemented, gratuitous Address Mask Replies MUST NOT be broadcast over any logical interface(s) which either:
- Are not configured to send gratuitous Address Mask Replies. Each logical interface MUST have a configuration parameter controlling this, and that parameter MUST default to not sending the gratuitous Address Mask Replies.
- Share subsuming (but not identical) network prefixes and physical interface.
The { <Network-prefix>, -1 } form of the IP broadcast address MUST be used for broadcast Address Mask Replies.
The ability to disable sending Address Mask Replies by routers is required at a few sites that intentionally lie to their hosts about the address mask. The need for this is expected to go away as more and more hosts become compliant with the Host Requirements standards.
The reason for both the second bullet above and the requirement about which IP broadcast address to use is to prevent problems when multiple IP network prefixes are in use on the same physical network.
MAC header | IP header | ICMP message 18 |
Message format:
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Type | Code | ICMP header checksum | |||||||||||||||||||||||||||||
Identifier | Sequence number | ||||||||||||||||||||||||||||||
Address mask. |
Type. 8 bits. Set to 18.
Code. 8 bits. Cleared to 0.
ICMP Header Checksum.
16 bits.
The 16-bit one's complement of the one's complement sum of the ICMP message, starting with
the ICMP Type field. When the checksum is computed, the checksum field should first be set
to 0. When the data packet is transmitted, the checksum is computed and inserted into this
field. When the data packet is received, the checksum is again computed and verified against the checksum field.
If the two checksums do not match then an error has occurred.
Identifier.
16 bits.
The identifier is used to help match the request to the associated reply. It may be set to zero.
Sequence number.
16 bits.
The sequence number is used to help match the request to the associated reply. It may be set to zero.
Address mask.
32 bits.
The subnet mask of the requesting host.
RFCs:
[RFC 950] IP Subnet Extension.
[RFC 1122] Requirements for Internet Hosts -- Communication Layers.
[RFC 1812] Requirements for IP Version 4 Routers.
[RFC 1009] Requirements for Internet Gateways.
[RFC 1716] Towards Requirements for IP Routers.
Description | Glossary | RFCs | Publications | Obsolete RFCs |