idnits 2.17.1 draft-ietf-rreq-iprouters-require-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 113 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 231 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 18 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 238: '...s similar in meaning to SHOULD, but is...' RFC 2119 keyword, line 279: '...it satisfies all of the Relevant MUST,...' RFC 2119 keyword, line 280: '... MUST IMPLEMENT, and MUST NOT req...' RFC 2119 keyword, line 283: '... of the Relevant SHOULD, SHOULD IMPLEM...' RFC 2119 keyword, line 286: '...one or more of the Relevant MUST, MUST...' (619 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 113 has weird spacing: '...erseded by th...' == Line 2518 has weird spacing: '...problem is in...' == Line 3409 has weird spacing: '...se, the packe...' == Line 4111 has weird spacing: '...dropped becau...' == Line 9346 has weird spacing: '...tecting and r...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A router MUST not believe any ARP reply which claims that the Link Layer address of another host or router is a broadcast or multicast address. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that to comply with Section [6.1] of this memo, a router MUST use UDP checksums in RIP packets which it originates, MUST discard RIP packets received with invalid UDP checksums, but MUST not discard received RIP packets simply because they do not contain UDP checksums. -- 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 (21 December 1993) is 11081 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) -- Missing reference section? '8' on line 1975 looks like a reference -- Missing reference section? '7' on line 5246 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT 4 Requirements for IP Routers 6 8 21 December 1993 9 Document Revision 1.47 10 Revision Date: 12/21/93 12 Frank Kastenholz (Editor) 13 FTP Software, Inc 14 2 High Street 15 North Andover, Mass 01845-2620 USA 17 kasten@ftp.com 19 Status of this Memo 21 This document is an Internet Draft. Internet Drafts are 22 working documents of the Internet Engineering Task Force 23 (IETF), its Areas, and its Working Groups. Note that other 24 groups may also distribute working documents as Internet 25 Drafts. 27 Internet Drafts are draft documents valid for a maximum of six 28 months. Internet Drafts may be updated, replaced, or 29 obsoleted by other documents at any time. It is not 30 appropriate to use Internet Drafts as reference material or to 31 cite them other than as a ``working draft'' or ``work in 32 progress.'' Please check the 1id-abstracts.txt listing 33 contained in the internet-drafts Shadow Directories on 34 nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or 35 munnari.oz.au to learn the current status of any Internet 36 Draft. 38 This is a working document only, it should neither be cited 39 nor quoted in any formal document. 41 This document will expire before 26 June 1994. 43 Distribution of this document is unlimited. 45 Please send comments to the editor. 47 If your comment pertains to a particular piece of text, please 48 remember to mention the section number, this document is very 49 large and locating the text solely by context might not be 50 possible. Please also mention the date of this draft 51 (12/21/93) and the revision level (1.47). 53 1. INTRODUCTION 55 The memo replaces for RFC-1009, "Requirements for Internet 56 Gateways" ([INTRO:1]). 58 This memo defines and discusses requirements for devices which 59 perform the network layer forwarding function of the Internet 60 protocol suite. The Internet community usually refers to such 61 devices as "IP routers" or simply "routers"; The OSI community 62 refers to such devices as "intermediate systems". Many older 63 Internet documents refer to these devices as "gateways", a 64 name which more recently has largely passed out of favor to 65 avoid confusion with application gateways. 67 An IP router can be distinguished from other sorts of packet 68 switching devices in that a router examines the IP protocol 69 header as part of the switching process. It generally has to 70 modify the IP header and to strip off and replace the Link 71 Layer framing. 73 The authors of this memo recognize, as should its readers, 74 that many routers support multiple protocol suites, and that 75 support for multiple protocol suites will be required in 76 increasingly large parts of the Internet in the future. This 77 memo, however, does not attempt to specify Internet 78 requirements for protocol suites other than TCP/IP. 80 This document enumerates standard protocols that a router 81 connected to the Internet must use, and it incorporates by 82 reference the RFCs and other documents describing the current 83 specifications for these protocols. It corrects errors in the 84 referenced documents and adds additional discussion and 85 guidance for an implementor. 87 For each protocol, this memo also contains an explicit set of 88 requirements, recommendations, and options. The reader must 89 understand that the list of requirements in this memo is 90 incomplete by itself; the complete set of requirements for an 91 Internet protocol router is primarily defined in the standard 92 protocol specification documents, with the corrections, 93 amendments, and supplements contained in this memo. 95 This memo should be read in conjunction with the Requirements 96 for Internet Hosts RFCs ([INTRO:2] and [INTRO:3]). Internet 97 hosts and routers must both be capable of originating IP 98 datagrams and receiving IP datagrams destined for them. The 99 major distinction between Internet hosts and routers is that 100 routers are required to implement forwarding algorithms and 101 Internet hosts do not require forwarding capabilities. Any 102 Internet host acting as a router must adhere to the 103 requirements contained in this memo. 105 The goal of "open system interconnection" dictates that 106 routers must function correctly as Internet hosts when 107 necessary. To achieve this, this memo provides guidelines for 108 such instances. For simplification and ease of document 109 updates, this memo tries to avoid overlapping discussions of 110 host requirements with [INTRO:2] and [INTRO:3] and 111 incorporates the relevant requirements of those documents by 112 reference. In some cases the requirements stated in [INTRO:2] 113 and [INTRO:3] are superseded by this document. 115 A good-faith implementation of the protocols produced after 116 careful reading of the RFCs, with some interaction with the 117 Internet technical community, and that follows good 118 communications software engineering practices, should differ 119 from the requirements of this memo in only minor ways. Thus, 120 in many cases, the "requirements" in this document are already 121 stated or implied in the standard protocol documents, so that 122 their inclusion here is, in a sense, redundant. However, they 123 were included because some past implementation has made the 124 wrong choice, causing problems of interoperability, 125 performance, and/or robustness. 127 This memo includes discussion and explanation of many of the 128 requirements and recommendations. A simple list of 129 requirements would be dangerous, because: 131 + Some required features are more important than others, and 132 some features are optional. 134 + Some features are critical in some applications of routers 135 but irrelevant in others. 137 + There may be valid reasons why particular vendor products 138 that are designed for restricted contexts might choose to 139 use different specifications. 141 However, the specifications of this memo must be followed to 142 meet the general goal of arbitrary router interoperation 143 across the diversity and complexity of the Internet. Although 144 most current implementations fail to meet these requirements 145 in various ways, some minor and some major, this specification 146 is the ideal towards which we need to move. 148 These requirements are based on the current level of Internet 149 architecture. This memo will be updated as required to 150 provide additional clarifications or to include additional 151 information in those areas in which specifications are still 152 evolving. 154 1.1 Reading this Document 156 1.1.1 Organization 158 This memo emulates the layered organization used by 159 [INTRO:2] and [INTRO:3]. Thus, Chapter 2 describes the 160 layers found in the Internet architecture. Chapter 3 161 covers the Link Layer. Chapters 4 and 5 are concerned 162 with the Internet Layer protocols and forwarding 163 algorithms. Chapter 6 covers the Transport Layer. 164 Upper layer protocols are divided between Chapter 7, 165 which discusses the protocols which routers use to 166 exchange routing information with each other, Chapter 8, 167 which discusses network management, and Chapter 9, which 168 discusses other upper layer protocols. The final 169 chapter covers operations and maintenance features. 170 This organization was chosen for simplicity, clarity, 171 and consistency with the Host Requirements RFCs. 172 Appendices to this memo include a bibliography, a 173 glossary, and some conjectures about future directions 174 of router standards. 176 In describing the requirements, we assume that an 177 implementation strictly mirrors the layering of the 178 protocols. However, strict layering is an imperfect 179 model, both for the protocol suite and for recommended 180 implementation approaches. Protocols in different 181 layers interact in complex and sometimes subtle ways, 182 and particular functions often involve multiple layers. 183 There are many design choices in an implementation, many 184 of which involve creative "breaking" of strict layering. 185 Every implementor is urged to read [INTRO:4] and 186 [INTRO:5]. 188 In general, each major section of this memo is organized 189 into the following subsections: 191 (1) Introduction 193 (2) Protocol Walk-Through -- considers the protocol 194 specification documents section-by-section, 195 correcting errors, stating requirements that may be 196 ambiguous or ill-defined, and providing further 197 clarification or explanation. 199 (3) Specific Issues -- discusses protocol design and 200 implementation issues that were not included in the 201 walk-through. 203 Under many of the individual topics in this memo, there 204 is parenthetical material labeled "DISCUSSION" or 205 "IMPLEMENTATION". This material is intended to give a 206 justification, clarification or explanation to the 207 preceding requirements text. The implementation 208 material contains suggested approaches that an 209 implementor may want to consider. The DISCUSSION and 210 IMPLEMENTATION sections are not part of the standard. 212 1.1.2 Requirements 214 In this memo, the words that are used to define the 215 significance of each particular requirement are 216 capitalized. These words are: 218 + "MUST" 219 This word means that the item is an absolute 220 requirement of the specification. 222 + "MUST IMPLEMENT" 223 This phrase means that this specification requires 224 that the item be implemented, but does not require 225 that it be enabled by default. 227 + "MUST NOT" 228 This phrase means that the item is an absolute 229 prohibition of the specification. 231 + "SHOULD" 232 This word means that there may exist valid reasons in 233 particular circumstances to ignore this item, but the 234 full implications should be understood and the case 235 carefully weighed before choosing a different course. 237 + "SHOULD IMPLEMENT" 238 This phrase is similar in meaning to SHOULD, but is 239 used when we recommend that a particular feature be 240 provided but does not necessarily recommend that it 241 be enabled by default. 243 + "SHOULD NOT" 244 This phrase means that there may exist valid reasons 245 in particular circumstances when the described 246 behavior is acceptable or even useful, but the full 247 implications should be understood and the case 248 carefully weighed before implementing any behavior 249 described with this label. 251 + "MAY" 252 This word means that this item is truly optional. 253 One vendor may choose to include the item because a 254 particular marketplace requires it or because it 255 enhances the product, for example; another vendor may 256 omit the same item. 258 1.1.3 Compliance 260 Some requirements are applicable to all routers. Other 261 requirements are applicable only to those which 262 implement particular features or protocols. In the 263 following paragraphs, "Relevant" refers to the union of 264 the requirements applicable to all routers and the set 265 of requirements applicable to a particular router 266 because of the set of features and protocols it has 267 implemented. 269 Note that not all Relevant requirements are stated 270 directly in this memo. Various parts of this memo 271 incorporate by reference sections of the Host 272 Requirements specification, [INTRO:2] and [INTRO:3]. 273 For purposes of determining compliance with this memo, 274 it does not matter whether a Relevant requirement is 275 stated directly in this memo or merely incorporated by 276 reference from one of those documents. 278 An implementation is said to be "conditionally 279 compliant" if it satisfies all of the Relevant MUST, 280 MUST IMPLEMENT, and MUST NOT requirements. An 281 implementation is said to be "unconditionally compliant" 282 if it is conditionally compliant and also satisfies all 283 of the Relevant SHOULD, SHOULD IMPLEMENT, and SHOULD NOT 284 requirements. An implementation is not compliant if it 285 is not conditionally compliant (i.e., it fails to 286 satisfy one or more of the Relevant MUST, MUST 287 IMPLEMENT, or MUST NOT requirements). 289 For any of the SHOULD and SHOULD NOT requirements, a 290 router may provide a configuration option that will 291 cause the router to act other than as specified by the 292 requirement. Having such a configuration option does 293 not void a router's claim to unconditional compliance as 294 long as the option has a default setting, and that 295 leaving the option at its default setting causes the 296 router to operate in a manner which conforms to the 297 requirement. 299 Likewise, routers may provide, except where explicitly 300 prohibited by this memo, options which cause them to 301 violate MUST or MUST NOT requirements. A router which 302 provides such options is compliant (either fully or 303 conditionally) if and only if each such option has a 304 default setting which causes the router to conform to 305 the requirements of this memo. Please note that the 306 authors of this memo, although aware of market 307 realities, strongly recommend against provision of such 308 options. Requirements are labeled MUST or MUST NOT 309 because experts in the field have judged them to be 310 particularly important to interoperability or proper 311 functioning in the Internet. Vendors should weigh 312 carefully the customer support costs of providing 313 options which violate those rules. 315 Of course, this memo is not a complete specification of 316 an IP router, but rather is closer to what in the OSI 317 world is called a profile. For example, this memo 318 requires that a number of protocols be implemented. 319 Although most of the contents of their protocol 320 specifications are not repeated in this memo, 321 implementors are nonetheless required to implement the 322 protocols according to those specifications. 324 1.2 Relationships to Other Standards 326 There are several reference documents of interest in 327 checking the current status of protocol specifications and 328 standardization: 330 + INTERNET OFFICIAL PROTOCOL STANDARDS 331 This document describes the Internet standards process 332 and lists the standards status of the protocols. As 333 of this writing (December, 1993) the current version 334 of this document is RFC 1540, [ARCH:7]. This document 335 is periodically re-issued. You should always consult 336 an RFC repository and use the latest version of this 337 document. 339 + Assigned Numbers 340 This document lists the assigned values of the 341 parameters used in the various protocols. For 342 example, IP protocol codes, TCP port numbers, Telnet 343 Option Codes, ARP hardware types, and Terminal Type 344 names. As of this writing (December, 1993) the 345 current version of this document is RFC 1340, 346 [INTRO:7]. This document is periodically re-issued. 347 You should always consult an RFC repository and use 348 the latest version of this document. 350 + Host Requirements 351 This pair of documents reviews the specifications that 352 apply to hosts and supplies guidance and clarification 353 for any ambiguities. Note that these requirements 354 also apply to routers, except where otherwise 355 specified in this memo. As of this writing (December, 356 1993) the current versions of these documents are RFC 357 1122 and RFC 1123, [INTRO:2], and [INTRO:3] 358 respectively. 360 + Router Requirements (formerly "Gateway Requirements") 361 This memo. 363 Note that these documents are revised and updated at 364 different times; in case of differences between these 365 documents, the most recent must prevail. 367 These and other Internet protocol documents may be 368 obtained from the: 369 DDN Network Information Center 370 14200 Park Meadow Drive, Suite 200 371 Chantilly, VA 22021 372 USA 374 nic@ds.internic.net 376 (800) 365-3642 or (703) 802-4535 378 1.3 General Considerations 380 There are several important lessons that vendors of 381 Internet software have learned and which a new vendor 382 should consider seriously. 384 1.3.1 Continuing Internet Evolution 386 The enormous growth of the Internet has revealed 387 problems of management and scaling in a large datagram- 388 based packet communication system. These problems are 389 being addressed, and as a result there will be 390 continuing evolution of the specifications described in 391 this memo. New routing protocols, algorithms, and 392 architectures are constantly being developed. New and 393 additional internet-layer protocols are also constantly 394 being devised. Because routers play such a crucial role 395 in the Internet, and because the number of routers 396 deployed in the Internet is much smaller than the number 397 of hosts, vendors should expect that router standards 398 will continue to evolve much more quickly than host 399 standards. These changes will be carefully planned and 400 controlled since there is extensive participation in 401 this planning by the vendors and by the organizations 402 responsible for operation of the networks. 404 Development, evolution, and revision are characteristic 405 of computer network protocols today, and this situation 406 will persist for some years. A vendor who develops 407 computer communications software for the Internet 408 protocol suite (or any other protocol suite!) and then 409 fails to maintain and update that software for changing 410 specifications is going to leave a trail of unhappy 411 customers. The Internet is a large communication 412 network, and the users are in constant contact through 413 it. Experience has shown that knowledge of deficiencies 414 in vendor software propagates quickly through the 415 Internet technical community. 417 1.3.2 Robustness Principle 419 At every layer of the protocols, there is a general rule 420 (from [TRANS:2] by Jon Postel) whose application can 421 lead to enormous benefits in robustness and 422 interoperability: 424 "Be conservative in what you do, 425 be liberal in what you accept from others." 427 Software should be written to deal with every 428 conceivable error, no matter how unlikely; sooner or 429 later a packet will come in with that particular 430 combination of errors and attributes, and unless the 431 software is prepared, chaos can ensue. In general, it 432 is best to assume that the network is filled with 433 malevolent entities that will send packets designed to 434 have the worst possible effect. This assumption will 435 lead to suitably protective design. The most serious 436 problems in the Internet have been caused by unforeseen 437 mechanisms triggered by low probability events; mere 438 human malice would never have taken so devious a course! 440 Adaptability to change must be designed into all levels 441 of router software. As a simple example, consider a 442 protocol specification that contains an enumeration of 443 values for a particular header field -- e.g., a type 444 field, a port number, or an error code; this enumeration 445 must be assumed to be incomplete. If the protocol 446 specification defines four possible error codes, the 447 software must not break when a fifth code shows up. An 448 undefined code might be logged, but it must not cause a 449 failure. 451 The second part of the principle is almost as important: 452 software on hosts or other routers may contain 453 deficiencies that make it unwise to exploit legal but 454 obscure protocol features. It is unwise to stray far 455 from the obvious and simple, lest untoward effects 456 result elsewhere. A corollary of this is "watch out for 457 misbehaving hosts"; router software should be prepared 458 to survive in the presence of misbehaving hosts. An 459 important function of routers in the Internet is to 460 limit the amount of disruption such hosts can inflict on 461 the shared communication facility. 463 1.3.3 Error Logging 465 The Internet includes a great variety of systems, each 466 implementing many protocols and protocol layers, and 467 some of these contain bugs and misfeatures in their 468 Internet protocol software. As a result of complexity, 469 diversity, and distribution of function, the diagnosis 470 of problems is often very difficult. 472 Problem diagnosis will be aided if routers include a 473 carefully designed facility for logging erroneous or 474 "strange" events. It is important to include as much 475 diagnostic information as possible when an error is 476 logged. In particular, it is often useful to record the 477 header(s) of a packet that caused an error. However, 478 care must be taken to ensure that error logging does not 479 consume prohibitive amounts of resources or otherwise 480 interfere with the operation of the router. 482 There is a tendency for abnormal but harmless protocol 483 events to overflow error logging files; this can be 484 avoided by using a "circular" log, or by enabling 485 logging only while diagnosing a known failure. It may 486 be useful to filter and count duplicate successive 487 messages. One strategy that seems to work well is to 488 both: 489 + Always count abnormalities and make such counts 490 accessible through the management protocol (see 491 Chapter 8); and 492 + Allow the logging of a great variety of events to be 493 selectively enabled. For example, it might useful to 494 be able to "log everything" or to "log everything for 495 host X". 497 This topic is further discussed in [MGT:5]. 499 1.3.4 Configuration 501 In an ideal world, routers would be easy to configure, 502 and perhaps even entirely self-configuring. However, 503 practical experience in the real world suggests that 504 this is an impossible goal, and that in fact many 505 attempts by vendors to make configuration easy actually 506 cause customers more grief than they prevent. As an 507 extreme example, a router designed to come up and start 508 routing packets without requiring any configuration 509 information at all would almost certainly choose some 510 incorrect parameter, possibly causing serious problems 511 on any networks unfortunate enough to be connected to 512 it. 514 Often this memo requires that a parameter be a 515 configurable option. There are several reasons for 516 this. In a few cases there currently is some 517 uncertainty or disagreement about the best value and it 518 may be necessary to update the recommended value in the 519 future. In other cases, the value really depends on 520 external factors -- e.g., the distribution of its 521 communication load, or the speeds and topology of nearby 522 networks -- and self-tuning algorithms are unavailable 523 and may be insufficient. In some cases, configurability 524 is needed because of administrative requirements. 526 Finally, some configuration options are required to 527 communicate with obsolete or incorrect implementations 528 of the protocols, distributed without sources, that 529 persist in many parts of the Internet. To make correct 530 systems coexist with these faulty systems, 531 administrators must occasionally misconfigure the 532 correct systems. This problem will correct itself 533 gradually as the faulty systems are retired, but cannot 534 be ignored by vendors. 536 When we say that a parameter must be configurable, we do 537 not intend to require that its value be explicitly read 538 from a configuration file at every boot time. For many 539 parameters, there is one value that is appropriate for 540 all but the most unusual situations. In such cases, it 541 is quite reasonable that the parameter default to that 542 value if not explicitly set. 544 This memo requires a particular value for such defaults 545 in some cases. The choice of default is a sensitive 546 issue when the configuration item controls accommodation 547 of existing, faulty, systems. If the Internet is to 548 converge successfully to complete interoperability, the 549 default values built into implementations must implement 550 the official protocol, not misconfigurations to 551 accommodate faulty implementations. Although marketing 552 considerations have led some vendors to choose 553 misconfiguration defaults, we urge vendors to choose 554 defaults that will conform to the standard. 556 Finally, we note that a vendor needs to provide adequate 557 documentation on all configuration parameters, their 558 limits and effects. 560 1.4 Algorithms 562 In several places in this memo, specific algorithms that a 563 router ought to follow are specified. These algorithms are 564 not, per se, required of the router. A router need not 565 implement each algorithm as it is written in this document. 566 Rather, an implementation must present a behavior to the 567 external world that is the same as a strict, literal, 568 implementation of the specified algorithm. 570 Algorithms are described in a manner that differs from the 571 way a good implementor would implement them. For 572 expository purposes, a style that emphasizes conciseness, 573 clarity, and independence from implementation details has 574 been chosen. A good implementor will choose algorithms and 575 implementation methods which produce the same results as 576 these algorithms, but may be more efficient or less 577 general. 579 We note that the art of efficient router implementation is 580 outside of the scope of this memo. 582 2. INTERNET ARCHITECTURE 584 This chapter does not contain any requirements. However, it 585 does contain useful background information on the general 586 architecture of the Internet and of routers. 588 General background and discussion on the Internet architecture 589 and supporting protocol suite can be found in the DDN Protocol 590 Handbook [ARCH:1]; for background see for example [ARCH:2], 591 [ARCH:3], and [ARCH:4]. The Internet architecture and 592 protocols are also covered in an ever-growing number of 593 textbooks, such as [ARCH:5] and [ARCH:6]. 595 2.1 Introduction 597 The Internet system consists of a number of interconnected 598 packet networks supporting communication among host 599 computers using the Internet protocols. These protocols 600 include the Internet Protocol (IP), the Internet Control 601 Message Protocol (ICMP), the Internet Group Management 602 Protocol (IGMP), and a variety transport and application 603 protocols that depend upon them. As was described in 604 Section [1.2], the Internet Engineering Steering Group 605 periodically releases an "Official Protocols" memo listing 606 all of the Internet protocols. 608 All Internet protocols use IP as the basic data transport 609 mechanism. IP is a datagram, or connectionless, 610 internetwork service and includes provision for addressing, 611 type-of-service specification, fragmentation and 612 reassembly, and security. ICMP and IGMP are considered 613 integral parts of IP, although they are architecturally 614 layered upon IP. ICMP provides error reporting, flow 615 control, first-hop router redirection, and other 616 maintenance and control functions. IGMP provides the 617 mechanisms by which hosts and routers can join and leave IP 618 multicast groups. 620 Reliable data delivery is provided in the Internet protocol 621 suite by Transport Layer protocols such as the Transmission 622 Control Protocol (TCP), which provides end-end 623 retransmission, resequencing and connection control. 624 Transport Layer connectionless service is provided by the 625 User Datagram Protocol (UDP). 627 2.2 Elements of the Architecture 629 2.2.1 Protocol Layering 631 To communicate using the Internet system, a host must 632 implement the layered set of protocols comprising the 633 Internet protocol suite. A host typically must 634 implement at least one protocol from each layer. 636 The protocol layers used in the Internet architecture 637 are as follows [ARCH:7]: 639 + Application Layer 640 The Application Layer is the top layer of the 641 Internet protocol suite. The Internet suite does not 642 further subdivide the Application Layer, although 643 some application layer protocols do contain some 644 internal sub-layering. The application layer of the 645 Internet suite essentially combines the functions of 646 the top two layers -- Presentation and Application -- 647 of the OSI Reference Model [ARCH:8]. The Application 648 Layer in the Internet protocol suite also includes 649 some of the function relegated to the Session Layer 650 in the OSI Reference Model. 652 We distinguish two categories of application layer 653 protocols: user protocols that provide service 654 directly to users, and support protocols that provide 655 common system functions. The most common Internet 656 user protocols are: 657 -- Telnet (remote login) 658 -- FTP (file transfer) 659 -- SMTP (electronic mail delivery) 661 There are a number of other standardized user 662 protocols and many private user protocols. 664 Support protocols, used for host name mapping, 665 booting, and management, include SNMP, BOOTP, TFTP, 666 the Domain Name System (DNS) protocol, and a variety 667 of routing protocols. 669 Application Layer protocols relevant to routers are 670 discussed in chapters 7, 8, and 9 of this memo. 672 + Transport Layer 673 The Transport Layer provides end-to-end communication 674 services. This layer is roughly equivalent to the 675 "Transport Layer" in the OSI Reference Model, except 676 that it also incorporates some of OSI's Session Layer 677 establishment and destruction functions. 679 There are two primary Transport Layer protocols at 680 present: 681 -- Transmission Control Protocol (TCP) 682 -- User Datagram Protocol (UDP) 684 TCP is a reliable connection-oriented transport 685 service that provides end-to-end reliability, 686 resequencing, and flow control. UDP is a 687 connectionless ("datagram") transport service. Other 688 transport protocols have been developed by the 689 research community, and the set of official Internet 690 transport protocols may be expanded in the future. 692 Transport Layer protocols relevant to routers are 693 discussed in Chapter 6. 695 + Internet Layer 696 All Internet transport protocols use the Internet 697 Protocol (IP) to carry data from source host to 698 destination host. IP is a connectionless or datagram 699 internetwork service, providing no end-to-end 700 delivery guarantees. IP datagrams may arrive at the 701 destination host damaged, duplicated, out of order, 702 or not at all. The layers above IP are responsible 703 for reliable delivery service when it is required. 704 The IP protocol includes provision for addressing, 705 type-of-service specification, fragmentation and 706 reassembly, and security. 708 The datagram or connectionless nature of IP is a 709 fundamental and characteristic feature of the 710 Internet architecture. 712 The Internet Control Message Protocol (ICMP) is a 713 control protocol that is considered to be an integral 714 part of IP, although it is architecturally layered 715 upon IP, i.e., it uses IP to carry its data end-to- 716 end. ICMP provides error reporting, congestion 717 reporting, and first-hop router redirection. 719 The Internet Group Management Protocol (IGMP) is an 720 Internet layer protocol used for establishing dynamic 721 host groups for IP multicasting. 723 The Internet layer protocols IP, ICMP, and IGMP are 724 discussed in chapter 4. 726 + Link Layer 727 To communicate on its directly-connected network, a 728 host must implement the communication protocol used 729 to interface to that network. We call this a Link 730 Layer layer protocol. 732 Some older Internet documents refer to this layer as 733 the "Network Layer", but it is not the same as the 734 "Network Layer" in the OSI Reference Model. 736 This layer contains everything "below" the Internet 737 Layer. 739 Protocols in this Layer are generally outside the 740 scope of Internet standardization; the Internet 741 (intentionally) uses existing standards whenever 742 possible. Thus, Internet Link Layer standards 743 usually address only address resolution and rules for 744 transmitting IP packets over specific Link Layer 745 protocols. Internet Link Layer standards are 746 discussed in chapter 3. 748 2.2.2 Networks 750 The constituent networks of the Internet system are 751 required to provide only packet (connectionless) 752 transport. According to the IP service specification, 753 datagrams can be delivered out of order, be lost or 754 duplicated, and/or contain errors. 756 For reasonable performance of the protocols that use IP 757 (e.g., TCP), the loss rate of the network should be very 758 low. In networks providing connection-oriented service, 759 the extra reliability provided by virtual circuits 760 enhances the end-end robustness of the system, but is 761 not necessary for Internet operation. 763 Constituent networks may generally be divided into two 764 classes: 766 + Local-Area Networks (LANs) 767 LANs may have a variety of designs. In general, a 768 LAN will cover a small geographical area (e.g., a 769 single building or plant site) and provide high 770 bandwidth with low delays. LANs may be passive 771 (similar to Ethernet) or they may be active (such 772 as ATM). 774 + Wide-Area Networks (WANs) 775 Geographically-dispersed hosts and LANs are 776 interconnected by wide-area networks, also called 777 long-haul networks. These networks may have a 778 complex internal structure of lines and packet- 779 switches, or they may be as simple as point-to- 780 point lines. 782 2.2.3 Routers 784 In the Internet model, constituent networks are 785 connected together by IP datagram forwarders which are 786 called "routers" or "IP routers". In this document, 787 every use of the term "router" is equivalent to "IP 788 router". Many older Internet documents refer to routers 789 as "gateways". 791 Historically, routers have been realized with packet- 792 switching software executing on a general-purpose CPU. 793 However, as custom hardware development becomes cheaper 794 and as higher throughput is required, but special- 795 purpose hardware is becoming increasingly common. This 796 specification applies to routers regardless of how they 797 are implemented. 799 A router is connected to two or more networks, appearing 800 to each of these networks as a connected host. Thus, it 801 has (at least) one physical interface and (at least) one 802 IP address on each of the connected networks (this 803 ignores the concept of un-numbered links, which is 804 discussed in section [2.2.7]). Forwarding an IP 805 datagram generally requires the router to choose the 806 address of the next-hop router or (for the final hop) 807 the destination host. This choice, called "routing", 808 depends upon a routing database within the router. The 809 routing database is also sometimes known as a routing 810 table or forwarding table. 812 The routing database should be maintained dynamically to 813 reflect the current topology of the Internet system. A 814 router normally accomplishes this by participating in 815 distributed routing and reachability algorithms with 816 other routers. 818 Routers provide datagram transport only, and they seek 819 to minimize the state information necessary to sustain 820 this service in the interest of routing flexibility and 821 robustness. 823 Packet switching devices may also operate at the Link 824 Layer; such devices are usually called "bridges". 825 Network segments which are connected by bridges share 826 the same IP network number, i.e., they logically form a 827 single IP network. These other devices are outside of 828 the scope of this document. 830 Another variation on the simple model of networks 831 connected with routers sometimes occurs: a set of 832 routers may be interconnected with only serial lines, to 833 form a network in which the packet switching is 834 performed at the Internetwork (IP) Layer rather than the 835 Link Layer. 837 2.2.4 Autonomous Systems 839 For technical, managerial, and sometimes political 840 reasons, the routers of the Internet system are grouped 841 into collections called "autonomous systems". The 842 routers included in a single autonomous system (AS) are 843 expected to: 845 + Be under the control of a single operations and 846 maintenance (O&M) organization; 848 + Employ common routing protocols among themselves, to 849 dynamically maintain their routing databases. 851 A number of different dynamic routing protocols have 852 been developed (see Section [7.2]); the routing protocol 853 within a single AS is generically called an interior 854 gateway protocol or IGP. 856 An IP datagram may have to traverse the routers of two 857 or more ASs to reach its destination, and the ASs must 858 provide each other with topology information to allow 859 such forwarding. An exterior gateway protocol 860 (generally BGP or EGP) is used for this purpose. 862 2.2.5 Addresses and Subnets 864 An IP datagram carries 32-bit source and destination 865 addresses, each of which is partitioned into two parts 866 -- a constituent network number and a host number on 867 that network. Symbolically: 869 IP-address ::= { , } 871 To finally deliver the datagram, the last router in its 872 path must map the Host-number (or "rest") part of an IP 873 address into the physical address of a host connection 874 to the constituent network. 876 This simple notion has been extended by the concept of 877 "subnets", which were introduced in order to allow 878 arbitrary complexity of interconnected LAN structures 879 within an organization, while insulating the Internet 880 system against explosive growth in network numbers and 881 routing complexity. Subnets essentially provide a 882 multi-level hierarchical routing structure for the 883 Internet system. The subnet extension, described in 884 [INTERNET:2], is now a required part of the Internet 885 architecture. The basic idea is to partition the field into two parts: a subnet number, and a 887 true host number on that subnet: 889 IP-address ::= 890 { , , 891 } 893 The interconnected physical networks within an 894 organization will be given the same network number but 895 different subnet numbers. The distinction between the 896 subnets of such a subnetted network is normally not 897 visible outside of that network. Thus, routing in the 898 rest of the Internet will be based only upon the 899 part of the IP destination address; 900 routers outside the network will combine 901 and together to form an uninterpreted 902 "rest" part of the 32-bit IP address. Within the 903 subnetted network, the routers must route on the basis 904 of an extended network number: 906 { , } 908 Under certain circumstances, it may be desirable to 909 support subnets of a particular network being 910 interconnected only via a path which is not part of the 911 subnetted network. Even though many IGP's and no EGP's 912 currently support this configuration effectively, 913 routers need to be able to support this configuration of 914 subnetting (see Section [4.2.3.4]). In general, routers 915 should not make assumptions about what are subnets and 916 what are not, but simply ignore the concept of Class in 917 networks, and treat each route as a { network, mask 918 }-tuple. 920 DISCUSSION: 921 It is becoming clear that as the Internet grows 922 larger and larger, the traditional uses of Class A, 923 B, and C networks will be modified in order to 924 achieve better use of IP's 32-bit address space. 925 Classless Interdomain Routing (CIDR) [INTERNET:15] is 926 a method currently being deployed in the Internet 927 backbones to achieve this added efficiency. CIDR 928 depends on the ability of assigning and routing to 929 networks that are not based on Class A, B, or C 930 networks. Thus, routers should always treat a route 931 as a network with a mask. 933 Furthermore, for similar reasons, a subnetted network 934 need not have a consistent subnet mask through all parts 935 of the network. For example, one subnet may use an 8 936 bit subnet mask, another 10 bit, and another 6 bit. 937 Routers need to be able to support this type of 938 configuration (see Section [4.2.3.4]). 940 The bit positions containing this extended network 941 number are indicated by a 32-bit mask called the "subnet 942 mask"; it is recommended but not required that the 943 bits be contiguous and fall between the 944 and the fields. No 945 subnet should be assigned the value zero or -1 (all one 946 bits). 948 Although the inventors of the subnet mechanism probably 949 expected that each piece of an organization's network 950 would have only a single subnet number, in practice it 951 has often proven necessary or useful to have several 952 subnets share a single physical cable. 954 There are special considerations for the router when a 955 connected network provides a broadcast or multicast 956 capability; these will be discussed later. 958 2.2.6 IP Multicasting 960 IP multicasting is an extension of Link Layer multicast 961 to IP internets. Using IP multicasts, a single datagram 962 can be addressed to multiple hosts. This collection of 963 hosts is called a multicast group. Each multicast group 964 is represented as a Class D IP address. An IP datagram 965 sent to the group is to be delivered to each group 966 member with the same best-effort delivery as that 967 provided for unicast IP traffic. The sender of the 968 datagram does not itself need to be a member of the 969 destination group. 971 The semantics of IP multicast group membership are 972 defined in [INTERNET:4]. That document describes how 973 hosts and routers join and leave multicast groups. It 974 also defines a protocol, the Internet Group Management 975 Protocol (IGMP), that monitors IP multicast group 976 membership. 978 Forwarding of IP multicast datagrams is accomplished 979 either through static routing information or via a 980 multicast routing protocol. Devices that forward IP 981 multicast datagrams are called multicast routers. They 982 may or may not also forward IP unicasts. In general, 983 multicast datagrams are forwarded on the basis of both 984 their source and destination addresses. Forwarding of 985 IP multicast packets is described in more detail in 986 Section [5.2.1]. Appendix D discusses multicast routing 987 protocols. 989 2.2.7 Unnumbered Lines and Networks and Subnets 991 Traditionally, each network interface on an IP host or 992 router has its own IP address. Over the years, people 993 have observed that this can cause inefficient use of the 994 scarce IP address space, since it forces allocation of 995 an IP network number, or at least a subnet number, to 996 every point-to-point link. 998 To solve this problem, a number of people have proposed 999 and implemented the concept of "unnumbered serial 1000 lines". An unnumbered serial line does not have any IP 1001 network or subnet number associated with it. As a 1002 consequence, the network interfaces connected to an 1003 unnumbered serial line do not have IP addresses. 1005 Because the IP architecture has traditionally assumed 1006 that all interfaces had IP addresses, these unnumbered 1007 interfaces cause some interesting dilemmas. For 1008 example, some IP options (e.g. Record Route) specify 1009 that a router must insert the interface address into the 1010 option, but an unnumbered interface has no IP address. 1011 Even more fundamental (as we shall see in chapter 5) is 1012 that routes contain the IP address of the next hop 1013 router. A router expects that that IP address will be 1014 on an IP (sub)net that the router is connected to. That 1015 assumption is of course violated if the only connection 1016 is an unnumbered serial line. 1018 To get around these difficulties, two schemes have been 1019 invented. The first scheme says that two routers 1020 connected by an unnumbered serial line aren't really two 1021 routers at all, but rather two "half-routers" which 1022 together make up a single (virtual) router. The 1023 unnumbered serial line is essentially considered to be 1024 an internal bus in the virtual router. The two halves 1025 of the virtual router must coordinate their activities 1026 in such a way that they act exactly like a single 1027 router. 1029 This scheme fits in well with the IP architecture, but 1030 suffers from two important drawbacks. The first is 1031 that, although it handles the common case of a single 1032 unnumbered serial line, it is not readily extensible to 1033 handle the case of a mesh of routers and unnumbered 1034 serial lines. The second drawback is that the 1035 interactions between the half routers are necessarily 1036 complex and are not standardized, effectively precluding 1037 the connection of equipment from different vendors using 1038 unnumbered serial lines. 1040 Because of these drawbacks, this memo has adopted an 1041 alternative scheme, which has been invented multiple 1042 times but which is probably originally attributable to 1043 Phil Karn. In this scheme, a router which has 1044 unnumbered serial lines also has a special IP address, 1045 called a "router-id" in this memo. The router-id is one 1046 of the router's IP addresses (a router is required to 1047 have at least one IP address). This router-id is used 1048 as if it is the IP address of all unnumbered interfaces. 1050 2.2.8 Notable Oddities 1052 2.2.8.1 Embedded Routers 1054 A router may be a stand-alone computer system, 1055 dedicated to its IP router functions. Alternatively, 1056 it is possible to embed router functions within a 1057 host operating system which supports connections to 1058 two or more networks. The best-known example of an 1059 operating system with embedded router code is the 1060 Berkeley BSD system. The embedded router feature 1061 seems to make internetting easy, but it has a number 1062 of hidden pitfalls: 1064 (1) If a host has only a single constituent-network 1065 interface, it should not act as a router. 1067 For example, hosts with embedded router code 1068 that gratuitously forward broadcast packets or 1069 datagrams on the same net often cause packet 1070 avalanches. 1072 (2) If a (multihomed) host acts as a router, it must 1073 implement ALL the relevant router requirements 1074 contained in this document. 1076 For example, the routing protocol issues and the 1077 router control and monitoring problems are as 1078 hard and important for embedded routers as for 1079 stand-alone routers. 1081 Since Internet router requirements and 1082 specifications may change independently of 1083 operating system changes, an administration that 1084 operates an embedded router in the Internet is 1085 strongly advised to have the ability to maintain 1086 and update the router code (e.g., this might 1087 require router code source). 1089 (3) Once a host runs embedded router code, it 1090 becomes part of the Internet system. Thus, 1091 errors in software or configuration can hinder 1092 communication between other hosts. As a 1093 consequence, the host administrator must lose 1094 some autonomy. 1096 In many circumstances, a host administrator will 1097 need to disable router code embedded in the 1098 operating system, and any embedded router code 1099 must be organized so that it can be easily 1100 disabled. 1102 (4) If a host running embedded router code is 1103 concurrently used for other services, the O&M 1104 (Operation and Maintenance) requirements for the 1105 two modes of use may be in serious conflict. 1107 For example, router O&M will in many cases be 1108 performed remotely by an operations center; this 1109 may require privileged system access which the 1110 host administrator would not normally want to 1111 distribute. 1113 2.2.8.2 Transparent Routers 1115 There are two basic models for interconnecting local- 1116 area networks and wide-area (or long-haul) networks 1117 in the Internet. In the first, the local-area 1118 network is assigned a network number and all routers 1119 in the Internet must know how to route to that 1120 network. In the second, the local-area network 1121 shares (a small part of) the address space of the 1122 wide-area network. Routers that support this second 1123 model are called "address sharing routers" or 1124 "transparent routers". The focus of this memo is on 1125 routers that support the first model, but this is not 1126 intended to exclude the use of transparent routers. 1128 The basic idea of a transparent router is that the 1129 hosts on the local-area network behind such a router 1130 share the address space of the wide-area network in 1131 front of the router. In certain situations this is a 1132 very useful approach and the limitations do not 1133 present significant drawbacks. 1135 The words "in front" and "behind" indicate one of the 1136 limitations of this approach: this model of 1137 interconnection is suitable only for a geographically 1138 (and topologically) limited stub environment. It 1139 requires that there be some form of logical 1140 addressing in the network level addressing of the 1141 wide-area network. All of the IP addresses in the 1142 local environment map to a few (usually one) physical 1143 address in the wide-area network. This mapping 1144 occurs in a way consistent with the { IP address <-> 1145 network address } mapping used throughout the wide- 1146 area network. 1148 Multihoming is possible on one wide-area network, but 1149 may present routing problems if the interfaces are 1150 geographically or topologically separated. 1151 Multihoming on two (or more) wide-area networks is a 1152 problem due to the confusion of addresses. 1154 The behavior that hosts see from other hosts in what 1155 is apparently the same network may differ if the 1156 transparent router cannot fully emulate the normal 1157 wide-area network service. For example, the ARPANET 1158 used a Link Layer protocol that provided a 1159 "Destination Dead" indication in response to an 1160 attempt to send to a host which was powered off. 1161 However, if there were a transparent router between 1162 the ARPANET and an Ethernet, a host on the ARPANET 1163 would not receive a Destination Dead indication if it 1164 sent a datagram to a host that was powered off and 1165 was connected to the ARPANET via the transparent 1166 router instead of directly. 1168 2.3 Router Characteristics 1170 An Internet router performs the following functions: 1172 (1) Conforms to specific Internet protocols specified in 1173 this document, including the Internet Protocol (IP), 1174 Internet Control Message Protocol (ICMP), and others 1175 as necessary. 1177 (2) Interfaces to two or more packet networks. For each 1178 connected network the router must implement the 1179 functions required by that network. These functions 1180 typically include: 1182 + Encapsulating and decapsulating the IP datagrams 1183 with the connected network framing (e.g., an 1184 Ethernet header and checksum), 1186 + Sending and receiving IP datagrams up to the 1187 maximum size supported by that network, this size 1188 is the network's "Maximum Transmission Unit" or 1189 "MTU", 1191 + Translating the IP destination address into an 1192 appropriate network-level address for the connected 1193 network (e.g., an Ethernet hardware address), if 1194 needed, and 1196 + Responding to the network flow control and error 1197 indication, if any. 1199 See chapter 3 (Link Layer). 1201 (3) Receives and forwards Internet datagrams. Important 1202 issues in this process are buffer management, 1203 congestion control, and fairness. 1205 + Recognizes various error conditions and generates 1206 ICMP error and information messages as required. 1208 + Drops datagrams whose time-to-live fields have 1209 reached zero. 1211 + Fragments datagrams when necessary to fit into the 1212 MTU of the next network. 1214 See chapter 4 (Internet Layer -- Protocols) and 1215 chapter 5 (Internet Layer -- Forwarding) for more 1216 information. 1218 (4) Chooses a next-hop destination for each IP datagram, 1219 based on the information in its routing database. See 1220 chapter 5 (Internet Layer -- Forwarding) for more 1221 information. 1223 (5) (Usually) supports an interior gateway protocol (IGP) 1224 to carry out distributed routing and reachability 1225 algorithms with the other routers in the same 1226 autonomous system. In addition, some routers will 1227 need to support an exterior gateway protocol (EGP) to 1228 exchange topological information with other autonomous 1229 systems. See chapter 7 (Application Layer -- Routing 1230 Protocols) for more information. 1232 (6) Provides network management and system support 1233 facilities, including loading, debugging, status 1234 reporting, exception reporting and control. See 1235 chapter 8 (Application Layer -- Network Management 1236 Protocols) and chapter 10 (Operation and Maintenance) 1237 for more information. 1239 A router vendor will have many choices on power, 1240 complexity, and features for a particular router product. 1241 It may be helpful to observe that the Internet system is 1242 neither homogeneous nor fully-connected. For reasons of 1243 technology and geography it is growing into a global 1244 interconnect system plus a "fringe" of LANs around the 1245 "edge". More and more these fringe LANs are becoming richly 1246 interconnected, thus making them less out on the fringe and 1247 more demanding on router requirements. 1249 + The global interconnect system is comprised of a number 1250 of wide-area networks to which are attached routers of 1251 several Autonomous Systems (AS); there are relatively 1252 few hosts connected directly to the system. 1254 + Most hosts are connected to LANs. Many organizations 1255 have clusters of LANs interconnected by local routers. 1256 Each such cluster is connected by routers at one or more 1257 points into the global interconnect system. If it is 1258 connected at only one point, a LAN is known as a "stub" 1259 network. 1261 Routers in the global interconnect system generally 1262 require: 1264 + Advanced Routing and Forwarding Algorithms 1266 These routers need routing algorithms which are highly 1267 dynamic and also offer type-of-service routing. 1268 Congestion is still not a completely resolved issue (see 1269 Section [5.3.6]). Improvements in these areas are 1270 expected, as the research community is actively working 1271 on these issues. 1273 + High Availability 1275 These routers need to be highly reliable, providing 24 1276 hours a day, 7 days a week service. Equipment and 1277 software faults can have a wide-spread (sometimes 1278 global) effect. In case of failure, they must recover 1279 quickly. In any environment, a router must be highly 1280 robust and able to operate, possibly in a degraded 1281 state, under conditions of extreme congestion or failure 1282 of network resources. 1284 + Advanced O&M Features 1286 Internet routers normally operate in an unattended mode. 1287 They will typically be operated remotely from a 1288 centralized monitoring center. They need to provide 1289 sophisticated means for monitoring and measuring traffic 1290 and other events and for diagnosing faults. 1292 + High Performance 1294 Long-haul lines in the Internet today are most 1295 frequently 56 Kbps, DS1 (1.4Mbps), and DS3 (45Mbps) 1296 speeds. LANs are typically Ethernet (10Mbps) and, to a 1297 lesser degree, FDDI (100Mbps). However, network media 1298 technology is constantly advancing and even higher 1299 speeds are likely in the future. Full-duplex operation 1300 is provided at all of these speeds. 1302 The requirements for routers used in the LAN fringe (e.g., 1303 campus networks) depend greatly on the demands of the local 1304 networks. These may be high or medium-performance devices, 1305 probably competitively procured from several different 1306 vendors and operated by an internal organization (e.g., a 1307 campus computing center). The design of these routers 1308 should emphasize low average latency and good burst 1309 performance, together with delay and type-of-service 1310 sensitive resource management. In this environment there 1311 may be less formal O&M but it will not be less important. 1312 The need for the routing mechanism to be highly dynamic 1313 will become more important as networks become more complex 1314 and interconnected. Users will demand more out of their 1315 local connections because of the speed of the global 1316 interconnects. 1318 As networks have grown, and as more networks have become 1319 old enough that they are phasing out older equipment, it 1320 has become increasingly imperative that routers 1321 interoperate with routers from other vendors. 1323 Even though the Internet system is not fully 1324 interconnected, many parts of the system need to have 1325 redundant connectivity. Rich connectivity allows reliable 1326 service despite failures of communication lines and 1327 routers, and it can also improve service by shortening 1328 Internet paths and by providing additional capacity. 1329 Unfortunately, this richer topology can make it much more 1330 difficult to choose the best path to a particular 1331 destination. 1333 2.4 Architectural Assumptions 1335 The current Internet architecture is based on a set of 1336 assumptions about the communication system. The 1337 assumptions most relevant to routers are as follows: 1339 + The Internet is a network of networks. 1341 Each host is directly connected to some particular 1342 network(s); its connection to the Internet is only 1343 conceptual. Two hosts on the same network communicate 1344 with each other using the same set of protocols that 1345 they would use to communicate with hosts on distant 1346 networks. 1348 + Routers don't keep connection state information. 1350 To improve the robustness of the communication system, 1351 routers are designed to be stateless, forwarding each IP 1352 packet independently of other packets. As a result, 1353 redundant paths can be exploited to provide robust 1354 service in spite of failures of intervening routers and 1355 networks. 1357 All state information required for end-to-end flow 1358 control and reliability is implemented in the hosts, in 1359 the transport layer or in application programs. All 1360 connection control information is thus co-located with 1361 the end points of the communication, so it will be lost 1362 only if an end point fails. Routers effect flow control 1363 only indirectly, by dropping packets or increasing 1364 network delay. 1366 Note that future protocol developments may well end up 1367 putting some more state into routers. This is 1368 especially likely for resource reservation and flows. 1370 + Routing complexity should be in the routers. 1372 Routing is a complex and difficult problem, and ought to 1373 be performed by the routers, not the hosts. An 1374 important objective is to insulate host software from 1375 changes caused by the inevitable evolution of the 1376 Internet routing architecture. 1378 + The system must tolerate wide network variation. 1380 A basic objective of the Internet design is to tolerate 1381 a wide range of network characteristics -- e.g., 1382 bandwidth, delay, packet loss, packet reordering, and 1383 maximum packet size. Another objective is robustness 1384 against failure of individual networks, routers, and 1385 hosts, using whatever bandwidth is still available. 1386 Finally, the goal is full "open system interconnection": 1387 an Internet router must be able to interoperate robustly 1388 and effectively with any other router or Internet host, 1389 across diverse Internet paths. 1391 Sometimes implementors have designed for less ambitious 1392 goals. For example, the LAN environment is typically 1393 much more benign than the Internet as a whole; LANs have 1394 low packet loss and delay and do not reorder packets. 1395 Some vendors have fielded implementations that are 1396 adequate for a simple LAN environment, but work badly 1397 for general interoperation. The vendor justifies such a 1398 product as being economical within the restricted LAN 1399 market. However, isolated LANs seldom stay isolated for 1400 long; they are soon connected to each other, to 1401 organization-wide internets, and eventually to the 1402 global Internet system. In the end, neither the 1403 customer nor the vendor is served by incomplete or 1404 substandard routers. 1406 The requirements spelled out in this document are 1407 designed for a full-function router. It is intended 1408 that fully compliant routers will be usable in almost 1409 any part of the Internet. 1411 3. LINK LAYER 1413 Although [INTRO:1] covers Link Layer standards (IP over foo, 1414 ARP, etc.), this document anticipates that Link-Layer material 1415 will be covered in a separate Link Layer Requirements 1416 document. A Link-Layer requirements document would be 1417 applicable to both hosts and routers. Thus, this document 1418 will not obsolete the parts of [INTRO:1] that deal with link- 1419 layer issues. 1421 3.1 INTRODUCTION 1423 Routers have essentially the same Link Layer protocol 1424 requirements as other sorts of Internet systems. These 1425 requirements are given in chapter 3 of "Requirements for 1426 Internet Gateways" [INTRO:1]. A router MUST comply with 1427 its requirements and SHOULD comply with its 1428 recommendations. Since some of the material in that 1429 document has become somewhat dated, some additional 1430 requirements and explanations are included below. 1432 DISCUSSION: 1433 It is expected that the Internet community will produce 1434 a "Requirements for Internet Link Layer" standard which 1435 will supersede both this chapter and chapter 3 of 1436 [INTRO:1]. 1438 3.2 LINK/INTERNET LAYER INTERFACE 1440 Although this document does not attempt to specify the 1441 interface between the Link Layer and the upper layers, it 1442 is worth noting here that other parts of this document, 1443 particularly chapter 5, require various sorts of 1444 information to be passed across this layer boundary. 1446 This section uses the following definitions: 1448 + Source physical address 1450 The source physical address is the Link Layer address of 1451 the host or router from which the packet was received. 1453 + Destination physical address 1455 The destination physical address is the Link Layer 1456 address to which the packet was sent. 1458 The information that must pass from the Link Layer to the 1459 Internetwork Layer for each received packet is: 1461 (1) The IP packet [5.2.2], 1463 (2) The length of the data portion (i.e., not including 1464 the Link-Layer framing) of the Link Layer frame 1465 [5.2.2], 1467 (3) The identity of the physical interface from which the 1468 IP packet was received [5.2.3], and 1470 (4) The classification of the packet's destination 1471 physical address as a Link Layer unicast, broadcast, 1472 or multicast [4.3.2], [5.3.4]. 1474 In addition, the Link Layer also should provide: 1476 (5) The source physical address. 1478 The information that must pass from the Internetwork Layer 1479 to the Link Layer for each transmitted packet is: 1481 (1) The IP packet [5.2.1] 1483 (2) The length of the IP packet [5.2.1] 1485 (3) The destination physical interface [5.2.1] 1487 (4) The next hop IP address [5.2.1] 1489 In addition, the Internetwork Layer also should provide: 1491 (5) The Link Layer priority value [5.3.3.2] 1493 The Link Layer must also notify the Internetwork Layer if 1494 the packet to be transmitted causes a Link Layer 1495 precedence-related error [5.3.3.3]. 1497 3.3 SPECIFIC ISSUES 1499 3.3.1 Trailer Encapsulation 1501 Routers which can connect to 10Mb Ethernets MAY be able 1502 to receive and forward Ethernet packets encapsulated 1503 using the trailer encapsulation described in [LINK:1]. 1504 However, a router SHOULD NOT originate trailer 1505 encapsulated packets. A router MUST NOT originate 1506 trailer encapsulated packets without first verifying, 1507 using the mechanism described in section 2.3.1 of 1508 [INTRO:2], that the immediate destination of the packet 1509 is willing and able to accept trailer-encapsulated 1510 packets. A router SHOULD NOT agree (using these same 1511 mechanisms) to accept trailer-encapsulated packets. 1513 3.3.2 Address Resolution Protocol -- ARP 1515 Routers which implement ARP MUST be compliant and SHOULD 1516 be unconditionally compliant with the requirements in 1517 section 2.3.2 of [INTRO:2]. 1519 The link layer MUST NOT report a Destination Unreachable 1520 error to IP solely because there is no ARP cache entry 1521 for a destination. 1523 A router MUST not believe any ARP reply which claims 1524 that the Link Layer address of another host or router is 1525 a broadcast or multicast address. 1527 3.3.3 Ethernet and 802.3 Coexistence 1529 Routers which can connect to 10Mb Ethernets MUST be 1530 compliant and SHOULD be unconditionally compliant with 1531 the requirements of Section [2.3.3] of [INTRO:2]. 1533 3.3.4 Maximum Transmission Unit -- MTU 1535 The MTU of each logical interface MUST be configurable. 1537 Many Link Layer protocols define a maximum frame size 1538 that may be sent. In such cases, a router MUST NOT 1539 allow an MTU to be set which would allow sending of 1540 frames larger than those allowed by the Link Layer 1541 protocol. However, a router SHOULD be willing to 1542 receive a packet as large as the maximum frame size even 1543 if that is larger than the MTU. 1545 DISCUSSION: 1546 Note that this is a stricter requirement than imposed 1547 on hosts by [INTRO:2], which requires that the MTU of 1548 each physical interface be configurable. 1550 If a network is using an MTU smaller than the maximum 1551 frame size for the Link Layer, a router may receive 1552 packets larger than the MTU from hosts which are in 1553 the process of initializing themselves, or which have 1554 been misconfigured. 1556 In general, the Robustness Principle indicates that 1557 these packets should be successfully received, if at 1558 all possible. 1560 3.3.5 Point-to-Point Protocol -- PPP 1562 Contrary to [INTRO:1], the Internet does have a standard 1563 serial line protocol: the Point-to-Point Protocol (PPP), 1564 defined in [LINK:2], [LINK:3], [LINK:4], and [LINK:5]. 1566 A "serial line interface" is any interface which is 1567 designed to send data over a telephone, leased, 1568 dedicated or direct line (either 2 or 4 wire) using a 1569 standardized modem or bit serial interface (such as 1570 RS-232, RS-449 or V.35), using either synchronous or 1571 asynchronous clocking. 1573 A "general purpose serial interface" is a serial line 1574 interface which is not solely for use as an access line 1575 to a network for which an alternative IP link layer 1576 specification exists (such as X.25 or Frame Relay). 1578 Routers which contain such general purpose serial 1579 interfaces MUST implement PPP. 1581 PPP MUST be supported on all general purpose serial 1582 interfaces on a router. The router MAY allow the line 1583 to be configured to use serial line protocols other than 1584 PPP, all general purpose serial interfaces MUST default 1585 to using PPP. 1587 3.3.5.1 Introduction 1589 This section provides guidelines to router 1590 implementors so that they can ensure interoperability 1591 with other routers using PPP over either synchronous 1592 or asynchronous links. 1594 It is critical that an implementor understand the 1595 semantics of the option negotiation mechanism. 1596 Options are a means for a local device to indicate to 1597 a remote peer what the local device will *accept* 1598 from the remote peer, not what it wishes to send. It 1599 is up to the remote peer to decide what is most 1600 convenient to send within the confines of the set of 1601 options that the local device has stated that it can 1602 accept. Therefore it is perfectly acceptable and 1603 normal for a remote peer to ACK all the options 1604 indicated in an LCP Configuration Request (CR) even 1605 if the remote peer does not support any of those 1606 options. Again, the options are simply a mechanism 1607 for either device to indicate to its peer what it 1608 will accept, not necessarily what it will send. 1610 3.3.5.2 Link Control Protocol (LCP) Options 1612 The PPP Link Control Protocol (LCP) offers a number 1613 of options that may be negotiated. These options 1614 include (among others) address and control field 1615 compression, protocol field compression, asynchronous 1616 character map, Maximum Receive Unit (MRU), Link 1617 Quality Monitoring (LQM), magic number (for loopback 1618 detection), Password Authentication Protocol (PAP), 1619 Challenge Handshake Authentication Protocol (CHAP), 1620 and the 32-bit Frame Check Sequence (FCS). 1622 A router MAY do address/control field compression on 1623 either synchronous or asynchronous links. A router 1624 MAY do protocol field compression on either 1625 synchronous or asynchronous links. A router MAY 1626 indicate that it can accept these compressions, but 1627 MUST be able to accept uncompressed PPP header 1628 information even if it has indicated a willingness to 1629 receive compressed PPP headers. 1631 DISCUSSION: 1632 These options control the appearance of the PPP 1633 header. Normally the PPP header consists of the 1634 address field (one byte containing the value 1635 0xff), the control field (one byte containing the 1636 value 0x03), and the two-byte protocol field that 1637 identifies the contents of the data area of the 1638 frame. If a system negotiates address and control 1639 field compression it indicates to its peer that it 1640 will accept PPP frames that have or do not have 1641 these fields at the front of the header. It does 1642 not indicate that it will be sending frames with 1643 these fields removed. The protocol field may also 1644 be compressed from two to one byte in most cases. 1646 IMPLEMENTATION: 1647 Some hardware does not deal well with variable 1648 length header information. In those cases it 1649 makes most sense for the remote peer to send the 1650 full PPP header. Implementations may ensure this 1651 by not sending the address/control field and 1652 protocol field compression options to the remote 1653 peer. Even if the remote peer has indicated an 1654 ability to receive compressed headers there is no 1655 requirement for the local router to send 1656 compressed headers. 1658 A router MUST negotiate the Async Control Character 1659 Map (ACCM) for asynchronous PPP links, but SHOULD NOT 1660 negotiate the ACCM for synchronous links. If a 1661 router receives an attempt to negotiate the ACCM over 1662 a synchronous link, it MUST ACKnowledge the option 1663 and then ignore it. 1665 DISCUSSION: 1666 There are implementations that offer both sync and 1667 async modes of operation and may use the same code 1668 to implement the option negotiation. In this 1669 situation it is possible that one end or the other 1670 may send the ACCM option on a synchronous link. 1672 A router SHOULD properly negotiate the maximum 1673 receive unit (MRU). Even if a system negotiates an 1674 MRU smaller than 1,500 bytes, it MUST be able to 1675 receive a 1,500 byte frame. 1677 A router SHOULD negotiate and enable the link quality 1678 monitoring (LQM) option. 1680 DISCUSSION: 1681 This memo does not specify a policy for deciding 1682 whether the link's quality is adequate. However, 1683 it is important (see Section [3.3.6]) that a 1684 router disable failed links. 1686 A router SHOULD implement and negotiate the magic 1687 number option for loopback detection. 1689 A router MAY support the authentication options (PAP 1690 - password authentication protocol, and/or CHAP - 1691 challenge handshake authentication protocol). 1693 A router MUST support 16-bit CRC frame check sequence 1694 (FCS) and MAY support the 32-bit CRC. 1696 3.3.5.3 IP Control Protocol (ICP) Options 1698 A router MAY offer to perform IP address negotiation. 1699 A router MUST accept a refusal (REJect) to perform IP 1700 address negotiation from the peer. 1702 A router SHOULD NOT perform Van Jacobson header 1703 compression of TCP/IP packets if the link speed is in 1704 excess of 64 Kbps. Below that speed the router MAY 1705 perform Van Jacobson (VJ) header compression. At 1706 link speeds of 19,200 bps or less the router SHOULD 1707 perform VJ header compression. 1709 3.3.6 Interface Testing 1711 A router MUST have a mechanism to allow routing software 1712 to determine whether a physical interface is available 1713 to send packets or not. A router SHOULD have a 1714 mechanism to allow routing software to judge the quality 1715 of a physical interface. A router MUST have a mechanism 1716 for informing the routing software when a physical 1717 interface becomes available or unavailable to send 1718 packets because of administrative action. A router MUST 1719 have a mechanism for informing the routing software when 1720 it detects a Link level interface has become available 1721 or unavailable, for any reason. 1723 DISCUSSION: 1724 It is crucial that routers have workable mechanisms 1725 for determining that their network connections are 1726 functioning properly, since failure to do so (or 1727 failure to take the proper actions when a problem is 1728 detected) can lead to black holes. 1730 The mechanisms available for detecting problems with 1731 network connections vary considerably, depending on 1732 the Link Layer protocols in use and also in some 1733 cases on the interface hardware chosen by the router 1734 manufacturer. The intent is to maximize the 1735 capability to detect failures within the Link-Layer 1736 constraints. 1738 4. INTERNET LAYER -- PROTOCOLS 1740 4.1 INTRODUCTION 1742 This chapter and chapter 5 discuss the protocols used at 1743 the Internet Layer: IP, ICMP, and IGMP. Since forwarding 1744 is obviously a crucial topic in a document discussing 1745 routers, chapter 5 limits itself to the aspects of the 1746 protocols which directly relate to forwarding. The current 1747 chapter contains the remainder of the discussion of the 1748 Internet Layer protocols. 1750 4.2 INTERNET PROTOCOL -- IP 1752 4.2.1 INTRODUCTION 1754 Routers MUST implement the IP protocol, as defined by 1755 [INTERNET:1]. They MUST also implement its mandatory 1756 extensions: subnets (defined in [INTERNET:2]), and IP 1757 broadcast (defined in [INTERNET:3]). 1759 A router MUST be compliant, and SHOULD be 1760 unconditionally compliant, with the requirements of 1761 sections 3.2.1 and 3.3 of [INTRO:2], except that: 1763 + Section 3.2.1.1 may be ignored, since it duplicates 1764 requirements found in this memo. 1766 + Section 3.2.1.2 may be ignored, since it duplicates 1767 requirements found in this memo. 1769 + Section 3.2.1.3 should be ignored, since it is 1770 superseded by Section [4.2.2.11] of this memo. 1772 + Section 3.2.1.4 may be ignored, since it duplicates 1773 requirements found in this memo. 1775 + Section 3.2.1.6 should be ignored, since it is 1776 superseded by Section [4.2.2.4] of this memo. 1778 + Section 3.2.1.8 should be ignored, since it is 1779 superseded by Section [4.2.2.1] of this memo. 1781 In the following, the action specified in certain cases 1782 is to "silently discard" a received datagram. This 1783 means that the datagram will be discarded without 1784 further processing and that the router will not send any 1785 ICMP error message (see Section [4.3]) as a result. 1786 However, for diagnosis of problems a router SHOULD 1787 provide the capability of logging the error (see Section 1788 [1.3.3]), including the contents of the silently- 1789 discarded datagram, and SHOULD record the event in a 1790 statistics counter. 1792 4.2.2 PROTOCOL WALK-THROUGH 1794 RFC 791 is [INTERNET:1], the specification for the 1795 Internet Protocol. 1797 4.2.2.1 Options: RFC-791 Section 3.2 1799 In datagrams received by the router itself, the IP 1800 layer MUST interpret those IP options that it 1801 understands and preserve the rest unchanged for use 1802 by higher layer protocols. 1804 Higher layer protocols may require the ability to set 1805 IP options in datagrams they send or examine IP 1806 options in datagrams they receive. Later sections of 1807 this document discuss specific IP option support 1808 required by higher layer protocols. 1810 DISCUSSION: 1811 Neither this memo nor [INTRO:2] define the order 1812 in which a receiver must process multiple options 1813 in the same IP header. Hosts and routers 1814 originating datagrams containing multiple options 1815 must be aware that this introduces an ambiguity in 1816 the meaning of certain options when combined with 1817 a source-route option. 1819 Here are the requirements for specific IP options: 1821 (a) Security Option 1823 Some environments require the Security option in 1824 every packet originated or received. Routers 1825 SHOULD IMPLEMENT the revised security option 1826 described in [INTERNET:5]. 1828 DISCUSSION: 1829 Note that the security options described in 1830 [INTERNET:1] and RFC 1038 ([INTERNET:16]) are 1831 obsolete. 1833 (b) Stream Identifier Option 1835 This option is obsolete; routers SHOULD NOT 1836 place this option in a datagram that the router 1837 originates. This option MUST be ignored in 1838 datagrams received by the router. 1840 (c) Source Route Options 1842 A router MUST be able to act as the final 1843 destination of a source route. If a router 1844 receives a packet containing a completed source 1845 route (i.e., the pointer points beyond the last 1846 field and the destination address in the IP 1847 header addresses the router), the packet has 1848 reached its final destination; the option as 1849 received (the recorded route) MUST be passed up 1850 to the transport layer (or to ICMP message 1851 processing). 1853 In order to respond correctly to source-routed 1854 datagrams it receives, a router MUST provide a 1855 means whereby transport protocols and 1856 applications can reverse the source route in a 1857 received datagram and insert the reversed source 1858 route into datagrams they originate (see Section 1859 4 of [INTRO:2] for details). 1861 Some applications in the router MAY require that 1862 the user be able to enter a source route. 1864 A router MUST NOT originate a datagram 1865 containing multiple source route options. What 1866 a router should do if asked to forward a packet 1867 containing multiple source route options is 1868 described in Section [5.2.4.1]. 1870 When a source route option is created, it MUST 1871 be correctly formed even if it is being created 1872 by reversing a recorded route that erroneously 1873 includes the source host (see case (B) in the 1874 discussion below). 1876 DISCUSSION: 1877 Suppose a source routed datagram is to be 1878 routed from source S to destination D via 1879 routers G1, G2, ... Gn. Source S constructs 1880 a datagram with G1's IP address as its 1881 destination address, and a source route 1882 option to get the datagram the rest of the 1883 way to its destination. However, there is an 1884 ambiguity in the specification over whether 1885 the source route option in a datagram sent 1886 out by S should be (A) or (B): 1888 (A): {>>G2, G3, ... Gn, D} <--- CORRECT 1890 (B): {S, >>G2, G3, ... Gn, D} <---- WRONG 1892 (where >> represents the pointer). If (A) is 1893 sent, the datagram received at D will contain 1894 the option: {G1, G2, ... Gn >>}, with S and D 1895 as the IP source and destination addresses. 1896 If (B) were sent, the datagram received at D 1897 would again contain S and D as the same IP 1898 source and destination addresses, but the 1899 option would be: {S, G1, ...Gn >>}; i.e., the 1900 originating host would be the first hop in 1901 the route. 1903 (d) Record Route Option 1905 Routers MAY support the Record Route option in 1906 datagrams originated by the router. 1908 (e) Timestamp Option 1909 Routers MAY support the timestamp option in 1910 datagrams originated by the router. The 1911 following rules apply: 1913 + When originating a datagram containing a 1914 Timestamp Option, a router MUST record a 1915 timestamp in the option if 1917 -- Its Internet address fields are not pre- 1918 specified or 1919 -- Its first pre-specified address is the IP 1920 address of the logical interface over 1921 which the datagram is being sent (or the 1922 router's router-id if the datagram is 1923 being sent over an unnumbered interface). 1925 + If the router itself receives a datagram 1926 containing a Timestamp Option, the router 1927 MUST insert the current timestamp into the 1928 Timestamp Option (if there is space in the 1929 option to do so) before passing the option to 1930 the transport layer or to ICMP for 1931 processing. 1933 + A timestamp value MUST follow the rules given 1934 in Section [3.2.2.8] of [INTRO:2]. 1936 IMPLEMENTATION: 1937 To maximize the utility of the timestamps 1938 contained in the timestamp option, it is 1939 suggested that the timestamp inserted be, as 1940 nearly as practical, the time at which the 1941 packet arrived at the router. For datagrams 1942 originated by the router, the timestamp 1943 inserted should be, as nearly as practical, 1944 the time at which the datagram was passed to 1945 the Link Layer for transmission. 1947 4.2.2.2 Addresses in Options: RFC-791 Section 3.1 1949 When a router inserts its address into a Record 1950 Route, Strict Source and Record Route, Loose Source 1951 and Record Route, or Timestamp, it MUST use the IP 1952 address of the logical interface on which the packet 1953 is being sent. Where this rule cannot be obeyed 1954 because the output interface has no IP address (i.e., 1955 is an unnumbered interface), the router MUST instead 1956 insert its "router-id". The router's router-id is 1957 one of the router's IP addresses. Which of the 1958 router's addresses is used as the router-id MUST NOT 1959 change (even across reboots) unless changed by the 1960 network manager or unless the configuration of the 1961 router is changed such that the IP address used as 1962 the router-id ceases to be one of the router's IP 1963 addresses. Routers with multiple unnumbered 1964 interfaces MAY have multiple router-id's. Each 1965 unnumbered interface MUST be associated with a 1966 particular router-id. This association MUST NOT 1967 change (even across reboots) without reconfiguration 1968 of the router. 1970 DISCUSSION: 1971 This specification does not allow for routers 1972 which do not have at least one IP address. We do 1973 not view this as a serious limitation, since a 1974 router needs an IP address to meet the 1975 manageability requirements of Chapter [8] even if 1976 the router is connected only to point-to-point 1977 links. 1979 IMPLEMENTATION: 1980 One possible method of choosing the router-id that 1981 fulfills this requirement is to use the 1982 numerically smallest (or greatest) IP address 1983 (treating the address as a 32-bit integer) that is 1984 assigned to the router. 1986 4.2.2.3 Unused IP Header Bits: RFC-791 Section 3.1 1988 The IP header contains two reserved bits: one in the 1989 Type of Service byte and the other in the Flags 1990 field. A router MUST NOT set either of these bits to 1991 one in datagrams originated by the router. A router 1992 MUST NOT drop (refuse to receive or forward) a packet 1993 merely because one or more of these reserved bits has 1994 a non-zero value. 1996 DISCUSSION: 1997 Future revisions to the IP protocol may make use 1998 of these unused bits. These rules are intended to 1999 ensure that these revisions can be deployed 2000 without having to simultaneously upgrade all 2001 routers in the Internet. 2003 4.2.2.4 Type of Service: RFC-791 Section 3.1 2005 The "Type-of-Service" byte in the IP header is 2006 divided into three sections: the Precedence field 2007 (high-order 3 bits), a field that is customarily 2008 called "Type of Service" or "TOS" (next 4 bits), and 2009 a reserved bit (the low order bit). 2011 Rules governing the reserved bit were described in 2012 Section [4.2.2.3]. 2014 A more extensive discussion of the TOS field and its 2015 use can be found in [ROUTE:11]. 2017 The description of the IP Precedence field is 2018 superseded by Section [5.3.3]. RFC-795, "Service 2019 Mappings", is obsolete and SHOULD NOT be implemented. 2021 4.2.2.5 Header Checksum: RFC-791 Section 3.1 2023 As stated in Section [5.2.2], a router MUST verify 2024 the IP checksum of any packet which is received. The 2025 router MUST NOT provide a means to disable this 2026 checksum verification. 2028 IMPLEMENTATION: 2029 A more extensive description of the IP checksum, 2030 including extensive implementation hints, can be 2031 found in [INTERNET:6] and [INTERNET:7]. 2033 4.2.2.6 Unrecognized Header Options: RFC-791 Section 3.1 2035 A router MUST ignore IP options which it does not 2036 recognize. A corollary of this requirement is that a 2037 router MUST implement the End of Option List option 2038 and the No Operation option, since neither contains 2039 an explicit length. 2041 DISCUSSION: 2042 All future IP options will include an explicit 2043 length. 2045 4.2.2.7 Fragmentation: RFC-791 Section 3.2 2047 Fragmentation, as described in [INTERNET:1], MUST be 2048 supported by a router. 2050 When a router fragments an IP datagram, it SHOULD 2051 minimize the number of fragments. When a router 2052 fragments an IP datagram, it MUST send the fragments 2053 in order. A fragmentation method which may generate 2054 one IP fragment which is significantly smaller than 2055 the other MAY cause the first IP fragment to be the 2056 smaller one. 2058 DISCUSSION: 2059 There are several fragmentation techniques in 2060 common use in the Internet. One involves 2061 splitting the IP datagram into IP fragments with 2062 the first being MTU sized, and the others being 2063 approximately the same size, smaller than the MTU. 2064 The reason for this is twofold. The first IP 2065 fragment in the sequence will be the effective MTU 2066 of the current path between the hosts, and the 2067 following IP fragments are sized to hopefully 2068 minimize the further fragmentation of the IP 2069 datagram. Another technique is to split the IP 2070 datagram into MTU sized IP fragments, with the 2071 last fragment being the only one smaller, as per 2072 page 26 of [INTERNET:1]. 2074 A common trick used by some implementations of 2075 TCP/IP is to fragment an IP datagram into IP 2076 fragments that are no larger than 576 bytes when 2077 the IP datagram is to travel through a router. In 2078 general, this allows the resulting IP fragments to 2079 pass the rest of the path without further 2080 fragmentation. This would, though, create more of 2081 a load on the destination host, since it would 2082 have a larger number of IP fragments to reassemble 2083 into one IP datagram. It would also not be 2084 efficient on networks where the MTU only changes 2085 once, and stays much larger than 576 bytes (such 2086 as an 802.5 network with a MTU of 2048 or an 2087 Ethernet network with an MTU of 1536). 2089 One other fragmentation technique discussed was 2090 splitting the IP datagram into approximately equal 2091 sized IP fragments, with the size being smaller 2092 than the next hop network's MTU. This is intended 2093 to minimize the number of fragments that would 2094 result from additional fragmentation further down 2095 the path. 2097 In most cases, routers should try and create 2098 situations that will generate the lowest number of 2099 IP fragments possible. 2101 Work with slow machines leads us to believe that 2102 if it is necessary to send small packets in a 2103 fragmentation scheme, sending the small IP 2104 fragment first maximizes the chance of a host with 2105 a slow interface of receiving all the fragments. 2107 4.2.2.8 Reassembly: RFC-791 Section 3.2 2109 As specified in Section 3.3.2 of [INTRO:2], a router 2110 MUST support reassembly of datagrams which it 2111 delivers to itself. 2113 4.2.2.9 Time to Live: RFC-791 Section 3.2 2115 Time to Live (TTL) handling for packets originated or 2116 received by the router is governed by [INTRO:2]. 2117 Note in particular that a router MUST NOT check the 2118 TTL of a packet except when forwarding it. 2120 4.2.2.10 Multi-subnet Broadcasts: RFC-922 2122 All-subnets broadcasts (called "multi-subnet 2123 broadcasts" in [INTERNET:3]) have been deprecated. 2124 See Section [5.3.5.3]. 2126 4.2.2.11 Addressing: RFC-791 Section 3.2 2128 There are now five classes of IP addresses: Class A 2129 through Class E. Class D addresses are used for IP 2130 multicasting [INTERNET:4], while Class E addresses 2131 are reserved for experimental use. 2133 A multicast (Class D) address is a 28-bit logical 2134 address that stands for a group of hosts, and may be 2135 either permanent or transient. Permanent multicast 2136 addresses are allocated by the Internet Assigned 2137 Number Authority [INTRO:7], while transient addresses 2138 may be allocated dynamically to transient groups. 2139 Group membership is determined dynamically using IGMP 2140 [INTERNET:4]. 2142 We now summarize the important special cases for 2143 Unicast (that is class A, B, and C) IP addresses, 2144 using the following notation for an IP address: 2146 { , } 2148 or 2150 { , , } 2152 and the notation "-1" for a field that contains all 1 2153 bits and the notation "0" for a field that contains 2154 all 0 bits. This notation is not intended to imply 2155 that the 1-bits in a subnet mask need be contiguous. 2157 (a) { 0, 0 } 2159 This host on this network. It MUST NOT be used 2160 as a source address by routers, except the 2161 router MAY use this as a source address as part 2162 of an initialization procedure (e.g., if the 2163 router is using BOOTP to load its configuration 2164 information). 2166 Incoming datagrams with a source address of { 0, 2167 0 } which are received for local delivery (see 2168 Section [5.2.3]), MUST be accepted if the router 2169 implements the associated protocol and that 2170 protocol clearly defines appropriate action to 2171 be taken. Otherwise, a router MUST silently 2172 discard any locally-delivered datagram whose 2173 source address is { 0, 0 }. 2175 DISCUSSION: 2176 Some protocols define specific actions to 2177 take in response to a received datagram whose 2178 source address is { 0, 0 }. Two examples are 2179 BOOTP and ICMP Mask Request. The proper 2180 operation of these protocols often depends on 2181 the ability to receive datagrams whose source 2182 address is { 0, 0 }. For most protocols, 2183 however, it is best to ignore datagrams 2184 having a source address of { 0, 0 } since 2185 they were probably generated by a 2186 misconfigured host or router. Thus, if a 2187 router knows how to deal with a given 2188 datagram having a { 0, 0 } source address, 2189 the router MUST accept it. Otherwise, the 2190 router MUST discard it. 2192 See also Section [4.2.3.1] for a non-standard 2193 use of { 0, 0 }. 2195 (b) { 0, } 2197 Specified host on this network. It MUST NOT be 2198 sent by routers except that the router MAY uses 2199 this as a source address as part of an 2200 initialization procedure by which the it learns 2201 its own IP address. 2203 (c) { -1, -1 } 2205 Limited broadcast. It MUST NOT be used as a 2206 source address. 2208 A datagram with this destination address will be 2209 received by every host and router on the 2210 connected physical network, but will not be 2211 forwarded outside that network. 2213 (d) { , -1 } 2215 Network Directed Broadcast -- a broadcast 2216 directed to the specified network. It MUST NOT 2217 be used as a source address. A router MAY 2218 originate Network Directed Broadcast packets. A 2219 router MUST receive Network Directed Broadcast 2220 packets; however a router MAY have a 2221 configuration option to prevent reception of 2222 these packets. Such an option MUST default to 2223 allowing reception. 2225 (e) { , , -1 } 2227 Subnetwork Directed Broadcast -- a broadcast 2228 sent to the specified subnet. It MUST NOT be 2229 used as a source address. A router MAY 2230 originate Network Directed Broadcast packets. A 2231 router MUST receive Network Directed Broadcast 2232 packets; however a router MAY have a 2233 configuration option to prevent reception of 2234 these packets. Such an option MUST default to 2235 allowing reception. 2237 (f) { , -1, -1 } 2239 All Subnets Directed Broadcast -- a broadcast 2240 sent to all subnets of the specified subnetted 2241 network. It MUST NOT be used as a source 2242 address. A router MAY originate Network 2243 Directed Broadcast packets. A router MUST 2244 receive Network Directed Broadcast packets; 2245 however a router MAY have a configuration option 2246 to prevent reception of these packets. Such an 2247 option MUST default to allowing reception. 2249 (g) { 127, } 2251 Internal host loopback address. Addresses of 2252 this form MUST NOT appear outside a host. 2254 The is administratively assigned so 2255 that its value will be unique in the entire world. 2257 IP addresses are not permitted to have the value 0 or 2258 -1 for any of the , , or 2259 fields (except in the special cases 2260 listed above). This implies that each of these 2261 fields will be at least two bits long. 2263 For further discussion of broadcast addresses, see 2264 Section [4.2.3.1]. 2266 Since (as described in Section [4.2.1]) a router must 2267 support the subnet extensions to IP, there will be a 2268 subnet mask of the form: { -1, -1, 0 } associated 2269 with each of the host's local IP addresses; see 2270 Sections [4.3.3.9], [5.2.4.2], and [10.2.2]. 2272 When a router originates any datagram, the IP source 2273 address MUST be one of its own IP addresses (but not 2274 a broadcast or multicast address). The only 2275 exception is during initialization. 2277 For most purposes, a datagram addressed to a 2278 broadcast or multicast destination is processed as if 2279 it had been addressed to one of the router's IP 2280 addresses; that is to say: 2282 + A router MUST receive and process normally any 2283 packets with a broadcast destination address. 2285 + A router MUST receive and process normally any 2286 packets sent to a multicast destination address 2287 which the router is interested in. 2289 The term "specific-destination address" means the 2290 equivalent local IP address of the host. The 2291 specific-destination address is defined to be the 2292 destination address in the IP header unless the 2293 header contains a broadcast or multicast address, in 2294 which case the specific-destination is an IP address 2295 assigned to the physical interface on which the 2296 datagram arrived. 2298 A router MUST silently discard any received datagram 2299 containing an IP source address that is invalid by 2300 the rules of this section. This validation could be 2301 done either by the IP layer or by each protocol in 2302 the transport layer. 2304 DISCUSSION: 2305 A misaddressed datagram might be caused by a Link 2306 Layer broadcast of a unicast datagram or by 2307 another router or host that is confused or 2308 misconfigured. 2310 4.2.3 SPECIFIC ISSUES 2312 4.2.3.1 IP Broadcast Addresses 2314 For historical reasons, there are a number of IP 2315 addresses (some standard and some not) which are used 2316 to indicate that an IP packet is an IP broadcast. A 2317 router 2319 (1) MUST treat as IP broadcasts packets addressed to 2320 255.255.255.255, { , -1 }, { 2321 , , -1 }, and { 2322 , -1, -1 }. 2324 (2) SHOULD silently discard on receipt (i.e., don't 2325 even deliver to applications in the router) any 2326 packet addressed to 0.0.0.0, { , 2327 0 }, { , , 0 }, 2328 or { , 0, 0 }; if these packets 2329 are not silently discarded, they MUST be treated 2330 as IP broadcasts (see Section [5.3.5]). There 2331 MAY be a configuration option to allow receipt 2332 of these packets. This option SHOULD default to 2333 discarding them. 2335 (3) SHOULD (by default) use the limited broadcast 2336 address (255.255.255.255) when originating an IP 2337 broadcast destined for a connected network or 2338 subnet (except when sending an ICMP Address Mask 2339 Reply, as discussed in Section [4.3.3.9]). A 2340 router MUST receive limited broadcasts. 2342 (4) SHOULD NOT originate datagrams addressed to 2343 0.0.0.0, { , 0 }, { , , 0 }, or { , 0, 0 }. There MAY be a configuration 2346 option to allow generation of these packets 2347 (instead of using the relevant "1s" format 2348 broadcast). This option SHOULD default to not 2349 generating them. 2351 DISCUSSION: 2352 In the second bullet, the router obviously cannot 2353 recognize addresses of the form { , , 0 } if the router does 2355 not know how the particular network is subnetted. 2356 In that case, the rules of the second bullet do 2357 not apply because, from the point of view of the 2358 router, the packet is not an IP broadcast packet. 2360 4.2.3.2 IP Multicasting 2362 An IP router SHOULD satisfy the Host Requirements 2363 with respect to IP multicasting, as specified in 2364 Section 3.3.7 of [INTRO:2]. An IP router SHOULD 2365 support local IP multicasting on all connected 2366 networks for which a mapping from Class D IP 2367 addresses to link-layer addresses has been specified 2368 (see the various IP-over-xxx specifications), and on 2369 all connected point-to-point links. Support for 2370 local IP multicasting includes originating multicast 2371 datagrams, joining multicast groups and receiving 2372 multicast datagrams, and leaving multicast groups. 2373 This implies support for all of [INTERNET:4] 2374 including IGMP (see Section [4.4]). 2376 DISCUSSION: 2377 Although [INTERNET:4] is entitled Host Extensions 2378 for IP Multicasting, it applies to all IP systems, 2379 both hosts and routers. In particular, since 2380 routers may join multicast groups, it is correct 2381 for them to perform the "host" part of IGMP, 2382 reporting their group memberships to any multicast 2383 routers that may be present on their attached 2384 networks (whether or not they themselves are 2385 multicast routers). 2387 Some router protocols may specifically require 2388 support for IP multicasting (e.g., OSPF 2389 [ROUTE:1]), or may recommend it (e.g., ICMP Router 2390 Discovery [INTERNET:13]). 2392 4.2.3.3 Path MTU Discovery 2394 In order to eliminate fragmentation or minimize it, 2395 it is desirable to know what is the path MTU along 2396 the path from the source to destination. The path 2397 MTU is the minimum of the MTUs of each hop in the 2398 path. [INTERNET:14] describes a technique for 2399 dynamically discovering the maximum transmission unit 2400 (MTU) of an arbitrary internet path. For a path that 2401 passes through a router that does not support 2402 [INTERNET:14], this technique might not discover the 2403 correct Path MTU, but it will always choose a Path 2404 MTU as accurate as, and in many cases more accurate 2405 than, the Path MTU that would be chosen by older 2406 techniques or the current practice. 2408 When a router is originating an IP datagram, it 2409 SHOULD use the scheme described in [INTERNET:14] to 2410 limit the datagram's size. If the router's route to 2411 the datagram's destination was learned from a routing 2412 protocol that provides Path MTU information, the 2413 scheme described in [INTERNET:14] is still used, but 2414 the Path MTU information from the routing protocol 2415 SHOULD be used as the initial guess as to the Path 2416 MTU and also as an upper bound on the Path MTU. 2418 4.2.3.4 Subnetting 2420 Under certain circumstances, it may be desirable to 2421 support subnets of a particular network being 2422 interconnected only via a path which is not part of 2423 the subnetted network. This is known as 2424 discontiguous subnetwork support. 2426 Routers MUST support discontiguous subnetworks. 2428 IMPLEMENTATION: 2429 In general, a router should not make assumptions 2430 about what are subnets and what are not, but 2431 simply ignore the concept of Class in networks, 2432 and treat each route as a { network, mask }-tuple. 2434 DISCUSSION: 2435 The Internet has been growing at a tremendous rate 2436 of late. This has been placing severe strains on 2437 the IP addressing technology. A major factor in 2438 this strain is the strict IP Address class 2439 boundaries. These make it difficult to 2440 efficiently size network numbers to their networks 2441 and aggregate several network numbers into a 2442 single route advertisement. By eliminating the 2443 strict class boundaries of the IP address and 2444 treating each route as a {network number, 2445 mask}-tuple these strains may be greatly reduced. 2447 The technology for currently doing this is 2448 Classless Interdomain Routing (CIDR) 2449 [INTERNET:15]. 2451 Furthermore, for similar reasons, a subnetted network 2452 need not have a consistent subnet mask through all 2453 parts of the network. For example, one subnet may 2454 use an 8 bit subnet mask, another 10 bit, and another 2455 6 bit. This is known as variable subnet-masks. 2457 Routers MUST support variable subnet-masks. 2459 4.3 INTERNET CONTROL MESSAGE PROTOCOL -- ICMP 2461 4.3.1 INTRODUCTION 2463 ICMP is an auxiliary protocol, which provides routing, 2464 diagnostic and and error functionality for IP. It is 2465 described in [INTERNET:8]. A router MUST support ICMP. 2467 ICMP messages are grouped in two classes which are 2468 discussed in the following sections: 2470 ICMP error messages: 2472 Destination Unreachable Section 4.3.3.1 2473 Redirect Section 4.3.3.2 2474 Source Quench Section 4.3.3.3 2475 Time Exceeded Section 4.3.3.4 2476 Parameter Problem Section 4.3.3.5 2478 ICMP query messages: 2479 Echo Section 4.3.3.6 2480 Information Section 4.3.3.7 2481 Timestamp Section 4.3.3.8 2482 Address Mask Section 4.3.3.9 2483 Router Discovery Section 4.3.3.10 2485 General ICMP requirements and discussion are in the next 2486 section. 2488 4.3.2 GENERAL ISSUES 2489 4.3.2.1 Unknown Message Types 2491 If an ICMP message of unknown type is received, it 2492 MUST be passed to the ICMP user interface (if the 2493 router has one) or silently discarded (if the router 2494 doesn't have one). 2496 4.3.2.2 ICMP Message TTL 2498 When originating an ICMP message, the router MUST 2499 initialize the TTL. The TTL for ICMP responses must 2500 not be taken from the packet which triggered the 2501 response. 2503 4.3.2.3 Original Message Header 2505 Every ICMP error message includes the Internet header 2506 and at least the first 8 data bytes of the datagram 2507 that triggered the error. More than 8 bytes MAY be 2508 sent, but the resulting ICMP datagram SHOULD have a 2509 length of less than or equal to 576 bytes. The 2510 returned IP header (and user data) MUST be identical 2511 to that which was received, except that the router is 2512 not required to undo any modifications to the IP 2513 header that are normally performed in forwarding that 2514 were performed before the error was detected (e.g., 2515 decrementing the TTL, updating options). Note that 2516 the requirements of Section [4.3.3.5] supersede this 2517 requirement in some cases (i.e., for a Parameter 2518 Problem message, if the problem is in a modified 2519 field, the router must "undo" the modification). See 2520 Section [4.3.3.5]) 2522 4.3.2.4 ICMP Message Source Address 2524 Except where this document specifies otherwise, the 2525 IP source address in an ICMP message originated by 2526 the router MUST be one of the IP addresses associated 2527 with the physical interface over which the ICMP 2528 message is transmitted. If the interface has no IP 2529 addresses associated with it, the router's router-id 2530 (see Section [5.2.5]) is used instead. 2532 4.3.2.5 TOS and Precedence 2534 ICMP error messages SHOULD have their TOS bits set to 2535 the same value as the TOS bits in the packet which 2536 provoked the sending of the ICMP error message, 2537 unless setting them to that value would cause the 2538 ICMP error message to be immediately discarded 2539 because it could not be routed to its destination. 2540 Otherwise, ICMP error messages MUST be sent with a 2541 normal (i.e. zero) TOS. An ICMP reply message SHOULD 2542 have its TOS bits set to the same value as the TOS 2543 bits in the ICMP request that provoked the reply. 2545 EDITOR'S COMMENTS: 2546 The following paragraph originally read: 2548 ICMP error messages MUST have their IP 2549 Precedence field set to the same value as the 2550 IP Precedence field in the packet which 2551 provoked the sending of the ICMP error message, 2552 except that the precedence value MUST be 6 2553 (INTERNETWORK CONTROL) or 7 (NETWORK CONTROL), 2554 SHOULD be 7, and MAY be settable for the 2555 following types of ICMP error messages: 2556 Unreachable, Redirect, Time Exceeded, and 2557 Parameter Problem. 2559 I believe that the following paragraph is 2560 equivalent and easier for humans to parse (Source 2561 Quench is the only other ICMP Error message). 2562 Other interpretations of the original are sought. 2564 ICMP Source Quench error messages MUST have their IP 2565 Precedence field set to the same value as the IP 2566 Precedence field in the packet which provoked the 2567 sending of the ICMP Source Quench message. All other 2568 ICMP error messages (Destination Unreachable, 2569 Redirect, Time Exceeded, and Parameter Problem) MUST 2570 have their precedence value set to 6 (INTERNETWORK 2571 CONTROL) or 7 (NETWORK CONTROL), SHOULD be 7. The IP 2572 Precedence value for these error messages MAY be 2573 settable. 2575 An ICMP reply message MUST have its IP Precedence 2576 field set to the same value as the IP Precedence 2577 field in the ICMP request that provoked the reply. 2579 4.3.2.6 Source Route 2581 If the packet which provokes the sending of an ICMP 2582 error message contains a source route option, the 2583 ICMP error message SHOULD also contain a source route 2584 option of the same type (strict or loose), created by 2585 reversing the portion before the pointer of the route 2586 recorded in the source route option of the original 2587 packet UNLESS the ICMP error message is an ICMP 2588 Parameter Problem complaining about a source route 2589 option in the original packet. 2591 DISCUSSION: 2592 In environments which use the U.S. Department of 2593 Defense security option (defined in [INTERNET:5]), 2594 ICMP messages may need to include a security 2595 option. Detailed information on this topic should 2596 be available from the Defense Communications 2597 Agency. 2599 4.3.2.7 When Not to Send ICMP Errors 2601 An ICMP error message MUST NOT be sent as the result 2602 of receiving: 2604 + An ICMP error message, or 2606 + A packet which fails the IP header validation 2607 tests described in Section [5.2.2] (except where 2608 that section specifically permits the sending of 2609 an ICMP error message), or 2611 + A packet destined to an IP broadcast or IP 2612 multicast address, or 2614 + A packet sent as a Link Layer broadcast or 2615 multicast, or 2617 + A packet whose source address has a network number 2618 of zero or is an invalid source address (as 2619 defined in Section [5.3.7]), or 2621 + Any fragment of a datagram other then the first 2622 fragment (i.e., a packet for which the fragment 2623 offset in the IP header is nonzero). 2625 Furthermore, an ICMP error message MUST NOT be sent 2626 in any case where this memo states that a packet is 2627 to be "silently discarded". 2629 NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY 2630 REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR SENDING 2631 ICMP ERROR MESSAGES. 2633 DISCUSSION: 2634 These rules aim to prevent the "broadcast storms" 2635 that have resulted from routers or hosts returning 2636 ICMP error messages in response to broadcast 2637 packets. For example, a broadcast UDP packet to a 2638 non-existent port could trigger a flood of ICMP 2639 Destination Unreachable datagrams from all devices 2640 that do not have a client for that destination 2641 port. On a large Ethernet, the resulting 2642 collisions can render the network useless for a 2643 second or more. 2645 Every packet that is broadcast on the connected 2646 network should have a valid IP broadcast address 2647 as its IP destination (see Section [5.3.4] and 2648 [INTRO:2]). However, some devices violate this 2649 rule. To be certain to detect broadcast packets, 2650 therefore, routers are required to check for a 2651 link-layer broadcast as well as an IP-layer 2652 address. 2654 IMPLEMENTATION: 2655 This requires that the link layer inform the IP 2656 layer when a link-layer broadcast packet has been 2657 received; see Section [3.1]. 2659 4.3.2.8 Rate Limiting 2661 A router which sends ICMP Source Quench messages MUST 2662 be able to limit the rate at which the messages can 2663 be generated. A router SHOULD also be able to limit 2664 the rate at which it sends other sorts of ICMP error 2665 messages (Destination Unreachable, Redirect, Time 2666 Exceeded, Parameter Problem). The rate limit 2667 parameters SHOULD be settable as part of the 2668 configuration of the router. How the limits are 2669 applied (e.g., per router or per interface) is left 2670 to the implementor's discretion. 2672 DISCUSSION: 2673 Two problems for a router sending ICMP error 2674 message are: 2675 (1) The consumption of bandwidth on the reverse 2676 path, and 2677 (2) The use of router resources (e.g., memory, 2678 CPU time) 2680 To help solve these problems a router can limit 2681 the frequency with which it generates ICMP error 2682 messages. For similar reasons, a router may limit 2683 the frequency at which some other sorts of 2684 messages, such as ICMP Echo Replies, are 2685 generated. 2687 IMPLEMENTATION: 2688 Various mechanisms have been used or proposed for 2689 limiting the rate at which ICMP messages are sent: 2691 (1) Count-based -- for example, send an ICMP 2692 error message for every N dropped packets 2693 overall or per given source host. This 2694 mechanism might be appropriate for ICMP 2695 Source Quench, but probably not for other 2696 types of ICMP messages. 2698 (2) Timer-based -- for example, send an ICMP 2699 error message to a given source host or 2700 overall at most once per T milliseconds. 2702 (3) Bandwidth-based -- for example, limit the 2703 rate at which ICMP messages are sent over a 2704 particular interface to some fraction of the 2705 attached network's bandwidth. 2707 4.3.3 SPECIFIC ISSUES 2709 4.3.3.1 Destination Unreachable 2711 If a route can not forward a packet because it has no 2712 routes at all to the destination network specified in 2713 the packet then the router MUST generate a 2714 Destination Unreachable, Code 0 (Network Unreachable) 2715 ICMP message. If the router does have routes to the 2716 destination network specified in the packet but the 2717 TOS specified for the routes is neither the default 2718 TOS (0000) nor the TOS of the packet that the router 2719 is attempting to route, then the router MUST generate 2720 a Destination Unreachable, Code 11 (Network 2721 Unreachable for TOS) ICMP message. 2723 If a packet is to be forwarded to a host on a network 2724 that is directly connected to the router (i.e., the 2725 router is the last-hop router) and the router has 2726 ascertained that there is no path to the destination 2727 host then the router MUST generate a Destination 2728 Unreachable, Code 1 (Host Unreachable) ICMP message. 2729 If a packet is to be forwarded to a host that is on a 2730 network that is directly connected to the router and 2731 the router cannot forward the packet because because 2732 no route to the destination has a TOS that is either 2733 equal to the TOS requested in the packet or is the 2734 default TOS (0000) then the router MUST generate a 2735 Destination Unreachable, Code 12 (Host Unreachable 2736 for TOS) ICMP message. 2738 DISCUSSION: 2739 The intent is that a router generates the 2740 "generic" host/network unreachable if it has no 2741 path at all (including default routes) to the 2742 destination. If the router has one or more paths 2743 to the destination, but none of those paths have 2744 an acceptable TOS, then the router generates the 2745 "unreachable for TOS" message. 2747 4.3.3.2 Redirect 2749 The ICMP Redirect message is generated to inform a 2750 host on the same subnet that the router used by the 2751 host to route certain packets should be changed. 2753 Contrary to section 3.2.2.2 of [INTRO:2], a router 2754 MAY ignore ICMP Redirects when choosing a path for a 2755 packet originated by the router if the router is 2756 running a routing protocol or if forwarding is 2757 enabled on the router and on the interface over which 2758 the packet is being sent. 2760 4.3.3.3 Source Quench 2762 A router SHOULD NOT originate ICMP Source Quench 2763 messages. As specified in Section [4.3.2], a router 2764 which does originate Source Quench messages MUST be 2765 able to limit the rate at which they are generated. 2767 DISCUSSION: 2768 Research seems to suggest that Source Quench 2769 consumes network bandwidth but is an ineffective 2770 (and unfair) antidote to congestion. See, for 2771 example, [INTERNET:9] and [INTERNET:10]. Section 2772 [5.3.6] discusses the current thinking on how 2773 routers ought to deal with overload and network 2774 congestion. 2776 A router MAY ignore any ICMP Source Quench messages 2777 it receives. 2779 DISCUSSION: 2780 A router itself may receive a Source Quench as the 2781 result of originating a packet sent to another 2782 router or host. Such datagrams might be, e.g., an 2783 EGP update sent to another router, or a telnet 2784 stream sent to a host. A mechanism has been 2785 proposed ([INTERNET:11], [INTERNET:12]) to make 2786 the IP layer respond directly to Source Quench by 2787 controlling the rate at which packets are sent, 2788 however, this proposal is currently experimental 2789 and not currently recommended. 2791 4.3.3.4 Time Exceeded 2793 When a router is forwarding a packet and the TTL 2794 field of the packet is reduced to 0, the requirements 2795 of section [5.2.3.8] apply. 2797 When the router is reassembling a packet that is 2798 destined for the router, it MUST fulfill requirements 2799 of [INTRO:2], section [3.3.2] apply. 2801 When the router receives (i.e., is destined for the 2802 router) a Time Exceeded message, it MUST comply with 2803 section 3.2.2.4 of [INTRO:2]. 2805 4.3.3.5 Parameter Problem 2807 A router MUST generate a Parameter Problem message 2808 for any error not specifically covered by another 2809 ICMP message. The IP header field or IP option 2810 including the byte indicated by the pointer field 2811 MUST be included unchanged in the IP header returned 2812 with this ICMP message. Section [4.3.2] defines an 2813 exception to this requirement. 2815 A new variant of the Parameter Problem message was 2816 defined in [INTRO:2]: 2817 Code 1 = required option is missing. 2819 DISCUSSION: 2821 This variant is currently in use in the military 2822 community for a missing security option. 2824 4.3.3.6 Echo Request/Reply 2826 A router MUST implement an ICMP Echo server function 2827 that receives Echo Requests and sends corresponding 2828 Echo Replies. A router MUST be prepared to receive, 2829 reassemble and echo an ICMP Echo Request datagram at 2830 least as large as the maximum of 576 and the MTUs of 2831 all the connected networks. 2833 The Echo server function MAY choose not to respond to 2834 ICMP echo requests addressed to IP broadcast or IP 2835 multicast addresses. 2837 A router SHOULD have a configuration option which, if 2838 enabled, causes the router to silently ignore all 2839 ICMP echo requests; if provided, this option MUST 2840 default to allowing responses. 2842 DISCUSSION: 2843 The neutral provision about responding to 2844 broadcast and multicast Echo Requests results from 2845 the conclusions reached in section [3.2.2.6] of 2846 [INTRO:2]. 2848 As stated in Section [10.3.3], a router MUST also 2849 implement an user/application-layer interface for 2850 sending an Echo Request and receiving an Echo Reply, 2851 for diagnostic purposes. All ICMP Echo Reply 2852 messages MUST be passed to this interface. 2854 The IP source address in an ICMP Echo Reply MUST be 2855 the same as the specific-destination address of the 2856 corresponding ICMP Echo Request message. 2858 Data received in an ICMP Echo Request MUST be 2859 entirely included in the resulting Echo Reply. 2861 If a Record Route and/or Timestamp option is received 2862 in an ICMP Echo Request, this option (these options) 2863 SHOULD be updated to include the current router and 2864 included in the IP header of the Echo Reply message, 2865 without "truncation". Thus, the recorded route will 2866 be for the entire round trip. 2868 If a Source Route option is received in an ICMP Echo 2869 Request, the return route MUST be reversed and used 2870 as a Source Route option for the Echo Reply message. 2872 4.3.3.7 Information Request/Reply 2874 A router SHOULD NOT originate or respond to these 2875 messages. 2877 DISCUSSION: 2878 The Information Request/Reply pair was intended to 2879 support self-configuring systems such as diskless 2880 workstations, to allow them to discover their IP 2881 network numbers at boot time. However, these 2882 messages are now obsolete. The RARP and BOOTP 2883 protocols provide better mechanisms for a host to 2884 discover its own IP address. 2886 4.3.3.8 Timestamp and Timestamp Reply 2888 A router MAY implement Timestamp and Timestamp Reply. 2889 If they are implemented then: 2891 + The ICMP Timestamp server function MUST return a 2892 Timestamp Reply to every Timestamp message that is 2893 received. It SHOULD be designed for minimum 2894 variability in delay. 2896 + An ICMP Timestamp Request message to an IP 2897 broadcast or IP multicast address MAY be silently 2898 discarded. 2900 + The IP source address in an ICMP Timestamp Reply 2901 MUST be the same as the specific-destination 2902 address of the corresponding Timestamp Request 2903 message. 2905 + If a Source Route option is received in an ICMP 2906 Timestamp Request, the return route MUST be 2907 reversed and used as a Source Route option for the 2908 Timestamp Reply message. 2910 + If a Record Route and/or Timestamp option is 2911 received in a Timestamp Request, this (these) 2912 option(s) SHOULD be updated to include the current 2913 router and included in the IP header of the 2914 Timestamp Reply message. 2916 + If the router provides an application-layer 2917 interface for sending Timestamp Request messages 2918 then incoming Timestamp Reply messages MUST be 2919 passed up to the ICMP user interface. 2921 The preferred form for a timestamp value (the 2922 "standard value") is milliseconds since midnight, 2923 Universal Time. However, it may be difficult to 2924 provide this value with millisecond resolution. For 2925 example, many systems use clocks that update only at 2926 line frequency, 50 or 60 times per second. 2927 Therefore, some latitude is allowed in a "standard 2928 value": 2930 (a) A "standard value" MUST be updated at least 16 2931 times per second (i.e., at most the six low- 2932 order bits of the value may be undefined). 2934 (b) The accuracy of a "standard value" MUST 2935 approximate that of operator-set CPU clocks, 2936 i.e., correct within a few minutes. 2938 IMPLEMENTATION: 2939 To meet the second condition, a router may need to 2940 query some time server when the router is booted 2941 or restarted. It is recommended that the UDP Time 2942 Server Protocol be used for this purpose. A more 2943 advanced implementation would use the Network Time 2944 Protocol (NTP) to achieve nearly millisecond clock 2945 synchronization; however, this is not required. 2947 4.3.3.9 Address Mask Request/Reply 2949 A router MUST implement support for receiving ICMP 2950 Address Mask Request messages and responding with 2951 ICMP Address Mask Reply messages. These messages are 2952 defined in [INTERNET:2]. 2954 A router SHOULD have a configuration option for each 2955 logical interface specifying whether the router is 2956 allowed to answer Address Mask Requests for that 2957 interface; this option MUST default to allowing 2958 responses. A router MUST NOT respond to an Address 2959 Mask Request before the router knows the correct 2960 subnet mask. 2962 A router MUST NOT respond to an Address Mask Request 2963 which has a source address of 0.0.0.0 and which 2964 arrives on a physical interface which has associated 2965 with it multiple logical interfaces and the subnet 2966 masks for those interfaces are not all the same. 2968 A router SHOULD examine all ICMP Address Mask Replies 2969 which it receives to determine whether the 2970 information it contains matches the router's 2971 knowledge of the subnet mask. If the ICMP Address 2972 Mask Reply appears to be in error, the router SHOULD 2973 log the subnet mask and the sender's IP address. A 2974 router MUST NOT use the contents of an ICMP Address 2975 Mask Reply to determine the correct subnet mask. 2977 Because hosts may not be able to learn the subnet 2978 mask if a router is down when the host boots up, a 2979 router MAY broadcast a gratuitous ICMP Address Mask 2980 Reply on each of its logical interfaces after it has 2981 configured its own subnet masks. However, this 2982 feature can be dangerous in environments which use 2983 variable length subnet masks. Therefore, if this 2984 feature is implemented, gratuitous Address Mask 2985 Replies MUST NOT be broadcast over any logical 2986 interface(s) which either: 2988 + Are not configured to send gratuitous Address Mask 2989 Replies. Each logical interface MUST have a 2990 configuration parameter controlling this, and that 2991 parameter MUST default to not sending the 2992 gratuitous Address Mask Replies. 2994 + Share the same IP network number and physical 2995 interface but have different subnet masks. 2997 The { , -1, -1 } form (on subnetted 2998 networks) or the { , -1 } form (on 2999 non-subnetted networks) of the IP broadcast address 3000 MUST be used for broadcast Address Mask Replies. 3002 DISCUSSION: 3003 The ability to disable sending Address Mask 3004 Replies by routers is required at a few sites 3005 which intentionally lie to their hosts about the 3006 subnet mask. The need for this is expected to go 3007 away as more and more hosts become compliant with 3008 the Host Requirements standards. 3010 The reason for both the second bullet above and 3011 the requirement about which IP broadcast address 3012 to use is to prevent problems when multiple IP 3013 networks or subnets are in use on the same 3014 physical network. 3016 4.3.3.10 Router Advertisement and Solicitations 3018 An IP router MUST support the router part of the ICMP 3019 Router Discovery Protocol [INTERNET:13] on all 3020 connected networks on which the router supports 3021 either IP multicast or IP broadcast addressing. The 3022 implementation MUST include all of the configuration 3023 variables specified for routers, with the specified 3024 defaults. 3026 DISCUSSION: 3027 Routers are not required to implement the host 3028 part of the ICMP Router Discovery Protocol, but 3029 might find it useful for operation while IP 3030 forwarding is disabled (i.e., when operating as a 3031 host). 3033 DISCUSSION: 3034 We note that it is quite common for hosts to use 3035 RIP as the "router discovery" protocol. Such 3036 hosts listen to RIP traffic and use and use 3037 information extracted from that traffic to 3038 discover routers and to make decisions as to which 3039 router to use as a first-hop router for a given 3040 destination. While this behavior is discouraged, 3041 it is still common and implementors should be 3042 aware of it. 3044 4.4 INTERNET GROUP MANAGEMENT PROTOCOL -- IGMP 3046 IGMP [INTERNET:4] is a protocol used between hosts and 3047 multicast routers on a single physical network to establish 3048 hosts' membership in particular multicast groups. 3049 Multicast routers use this information, in conjunction with 3050 a multicast routing protocol, to support IP multicast 3051 forwarding across the Internet. 3053 A router SHOULD implement the host part of IGMP. 3055 5. INTERNET LAYER -- FORWARDING 3057 5.1 INTRODUCTION 3059 This section describes the process of forwarding packets. 3061 5.2 FORWARDING WALK-THROUGH 3063 There is no separate specification of the forwarding 3064 function in IP. Instead, forwarding is covered by the 3065 protocol specifications for the internet layer protocols 3066 ([INTERNET:1], [INTERNET:2], [INTERNET:3], [INTERNET:8], 3067 and [ROUTE:11]). 3069 5.2.1 Forwarding Algorithm 3071 Since none of the primary protocol documents describe 3072 the forwarding algorithm in any detail, we present it 3073 here. This is just a general outline, and omits 3074 important details, such as handling of congestion, that 3075 are dealt with in later sections. 3077 It is not required that an implementation follow exactly 3078 the algorithms given in sections [5.2.1.1], [5.2.1.2], 3079 and [5.2.1.3]. Much of the challenge of writing router 3080 software is to maximize the rate at which the router can 3081 forward packets while still achieving the same effect of 3082 the algorithm. Details of how to do that are beyond the 3083 scope of this document, in part because they are heavily 3084 dependent on the architecture of the router. Instead, 3085 we merely point out the order dependencies among the 3086 steps: 3088 (1) A router MUST verify the IP header, as described in 3089 section [5.2.2], before performing any actions 3090 based on the contents of the header. This allows 3091 the router to detect and discard bad packets before 3092 the expenditure of other resources. 3094 (2) Processing of certain IP options requires that the 3095 router insert its IP address into the option. As 3096 noted in Section [5.2.4], the address inserted MUST 3097 be the address of the logical interface on which 3098 the packet is sent or the router's router-id if the 3099 packet is sent over an unnumbered interface. Thus, 3100 processing of these options cannot be completed 3101 until after the output interface is chosen. 3103 (3) The router cannot check and decrement the TTL 3104 before checking whether the packet should be 3105 delivered to the router itself, for reasons 3106 mentioned in Section [4.2.2.9]. 3108 (4) More generally, when a packet is delivered locally 3109 to the router, its IP header MUST NOT be modified 3110 in any way (except that a router may be required to 3111 insert a timestamp into any Timestamp options in 3112 the IP header). Thus, before the router determines 3113 whether the packet is to be delivered locally to 3114 the router, it cannot update the IP header in any 3115 way that it is not prepared to undo. 3117 5.2.1.1 General 3119 This section covers the general forwarding algorithm. 3120 This algorithm applies to all forms of packets to be 3121 forwarded: unicast, multicast, and broadcast. 3123 (1) The router receives the IP packet (plus 3124 additional information about it, as described in 3125 Section [3.1]) from the Link Layer. 3127 (2) The router validates the IP header, as described 3128 in Section [5.2.2]. Note that IP reassembly is 3129 not done, except on IP fragments to be queued 3130 for local delivery in step (4). 3132 (3) The router performs most of the processing of 3133 any IP options. As described in Section 3134 [5.2.4], some IP options require additional 3135 processing after the routing decision has been 3136 made. 3138 (4) The router examines the destination IP address 3139 of the IP datagram, as described in Section 3140 [5.2.3], to determine how it should continue to 3141 process the IP datagram. There are three 3142 possibilities: 3144 + The IP datagram is destined for the router, 3145 and should be queued for local delivery, 3146 doing reassembly if needed. 3148 + The IP datagram is not destined for the 3149 router, and should be queued for forwarding. 3151 + The IP datagram should be queued for 3152 forwarding, but (a copy) must also be queued 3153 for local delivery. 3155 5.2.1.2 Unicast 3157 Since the local delivery case is well-covered by 3158 [INTRO:2], the following assumes that the IP datagram 3159 was queued for forwarding. If the destination is an 3160 IP unicast address: 3162 (5) The forwarder determines the next hop IP address 3163 for the packet, usually by looking up the 3164 packet's destination in the router's routing 3165 table. This procedure is described in more 3166 detail in Section [5.2.4]. This procedure also 3167 decides which network interface should be used 3168 to send the packet. 3170 (6) The forwarder verifies that forwarding the 3171 packet is permitted. The source and destination 3172 addresses should be valid, as described in 3173 Section [5.3.7] and Section [5.3.4] If the 3174 router supports administrative constraints on 3175 forwarding, such as those described in Section 3176 [5.3.9], those constraints must be satisfied. 3178 (7) The forwarder decrements (by at least one) and 3179 checks the packet's TTL, as described in Section 3180 [5.3.1]. 3182 (8) The forwarder performs any IP option processing 3183 that could not be completed in step 3. 3185 (9) The forwarder performs any necessary IP 3186 fragmentation, as described in Section 3187 [4.2.2.7]. Since this step occurs after 3188 outbound interface selection (step 5), all 3189 fragments of the same datagram will be 3190 transmitted out the same interface. 3192 (10) The forwarder determines the Link Layer address 3193 of the packet's next hop. The mechanisms for 3194 doing this are Link Layer-dependent (see chapter 3195 3). 3197 (11) The forwarder encapsulates the IP datagram (or 3198 each of the fragments thereof) in an appropriate 3199 Link Layer frame and queues it for output on the 3200 interface selected in step 5. 3202 (12) The forwarder sends an ICMP redirect if 3203 necessary, as described in Section [4.3.3.2]. 3205 5.2.1.3 Multicast 3207 If the destination is an IP multicast, the following 3208 steps are taken. 3210 Note that the main differences between the forwarding 3211 of IP unicasts and the forwarding of IP multicasts 3212 are 3214 + IP multicasts are usually forwarded based on both 3215 the datagram's source and destination IP 3216 addresses, 3218 + IP multicast uses an expanding ring search, 3220 + IP multicasts are forwarded as Link Level 3221 multicasts, and 3223 + ICMP errors are never sent in response to IP 3224 multicast datagrams. 3226 Note that the forwarding of IP multicasts is still 3227 somewhat experimental. As a result, the algorithm 3228 presented below is not mandatory, and is provided as 3229 an example only. 3231 (5a) Based on the IP source and destination addresses 3232 found in the datagram header, the router 3233 determines whether the datagram has been 3234 received on the proper interface for forwarding. 3235 If not, the datagram is dropped silently. The 3236 method for determining the proper receiving 3237 interface depends on the multicast routing 3238 algorithm(s) in use. In one of the simplest 3239 algorithms, reverse path forwarding (RPF), the 3240 proper interface is the one that would be used 3241 to forward unicasts back to the datagram source. 3243 (6a) Based on the IP source and destination addresses 3244 found in the datagram header, the router 3245 determines the datagram's outgoing interfaces. 3246 In order to implement IP multicast's expanding 3247 ring search (see [INTERNET:4]) a minimum TTL 3248 value is specified for each outgoing interface. 3249 A copy of the multicast datagram is forwarded 3250 out each outgoing interface whose minimum TTL 3251 value is less than or equal to the TTL value in 3252 the datagram header, by separately applying the 3253 remaining steps on each such interface. 3255 (7a) The router decrements the packet's TTL by one. 3257 (8a) The forwarder performs any IP option processing 3258 that could not be completed in step (3). 3260 (9a) The forwarder performs any necessary IP 3261 fragmentation, as described in Section 3262 [4.2.2.7]. 3264 (10a) The forwarder determines the Link Layer address 3265 to use in the Link Level encapsulation. The 3266 mechanisms for doing this are Link Layer- 3267 dependent. On LANs a Link Level multicast or 3268 broadcast is selected, as an algorithmic 3269 translation of the datagrams' class D 3270 destination address. See the various IP-over- 3271 xxx specifications for more details. 3273 (11a) The forwarder encapsulates the packet (or each 3274 of the fragments thereof) in an appropriate Link 3275 Layer frame and queues it for output on the 3276 appropriate interface. 3278 5.2.2 IP Header Validation 3280 Before a router can process any IP packet, it MUST 3281 perform a the following basic validity checks on the 3282 packet's IP header to ensure that the header is 3283 meaningful. If the packet fails any of the following 3284 tests, it MUST be silently discarded, and the error 3285 SHOULD be logged. 3287 (1) The packet length reported by the Link Layer must 3288 be large enough to hold the minimum length legal IP 3289 datagram (20 bytes). 3291 (2) The IP checksum must be correct. 3293 (3) The IP version number must be 4. If the version 3294 number is not 4 then the packet may well be another 3295 version of IP, such as ST-II. 3297 (4) The IP header length field must be at least 5. 3299 (5) The IP total length field must be at least 4 * IP 3300 header length field. 3302 A router MUST NOT have a configuration option which 3303 allows disabling any of these tests. 3305 If the packet passes the second and third tests, the IP 3306 header length field is at least 4, and both the IP total 3307 length field and the packet length reported by the Link 3308 Layer are at least 16 then, despite the above rule, the 3309 router MAY respond with an ICMP Parameter Problem 3310 message, whose pointer points at the IP header length 3311 field (if it failed the fourth test) or the IP total 3312 length field (if it failed the fifth test). However, it 3313 still MUST discard the packet and still SHOULD log the 3314 error. 3316 These rules (and this entire document) apply only to 3317 version 4 of the Internet Protocol. These rules should 3318 not be construed as prohibiting routers from supporting 3319 other versions of IP. Furthermore, if a router can 3320 truly classify a packet as being some other version of 3321 IP then it ought not treat that packet as an error 3322 packet within the context of this memo. 3324 IMPLEMENTATION: 3325 It is desirable for purposes of error reporting, 3326 though not always entirely possible, to determine why 3327 a header was invalid. There are four possible 3328 reasons: 3330 + The Link Layer truncated the IP header 3332 + The datagram is using a version of IP other than 3333 the standard one (version 4). 3335 + The IP header has been corrupted in transit. 3337 + The sender generated an illegal IP header. 3339 It is probably desirable to perform the checks in the 3340 order listed, since we believe that this ordering is 3341 most likely to correctly categorize the cause of the 3342 error. For purposes of error reporting, it may also 3343 be desirable to check if a packet which fails these 3344 tests has an IP version number equal to 6. If it 3345 does, the packet is probably an ST-II datagram and 3346 should be treated as such. ST-II is described in 3347 [FORWARD:1]. 3349 Additionally, the router SHOULD verify that the packet 3350 length reported by the Link Layer is at least as large 3351 as the IP total length recorded in the packet's IP 3352 header. If it appears that the packet has been 3353 truncated, the packet MUST be discarded, the error 3354 SHOULD be logged, and the router SHOULD respond with an 3355 ICMP Parameter Problem message whose pointer points at 3356 the IP total length field. 3358 DISCUSSION: 3359 Because any higher layer protocol which concerns 3360 itself with data corruption will detect truncation of 3361 the packet data when it reaches its final 3362 destination, it is not absolutely necessary for 3363 routers to perform the check suggested above in order 3364 to maintain protocol correctness. However, by making 3365 this check a router can simplify considerably the 3366 task of determining which hop in the path is 3367 truncating the packets. It will also reduce the 3368 expenditure of resources "down-stream" from the 3369 router in that down-stream systems will not need to 3370 deal with the packet. 3372 Finally, if the destination address in the IP header is 3373 not one of the addresses of the router, the router 3374 SHOULD verify that the packet does not contain a Strict 3375 Source and Record Route option. If a packet fails this 3376 test, the router SHOULD log the error and SHOULD respond 3377 with an ICMP Parameter Problem error with the pointer 3378 pointing at the offending packet's IP destination 3379 address. 3381 DISCUSSION: 3382 Some people might suggest that the router should 3383 respond with a Bad Source Route message instead of a 3384 Parameter Problem message. However, when a packet 3385 fails this test, it usually indicates a protocol 3386 error by the previous hop router, whereas Bad Source 3387 Route would suggest that the source host had 3388 requested a nonexistent or broken path through the 3389 network. 3391 5.2.3 Local Delivery Decision 3393 When a router receives an IP packet, it must decide 3394 whether the packet is addressed to the router (and 3395 should be delivered locally) or the packet is addressed 3396 to another system (and should be handled by the 3397 forwarder). There is also a hybrid case, where certain 3398 IP broadcasts and IP multicasts are both delivered 3399 locally and forwarded. A router MUST determine which of 3400 the these three cases applies using the following rules: 3402 + An unexpired source route option is one whose pointer 3403 value does not point past the last entry in the 3404 source route. If the packet contains an unexpired 3405 source route option, the pointer in the option is 3406 advanced until either the pointer does point past the 3407 last address in the option or else the next address 3408 is not one of the router's own addresses. In the 3409 latter (normal) case, the packet is forwarded (and 3410 not delivered locally) regardless of the rules below. 3412 + The packet is delivered locally and not considered 3413 for forwarding in the following cases: 3415 -- The packet's destination address exactly matches 3416 one of the router's IP addresses, 3418 -- The packet's destination address is a limited 3419 broadcast address ({-1, -1}), and 3421 -- The packet's destination is an IP multicast 3422 address which is limited to a single subnet (such 3423 as 224.0.0.1 or 224.0.0.2) and (at least) one of 3424 the logical interfaces associated with the 3425 physical interface on which the packet arrived is 3426 a member of the destination multicast group. 3428 + The packet is passed to the forwarder AND delivered 3429 locally in the following cases: 3431 -- The packet's destination address is an IP 3432 broadcast address that addresses at least one of 3433 the router's logical interfaces but does not 3434 address any of the logical interfaces associated 3435 with the physical interface on which the packet 3436 arrived 3438 -- The packet's destination is an IP multicast 3439 address which is not limited to a single 3440 subnetwork (such as 224.0.0.1 and 224.0.0.2 are) 3441 and (at least) one of the logical interfaces 3442 associated with the physical interface on which 3443 the packet arrived is a member of the destination 3444 multicast group. 3446 + The packet is delivered locally if the packet's 3447 destination address is an IP broadcast address (other 3448 than a limited broadcast address) that addresses at 3449 least one of the logical interfaces associated with 3450 the physical interface on which the packet arrived. 3451 The packet is ALSO passed to the forwarder unless the 3452 link on which the packet arrived uses an IP 3453 encapsulation that does not encapsulate broadcasts 3454 differently than unicasts (e.g. by using different 3455 Link Layer destination addresses). 3457 + The packet is passed to the forwarder in all other 3458 cases. 3460 DISCUSSION: 3461 The purpose of the requirement in the last sentence 3462 of the fourth bullet is to deal with a directed 3463 broadcast to another net or subnet on the same 3464 physical cable. Normally, this works as expected: 3465 the sender sends the broadcast to the router as a 3466 Link Layer unicast. The router notes that it arrived 3467 as a unicast, and therefore must be destined for a 3468 different logical net (or subnet) than the sender 3469 sent it on. Therefore, the router can safely send it 3470 as a Link Layer broadcast out the same (physical) 3471 interface over which it arrived. However, if the 3472 router can't tell whether the packet was received as 3473 a Link Layer unicast, the sentence ensures that the 3474 router does the safe but wrong thing rather than the 3475 unsafe but right thing. 3477 IMPLEMENTATION: 3478 As described in Section [5.3.4], packets received as 3479 Link Layer broadcasts are generally not forwarded. 3480 It may be advantageous to avoid passing to the 3481 forwarder packets it would later discard because of 3482 the rules in that section. 3484 Some Link Layers (either because of the hardware or 3485 because of special code in the drivers) can deliver 3486 to the router copies of all Link Layer broadcasts and 3487 multicasts it transmits. Use of this feature can 3488 simplify the implementation of cases where a packet 3489 has to both be passed to the forwarder and delivered 3490 locally, since forwarding the packet will 3491 automatically cause the router to receive a copy of 3492 the packet that it can then deliver locally. One 3493 must use care in these circumstances in order to 3494 prevent treating a received loop-back packet as a 3495 normal packet that was received (and then being 3496 subject to the rules of forwarding, etc etc). 3498 Even in the absence of such a Link Layer, it is of 3499 course hardly necessary to make a copy of an entire 3500 packet in order to queue it both for forwarding and 3501 for local delivery, though care must be taken with 3502 fragments, since reassembly is performed on locally 3503 delivered packets but not on forwarded packets. One 3504 simple scheme is to associate a flag with each packet 3505 on the router's output queue which indicates whether 3506 it should be queued for local delivery after it has 3507 been sent. 3509 5.2.4 Determining the Next Hop Address 3511 When a router is going to forward a packet, it must 3512 determine whether it can send it directly to its 3513 destination, or whether it needs to pass it through 3514 another router. If the latter, it needs to determine 3515 which router to use. This section explains how these 3516 determinations are made. 3518 This section makes use of the following definitions: 3520 + "LSRR" -- IP Loose Source and Record Route option 3522 + "SSRR" -- IP Strict Source and Record Route option 3524 + "Source Route Option" -- an LSRR or an SSRR 3526 + "Ultimate Destination Address" -- where the packet is 3527 being sent to: the last address in the source route 3528 of a source-routed packet, or the destination address 3529 in the IP header of a non-source-routed packet 3531 + "Adjacent" -- reachable without going through any IP 3532 routers 3534 + "Next Hop Address" -- the IP address of the adjacent 3535 host or router to which the packet should be sent 3536 next 3538 + "Immediate Destination Address" -- the ultimate 3539 destination address, except in source routed packets, 3540 where it is the next address specified in the source 3541 route 3543 + Immediate Destination -- the node, system, router, 3544 end-system, or whatever that is addressed by the 3545 Immediate Destination Address. 3547 5.2.4.1 Immediate Destination Address 3549 If the destination address in the IP header is one of 3550 the addresses of the router and the packet contains a 3551 Source Route Option, the Immediate Destination 3552 Address is the address pointed at by the pointer in 3553 that option if the pointer does not point past the 3554 end of the option. Otherwise, the Immediate 3555 Destination Address is the same as the IP destination 3556 address in the IP header. 3558 A router MUST use the Immediate Destination Address, 3559 not the Ultimate Destination Address, when 3560 determining how to handle a packet. 3562 It is an error for more than one source route option 3563 to appear in a datagram. If it receives one, it 3564 SHOULD discard the packet and reply with an ICMP 3565 Parameter Problem message whose pointer points at the 3566 beginning of the second source route option. 3568 5.2.4.2 Local/Remote Decision 3570 After it has been determined that the IP packet needs 3571 to be forwarded in accordance with the rules 3572 specified in Section [5.2.3], the following algorithm 3573 MUST be used to determine if the Immediate 3574 Destination is directly accessible (see 3575 [INTERNET:2]): 3577 (1) For each network interface that has not been 3578 assigned any IP address (the "unnumbered lines" 3579 as described in Section [2.2.7]), compare the 3580 router-id of the other end of the line to the 3581 Immediate Destination Address. If they are 3582 exactly equal, the packet can be transmitted 3583 through this interface. 3585 DISCUSSION: 3586 In other words, the router or host at the 3587 remote end of the line is the destination of 3588 the packet or is the next step in the source 3589 route of a source routed packet. 3591 (2) If no network interface has been selected in the 3592 first step, for each IP address assigned to the 3593 router: 3594 (a) Apply the subnet mask associated with the 3595 address to this IP address. 3597 IMPLEMENTATION: 3598 The result of this operation will 3599 usually have been computed and saved 3600 during initialization. 3602 (b) Apply the same subnet mask to the Immediate 3603 Destination Address of the packet. 3604 (c) Compare the resulting values. If they are 3605 equal to each other, the packet can be 3606 transmitted through the corresponding 3607 network interface. 3609 (3) If an interface has still not been selected, the 3610 Immediate Destination is accessible only through 3611 some other router. The selection of the router 3612 and the "next hop" IP address is described in 3613 Section [5.2.4.3]. 3615 5.2.4.3 Next Hop Address 3617 EDITOR'S COMMENTS: 3618 Note that this section has been extensively 3619 rewritten. The original document indicated that 3620 Phil Almquist wished to revise this section to 3621 conform to his "Ruminations on the Next Hop" 3622 document. I am under the assumption that the 3623 working group generally agreed with this goal; 3624 there was an editor's note from Phil that remained 3625 in this document to that effect, and the RoNH 3626 document contains a "mandatory RRWG algorithm". 3628 So, I have taken said algorithm from RoNH and 3629 moved it into here. 3631 Additional useful or interesting information from 3632 RoNH has been extracted and placed into an 3633 appendix to this note. 3635 The router applies the algorithm in the previous 3636 section to determine if the Immediate Destination 3637 Address is adjacent. If so, the next hop address is 3638 the same as the Immediate Destination Address. 3639 Otherwise, the packet must be forwarded through 3640 another router to reach its Immediate Destination. 3641 The selection of this router is the topic of this 3642 section. 3644 If the packet contains an SSRR, the router MUST 3645 discard the packet and reply with an ICMP Bad Source 3646 Route error. Otherwise, the router looks up the 3647 Immediate Destination Address in its routing table to 3648 determine an appropriate next hop address. 3650 DISCUSSION: 3651 Per the IP specification, a Strict Source Route 3652 must specify a sequence of nodes through which the 3653 packet must traverse; the packet must go from one 3654 node of the source route to the next, traversing 3655 intermediate networks only. Thus, if the router 3656 is not adjacent to the next step of the source 3657 route, the source route can not be fulfilled. 3659 Therefore, the ICMP Bad Source Route error. 3661 The goal of the next-hop selection process is to 3662 examine the entries in the router's Forwarding 3663 Information Base (FIB) and select the best route (if 3664 there is one) for the packet from those available in 3665 the FIB. 3667 Conceptually, any route lookup algorithm starts out 3668 with a set of candidate routes which consists of the 3669 entire contents of the FIB. The algorithm consists 3670 of a series of steps which discard routes from the 3671 set. These steps are referred to as Pruning Rules. 3672 Normally, when the algorithm terminates there is 3673 exactly one route remaining in the set. If the set 3674 ever becomes empty, the packet is discarded because 3675 the destination is unreachable. It is also possible 3676 for the algorithm to terminate when more than one 3677 route remains in the set. In this case, the router 3678 may arbitrarily discard all but one of them, or may 3679 perform "load-splitting" by choosing whichever of the 3680 routes has been least recently used. 3682 With the exception of rule 3 (Weak TOS), a router 3683 MUST use the following Pruning Rules when selecting a 3684 next hop for a packet. If a router does consider TOS 3685 when making next-hop decisions, the Rule 3 must be 3686 applied in the order indicated below. These rules 3687 MUST be (conceptually) applied to the FIB in the 3688 order that they are presented. (For some historical 3689 perspective, additional pruning rules, and other 3690 common algorithms in use, see Appendix E). 3692 DISCUSSION: 3693 Rule 3 is optional in that Section [5.3.2] says 3694 that a router only SHOULD consider TOS when making 3695 forwarding decisions. 3697 (1) Basic Match 3698 This rule discards any routes to destinations 3699 other than the Immediate Destination Address of 3700 the packet. For example, if a packet's 3701 Immediate Destination Address is 36.144.2.5, 3702 this step would discard a route to net 3703 128.12.0.0 but would retain any routes to net 3704 36.0.0.0, any routes to subnet 36.144.0.0, and 3705 any default routes. 3707 More precisely, we assume that each route has a 3708 destination attribute, called route.dest, and a 3709 corresponding mask, called route.mask, to 3710 specify which bits of route.dest are 3711 significant. The Immediate Destination Address 3712 of the packet being forwarded is ip.dest. This 3713 rule discards all routes from the set of 3714 candidate routes except those for which 3715 (route.dest & route.mask) = (ip.dest & 3716 route.mask). 3718 (2) Longest Match 3719 Longest Match is a refinement of Basic Match, 3720 described above. After Basic Match pruning is 3721 performed, the remaining routes are examined to 3722 determine the maximum number of bits set in any 3723 of their route.mask attributes. The step then 3724 discards from the set of candidate routes any 3725 routes which have fewer than that maximum number 3726 of bits set in their route.mask attributes. 3728 For example, if a packet's Immediate Destination 3729 Address is 36.144.2.5 and there are 3730 {route.dest, route.mask} pairs of {36.144.2.0, 3731 255.255.255.0}, {36.144.0.5, 255.255.0.255}, 3732 {36.144.0.0, 255.255.0.0}, and {36.0.0.0, 3733 255.0.0.0}, then this rule would keep only the 3734 first two pairs; {36.144.2.0, 255.255.255.0} and 3735 {36.144.0.5, 255.255.0.255}. 3737 (3) Weak TOS 3738 Each route has a type of service attribute, 3739 called route.tos, whose possible values are 3740 assumed to be identical to those used in the TOS 3741 field of the IP header. Routing protocols which 3742 distribute TOS information fill in route.tos 3743 appropriately in routes they add to the FIB; 3744 routes from other routing protocols are treated 3745 as if they have the default TOS (0000). The TOS 3746 field in the IP header of the packet being 3747 routed is called ip.tos. 3749 The set of candidate routes is examined to 3750 determine if it contains any routes for which 3751 route.tos = ip.tos. If so, all routes except 3752 those for which route.tos = ip.tos are 3753 discarded. If not, all routes except those for 3754 which route.tos = 0000 are discarded from the 3755 set of candidate routes. 3757 Additional discussion of routing based on Weak 3758 TOS may be found in [ROUTE:11]. 3760 DISCUSSION: 3761 The effect of this rule is to select only 3762 those routes which have a TOS that matches 3763 the TOS requested in the packet. If no such 3764 routes exist then routes with the default TOS 3765 are considered. Routes with a non-default 3766 TOS that is not the TOS requested in the 3767 packet are never used, even if such routes 3768 are the only available routes that go to the 3769 packet's destination. 3771 (4) Best Metric 3772 Each route has a metric attribute, called 3773 route.metric, and a routing domain identifier, 3774 called route.domain. Each member of the set of 3775 candidate routes is compared with each other 3776 member of the set. If route.domain is equal for 3777 the two routes and route.metric is strictly 3778 "inferior" for one when compared with the other, 3779 then the one with the "inferior" metric is 3780 discarded from the set. The determination of 3781 "inferior" is usually by a simple arithmetic 3782 comparison, though some protocols may have 3783 structured metrics requiring more complex 3784 comparisons. 3786 (5) Vendor Policy 3787 Vendor Policy is sort of a catch-all to make up 3788 for the fact that the previously listed rules 3789 are often inadequate to chose from among the 3790 possible routes. Vendor Policy pruning rules 3791 are extremely vendor-specific. See section 3792 [5.2.4.4]. 3794 This algorithm has two distinct disadvantages. 3795 Presumably, a router implementor might develop 3796 techniques to deal with these disadvantages and make 3797 them a part of the Vendor Policy pruning rule. 3799 (1) IS-IS and OSPF route classes are not directly 3800 handled. 3802 (2) Path properties other than type of service (e.g. 3803 MTU) are ignored. 3805 It is also worth noting a deficiency in the way that 3806 TOS is supported: routing protocols which support TOS 3807 are implicitly preferred when forwarding packets 3808 which have non-zero TOS values. 3810 The Basic Match and Longest Match pruning rules 3811 generalize the treatment of a number of particular 3812 types of routes. These routes are selected in the 3813 following, decreasing, order of preference: 3815 (1) Host Route: This is a route to a specific end 3816 system. 3818 (2) Subnetwork Route: This is a route to a 3819 particular subnet of a network. 3821 (3) Default Subnetwork Route: This is a route to all 3822 subnets of a particular net for which there are 3823 not (explicit) subnet routes. 3825 (4) Network Route: This is a route to a particular 3826 network. 3828 (5) Default Network Route (also known as the 3829 "default route"): This is a route to all 3830 networks for which there are no explicit routes 3831 to the net or any of its subnets. 3833 If, after application of the pruning rules, the set 3834 of routes is empty (i.e., no routes were found), the 3835 packet MUST be discarded and an appropriate ICMP 3836 error generated (ICMP Bad Source Route if the 3837 Immediate Destination Address came from a source 3838 route option; otherwise, whichever of ICMP 3839 Destination Host Unreachable or Destination Network 3840 Unreachable is appropriate, as described in Section 3841 [4.3.3.1]). 3843 5.2.4.4 Administrative Preference 3845 One suggested mechanism for the Vendor Policy Pruning 3846 Rule is to use administrative preference. 3848 Each route has associated with it a "preference 3849 value", based on various attributes of the route 3850 (specific mechanisms for assignment of preference 3851 values are suggested below). This preference value 3852 is an integer in the range [0..255], with zero being 3853 the most preferred and 254 being the least preferred. 3854 255 is a special value that means that the route 3855 should never be used. The first step in the Vendor 3856 Policy pruning rule discards all but the most 3857 preferable routes (and always discards routes whose 3858 preference value is 255). 3860 This policy is not "safe" in that it can easily be 3861 misused to create routing loops. Since no protocol 3862 ensures that the preferences configured for a router 3863 are consistent with the preferences configured in its 3864 neighbors, network managers must exercise care in 3865 configuring preferences. 3867 + Address Match 3868 It is useful to be able to assign a single 3869 preference value to all routes (learned from the 3870 same routing domain) to any of a specified set of 3871 destinations, where the set of destinations is all 3872 destinations that match a specified address/mask 3873 pair. 3875 + Route Class 3876 For routing protocols which maintain the 3877 distinction, it is useful to be able to assign a 3878 single preference value to all routes (learned 3879 from the same routing domain) which have a 3880 particular route class (intra-area, inter-area, 3881 external with internal metrics, or external with 3882 external metrics). 3884 + Interface 3885 It is useful to be able to assign a single 3886 preference value to all routes (learned from a 3887 particular routing domain) that would cause 3888 packets to be routed out a particular logical 3889 interface on the router (logical interfaces 3890 generally map one-to-one onto the router's network 3891 interfaces, except that any network interface 3892 which has multiple IP addresses will have multiple 3893 logical interfaces associated with it). 3895 + Source router 3896 It is useful to be able to assign a single 3897 preference value to all routes (learned from the 3898 same routing domain) which were learned from any 3899 of a set of routers, where the set of routers are 3900 those whose updates have a source address which 3901 match a specified address/mask pair. 3903 + Originating AS 3904 For routing protocols which provide the 3905 information, it is useful to be able to assign a 3906 single preference value to all routes (learned 3907 from a particular routing domain) which originated 3908 in another particular routing domain. For BGP 3909 routes, the originating AS is the first AS listed 3910 in the route's AS_PATH attribute. For OSPF 3911 external routes, the originating AS may be 3912 considered to be the low order 16 bits of the 3913 route's external route tag if the tag's Automatic 3914 bit is set and the tag's PathLength is not equal 3915 to 3. 3917 + External route tag 3918 It is useful to be able to assign a single 3919 preference value to all OSPF external routes 3920 (learned from the same routing domain) whose 3921 external route tags match any of a list of 3922 specified values. Because the external route tag 3923 may contain a structured value, it may be useful 3924 to provide the ability to match particular 3925 subfields of the tag. 3927 + AS path 3928 It may be useful to be able to assign a single 3929 preference value to all BGP routes (learned from 3930 the same routing domain) whose AS path "matches" 3931 any of a set of specified values. It is not yet 3932 clear exactly what kinds of matches are most 3933 useful. A simple option would be to allow 3934 matching of all routes for which a particular AS 3935 number appears (or alternatively, does not appear) 3936 anywhere in the route's AS_PATH attribute. A more 3937 general but somewhat more difficult alternative 3938 would be to allow matching all routes for which 3939 the AS path matches a specified regular 3940 expression. 3942 5.2.4.6 Load Splitting 3944 At the end of the Next-hop selection process, 3945 multiple routes may still remain. A router has 3946 several options when this occurs. It may arbitrarily 3947 discard some of the routes. It may reduce the number 3948 of candidate routes by comparing metrics of routes 3949 from routing domains which are not considered 3950 equivalent. It may retain more than one route and 3951 employ a "load-splitting" mechanism to divide traffic 3952 among them. Perhaps the only thing that can be said 3953 about the relative merits of the options is that 3954 load-splitting is useful in some situations but not 3955 in others, so a wise implementor who implements load- 3956 splitting will also provide a way for the network 3957 manager to disable it. 3959 5.2.5 Unused IP Header Bits: RFC-791 Section 3.1 3961 The IP header contains several reserved bits, in the 3962 Type of Service field and in the Flags field. Routers 3963 MUST NOT drop packets merely because one or more of 3964 these reserved bits has a non-zero value. 3966 Routers MUST ignore and MUST pass through unchanged the 3967 values of these reserved bits. If a router fragments a 3968 packet, it MUST copy these bits into each fragment. 3970 DISCUSSION: 3971 Future revisions to the IP protocol may make use of 3972 these unused bits. These rules are intended to 3973 ensure that these revisions can be deployed without 3974 having to simultaneously upgrade all routers in the 3975 Internet. 3977 5.2.6 Fragmentation and Reassembly: RFC-791 Section 3.2 3979 As was discussed in Section [4.2.2.7], a router MUST 3980 support IP fragmentation. 3982 A router MUST NOT reassemble any datagram before 3983 forwarding it. 3985 DISCUSSION: 3986 A few people have suggested that there might be some 3987 topologies where reassembly of transit datagrams by 3988 routers might improve performance. In general, 3989 however, the fact that fragments may take different 3990 paths to the destination precludes safe use of such a 3991 feature. 3993 Nothing in this section should be construed to 3994 control or limit fragmentation or reassembly 3995 performed as a link layer function by the router. 3997 5.2.7 Internet Control Message Protocol -- ICMP 3999 General requirements for ICMP were discussed in Section 4000 [4.3]. This section discusses ICMP messages which are 4001 sent only by routers. 4003 5.2.7.1 Destination Unreachable 4005 The ICMP Destination Unreachable message is sent by a 4006 router in response to a packet which it cannot 4007 forward because the destination (or next hop) is 4008 unreachable or a service is unavailable 4010 A router MUST be able to generate ICMP Destination 4011 Unreachable messages and SHOULD choose a response 4012 code that most closely matches the reason why the 4013 message is being generated. 4015 The following codes are defined in [INTERNET:8] and 4016 [INTRO:2]: 4018 0 = Network Unreachable - generated by a router if a 4019 forwarding path (route) to the destination 4020 network is not available; 4022 1 = Host Unreachable - generated by a router if a 4023 forwarding path (route) to the destination host 4024 on a directly connected network is not 4025 available; 4027 2 = Protocol Unreachable - generated if the 4028 transport protocol designated in a datagram is 4029 not supported in the transport layer of the 4030 final destination; 4032 3 = Port Unreachable - generated if the designated 4033 transport protocol (e.g. UDP) is unable to 4034 demultiplex the datagram in the transport layer 4035 of the final destination but has no protocol 4036 mechanism to inform the sender; 4038 4 = Fragmentation Needed and DF Set - generated if a 4039 router needs to fragment a datagram but cannot 4040 since the DF flag is set; 4042 5 = Source Route Failed - generated if a router 4043 cannot forward a packet to the next hop in a 4044 source route option; 4046 6 = Destination Network Unknown - This code SHOULD 4047 NOT be generated since it would imply on the 4048 part of the router that the destination network 4049 does not exist (net unreachable code 0 SHOULD be 4050 used in place of code 6); 4052 7 = Destination Host Unknown - generated only when a 4053 router can determine (from link layer advice) 4054 that the destination host does not exist; 4056 11 = Network Unreachable For Type Of Service - 4057 generated by a router if a forwarding path 4058 (route) to the destination network with the 4059 requested or default TOS is not available; 4061 12 = Host Unreachable For Type Of Service - generated 4062 if a router cannot forward a packet because its 4063 route(s) to the destination do not match either 4064 the TOS requested in the datagram or the default 4065 TOS (0). 4067 The following additional codes are hereby defined: 4069 13 = Communication Administratively Prohibited - 4070 generated if a router cannot forward a packet 4071 due to administrative filtering; 4073 14 = Host Precedence Violation. Sent by the first 4074 hop router to a host to indicate that a 4075 requested precedence is not permitted for the 4076 particular combination of source/destination 4077 host or network, upper layer protocol, and 4078 source/destination port; 4080 15 = Precedence cutoff in effect. The network 4081 operators have imposed a minimum level of 4082 precedence required for operation, the datagram 4083 was sent with a precedence below this level; 4085 NOTE: [INTRO:2] defined Code 8 for "source host 4086 isolated". Routers SHOULD NOT generate Code 8; 4087 whichever of Codes 0 (Network Unreachable) and 1 4088 (Host Unreachable) is appropriate SHOULD be used 4089 instead. [INTRO:2] also defined Code 9 for 4090 communication with destination network 4091 administratively prohibited and Code 10 for 4092 communication with destination host administratively 4093 prohibited. These codes were intended for use by 4094 end-to-end encryption devices used by U.S military 4095 agencies. Routers SHOULD use the newly defined Code 4096 13 (Communication Administratively Prohibited) if 4097 they administratively filter packets. 4099 Routers MAY have a configuration option that causes 4100 Code 13 (Communication Administratively Prohibited) 4101 messages not to be generated. When this option is 4102 enabled, no ICMP error message is sent in response to 4103 a packet which is dropped because its forwarding is 4104 administratively prohibited. 4106 Similarly, routers MAY have a configuration option 4107 that causes Code 14 (Host Precedence Violation) and 4108 Code 15 (Precedence Cutoff in Effect) messages not to 4109 be generated. When this option is enabled, no ICMP 4110 error message is sent in response to a packet which 4111 is dropped because of a precedence violation. 4113 Routers MUST use Host Unreachable or Destination Host 4114 Unknown codes whenever other hosts on the same 4115 destination network might be reachable; otherwise, 4116 the source host may erroneously conclude that all 4117 hosts on the network are unreachable, and that may 4118 not be the case. 4120 [INTERNET:14] describes a slight modification the 4121 form of Destination Unreachable messages containing 4122 Code 4 (Fragmentation needed and DF set). A router 4123 MUST use this modified form when originating Code 4 4124 Destination Unreachable messages. 4126 5.2.7.2 Redirect 4128 The ICMP Redirect message is generated to inform a 4129 host on the same subnet that the router used by the 4130 host to route certain packets should be changed. 4132 Routers MUST NOT generate the Redirect for Network or 4133 Redirect for Network and Type of Service messages 4134 (Codes 0 and 2) specified in [INTERNET:8]. Routers 4135 MUST be able to generate the Redirect for Host 4136 message (Code 1) and SHOULD be able to generate the 4137 Redirect for Type of Service and Host message (Code 4138 3) specified in [INTERNET:8]. 4140 DISCUSSION: 4141 If the directly-connected network is not 4142 subnetted, a router can normally generate a 4143 network Redirect which applies to all hosts on a 4144 specified remote network. Using a network rather 4145 than a host Redirect may economize slightly on 4146 network traffic and on host routing table storage. 4147 However, the savings are not significant, and 4148 subnets create an ambiguity about the subnet mask 4149 to be used to interpret a network Redirect. In a 4150 general subnet environment, it is difficult to 4151 specify precisely the cases in which network 4152 Redirects can be used. Therefore, routers must 4153 send only host (or host and type of service) 4154 Redirects. 4156 A Code 3 (Redirect for Host and Type of Service) 4157 message is generated when the packet provoking the 4158 redirect has a destination for which the path chosen 4159 by the router would depend (in part) on the TOS 4160 requested. 4162 Routers which can generate Code 3 redirects (Host and 4163 Type of Service) MUST have a configuration option 4164 (which defaults to on) to enable Code 1 (Host) 4165 redirects to be substituted for Code 3 redirects. A 4166 router MUST send a Code 1 Redirect in place of a Code 4167 3 Redirect if it has been configured to do so. 4169 If a router is not able to generate Code 3 Redirects 4170 then it MUST generate Code 1 Redirects in situations 4171 where a Code 3 Redirect is called for. 4173 Routers MUST NOT generate a Redirect Message unless 4174 all of the following conditions are met: 4176 + The packet is being forwarded out the same 4177 physical interface that it was received from, 4179 + The IP source address in the packet is on the same 4180 Logical IP (sub)network as the next-hop IP 4181 address, and 4183 + The packet does not contain an IP source route 4184 option. 4186 The source address used in the ICMP Redirect MUST 4187 belong to the same logical (sub)net as the 4188 destination address. 4190 A router using a routing protocol (other than static 4191 routes) MUST NOT consider paths learned from ICMP 4192 Redirects when forwarding a packet. If a router is 4193 not using a routing protocol, a router MAY have a 4194 configuration which, if set, allows the router to 4195 consider routes learned via ICMP Redirects when 4196 forwarding packets. 4198 DISCUSSION: 4199 ICMP Redirect is a mechanism for routers to convey 4200 routing information to hosts. Routers use other 4201 mechanisms to learn routing information, and 4202 therefore have no reason to obey redirects. 4203 Believing a redirect which contradicted the 4204 router's other information would likely create 4205 routing loops. 4207 On the other hand, when a router is not acting as 4208 a router, it MUST comply with the behavior 4209 required of a host. 4211 5.2.7.3 Time Exceeded 4213 A router MUST generate a Time Exceeded message Code 0 4214 (In Transit) when it discards a packet due to an 4215 expired TTL field. A router MAY have a per-interface 4216 option to disable origination of these messages on 4217 that interface, but that option MUST default to 4218 allowing the messages to be originated. 4220 5.2.8 INTERNET GROUP MANAGEMENT PROTOCOL -- IGMP 4222 IGMP [INTERNET:4] is a protocol used between hosts and 4223 multicast routers on a single physical network to 4224 establish hosts' membership in particular multicast 4225 groups. Multicast routers use this information, in 4226 conjunction with a multicast routing protocol, to 4227 support IP multicast forwarding across the Internet. 4229 A router SHOULD implement the multicast router part of 4230 IGMP. 4232 5.3 SPECIFIC ISSUES 4234 5.3.1 Time to Live (TTL) 4236 The Time-to-Live (TTL) field of the IP header is defined 4237 to be a timer limiting the lifetime of a datagram. It 4238 is an 8-bit field and the units are seconds. Each 4239 router (or other module) that handles a packet MUST 4240 decrement the TTL by at least one, even if the elapsed 4241 time was much less than a second. Since this is very 4242 often the case, the TTL is effectively a hop count limit 4243 on how far a datagram can propagate through the 4244 Internet. 4246 When a router forwards a packet, it MUST reduce the TTL 4247 by at least one. If it holds a packet for more than one 4248 second, it MAY decrement the TTL by one for each second. 4250 If the TTL is reduced to zero (or less), the packet MUST 4251 be discarded, and if the destination is not a multicast 4252 address the router MUST send an ICMP Time Exceeded 4253 message, Code 0 (TTL Exceeded in Transit) message to the 4254 source. Note that a router MUST NOT discard an IP 4255 unicast or broadcast packet with a non-zero TTL merely 4256 because it can predict that another router on the path 4257 to the packet's final destination will decrement the TTL 4258 to zero. However, a router MAY do so for IP multicasts, 4259 in order to more efficiently implement IP multicast's 4260 expanding ring search algorithm (see [INTERNET:4]). 4262 DISCUSSION: 4263 The IP TTL is used, somewhat schizophrenically, as 4264 both a hop count limit and a time limit. Its hop 4265 count function is critical to ensuring that routing 4266 problems can't melt down the network by causing 4267 packets to loop infinitely in the network. The time 4268 limit function is used by transport protocols such as 4269 TCP to ensure reliable data transfer. Many current 4270 implementations treat TTL as a pure hop count, and in 4271 parts of the Internet community there is a strong 4272 sentiment that the time limit function should instead 4273 be performed by the transport protocols that need it. 4275 In this specification, we have reluctantly decided to 4276 follow the strong belief among the router vendors 4277 that the time limit function should be optional. 4278 They argued that implementation of the time limit 4279 function is difficult enough that it is currently not 4280 generally done. They further pointed to the lack of 4281 documented cases where this shortcut has caused TCP 4282 to corrupt data (of course, we would expect the 4283 problems created to be rare and difficult to 4284 reproduce, so the lack of documented cases provides 4285 little reassurance that there haven't been a number 4286 of undocumented cases). 4288 IP multicast notions such as the expanding ring 4289 search may not work as expected unless the TTL is 4290 treated as a pure hop count. The same thing is 4291 somewhat true of traceroute. 4293 ICMP Time Exceeded messages are required because the 4294 traceroute diagnostic tool depends on them. 4296 Thus, the tradeoff is between severely crippling, if 4297 not eliminating, two very useful tools vs. a very 4298 rare and transient data transport problem (which may 4299 not occur at all). 4301 5.3.2 Type of Service (TOS) 4303 The "Type-of-Service" byte in the IP header is divided 4304 into three sections: the Precedence field (high-order 3 4305 bits), a field that is customarily called "Type of 4306 Service" or "TOS" (next 4 bits), and a reserved bit (the 4307 low order bit). Rules governing the reserved bit were 4308 described in Section [4.2.2.3]. The Precedence field 4309 will be discussed in Section [5.3.3]. A more extensive 4310 discussion of the TOS field and its use can be found in 4311 [ROUTE:11]. 4313 A router SHOULD consider the TOS field in a packet's IP 4314 header when deciding how to forward it. The remainder 4315 of this section describes the rules that apply to 4316 routers that conform to this requirement. 4318 A router MUST maintain a TOS value for each route in its 4319 routing table. Routes learned via a routing protocol 4320 which does not support TOS MUST be assigned a TOS of 4321 zero (the default TOS). 4323 To choose a route to a destination, a router MUST use an 4324 algorithm equivalent to the following: 4326 (1) The router locates in its routing table all 4327 available routes to the destination (see Section 4328 [5.2.4]). 4330 (2) If there are none, the router drops the packet 4331 because the destination is unreachable. See 4332 section [5.2.4]. 4334 (3) If one or more of those routes have a TOS that 4335 exactly matches the TOS specified in the packet, 4336 the router chooses the route with the best metric. 4338 (4) Otherwise, the router repeats the above step, 4339 except looking at routes whose TOS is zero. 4341 (5) If no route was chosen above, the router drops the 4342 packet because the destination is unreachable. The 4343 router returns an ICMP Destination Unreachable 4344 error specifying the appropriate code: either 4345 Network Unreachable with Type of Service (code 11) 4346 or Host Unreachable with Type of Service (code 12). 4348 DISCUSSION: 4349 Although TOS has been little used in the past, its 4350 use by hosts is now mandated by the Requirements for 4351 Internet Hosts RFCs ([INTRO:2] and [INTRO:3]). 4352 Support for TOS in routers may become a MUST in the 4353 future, but is a SHOULD for now until we get more 4354 experience with it and can better judge both its 4355 benefits and its costs. 4357 Various people have proposed that TOS should affect 4358 other aspects of the forwarding function. For 4359 example: 4361 (1) A router could place packets which have the "Low 4362 Delay" bit set ahead of other packets in its 4363 output queues. 4365 (2) a router is forced to discard packets, it could 4366 try to avoid discarding those which have the 4367 "High Reliability" bit set. 4369 These ideas have been explored in more detail in 4370 [INTERNET:17] but we don't yet have enough experience 4371 with such schemes to make requirements in this area. 4373 5.3.3 IP Precedence 4375 This section specifies requirements and guidelines for 4376 appropriate processing of the IP Precedence field in 4377 routers. Precedence is a scheme for allocating 4378 resources in the network based on the relative 4379 importance of different traffic flows. The IP 4380 specification defines specific values to be used in this 4381 field for various types of traffic. 4383 The basic mechanisms for precedence processing in a 4384 router are preferential resource allocation, including 4385 both precedence-ordered queue service and precedence- 4386 based congestion control, and selection of Link Layer 4387 priority features. The router also selects the IP 4388 precedence for routing, management and control traffic 4389 it originates. For a more extensive discussion of IP 4390 Precedence and its implementation see [FORWARD:6]. 4392 Precedence-ordered queue service, as discussed in this 4393 section, includes but is not limited to the queue for 4394 the forwarding process and queues for outgoing links. 4395 It is intended that a router supporting precedence 4396 should also use the precedence indication at whatever 4397 points in its processing are concerned with allocation 4398 of finite resources, such as packet buffers or Link 4399 Layer connections. The set of such points is 4400 implementation-dependent. 4402 DISCUSSION: 4403 Although the Precedence field was originally provided 4404 for use in DOD systems where large traffic surges or 4405 major damage to the network are viewed as inherent 4406 threats, it has useful applications for many non- 4407 military IP networks. Although the traffic handling 4408 capacity of networks has grown greatly in recent 4409 years, the traffic generating ability of the users 4410 has also grown, and network overload conditions still 4411 occur at times. Since IP-based routing and 4412 management protocols have become more critical to the 4413 successful operation of the Internet, overloads 4414 present two additional risks to the network: 4416 (1) High delays may result in routing protocol 4417 packets being lost. This may cause the routing 4418 protocol to falsely deduce a topology change and 4419 propagate this false information to other 4420 routers. Not only can this cause routes to 4421 oscillate, but an extra processing burden may be 4422 placed on other routers. 4424 (2) High delays may interfere with the use of 4425 network management tools to analyze and perhaps 4426 correct or relieve the problem in the network 4427 that caused the overload condition to occur. 4429 Implementation and appropriate use of the Precedence 4430 mechanism alleviates both of these problems. 4432 5.3.3.1 Precedence-Ordered Queue Service 4434 Routers SHOULD implement precedence-ordered queue 4435 service. Precedence-ordered queue service means that 4436 when a packet is selected for output on a (logical) 4437 link, the packet of highest precedence that has been 4438 queued for that link is sent. Routers that implement 4439 precedence-ordered queue service MUST also have a 4440 configuration option to suppress precedence-ordered 4441 queue service in the Internet Layer. 4443 Any router MAY implement other policy-based 4444 throughput management procedures that result in other 4445 than strict precedence ordering, but it MUST be 4446 configurable to suppress them (i.e., use strict 4447 ordering). 4449 As detailed in Section [5.3.6], routers that 4450 implement precedence-ordered queue service discard 4451 low precedence packets before discarding high 4452 precedence packets for congestion control purposes. 4454 Preemption (interruption of processing or 4455 transmission of a packet) is not envisioned as a 4456 function of the Internet Layer. Some protocols at 4457 other layers may provide preemption features. 4459 5.3.3.2 Lower Layer Precedence Mappings 4461 Routers that implement precedence-ordered queueing 4462 MUST IMPLEMENT, and other routers SHOULD IMPLEMENT, 4463 Lower Layer Precedence Mapping. 4465 A router which implements Lower Layer Precedence 4466 Mapping: 4468 + MUST be able to map IP Precedence to Link Layer 4469 priority mechanisms for link layers that have such 4470 a feature defined. 4472 + MUST have a configuration option to select the 4473 Link Layer's default priority treatment for all IP 4474 traffic 4476 + SHOULD be able to configure specific nonstandard 4477 mappings of IP precedence values to Link Layer 4478 priority values for each interface. 4480 DISCUSSION: 4481 Some research questions the workability of the 4482 priority features of some Link Layer protocols, 4483 and some networks may have faulty implementations 4484 of the link layer priority mechanism. It seems 4485 prudent to provide an escape mechanism in case 4486 such problems show up in a network. 4488 On the other hand, there are proposals to use 4489 novel queueing strategies to implement special 4490 services such as low-delay service. Special 4491 services and queueing strategies to support them 4492 need further research and experimentation before 4493 they are put into widespread use in the Internet. 4494 Since these requirements are intended to encourage 4495 (but not force) the use of precedence features in 4496 the hope of providing better Internet service to 4497 all users, routers supporting precedence-ordered 4498 queue service should default to maintaining strict 4499 precedence ordering regardless of the type of 4500 service requested. 4502 Implementors may wish to consider that correct 4503 link layer mapping of IP precedence is required by 4504 DOD policy for TCP/IP systems used on DOD 4505 networks. 4507 5.3.3.3 Precedence Handling For All Routers 4509 A router (whether or not it employs precedence- 4510 ordered queue service): 4512 (1) MUST accept and process incoming traffic of all 4513 precedence levels normally, unless it has been 4514 administratively configured to do otherwise. 4516 (2) MAY implement a validation filter to 4517 administratively restrict the use of precedence 4518 levels by particular traffic sources. If 4519 provided, this filter MUST NOT filter out or cut 4520 off the following sorts of ICMP error messages: 4521 Destination Unreachable, Redirect, Time 4522 Exceeded, and Parameter Problem. If this filter 4523 is provided, the procedures required for packet 4524 filtering by addresses are required for this 4525 filter also. 4527 DISCUSSION: 4528 Precedence filtering should be applicable to 4529 specific source/destination IP Address pairs, 4530 specific protocols, specific ports, and so 4531 on. 4533 An ICMP Destination Unreachable message with 4534 code 14 SHOULD be sent when a packet is dropped 4535 by the validation filter, unless this has been 4536 suppressed by configuration choice. 4538 (3) MAY implement a cutoff function which allows the 4539 router to be set to refuse or drop traffic with 4540 precedence below a specified level. This 4541 function may be activated by management actions 4542 or by some implementation dependent heuristics, 4543 but there MUST be a configuration option to 4544 disable any heuristic mechanism that operates 4545 without human intervention. An ICMP Destination 4546 Unreachable message with code 15 SHOULD be sent 4547 when a packet is dropped by the cutoff function, 4548 unless this has been suppressed by configuration 4549 choice. 4551 A router MUST NOT refuse to forward datagrams 4552 with IP precedence of 6 (Internetwork Control) 4553 or 7 (Network Control) solely due to precedence 4554 cutoff. However, other criteria may be used in 4555 conjunction with precedence cutoff to filter 4556 high precedence traffic. 4558 DISCUSSION: 4559 Unrestricted precedence cutoff could result 4560 in an unintentional cutoff of routing and 4561 control traffic. In general, host traffic 4562 should be restricted to a value of 5 4563 (CRITIC/ECP) or below although this is not a 4564 requirement and may not be valid in certain 4565 systems. 4567 (4) MUST NOT change precedence settings on packets 4568 it did not originate. 4570 (5) SHOULD be able to configure distinct precedence 4571 values to be used for each routing or management 4572 protocol supported (except for those protocols, 4573 such as OSPF, which specify which precedence 4574 value must be used). 4576 (6) MAY be able to configure routing or management 4577 traffic precedence values independently for each 4578 peer address. 4580 (7) MUST respond appropriately to Link Layer 4581 precedence-related error indications where 4582 provided. An ICMP Destination Unreachable 4583 message with code 15 SHOULD be sent when a 4584 packet is dropped because a link cannot accept 4585 it due to a precedence-related condition, unless 4586 this has been suppressed by configuration 4587 choice. 4589 DISCUSSION: 4590 The precedence cutoff mechanism described in 4591 (3) is somewhat controversial. Depending on 4592 the topological location of the area affected 4593 by the cutoff, transit traffic may be 4594 directed by routing protocols into the area 4595 of the cutoff, where it will be dropped. 4596 This is only a problem if another path which 4597 is unaffected by the cutoff exists between 4598 the communicating points. Proposed ways of 4599 avoiding this problem include providing some 4600 minimum bandwidth to all precedence levels 4601 even under overload conditions, or 4602 propagating cutoff information in routing 4603 protocols. In the absence of a widely 4604 accepted (and implemented) solution to this 4605 problem, great caution is recommended in 4606 activating cutoff mechanisms in transit 4607 networks. 4609 A transport layer relay could legitimately 4610 provide the function prohibited by (4) above. 4611 Changing precedence levels may cause subtle 4612 interactions with TCP and perhaps other 4613 protocols; a correct design is a non-trivial 4614 task. 4616 The intent of (5) and (6) (and the discussion 4617 of IP Precedence in ICMP messages in Section 4618 [4.3.2]) is that the IP precedence bits 4619 should be appropriately set, whether or not 4620 this router acts upon those bits in any other 4621 way. We expect that in the future 4622 specifications for routing protocols and 4623 network management protocols will specify how 4624 the IP Precedence should be set for messages 4625 sent by those protocols. 4627 The appropriate response for (7) depends on 4628 the link layer protocol in use. Typically, 4629 the router should stop trying to send 4630 "offensive" traffic to that destination for 4631 some period of time, and should return an 4632 ICMP Destination Unreachable message with 4633 code 15 (service not available for precedence 4634 requested) to the traffic source. It also 4635 should not try to reestablish a preempted 4636 Link Layer connection for some period of 4637 time. 4639 5.3.4 Forwarding of Link Layer Broadcasts 4641 The encapsulation of IP packets in most Link Layer 4642 protocols (except PPP) allows a receiver to distinguish 4643 broadcasts and multicasts from unicasts simply by 4644 examining the Link Layer protocol headers (most 4645 commonly, the Link Layer destination address). The 4646 rules in this section which refer to "Link Layer 4647 broadcasts" apply only to Link Layer protocols which 4648 allow broadcasts to be distinguished; likewise, the 4649 rules which refer to "Link Layer multicasts" apply only 4650 to Link Layer protocols which allow multicasts to be 4651 distinguished. 4653 A router MUST NOT forward any packet which the router 4654 received as a Link Layer broadcast (even if the IP 4655 destination address is also some form of broadcast 4656 address) unless the packet is an all-subnets-directed 4657 broadcast being forwarded as specified in [INTERNET:3]. 4659 DISCUSSION: 4660 As noted in Section [5.3.5.3], forwarding of all- 4661 subnets-directed broadcasts in accordance with 4662 [INTERNET:3] is optional and is not something that 4663 routers do by default. 4665 A router MUST NOT forward any packet which the router 4666 received as a Link Layer multicast unless the packet's 4667 destination address is an IP multicast address. 4669 A router SHOULD silently discard a packet that is 4670 received via a Link Layer broadcast but does not specify 4671 an IP multicast or IP broadcast destination address. 4673 When a router sends a packet as a Link Layer broadcast, 4674 the IP destination address MUST be a legal IP broadcast 4675 or IP multicast address. 4677 5.3.5 Forwarding of Internet Layer Broadcasts 4679 There are two major types of IP broadcast addresses; 4680 limited broadcast and directed broadcast. In addition, 4681 there are three subtypes of directed broadcast; a 4682 broadcast directed to a specified network, a broadcast 4683 directed to a specified subnetwork, and a broadcast 4684 directed to all subnets of a specified network. 4685 Classification by a router of a broadcast into one of 4686 these categories depends on the broadcast address and on 4687 the router's understanding (if any) of the subnet 4688 structure of the destination network. The same 4689 broadcast will be classified differently by different 4690 routers. 4692 A limited IP broadcast address is defined to be all- 4693 ones: { -1, -1 } or 255.255.255.255. 4695 A net-directed broadcast is composed of the network 4696 portion of the IP address with a local part of all-ones, 4697 { , -1 }. For example, a Class A net 4698 broadcast address is net.255.255.255, a Class B net 4699 broadcast address is net.net.255.255 and a Class C net 4700 broadcast address is net.net.net.255 where "net" is a 4701 byte of the network address. 4703 An all-subnets-directed broadcast is composed of the 4704 network part of the IP address with a subnet and a host 4705 part of all-ones, { , -1, -1 }. For 4706 example, an all-subnets broadcast on a subnetted class B 4707 network is net.net.255.255. A network must be known to 4708 be subnetted and the subnet part must be all-ones before 4709 a broadcast can be classified as all-subnets-directed. 4711 A subnet-directed broadcast address is composed of the 4712 network and subnet part of the IP address with a host 4713 part of all-ones, { , , 4714 -1 }. For example, a subnet-directed broadcast to 4715 subnet 2 of a class B network might be net.net.2.255 (if 4716 the subnet mask was 255.255.255.0) or net.net.1.127 (if 4717 the subnet mask was 255.255.255.128). A network must be 4718 known to be subnetted and the net and subnet part must 4719 not be all-ones before an IP broadcast can be classified 4720 as subnet-directed. 4722 As was described in Section [4.2.3.1], a router may 4723 encounter certain non-standard IP broadcast addresses: 4725 + 0.0.0.0 is an obsolete form of the limited broadcast 4726 address 4728 + { , 0 } is an obsolete form of a net- 4729 directed broadcast address. 4731 + { , 0, 0 } is an obsolete form of a 4732 all-subnets-directed broadcast address. 4734 + { , , 0 } is an 4735 obsolete form of a subnet-directed broadcast address. 4737 As was described in that section, packets addressed to 4738 any of these addresses SHOULD be silently discarded, but 4739 if they are not, they MUST be treated in accordance with 4740 the same rules that apply to packets addressed to the 4741 non-obsolete forms of the broadcast addresses described 4742 above. These rules are described in the next few 4743 sections. 4745 5.3.5.1 Limited Broadcasts 4747 Limited broadcasts MUST NOT be forwarded. Limited 4748 broadcasts MUST NOT be discarded. Limited broadcasts 4749 MAY be sent and SHOULD be sent instead of directed 4750 broadcasts where limited broadcasts will suffice. 4752 DISCUSSION: 4753 Some routers contain UDP servers which function by 4754 resending the requests (as unicasts or directed 4755 broadcasts) to other servers. This requirement 4756 should not be interpreted as prohibiting such 4757 servers. Note, however, that such servers can 4758 easily cause packet looping if misconfigured. 4759 Thus, providers of such servers would probably be 4760 well-advised to document their setup carefully and 4761 to consider carefully the TTL on packets which are 4762 sent. 4764 5.3.5.2 Net-directed Broadcasts 4766 A router MUST classify as net-directed broadcasts all 4767 valid, directed broadcasts destined for a remote 4768 network or an attached nonsubnetted network. A 4769 router MUST forward net-directed broadcasts. Net- 4770 directed broadcasts MAY be sent. 4772 A router MAY have an option to disable receiving net- 4773 directed broadcasts on an interface and MUST have an 4774 option to disable forwarding net-directed broadcasts. 4776 These options MUST default to permit receiving and 4777 forwarding net-directed broadcasts. 4779 DISCUSSION: 4780 There has been some debate about forwarding or not 4781 forwarding directed broadcasts. In this memo we 4782 have made the forwarding decision depend on the 4783 router's knowledge of the subnet mask for the 4784 destination network. Forwarding decisions for 4785 subnetted networks should be made by routers with 4786 an understanding of the subnet structure. 4787 Therefore, in general, routers must forward 4788 directed broadcasts for networks they are not 4789 attached to and for which they do not understand 4790 the subnet structure. One router may interpret 4791 and handle the same IP broadcast packet 4792 differently than another, depending on its own 4793 understanding of the structure of the destination 4794 (sub)network. 4796 5.3.5.3 All-subnets-directed Broadcasts 4798 A router MUST classify as all-subnets-directed 4799 broadcasts all valid directed broadcasts destined for 4800 a directly attached subnetted network which have all- 4801 ones in the subnet part of the address. If the 4802 destination network is not subnetted, the broadcast 4803 MUST be treated as a net-directed broadcast. 4805 A router MUST forward an all-subnets-directed 4806 broadcast as a link level broadcast out all physical 4807 interfaces connected to the IP network addressed by 4808 the broadcast, except that: 4810 + A router MUST NOT forward an all-subnet-directed 4811 broadcast that was received by the router as a 4812 Link Layer broadcast, unless the router is 4813 forwarding the broadcast in accordance with 4814 [INTERNET:3] (see below). 4816 + If a router receives an all-subnets-directed 4817 broadcast over a network which does not indicate 4818 via Link Layer framing whether the frame is a 4819 broadcast or a unicast, the packet MUST NOT be 4820 forwarded to any network which likewise does not 4821 indicate whether a frame is a broadcast. 4823 + A router MUST NOT forward an all-subnets-directed 4824 broadcast if the router is configured not to 4825 forward such broadcasts. A router MUST have a 4826 configuration option to deny forwarding of all- 4827 subnets-directed broadcasts. The configuration 4828 option MUST default to permit forwarding of all- 4829 subnets-directed broadcasts. 4831 EDITOR'S COMMENTS: 4832 The algorithm presented here is broken. The 4833 working group explicitly desired this algorithm, 4834 knowing its failures. 4836 The second bullet, above, prevents All Subnets 4837 Directed Broadcasts from traversing more than one 4838 PPP (or other serial) link in a row. Such a 4839 topology is easily conceived. Suppose that some 4840 corporation builds its corporate backbone out of 4841 PPP links, connecting routers at geographically 4842 dispersed locations. Suppose that this 4843 corporation has 3 sites (S1, S2, and S3) and there 4844 is a router at each site (R1, R2, and R3). At 4845 each site there are also several LANs connected to 4846 the local router. Let there be a PPP link 4847 connecting S1 to S2 and one connecting S2 to S3 4848 (i.e. the links are R1-R2 and R2-R3). So, if a 4849 host on a LAN at S1 sends a All Subnets Directed 4850 Broadcast, R1 will forward the broadcast over the 4851 R1-R2 link to R2. R2 will forward the broadcast 4852 to the LAN(s) connected to R2. Since the PPP does 4853 not differentiate broadcast from non-broadcast 4854 frames, R2 will NOT forward the broadcast onto the 4855 R2-R3 link. Therefore, the broadcast will not 4856 reach S3. 4858 [INTERNET:3] describes an alternative set of rules 4859 for forwarding of all-subnets-directed broadcasts 4860 (called multi-subnet-broadcasts in that document). A 4861 router MAY IMPLEMENT that alternative set of rules, 4862 but MUST use the set of rules described above unless 4863 explicitly configured to use the [INTERNET:3] rules. 4864 If routers will do [INTERNET:3]-style forwarding, 4865 then the router MUST have a configuration option 4866 which MUST default to doing the rules presented in 4867 this document. 4869 DISCUSSION: 4870 As far as we know, the rules for multi-subnet 4871 broadcasts described in [INTERNET:3] have never 4872 been implemented, suggesting that either they are 4873 too complex or the utility of multi-subnet 4874 broadcasts is low. The rules described in this 4875 section match current practice. In the future, we 4876 expect that IP multicast (see [INTERNET:4]) will 4877 be used to better solve the sorts of problems that 4878 multi-subnets broadcasts were intended to address. 4880 We were also concerned that hosts whose system 4881 managers neglected to configure with a subnet mask 4882 could unintentionally send multi-subnet 4883 broadcasts. 4885 A router SHOULD NOT originate all-subnets broadcasts, 4886 except as required by Section [4.3.3.9] when sending 4887 ICMP Address Mask Replies on subnetted networks. 4889 DISCUSSION: 4890 The current intention is to decree that (like 4891 0-filled IP broadcasts) the notion of the all- 4892 subnets broadcast is obsolete. It should be 4893 treated as a directed broadcast to the first 4894 subnet of the net in question that it appears on. 4896 Routers may implement a switch (default off) which 4897 if turned on enables the [INTERNET:3] behavior for 4898 all-subnets broadcasts. 4900 If a router has a configuration option to allow 4901 for forwarding all-subnet broadcasts, it should 4902 use a spanning tree, RPF, or other multicast 4903 forwarding algorithm (which may be computed for 4904 other purposes such as bridging or OSPF) to 4905 distribute the all-subnets broadcast efficiently. 4907 In general, it is better to use an IP multicast 4908 address rather than an all-subnets broadcast. 4910 5.3.5.4 Subnet-directed Broadcasts 4912 A router MUST classify as subnet-directed broadcasts 4913 all valid directed broadcasts destined for a directly 4914 attached subnetted network in which the subnet part 4915 is not all-ones. If the destination network is not 4916 subnetted, the broadcast MUST be treated as a net- 4917 directed broadcast. 4919 A router MUST forward subnet-directed broadcasts. 4921 A router MUST have a configuration option to prohibit 4922 forwarding of subnet-directed broadcasts. Its 4923 default setting MUST permit forwarding of subnet- 4924 directed broadcasts. 4926 A router MAY have a configuration option to prohibit 4927 forwarding of subnet-directed broadcasts from a 4928 source on a network on which the router has an 4929 interface. If such an option is provided, its 4930 default setting MUST permit forwarding of subnet- 4931 directed broadcasts. 4933 5.3.6 Congestion Control 4935 Congestion in a network is loosely defined as a 4936 condition where demand for resources (usually bandwidth 4937 or CPU time) exceeds capacity. Congestion avoidance 4938 tries to prevent demand from exceeding capacity, while 4939 congestion recovery tries to restore an operative state. 4940 It is possible for a router to contribute to both of 4941 these mechanisms. A great deal of effort has been spent 4942 studying the problem. The reader is encouraged to read 4943 [FORWARD:2] for a survey of the work. Important papers 4944 on the subject include [FORWARD:3], [FORWARD:4], 4945 [FORWARD:5], and [INTERNET:10], among others. 4947 The amount of storage that router should have available 4948 to handle peak instantaneous demand when hosts use 4949 reasonable congestion policies, such as described in 4950 [FORWARD:5], is a function of the product of the 4951 bandwidth of the link times the path delay of the flows 4952 using the link, and therefore storage should increase as 4953 this Bandwidth*Delay product increases. The exact 4954 function relating storage capacity to probability of 4955 discard is not known. 4957 When a router receives a packet beyond its storage 4958 capacity it must (by definition, not by decree) discard 4959 it or some other packet or packets. Which packet to 4960 discard is the subject of much study but, unfortunately, 4961 little agreement so far. 4963 A router MAY discard the packet it has just received; 4964 this is the simplest but not the best policy. It is 4965 considered better policy to randomly pick some transit 4966 packet on the queue and discard it (see [FORWARD:2]). A 4967 router MAY use this Random Drop algorithm to determine 4968 which packet to discard. 4970 If a router implements a discard policy (such as Random 4971 Drop) under which it chooses a packet to discard from 4972 among a pool of eligible packets: 4974 + If precedence-ordered queue service (described in 4975 Section [5.3.3.1]) is implemented and enabled, the 4976 router MUST NOT discard a packet whose IP precedence 4977 is higher than that of a packet which is not 4978 discarded. 4980 + A router MAY protect packets whose IP headers request 4981 the "maximize reliability" TOS, except where doing so 4982 would be in violation of the previous rule. 4984 + A router MAY protect fragmented IP packets, on the 4985 theory that dropping a fragment of a datagram may 4986 increase congestion by causing all fragments of the 4987 datagram to be retransmitted by the source. 4989 + To help prevent routing perturbations or disruption 4990 of management functions, the router MAY protect 4991 packets used for routing control, link control, or 4992 network management from being discarded. Dedicated 4993 routers (i.e.. routers which are not also general 4994 purpose hosts, terminal servers, etc.) can achieve an 4995 approximation of this rule by protecting packets 4996 whose source or destination is the router itself. 4998 Advanced methods of congestion control include a notion 4999 of fairness, so that the 'user' that is penalized by 5000 losing a packet is the one that contributed the most to 5001 the congestion. No matter what mechanism is implemented 5002 to deal with bandwidth congestion control, it is 5003 important that the CPU effort expended be sufficiently 5004 small that the router is not driven into CPU congestion 5005 also. 5007 As described in Section [4.3.3.3], this document 5008 recommends that a router should not send a Source Quench 5009 to the sender of the packet that it is discarding. ICMP 5010 Source Quench is a very weak mechanism, so it is not 5011 necessary for a router to send it, and host software 5012 should not use it exclusively as an indicator of 5013 congestion. 5015 5.3.7 Martian Address Filtering 5017 An IP source address is invalid if it is an IP broadcast 5018 address or is not a class A, B, or C address. 5020 An IP destination address is invalid if it is not a 5021 class A, B, C, or D address. 5023 A router SHOULD NOT forward any packet which has an 5024 invalid IP source address or a source address on network 5025 0. A router SHOULD NOT forward, except over a loopback 5026 interface, any packet which has a source address on 5027 network 127. A router MAY have a switch which allows 5028 the network manager to disable these checks. If such a 5029 switch is provided, it MUST default to performing the 5030 checks. 5032 A router SHOULD NOT forward any packet which has an 5033 invalid IP destination address or a destination address 5034 on network 0. A router SHOULD NOT forward, except over 5035 a loopback interface, any packet which has a destination 5036 address on network 127. A router MAY have a switch 5037 which allows the network manager to disable these 5038 checks. If such a switch is provided, it MUST default 5039 to performing the checks. 5041 If a router discards a packet because of these rules, it 5042 SHOULD log at least the IP source address, the IP 5043 destination address, and, if the problem was with the 5044 source address, the physical interface on which the 5045 packet was received and the Link Layer address of the 5046 host or router from which the packet was received. 5048 5.3.8 Source Address Validation 5050 A router SHOULD IMPLEMENT the ability to filter traffic 5051 based on a comparison of the source address of a packet 5052 and the forwarding table for a logical interface on 5053 which the packet was received. If this filtering is 5054 enabled, the router MUST silently discard a packet if 5055 the interface on which the packet was received is not 5056 the interface on which a packet would be forwarded to 5057 reach the address contained in the source address. In 5058 simpler terms, if a router wouldn't route a packet 5059 containing this address through a particular interface, 5060 it shouldn't believe the address if it appears as a 5061 source address in a packet read from this interface. 5063 If this feature is implemented, it MUST be disabled by 5064 default. 5066 DISCUSSION: 5067 This feature can provide useful security improvements 5068 in some situations, but can erroneously discard valid 5069 packets in situations where paths are asymmetric. 5071 5.3.9 Packet Filtering and Access Lists 5073 As a means of providing security and/or limiting traffic 5074 through portions of a network a router SHOULD provide 5075 the ability to selectively forward (or filter) packets. 5077 If this capability is provided, filtering of packets 5078 MUST be configurable either to forward all packets or to 5079 selectively forward them based upon the source and 5080 destination addresses. Each source and destination 5081 address SHOULD allow specification of an arbitrary mask. 5083 If supported, a router MUST be configurable to allow one 5084 of an 5086 + Include list -- specification of a list of address 5087 pairs to be forwarded, or an 5089 + Exclude list -- specification of a list of address 5090 pairs NOT to be forwarded. 5092 A router MAY provide a configuration switch which allows 5093 a choice between specifying an include or an exclude 5094 list. 5096 A value matching any address (e.g. a keyword "any" or an 5097 address with a mask of all 0's) MUST be allowed as a 5098 source and/or destination address. 5100 In addition to address pairs, the router MAY allow any 5101 combination of transport and/or application protocol and 5102 source and destination ports to be specified. 5104 The router MUST allow packets to be silently discarded 5105 (i.e.. discarded without an ICMP error message being 5106 sent). 5108 The router SHOULD allow an appropriate ICMP unreachable 5109 message to be sent when a packet is discarded. The ICMP 5110 message SHOULD specify Communication Administratively 5111 Prohibited (code 13) as the reason for the destination 5112 being unreachable. 5114 The router SHOULD allow the sending of ICMP destination 5115 unreachable messages (code 13) to be configured for each 5116 combination of address pairs, protocol types, and ports 5117 it allows to be specified. 5119 The router SHOULD count and SHOULD allow selective 5120 logging of packets not forwarded. 5122 5.3.10 Multicast Routing 5124 An IP router SHOULD support forwarding of IP multicast 5125 packets, based either on static multicast routes or on 5126 routes dynamically determined by a multicast routing 5127 protocol (e.g., DVMRP [ROUTE:9]). A router that 5128 forwards IP multicast packets is called a multicast 5129 router. 5131 5.3.11 Controls on Forwarding 5133 For each physical interface, a router SHOULD have a 5134 configuration option which specifies whether forwarding 5135 is enabled on that interface. When forwarding on an 5136 interface is disabled, the router: 5138 + MUST silently discard any packets which are received 5139 on that interface but are not addressed to the router 5141 + MUST NOT send packets out that interface, except for 5142 datagrams originated by the router 5144 + MUST NOT announce via any routing protocols the 5145 availability of paths through the interface 5147 DISCUSSION: 5148 This feature allows the network manager to 5149 essentially turn off an interface but leaves it 5150 accessible for network management. 5152 Ideally, this control would apply to logical rather 5153 than physical interfaces, but cannot because there is 5154 no known way for a router to determine which logical 5155 interface a packet arrived on when there is not a 5156 one-to-one correspondence between logical and 5157 physical interfaces. 5159 5.3.12 State Changes 5161 During the course of router operation, interfaces may 5162 fail or be manually disabled, or may become available 5163 for use by the router. Similarly, forwarding may be 5164 disabled for a particular interface or for the entire 5165 router or may be (re)enabled. While such transitions 5166 are (usually) uncommon, it is important that routers 5167 handle them correctly. 5169 5.3.12.1 When a Router Ceases Forwarding 5171 When a router ceases forwarding it MUST stop 5172 advertising all routes, except for third party 5173 routes. It MAY continue to receive and use routes 5174 from other routers in its routing domains. If the 5175 forwarding database is retained, the router MUST NOT 5176 cease timing the routes in the forwarding database. 5177 If routes that have been received from other routers 5178 are remembered, the router MUST NOT cease timing the 5179 routes which it has remembered. It MUST discard any 5180 routes whose timers expire while forwarding is 5181 disabled, just as it would do if forwarding were 5182 enabled. 5184 DISCUSSION: 5185 When a router ceases forwarding, it essentially 5186 ceases being a router. It is still a host, and 5187 must follow all of the requirements of Host 5188 Requirements [INTRO: 2]. The router may still be 5189 a passive member of one or more routing domains, 5190 however. As such, it is allowed to maintain its 5191 forwarding database by listening to other routers 5192 in its routing domain. It may not, however, 5193 advertise any of the routes in its forwarding 5194 database, since it itself is doing no forwarding. 5195 The only exception to this rule is when the router 5196 is advertising a route which uses only some other 5197 router, but which this router has been asked to 5198 advertise. 5200 A router MAY send ICMP destination unreachable (host 5201 unreachable) messages to the senders of packets that 5202 it is unable to forward. It SHOULD NOT send ICMP 5203 redirect messages. 5205 DISCUSSION: 5207 Note that sending an ICMP destination unreachable 5208 (host unreachable) is a router action. This 5209 message should not be sent by hosts. This 5210 exception to the rules for hosts is allowed so 5211 that packets may be rerouted in the shortest 5212 possible time, and so that "black holes" are 5213 avoided. 5215 5.3.12.2 When a Router Starts Forwarding 5217 When a router begins forwarding, it SHOULD expedite 5218 the sending of new routing information to all routers 5219 with which it normally exchanges routing information. 5221 5.3.12.3 When an Interface Fails or is Disabled 5223 If an interface fails or is disabled a router MUST 5224 remove and stop advertising all routes in its 5225 forwarding database which make use of that interface. 5226 It MUST disable all static routes which make use of 5227 that interface. If other routes to the same 5228 destination and TOS are learned or remembered by the 5229 router, the router MUST choose the best alternate, 5230 and add it to its forwarding database. The router 5231 SHOULD send ICMP destination unreachable or ICMP 5232 redirect messages, as appropriate, in reply to all 5233 packets which it is unable to forward due to the 5234 interface being unavailable. 5236 5.3.12.4 When an Interface is Enabled 5238 If an interface which had not been available becomes 5239 available, a router MUST reenable any static routes 5240 which use that interface. If routes which would use 5241 that interface are learned by the router, then these 5242 routes MUST be evaluated along with all of the other 5243 learned routes, and the router MUST make a decision 5244 as to which routes should be placed in the forwarding 5245 database. The implementor is referred to Chapter 5246 [7], "Application Layer -- Routing Protocols" for 5247 further information on how this decision is made. 5249 A router SHOULD expedite the sending of new routing 5250 information to all routers with which it normally 5251 exchanges routing information. 5253 5.3.13 IP Options 5255 Several options, such as Record Route and Timestamp, 5256 contain "slots" into which a router inserts its address 5257 when forwarding the packet. However, each such option 5258 has a finite number of slots, and therefore a router may 5259 find that there is not free slot into which it can 5260 insert its address. No requirement listed below should 5261 be construed as requiring a router to insert its address 5262 into an option that has no remaining slot to insert it 5263 into. Section [5.2.5] discusses how a router must 5264 choose which of its addresses to insert into an option. 5266 5.3.13.1 Unrecognized Options 5268 Unrecognized IP options in forwarded packets MUST be 5269 passed through unchanged. 5271 5.3.13.2 Security Option 5273 Some environments require the Security option in 5274 every packet; such a requirement is outside the scope 5275 of this document and the IP standard specification. 5276 Note, however, that the security options described in 5277 [INTERNET:1] and [INTERNET:16] are obsolete. Routers 5278 SHOULD IMPLEMENT the revised security option 5279 described in [INTERNET:5]. 5281 5.3.13.3 Stream Identifier Option 5283 This option is obsolete. If the Stream Identifier 5284 option is present in a packet forwarded by the 5285 router, the option MUST be ignored and passed through 5286 unchanged. 5288 5.3.13.4 Source Route Options 5290 A router MUST implement support for source route 5291 options in forwarded packets. A router MAY implement 5292 a configuration option which, when enabled, causes 5293 all source-routed packets to be discarded. However, 5294 such an option MUST NOT be enabled by default. 5296 DISCUSSION: 5297 The ability to source route datagrams through the 5298 Internet is important to various network 5299 diagnostic tools. However, in a few rare cases, 5300 source routing may be used to bypass 5301 administrative and security controls within a 5302 network. Specifically, those cases where 5303 manipulation of routing tables is used to provide 5304 administrative separation in lieu of other methods 5305 such as packet filtering may be vulnerable through 5306 source routed packets. 5308 5.3.13.5 Record Route Option 5310 Routers MUST support the Record Route option in 5311 forwarded packets. 5313 A router MAY provide a configuration option which, if 5314 enabled, will cause the router to ignore (i.e. pass 5315 through unchanged) Record Route options in forwarded 5316 packets. If provided, such an option MUST default to 5317 enabling the record-route. This option does not 5318 affect the processing of Record Route options in 5319 datagrams received by the router itself (in 5320 particular, Record Route options in ICMP echo 5321 requests will still be processed in accordance with 5322 Section [4.3.3.6]). 5324 DISCUSSION: 5325 There are some people who believe that Record 5326 Route is a security problem because it discloses 5327 information about the topology of the network. 5328 Thus, this document allows it to be disabled. 5330 5.3.13.6 Timestamp Option 5332 Routers MUST support the timestamp option in 5333 forwarded packets. A timestamp value MUST follow the 5334 rules given in Section [3.2.2.8] of [INTRO:2]. 5336 If the flags field = 3 (timestamp and prespecified 5337 address), the router MUST add its timestamp if the 5338 next prespecified address matches any of the router's 5339 IP addresses. It is not necessary that the 5340 prespecified address be either the address of the 5341 interface on which the packet arrived or the address 5342 of the interface over which it will be sent. 5344 IMPLEMENTATION: 5345 To maximize the utility of the timestamps 5346 contained in the timestamp option, it is suggested 5347 that the timestamp inserted be, as nearly as 5348 practical, the time at which the packet arrived at 5349 the router. For datagrams originated by the 5350 router, the timestamp inserted should be, as 5351 nearly as practical, the time at which the 5352 datagram was passed to the network layer for 5353 transmission. 5355 A router MAY provide a configuration option which, if 5356 enabled, will cause the router to ignore (i.e. pass 5357 through unchanged) Timestamp options in forwarded 5358 datagrams when the flag word is set to zero 5359 (timestamps only) or one (timestamp and registering 5360 IP address). If provided, such an option MUST 5361 default to off (that is, the router does not ignore 5362 the timestamp). This option does not affect the 5363 processing of Timestamp options in datagrams received 5364 by the router itself (in particular, a router will 5365 insert timestamps into Timestamp options in datagrams 5366 received by the router, and Timestamp options in ICMP 5367 echo requests will still be processed in accordance 5368 with Section [4.3.3.6]). 5370 DISCUSSION: 5371 Like the Record Route option, the Timestamp option 5372 can reveal information about a network's topology. 5373 Some people consider this to be a security 5374 concern. 5376 6. TRANSPORT LAYER 5378 A router is not required to implement any Transport Layer 5379 protocols except those required to support Application Layer 5380 protocols supported by the router. In practice, this means 5381 that most routers implement both the Transmission Control 5382 Protocol (TCP) and the User Datagram Protocol (UDP). 5384 6.1 USER DATAGRAM PROTOCOL -- UDP 5386 The User Datagram Protocol (UDP) is specified in [TRANS:1]. 5388 A router which implements UDP MUST be compliant, and SHOULD 5389 be unconditionally compliant, with the requirements of 5390 section 4.1.3 of [INTRO:2], except that: 5392 + This specification does not specify the interfaces 5393 between the various protocol layers. Thus, a router 5394 need not comply with sections 4.1.3.2, 4.1.3.3, and 5395 4.1.3.5 of [INTRO:2] (except of course where compliance 5396 is required for proper functioning of Application Layer 5397 protocols supported by the router). 5399 + Contrary to section 4.1.3.4 of [INTRO:2], an application 5400 MUST NOT be able to disable to generation of UDP 5401 checksums. 5403 DISCUSSION: 5404 Although a particular application protocol may require 5405 that UDP datagrams it receives must contain a UDP 5406 checksum, there is no general requirement that received 5407 UDP datagrams contain UDP checksums. Of course, if a 5408 UDP checksum is present in a received datagram, the 5409 checksum must be verified and the datagram discarded if 5410 the checksum is incorrect. 5412 6.2 TRANSMISSION CONTROL PROTOCOL -- TCP 5414 The Transmission Control Protocol (TCP) is specified in 5415 [TRANS:2]. 5417 A router which implements TCP MUST be compliant, and SHOULD 5418 be unconditionally compliant, with the requirements of 5419 section 4.2 of [INTRO:2], except that: 5421 + This specification does not specify the interfaces 5422 between the various protocol layers. Thus, a router 5423 need not comply with the following requirements of 5424 [INTRO:2] (except of course where compliance is required 5425 for proper functioning of Application Layer protocols 5426 supported by the router): 5428 Section 4.2.2.2: 5429 "Passing a received PSH flag to the application 5430 layer is now OPTIONAL." 5432 Section 4.2.2.4: 5433 "A TCP MUST inform the application layer 5434 asynchronously whenever it receives an Urgent 5435 pointer and there was previously no pending urgent 5436 data, or whenever the Urgent pointer advances in 5437 the data stream. There MUST be a way for the 5438 application to learn how much urgent data remains 5439 to be read from the connection, or at least to 5440 determine whether or not more urgent data remains 5441 to be read." 5443 Section 4.2.3.5: 5444 "An application MUST be able to set the value for 5445 R2 for a particular connection. For example, an 5446 interactive application might set R2 to 5447 ``infinity,'' giving the user control over when to 5448 disconnect." 5450 Section 4.2.3.7: 5451 "If an application on a multihomed host does not 5452 specify the local IP address when actively opening 5453 a TCP connection, then the TCP MUST ask the IP 5454 layer to select a local IP address before sending 5455 the (first) SYN. See the function GET_SRCADDR() in 5456 Section 3.4." 5458 Section 4.2.3.8: 5459 "An application MUST be able to specify a source 5460 route when it actively opens a TCP connection, and 5461 this MUST take precedence over a source route 5462 received in a datagram." 5464 + For similar reasons, a router need not comply with any 5465 of the requirements of section 4.2.4 of [INTRO:2]. 5467 + The requirements of section 4.2.2.6 of [INTRO:2] are 5468 amended as follows: a router which implements the host 5469 portion of MTU discovery (discussed in Section [4.2.3.3] 5470 of this memo) uses 536 as the default value of SendMSS 5471 only if the path MTU is unknown; if the path MTU is 5472 known, the default value for SendMSS is the path MTU - 5473 40. 5475 + The requirements of section 4.2.2.6 of [INTRO:2] are 5476 amended as follows: ICMP Destination Unreachable codes 5477 11 and 12 are additional soft error conditions. 5478 Therefore, these message MUST NOT cause TCP to abort a 5479 connection. 5481 DISCUSSION: 5482 It should particularly be noted that a TCP 5483 implementation in a router must conform to the following 5484 requirements of [INTRO:2]: 5486 + Providing a configurable TTL. [4.2.2.1] 5488 + Providing an interface to configure keep-alive 5489 behavior, if keep-alives are used at all. [4.2.3.6] 5491 + Providing an error reporting mechanism, and the 5492 ability to manage it. [4.2.4.1] 5494 + Specifying type of service. [4.2.4.2] 5496 The general paradigm applied is that if a particular 5497 interface is visible outside the router, then all 5498 requirements for the interface must be followed. For 5499 example, if a router provides a telnet function, then it 5500 will be generating traffic, likely to be routed in the 5501 external networks. Therefore, it must be able to set 5502 the type of service correctly or else the telnet traffic 5503 may not get through. 5505 7. APPLICATION LAYER -- ROUTING PROTOCOLS 5507 7.1 INTRODUCTION 5509 An Autonomous System (AS) is defined as a set of routers 5510 all belonging under the same authority and all subject to a 5511 consistent set of routing policies. Interior gateway 5512 protocols (IGPs) are used to distribute routing information 5513 inside of an AS (i.e. intra-AS routing). Exterior gateway 5514 protocols are used to exchange routing information between 5515 ASs (i.e. inter-AS routing). 5517 7.1.1 Routing Security Considerations 5519 Routing is one of the few places where the Robustness 5520 Principle ("be liberal in what you accept") does not 5521 apply. Routers should be relatively suspicious in 5522 accepting routing data from other routing systems. 5524 A router SHOULD provide the ability to rank routing 5525 information sources from "most trustworthy" to "least 5526 trustworthy" and to accept routing information about any 5527 particular destination from the most trustworthy sources 5528 first. This was implicit in the original core/stub 5529 autonomous system routing model using EGP and various 5530 interior routing protocols. It is even more important 5531 with the demise of a central, "trusted" core. 5533 A router SHOULD provide a mechanism to filter out 5534 "obviously invalid" routes (such as those for net 127). 5536 Routers MUST NOT by default redistribute routing data 5537 they do not themselves use, trust or otherwise consider 5538 invalid. In rare cases, it may be necessary to 5539 redistribute suspicious information, but this should 5540 only happen under direct intercession by some human 5541 agency. 5543 In general, routers must be at least a little paranoid 5544 about accepting routing data from anyone, and must be 5545 especially careful when they distribute routing 5546 information provided to them by another party. See 5547 below for specific guidelines. 5549 Routers SHOULD IMPLEMENT peer-to-peer authentication for 5550 those routing protocols that support them. 5552 7.1.2 Precedence 5554 Except where the specification for a particular routing 5555 protocol specifies otherwise, a router SHOULD set the IP 5556 Precedence value for IP datagrams carrying routing 5557 traffic it originates to 6 (INTERNETWORK CONTROL). 5559 DISCUSSION: 5560 Routing traffic with VERY FEW exceptions should be 5561 the highest precedence traffic on any network. If a 5562 system's routing traffic can't get through, chances 5563 are nothing else will. 5565 7.2 INTERIOR GATEWAY PROTOCOLS 5567 7.2.1 INTRODUCTION 5569 An Interior Gateway Protocol (IGP) is used to distribute 5570 routing information between the various routers in a 5571 particular AS. Independent of the algorithm used to 5572 implement a particular IGP, it should perform the 5573 following functions: 5575 (1) Respond quickly to changes in the internal topology 5576 of an AS 5578 (2) Provide a mechanism such that circuit flapping does 5579 not cause continuous routing updates 5581 (3) Provide quick convergence to loop-free routing 5583 (4) Utilize minimal bandwidth 5584 (5) Provide "equal cost" routes to enable "load- 5585 splitting" 5587 (6) Provide a means for authentication of routing 5588 updates 5590 Current IGPs used in the internet today are 5591 characterized as either being being based on a distance- 5592 vector or a link-state algorithm. 5594 Several IGPs are detailed in this section, including 5595 those most commonly used and some recently developed 5596 protocols which may be widely used in the future. 5597 Numerous other protocols intended for use in intra-AS 5598 routing exist in the Internet community. 5600 A router which implements any routing protocol (other 5601 than static routes) MUST IMPLEMENT OSPF (see Section 5602 [7.2.2]) and MUST IMPLEMENT RIP (see Section [7.2.4]). 5603 A router MAY implement additional IGPs. 5605 7.2.2 OPEN SHORTEST PATH FIRST -- OSPF 5607 7.2.2.1 Introduction 5609 Shortest Path First (SPF) based routing protocols are 5610 a class of link-state algorithms which are based on 5611 the shortest-path algorithm of Dijkstra. Although 5612 SPF based algorithms have been around since the 5613 inception of the ARPANet, it is only recently that 5614 they have achieved popularity both inside both the IP 5615 and the OSI communities. In an SPF based system, 5616 each router obtains an exact replica of the entire 5617 topology database via a process known as flooding. 5618 Flooding insures a reliable transfer of the 5619 information. Each individual router then runs the SPF 5620 algorithm on its database to build the IP routing 5621 table. The OSPF routing protocol is an 5622 implementation of an SPF algorithm. The current 5623 version, OSPF version 2, is specified in [ROUTE:1]. 5624 Note that RFC-1131, which describes OSPF version 1, 5625 is obsolete. 5627 Note that to comply with Section [8.3] of this memo, 5628 a router which implements OSPF MUST implement the 5629 OSPF MIB [MGT:14]. 5631 7.2.2.2 Specific Issues 5633 Virtual Links 5635 There is a minor error in the specification that 5636 can cause routing loops when all of the 5637 following conditions are simultaneously true: 5639 (1) A virtual link is configured through a 5640 transit area, 5642 (2) Two separate paths exist, each having the 5643 same endpoints, but one utilizing only non- 5644 virtual backbone links, and the other using 5645 links in the transit area, and 5647 (3) The latter path is part of the (underlying 5648 physical representation of the) configured 5649 virtual link, routing loops may occur. 5651 To prevent this, an implementation of OSPF 5652 SHOULD invoke the calculation in Section 16.3 of 5653 [ROUTE:1] whenever any part of the path to the 5654 destination is a virtual link (the specification 5655 only says this is necessary when the first hop 5656 is a virtual link). 5658 7.2.2.3 New Version of OSPF 5660 As of this writing (12/21/93) there is a new version 5661 of the OSPF specification that is winding its way 5662 through the Internet standardization process. A 5663 prudent implementor will be aware of this and develop 5664 an implementation accordingly. 5666 The new version fixes several errors in the current 5667 specification [ROUTE:1]. For this reason, 5668 implementors and vendors ought to expect to upgrade 5669 to the new version relatively soon. In particular, 5670 the following problems exist in [ROUTE:1] that the 5671 new version fixes: 5673 + In [ROUTE:1], certain configurations of virtual 5674 links can lead to incorrect routing and/or routing 5675 loops. A fix for this is specified in the new 5676 specification. 5678 + In [ROUTE:1], OSPF external routes to "subnet 0"s 5679 cannot be expressed. For example, a router cannot 5680 import into an OSPF domain external routes both 5681 for 192.2.0.0, 255.255.0.0 and 192.2.0.0, 5682 255.255.255.0. Routes such as these may become 5683 common with the deployment of CIDR [INTERNET:15]. 5684 This has been addressed in the new OSPF 5685 specification. 5687 + In [ROUTE:1], OSPF Network-LSAs originated before 5688 a router changes its OSPF Router ID can confuse 5689 the Dijkstra calculation if the router again 5690 becomes Designated Router for the network. This 5691 has been fixed. 5693 7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM -- DUAL 5694 IS-IS 5696 The American National Standards Institute (ANSI) X3S3.3 5697 committee has defined an intra-domain routing protocol. 5698 This protocol is titled "Intermediate System to 5699 Intermediate System Routeing Exchange Protocol". 5701 Its application to an IP network has been defined in 5702 [ROUTE:2], and is referred to as Dual IS-IS (or 5703 sometimes as Integrated IS-IS). IS-IS is based on a 5704 link-state (SPF) routing algorithm and shares all the 5705 advantages for this class of protocols. 5707 7.2.4 ROUTING INFORMATION PROTOCOL -- RIP 5709 7.2.4.1 Introduction 5711 RIP is specified in [ROUTE:3]. Although RIP is still 5712 quite important in the Internet, it is being replaced 5713 in sophisticated applications by more modern IGPs 5714 such as the ones described above. 5716 Another common use for RIP is as a "router discovery" 5717 protocol. Section [4.3.3.10] briefly touches upon 5718 this subject. 5720 7.2.4.2 Protocol Walk-Through 5722 Dealing with changes in topology: [ROUTE:3], pp. 11 5724 An implementation of RIP MUST provide a means 5725 for timing out routes. Since messages are 5726 occasionally lost, implementations MUST NOT 5727 invalidate a route based on a single missed 5728 update. 5730 Implementations MUST by default wait six times 5731 the update interval before invalidating a route. 5732 A router MAY have configuration options to alter 5733 this value. 5735 DISCUSSION: 5736 It is important to routing stability that all 5737 routers in a RIP autonomous system use 5738 similar timeout value for invalidating 5739 routes, and therefore it is important that an 5740 implementation default to the timeout value 5741 specified in the RIP specification. However, 5742 that timeout value is overly conservative in 5743 environments where packet loss is reasonably 5744 rare. In such an environment, a network 5745 manager may wish to be able to decrease the 5746 timeout period in order to promote faster 5747 recovery from failures. 5749 IMPLEMENTATION: 5750 There is a very simple mechanism which a 5751 router may use to meet the requirement to 5752 invalidate routes promptly after they time 5753 out. Whenever the router scans the routing 5754 table to see if any routes have timed out, it 5755 also notes the age of the least recently 5756 updated route which has not yet timed out. 5757 Subtracting this age from the timeout period 5758 gives the amount of time until the router 5759 again needs to scan the table for timed out 5760 routes. 5762 Split Horizon: [ROUTE:3], pp. 14-15 5764 An implementation of RIP MUST implement "split 5765 horizon", a scheme used for avoiding problems 5766 caused by including routes in updates sent to 5767 the router from which they were learned. 5769 An implementation of RIP SHOULD implement "Split 5770 horizon with poisoned reverse", a variant of 5771 split horizon which includes routes learned from 5772 a router sent to that router, but sets their 5773 metric to infinity. Because of the routing 5774 overhead which may be incurred by implementing 5775 split horizon with poisoned reverse, 5776 implementations MAY include an option to select 5777 whether poisoned reverse is in effect. An 5778 implementation SHOULD limit the period of time 5779 in which it sends reverse routes at an infinite 5780 metric. 5782 IMPLEMENTATION: 5783 Each of the following algorithms can be used 5784 to limit the period of time for which 5785 poisoned reverse is applied to a route. The 5786 first algorithm is more complex but does a 5787 more complete job of limiting poisoned 5788 reverse to only those cases where it is 5789 necessary. 5791 The goal of both algorithms is to ensure that 5792 poison reverse is done for any destination 5793 whose route has changed in the last Route 5794 Lifetime (typically 180 seconds), unless it 5795 can be sure that the previous route used the 5796 same output interface. The Route Lifetime is 5797 used because that is the amount of time RIP 5798 will keep around an old route before 5799 declaring it stale. 5801 The time intervals (and derived variables) 5802 used in the following algorithms are as 5803 follows: 5805 Tu The Update Timer; the number of seconds 5806 between RIP updates. This typically 5807 defaults to 30 seconds. 5809 Rl The Route Lifetime, in seconds. This is 5810 the amount of time that a route is 5811 presumed to be good, without requiring 5812 an update. This typically defaults to 5813 180 seconds. 5815 Ul The Update Loss; the number of 5816 consecutive updates that have to be lost 5817 or fail to mention a route before RIP 5818 deletes the route. Ul is calculated to 5819 be (Rl/Tu)+1. The "+1" is to account 5820 for the fact that the first time the 5821 ifcounter is decremented will be less 5822 than Tu seconds after it is initialized. 5823 Typically, Ul will be 7: (180/30)+1. 5825 In The value to set ifcounter to when a 5826 destination is newly learned. This 5827 value is Ul-4, where the "4" is RIP's 5828 garbage collection timer/30 5830 The first algorithm is: 5832 -- Associated with each destination is a 5833 counter, called the ifcounter below. 5834 Poison reverse is done for any route whose 5835 destination's ifcounter is greater than 5836 zero. 5838 -- After a regular (not triggered or in 5839 response to a request) update is sent, all 5840 of the non-zero ifcounters are decremented 5841 by one. 5843 -- When a route to a destination is created, 5844 its ifcounter is set as follows: 5846 -- If the new route is superseding a valid 5847 route, and the old route used a 5848 different (logical) output interface, 5849 then the ifcounter is set to Ul. 5851 -- If the new route is superseding a stale 5852 route, and the old route used a 5853 different (logical) output interface, 5854 then the ifcounter is set to MAX(0, Ul 5855 - INT(seconds that the route has been 5856 stale/Ut). 5858 -- If there was no previous route to the 5859 destination, the ifcounter is set to 5860 In. 5862 -- Otherwise, the ifcounter is set to zero 5864 -- RIP also maintains a timer, called the 5865 resettimer below. Poison reverse is done 5866 on all routes whenever resettimer has not 5867 expired (regardless of the ifcounter 5868 values). 5870 -- When RIP is started, restarted, reset, or 5871 otherwise has its routing table cleared, 5872 it sets the resettimer to go off in Rl 5873 seconds. 5875 The second algorithm is identical to the 5876 first except that: 5878 -- The rules which set the ifcounter to non- 5879 zero values are changed to always set it 5880 to Rl/Tu, and 5882 -- The resettimer is eliminated. 5884 Triggered updates: [ROUTE:3], pp. 15-16; pp. 29 5886 Triggered updates (also called "flash 5887 updates") are a mechanism for immediately 5888 notifying a router's neighbors when the 5889 router adds or deletes routes or changes 5890 their metrics. A router MUST send a 5891 triggered update when routes are deleted or 5892 their metrics are increased. A router MAY 5893 send a triggered update when routes are added 5894 or their metrics decreased. 5896 Since triggered updates can cause excessive 5897 routing overhead, implementations MUST use 5898 the following mechanism to limit the 5899 frequency of triggered updates: 5901 (1) When a router sends a triggered update, 5902 it sets a timer to a random time between 5903 one and five seconds in the future. The 5904 router must not generate additional 5905 triggered updates before this timer 5906 expires. 5908 (2) If the router would generate a triggered 5909 update during this interval it sets a 5910 flag indicating that a triggered update 5911 is desired. The router also logs the 5912 desired triggered update. 5914 (3) When the triggered update timer expires, 5915 the router checks the triggered update 5916 flag. If the flag is set then the router 5917 sends a single triggered update which 5918 includes all of the changes that were 5919 logged. The router then clears the flag 5920 and, since a triggered update was sent, 5921 restarts this algorithm. 5923 (4) The flag is also cleared whenever a 5924 regular update is sent. 5926 Triggered updates SHOULD include all routes 5927 that have changed since the most recent 5928 regular (non-triggered) update. Triggered 5929 updates MUST NOT include routes that have not 5930 changed since the most recent regular update. 5932 DISCUSSION: 5933 Sending all routes, whether they have 5934 changed recently or not, is unacceptable 5935 in triggered updates because the 5936 tremendous size of many Internet routing 5937 tables could otherwise result in 5938 considerable bandwidth being wasted on 5939 triggered updates. 5941 Use of UDP: [ROUTE:3], pp. 18-19. 5943 RIP packets sent to an IP broadcast address 5944 SHOULD have their initial TTL set to one. 5946 Note that to comply with Section [6.1] of 5947 this memo, a router MUST use UDP checksums in 5948 RIP packets which it originates, MUST discard 5949 RIP packets received with invalid UDP 5950 checksums, but MUST not discard received RIP 5951 packets simply because they do not contain 5952 UDP checksums. 5954 Addressing Considerations: [ROUTE:3], pp. 22 5956 A RIP implementation SHOULD support host 5957 routes. If it does not, it MUST (as 5958 described on page 27 of [ROUTE:3]) ignore 5959 host routes in received updates. A router 5960 MAY log ignored hosts routes. 5962 The special address 0.0.0.0 is used to 5963 describe a default route. A default route is 5964 used as the route of last resort (i.e. when a 5965 route to the specific net does not exist in 5966 the routing table). The router MUST be able 5967 to create a RIP entry for the address 5968 0.0.0.0. 5970 Input Processing - Response: [ROUTE:3], pp. 26 5972 When processing an update, the following 5973 validity checks MUST be performed: 5975 + The response MUST be from UDP port 520. 5977 + The source address MUST be on a directly 5978 connected subnet (or on a directly 5979 connected, non-subnetted network) to be 5980 considered valid. 5982 + The source address MUST NOT be one of the 5983 router's addresses. 5985 DISCUSSION: 5986 Some networks, media, and interfaces 5987 allow a sending node to receive packets 5988 that it broadcasts. A router must not 5989 accept its own packets as valid routing 5990 updates and process them. The last 5991 requirement prevents a router from 5992 accepting its own routing updates and 5993 processing them (on the assumption that 5994 they were sent by some other router on 5995 the network). 5997 An implementation MUST NOT replace an 5998 existing route if the metric received is 5999 equal to the existing metric except in 6000 accordance with the following heuristic. 6002 An implementation MAY choose to implement the 6003 following heuristic to deal with the above 6004 situation. Normally, it is useless to change 6005 the route to a network from one router to 6006 another if both are advertised at the same 6007 metric. However, the route being advertised 6008 by one of the routers may be in the process 6009 of timing out. Instead of waiting for the 6010 route to timeout, the new route can be used 6011 after a specified amount of time has elapsed. 6012 If this heuristic is implemented, it MUST 6013 wait at least halfway to the expiration point 6014 before the new route is installed. 6016 7.2.4.3 Specific Issues 6018 RIP Shutdown 6020 An implementation of RIP SHOULD provide for a 6021 graceful shutdown using the following steps: 6023 (1) Input processing is terminated, 6025 (2) Four updates are generated at random 6026 intervals of between two and four seconds, 6027 These updates contain all routes that were 6028 previously announced, but with some metric 6029 changes. Routes that were being announced 6030 at a metric of infinity should continue to 6031 use this metric. Routes that had been 6032 announced with a non-infinite metric should 6033 be announced with a metric of 15 (infinity 6034 - 1). 6036 DISCUSSION: 6037 The metric used for the above really 6038 ought to be 16 (infinity); setting it to 6039 15 is a kludge to avoid breaking certain 6040 old hosts which wiretap the RIP 6041 protocol. Such a host will 6042 (erroneously) abort a TCP connection if 6043 it tries to send a datagram on the 6044 connection while the host has no route 6045 to the destination (even if the period 6046 when the host has no route lasts only a 6047 few seconds while RIP chooses an 6048 alternate path to the destination). 6050 RIP Split Horizon and Static Routes 6052 Split horizon SHOULD be applied to static routes 6053 by default. An implementation SHOULD provide a 6054 way to specify, per static route, that split 6055 horizon should not be applied to this route. 6057 7.2.5 GATEWAY TO GATEWAY PROTOCOL -- GGP 6059 The Gateway to Gateway protocol is considered obsolete 6060 and SHOULD NOT be implemented. 6062 7.3 EXTERIOR GATEWAY PROTOCOLS 6064 7.3.1 INTRODUCTION 6066 Exterior Gateway Protocols are utilized for inter- 6067 Autonomous System routing to exchange reachability 6068 information for a set of networks internal to a 6069 particular autonomous system to a neighboring autonomous 6070 system. 6072 The area of inter-AS routing is a current topic of 6073 research inside the Internet Engineering Task Force. 6074 The Exterior Gateway Protocol (EGP) described in Section 6075 [7.3.3] has traditionally been the inter-AS protocol of 6076 choice. The Border Gateway Protocol (BGP) eliminates 6077 many of the restrictions and limitations of EGP, and is 6078 therefore growing rapidly in popularity. A router is 6079 not required to implement any inter-AS routing protocol. 6080 However, if a router does implement EGP it also MUST 6081 IMPLEMENT BGP. 6083 Although it was not designed as an exterior gateway 6084 protocol, RIP (described in Section [7.2.4]) is 6085 sometimes used for inter-AS routing. 6087 7.3.2 BORDER GATEWAY PROTOCOL -- BGP 6089 7.3.2.1 Introduction 6091 The Border Gateway Protocol (BGP) is an inter-AS 6092 routing protocol which exchanges network reachability 6093 information with other BGP speakers. The information 6094 for a network includes the complete list of ASs that 6095 traffic must transit to reach that network. This 6096 information can then be used to insure loop-free 6097 paths. This information is sufficient to construct a 6098 graph of AS connectivity from which routing loops may 6099 be pruned and some policy decisions at the AS level 6100 may be enforced. 6102 BGP is defined by [ROUTE:4]. [ROUTE:5] specifies the 6103 proper usage of BGP in the Internet, and provides 6104 some useful implementation hints and guidelines. 6105 [ROUTE:12] and [ROUTE:13] provide additional useful 6106 information. 6108 To comply with Section [8.3] of this memo, a router 6109 which implements BGP MUST also implement the BGP MIB 6110 [MGT:15]. 6112 To characterize the set of policy decisions that can 6113 be enforced using BGP, one must focus on the rule 6114 that an AS advertises to its neighbor ASs only those 6115 routes that it itself uses. This rule reflects the 6116 "hop-by-hop" routing paradigm generally used 6117 throughout the current Internet. Note that some 6118 policies cannot be supported by the "hop-by-hop" 6119 routing paradigm and thus require techniques such as 6120 source routing to enforce. For example, BGP does not 6121 enable one AS to send traffic to a neighbor AS 6122 intending that that traffic take a different route 6123 from that taken by traffic originating in the 6124 neighbor AS. On the other hand, BGP can support any 6125 policy conforming to the "hop-by-hop" routing 6126 paradigm. 6128 Implementors of BGP are strongly encouraged to follow 6129 the recommendations outlined in Section 6 of 6130 [ROUTE:5]. 6132 7.3.2.2 Protocol Walk-through 6134 While BGP provides support for quite complex routing 6135 policies (as an example see Section 4.2 in 6136 [ROUTE:5]), it is not required for all BGP 6137 implementors to support such policies. At a minimum, 6138 however, a BGP implementation: 6140 (1) SHOULD allow an AS to control announcements of 6141 the BGP learned routes to adjacent AS's. 6142 Implementations SHOULD support such control with 6143 at least the granularity of a single network. 6144 Implementations SHOULD also support such control 6145 with the granularity of an autonomous system, 6146 where the autonomous system may be either the 6147 autonomous system that originated the route, or 6148 the autonomous system that advertised the route 6149 to the local system (adjacent autonomous 6150 system). 6152 (2) SHOULD allow an AS to prefer a particular path 6153 to a destination (when more than one path is 6154 available). Such function SHOULD be implemented 6155 by allowing system administrator to assign 6156 "weights" to Autonomous Systems, and making 6157 route selection process to select a route with 6158 the lowest "weight" (where "weight" of a route 6159 is defined as a sum of "weights" of all AS's in 6160 the AS_PATH path attribute associated with that 6161 route). 6163 (3) SHOULD allow an AS to ignore routes with certain 6164 AS's in the AS_PATH path attribute. Such 6165 function can be implemented by using technique 6166 outlined in (2), and by assigning "infinity" as 6167 "weights" for such AS's. The route selection 6168 process must ignore routes that have "weight" 6169 equal to "infinity". 6171 7.3.3 EXTERIOR GATEWAY PROTOCOL -- EGP 6173 7.3.3.1 Introduction 6175 The Exterior Gateway Protocol (EGP) specifies an EGP 6176 which is used to exchange reachability information 6177 between routers of the same or differing autonomous 6178 systems. EGP is not considered a routing protocol 6179 since there is no standard interpretation (i.e. 6180 metric) for the distance fields in the EGP update 6181 message, so distances are comparable only among 6182 routers of the same AS. It is however designed to 6183 provide high-quality reachability information, both 6184 about neighbor routers and about routes to non- 6185 neighbor routers. 6187 EGP is defined by [ROUTE:6]. An implementor almost 6188 certainly wants to read [ROUTE:7] and [ROUTE:8] as 6189 well, for they contain useful explanations and 6190 background material. 6192 DISCUSSION: 6193 The present EGP specification has serious 6194 limitations, most importantly a restriction which 6195 limits routers to advertising only those networks 6196 which are reachable from within the router's 6197 autonomous system. This restriction against 6198 propagating "third party" EGP information is to 6199 prevent long-lived routing loops. This 6200 effectively limits EGP to a two-level hierarchy. 6202 RFC-975 is not a part of the EGP specification, 6203 and should be ignored. 6205 7.3.3.2 Protocol Walk-through 6207 Indirect Neighbors: RFC-888, pp. 26 6209 An implementation of EGP MUST include indirect 6210 neighbor support. 6212 Polling Intervals: RFC-904, pp. 10 6214 The interval between Hello command retransmissions 6215 and the interval between Poll retransmissions 6216 SHOULD be configurable but there MUST be a minimum 6217 value defined. 6219 The interval at which an implementation will 6220 respond to Hello commands and Poll commands SHOULD 6221 be configurable but there MUST be a minimum value 6222 defined. 6224 Network Reachability: RFC-904, pp. 15 6226 An implementation MUST default to not providing 6227 the external list of routers in other autonomous 6228 systems; only the internal list of routers 6229 together with the nets which are reachable via 6230 those routers should be included in an Update 6231 Response/Indication packet. However, an 6232 implementation MAY elect to provide a 6233 configuration option enabling the external list to 6234 be provided. An implementation MUST NOT include 6235 in the external list routers which were learned 6236 via the external list provided by a router in 6237 another autonomous system. An implementation MUST 6238 NOT send a network back to the autonomous system 6239 from which it is learned, i.e. it MUST do split- 6240 horizon on an autonomous system level. 6242 If more than 255 internal or 255 external routers 6243 need to be specified in a Network Reachability 6244 update, the networks reachable from routers that 6245 can not be listed MUST be merged into the list for 6246 one of the listed routers. Which of the listed 6247 routers is chosen for this purpose SHOULD be user 6248 configurable, but SHOULD default to the source 6249 address of the EGP update being generated. 6251 An EGP update contains a series of blocks of 6252 network numbers, where each block contains a list 6253 of network numbers reachable at a particular 6254 distance via a particular router. If more than 6255 255 networks are reachable at a particular 6256 distance via a particular router, they are split 6257 into multiple blocks (all of which have the same 6258 distance). Similarly, if more than 255 blocks are 6259 required to list the networks reachable via a 6260 particular router, the router's address is listed 6261 as many times as necessary to include all of the 6262 blocks in the update. 6263 Unsolicited Updates: RFC-904, pp. 16 6265 If a network is shared with the peer, an 6266 implementation MUST send an unsolicited update 6267 upon entry to the Up state assuming that the 6268 source network is the shared network. 6270 Neighbor Reachability: RFC-904, pp. 6, 13-15 6272 The table on page 6 which describes the values of 6273 j and k (the neighbor up and down thresholds) is 6274 incorrect. It is reproduced correctly here: 6276 Name Active Passive Description 6277 ----------------------------------------------- 6278 j 3 1 neighbor-up threshold 6279 k 1 0 neighbor-down threshold 6281 The value for k in passive mode also specified 6282 incorrectly in RFC-904, pp. 14 The values in 6283 parenthesis should read: 6285 (j = 1, k = 0, and T3/T1 = 4) 6287 As an optimization, an implementation can refrain 6288 from sending a Hello command when a Poll is due. 6289 If an implementation does so, it SHOULD provide a 6290 user configurable option to disable this 6291 optimization. 6293 Abort timer: RFC-904, pp. 6, 12, 13 6295 An EGP implementation MUST include support for the 6296 abort timer (as documented in section 4.1.4 of 6297 RFC-904). An implementation SHOULD use the abort 6298 timer in the Idle state to automatically issue a 6299 Start event to restart the protocol machine. 6300 Recommended values are P4 for a critical error 6301 (Administratively prohibited, Protocol Violation 6302 and Parameter Problem) and P5 for all others. The 6303 abort timer SHOULD NOT be started when a Stop 6304 event was manually initiated (such as via a 6305 network management protocol). 6307 Cease command received in Idle state: RFC-904, pp. 13 6309 When the EGP state machine is in the Idle state, 6310 it MUST reply to Cease commands with a Cease-ack 6311 response. 6313 Hello Polling Mode: RFC-904, pp. 11 6315 An EGP implementation MUST include support for 6316 both active and passive polling modes. 6318 Neighbor Acquisition Messages: RFC-904, pp. 18 6320 As noted the Hello and Poll Intervals should only 6321 be present in Request and Confirm messages. 6322 Therefore the length of an EGP Neighbor 6323 Acquisition Message is 14 bytes for a Request or 6324 Confirm message and 10 bytes for a Refuse, Cease 6325 or Cease-ack message. Implementations MUST NOT 6326 send 14 bytes for Refuse, Cease or Cease-ack 6327 messages but MUST allow for implementations that 6328 send 14 bytes for these messages. 6330 Sequence Numbers: RFC-904, pp. 10 6332 Response or indication packets received with a 6333 sequence number not equal to S MUST be discarded. 6334 The send sequence number S MUST be incremented 6335 just before the time a Poll command is sent and at 6336 no other times. 6338 7.3.4 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL 6340 It is possible to exchange routing information between 6341 two autonomous systems or routing domains without using 6342 a standard exterior routing protocol between two 6343 separate, standard interior routing protocols. The most 6344 common way of doing this is to run both interior 6345 protocols independently in one of the border routers 6346 with an exchange of route information between the two 6347 processes. 6349 As with the exchange of information from an EGP to an 6350 IGP, without appropriate controls these exchanges of 6351 routing information between two IGPs in a single router 6352 are subject to creation of routing loops. 6354 7.4 STATIC ROUTING 6356 Static routing provides a means of explicitly defining the 6357 next hop from a router for a particular destination. A 6358 router SHOULD provide a means for defining a static route 6359 to a destination, where the destination is defined by an 6360 address and an address mask. The mechanism SHOULD also 6361 allow for a metric to be specified for each static route. 6363 A router which supports a dynamic routing protocol MUST 6364 allow static routes to be defined with any metric valid for 6365 the routing protocol used. The router MUST provide the 6366 ability for the user to specify a list of static routes 6367 which may or may not be propagated via the routing 6368 protocol. In addition, a router SHOULD support the 6369 following additional information if it supports a routing 6370 protocol that could make use of the information. They are: 6372 + TOS, 6374 + Subnet mask, or 6376 + A metric specific to a given routing protocol that can 6377 import the route. 6379 DISCUSSION: 6380 We intend that one needs to support only the things 6381 useful to the given routing protocol. The need for TOS 6382 should not require the vendor to implement the other 6383 parts if they are not used. 6385 Whether a router prefers a static route over a dynamic 6386 route (or vice versa) or whether the associated metrics are 6387 used to choose between conflicting static and dynamic 6388 routes SHOULD be configurable for each static route. 6390 A router MUST allow a metric to be assigned to a static 6391 route for each routing domain that it supports. Each such 6392 metric MUST be explicitly assigned to a specific routing 6393 domain. For example: 6395 route 36.0.0.0 255.0.0.0 via 192.19.200.3 rip metric 3 6397 route 36.21.0.0 255.255.0.0 via 192.19.200.4 ospf 6398 inter-area metric 27 6400 route 36.22.0.0 255.255.0.0 via 192.19.200.5 egp 123 6401 metric 99 6403 route 36.23.0.0 255.255.0.0 via 192.19.200.6 igrp 47 6404 metric 1 2 3 4 5 6406 DISCUSSION: 6407 It has been suggested that, ideally, static routes 6408 should have preference values rather than metrics (since 6409 metrics can only be compared with metrics of other 6410 routes in the same routing domain, the metric of a 6411 static route could only be compared with metrics of 6412 other static routes). This is contrary to some current 6413 implementations, where static routes really do have 6414 metrics, and those metrics are used to determine whether 6415 a particular dynamic route overrides the static route to 6416 the same destination. Thus, this document uses the term 6417 metric rather than preference. 6419 This technique essentially makes the static route into a 6420 RIP route, or an OSPF route (or whatever, depending on 6421 the domain of the metric). Thus, the route lookup 6422 algorithm of that domain applies. However, this is NOT 6423 route leaking, in that coercing a static route into a 6424 dynamic routing domain does not authorize the router to 6425 redistribute the route into the dynamic routing domain. 6427 For static routes not put into a specific routing 6428 domain, the route lookup algorithm is: 6430 (1) Basic match 6432 (2) Longest match 6434 (3) Weak TOS (if TOS supported) 6436 (4) Best metric (where metric are implementation- 6437 defined) 6439 The last step may not be necessary, but it's useful in 6440 the case where you want to have a primary static route 6441 over one interface and a secondary static route over an 6442 alternate interface, with failover to the alternate path 6443 if the interface for the primary route fails. 6445 7.5 FILTERING OF ROUTING INFORMATION 6447 Each router within a network makes forwarding decisions 6448 based upon information contained within its forwarding 6449 database. In a simple network the contents of the database 6450 may be statically configured. As the network grows more 6451 complex, the need for dynamic updating of the forwarding 6452 database becomes critical to the efficient operation of the 6453 network. 6455 If the data flow through a network is to be as efficient as 6456 possible, it is necessary to provide a mechanism for 6457 controlling the propagation of the information a router 6458 uses to build its forwarding database. This control takes 6459 the form of choosing which sources of routing information 6460 should be trusted and selecting which pieces of the 6461 information to believe. The resulting forwarding database 6462 is a filtered version of the available routing information. 6464 In addition to efficiency, controlling the propagation of 6465 routing information can reduce instability by preventing 6466 the spread of incorrect or bad routing information. 6468 In some cases local policy may require that complete 6469 routing information not be widely propagated. 6471 These filtering requirements apply only to non-SPF-based 6472 protocols (and therefore not at all to routers which don't 6473 implement any distance vector protocols). 6475 7.5.1 Route Validation 6477 A router SHOULD log as an error any routing update 6478 advertising a route to network zero, subnet zero, or 6479 subnet -1, unless the routing protocol from which the 6480 update was received uses those values to encode special 6481 routes (such as default routes). 6483 7.5.2 Basic Route Filtering 6485 Filtering of routing information allows control of paths 6486 used by a router to forward packets it receives. A 6487 router should be selective in which sources of routing 6488 information it listens to and what routes it believes. 6489 Therefore, a router MUST provide the ability to specify: 6491 + On which logical interfaces routing information will 6492 be accepted and which routes will be accepted from 6493 each logical interface. 6495 + Whether all routes or only a default route is 6496 advertised on a logical interface. 6498 Some routing protocols do not recognize logical 6499 interfaces as a source of routing information. In such 6500 cases the router MUST provide the ability to specify 6502 + from which other routers routing information will be 6503 accepted. 6505 For example, assume a router connecting one or more leaf 6506 networks to the main portion or backbone of a larger 6507 network. Since each of the leaf networks has only one 6508 path in and out, the router can simply send a default 6509 route to them. It advertises the leaf networks to the 6510 main network. 6512 7.5.3 Advanced Route Filtering 6514 As the topology of a network grows more complex, the 6515 need for more complex route filtering arises. 6516 Therefore, a router SHOULD provide the ability to 6517 specify independently for each routing protocol: 6519 + Which logical interfaces or routers routing 6520 information (routes) will be accepted from and which 6521 routes will be believed from each other router or 6522 logical interface, 6524 + Which routes will be sent via which logical 6525 interface(s), and 6527 + Which routers routing information will be sent to, if 6528 this is supported by the routing protocol in use. 6530 In many situations it is desirable to assign a 6531 reliability ordering to routing information received 6532 from another router instead of the simple believe or 6533 don't believe choice listed in the first bullet above. 6534 A router MAY provide the ability to specify: 6536 + A reliability or preference to be assigned to each 6537 route received. A route with higher reliability will 6538 be chosen over one with lower reliability regardless 6539 of the routing metric associated with each route. 6541 If a router supports assignment of preferences, the 6542 router MUST NOT propagate any routes it does not prefer 6543 as first party information. If the routing protocol 6544 being used to propagate the routes does not support 6545 distinguishing between first and third party 6546 information, the router MUST NOT propagate any routes it 6547 does not prefer. 6549 DISCUSSION: 6550 For example, assume a router receives a route to 6551 network C from router R and a route to the same 6552 network from router S. If router R is considered 6553 more reliable than router S traffic destined for 6554 network C will be forwarded to router R regardless of 6555 the route received from router S. 6557 Routing information for routes which the router does not 6558 use (router S in the above example) MUST NOT be passed 6559 to any other router. 6561 7.6 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE 6563 Routers MUST be able to exchange routing information 6564 between separate IP interior routing protocols, if 6565 independent IP routing processes can run in the same 6566 router. Routers MUST provide some mechanism for avoiding 6567 routing loops when routers are configured for bi- 6568 directional exchange of routing information between two 6569 separate interior routing processes. Routers MUST provide 6570 some priority mechanism for choosing routes from among 6571 independent routing processes. Routers SHOULD provide 6572 administrative control of IGP-IGP exchange when used across 6573 administrative boundaries. 6575 Routers SHOULD provide some mechanism for translating or 6576 transforming metrics on a per network basis. Routers (or 6577 routing protocols) MAY allow for global preference of 6578 exterior routes imported into an IGP. 6580 DISCUSSION: 6581 Different IGPs use different metrics, requiring some 6582 translation technique when introducing information from 6583 one protocol into another protocol with a different form 6584 of metric. Some IGPs can run multiple instances within 6585 the same router or set of routers. In this case metric 6586 information can be preserved exactly or translated. 6588 There are at least two techniques for translation 6589 between different routing processes. The static (or 6590 reachability) approach uses the existence of a route 6591 advertisement in one IGP to generate a route 6592 advertisement in the other IGP with a given metric. The 6593 translation or tabular approach uses the metric in one 6594 IGP to create a metric in the other IGP through use of 6595 either a function (such as adding a constant) or a table 6596 lookup. 6598 Bi-directional exchange of routing information is 6599 dangerous without control mechanisms to limit feedback. 6600 This is the same problem that distance vector routing 6601 protocols must address with the split horizon technique 6602 and that EGP addresses with the third-party rule. 6603 Routing loops can be avoided explicitly through use of 6604 tables or lists of permitted/denied routes or implicitly 6605 through use of a split horizon rule, a no-third-party 6606 rule, or a route tagging mechanism. Vendors are 6607 encouraged to use implicit techniques where possible to 6608 make administration easier for network operators. 6610 8. APPLICATION LAYER -- NETWORK MANAGEMENT PROTOCOLS 6612 Note that this chapter supersedes any requirements stated in 6613 section 6.3 of [INTRO:3]. 6615 8.1 The Simple Network Management Protocol -- SNMP 6617 8.1.1 SNMP Protocol Elements 6619 Routers MUST be manageable by SNMP [MGT:3]. The SNMP 6620 MUST operate using UDP/IP as its transport and network 6621 protocols. Others MAY be supported (e.g., see [MGT:25, 6622 MGT:26, MGT:27, and MGT:28]). SNMP management 6623 operations MUST operate as if the SNMP was implemented 6624 on the router itself. Specifically, management 6625 operations MUST be effected by sending SNMP management 6626 requests to any of the IP addresses assigned to any of 6627 the router's interfaces. The actual management operation 6628 may be performed either by the router or by a proxy for 6629 the router. 6631 DISCUSSION: 6632 This wording is intended to allow management either 6633 by proxy, where the proxy device responds to SNMP 6634 packets which have one of the router's IP addresses 6635 in the packets destination address field, or the SNMP 6636 is implemented directly in the router itself and 6637 receives packets and responds to them in the proper 6638 manner. 6640 It is important that management operations can be 6641 sent to one of the router's IP Addresses. In 6642 diagnosing network problems the only thing 6643 identifying the router that is available may be one 6644 of the router's IP address; obtained perhaps by 6645 looking through another router's routing table. 6647 All SNMP operations (get, get-next, get-response, set, 6648 and trap) MUST be implemented. 6650 Routers MUST provide a mechanism for rate-limiting the 6651 generation of SNMP trap messages. Routers MAY provide 6652 this mechanism via the algorithms for asynchronous alert 6653 management described in [MGT:5]. 6655 DISCUSSION: 6656 Although there is general agreement about the need to 6657 rate-limit traps, there is not yet consensus on how 6658 this is best achieved. The reference cited is 6659 considered experimental. 6661 8.2 Community Table 6663 For the purposes of this specification, we assume that 6664 there is an abstract `community table' in the router. This 6665 table contains several entries, each entry for a specific 6666 community and containing the parameters necessary to 6667 completely define the attributes of that community. The 6668 actual implementation method of the abstract community 6669 table is, of course, implementation specific. 6671 A router's community table MUST allow for at least one 6672 entry and SHOULD allow for at least two entries. 6674 DISCUSSION: 6675 A community table with zero capacity is useless. It 6676 means that the router will not recognize any communities 6677 and, therefore, all SNMP operations will be rejected. 6679 Therefore, one entry is the minimal useful size of the 6680 table. Having two entries allows one entry to be 6681 limited to read-only access while the other would have 6682 write capabilities. 6684 Routers MUST allow the user to manually (i.e., without 6685 using SNMP) examine, add, delete and change entries in the 6686 SNMP community table. The user MUST be able to set the 6687 community name. The user MUST be able to configure 6688 communities as read-only (i.e., they do not allow SETs) or 6689 read-write (i.e., they do allow SETs). 6691 The user MUST be able to define at least one IP address to 6692 which traps are sent for each community. These addresses 6693 MUST be definable on a per-community basis. Traps MUST be 6694 enablable or disablable on a per-community basis. 6696 A router SHOULD provide the ability to specify a list of 6697 valid network managers for any particular community. If 6698 enabled, a router MUST validate the source address of the 6699 SNMP datagram against the list and MUST discard the 6700 datagram if its address does not appear. If the datagram 6701 is discarded the router MUST take all actions appropriate 6702 to an SNMP authentication failure. 6704 DISCUSSION: 6705 This is a rather limited authentication system, but 6706 coupled with various forms of packet filtering may 6707 provide some small measure of increased security. 6709 The community table MUST be saved in non-volatile storage. 6711 The initial state of the community table SHOULD contain one 6712 entry, with the community name string "public" and read- 6713 only access. The default state of this entry MUST NOT send 6714 traps. If it is implemented, then this entry MUST remain 6715 in the community table until the administrator changes it 6716 or deletes it. 6718 DISCUSSION: 6719 By default, traps are not sent to this community. Trap 6720 PDUs are sent to unicast IP addresses. This address must 6721 be configured into the router in some manner. Before the 6722 configuration occurs, there is no such address, so to 6723 whom should the trap be sent? Therefore trap sending to 6724 the "public" community defaults to be disabled. This 6725 can, of course, be changed by an administrative 6726 operation once the router is operational. 6728 8.3 Standard MIBS 6730 All MIBS relevant to a router's configuration are to be 6731 implemented. To wit: 6733 + The System, Interface, IP, ICMP, and UDP groups of MIB- 6734 II [MGT:2] MUST be implemented. 6736 + The Interface Extensions MIB [MGT:18] MUST be 6737 implemented. 6739 + The IP Forwarding Table MIB [MGT:20] MUST be 6740 implemented. 6742 + If the router implements TCP (e.g. for Telnet) then the 6743 TCP group of MIB-II [MGT:2] MUST be implemented. 6745 + If the router implements EGP then the EGP group of MIB- 6746 II [MGT:2] MUST be implemented. 6748 + If the router supports OSPF then the OSPF MIB [MGT:14] 6749 MUST be implemented. 6751 + If the router supports BGP then the BGP MIB [MGT:15] 6752 MUST be implemented. 6754 + If the router has Ethernet, 802.3, or StarLan interfaces 6755 then the Ethernet-Like MIB [MGT:6] MUST be implemented. 6757 + If the router has 802.4 interfaces then the 802.4 MIB 6758 [MGT:7] MAY be implemented. 6760 + If the router has 802.5 interfaces then the 802.5 MIB 6761 [MGT:8] MUST be implemented. 6763 + If the router has FDDI interfaces that implement ANSI 6764 SMT 7.3 then the FDDI MIB [MGT:9] MUST be implemented. 6766 + If the router has FDDI interfaces that implement ANSI 6767 SMT 6.2 then the FDDI MIB [MGT:29] MUST be implemented. 6769 + If the router has RS-232 interfaces then the RS-232 6770 [MGT:10] MIB MUST be implemented. 6772 + If the router has T1/DS1 interfaces then the T1/DS1 MIB 6773 [MGT:16] MUST be implemented. 6775 + If the router has T3/DS3 interfaces then the T3/DS3 MIB 6776 [MGT:17] MUST be implemented. 6778 + If the router has SMDS interfaces then the SMDS 6779 Interface Protocol MIB [MGT:19] MUST be implemented. 6781 + If the router supports PPP over any of its interfaces 6782 then the PPP MIBs [MGT:11], [MGT:12], and [MGT:13] MUST 6783 be implemented. 6785 + If the router supports RIP Version 2 then the RIP 6786 Version 2 MIB [MGT:21] MUST be implemented. 6788 + If the router supports X.25 over any of its interfaces 6789 then the X.25 MIBs [MGT:22, MGT:23 and MGT:24] MUST be 6790 implemented. 6792 8.4 Vendor Specific MIBS 6794 The Internet Standard and Experimental MIBs do not cover 6795 the entire range of statistical, state, configuration and 6796 control information that may be available in a network 6797 element. This information is, never the less, extremely 6798 useful. Vendors of routers (and other network devices) 6799 generally have developed MIB extensions that cover this 6800 information. These MIB extensions are called Vendor 6801 Specific MIBs. 6803 The Vendor Specific MIB for the router MUST provide access 6804 to all statistical, state, configuration, and control 6805 information that is not available through the Standard and 6806 Experimental MIBs that have been implemented. This 6807 information MUST be available for both monitoring and 6808 control operations. 6810 DISCUSSION: 6811 The intent of this requirement is to provide the ability 6812 to do anything on the router via SNMP that can be done 6813 via a console. A certain minimal amount of 6814 configuration is necessary before SNMP can operate 6815 (e.g., the router must have an IP address). This initial 6816 configuration can not be done via SNMP. However, once 6817 the initial configuration is done, full capabilities 6818 ought to be available via network management. 6820 The vendor SHOULD make available the specifications for all 6821 Vendor Specific MIB variables. These specifications MUST 6822 conform to the SMI [MGT:1] and the descriptions MUST be in 6823 the form specified in [MGT:4]. 6825 DISCUSSION: 6826 Making the Vendor Specific MIB available to the user is 6827 necessary. Without this information the users would not 6828 be able to configure their network management systems to 6829 be able to access the Vendor Specific parameters. These 6830 parameters would then be useless. 6832 The format of the MIB specification is also specified. 6833 Parsers which read MIB specifications and generate the 6834 needed tables for the network management station are 6835 available. These parsers generally understand only the 6836 standard MIB specification format. 6838 8.5 Saving Changes 6840 Parameters altered by SNMP MAY be saved to non-volatile 6841 storage. 6843 DISCUSSION: 6844 Reasons why this "requirement" is a MAY: 6846 + The exact physical nature of non-volatile storage is 6847 not specified in this document. Hence, parameters 6848 may be saved in NVRAM/EEPROM, local floppy or hard 6849 disk, or in some TFTP file server or BOOTP server, 6850 etc. Suppose that that this information is in a file 6851 that is retrieved via TFTP. In that case, a change 6852 made to a configuration parameter on the router would 6853 need to be propagated back to the file server holding 6854 the configuration file. Alternatively, the SNMP 6855 operation would need to be directed to the file 6856 server, and then the change somehow propagated to the 6857 router. The answer to this problem does not seem 6858 obvious. 6860 This also places more requirements on the host 6861 holding the configuration information than just 6862 having an available tftp server, so much more that 6863 its probably unsafe for a vendor to assume that any 6864 potential customer will have a suitable host 6865 available. 6867 + The timing of committing changed parameters to non- 6868 volatile storage is still an issue for debate. Some 6869 prefer to commit all changes immediately. Others 6870 prefer to commit changes to non-volatile storage only 6871 upon an explicit command. 6873 9. APPLICATION LAYER -- MISCELLANEOUS PROTOCOLS 6875 For all additional application protocols that a router 6876 implements, the router MUST be compliant and SHOULD be 6877 unconditionally compliant with the relevant requirements of 6878 [INTRO:3]. 6880 9.1 BOOTP 6882 9.1.1 Introduction 6884 The Bootstrap Protocol (BOOTP) is a UDP/IP-based 6885 protocol which allows a booting host to configure itself 6886 dynamically and without user supervision. BOOTP 6887 provides a means to notify a host of its assigned IP 6888 address, the IP address of a boot server host, and the 6889 name of a file to be loaded into memory and executed 6890 ([APPL:1]). Other configuration information such as the 6891 local subnet mask, the local time offset, the addresses 6892 of default routers, and the addresses of various 6893 Internet servers can also be communicated to a host 6894 using BOOTP ([APPL:2]). 6896 9.1.2 BOOTP Relay Agents 6898 In many cases, BOOTP clients and their associated BOOTP 6899 server(s) do not reside on the same IP network or 6900 subnet. In such cases, a third-party agent is required 6901 to transfer BOOTP messages between clients and servers. 6902 Such an agent was originally referred to as a "BOOTP 6903 forwarding agent." However, in order to avoid confusion 6904 with the IP forwarding function of a router, the name 6905 "BOOTP relay agent" has been adopted instead. 6907 DISCUSSION: 6908 A BOOTP relay agent performs a task which is distinct 6909 from a router's normal IP forwarding function. While 6910 a router normally switches IP datagrams between 6911 networks more-or-less transparently, a BOOTP relay 6912 agent may more properly be thought to receive BOOTP 6913 messages as a final destination and then generate new 6914 BOOTP messages as a result. One should resist the 6915 notion of simply forwarding a BOOTP message "straight 6916 through like a regular packet." 6918 This relay-agent functionality is most conveniently 6919 located in the routers which interconnect the clients 6920 and servers (although it may alternatively be located in 6921 a host which is directly connected to the client 6922 subnet). 6924 A router MAY provide BOOTP relay-agent capability. If 6925 it does, it MUST conform to the specifications in 6926 [APPL:3]. 6928 Section [5.2.3] discussed the circumstances under which 6929 a packet is delivered locally (to the router). All 6930 locally delivered UDP messages whose UDP destination 6931 port number is BOOTPS (67) are considered for special 6932 processing by the router's logical BOOTP relay agent. 6934 Sections [4.2.2.11] and [5.3.7] discussed invalid IP 6935 source addresses. According to these rules, a router 6936 must not forward any received datagram whose IP source 6937 address is 0.0.0.0. However, routers which support a 6938 BOOTP relay agent MUST accept for local delivery to the 6939 relay agent BOOTREQUEST messages whose IP source address 6940 is 0.0.0.0. 6942 10. OPERATIONS AND MAINTENANCE 6944 This chapter supersedes any requirements stated in section 6.2 6945 of [INTRO:3]. 6947 Facilities to support operation and maintenance (O&M) 6948 activities form an essential part of any router 6949 implementation. Although these functions do not seem to 6950 relate directly to interoperability, they are essential to the 6951 network manager who must make the router interoperate and must 6952 track down problems when it doesn't. This chapter also 6953 includes some discussion of router initialization and of 6954 facilities to assist network managers in securing and 6955 accounting for their networks. 6957 10.1 Introduction 6959 The following kinds of activities are included under router 6960 O&M: 6962 + Diagnosing hardware problems in the router's processor, 6963 in its network interfaces, or in its connected networks, 6964 modems, or communication lines. 6966 + Installing new hardware 6968 + Installing new software. 6970 + Restarting or rebooting the router after a crash. 6972 + Configuring (or reconfiguring) the router. 6974 + Detecting and diagnosing Internet problems such as 6975 congestion, routing loops, bad IP addresses, black 6976 holes, packet avalanches, and misbehaved hosts. 6978 + Changing network topology, either temporarily (e.g., to 6979 bypass a communication line problem) or permanently. 6981 + Monitoring the status and performance of the routers and 6982 the connected networks. 6984 + Collecting traffic statistics for use in (Inter-)network 6985 planning. 6987 + Coordinating the above activities with appropriate 6988 vendors and telecommunications specialists. 6990 Routers and their connected communication lines are often 6991 operated as a system by a centralized O&M organization. 6992 This organization may maintain a (Inter-)network operation 6993 center, or NOC, to carry out its O&M functions. It is 6994 essential that routers support remote control and 6995 monitoring from such a NOC through an Internet path, since 6996 routers might not be connected to the same network as their 6997 NOC. Since a network failure may temporarily preclude 6998 network access, many NOCs insist that routers be accessible 6999 for network management via an alternative means, often 7000 dialup modems attached to console ports on the routers. 7002 Since an IP packet traversing an internet will often use 7003 routers under the control of more than one NOC, Internet 7004 problem diagnosis will often involve cooperation of 7005 personnel of more than one NOC. In some cases, the same 7006 router may need to be monitored by more than one NOC, but 7007 only if necessary, because excessive monitoring could 7008 impact a router's performance. 7010 The tools available for monitoring at a NOC may cover a 7011 wide range of sophistication. Current implementations 7012 include multi-window, dynamic displays of the entire router 7013 system. The use of AI techniques for automatic problem 7014 diagnosis is proposed for the future. 7016 Router O&M facilities discussed here are only a part of the 7017 large and difficult problem of Internet management. These 7018 problems encompass not only multiple management 7019 organizations, but also multiple protocol layers. For 7020 example, at the current stage of evolution of the Internet 7021 architecture, there is a strong coupling between host TCP 7022 implementations and eventual IP-level congestion in the 7023 router system [OPER:1]. Therefore, diagnosis of congestion 7024 problems will sometimes require the monitoring of TCP 7025 statistics in hosts. There are currently a number of R&D 7026 efforts in progress in the area of Internet management and 7027 more specifically router O&M. These R&D efforts have 7028 already produced standards for router O&M. This is also an 7029 area in which vendor creativity can make a significant 7030 contribution. 7032 10.2 Router Initialization 7034 10.2.1 Minimum Router Configuration 7036 There exists a minimum set of conditions that must be 7037 satisfied before a router may forward packets. A router 7038 MUST NOT enable forwarding on any physical interface 7039 unless either: 7041 (1) The router knows the IP address and associated 7042 subnet mask of at least one logical interface 7043 associated with that physical interface, or 7045 (2) The router knows that the interface is an 7046 unnumbered interface and also knows its router-id. 7048 These parameters MUST be explicitly configured: 7050 + A router MUST NOT use factory-configured default 7051 values for its IP addresses, subnet masks, or router- 7052 id, and 7054 + A router MUST NOT assume that an unconfigured 7055 interface is an unnumbered interface. 7057 DISCUSSION: 7058 There have been instances in which routers have been 7059 shipped with vendor-installed default addresses for 7060 interfaces. In a few cases, this has resulted in 7061 routers advertising these default addresses into 7062 active networks. 7064 10.2.2 Address and Address Mask Initialization 7066 A router MUST allow its IP addresses and their subnet 7067 masks to be statically configured and saved in permanent 7068 storage. 7070 A router MAY obtain its IP addresses and their 7071 corresponding subnet masks dynamically as a side effect 7072 of the system initialization process (see Section 7073 10.2.3]); 7075 If the dynamic method is provided, the choice of method 7076 to be used in a particular router MUST be configurable. 7078 As was described in Section [4.2.2.11], IP addresses are 7079 not permitted to have the value 0 or -1 for any of the 7080 , , or 7081 fields. Therefore, a router SHOULD NOT allow an IP 7082 address or subnet mask to be set to a value which would 7083 make any of the the three fields above have the value 7084 zero or -1. 7086 DISCUSSION: 7087 It is possible using variable length subnet masks to 7088 create situations in which routing is ambiguous 7089 (i.e., two routes with different but equally-specific 7090 subnet masks match a particular destination address). 7091 We suspect that a router could, when setting a subnet 7092 mask, check whether the mask would cause routing to 7093 be ambiguous, and that implementors might be able to 7094 decrease their customer support costs by having 7095 routers prohibit or log such erroneous 7096 configurations. However, at this time we do not 7097 require routers to make such checks because we know 7098 of no published method for accurately making this 7099 check. 7101 A router SHOULD make the following checks on any subnet 7102 mask it installs: 7104 + The mask is not all 1-bits. 7106 + The bits which correspond to the network number part 7107 of the address are all set to 1. 7109 DISCUSSION: 7110 The masks associated with routes are also sometimes 7111 called "subnet masks", this test should not be 7112 applied to them. 7114 10.2.3 Network Booting using BOOTP and TFTP 7116 There has been a lot of discussion on how routers can 7117 and should be booted from the network. In general, 7118 these discussions have centered around BOOTP and TFTP. 7119 Currently, there are routers that boot with TFTP from 7120 the network. There is no reason that BOOTP could not be 7121 used for locating the server that the boot image should 7122 be loaded from. 7124 In general, BOOTP is a protocol used to boot end 7125 systems, and requires some stretching to accommodate its 7126 use with routers. If a router is using BOOTP to locate 7127 the current boot host, it should send a BOOTP Request 7128 with its hardware address for its first interface, or, 7129 if it has been previously configured otherwise, with 7130 either another interface's hardware address, or another 7131 number to put in the hardware address field of the BOOTP 7132 packet. This is to allow routers without hardware 7133 addresses (like sync line only routers) to use BOOTP for 7134 bootload discovery. TFTP can then be used to retrieve 7135 the image found in the BOOTP Reply. If there are no 7136 configured interfaces or numbers to use, a router MAY 7137 cycle through the interface hardware addresses it has 7138 until a match is found by the BOOTP server. 7140 A router SHOULD IMPLEMENT the ability to store 7141 parameters learned via BOOTP into local stable storage. 7142 A router MAY implement the ability to store a system 7143 image loaded over the network into local stable storage. 7145 A router MAY have a facility to allow a remote user to 7146 request that the router get a new boot image. 7147 Differentiation should be made between getting the new 7148 boot image from one of three locations: the one included 7149 in the request, from the last boot image server, and 7150 using BOOTP to locate a server. 7152 10.3 Operation and Maintenance 7154 10.3.1 Introduction 7156 There is a range of possible models for performing O&M 7157 functions on a router. At one extreme is the local-only 7158 model, under which the O&M functions can only be 7159 executed locally (e.g., from a terminal plugged into the 7160 router machine). At the other extreme, the fully-remote 7161 model allows only an absolute minimum of functions to be 7162 performed locally (e.g., forcing a boot), with most O&M 7163 being done remotely from the NOC. There are 7164 intermediate models, such as one in which NOC personnel 7165 can log into the router as a host, using the Telnet 7166 protocol, to perform functions which can also be invoked 7167 locally. The local-only model may be adequate in a few 7168 router installations, but in general remote operation 7169 from a NOC will be required, and therefore remote O&M 7170 provisions are required for most routers. 7172 Remote O&M functions may be exercised through a control 7173 agent (program). In the direct approach, the router 7174 would support remote O&M functions directly from the NOC 7175 using standard Internet protocols (e.g., SNMP, UDP or 7176 TCP); in the indirect approach, the control agent would 7177 support these protocols and control the router itself 7178 using proprietary protocols. The direct approach is 7179 preferred, although either approach is acceptable. The 7180 use of specialized host hardware and/or software 7181 requiring significant additional investment is 7182 discouraged; nevertheless, some vendors may elect to 7183 provide the control agent as an integrated part of the 7184 network in which the routers are a part. If this is the 7185 case, it is required that a means be available to 7186 operate the control agent from a remote site using 7187 Internet protocols and paths and with equivalent 7188 functionality with respect to a local agent terminal. 7190 It is desirable that a control agent and any other NOC 7191 software tools which a vendor provides operate as user 7192 programs in a standard operating system. The use of the 7193 standard Internet protocols UDP and TCP for 7194 communicating with the routers should facilitate this. 7196 Remote router monitoring and (especially) remote router 7197 control present important access control problems which 7198 must be addressed. Care must also be taken to ensure 7199 control of the use of router resources for these 7200 functions. It is not desirable to let router monitoring 7201 take more than some limited fraction of the router CPU 7202 time, for example. On the other hand, O&M functions 7203 must receive priority so they can be exercised when the 7204 router is congested, since often that is when O&M is 7205 most needed. 7207 10.3.2 Out Of Band Access 7209 Routers MUST support Out-Of-Band (OOB) access. OOB 7210 access SHOULD provide the same functionality as in-band 7211 access. 7213 DISCUSSION: 7214 This Out-Of-Band access will allow the NOC a way to 7215 access isolated routers during times when network 7216 access is not available. 7218 Out-Of-Band access is an important management tool 7219 for the network administrator. It allows the access 7220 of equipment independent of the network connections. 7221 There are many ways to achieve this access. 7222 Whichever one is used it is important that the access 7223 is independent of the network connections. An 7224 example of Out-Of-Band access would be a serial port 7225 connected to a modem that provides dial up access to 7226 the router. 7228 It is important that the OOB access provides the same 7229 functionality as in-band access. In-band access, or 7230 accessing equipment through the existing network 7231 connection, is limiting, because most of the time, 7232 administrators need to reach equipment to figure out 7233 why it is unreachable. In band access is still very 7234 important for configuring a router, and for 7235 troubleshooting more subtle problems. 7237 10.3.2 Router O&M Functions 7239 10.3.2.1 Maintenance -- Hardware Diagnosis 7241 Each router SHOULD operate as a stand-alone device 7242 for the purposes of local hardware maintenance. 7243 Means SHOULD be available to run diagnostic programs 7244 at the router site using only on-site tools. A 7245 router SHOULD be able to run diagnostics in case of a 7246 fault. For suggested hardware and software 7247 diagnostics see Section [10.3.3]. 7249 10.3.2.2 Control -- Dumping and Rebooting 7251 A router MUST include both in-band and out-of-band 7252 mechanisms to allow the network manager to reload, 7253 stop, and restart the router. A router SHOULD also 7254 contain a mechanism (such as a watchdog timer) which 7255 will reboot the router automatically if it "hangs" 7256 due to a software or hardware fault. 7258 A router SHOULD IMPLEMENT a mechanism for dumping the 7259 contents of a router's memory (and/or other state 7260 useful for vendor debugging after a crash), and 7261 either saving them on a stable storage device local 7262 to the router or saving them on another host via an 7263 up-line dump mechanism such as TFTP (see [OPER:2], 7264 [INTRO:3]). 7266 10.3.2.3 Control -- Configuring the Router 7268 Every router has configuration parameters which may 7269 need to be set. It SHOULD be possible to update the 7270 parameters without rebooting the router; at worst, a 7271 restart MAY be required. There may be cases when it 7272 is not possible to change parameters without 7273 rebooting the router (for instance, changing the IP 7274 address of an interface). In these cases, care 7275 should be taken to minimize disruption to the router 7276 and the surrounding network. 7278 There SHOULD be a way to configure the router over 7279 the network either manually or automatically. A 7280 router SHOULD be able to upload or download its 7281 parameters from a host or another router, and these 7282 parameters SHOULD be convertible into some sort of 7283 text format for making changes and then back to the 7284 form the router can read. A router SHOULD have some 7285 sort of stable storage for its configuration. A 7286 router SHOULD NOT believe protocols such as RARP, 7287 ICMP Address Mask Reply, and MAY not believe BOOTP. 7289 DISCUSSION: 7290 It is necessary to note here that in the future 7291 RARP, ICMP Address Mask Reply, BOOTP and other 7292 mechanisms may be needed to allow a router to 7293 auto-configure. Although routers may in the 7294 future be able to configure automatically, the 7295 intent here is to discourage this practice in a 7296 production environment until such time as auto- 7297 configuration has been tested more thoroughly. The 7298 intent is NOT to discourage auto-configuration all 7299 together. In cases where a router is expected to 7300 get its configuration automatically it may be wise 7301 to allow the router to believe these things as it 7302 comes up and then ignore them after it has gotten 7303 its configuration. 7305 10.3.2.4 Netbooting of System Software 7307 A router SHOULD keep its system image in local non- 7308 volatile storage such as PROM, NVRAM, or disk. It MAY 7309 also be able to load its system software over the 7310 network from a host or another router. 7312 A router which can keep its system image in local 7313 non-volatile storage MAY be configurable to boot its 7314 system image over the network. A router which offers 7315 this option SHOULD be configurable to boot the system 7316 image in its non-volatile local storage if it is 7317 unable to boot its system image over the network. 7319 DISCUSSION: 7321 It is important that the router be able to come up 7322 and run on its own. NVRAM may be a particular 7323 solution for routers used in large networks, since 7324 changing PROMs can be quite time consuming for a 7325 network manager responsible for numerous or 7326 geographically dispersed routers. It is important 7327 to be able to netboot the system image because 7328 there should be an easy way for a router to get a 7329 bug fix or new feature more quickly than getting 7330 PROMS installed. Also if the router has NVRAM 7331 instead of PROMs, it will netboot the image and 7332 then put it in NVRAM. 7334 A router MAY also be able to distinguish between 7335 different configurations based on which software it 7336 is running. If configuration commands change from one 7337 software version to another, it would be helpful if 7338 the router could use the configuration that was 7339 compatible with the software. 7341 10.3.2.5 Detecting and responding to misconfiguration 7343 There MUST be mechanisms for detecting and responding 7344 to misconfigurations. If a command is executed 7345 incorrectly, the router SHOULD give an error message. 7346 The router SHOULD NOT accept a poorly formed command 7347 as if it were correct. 7349 DISCUSSION: 7350 There are cases where it is not possible to detect 7351 errors: the command is correctly formed, but 7352 incorrect with respect to the network. This may 7353 be detected by the router, but may not be 7354 possible. 7356 Another form of misconfiguration is misconfiguration 7357 of the network to which the router is attached. A 7358 router MAY detect misconfigurations in the network. 7359 The router MAY log these findings to a file, either 7360 on the router or a host, so that the network manager 7361 will see that there are possible problems on the 7362 network. 7364 DISCUSSION: 7365 Examples of such misconfigurations might be 7366 another router with the same address as the one in 7367 question or a router with the wrong subnet mask. 7368 If a router detects such problems it is probably 7369 not the best idea for the router to try to fix the 7370 situation. That could cause more harm than good. 7372 10.3.2.6 Minimizing Disruption 7374 Changing the configuration of a router SHOULD have 7375 minimal affect on the network. Routing tables 7376 SHOULD NOT be unnecessarily flushed when a simple 7377 change is made to the router. If a router is running 7378 several routing protocols, stopping one routing 7379 protocol SHOULD NOT disrupt other routing protocols, 7380 except in the case where one network is learned by 7381 more than one routing protocol. 7383 DISCUSSION: 7384 It is the goal of a network manager to run a 7385 network so that users of the network get the best 7386 connectivity possible. Reloading a router for 7387 simple configuration changes can cause disruptions 7388 in routing and ultimately cause disruptions to the 7389 network and its users. If routing tables are 7390 unnecessarily flushed, for instance, the default 7391 route will be lost as well as specific routes to 7392 sites within the network. This sort of disruption 7393 will cause significant downtime for the users. It 7394 is the purpose of this section to point out that 7395 whenever possible, these disruptions should be 7396 avoided. 7398 10.3.2.7 Control -- Troubleshooting Problems 7400 (1) A router MUST provide in-band network access, 7401 but (except as required by Section [8.2]) for 7402 security considerations this access SHOULD be 7403 disabled by default. Vendors MUST document the 7404 default state of any in-band access. 7406 DISCUSSION: 7407 In-band access primarily refers to access via 7408 the normal network protocols which may or may 7409 not affect the permanent operational state of 7410 the router. This includes, but is not 7411 limited to Telnet/RLOGIN console access and 7412 SNMP operations. 7414 This was a point of contention between the 7415 "operational out of the box" and "secure out 7416 of the box" contingents. Any "automagic" 7417 access to the router may introduce 7418 insecurities, but it may be more important 7419 for the customer to have a router which is 7420 accessible over the network as soon as it is 7421 plugged in. At least one vendor supplies 7422 routers without any external console access 7423 and depends on being able to access the 7424 router via the network to complete its 7425 configuration. 7427 Basically, it is the vendors call whether or 7428 not in-band access is enabled by default; but 7429 it is also the vendors responsibility to make 7430 its customers aware of possible insecurities. 7432 (2) A router MUST provide the ability to initiate an 7433 ICMP echo. The following options SHOULD be 7434 implemented: 7436 + Choice of data patterns 7438 + Choice of packet size 7440 + Record route 7442 and the following additional options MAY be 7443 implemented: 7445 + Loose source route 7446 + Strict source route 7448 + Timestamps 7450 (3) A router SHOULD provide the ability to initiate 7451 a traceroute. If traceroute is provided, then 7452 the 3rd party traceroute SHOULD be implemented. 7454 Each of the above three facilities (if implemented) 7455 SHOULD have access restrictions placed on it to 7456 prevent its abuse by unauthorized persons. 7458 10.4 Security Considerations 7460 10.4.1 Auditing and Audit Trails 7462 Auditing and billing are the bane of the network 7463 operator, but are the two features most requested by 7464 those in charge of network security and those who are 7465 responsible for paying the bills. In the context of 7466 security, auditing is desirable if it helps you keep 7467 your network working and protects your resources from 7468 abuse, without costing you more than those resources are 7469 worth. 7471 (1) Configuration Changes 7473 Router SHOULD provide a method for auditing a 7474 configuration change of a router, even if it's 7475 something as simple as recording the operator's 7476 initials and time of change. 7478 DISCUSSION: 7479 Having the ability to track who made changes and 7480 when is highly desirable, especially if your 7481 packets suddenly start getting routed through 7482 Alaska on their way across town. 7484 (2) Packet Accounting 7486 Vendors should strongly consider providing a system 7487 for tracking traffic levels between pairs of hosts 7488 or networks. A mechanism for limiting the 7489 collection of this information to specific pairs of 7490 hosts or networks is also strongly encouraged. 7492 DISCUSSION: 7493 A "host traffic matrix" as described above can 7494 give the network operator a glimpse of traffic 7495 trends not apparent from other statistics. It 7496 can also identify hosts or networks which are 7497 "probing" the structure of the attached networks 7498 -- e.g., a single external host which tries to 7499 send packets to every IP address in the network 7500 address range for a connected network. 7502 (3) Security Auditing 7504 Routers MUST provide a method for auditing security 7505 related failures or violations to include: 7507 + Authorization Failures: bad passwords, invalid 7508 SNMP communities, invalid authorization tokens, 7510 + Violations of Policy Controls: Prohibited 7511 Source Routes, Filtered Destinations, and 7513 + Authorization Approvals: good passwords -- 7514 Telnet in-band access, console access. 7516 Routers MUST provide a method of limiting or 7517 disabling such auditing but auditing SHOULD be on 7518 by default. Possible methods for auditing include 7519 listing violations to a console if present, logging 7520 or counting them internally, or logging them to a 7521 remote security server via the SNMP trap mechanism 7522 or the Unix logging mechanism as appropriate. A 7523 router MUST implement at least one of these 7524 reporting mechanisms -- it MAY implement more than 7525 one. 7527 10.4.2 Configuration Control 7529 A vendor has a responsibility to use good configuration 7530 control practices in the creation of the 7531 software/firmware loads for their routers. In 7532 particular, if a vendor makes updates and loads 7533 available for retrieval over the Internet, the vendor 7534 should also provide a way for the customer to confirm 7535 the load is a valid one, perhaps by the verification of 7536 a checksum over the load. 7538 DISCUSSION: 7539 Many vendors currently provide short notice updates 7540 of their software products via the Internet. This a 7541 good trend and should be encouraged, but provides a 7542 point of vulnerability in the configuration control 7543 process. 7545 If a vendor provides the ability for the customer to 7546 change the configuration parameters of a router 7547 remotely, for example via a Telnet session, the ability 7548 to do so SHOULD be configurable and SHOULD default to 7549 off. The router SHOULD require a password or other 7550 valid authentication before permitting remote 7551 reconfiguration. 7553 DISCUSSION: 7554 Allowing your properly identified network operator to 7555 twiddle with your routers is necessary; allowing 7556 anyone else to do so is foolhardy. 7558 A router MUST NOT have undocumented "back door" access 7559 and "master passwords". A vendor MUST ensure any such 7560 access added for purposes of debugging or product 7561 development are deleted before the product is 7562 distributed to its customers. 7564 DISCUSSION: 7565 A vendor has a responsibility to its customers to 7566 ensure they are aware of the vulnerabilities present 7567 in its code by intention - e.g. in-band access. 7568 "Trap doors", "back doors" and "master passwords" 7569 intentional or unintentional can turn a relatively 7570 secure router into a major problem on an operational 7571 network. The supposed operational benefits are not 7572 matched by the potential problems. 7574 11. REFERENCES 7576 Implementors should be aware that Internet protocol standards 7577 are occasionally updated. These references are current as of 7578 this writing, but a cautious implementor will always check a 7579 recent version of the RFC index to ensure that an RFC has not 7580 been updated or superseded by another, more recent RFC. 7581 Reference [INTRO:6] explains various ways to obtain a current 7582 RFC index. 7584 APPL:1. 7585 B. Croft and J. Gilmore, "Bootstrap Protocol (BOOTP), 7586 Request For Comments (RFC) 951, DDN Network Information 7587 Center, SRI International, Menlo Park, California, USA, 7588 September 1985. 7590 APPL:2. 7591 S. Alexander and R. Droms, "DHCP Options and BOOTP Vendor 7592 Extensions", Request For Comments (RFC) 1533, October 7593 1993. 7595 APPL:3. 7596 W. Wimer, "Clarifications and Extensions for the 7597 Bootstrap Protocol", Request For Comments (RFC) 1542, 7598 October 1993. 7600 ARCH:1. 7601 "DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 7602 (three volumes), DDN Network Information Center, SRI 7603 International, Menlo Park, California, USA, December 7604 1985. 7606 ARCH:2. 7607 V. Cerf and R. Kahn, "A Protocol for Packet Network 7608 Intercommunication," IEEE Transactions on Communication, 7609 May 1974. Also included in [ARCH:1]. 7611 ARCH:3. 7612 J. Postel, C. Sunshine, and D. Cohen, "The ARPA Internet 7613 Protocol," Computer Networks, vol. 5, no. 4, July 1981. 7614 Also included in [ARCH:1]. 7616 ARCH:4. 7617 B. Leiner, J. Postel, R. Cole, and D. Mills, "The DARPA 7618 Internet Protocol Suite," Proceedings of INFOCOM '85, 7619 IEEE, Washington, DC, March 1985. Also in: IEEE 7620 Communications Magazine, March 1985. Also available from 7621 the Information Sciences Institute, University of 7622 Southern California as Technical Report ISI-RS-85-153. 7624 ARCH:5. 7625 D. Comer, "Internetworking With TCP/IP Volume 1: 7626 Principles, Protocols, and Architecture", Prentice Hall, 7627 Englewood Cliffs, NJ, 1991. 7629 ARCH:6. 7630 W. Stallings, "Handbook of Computer-Communications 7631 Standards Volume 3: The TCP/IP Protocol Suite", 7632 Macmillan, New York, NY, 1990. 7634 ARCH:7. 7635 J. Postel, "Internet Official Protocol Standards", 7636 Request For Comments (RFC) 1540, October 1993. 7638 ARCH:8. 7639 "Information processing systems -- Open Systems 7640 Interconnection -- Basic Reference Model", ISO 7489, 7641 International Standards Organization, 1984. 7643 FORWARD:1. 7644 IETF CIP Working Group (C. Topolcic, Editor), 7645 "Experimental Internet Stream Protocol, Version 2 (ST- 7646 II)", Request For Comments (RFC) 1190, DDN Network 7647 Information Center, SRI International, Menlo Park, 7648 California, USA, October 1990. 7650 FORWARD:2. 7651 A. Mankin and K. Ramakrishnan, Editors, "Gateway 7652 Congestion Control Survey", Request For Comments (RFC) 7653 1254, DDN Network Information Center, SRI International, 7654 Menlo Park, California, USA, August 1991. 7656 FORWARD:3. 7657 J. Nagle, "On Packet Switches with Infinite Storage," 7658 IEEE Transactions on Communications, vol. COM-35, no. 4, 7659 April 1987. 7661 FORWARD:4. 7663 R. Jain, K. Ramakrishnan, and D. Chiu, "Congestion 7664 Avoidance in Computer Networks With a Connectionless 7665 Network Layer", Technical Report DEC-TR-506, Digital 7666 Equipment Corporation. 7668 FORWARD:5. 7669 V. Jacobson, "Congestion Avoidance and Control," 7670 Proceedings of SIGCOMM '88, Association for Computing 7671 Machinery, August 1988. 7673 FORWARD:6. 7674 W. Barns, "Precedence and Priority Access Implementation 7675 for Department of Defense Data Networks", Technical 7676 Report MTR-91W00029, The Mitre Corporation, McLean, 7677 Virginia, USA, July 1991. 7679 INTERNET:1. 7680 J. Postel, "Internet Protocol", Request For Comments 7681 (RFC) 791, DDN Network Information Center, SRI 7682 International, Menlo Park, California, USA, September 7683 1981. 7685 INTERNET:2. 7686 J. Mogul and J. Postel, "Internet Standard Subnetting 7687 Procedure", Request For Comments (RFC) 950, DDN Network 7688 Information Center, SRI International, Menlo Park, 7689 California, USA, August 1985. 7691 INTERNET:3. 7692 J. Mogul, "Broadcasting Internet Datagrams in the 7693 Presence of Subnets", Request For Comments (RFC) 922, DDN 7694 Network Information Center, SRI International, Menlo 7695 Park, California, USA, October 1984. 7697 INTERNET:4. 7698 S. Deering, "Host Extensions for IP Multicasting", 7699 Request For Comments (RFC) 1112, DDN Network Information 7700 Center, SRI International, Menlo Park, California, USA, 7701 August 1989. 7703 INTERNET:5. 7704 S. Kent, "U.S. Department of Defense Security Options for 7705 the Internet Protocol", Request for Comments (RFC) 1108, 7706 November 1991. 7708 INTERNET:6. 7709 R. Braden, D. Borman, and C. Partridge, "Computing the 7710 Internet Checksum", Request For Comments (RFC) 1071, DDN 7711 Network Information Center, SRI International, Menlo 7712 Park, California, USA, September 1988. 7714 INTERNET:7. 7715 T. Mallory and A. Kullberg, "Incremental Updating of the 7716 Internet Checksum", Request For Comments (RFC) 1141, DDN 7717 Network Information Center, SRI International, Menlo 7718 Park, California, USA, January 1990. 7720 INTERNET:8. 7721 J. Postel, "Internet Control Message Protocol", Request 7722 For Comments (RFC) 792, DDN Network Information Center, 7723 SRI International, Menlo Park, California, USA, September 7724 1981. 7726 INTERNET:9. 7727 A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R. 7728 Wilder, and R. Zahavi, "Evaluation of Internet 7729 Performance -- FY89", Technical Report MTR-89W00216, 7730 MITRE Corporation, February, 1990. 7732 INTERNET:10. 7733 G. Finn, "A Connectionless Congestion Control Algorithm," 7734 Computer Communications Review, vol. 19, no. 5, 7735 Association for Computing Machinery, October 1989. 7737 INTERNET:11. 7738 W. Prue, "The Source Quench Introduced Delay (SQuID)", 7739 Request For Comments (RFC) 1016, DDN Network Information 7740 Center, SRI International, J. Postel, August 1987. 7742 INTERNET:12. 7743 A. McKenzie, "Some comments on SQuID", Request For 7744 Comments (RFC) 1018, DDN Network Information Center, SRI 7745 International, Menlo Park, California, USA, August 1987. 7747 INTERNET:13. 7748 S. Deering, "ICMP Router Discovery Messages", Request For 7749 Comments (RFC) 1256, DDN Network Information Center, SRI 7750 International, Menlo Park, California, USA, September 7751 1991. 7753 INTERNET:14. 7754 J. Mogul and S. Deering, "Path MTU Discovery", Request 7755 For Comments (RFC) 1191, DDN Network Information Center, 7756 SRI International, Menlo Park, California, USA, November 7757 1990. 7759 INTERNET:15 7760 V. Fuller, T. Li, J. Yi, and K. Varadhan, "Classless 7761 Inter-Domain Routing (CIDR): an Address Assignment and 7762 Aggregation Strategy" Request For Comments (RFC) 1519, 7763 DDN Network Information Center, SRI International Menlo 7764 Park, California, USA September 1993. 7766 INTERNET:16 7767 M. St. Johns, "Draft Revised IP Security Option", Request 7768 for Comments 1038, January 1988. 7770 INTERNET:17 7771 W. Prue and J. Postel, "Queuing Algorithm to Provide 7772 Type-of-service For IP Links", Request for Comments 1046, 7773 February 1988. 7775 INTRO:1. 7776 R. Braden and J. Postel, "Requirements for Internet 7777 Gateways", Request For Comments (RFC) 1009, DDN Network 7778 Information Center, SRI International, Menlo Park, 7779 California, USA, June 1987. 7781 INTRO:2. 7782 Internet Engineering Task Force (R. Braden, Editor), 7783 "Requirements for Internet Hosts -- Communication 7784 Layers", Request For Comments (RFC) 1122, DDN Network 7785 Information Center, SRI International, Menlo Park, 7786 California, USA, October 1989. 7788 INTRO:3. 7789 Internet Engineering Task Force (R. Braden, Editor), 7790 "Requirements for Internet Hosts -- Application and 7791 Support", Request For Comments (RFC) 1123, DDN Network 7792 Information Center, SRI International, Menlo Park, 7793 California, USA, October 1989. 7795 INTRO:4. 7796 D. Clark, "Modularity and Efficiency in Protocol 7797 Implementations", Request For Comments (RFC) 817, DDN 7798 Network Information Center, SRI International, Menlo 7799 Park, California, USA, July 1982. 7801 INTRO:5. 7802 D. Clark, "The Structuring of Systems Using Upcalls," 7803 Proceedings of 10th ACM SOSP, December 1985. 7805 INTRO:6. 7806 O. Jacobsen and J. Postel, "Protocol Document Order 7807 Information", Request For Comments (RFC) 980, DDN Network 7808 Information Center, SRI International, Menlo Park, 7809 California, USA, March 1986. 7811 INTRO:7. 7812 J. Reynolds and J. Postel, "Assigned Numbers", Request 7813 For Comments (RFC) 1340, July 1992. This document is 7814 periodically updated and reissued with a new number. It 7815 is wise to verify occasionally that the version you have 7816 is still current. 7818 INTRO:8. 7819 "DoD Trusted Computer System Evaluation Criteria", DoD 7820 publication 5200.28-STD, U.S. Department of Defense, 7821 December 1985. 7823 INTRO:9 7824 G. Malkin and T. LaQuey Parker, "Internet Users' 7825 Glossary", Request for Comments (RFC) 1392 (also FYI 7826 0018), Network Information Center, January 1993. 7828 LINK:1. 7829 S. Leffler and M. Karels, "Trailer Encapsulations", 7830 Request For Comments (RFC) 893, DDN Network Information 7831 Center, SRI International, Menlo Park, California, USA, 7832 April 1984. 7834 LINK:2 7835 W. Simpson, "The Point-to-Point Protocol (PPP) for the 7836 Transmission of Multi-protocol Datagrams over Point-to- 7837 Point Links", Request For Comments (RFC) 1331, May 1992. 7839 LINK:3 7840 G. McGregor, "The PPP Internet Protocol Control Protocol 7841 (IPCP)", Request For Comments (RFC) 1332, May 1992. 7843 LINK:4 7844 B. Lloyd, W. Simpson, "PPP Authentication Protocols", 7845 Request For Comments (RFC) 1334, May 1992. 7847 LINK:5 7848 W. Simpson "PPP Link Quality Monitoring", Request For 7849 Comments (RFC) 1333, May 1992. 7851 MGT:1. 7852 M. Rose and K. McCloghrie, "Structure and Identification 7853 of Management Information of TCP/IP-based Internets", 7854 Request For Comments (RFC) 1155, DDN Network Information 7855 Center, SRI International, Menlo Park, California, USA, 7856 May 1990. 7858 MGT:2. 7859 K. McCloghrie and M. Rose (Editors), "Management 7860 Information Base of TCP/IP-Based Internets: MIB-II", 7861 Request For Comments (RFC) 1213, DDN Network Information 7862 Center, SRI International, Menlo Park, California, USA, 7863 March 1991. 7865 MGT:3. 7866 J. Case, M. Fedor, M. Schoffstall, and J. Davin, "Simple 7867 Network Management Protocol", Request For Comments (RFC) 7868 1157, DDN Network Information Center, SRI International, 7869 Menlo Park, California, USA, May 1990. 7871 MGT:4. 7872 M. Rose and K. McCloghrie (Editors), "Towards Concise MIB 7873 Definitions", Request For Comments (RFC) 1212, DDN 7874 Network Information Center, SRI International, Menlo 7875 Park, California, USA, March 1991. 7877 MGT:5. 7878 L. Steinberg, "Techniques for Managing Asynchronously 7879 Generated Alerts", Request for Comments (RFC) 1224, May 7880 1991. 7882 MGT:6. 7883 F. Kastenholz, "Definitions of Managed Objects for the 7884 Ethernet-like Interface Types", Request for Comments 7885 (RFC) 1398, January 1993. 7887 MGT:7. 7888 R. Fox and K. McCloghrie, "IEEE 802.4 Token Bus MIB", 7889 Request for Comments (RFC) 1230, May 1991. 7891 MGT:8. 7892 E. Decker, R. Fox and K. McCloghrie, "IEEE 802.5 Token 7893 Ring MIB", Request for Comments (RFC) 1231, February 7894 1993. 7896 MGT:9. 7897 J. Case and A. Rijsinghani, "FDDI Management Information 7898 Base", Request for Comments (RFC) 1512, September 1993. 7900 MGT:10. 7901 B. Stewart, "Definitions of Managed Objects for 7902 RS-232-like Hardware Devices", Request for Comments (RFC) 7903 1317, April 1992. 7905 MGT:11. 7906 F. Kastenholz, " Definitions of Managed Objects for the 7907 Link Control Protocol of the Point-to-Point Protocol", 7908 Request For Comments (RFC) 1471 June 1992. 7910 MGT:12. 7911 F. Kastenholz, "The Definitions of Managed Objects for 7912 the Security Protocols of the Point-to-Point Protocol", 7913 Request For Comments (RFC) 1472 June 1992. 7915 MGT:13. 7916 F. Kastenholz, "The Definitions of Managed Objects for 7917 the IP Network Control Protocol of the Point-to-Point 7918 Protocol", Request For Comments (RFC) 1473 June 1992. 7920 MGT:14. 7921 F. Baker and R. Coltun, "OSPF Version 2 Management 7922 Information Base", Request For Comments (RFC) 1253, 7923 August 1991. 7925 MGT:15. 7926 S. Willis and J. Burruss, "Definitions of Managed Objects 7927 for the Border Gateway Protocol (Version 3)", Request For 7928 Comments (RFC) 1269, October 1991. 7930 MGT:16. 7931 F. Baker, J. Watt, "Definitions of Managed Objects for 7932 the DS1 and E1 Interface Types", Request For Comments 7933 (RFC) 1406, January 1993. 7935 MGT:17. 7936 T. Cox and K. Tesink, "Definitions of Managed Objects for 7937 the DS3/E3 Interface Types", Request For Comments (RFC) 7938 1407, January 1993. 7940 MGT:18. 7941 K. McCloghrie, "Extensions to the Generic-Interface MIB", 7942 Request For Comments (RFC) 1229, August 1992. 7944 MGT:19. 7945 T. Cox and K. Tesink, "Definitions of Managed Objects for 7946 the SIP Interface Type", Request For Comments (RFC) 1304, 7947 February 1992. 7949 MGT:20 7950 F. Baker, "IP Forwarding Table MIB", Request For Comments 7951 (RFC) 1354, July 1992. 7953 MGT:21. 7954 G. Malkin and F. Baker, "RIP Version 2 MIB Extension", 7955 Request For Comments (RFC) 1389, January 1993. 7957 MGT:22. 7958 D. Throop, "SNMP MIB Extension for the X.25 Packet 7959 Layer", Request For Comments (RFC) 1382, November 1992. 7961 MGT:23. 7962 D. Throop and F. Baker, "SNMP MIB Extension for X.25 7963 LAPB", Request For Comments (RFC) 1381, November 1992. 7965 MGT:24. 7966 D. Throop and F. Baker, "SNMP MIB Extension for 7967 MultiProtocol Interconnect over X.25", Request For 7968 Comments (RFC) 1461, May 1993. 7970 MGT:25. 7971 M. Rose, "SNMP over OSI", Request For Comments (RFC) 7972 1418, March 1993. 7974 MGT:26. 7975 G. Minshall and M. Ritter, "SNMP over AppleTalk", Request 7976 For Comments (RFC) 1419, March 1993. 7978 MGT:27. 7979 S. Bostock, "SNMP over IPX", Request For Comments (RFC) 7980 1420, March 1993. 7982 MGT:28. 7983 M. Schoffstall, C. Davin, M. Fedor, J. Case, "SNMP over 7984 Ethernet", Request For Comments (RFC) 1089, February 7985 1989. 7987 MGT:29. 7988 J. Case, "FDDI Management Information Base", Request For 7989 Comments (RFC) 1285, January 1992. 7991 OPER:1. 7992 J. Nagle, "Congestion Control in IP/TCP Internetworks", 7993 Request For Comments (RFC) 896, DDN Network Information 7994 Center, SRI International, Menlo Park, California, USA, 7995 January 1984. 7997 OPER:2. 7998 K.R. Sollins, "TFTP Protocol (revision 2)", Request For 7999 Comments (RFC) 1350, July 1992. 8001 ROUTE:1. 8002 J. Moy, "OSPF Version 2", Request For Comments (RFC) 8003 1247, DDN Network Information Center, SRI International, 8004 Menlo Park, California, USA, July 1991. 8006 ROUTE:2. 8007 R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and 8008 Dual Environments", Request For Comments (RFC) 1195, DDN 8009 Network Information Center, SRI International, Menlo 8010 Park, California, USA, December 1990. 8012 ROUTE:3. 8013 C. L. Hedrick, "Routing Information Protocol", Request 8014 For Comments (RFC) 1058, DDN Network Information Center, 8015 SRI International, Menlo Park, California, USA, June 8016 1988. 8018 ROUTE:4. 8019 K. Lougheed and Y. Rekhter, "A Border Gateway Protocol 3 8020 (BGP-3)", Request For Comments (RFC) 1267, October 1991. 8022 ROUTE:5. 8023 P. Gross and Y. Rekhter, "Application of the Border 8024 Gateway Protocol in the Internet", Request For Comments 8025 (RFC) 1268, October 1991. 8027 ROUTE:6. 8028 D. Mills, "Exterior Gateway Protocol Formal 8029 Specification", Request For Comments (RFC) 904, DDN 8030 Network Information Center, SRI International, Menlo 8031 Park, California, USA, April 1984. 8033 ROUTE:7. 8034 E. Rosen, "Exterior Gateway Protocol (EGP)", Request For 8035 Comments (RFC) 827, DDN Network Information Center, SRI 8036 International, Menlo Park, California, USA, October 1982. 8038 ROUTE:8. 8039 L. Seamonson and E. Rosen, ""STUB" Exterior Gateway 8040 Protocol", Request For Comments (RFC) 888, DDN Network 8041 Information Center, SRI International, Menlo Park, 8042 California, USA, January 1984. 8044 ROUTE:9. 8045 D. Waitzman, C. Partridge, and S. Deering, "Distance 8046 Vector Multicast Routing Protocol", Request For Comments 8047 (RFC) 1075, DDN Network Information Center, SRI 8048 International, Menlo Park, California, USA, November 8049 1988. 8051 ROUTE:10. 8052 S. Deering, "Multicast Routing in Internetworks and 8053 Extended LANs," Proceedings of SIGCOMM '88, Association 8054 for Computing Machinery, August 1988. 8056 ROUTE:11. 8057 P. Almquist, "Type of Service in the Internet Protocol 8058 Suite", Request for Comments (RFC) 1349, July 1992. 8060 ROUTE:12. 8061 Y. Rekhter, "Experience with the BGP Protocol", Request 8062 For Comments (RFC) 1266, October 1991. 8064 ROUTE:13. 8065 Y. Rekhter, "BGP Protocol Analysis", Request For Comments 8066 (RFC) 1265, October 1991. 8068 TRANS:1. 8069 J. Postel, "User Datagram Protocol", Request For Comments 8070 (RFC) 768, DDN Network Information Center, SRI 8071 International, Menlo Park, California, USA, August 1980. 8073 TRANS:2. 8074 J. Postel, "Transmission Control Protocol", Request For 8075 Comments (RFC) 793, DDN Network Information Center, SRI 8076 International, Menlo Park, California, USA, September 8077 1981. 8079 APPENDIX A. REQUIREMENTS FOR SOURCE-ROUTING HOSTS 8081 Subject to restrictions given below, a host MAY be able to act 8082 as an intermediate hop in a source route, forwarding a source- 8083 routed datagram to the next specified hop. 8085 However, in performing this router-like function, the host 8086 MUST obey all the relevant rules for a router forwarding 8087 source-routed datagrams [INTRO:2]. This includes the 8088 following specific provisions: 8090 (A) TTL 8091 The TTL field MUST be decremented and the datagram 8092 perhaps discarded as specified for a router in [INTRO:2]. 8094 (B) ICMP Destination Unreachable 8095 A host MUST be able to generate Destination Unreachable 8096 messages with the following codes: 8097 4 (Fragmentation Required but DF Set) when a source- 8098 routed datagram cannot be fragmented to fit into the 8099 target network; 8100 5 (Source Route Failed) when a source-routed datagram 8101 cannot be forwarded, e.g., because of a routing problem 8102 or because the next hop of a strict source route is not 8103 on a connected network. 8105 (C) IP Source Address 8106 A source-routed datagram being forwarded MAY (and 8107 normally will) have a source address that is not one of 8108 the IP addresses of the forwarding host. 8110 (D) Record Route Option 8111 A host that is forwarding a source-routed datagram 8112 containing a Record Route option MUST update that option, 8113 if it has room. 8115 (E) Timestamp Option 8116 A host that is forwarding a source-routed datagram 8117 containing a Timestamp Option MUST add the current 8118 timestamp to that option, according to the rules for this 8119 option. 8121 To define the rules restricting host forwarding of source- 8122 routed datagrams, we use the term "local source-routing" if 8123 the next hop will be through the same physical interface 8124 through which the datagram arrived; otherwise, it is "non- 8125 local source-routing". 8127 A host is permitted to perform local source-routing without 8128 restriction. 8130 A host that supports non-local source-routing MUST have a 8131 configurable switch to disable forwarding, and this switch 8132 MUST default to disabled. 8134 The host MUST satisfy all router requirements for configurable 8135 policy filters [INTRO:2] restricting non-local forwarding. 8137 If a host receives a datagram with an incomplete source route 8138 but does not forward it for some reason, the host SHOULD 8139 return an ICMP Destination Unreachable (code 5, Source Route 8140 Failed) message, unless the datagram was itself an ICMP error 8141 message. 8143 APPENDIX B. GLOSSARY 8145 This Appendix defines specific terms used in this memo. It 8146 also defines some general purpose terms that may be of 8147 interest. See also [INTRO:9] for a more general set of 8148 definitions. 8150 AS 8151 Autonomous System A collection of routers under a single 8152 administrative authority using a common Interior Gateway 8153 Protocol for routing packets. 8155 Connected Network 8156 A network to which a router is interfaced is often known 8157 as the "local network" or the "subnetwork" relative to 8158 that router. However, these terms can cause confusion, 8159 and therefore we use the term "Connected Network" in this 8160 memo. 8162 Connected (Sub)Network 8163 A Connected (Sub)Network is an IP subnetwork to which a 8164 router is interfaced, or a connected network if the 8165 connected network is not subnetted. See also Connected 8166 Network. 8168 Datagram 8169 The unit transmitted between a pair of internet modules. 8170 data, called datagrams, from sources to destinations. 8171 The Internet Protocol does not provide a reliable 8172 communication facility. There are no acknowledgments 8173 either end-to-end or hop-by-hop. There is no error no 8174 retransmissions. There is no flow control. See IP. 8176 Default Route 8177 A routing table entry which is used to direct any data 8178 addressed to any network numbers not explicitly listed in 8179 the routing table. 8181 EGP 8182 Exterior Gateway Protocol A protocol which distributes 8183 routing information to the gateways (routers) which 8184 connect autonomous systems. See IGP. 8186 EGP-2 8187 Exterior Gateway Protocol version 2 This is an EGP 8188 routing protocol developed to handle traffic between AS's 8189 in the Internet. 8191 Forwarder 8192 The logical entity within a router that is responsible 8193 for switching packets among the router's interfaces. The 8194 Forwarder also makes the decisions to queue a packet for 8195 local delivery, to queue a packet for transmission out 8196 another interface, or both. 8198 Forwarding 8199 Forwarding is the process a router goes through for each 8200 packet received by the router. The packet may be 8201 consumed by the router, it may be output on one or more 8202 interfaces of the router, or both. Forwarding includes 8203 the process of deciding what to do with the packet as 8204 well as queuing it up for (possible) output or internal 8205 consumption. 8207 Fragment 8208 An IP datagram which represents a portion of a higher 8209 layer's packet which was too large to be sent in its 8210 entirety over the output network. 8212 IGP 8213 Interior Gateway Protocol A protocol which distributes 8214 routing information with an Autonomous System (AS). See 8215 EGP. 8217 Interface IP Address 8218 The IP Address and subnet mask that is assigned to a 8219 specific interface of a router. 8221 Internet Address 8222 An assigned number which identifies a host in an 8223 internet. It has two or three parts: network number, 8224 optional subnet number, and host number. 8226 IP 8227 Internet Protocol The network layer protocol for the 8228 Internet. It is a packet switching, datagram protocol 8229 defined in RFC 791. IP does not provide a reliable 8230 communications facility; that is, there are no end-to-end 8231 of hop-by-hop acknowledgments. 8233 IP Datagram 8234 An IP Datagram is the unit of end-to-end transmission in 8235 the Internet Protocol. An IP Datagram consists of an IP 8236 header followed by all of higher-layer data (such as TCP, 8237 UDP, ICMP, and the like). An IP Datagram is an IP header 8238 followed by a message. 8240 An IP Datagram is a complete IP end-to-end transmission 8241 unit. An IP Datagram is composed of one or more IP 8242 Fragments. 8244 In this memo, the unqualified term "Datagram" should be 8245 understood to refer to an IP Datagram. 8247 IP Fragment 8248 An IP Fragment is a component of an IP Datagram. An IP 8249 Fragment consists of an IP header followed by all or part 8250 of the higher-layer of the original IP Datagram. 8252 One or more IP Fragments comprises a single IP Datagram. 8254 In this memo, the unqualified term "Fragment" should be 8255 understood to refer to an IP Fragment. 8257 IP Packet 8258 An IP Datagram or an IP Fragment. 8260 In this memo, the unqualified term "Packet" should 8261 generally be understood to refer to an IP Packet. 8263 Logical [network] interface 8264 We define a logical [network] interface to be a logical 8265 path, distinguished by a unique IP address, to a 8266 connected network. 8268 Martian Filtering 8269 A packet which contains an invalid source or destination 8270 address is considered to be "martian" and discarded. 8272 MTU (Maximum Transmission Unit) 8273 The size of the largest packet that can be transmitted or 8274 received through a logical interface. This size includes 8275 the IP header but does not include the size of any Link 8276 Layer headers or framing. 8278 Multicast 8279 A packet which is destined for multiple hosts. See 8280 "broadcast". 8282 Multicast Address 8283 A special type of address which is recognized by multiple 8284 hosts. 8286 A Multicast Address is sometimes known as a Functional 8287 Address or a Group Address. 8289 Originate 8290 Packets can be transmitted by a router for one of two 8291 reasons: 1) the packet was received and is being 8292 forwarded or 2) the router itself created the packet for 8293 transmission (such as route advertisements). Packets 8294 that the router creates for transmission are said to 8295 originate at the router. 8297 Packet 8298 A packet is the unit of data passed across the interface 8299 between the Internet Layer and the Link Layer. It 8300 includes an IP header and data. A packet may be a 8301 complete IP datagram or a fragment of an IP datagram. 8303 Path 8304 The sequence of routers and (sub-)networks which a packet 8305 traverses from a particular router to a particular 8306 destination host. Note that a path is uni-directional; 8307 it is not unusual to have different paths in the two 8308 directions between a given host pair. 8310 Physical Network 8311 A Physical Network is a network (or a piece of an 8312 internet) which is contiguous at the Link Layer. Its 8313 internal structure (if any) is transparent to the 8314 Internet Layer. 8316 In this memo, several media components that are connected 8317 together via devices such as bridges or repeaters are 8318 considered to be a single Physical Network since such 8319 devices are transparent to the IP. 8321 Physical Network Interface 8322 This is a physical interface to a Connected Network and 8323 has a (possibly unique) Link-Layer address. Multiple 8324 Physical Network Interfaces on a single router may share 8325 the same Link-Layer address, but the address must be 8326 unique for different routers on the same Physical 8327 Network. 8329 router 8330 A special-purpose dedicated computer that attaches 8331 several networks together. Routers switch packets 8332 between these networks in a process known as forwarding. 8333 This process may be repeated several times on a single 8334 packet by multiple routers until the packet can be 8335 delivered to the final destination -- switching the 8336 packet from router to router to router... until the 8337 packet gets to its destination. 8339 RPF 8340 Reverse Path Forwarding A method used to deduce the next 8341 hops for broadcast and multicast packets. 8343 serial line 8344 A physical medium which we cannot define, but we 8345 recognize one when we see one. See the U.S. Supreme 8346 Court's definitions on pornography. 8348 Silently Discard 8349 This memo specifies several cases where a router is to 8350 "Silently Discard" a received packet (or datagram). This 8351 means that the router should discard the packet without 8352 further processing, and that the router will not send any 8353 ICMP error message (see Section [4.3.2]) as a result. 8354 However, for diagnosis of problems, the router should 8355 provide the capability of logging the error (see Section 8356 [1.3.3]), including the contents of the silently- 8357 discarded packet, and should record the event in a 8358 statistics counter. 8360 Silently Ignore 8361 A router is said to "Silently Ignore" an error or 8362 condition if it takes no action other than possibly 8363 generating an error report in an error log or via some 8364 network management protocol, and discarding, or ignoring, 8365 the source of the error. In particular, the router does 8366 NOT generate an ICMP error message. 8368 Specific-destination address 8369 This is defined to be the destination address in the IP 8370 header unless the header contains an IP broadcast or IP 8371 multicast address, in which case the specific-destination 8372 is an IP address assigned to the physical interface on 8373 which the packet arrived. 8375 subnet 8376 A portion of a network, which may be a physically 8377 independent network, which shares a network address with 8378 other portions of the network and is distinguished by a 8379 subnet number. A subnet is to a network what a network 8380 is to an internet. 8382 subnet number 8383 A part of the internet address which designates a subnet. 8384 It is ignored for the purposes internet routing, but is 8385 used for intranet routing. 8387 TOS 8388 Type Of Service A field in the IP header which represents 8389 the degree of reliability expected from the network layer 8390 by the transport layer or application. 8392 TTL 8393 Time To Live A field in the IP header which represents 8394 how long a packet is considered valid. It is a 8395 combination "hop count" and "timer value". 8397 APPENDIX C. FUTURE DIRECTIONS 8399 This appendix lists work that future revisions of this 8400 document may wish to address. 8402 In the preparation of Router Requirements, we stumbled across 8403 several other architectural issues. Each of these is dealt 8404 with somewhat in the document, but still ought to be 8405 classified as an open issue in the IP architecture. 8407 Most of the he topics presented here generally indicate areas 8408 where the technology is still relatively new and it is not 8409 appropriate to develop specific requirements since the 8410 community is still gaining operational experience. 8412 Other topics represent areas of ongoing research and indicate 8413 areas that the prudent developer would closely monitor. 8415 (1) SNMP Version 2 8417 (2) Additional SNMP MIBs 8419 (3) IDPR 8421 (4) CIPSO 8423 (5) IP Next Generation research 8425 (6) More detailed requirements for next-hop selection 8427 (7) More detailed requirements for leaking routes between 8428 routing protocols 8430 (8) Router system security 8432 (9) Routing protocol security 8434 (10) Internetwork Protocol layer security. There has been 8435 extensive work refining the security of IP since the 8436 original work writing this document. This security work 8437 should be included in here. 8439 (11) Route caching 8440 (12) Load Splitting 8442 (13) Sending fragments along different paths 8444 (14) Variable width subnet masks (i.e., not all subnets of a 8445 particular net use the same subnet mask). Routers are 8446 required (MUST) support them, but are not required to 8447 detect ambiguous configurations. 8449 (15) Multiple logical (sub)nets on the same wire. Router 8450 Requirements does not require support for this. We made 8451 some attempt to identify pieces of the architecture (e.g. 8452 forwarding of directed broadcasts and issuing of 8453 Redirects) where the wording of the rules has to be done 8454 carefully to make "the right thing" happen, and tried to 8455 clearly distinguish logical interfaces from physical 8456 interfaces. However, we did not study this issue in 8457 detail, and we are not at all confident that all of the 8458 rules in the document are correct in the presence of 8459 multiple logical (sub)nets on the same wire. 8461 (15) Congestion control and resource management. On the 8462 advice of the IETF's experts (Mankin and Ramakrishnan) we 8463 deprecated (SHOULD NOT) Source Quench and said little 8464 else concrete (Section 5.3.6). 8466 (16) Developing a Link-Layer requirements document that would 8467 be common for both routers and hosts. 8469 (17) Developing a common PPP LQM algorithm. 8471 (18) Investigate of other information (above and beyond 8472 section [3.2]) that passes between the layers, such as 8473 physical network MTU, mappings of IP precedence to Link 8474 Layer priority values, etc. 8476 (19) Should the Link Layer notify IP if address resolution 8477 failed (just like it notifies IP when there is a Link 8478 Layer priority value problem)? 8480 (20) Should all routers be required to implement a DNS 8481 resolver? 8483 (21) Should a human user be able to use a host name anywhere 8484 you can use an IP address when configuring the router? 8485 Even in ping and traceroute? 8487 (22) Almquist's draft ruminations on the next hop and 8488 ruminations on route leaking need to be reviewed, brought 8489 up to date, and published. 8491 (23) Investigation is needed to determine if a redirect 8492 message for precedence is needed or not. If not, are the 8493 type-of-service redirects acceptable? 8495 (24) RIPv2 and RIP+CIDR and variable length subnet masks. 8497 (25) BGP-4 CIDR is going to be important, and everyone is 8498 betting on BGP-4. We can't avoid mentioning it. Probably 8499 need to describe the differences between BGP-3 and BGP-4, 8500 and explore upgrade issues... 8502 APPENDIX D. Multicast Routing Protocols 8504 Multicasting is a relatively new technology within the 8505 Internet Protocol family. It is not widely deployed or 8506 commonly in use yet. Its importance, however, is expected to 8507 grow over the coming years. 8509 This Appendix describes some of the technologies being 8510 investigated for routing multicasts through the Internet. 8512 A diligent implementor will keep abreast of developments in 8513 this area in order to properly develop multicast facilities. 8515 This Appendix does not specify any standards or requirements. 8517 D.1 Introduction 8519 Multicast routing protocols enable the forwarding of IP 8520 multicast datagrams throughout a TCP/IP internet. Generally 8521 these algorithms forward the datagram based on its source 8522 and destination addresses. Additionally, the datagram may 8523 need to be forwarded to several multicast group members, at 8524 times requiring the datagram to be replicated and sent out 8525 multiple interfaces. 8527 The state of multicast routing protocols is less developed 8528 than the protocols available for the forwarding of IP 8529 unicasts. Two multicast routing protocols have been 8530 documented for TCP/IP; both are currently considered to be 8531 experimental. Both also use the IGMP protocol (discussed 8532 in Section [4.4]) to monitor multicast group membership. 8534 D.2 Distance Vector Multicast Routing Protocol -- DVMRP 8536 DVMRP, documented in [ROUTE:9], is based on Distance Vector 8537 or Bellman-Ford technology. It routes multicast datagrams 8538 only, and does so within a single Autonomous System. DVMRP 8539 is an implementation of the Truncated Reverse Path 8540 Broadcasting algorithm described in [ROUTE:10]. In 8541 addition, it specifies the tunneling of IP multicasts 8542 through non-multicast-routing-capable IP domains. 8544 D.3 Multicast Extensions to OSPF -- MOSPF 8546 MOSPF, currently under development, is a backward- 8547 compatible addition to OSPF that allows the forwarding of 8548 both IP multicasts and unicasts within an Autonomous 8549 System. MOSPF routers can be mixed with OSPF routers within 8550 a routing domain, and they will interoperate in the 8551 forwarding of unicasts. OSPF is a link-state or SPF-based 8552 protocol. By adding link state advertisements that pinpoint 8553 group membership, MOSPF routers can calculate the path of a 8554 multicast datagram as a tree rooted at the datagram source. 8555 Those branches that do not contain group members can then 8556 be discarded, eliminating unnecessary datagram forwarding 8557 hops. 8559 APPENDIX E Additional Next-Hop Selection Algorithms 8561 Section [5.2.4.3] specifies an algorithm that routers ought to 8562 use when selecting a next-hop for a packet. 8564 This appendix provides historical perspective for the next-hop 8565 selection problem. It also presents several additional 8566 pruning rules and next-hop selection algorithms that might be 8567 found in the Internet. 8569 This appendix presents material drawn from an earlier, 8570 unpublished, work by Philip Almquist; "Ruminations on the Next 8571 Hop". 8573 This Appendix does not specify any standards or requirements. 8575 E.1. Some Historical Perspective 8577 It is useful to briefly review the history of the topic, 8578 beginning with what is sometimes called the "classic model" 8579 of how a router makes routing decisions. This model 8580 predates IP. In this model, a router speaks some single 8581 routing protocol such as RIP. The protocol completely 8582 determines the contents of the router's FIB. The route 8583 lookup algorithm is trivial: the router looks in the FIB 8584 for a route whose destination attribute exactly matches the 8585 network number portion of the destination address in the 8586 packet. If one is found, it is used; if none is found, the 8587 destination is unreachable. Because the routing protocol 8588 keeps at most one route to each destination, the problem of 8589 what to do when there are multiple routes which match the 8590 same destination cannot arise. 8592 Over the years, this classic model has been augmented in 8593 small ways. With the advent of default routes, subnets, 8594 and host routes, it became possible to have more than one 8595 routing table entry which in some sense matched the 8596 destination. This was easily resolved by a consensus that 8597 there was a hierarchy of routes: host routes should be 8598 preferred over subnet routes, subnet routes over net 8599 routes, and net routes over default routes. 8601 With the advent of variable length subnet masks, the 8602 general approach remained the same although its description 8603 became a little more complicated. We now say that each 8604 route has a bit mask associated with it. If a particular 8605 bit in a route's bit mask is set, the corresponding bit in 8606 the route's destination attribute is significant. A route 8607 cannot be used to route a packet unless each significant 8608 bit in the route's destination attribute matches the 8609 corresponding bit in the packet's destination address, and 8610 routes with more bits set in their masks are preferred over 8611 routes which have fewer bits set in their masks. This is 8612 simply a generalization of the hierarchy of routes 8613 described above, and will be referred to for the rest of 8614 this memo as choosing a route by preferring longest match. 8616 Another way the classic model has been augmented is through 8617 a small amount of relaxation of the notion that a routing 8618 protocol has complete control over the contents of the 8619 routing table. First, static routes were introduced. For 8620 the first time, it was possible to simultaneously have two 8621 routes (one dynamic and one static) to the same 8622 destination. When this happened, a router had to have a 8623 policy (in some cases configurable, and in other cases 8624 chosen by the author of the router's software) which 8625 determined whether the static route or the dynamic route 8626 was preferred. However, this policy was only used as a tie- 8627 breaker when longest match didn't uniquely determine which 8628 route to use. Thus, for example, a static default route 8629 would never be preferred over a dynamic net route even if 8630 the policy preferred static routes over dynamic routes. 8632 The classic model had to be further augmented when inter- 8633 domain routing protocols were invented. Traditional routing 8634 protocols came to be called "interior gateway protocols" 8635 (IGPs), and at each Internet site there was a strange new 8636 beast called an "exterior gateway", a router which spoke 8637 EGP to several "BBN Core Gateways" (the routers which made 8638 up the Internet backbone at the time) at the same time as 8639 it spoke its IGP to the other routers at its site. Both 8640 protocols wanted to determine the contents of the router's 8641 routing table. Theoretically, this could result in a router 8642 having three routes (EGP, IGP, and static) to the same 8643 destination. Because of the Internet topology at the time, 8644 it was resolved with little debate that routers would be 8645 best served by a policy of preferring IGP routes over EGP 8646 routes. However, the sanctity of longest match remained 8647 unquestioned: a default route learned from the IGP would 8648 never be preferred over a net route from learned EGP. 8650 Although the Internet topology, and consequently routing in 8651 the Internet, have evolved considerably since then, this 8652 slightly augmented version of the classic model has 8653 survived pretty much intact to this day in the Internet 8654 (except that BGP has replaced EGP). Conceptually (and 8655 often in implementation) each router has a routing table 8656 and one or more routing protocol processes. Each of these 8657 processes can add any entry that it pleases, and can delete 8658 or modify any entry that it has created. When routing a 8659 packet, the router picks the best route using longest 8660 match, augmented with a policy mechanism to break ties. 8661 Although this augmented classic model has served us well, 8662 it has a number of shortcomings: 8664 + It ignores (although it could be augmented to consider) 8665 path characteristics such as quality of service and MTU. 8667 + It doesn't support routing protocols (such as OSPF and 8668 Integrated IS-IS) that require route lookup algorithms 8669 different than pure longest match. 8671 + There has not been a firm consensus on what the tie- 8672 breaking mechanism ought to be. Tie-breaking mechanisms 8673 have often been found to be difficult if not impossible 8674 to configure in such a way that the router will always 8675 pick what the network manger considers to be the 8676 "correct" route. 8678 E.2. Additional Pruning Rules 8680 Section [5.2.4.3] defined several pruning rules to use to 8681 select routes from the FIB. There are other rules that 8682 could also be used. 8684 + OSPF Route Class 8685 Routing protocols which have areas or make a distinction 8686 between internal and external routes divide their routes 8687 into classes, where classes are rank-ordered in terms of 8688 preference. A route is always chosen from the most 8689 preferred class unless none is available, in which case 8690 one is chosen from the second most preferred class, and 8691 so on. In OSPF, the classes (in order from most 8692 preferred to least preferred) are intra-area, inter- 8693 area, type 1 external (external routes with internal 8694 metrics), and type 2 external. As an additional wrinkle, 8695 a router is configured to know what addresses ought to 8696 be accessible via intra-area routes, and will not use 8697 inter- area or external routes to reach these 8698 destinations even when no intra-area route is available. 8700 More precisely, we assume that each route has a class 8701 attribute, called route.class, which is assigned by the 8702 routing protocol. The set of candidate routes is 8703 examined to determine if it contains any for which 8704 route.class = intra-area. If so, all routes except 8705 those for which route.class = intra-area are discarded. 8706 Otherwise, router checks whether the packet's 8707 destination falls within the address ranges configured 8708 for the local area. If so, the entire set of candidate 8709 routes is deleted. Otherwise, the set of candidate 8710 routes is examined to determine if it contains any for 8711 which route.class = inter-area. If so, all routes 8712 except those for which route.class = inter-area are 8713 discarded. Otherwise, the set of candidate routes is 8714 examined to determine if it contains any for which 8715 route.class = type 1 external. If so, all routes except 8716 those for which route.class = type 1 external are 8717 discarded. 8719 + IS-IS Route Class 8720 IS-IS route classes work identically to OSPF's. However, 8721 the set of classes defined by Integrated IS-IS is 8722 different, such that there isn't a one-to-one mapping 8723 between IS-IS route classes and OSPF route classes. The 8724 route classes used by Integrated IS-IS are (in order 8725 from most preferred to least preferred) intra-area, 8726 inter-area, and external. 8728 The Integrated IS-IS internal class is equivalent to the 8729 OSPF internal class. Likewise, the Integrated IS-IS 8730 external class is equivalent to OSPF's type 2 external 8731 class. However, Integrated IS-IS does not make a 8732 distinction between inter-area routes and external 8733 routes with internal metrics -- both are considered to 8734 be inter-area routes. Thus, OSPF prefers true inter-area 8735 routes over external routes with internal metrics, 8736 whereas Integrated IS-IS gives the two types of routes 8737 equal preference. 8739 + IDPR Policy 8740 A specific case of Policy. The IETF's Inter-domain 8741 Policy Routing Working Group is devising a routing 8742 protocol called Inter-Domain Policy Routing (IDPR) to 8743 support true policy-based routing in the Internet. 8744 Packets with certain combinations of header attributes 8745 (such as specific combinations of source and destination 8746 addresses or special IDPR source route options) are 8747 required to use routes provided by the IDPR protocol. 8748 Thus, unlike other Policy pruning rules, IDPR Policy 8749 would have to be applied before any other pruning rules 8750 except Basic Match. 8752 Specifically, IDPR Policy examines the packet being 8753 forwarded to ascertain if its attributes require that it 8754 be forwarded using policy-based routes. If so, IDPR 8755 Policy deletes all routes not provided by the IDPR 8756 protocol. 8758 E.3 Some Route Lookup Algorithms 8760 This section examines several route lookup algorithms that 8761 are in use or have been proposed. Each is described by 8762 giving the sequence of pruning rules it uses. The 8763 strengths and weaknesses of each algorithm are presented 8765 E.3.1 The Revised Classic Algorithm 8767 The Revised Classic Algorithm is the form of the 8768 traditional algorithm which was discussed in Section 8769 [E.1]. The steps of this algorithm are: 8770 1. Basic match 8771 2. Longest match 8772 3. Best metric 8773 4. Policy 8774 Some implementations omit the Policy step, since it is 8775 needed only when routes may have metrics that are not 8776 comparable (because they were learned from different 8777 routing domains). 8779 The advantages of this algorithm are: 8781 (1) It is widely implemented. 8783 (2) Except for the Policy step (which an implementor 8784 can choose to make arbitrarily complex) the 8785 algorithm is simple both to understand and to 8786 implement. 8788 Its disadvantages are: 8790 (1) It does not handle IS-IS or OSPF route classes, and 8791 therefore cannot be used for Integrated IS-IS or 8792 OSPF. 8794 (2) It does not handle TOS or other path attributes. 8796 (3) The policy mechanisms are not standardized in any 8797 way, and are therefore are often implementation- 8798 specific. This causes extra work for implementors 8799 (who must invent appropriate policy mechanisms) and 8800 for users (who must learn how to use the 8801 mechanisms. This lack of a standardized mechanism 8802 also makes it difficult to build consistent 8803 configurations for routers from different vendors. 8804 This presents a significant practical deterrent to 8805 multi-vendor interoperability. 8807 (4) The proprietary policy mechanisms currently 8808 provided by vendors are often inadequate in complex 8809 parts of the Internet. 8811 (5) The algorithm has not been written down in any 8812 generally available document or standard. It is, 8813 in effect, a part of the Internet Folklore. 8815 E.3.2 The Variant Router Requirements Algorithm 8817 Some Router Requirements Working Group members have 8818 proposed a slight variant of the algorithm described in 8819 the Section [5.2.4.3]. In this variant, matching the 8820 type of service requested is considered to be more 8821 important, rather than less important, than matching as 8822 much of the destination address as possible. For 8823 example, this algorithm would prefer a default route 8824 which had the correct type of service over a network 8825 route which had the default type of service, whereas the 8826 algorithm in [5.2.4.3] would make the opposite choice. 8828 The steps of the algorithm are: 8829 1. Basic match 8830 2. Weak TOS 8831 3. Longest match 8832 4. Best metric 8833 5. Policy 8835 Debate between the proponents of this algorithm and the 8836 regular Router Requirements Algorithm suggests that each 8837 side can show cases where its algorithm leads to 8838 simpler, more intuitive routing than the other's 8839 algorithm does. In general, this variant has the same 8840 set of advantages and disadvantages that the algorithm 8841 specified in [5.2.4.3] does, except that pruning on Weak 8842 TOS before pruning on Longest Match makes this algorithm 8843 less compatible with OSPF and Integrated IS-IS than the 8844 standard Router Requirements Algorithm. 8846 E.3.3 The OSPF Algorithm 8848 OSPF uses an algorithm which is virtually identical to 8849 the Router Requirements Algorithm except for one crucial 8850 difference: OSPF considers OSPF route classes. 8852 The algorithm is: 8853 1. Basic match 8854 2. OSPF route class 8855 3. Longest match 8856 4. Weak TOS 8857 5. Best metric 8858 6. Policy 8860 Type of service support is not always present. If it is 8861 not present then, of course, the fourth step would be 8862 omitted 8864 This algorithm has some advantages over the Revised 8865 Classic Algorithm: 8867 (1) It supports type of service routing. 8869 (2) Its rules are written down, rather than merely 8870 being a part of the Internet folklore. 8872 (3) It (obviously) works with OSPF. 8874 However, this algorithm also retains some of the 8875 disadvantages of the Revised Classic Algorithm: 8877 (1) Path properties other than type of service (e.g. 8878 MTU) are ignored. 8880 (2) As in the Revised Classic Algorithm, the details 8881 (or even the existence) of the Policy step are left 8882 to the discretion of the implementor. 8884 The OSPF Algorithm also has a further disadvantage 8885 (which is not shared by the Revised Classic Algorithm). 8886 OSPF internal (intra-area or inter-area) routes are 8887 always considered to be superior to routes learned from 8888 other routing protocols, even in cases where the OSPF 8889 route matches fewer bits of the destination address. 8890 This is a policy decision that is inappropriate in some 8891 networks. 8893 Finally, it is worth noting that the OSPF Algorithm's 8894 TOS support suffers from a deficiency in that routing 8895 protocols which support TOS are implicitly preferred 8896 when forwarding packets which have non-zero TOS values. 8897 This may not be appropriate in some cases. 8899 E.3.4 The Integrated IS-IS Algorithm 8901 Integrated IS-IS uses an algorithm which is similar to 8902 but not quite identical to the OSPF Algorithm. 8903 Integrated IS-IS uses a different set of route classes, 8904 and also differs slightly in its handling of type of 8905 service. The algorithm is: 8906 1. Basic Match 8907 2. IS-IS Route Classes 8908 3. Longest Match 8909 4. Weak TOS 8910 5. Best Metric 8911 6. Policy 8913 Although Integrated IS-IS uses Weak TOS, the protocol is 8914 only capable of carrying routes for a small specific 8915 subset of the possible values for the TOS field in the 8916 IP header. Packets containing other values in the TOS 8917 field are routed using the default TOS. 8919 Type of service support is optional; if disabled, the 8920 fourth step would be omitted. As in OSPF, the 8921 specification does not include the Policy step. 8923 This algorithm has some advantages over the Revised 8924 Classic Algorithm: 8925 (1) It supports type of service routing. 8926 (2) Its rules are written down, rather than merely 8927 being a part of the Internet folklore. 8928 (3) It (obviously) works with Integrated IS-IS. 8930 However, this algorithm also retains some of the 8931 disadvantages of the Revised Classic Algorithm: 8932 (1) Path properties other than type of service (e.g. 8933 MTU) are ignored. 8934 (2) As in the Revised Classic Algorithm, the details 8935 (or even the existence) of the Policy step are left 8936 to the discretion of the implementor. 8937 (3) It doesn't work with OSPF because of the 8938 differences between IS-IS route classes and OSPF 8939 route classes. Also, because IS-IS supports only a 8940 subset of the possible TOS values, some obvious 8941 implementations of the Integrated IS-IS algorithm 8942 would not support OSPF's interpretation of TOS. 8944 The Integrated IS-IS Algorithm also has a further 8945 disadvantage (which is not shared by the Revised Classic 8946 Algorithm): IS-IS internal (intra-area or inter-area) 8947 routes are always considered to be superior to routes 8948 learned from other routing protocols, even in cases 8949 where the IS-IS route matches fewer bits of the 8950 destination address and doesn't provide the requested 8951 type of service. This is a policy decision that may not 8952 be appropriate in all cases. 8954 Finally, it is worth noting that the Integrated IS-IS 8955 Algorithm's TOS support suffers from the same deficiency 8956 noted for the OSPF Algorithm. 8958 Security Considerations 8960 Although the focus of this document is interoperability rather 8961 than security, there are obviously many sections of this 8962 document which have some ramifications on network security. 8964 "Security" means different things to different people. 8965 Security from a router's point of view is anything that helps 8966 to keep its own networks operational and in addition helps to 8967 keep the Internet as a whole healthy. For the purposes of 8968 this document, the security services we are concerned with are 8969 "denial of service", "integrity", and "authentication" as it 8970 applies to the first two. "Privacy" as a security service is 8971 important, but only peripherally a concern of a router -- at 8972 least as of the date of this document. 8974 In several places in this document there are sections entitled 8975 "... Security Considerations". These sections discuss 8976 specific considerations that apply to the general topic under 8977 discussion. 8979 Rarely does this document say "do this and your router/network 8980 will be secure". More likely, it says "this is a good idea 8981 and if you do it, it *may* improve the security of the 8982 Internet and your local system in general." 8984 Unfortunately, this is the state-of-the-art AT THIS TIME. Few 8985 if any of the network protocols a router is concerned with 8986 have reasonable, built-in security features. Industry and the 8987 protocol designers have been and are continuing to struggle 8988 with these issues. There is progress, but only small baby 8989 steps such as the peer-to-peer authentication available in the 8990 BGP and OSPF routing protocols. 8992 In particular, this document notes the current research into 8993 developing and enhancing network security. Specific areas of 8994 research, development, and engineering that are underway as of 8995 this writing (December 1993) are in IP Security, SNMP 8996 Security, and common authentication technologies. 8998 Notwithstanding all of the above, there are things both 8999 vendors and users can do to improve the security of their 9000 router. Vendors should get a copy of "Trusted Computer System 9001 Interpretation" [INTRO:8]. Even if a vendor decides not to 9002 submit their device for formal verification under these 9003 guidelines, the publication provides excellent guidance on 9004 general security design and practices for computing devices. 9006 Acknowledgments 9008 O that we now had here 9009 But one ten thousand of those men in England 9010 That do no work to-day! 9012 What's he that wishes so? 9013 My cousin Westmoreland? No, my fair cousin: 9014 If we are mark'd to die, we are enow 9015 To do our country loss; and if to live, 9016 The fewer men, the greater share of honour. 9017 God's will! I pray thee, wish not one man more. 9018 By Jove, I am not covetous for gold, 9019 Nor care I who doth feed upon my cost; 9020 It yearns me not if men my garments wear; 9021 Such outward things dwell not in my desires: 9022 But if it be a sin to covet honour, 9023 I am the most offending soul alive. 9024 No, faith, my coz, wish not a man from England: 9025 God's peace! I would not lose so great an honour 9026 As one man more, methinks, would share from me 9027 For the best hope I have. O, do not wish one more! 9028 Rather proclaim it, Westmoreland, through my host, 9029 That he which hath no stomach to this fight, 9030 Let him depart; his passport shall be made 9031 And crowns for convoy put into his purse: 9032 We would not die in that man's company 9033 That fears his fellowship to die with us. 9034 This day is called the feast of Crispian: 9035 He that outlives this day, and comes safe home, 9036 Will stand a tip-toe when the day is named, 9037 And rouse him at the name of Crispian. 9038 He that shall live this day, and see old age, 9039 Will yearly on the vigil feast his neighbours, 9040 And say 'To-morrow is Saint Crispian:' 9041 Then will he strip his sleeve and show his scars. 9042 And say 'These wounds I had on Crispin's day.' 9043 Old men forget: yet all shall be forgot, 9044 But he'll remember with advantages 9045 What feats he did that day: then shall our names. 9046 Familiar in his mouth as household words 9047 Harry the king, Bedford and Exeter, 9048 Warwick and Talbot, Salisbury and Gloucester, 9049 Be in their flowing cups freshly remember'd. 9050 This story shall the good man teach his son; 9051 And Crispin Crispian shall ne'er go by, 9052 From this day to the ending of the world, 9053 But we in it shall be remember'd; 9054 We few, we happy few, we band of brothers; 9055 For he to-day that sheds his blood with me 9056 Shall be my brother; be he ne'er so vile, 9057 This day shall gentle his condition: 9058 And gentlemen in England now a-bed 9059 Shall think themselves accursed they were not here, 9060 And hold their manhoods cheap whiles any speaks 9061 That fought with us upon Saint Crispin's day. 9063 This memo is a product of the IETF's Router Requirements 9064 Working Group. A memo such as this one is of necessity the 9065 work of many more people than could be listed here. A wide 9066 variety of vendors, network managers, and other experts from 9067 the Internet community graciously contributed their time and 9068 wisdom to improve the quality of this memo. The editor wishes 9069 to extend sincere thanks to all of them. 9071 The current editor also wishes to single out and extend his 9072 heartfelt gratitude and appreciation to the original editor of 9073 this document; Philip Almquist. Without Philip's work, both 9074 as the original editor and as the Chair of the working group, 9075 this document would not have been produced. 9077 Philip Almquist, Jeffrey Burgan, Frank Kastenholz, and Cathy 9078 Wittbrodt each wrote major chapters of this memo. Others who 9079 made major contributions to the document included Bill Barns, 9080 Steve Deering, Kent England, Jim Forster, Martin Gross, Jeff 9081 Honig, Steve Knowles, Yoni Malachi, Michael Reilly, and Walt 9082 Wimer. 9084 Additional text came from Art Berggreen, John Cavanaugh, Ross 9085 Callon, John Lekashman, Brian Lloyd, Gary Malkin, Milo Medin, 9086 John Moy, Craig Partridge, Stephanie Price, Yakov Rekhter, 9087 Steve Senum, Richard Smith, Frank Solensky, Rich Woundy, and 9088 others who have been inadvertently overlooked. 9090 Some of the text in this memo has been (shamelessly) 9091 plagiarized from earlier documents, most notably RFC-1122 by 9092 Bob Braden and the Host Requirements Working Group, and 9093 RFC-1009 by Bob Braden and Jon Postel. The work of these 9094 earlier authors is gratefully acknowledged. 9096 Jim Forster was a co-chair of the Router Requirements Working 9097 Group during its early meetings, and was instrumental in 9098 getting the group off to a good start. Jon Postel, Bob 9099 Braden, and Walt Prue also contributed to the success by 9100 providing a wealth of good advice prior to the group's first 9101 meeting. Later on, Phill Gross, Vint Cerf, and Noel Chiappa 9102 all provided valuable advice and support. 9104 Mike St. Johns coordinated the Working Group's interactions 9105 with the security community, and Frank Kastenholz coordinated 9106 the Working Group's interactions with the network management 9107 area. Allison Mankin and K.K. Ramakrishnan provided expertise 9108 on the issues of congestion control and resource allocation. 9110 Many more people than could possibly be listed or credited 9111 here participated in the deliberations of the Router 9112 Requirements Working Group, either through electronic mail or 9113 by attending meetings. However, the efforts of Ross Callon 9114 and Vince Fuller in sorting out the difficult issues of route 9115 choice and route leaking are especially acknowledged. 9117 The previous editor, Philip Almquist, wishes to extend his 9118 thanks and appreciation to his former employers, Stanford 9119 University and BARRNet, for allowing him to spend a large 9120 fraction (probably far more than they ever imagined when he 9121 started on this) of his time working on this project. 9123 The current editor wishes to thank his employer, FTP Software, 9124 for allowing him to spend the time necessary to finish this 9125 document. 9127 Editor's Address 9129 The address of the current editor of this document is 9130 Frank J. Kastenholz 9131 FTP Software 9132 2 High Street 9133 North Andover, MA, 01845-2620 9134 USA 9136 Phone: +1 508-685-4000 9138 EMail: kasten@ftp.com 9140 Table of Contents 9142 Status of this Memo .................................... i 9143 1. INTRODUCTION ....................................... 1 9144 1.1 Reading this Document ............................. 3 9145 1.1.1 Organization .................................... 3 9146 1.1.2 Requirements .................................... 4 9147 1.1.3 Compliance ...................................... 5 9148 1.2 Relationships to Other Standards .................. 7 9149 1.3 General Considerations ............................ 8 9150 1.3.1 Continuing Internet Evolution ................... 8 9151 1.3.2 Robustness Principle ............................ 9 9152 1.3.3 Error Logging ................................... 10 9153 1.3.4 Configuration ................................... 11 9154 1.4 Algorithms ........................................ 12 9155 2. INTERNET ARCHITECTURE .............................. 14 9156 2.1 Introduction ...................................... 14 9157 2.2 Elements of the Architecture ...................... 15 9158 2.2.1 Protocol Layering ............................... 15 9159 2.2.2 Networks ........................................ 17 9160 2.2.3 Routers ......................................... 18 9161 2.2.4 Autonomous Systems .............................. 20 9162 2.2.5 Addresses and Subnets ........................... 20 9163 2.2.6 IP Multicasting ................................. 22 9164 2.2.7 Unnumbered Lines and Networks and Subnets ....... 23 9165 2.2.8 Notable Oddities ................................ 25 9166 2.2.8.1 Embedded Routers .............................. 25 9167 2.2.8.2 Transparent Routers ........................... 26 9168 2.3 Router Characteristics ............................ 27 9169 2.4 Architectural Assumptions ......................... 31 9170 3. LINK LAYER ......................................... 34 9171 3.1 INTRODUCTION ...................................... 34 9172 3.2 LINK/INTERNET LAYER INTERFACE ..................... 34 9173 3.3 SPECIFIC ISSUES ................................... 36 9174 3.3.1 Trailer Encapsulation ........................... 36 9175 3.3.2 Address Resolution Protocol -- ARP .............. 36 9176 3.3.3 Ethernet and 802.3 Coexistence .................. 36 9177 3.3.4 Maximum Transmission Unit -- MTU ................ 37 9178 3.3.5 Point-to-Point Protocol -- PPP .................. 37 9179 3.3.5.1 Introduction .................................. 38 9180 3.3.5.2 Link Control Protocol (LCP) Options ........... 38 9181 3.3.5.3 IP Control Protocol (ICP) Options ............. 40 9182 3.3.6 Interface Testing ............................... 41 9183 4. INTERNET LAYER -- PROTOCOLS ........................ 42 9184 4.1 INTRODUCTION ...................................... 42 9185 4.2 INTERNET PROTOCOL -- IP ........................... 42 9186 4.2.1 INTRODUCTION .................................... 42 9187 4.2.2 PROTOCOL WALK-THROUGH ........................... 43 9188 4.2.2.1 Options: RFC-791 Section 3.2 .................. 43 9189 4.2.2.2 Addresses in Options: RFC-791 Section 3.1 ..... 46 9190 4.2.2.3 Unused IP Header Bits: RFC-791 Section 3.1 9191 .................................................... 47 9192 4.2.2.4 Type of Service: RFC-791 Section 3.1 .......... 48 9193 4.2.2.5 Header Checksum: RFC-791 Section 3.1 .......... 48 9194 4.2.2.6 Unrecognized Header Options: RFC-791 Section 9195 3.1 ................................................ 49 9196 4.2.2.7 Fragmentation: RFC-791 Section 3.2 ............ 49 9197 4.2.2.8 Reassembly: RFC-791 Section 3.2 ............... 50 9198 4.2.2.9 Time to Live: RFC-791 Section 3.2 ............. 51 9199 4.2.2.10 Multi-subnet Broadcasts: RFC-922 ............. 51 9200 4.2.2.11 Addressing: RFC-791 Section 3.2 .............. 51 9201 4.2.3 SPECIFIC ISSUES ................................. 55 9202 4.2.3.1 IP Broadcast Addresses ........................ 55 9203 4.2.3.2 IP Multicasting ............................... 56 9204 4.2.3.3 Path MTU Discovery ............................ 57 9205 4.2.3.4 Subnetting .................................... 58 9206 4.3 INTERNET CONTROL MESSAGE PROTOCOL -- ICMP ......... 59 9207 4.3.1 INTRODUCTION .................................... 59 9208 4.3.2 GENERAL ISSUES .................................. 59 9209 4.3.2.1 Unknown Message Types ......................... 60 9210 4.3.2.2 ICMP Message TTL .............................. 60 9211 4.3.2.3 Original Message Header ....................... 60 9212 4.3.2.4 ICMP Message Source Address ................... 60 9213 4.3.2.5 TOS and Precedence ............................ 61 9214 4.3.2.6 Source Route .................................. 62 9215 4.3.2.7 When Not to Send ICMP Errors .................. 62 9216 4.3.2.8 Rate Limiting ................................. 64 9217 4.3.3 SPECIFIC ISSUES ................................. 65 9218 4.3.3.1 Destination Unreachable ....................... 65 9219 4.3.3.2 Redirect ...................................... 66 9220 4.3.3.3 Source Quench ................................. 66 9221 4.3.3.4 Time Exceeded ................................. 67 9222 4.3.3.5 Parameter Problem ............................. 67 9223 4.3.3.6 Echo Request/Reply ............................ 68 9224 4.3.3.7 Information Request/Reply ..................... 69 9225 4.3.3.8 Timestamp and Timestamp Reply ................. 69 9226 4.3.3.9 Address Mask Request/Reply .................... 71 9227 4.3.3.10 Router Advertisement and Solicitations ....... 72 9228 4.4 INTERNET GROUP MANAGEMENT PROTOCOL -- IGMP ........ 73 9229 5. INTERNET LAYER -- FORWARDING ....................... 74 9230 5.1 INTRODUCTION ...................................... 74 9231 5.2 FORWARDING WALK-THROUGH ........................... 74 9232 5.2.1 Forwarding Algorithm ............................ 74 9233 5.2.1.1 General ....................................... 75 9234 5.2.1.2 Unicast ....................................... 76 9235 5.2.1.3 Multicast ..................................... 77 9236 5.2.2 IP Header Validation ............................ 79 9237 5.2.3 Local Delivery Decision ......................... 81 9238 5.2.4 Determining the Next Hop Address ................ 84 9239 5.2.4.1 Immediate Destination Address ................. 85 9240 5.2.4.2 Local/Remote Decision ......................... 85 9241 5.2.4.3 Next Hop Address .............................. 87 9242 5.2.4.4 Administrative Preference ..................... 92 9243 5.2.4.6 Load Splitting ................................ 94 9244 5.2.5 Unused IP Header Bits: RFC-791 Section 3.1 ...... 94 9245 5.2.6 Fragmentation and Reassembly: RFC-791 Section 9246 3.2 ................................................ 95 9247 5.2.7 Internet Control Message Protocol -- ICMP ....... 95 9248 5.2.7.1 Destination Unreachable ....................... 96 9249 5.2.7.2 Redirect ...................................... 98 9250 5.2.7.3 Time Exceeded ................................. 100 9251 5.2.8 INTERNET GROUP MANAGEMENT PROTOCOL -- IGMP ...... 101 9252 5.3 SPECIFIC ISSUES ................................... 101 9253 5.3.1 Time to Live (TTL) .............................. 101 9254 5.3.2 Type of Service (TOS) ........................... 103 9255 5.3.3 IP Precedence ................................... 104 9256 5.3.3.1 Precedence-Ordered Queue Service .............. 106 9257 5.3.3.2 Lower Layer Precedence Mappings ............... 106 9258 5.3.3.3 Precedence Handling For All Routers ........... 107 9259 5.3.4 Forwarding of Link Layer Broadcasts ............. 110 9260 5.3.5 Forwarding of Internet Layer Broadcasts ......... 111 9261 5.3.5.1 Limited Broadcasts ............................ 113 9262 5.3.5.2 Net-directed Broadcasts ....................... 113 9263 5.3.5.3 All-subnets-directed Broadcasts ............... 114 9264 5.3.5.4 Subnet-directed Broadcasts .................... 117 9265 5.3.6 Congestion Control .............................. 117 9266 5.3.7 Martian Address Filtering ....................... 119 9267 5.3.8 Source Address Validation ....................... 120 9268 5.3.9 Packet Filtering and Access Lists ............... 120 9269 5.3.10 Multicast Routing .............................. 122 9270 5.3.11 Controls on Forwarding ......................... 122 9271 5.3.12 State Changes .................................. 122 9272 5.3.12.1 When a Router Ceases Forwarding .............. 123 9273 5.3.12.2 When a Router Starts Forwarding .............. 124 9274 5.3.12.3 When an Interface Fails or is Disabled ....... 124 9275 5.3.12.4 When an Interface is Enabled ................. 124 9276 5.3.13 IP Options ..................................... 125 9277 5.3.13.1 Unrecognized Options ......................... 125 9278 5.3.13.2 Security Option .............................. 125 9279 5.3.13.3 Stream Identifier Option ..................... 125 9280 5.3.13.4 Source Route Options ......................... 126 9281 5.3.13.5 Record Route Option .......................... 126 9282 5.3.13.6 Timestamp Option ............................. 127 9283 6. TRANSPORT LAYER .................................... 129 9284 6.1 USER DATAGRAM PROTOCOL -- UDP ..................... 129 9285 6.2 TRANSMISSION CONTROL PROTOCOL -- TCP .............. 129 9286 7. APPLICATION LAYER -- ROUTING PROTOCOLS ............. 132 9287 7.1 INTRODUCTION ...................................... 132 9288 7.1.1 Routing Security Considerations ................. 132 9289 7.1.2 Precedence ...................................... 133 9290 7.2 INTERIOR GATEWAY PROTOCOLS ........................ 133 9291 7.2.1 INTRODUCTION .................................... 133 9292 7.2.2 OPEN SHORTEST PATH FIRST -- OSPF ................ 134 9293 7.2.2.1 Introduction .................................. 134 9294 7.2.2.2 Specific Issues ............................... 135 9295 7.2.2.3 New Version of OSPF ........................... 135 9296 7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM -- 9297 DUAL IS-IS ......................................... 136 9298 7.2.4 ROUTING INFORMATION PROTOCOL -- RIP ............. 137 9299 7.2.4.1 Introduction .................................. 137 9300 7.2.4.2 Protocol Walk-Through ......................... 137 9301 7.2.4.3 Specific Issues ............................... 144 9302 7.2.5 GATEWAY TO GATEWAY PROTOCOL -- GGP .............. 145 9303 7.3 EXTERIOR GATEWAY PROTOCOLS ........................ 145 9304 7.3.1 INTRODUCTION .................................... 145 9305 7.3.2 BORDER GATEWAY PROTOCOL -- BGP .................. 146 9306 7.3.2.1 Introduction .................................. 146 9307 7.3.2.2 Protocol Walk-through ......................... 147 9308 7.3.3 EXTERIOR GATEWAY PROTOCOL -- EGP ................ 148 9309 7.3.3.1 Introduction .................................. 148 9310 7.3.3.2 Protocol Walk-through ......................... 148 9311 7.3.4 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL 9312 .................................................... 152 9313 7.4 STATIC ROUTING .................................... 152 9314 7.5 FILTERING OF ROUTING INFORMATION .................. 154 9315 7.5.1 Route Validation ................................ 155 9316 7.5.2 Basic Route Filtering ........................... 155 9317 7.5.3 Advanced Route Filtering ........................ 156 9318 7.6 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE ....... 157 9319 8. APPLICATION LAYER -- NETWORK MANAGEMENT PROTOCOLS 9320 .................................................... 159 9321 8.1 The Simple Network Management Protocol -- SNMP 9322 .................................................... 159 9323 8.1.1 SNMP Protocol Elements .......................... 159 9324 8.2 Community Table ................................... 160 9325 8.3 Standard MIBS ..................................... 161 9326 8.4 Vendor Specific MIBS .............................. 163 9327 8.5 Saving Changes .................................... 164 9328 9. APPLICATION LAYER -- MISCELLANEOUS PROTOCOLS ....... 166 9329 9.1 BOOTP ............................................. 166 9330 9.1.1 Introduction .................................... 166 9331 9.1.2 BOOTP Relay Agents .............................. 166 9332 10. OPERATIONS AND MAINTENANCE ........................ 168 9333 10.1 Introduction ..................................... 168 9334 10.2 Router Initialization ............................ 170 9335 10.2.1 Minimum Router Configuration ................... 170 9336 10.2.2 Address and Address Mask Initialization ........ 170 9337 10.2.3 Network Booting using BOOTP and TFTP ........... 172 9338 10.3 Operation and Maintenance ........................ 173 9339 10.3.1 Introduction ................................... 173 9340 10.3.2 Out Of Band Access ............................. 174 9341 10.3.2 Router O&M Functions ........................... 175 9342 10.3.2.1 Maintenance -- Hardware Diagnosis ............ 175 9343 10.3.2.2 Control -- Dumping and Rebooting ............. 175 9344 10.3.2.3 Control -- Configuring the Router ............ 175 9345 10.3.2.4 Netbooting of System Software ................ 176 9346 10.3.2.5 Detecting and responding to misconfigura- 9347 tion ............................................... 177 9348 10.3.2.6 Minimizing Disruption ........................ 178 9349 10.3.2.7 Control -- Troubleshooting Problems .......... 178 9350 10.4 Security Considerations .......................... 180 9351 10.4.1 Auditing and Audit Trails ...................... 180 9352 10.4.2 Configuration Control .......................... 182 9353 11. REFERENCES ........................................ 184 9354 APPENDIX A. REQUIREMENTS FOR SOURCE-ROUTING HOSTS 9355 .................................................... 196 9356 APPENDIX B. GLOSSARY .................................. 198 9357 APPENDIX C. FUTURE DIRECTIONS ......................... 204 9358 APPENDIX D. Multicast Routing Protocols ............... 207 9359 D.1 Introduction ...................................... 207 9360 D.2 Distance Vector Multicast Routing Protocol -- 9361 DVMRP .............................................. 207 9362 D.3 Multicast Extensions to OSPF -- MOSPF ............. 208 9363 APPENDIX E Additional Next-Hop Selection Algorithms 9364 .................................................... 209 9365 E.1. Some Historical Perspective ....................... 209 9366 E.2. Additional Pruning Rules .......................... 211 9367 E.3 Some Route Lookup Algorithms ...................... 213 9368 E.3.1 The Revised Classic Algorithm .................... 213 9369 E.3.2 The Variant Router Requirements Algorithm ........ 215 9370 E.3.3 The OSPF Algorithm ............................... 215 9371 E.3.4 The Integrated IS-IS Algorithm ................... 217 9372 Security Considerations ................................ 219 9373 Acknowledgments ........................................ 221 9374 Editor's Address ....................................... 224