Network Working Group                                        W A Simpson
Internet Draft                                                Daydreamer
                          SIP System
expires in six months                                      December 1993

                        SIPP Neighbor Discovery
                    draft-ietf-sip-discovery-03.txt

Status of this Memo

   This memo is the product of the SIP SIPP Working Group of the Internet
   Engineering Task Force (IETF).  Comments on this memo should be
   submitted to the sip@caldera.usc.edu sipp@sunroof.eng.sun.com mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, ds.internic.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.

Abstract

   This document specifies ICMP messages for discusses the identification and location of adjacent SIP
   SIPP nodes.

1.  Goals

   Historically, the methods for determination of the next-hop media
   address evolved separately from those for location of neighbors or
   auto-configuration of systems.  This is intended to replace ARP,
   ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP
   Mask, and OSPF Hello in  With the SIP environment.  There are also elements advent of SIPP, the OSI ES-IS old
   techniques must be re-implemented, usually due to larger field sizes.

   Unfortunately, older implementations frequently did not take proper
   care in differentiating existing variable field lengths, version
   numbers, and IS-IS Hello.

1.  Terminology

   The following terms new types of messages.  None of the current protocols
   are readily extensible.  While some have a precise meaning when used the ability to change in
   simple terms, such as larger addresses, none were designed to add new
   kinds of information to be carried in this
   document:
   system          a device that implements the Internet Protocol, same packet.

   Therefore, the techniques used for SIPP are required to be
   distinguishable from previous IP [9].

   intermediate-system versions.  This is an opportunity to
   design a system that forwards datagrams, uniform and coherent method for accomplishing these goals.

   Find Neighbors

      Each SIPP node needs to determine the availability of other SIPP
      nodes as specified in [2].
                   Often called demand for communication occurs.

      Each SIPP host needs to detect the presence of available SIPP
      routers.

   Redirect

      A redirect is used when a router packet could be sent more directly to
      the SIPP next-hop, or gateway.  This does not include
                   systems that, though capable of forwarding, have that
                   capability turned off.  Nor does it include systems to indicate that
                   do another SIPP router should
      be used for forwarding only as required specific packets.

   Resolve Media Address

      Each SIPP node which desires to obey Source Route
                   options.

   end-system      any system that is not acting as an intermediate-system.
                   Often called a host.

   dumb send to another SIPP node needs to
      know the minimal implementation.  This appropriate media address, when the link is not meant in a
                   perjorative sense. point
      to point link.  It is intended that every mechanism
                   be defined in such a way that it is implementable on a
                   minimal system.

   smart           an improved implementation, possibly requiring more
                   internal resources, while using less external resources.

   multicast       unless otherwise qualified, means the use of either IP
                   multicast [4] or IP broadcast [6] service.

   link            a communication facility or medium over which systems
                   can communicate at efficient to learn this in the link layer; that is, same
      transaction as the protocol
                   layer immediately below IP.  The term "physical network"
                   has sometimes been used (imprecisely) for this.
                   Examples of links are LANs (possibly bridged to other
                   LANs), wide-area store-and-forward networks, satellite
                   channels, and point-to-point circuits.

   multicast link  a link over which IP multicast neighbor is found or IP broadcast service traffic is supported.  This includes broadcast media such as
                   LANs and satellite channels, single point-to-point
                   circuits, and some store-and-forward networks such as
                   SMDS networks [8].

   interface       a system's attachment point to a link.  It redirected.

   Learn Prefix

      When prefix-routing is possible
                   (though unusual) for a system to have more than one
                   interface in use, it is necessary to determine the same link.

   multicast interface
                   an interface to a multicast link; that is, an interface
                   to
      prefix(es) for a link over which IP multicast or IP broadcast
                   service is local subnet.  Local prefixes and multiple
      providers are supported.

   identifier      uniquely identifies each interface;

   Change Prefix

      When a single interface
                   may have more than one such identifier.

   primary identifier
                   uniquely identifies each system; only one such
                   identifier prefix changes, it is used, necessary to simplify discovery of neighbors.

   subnet          either a single link of a subnetted IP network [7] or
                   a single non-subnetted link.

   prefix update the part of an identifier nodes.

   Mobility

      The same mechanisms which may be support wired identification and
      location are used for routing to a particular subnet, defined by logically ANDing with
                   its assigned subnet mask.  More than one subnet prefix
                   may identify the same link.

   zone            the part of a special identifier which indicates a
                   unique subnet provide mobile beaconing and roaming within an administrative domain.

   neighbor        having an identifier belonging to the same subnet.
      clusters.

2.  Criteria

   Historically,

   Through prior experience, the methods for discovery of the next-hop evolved
   separately from those for location of neighbors and auto-
   configuration of systems.  With the advent of SIP, the old techniques
   must be re-implemented, usually due to larger field sizes.
   Unfortunately, older implementations frequently did not take proper
   care in differentiating existing variable field lengths, version
   numbers, and new types of messages.  Therefore, the techniques used
   for SIP are required to be distinguishable from previous versions.

   None of the current protocols are readily extensible.  While some
   have the ability to change in simple terms, such as larger addresses,
   none were designed to add new kinds of information to be carried in
   the same packet.

   This can be viewed is an opportunity to design a uniform and coherent
   method for accomplishing these goals, rather than a liability.

   Through prior experience, the following criteria were established, in
   order following criteria were established, in
   order of relative importance.  It is understood that many of these
   criteria may conflict, and require numerous various tradeoffs.

   Multicast support

      All SIP SIPP systems are required to support multicast.

      This is the primary technique for distinguishing the new messages.
      Older systems will ignore multicast messages at the link layer. techniques.

      There are numerous other advantages to using multicast for the new
      messages.  In particular, when compared to broadcast, reduced
      overhead for processing messages which are not ultimately intended
      for the local system.

      This is the primary technique for distinguishing the new messages.
      Older systems will discard SIPP multicast messages at the link
      layer.

      Not all media supports multicast.  Since multicast is directly
      supported by the SIP SIPP header, this technique will work even when
      using link-layer broadcast, or link-layer unicast to each
      recipient.  Older systems should discard SIPP headers at the
      network layer.

   Reduced net traffic

      Currently, there are separate packets are sent for media address resolution,
      router discovery, and the Hello protocols for the various routing
      algorithms.  Since much of the same information is contained in
      each of these packets, it would be helpful to combine the
      functions in a single packet where possible.

      Also, the most common next-hop resolution protocol, the Address
      Resolution Protocol (ARP), requires an additional two packets at
      the beginning of each connection.  The Request is sent, a Reply

      This is
      received, and then the first datagram can be sent particularly important in broadcast mobile environments,
      due to the next-hop.
      This causes a significant amount time for setup of traffic, transmission, the increased per frame
      overhead for contention resolution, and considerable
      latency in establishing a connection.

      Several alternative methods were proposed:

      1)    The ISO solution (ES-IS) eliminates some of these problems.
            Each end-system forward error correction.

   Low storage overhead

      It is desirable that systems require as little storage overhead as
      possible.  In particular, mobile nodes often have significantly
      reduced processing power and intermediate-system sends Hellos on a
            periodic basis.  Every system memory.

      A host should only retain information for those hosts with which
      it is directly communicating.

      There must remember all of the media
            addresses be sufficient storage in a host for the other systems on the local network.  This
            does eliminate the latency of ARP, information about
      at the expense least one router.  In addition, storage is required for at
      least one location of many
            additional packets sent on each service (such as a regular basis, domain name server)
      which is used.

      A router may require more processing power and memory.
      Participation in routing protocols requires the knowledge of every
      neighboring router.

      When prefix-routing is in use, it is not necessary for a large
            amount router to
      determine the location of storage overhead a host until traffic for the host
      arrives.  If prefix-routing is not used, particularly in mobile
      environments, the location of each system.

      2) reachable host must be
      retained.

   Auto-configuration

      The first packet destined connection procedures for an unknown a configuring a new system may be sent are
      reduced to the all-systems multicast, or to a media multicast based
            on a hash function minimal set of "plug it in, turn on the destination.  The appropriate
            system accepts the packet, power, and sends a redirect indicating
      run".

      -  Each node is assigned an identifier, usually within the appropriate media address number
         space assigned to be used for future packets.
            This reduces the traffic from 3 to 2 packets at local subnet.

      -  The node discovers the
            beginning of a connection, and eliminates the latency, as
            the discovery packet sent is also the data packet.  The
            destination identifer in the network header will be unicast,
            while the media address will be multicast.  Intermediate-
            systems would require extra intelligence routers attached to recognize those
            packets destined beyond the local link, while multi-homed
            end-systems require subnet, so
         that capability already.  Also, this
            method is not extensible to include other information useful
            in mobile environments.

      3)    Using advertisements for it can exchange packets with remote systems.

      -  The node discovers the (fewer) intermediate systems,
            and an ARP-like protocol for those end-system connections location of servers that are on the local media.  For those packets which are
            clearly destined off it needs for
         configuration, loading, dumping, printing, and other services.

      -  If desired, each node is assigned a name within the local media,
         domain.  The name, and the packet associated identifiers, can be sent
            directly to the appropriate intermediate system.  When most
            of the traffic is between systems that are not on
         registered in the same local media, this is very efficient.  When most of domain name server.

      In evaluating previous experience with autoconfiguration
      procedures, the
            traffic is between end-systems on following constraints were determined:

      1)    Using the 48-bit IEEE-802 number to identify one node within
            a local media (client-
            server), the extra discovery packets will be rare.

      The solution subnetwork that is detailed here is not designed to accomodate more
            than a combination of the best
      features of the preceding techniques.

      Intermediate-systems advertise their locations.  When an
      intermediate-system needs the location of an end-system, it
      requests the location of the end-system, and the end-system
      replies.  Knowledge about end-systems is concentrated in the
      intermediate-systems, but only for the few hundred systems that are actually
      communicating.

      End-systems send all datagrams directly to the intermediate-
      systems.  If there is a more direct path to the end-system,
      because considerable overkill.

            However, it is directly accessible on the local link or another
      intermediate-system would may be more appropriate, the intermediate-
      system issues a redirect.

      Also, by carrying media addresses within the advertisements and
      redirect packets, worthwhile to use an IEEE-802 number
            during initial configuration, until a further ARP-like query/response globally routable
            identifier can be avoided
      entirely.

   Low storage overhead

      It is desirable that systems require as little storage overhead as
      possible.  In particular, mobile systems often have significantly
      reduced processing power assigned.

      2)    Random identifier assignments are to be avoided.  They do
            not scale well to large networks, are difficult to track and memory.

      An end-system need only retain information
            manage, and lead to administrative confusion.

            Relying on broadcast collision resolution procedures for those end-systems
      with which it is directly communicating.

      This design requires sufficient storage
            avoiding duplicate assignments results in an end-system for
      information about at least one intermediate-system. conflicts when
            nodes occupy partitioned subnets, or are frequently powered
            down or taken off-line.

      3)    Changes of identifiers should be transparent to the human
            users.  In addition,
      storage is required particular, renumbering for at least one location changes of each service
      (such as a domain name server) which is used.

      An intermediate-system may require more processing power providers,
            and
      memory.  Participation in routing protocols requires the knowledge assignment of every neighboring intermediate-system.

      When subnet prefix-routing is in use, it is alias identifiers as a mobile node moves,
            should be automatic.

      4)    Users should not necessary for an
      intermediate-system to determine be concerned with routing prefixes, or the location of an end-system
      until traffic for
            routing methods extant on the end-system arrives.  If prefix-routing is
      not local network.  When used, particularly in radio and mobile environments, the
      location of each reachable end-system must be continuously
      retained.

   Auto-configuration

      It would
            such prefixes should be highly desirable that the connection procedures for a
      configuring a new system are reduced to the minimal set of "plug
      it in, turn on the power, and run".

      -  Each system, or more precisely each interface, should be
         assigned an identifier, within the number space assigned to the
         local subnet.

      -  Each system should be assigned a name within the local domain.
         The name, automatically determined, and the associated identifiers, should be registered
         in the local domain name server.

      -  The system should discover the external routes provided by the
         intermediate-systems attached to the local subnet, so that it
         can exchange packets with remote systems.

      -  The system
            dynamic changes should discover the location of servers that it
         needs for configuration, loading, dumping, printing, and other
         services.

      In evaluating previous experience with autoconfiguration
      procedures, the following constraints were determined:

      1) propagate automatically.

      5)    It is not possible to embed an IEEE-802 component within
            every SIP identifier, since the remaining prefix would be
            too small for global routing.  Using the 48-bit IEEE-802
            number to identify one system within a local network that is
            not designed to accomodate more than a few hundred systems
            is considerable overkill.  It may be worthwhile to use the
            address during initial configuration.

      2)    Random identifier assignments are to be avoided.  They do
            not scale well to large networks, are difficult to track and
            manage, and lead important to administrative confusion.  Relying on
            broadcast collision resolution procedures for avoiding
            duplicate assignments results in conflicts when systems
            occupy partitioned subnets, or are frequently powered down
            or taken off-line.

      3)    Reassignment of identifiers should be transparent to the
            human users.  In particular, renumbering, and assignment of
            alias identifiers as a mobile system moves should be
            automatic.

      4)    End-system users should not be concerned with routing
            prefixes, or the routing methods extant on the local
            network.  When used, such prefixes should be automatically
            determined, and dynamic changes should propagate
            automatically.

      5)    It is important to allow users allow users to choose a system name which
            is memorable and comfortable to them.  The name should be
            automatically registered, and changes to the associated
            identifers should be maintained automatically.

      This design handles initial self-identification and propagation of
      changes in identification.  Other aspects of configuration, such
      as loading the operating system and environment, and additional
      facilities and servers for registration, are specified elsewhere.

   Mobility support

      This is sometimes considered a subset of the above, as related to
      dynamically changing addresses while moving.  Other systems must
      be notified of the changes.

      In addition, the "hidden transmitter" problem is considered (you
      can hear another system, it can't hear you, but there is a path to
      a third system which it can hear, completing the circuit).  This
      is not well supported in any of the past protocols.

      Although basic support for mobility is provided, descriptions of
      additional facilities and servers are specified elsewhere.

   Black hole detection

      In determining whether the next-hop system is still available,
      there is a basic tradeoff between frequent queries and resources
      used.  This design trades fewer queries against more information
      within each query and response.

      Explicit holding times are used to limit the exposure to black
      holes.  The times may be dynamically shortened by the responsible
      system when a resource is critical, or when the system is actively
      moving.

   Media independence

      There are many instances where system discovery is accomplished
      differently over different media, such as point-to-point versus
      broadcast versus Large Public Data Networks.  This design places
      the system discovery above the network layer, where it enjoys
      greater independence.  It also encompasses media level redirects
      between multiple logical subnets on the same physical media.

      There are difficulties with carrying media addresses within
      packets, especially in the presence of multi-media bridges.
      Rather than allowing translation by bridges in the path, this
      design exercizes control at the destination system, and requires
      all such media addresses to be in canonical form,

   Optimal route determination

      This is essentially a superset of next-hop discovery, combined
      with resource reservation and possible policy considerations, and
      the ability to redirect traffic under changing conditions.  This
      is not well supported in any of the past protocols.

      To balance system overhead against network traffic, this design
      attempts to adapt to a continuum of system capabilities.  Dumb
      end-systems may simply send packets to a default intermediate-
      system, and be redirected to the correct next-hop by more capable
      intermediate-systems.  Smarter end-systems learn sufficient
      information to make informed choices.

   Simplicity

      All of the above desires, and they want to keep it simple, too.
      This design reduces the number of packet types which must be
      supported in a pure SIP system, and reduces the number of systems
      which recognize and respond to each type.  The extensions are
      designed with 32 and 64 bit boundaries for efficient processing.

