RFC 1256

ICMP Router Discovery Messages

📅 published September 1991, from ietf

RFC 1256: ICMP Router Discovery Messages 🎀

okay bestie, RFC 1256 is literally about how hosts find their routers 🫶 It was written by S. Deering as Editor, from Xerox PARC, and it's dated September 1991. The header marks it as an IAB standards track protocol. It's a product of the IETF Router Discovery Working Group, which is why it's sitting under the Network Working Group banner. Distribution is unlimited, so everyone gets to read it 💖 The header doesn't list anything it obsoletes or updates, so no drama there ✨

Status of this Memo 💅

This RFC specifies an IAB standards track protocol for the Internet community, and it's basically asking for discussion and suggestions for improvements 💌 For the standardization state and status, check the current edition of the "IAB Official Protocol Standards" 📚 It's from the IETF Router Discovery Working Group, and distribution is unlimited 🦋

Abstract 🌸

So this doc extends ICMP (the Internet Control Message Protocol) so that hosts on multicast or broadcast networks can discover the IP addresses of their neighboring routers. Main character energy 👑

Table of Contents 📖

   1. Terminology                                                      1
   2. Protocol Overview                                                3
   3. Message Formats                                                  5
   4. Router Specification                                             7
        4.1. Router Configuration Variables                            7
        4.2. Message Validation by Routers                             9
        4.3. Router Behavior                                           9
   5. Host Specification                                              12
        5.1. Host Configuration Variables                             12
        5.2. Message Validation by Hosts                              13
        5.3. Host Behavior                                            14
   6. Protocol Constants                                              17
   7. Security Considerations                                         17
   References                                                         18
   Author's Address                                                   19

1. Terminology 🧚

okay so these words have a very specific meaning in this doc, so let's lock them in 🔒

  • system: a device that implements the Internet Protocol, IP [9] 💻
  • router: a system that forwards IP datagrams, as specified in [2] 🔀 It doesn't count if the system can forward but has that turned off. It also doesn't count if it only forwards as much as it needs to in order to obey IP Source Route options. Not me being picky, just precise 🙈
  • host: any system that is not a router 🍓
  • multicast: unless it's specifically qualified, this means using either IP multicast [4] or IP broadcast [6] service 📡
  • link: a communication facility or medium where systems can talk at the link layer, which is the protocol layer right below IP. People have sometimes used the term "physical network" for this, though it's a bit imprecise 😅 Examples are LANs (possibly bridged to other LANs), wide-area store-and-forward networks, satellite channels, and point-to-point links 🌈
  • multicast link: a link where IP multicast or IP broadcast service is supported. This includes broadcast media like LANs and satellite channels, single point-to-point links, and some store-and-forward networks such as SMDS networks [8] 🛰️
  • interface: a system's attachment point to a link. It's possible (though unusual) for a system to have more than one interface to the same link. Interfaces are uniquely identified by IP unicast addresses, and a single interface may have more than one of those addresses 🔑
  • multicast interface: an interface to a multicast link, meaning an interface to a link where IP multicast or IP broadcast service is supported ✨
  • subnet: either a single subnet of a subnetted IP network [7], or a single non-subnetted IP network. In other words, it's the entity identified by an IP address logically ANDed with its assigned subnet mask. More than one subnet can exist on the same link 🧩
  • neighboring: having an IP address that belongs to the same subnet 💞

2. Protocol Overview 🦋

okay this part is the big picture, so pay attention 👀

Before a host can send IP datagrams beyond its directly-attached subnet, it must discover the address of at least one operational router on that subnet 😭 Usually, the host does this by reading a list of one or more router addresses from a (possibly remote) configuration file at startup. On multicast links, some hosts also find router addresses by listening to routing protocol traffic. Both of these have serious drawbacks 💀 The config files have to be maintained manually, which is a significant administrative burden, and they can't track dynamic changes in router availability. Eavesdropping on routing traffic requires that hosts recognize the particular routing protocols in use, and those vary from subnet to subnet and can change at any time 🙃

