INTERNET-DRAFT Dave Katz, Juniper Networks
Randall Atkinson, @ Home
Craig Partridge, BBN
Alden Jackson, BBN
29 July 1997
IPv6 Router Alert Option
<draft-ietf-ipngwg-ipv6-router-alert-03.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 29 January 1998 and reflects comments received
during the WG last call.
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
<draft-ietf-ipngwg-ipv6-router-alert-03.txt> [Page 1]
Internet Draft IPv6 Router Alert 29 July 1997
regular datagrams as rapidly as possible, while ensuring that the
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 the
IANA).
Nodes not recognizing this option type SHOULD skip over this
option and continue processing the header. This option MUST NOT
<draft-ietf-ipngwg-ipv6-router-alert-03.txt> [Page 2]
Internet Draft IPv6 Router Alert 29 July 1997
change en route. There MUST only be one option of this type,
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 [ANEP97].
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 to determine whether or not further processing is
necessary. The router only needs to parse the packet in sufficient
detail to decide whether the packet contains something of interest.
The value field can 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. Precisely how the router
handles the contents is value-field specific. However, if the
processing required for the datagram involves examining the payload
of the IPv6 datagram, then the interim router is performing a host
function and SHOULD interpret the data as a host.
The option indicates that the contents of the datagram may be
interesting to the router. 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.
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
<draft-ietf-ipngwg-ipv6-router-alert-03.txt> [Page 3]
Internet Draft IPv6 Router Alert 29 July 1997
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.
[ANEP97] Alexander, D., B. Braden, C. Gunther, A. Jackson, A.
Keromytis, G. Minden, D. Wetherall, "Active Network
Encapsulation Protocol (ANEP)", DRAFT, July 1977,
http://www.cis.upenn.edu/~angelos/ANEP.txt.
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
<draft-ietf-ipngwg-ipv6-router-alert-03.txt> [Page 4]
Internet Draft IPv6 Router Alert 29 July 1997
Craig Partridge Phone: +1 (617) 873-3000
BBN Technologies Email: craig@bbn.com
10 Moulton Street
Cambridge, MA 02138
USA
Alden Jackson Phone: +1 (617) 873-3000
BBN Technologies Email: awjacks@bbn.com
10 Moulton Street
Cambridge, MA 02138
USA
<draft-ietf-ipngwg-ipv6-router-alert-03.txt> [Page 5]
