idnits 2.17.1 draft-ietf-ospf-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 673. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 18, 2007) is 6248 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1584 ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) == Outdated reference: A later version (-11) exists of draft-ietf-ospf-cap-10 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet-Draft Juniper Networks 4 Intended status: Best Current B. Fenner 5 Practice AT&T Labs--Research 6 Expires: September 19, 2007 March 18, 2007 8 IANA Considerations for OSPF 9 draft-ietf-ospf-iana-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 19, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This memo creates a number of OSPF registries and provides guidance 43 to IANA for assignment of code points within these registries. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Conventions used in this document . . . . . . . . . . . . 4 49 1.2. Changes from version -00 . . . . . . . . . . . . . . . . . 4 50 1.3. Changes from version -01 . . . . . . . . . . . . . . . . . 4 51 2. OSPF Registries . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. OSPFv2 Options . . . . . . . . . . . . . . . . . . . . . . 4 53 2.2. OSPFv3 Options . . . . . . . . . . . . . . . . . . . . . . 5 54 2.3. OSPF Packet Type (both v2 and v3) . . . . . . . . . . . . 5 55 2.3.1. OSPF Authentication Type . . . . . . . . . . . . . . . 5 56 2.4. OSPFv2 Link State (LS) Type . . . . . . . . . . . . . . . 5 57 2.4.1. OSPFv2 Router LSA Link Type . . . . . . . . . . . . . 6 58 2.4.2. OSPFv2 Router Properties . . . . . . . . . . . . . . . 6 59 2.5. OSPFv3 LSA Function Code . . . . . . . . . . . . . . . . . 6 60 2.5.1. OSPFv3 Prefix Options . . . . . . . . . . . . . . . . 6 61 2.5.2. OSPFv3 Router LSA Link Type . . . . . . . . . . . . . 7 62 2.6. OSPFv2 Opaque LSA Type . . . . . . . . . . . . . . . . . . 7 63 2.6.1. OSPFv2 Grace LSA Top Level TLVs . . . . . . . . . . . 7 64 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. OSPFv2 Options Registry . . . . . . . . . . . . . . . . . 8 68 5.2. OSPFv3 Options Registry . . . . . . . . . . . . . . . . . 9 69 5.3. OSPF Packet Type Registry . . . . . . . . . . . . . . . . 9 70 5.4. OSPF Authentication Type Registry . . . . . . . . . . . . 10 71 5.5. OSPFv2 Link State Type Registry . . . . . . . . . . . . . 10 72 5.6. OSPFv2 Router LSA Link Type Registry . . . . . . . . . . . 10 73 5.7. OSPFv2 Router Properties Registry . . . . . . . . . . . . 10 74 5.8. OSPFv3 LSA Function Code Registry . . . . . . . . . . . . 11 75 5.9. OSPFv3 Prefix Options Registry . . . . . . . . . . . . . . 12 76 5.10. OSPFv3 Router LSA Link Type Registry . . . . . . . . . . . 12 77 5.11. OSPFv2 Opaque LSA Type Registry . . . . . . . . . . . . . 13 78 5.12. OSPFv2 Grace LSA Top Level TLV Registry . . . . . . . . . 13 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 81 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 83 Intellectual Property and Copyright Statements . . . . . . . . . . 15 85 1. Introduction 87 This memo defines various OSPF registries for IANA to set up and 88 maintain for OSPF code points. In some cases, this memo defines 89 ranges of code point values within these registries; each such range 90 has a different assignment policy. 92 The terms used in describing the assignment policies are as follows: 94 o Standards Action 96 o Experimentation 98 o Vendor Private Use 100 o Reserved 102 Standards Action means that assignment in that range MUST only be 103 made for Standards Track RFCs (as defined in [RFC2434]). 105 Some of the registries defined below reserve a range of values for 106 Experimentation. For guidelines regarding the use of such values see 107 [RFC3692]. Values from this range MUST NOT be assigned by IANA. 108 Further guidance on the use of the Experimentation range may be found 109 in paragraphs 4, 5 and 6 of [RFC3692]. An implementation MAY choose 110 to not support values from the Experimentation range. In such a 111 case, the protocol data structure with a code point from the 112 Experimentation range is ignored, unless other protocol machinery 113 says how to deal with it. "Ignored" in this context means that the 114 associated data structure is removed from the received packet before 115 further processing, including flooding. 117 Values set aside as Vendor Private Use MUST NOT be assigned by IANA. 118 A protocol data structure whose code point falls in this range MUST 119 have a disambiguating field identifying the Vendor. This identifier 120 consists of four octets of the Vendor's SMI enterprise code (see 121 [ENTERPRISE-NUMBERS]) in network byte order; the location of this 122 code must be well- defined per data structure. An implementation 123 that encounters a Vendor Private code point SHOULD check whether the 124 enterprise code is one that it recognises; if so, the implementation 125 MAY choose to interpret the code point and data structure. 126 Otherwise, it SHOULD ignore the code point, unless protocol machinery 127 says how to deal with the data structure (as defined in the previous 128 paragraph). This allows multiple vendor private extensions to co- 129 exist in a network. 131 Values in the Reserved range MUST NOT be assigned until a Standards 132 Track or Best Common Practices RFC is published defining the 133 assignment policy for that range. This RFC MUST be the product of 134 the OSPF Working Group; if the OSPF WG is terminated, then it MUST be 135 reviewed by an Expert Reviewer designated by the IESG. 137 1.1. Conventions used in this document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 1.2. Changes from version -00 145 [This section to be removed before publication.] 147 Removed misguided reference to non-existent U bit in OSPFv2 Opaque 148 LSAs. 150 Tightened up requirements for defining new OSPFv2 Link State (LS) 151 Type (section 2.4) and OSPFv2 Router LSA Link Type (section 2.4.1). 153 1.3. Changes from version -01 155 [This section to be removed before publication.] 157 Reworded experimental text as suggested by Jari Arkko and Brian 158 Carpenter in IESG review. 160 Added all of Section 5 to give IANA starting points for the 161 registries to create. 163 2. OSPF Registries 165 This section lists the various registries for OSPF protocol code 166 points. Note that some of these are for OSPF, and some are specific 167 to a particular version of OSPF; also, some registries pre-date this 168 memo. 170 Registries that are specific to one version of OSPF reflect the 171 version number in the registry name (e.g., OSPFv2 Options). A 172 registry whose name does not mention a version number applies to both 173 OSPFv2 and OSPFv3 (e.g., OSPF Packet Type). 175 2.1. OSPFv2 Options 177 (Defined in section A.2 of [RFC2328], updated in section A.1 of 178 [RFC2370]. See also [RFC3101].) 179 Assignment policy: Standards Action. 181 2.2. OSPFv3 Options 183 (Defined in section A.2 of [RFC2740]) 185 Assignment policy: Standards Action. 187 2.3. OSPF Packet Type (both v2 and v3) 189 (Defined in section A.3.1 of [RFC2328]) 191 +---------+--------------------+ 192 | Range | Assignment Policy | 193 +---------+--------------------+ 194 | 0 | Not to be assigned | 195 | 1-5 | Already assigned | 196 | 6-127 | Standards Action | 197 | 128-255 | Reserved | 198 +---------+--------------------+ 200 2.3.1. OSPF Authentication Type 202 (Defined in section A.3.1 of [RFC2328]) 204 (Note: this registry is called "OSPF AUTHENTICATION CODES" by IANA.) 206 +-------------+-------------------+ 207 | Range | Assignment Policy | 208 +-------------+-------------------+ 209 | 0-2 | Already assigned | 210 | 3-247 | Standards Action | 211 | 248-65519 | Reserved | 212 | 65520-65535 | Experimentation | 213 +-------------+-------------------+ 215 2.4. OSPFv2 Link State (LS) Type 217 (Defined in section A.4.1 of [RFC2328]) 219 +---------+--------------------+ 220 | Range | Assignment Policy | 221 +---------+--------------------+ 222 | 0 | Not to be assigned | 223 | 1-11 | Already assigned | 224 | 12-127 | Standards Action | 225 | 128-255 | Reserved | 226 +---------+--------------------+ 228 If a new LS Type is documented, the documentation MUST say how the 229 Link State ID is to be filled in, what the flooding scope of the LSA 230 is, and how backward compatibility is maintained. 232 2.4.1. OSPFv2 Router LSA Link Type 234 (Defined in section A.4.2 of [RFC2328]) 236 +---------+--------------------+ 237 | Range | Assignment Policy | 238 +---------+--------------------+ 239 | 0 | Not to be assigned | 240 | 1-4 | Already assigned | 241 | 5-127 | Standards Action | 242 | 128-255 | Reserved | 243 +---------+--------------------+ 245 There is no range for Vendor Private Use, as there is no space for an 246 enterprise code to identify the Vendor. 248 No Experimental range is defined, due to possible backwards 249 compatibility issues. 251 If a new Router LSA Link Type is documented, the documentation SHOULD 252 say how the Link State ID, Link ID and Link Data fields are to be 253 filled in, and how backward compatibility is maintained. 255 2.4.2. OSPFv2 Router Properties 257 (Defined in section A.4.2 of [RFC2328], updated in [RFC3101]) 259 This 8-bit field in the Router LSA is unnamed; it is the field 260 immediately following the Router LSA length. 262 Assignment policy: Standards Action. 264 2.5. OSPFv3 LSA Function Code 266 This registry is created by [I-D.ietf-ospf-cap]. This document 267 provides the values to be populated for values defined in section 268 A.4.2.1 of [RFC2740]. 270 2.5.1. OSPFv3 Prefix Options 272 (Defined in section A.4.1.1 of [RFC2740]) 274 Assignment policy: Standards Action. 276 2.5.2. OSPFv3 Router LSA Link Type 278 (Defined in section A.4.3 of [RFC2740]) 280 +---------+--------------------+ 281 | Range | Assignment Policy | 282 +---------+--------------------+ 283 | 0 | Not to be assigned | 284 | 1-4 | Already assigned | 285 | 5-127 | Standards Action | 286 | 128-255 | Reserved | 287 +---------+--------------------+ 289 There is no range for Vendor Private Use, as there is no space for an 290 enterprise code to identify the Vendor. 292 No Experimental range is defined, due to possible backwards 293 compatibility issues. 295 2.6. OSPFv2 Opaque LSA Type 297 (Defined in section A.2 of [RFC2370]) 299 (Note: this registry is called "OSPF Opaque LSA Option" by IANA. See 300 also [RFC3630].) 302 +---------+--------------------+ 303 | Range | Assignment Policy | 304 +---------+--------------------+ 305 | 0 | Not to be assigned | 306 | 1-3 | Already assigned | 307 | 4-127 | Standards Action | 308 | 128-247 | Reserved | 309 | 248-251 | Experimentation | 310 | 252-255 | Vendor Private Use | 311 +---------+--------------------+ 313 In an OSPFv2 Opaque LSA with Opaque LSA Type in the Vendor Private 314 Use range, the first four octets of Opaque Information MUST be the 315 Vendor enterprise code. 317 A document defining a new Standards Track Opaque LSA with TLVs and 318 sub-TLVs MUST describe ranges and assignment policies for these TLVs. 320 2.6.1. OSPFv2 Grace LSA Top Level TLVs 322 (Defined in Section A of [RFC3623]) 323 +-------------+--------------------+ 324 | Range | Assignment Policy | 325 +-------------+--------------------+ 326 | 0 | Not to be assigned | 327 | 1-3 | Already assigned | 328 | 4-255 | Standards Action | 329 | 256-65519 | Reserved | 330 | 65520-65527 | Experimentation | 331 | 65528-65535 | Vendor Private Use | 332 +-------------+--------------------+ 334 In a Grace LSA, if a top-level TLV has a Type from the Vendor Private 335 Use range, the Length MUST be at least four, and the first four 336 octets of the Value field MUST be the Vendor enterprise code. 338 3. Acknowledgments 340 Many thanks to Adrian Farrel and Acee Lindem for their review and 341 comments. 343 4. Security Considerations 345 The lack of adequate IANA guidelines may be viewed as an avenue for 346 Denial of Service attacks on IETF protocols (in this case, OSPFv2 and 347 OSPFv3), and on the IETF Standards Process in general. This memo 348 attempts to close this loophole for OSPFv2 and OSPFv3. 350 Authors contemplating extensions to OSPF SHOULD examine such 351 extensions carefully, and consider whether new registries are needed, 352 and if so, allocation policies within each registry. 354 5. IANA Considerations 356 This document specifies assignment policy for several existing IANA 357 registries and creates several more. 359 5.1. OSPFv2 Options Registry 361 Section 2.1 defines the policy for allocation of bits from this 362 registry as "Standards Action". There are only 8 bits in this field, 363 and 6 are already assigned. The initial registry contents are given 364 below. 366 OSPFv2 Options Registry (Section 2.1) 368 Value Description Reference 369 ----- ----------- --------- 370 0x02 E-bit [RFC2328] 371 0x04 MC-bit [RFC1584] 372 0x08 N/P-bit [RFC3101] 373 0x10 Reserved 374 0x20 DC-bit [RFC1793] 375 0x40 O-bit [RFC2370] 377 5.2. OSPFv3 Options Registry 379 Section 2.2 defines the policy for allocation of bits from this 380 registry as "Standards Action". There are 24 bits in this field, and 381 6 are assigned. The initial registry contents are given below. 383 OSPFv3 Options Registry (Section 2.2) 385 Value Description Reference 386 -------- ----------- --------- 387 0x000001 V6-bit [RFC2740] 388 0x000002 E-bit [RFC2328] 389 0x000004 MC-bit [RFC1584] 390 0x000008 N-bit [RFC3101] 391 0x000010 R-Bit [RFC2740] 392 0x000020 DC-bit [RFC1793] 394 5.3. OSPF Packet Type Registry 396 Section 2.3 defines the policy for allocation of values from this 397 registry for different ranges. The initial registry contents are 398 given below. 400 OSPF Packet Type (Section 2.3) 402 Value Description Reference 403 ----- -------------------- --------- 404 1 Hello [RFC2328] 405 2 Database Description [RFC2328] 406 3 Link State Request [RFC2328] 407 4 Link State Update [RFC2328] 408 5 Link State Ack [RFC2328] 410 5.4. OSPF Authentication Type Registry 412 This registry already exists at IANA, called "ospf-authentication- 413 codes". Section 2.3.1 defines the policy for allocation from this 414 registry for different ranges. 416 5.5. OSPFv2 Link State Type Registry 418 Section 2.4 defines the policy for allocations from this registry for 419 different ranges. The initial registry contents are given below. 421 OSPFv2 Link State (LS) Type (Section 2.4) 423 Value Description Reference 424 ----- ------------------------ --------- 425 1 Router-LSA [RFC2328] 426 2 Network-LSA [RFC2328] 427 3 Summary-LSA (IP network) [RFC2328] 428 4 Summary-LSA (ASBR) [RFC2328] 429 5 AS-external-LSA [RFC2328] 430 6 Group-membership-LSA [RFC1584] 431 7 NSSA AS-external LSA [RFC3101] 432 8 Reserved 433 9 Link-local Opaque LSA [RFC2370] 434 10 Area-local Opaque LSA [RFC2370] 435 11 Opaque LSA [RFC2370] 437 5.6. OSPFv2 Router LSA Link Type Registry 439 Section 2.4.1 defines the policy for allocations from this registry 440 for different ranges. The initial registry contents are given below. 442 OSPFv2 Router LSA Link Type (Section 2.4.1) 444 Value Description Reference 445 ----- ------------------------------------------- --------- 446 1 Point-to-Point connection to another router [RFC2328] 447 2 Transit Network [RFC2328] 448 3 Stub Network [RFC2328] 449 4 Virtual Link [RFC2328] 451 5.7. OSPFv2 Router Properties Registry 453 Section 2.4.2 defines the policy for allocation of bits from this 454 registry as "Standards Action". There are only 8 bits in this field, 455 and 5 are already assigned. The initial registry contents are given 456 below. 458 OSPFv2 Options Registry (Section 2.1) 460 Value Description Reference 461 ----- ----------- --------- 462 0x01 B-bit [RFC2328] 463 0x02 W-bit [RFC2328] 464 0x04 V-bit [RFC2328] 465 0x08 W-bit [RFC1584] 466 0x10 Nt-bit [RFC3101] 468 5.8. OSPFv3 LSA Function Code Registry 470 This registry is created by [I-D.ietf-ospf-cap], which also defines 471 the registration policy. This section contains values that belong in 472 this registry that were defined by [RFC2740]. 474 As defined in [RFC2740], the first three bits of the LSA Function 475 Code are the U, S1 and S2 bits. A given function code implies a 476 specific setting for the U, S1 and S2 bits as shwon in the "LS Type" 477 column. 478 1 1 1 1 1 1 479 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 480 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 481 |U |S2|S1| LSA Function Code | 482 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 484 The U bit indicates how the LSA should be handled by a router which 485 does not recognize the LSA's function code. Its values are: 487 U-bit LSA Handling 488 ----- ---------------------------------------------------- 489 0 Treat the LSA as if it had link-local flooding scope 490 1 Store and flood the LSA, as if type understood 492 The S1 and S2 bits indicate the flooding scope of the LSA. The 493 values are: 495 S1 S2 Flooding Scope 496 -- -- -------------------------------------------------------------- 497 0 0 Link-Local Scoping. Flooded only on link it is originated on. 498 0 1 Area Scoping. Flooded to all routers in the originating area 499 1 0 AS Scoping. Flooded to all routers in the AS 500 1 1 Reserved 502 The initial registry contents are given below. 504 OSPFv3 LSA Function Code (Section 2.5) 506 LSA function code LS Type Description Reference 507 ----------------- ------- --------------------- --------- 508 1 0x2001 Router-LSA [RFC2740] 509 2 0x2002 Network-LSA [RFC2740] 510 3 0x2003 Inter-Area-Prefix-LSA [RFC2740] 511 4 0x2004 Inter-Area-Router-LSA [RFC2740] 512 5 0x4005 AS-External-LSA [RFC2740] 513 6 0x2006 Group-membership-LSA [RFC2740] 514 7 0x2007 Type-7-LSA [RFC2740] 515 8 0x0008 Link-LSA [RFC2740] 516 9 0x2009 Intra-Area-Prefix-LSA [RFC2740] 518 5.9. OSPFv3 Prefix Options Registry 520 Section 2.5.1 defines the policy for allocation of bits from this 521 registry as "Standards Action". There are only 8 bits in this field, 522 and 4 are already assigned. The initial registry contents are given 523 below. 525 OSPFv3 Prefix Options Registry (Section 2.5.1) 527 Value Description Reference 528 ----- ----------- --------- 529 0x01 NU-bit [RFC2740] 530 0x02 LA-bit [RFC2740] 531 0x04 MC-bit [RFC2740] 532 0x08 P-bit [RFC2740] 534 5.10. OSPFv3 Router LSA Link Type Registry 536 Section 2.5.2 defines the policy for allocations from this registry 537 for different ranges. The initial registry contents are given below. 539 OSPFv3 Router LSA Link Type (Section 2.5.2) 541 Value Description Reference 542 ----- ------------------------------------------- --------- 543 1 Point-to-Point connection to another router [RFC2740] 544 2 Transit Network [RFC2740] 545 3 Reserved [RFC2740] 546 4 Virtual Link [RFC2740] 548 5.11. OSPFv2 Opaque LSA Type Registry 550 This registry already exists at IANA, called "ospf-opaque-types". 551 Section 2.6 defines the policy for allocation from this registry for 552 different ranges. 554 5.12. OSPFv2 Grace LSA Top Level TLV Registry 556 Section 2.6.1 defines the policy for allocations from this registry 557 for different ranges. The initial registry contents are given below. 559 OSPFv2 Grace LSA Top Level TLV (Section 2.6.1) 561 Value Description Reference 562 ----- ----------------------- --------- 563 1 Grace Period [RFC3623] 564 2 Graceful Restart reason [RFC3623] 565 3 IP Interface Address [RFC3623] 567 6. References 569 6.1. Normative References 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, March 1997. 574 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 575 March 1994. 577 [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", 578 RFC 1793, April 1995. 580 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 582 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 583 July 1998. 585 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 586 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 587 October 1998. 589 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 590 RFC 2740, December 1999. 592 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 593 RFC 3101, January 2003. 595 [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF 596 Restart", RFC 3623, November 2003. 598 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 599 (TE) Extensions to OSPF Version 2", RFC 3630, 600 September 2003. 602 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 603 Considered Useful", BCP 82, RFC 3692, January 2004. 605 6.2. Informative References 607 [ENTERPRISE-NUMBERS] 608 "PRIVATE ENTERPRISE NUMBERS", 609 . 611 [I-D.ietf-ospf-cap] 612 Lindem, A., "Extensions to OSPF for Advertising Optional 613 Router Capabilities", draft-ietf-ospf-cap-10 (work in 614 progress), February 2007. 616 Authors' Addresses 618 Kireeti Kompella 619 Juniper Networks 620 1194 N. Mathilda Ave. 621 Sunnyvale, CA 94089 622 US 624 Email: kireeti@juniper.net 626 Bill Fenner 627 AT&T Labs--Research 628 1 River Oaks Place 629 San Jose, California 95134 630 United States 632 Phone: +1 (408) 493-8505 633 Email: fenner@research.att.com 635 Full Copyright Statement 637 Copyright (C) The IETF Trust (2007). 639 This document is subject to the rights, licenses and restrictions 640 contained in BCP 78, and except as set forth therein, the authors 641 retain all their rights. 643 This document and the information contained herein are provided on an 644 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 645 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 646 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 647 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 648 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 649 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 651 Intellectual Property 653 The IETF takes no position regarding the validity or scope of any 654 Intellectual Property Rights or other rights that might be claimed to 655 pertain to the implementation or use of the technology described in 656 this document or the extent to which any license under such rights 657 might or might not be available; nor does it represent that it has 658 made any independent effort to identify any such rights. Information 659 on the procedures with respect to rights in RFC documents can be 660 found in BCP 78 and BCP 79. 662 Copies of IPR disclosures made to the IETF Secretariat and any 663 assurances of licenses to be made available, or the result of an 664 attempt made to obtain a general license or permission for the use of 665 such proprietary rights by implementers or users of this 666 specification can be obtained from the IETF on-line IPR repository at 667 http://www.ietf.org/ipr. 669 The IETF invites any interested party to bring to its attention any 670 copyrights, patents or patent applications, or other proprietary 671 rights that may cover technology that may be required to implement 672 this standard. Please address the information to the IETF at 673 ietf-ipr@ietf.org. 675 Acknowledgment 677 Funding for the RFC Editor function is provided by the IETF 678 Administrative Support Activity (IASA).