3.  Design Overview

   This proposal describes two packets, not much different from those
   already deployed.  These familiar forms are re-packaged to join
   common functions into the same packet to reduce traffic, and are
   designed to be more extensible in the future.

   In order to foster media independence, the packets are part of ICMP,
   which allows the protocols to be used over broadcast, multicast,
   partial-mesh, and point-to-point media.  This is similar to the
   positioning of ES-IS.

   The Where-Are-You solicitation is used to find other systems, and
   associated resources and services.  General solicitations are sent
   when a system interface is initialized.  Specific solicitations are
   sent when one system is ready to communicate with another particular
   system.

   The I-Am-Here advertisement is the answer to the Where-Are-You
   solicitation.  Advertisements are also sent on a periodic basis to
   indicate special resources and services.  Periodic advertisements
   from a few commonly requested systems result in less traffic than
   repeated solicitations from many systems.

   Each advertisement includes a lifetime field, specifying the maximum
   length of time that the advertisements are to be considered valid in
   the absence of further advertisements.  This ensures that other
   systems eventually forget about systems that become unreachable,
   whether that is because the system has failed, or it no longer
   provides the advertised service.

   Each message contains "optional" extensions, designed to allow
   flexibility and extensibility.

   One of the common extensions is the media address.  Each message
   contains enough information to return a reply directly to the sender,
   without additional location traffic.

   Another common extension is a list of the intermediate-systems which
   have been heard.  This allows intermediate-systems to build a map of
   the paths between intermediate-systems, and between intermediate-
   systems and end-systems.  This is designed to be used by most
   commonly deployed routing protocols.  This also solves the "hidden
   transmitter" problem, when used together with the well-known link-
   state class of routing protocols.

   Several methods of routing are supported.

3.1.  System Identification

   Zone

      A Zone is defined to be a collection of links which may be
      accessed as the same next-hop.  A Zone is usually a single link,
      or a collection of bridged links.  When a single intermediate-
      system is connected to multiple point-to-point links, these links
      may be collected into a single zone.

      The Zone number is a fixed size.  The value 0 is only used to
      indicate the local zone.  The values 1 through 255 indicate each
      zone within an administrative domain.

      Zone numbers may be combined with an interface media address to
      make a locally significant identifier.  This is useful for initial
      configuration and local communication within the administrative
      domain.  These identifiers may be routed in a similar manner to
      prefix-routed subnets.

      The generation of these local identifiers depends upon the
      availability of a registered unique number, such as an IEEE-802
      number.  When there is no IEEE-802 number to be found anywhere in
      the machine, such as when the machine is connected exclusively to
      point-to-point links, an external link-level mechanism MUST be
      used to negotiate a unique identifier.  Such a mechanism is beyond
      the scope of this document.

   Prefix

      A Prefix is similar to a Zone, in that it identifies a collection
      of links which may be accessed as the same next-hop.  The Prefix
      may indicate a single zone, a collection of zones, an entire
      administrative domain, or a collection of administrative domains.

      The Prefix is variable in size.  The Prefix Size ranges from 1 to
      62.  The value of 63 cannot be used, since at least 2 bits of the
      SIP 64-bit identifier are reserved to identify a particular
      system.

      Prefix-routed subnet identifiers are supported for addressing
      globally connected networks in the metropolitan and/or provider
      addressing models.

   End-Point Identifiers

      End-Point identifiers, or any other globally unique identifier,
      may be used with future routing techniques.  An End-Point
      Identifier is indicated as having a Prefix Size of 0.  A mobile
      system may be treated as having an End-Point Identifier when it
      appears in a prefix-routed subnet, since it will not have the same
      prefix as other systems in the subnet.

   Facilities are provided for exchange of redirects and translation
   between the various forms of identifiers.

3.2.  Multicast Support

   Every SIP system MUST join the all-systems multicast group on all
   interfaces on which the system supports multicast.

   Every SIP intermediate-system MUST also join the all-routers
   multicast group.

   Every SIP end-system which offers a particular service MUST also join
   the multicast group for that service.  Intermediate-systems do not
   join the service multicast group, as their services are discovered
   under a separate process.

4.  Intermediate-System Discovery

   Before an end-system can send datagrams beyond its directly attached
   link, it must discover the location of at least one operational
   intermediate-system on that link.  This is accomplished through
   intermediate-system advertisement messages.

   The intermediate-system advertisements also serve to indicate zone
   and subnet prefixes for each link, and to establish neighbor
   relationships with other intermediate-systems.

   Each intermediate-system periodically sends the I-Am-Here message to
   advertise its forwarding capability.  End-systems and intermediate-
   systems discover the location of their neighboring intermediate-
   systems simply by listening for the advertisements.  This eliminates
   the need for manual configuration of intermediate-system addresses
   and is independent of any specific routing protocol.

   The advertisement messages do not constitute a routing protocol,
   although they might be used by a routing protocol to build a map.
   They enable systems to discover the existence of neighboring
   intermediate-systems, but not necessarily which intermediate-system
   is best to reach a particular destination.  If a system chooses a
   poor intermediate-system for a particular destination, it should
   receive a redirect from that intermediate-system.

   However, the advertisements often contain sufficient information to
   make a good choice of first-hop.  This may be important for choosing
   among intermediate-systems which are participating in a security
   group or policy-based routing.

4.1.  Solicitations

   Every SIP end-system MUST implement Intermediate-System Solicitation.

   When any end-system starts up, it MUST send the Where-Are-You
   solicitation to prompt the advertisement of intermediate-systems.
   This is also used by the intermediate-systems to construct a map of
   accessible end-systems, to discover partitions in the local subnet,
   and to support mobile systems.

   If (and only if) no advertisements from neighboring intermediate-
   systems are forthcoming, the end-system MAY retransmit the Where-
   Are-You a small number of times, but then MUST desist from sending
   more solicitations.

   Any intermediate-systems that subsequently start up, or that were not
   discovered because of packet loss or temporary link partitioning, are
   eventually discovered by reception of their periodic (unsolicited)
   advertisements.  Links that suffer high packet loss rates or frequent
   partitioning are accommodated by increasing the rate of
   intermediate-system advertisements, rather than increasing the number
   of solicitations that end-systems are permitted to send.

