rfc-2711

IPv6 Router Alert Option

C. Partridge, A. Jackson
date1999-10 streamIETF areaint wgipngwg statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc2711 doi10.17487/RFC2711
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. [STANDARDS-TRACK]

updated by

Extracted elements (15)

design-rationale §1.0

The option was introduced because the only prior way for a router to determine whether it needed to examine a datagram was to partially parse upper-layer data in every datagram, which was expensive and slow. The Router Alert option avoids this overhead by explicitly signaling router interest.

ip, v6ops

design-rationale §2.1

The top 3 bits of the option type byte are zeroed, following RFC 2460 semantics: nodes not recognizing this option type will skip over it and continue processing, and the option must not change en route.

ip, v6ops

interoperability-note §3.0

Routers are not required to examine datagrams not addressed to them unless those datagrams include the Router Alert option. Protocols relying on router inspection of transit datagrams must mandate use of this option.

ip, v6ops

normative-requirement §3.0 MUST

All IPv6 datagrams containing an RSVP message MUST include the Router Alert option within the IPv6 Hop-by-Hop Options Header.

ip, v6ops

normative-requirement §3.0 MUST

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

ip, v6ops

normative-requirement §2.2 SHOULD

If processing a datagram with the Router Alert option requires examining the IPv6 payload, the transit router is performing a host function and SHOULD interpret the data as a host.

ip, v6ops

normative-requirement §2.2 MUST

The final destination of an IPv6 datagram carrying the Router Alert option MUST ignore this option upon receipt to prevent multiple evaluations of the datagram.

ip, v6ops

normative-requirement §2.2 MUST

The router's interest and actions taken by employing Router Alert MUST be specified in the RFC of the protocol that mandates or allows its use.

ip, v6ops

normative-requirement §2.1 MUST

There MUST only be one Router Alert option, regardless of value, per Hop-by-Hop header.

ip, v6ops

normative-requirement §2.2 MUST

Unrecognized Router Alert value fields MUST be silently ignored and processing of the header continued.

ip, v6ops

protocol-element §1.0

The IPv6 Router Alert Option is a new Hop-by-Hop Option type that signals transit routers to more closely examine the contents of a datagram. Its presence indicates the datagram may require special processing by routers along the path; its absence signals safe forwarding without further parsing.

ip, v6ops

protocol-element §2.1

The Value field is a 2-octet code identifying the type of content requiring router attention: 0 = Multicast Listener Discovery (MLD), 1 = RSVP message, 2 = Active Networks message, 3-65535 reserved for IANA future use.

ip, v6ops, registry

registry §5.0

The Router Alert Option Value field is registered and maintained by IANA. New values are assigned via IETF Consensus as defined in RFC 2434. Initial values: 0 (MLD), 1 (RSVP), 2 (Active Networks), 3-65535 reserved.

registry, ip, v6ops

security-consideration §4.0 MAY

Gratuitous or malicious use of the Router Alert option can cause performance problems in routers. A severe attack involves flooding a router with bogus datagrams containing Router Alert options. Transit routers MAY rate-limit or otherwise restrict processing of this option to mitigate such attacks.

ip, v6ops, security

wire-format §2.1

The Router Alert option is 4 bytes total: a 1-byte type field (0x05 with top 3 bits zero), a 1-byte length field (value=2), and a 2-octet Value field in network byte order. Alignment requirement is 2n+0.

ip, v6ops