tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 1716

 
 
 

Towards Requirements for IP Routers

Part 3 of 6, p. 70 to 99
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 70 
5.2.1.2  Unicast

         Since the local delivery case is well-covered by [INTRO:2], the
         following assumes that the IP datagram was queued for
         forwarding.  If the destination is an IP unicast address:

         (5)  The forwarder determines the next hop IP address for the
              packet, usually by looking up the packet's destination in
              the router's routing table.  This procedure is described
              in more detail in Section [5.2.4].  This procedure also
              decides which network interface should be used to send the
              packet.

         (6)  The forwarder verifies that forwarding the packet is
              permitted.  The source and destination addresses should be
              valid, as described in Section [5.3.7] and Section [5.3.4]
              If the router supports administrative constraints on
              forwarding, such as those described in Section [5.3.9],
              those constraints must be satisfied.

         (7)  The forwarder decrements (by at least one) and checks the
              packet's TTL, as described in Section [5.3.1].

         (8)  The forwarder performs any IP option processing that could
              not be completed in step 3.

         (9)  The forwarder performs any necessary IP fragmentation, as
              described in Section [4.2.2.7].  Since this step occurs
              after outbound interface selection (step 5), all fragments
              of the same datagram will be transmitted out the same
              interface.

         (10) The forwarder determines the Link Layer address of the
              packet's next hop.  The mechanisms for doing this are Link
              Layer-dependent (see chapter 3).

         (11) The forwarder encapsulates the IP datagram (or each of the
              fragments thereof) in an appropriate Link Layer frame and
              queues it for output on the interface selected in step 5.

         (12) The forwarder sends an ICMP redirect if necessary, as
              described in Section [4.3.3.2].

Top      Up      ToC       Page 71 
5.2.1.3  Multicast

         If the destination is an IP multicast, the following steps are
         taken.

         Note that the main differences between the forwarding of IP
         unicasts and the forwarding of IP multicasts are

         o  IP multicasts are usually forwarded based on both the
            datagram's source and destination IP addresses,

         o  IP multicast uses an expanding ring search,

         o  IP multicasts are forwarded as Link Level multicasts, and

         o  ICMP errors are never sent in response to IP multicast
            datagrams.

         Note that the forwarding of IP multicasts is still somewhat
         experimental. As a result, the algorithm presented below is not
         mandatory, and is provided as an example only.

         (5a) Based on the IP source and destination addresses found in
              the datagram header, the router determines whether the
              datagram has been received on the proper interface for
              forwarding. If not, the datagram is dropped silently.  The
              method for determining the proper receiving interface
              depends on the multicast routing algorithm(s) in use. In
              one of the simplest algorithms, reverse path forwarding
              (RPF), the proper interface is the one that would be used
              to forward unicasts back to the datagram source.

         (6a) Based on the IP source and destination addresses found in
              the datagram header, the router determines the datagram's
              outgoing interfaces. In order to implement IP multicast's
              expanding ring search (see [INTERNET:4]) a minimum TTL
              value is specified for each outgoing interface. A copy of
              the multicast datagram is forwarded out each outgoing
              interface whose minimum TTL value is less than or equal to
              the TTL value in the datagram header, by separately
              applying the remaining steps on each such interface.

         (7a) The router decrements the packet's TTL by one.

         (8a) The forwarder performs any IP option processing that could
              not be completed in step (3).

Top      Up      ToC       Page 72 
         (9a) The forwarder performs any necessary IP fragmentation, as
              described in Section [4.2.2.7].

         (10a) The forwarder determines the Link Layer address to use in
              the Link Level encapsulation. The mechanisms for doing
              this are Link Layer-dependent. On LANs a Link Level
              multicast or broadcast is selected, as an algorithmic
              translation of the datagrams' class D destination address.
              See the various IP-over-xxx specifications for more
              details.

         (11a) The forwarder encapsulates the packet (or each of the
              fragments thereof) in an appropriate Link Layer frame and
              queues it for output on the appropriate interface.

5.2.2  IP Header Validation

      Before a router can process any IP packet, it MUST perform a the
      following basic validity checks on the packet's IP header to
      ensure that the header is meaningful.  If the packet fails any of
      the following tests, it MUST be silently discarded, and the error
      SHOULD be logged.

      (1)  The packet length reported by the Link Layer must be large
           enough to hold the minimum length legal IP datagram (20
           bytes).

      (2)  The IP checksum must be correct.

      (3)  The IP version number must be 4.  If the version number is
           not 4 then the packet may well be another version of IP, such
           as ST-II.

      (4)  The IP header length field must be at least 5.

      (5)  The IP total length field must be at least 4 * IP header
           length field.

      A router MUST NOT have a configuration option which allows
      disabling any of these tests.

      If the packet passes the second and third tests, the IP header
      length field is at least 4, and both the IP total length field and
      the packet length reported by the Link Layer are at least 16 then,
      despite the above rule, the router MAY respond with an ICMP
      Parameter Problem message, whose pointer points at the IP header
      length field (if it failed the fourth test) or the IP total length

Top      Up      ToC       Page 73 
      field (if it failed the fifth test).  However, it still MUST
      discard the packet and still SHOULD log the error.

      These rules (and this entire document) apply only to version 4 of
      the Internet Protocol.  These rules should not be construed as
      prohibiting routers from supporting other versions of IP.
      Furthermore, if a router can truly classify a packet as being some
      other version of IP then it ought not treat that packet as an
      error packet within the context of this memo.

      IMPLEMENTATION:
         It is desirable for purposes of error reporting, though not
         always entirely possible, to determine why a header was
         invalid.  There are four possible reasons:

         o  The Link Layer truncated the IP header

         o  The datagram is using a version of IP other than the
            standard one (version 4).

         o  The IP header has been corrupted in transit.

         o  The sender generated an illegal IP header.

         It is probably desirable to perform the checks in the order
         listed, since we believe that this ordering is most likely to
         correctly categorize the cause of the error.  For purposes of
         error reporting, it may also be desirable to check if a packet
         which fails these tests has an IP version number equal to 6.
         If it does, the packet is probably an ST-II datagram and should
         be treated as such.  ST-II is described in [FORWARD:1].

      Additionally, the router SHOULD verify that the packet length
      reported by the Link Layer is at least as large as the IP total
      length recorded in the packet's IP header.  If it appears that the
      packet has been truncated, the packet MUST be discarded, the error
      SHOULD be logged, and the router SHOULD respond with an ICMP
      Parameter Problem message whose pointer points at the IP total
      length field.

      DISCUSSION:
         Because any higher layer protocol which concerns itself with
         data corruption will detect truncation of the packet data when
         it reaches its final destination, it is not absolutely
         necessary for routers to perform the check suggested above in
         order to maintain protocol correctness.  However, by making
         this check a router can simplify considerably the task of