So this document specifies a better router discovery method using a pair of ICMP [10] messages, for use on multicast links 🎀 It gets rid of the need for manual configuration of router addresses, and it's independent of any specific routing protocol. Iconic behavior 💅

The ICMP router discovery messages are called "Router Advertisements" and "Router Solicitations" 📣 Each router periodically multicasts a Router Advertisement from each of its multicast interfaces, announcing the IP address(es) of that interface. Hosts discover their neighboring routers simply by listening for those advertisements 👂

When a host attached to a multicast link starts up, it may multicast a Router Solicitation to ask for immediate advertisements, instead of waiting for the next periodic ones to show up 🙋‍♀️ If (and only if) no advertisements are coming, the host may retransmit the solicitation a small number of times, but then it must desist from sending any more solicitations 🛑 Any routers that start up later, or that weren't discovered because of packet loss or temporary link partitioning, are eventually discovered when their periodic (unsolicited) advertisements arrive ⏳ (Links with high packet loss rates or frequent partitioning are handled by increasing the rate of advertisements, rather than letting hosts send more solicitations. Lowkey genius 🧠)

The router discovery messages are not a routing protocol 🚫 They let hosts discover that neighboring routers exist, but not which router is best to reach a particular destination. If a host picks a poor first-hop router for a particular destination, it should receive an ICMP Redirect from that router, identifying a better one 🔁

