RFC 2711

IPv6 Router Alert Option 🎀

Title block, the tea 🫖: RFC 2711, from the Network Working Group, written by Craig Partridge (BBN) and A. Jackson (BBN). It's a Standards Track doc, dated October 1999. The title block doesn't list anything it obsoletes or updates, so there's no drama there. 💅

Status of This Memo

Okay so this doc is an Internet standards track protocol for the whole Internet community, and it's asking for discussion and suggestions for improvements 🙏. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved. 🌸

Abstract

Bestie, this memo introduces a brand new IPv6 Hop-by-Hop Option type that tells transit routers to take a closer look at what's inside an IP datagram 👀. It's super useful when a datagram aimed at one destination carries info that routers along the way might need to process specially 🦋.

1.0 Introduction ✨

So new protocols like RSVP send control datagrams. They're addressed to one destination, but the routers along the path need to peek at them and sometimes update them 🧚. We want regular datagrams to zoom through as fast as possible while still making sure routers handle these special control ones properly 🏎️💨. The problem is that right now, the only way a router can tell whether it needs to look closer is to at least partly parse upper layer data in every datagram. That parsing is expensive and slow, and honestly it's giving unbothered-no-it's-not 💀. This situation is undesirable.

This document defines a new option inside the IPv6 Hop-by-Hop Header 🎀. If the option is there, the router knows the datagram's contents are of interest to it and it should handle any control data accordingly 👑. If the option is missing, the router knows the datagram has nothing it needs, so it can be routed safely without any more parsing 🫶. Hosts that originate 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 [RFC-2119] 📚.

2.0 Approach 💖

The goal is an efficient way for routers to know when to grab datagrams that aren't addressed to them, without having to dig through every single one 🕵️‍♀️. The plan is to define a new IPv6 Hop-by-Hop Header option with the meaning "routers should examine this datagram more closely", and then have protocols like RSVP use it 🌈. This barely costs anything for normal datagrams. And if the option isn't there, that just tells the router there's no need to closely examine the contents, which is so efficient it's iconic ✨.

2.1 Syntax 🧚

The router alert option looks like this 👇:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0|        Value (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   length = 2

The first three bits of the first byte are zero, and the value 5 in the other five bits is the Hop-by-Hop Option Type number 🔢. [RFC-2460] is where the meaning of those first three bits is spelled out. By zeroing all three, this spec says that nodes that don't recognize this option type should skip over it and keep processing the header, and the option must not change en route 🙌.

There MUST only be one option of this type per Hop-by-Hop header, no matter what its value is 🛑. That's a hard rule, periodt 💅.

Value: a 2 octet code in network byte order, with these values 🍓:

0        Datagram contains a Multicast Listener Discovery
         message [RFC-2710].
1        Datagram contains RSVP message.
2        Datagram contains an Active Networks message.
3-65535  Reserved to IANA for future use.

Alignment requirement: 2n+0 📐

Values are registered and maintained by the IANA. See section 5.0 for more details 📝.

2.2 Semantics 🦋

The option says the contents of the datagram may be interesting to the router 👀. The router's interest and the actions it takes when it uses Router Alert MUST be specified in the RFC of the protocol that mandates or allows Router Alert. Honestly that's the rule that keeps everyone on the same page 🫶.

The final destination of the IPv6 datagram MUST ignore this option on receipt, so the datagram doesn't get evaluated more than once 🙈. Unrecognized value fields MUST be silently ignored, and header processing carries on 🤫.

Routers that recognize the option will look at datagrams carrying it more closely to decide whether they need further processing 🔍. The router only has to parse the packet far enough to decide if there's something of interest in it 🧐. The value field can be used by an implementation to speed up processing of the datagram at a transit router ⚡.

Also, further processing can involve protocol layers above IPv6. For example, RSVP messages have to go through UDP and RSVP protocol processing 🌊. Once the datagram leaves the IPv6 layer, it gets pretty ambiguous whether the router is acting as an IPv6 host or an IPv6 router 🤷‍♀️. Exactly how the router handles the contents depends on the value field. But if handling the datagram means looking at the payload of the IPv6 datagram, then the interim router is doing a host function, and it SHOULD interpret the data as a host 🎀.

3.0 Impact on Other Protocols 🌸

For this option to actually work, its use MUST be mandated in protocols that expect routers to do real processing on datagrams that aren't addressed to them 🧠. Routers aren't required to examine datagrams that aren't addressed to them, unless those datagrams include the router alert option 🙅‍♀️.

All IPv6 datagrams containing an RSVP message MUST contain this option within the IPv6 Hop-by-Hop Options Header of those datagrams 🎀. Non-negotiable, bestie 💜.

4.0 Security Considerations 🚨

Okay this part is serious 😭. Gratuitous use of this option can cause performance problems in routers 💀. A more severe attack is possible, where the router gets flooded with bogus datagrams containing router alert options 🌪️.

So if a router supports the option, it MAY limit its use by rate or some other means 🛡️. Protect that router, babe 🫶.

5.0 IANA Considerations 📚

The value field described in Section 2.1 is registered and maintained by IANA ✨. New values are to be assigned via IETF Consensus, as defined in RFC 2434 [RFC-2434] 🎀.

6.0 Notice on Intellectual Property 🔐

The IETF doesn't take a position on the validity or scope of any intellectual property or other rights that might be claimed to apply to the implementation or use of the technology described here 🙃. It also doesn't say it has tried to find any such rights. Info about the IETF's procedures for rights in standards-track and standards-related documents is in BCP-11. Copies of claims of rights made available for publication, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat 📬.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard 💌. Send that info to the IETF Executive Director 🫶.

7.0 References 📚

• [RFC-2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1977.
• [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC 2205, September 1997.
• [RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
• [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
• [RFC-2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.

6.0 Authors' Addresses 🧚

Craig Partridge
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
USA

Phone: +1 (617) 873-3000
EMail: craig@bbn.com


Alden Jackson
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
USA

Phone: +1 (617) 873-3000
EMail: awjacks@bbn.com

7.0 Full Copyright Statement 🎀

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🌈.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society ✨.