Top      Up      ToC       Page 74 
         determining which hop in the path is truncating the packets.
         It will also reduce the expenditure of resources down-stream
         from the router in that down-stream systems will not need to
         deal with the packet.

      Finally, if the destination address in the IP header is not one of
      the addresses of the router, the router SHOULD verify that the
      packet does not contain a Strict Source and Record Route option.
      If a packet fails this test, the router SHOULD log the error and
      SHOULD respond with an ICMP Parameter Problem error with the
      pointer pointing at the offending packet's IP destination address.

      DISCUSSION:
         Some people might suggest that the router should respond with a
         Bad Source Route message instead of a Parameter Problem
         message.  However, when a packet fails this test, it usually
         indicates a protocol error by the previous hop router, whereas
         Bad Source Route would suggest that the source host had
         requested a nonexistent or broken path through the network.


5.2.3  Local Delivery Decision

      When a router receives an IP packet, it must decide whether the
      packet is addressed to the router (and should be delivered
      locally) or the packet is addressed to another system (and should
      be handled by the forwarder).  There is also a hybrid case, where
      certain IP broadcasts and IP multicasts are both delivered locally
      and forwarded.  A router MUST determine which of the these three
      cases applies using the following rules:

      o  An unexpired source route option is one whose pointer value
         does not point past the last entry in the source route.  If the
         packet contains an unexpired source route option, the pointer
         in the option is advanced until either the pointer does point
         past the last address in the option or else the next address is
         not one of the router's own addresses.  In the latter (normal)
         case, the  packet is forwarded (and not delivered locally)
         regardless of the rules below.

      o  The packet is delivered locally and not considered for
         forwarding in the following cases:

         - The packet's destination address exactly matches one of the
            router's IP addresses,

         - The packet's destination address is a limited broadcast

Top      Up      ToC       Page 75 
            address ({-1, -1}), and

         - The packet's destination is an IP multicast address which is
            limited to a single subnet (such as 224.0.0.1 or 224.0.0.2)
            and (at least) one of the logical interfaces associated with
            the physical interface on which the packet arrived is a
            member of the destination multicast group.

      o  The packet is passed to the forwarder AND delivered locally in
         the following cases:

         - The packet's destination address is an IP broadcast address
            that addresses at least one of the router's logical
            interfaces but does not address any of the logical
            interfaces associated with the physical interface on which
            the packet arrived

         - The packet's destination is an IP multicast address which is
            not limited to a single subnetwork (such as 224.0.0.1 and
            224.0.0.2 are) and (at least) one of the logical interfaces
            associated with the physical interface on which the packet
            arrived is a member of the destination multicast group.

      o  The packet is delivered locally if the packet's destination
         address is an IP broadcast address (other than a limited
         broadcast address) that addresses at least one of the logical
         interfaces associated with the physical interface on which the
         packet arrived.  The packet is ALSO passed to the forwarder
         unless the link on which the packet arrived uses an IP
         encapsulation that does not encapsulate broadcasts differently
         than unicasts (e.g. by using different Link Layer destination
         addresses).

      o  The packet is passed to the forwarder in all other cases.

      DISCUSSION:
         The purpose of the requirement in the last sentence of the
         fourth bullet is to deal with a directed broadcast to another
         net or subnet on the same physical cable.  Normally, this works
         as expected: the sender sends the broadcast to the router as a
         Link Layer unicast.  The router notes that it arrived as a
         unicast, and therefore must be destined for a different logical
         net (or subnet) than the sender sent it on.  Therefore, the
         router can safely send it as a Link Layer broadcast out the
         same (physical) interface over which it arrived.  However, if
         the router can't tell whether the packet was received as a Link
         Layer unicast, the sentence ensures that the router does the

Top      Up      ToC       Page 76 
         safe but wrong thing rather than the unsafe but right thing.


      IMPLEMENTATION:
         As described in Section [5.3.4], packets received as Link Layer
         broadcasts are generally not forwarded.  It may be advantageous
         to avoid passing to the forwarder packets it would later
         discard because of the rules in that section.

         Some Link Layers (either because of the hardware or because of
         special code in the drivers) can deliver to the router copies
         of all Link Layer broadcasts and multicasts it transmits.  Use
         of this feature can simplify the implementation of cases where
         a packet has to both be passed to the forwarder and delivered
         locally, since forwarding the packet will automatically cause
         the router to receive a copy of the packet that it can then
         deliver locally.  One must use care in these circumstances in
         order to prevent treating a received loop-back packet as a
         normal packet that was received (and then being subject to the
         rules of forwarding, etc etc).

         Even in the absence of such a Link Layer, it is of course
         hardly necessary to make a copy of an entire packet in order to
         queue it both for forwarding and for local delivery, though
         care must be taken with fragments, since reassembly is
         performed on locally delivered packets but not on forwarded
         packets.  One simple scheme is to associate a flag with each
         packet on the router's output queue which indicates whether it
         should be queued for local delivery after it has been sent.

5.2.4  Determining the Next Hop Address

      When a router is going to forward a packet, it must determine
      whether it can send it directly to its destination, or whether it
      needs to pass it through another router.  If the latter, it needs
      to determine which router to use.  This section explains how these
      determinations are made.

      This section makes use of the following definitions:

      o  LSRR - IP Loose Source and Record Route option

      o  SSRR - IP Strict Source and Record Route option

      o  Source Route Option - an LSRR or an SSRR

      o  Ultimate Destination Address - where the packet is being sent

Top      Up      ToC       Page 77 
         to: the last address in the source route of a source-routed
         packet, or the destination address in the IP header of a non-
         source-routed packet

      o  Adjacent - reachable without going through any IP routers

      o  Next Hop Address - the IP address of the adjacent host or
         router to which the packet should be sent next

      o  Immediate Destination Address - the ultimate destination
         address, except in source routed packets, where it is the next
         address specified in the source route

      o  Immediate Destination - the node, system, router, end-system,
         or whatever that is addressed by the Immediate Destination
         Address.

5.2.4.1  Immediate Destination Address

         If the destination address in the IP header is one of the
         addresses of the router and the packet contains a Source Route
         Option, the Immediate Destination Address is the address
         pointed at by the pointer in that option if the pointer does
         not point past the end of the option.  Otherwise, the Immediate
         Destination Address is the same as the IP destination address
         in the IP header.

         A router MUST use the Immediate Destination Address, not the
         Ultimate Destination Address, when determining how to handle a
         packet.

         It is an error for more than one source route option to appear
         in a datagram.  If it receives one, it SHOULD discard the
         packet and reply with an ICMP Parameter Problem message whose
         pointer points at the beginning of the second source route
         option.