4.1.1.  Constants

      MAX_SOLICITATIONS                 3 transmissions

      MAX_SOLICITATION_DELAY            1 second

      SOLICITATION_INTERVAL             3 seconds

4.1.2.  Implementation

   The intermediate-system solicitation is sent to the all-routers
   multicast, with the scope set to local.

   An end-system is required to transmit up to MAX_SOLICITATIONS Where-
   Are-You messages from any of its 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 has its forwarding capability turned off by system
      management.

   If a system chooses to send a solicitation after one of the above
   events, it should delay transmission for a random amount of time
   between 0 and MAX_SOLICITATION_DELAY.  This serves to alleviate
   congestion when many systems start up on a link at the same time,
   such as might happen after recovery from a power failure.

   It is recommended that systems include some unique value (such as one
   of their interface or link-layer identifiers) 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.

   The small number of retransmissions of a solicitation, which are
   permitted if no advertisement is received, should be sent at
   intervals of SOLICITATION_INTERVAL seconds, without further
   randomization.

   Upon receiving a valid advertisement from any intermediate-system
   subsequent to one of the above events, the system MUST NOT send any
   solicitation on that interface (even if none have been sent yet)
   until the next time one of the above events occurs.

4.1.3.  Receipt

   An end-system MUST silently discard any received Intermediate-System
   Solicitation messages.

   An intermediate-system MUST silently discard any received
   Intermediate-System Solicitation messages that do not satisfy the
   following validity checks:

   -  ICMP Checksum is correct.

   -  ICMP length (derived from the payload length) is 16 or more
      octets.

   -  Source Address is either 0 or the identifier of a neighbor (an
      identifier that matches one of the intermediate-system's own
      identifiers on the arrival interface under the prefix mask
      associated with that identifer, or the zone associated with that
      interface).

4.2.  Advertisements

   Every SIP intermediate-system MUST implement Intermediate-System
   Advertisements.

   The intermediate-system advertisements include such important
   information as the media address to access the system, other subnets
   directly accessible through the system, services available through
   the system, and neighboring intermediate-systems heard.

   Identifiers

      Each intermediate-system advertisement includes one or more
      identifier fields.  These indicate the identifiers which are
      presently in use for each interface of the intermediate-system.

   Zone

      Each advertised identifier includes a zone field.  The value
      ranges from 0 to 255, and indicates a subnet number which is
      unique to the administrative domain.  A value of zero indicates
      that no zone number has been assigned.  It may be combined with an
      interface media address to make a locally significant identifier.

      If all advertised zone values are zero, then zone routing is not
      available beyond that link.  This does not prevent the use of
      locally significant identifiers for communication with other
      systems on the local link.

   Prefix Size

      Each advertised identifier includes a prefix size field.  The
      value ranges from 0 to 62, and indicates the number of bits in the
      Identifier which define the prefix mask for the link.  A value of
      zero indicates an end-point identifier.  When the value is not
      zero, the identifier may be used to discern prefix-routed subnet
      mapping.

      If all advertised prefix values are zero, then subnet prefix-
      routing is not in use on that link.

   Preference

      Each advertised identifier includes a preference field.  This is
      used to choose a default intermediate-system for the first-hop
      when the end-system has not yet been redirected or configured to
      use a specific intermediate-system for a particular destination.
      The end-system is expected to choose from those intermediate-
      systems that have the highest preference level for the best
      prefix-routing match.  When there is no match, or prefix-routing
      is not in use, the preference value is used alone.

      A network administrator can configure intermediate-system
      preference levels to encourage or discourage the use of particular
      intermediate-systems as the default first-hop.  The use of
      separate preferences per prefix allows the choice of different
      intermediate-systems for each prefix, when there are multiple
      prefixes in use for the same link.  This may be useful where
      multiple organizations share resources.

      [I am not sure how this works when there are multiple identifiers
      per end-system interface.]

      The preference value is not the same as the "metric" used in many
      routing protocols.  It is used only by end-systems in determining
      the default first-hop, rather than by intermediate-systems in
      choosing a link for transit traffic.  The values are not additive.
      Therefore, the range of values is smaller, and a higher value
      indicates a higher preference.

      It should be understood that preference levels learned from
      intermediate-system advertisements do not affect any system's
      cached route entries.  For example, if a system has been
      redirected to use a particular intermediate-system to reach a
      specific destination, it continues to use that intermediate-system
      for that destination, even if it discovers another intermediate-
      system identifier with a higher preference level.  Preference
      levels influence the choice of intermediate-system only for a
      destination for which there is no cached or configured route, or
      whose cached route points to an intermediate-system that is
      subsequently determined to be unreachable.

4.2.1.  Constants

      MAX_INITIAL_ADVERTISEMENTS        3 transmissions

      MAX_INITIAL_ADVERT_INTERVAL      16 seconds

      MAX_RESPONSE_DELAY                2 seconds

4.2.2.  Configuration

   An intermediate-system MUST allow the following variables to be
   configured by system management.  Default values are specified which
   make it unnecessary to re-configure these variables in most cases.

   For each interface:

   MaxAdvertisementInterval

      The maximum time (in seconds) allowed between sending
      intermediate-system advertisements from the interface.  Must be no
      less than 4 seconds and no greater than 1800 seconds.

      Default: 600 seconds

   MinAdvertisementInterval

      The minimum time (in seconds) allowed between sending unsolicited
      intermediate-system advertisements from the interface.  Must be no
      less than 1 second and no greater than MaxAdvertisementInterval.

      Default: 0.75 * MaxAdvertisementInterval

   AdvertisementLifetime

      The value (in seconds) to be placed in the Lifetime field of
      intermediate-system advertisements sent from the interface.  Must
      be no less than MaxAdvertisementInterval and no greater than 9000
      seconds.

      Default: 3 * MaxAdvertisementInterval

   For each of the identifiers of each interface:

   Advertise

      A flag indicating whether or not the identifier is to be
      advertised.

      Default: TRUE

   PreferenceLevel

      The preferability of the interface as a default intermediate-
      system choice, relative to other intermediate-system interfaces
      serving the same prefix on the same link.

      Values are in the range 0 to 255.  Higher values mean more
      preferable.  The minimum value 0 is used to indicate that the
      identifier, even though it may be advertised, is not to be used by
      neighboring end-systems as a default intermediate-system address.

      Default: 1

   It is useful to configure an identifier with a preference level of 0
   (rather than simply setting its Advertise flag to FALSE) when
   advertisements are being used for "black hole" detection.  In
   particular, an intermediate-system that is to be used to reach only
   specific destinations could advertise a preference level of 0 (so
   that neighboring end-systems will not use it as a default
   intermediate-system for reaching arbitrary destinations) and a non-
   zero lifetime (so that neighboring end-systems that have been
   redirected or configured to use it can detect its failure by timing
   out the reception of its advertisements).

   It has been suggested that, when the preference level of an
   identifier has not been explicitly configured, an intermediate-system
   could set it according to the metric of the intermediate-system's
   "default route" (if it has one), rather than defaulting as suggested
   above.  Thus, an intermediate-system with a better metric for its
   default route would advertise a higher preference level for its
   identifier.  (Note that routing metrics that are encoded such that
   "lower is better" would have to be inverted before being used as
   preference levels in intermediate-system advertisement messages.)
   Such a strategy might reduce the amount of redirect traffic on some
   links by making it more likely that an end-system's first choice 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 such a strategy would result in
   more redirect traffic (on links from which the most frequently chosen
   destinations are best reached via intermediate-systems other than the
   one with the best default route).  Also, since the routing algorithms
   learn of neighboring intermediate-systems from the advertisements,
   and the default routes are learned from the routing algorithms, the
   calculated preference may be unstable from time to time.  This
   document makes no recommendation concerning this issue, and
   implementors are free to try such a strategy, as long as they also
   support static configuration of preference levels as specified above.

