idnits 2.17.1 draft-ietf-ospf-iana-02.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 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 681. 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 3, 2007) is 6263 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) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 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 4, 2007 March 3, 2007 8 IANA Considerations for OSPF 9 draft-ietf-ospf-iana-02 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 4, 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 . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . 8 64 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 5.1. OSPFv2 Options Registry . . . . . . . . . . . . . . . . . 9 68 5.2. OSPFv3 Options Registry . . . . . . . . . . . . . . . . . 9 69 5.3. OSPF Packet Type Registry . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . 11 73 5.7. OSPFv2 Router Properties Registry . . . . . . . . . . . . 11 74 5.8. OSPFv3 LSA Function Code Registry . . . . . . . . . . . . 12 75 5.9. OSPFv3 Prefix Options Registry . . . . . . . . . . . . . . 13 76 5.10. OSPFv3 Router LSA Link Type Registry . . . . . . . . . . . 13 77 5.11. OSPFv2 Opaque LSA Type Registry . . . . . . . . . . . . . 13 78 5.12. OSPFv2 Grace LSA Top Level TLV Registry . . . . . . . . . 13 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 81 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 83 Intellectual Property and Copyright Statements . . . . . . . . . . 16 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 (Defined in section A.4.2.1 of [RFC2740]) 267 +-----------+--------------------+ 268 | Range | Assignment Policy | 269 +-----------+--------------------+ 270 | 0 | Not to be assigned | 271 | 1-9 | Already assigned | 272 | 10-255 | Standards Action | 273 | 256-8175 | Reserved | 274 | 8176-8183 | Experimentation | 275 | 8184-8191 | Vendor Private Use | 276 +-----------+--------------------+ 278 In an OSPFv3 LSA with LSA Function Code in the Vendor Private Use 279 range, the first four octets following the 20 octets of LSA header 280 MUST be the Vendor enterprise code. 282 If a new LSA Function Code is documented, the documentation MUST 283 include the valid combinations of the U, S2 and S1 bits for the LSA. 284 It SHOULD also say how the Link State ID is to be filled in. 286 2.5.1. OSPFv3 Prefix Options 288 (Defined in section A.4.1.1 of [RFC2740]) 290 Assignment policy: Standards Action. 292 2.5.2. OSPFv3 Router LSA Link Type 294 (Defined in section A.4.3 of [RFC2740]) 296 +---------+--------------------+ 297 | Range | Assignment Policy | 298 +---------+--------------------+ 299 | 0 | Not to be assigned | 300 | 1-4 | Already assigned | 301 | 5-127 | Standards Action | 302 | 128-255 | Reserved | 303 +---------+--------------------+ 305 There is no range for Vendor Private Use, as there is no space for an 306 enterprise code to identify the Vendor. 308 No Experimental range is defined, due to possible backwards 309 compatibility issues. 311 2.6. OSPFv2 Opaque LSA Type 313 (Defined in section A.2 of [RFC2370]) 314 (Note: this registry is called "OSPF Opaque LSA Option" by IANA. See 315 also [RFC3630].) 317 +---------+--------------------+ 318 | Range | Assignment Policy | 319 +---------+--------------------+ 320 | 0 | Not to be assigned | 321 | 1-3 | Already assigned | 322 | 4-127 | Standards Action | 323 | 128-247 | Reserved | 324 | 248-251 | Experimentation | 325 | 252-255 | Vendor Private Use | 326 +---------+--------------------+ 328 In an OSPFv2 Opaque LSA with Opaque LSA Type in the Vendor Private 329 Use range, the first four octets of Opaque Information MUST be the 330 Vendor enterprise code. 332 A document defining a new Standards Track Opaque LSA with TLVs and 333 sub-TLVs MUST describe ranges and assignment policies for these TLVs. 335 2.6.1. OSPFv2 Grace LSA Top Level TLVs 337 (Defined in Section A of [RFC3623]) 339 +-------------+--------------------+ 340 | Range | Assignment Policy | 341 +-------------+--------------------+ 342 | 0 | Not to be assigned | 343 | 1-3 | Already assigned | 344 | 4-255 | Standards Action | 345 | 256-65519 | Reserved | 346 | 65520-65527 | Experimentation | 347 | 65528-65535 | Vendor Private Use | 348 +-------------+--------------------+ 350 In a Grace LSA, if a top-level TLV has a Type from the Vendor Private 351 Use range, the Length MUST be at least four, and the first four 352 octets of the Value field MUST be the Vendor enterprise code. 354 3. Acknowledgments 356 Many thanks to Adrian Farrel and Acee Lindem for their review and 357 comments. 359 4. Security Considerations 361 The lack of adequate IANA guidelines may be viewed as an avenue for 362 Denial of Service attacks on IETF protocols (in this case, OSPFv2 and 363 OSPFv3), and on the IETF Standards Process in general. This memo 364 attempts to close this loophole for OSPFv2 and OSPFv3. 366 Authors contemplating extensions to OSPF SHOULD examine such 367 extensions carefully, and consider whether new registries are needed, 368 and if so, allocation policies within each registry. 370 5. IANA Considerations 372 This document specifies assignment policy for several existing IANA 373 registries and creates several more. 375 5.1. OSPFv2 Options Registry 377 Section 2.1 defines the policy for allocation of bits from this 378 registry as "Standards Action". There are only 8 bits in this field, 379 and 6 are already assigned. The initial registry contents are given 380 below. 382 OSPFv2 Options Registry (Section 2.1) 384 Value Description Reference 385 ----- ----------- --------- 386 0x02 E-bit [RFC2328] 387 0x04 MC-bit [RFC1584] 388 0x08 N/P-bit [RFC3101] 389 0x10 EA-Bit 390 0x20 DC-bit [RFC1793] 391 0x40 O-bit [RFC2370] 393 5.2. OSPFv3 Options Registry 395 Section 2.2 defines the policy for allocation of bits from this 396 registry as "Standards Action". There are 24 bits in this field, and 397 6 are assigned. The initial registry contents are given below. 399 OSPFv3 Options Registry (Section 2.2) 401 Value Description Reference 402 -------- ----------- --------- 403 0x000001 V6-bit [RFC2740] 404 0x000002 E-bit [RFC2328] 405 0x000004 MC-bit [RFC1584] 406 0x000008 N-bit [RFC3101] 407 0x000010 R-Bit [RFC2740] 408 0x000020 DC-bit [RFC1793] 410 5.3. OSPF Packet Type Registry 412 Section 2.3 defines the policy for allocation of values from this 413 registry for different ranges. The initial registry contents are 414 given below. 416 OSPF Packet Type (Section 2.3) 418 Value Description Reference 419 ----- -------------------- --------- 420 1 Hello [RFC2328] 421 2 Database Description [RFC2328] 422 3 Link State Request [RFC2328] 423 4 Link State Update [RFC2328] 424 5 Link State Ack [RFC2328] 426 5.4. OSPF Authentication Type Registry 428 This registry already exists at IANA, called "ospf-authentication- 429 codes". Section 2.3.1 defines the policy for allocation from this 430 registry for different ranges. 432 5.5. OSPFv2 Link State Type Registry 434 Section 2.4 defines the policy for allocations from this registry for 435 different ranges. The initial registry contents are given below. 437 OSPFv2 Link State (LS) Type (Section 2.4) 439 Value Description Reference 440 ----- ------------------------ --------- 441 1 Router-LSA [RFC2328] 442 2 Network-LSA [RFC2328] 443 3 Summary-LSA (IP network) [RFC2328] 444 4 Summary-LSA (ASBR) [RFC2328] 445 5 AS-external-LSA [RFC2328] 446 6 Group-membership-LSA [RFC1584] 447 7 NSSA AS-external LSA [RFC3101] 448 8 external-attributes-LSA 449 9 Link-local Opaque LSA [RFC2370] 450 10 Area-local Opaque LSA [RFC2370] 451 11 Opaque LSA [RFC2370] 453 5.6. OSPFv2 Router LSA Link Type Registry 455 Section 2.4.1 defines the policy for allocations from this registry 456 for different ranges. The initial registry contents are given below. 458 OSPFv2 Router LSA Link Type (Section 2.4.1) 460 Value Description Reference 461 ----- ------------------------------------------- --------- 462 1 Point-to-Point connection to another router [RFC2328] 463 2 Transit Network [RFC2328] 464 3 Stub Network [RFC2328] 465 4 Virtual Link [RFC2328] 467 5.7. OSPFv2 Router Properties Registry 469 Section 2.4.2 defines the policy for allocation of bits from this 470 registry as "Standards Action". There are only 8 bits in this field, 471 and 5 are already assigned. The initial registry contents are given 472 below. 474 OSPFv2 Options Registry (Section 2.1) 476 Value Description Reference 477 ----- ----------- --------- 478 0x01 B-bit [RFC2328] 479 0x02 W-bit [RFC2328] 480 0x04 V-bit [RFC2328] 481 0x08 W-bit [RFC1584] 482 0x10 Nt-bit [RFC3101] 484 5.8. OSPFv3 LSA Function Code Registry 486 Section 2.5 defines the policy for allocations from this registry for 487 different ranges. As defined in [RFC2740], the first three bits of 488 the LSA Function Code are the U, S1 and S2 bits. A given function 489 code implies a specific setting for the U, S1 and S2 bits as shwon in 490 the "LS Type" column. 491 1 1 1 1 1 1 492 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 493 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 494 |U |S2|S1| LSA Function Code | 495 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 497 The U bit indicates how the LSA should be handled by a router which 498 does not recognize the LSA's function code. Its values are: 500 U-bit LSA Handling 501 ----- ---------------------------------------------------- 502 0 Treat the LSA as if it had link-local flooding scope 503 1 Store and flood the LSA, as if type understood 505 The S1 and S2 bits indicate the flooding scope of the LSA. The 506 values are: 508 S1 S2 Flooding Scope 509 -- -- -------------------------------------------------------------- 510 0 0 Link-Local Scoping. Flooded only on link it is originated on. 511 0 1 Area Scoping. Flooded to all routers in the originating area 512 1 0 AS Scoping. Flooded to all routers in the AS 513 1 1 Reserved 515 The initial registry contents are given below. 517 OSPFv3 LSA Function Code (Section 2.5) 519 LSA function code LS Type Description Reference 520 ----------------- ------- --------------------- --------- 521 1 0x2001 Router-LSA [RFC2740] 522 2 0x2002 Network-LSA [RFC2740] 523 3 0x2003 Inter-Area-Prefix-LSA [RFC2740] 524 4 0x2004 Inter-Area-Router-LSA [RFC2740] 525 5 0x4005 AS-External-LSA [RFC2740] 526 6 0x2006 Group-membership-LSA [RFC2740] 527 7 0x2007 Type-7-LSA [RFC2740] 528 8 0x0008 Link-LSA [RFC2740] 529 9 0x2009 Intra-Area-Prefix-LSA [RFC2740] 531 5.9. OSPFv3 Prefix Options Registry 533 Section 2.5.1 defines the policy for allocation of bits from this 534 registry as "Standards Action". There are only 8 bits in this field, 535 and 4 are already assigned. The initial registry contents are given 536 below. 538 OSPFv3 Prefix Options Registry (Section 2.5.1) 540 Value Description Reference 541 ----- ----------- --------- 542 0x01 NU-bit [RFC2740] 543 0x02 LA-bit [RFC2740] 544 0x04 MC-bit [RFC2740] 545 0x08 P-bit [RFC2740] 547 5.10. OSPFv3 Router LSA Link Type Registry 549 Section 2.5.2 defines the policy for allocations from this registry 550 for different ranges. The initial registry contents are given below. 552 OSPFv3 Router LSA Link Type (Section 2.5.2) 554 Value Description Reference 555 ----- ------------------------------------------- --------- 556 1 Point-to-Point connection to another router [RFC2740] 557 2 Transit Network [RFC2740] 558 3 Reserved [RFC2740] 559 4 Virtual Link [RFC2740] 561 5.11. OSPFv2 Opaque LSA Type Registry 563 This registry already exists at IANA, called "ospf-opaque-types". 564 Section 2.6 defines the policy for allocation from this registry for 565 different ranges. 567 5.12. OSPFv2 Grace LSA Top Level TLV Registry 569 Section 2.6.1 defines the policy for allocations from this registry 570 for different ranges. The initial registry contents are given below. 572 OSPFv2 Grace LSA Top Level TLV (Section 2.6.1) 574 Value Description Reference 575 ----- ----------------------- --------- 576 1 Grace Period [RFC3623] 577 2 Graceful Restart reason [RFC3623] 578 3 IP Interface Address [RFC3623] 580 6. References 582 6.1. Normative References 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, March 1997. 587 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 588 March 1994. 590 [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", 591 RFC 1793, April 1995. 593 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 595 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 596 July 1998. 598 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 599 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 600 October 1998. 602 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 603 RFC 2740, December 1999. 605 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 606 RFC 3101, January 2003. 608 [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF 609 Restart", RFC 3623, November 2003. 611 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 612 (TE) Extensions to OSPF Version 2", RFC 3630, 613 September 2003. 615 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 616 Considered Useful", BCP 82, RFC 3692, January 2004. 618 6.2. Informative References 620 [ENTERPRISE-NUMBERS] 621 "PRIVATE ENTERPRISE NUMBERS", 622 . 624 Authors' Addresses 626 Kireeti Kompella 627 Juniper Networks 628 1194 N. Mathilda Ave. 629 Sunnyvale, CA 94089 630 US 632 Email: kireeti@juniper.net 634 Bill Fenner 635 AT&T Labs - Research 636 1 River Oaks Place 637 San Jose, California 95134 638 United States 640 Phone: +1 (408) 493-8505 641 Email: fenner@research.att.com 643 Full Copyright Statement 645 Copyright (C) The IETF Trust (2007). 647 This document is subject to the rights, licenses and restrictions 648 contained in BCP 78, and except as set forth therein, the authors 649 retain all their rights. 651 This document and the information contained herein are provided on an 652 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 653 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 654 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 655 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 656 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 657 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 659 Intellectual Property 661 The IETF takes no position regarding the validity or scope of any 662 Intellectual Property Rights or other rights that might be claimed to 663 pertain to the implementation or use of the technology described in 664 this document or the extent to which any license under such rights 665 might or might not be available; nor does it represent that it has 666 made any independent effort to identify any such rights. Information 667 on the procedures with respect to rights in RFC documents can be 668 found in BCP 78 and BCP 79. 670 Copies of IPR disclosures made to the IETF Secretariat and any 671 assurances of licenses to be made available, or the result of an 672 attempt made to obtain a general license or permission for the use of 673 such proprietary rights by implementers or users of this 674 specification can be obtained from the IETF on-line IPR repository at 675 http://www.ietf.org/ipr. 677 The IETF invites any interested party to bring to its attention any 678 copyrights, patents or patent applications, or other proprietary 679 rights that may cover technology that may be required to implement 680 this standard. Please address the information to the IETF at 681 ietf-ipr@ietf.org. 683 Acknowledgment 685 Funding for the RFC Editor function is provided by the IETF 686 Administrative Support Activity (IASA).