5.2.4.2  Local/Remote Decision

         After it has been determined that the IP packet needs to be
         forwarded in accordance with the rules specified in Section
         [5.2.3], the following algorithm MUST be used to determine if
         the Immediate Destination is directly accessible (see
         [INTERNET:2]):

         (1)  For each network interface that has not been assigned any
              IP address (the unnumbered lines as described in Section

Top      Up      ToC       Page 78 
              [2.2.7]), compare the router-id of the other end of the
              line to the Immediate Destination Address.  If they are
              exactly equal, the packet can be transmitted through this
              interface.

              DISCUSSION:
                 In other words, the router or host at the remote end of
                 the line is the destination of the packet or is the
                 next step in the source route of a source routed
                 packet.

         (2)  If no network interface has been selected in the first
              step, for each IP address assigned to the router:
              (a)  Apply the subnet mask associated with the address to
                   this IP address.

                   IMPLEMENTATION:
                      The result of this operation will usually have
                      been computed and saved during initialization.

              (b)  Apply the same subnet mask to the Immediate
                   Destination Address of the packet.
              (c)  Compare the resulting values. If they are equal to
                   each other, the packet can be transmitted through the
                   corresponding network interface.

         (3)  If an interface has still not been selected, the Immediate
              Destination is accessible only through some other router.
              The selection of the router and the next hop IP address is
              described in Section [5.2.4.3].

5.2.4.3  Next Hop Address


         EDITOR'S COMMENTS:
            Note that this section has been extensively rewritten.  The
            original document indicated that Phil Almquist wished to
            revise this section to conform to his "Ruminations on the
            Next Hop" document.  I am under the assumption that the
            working group generally agreed with this goal; there was an
            editor's note from Phil that remained in this document to
            that effect, and the RoNH document contains a "mandatory
            RRWG algorithm".

            So, I have taken said algorithm from RoNH and moved it into
            here.

Top      Up      ToC       Page 79 
            Additional useful or interesting information from RoNH has
            been extracted and placed into an appendix to this note.

         The router applies the algorithm in the previous section to
         determine if the Immediate Destination Address is adjacent.  If
         so, the next hop address is the same as the Immediate
         Destination Address.  Otherwise, the packet must be forwarded
         through another router to reach its Immediate Destination.  The
         selection of this router is the topic of this section.

         If the packet contains an SSRR, the router MUST discard the
         packet and reply with an ICMP Bad Source Route error.
         Otherwise, the router looks up the Immediate Destination
         Address in its routing table to determine an appropriate next
         hop address.

         DISCUSSION:
            Per the IP specification, a Strict Source Route must specify
            a sequence of nodes through which the packet must traverse;
            the packet must go from one node of the source route to the
            next, traversing intermediate networks only.  Thus, if the
            router is not adjacent to the next step of the source route,
            the source route can not be fulfilled.  Therefore, the ICMP
            Bad Source Route error.

         The goal of the next-hop selection process is to examine the
         entries in the router's Forwarding Information Base (FIB) and
         select the best route (if there is one) for the packet from
         those available in the FIB.

         Conceptually, any route lookup algorithm starts out with a set
         of candidate routes which consists of the entire contents of
         the FIB.  The algorithm consists of a series of steps which
         discard routes from the set.  These steps are referred to as
         Pruning Rules.  Normally, when the algorithm terminates there
         is exactly one route remaining in the set.  If the set ever
         becomes empty, the packet is discarded because the destination
         is unreachable.  It is also possible for the algorithm to
         terminate when more than one route remains in the set.  In this
         case, the router may arbitrarily discard all but one of them,
         or may perform "load-splitting" by choosing whichever of the
         routes has been least recently used.

         With the exception of rule 3 (Weak TOS), a router MUST use the
         following Pruning Rules when selecting a next hop for a packet.
         If a router does consider TOS when making next-hop decisions,
         the Rule 3 must be applied in the order indicated below.  These

Top      Up      ToC       Page 80 
         rules MUST be (conceptually) applied to the FIB in the order
         that they are presented.  (For some historical perspective,
         additional pruning rules, and other common algorithms in use,
         see Appendix E).

         DISCUSSION:
            Rule 3 is optional in that Section [5.3.2] says that a
            router only SHOULD consider TOS when making forwarding
            decisions.


         (1)  Basic Match
              This rule discards any routes to destinations other than
              the Immediate Destination Address of the packet.  For
              example, if a packet's Immediate Destination Address is
              36.144.2.5, this step would discard a route to net
              128.12.0.0 but would retain any routes to net 36.0.0.0,
              any routes to subnet 36.144.0.0, and any default routes.

              More precisely, we assume that each route has a
              destination attribute, called route.dest, and a
              corresponding mask, called route.mask, to specify which
              bits of route.dest are significant.  The Immediate
              Destination Address of the packet being forwarded is
              ip.dest.  This rule discards all routes from the set of
              candidate routes except those for which (route.dest &
              route.mask) = (ip.dest & route.mask).

         (2)  Longest Match
              Longest Match is a refinement of Basic Match, described
              above.  After Basic Match pruning is performed, the
              remaining routes are examined to determine the maximum
              number of bits set in any of their route.mask attributes.
              The step then discards from the set of candidate routes
              any routes which have fewer than that maximum number of
              bits set in their route.mask attributes.

              For example, if a packet's Immediate Destination Address
              is 36.144.2.5 and there are  {route.dest, route.mask}
              pairs of {36.144.2.0, 255.255.255.0}, {36.144.0.5,
              255.255.0.255}, {36.144.0.0, 255.255.0.0}, and {36.0.0.0,
              255.0.0.0}, then this rule would keep only the first two
              pairs; {36.144.2.0, 255.255.255.0} and {36.144.0.5,
              255.255.0.255}.

