IPv4 Automatic Addressing

[#icmprtds]: ICMP Router Discovery Messages
Overview
Introduction

(For information about using this sort of technology with IPv6, see the “Relevance” section below for references. Most of this section is focused on implementing this method using IPv4.)

One method to perform automatic addressing is by using ICMP router discovery messages. Some of these ICMP router discovery messages messages are called “router advertisements” while other messages are called “router solicitations”.

Relevance

Another method, using DHCP, has been used substantially more for automatic IPv4 addressing. Using ICMP router discovery messages is noted by RFC 1256: ICMP Router Discovery Messages. This RFC 1256 predates, by more than two years, even the old RFC 1531 (“Dynamic Host Configuration Protocol”) (which has been obsoleted by newer DHCP RFC documents at least twice).

These facts do not seem to instantly suggest a super-bright future for IPv4 ICMP router discovery messages. IPv4 ICMP router discovery messages may seem to be an ignored method. However, there is one consideration that may cause an increased use in IPv4 ICMP router discovery messages.

Using IPv4 ICMP router discovery messages is a technique that is substantially more similar to the recommended IPv6 technologies of NDP (IPv6) and SLAAC. SLAAC uses NDP and NDP is basically all about using ICMPv6's router discovery messages (which are called “router advertisements” and “router solicitations”). Since this technology is being promoted as a recommended way to use automatic IPv6 address assignment, it seems possible that people will become more familiar with using ICMPv4's router discovery messages that are called “router advertisements” and “router solicitations”.

[#icmprdmt]: Brief blurb about ICMP

The ICMP protocol may be most well known for the “Echo Request” messages used by the ping command, and the types of ICMP messages which are typically sent in response to message type called “Echo Request”. However, ICMP does have other message types.

Firewalls might block ICMP messages that are not using specific and pre-approved message types. Therefore, it is possible that the ICMP messages used by the ping command may be allowed, but other ICMP messages, including the ICMP messages used for router discovery messages, may be prohibited. Any decent firewall should permit a method of allowing the traffic that will allow ICMP router discovery messages to work. (What may be a bit trickier is figuring out how to allow the desired ICMP messages messages while denying other types of traffic.)

Details about using ICMP/IPv4 Router Discovery Messages

(This section may benefit by additional research/implementation/testing/elaborating.)

The IPv4 version of this is documented by RFC 1256: ICMP Router Discovery Messages.

Technet: ICMP Router Discovery notes, “TCP/IP for Windows 2000 and Windows 98 supports the use of Router Solicitation messages to discover the default gateway.” However, this sort of method was not widely deployed during most of IPv4's widespread prominence. Therefore, other platforms (such as items sold as part of the “embedded device” market, such as a mobile phone) might be less likely to support this than DHCP.

Using DHCP, insetad of ICMP/IPv4 Router Discovery Messages, may be worthwhile for two main reasons: Maximum compatibility with various devices that use IPv4, and familiarity by technicians familiar with IPv4. However, hopefully that latter reason will become less important as more people with IPv4 experience also gain experience with IPv6. Those who are in a more controlled environment, such as a classroom, may benefit by starting out with ICMP/IPv4 Router Discovery Messages, with the idea being that the transition with additional learning, about IPv6, may go more smoothly.

At the time of this writing, this guide has little/no further details about using ICMP Router Discovery Messages over IPv4.

[#dhcp]: Dynamic Host Control Protocol (“DCHP”)

DHCP quickly became popular around the middle of the last decade of the twentieth century, and became the most commonly supported/used method of automatic assigning IPv4 addresses. Perhaps due to pre-existing infrastructure and trusted experience, it remained popular past the first decade of the twenty-first century. Perhaps another reason there was no change to the other IPv4 automatic addressing methods is because people simply planned to use the familiar, working IPv4 technologies until they started to deploy IPv6 technologies.

[#bootp]: Bootstrap Protocol (BOOTP)

This protocol is really historical: the newer DHCP/IPv4 became much more popular.

RFC 951: Bootstrap Protocol (BOOTP). This protocol has similarities to DHCP. Perhaps the main reason that BOOTP has been supported to the extent that it has, is because supporting BOOTP is rather trivial for software that supports DHCP. (This compatability is compatibility is clearly documented: RFC 2131 (DHCP/IPv4) notes, “DHCP captures the behavior of BOOTP relay agents” and “DHCP participants can interoperate with BOOTP participants”. Additional resources may include RFC 1534: Interoperation Between DHCP and BOOTP.) (Just because software may support BOOTP does not mean that BOOTP continued to actually see any real widespread usage.)

BOOTP was the direct predecessor to DHCP and is fairly similar. It allows a client to automatically obtain its network settings, allowing for address configuration to be centrally managed from the server of this automatic addressing service. However, it might be true that common implementations may not support as many features such as easy server configuration by using a pool of addresses, and setting a default gateway. The protocols are also a bit different: BOOTP did not support the concept of a “lease”. (A DHCP lease time-limits the settings that are provided to a client. Once an expiration time is reached, the settings are invalid.) Also, DHCP provides support for transmitting additional settings, such as an IPv4 address to be used as a “default gateway”. BOOTP is an older, simpler protocol that lacks these features.

[#btpprtnm]: UDP (and TCP) ports named after BOOTP

IANA's Service Name and Transport Protocol Port Number Registry uses the “Service Name” of “bootps” for port 67 (for both UDP and TCP). This service name of “bootps”, which stands for BOOTP/Bootstrap Protocol Server.

IANA's Service Name and Transport Protocol Port Number Registry uses the “Service Name” of “bootps” for port 68 (for both UDP and TCP). This service name of “bootpc”, which stands for BOOTP/Bootstrap Protocol Client.

These service names may also be seen in the /etc/services file, as many systems using Unix and similar systems will have that file contain an abbreviated version of the information from IANA.)

[#bootprly]: BOOTP relay
Software implementing relay services for BOOTP traffic may also be able to handle DHCP traffic, and such software may be named after the DHCP functionality. Therefore, information about such software is included in the section about DHCP relay. See that section for details about software that relays BOOTP traffic.
[#rarp]: Reverse ARP (“RARP”) (Historical)

Be careful not to confuse this with Inverse ARP (InARP). RARP was essentially a predecessor to BOOTP.

The purpose of RARP, like BOOTP and DHCP, is for a computer to be able to obtain its own IPv4 address. In contrast, RFC 2390: Inverse ARP (“InARP”) is about a (functional) computer obtaining the IPv4 address of a different device. The concepts may be a bit similar, but are not absolutely identical, and these are different protocols.

This protocol is really very historical: the newer DHCP/IPv4 became much more popular than BOOTP which was effectively able to replace the functionality of RARP. IETF STD 38: Reverse Address Resolution Protocol (“RARP”) has referred to RFC 903: “A Reverse Address Resolution Protocol (“RARP”). With no development anticipated, IETF STD 38 will likely continue to point at that same old RFC from June of 1984 A.D.

RFC 1931: “Dynamic RARP” (“DRARP”)

[#ip4lnklc]: Using IPv4 link-local (“IPv4LL”) addresses

(This text recognizes that this section may benefit from some re-organization and/or additional research/implementation/elaboration of documentation.)

See: IPv4 link-local addresses. (Some of the following text may be getting merged onto that page.)

Perhaps see: Wikipedia's page on Zero configuration networking: section on Link-local IPv4 addresses. If there is an interest in using these non-routable addresses, perhaps see: LLMNR which implements name resolution by relying on multicast instead of routing.

Link local is not recommended for general use due to routing issues. DHCP can be used instead for offline networks, and also works with online networks (even with RFC 1918 private addresses which can be used for systems that use NAT for an Internet connection). However, DHCP does require a server that requires some configuration, making the autoconfigurable Link-Local easier to implement in some cases where the cost of offline-use-only isn't incentive enough to perform manual configuration (of a DHCP server or static addresses).

From RFC 3927: “Dynamic Configuration of IPv4 Link-Local Addresses”: "The IPv4 prefix 169.254/16 is registered with the IANA for this purpose. Allocation of IPv6 Link-Local addresses is described in" RFC 2462: IPv6 Stateless Address Autoconfiguration. (Hyperlinks were added to quoted text.)

Synonymous to this, or related to this (technologies that use Link Local addresses), are: Automatic Private IP Addressing (APIPA), and Internet Protocol Automatic Configuration (IPAC). Networks with link local addresses are generally segmented from other networks, so they are unable to communicate with other addresses (until different IP addresses are given). This is due in part to the fact that RFC 3927 "does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface." (This is discussed in section 1.4 of RFC 3927.) The other factor, implied by the previous statement (identifying Link-Local addresses and separately identifying routable addresses), is "IPv4 Link-Local addresses are not routable" (according to section 1.6 of RFC 3927). This means that if one machine is connected to the Internet, other machines on the link local network won't have that information, and therefore they won't know to send the Internet traffic to that machine. Also, a machine that is on the link local network isn't likely to be receiving packets that are from other networks and destined to a link local network. section 1.6 of RFC 3927 says that addresses of these types should not be assigned by a DHCP server. (The RFC also says such addresses should not be assigned manually. However, there are occasions where such manual assignments may be convenient to enable communication with a device that has an address in that range. Leaving such a manual assignment active, though, would result in long-term violation of the directions of this RFC, and so allowing any such manual assignment to remain long term is not recommended.)

RFC 3330 indicates the 169.254/16 addresses are reserved for use on a Link Local network. So does RFC 3927 which cites IANA's reservation of these addresses. To summarize, addresses are randomly selected from 169.254.1/24 through 169.254.254/24 (but not 169.254.0/24, nor 169.254.255/24), and there are checks in place to deal with conflicts if two devices try to use the same address.

Zero Configuration Networking
Microsoft's “Automatic Private IP Addressing” (“APIPA”)
Microsoft's “Internet Protocol Automatic Configuration” (“IPAC”)
Using ICMP

RFC 1122 page 43, in section 3.2.2.7 of the document, says “A host SHOULD NOT implement these messages.” The reason is simply that there are newer alternatives. MS KB 170292 states, “This method is obsolete and is no longer used.”

RFC 1122 page 45 starts with the top of section 3.2.2.9, which indicates that subnet masks delivered by ICMP messages “MUST” be supported. This does not seem to be widely known, and is not widely implemented.