Internet Draft


INTERNET-DRAFT                              Dave Katz, Juniper Networks
Expires: December, 1997                        Randall Atkinson, @ Home
                                                   Craig Partridge, BBN
                                                     Alden Jackson, BBN
                                                           13 June 1997


                        IPv6 Router Alert Option

              <draft-ietf-ipngwg-ipv6router-alert-02.txt>



Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any Internet
   Draft.

   This draft expires 14 December 1997.

Abstract

   This memo describes a new IPv6 Hop-by-Hop Option type that alerts
   transit routers to more closely examine the contents of an IP
   datagram.  This option is useful for situations where a datagram
   addressed to a particular destination contains information that may
   require special processing by routers along the path.


1.0  Introduction

   New protocols, such as RSVP, use control datagrams which, while
   addressed to a particular destination, contain information that needs
   to be examined, and in some case updated, by routers along the path
   between the source and destination.  It is desirable to forward
   regular datagrams as rapidly as possible, while ensuring that the



                    [Page 1]

Internet Draft              IPv6 Router Alert               13 June 1997


   router processes these special control datagrams appropriately.
   Currently, however, the only way for a router to determine if it
   needs to examine a datagram is to at least partially parse upper
   layer data in all datagrams.  This parsing is expensive and slow.
   This situation is undesirable.

   This draft defines a new option within the IPv6 Hop-by-Hop Header.
   The presence of this option in an IPv6 datagram informs the router
   that the contents of this datagram is of interest to the router and
   to handle any control data accordingly.  The absence of this option
   in an IPv6 datagram informs the router that the datagram does not
   contain information needed by the router and hence can be safely
   routed without further datagram parsing.  Hosts originating IPv6
   datagrams are required to include this option in certain
   circumstances.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [BRAD97].


2.0  Approach

   The goal is to provide an efficient mechanism whereby routers can
   know when to intercept datagrams not addressed to them without having
   to extensively examine every datagram.  The described solution is to
   define a new IPv6 Hop-by-Hop Header option having the semantic
   "routers should examine this datagram more closely" and require
   protocols such as RSVP to use this option.  This approach incurs
   little or no performance penalty on the forwarding of normal
   datagrams.  Not including this option tells the router that there is
   no need to closely examine the contents of the datagram.


2.1  Syntax

   The router alert option has the following format:

                 +--------+--------+--------+--------+
                 |00| TBD | Len= 2 | Value (2 octets)|
                 +--------+--------+--------+--------+

      "TBD" is the Hop-by-Hop Option Type number (To be allocated by
      IANA).

      Nodes not recognizing this option type should skip over this
      option and continue processing the header.  This option MUST NOT
      change en route.  There must only be one option of this type,



                    [Page 2]

Internet Draft              IPv6 Router Alert               13 June 1997


      regardless of value, per Hop-by-Hop header.

      Value:  A 2 octet code in network byte order with the following
      values:

         0        Datagram contains ICMPv6 Group Membership message.
         1        Datagram contains RSVP message.
         2     Datagram contains an Active Networks message.
         3-65535  Reserved to IANA for future use.

   New value fields must be registered with the IANA.


2.2  Semantics

   The destination identified in the IPv6 header MUST ignore this option
   upon receipt.  Nodes that do not recognize this option MUST ignore it
   and continue processing the header.  Unrecognized value fields MUST
   be silently ignored and the processing of the header continued.

   Routers that recognize this option MUST examine datagrams carrying it
   more closely (parse the entire datagram checking for interesting
   values of NextHeader fields, for example) to determine whether or not
   further processing is necessary.  The value field may be used by an
   implementation to speed processing of the datagram within the transit
   router.

   Observe that further processing can involve protocol layers above
   IPv6.  E.g., for RSVP messages, the datagram will have to undergo UDP
   and RSVP protocol processing.  Once the datagram leaves the IPv6
   layer, there is considerable ambiguity about whether the router is
   acting as an IPv6 host or an IPv6 router.  Clearly once the datagram
   leaves the IPv6 layer, any indication of the existence of extension
   headers is lost.  Furthermore, any extension headers in the datagram
   after the Hop-by-Hop header cannot be guaranteed to be evaluated
   properly.  For this reason, extension headers other than the Hop-by-
   Hop header SHOULD NOT be used with this option.

   The option indicates that the contents of the datagram may be
   interesting to the router.  How the router handles the contents is
   protocol specific.  The router's interest and the actions taken by
   employing Router Alert MUST be specified in the RFC of the protocol
   that mandates or allows the use of Router Alert.








                    [Page 3]

Internet Draft              IPv6 Router Alert               13 June 1997


3.0  Impact on Other Protocols

   For this option to be effective, its use MUST be mandated in
   protocols that expect routers to perform significant processing on
   datagrams not directly addressed to them.

   All IPv6 datagrams containing an ICMPv6 Group Membership message MUST
   contain this option within the IPv6 Hop-by-Hop Options Header of such
   datagrams.

   All IPv6 datagrams containing an RSVP message MUST contain this
   option within the IPv6 Hop-by-Hop Options Header of such datagrams.


4.0  Security Considerations

   Gratuitous use of this option can cause performance problems in
   routers.  The use of the option, if supported, MAY be limited by rate
   or other means by the transit router.


5.0  References

    [DH95]    Deering, S. & R. Hinden, "IPv6 Specification", RFC-1883,
              Internet Engineering Task Force, December 1995.

    [BZEHJ95] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S.
              Jamin, "Resource ReSerVation Protocol (RSVP)," Internet
              Draft, 1996.

    [BRAD97]  Bradner, S., "Key words for use in RFC's to Indicate
              Requirement Levels", RFC-2119, Internet Engineering Task
              Force, March 1977.


6.0  Authors' Addresses

   Dave Katz                               Phone:  +1 (408) 327-0173
   Juniper Networks                        Email:  dkatz@jnx.com
   3260 Jay Street
   Santa Clara, CA 95054
   USA

   Randall Atkinson                        Phone:  +1 (415) 944-7200
   @ Home Network                          Email:  rja@inet.org
   385 Ravendale Drive
   Mountain View, CA 94043
   USA



                    [Page 4]

Internet Draft              IPv6 Router Alert               13 June 1997


   Craig Partridge                         Phone: +1 (617) 873-3000
   BBN Systems and Technologies            Email: craig@bbn.com
   10 Moulton Street
   Cambridge, MA 02138
   USA

   Alden Jackson                           Phone: +1 (617) 873-3000
   BBN Systems and Technologies            Email: awjacks@bbn.com
   10 Moulton Street
   Cambridge, MA 02138
   USA








































                    [Page 5]