Top      Up      ToC       Page 81 
         (3)  Weak TOS
              Each route has a type of service attribute, called
              route.tos, whose possible values are assumed to be
              identical to those used in the TOS field of the IP header.
              Routing protocols which distribute TOS information fill in
              route.tos appropriately in routes they add to the FIB;
              routes from other routing protocols are treated as if they
              have the default TOS (0000).  The TOS field in the IP
              header of the packet being routed is called ip.tos.

              The set of candidate routes is examined to determine if it
              contains any routes for which route.tos = ip.tos.  If so,
              all routes except those for which route.tos = ip.tos are
              discarded.  If not, all routes except those for which
              route.tos = 0000 are discarded from the set of candidate
              routes.

              Additional discussion of routing based on Weak TOS may be
              found in [ROUTE:11].

              DISCUSSION:
                 The effect of this rule is to select only those routes
                 which have a TOS that matches the TOS requested in the
                 packet.  If no such routes exist then routes with the
                 default TOS are considered.  Routes with a non-default
                 TOS that is not the TOS requested in the packet are
                 never used, even if such routes are the only available
                 routes that go to the packet's destination.

         (4)  Best Metric
              Each route has a metric attribute, called route.metric,
              and a routing domain identifier, called route.domain.
              Each member of the set of candidate routes is compared
              with each other member of the set.  If route.domain is
              equal for the two routes and route.metric is strictly
              inferior for one when compared with the other, then the
              one with the inferior metric is discarded from the set.
              The determination of inferior is usually by a simple
              arithmetic comparison, though some protocols may have
              structured metrics requiring more complex comparisons.

         (5)  Vendor Policy
              Vendor Policy is sort of a catch-all to make up for the
              fact that the previously listed rules are often inadequate
              to chose from among the possible routes.  Vendor Policy
              pruning rules are extremely vendor-specific.  See section
              [5.2.4.4].

Top      Up      ToC       Page 82 
         This algorithm has two distinct disadvantages.  Presumably, a
         router implementor might develop techniques to deal with these
         disadvantages and make them a part of the Vendor Policy pruning
         rule.

         (1)  IS-IS and OSPF route classes are not directly handled.

         (2)  Path properties other than type of service (e.g. MTU) are
              ignored.

         It is also worth noting a deficiency in the way that TOS is
         supported: routing protocols which support TOS are implicitly
         preferred when forwarding packets which have non-zero TOS
         values.

         The Basic Match and Longest Match pruning rules generalize the
         treatment of a number of particular types of routes.  These
         routes are selected in the following, decreasing, order of
         preference:

         (1)  Host Route: This is a route to a specific end system.

         (2)  Subnetwork Route: This is a route to a particular subnet
              of a network.

         (3)  Default Subnetwork Route: This is a route to all subnets
              of a particular net for which there are not (explicit)
              subnet routes.

         (4)  Network Route: This is a route to a particular network.

         (5)  Default Network Route (also known as the default route):
              This is a route to all networks for which there are no
              explicit routes to the net or any of its subnets.

         If, after application of the pruning rules, the set of routes
         is empty (i.e., no routes were found), the packet MUST be
         discarded and an appropriate ICMP error generated (ICMP Bad
         Source Route if the Immediate Destination Address came from a
         source route option; otherwise, whichever of ICMP Destination
         Host Unreachable or Destination Network Unreachable is
         appropriate, as described in Section [4.3.3.1]).

Top      Up      ToC       Page 83 
5.2.4.4  Administrative Preference

         One suggested mechanism for the Vendor Policy Pruning Rule is
         to use administrative preference.

         Each route has associated with it a preference value, based on
         various attributes of the route (specific mechanisms for
         assignment of preference values are suggested below).  This
         preference value is an integer in the range [0..255], with zero
         being the most preferred and 254 being the least preferred.
         255 is a special value that means that the route should never
         be used.  The first step in the Vendor Policy pruning rule
         discards all but the most preferable routes (and always
         discards routes whose preference value is 255).

         This policy is not safe in that it can easily be misused to
         create routing loops.  Since no protocol ensures that the
         preferences configured for a router are consistent with the
         preferences configured in its neighbors, network managers must
         exercise care in configuring preferences.

         o  Address Match
            It is useful to be able to assign a single preference value
            to all routes (learned from the same routing domain) to any
            of a specified set of destinations, where the set of
            destinations is all destinations that match a specified
            address/mask pair.

         o  Route Class
            For routing protocols which maintain the distinction, it is
            useful to be able to assign a single preference value to all
            routes (learned from the same routing domain) which have a
            particular route class (intra-area, inter-area, external
            with internal metrics, or external with external metrics).

         o  Interface
            It is useful to be able to assign a single preference value
            to all routes (learned from a particular routing domain)
            that would cause packets to be routed out a particular
            logical interface on the router (logical interfaces
            generally map one-to-one onto the router's network
            interfaces, except that any network interface which has
            multiple IP addresses will have multiple logical interfaces
            associated with it).

         o  Source router
            It is useful to be able to assign a single preference value

Top      Up      ToC       Page 84 
            to all routes (learned from the same routing domain) which
            were learned from any of a set of routers, where the set of
            routers are those whose updates have a source address which
            match a specified address/mask pair.

         o  Originating AS
            For routing protocols which provide the information, it is
            useful to be able to assign a single preference value to all
            routes (learned from a particular routing domain) which
            originated in another particular routing domain.  For BGP
            routes, the originating AS is the first AS listed in the
            route's AS_PATH attribute.  For OSPF external routes, the
            originating AS may be considered to be the low order 16 bits
            of the route's external route tag if the tag's Automatic bit
            is set and the tag's PathLength is not equal to 3.

         o  External route tag
            It is useful to be able to assign a single preference value
            to all OSPF external routes (learned from the same routing
            domain) whose external route tags match any of a list of
            specified values.  Because the external route tag may
            contain a structured value, it may be useful to provide the
            ability to match particular subfields of the tag.

         o  AS path
            It may be useful to be able to assign a single preference
            value to all BGP routes (learned from the same routing
            domain) whose AS path "matches" any of a set of specified
            values.  It is not yet clear exactly what kinds of matches
            are most useful.  A simple option would be to allow matching
            of all routes for which a particular AS number appears (or
            alternatively, does not appear) anywhere in the route's
            AS_PATH attribute.  A more general but somewhat more
            difficult alternative would be to allow matching all routes
            for which the AS path matches a specified regular
            expression.

5.2.4.6  Load Splitting

         At the end of the Next-hop selection process, multiple routes
         may still remain.  A router has several options when this
         occurs.  It may arbitrarily discard some of the routes.  It may
         reduce the number of candidate routes by comparing metrics of
         routes from routing domains which are not considered
         equivalent.  It may retain more than one route and employ a
         load-splitting mechanism to divide traffic among them.  Perhaps
         the only thing that can be said about the relative merits of

Top      Up      ToC       Page 85 
         the options is that load-splitting is useful in some situations
         but not in others, so a wise implementor who implements load-
         splitting will also provide a way for the network manager to
         disable it.

