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-ipv6-router-alert-02.txt < prev    next >
Text File  |  1997-06-16  |  9KB  |  279 lines
  1.  
  2.  
  3. INTERNET-DRAFT                              Dave Katz, Juniper Networks
  4. Expires: December, 1997                        Randall Atkinson, @ Home
  5.                                                    Craig Partridge, BBN
  6.                                                      Alden Jackson, BBN
  7.                                                            13 June 1997
  8.  
  9.  
  10.                         IPv6 Router Alert Option
  11.  
  12.               <draft-ietf-ipngwg-ipv6-router-alert-02.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 14 December 1997.
  34.  
  35. Abstract
  36.  
  37.    This memo describes a new IPv6 Hop-by-Hop Option type that alerts
  38.    transit routers to more closely examine the contents of an IP
  39.    datagram.  This option is useful for situations where a datagram
  40.    addressed to a particular destination contains information that may
  41.    require special processing by routers along the path.
  42.  
  43.  
  44. 1.0  Introduction
  45.  
  46.    New protocols, such as RSVP, use control datagrams which, while
  47.    addressed to a particular destination, contain information that needs
  48.    to be examined, and in some case updated, by routers along the path
  49.    between the source and destination.  It is desirable to forward
  50.    regular datagrams as rapidly as possible, while ensuring that the
  51.  
  52.  
  53.  
  54. <draft-ietf-ipngwg-ipv6-router-alert-02.txt>                    [Page 1]
  55.  
  56. Internet Draft              IPv6 Router Alert               13 June 1997
  57.  
  58.  
  59.    router processes these special control datagrams appropriately.
  60.    Currently, however, the only way for a router to determine if it
  61.    needs to examine a datagram is to at least partially parse upper
  62.    layer data in all datagrams.  This parsing is expensive and slow.
  63.    This situation is undesirable.
  64.  
  65.    This draft defines a new option within the IPv6 Hop-by-Hop Header.
  66.    The presence of this option in an IPv6 datagram informs the router
  67.    that the contents of this datagram is of interest to the router and
  68.    to handle any control data accordingly.  The absence of this option
  69.    in an IPv6 datagram informs the router that the datagram does not
  70.    contain information needed by the router and hence can be safely
  71.    routed without further datagram parsing.  Hosts originating IPv6
  72.    datagrams are required to include this option in certain
  73.    circumstances.
  74.  
  75.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  76.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  77.    document are to be interpreted as described in [BRAD97].
  78.  
  79.  
  80. 2.0  Approach
  81.  
  82.    The goal is to provide an efficient mechanism whereby routers can
  83.    know when to intercept datagrams not addressed to them without having
  84.    to extensively examine every datagram.  The described solution is to
  85.    define a new IPv6 Hop-by-Hop Header option having the semantic
  86.    "routers should examine this datagram more closely" and require
  87.    protocols such as RSVP to use this option.  This approach incurs
  88.    little or no performance penalty on the forwarding of normal
  89.    datagrams.  Not including this option tells the router that there is
  90.    no need to closely examine the contents of the datagram.
  91.  
  92.  
  93. 2.1  Syntax
  94.  
  95.    The router alert option has the following format:
  96.  
  97.                  +--------+--------+--------+--------+
  98.                  |00| TBD | Len= 2 | Value (2 octets)|
  99.                  +--------+--------+--------+--------+
  100.  
  101.       "TBD" is the Hop-by-Hop Option Type number (To be allocated by
  102.       IANA).
  103.  
  104.       Nodes not recognizing this option type should skip over this
  105.       option and continue processing the header.  This option MUST NOT
  106.       change en route.  There must only be one option of this type,
  107.  
  108.  
  109.  
  110. <draft-ietf-ipngwg-ipv6-router-alert-02.txt>                    [Page 2]
  111.  
  112. Internet Draft              IPv6 Router Alert               13 June 1997
  113.  
  114.  
  115.       regardless of value, per Hop-by-Hop header.
  116.  
  117.       Value:  A 2 octet code in network byte order with the following
  118.       values:
  119.  
  120.          0        Datagram contains ICMPv6 Group Membership message.
  121.          1        Datagram contains RSVP message.
  122.          2     Datagram contains an Active Networks message.
  123.          3-65535  Reserved to IANA for future use.
  124.  
  125.    New value fields must be registered with the IANA.
  126.  
  127.  
  128. 2.2  Semantics
  129.  
  130.    The destination identified in the IPv6 header MUST ignore this option
  131.    upon receipt.  Nodes that do not recognize this option MUST ignore it
  132.    and continue processing the header.  Unrecognized value fields MUST
  133.    be silently ignored and the processing of the header continued.
  134.  
  135.    Routers that recognize this option MUST examine datagrams carrying it
  136.    more closely (parse the entire datagram checking for interesting
  137.    values of NextHeader fields, for example) to determine whether or not
  138.    further processing is necessary.  The value field may be used by an
  139.    implementation to speed processing of the datagram within the transit
  140.    router.
  141.  
  142.    Observe that further processing can involve protocol layers above
  143.    IPv6.  E.g., for RSVP messages, the datagram will have to undergo UDP
  144.    and RSVP protocol processing.  Once the datagram leaves the IPv6
  145.    layer, there is considerable ambiguity about whether the router is
  146.    acting as an IPv6 host or an IPv6 router.  Clearly once the datagram
  147.    leaves the IPv6 layer, any indication of the existence of extension
  148.    headers is lost.  Furthermore, any extension headers in the datagram
  149.    after the Hop-by-Hop header cannot be guaranteed to be evaluated
  150.    properly.  For this reason, extension headers other than the Hop-by-
  151.    Hop header SHOULD NOT be used with this option.
  152.  
  153.    The option indicates that the contents of the datagram may be
  154.    interesting to the router.  How the router handles the contents is
  155.    protocol specific.  The router's interest and the actions taken by
  156.    employing Router Alert MUST be specified in the RFC of the protocol
  157.    that mandates or allows the use of Router Alert.
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166. <draft-ietf-ipngwg-ipv6-router-alert-02.txt>                    [Page 3]
  167.  
  168. Internet Draft              IPv6 Router Alert               13 June 1997
  169.  
  170.  
  171. 3.0  Impact on Other Protocols
  172.  
  173.    For this option to be effective, its use MUST be mandated in
  174.    protocols that expect routers to perform significant processing on
  175.    datagrams not directly addressed to them.
  176.  
  177.    All IPv6 datagrams containing an ICMPv6 Group Membership message MUST
  178.    contain this option within the IPv6 Hop-by-Hop Options Header of such
  179.    datagrams.
  180.  
  181.    All IPv6 datagrams containing an RSVP message MUST contain this
  182.    option within the IPv6 Hop-by-Hop Options Header of such datagrams.
  183.  
  184.  
  185. 4.0  Security Considerations
  186.  
  187.    Gratuitous use of this option can cause performance problems in
  188.    routers.  The use of the option, if supported, MAY be limited by rate
  189.    or other means by the transit router.
  190.  
  191.  
  192. 5.0  References
  193.  
  194.     [DH95]    Deering, S. & R. Hinden, "IPv6 Specification", RFC-1883,
  195.               Internet Engineering Task Force, December 1995.
  196.  
  197.     [BZEHJ95] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S.
  198.               Jamin, "Resource ReSerVation Protocol (RSVP)," Internet
  199.               Draft, 1996.
  200.  
  201.     [BRAD97]  Bradner, S., "Key words for use in RFC's to Indicate
  202.               Requirement Levels", RFC-2119, Internet Engineering Task
  203.               Force, March 1977.
  204.  
  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-02.txt>                    [Page 4]
  223.  
  224. Internet Draft              IPv6 Router Alert               13 June 1997
  225.  
  226.  
  227.    Craig Partridge                         Phone: +1 (617) 873-3000
  228.    BBN Systems and 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 Systems and 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-02.txt>                    [Page 5]
  279.