From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5350.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc5350.txt (limited to 'doc/rfc/rfc5350.txt') diff --git a/doc/rfc/rfc5350.txt b/doc/rfc/rfc5350.txt new file mode 100644 index 0000000..6f1990a --- /dev/null +++ b/doc/rfc/rfc5350.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group J. Manner +Request for Comments: 5350 TKK +Updates: 2113, 3175 A. McDonald +Category: Standards Track Siemens/Roke + September 2008 + + + IANA Considerations for the IPv4 and IPv6 Router Alert Options + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2008). + +Abstract + + This document updates the IANA allocation rules and registry of IPv4 + and IPv6 Router Alert Option Values. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Use of the Router Alert Option Value Field ......................2 + 3. IANA Considerations .............................................4 + 3.1. IANA Considerations for IPv4 Router Alert Option Values ....4 + 3.2. IANA Considerations for IPv6 Router Alert Option Values ....5 + 4. Security Considerations .........................................5 + 5. Acknowledgements ................................................6 + 6. References ......................................................6 + 6.1. Normative References .......................................6 + 6.2. Informative References .....................................6 + + + + + + + + + + + + + +Manner & McDonald Standards Track [Page 1] + +RFC 5350 IANA Considerations for Router Alert September 2008 + + +1. Introduction + + The IP Router Alert Option is defined for IPv4 in [RFC2113]. A + similar IPv6 option is defined in [RFC2711]. When one of these + options is present in an IP datagram, it indicates that the contents + of the datagram may be interesting to routers. The Router Alert + Option (RAO) is used by protocols such as the Resource Reservation + Protocol (RSVP) [RFC2205] and IGMP [RFC3376]. + + Both the IPv4 and IPv6 options contain a two-octet Value field to + carry extra information. This information can be used, for example, + by routers to determine whether or not the packet should be more + closely examined by them. + + There can be up to 65536 values for the RAO. Yet, currently there is + only a registry for IPv6 values. No registry or allocation policies + are defined for IPv4. + + This document updates the IANA registry for managing IPv4 and IPv6 + Router Alert Option Values, and removes one existing IPv6 Router + Alert Option Value. + +2. Use of the Router Alert Option Value Field + + One difference between the specifications for the IPv4 and IPv6 + Router Alert Options is the way values for the Value field are + managed. In [RFC2113], the IPv4 Router Alert Option Value field has + the value 0 assigned to "Router shall examine packet". All other + values (1-65535) are reserved. Neither a management mechanism (e.g., + an IANA registry) nor an allocation policy are provided for the IPv4 + RAO values. + + The IPv6 Router Alert Option has an IANA-managed registry + [IANA-IPv6RAO] containing allocations for the Value field. + + In [RFC3175], the IPv4 Router Alert Option Value is described as a + parameter that provides "additional information" to the router in + making its interception decision, rather than as a registry managed + by IANA. As such, this aggregation mechanism makes use of the Value + field to carry the reservation aggregation level. For the IPv6 + option, IANA has assigned a set of 32 values to indicate reservation + levels. However, since other registrations have already been made in + that registry, these values are from 3-35 (which is actually a set of + 33 values). + + Although it might have been desirable to have the same values used in + both the IPv4 and IPv6 registries, the initial allocations in + [RFC2711] and the aggregation-level allocations in [RFC3175] have + + + +Manner & McDonald Standards Track [Page 2] + +RFC 5350 IANA Considerations for Router Alert September 2008 + + + made this impossible. The following table shows the allocations in + the IPv6 registry and the values used in the IPv4 registry, where the + latter have been deduced from [RFC2113] and [RFC3175] with the + assumption that the number of aggregation levels can be limited to 32 + as in the IPv6 case. Entries for values 6 to 31 have been elided for + brevity. + + +----------+-------------------------+------------------------------+ + | Value | IPv4 RAO Meaning | IPv6 RAO Meaning | + +----------+-------------------------+------------------------------+ + | 0 | Router shall examine | Datagram contains a | + | | packet [RFC2113] | Multicast Listener Discovery | + | | [RFC2205] [RFC3376] | message [RFC2711] [RFC2710] | + | | [RFC4286] | [RFC4286] | + | 1 | Aggregated Reservation | Datagram contains RSVP | + | | Nesting Level 1 | message [RFC2711] [RFC2205] | + | | [RFC3175] | | + | 2 | Aggregated Reservation | Datagram contains an Active | + | | Nesting Level 2 | Networks message [RFC2711] | + | | [RFC3175] | [Schwartz2000] | + | 3 | Aggregated Reservation | Aggregated Reservation | + | | Nesting Level 3 | Nesting Level 0 [RFC3175](*) | + | | [RFC3175] | | + | 4 | Aggregated Reservation | Aggregated Reservation | + | | Nesting Level 4 | Nesting Level 1 [RFC3175] | + | | [RFC3175] | | + | 5 | Aggregated Reservation | Aggregated Reservation | + | | Nesting Level 5 | Nesting Level 2 [RFC3175] | + | | [RFC3175] | | + | ... | ... | ... | + | 32 | Aggregated Reservation | Aggregated Reservation | + | | Nesting Level 32 | Nesting Level 29 [RFC3175] | + | | [RFC3175] | | + | 33 | Reserved | Aggregated Reservation | + | | | Nesting Level 30 [RFC3175] | + | 34 | Reserved | Aggregated Reservation | + | | | Nesting Level 31 [RFC3175] | + | 35 | Reserved | Aggregated Reservation | + | | | Nesting Level 32(*) | + | | | [RFC3175] | + | 36-65534 | Reserved | Reserved to IANA for future | + | | | assignment | + | 65535 | Reserved | Reserved [IANA-IPv6RAO] | + +----------+-------------------------+------------------------------+ + + Note (*): The entry in the above table for the IPv6 RAO Value of 35 + (Aggregated Reservation Nesting Level 32) has been marked due to an + inconsistency in the text of [RFC3175], and is consequently reflected + + + +Manner & McDonald Standards Track [Page 3] + +RFC 5350 IANA Considerations for Router Alert September 2008 + + + in the IANA registry. In that document, the values 3-35 (i.e., 33 + values) are defined for nesting levels 0-31 (i.e., 32 levels). + Similarly, value 3 is a duplicate, because aggregation level 0 means + end-to-end signaling, and this already has an IPv6 RAO value "1" + assigned. + + Also note that nesting levels begin at 1 for IPv4 (described in + Section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in Section 6 of + [RFC3175]). + + Section 3.2 of this document redefines these so that for IPv6, value + 3 is no longer used and values 4-35 represent levels 1-32. This + removes the above inconsistencies. + +3. IANA Considerations + + This section contains the new procedures for managing IPv4 Router + Alert Option Values. IANA has created a registry for IPv4 Router + Alert Option Values (described in Section 3.1) and has updated the + IPv6 Router Alert Option Values (described in Section 3.2). + + IP Router Alert Option Values are currently managed separately for + IPv4 and IPv6. This document does not change this, as there is + little value in forcing the two registries to be aligned. + +3.1. IANA Considerations for IPv4 Router Alert Option Values + + The Value field, as specified in [RFC2113], is two octets in length. + The Value field is registered and maintained by IANA. The initial + contents of this registry are: + + +-------------+--------------------------------------+-----------+ + | Value | Description | Reference | + +-------------+--------------------------------------+-----------+ + | 0 | Router shall examine packet | [RFC2113] | + | 1-32 | Aggregated Reservation Nesting Level | [RFC3175] | + | 33-65502 | Available for assignment by the IANA | | + | 65503-65534 | Available for experimental use | | + | 65535 | Reserved | | + +-------------+--------------------------------------+-----------+ + + New values are to be assigned via IETF Review as defined in + [RFC5226]. + + + + + + + + +Manner & McDonald Standards Track [Page 4] + +RFC 5350 IANA Considerations for Router Alert September 2008 + + +3.2. IANA Considerations for IPv6 Router Alert Option Values + + The registry for IPv6 Router Alert Option Values continues to be + maintained as specified in [RFC2711]. In addition, the following + value has been removed from the IANA registry and reserved for + possible future use (not to be allocated currently). The reason is + that it is a duplicate value; aggregation level 0 means end-to-end + signaling, and this already has an IPv6 RAO value "1" assigned. + + +-------+--------------------------+-----------+ + | Value | Description | Reference | + +-------+--------------------------+-----------+ + | 3 | RSVP Aggregation level 0 | [RFC3175] | + +-------+--------------------------+-----------+ + + The following IPv6 RAO values are available for experimental use: + + +-------------+------------------+-----------+ + | Value | Description | Reference | + +-------------+------------------+-----------+ + | 65503-65534 | Experimental use | | + +-------------+------------------+-----------+ + +4. Security Considerations + + Since this document is only concerned with the IANA management of the + IPv4 and IPv6 Router Alert Option Values registry, it raises no new + security issues beyond those identified in [RFC2113] and [RFC2711]. + + Yet, as discussed in RFC 4727 [RFC4727], production networks do not + necessarily support the use of experimental code points in IP option + headers. The network scope of support for experimental values should + be evaluated carefully before deploying any experimental RAO value + across extended network domains, such as the public Internet. The + potential to disrupt the stable operation of the network hosting the + experiment through the use of unsupported experimental code points is + a serious consideration when planning an experiment using such code + points. + + When experimental RAO values are deployed within an administratively + self-contained network domain, the network administrators should + ensure that each value is used consistently to avoid interference + between experiments. When experimental values are used in traffic + that crosses multiple administrative domains, the experimenters + should assume that there is a risk that the same values will be used + simultaneously by other experiments, and thus that there is a + + + + + +Manner & McDonald Standards Track [Page 5] + +RFC 5350 IANA Considerations for Router Alert September 2008 + + + possibility that the experiments will interfere. Particular + attention should be given to security threats that such interference + might create. + +5. Acknowledgements + + Thanks to Robert Hancock, Martin Stiemerling, Alan Ford, and Francois + Le Faucheur for their helpful comments on this document. + +6. References + +6.1. Normative References + + [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, + February 1997. + + [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert + Option", RFC 2711, October 1999. + + [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. + Davie, "Aggregation of RSVP for IPv4 and IPv6 + Reservations", RFC 3175, September 2001. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP + 26, RFC 5226, May 2008. + +6.2. Informative References + + [IANA-IPv6RAO] "IANA Registry for Internet Protocol version 6 (IPv6) + Router Alert Option Values", . + + [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., + and S. Jamin, "Resource ReSerVation Protocol (RSVP) + -- Version 1 Functional Specification", RFC 2205, + September 1997. + + [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, + October 1999. + + [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and + A. Thyagarajan, "Internet Group Management Protocol, + Version 3", RFC 3376, October 2002. + + [RFC4286] Haberman, B. and J. Martin, "Multicast Router + Discovery", RFC 4286, December 2005. + + + + +Manner & McDonald Standards Track [Page 6] + +RFC 5350 IANA Considerations for Router Alert September 2008 + + + [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, + ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, + November 2006. + + [Schwartz2000] Schwartz, B., Jackson, A., Strayer, W., Zhou, W., + Rockwell, D., and C. Partridge, "Smart Packets: + Applying Active Networks to Network Management", ACM + Transactions on Computer Systems (TOCS), Volume 18, + Issue 1, February 2000. + +Authors' Addresses + + Jukka Manner + Department of Communications and Networking (Comnet) + Helsinki University of Technology (TKK) + P.O. Box 3000 + Espoo FIN-02015 TKK + Finland + + Phone: +358 9 451 2481 + EMail: jukka.manner@tkk.fi + + + Andrew McDonald + Roke Manor Research Ltd (a Siemens company) + Old Salisbury Lane + Romsey, Hampshire SO51 0ZN + United Kingdom + + EMail: andrew.mcdonald@roke.co.uk + + + + + + + + + + + + + + + + + + + + + +Manner & McDonald Standards Track [Page 7] + +RFC 5350 IANA Considerations for Router Alert September 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain 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 on-line IPR repository at + http://www.ietf.org/ipr. + + 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 implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Manner & McDonald Standards Track [Page 8] + -- cgit v1.2.3