summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5350.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5350.txt')
-rw-r--r--doc/rfc/rfc5350.txt451
1 files changed, 451 insertions, 0 deletions
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", <http://www.iana.org>.
+
+ [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]
+