home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipngwg-ipv6router-alert-00.txt < prev    next >
Text File  |  1996-11-19  |  7KB  |  224 lines
  1. INTERNET-DRAFT                                                Dave Katz
  2. <draft-ietf-ipngwg-ipv6-router-alert-00.txt>           Randall Atkinson
  3.                                                           cisco Systems
  4.                                                        15 November 1996
  5.  
  6.  
  7.                         IPv6 Router Alert Option
  8.  
  9. Status of this Memo
  10.  
  11.    This document is an Internet Draft.  Internet Drafts are working
  12.    documents of the Internet Engineering Task Force (IETF), its Areas,
  13.    and its Working Groups.  Note that other groups may also distribute
  14.    working documents as Internet Drafts.
  15.  
  16.    Internet Drafts are draft documents valid for a maximum of six
  17.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  18.    other documents at any time.  It is not appropriate to use Internet
  19.    Drafts as reference material or to cite them other than as a "working
  20.    draft" or "work in progress."
  21.  
  22.    Please check the I-D abstract listing contained in each Internet
  23.    Draft directory to learn the current status of this or any Internet
  24.    Draft.
  25.  
  26. Abstract
  27.  
  28.    This memo describes a new IPv6 Hop-by-Hop Option type that alerts
  29.    transit routers to more closely examine the contents of an IP packet.
  30.    This is useful for protocols addressed to a destination but also
  31.    require special processing in routers along the path.
  32.  
  33. 1.0  Introduction
  34.  
  35.      IPv6 uses daisy-chained optional headers to increase flexibility
  36.    and remove the IPv4 constraint on how large options can be.  Because
  37.    several optional headers can be present between the base IPv6 header
  38.    and the final payload, more parsing effort is needed to determine
  39.    what kind of upper layer information is present in a given IPv6
  40.    packet.  Some control packets that are interesting to routers (e.g.
  41.    RSVP messages) are addressed to the same destination as data packets
  42.    belonging to that session.  It is desirable to forward the data-only
  43.    packets as rapidly as possible, while ensuring that the router
  44.    processes control packets appropriately.  At present, the router
  45.    cannot easily fast switch packets containing optional headers because
  46.    it needs to determine whether or not the upper layer information is
  47.    control information needed by the router.  As noted before, the
  48.    parsing to determine this causes the packet to traverse the slow path
  49.  
  50.  
  51.  
  52. Katz & Atkinson          Expires in 6 months                 [Page 1]
  53.  
  54. INTERNET-DRAFT              IPv6 Router Alert                3 June 1996
  55.  
  56.  
  57.    through the router.  This situation is undesirable.
  58.  
  59.      This draft proposes the addition of a new mandatory option within
  60.    the IPv6 Hop-by-Hop Header.  The presence of this new option in an
  61.    IPv6 packet informs the router to slow-path process this router and
  62.    handle any control data accordingly.  The absence of this option in
  63.    an IPv6 packet informs the router that the packet does not contain
  64.    information needed by the router and hence can safely be fast
  65.    switched without further packet parsing.  Hosts originating IPv6
  66.    packets are required to include this option in certain circumstances.
  67.  
  68. 3.0  Proposal
  69.  
  70.         The goal is to provide a mechanism whereby routers can intercept
  71.    packets not addressed to them directly without incurring any
  72.    significant performance penalty.  The proposed solution is to define
  73.    a new IPv6 Hop-by-Hop Header option having the semantic "routers
  74.    should examine this packet more closely" and require protocols such
  75.    as RSVP to use this option.  This would incur little performance
  76.    penalty on the forwarding of normal data packets.
  77.  
  78.         Routers that support option processing in the fast path already
  79.    demultiplex processing based on the Hop-by-Hop header options.  If
  80.    all hop-by-hop option types are supported in the fast path, then the
  81.    addition of another option type to process is unlikely to impact
  82.    performance.  If some hop-by-hop option types are not supported in
  83.    the fast path, this new option type will be unrecognized and cause
  84.    packets carrying it to be kicked out into the slow path, so no change
  85.    to the fast path is necessary, and no performance penalty will be
  86.    incurred for regular data packets.
  87.  
  88.         Routers that do not support option processing in the fast path
  89.    will cause packets carrying this new option to be forwarded through
  90.    the slow path, so no change to the fast path is necessary and no
  91.    performance penalty will be incurred for regular data packets.
  92.  
  93.  
  94. 3.1  Syntax
  95.  
  96.    The proposed option has the following format:
  97.  
  98.                  +--------+--------+--------+--------+
  99.                  |IANA=TBD| Len= 2 | Value (2 bytes) |
  100.                  +--------+--------+--------+--------+
  101.  
  102.         "IANA-TBD" is the Hop-by-Hop Option Type number allocated
  103.         by IANA for this option.
  104.  
  105.  
  106.  
  107.  
  108. Katz & Atkinson          Expires in 6 months                 [Page 2]
  109.  
  110. INTERNET-DRAFT              IPv6 Router Alert                3 June 1996
  111.  
  112.  
  113.         Nodes not recognising this option should skip over this option
  114.         and continue processing the header.  This option MUST NOT
  115.         change en route.
  116.  
  117.  
  118.         Value:  A 2 octet code with the following values:
  119.           0 - Packet contains ICMPv6 Group Membership message.
  120.           1 - Packet contains RSVP message.
  121.           2-255 - Reserved to IANA for future use.
  122.  
  123. 3.2  Semantics
  124.  
  125.         Hosts shall ignore this option upon receipt.  Routers that do
  126.    not recognize this option shall ignore it.  Routers that recognize
  127.    this option shall examine packets carrying it more closely (parse the
  128.    entire packet checking for interesting values of NextHeader fields,
  129.    for example) to determine whether or not further processing is
  130.    necessary.  The value field may be used by an implementation to speed
  131.    processing of the packet within the transit router.  Unrecognized
  132.    value fields shall be silently ignored.
  133.  
  134.    All other values of the VALUE field are reserved to IANA for future
  135.    use.
  136.  
  137.  
  138. 4.0  Impact on Other Protocols
  139.  
  140.         For this option to be effective, its use must be mandated in
  141.    protocols that expect routers to perform significant processing on
  142.    packets not directly addressed to them.
  143.  
  144.         All IPv6 packets containing an ICMPv6 Group Membership message
  145.    MUST contain this option within the IPv6 Hop-by-Hop Options Header of
  146.    such packets.
  147.  
  148.         All IPv6 packets containing an RSVP message MUST contain this
  149.    option within the IPv6 Hop-by-Hop Options Header of such packets.
  150.  
  151. 5.0  References
  152.  
  153.    [DH95] Deering, S. & R. Hinden, "IPv6 Specification", RFC-1883,
  154.             Internet Engineering Task Force, December 1995.
  155.  
  156.        [BZEHJ95] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S.
  157.        Jamin,      "Resource ReSerVation Protocol (RSVP)," Internet
  158.        Draft, 1996.
  159.  
  160.  
  161.  
  162.  
  163.  
  164. Katz & Atkinson          Expires in 6 months                 [Page 3]
  165.  
  166. INTERNET-DRAFT              IPv6 Router Alert                3 June 1996
  167.  
  168.  
  169. Authors' Addresses
  170.  
  171.    Dave Katz
  172.    cisco Systems
  173.    170 W. Tasman Dr.
  174.    San Jose, CA  95134-1706  USA
  175.  
  176.    Phone:  +1 (408) 526-8284
  177.    Email:  dkatz@cisco.com
  178.  
  179.  
  180.    Randall Atkinson
  181.    cisco Systems
  182.    170 W. Tasman Drive
  183.    San Jose, CA 95134-1706  USA
  184.  
  185.    Phone:  +1 (408) 526-6566
  186.    Email:  rja@cisco.com
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220. Katz & Atkinson          Expires in 6 months                 [Page 4]
  221.  
  222.  
  223. -- 
  224.