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-03.txt < prev    next >
Text File  |  1997-07-30  |  9KB  |  279 lines
  1.  
  2.  
  3. INTERNET-DRAFT                              Dave Katz, Juniper Networks
  4.                                                Randall Atkinson, @ Home
  5.                                                    Craig Partridge, BBN
  6.                                                      Alden Jackson, BBN
  7.                                                            29 July 1997
  8.  
  9.  
  10.                         IPv6 Router Alert Option
  11.  
  12.               <draft-ietf-ipngwg-ipv6-router-alert-03.txt>
  13.  
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document is an Internet Draft.  Internet Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its Areas,
  20.    and its Working Groups.  Note that other groups may also distribute
  21.    working documents as Internet Drafts.
  22.  
  23.    Internet Drafts are draft documents valid for a maximum of six
  24.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  25.    other documents at any time.  It is not appropriate to use Internet
  26.    Drafts as reference material or to cite them other than as a "working
  27.    draft" or "work in progress."
  28.  
  29.    Please check the I-D abstract listing contained in each Internet
  30.    Draft directory to learn the current status of this or any Internet
  31.    Draft.
  32.  
  33.    This draft expires 29 January 1998 and reflects comments received
  34.    during the WG last call.
  35.  
  36. Abstract
  37.  
  38.    This memo describes a new IPv6 Hop-by-Hop Option type that alerts
  39.    transit routers to more closely examine the contents of an IP
  40.    datagram.  This option is useful for situations where a datagram
  41.    addressed to a particular destination contains information that may
  42.    require special processing by routers along the path.
  43.  
  44.  
  45. 1.0  Introduction
  46.  
  47.    New protocols, such as RSVP, use control datagrams which, while
  48.    addressed to a particular destination, contain information that needs
  49.    to be examined, and in some case updated, by routers along the path
  50.    between the source and destination.  It is desirable to forward
  51.  
  52.  
  53.  
  54. <draft-ietf-ipngwg-ipv6-router-alert-03.txt>            [Page 1]
  55.  
  56. Internet Draft             IPv6 Router Alert                29 July 1997
  57.  
  58.  
  59.    regular datagrams as rapidly as possible, while ensuring that the
  60.    router processes these special control datagrams appropriately.
  61.    Currently, however, the only way for a router to determine if it
  62.    needs to examine a datagram is to at least partially parse upper
  63.    layer data in all datagrams.  This parsing is expensive and slow.
  64.    This situation is undesirable.
  65.  
  66.    This draft defines a new option within the IPv6 Hop-by-Hop Header.
  67.    The presence of this option in an IPv6 datagram informs the router
  68.    that the contents of this datagram is of interest to the router and
  69.    to handle any control data accordingly.  The absence of this option
  70.    in an IPv6 datagram informs the router that the datagram does not
  71.    contain information needed by the router and hence can be safely
  72.    routed without further datagram parsing.  Hosts originating IPv6
  73.    datagrams are required to include this option in certain
  74.    circumstances.
  75.  
  76.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  77.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  78.    document are to be interpreted as described in [BRAD97].
  79.  
  80.  
  81. 2.0  Approach
  82.  
  83.    The goal is to provide an efficient mechanism whereby routers can
  84.    know when to intercept datagrams not addressed to them without having
  85.    to extensively examine every datagram.  The described solution is to
  86.    define a new IPv6 Hop-by-Hop Header option having the semantic
  87.    "routers should examine this datagram more closely" and require
  88.    protocols such as RSVP to use this option.  This approach incurs
  89.    little or no performance penalty on the forwarding of normal
  90.    datagrams.  Not including this option tells the router that there is
  91.    no need to closely examine the contents of the datagram.
  92.  
  93.  
  94. 2.1  Syntax
  95.  
  96.    The router alert option has the following format:
  97.  
  98.                  +--------+--------+--------+--------+
  99.                  |00| TBD | Len= 2 | Value (2 octets)|
  100.                  +--------+--------+--------+--------+
  101.  
  102.       "TBD" is the Hop-by-Hop Option Type number (To be allocated by the
  103.       IANA).
  104.  
  105.       Nodes not recognizing this option type SHOULD skip over this
  106.       option and continue processing the header.  This option MUST NOT
  107.  
  108.  
  109.  
  110. <draft-ietf-ipngwg-ipv6-router-alert-03.txt>            [Page 2]
  111.  
  112. Internet Draft             IPv6 Router Alert                29 July 1997
  113.  
  114.  
  115.       change en route.  There MUST only be one option of this type,
  116.       regardless of value, per Hop-by-Hop header.
  117.  
  118.       Value:  A 2 octet code in network byte order with the following
  119.       values:
  120.  
  121.          0        Datagram contains ICMPv6 Group Membership message.
  122.          1        Datagram contains RSVP message.
  123.          2        Datagram contains an Active Networks message [ANEP97].
  124.          3-65535  Reserved to IANA for future use.
  125.  
  126.    New value fields must be registered with the IANA.
  127.  
  128.  
  129. 2.2  Semantics
  130.  
  131.    The destination identified in the IPv6 header MUST ignore this option
  132.    upon receipt.  Nodes that do not recognize this option MUST ignore it
  133.    and continue processing the header.  Unrecognized value fields MUST
  134.    be silently ignored and the processing of the header continued.
  135.  
  136.    Routers that recognize this option MUST examine datagrams carrying it
  137.    more closely to determine whether or not further processing is
  138.    necessary.  The router only needs to parse the packet in sufficient
  139.    detail to decide whether the packet contains something of interest.
  140.    The value field can be used by an implementation to speed processing
  141.    of the datagram within the transit router.
  142.  
  143.    Observe that further processing can involve protocol layers above
  144.    IPv6.  E.g., for RSVP messages, the datagram will have to undergo UDP
  145.    and RSVP protocol processing.  Once the datagram leaves the IPv6
  146.    layer, there is considerable ambiguity about whether the router is
  147.    acting as an IPv6 host or an IPv6 router.  Precisely how the router
  148.    handles the contents is value-field specific.  However, if the
  149.    processing required for the datagram involves examining the payload
  150.    of the IPv6 datagram, then the interim router is performing a host
  151.    function and SHOULD interpret the data as a host.
  152.  
  153.    The option indicates that the contents of the datagram may be
  154.    interesting to the router.  The router's interest and the actions
  155.    taken by employing Router Alert MUST be specified in the RFC of the
  156.    protocol that mandates or allows the use of Router Alert.
  157.  
  158.  
  159. 3.0  Impact on Other Protocols
  160.  
  161.    For this option to be effective, its use MUST be mandated in
  162.    protocols that expect routers to perform significant processing on
  163.  
  164.  
  165.  
  166. <draft-ietf-ipngwg-ipv6-router-alert-03.txt>            [Page 3]
  167.  
  168. Internet Draft             IPv6 Router Alert                29 July 1997
  169.  
  170.  
  171.    datagrams not directly addressed to them.
  172.  
  173.    All IPv6 datagrams containing an ICMPv6 Group Membership message MUST
  174.    contain this option within the IPv6 Hop-by-Hop Options Header of such
  175.    datagrams.
  176.  
  177.    All IPv6 datagrams containing an RSVP message MUST contain this
  178.    option within the IPv6 Hop-by-Hop Options Header of such datagrams.
  179.  
  180.  
  181. 4.0  Security Considerations
  182.  
  183.    Gratuitous use of this option can cause performance problems in
  184.    routers.  The use of the option, if supported, MAY be limited by rate
  185.    or other means by the transit router.
  186.  
  187.  
  188. 5.0  References
  189.  
  190.     [DH95]    Deering, S. & R. Hinden, "IPv6 Specification", RFC-1883,
  191.               Internet Engineering Task Force, December 1995.
  192.  
  193.     [BZEHJ95] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S.
  194.               Jamin, "Resource ReSerVation Protocol (RSVP)," Internet
  195.               Draft, 1996.
  196.  
  197.     [BRAD97]  Bradner, S., "Key words for use in RFC's to Indicate
  198.               Requirement Levels", RFC-2119, Internet Engineering Task
  199.               Force, March 1977.
  200.  
  201.     [ANEP97]  Alexander, D., B. Braden, C. Gunther, A. Jackson, A.
  202.               Keromytis, G. Minden, D. Wetherall, "Active Network
  203.               Encapsulation Protocol (ANEP)", DRAFT, July 1977,
  204.               http://www.cis.upenn.edu/~angelos/ANEP.txt.
  205.  
  206. 6.0  Authors' Addresses
  207.  
  208.    Dave Katz                               Phone:  +1 (408) 327-0173
  209.    Juniper Networks                        Email:  dkatz@jnx.com
  210.    3260 Jay Street
  211.    Santa Clara, CA 95054
  212.    USA
  213.  
  214.    Randall Atkinson                        Phone:  +1 (415) 944-7200
  215.    @ Home Network                          Email:  rja@inet.org
  216.    385 Ravendale Drive
  217.    Mountain View, CA 94043
  218.    USA
  219.  
  220.  
  221.  
  222. <draft-ietf-ipngwg-ipv6-router-alert-03.txt>            [Page 4]
  223.  
  224. Internet Draft             IPv6 Router Alert                29 July 1997
  225.  
  226.  
  227.    Craig Partridge                         Phone: +1 (617) 873-3000
  228.    BBN Technologies                        Email: craig@bbn.com
  229.    10 Moulton Street
  230.    Cambridge, MA 02138
  231.    USA
  232.  
  233.    Alden Jackson                           Phone: +1 (617) 873-3000
  234.    BBN Technologies                        Email: awjacks@bbn.com
  235.    10 Moulton Street
  236.    Cambridge, MA 02138
  237.    USA
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. <draft-ietf-ipngwg-ipv6-router-alert-03.txt>            [Page 5]
  279.