Internet DRAFT - draft-cisco-ipv6-router-alert

draft-cisco-ipv6-router-alert



HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:17:41 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 16 Aug 1996 05:53:48 GMT
ETag: "2e7f5f-1dc3-32140cec"
Accept-Ranges: bytes
Content-Length: 7619
Connection: close
Content-Type: text/plain

INTERNET-DRAFT                                                Dave Katz
<draft-cisco-ipv6-router-alert-01.txt>                 Randall Atkinson
                                                          cisco Systems
                                                         13 August 1996


                        IPv6 Router Alert Option

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.

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 packet.
   This is useful for protocols addressed to a destination but also
   require special processing in routers along the path.

1.0  Introduction

     IPv6 uses daisy-chained optional headers to increase flexibility
   and remove the IPv4 constraint on how large options can be.  Because
   several optional headers can be present between the base IPv6 header
   and the final payload, more parsing effort is needed to determine
   what kind of upper layer information is present in a given IPv6
   packet.  Some control packets that are interesting to routers (e.g.
   RSVP messages) are addressed to the same destination as data packets
   belonging to that session.  It is desirable to forward the data-only
   packets as rapidly as possible, while ensuring that the router
   processes control packets appropriately.  At present, the router
   cannot easily fast switch packets containing optional headers because
   it needs to determine whether or not the upper layer information is
   control information needed by the router.  As noted before, the
   parsing to determine this causes the packet to traverse the slow path



Katz & Atkinson          Expires 13 February 1997                 [Page 1]

INTERNET-DRAFT              IPv6 Router Alert                3 June 1996


   through the router.  This situation is undesirable.

     This draft proposes the addition of a new mandatory option within
   the IPv6 Hop-by-Hop Header.  The presence of this new option in an
   IPv6 packet informs the router to slow-path process this router and
   handle any control data accordingly.  The absence of this option in
   an IPv6 packet informs the router that the packet does not contain
   information needed by the router and hence can safely be fast
   switched without further packet parsing.  Hosts originating IPv6
   packets are required to include this option in certain circumstances.

2.0  Proposal

        The goal is to provide a mechanism whereby routers can intercept
   packets not addressed to them directly without incurring any
   significant performance penalty.  The proposed solution is to define
   a new IPv6 Hop-by-Hop Header option having the semantic "routers
   should examine this packet more closely" and require protocols such
   as RSVP to use this option.  This would incur little performance
   penalty on the forwarding of normal data packets.

        Routers that support option processing in the fast path already
   demultiplex processing based on the Hop-by-Hop header options.  If
   all hop-by-hop option types are supported in the fast path, then the
   addition of another option type to process is unlikely to impact
   performance.  If some hop-by-hop option types are not supported in
   the fast path, this new option type will be unrecognized and cause
   packets carrying it to be kicked out into the slow path, so no change
   to the fast path is necessary, and no performance penalty will be
   incurred for regular data packets.

        Routers that do not support option processing in the fast path
   will cause packets carrying this new option to be forwarded through
   the slow path, so no change to the fast path is necessary and no
   performance penalty will be incurred for regular data packets.


2.1  Syntax

   The proposed option has the following format:

                 +--------+--------+--------+--------+
                 |IANA=TBD| Len= 2 | Value (2 bytes) |
                 +--------+--------+--------+--------+

        "IANA-TBD" is the Hop-by-Hop Option Type number allocated
        by IANA for this option.




Katz & Atkinson          Expires 13 February 1997                 [Page 2]

INTERNET-DRAFT              IPv6 Router Alert                3 June 1996


        Nodes not recognising this option should skip over this option
        and continue processing the header.  This option MUST NOT
        change en route.


        Value:  A 2 octet code with the following values:
          0 - Packet contains ICMPv6 Group Membership message.
          1 - Packet contains RSVP message.
          2-255 - Reserved to IANA for future use.

2.2  Semantics

        Hosts shall ignore this option upon receipt.  Routers that do
   not recognize this option shall ignore it.  Routers that recognize
   this option shall examine packets carrying it more closely (parse the
   entire packet 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 packet within the transit router.  Unrecognized
   value fields shall be silently ignored.

   All other values of the VALUE field are reserved to IANA for future
   use.


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
   packets not directly addressed to them.

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

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

4.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.





Katz & Atkinson          Expires 13 February 1997                 [Page 3]

INTERNET-DRAFT              IPv6 Router Alert                3 June 1996

5. SECURITY CONSIDERATIONS

This Router Alert option is included in the IPv6 Authentication Header
calculation because it does not vary in transit from the originating
system to the destination system.  It is not zeroed for AH calculations.

 
Authors' Addresses

   Dave Katz
   cisco Systems
   170 W. Tasman Dr.
   San Jose, CA  95134-1706  USA

   Phone:  +1 (408) 526-8284
   Email:  dkatz@cisco.com


   Randall Atkinson
   cisco Systems
   170 W. Tasman Drive
   San Jose, CA 95134-1706  USA

   Phone:  +1 (408) 526-6566
   Email:  rja@cisco.com

































Katz & Atkinson          Expires 13 February 1997                 [Page 4]