5.2.5  Unused IP Header Bits: RFC-791 Section 3.1

      The IP header contains several reserved bits, in the Type of
      Service field and in the Flags field.  Routers MUST NOT drop
      packets merely because one or more of these reserved bits has a
      non-zero value.

      Routers MUST ignore and MUST pass through unchanged the values of
      these reserved bits.  If a router fragments a packet, it MUST copy
      these bits into each fragment.

      DISCUSSION:
         Future revisions to the IP protocol may make use of these
         unused bits.  These rules are intended to ensure that these
         revisions can be deployed without having to simultaneously
         upgrade all routers in the Internet.


5.2.6  Fragmentation and Reassembly: RFC-791 Section 3.2

      As was discussed in Section [4.2.2.7], a router MUST support IP
      fragmentation.

      A router MUST NOT reassemble any datagram before forwarding it.

      DISCUSSION:
         A few people have suggested that there might be some topologies
         where reassembly of transit datagrams by routers might improve
         performance.  In general, however, the fact that fragments may
         take different paths to the destination precludes safe use of
         such a feature.

         Nothing in this section should be construed to control or limit
         fragmentation or reassembly performed as a link layer function
         by the router.

Top      Up      ToC       Page 86 
5.2.7  Internet Control Message Protocol - ICMP

      General requirements for ICMP were discussed in Section [4.3].
      This section discusses ICMP messages which are sent only by
      routers.

5.2.7.1  Destination Unreachable

         The ICMP Destination Unreachable message is sent by a router in
         response to a packet which it cannot forward because the
         destination (or next hop) is unreachable or a service is
         unavailable

         A router MUST be able to generate ICMP Destination Unreachable
         messages and SHOULD choose a response code that most closely
         matches the reason why the message is being generated.

         The following codes are defined in [INTERNET:8] and [INTRO:2]:

         0 =  Network Unreachable - generated by a router if a
              forwarding path (route) to the destination network is not
              available;

         1 =  Host Unreachable - generated by a router if a forwarding
              path (route) to the destination host on a directly
              connected network is not available;

         2 =  Protocol Unreachable - generated if the transport protocol
              designated in a datagram is not supported in the transport
              layer of the final destination;

         3 =  Port Unreachable -  generated if the designated transport
              protocol (e.g. UDP) is unable to demultiplex the datagram
              in the transport layer of the final destination but has no
              protocol mechanism to inform the sender;

         4 =  Fragmentation Needed and DF Set - generated if a router
              needs to fragment a datagram but cannot since the DF flag
              is set;

         5 =  Source Route Failed - generated if a router cannot forward
              a packet to the next hop in a source route option;

         6 =  Destination Network Unknown - This code SHOULD NOT be
              generated since it would imply on the part of the router
              that the destination network does not exist (net
              unreachable code 0 SHOULD be used in place of code 6);

Top      Up      ToC       Page 87 
         7 =  Destination Host Unknown - generated only when a router
              can determine (from link layer advice) that the
              destination host does not exist;

         11 = Network Unreachable For Type Of Service - generated by a
              router if a forwarding path (route) to the destination
              network with the requested or default TOS is not
              available;

         12 = Host Unreachable For Type Of Service - generated if a
              router cannot forward a packet because its route(s) to the
              destination do not match either the TOS requested in the
              datagram or the default TOS (0).

         The following additional codes are hereby defined:

         13 = Communication Administratively Prohibited - generated if a
              router cannot forward a packet due to administrative
              filtering;

         14 = Host Precedence Violation.  Sent by the first hop router
              to a host to indicate that a requested precedence is not
              permitted for the particular combination of
              source/destination host or network, upper layer protocol,
              and source/destination port;

         15 = Precedence cutoff in effect.  The network operators have
              imposed a minimum level of precedence required for
              operation, the datagram was sent with a precedence below
              this level;

         NOTE: [INTRO:2] defined Code 8 for source host isolated.
         Routers SHOULD NOT generate Code 8; whichever of Codes 0
         (Network Unreachable) and 1 (Host Unreachable) is appropriate
         SHOULD be used instead.  [INTRO:2] also defined Code 9 for
         communication with destination network administratively
         prohibited and Code 10 for communication with destination host
         administratively prohibited.  These codes were intended for use
         by end-to-end encryption devices used by U.S military agencies.
         Routers SHOULD use the newly defined Code 13 (Communication
         Administratively Prohibited) if they administratively filter
         packets.

         Routers MAY have a configuration option that causes Code 13
         (Communication Administratively Prohibited) messages not to be
         generated.  When this option is enabled, no ICMP error message
         is sent in response to a packet which is dropped because its

Top      Up      ToC       Page 88 
         forwarding is administratively prohibited.

         Similarly, routers MAY have a configuration option that causes
         Code 14 (Host Precedence Violation) and Code 15 (Precedence
         Cutoff in Effect) messages not to be generated.  When this
         option is enabled, no ICMP error message is sent in response to
         a packet which is dropped  because of a precedence violation.

         Routers MUST use Host Unreachable or Destination Host Unknown
         codes whenever other hosts on the same destination network
         might be reachable; otherwise, the source host may erroneously
         conclude that all hosts on the network are unreachable, and
         that may not be the case.

         [INTERNET:14] describes a slight modification the form of
         Destination Unreachable messages containing Code 4
         (Fragmentation needed and DF set).  A router MUST use this
         modified form when originating Code 4 Destination Unreachable
         messages.

5.2.7.2  Redirect

         The ICMP Redirect message is generated to inform a host on the
         same subnet that the router used by the host to route certain
         packets should be changed.

         Routers MUST NOT generate the Redirect for Network or Redirect
         for Network and Type of Service messages (Codes 0 and 2)
         specified in [INTERNET:8].  Routers MUST be able to generate
         the Redirect for Host message (Code 1) and SHOULD be able to
         generate the Redirect for Type of Service and Host message
         (Code 3) specified in [INTERNET:8].

         DISCUSSION:
            If the directly-connected network is not subnetted, a router
            can normally generate a network Redirect which applies to
            all hosts on a specified remote network.  Using a network
            rather than a host Redirect may economize slightly on
            network traffic and on host routing table storage.  However,
            the savings are not significant, and subnets create an
            ambiguity about the subnet mask to be used to interpret a
            network Redirect.  In a general subnet environment, it is
            difficult to specify precisely the cases in which network
            Redirects can be used.  Therefore, routers must send only
            host (or host and type of service) Redirects.

         A Code 3 (Redirect for Host and Type of Service) message is

