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