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 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]