idnits 2.17.1 draft-mcdonald-nsis-router-alert-iana-00.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 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (October 16, 2006) is 6395 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 2434 (Obsoleted by RFC 5226) Summary: 4 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 A. McDonald 3 Internet-Draft Siemens/Roke 4 Updates: RFC2113, RFC2711 (if October 16, 2006 5 approved) 6 Intended status: Standards Track 7 Expires: April 19, 2007 9 IANA Considerations for the IPv4 and IPv6 Router Alert Option 10 draft-mcdonald-nsis-router-alert-iana-00 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 April 19, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document provides new instructions to IANA on the allocation of 44 IPv4 and IPv6 Router Alert Option Values. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 50 3. Use of the Router Alert Option Value Field . . . . . . . . . . 3 51 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 52 4.1. IANA Considerations for IPv4 Router Alert Option Values . . 5 53 4.2. IANA Considerations for IPv6 Router Alert Option Values . . 6 54 5. Alternative Proposals . . . . . . . . . . . . . . . . . . . . . 6 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 59 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 Intellectual Property and Copyright Statements . . . . . . . . . . 9 63 1. Introduction 65 The IP Router Alert Option is defined for IPv4 in [RFC2113]. A 66 similar IPv6 option is defined in [RFC2711]. When one of these 67 options is present in an IP datagram, it indicates that the contents 68 of the datagram may be interesting to routers. The Router Alert 69 Option (RAO) is used by protocols such as RSVP [RFC2205] and IGMP 70 [RFC3376]. 72 Both the IPv4 and IPv6 option contain a two octet value field to 73 carry extra information. This information can be used, for example, 74 by routers to determine whether or not the packet should be more 75 closely examined by them. 77 This document proposes the creation of a new IANA registry for 78 managing IPv4 Router Alert Option Values. In conjunction with this, 79 it also proposes an update to the way in which IPv6 Router Alert 80 Option Values are assigned in the existing IANA registry. 82 2. Requirements notation 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. Use of the Router Alert Option Value Field 90 One difference betwen the specifications for the IPv4 and IPv6 Router 91 Alert Options is the way in which values for the value field are 92 managed. 94 In [RFC2113], the IPv4 Router Alert Option value field has the value 95 0 assigned to "Router shall examine packet". All other values 96 (1-65535) are reserved. No mechanism is provided for the allocation 97 of these values by IANA. 99 The IPv6 Router Alert Option has an IANA managed registry 100 [IANA-IPv6RAO] containing allocations for the value field. All 101 values in this registry are assigned by IETF consensus. 103 In [RFC3175] the IPv4 Router Alert Option Value is described as a 104 parameter which provides "additional information" to the router in 105 making its interception decision, rather than as a registry managed 106 by IANA. As such, this aggregation mechanism makes use of the value 107 field to carry the reservation aggregation level. For the IPv6 108 option, this document requests a set of 32 values to be assigned by 109 IANA for indicating reservation levels. However, since other 110 registrations had already been made in that registry these values are 111 from 3-35 (which is actually a set of 33 values). 113 Although it would be strongly desirable to have the same values being 114 used in both the IPv4 and IPv6 registries, the initial allocations in 115 [RFC2711] and the aggregation level allocations in [RFC3175] have 116 made this impossible. The following table shows the allocations in 117 the IPv6 registry and values used in the IPv4 registry, where the 118 latter have been deduced from [RFC2113] and [RFC3175] with the 119 assumption that the number of aggregation levels can be limited to 32 120 as in the IPv6 case. Entries for values 6 to 31 have been elided for 121 brevity. 123 +----------+-------------------------+------------------------------+ 124 | Value | IPv4 RAO Meaning | IPv6 RAO Meaning | 125 +----------+-------------------------+------------------------------+ 126 | 0 | Router shall examine | Datagram contains a | 127 | | packet [RFC2113] | Multicast Listener Discovery | 128 | | [RFC2205] [RFC3376] | message [RFC2711] [RFC2710] | 129 | | [RFC4286] | [RFC4286] | 130 | 1 | Aggregated Reservation | Datagram contains RSVP | 131 | | Nesting Level 1 | message [RFC2711] [RFC2205] | 132 | | [RFC3175] | | 133 | 2 | Aggregated Reservation | Datagram contains an Active | 134 | | Nesting Level 2 | Networks message [RFC2711] | 135 | | [RFC3175] | [Schwartz2000] | 136 | 3 | Aggregated Reservation | Aggregated Reservation | 137 | | Nesting Level 3 | Nesting Level 0 [RFC3175] | 138 | | [RFC3175] | | 139 | 4 | Aggregated Reservation | Aggregated Reservation | 140 | | Nesting Level 4 | Nesting Level 1 [RFC3175] | 141 | | [RFC3175] | | 142 | 5 | Aggregated Reservation | Aggregated Reservation | 143 | | Nesting Level 5 | Nesting Level 2 [RFC3175] | 144 | | [RFC3175] | | 145 | ... | ... | ... | 146 | 32 | Aggregated Reservation | Aggregated Reservation | 147 | | Nesting Level 32 | Nesting Level 29 [RFC3175] | 148 | | [RFC3175] | | 149 | 33 | Reserved | Aggregated Reservation | 150 | | | Nesting Level 30 [RFC3175] | 151 | 34 | Reserved | Aggregated Reservation | 152 | | | Nesting Level 31 [RFC3175] | 153 | 35 | Reserved | Aggregated Reservation | 154 | | | Nesting Level 32(?) | 155 | | | [RFC3175] | 156 | 36-65534 | Reserved | Reserved to IANA for future | 157 | | | use | 158 | 65535 | Reserved | Reserved [IANA-IPv6RAO] | 159 +----------+-------------------------+------------------------------+ 161 The entry in the above table for the IPv6 RAO Value of 32 has been 162 marked with a question mark due to an inconsistency in the text of 163 [RFC3175], which is consequently reflected in the IANA registry. In 164 that document the values 3-35 (i.e. 33 values) are defined for 165 nesting levels 0-31 (i.e. 32 levels). 167 It is unclear why nesting levels begin at 1 for IPv4 (described in 168 section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of 169 [RFC3175]). 171 Although it is not possible to remedy the past inconsistency between 172 the two sets of allocations, it is still preferable that future 173 allocations should be made identically in both registries. 175 4. IANA Considerations 177 This section contains the proposed new procedures for managing Router 178 Alert Option Values. This requires the creation of a registry for 179 IPv4 Router Alert Option Values (described in Section 4.1) and 180 changes to the way in which IPv6 Router Alert Option Values are 181 managed (described in Section 4.2). 183 4.1. IANA Considerations for IPv4 Router Alert Option Values 185 The value field, as specified in [RFC2113] is two octets in length. 186 The value field is registered and maintained by IANA. The initial 187 contents of this registry are: 189 +----------+--------------------------------------------+-----------+ 190 | Value | Description | Reference | 191 +----------+--------------------------------------------+-----------+ 192 | 0 | Router shall examine packet | [RFC2119] | 193 | 1-32 | Aggregated Reservation Nesting Level | [RFC3175] | 194 | 33-35 | Reserved (not to be allocated) - Note: | | 195 | | These values are allocated in the IPv6 | | 196 | | Router Alert Option Values registry | | 197 | 36-65534 | Reserved to IANA for future use | | 198 | 65535 | Reserved | | 199 +----------+--------------------------------------------+-----------+ 201 New values are to be assigned via IETF Consensus as defined in 202 [RFC2434]. When a new allocation is made in this registry an 203 identical registration MUST be made in the IPv6 Router Alert Option 204 Values registry, or that value MUST be reserved. In the case that it 205 is reserved rather than allocated, the registry entry should say 206 "Reserved (not to be allocated) - Note: This value is allocated in 207 the IPv6 Router Alert Options registry". 209 4.2. IANA Considerations for IPv6 Router Alert Option Values 211 The registry for IPv6 Router Alert Option Values should continue to 212 be maintained as specified in [RFC2711]. However, when a new 213 allocation is made in this registry an identical registration MUST be 214 made in the IPv4 Router Alert Option Values registry, or that value 215 MUST be reserved. In the case that it is reserved rather than 216 allocated, the registry entry should say "Reserved (not to be 217 allocated) - Note: This value is allocated in the IPv4 Router Alert 218 Options registry". 220 5. Alternative Proposals 222 In Section 4 this document describes one way of modifying the Router 223 Alert Option registry management, but this is not necessarily the 224 only solution. 226 One question that arises is what the intended status of this document 227 should be. Currently this document is aimed as a standards track 228 document, that modifies [RFC2113] and [RFC2711]. It is not clear 229 whether this is the right option. A draft aimed at becoming a BCP 230 might be an alternative. 232 This document currently proposes the use of separate registries for 233 IPv4 and IPv6 Router Alert Options, but with coordinated management 234 of future allocations. This is mainly because of the differences in 235 the existing allocation, e.g. for the 0 codepoint. An alternative 236 proposal would be to use a single combined registry. 238 It might also be desirable to align the Aggregated Reservation 239 Nesting Levels, as defined in [RFC3175], for IPv4 and IPv6. 240 Aggregated Nesting Level 1 for IPv4 would then need to move to using 241 the codepoint 4, as in the IPv6 case. However, such a change may not 242 be possible. 244 6. Security Considerations 246 Since this document is only concerned with the IANA management of the 247 IPv4 Router Alert Option values registry it raises no new security 248 issues beyond those identified in [RFC2113] and [RFC2711]. 250 7. Acknowledgements 252 Thanks to Robert Hancock, Martin Stiemerling and Alan Ford for their 253 helpful comments on this document. 255 8. References 257 8.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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 271 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 272 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 273 October 1998. 275 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 276 RFC 2711, October 1999. 278 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 279 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 280 RFC 3175, September 2001. 282 8.2. Informative References 284 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 285 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 286 Functional Specification", RFC 2205, September 1997. 288 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 289 Listener Discovery (MLD) for IPv6", RFC 2710, 290 October 1999. 292 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 293 Thyagarajan, "Internet Group Management Protocol, Version 294 3", RFC 3376, October 2002. 296 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 297 RFC 4286, December 2005. 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 Author's Address 308 Andrew McDonald 309 Roke Manor Research Ltd (a Siemens company) 310 Old Salisbury Lane 311 Romsey, Hampshire SO51 0ZN 312 United Kingdom 314 Email: andrew.mcdonald@roke.co.uk 316 Full Copyright Statement 318 Copyright (C) The Internet Society (2006). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 327 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 328 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 329 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Intellectual Property 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org. 356 Acknowledgment 358 Funding for the RFC Editor function is provided by the IETF 359 Administrative Support Activity (IASA).