idnits 2.17.1 draft-manner-router-alert-iana-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 363. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 29, 2008) is 5809 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IPv6RAO' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Manner 3 Internet-Draft TKK 4 Updates: RFC2113, RFC3175 A. McDonald 5 (if approved) Siemens/Roke 6 Intended status: Standards Track May 29, 2008 7 Expires: November 30, 2008 9 IANA Considerations for the IPv4 and IPv6 Router Alert Option 10 draft-manner-router-alert-iana-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 30, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document updates the IANA allocation rules and registry of IPv4 44 and IPv6 Router Alert Option Values. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Use of the Router Alert Option Value Field . . . . . . . . . . 3 50 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 51 3.1. IANA Considerations for IPv4 Router Alert Option Values . . 5 52 3.2. IANA Considerations for IPv6 Router Alert Option Values . . 5 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 57 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 59 Intellectual Property and Copyright Statements . . . . . . . . . . 9 61 1. Introduction 63 The IP Router Alert Option is defined for IPv4 in [RFC2113]. A 64 similar IPv6 option is defined in [RFC2711]. When one of these 65 options is present in an IP datagram, it indicates that the contents 66 of the datagram may be interesting to routers. The Router Alert 67 Option (RAO) is used by protocols such as RSVP [RFC2205] and IGMP 68 [RFC3376]. 70 Both the IPv4 and IPv6 option contain a two octet value field to 71 carry extra information. This information can be used, for example, 72 by routers to determine whether or not the packet should be more 73 closely examined by them. 75 There can be up to 65536 values for the RAO. Yet, currently there is 76 only a registry for IPv6 values. No registry or allocation policies 77 are defined for IPv4. 79 This document proposes updates to the IANA registry for managing IPv4 80 and IPv6 Router Alert Option Values, and proposes to remove one 81 existing IPv6 Router Alert Option value. 83 2. Use of the Router Alert Option Value Field 85 One difference between the specifications for the IPv4 and IPv6 86 Router Alert Options is the way values for the value field are 87 managed. In [RFC2113], the IPv4 Router Alert Option value field has 88 the value 0 assigned to "Router shall examine packet". All other 89 values (1-65535) are reserved. Neither a management mechanism (e.g., 90 such as an IANA registry) nor an allocation policy are provided for 91 the IPv4 RAO values. 93 The IPv6 Router Alert Option has an IANA managed registry 94 [IANA-IPv6RAO] containing allocations for the value field. 96 In [RFC3175] the IPv4 Router Alert Option Value is described as a 97 parameter that provides "additional information" to the router in 98 making its interception decision, rather than as a registry managed 99 by IANA. As such, this aggregation mechanism makes use of the value 100 field to carry the reservation aggregation level. For the IPv6 101 option, this document requests a set of 32 values to be assigned by 102 IANA for indicating reservation levels. However, since other 103 registrations had already been made in that registry these values are 104 from 3-35 (that is actually a set of 33 values). 106 Although it might have been desirable to have the same values being 107 used in both the IPv4 and IPv6 registries, the initial allocations in 109 [RFC2711] and the aggregation level allocations in [RFC3175] have 110 made this impossible. The following table shows the allocations in 111 the IPv6 registry and values used in the IPv4 registry, where the 112 latter have been deduced from [RFC2113] and [RFC3175] with the 113 assumption that the number of aggregation levels can be limited to 32 114 as in the IPv6 case. Entries for values 6 to 31 have been elided for 115 brevity. 117 +----------+-------------------------+------------------------------+ 118 | Value | IPv4 RAO Meaning | IPv6 RAO Meaning | 119 +----------+-------------------------+------------------------------+ 120 | 0 | Router shall examine | Datagram contains a | 121 | | packet [RFC2113] | Multicast Listener Discovery | 122 | | [RFC2205] [RFC3376] | message [RFC2711] [RFC2710] | 123 | | [RFC4286] | [RFC4286] | 124 | 1 | Aggregated Reservation | Datagram contains RSVP | 125 | | Nesting Level 1 | message [RFC2711] [RFC2205] | 126 | | [RFC3175] | | 127 | 2 | Aggregated Reservation | Datagram contains an Active | 128 | | Nesting Level 2 | Networks message [RFC2711] | 129 | | [RFC3175] | [Schwartz2000] | 130 | 3 | Aggregated Reservation | Aggregated Reservation | 131 | | Nesting Level 3 | Nesting Level 0 [RFC3175] | 132 | | [RFC3175] | | 133 | 4 | Aggregated Reservation | Aggregated Reservation | 134 | | Nesting Level 4 | Nesting Level 1 [RFC3175] | 135 | | [RFC3175] | | 136 | 5 | Aggregated Reservation | Aggregated Reservation | 137 | | Nesting Level 5 | Nesting Level 2 [RFC3175] | 138 | | [RFC3175] | | 139 | ... | ... | ... | 140 | 32 | Aggregated Reservation | Aggregated Reservation | 141 | | Nesting Level 32 | Nesting Level 29 [RFC3175] | 142 | | [RFC3175] | | 143 | 33 | Reserved | Aggregated Reservation | 144 | | | Nesting Level 30 [RFC3175] | 145 | 34 | Reserved | Aggregated Reservation | 146 | | | Nesting Level 31 [RFC3175] | 147 | 35 | Reserved | Aggregated Reservation | 148 | | | Nesting Level 32(*) | 149 | | | [RFC3175] | 150 | 36-65534 | Reserved | Reserved to IANA for future | 151 | | | assignment | 152 | 65535 | Reserved | Reserved [IANA-IPv6RAO] | 153 +----------+-------------------------+------------------------------+ 155 Note (*): The entry in the above table for the IPv6 RAO Value of 35 156 (Aggregated Reservation Nesting Level 32) has been marked due to an 157 inconsistency in the text of [RFC3175], and that is consequently 158 reflected in the IANA registry. In that document the values 3-35 159 (i.e. 33 values) are defined for nesting levels 0-31 (i.e. 32 160 levels). 162 It is unclear why nesting levels begin at 1 for IPv4 (described in 163 section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of 164 [RFC3175]). 166 3. IANA Considerations 168 This section contains the proposed new procedures for managing IPv4 169 Router Alert Option values. This requires the creation of a registry 170 for IPv4 Router Alert Option Values (described in Section 3.1) and 171 updates the IPv6 Router Alert Option Values (described in 172 Section 3.2). 174 IP Router Alert Option values are currently managed separately for 175 IPv4 and IPv6. This should not change, as there has been seen little 176 value in forcing the two registry to be aligned. 178 3.1. IANA Considerations for IPv4 Router Alert Option Values 180 The value field, as specified in [RFC2113] is two octets in length. 181 The value field is registered and maintained by IANA. The initial 182 contents of this registry are: 184 +-------------+--------------------------------------+-----------+ 185 | Value | Description | Reference | 186 +-------------+--------------------------------------+-----------+ 187 | 0 | Router shall examine packet | [RFC2113] | 188 | 1-32 | Aggregated Reservation Nesting Level | [RFC3175] | 189 | 33-65502 | Available for assignment by the IANA | | 190 | 65503-65534 | Available for experimental use | | 191 | 65535 | Reserved | | 192 +-------------+--------------------------------------+-----------+ 194 New values are to be assigned via IETF Review as defined in 195 [RFC5226]. 197 3.2. IANA Considerations for IPv6 Router Alert Option Values 199 The registry for IPv6 Router Alert Option Values should continue to 200 be maintained as specified in [RFC2711]. 202 In addition, the following value should be removed from the IANA 203 registry and reserved for possible future use (not to be allocated 204 currently). The reason is that it is a duplicate value, aggregation 205 level 0 means end-to-end signaling, and this already has an IPv6 RAO 206 value "1" assigned. 208 +-------+--------------------------+-----------+ 209 | Value | Description | Reference | 210 +-------+--------------------------+-----------+ 211 | 3 | RSVP Aggregation level 0 | [RFC3175] | 212 +-------+--------------------------+-----------+ 214 The following IPv6 RAO values should be made available for 215 experimental use: 217 +-------------+------------------+-----------+ 218 | Value | Description | Reference | 219 +-------------+------------------+-----------+ 220 | 65503-65534 | Experimental use | | 221 +-------------+------------------+-----------+ 223 4. Security Considerations 225 Since this document is only concerned with the IANA management of the 226 IPv4 and IPv6 Router Alert Option values registry it raises no new 227 security issues beyond those identified in [RFC2113] and [RFC2711]. 229 Yet, as discussed in RFC 4727 [RFC4727] production networks do not 230 necessarily support the use of experimental code points in IP option 231 headers. The network scope of support for experimental values should 232 carefully be evaluated before deploying any experimental RAO value 233 across extended network domains, such as the public Internet. The 234 potential to disrupt the stable operation of the network hosting the 235 experiment through the use of unsupported experimental code points is 236 a serious consideration when planning an experiment using such code 237 points. 239 When experimental RAO values are deployed within an administratively 240 self-contained network domain, the network administrators should 241 ensure that each value is used consistently to avoid interference 242 between experiments. When experimental values are used in traffic 243 that crosses multiple administrative domains, the experimenters 244 should assume that there is a risk that the same values will be used 245 simultaneously by other experiments and thus that there is a 246 possibility that the experiments will interfere. Particular 247 attention should be given to security threats that such interference 248 might create. 250 5. Acknowledgements 252 Thanks to Robert Hancock, Martin Stiemerling, Alan Ford and Francois 253 Le Faucheur for their helpful comments on this document. 255 6. References 257 6.1. Normative References 259 [IANA-IPv6RAO] 260 "IANA Registry for Internet Protocol version 6 (IPv6) 261 Router Alert Option Values" . 263 265 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 266 February 1997. 268 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 269 RFC 2711, October 1999. 271 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 272 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 273 RFC 3175, September 2001. 275 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 276 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 277 May 2008. 279 6.2. Informative References 281 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 282 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 283 Functional Specification", RFC 2205, September 1997. 285 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 286 Listener Discovery (MLD) for IPv6", RFC 2710, 287 October 1999. 289 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 290 Thyagarajan, "Internet Group Management Protocol, Version 291 3", RFC 3376, October 2002. 293 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 294 RFC 4286, December 2005. 296 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 297 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 299 [Schwartz2000] 300 Schwartz, B., Jackson, A., Strayer, W., Zhou, W., 301 Rockwell, D., and C. Partridge, "Smart Packets: Applying 302 Active Networks to Network Management", ACM Transactions 303 on Computer Systems (TOCS) Volume 18 , Issue 1, 304 February 2000. 306 Authors' Addresses 308 Jukka Manner 309 Helsinki University of Technology (TKK) 310 P.O. Box 3000 311 Espoo FIN-02015 TKK 312 Finland 314 Phone: +358 9 451 2481 315 Email: jukka.manner@tkk.fi 317 Andrew McDonald 318 Roke Manor Research Ltd (a Siemens company) 319 Old Salisbury Lane 320 Romsey, Hampshire SO51 0ZN 321 United Kingdom 323 Email: andrew.mcdonald@roke.co.uk 325 Full Copyright Statement 327 Copyright (C) The IETF Trust (2008). 329 This document is subject to the rights, licenses and restrictions 330 contained in BCP 78, and except as set forth therein, the authors 331 retain all their rights. 333 This document and the information contained herein are provided on an 334 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 335 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 336 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 337 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 338 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 339 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 341 Intellectual Property 343 The IETF takes no position regarding the validity or scope of any 344 Intellectual Property Rights or other rights that might be claimed to 345 pertain to the implementation or use of the technology described in 346 this document or the extent to which any license under such rights 347 might or might not be available; nor does it represent that it has 348 made any independent effort to identify any such rights. Information 349 on the procedures with respect to rights in RFC documents can be 350 found in BCP 78 and BCP 79. 352 Copies of IPR disclosures made to the IETF Secretariat and any 353 assurances of licenses to be made available, or the result of an 354 attempt made to obtain a general license or permission for the use of 355 such proprietary rights by implementers or users of this 356 specification can be obtained from the IETF on-line IPR repository at 357 http://www.ietf.org/ipr. 359 The IETF invites any interested party to bring to its attention any 360 copyrights, patents or patent applications, or other proprietary 361 rights that may cover technology that may be required to implement 362 this standard. Please address the information to the IETF at 363 ietf-ipr@ietf.org. 365 Acknowledgment 367 Funding for the RFC Editor function is provided by the IETF 368 Administrative Support Activity (IASA).