4.2.3.  Implementation

   The intermediate-system advertisement is sent to the all-systems
   multicast, with the scope set to local.

   The term "advertising interface" refers to any functioning and
   enabled interface that has at least one identifier whose configured
   Advertise flag is TRUE.

   From each advertising interface, the system MUST transmit periodic
   I-Am-Here messages.

      CONTROVERSIAL:

      When an intermediate-system discovers that it is receiving its own
      advertisements, that is an indication that it has more than one
      interface on same link.  The system MUST choose only one
      advertising interface for each link.  Identifiers associated with
      the remaining interfaces on the same link are indicated with the
      Other-Identifier extension.  Redirect is used to move specific
      traffic to the alternate interfaces.

      An intermediate-system MAY proxy for the identifers of other
      systems, using the Other-Identifier extension.  This SHOULD only
      be used when the intermediate-system is translating to another
      network-layer protocol format.

   The advertisements are not strictly periodic.  The interval between
   subsequent transmissions is randomized to reduce the probability of
   synchronization with the advertisements from other intermediate-
   systems on the same link.  This is done by maintaining a separate
   transmission interval timer for each advertising interface.  Each
   time an advertisement is sent from an interface, that interface's
   timer is reset to a uniformly-distributed random value between the
   configured MinAdvertisementInterval and MaxAdvertisementInterval.
   Expiration of the timer causes the next advertisement to be sent, and
   a new random value to be chosen.

   It is recommended that intermediate-systems include some unique value
   (such as one of their interface 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 sent from an interface (up to
   MAX_INITIAL_ADVERTISEMENTS), if the randomly chosen interval is
   greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to
   MAX_INITIAL_ADVERT_INTERVAL instead.  Using this smaller interval for
   the initial advertisements increases the likelihood of an
   intermediate-system being discovered quickly when it first becomes
   available, in the presence of possible packet loss.

   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 identifiers whose Advertise flag is TRUE,

   -  enabling SIP forwarding capability (changing the system from an
      end-system to an intermediate-system), when the interface has one
      or more identifiers whose Advertise flag is TRUE,

   -  setting the Advertise flag of one or more of the interface's
      identifiers to TRUE (or adding a new identifier with a TRUE
      Advertise flag), when previously the interface had no identifier
      whose Advertise flag was TRUE.

   In such cases, the intermediate-system 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 an end-system becoming
   an intermediate-system, the system must also join the all-routers
   multicast group on all interfaces on which the intermediate-system
   supports 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:

   -  shutting down the system,

   -  administratively disabling the interface,

   -  disabling SIP forwarding capability (changing the system from an
      intermediate-system to an end-system),

   -  setting the Advertise flags of all of the interface's identifiers
      to FALSE.

   In such cases, the intermediate-system SHOULD transmit a final
   multicast advertisement on the interface, identical to its previous
   transmission, but with a Lifetime field of zero.  In the case of an
   intermediate-system becoming an end-system, the system must also
   depart from the all-routers multicast group on all interfaces on
   which the intermediate-system supports multicast (whether or not they
   had been advertising interfaces).

   When the Advertise flag of one or more of an interface's identifiers
   are set to FALSE by system management, but there remain other
   identifiers on that interface whose Advertise flags are TRUE, the
   intermediate-system SHOULD send a single multicast advertisement
   containing only those identifiers whose Advertise flags were set to
   FALSE, with a Lifetime field of zero.

   In addition to the periodic unsolicited advertisements, an
   intermediate-system MUST send advertisements in response to valid
   advertisements or solicitations received on any of its advertising
   interfaces.  If the advertisement or solicitation does not contain
   any System-Heard extension, and the time since the previous
   advertisement is greater than MAX_INITIAL_ADVERT_INTERVAL, the
   intermediate-system MUST multicast an advertisement from that
   interface.

   Whenever these response advertisements are sent, the advertisement
   MUST be delayed for a small random interval not greater than
   MAX_RESPONSE_DELAY, in order to prevent synchronization with other
   responding intermediate-systems, and to allow multiple closely-spaced
   solicitations to be answered with a single advertisement.  The
   interface's interval timer is reset to a new random value, as with
   unsolicited advertisements.

4.2.4.  Receipt

   All systems MUST silently discard any received Intermediate-System
   Advertisement messages that do not satisfy the following validity
   checks:

   -  ICMP Checksum is correct.

   -  ICMP length (derived from the payload length) is 16 or more
      octets.

   -  At least one Routing-Information extension.

   -  For interfaces which are not point-to-point links, the Media-
      Access extension.

4.3.  Processing Advertisements

   Every intermediate-system saves the information contained in the
   advertisements, in order to respond to future requests.  Any other
   action on receipt of such messages by an intermediate-system (for
   example, as part of a "peer discovery" process) is beyond the scope
   of this document.

   An end-system saves the information contained in the advertisements,
   in order to determine the first-hop when sending datagrams.  First-
   hop determination is elaborated in a subsequent section.

4.3.1.  Configuration

   The Host Requirements -- Communication Layers [1], Section 3.3.1.6,
   specifies that each end-system must support a configurable list of
   default intermediate-system identifiers.  The purpose of the
   intermediate-system discovery messages is to eliminate the need to
   configure that list.  On links for which intermediate-system
   discovery is administratively disabled, it MAY continue to be
   necessary to configure the default intermediate-system list in each
   end-system.

   Each entry in the list contains (at least) the following configurable
   variables:

   RouterAddress

      An identifier of a default intermediate-system.

      Default: (none)

   PreferenceLevel

      The preferability of the RouterAddress as a default intermediate-
      system choice, relative to other intermediate-system interfaces
      serving the same prefix on the same link.  The Host Requirements
      RFC does not specify how this value is to be encoded.  The values
      used here are defined above.

      Default: 255

4.3.2.  Implementation

   To process an Intermediate-System Advertisement, an end-system scans
   the list of Routing-Information extensions contained in it.  For each
   identifier, the end-system does the following:

   -  If the prefix size is not zero, the identifier and prefix size are
      compared against any identifiers associated with the interface on
      which the message was received.  If there is a match, the
      interface prefix size is set to the advertised prefix size.

   -  If the identifier is not already present in the end-system's
      intermediate-system list, a new entry is added to the list,
      containing the identifier along with its accompanying preference
      level, and a timer initialized to the Lifetime value from the
      advertisement.

   -  If the identifier is already present in the end-system's
      intermediate-system list as a result of a previously-received
      advertisement, its preference level is updated and its timer is
      reset to the value in the newly-received advertisement.

   -  If the identifier is already present in the end-system's
      intermediate-system list as a result of system configuration, no
      change is made to its preference level.  There is no timer
      associated with a configured identifier.

   -  If a Media-Access extension is present, the intermediate-system
      list is updated with the location information.

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

      Note that any intermediate-system identifiers acquired from the
      "Gateway" subfield of the vendor extensions field of a BOOTP
      packet [11] are considered to be configured identifiers; they are
      assigned the default preference level of 255, and they do not have
      an associated timer.

      Note further that any identifier found in the "giaddr" field of a
      BOOTP packet [3] identifies a BOOTP forwarder which is not
      necessarily a SIP intermediate-system; such an identifier should
      not be installed in the end-system's default intermediate-system
      list.

   To limit the storage needed for the default intermediate-system list,
   an end-system MAY choose not to store all of the intermediate-system
   identifiers discovered via advertisements.  The end-system SHOULD
   discard those identifiers with lower preference levels in favor of
   those with higher levels.  It is desirable to retain more than one
   default intermediate-system identifier in the list; if the current
   choice of default intermediate-system is discovered to be down, the
   end-system may immediately choose another default intermediate-system
   without having to wait for the next advertisement to arrive.

   Any intermediate-system identifier advertised with a preference level
   of zero is not to be used by the end-system as default intermediate-
   system identifier.  Such an identifier may be omitted from the
   default intermediate-system list, unless its timer is being use as a
   "black-hole" detection mechanism.

5.  End-System Discovery

   Within a directly attached link, each system must be able to locate
   end-systems with which it desires to communicate.  This is
   accomplished using the Where-Are-You and I-Am-Here messages described
   below.  This is independent of any specific media.

   When an intermediate-system needs the location of an end-system, it
   sends the Where-Are-You solicitation.  The target end-system responds
   with the I-Am-Here advertisement.

   When no intermediate-system advertisements have been heard, an end-
   system sends the Where-Are-You solicitation itself.  The target end-
   system responds with the I-Am-Here advertisement as usual.

   When an end-system has heard one or more intermediate-system
   advertisements, the default behavior is to send all datagrams to the
   preferred intermediate-system.  If the target end-system is
   accessible on the local link, the intermediate-system sends a
   redirect back indicating the appropriate media address.

   When an end-system has heard one or more intermediate-system
   advertisements, and no zone or prefix-routing is being used, or no
   prefix matches any current interface identifier, the end-system can
   assume that it is operating as a mobile end-system.  The mobile end-
   system advertises on a periodic basis, just as an intermediate-
   system.

5.1.  Solicitations

   Every SIP system MUST implement End-System Solicitation for discovery
   of local end-systems.

   When a system is ready to send a datagram to another system, it
   examines its cache of system locations.  If no intermediate-system
   advertisements have been received, the system MUST send the Where-
   Are-You solicitation to prompt the advertisement of the target
   system.

   If (and only if) no advertisements from the target system are
   forthcoming, the system MAY retransmit the Where-Are-You a small
   number of times, but then MUST desist from sending more
   solicitations.

5.1.1.  Implementation

   The end-system solicitation is sent to the all-systems multicast.

   The end-system solicitations use the same configuration constants as
   intermediate-system solicitations.

   Unlike intermediate-system solicitations, end-system solicitations
   are sent only when a particular end-system location is needed, rather
   than on startup.

   End-system solicitations are sent using the same periodicity
   calculations as intermediate-system solicitations.

   Upon receiving a valid advertisement from any intermediate-system, an
   end-system MUST NOT send any end-system solicitations.

5.1.2.  Receipt

   An intermediate-system MUST silently discard any received End-System
   Solicitation messages.

   An end-system MUST silently discard any received End-System
   Solicitation messages that do not satisfy the following validity
   checks:

   -  ICMP Checksum is correct.

   -  ICMP length (derived from the payload length) is 16 or more
      octets.

   -  Source Address is either 0 or the identifier of a neighbor (an
      identifier that matches one of the end-system's own identifiers on
      the arrival interface under the prefix mask associated with that
      identifer, or the zone associated with that interface).

5.2.  Advertisements

   Every SIP end-system MUST implement End-System Advertisements.

   Usually, end-system advertisements are sent in response to end-system
   solicitations.  In addition, mobile end-system advertisements and
   service end-system advertisements (described below) are sent on a
   periodic basis.

   The end-system advertisements include such important information as
   the media address to access the system, and neighboring
   intermediate-systems heard.

5.2.1.  Implementation

   The periodic mobile end-system advertisement is sent to the all-
   routers multicast.

   The single end-system advertisement in respnse to a solicitation is
   sent to the all-systems multicast.

   In either case, the scope is set to local.

      CONTROVERIAL: The all-systems multicast is used for end-system
      advertisements, rather than responding directly to the soliciting
      system.  This is under the assumption that all intermediate-
      systems need to update the list of active end-systems, when the
      query is sent by a router.  Logically, the response could be sent
      to all-routers.

      However, when the query is sent by an end-system, there are no
      routers present.  The response could be sent directly to the
      requesting end-system.

      There is no easy way to determine that the sender was an
      intermediate-system rather than an end-system.  The only multicast
      which covers both cases is all-systems.

   Mobile advertisements use similar configuration constants and
   variables as intermediate-system advertisements.

   Mobile advertisements are sent using the same periodicity
   calculations as intermediate-system advertisements.

   Advertising interfaces are established and terminated in the same
   manner as intermediate-system advertisements.

6.  Service Discovery

   Each system offering one of the special configuration services
   detailed below, whether an end-system or intermediate-system,
   includes that service availability in every advertisement that it
   sends.  All systems discover the location of these services simply by
   listening for the advertisements.  This eliminates the need for
   manual configuration, periodic probes, and special handling of
   certain packet types by intermediate-systems.

   The learned service information is included in any neighboring
   intermediate-system advertisements.  In this fashion, the
   intermediate-system advertisements provide a summary of all available
   network services, and pass information beyond the link where the
   advertisement originated.  This results in a reduction of network
   traffic when compared to the broadcast or multicast of service
   discovery requests/replies over a wide area.

   The initial services listed here are primarily concerned with
   configuration.  The locations of other facilities may be learned from
   these basic servers.

   Domain Name Service

      Before a system can communicate with another system, it must learn
      that system's identifiers and location.  The Domain Name System
      (DNS) is usually used for this purpose.

      In the past, this was accomplished by reading a list of servers
      from a (possibly remote) configuration file at startup time.  Some
      systems discovered servers by sending periodic probes to a
      broadcast or multicast address.  Both of these methods have
      serious drawbacks.  Configuration files must be maintained
      manually (a significant administrative burden when ther are large
      numbers of systems), and are unable to track dynamic changes in
      DNS availability.  Periodic probes are restricted from using
      recursion (see Host Requirements -- Application and Support [2],
      Section 6.1.3.2), and are thus limited to information about the
      local domain.

      In practice, only systems which are users or stub resolvers of the
      DNS can use the DNS server advertisements.  Full-Service resolvers
      MUST continue to be manually configured to ensure a heirarchy of
      believability within the network.

   Self-Configuration Service

      Before a system can communicate with another system, it must learn
      its own identity.  The Bootstrap Protocol (BOOTP) is frequently
      used for this purpose.

      In the past, this was accomplished by ad hoc passing of BOOTP
      requests by routers.  This method has several serious drawbacks.
      Presence of the feature cannot be relied upon.  It is not of much
      use for mobile, roving or portable systems.

6.1.  Solicitations

   Every SIP end-system SHOULD implement End-System Solicitation for
   discovery of local services.

   When a system is ready to use a particular service, it examines its
   cache of such services.  If no intermediate-system or other service
   advertisements have been received, the system MAY send the Where-
   Are-You solicitation to prompt the advertisement of the service.

   If (and only if) no advertisements from desired services are
   forthcoming, the system MAY retransmit the Where-Are-You a small
   number of times, but then MUST desist from sending more
   solicitations.

6.1.1.  Implementation

   The service solicitation is sent to the special multicast for each
   particular service, with the scope set to local.

   The service solicitations use the same configuration constants as
   intermediate-system and end-system solicitations.

   Unlike intermediate-system solicitations, service solicitations are
   sent only when a particular service is utilized, rather than on
   startup.

   Service solicitations are sent using the same periodicity
   calculations as intermediate-system and end-system solicitations.

   Upon receiving a valid advertisement from any intermediate-system,
   the system MUST NOT send any service solicitation.

   Service solicitations require the same validity checks as end-system
   solicitations.

6.2.  Advertisements

   Like intermediate-system and mobile end-system advertisements,
   service end-systems advertisements are sent on a periodic basis.

   Services offered by intermediate-systems are included in the
   intermediate-system advertisements described above.

6.2.1.  Implementation

   The service advertisement is sent to the all-systems multicast, with
   the scope set to local.

      CONTROVERIAL: The all-systems multicast is used for service
      advertisements, rather than different multicasts for each service.
      This is under the assumption that all systems need to learn of
      services.

      This corresponds to the design for intermediate-system
      advertisements.  Thus, intermediate-system advertisements can be
      viewed as a special case of service advertisements.

      This ensures that the design will operate when there are no
      routers, and when the routing protocols are still initializing.

   The service advertisements use similar configuration constants and
   variables as intermediate-system advertisements.

   Service advertisements are sent using the same periodicity
   calculations as intermediate-system advertisements.

   Advertising interfaces are established and terminated in the same
   manner as intermediate-system advertisements.

   When any system ceases to offer an advertised service, the system
   SHOULD transmit a final multicast advertisement on the interface,
   identical to its previous transmission, but with a Lifetime field of
   zero.

7.  Self Discovery

7.1.  End-Systems

   At startup, each SIP end-system solicits the advertisements of
   intermediate-systems, as described in Intermediate-System Discovery
   above.  Until an intermediate-system is discovered, an end-system is
   limited to accessing systems and services for the links to which it
   is directly attached.

   In the absence of an intermediate-system, each SIP end-system
   solicits the advertisements of services as described in Service
   Discovery above.  Until self-configuration services are discovered,
   an end-system is limited to accessing systems and services according
   to prior configuration.

7.1.1.  Zone Determination

   Until an intermediate-system is discovered, an end-system assumes a
   zone number of zero.  When combined with any IEEE-802 number found in
   the machine, or other identifier negotiated at the link level, this
   yields a local identifier which is unique to the system.

   When an intermediate-system is discovered, the advertisements are
   examined for zone information, as described in Intermediate-System
   Discovery above.  If all advertised zone values are zero, then zone
   routing is not available beyond that link.  If more than one zone
   number is discovered for the same interface, only the highest zone
   number is used.

   When there is more than one interface on a multi-homed end-system,
   each interface MUST answer to all of the local identifers generated.

   When more than one IEEE-802 number is available, the primary system
   identifier is composed of the highest zone discovered, combined with
   the highest IEEE-802 number found.

7.1.2.  Initialization

   Once a system has becomed locally addressable, it can engage in
   exchanges with local servers.  Some of these local servers could be a
   bootstrap service, for loading and configuring the system.  Another
   server could be a registration service, in charge of managing the
   local name and identifier space.

   When the registration service is unable to find a match for the
   system, the system SHOULD request the operator to provide a name for
   the system.  The registration service would be responsible for
   ensuring uniqueness, and assigning appropriate identifiers for the
   name.

   Further specification of such services is beyond the scope of this
   document.

7.1.3.  Identifier Determination

   Once the Domain Name has been determined for a system, the Domain
   Name Service SHOULD be consulted to determine the globally advertised
   identifiers for the system.  In this fashion, system is coordinated
   with the most current information actually propagated within the
   internet.

   Each DNS identifier has a Time-To-Live associated with it.  When any
   identifier expires, another request SHOULD be made to the DNS for a
   list of identifiers.

   When there is more than one interface on a multi-homed end-system,
   each interface MUST answer to all of the identifers learned.

   When more than one identifier is returned for a system, the primary
   system identifier is the identifier with the highest TTL, or the
   first listed identifier of those with the highest TTL.

7.1.4.  Prefix Determination

   The prefix size is dynamically learned from matching interface
   identifiers against the intermediate-system advertisements, as
   described in Intermediate-System Discovery above.

   Unlike previous practice, an end-system prefix sizes SHOULD NOT be
   preconfigured.  Any preconfigured value MUST be superceded by new
   values and changes propagated in intermediate-system advertisements.

7.1.5.  Changing Identifiers

7.2.  Intermediate-Systems

   The zones and prefixes are assigned by hand.

8.  Next-Hop Determination

   When an end-system has not heard any intermediate-system
   advertisements, it is assumed that all end-systems are only
   accessible on the local link.

   multi-homed

   preferred router

   smart selection

   local redirect

   remote redirect

8.1.  Examples of Use

       Simple case -- J to K on the same fully-connected link.

           J sends the Where-Are-You (which contains its own media address)
           to all-systems.  K sends the I-Am-Here (which contains its own
           media address) directly to all-systems.  At this point, they
           both know that they can talk directly to each other, without
           regard to subnet.

       Routed case -- J to K not on the same fully-connected link.

           If no resource reservation or policy routing is desired, J
           simply sends its packets directly to the "preferred" router that
           it has learned from the Advertisements.  If there is a better
           router for the first-hop, that router sends the I-Am-Here
           redirect to J, but never-the-less forwards the packet.

           In the presence of RR or PR, J sends a Where-Are-You to the
           "preferred" router that it has learned from the Advertisements.
           That router always returns an I-Am-Here redirect (even if the
           correct hop is itself), which contains the requested RR or PR
           status information.  J then sends its packets to the first-hop
           router as determined from the I-Am-Here.

       General case -- J to K over disconnected partial mesh (radio/framerelay).

           J periodically sends the I-Am-Here (which contains its own media
           address, and the addresses of its "heard" routers) to the
           all-routers multicast.  The routers use such messages to
           construct a map of the current state of the topology.  The
           routers now know who J hears, and who hears J.

           If the routing map doesn't contain a current whereabouts of K,
           the Destination Unreachable message is returned by the "best"
           router on J's "heard" list.

           If the routing map contains the current whereabouts of K, the
           "best" router on K's "heard" list sends a Where-Are-You to K,
           with a list of routers which can hear K.  The list is ordered by
           the intersection of those routers which can also hear J,
           minimizing the number of hops.

           When K hears the Where-Are-You, it sends the I-Am-Here to the
           all-systems address.  The "best" router on J's "heard" list
           sends an I-Am-Here redirect to J, with a substitute list of
           routers which can hear J.  The list is ordered by the
           intersection of those routers which can also hear K.

           Of course, J may have heard K's I-Am-Here directly.

           At this point, the routing fabric knows which routers are heard
           by J and K, and which routers can hear J and K.  J and K know
           whether they can hear each other directly.  If not, they know
           the "best" next-hop router (which may not be the same in both
           directions).

           Unlike the fully-connected scenarios, this scheme requires that
           the I-Am-Here is sent from time to time to keep the map updated.
           However, only routers need store the information.

9.  Additional ICMP Packets

   The Packet format and basic facilities are already defined for ICMP
   [3], as modified for SIP [1].

   Up-to-date values of the ICMP Type field are specified in the most
   recent "Assigned Numbers" RFC [2].  This document concerns the
   following values:

      <TBD>   Where-Are-You
      <TBD>   I-Am-Here

9.1.  Where-Are-You

   A summary of the Where-Are-You message format is shown below.  The
   fields are transmitted from left to right.

    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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       System Identifier                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Extensions ...
   +-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      <TBD>

   Code

      The Code field is one octet.  Up-to-date values of the I-Am-Here
      Code field are specified in the most recent "Assigned Numbers" RFC
      [2].  Current values are assigned as follows:

           0     RESERVED
           1     End-System Solicitation
           2     Intermediate-System Solicitation

   Checksum

      The ICMP Checksum.

   System Identifier

      The System Identifier field is eight octets in length, and
      contains an identifier of the system which is sought.  When the
      identifer of the system is unknown, the field is zero filled.

   Extensions

      The Extensions field is variable in length and contains zero or
      more Extensions.  These Extensions are described in a later
      section. node name which
            is memorable and comfortable to them.  The contents of the Reserved field are ignored.  Future backward-
compatible name should be
            automatically registered, and changes to the protocol may specify the contents of the
Reserved field or associated
            identifers should be maintained automatically.

      This design provides initial self-identification and propagation
      of additional octets at the end changes in identification.  Other aspects of configuration,
      such as loading the message.

9.1.1.  End-System Solicitation

   The End-System Solicitation contains the following values:

   -  In operating system and environment, and
      additional facilities and servers for registration, are outside
      the Destination Address field scope of the SIP header: For service
      solicitations, the special multicast group associated with the
      service.  For neighbor discovery.

   Mobility

      As mentioned repeatedly above, mobility is an important
      consideration when evaluating these criteria.

      When identification is dynamically changing while moving, other solicitations,
      nodes must be notified of the all-systems multicast. changes.

      In
      either case, addition, the scope "half link" problem has to be considered.  This
      occurs when node J can hear node K, but K cannot hear J.  If there
      is set a path from J to local.

   -  In the Source Address field of the SIP header: any identifier
      associated with the sending interface.  It MAY contain zero if a router which K can hear, completing the
      system has not yet determined an identifier
      circuit, communication can still occur.

      Only basic support for mobility is provided.  Other aspects of
      mobility, such as registration and caching, are outside the interface.

   -  In the Code field scope
      of neighbor discovery.

   Black hole detection

      In determining whether the ICMP header: 1 for End-System
      Solicitation.

   -  For next-hop node is still available, there
      is a basic tradeoff between frequent queries and resources used.
      This design trades fewer queries against more information within
      each intermediate-system advertisement that has been heard, query and response.

      Explicit holding times are used to limit the exposure to black
      holes.  The times may be dynamically shortened by the responsible
      node when a resource is critical, or when the System-Heard extension.

   -  For interfaces which node is actively
      moving.

   Media independence

      There are not many instances where node discovery is accomplished
      differently over different media, such as point-to-point links, versus
      broadcast versus Public Data Networks.  This design places the Media-
      Access extension.

   In
      neighbor discovery above the unlikely event that not all extensions fit network layer, where it enjoys
      greater independence.

      There are difficulties with carrying media addresses within
      packets, especially in a single
   solicitaion, as constrained by the MTU presence of multi-media bridges.
      Rather than allowing translation by bridges in the link, path, this
      design exercizes control at the remaining
   extensions are removed.  Only a single solicitation destination node, and requires all
      such media addresses to be in canonical form.

   Optimal route determination

      This is sent.

9.1.2.  Intermediate-System Solicitation

   The Intermediate-System Solicitation contains the following values:

   -  In the Destination Address field essentially a superset of the SIP header: the all-
      routers multicast, next-hop discovery, combined
      with resource reservation and possible policy considerations, and
      the scope set ability to local.

   -  In the Source Address field of the SIP header: redirect traffic under changing conditions.  This
      is not well supported in any identifier
      associated with of the sending interface.  It MAY contain zero if past protocols.

      The design encompasses media level redirects between multiple
      logical subnets on the
      system has not yet determined an identifier same physical media, and provides for the interface.

   -  In the Code field
      absence of the ICMP header: 2 for Intermediate-System
      Solicitation.

   -  For each logical subnetting information when visiting mobile
      hosts continue to use their native identifiers.

      To balance system overhead against network traffic, this design
      attempts to adapt to a continuum of that system's interface identifiers other than the
      primary identifier, machine capabilities.  Dumb
      hosts may simply send packets to a default router, and be
      redirected to the Other-Identifier extension, with correct next-hop by the
      prefix size set more capable routers.
      Smarter hosts learn sufficient information to zero.

   -  For each intermediate-system advertisement that has been heard, make informed
      choices.

   Simplicity

      This design reduces the System-Heard extension.

   -  For interfaces number of packet types which are not point-to-point links, the Media-
      Access extension.

   In the unlikely event that not all extensions fit must be
      supported in a single
   solicitaion, as constrained by pure SIPP node, and reduces the MTU number of the link, multiple
   solicitations are sent, with nodes
      which recognize and respond to each except the last containing as many
   extensions as can fit.

9.2.  I-Am-Here

   A summary of the I-Am-Here message format is shown below. type.  The fields packets are transmitted from left to right.

    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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Sequence Number        |          LifeTime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       System Identifier                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Extensions ...
   +-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      <TBD>

   Code
      designed with 32 and 64 bit boundaries for efficient processing.

3.  Historic Methods

ARP

   The Code field is one octet.  Up-to-date values of the I-Am-Here
      Code field are specified in the most recent "Assigned Numbers" RFC
      [2].  Current values are assigned as follows:

           0     RESERVED
           1     End-System Advertisement
           2     Intermediate-System Advertisement
           3     Local Redirect
           4     Remote Redirect

   Checksum

      The ICMP Checksum.

   Sequence Number

      The Sequence Number field common next-hop resolution protocol, the Address Resolution
   Protocol (ARP), is two octets in length, and contains done at the number of I-Am-Here messsages sent since link level rather than the system was
      initialized.  This number MUST include this advertisement.

   LifeTime

      The LifeTime field is network
   level.  It requires an additional two octets in length, and indicates the
      seconds remaining before media packets at the entry beginning
   of each connection.  A Request is considered invalid.

   System Identifier

      The System Identifier field sent, a Reply is eight octets in length, received, and
      contains then
   the primary identifier for this system.  Other
      identifiers are indicated with first datagram can be sent to the Other-Identifier extension.

   Extensions

      The Extensions field is variable in length next-hop.  This causes a
   significant amount of traffic, and contains zero or
      more Extensions.  These Extensions are described considerable latency in
   establishing a connection, particularly when multiple hops need to
   use ARP.

   ARP is simple, and has low storage overhead.

   ARP is deemed inadequate because it is a broadcast rather than a later
      section.

9.2.1.  End-System Advertisement
   multicast technique, is frequently media dependent, is not easily
   extensible for auto-configuration or mobility support, and it does
   not directly support black-hole detection.

ICMP Router Discovery

   The End-System Advertisement contains the following values:

   -  In the Destination Address field ICMP Router Discovery messages provide some of the SIP header: For desired
   features.  Each router sends Hellos on a periodic
      mobile end-system advertisements, the all-routers multicast.  For
      other end-system advertisements, the all-systems multicast.  In
      either case, the scope basis.  After
   determining that a destination is set not on the local media, a host can
   send packets directly to local.

   -  In a "preferred" router, which forwards the Source Address field of
   packet to the SIP header: For service
      advertisements, correct destination.  If a better next-hop is known,
   the primary identifier associated with that
      system.  For responses router sends a redirect to solicitations, the identifier specified
      in host.

   This can reduce the solicitation.

   -  In traffic from 3 to 2 packets at the Code field beginning of a
   connection.  Unfortunately, the ICMP header: 1 for End-System
      Advertisement.

   -  In the Lifetime field: technique is not widely implemented
   in the interface's configured
      AdvertisementLifetime.

   -  For each current generation of that system's interface identifiers other than the
      primary identifier, the Other-Identifier extension, with the
      prefix size set protocols.

   It does not provide a comprehensive solution to zero.

   -  For each service advertisement that is offered, auto-configuration,
   mobility, black-hole detection, or media independence.

ES-IS Hellos

   The ISO solution (ES-IS) addresses some of these problems.  Each host
   and router sends Hellos on a periodic basis.  Every node must
   remember all of the Service-
      Information extension.

   -  For each intermediate-system advertisement that has been heard, media addresses for the System-Heard extension.

   -  For interfaces which are not point-to-point links, other systems on the Media-
      Access extension.

   In
   local network.

   However, the unlikely event that not all extensions fit in a single
   advertisement, as constrained traffic overhead of many packets sent by the MTU every node on a
   regular basis eliminates it from consideration.  Also, it requires a
   large amount of the link, multiple
   advertisements are sent, with storage overhead in each except the last containing as many
   extensions as can fit.

9.2.2.  Intermediate-System Advertisement node.

Media Multicast

   The Intermediate-System Advertisement contains the following values:

   -  In first packet destined for an unknown node might be sent to the Destination Address field
   all-systems multicast, or to a media multicast based on a hash
   function of the SIP header: destination.  The appropriate node would accept the all-
      systems multicast, with
   packet, and send a redirect indicating the scope set appropriate media address
   to local.

   -  In be used for future packets.

   This reduces the Source Address field of traffic from 3 to 2 packets at the SIP header: beginning of a
   connection, and eliminates the primary
      identifier latency of ARP, as the system.  The same identifier probe packet
   sent is used for all
      interfaces.

   -  In also the Code field of data packet.  This also eliminates the ICMP header: 2 queuing of
   datagrams waiting for Intermediate-System
      Advertisement.

   -  In the Lifetime field: the interface's configured
      AdvertisementLifetime.

   -  For each of that interface's identifiers whose Advertise flags are
      TRUE, ARP reply.

   However, the Routing-Information extension.

   -  For each of that interface's recently changed identifiers, destination identifier in the
      Change-Identifier extension.

   -  For each of that system's other interface's identifiers which have
      not already been included through prefix subsumption, network header will be
   unicast, while the Other-
      Identifier extension.

   -  For each service that is offered, or has been learned from another
      advertisement, media address will be multicast.

   If this method were used exclusively, routers would be required to
   listen to all multicasts, and recognize those packets destined beyond
   the Service-Information extension.

   -  For each intermediate-system advertisement that has been heard, local link.

   Multi-homed hosts also require the System-Heard extension.

   -  For interfaces capability to decide which link to
   use, and are not point-to-point links, the Media-
      Access extension.

   In the unlikely event that supportable using this technique alone.

   This method is not all extensions fit extensible to include other information useful in a single
   advertisement, as constrained by
   mobile environments, resource reservation, and policy routing.

4.  Solution Overview

   This design is a combination of the MTU best features of the link, multiple
   advertisements preceding
   techniques.

4.1.  Packets

   This solution describes two packets, not much different from those
   already deployed.  These familiar forms are sent, with each except re-packaged to join
   common functions into the last containing as many
   extensions as can fit.

10.  Extensions

   Extensions allow variable amounts of information same packet to be carried within
   each Advertisement or Advertisement packet.  Some extensions reduce traffic, and are
   common
   designed to both packet types.

   The end of the list of Extensions is indicated by be more extensible in the Payload Length
   of future.

   In order to foster media independence, the SIP packet.

   A summary packets are part of ICMP,
   which allows the Extensions format protocols to be used over broadcast, multicast,
   partial-mesh, and point-to-point media.  This is shown below.  The fields are
   transmitted from left similar to right.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type the
   positioning of ES-IS.

4.1.1.  Solicitations

   The Type field Where-Are-You solicitation is one octet used to find other nodes, and indicates the type of Extension.
      Up-to-date values of the Extension Type field
   associated resources and services.  Router solicitations are specified in the
      most recent "Assigned Numbers" RFC [2].  Current values sent
   when a node interface is initialized.  Specific solicitations are
      assigned as follows:

           1     Media-Access
           2     Change-Identifier
           3     Other-Identifier
           4     System-Heard
           5     Routing-Information
           6     Service-Information
           7     Transit-Information
           8     Authentication
           9     Security-Information
          10     Redirected-Header

   Length
   sent when one node is ready to communicate with another particular
   node.

4.1.2.  Advertisements

   The Length field I-Am-Here advertisement is one octet and indicates the length of answer to the Data
      field which has been used.

      Each Extension ends Where-Are-You
   solicitation.  Advertisements are also sent on an octet boundary which is an integral
      multiple of four octets.  Any unused portion of the Data field is
      padded with zeros.

      length          actual
      0 through 2        4
      3 through 6        8
      7 through 10      12

   Data

      The Data field a periodic basis to
   indicate special resources and services.  Periodic advertisements
   from a few commonly requested nodes result in less traffic than
   repeated solicitations from many nodes.

4.1.3.  LifeTime

   A lifetime is zero or more octets and contains associated with each node location, specifying the value or
      other information for this Extension.  The format and
   maximum length of time that the Data field location is determined by to be considered valid in
   the Type and Length fields.

10.1.  Media-Access

A summary absence of the Media-Access extension format is shown below.  The
fields are transmitted from left to right.

 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      |    Length     |           Media Type          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

     1

Length

     >= 3

Media Type further information.  The Media Type field lifetime is two octets in length.  The value of this
   field set when a
   solicitation is sent, or when an advertisement is received.

   This prevents the same as the Hardware Type used in ARP.  Up-to-date
   values sending of repeated solicitations, and limits
   exposure to black holes.  This ensures that other nodes eventually
   forget about nodes that become unreachable, whether that is because
   the Hardware Type field are specified in node has failed, or it no longer provides the most recent
   "Assigned Numbers" RFC [2].

      [Should we use advertised service.

4.1.4.  Extensions

   Each message contains "optional" extensions, designed to allow
   flexibility and extensibility.

   One of the ifType from MIB-II instead?]

MAC Address

   The MAC Address field common extensions is variable in length, and contains the media
   address which is used address.  Each message
   contains enough information to access this system.

   The MAC Address is always specified in Canonical order.

The Media-Access extension MUST be included in those messages sent from
an interface on return a multi-access media.

It MUST NOT be included in reply directly to the sender,
   without additional location traffic.  By carrying media addresses
   within the advertisements and redirect packets, a message sent from further ARP-like
   query/response can be avoided entirely.  This reduces traffic, and
   further prevents black-holes when forwarding tables are not updated
   due to packet loss.

   Another common extension is a point-to-point
interface, or in messages such as list of the Remote Redirect routers which pass through
intermediate systems.

10.2.  Change-Identifier

A summary have been
   heard.  This allows routers to build a map of the Change-Identifier extension format paths between
   routers, and between routers and hosts.  This is shown below.  The
fields are transmitted from left designed to right.

 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      |    Length     |                   |Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         Old Identifier                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         New Identifier                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

     2

Length

    22

Prefix Size be used
   by most commonly deployed routing protocols.  This also solves the
   "half link" problem, when used together with the well-known link-
   state class of routing protocols.

4.2.  Router Discovery

   Routers advertise their locations periodically.  The Prefix Size field is six bits in length, and indicates number of
   routers are usually fewer than the number of bits in both Identifiers which define hosts.

   When a router is present, a host learns whether the local media uses
   prefix mask routing.  The host sends datagrams directly to its preferred
   router for all destinations which it cannot determine to be on the
   link.
   local media.  The value ranges from 0 to 62.

   End-Systems MUST have router issues a Prefix Size of zero.

Old Identifier

   The Old Identifier field is eight octets in length, and contains redirect when another router would
   be more appropriate or the
   old identifier for this interface.

New Identifier

   The New Identifier field destination is eight octets in length, and contains one
   of directly accessible on the identifiers for this interface.  This may be another
   identifier for
   local media.

   When most of the same interface traffic is between nodes that sent the message, or may
   identify another interface are not on the same system which sent the message.

10.3.  Other-Identifier

A summary
   local media, this is very efficient.  When most of the Other-Identifier extension format is shown below.  The
fields are transmitted from left to right.

 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      |    Length     |                   |Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Metric                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                      Interface Identifier                     +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

     3

Length

    14

Prefix Size

   The Prefix Size field traffic is six bits in length, and indicates
   between hosts on the local media (client-server), the extra redirect
   packets will be rare.

4.3.  Host Discovery

   When a host or router needs the number location of bits in the Interface Identifier which define a target host on the prefix mask
   local media, it sends a media multicast solicitation for the link.  The value ranges from 0 to 62.

   If the Interface Identifier does not indicate a valid prefix, location
   of the
   value is zero.

   End-Systems MUST have host, followed by a Prefix Size media multicast of zero.

Metric the original data
   packet.  The Metric field is four octets in length, and target node issues an advertisement which indicates the
   preference level for use its
   current reachability.

   When most of this system to forward packets to the
   Interface Identifier.  Lower values indicate greater preference.

   End-Systems MUST set this field to zero.

Interface Identifier

   The Interface Identifier field traffic is eight octets in length, and
   contains one of between hosts on the identifiers for this system.  This may local media
   (client-server), the extra solicitation and advertisement packets
   will be another
   identifier for rare.

5.  Sending Datagrams

   The internetwork layer chooses the same interface that sent next hop for each datagram sent.
   If the message, or may
   identify another interface destination is on the same system which sent local media, the message.

Every identifier for every interface datagram is listed in each I-Am-Here
message.

This supports multiple identifiers per interface, as well as multi-homed
systems.

When a number of interfaces, such as point-to-point interfaces, may be
aggregated with sent
   directly to the same prefix, only one extension need destination.  Otherwise, it has to be included.

This enables end-systems sent to determine the best next-hop without sending a Where-Are-You solicitation when
   router.

5.1.  Local/Remote Decision

   To decide if the next-hop destination is on another interface
attached to the same advertising system.

10.4.  System-Heard

A summary of the System-Heard extension format is shown below.  The
fields are transmitted from left to right.

 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      |    Length     |     Speed     |D|B|Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              MRU              |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       System Identifier                       +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Sequence Number        |      Remaining LifeTime       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Quality                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Advertisement Count                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Error Count                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

     4

Length

    30

Designated Bit

   The Designated Bit indicates that local media, the System Identifier is following
   algorithm MUST be used:

   (a)   For a multicast destination, simply pass the
   Designated Router.

Backup Bit

   The Backup Bit indicates that datagram to the System Identifier
         link layer for any indicated interface(s).

   (b)   A list of routing-prefixes is the Backup
   Designated Router.

Prefix Size maintained for each interface.
         This prefix MAY be configured, or learned from Router
         Advertisements.  The Prefix Size field prefix size is six bits in length, and indicates the number of valid bits in
         the System Identifier which define prefix.

   (c)   If an interface prefix exactly matches the destination prefix mask for
         extracted by the
   link.  The value ranges from 0 same prefix size, then the destination is on
         the corresponding local media, and the datagram is to be
         transmitted directly to 62. the destination.

   (d)   If there are no matches, and no Router Advertisements have been
         heard, then the System Identifier does not indicate a valid prefix, destination is on the value local media.  The
         datagram is zero.

   End-Systems MUST multicast on all interfaces.

   (e)   If there are no matches, and one or more Router Advertisements
         have been heard, then the destination is accessible only
         through a Prefix Size router.  Selection of zero.

MRU

   The Maximum Receive Unit field a router is two octets described in length, and indicates "SIPP
         Router Discovery" [$].

   The host MUST operate correctly in a minimal network environment.
   For example, if the maximum size packet that host insists on finding at least one router to
   initialize, the system host will receive over be unable to operate on an isolated
   network.

5.2.  Media Address Determination

   When the link.

Speed

   The Speed field media address for a destination is one octet in length, and indicates the speed of unknown, the link over which following
   procedure is used:

   (a)   For a multi-homed host, the advertisement or solicitation was heard.
   Higher values indicate greater speed.  The speed value datagram is related to
   int( 10 * ln( speed / 100 ) ) in bits per second.

      After considerable trial duplicated on all
         interfaces.

   (b)   If an interface has no broadcast capability (a point-to-point
         link), and error, this formula was used because
      it gave the best distribution for distinguishing medium speed
      links, and fit reasonably well in peer entity is unknown, the realm of currently
      envisioned speeds.  It has datagram is sent on
         the interface.

   (c)   If an upper limit of 11.87 Terabits per
      second.  (It also interface has no broadcast capability (an X.25 or Frame-
         Relay link), the datagram is duplicated on each virtual circuit
         for which there is no known peer entity, as if they were each a convenient button
         separate point-to-point interface on a multi-homed host.

   (d)   If an interface has no multicast capability, the calculator.)

        0      link datagram is down
        1 - 9  reserved
       10      300 or less
       24    1,200                  96      1,544,000 T1
       31    2,400                  99      2,048,000 E1
       38    4,800                 106      4,000,000 Token Ring
       42    7,200                 110      6,312,000 T2
       45    9,600                 115     10,000,000 Ethernet
       49   14,400                 119     16,000,000 Token Ring
       52   19,200
       56   28,800                 130     44,736,000 T3
       59   38,400                 142    155,520,000 STS-3,STM-1
       63   57,600                 202    622,080,000 STS-12,STM-4
       64   64,000                 216  2,488,320,000 STS-48,STM-16
       71  128,000
       73  153,600
       78  256,000

System Identifier
         sent as a link-layer broadcast.  The System Identifier field SIPP Destination is eight octets in length, and contains
   the primary identifier for
         unchanged.

   (e)   For an interface with multicast capability, the system, taken from datagram is
         sent as a link-layer multicast.  The multicast address used is
         the Source Address
   field exclusive-or of every octet of the advertisement heard.

Sequence Number SIPP Destination, added
         to the selected-systems multicast.  The Sequence Number field SIPP Destination is two octets in length, and contains the
   last heard sequence number from
         unchanged.

   (f)   Immediately following the system.

Remaining LifeTime

   The Remaining LifeTime field datagram, when there is two octets no entry in length, and indicates
   the seconds remaining before
         the entry route cache, a Where-Are-You solicitation is considered invalid.

Quality

   The Quality field sent,
         utilizing the same SIPP Destination as the datagram.

   (g)   When there is four octets an entry in length, and contains the route cache, for an
   indication of unknown media
         address, no further solicitations are sent until the signal quality received cache
         entry expires.

   On receipt of a unicast datagram from this system.  Higher
   values indicate greater quality.

Advertisement Count

   The Advertisement Count field a broadcast or multicast media
   address, the datagram is four octets in length, and indicates silently discarded if the number SIPP Destination
   does not match any SIPP identifying-address of advertisements that have been heard from the identified
   system.

Error Count

   The Error Count field is four octets in length, and indicates node.

   On receipt of a Where-Are-You solicitation, the
   number target node sends a
   multicast I-Am-Here advertisement to the all-systems multicast.

   On receipt of errors a multicast I-Am-Here advertisement, all nodes which
   have been detected on a route cache entry for the link with SIPP Source update the
   identified system.

This extension is included in every I-Am-Here.

10.5.  Routing-Information

A summary of cache entry
   with the Routing-Information extension format is shown below.
The fields are transmitted from left to right.

 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      |    Length     |  Preference   |D|B|Prefix Size|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              MRU              |     Zone      |   Priority    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                      Interface Identifier                     +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

     5

Length

    14

Preference

   The Preference field is one octet in length, current LifeTime and indicates the
   preference level for use media address.

5.3.  Route Cache

   To efficiently route a series of this system to forward packets datagrams to the
   Interface Identifier.  Higher values indicate greater preference.

Designated Bit

   The Designated Bit indicates that same destination,
   the system is source host MUST keep a "route cache" of mappings to
   destinations.  A host uses the Designated
   Router.

Backup Bit

   The Backup Bit indicates that following basic algorithm on this
   cache to route a datagram:

   (a)   If the system is cache contains information for a particular destination,
         the Backup Designated
   Router.

Prefix Size

   The Prefix Size field is six bits in length, interface and indicates media address are used to send the number
   of bits in datagram.

         This entry might point directly to the Interface Identifier destination, or to a
         router which define the prefix mask for handles the link.  The value ranges from 0 to 62. destination.

   (b)   If the Interface Identifier does not indicate cache contains no information for a valid prefix, the
   value is zero.

MRU

   The Maximum Receive Unit field particular
         destination, a determination is two octets in length, and indicates made whether the maximum size packet that destination is
         on the system will receive over local media.

   (c)   When the link.

Zone

   The Zone field destination is one octet in length, and indicates determined to be accessible through a
         router, the zone cache entry for the
   link.  A value of zero indicates that no zone has been assigned.

Priority

   The Priority field router is one octet in length, and indicates the priority
   for election used to Designated Backup.  A value of zero indicates that send the system is not eligible.

Interface Identifier
         datagram.  The Interface Identifier field is eight octets in length, and
   contains one router cache entry might be duplicated, or a
         system of pointers could be used.  In any case, the identifiers cache entry
         for this interface.

This extension is sent only by Intermediate-Systems.

When more than one of these extensions is present, the Designated and
Backup bits, MRU, Zone and Priority fields destination MUST be have the same in each
copy.

10.6.  Service-Information

A summary of the Service-Information extension format is shown below.
The fields are transmitted from left to right.

 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      |    Length     |           Service             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Sequence Number        |      Remaining LifeTime       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       System Identifier                       +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

     6

Length

    >= 14

Service

   The Service field as the cache
         entry for the router.

   (d)   When the destination is two octets in length.  The value of this field determined to be on the local media,
         the media address is usually solicited.  A new cache entry is made,
         with a limited LifeTime, to inhibit sending of repeated
         solicitations.

   Each route cache entry needs to include the same as following items.

   (1)  LifeTime
   (2)  Next-hop interface (for a multi-homed host)
   (3)  Next-hop media address
   (4)  Destination SIPP identifying-address
   (5)  Destination prefix size
   (6)  Source SIPP identifying-address (for a multi-homed host)
   (7)  Flow number

   Field (4) MAY be the well-known port number.  Up-to-date values full SIPP identifying-address of the Service field are specified in
   destination, or only the most recent "Assigned
   Numbers" RFC [2].

Sequence Number

   The Sequence Number field destination network number.  This is two octets
   determined by the prefix size in length, and contains (5).

   Field (7) SHOULD be included.

   DISCUSSION:
      Each route cache entry defines the
   last heard sequence number from endpoints of an internetwork
      path.  Although the system.

Remaining LifeTime

   The Remaining LifeTime field is two octets connecting path may change dynamically in length, and indicates an
      arbitrary way, the seconds remaining before transmission characteristics of the path tend
      to remain approximately constant over a time period longer than a
      single typical host-host transport connection.  Therefore, a route
      cache entry is considered invalid.

System Identifier

   The System Identifier field is eight octets in length, and contains
   the primary identifier for this system.

Data

   The Data field is variable in length, and contains information
   specific to the service.  For example, it could contain a string with natural place to cache data on the description properties of
      the service.

   The format path.

      Examples of such properties might be the Data field is entirely service dependent, maximum unfragmented
      datagram size, or the average round-trip delay measured by a
      transport protocol.  This data will generally be both gathered and is
   always treated as
      used by a binary value.

10.7.  Transit-Information

A summary of the Transit-Information extension format is shown below.
The fields higher layer protocol (that is, by TCP, or by an
      application using UDP).  Experiments are transmitted from left to right.

 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      |    Length     |               |      QoS      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Metric                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

     7

Length

     6

QoS

   The Quality currently in progress on
      caching path properties in this manner.

      There is no consensus on whether the route cache should be keyed
      on destination host addresses alone, or allow both host and
      network addresses.  Those who favor the use of Service field is one octet only host addresses
      argue that:

      (1)   Redirect messages will generally result in length, entries keyed on
            destination host addresses.  The simplest and indicates a
   service for which transit will most general
            scheme would be accepted.

Metric to use host addresses always.

      (2)   The Metric field is four octets in length, and indicates IP layer may not always know the
   preference level prefix size for a
            network address in a complex subnetted environment.

      (3)   The use of this network link only host addresses allows the destination
            address to forward packets of be used as a pure 64-bit number, which may allow
            the indicated Quality of Service.  Lower values indicate greater
   preference.

This extension is included Internet architecture to be more easily extended in the Intermediate-System I-Am-Here
            future without any change to
indicate that it will accept transit traffic.  If this extension is not
included, other intermediate-systems will treat the link as hosts.

      The opposing view is that allowing a stub
network.

10.8.  Authentication

A summary mixture of destination hosts
      and networks in the Authentication extension format is shown below.  The
fields are transmitted from left route cache:

      (1)   Saves memory space.

      (2)   Leads to right.

 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      |    Length     |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

     8

Length

    22

Data

   The Data field is variable in length, a simpler data structure, easily combining the
            cache with the tables of default and contains information
   specific static routes.

      (3)   Provides a more useful place to cache path properties.

IMPLEMENTATION:
   The cache needs to be large enough to include entries for the authentication method,

This extension is included maximum
   number of destination hosts that may be in any I-Am-Here.

10.9.  Security-Information use at one time.

   A summary of the Security-Information extension format is shown below.
The fields are transmitted from left route cache entry may also include control information used to right.

 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      |    Length     |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Compartments ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

     9

Length

    22

Compartments

   The Compartments field is sixteen octets in length.
   choose an entry for replacement.  This extension is included in might take the Intermediate-System I-Am-Here to
indicate form of a
   "recently used" bit, a use count, or a last-used timestamp, for
   example.  It is recommended that it will accept transit traffic include the time of last
   modification of the entry, for diagnostic purposes.

   An implementation may wish to reduce the designated security
compartments.

10.10.  Redirected-Header

A summary overhead of scanning the Redirected-Header extension format is shown below.  The
fields are transmitted from left
   route cache for every datagram to right.

 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      |    Length     |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     SIP Header ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

    10

Length

    22

SIP Header

   The SIP Header field is 48 octets in length. be transmitted.  This extension is included in may be
   accomplished with a hash table to speed the Local lookup, or Remote Redirect by giving a
   connection-oriented transport protocol a "hint" or temporary handle
   on the appropriate cache entry, to be passed to verifiy the traffic that IP layer with
   each subsequent datagram.

   Although we have described the route cache, the lists of default
   routers, and a table of static routes as conceptually distinct, in
   practice they may be combined into a single "routing table" data
   structure.

5.4.  Configuration

   Default routers and preference levels MUST NOT be configured
   manually.  Instead, "SIPP Router Discovery" [$] MUST be used.

   The routing-prefix(es) for an interface SHOULD NOT be configured
   manually.  When a node is being redirected. multi-homed, the node discovery multicast
   MUST be sent on all interfaces which have not discovered the presence
   of a router.

Security Considerations

References

   [1]

   [2]

Acknowledgments

   The document was initially composed of quotations from the RFC-1122
   Host Requirements, and selections of text contributed by Fred Baker
   (ACC), Dino Farinacci (Cisco), Christian Huitema (INRIA), Frank
   Kastenholz (FTP Software), Tony Li (Cisco), Dave Piscitello
   (Bellcore), and Garrett Wollman (UVM?).

Chair's Address

   The working group can be contacted via the current chairs:

      Stephen Deering                 Paul Francis
      3333 Coyote Hill Road           445 South St. 2L-281
      Palo Alto, CA  94304            Morristown, NJ  07960

      415-812-4839                    201-829-4484

      Deering@PARC.Xerox.com          francis@thumper.bellcore.com

      Robert M Hinden
      2550 Garcia Avenue
      Mountain View, CA  94043-1100

      415-336-2082

      hinden@Eng.Sun.com

Author's Address

   Questions about this memo can also be directed to:

      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      P O Box 6205
      East Lansing, MI  48826-6205

      EMail:
      1384 Fontaine
      Madison Heights, Michigan  48071

      Bill.Simpson@um.cc.umich.edu
      bsimpson@MorningStar.com
                           Table of Contents

     1.     Terminology ...........................................     Goals .................................................    1

     2.     Criteria ..............................................    2

     3.     Design     Historic Methods ......................................    7

     4.     Solution Overview .......................................    8
        3.1       System Identification ........................... .....................................    9
        3.2       Multicast Support ...............................   10

     4.     Intermediate-System Discovery .........................   11
        4.1       Packets .........................................    9
           4.1.1  Solicitations ...................................   11
           4.1.1  Constants .......................................   12    9
           4.1.2  Implementation  Advertisements ..................................   12    9
           4.1.3  Receipt .........................................   13  LifeTime ........................................    9
           4.1.4  Extensions ......................................   10
        4.2       Advertisements ..................................   13
           4.2.1  Constants .......................................   15
           4.2.2  Configuration ...................................   15
           4.2.3  Implementation ..................................   17
           4.2.4  Receipt .........................................   20       Router Discovery ................................   10
        4.3       Processing Advertisements .......................   20
           4.3.1  Configuration ...................................   20
           4.3.2  Implementation ..................................   21

     5.     End-System       Host Discovery ..................................   23   10

     5.     Sending Datagrams .....................................   12
        5.1       Solicitations ...................................   23
           5.1.1  Implementation ..................................   24
           5.1.2  Receipt .........................................   24       Local/Remote Decision ...........................   12
        5.2       Advertisements ..................................   24
           5.2.1  Implementation ..................................   25

     6.     Service Discovery .....................................   26
        6.1       Solicitations ...................................   27
           6.1.1  Implementation ..................................   27
        6.2       Advertisements ..................................   28
           6.2.1  Implementation ..................................   28

     7.     Self Discovery ........................................   29
        7.1       End-Systems .....................................   29
           7.1.1  Zone Determination ..............................   29
           7.1.2  Initialization ..................................   29
           7.1.3  Identifier Determination ........................   30
           7.1.4  Prefix Determination ............................   30
           7.1.5  Changing Identifiers ............................   30
        7.2       Intermediate-Systems ............................   30

     8.     Next-Hop       Media Address Determination ................................   31
        8.1       Examples of Use .................................   32

     9.     Additional ICMP Packets ...............................   34
        9.1       Where-Are-You .....................   12
        5.3       Route Cache .....................................   13
        5.4       Configuration ...................................   35
           9.1.1  End-System Solicitation .........................   37
           9.1.2  Intermediate-System Solicitation ................   38
        9.2       I-Am-Here .......................................   39
           9.2.1  End-System Advertisement ........................   41
           9.2.2  Intermediate-System Advertisement ...............   42

     10.    Extensions ............................................   43
        10.1      Media-Access ....................................   45
        10.2      Change-Identifier ...............................   46
        10.3      Other-Identifier ................................   48
        10.4      System-Heard ....................................   50
        10.5      Routing-Information .............................   53
        10.6      Service-Information .............................   55
        10.7      Transit-Information .............................   57
        10.8      Authentication ..................................   58
        10.9      Security-Information ............................   59
        10.10     Redirected-Header ...............................   60   16

     SECURITY CONSIDERATIONS ......................................   61   17

     REFERENCES ...................................................   61   17

     ACKNOWLEDGEMENTS .............................................   61   17

     CHAIR'S ADDRESS ..............................................   61   18

     AUTHOR'S ADDRESS .............................................   61   18