A Router Advertisement includes a "preference level" for each advertised router address 🏆 When a host must choose a default router address (meaning, for a particular destination, the host hasn't been redirected or configured to use a specific router address), it is expected to choose from the router addresses with the highest preference level. See Section 3.3.1 in the Host Requirements -- Communication Layers RFC [1] for that. A network administrator can configure router address preference levels to encourage or discourage the use of particular routers as default routers 🎛️

A Router Advertisement also includes a "lifetime" field 🕰️ It specifies the maximum length of time that the advertised addresses are considered valid router addresses by hosts, in the absence of further advertisements. This is how hosts eventually forget about routers that fail, become unreachable, or stop acting as routers. Bye bye, old routers 👋

The default advertising rate is once every 7 to 10 minutes, and the default lifetime is 30 minutes ⏱️ With those default values, advertisements are not sufficient as a mechanism for "black hole" detection (detecting failure of the first hop of an active path). Ideally, black holes should be detected quickly enough to switch to another router before any transport connections or higher-layer sessions time out 😬 It's assumed that hosts already have black hole detection mechanisms, as required by [1]. Hosts cannot depend on Router Advertisements for this, since they may be unavailable or administratively disabled on any particular link or from any particular router 🙅‍♀️ So the default advertising rate and lifetime values were chosen to make the load that periodic multicast advertisements put on links and hosts negligible, even when there are many routers around 🌸 That's the whole reason. However, a network administrator who wants to use advertisements as a supplemental black hole detection mechanism is free to configure smaller values ✨

3. Message Formats ✨

Okay bestie, this part is all about the exact shapes of the packets 📦 Every bit has a job, so we're keeping the diagrams perfect 🎀

ICMP Router Advertisement Message

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Num Addrs   |Addr Entry Size|           Lifetime            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Router Address[1]                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Preference Level[1]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Router Address[2]                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Preference Level[2]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               .                               |
      |                               .                               |
      |                               .                               |

IP Fields: 💫

  • Source Address: An IP address belonging to the interface from which this message is sent.
  • Destination Address: The configured AdvertisementAddress or the IP address of a neighboring host.
  • Time-to-Live: 1 if the Destination Address is an IP multicast address; at least 1 otherwise.

ICMP Fields: 🧚

  • Type: 9
  • Code: 0
  • Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum field is set to 0.
  • Num Addrs: The number of router addresses advertised in this message.
  • Addr Entry Size: The number of 32-bit words of information per each router address (2, in the version of the protocol described here).
  • Lifetime: The maximum number of seconds that the router addresses may be considered valid.
  • Router Address[i], i = 1..Num Addrs: The sending router's IP address(es) on the interface from which this message is sent.
  • Preference Level[i], i = 1..Num Addrs: The preferability of each Router Address[i] as a default router address, relative to other router addresses on the same subnet. A signed, twos-complement value; higher values mean more preferable. 🌈

ICMP Router Solicitation Message

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP Fields: 🦋

  • Source Address: An IP address belonging to the interface from which this message is sent, or 0.
  • Destination Address: The configured SolicitationAddress.
  • Time-to-Live: 1 if the Destination Address is an IP multicast address; at least 1 otherwise.

ICMP Fields: 🌸

  • Type: 10
  • Code: 0
  • Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum field is set to 0.
  • Reserved: Sent as 0; ignored on reception.

4. Router Specification 👑

4.1. Router Configuration Variables

A router that implements the ICMP router discovery messages MUST allow for the following variables to be configured by system management. Default values are specified so that you don't have to configure any of these variables in many cases, which is honestly so convenient 🥹

For each multicast interface:

AdvertisementAddress 📣 The IP destination address to be used for multicast Router Advertisements sent from the interface. The only permissible values are the all-systems multicast address, 224.0.0.1, or the limited-broadcast address, 255.255.255.255. (The all-systems address is preferred wherever possible, i.e., on any link where all listening hosts support IP multicast.)

Default: 224.0.0.1 if the router supports IP multicast on the interface, else 255.255.255.255

MaxAdvertisementInterval ⏰ The maximum time allowed between sending multicast Router Advertisements from the interface, in seconds. MUST be no less than 4 seconds and no greater than 1800 seconds.

Default: 600 seconds

MinAdvertisementInterval ⏳ The minimum time allowed between sending unsolicited multicast Router Advertisements from the interface, in seconds. MUST be no less than 3 seconds and no greater than MaxAdvertisementInterval.

Default: 0.75 * MaxAdvertisementInterval

AdvertisementLifetime 💜 The value to be placed in the Lifetime field of Router Advertisements sent from the interface, in seconds. MUST be no less than MaxAdvertisementInterval and no greater than 9000 seconds.

Default: 3 * MaxAdvertisementInterval

For each of the router's IP addresses on its multicast interfaces:

Advertise 🎀 A flag indicating whether or not the address is to be advertised.

Default: TRUE

PreferenceLevel 🏆 The preferability of the address as a default router address, relative to other router addresses on the same subnet. It's a 32-bit, signed, twos-complement integer, and higher values mean more preferable. The minimum value (hex 80000000) is used to indicate that the address, even though it may be advertised, is not to be used by neighboring hosts as a default router address.

Default: 0

The case where it's useful to set a preference level of hex 80000000 (instead of just setting the Advertise flag to FALSE) is when advertisements are being used for "black hole" detection, as mentioned in Section 2. Picture a router that's only meant to reach specific IP destinations. It can advertise its address with a preference level of hex 80000000, so neighboring hosts won't use it as a default router for reaching arbitrary IP destinations. It can also use a non-zero lifetime, so neighboring hosts that were redirected or configured to use it can notice it's failed when its advertisements time out. Literally genius 🧠✨

It has been suggested that, when the preference level of an address hasn't been explicitly configured, a router could set it according to the metric of the router's "default route" (if it has one), instead of defaulting it to zero like we said above. So a router with a better metric for its default route would advertise a higher preference level for its address. (Note that routing metrics that are encoded such that "lower is better" would have to be inverted before being used as preference levels in Router Advertisement messages.) This kind of strategy might reduce the amount of ICMP Redirect traffic on some links, because it's more likely that a host's first choice router for reaching an arbitrary destination is also the best choice. On the other hand, Redirect traffic is rarely a significant load on a link, and there are some cases where this strategy would actually result in more Redirect traffic, not less (for example, on links where the most frequently chosen destinations are best reached via routers other than the one with the best default route). This document makes no recommendation about this issue, so implementors are free to try such a strategy, as long as they also support static configuration of preference levels as specified above. 💅

4.2. Message Validation by Routers

A router MUST silently discard any received Router Solicitation messages that do not satisfy the following validity checks: 🚫

  • IP Source Address is either 0 or the address of a neighbor (i.e., an address that matches one of the router's own addresses on the arrival interface, under the subnet mask associated with that address.)
  • ICMP Checksum is valid.
  • ICMP Code is 0.
  • ICMP length (derived from the IP length) is 8 or more octets.

The contents of the ICMP Reserved field, and of any octets beyond the first 8, are ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or of additional octets at the end of the message; backward-incompatible changes may use different Code values. 🔮

A solicitation that passes the validity checks is called a "valid solicitation" ✅

A router MAY silently discard any received Router Advertisement messages. Any other action on reception of such messages by a router (for example, as part of a "peer discovery" process) is beyond the scope of this document. That's a whole other story, bestie 🙈

4.3. Router Behavior ✨

okay so the router joins the all-routers IP multicast group (224.0.0.2) on all interfaces where it supports IP multicast 📣 it's basically the router signing up for the group chat 💬

so an "advertising interface" is any functioning and enabled multicast interface with at least one IP address whose configured Advertise flag is TRUE 💅 from each of those, the router sends out periodic, multicast Router Advertisements containing these values:

  • In the destination address field of the IP header: the interface's configured AdvertisementAddress.
  • In the Lifetime field: the interface's configured AdvertisementLifetime.
  • In the Router Address[i] and Preference Level[i] fields: all of the interface's addresses whose Advertise flags are TRUE, along with their corresponding PreferenceLevel values. (In the unlikely event that not all addresses fit in a single advertisement, as constrained by the MTU of the link, multiple advertisements are sent, with each except the last containing as many addresses as can fit.)

the advertisements aren't strictly periodic 🎲 the gap between sends is randomized so routers don't all end up syncing up with each other on the same link. each advertising interface gets its own transmission interval timer. every time a multicast advertisement goes out, that timer resets to a uniformly-distributed random value between the interface's configured MinAdvertisementInterval and MaxAdvertisementInterval. when it expires, the next advertisement goes out and a new random value gets picked ✨ (It is RECOMMENDED that routers include some unique value, such as one of their IP or link-layer addresses, in the seed used to initialize their pseudo-random number generators. Although the randomization range is configured in units of seconds, the actual randomly-chosen values SHOULD NOT be in units of whole seconds, but rather in units of the highest available timer resolution.)

for the first few advertisements from an interface (up to MAX_INITIAL_ADVERTISEMENTS), if the random interval is greater than MAX_INITIAL_ADVERT_INTERVAL, the timer SHOULD be set to MAX_INITIAL_ADVERT_INTERVAL instead 🚀 the shorter interval helps a router get discovered quickly when it first shows up, even if some packets get lost along the way.

in addition to the periodic, unsolicited advertisements, a router sends advertisements in response to valid solicitations received on any of its advertising interfaces 🙌 A router MAY choose to unicast the response directly to the soliciting host's address (if it is not zero), or multicast it to the interface's configured AdvertisementAddress. in the multicast case, the interface's interval timer resets to a new random value, same as with unsolicited advertisements. A unicast response MAY be delayed, and a multicast response MUST be delayed, for a small random interval not greater than MAX_RESPONSE_DELAY. this stops responding routers from syncing up and lets several closely-spaced solicitations get answered with one single multicast advertisement.

if a router receives a solicitation sent to an IP broadcast address, on an interface whose configured AdvertisementAddress is an IP multicast address, the router MAY send its response to the IP broadcast address instead of the configured IP multicast address. this is a configuration inconsistency 🚨 it SHOULD be logged so the network administrator can take corrective action.

It should be noted that an interface may become an advertising interface at times other than system startup, as a result of recovery from an interface failure or through actions of system management such as:

  • enabling the interface, if it had been administratively disabled and it has one or more addresses whose Advertise flag is TRUE, or
  • enabling IP forwarding capability (i.e., changing the system from being a host to being a router), when the interface has one or more addresses whose Advertise flag is TRUE, or
  • setting the Advertise flag of one or more of the interface's addresses to TRUE (or adding a new address with a TRUE Advertise flag), when previously the interface had no address whose Advertise flag was TRUE.

In such cases, the router MUST commence transmission of periodic advertisements on the new advertising interface, limiting the first few advertisements to intervals no greater than MAX_INITIAL_ADVERT_INTERVAL. In the case of a host becoming a router, the system MUST also join the all-routers IP multicast group on all interfaces on which the router supports IP multicast (whether or not they are advertising interfaces). 🌸

An interface may also cease to be an advertising interface, through actions of system management such as:

  • administratively disabling the interface,
  • shutting down the system, or disabling the IP forwarding capability (i.e., changing the system from being a router to being a host), or
  • setting the Advertise flags of all of the interface's addresses to FALSE.

In such cases, it is RECOMMENDED (but not REQUIRED) that the router transmit a final multicast advertisement on the interface, identical to its previous transmission but with a Lifetime field of zero. In the case of a router becoming a host, the system MUST also depart from the all-routers IP multicast group on all interfaces on which the router supports IP multicast (whether or not they had been advertising interfaces). 👋

When the Advertise flag of one or more of an interface's addresses are set to FALSE by system management, but there remain other addresses on that interface whose Advertise flags are TRUE, it is RECOMMENDED that the router send a single multicast advertisement containing only those address whose Advertise flags were set to FALSE, with a Lifetime field of zero. 🧹

5. Host Specification ✨

5.1. Host Configuration Variables

A host that implements the ICMP router discovery messages MUST allow for the following variables to be configured by system management. the default values are set up so you don't have to configure any of these in lots of cases 🥰

For each multicast interface:

  • PerformRouterDiscovery
    • A flag indicating whether or not the host is to perform ICMP router discovery on the interface.
    • Default: TRUE
  • SolicitationAddress
    • The IP destination address to be used for sending Router Solicitations from the interface. The only permissible values are the all-routers multicast address, 224.0.0.2, or the limited-broadcast address, 255.255.255.255. (The all-routers address is preferred wherever possible, i.e., on any link where all advertising routers support IP multicast.)
    • Default: 224.0.0.2 if the host supports IP multicast on the interface, else 255.255.255.255

The Host Requirements -- Communication Layers RFC [1], Section 3.3.1.6, specifies that each host implementation MUST support a configurable list of default router addresses. the whole point of ICMP router discovery is to get rid of the need to configure that list on hosts attached to multicast links 🙌 on non-multicast links, and on multicast links where routers don't support ICMP router discovery yet (or it's administratively disabled), it will keep being necessary to configure the default router list on each host. Each entry in the list contains (at least) the following configurable variables:

  • RouterAddress
    • An IP address of a default router.
    • Default: (none)
  • PreferenceLevel
    • The preferability of the RouterAddress as a default router address, relative to other router addresses on the same subnet. The Host Requirements RFC does not specify how this value is to be encoded; to allow the preference level to be conveyed in a Router Advertisement or configured by system management, it is here specified that it be encoded as a 32-bit, signed, twos-complement integer, with higher values meaning more preferable. The minimum value (hex 80000000) is reserved to mean that the address is not to be used as a default router address, i.e., it is to be used only for specific IP destinations, of which the host has been informed by ICMP Redirect or configuration. 💜
    • Default: 0

5.2. Message Validation by Hosts

A host MUST silently discard any received Router Advertisement messages that do not satisfy the following validity checks:

  • ICMP Checksum is valid.
  • ICMP Code is 0.
  • ICMP Num Addrs is greater than or equal to 1.
  • ICMP Addr Entry Size is greater than or equal to 2.
  • ICMP length (derived from the IP length) is greater than or equal to 8 + (Num Addrs * Addr Entry Size * 4) octets.

The contents of any additional words of per-address information (i.e., other than the Router Address and Preference Level fields), and the contents of any octets beyond the first 8 + (Num Addrs * Addr Entry Size * 4) octets, are ignored. Future, backward-compatible changes to the protocol MAY specify additional per-address information words, or additional octets at the end of the message; backward-incompatible changes MAY use different Code values. 🔮

An advertisement that passes the validity checks is called a "valid advertisement". ✅

A host MUST silently discard any received Router Solicitation messages. 🫶

5.3. Host Behavior ✨

Okay so, on any interface where the host supports IP multicast, the host will be a member of the all-systems IP multicast group (224.0.0.1) 🌈 This happens automatically, as specified in [4], so the router discovery protocol doesn't have to do anything explicit for it 🫶

A host never sends a Router Advertisement message. Not ever 💅

A host silently discards any Router Advertisement message that arrives on an interface where its configured PerformRouterDiscovery flag is FALSE, and it never sends a Router Solicitation on that interface either 🙈

A host cannot process an advertisement until it has figured out its own IP address(es) and subnet mask(s) for the interface where the advertisement shows up. (On some links, a host MAY be able to use some combo of BOOTP [3], RARP [5], or ICMP Address Mask messages [7] to find its own address and mask 🧚) While it's waiting to learn the address and mask of an interface, a host MAY save any valid advertisements it gets on that interface for later processing. This lets router discovery and address/mask discovery happen at the same time, which is so efficient 🔥

To process an advertisement, a host scans the list of router addresses inside it. It ignores any non-neighboring addresses, meaning addresses that don't match one of the host's own addresses on the arrival interface under the subnet mask linked to that address. For each neighboring address, the host does the following:

  • If the address isn't already in the host's default router list, a new entry gets added to the list. It holds the address, its preference level, and a timer set to the Lifetime value from the advertisement.
  • If the address is already in the default router list because of a previous advertisement, its preference level gets updated and its timer gets reset to the values from the newly received advertisement.
  • If the address is already in the default router list because of system configuration, its preference level stays the same, since there's no timer tied to a configured address. (Quick note: any router addresses picked up from the "Gateway" subfield of the vendor extensions field of a BOOTP packet [11] count as configured addresses. They get the default preference level of zero and don't have a timer. Also, any address found in the giaddr field of a BOOTP packet [3] identifies a BOOTP forwarder, which isn't necessarily an IP router, so that address SHOULD NOT be installed in the host's default router list 👀)

