home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2113.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  7.7 KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            D. Katz
  8. Request for Comments: 2113                                 cisco Systems
  9. Category: Standards Track                                  February 1997
  10.  
  11.                          IP Router Alert Option
  12.  
  13. Status of this Memo
  14.  
  15.    This document specifies an Internet standards track protocol for the
  16.    Internet community, and requests discussion and suggestions for
  17.    improvements.  Please refer to the current edition of the "Internet
  18.    Official Protocol Standards" (STD 1) for the standardization state
  19.    and status of this protocol.  Distribution of this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    This memo describes a new IP Option type that alerts transit routers
  24.    to more closely examine the contents of an IP packet.  This is useful
  25.    for, but not limited to, new protocols that are addressed to a
  26.    destination but require relatively complex processing in routers
  27.    along the path.
  28.  
  29. 1.0  Introduction
  30.  
  31.    A recent trend in routing protocols is to loosely couple new routing
  32.    functionality to existing unicast routing.  The motivation for this
  33.    is simple and elegant -- it allows deployment of new routing
  34.    functionality without having to reinvent all of the basic routing
  35.    protocol functions, greatly reducing specification and implementation
  36.    complexity.
  37.  
  38.    The downside of this is that the new functionality can only depend on
  39.    the least common denominator in unicast routing, the next hop toward
  40.    the destination.  No assumptions can be made about the existence of
  41.    more richly detailed information (such as a link state database).
  42.  
  43.    It is also desirable to be able to gradually deploy the new
  44.    technology, specifically to avoid having to upgrade all routers in
  45.    the path between source and destination.  This goal is somewhat at
  46.    odds with the least common denominator information available, since a
  47.    router that is not immediately adjacent to another router supporting
  48.    the new protocol has no way of determining the location or identity
  49.    of other such routers (unless something like a flooding algorithm is
  50.    implemented over unicast forwarding, which conflicts with the
  51.    simplicity goal).
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Katz                        Standards Track                     [Page 1]
  59.  
  60. RFC 2113                  Router Alert Option              February 1997
  61.  
  62.  
  63.    One obvious approach to leveraging unicast routing is to do hop-by-
  64.    hop forwarding of the new protocol packets along the path toward the
  65.    ultimate destination.  Each system that implements the new protocol
  66.    would be responsible for addressing the packet to the next system in
  67.    the path that understood it.  As noted above, however, it is
  68.    difficult to know the next system implementing the protocol.  The
  69.    simple, degenerate case is to assume that every system along the path
  70.    implements the protocol.  This is a barrier to phased deployment of
  71.    the new protocol, however.
  72.  
  73.    RSVP [1] finesses the problem by instead putting the address of the
  74.    ultimate destination in the IP Destination Address field, and then
  75.    asking that every RSVP router make a "small change in its ...
  76.    forwarding path" to look for the specific RSVP packet type and pull
  77.    such packets out of the mainline forwarding path, performing local
  78.    processing on the packets before forwarding them on.  This has the
  79.    decided advantage of allowing automatic tunneling through routers
  80.    that don't understand RSVP, since the packets will naturally flow
  81.    toward the ultimate destination.  However, the performance cost of
  82.    making this Small Change may be unacceptable, since the mainline
  83.    forwarding path of routers tends to be highly tuned--even the
  84.    addition of a single instruction may incur penalties of hundreds of
  85.    packets per second in performance.
  86.  
  87. 2.0  Router Alert Option
  88.  
  89.    The goal, then, is to provide a mechanism whereby routers can
  90.    intercept packets not addressed to them directly, without incurring
  91.    any significant performance penalty.  This document defines a new IP
  92.    option type, Router Alert, for this purpose.
  93.  
  94.    The Router Alert option has the semantic "routers should examine this
  95.    packet more closely".  By including the Router Alert option in the IP
  96.    header of its protocol message, RSVP can cause the message to be
  97.    intercepted while causing little or no performance penalty on the
  98.    forwarding of normal data packets.
  99.  
  100.    Routers that support option processing in the fast path already
  101.    demultiplex processing based on the option type field.  If all option
  102.    types are supported in the fast path, then the addition of another
  103.    option type to process is unlikely to impact performance.  If some
  104.    option types are not supported in the fast path, this new option type
  105.    will be unrecognized and cause packets carrying it to be kicked out
  106.    into the slow path, so no change to the fast path is necessary, and
  107.    no performance penalty will be incurred for regular data packets.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Katz                        Standards Track                     [Page 2]
  115.  
  116. RFC 2113                  Router Alert Option              February 1997
  117.  
  118.  
  119.    Routers that do not support option processing in the fast path will
  120.    cause packets carrying this new option to be forwarded through the
  121.    slow path, so no change to the fast path is necessary and no
  122.    performance penalty will be incurred for regular data packets.
  123.  
  124. 2.1  Syntax
  125.  
  126.    The Router Alert option has the following format:
  127.  
  128.                  +--------+--------+--------+--------+
  129.                  |10010100|00000100|  2 octet value  |
  130.                  +--------+--------+--------+--------+
  131.  
  132.    Type:
  133.      Copied flag:  1 (all fragments must carry the option)
  134.      Option class: 0 (control)
  135.      Option number: 20 (decimal)
  136.  
  137.    Length: 4
  138.  
  139.    Value:  A two octet code with the following values:
  140.      0 - Router shall examine packet
  141.      1-65535 - Reserved
  142.  
  143. 2.2  Semantics
  144.  
  145.    Hosts shall ignore this option.  Routers that do not recognize this
  146.    option shall ignore it.  Routers that recognize this option shall
  147.    examine packets carrying it more closely (check the IP Protocol
  148.    field, for example) to determine whether or not further processing is
  149.    necessary.  Unrecognized value fields shall be silently ignored.
  150.  
  151.    The semantics of other values in the Value field are for further
  152.    study.
  153.  
  154. 3.0  Impact on Other Protocols
  155.  
  156.    For this option to be effective, its use must be mandated in
  157.    protocols that expect routers to perform significant processing on
  158.    packets not directly addressed to them.  Currently such protocols
  159.    include RSVP [1] and IGMP [2].
  160.  
  161. 4.0 Security Considerations
  162.  
  163.    If the Router Alert option is not set and should be set, the behavior
  164.    of the protocol using the Router Alert, e.g., RSVP or IGMPv2, will be
  165.    adversely affected since the protocol relies on the use of the Router
  166.    Alert option.
  167.  
  168.  
  169.  
  170. Katz                        Standards Track                     [Page 3]
  171.  
  172. RFC 2113                  Router Alert Option              February 1997
  173.  
  174.  
  175.    If the Router Alert option is set when it should not be set, it is
  176.    likely that the flow will experience a performance penalty, as a
  177.    packet whose Router Alert option is set will not go through the
  178.    router's fastpath and will be processed in the router more slowly
  179.    than if the option were not set.
  180.  
  181. 5.0  References
  182.  
  183.    [1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin,
  184.        "Resource ReSerVation Protocol (RSVP)," work in progress, March
  185.        1996.
  186.  
  187.    [2] Fenner, W., "Internet Group Management Protocol, Version 2
  188.        (IGMPv2)," work in progress, October 1996.
  189.  
  190. Author's Address
  191.  
  192.       Dave Katz
  193.       cisco Systems
  194.       170 W. Tasman Dr.
  195.       San Jose, CA  95134-1706  USA
  196.  
  197.       Phone:  +1 408 526 8284
  198.       Email:  dkatz@cisco.com
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Katz                        Standards Track                     [Page 4]
  227.  
  228.