Top      Up      ToC       Page 89 
         generated when the packet provoking the redirect has a
         destination for which the path chosen by the router would
         depend (in part) on the TOS requested.

         Routers which can generate Code 3 redirects (Host and Type of
         Service) MUST have a configuration option (which defaults to
         on) to enable Code 1 (Host) redirects to be substituted for
         Code 3 redirects.  A router MUST send a Code 1 Redirect in
         place of a Code 3 Redirect if it has been configured to do so.

         If a router is not able to generate Code 3 Redirects then it
         MUST generate Code 1 Redirects in situations where a Code 3
         Redirect is called for.

         Routers MUST NOT generate a Redirect Message unless all of the
         following conditions are met:

         o  The packet is being forwarded out the same physical
            interface that it was received from,

         o  The IP source address in the packet is on the same Logical
            IP (sub)network as the next-hop IP address, and

         o  The packet does not contain an IP source route option.

         The source address used in the ICMP Redirect MUST belong to the
         same logical (sub)net as the destination address.

         A router using a routing protocol (other than static routes)
         MUST NOT consider paths learned from ICMP Redirects when
         forwarding a packet.  If a router is not using a routing
         protocol, a router MAY have a configuration which, if set,
         allows the router to consider routes learned via ICMP Redirects
         when forwarding packets.

         DISCUSSION:
            ICMP Redirect is a mechanism for routers to convey routing
            information to hosts.  Routers use other mechanisms to learn
            routing information, and therefore have no reason to obey
            redirects.  Believing a redirect which contradicted the
            router's other information would likely create routing
            loops.

            On the other hand, when a router is not acting as a router,
            it MUST comply with the behavior required of a host.

Top      Up      ToC       Page 90 
5.2.7.3  Time Exceeded

         A router MUST generate a Time Exceeded message Code 0 (In
         Transit) when it discards a packet due to an expired TTL field.
         A router MAY have a per-interface option to disable origination
         of these messages on that interface, but that option MUST
         default to allowing the messages to be originated.

5.2.8  INTERNET GROUP MANAGEMENT PROTOCOL - IGMP

      IGMP [INTERNET:4] is a protocol used between hosts and multicast
      routers on a single physical network to establish hosts'
      membership in particular multicast groups.  Multicast routers use
      this information, in conjunction with a multicast routing
      protocol, to support IP multicast forwarding across the Internet.

      A router SHOULD implement the multicast router part of IGMP.

5.3  SPECIFIC ISSUES


5.3.1  Time to Live (TTL)

      The Time-to-Live (TTL) field of the IP header is defined to be a
      timer limiting the lifetime of a datagram.  It is an 8-bit field
      and the units are seconds.  Each router (or other module) that
      handles a packet MUST decrement the TTL by at least one, even if
      the elapsed time was much less than a second.  Since this is very
      often the case, the TTL is effectively a hop count limit on how
      far a datagram can propagate through the Internet.

      When a router forwards a packet, it MUST reduce the TTL by at
      least one.  If it holds a packet for more than one second, it MAY
      decrement the TTL by one for each second.

      If the TTL is reduced to zero (or less), the packet MUST be
      discarded, and if the destination is not a multicast address the
      router MUST send an ICMP Time Exceeded message, Code 0 (TTL
      Exceeded in Transit) message to the source.  Note that a router
      MUST NOT discard an IP unicast or broadcast packet with a non-zero
      TTL merely because it can predict that another router on the path
      to the packet's final destination will decrement the TTL to zero.
      However, a router MAY do so for IP multicasts, in order to more
      efficiently implement IP multicast's expanding ring search
      algorithm (see [INTERNET:4]).

Top      Up      ToC       Page 91 
      DISCUSSION:
         The IP TTL is used, somewhat schizophrenically, as both a hop
         count limit and a time limit.  Its hop count function is
         critical to ensuring that routing problems can't melt down the
         network by causing packets to loop infinitely in the network.
         The time limit function is used by transport protocols such as
         TCP to ensure reliable data transfer.  Many current
         implementations treat TTL as a pure hop count, and in parts of
         the Internet community there is a strong sentiment that the
         time limit function should instead be performed by the
         transport protocols that need it.

         In this specification, we have reluctantly decided to follow
         the strong belief among the router vendors that the time limit
         function should be optional.  They argued that implementation
         of the time limit function is difficult enough that it is
         currently not generally done.  They further pointed to the lack
         of documented cases where this shortcut has caused TCP to
         corrupt data (of course, we would expect the problems created
         to be rare and difficult to reproduce, so the lack of
         documented cases provides little reassurance that there haven't
         been a number of undocumented cases).

         IP multicast notions such as the expanding ring search may not
         work as expected unless the TTL is treated as a pure hop count.
         The same thing is somewhat true of traceroute.

         ICMP Time Exceeded messages are required because the traceroute
         diagnostic tool depends on them.

         Thus, the tradeoff is between severely crippling, if not
         eliminating, two very useful tools vs. a very rare and
         transient data transport problem (which may not occur at all).


5.3.2  Type of Service (TOS)

      The Type-of-Service byte in the IP header is divided into three
      sections:  the Precedence field (high-order 3 bits), a field that
      is customarily called Type of Service or "TOS (next 4 bits), and a
      reserved bit (the low order bit).  Rules governing the reserved
      bit were described in Section [4.2.2.3].  The Precedence field
      will be discussed in Section [5.3.3].  A more extensive discussion
      of the TOS field and its use can be found in [ROUTE:11].

      A router SHOULD consider the TOS field in a packet's IP header
      when deciding how to forward it.  The remainder of this section

Top      Up      ToC       Page 92 
      describes the rules that apply to routers that conform to this
      requirement.

      A router MUST maintain a TOS value for each route in its routing
      table.  Routes learned via a routing protocol which does not
      support TOS MUST be assigned a TOS of zero (the default TOS).

      To choose a route to a destination, a router MUST use an algorithm
      equivalent to the following:

      (1)  The router locates in its routing table all available routes
           to the destination (see Section [5.2.4]).

      (2)  If there are none, the router drops the packet because the
           destination is unreachable.  See section [5.2.4].

      (3)  If one or more of those routes have a TOS that exactly
           matches the TOS specified in the packet, the router chooses
           the route with the best metric.

      (4)  Otherwise, the router repeats the above step, except looking
           at routes whose TOS is zero.

      (5)  If no route was chosen above, the router drops the packet
           because the destination is unreachable.  The router returns
           an ICMP Destination Unreachable error specifying the
           appropriate code: either Network Unreachable with Type of
           Service (code 11) or Host Unreachable with Type of Service
           (code 12).

      DISCUSSION:
         Although TOS has been little used in the past, its use by hosts
         is now mandated by the Requirements for Internet Hosts RFCs
         ([INTRO:2] and [INTRO:3]).  Support for TOS in routers may
         become a MUST in the future, but is a SHOULD for now until we
         get more experience with it and can better judge both its
         benefits and its costs.

         Various people have proposed that TOS should affect other
         aspects of the forwarding function.  For example:

         (1)  A router could place packets which have the Low Delay bit
              set ahead of other packets in its output queues.

         (2)  a router is forced to discard packets, it could try to
              avoid discarding those which have the High Reliability bit
              set.