Whenever the timer expires on any entry that was created from a received advertisement, that entry gets tossed 🗑️

To keep the storage for the default router list in check, a host MAY choose not to store every router address it discovers through advertisements. If it does that, the host SHOULD discard the addresses with lower preference levels in favor of the ones with higher levels. It's really desirable to keep more than one default router address in the list 🌸 That way, if the current default router turns out to be down, the host can immediately pick another one without waiting for the next advertisement to show up.

Any router address advertised with a preference level of hex 80000000 is not to be used by the host as a default router address. Such an address MAY be left out of the default router list, unless its timer is being used as a "black-hole" detection mechanism, as discussed in Section 4.1 🖤

It SHOULD be understood that preference levels learned from advertisements don't touch any of the host's cached route entries. For example, if the host has been redirected to use a particular router address to reach a specific IP destination, it keeps using that router address for that destination, even if it finds another router address with a higher preference level. Preference levels only influence which router gets picked for an IP destination that has no cached or configured route, or whose cached route points to a router that's later found to be dead or unreachable 💅✨

A host is permitted (but not required) to transmit up to MAX_SOLICITATIONS Router Solicitation messages from any of its multicast interfaces after any of these events:

  • The interface is initialized at system startup time.
  • The interface is reinitialized after a temporary interface failure, or after being temporarily disabled by system management.
  • The system changes from being a router to being a host, by having its IP forwarding capability turned off by system management.
  • The PerformRouterDiscovery flag for the interface is changed from FALSE to TRUE by system management.

