INTERNET-DRAFT Dave Katz, Juniper Networks
Randall Atkinson, @ Home
21 April 1997
IPv6 Router Alert Option
<draft-ietf-ipngwg-ipv6router-alert-01.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 October 21, 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 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 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
<draft-ietf-ipngwg-ipv6router-alert-01.txt> [Page 1]
Katz & Atkinson IPv6 Router Alert 21 April 1997
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
through the router. This situation is undesirable.
This draft defines the a new mandatory option within the IPv6 Hop-by-
Hop Header. The presence of this 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 Approach
The goal is to provide a mechanism whereby routers can intercept
packets not addressed to them directly without incurring any
significant performance penalty. The described 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.
<draft-ietf-ipngwg-ipv6router-alert-01.txt> [Page 2]
Katz & Atkinson IPv6 Router Alert 21 April 1997
2.1 Syntax
The router alert option has the following format:
+--------+--------+--------+--------+
|IANA=TBD| Len= 2 | Value (2 octets)|
+--------+--------+--------+--------+
"IANA-TBD" is the Hop-by-Hop Option Type number (To be allocated
by IANA).
Nodes not recognizing 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-65535 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
<draft-ietf-ipngwg-ipv6router-alert-01.txt> [Page 3]
Katz & Atkinson IPv6 Router Alert 21 April 1997
within the IPv6 Hop-by-Hop Options Header of such packets.
4.0 Security Considerations
Security issues are not discussed in this document.
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.
Authors' Addresses
Dave Katz
Juniper Networks
3260 Jay Street
Santa Clara, CA 95054
USA
Phone: +1 (408) 327-0173
Email: dkatz@jnx.com
Randall Atkinson
@ Home Network
385 Ravendale Drive
Mountain View, CA 94043
Phone: +1 (415) 944-7200
Email: rja@inet.org
<draft-ietf-ipngwg-ipv6router-alert-01.txt> [Page 4]