Top      Up      ToC       Page 93 
         These ideas have been explored in more detail in [INTERNET:17]
         but we don't yet have enough experience with such schemes to
         make requirements in this area.


5.3.3  IP Precedence

      This section specifies requirements and guidelines for appropriate
      processing of the IP Precedence field in routers.  Precedence is a
      scheme for allocating resources in the network based on the
      relative importance of different traffic flows.  The IP
      specification defines specific values to be used in this field for
      various types of traffic.

      The basic mechanisms for precedence processing in a router are
      preferential resource allocation, including both precedence-
      ordered queue service and precedence-based congestion control, and
      selection of Link Layer priority features.  The router also
      selects the IP precedence for routing, management and control
      traffic it originates.  For a more extensive discussion of IP
      Precedence and its implementation see [FORWARD:6].

      Precedence-ordered queue service, as discussed in this section,
      includes but is not limited to the queue for the forwarding
      process and queues for outgoing links.  It is intended that a
      router supporting precedence should also use the precedence
      indication at whatever points in its processing are concerned with
      allocation of finite resources, such as packet buffers or Link
      Layer connections.  The set of such points is implementation-
      dependent.

      DISCUSSION:
         Although the Precedence field was originally provided for use
         in DOD systems where large traffic surges or major damage to
         the network are viewed as inherent threats, it has useful
         applications for many non-military IP networks.  Although the
         traffic handling capacity of networks has grown greatly in
         recent years, the traffic generating ability of the users has
         also grown, and network overload conditions still occur at
         times.  Since IP-based routing and management protocols have
         become more critical to the successful operation of the
         Internet, overloads present two additional risks to the
         network:

         (1)  High delays may result in routing protocol packets being
              lost.  This may cause the routing protocol to falsely
              deduce a topology change and propagate this false

Top      Up      ToC       Page 94 
              information to other routers.  Not only can this cause
              routes to oscillate, but an extra processing burden may be
              placed on other routers.

         (2)  High delays may interfere with the use of network
              management tools to analyze and perhaps correct or relieve
              the problem in the network that caused the overload
              condition to occur.

         Implementation and appropriate use of the Precedence mechanism
         alleviates both of these problems.


5.3.3.1  Precedence-Ordered Queue Service

         Routers SHOULD implement precedence-ordered queue service.
         Precedence-ordered queue service means that when a packet is
         selected for output on a (logical) link, the packet of highest
         precedence that has been queued for that link is sent.  Routers
         that implement precedence-ordered queue service MUST also have
         a configuration option to suppress precedence-ordered queue
         service in the Internet Layer.

         Any router MAY implement other policy-based throughput
         management procedures that result in other than strict
         precedence ordering, but it MUST be configurable to suppress
         them (i.e., use strict ordering).

         As detailed in Section [5.3.6], routers that implement
         precedence-ordered queue service discard low precedence packets
         before discarding high precedence packets for congestion
         control purposes.

         Preemption (interruption of processing or transmission of a
         packet) is not envisioned as a function of the Internet Layer.
         Some protocols at other layers may provide preemption features.

5.3.3.2  Lower Layer Precedence Mappings

         Routers that implement precedence-ordered queueing MUST
         IMPLEMENT, and other routers SHOULD IMPLEMENT, Lower Layer
         Precedence Mapping.

         A router which implements Lower Layer Precedence Mapping:

         o  MUST be able to map IP Precedence to Link Layer priority
            mechanisms for link layers that have such a feature defined.

Top      Up      ToC       Page 95 
         o  MUST have a configuration option to select the Link Layer's
            default priority treatment for all IP traffic

         o  SHOULD be able to configure specific nonstandard mappings of
            IP precedence values to Link Layer priority values for each
            interface.

         DISCUSSION:
            Some research questions the workability of the priority
            features of some Link Layer protocols, and some networks may
            have faulty implementations of the link layer priority
            mechanism.  It seems prudent to provide an escape mechanism
            in case such problems show up in a network.

            On the other hand, there are proposals to use novel queueing
            strategies to implement special services such as low-delay
            service.  Special services and queueing strategies to
            support them need further research and experimentation
            before they are put into widespread use in the Internet.
            Since these requirements are intended to encourage (but not
            force) the use of precedence features in the hope of
            providing better Internet service to all users, routers
            supporting precedence-ordered queue service should default
            to maintaining strict precedence ordering regardless of the
            type of service requested.

            Implementors may wish to consider that correct link layer
            mapping of IP precedence is required by DOD policy for
            TCP/IP systems used on DOD networks.


5.3.3.3  Precedence Handling For All Routers

         A router (whether or not it employs precedence-ordered queue
         service):

         (1)  MUST accept and process incoming traffic of all precedence
              levels normally, unless it has been administratively
              configured to do otherwise.

         (2)  MAY implement a validation filter to administratively
              restrict the use of precedence levels by particular
              traffic sources.  If provided, this filter MUST NOT filter
              out or cut off the following sorts of ICMP error messages:
              Destination Unreachable, Redirect, Time Exceeded, and
              Parameter Problem.  If this filter is provided, the
              procedures required for packet filtering by addresses are

Top      Up      ToC       Page 96 
              required for this filter also.

              DISCUSSION:
                 Precedence filtering should be applicable to specific
                 source/destination IP Address pairs, specific
                 protocols, specific ports, and so on.

              An ICMP Destination Unreachable message with code 14
              SHOULD be sent when a packet is dropped by the validation
              filter, unless this has been suppressed by configuration
              choice.

         (3)  MAY implement a cutoff function which allows the router to
              be set to refuse or drop traffic with precedence below a
              specified level.  This function may be activated by
              management actions or by some implementation dependent
              heuristics, but there MUST be a configuration option to
              disable any heuristic mechanism that operates without
              human intervention.  An ICMP Destination Unreachable
              message with code 15 SHOULD be sent when a packet is
              dropped by the cutoff function, unless this has been
              suppressed by configuration choice.

              A router MUST NOT refuse to forward datagrams with IP
              precedence of 6 (Internetwork Control) or 7 (Network
              Control) solely due to precedence cutoff.  However, other
              criteria may be used in conjunction with precedence cutoff
              to filter high precedence traffic.

              DISCUSSION:
                 Unrestricted precedence cutoff could result in an
                 unintentional cutoff of routing and control traffic.
                 In general, host traffic should be restricted to a
                 value of 5 (CRITIC/ECP) or below although this is not a
                 requirement and may not be valid in certain systems.


         (4)  MUST NOT change precedence settings on packets it did not
              originate.

         (5)  SHOULD be able to configure distinct precedence values to
              be used for each routing or management protocol supported
              (except for those protocols, such as OSPF, which specify
              which precedence value must be used).

         (6)  MAY be able to configure routing or management traffic
              precedence values independently for each peer address.