The IP destination address of the solicitations is the configured SolicitationAddress for the interface. The IP source address MAY contain zero if the host hasn't figured out an address for the interface yet. Otherwise, it contains one of the interface's addresses 🦋

If a host does choose to send a solicitation after one of the events above, it SHOULD delay that transmission for a random amount of time between 0 and MAX_SOLICITATION_DELAY. This helps ease congestion when lots of hosts start up on a link at the same time, like after recovering from a power failure 😭 (It is RECOMMENDED that hosts include some unique value, such as one of their IP or link-layer addresses, in the seed used to initialize their pseudo-random number generators. Even though the randomization range is specified in seconds, the actual randomly chosen value SHOULD NOT be in whole seconds. It should be in units of the highest available timer resolution instead ⏱️)

A host MAY also choose to postpone its solicitations even further, after one of the events above, until the first time it needs to use a default router 🧁

Upon receiving a valid advertisement that has at least one neighboring address with a preference level other than hex 80000000, after one of the events above, the host MUST desist from sending any solicitations on that interface. This applies even if none have been sent yet, and it lasts until the next time one of the events above happens. The small number of retransmissions of a solicitation, which are permitted if no such advertisement arrives, SHOULD be sent at intervals of SOLICITATION_INTERVAL seconds, without randomization 🎀

