rfc1256.txt

windows 网络编程。pdf文档

                 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.



Router Discovery Working Group                                 [Page 13]

RFC 1256             ICMP Router Discovery Messages       September 1991


      - 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

   On any interface on which the host supports IP multicast, the host
   will be a member of the all-systems IP multicast group (224.0.0.1).
   This occurs automatically, as specified in [4]; no explicit action is
   required on the part of the router discovery protocol implementation.

   A host never sends a Router Advertisement message.

   A host silently discards any Router Advertisement message that
   arrives on an interface for which the host's configured
   PerformRouterDiscovery flag is FALSE, and it never sends a Router
   Solicitation on such an interface.

   A host cannot process an advertisement until it has determined its
   own IP address(es) and subnet mask(s) for the interface on which the
   advertisement is received.  (On some links, a host may be able to use
   some combination of BOOTP [3], RARP [5], or ICMP Address Mask
   messages [7] to discover its own address and mask.)  While waiting to
   learn the address and mask of an interface, a host may save any valid
   advertisements received on that interface for later processing; this
   allows router discovery and address/mask discovery to proceed in
   parallel.

   To process an advertisement, a host scans the list of router
   addresses contained in it. It ignores any non-neighboring addresses,
   i.e., addresses that do not match one of the host's own addresses on
   the arrival interface, under the subnet mask associated with that
   address.  For each neighboring address, the host does the following:

      - If the address is not already present in the host's default



Router Discovery Working Group                                 [Page 14]

RFC 1256             ICMP Router Discovery Messages       September 1991


        router list, a new entry is added to the list, containing
        the address along with its accompanying preference level
        and a timer initialized to the Lifetime value from the
        advertisement.

      - If the address is already present in the host's default
        router list as a result of a previously-received
        advertisement, its preference level is updated and its
        timer is reset to the values in the newly-received
        advertisement.

      - If the address is already present in the host's default
        router list as a result of system configuration, no change
        is made to its preference level; there is no timer
        associated with a configured address.  (Note that any
        router addresses acquired from the "Gateway" subfield of
        the vendor extensions field of a BOOTP packet [11] are
        considered to be configured addresses; they are assigned
        the default preference level of zero, and they do not have
        an associated timer.  Note further that any address found
        in the "giaddr" field of a BOOTP packet [3] identifies a
        BOOTP forwarder which is not necessarily an IP router; such
        an address should not be installed in the host's default
        router list.)

   Whenever the timer expires in any entry that was created as a result
   of a received advertisement, that entry is discarded.

   To limit the storage needed for the default router list, a host may
   choose not to store all of the router addresses discovered via
   advertisements.  If so, the host should discard those addresses with
   lower preference levels in favor of those with higher levels.  It is
   desirable to retain more than one default router address in the list
   so that, if the current choice of default router is discovered to be
   down, the host may immediately choose another default router, without
   having to wait for the next advertisement to arrive.

   Any router address advertised with a preference level of hex 80000000
   is not to be used by the host as default router address; such an
   address may be omitted from the default router list, unless its timer
   is being use as a "black-hole" detection mechanism, as discussed in
   Section 4.1.

   It should be understood that preference levels learned from
   advertisements do not affect 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 continues to
   use that router address for that destination, even if it discovers



Router Discovery Working Group                                 [Page 15]

RFC 1256             ICMP Router Discovery Messages       September 1991


   another router address with a higher preference level.  Preference
   levels influence the choice of router only for an IP destination for
   which there is no cached or configured route, or whose cached route
   points to a router that is subsequently discovered 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 the following 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 has not yet determined an address for the
   interface; otherwise it contains one of the interface's addresses.

   If a host does choose to send a solicitation after one of the above
   events, it should delay that transmission for a random amount of time
   between 0 and MAX_SOLICITATION_DELAY.  This serves to alleviate
   congestion when many hosts start up on a link at the same time, such
   as might happen after recovery 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.  Although the randomization
   range is specified in units of seconds, the actual randomly-chosen
   value should not be in units of whole seconds, but rather in units of
   the highest available timer resolution.)

   A host may also choose to further postpone its solicitations,
   subsequent to one of the above events, until the first time it needs
   to use a default router.

   Upon receiving a valid advertisement containing at least one
   neighboring address whose preference level is other than hex
   80000000, subsequent to one of the above events, the host must desist
   from sending any solicitations on that interface (even if none have



Router Discovery Working Group                                 [Page 16]

RFC 1256             ICMP Router Discovery Messages       September 1991


   been sent yet), until the next time one of the above events occurs.
   The small number of retransmissions of a solicitation, which are
   permitted if no such advertisement is received, should be sent at
   intervals of SOLICITATION_INTERVAL seconds, without randomization.

6. Protocol Constants

   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.

7. Security Considerations

   This extension of ICMP makes it possible for any system attached to a
   link to masquerade as a default router for hosts attached to 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 on which this protocol is
   expected to operate, eavesdropping is already possible by any system
   attached to the link, and 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 deemed unacceptable, there are configuration variables to disable
   dynamic router discovery by hosts.

   The Router Advertisement message format is defined so as to allow
   additional information to be added to the message in a backward-
   compatible manner.  One possible use of that capability is to add



Router Discovery Working Group                                 [Page 17]

RFC 1256             ICMP Router Discovery Messages       September 1991


   digital signatures or some other form of authentication information
   to the advertisements, to enable hosts to 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.








Router Discovery Working Group                                 [Page 18]

RFC 1256             ICMP Router Discovery Messages       September 1991


Author's Address

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

       Phone: [phone]

       EMail: [e-mail]

       Or send comments to [e-mail].







































Router Discovery Working Group                                 [Page 19]