home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1256 < prev    next >
Text File  |  1991-09-30  |  44KB  |  1,067 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                 S. Deering, Editor
  8. Request for Comments: 1256                                    Xerox PARC
  9.                                                           September 1991
  10.  
  11.  
  12.                      ICMP Router Discovery Messages
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC specifies an IAB standards track protocol for the Internet
  17.    community, and requests discussion and suggestions for improvements.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    This document is a product of the IETF Router Discovery Working
  21.    Group.  Distribution of this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    This document specifies an extension of the Internet Control Message
  26.    Protocol (ICMP) to enable hosts attached to multicast or broadcast
  27.    networks to discover the IP addresses of their neighboring routers.
  28.  
  29. Table of Contents
  30.  
  31.    1. Terminology                                                      1
  32.    2. Protocol Overview                                                3
  33.    3. Message Formats                                                  5
  34.    4. Router Specification                                             7
  35.         4.1. Router Configuration Variables                            7
  36.         4.2. Message Validation by Routers                             9
  37.         4.3. Router Behavior                                           9
  38.    5. Host Specification                                              12
  39.         5.1. Host Configuration Variables                             12
  40.         5.2. Message Validation by Hosts                              13
  41.         5.3. Host Behavior                                            14
  42.    6. Protocol Constants                                              17
  43.    7. Security Considerations                                         17
  44.    References                                                         18
  45.    Author's Address                                                   19
  46.  
  47. 1. Terminology
  48.  
  49.    The following terms have a precise meaning when used in this
  50.    document:
  51.  
  52.    system        a device that implements the Internet Protocol, IP [9].
  53.  
  54.    router        a system that forwards IP datagrams, as specified
  55.  
  56.  
  57.  
  58. Router Discovery Working Group                                  [Page 1]
  59.  
  60. RFC 1256             ICMP Router Discovery Messages       September 1991
  61.  
  62.  
  63.                  in [2].  This does not include systems that, though
  64.                  capable of IP forwarding, have that capability turned
  65.                  off.  Nor does it include systems that do IP forwarding
  66.                  only insofar as required to obey IP Source Route
  67.                  options.
  68.  
  69.    host          any system that is not a router.
  70.  
  71.    multicast     unless otherwise qualified, means the use of either IP
  72.                  multicast [4] or IP broadcast [6] service.
  73.  
  74.    link          a communication facility or medium over which systems
  75.                  can communicate at the link layer, i.e., the protocol
  76.                  layer immediately below IP.  The term "physical
  77.                  network" has sometimes been used (imprecisely) for
  78.                  this. Examples of links are LANs (possibly bridged to
  79.                  other LANs), wide-area store-and-forward networks,
  80.                  satellite channels, and point-to-point links.
  81.  
  82.    multicast link
  83.                  a link over which IP multicast or IP broadcast service
  84.                  is supported.  This includes broadcast media such as
  85.                  LANs and satellite channels, single point-to-point
  86.                  links, and some store-and-forward networks such as SMDS
  87.                  networks [8].
  88.  
  89.    interface     a system's attachment point to a link.  It is possible
  90.                  (though unusual) for a system to have more than one
  91.                  interface to the same link.  Interfaces are uniquely
  92.                  identified by IP unicast addresses; a single interface
  93.                  may have more than one such address.
  94.  
  95.    multicast interface
  96.                  an interface to a multicast link, that is, an interface
  97.                  to a link over which IP multicast or IP broadcast
  98.                  service is supported.
  99.  
  100.    subnet        either a single subnet of a subnetted IP network [7] or
  101.                  a single non-subnetted IP network, i.e., the entity
  102.                  identified by an IP address logically ANDed with its
  103.                  assigned subnet mask.  More than one subnet may exist
  104.                  on the same link.
  105.  
  106.    neighboring   having an IP address belonging to the same subnet.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Router Discovery Working Group                                  [Page 2]
  115.  
  116. RFC 1256             ICMP Router Discovery Messages       September 1991
  117.  
  118.  
  119. 2. Protocol Overview
  120.  
  121.    Before a host can send IP datagrams beyond its directly-attached
  122.    subnet, it must discover the address of at least one operational
  123.    router on that subnet. Typically, this is accomplished by reading a
  124.    list of one or more router addresses from a (possibly remote)
  125.    configuration file at startup time.  On multicast links, some hosts
  126.    also discover router addresses by listening to routing protocol
  127.    traffic.  Both of these methods have serious drawbacks: configuration
  128.    files must be maintained manually -- a significant administrative
  129.    burden -- and are unable to track dynamic changes in router
  130.    availability; eavesdropping on routing traffic requires that hosts
  131.    recognize the particular routing protocols in use, which vary from
  132.    subnet to subnet and which are subject to change at any time.  This
  133.    document specifies an alternative router discovery method using a
  134.    pair of ICMP [10] messages, for use on multicast links.  It
  135.    eliminates the need for manual configuration of router addresses and
  136.    is independent of any specific routing protocol.
  137.  
  138.    The ICMP router discovery messages are called "Router Advertisements"
  139.    and "Router Solicitations".  Each router periodically multicasts a
  140.    Router Advertisement from each of its multicast interfaces,
  141.    announcing the IP address(es) of that interface.  Hosts discover the
  142.    addresses of their neighboring routers simply by listening for
  143.    advertisements.  When a host attached to a multicast link starts up,
  144.    it may multicast a Router Solicitation to ask for immediate
  145.    advertisements, rather than waiting for the next periodic ones to
  146.    arrive; if (and only if) no advertisements are forthcoming, the host
  147.    may retransmit the solicitation a small number of times, but then
  148.    must desist from sending any more solicitations.  Any routers that
  149.    subsequently start up, or that were not discovered because of packet
  150.    loss or temporary link partitioning, are eventually discovered by
  151.    reception of their periodic (unsolicited) advertisements.  (Links
  152.    that suffer high packet loss rates or frequent partitioning are
  153.    accommodated by increasing the rate of advertisements, rather than
  154.    increasing the number of solicitations that hosts are permitted to
  155.    send.)
  156.  
  157.    The router discovery messages do not constitute a routing protocol:
  158.    they enable hosts to discover the existence of neighboring routers,
  159.    but not which router is best to reach a particular destination.  If a
  160.    host chooses a poor first-hop router for a particular destination, it
  161.    should receive an ICMP Redirect from that router, identifying a
  162.    better one.
  163.  
  164.    A Router Advertisement includes a "preference level" for each
  165.    advertised router address.  When a host must choose a default router
  166.    address (i.e., when, for a particular destination, the host has not
  167.  
  168.  
  169.  
  170. Router Discovery Working Group                                  [Page 3]
  171.  
  172. RFC 1256             ICMP Router Discovery Messages       September 1991
  173.  
  174.  
  175.    been redirected or configured to use a specific router address), it
  176.    is expected to choose from those router addresses that have the
  177.    highest preference level (see Section 3.3.1 in the Host Requirements
  178.    -- Communication Layers RFC [1]).  A network administrator can
  179.    configure router address preference levels to encourage or discourage
  180.    the use of particular routers as default routers.
  181.  
  182.    A Router Advertisement also includes a "lifetime" field, specifying
  183.    the maximum length of time that the advertised addresses are to be
  184.    considered as valid router addresses by hosts, in the absence of
  185.    further advertisements.  This is used to ensure that hosts eventually
  186.    forget about routers that fail, become unreachable, or stop acting as
  187.    routers.
  188.  
  189.    The default advertising rate is once every 7 to 10 minutes, and the
  190.    default lifetime is 30 minutes.  This means that, using the default
  191.    values, the advertisements are not sufficient as a mechanism for
  192.    "black hole" detection, i.e., detection of failure of the first hop
  193.    of an active path -- ideally, black holes should be detected quickly
  194.    enough to switch to another router before any transport connections
  195.    or higher-layer sessions time out.  It is assumed that hosts already
  196.    have mechanisms for black hole detection, as required by [1].  Hosts
  197.    cannot depend on Router Advertisements for this purpose, since they
  198.    may be unavailable or administratively disabled on any particular
  199.    link or from any particular router.  Therefore, the default
  200.    advertising rate and lifetime values were chosen simply to make the
  201.    load imposed on links and hosts by the periodic multicast
  202.    advertisements negligible, even when there are many routers present.
  203.    However, a network administrator who wishes to employ advertisements
  204.    as a supplemental black hole detection mechanism is free to configure
  205.    smaller values.
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Router Discovery Working Group                                  [Page 4]
  227.  
  228. RFC 1256             ICMP Router Discovery Messages       September 1991
  229.  
  230.  
  231. 3. Message Formats
  232.  
  233.  
  234.    ICMP Router Advertisement Message
  235.  
  236.        0                   1                   2                   3
  237.        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
  238.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  239.       |     Type      |     Code      |           Checksum            |
  240.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  241.       |   Num Addrs   |Addr Entry Size|           Lifetime            |
  242.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  243.       |                       Router Address[1]                       |
  244.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  245.       |                      Preference Level[1]                      |
  246.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  247.       |                       Router Address[2]                       |
  248.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  249.       |                      Preference Level[2]                      |
  250.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  251.       |                               .                               |
  252.       |                               .                               |
  253.       |                               .                               |
  254.  
  255.  
  256.    IP Fields:
  257.  
  258.       Source Address        An IP address belonging to the interface
  259.                             from which this message is sent.
  260.  
  261.       Destination Address   The configured AdvertisementAddress or the
  262.                             IP address of a neighboring host.
  263.  
  264.       Time-to-Live          1 if the Destination Address is an IP
  265.                             multicast address; at least 1 otherwise.
  266.  
  267.  
  268.    ICMP Fields:
  269.  
  270.       Type                  9
  271.  
  272.       Code                  0
  273.  
  274.       Checksum              The  16-bit one's complement of the one's
  275.                             complement sum of the ICMP message, start-
  276.                             ing with the ICMP Type.  For computing the
  277.                             checksum, the Checksum field is set to 0.
  278.  
  279.  
  280.  
  281.  
  282. Router Discovery Working Group                                  [Page 5]
  283.  
  284. RFC 1256             ICMP Router Discovery Messages       September 1991
  285.  
  286.  
  287.       Num Addrs             The number of router addresses advertised
  288.                             in this message.
  289.  
  290.       Addr Entry Size       The number of 32-bit words of information
  291.                             per each router address (2, in the version
  292.                             of the protocol described here).
  293.  
  294.       Lifetime              The maximum number of seconds that the
  295.                             router addresses may be considered valid.
  296.  
  297.       Router Address[i],    The sending router's IP address(es) on the
  298.        i = 1..Num Addrs     interface from which this message is sent.
  299.  
  300.       Preference Level[i],  The preferability of each Router Address[i]
  301.        i = 1..Num Addrs     as a default router address, relative to
  302.                             other router addresses on the same subnet.
  303.                             A signed, twos-complement value; higher
  304.                             values mean more preferable.
  305.  
  306.  
  307.    ICMP Router Solicitation Message
  308.  
  309.        0                   1                   2                   3
  310.        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
  311.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  312.       |     Type      |     Code      |           Checksum            |
  313.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  314.       |                           Reserved                            |
  315.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  316.  
  317.  
  318.    IP Fields:
  319.  
  320.       Source Address        An IP address belonging to the interface
  321.                             from which this message is sent, or 0.
  322.  
  323.       Destination Address   The configured SolicitationAddress.
  324.  
  325.       Time-to-Live          1 if the Destination Address is an IP
  326.                             multicast address; at least 1 otherwise.
  327.  
  328.  
  329.    ICMP Fields:
  330.  
  331.       Type                  10
  332.  
  333.       Code                  0
  334.  
  335.  
  336.  
  337.  
  338. Router Discovery Working Group                                  [Page 6]
  339.  
  340. RFC 1256             ICMP Router Discovery Messages       September 1991
  341.  
  342.  
  343.       Checksum              The  16-bit one's complement of the one's
  344.                             complement sum of the ICMP message, start-
  345.                             ing with the ICMP Type.  For computing the
  346.                             checksum, the Checksum field is set to 0.
  347.  
  348.       Reserved              Sent as 0; ignored on reception.
  349.  
  350.  
  351. 4. Router Specification
  352.  
  353. 4.1. Router Configuration Variables
  354.  
  355.    A router that implements the ICMP router discovery messages must
  356.    allow for the following variables to be configured by system
  357.    management; default values are specified so as to make it unnecessary
  358.    to configure any of these variables in many cases.
  359.  
  360.    For each multicast interface:
  361.  
  362.    AdvertisementAddress
  363.                  The IP destination address to be used for multicast
  364.                  Router Advertisements sent from the interface.  The
  365.                  only permissible values are the all-systems multicast
  366.                  address, 224.0.0.1, or the limited-broadcast address,
  367.                  255.255.255.255.  (The all-systems address is preferred
  368.                  wherever possible, i.e., on any link where all
  369.                  listening hosts support IP multicast.)
  370.  
  371.                  Default: 224.0.0.1 if the router supports IP multicast
  372.                  on the interface, else 255.255.255.255
  373.  
  374.    MaxAdvertisementInterval
  375.                  The maximum time allowed between sending multicast
  376.                  Router Advertisements from the interface, in seconds.
  377.                  Must be no less than 4 seconds and no greater than 1800
  378.                  seconds.
  379.  
  380.                  Default: 600 seconds
  381.  
  382.    MinAdvertisementInterval
  383.                  The minimum time allowed between sending unsolicited
  384.                  multicast Router Advertisements from the interface, in
  385.                  seconds.  Must be no less than 3 seconds and no greater
  386.                  than MaxAdvertisementInterval.
  387.  
  388.                  Default: 0.75 * MaxAdvertisementInterval
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Router Discovery Working Group                                  [Page 7]
  395.  
  396. RFC 1256             ICMP Router Discovery Messages       September 1991
  397.  
  398.  
  399.    AdvertisementLifetime
  400.                  The value to be placed in the Lifetime field of Router
  401.                  Advertisements sent from the interface, in seconds.
  402.                  Must be no less than MaxAdvertisementInterval and no
  403.                  greater than 9000 seconds.
  404.  
  405.                  Default: 3 * MaxAdvertisementInterval
  406.  
  407.  
  408.    For each of the router's IP addresses on its multicast interfaces:
  409.  
  410.    Advertise
  411.                  A flag indicating whether or not the address is to be
  412.                  advertised.
  413.  
  414.                  Default: TRUE
  415.  
  416.    PreferenceLevel
  417.                  The preferability of the address as a default router
  418.                  address, relative to other router addresses on the same
  419.                  subnet.  A 32-bit, signed, twos-complement integer,
  420.                  with higher values meaning more preferable.  The
  421.                  minimum value (hex 80000000) is used to indicate that
  422.                  the address, even though it may be advertised, is not
  423.                  to be used by neighboring hosts as a default router
  424.                  address.
  425.  
  426.                  Default: 0
  427.  
  428.    The case in which it is useful to configure an address with a
  429.    preference level of hex 80000000 (rather than simply setting its
  430.    Advertise flag to FALSE) is when advertisements are being used for
  431.    "black hole" detection, as mentioned in Section 2.  In particular, a
  432.    router that is to be used to reach only specific IP destinations
  433.    could advertise its address with a preference level of hex 80000000
  434.    (so that neighboring hosts will not use it as a default router for
  435.    reaching arbitrary IP destinations) and a non-zero lifetime (so that
  436.    neighboring hosts that have been redirected or configured to use it
  437.    can detect its failure by timing out the reception of its
  438.    advertisements).
  439.  
  440.    It has been suggested that, when the preference level of an address
  441.    has not been explicitly configured, a router could set it according
  442.    to the metric of the router's "default route" (if it has one), rather
  443.    than defaulting it to zero as suggested above.  Thus, a router with a
  444.    better metric for its default route would advertise a higher
  445.    preference level for its address.  (Note that routing metrics that
  446.    are encoded such that "lower is better" would have to be inverted
  447.  
  448.  
  449.  
  450. Router Discovery Working Group                                  [Page 8]
  451.  
  452. RFC 1256             ICMP Router Discovery Messages       September 1991
  453.  
  454.  
  455.    before being used as preference levels in Router Advertisement
  456.    messages.)  Such a strategy might reduce the amount of ICMP Redirect
  457.    traffic on some links by making it more likely that a host's first
  458.    choice router for reaching an arbitrary destination is also the best
  459.    choice.  On the other hand, Redirect traffic is rarely a significant
  460.    load on a link, and there are some cases where such a strategy would
  461.    result in more Redirect traffic, not less (for example, on links from
  462.    which the most frequently chosen destinations are best reached via
  463.    routers other than the one with the best default route).  This
  464.    document makes no recommendation concerning this issue, and
  465.    implementors are free to try such a strategy, as long as they also
  466.    support static configuration of preference levels as specified above.
  467.  
  468. 4.2. Message Validation by Routers
  469.  
  470.    A router must silently discard any received Router Solicitation
  471.    messages that do not satisfy the following validity checks:
  472.  
  473.       - IP Source Address is either 0 or the address of a neighbor
  474.         (i.e., an address that matches one of the router's own
  475.         addresses on the arrival interface, under the subnet mask
  476.         associated with that address.)
  477.  
  478.       - ICMP Checksum is valid.
  479.  
  480.       - ICMP Code is 0.
  481.  
  482.       - ICMP length (derived from the IP length) is 8 or more
  483.         octets.
  484.  
  485.    The contents of the ICMP Reserved field, and of any octets beyond the
  486.    first 8, are ignored.  Future, backward-compatible changes to the
  487.    protocol may specify the contents of the Reserved field or of
  488.    additional octets at the end of the message; backward-incompatible
  489.    changes may use different Code values.
  490.  
  491.    A solicitation that passes the validity checks is called a "valid
  492.    solicitation".
  493.  
  494.    A router may silently discard any received Router Advertisement
  495.    messages.  Any other action on reception of such messages by a router
  496.    (for example, as part of a "peer discovery" process) is beyond the
  497.    scope of this document.
  498.  
  499. 4.3. Router Behavior
  500.  
  501.    The router joins the all-routers IP multicast group (224.0.0.2) on
  502.    all interfaces on which the router supports IP multicast.
  503.  
  504.  
  505.  
  506. Router Discovery Working Group                                  [Page 9]
  507.  
  508. RFC 1256             ICMP Router Discovery Messages       September 1991
  509.  
  510.  
  511.    The term "advertising interface" refers to any functioning and
  512.    enabled multicast interface that has at least one IP address whose
  513.    configured Advertise flag is TRUE.  From each advertising interface,
  514.    the router transmits periodic, multicast Router Advertisements,
  515.    containing the following values:
  516.  
  517.       - In the destination address field of the IP header: the
  518.         interface's configured AdvertisementAddress.
  519.  
  520.       - In the Lifetime field: the interface's configured
  521.         AdvertisementLifetime.
  522.  
  523.       - In the Router Address[i] and Preference Level[i] fields:
  524.         all of the interface's addresses whose Advertise flags are
  525.         TRUE, along with their corresponding PreferenceLevel
  526.         values.  (In the unlikely event that not all addresses fit
  527.         in a single advertisement, as constrained by the MTU of the
  528.         link, multiple advertisements are sent, with each except
  529.         the last containing as many addresses as can fit.)
  530.  
  531.    The advertisements are not strictly periodic: the interval between
  532.    subsequent transmissions is randomized to reduce the probability of
  533.    synchronization with the advertisements from other routers on the
  534.    same link. This is done by maintaining a separate transmission
  535.    interval timer for each advertising interface.  Each time a multicast
  536.    advertisement is sent from an interface, that interface's timer is
  537.    reset to a uniformly-distributed random value between the interface's
  538.    configured MinAdvertisementInterval and MaxAdvertisementInterval;
  539.    expiration of the timer causes the next advertisement to be sent from
  540.    the interface, and a new random value to be chosen.  (It is
  541.    recommended that routers include some unique value, such as one of
  542.    their IP or link-layer addresses, in the seed used to initialize
  543.    their pseudo-random number generators.  Although the randomization
  544.    range is configured in units of seconds, the actual randomly-chosen
  545.    values should not be in units of whole seconds, but rather in units
  546.    of the highest available timer resolution.)
  547.  
  548.    For the first few advertisements sent from an interface (up to
  549.    MAX_INITIAL_ADVERTISEMENTS), if the randomly chosen interval is
  550.    greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to
  551.    MAX_INITIAL_ADVERT_INTERVAL instead.  Using this smaller interval for
  552.    the initial advertisements increases the likelihood of a router being
  553.    discovered quickly when it first becomes available, in the presence
  554.    of possible packet loss.
  555.  
  556.    In addition to the periodic, unsolicited advertisements, a router
  557.    sends advertisements in response to valid solicitations received on
  558.    any of its advertising interfaces.  A router may choose to unicast
  559.  
  560.  
  561.  
  562. Router Discovery Working Group                                 [Page 10]
  563.  
  564. RFC 1256             ICMP Router Discovery Messages       September 1991
  565.  
  566.  
  567.    the response directly to the soliciting host's address (if it is not
  568.    zero), or multicast it to the interface's configured
  569.    AdvertisementAddress; in the latter case, the interface's interval
  570.    timer is reset to a new random value, as with unsolicited
  571.    advertisements.  A unicast response may be delayed, and a multicast
  572.    response must be delayed, for a small random interval not greater
  573.    than MAX_RESPONSE_DELAY, in order to prevent synchronization with
  574.    other responding routers, and to allow multiple, closely-spaced
  575.    solicitations to be answered with a single multicast advertisement.
  576.  
  577.    If a router receives a solicitation sent to an IP broadcast address,
  578.    on an interface whose configured AdvertisementAddress is an IP
  579.    multicast address, the router may send its response to the IP
  580.    broadcast address instead of the configured IP multicast address.
  581.    Such an event indicates a configuration inconsistency, and should be
  582.    logged for possible corrective action by the network administrator.
  583.  
  584.    It should be noted that an interface may become an advertising
  585.    interface at times other than system startup, as a result of recovery
  586.    from an interface failure or through actions of system management
  587.    such as:
  588.  
  589.       - enabling the interface, if it had been administratively
  590.         disabled and it has one or more addresses whose Advertise
  591.         flag is TRUE, or
  592.  
  593.       - enabling IP forwarding capability (i.e., changing the
  594.         system from being a host to being a router), when the
  595.         interface has one or more addresses whose Advertise flag is
  596.         TRUE, or
  597.  
  598.       - setting the Advertise flag of one or more of the
  599.         interface's addresses to TRUE (or adding a new address with
  600.         a TRUE Advertise flag), when previously the interface had
  601.         no address whose Advertise flag was TRUE.
  602.  
  603. In such cases, the router must commence transmission of periodic
  604. advertisements on the new advertising interface, limiting the first few
  605. advertisements to intervals no greater than MAX_INITIAL_ADVERT_INTERVAL.
  606. In the case of a host becoming a router, the system must also join the
  607. all-routers IP multicast group on all interfaces on which the router
  608. supports IP multicast (whether or not they are advertising interfaces).
  609.  
  610. An interface may also cease to be an advertising interface, through
  611. actions of system management such as:
  612.  
  613.       - administratively disabling the interface,
  614.  
  615.  
  616.  
  617.  
  618. Router Discovery Working Group                                 [Page 11]
  619.  
  620. RFC 1256             ICMP Router Discovery Messages       September 1991
  621.  
  622.  
  623.       - shutting down the system, or disabling the IP forwarding
  624.         capability (i.e., changing the system from being a router
  625.         to being a host), or
  626.  
  627.       - setting the Advertise flags of all of the interface's
  628.         addresses to FALSE.
  629.  
  630.    In such cases, it is recommended (but not required) that the router
  631.    transmit a final multicast advertisement on the interface, identical
  632.    to its previous transmission but with a Lifetime field of zero.  In
  633.    the case of a router becoming a host, the system must also depart
  634.    from the all-routers IP multicast group on all interfaces on which
  635.    the router supports IP multicast (whether or not they had been
  636.    advertising interfaces).
  637.  
  638.    When the Advertise flag of one or more of an interface's addresses
  639.    are set to FALSE by system management, but there remain other
  640.    addresses on that interface whose Advertise flags are TRUE, it is
  641.    recommended that the router send a single multicast advertisement
  642.    containing only those address whose Advertise flags were set to
  643.    FALSE, with a Lifetime field of zero.
  644.  
  645. 5. Host Specification
  646.  
  647. 5.1. Host Configuration Variables
  648.  
  649.    A host that implements the ICMP router discovery messages must allow
  650.    for the following variables to be configured by system management;
  651.    default values are specified so as to make it unnecessary to
  652.    configure any of these variables in many cases.
  653.  
  654.    For each multicast interface:
  655.  
  656.    PerformRouterDiscovery
  657.                  A flag indicating whether or not the host is to perform
  658.                  ICMP router discovery on the interface.
  659.  
  660.                  Default: TRUE
  661.  
  662.    SolicitationAddress
  663.                  The IP destination address to be used for sending
  664.                  Router Solicitations from the interface.  The only
  665.                  permissible values are the all-routers multicast
  666.                  address, 224.0.0.2, or the limited-broadcast address,
  667.                  255.255.255.255.  (The all-routers address is preferred
  668.                  wherever possible, i.e., on any link where all
  669.                  advertising routers support IP multicast.)
  670.  
  671.  
  672.  
  673.  
  674. Router Discovery Working Group                                 [Page 12]
  675.  
  676. RFC 1256             ICMP Router Discovery Messages       September 1991
  677.  
  678.  
  679.                  Default: 224.0.0.2 if the host supports IP multicast on
  680.                  the interface, else 255.255.255.255
  681.  
  682.    The Host Requirements -- Communication Layers RFC [1], Section
  683.    3.3.1.6, specifies that each host implementation must support a
  684.    configurable list of default router addresses.  The purpose of the
  685.    ICMP router discovery messages is to eliminate the need to configure
  686.    that list in hosts attached to multicast links.  On non-multicast
  687.    links, and on multicast links for which ICMP router discovery is not
  688.    (yet) supported by the routers or is administratively disabled, it
  689.    will continue to be necessary to configure the default router list in
  690.    each host.  Each entry in the list contains (at least) the following
  691.    configurable variables:
  692.  
  693.    RouterAddress
  694.                  An IP address of a default router.
  695.  
  696.                  Default: (none)
  697.  
  698.    PreferenceLevel
  699.                  The preferability of the RouterAddress as a default
  700.                  router address, relative to other router addresses on
  701.                  the same subnet.  The Host Requirements RFC does not
  702.                  specify how this value is to be encoded; to allow the
  703.                  preference level to be conveyed in a Router
  704.                  Advertisement or configured by system management, it is
  705.                  here specified that it be encoded as a 32-bit, signed,
  706.                  twos-complement integer, with higher values meaning
  707.                  more preferable.  The minimum value (hex 80000000) is
  708.                  reserved to mean that the address is not to be used as
  709.                  a default router address, i.e., it is to be used only
  710.                  for specific IP destinations, of which the host has
  711.                  been informed by ICMP Redirect or configuration.
  712.  
  713.                  Default: 0
  714.  
  715. 5.2. Message Validation by Hosts
  716.  
  717.    A host must silently discard any received Router Advertisement
  718.    messages that do not satisfy the following validity checks:
  719.  
  720.       - ICMP Checksum is valid.
  721.  
  722.       - ICMP Code is 0.
  723.  
  724.       - ICMP Num Addrs is greater than or equal to 1.
  725.  
  726.       - ICMP Addr Entry Size is greater than or equal to 2.
  727.  
  728.  
  729.  
  730. Router Discovery Working Group                                 [Page 13]
  731.  
  732. RFC 1256             ICMP Router Discovery Messages       September 1991
  733.  
  734.  
  735.       - ICMP length (derived from the IP length) is greater than or
  736.         equal to 8 + (Num Addrs * Addr Entry Size * 4) octets.
  737.  
  738.    The contents of any additional words of per-address information
  739.    (i.e., other than the Router Address and Preference Level fields),
  740.    and the contents of any octets beyond the first 8 + (Num Addrs * Addr
  741.    Entry Size * 4) octets, are ignored.  Future, backward-compatible
  742.    changes to the protocol may specify additional per-address
  743.    information words, or additional octets at the end of the message;
  744.    backward-incompatible changes may use different Code values.
  745.  
  746.    An advertisement that passes the validity checks is called a "valid
  747.    advertisement".
  748.  
  749.    A host must silently discard any received Router Solicitation
  750.    messages.
  751.  
  752. 5.3. Host Behavior
  753.  
  754.    On any interface on which the host supports IP multicast, the host
  755.    will be a member of the all-systems IP multicast group (224.0.0.1).
  756.    This occurs automatically, as specified in [4]; no explicit action is
  757.    required on the part of the router discovery protocol implementation.
  758.  
  759.    A host never sends a Router Advertisement message.
  760.  
  761.    A host silently discards any Router Advertisement message that
  762.    arrives on an interface for which the host's configured
  763.    PerformRouterDiscovery flag is FALSE, and it never sends a Router
  764.    Solicitation on such an interface.
  765.  
  766.    A host cannot process an advertisement until it has determined its
  767.    own IP address(es) and subnet mask(s) for the interface on which the
  768.    advertisement is received.  (On some links, a host may be able to use
  769.    some combination of BOOTP [3], RARP [5], or ICMP Address Mask
  770.    messages [7] to discover its own address and mask.)  While waiting to
  771.    learn the address and mask of an interface, a host may save any valid
  772.    advertisements received on that interface for later processing; this
  773.    allows router discovery and address/mask discovery to proceed in
  774.    parallel.
  775.  
  776.    To process an advertisement, a host scans the list of router
  777.    addresses contained in it. It ignores any non-neighboring addresses,
  778.    i.e., addresses that do not match one of the host's own addresses on
  779.    the arrival interface, under the subnet mask associated with that
  780.    address.  For each neighboring address, the host does the following:
  781.  
  782.       - If the address is not already present in the host's default
  783.  
  784.  
  785.  
  786. Router Discovery Working Group                                 [Page 14]
  787.  
  788. RFC 1256             ICMP Router Discovery Messages       September 1991
  789.  
  790.  
  791.         router list, a new entry is added to the list, containing
  792.         the address along with its accompanying preference level
  793.         and a timer initialized to the Lifetime value from the
  794.         advertisement.
  795.  
  796.       - If the address is already present in the host's default
  797.         router list as a result of a previously-received
  798.         advertisement, its preference level is updated and its
  799.         timer is reset to the values in the newly-received
  800.         advertisement.
  801.  
  802.       - If the address is already present in the host's default
  803.         router list as a result of system configuration, no change
  804.         is made to its preference level; there is no timer
  805.         associated with a configured address.  (Note that any
  806.         router addresses acquired from the "Gateway" subfield of
  807.         the vendor extensions field of a BOOTP packet [11] are
  808.         considered to be configured addresses; they are assigned
  809.         the default preference level of zero, and they do not have
  810.         an associated timer.  Note further that any address found
  811.         in the "giaddr" field of a BOOTP packet [3] identifies a
  812.         BOOTP forwarder which is not necessarily an IP router; such
  813.         an address should not be installed in the host's default
  814.         router list.)
  815.  
  816.    Whenever the timer expires in any entry that was created as a result
  817.    of a received advertisement, that entry is discarded.
  818.  
  819.    To limit the storage needed for the default router list, a host may
  820.    choose not to store all of the router addresses discovered via
  821.    advertisements.  If so, the host should discard those addresses with
  822.    lower preference levels in favor of those with higher levels.  It is
  823.    desirable to retain more than one default router address in the list
  824.    so that, if the current choice of default router is discovered to be
  825.    down, the host may immediately choose another default router, without
  826.    having to wait for the next advertisement to arrive.
  827.  
  828.    Any router address advertised with a preference level of hex 80000000
  829.    is not to be used by the host as default router address; such an
  830.    address may be omitted from the default router list, unless its timer
  831.    is being use as a "black-hole" detection mechanism, as discussed in
  832.    Section 4.1.
  833.  
  834.    It should be understood that preference levels learned from
  835.    advertisements do not affect any of the host's cached route entries.
  836.    For example, if the host has been redirected to use a particular
  837.    router address to reach a specific IP destination, it continues to
  838.    use that router address for that destination, even if it discovers
  839.  
  840.  
  841.  
  842. Router Discovery Working Group                                 [Page 15]
  843.  
  844. RFC 1256             ICMP Router Discovery Messages       September 1991
  845.  
  846.  
  847.    another router address with a higher preference level.  Preference
  848.    levels influence the choice of router only for an IP destination for
  849.    which there is no cached or configured route, or whose cached route
  850.    points to a router that is subsequently discovered to be dead or
  851.    unreachable.
  852.  
  853.    A host is permitted (but not required) to transmit up to
  854.    MAX_SOLICITATIONS Router Solicitation messages from any of its
  855.    multicast interfaces after any of the following events:
  856.  
  857.       - The interface is initialized at system startup time.
  858.  
  859.       - The interface is reinitialized after a temporary interface
  860.         failure or after being temporarily disabled by system
  861.         management.
  862.  
  863.       - The system changes from being a router to being a host, by
  864.         having its IP forwarding capability turned off by system
  865.         management.
  866.  
  867.       - The PerformRouterDiscovery flag for the interface is
  868.         changed from FALSE to TRUE by system management.
  869.  
  870.    The IP destination address of the solicitations is the configured
  871.    SolicitationAddress for the interface.  The IP source address may
  872.    contain zero if the host has not yet determined an address for the
  873.    interface; otherwise it contains one of the interface's addresses.
  874.  
  875.    If a host does choose to send a solicitation after one of the above
  876.    events, it should delay that transmission for a random amount of time
  877.    between 0 and MAX_SOLICITATION_DELAY.  This serves to alleviate
  878.    congestion when many hosts start up on a link at the same time, such
  879.    as might happen after recovery from a power failure.  (It is
  880.    recommended that hosts include some unique value, such as one of
  881.    their IP or link-layer addresses, in the seed used to initialize
  882.    their pseudo-random number generators.  Although the randomization
  883.    range is specified in units of seconds, the actual randomly-chosen
  884.    value should not be in units of whole seconds, but rather in units of
  885.    the highest available timer resolution.)
  886.  
  887.    A host may also choose to further postpone its solicitations,
  888.    subsequent to one of the above events, until the first time it needs
  889.    to use a default router.
  890.  
  891.    Upon receiving a valid advertisement containing at least one
  892.    neighboring address whose preference level is other than hex
  893.    80000000, subsequent to one of the above events, the host must desist
  894.    from sending any solicitations on that interface (even if none have
  895.  
  896.  
  897.  
  898. Router Discovery Working Group                                 [Page 16]
  899.  
  900. RFC 1256             ICMP Router Discovery Messages       September 1991
  901.  
  902.  
  903.    been sent yet), until the next time one of the above events occurs.
  904.    The small number of retransmissions of a solicitation, which are
  905.    permitted if no such advertisement is received, should be sent at
  906.    intervals of SOLICITATION_INTERVAL seconds, without randomization.
  907.  
  908. 6. Protocol Constants
  909.  
  910.    Router constants:
  911.  
  912.          MAX_INITIAL_ADVERT_INTERVAL       16 seconds
  913.  
  914.          MAX_INITIAL_ADVERTISEMENTS        3 transmissions
  915.  
  916.          MAX_RESPONSE_DELAY                2 seconds
  917.  
  918.    Host constants:
  919.  
  920.          MAX_SOLICITATION_DELAY            1 second
  921.  
  922.          SOLICITATION_INTERVAL             3 seconds
  923.  
  924.          MAX_SOLICITATIONS                 3 transmissions
  925.  
  926.    Additional protocol constants are defined with the message formats in
  927.    Section 3, and with the router and host configuration variables in
  928.    Sections 4.1 and 5.1.
  929.  
  930.    All protocol constants are subject to change in future revisions of
  931.    the protocol.
  932.  
  933. 7. Security Considerations
  934.  
  935.    This extension of ICMP makes it possible for any system attached to a
  936.    link to masquerade as a default router for hosts attached to that
  937.    link.  Any traffic sent to such an imposter is vulnerable to
  938.    eavesdropping, to denial of forwarding service, and to modification
  939.    by insertion, deletion, or alteration of packets.  It should be noted
  940.    that, on most multicast or broadcast links on which this protocol is
  941.    expected to operate, eavesdropping is already possible by any system
  942.    attached to the link, and the Address Resolution Protocol (ARP) used
  943.    on those links offers a similar opportunity for service denial and
  944.    message stream modification.  For environments where those threats
  945.    are deemed unacceptable, there are configuration variables to disable
  946.    dynamic router discovery by hosts.
  947.  
  948.    The Router Advertisement message format is defined so as to allow
  949.    additional information to be added to the message in a backward-
  950.    compatible manner.  One possible use of that capability is to add
  951.  
  952.  
  953.  
  954. Router Discovery Working Group                                 [Page 17]
  955.  
  956. RFC 1256             ICMP Router Discovery Messages       September 1991
  957.  
  958.  
  959.    digital signatures or some other form of authentication information
  960.    to the advertisements, to enable hosts to verify their authenticity.
  961.    This is FOR FURTHER STUDY.
  962.  
  963. References
  964.  
  965.    [1] Braden, R., Editor, "Requirements for Internet Hosts --
  966.        Communication Layers", RFC 1122, USC/Information Sciences
  967.        Institute, October 1989.
  968.  
  969.    [2] Braden, R., and J. Postel, "Requirements for Internet Gateways",
  970.        RFC 1009, USC/Information Sciences Institute, June 1987.
  971.  
  972.    [3] Croft, B, and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
  973.        Stanford and SUN Microsystems, September 1985.
  974.  
  975.    [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
  976.        Stanford University, August 1989.
  977.  
  978.    [5] Finlayson, R., Mann, T., Mogul J., and M. Theimer, "A Reverse
  979.        Address Resolution Protocol", RFC 903, Stanford University, June
  980.        1984.
  981.  
  982.    [6] Mogul, J., "Broadcasting Internet Datagrams", RFC 919, Stanford
  983.        University, October 1984.
  984.  
  985.    [7] Mogul J., and J. Postel, "Internet Standard Subnetting
  986.        Procedure", RFC 950, USC/Information Sciences Institute, August
  987.        1985.
  988.  
  989.    [8] Piscitello D., and J. Lawrence, "Transmission of IP datagrams
  990.        over the SMDS Service", RFC 1209, Bell Communications Research,
  991.        March, 1991.
  992.  
  993.    [9] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
  994.        Specification", RFC 791, DARPA, September 1981.
  995.  
  996.   [10] Postel, J., "Internet Control Message Protocol - DARPA Internet
  997.        Program Protocol Specification", RFC 792, USC/Information
  998.        Sciences Institute, September 1981.
  999.  
  1000.   [11] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1084,
  1001.        USC/Information Sciences Institute, December 1988.
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Router Discovery Working Group                                 [Page 18]
  1011.  
  1012. RFC 1256             ICMP Router Discovery Messages       September 1991
  1013.  
  1014.  
  1015. Author's Address
  1016.  
  1017.        Stephen E. Deering
  1018.        Xerox Palo Alto Research Center
  1019.        3333 Coyote Hill Road
  1020.        Palo Alto, CA  94304
  1021.  
  1022.        Phone: (415) 494-4839
  1023.  
  1024.        EMail: deering@xerox.com
  1025.  
  1026.        Or send comments to gw-discovery@gregorio.stanford.edu.
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Router Discovery Working Group                                 [Page 19]
  1067.