6. Protocol Constants

Okay, here are the constants. Router constants first 👑

   Router constants:

         MAX_INITIAL_ADVERT_INTERVAL       16 seconds

         MAX_INITIAL_ADVERTISEMENTS        3 transmissions

         MAX_RESPONSE_DELAY                2 seconds

   Host constants:

         MAX_SOLICITATION_DELAY            1 second

         SOLICITATION_INTERVAL             3 seconds

         MAX_SOLICITATIONS                 3 transmissions

Additional protocol constants are defined with the message formats in Section 3, and with the router and host configuration variables in Sections 4.1 and 5.1 🌈

All protocol constants are subject to change in future revisions of the protocol. Plan accordingly, bestie 💜

7. Security Considerations 🚨

Okay, this part is seriously important, so listen up 👀 This extension of ICMP makes it possible for any system attached to a link to masquerade as a default router for hosts on that link. Any traffic sent to such an imposter is vulnerable to eavesdropping, to denial of forwarding service, and to modification by insertion, deletion, or alteration of packets. It SHOULD be noted that, on most multicast or broadcast links where this protocol is expected to run, eavesdropping is already possible for any system attached to the link. The Address Resolution Protocol (ARP) used on those links offers a similar opportunity for service denial and message stream modification. For environments where those threats are considered unacceptable, there are configuration variables that disable dynamic router discovery by hosts 🛑