Top      Up      ToC       Page 97 
         (7)  MUST respond appropriately to Link Layer precedence-
              related error indications where provided.  An ICMP
              Destination Unreachable message with code 15 SHOULD be
              sent when a packet is dropped because a link cannot accept
              it due to a precedence-related condition, unless this has
              been suppressed by configuration choice.

              DISCUSSION:
                 The precedence cutoff mechanism described in (3) is
                 somewhat controversial.  Depending on the topological
                 location of the area affected by the cutoff, transit
                 traffic may be directed by routing protocols into the
                 area of the cutoff, where it will be dropped.  This is
                 only a problem if another path which is unaffected by
                 the cutoff exists between the communicating points.
                 Proposed ways of avoiding this problem include
                 providing some minimum bandwidth to all precedence
                 levels even under overload conditions, or propagating
                 cutoff information in routing protocols.  In the
                 absence of a widely accepted (and implemented) solution
                 to this problem, great caution is recommended in
                 activating cutoff mechanisms in transit networks.

                 A transport layer relay could legitimately provide the
                 function prohibited by (4) above.  Changing precedence
                 levels may cause subtle interactions with TCP and
                 perhaps other protocols; a correct design is a non-
                 trivial task.

                 The intent of (5) and (6) (and the discussion of IP
                 Precedence in ICMP messages in Section [4.3.2]) is that
                 the IP precedence bits should be appropriately set,
                 whether or not this router acts upon those bits in any
                 other way.  We expect that in the future specifications
                 for routing protocols and network management protocols
                 will specify how the IP Precedence should be set for
                 messages sent by those protocols.

                 The appropriate response for (7) depends on the link
                 layer protocol in use.  Typically, the router should
                 stop trying to send offensive traffic to that
                 destination for some period of time, and should return
                 an ICMP Destination Unreachable message with code 15
                 (service not available for precedence requested) to the
                 traffic source.  It also should not try to reestablish
                 a preempted Link Layer connection for some period of
                 time.

Top      Up      ToC       Page 98 
5.3.4  Forwarding of Link Layer Broadcasts

      The encapsulation of IP packets in most Link Layer protocols
      (except PPP) allows a receiver to distinguish broadcasts and
      multicasts from unicasts simply by examining the Link Layer
      protocol headers (most commonly, the Link Layer destination
      address).  The rules in this section which refer to Link Layer
      broadcasts apply only to Link Layer protocols which allow
      broadcasts to be distinguished; likewise, the rules which refer to
      Link Layer multicasts apply only to Link Layer protocols which
      allow multicasts to be distinguished.

      A router MUST NOT forward any packet which the router received as
      a Link Layer broadcast (even if the IP destination address is also
      some form of broadcast address) unless the packet is an all-
      subnets-directed broadcast being forwarded as specified in
      [INTERNET:3].

      DISCUSSION:
         As noted in Section [5.3.5.3], forwarding of all-subnets-
         directed broadcasts in accordance with [INTERNET:3] is optional
         and is not something that routers do by default.

      A router MUST NOT forward any packet which the router received as
      a Link Layer multicast unless the packet's destination address is
      an IP multicast address.

      A router SHOULD silently discard a packet that is received via a
      Link Layer broadcast but does not specify an IP multicast or IP
      broadcast destination address.

      When a router sends a packet as a Link Layer broadcast, the IP
      destination address MUST be a legal IP broadcast or IP multicast
      address.

5.3.5  Forwarding of Internet Layer Broadcasts

      There are two major types of IP broadcast addresses; limited
      broadcast and directed broadcast.  In addition, there are three
      subtypes of directed broadcast; a broadcast directed to a
      specified network, a broadcast directed to a specified subnetwork,
      and a broadcast directed to all subnets of a specified network.
      Classification by a router of a broadcast into one of these
      categories depends on the broadcast address and on the router's
      understanding (if any) of the subnet structure of the destination
      network.  The same broadcast will be classified differently by
      different routers.

Top      Up      ToC       Page 99 
      A limited IP broadcast address is defined to be all-ones: { -1, -1
      } or 255.255.255.255.

      A net-directed broadcast is composed of the network portion of the
      IP address with a local part of all-ones, { <Network-number>, -1
      }.  For example, a Class A net broadcast address is
      net.255.255.255, a Class B net broadcast address is
      net.net.255.255 and a Class C net broadcast address is
      net.net.net.255 where net is a byte of the network address.

      An all-subnets-directed broadcast is composed of the network part
      of the IP address with a subnet and a host part of all-ones, {
      <Network-number>, -1, -1 }.  For example, an all-subnets broadcast
      on a subnetted class B network is net.net.255.255.  A network must
      be known to be subnetted and the subnet part must be all-ones
      before a broadcast can be classified as all-subnets-directed.

      A subnet-directed broadcast address is composed of the network and
      subnet part of the IP address with a host part of all-ones, {
      <Network-number>, <Subnet-number>, -1 }.  For example, a subnet-
      directed broadcast to subnet 2 of a class B network might be
      net.net.2.255 (if the subnet mask was 255.255.255.0) or
      net.net.1.127 (if the subnet mask was 255.255.255.128).  A network
      must be known to be subnetted and the net and subnet part must not
      be all-ones before an IP broadcast can be classified as subnet-
      directed.

      As was described in Section [4.2.3.1], a router may encounter
      certain non-standard IP broadcast addresses:

      o  0.0.0.0 is an obsolete form of the limited broadcast address

      o  { broadcast address.

      o  { broadcast address.

      o  { form of a subnet-directed broadcast address.

      As was described in that section, packets addressed to any of
      these addresses SHOULD be silently discarded, but if they are not,
      they MUST be treated in accordance with the same rules that apply
      to packets addressed to the non-obsolete forms of the broadcast
      addresses described above.  These rules are described in the next
      few sections.


Next RFC Part