The Router Advertisement message format is defined so that additional information can be added in a backward-compatible way. One possible use of that is adding digital signatures or some other form of authentication information to the advertisements, so hosts can verify their authenticity 🔐 This is FOR FURTHER STUDY 🔭

References 📚

[1] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", RFC 1122, USC/Information Sciences Institute, October 1989.

[2] Braden, R., and J. Postel, "Requirements for Internet Gateways", RFC 1009, USC/Information Sciences Institute, June 1987.

[3] Croft, B, and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford and SUN Microsystems, September 1985.

[4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, Stanford University, August 1989.

[5] Finlayson, R., Mann, T., Mogul J., and M. Theimer, "A Reverse Address Resolution Protocol", RFC 903, Stanford University, June 1984.

[6] Mogul, J., "Broadcasting Internet Datagrams", RFC 919, Stanford University, October 1984.

[7] Mogul J., and J. Postel, "Internet Standard Subnetting Procedure", RFC 950, USC/Information Sciences Institute, August 1985.

[8] Piscitello D., and J. Lawrence, "Transmission of IP datagrams over the SMDS Service", RFC 1209, Bell Communications Research, March, 1991.

[9] Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, DARPA, September 1981.

[10] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification", RFC 792, USC/Information Sciences Institute, September 1981.

[11] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1084, USC/Information Sciences Institute, December 1988.

Author's Address 💌

   Stephen E. Deering
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA  94304

   Phone: (415) 494-4839

   EMail: deering@xerox.com

   Or send comments to gw-discovery@gregorio.stanford.edu.

That's the whole spec, bestie 🌈🦋💖 You made it!

📦 where this page comes from