idnits 2.17.1 draft-ietf-rreq-cidr-02.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-26) 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 106 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 241 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 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 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 == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 282: '...s similar in meaning to SHOULD, but is...' RFC 2119 keyword, line 326: '... satisfies all the Relevant MUST, MUST...' RFC 2119 keyword, line 327: '... IMPLEMENT, and MUST NOT requirements...' RFC 2119 keyword, line 330: '... Relevant SHOULD, SHOULD IMPLEMEN...' RFC 2119 keyword, line 333: '...one or more of the Relevant MUST, MUST...' (618 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 8529 has weird spacing: '...no part of th...' == 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 that claims that the Link Layer address of another host or router is a broadcast or multicast address. -- 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 (17 March 1995) is 10633 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 2236 looks like a reference -- Missing reference section? '7' on line 5669 looks like a reference -- Missing reference section? 'Type-of-Service' on line 5956 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT 4 Requirements for IP Version 4 Routers 6 17 March 1995 7 Document Revision 2.05 | 8 draft-ietf-rreq-cidr-02.txt | 9 Revision Date: 10 3/17/95 | 12 Fred Baker (Editor) 14 Cisco Systems 15 519 Lado Drive 16 Santa Barbara, California 93111 18 fred@cisco.com 20 Status of this Memo 22 This document is an Internet Draft. Internet Drafts are 23 working documents of the Internet Engineering Task Force 24 (IETF), its Areas, and its Working Groups. Note that other 25 groups may also distribute working documents as Internet 26 Drafts. 28 Internet Drafts are draft documents valid for a maximum of six 29 months. Internet Drafts may be updated, replaced, or 30 obsoleted by other documents at any time. It is not 31 appropriate to use Internet Drafts as reference material or to 32 cite them other than as a ``working draft'' or ``work in 33 progress.'' Please check the 1id-abstracts.txt listing 34 contained in the internet-drafts Shadow Directories on 35 nic.ddn.mil, venera.isi.edu, nnsc.nsf.net, nic.nordu.net, 36 ftp.nisc.sri.com, or munnari.oz.au to learn the current status 37 of any Internet Draft. 39 Draft Requirements for IP Version 4 Routers March 1995 41 This is a working document only, it should neither be cited 42 nor quoted in any formal document. 44 This document will expire before 22 Sep. 1995. 46 Distribution of this document is unlimited. 48 Please send comments to The editor or the Router Requirements 49 Working Group (rreq@isi.edu). 51 If your comment pertains to a particular piece of text, please 52 remember to mention the section number. This document is very 53 large and locating the text solely by context might not be 54 possible. Please also mention the date of this draft | 55 (3/17/95) and the revision level (2.05). 57 Draft Requirements for IP Version 4 Routers March 1995 59 0. PREFACE 61 This document is an updated version of RFC 1716, the 62 historical Router Requirements document. That RFC preserved 63 the significant work that went into the working group, but 64 failed to adequately describe current technology for the IESG 65 to consider it a current standard. 67 The current editor had been asked to bring the document up to 68 date, so that it is useful as a procurement specification and 69 a guide to implementors. In this, he stands squarely on the 70 shoulders of those who have gone before him, and depends 71 largely on expert contributors for text. Any credit is 72 theirs; the errors are his. 74 The content and form of this document are due, in large part, 75 to the working group's chair, and document's original editor 76 and author: Philip Almquist. It is also largely due to the 77 efforts of its previous editor, Frank Kastenholz. Without 78 their efforts, this document would not exist. 80 Draft Requirements for IP Version 4 Routers March 1995 82 1. INTRODUCTION 84 The memo replaces for RFC 1716, "Requirements for Internet 85 Gateways" ([INTRO:1]). 87 This memo defines and discusses requirements for devices that 88 perform the network layer forwarding function of the Internet 89 protocol suite. The Internet community usually refers to such 90 devices as "IP routers" or simply "routers"; The OSI community 91 refers to such devices as "intermediate systems". Many older 92 Internet documents refer to these devices as "gateways", a 93 name which more recently has largely passed out of favor to 94 avoid confusion with application gateways. 96 An IP router can be distinguished from other sorts of packet 97 switching devices in that a router examines the IP protocol 98 header as part of the switching process. It generally removes 99 the Link Layer header a message was received with, modifies 100 the IP header, and replaces the Link Layer header for 101 retransmission. 103 The authors of this memo recognize, as should its readers, 104 that many routers support more than one protocol. Support for 105 multiple protocol suites will be required in increasingly 106 large parts of the Internet in the future. This memo, 107 however, does not attempt to specify Internet requirements for 108 protocol suites other than TCP/IP. 110 This document enumerates standard protocols that a router 111 connected to the Internet must use, and it incorporates by 112 reference the RFCs and other documents describing the current 113 specifications for these protocols. It corrects errors in the 114 referenced documents and adds additional discussion and 115 guidance for an implementor. 117 For each protocol, this memo also contains an explicit set of 118 requirements, recommendations, and options. The reader must 119 understand that the list of requirements in this memo is 120 incomplete by itself. The complete set of requirements for an 121 Internet protocol router is primarily defined in the standard 122 protocol specification documents, with the corrections, 123 amendments, and supplements contained in this memo. 125 This memo should be read in conjunction with the Requirements 127 Draft Requirements for IP Version 4 Routers March 1995 129 for Internet Hosts RFCs ([INTRO:2] and [INTRO:3]). Internet 130 hosts and routers must both be capable of originating IP 131 datagrams and receiving IP datagrams destined for them. The 132 major distinction between Internet hosts and routers is that 133 routers implement forwarding algorithms, while Internet hosts 134 do not require forwarding capabilities. Any Internet host 135 acting as a router must adhere to the requirements contained 136 in this memo. 138 The goal of "open system interconnection" dictates that 139 routers must function correctly as Internet hosts when 140 necessary. To achieve this, this memo provides guidelines for 141 such instances. For simplification and ease of document 142 updates, this memo tries to avoid overlapping discussions of 143 host requirements with [INTRO:2] and [INTRO:3] and 144 incorporates the relevant requirements of those documents by 145 reference. In some cases the requirements stated in [INTRO:2] 146 and [INTRO:3] are superseded by this document. 148 A good-faith implementation of the protocols produced after 149 careful reading of the RFCs should differ from the 150 requirements of this memo in only minor ways. Producing such 151 an implementation often requires some interaction with the 152 Internet technical community, and must follow good 153 communications software engineering practices. In many cases, 154 the "requirements" in this document are already stated or 155 implied in the standard protocol documents, so that their 156 inclusion here is, in a sense, redundant. They were included 157 because some past implementation has made the wrong choice, 158 causing problems of interoperability, performance, and/or 159 robustness. 161 This memo includes discussion and explanation of many of the 162 requirements and recommendations. A simple list of 163 requirements would be dangerous, because: 165 + Some required features are more important than others, and 166 some features are optional. 168 + Some features are critical in some applications of routers 169 but irrelevant in others. 171 + There may be valid reasons why particular vendor products 172 that are designed for restricted contexts might choose to 174 Draft Requirements for IP Version 4 Routers March 1995 176 use different specifications. 178 However, the specifications of this memo must be followed to 179 meet the general goal of arbitrary router interoperation 180 across the diversity and complexity of the Internet. Although 181 most current implementations fail to meet these requirements 182 in various ways, some minor and some major, this specification 183 is the ideal towards which we need to move. 185 These requirements are based on the current level of Internet 186 architecture. This memo will be updated as required to 187 provide additional clarifications or to include additional 188 information in those areas in which specifications are still 189 evolving. 191 1.1 Reading this Document 193 1.1.1 Organization 195 This memo emulates the layered organization used by 196 [INTRO:2] and [INTRO:3]. Thus, Chapter 2 describes the 197 layers found in the Internet architecture. Chapter 3 198 covers the Link Layer. Chapters 4 and 5 are concerned 199 with the Internet Layer protocols and forwarding 200 algorithms. Chapter 6 covers the Transport Layer. 201 Upper layer protocols are divided among Chapters 7, 8, 202 and 9. Chapter 7 discusses the protocols which routers 203 use to exchange routing information with each other. 204 Chapter 8 discusses network management. Chapter 9 205 discusses other upper layer protocols. The final 206 chapter covers operations and maintenance features. 207 This organization was chosen for simplicity, clarity, 208 and consistency with the Host Requirements RFCs. 209 Appendices to this memo include a bibliography, a 210 glossary, and some conjectures about future directions 211 of router standards. 213 In describing the requirements, we assume that an 214 implementation strictly mirrors the layering of the 215 protocols. However, strict layering is an imperfect 216 model, both for the protocol suite and for recommended 218 Draft Requirements for IP Version 4 Routers March 1995 220 implementation approaches. Protocols in different 221 layers interact in complex and sometimes subtle ways, 222 and particular functions often involve multiple layers. 223 There are many design choices in an implementation, many 224 of which involve creative "breaking" of strict layering. 225 Every implementor is urged to read [INTRO:4] and 226 [INTRO:5]. 228 Each major section of this memo is organized into the 229 following subsections: 231 (1) Introduction 233 (2) Protocol Walk-Through - considers the protocol 234 specification documents section-by-section, 235 correcting errors, stating requirements that may be 236 ambiguous or ill-defined, and providing further 237 clarification or explanation. 239 (3) Specific Issues - discusses protocol design and 240 implementation issues that were not included in the 241 walk-through. 243 Under many of the individual topics in this memo, there 244 is parenthetical material labeled "DISCUSSION" or 245 "IMPLEMENTATION". This material is intended to give a 246 justification, clarification or explanation to the 247 preceding requirements text. The implementation 248 material contains suggested approaches that an 249 implementor may want to consider. The DISCUSSION and 250 IMPLEMENTATION sections are not part of the standard. 252 1.1.2 Requirements 254 In this memo, the words that are used to define the 255 significance of each particular requirement are 256 capitalized. These words are: 258 + "MUST" 259 This word means that the item is an absolute 260 requirement of the specification. Violation of such 261 a requirement is a fundamental error; there is no 262 case where it is justified. 264 Draft Requirements for IP Version 4 Routers March 1995 266 + "MUST IMPLEMENT" 267 This phrase means that this specification requires 268 that the item be implemented, but does not require 269 that it be enabled by default. 271 + "MUST NOT" 272 This phrase means that the item is an absolute 273 prohibition of the specification. 275 + "SHOULD" 276 This word means that there may exist valid reasons in 277 particular circumstances to ignore this item, but the 278 full implications should be understood and the case 279 carefully weighed before choosing a different course. 281 + "SHOULD IMPLEMENT" 282 This phrase is similar in meaning to SHOULD, but is 283 used when we recommend that a particular feature be 284 provided but does not necessarily recommend that it 285 be enabled by default. 287 + "SHOULD NOT" 288 This phrase means that there may exist valid reasons 289 in particular circumstances when the described 290 behavior is acceptable or even useful. Even so, the 291 full implications should be understood and the case 292 carefully weighed before implementing any behavior 293 described with this label. 295 + "MAY" 296 This word means that this item is truly optional. 297 One vendor may choose to include the item because a 298 particular marketplace requires it or because it 299 enhances the product, for example; another vendor may 300 omit the same item. 302 1.1.3 Compliance 304 Some requirements are applicable to all routers. Other 305 requirements are applicable only to those which 306 implement particular features or protocols. In the 307 following paragraphs, "relevant" refers to the union of 308 the requirements applicable to all routers and the set 310 Draft Requirements for IP Version 4 Routers March 1995 312 of requirements applicable to a particular router 313 because of the set of features and protocols it has 314 implemented. 316 Note that not all Relevant requirements are stated 317 directly in this memo. Various parts of this memo 318 incorporate by reference sections of the Host 319 Requirements specification, [INTRO:2] and [INTRO:3]. 320 For purposes of determining compliance with this memo, 321 it does not matter whether a Relevant requirement is 322 stated directly in this memo or merely incorporated by 323 reference from one of those documents. 325 An implementation is said to be "conditionally 326 compliant" if it satisfies all the Relevant MUST, MUST 327 IMPLEMENT, and MUST NOT requirements. An implementation 328 is said to be "unconditionally compliant" if it is 329 conditionally compliant and also satisfies all the 330 Relevant SHOULD, SHOULD IMPLEMENT, and SHOULD NOT 331 requirements. An implementation is not compliant if it 332 is not conditionally compliant (i.e., it fails to 333 satisfy one or more of the Relevant MUST, MUST 334 IMPLEMENT, or MUST NOT requirements). 336 This specification occasionally indicates that an 337 implementation SHOULD implement a management variable, 338 and that it SHOULD have a certain default value. An 339 unconditionally compliant implementation implements the 340 default behavior, and if there are other implemented 341 behaviors implements the variable. A conditionally 342 compliant implementation clearly documents what the 343 default setting of the variable is or, in the absence of 344 the implementation of a variable, may be construed to 345 be. An implementation that both fails to implement the 346 variable and chooses a different behavior is "not 347 compliant". 349 For any of the SHOULD and SHOULD NOT requirements, a 350 router may provide a configuration option that will 351 cause the router to act other than as specified by the 352 requirement. Having such a configuration option does 353 not void a router's claim to unconditional compliance if 354 the option has a default setting, and that setting 355 causes the router to operate in the required manner. 357 Draft Requirements for IP Version 4 Routers March 1995 359 Likewise, routers may provide, except where explicitly 360 prohibited by this memo, options which cause them to 361 violate MUST or MUST NOT requirements. A router that 362 provides such options is compliant (either fully or 363 conditionally) if and only if each such option has a 364 default setting that causes the router to conform to the 365 requirements of this memo. Please note that the authors 366 of this memo, although aware of market realities, 367 strongly recommend against provision of such options. 368 Requirements are labeled MUST or MUST NOT because 369 experts in the field have judged them to be particularly 370 important to interoperability or proper functioning in 371 the Internet. Vendors should weigh carefully the 372 customer support costs of providing options that violate 373 those rules. 375 Of course, this memo is not a complete specification of 376 an IP router, but rather is closer to what in the OSI 377 world is called a profile. For example, this memo 378 requires that a number of protocols be implemented. 379 Although most of the contents of their protocol 380 specifications are not repeated in this memo, 381 implementors are nonetheless required to implement the 382 protocols according to those specifications. 384 1.2 Relationships to Other Standards 386 There are several reference documents of interest in 387 checking the status of protocol specifications and 388 standardization: 390 + INTERNET OFFICIAL PROTOCOL STANDARDS 391 This document describes the Internet standards process 392 and lists the standards status of the protocols. As 393 of this writing, the current version of this document 394 is [ARCH:7]. This document is periodically re-issued. 395 You should always consult an RFC repository and use 396 the latest version of this document. 398 + Assigned Numbers 399 This document lists the assigned values of the 400 parameters used in the various protocols. For 401 example, it lists IP protocol codes, TCP port numbers, 403 Draft Requirements for IP Version 4 Routers March 1995 405 Telnet Option Codes, ARP hardware types, and Terminal 406 Type names. As of this writing, the current version 407 of this document is [INTRO:7]. This document is 408 periodically re-issued. You should always consult an 409 RFC repository and use the latest version of this 410 document. 412 + Host Requirements 413 This pair of documents reviews the specifications that 414 apply to hosts and supplies guidance and clarification 415 for any ambiguities. Note that these requirements 416 also apply to routers, except where otherwise 417 specified in this memo. As of this writing, the 418 current versions of these documents are [INTRO:2], and 419 [INTRO:3]. 421 + Router Requirements (formerly "Gateway Requirements") 422 This memo. 424 Note that these documents are revised and updated at 425 different times; in case of differences between these 426 documents, the most recent must prevail. 428 These and other Internet protocol documents may be 429 obtained from the: 430 DDN Network Information Center 431 14200 Park Meadow Drive, 432 Suite 200 433 Chantilly, 434 VA 22021 435 USA 437 nic@ds.internic.net 439 (800) 440 365-3642 or | 441 (703) 442 802-4535 444 1.3 General Considerations 446 There are several important lessons that vendors of 447 Internet software have learned and which a new vendor 449 Draft Requirements for IP Version 4 Routers March 1995 451 should consider seriously. 453 1.3.1 Continuing Internet Evolution 455 The enormous growth of the Internet has revealed 456 problems of management and scaling in a large datagram 457 based packet communication system. These problems are 458 being addressed, and as a result there will be 459 continuing evolution of the specifications described in 460 this memo. New routing protocols, algorithms, and 461 architectures are constantly being developed. New 462 internet layer protocols, and modifications to existing 463 protocols, are also constantly being devised. Routers 464 play a crucial role in the Internet, and the number of 465 routers deployed in the Internet is much smaller than 466 the number of hosts. Vendors should therefore expect 467 that router standards will continue to evolve much more 468 quickly than host standards. These changes will be 469 carefully planned and controlled since there is 470 extensive participation in this planning by the vendors 471 and by the organizations responsible for operation of 472 the networks. 474 Development, evolution, and revision are characteristic 475 of computer network protocols today, and this situation 476 will persist for some years. A vendor who develops 477 computer communications software for the Internet 478 protocol suite (or any other protocol suite!) and then 479 fails to maintain and update that software for changing 480 specifications is going to leave a trail of unhappy 481 customers. The Internet is a large communication 482 network, and the users are in constant contact through 483 it. Experience has shown that knowledge of deficiencies 484 in vendor software propagates quickly through the 485 Internet technical community. 487 1.3.2 Robustness Principle 489 At every layer of the protocols, there is a general rule 490 (from [TRANS:2] by Jon Postel) whose application can 491 lead to enormous benefits in robustness and 492 interoperability: 494 Draft Requirements for IP Version 4 Routers March 1995 496 "Be conservative in what you do, 497 be liberal in what you accept from others." 499 Software should be written to deal with every 500 conceivable error, no matter how unlikely. Eventually a 501 packet will come in with that particular combination of 502 errors and attributes, and unless the software is 503 prepared, chaos can ensue. It is best to assume that 504 the network is filled with malevolent entities that will 505 send packets designed to have the worst possible effect. 506 This assumption will lead to suitably protective design. 507 The most serious problems in the Internet have been 508 caused by unforeseen mechanisms triggered by low 509 probability events; mere human malice would never have 510 taken so devious a course! 512 Adaptability to change must be designed into all levels 513 of router software. As a simple example, consider a 514 protocol specification that contains an enumeration of 515 values for a particular header field - e.g., a type 516 field, a port number, or an error code; this enumeration 517 must be assumed to be incomplete. If the protocol 518 specification defines four possible error codes, the 519 software must not break when a fifth code is defined. 520 An undefined code might be logged, but it must not cause 521 a failure. 523 The second part of the principal is almost as important: 524 software on hosts or other routers may contain 525 deficiencies that make it unwise to exploit legal but 526 obscure protocol features. It is unwise to stray far 527 from the obvious and simple, lest untoward effects 528 result elsewhere. A corollary of this is "watch out for 529 misbehaving hosts"; router software should be prepared 530 to survive in the presence of misbehaving hosts. An 531 important function of routers in the Internet is to 532 limit the amount of disruption such hosts can inflict on 533 the shared communication facility. 535 1.3.3 Error Logging 537 The Internet includes a great variety of systems, each 538 implementing many protocols and protocol layers, and 540 Draft Requirements for IP Version 4 Routers March 1995 542 some of these contain bugs and misguided features in 543 their Internet protocol software. As a result of 544 complexity, diversity, and distribution of function, the 545 diagnosis of problems is often very difficult. 547 Problem diagnosis will be aided if routers include a 548 carefully designed facility for logging erroneous or 549 "strange" events. It is important to include as much 550 diagnostic information as possible when an error is 551 logged. In particular, it is often useful to record the 552 header(s) of a packet that caused an error. However, 553 care must be taken to ensure that error logging does not 554 consume prohibitive amounts of resources or otherwise 555 interfere with the operation of the router. 557 There is a tendency for abnormal but harmless protocol 558 events to overflow error logging files; this can be 559 avoided by using a "circular" log, or by enabling 560 logging only while diagnosing a known failure. It may 561 be useful to filter and count duplicate successive 562 messages. One strategy that seems to work well is to 563 both: 564 + Always count abnormalities and make such counts 565 accessible through the management protocol (see 566 Chapter 8); and 567 + Allow the logging of a great variety of events to be 568 selectively enabled. For example, it might useful to 569 be able to "log everything" or to "log everything for 570 host X". 572 This topic is further discussed in [MGT:5]. 574 1.3.4 Configuration 576 In an ideal world, routers would be easy to configure, 577 and perhaps even entirely self-configuring. However, 578 practical experience in the real world suggests that 579 this is an impossible goal, and that many attempts by 580 vendors to make configuration easy actually cause 581 customers more grief than they prevent. As an extreme 582 example, a router designed to come up and start routing 583 packets without requiring any configuration information 584 at all would almost certainly choose some incorrect 586 Draft Requirements for IP Version 4 Routers March 1995 588 parameter, possibly causing serious problems on any 589 networks unfortunate enough to be connected to it. 591 Often this memo requires that a parameter be a 592 configurable option. There are several reasons for 593 this. In a few cases there currently is some 594 uncertainty or disagreement about the best value and it 595 may be necessary to update the recommended value in the 596 future. In other cases, the value really depends on 597 external factors - e.g., the distribution of its 598 communication load, or the speeds and topology of nearby 599 networks - and self-tuning algorithms are unavailable 600 and may be insufficient. In some cases, configurability 601 is needed because of administrative requirements. 603 Finally, some configuration options are required to 604 communicate with obsolete or incorrect implementations 605 of the protocols, distributed without sources, that 606 persist in many parts of the Internet. To make correct 607 systems coexist with these faulty systems, 608 administrators must occasionally misconfigure the 609 correct systems. This problem will correct itself 610 gradually as the faulty systems are retired, but cannot 611 be ignored by vendors. 613 When we say that a parameter must be configurable, we do 614 not intend to require that its value be explicitly read 615 from a configuration file at every boot time. For many 616 parameters, there is one value that is appropriate for 617 all but the most unusual situations. In such cases, it 618 is quite reasonable that the parameter default to that 619 value if not explicitly set. 621 This memo requires a particular value for such defaults 622 in some cases. The choice of default is a sensitive 623 issue when the configuration item controls accommodation 624 of existing, faulty, systems. If the Internet is to 625 converge successfully to complete interoperability, the 626 default values built into implementations must implement 627 the official protocol, not misconfigurations to 628 accommodate faulty implementations. Although marketing 629 considerations have led some vendors to choose 630 misconfiguration defaults, we urge vendors to choose 631 defaults that will conform to the standard. 633 Draft Requirements for IP Version 4 Routers March 1995 635 Finally, we note that a vendor needs to provide adequate 636 documentation on all configuration parameters, their 637 limits and effects. 639 1.4 Algorithms 641 In several places in this memo, specific algorithms that a 642 router ought to follow are specified. These algorithms are 643 not, per se, required of the router. A router need not 644 implement each algorithm as it is written in this document. 645 Rather, an implementation must present a behavior to the 646 external world that is the same as a strict, literal, 647 implementation of the specified algorithm. 649 Algorithms are described in a manner that differs from the 650 way a good implementor would implement them. For 651 expository purposes, a style that emphasizes conciseness, 652 clarity, and independence from implementation details has 653 been chosen. A good implementor will choose algorithms and 654 implementation methods that produce the same results as 655 these algorithms, but may be more efficient or less 656 general. 658 We note that the art of efficient router implementation is 659 outside the scope of this memo. 661 Draft Requirements for IP Version 4 Routers March 1995 663 2. INTERNET ARCHITECTURE 665 This chapter does not contain any requirements. However, it 666 does contain useful background information on the general 667 architecture of the Internet and of routers. 669 General background and discussion on the Internet architecture 670 and supporting protocol suite can be found in the DDN Protocol 671 Handbook [ARCH:1]; for background see for example [ARCH:2], 672 [ARCH:3], and [ARCH:4]. The Internet architecture and 673 protocols are also covered in an ever-growing number of 674 textbooks, such as [ARCH:5] and [ARCH:6]. 676 2.1 Introduction 678 The Internet system consists of a number of interconnected 679 packet networks supporting communication among host 680 computers using the Internet protocols. These protocols 681 include the Internet Protocol (IP), the Internet Control 682 Message Protocol (ICMP), the Internet Group Management 683 Protocol (IGMP), and a variety transport and application 684 protocols that depend upon them. As was described in 685 Section [1.2], the Internet Engineering Steering Group 686 periodically releases an "Official Protocols" memo listing 687 all the Internet protocols. 689 All Internet protocols use IP as the basic data transport 690 mechanism. IP is a datagram, or connectionless, 691 internetwork service and includes provision for addressing, 692 type-of-service specification, fragmentation and 693 reassembly, and security. ICMP and IGMP are considered 694 integral parts of IP, although they are architecturally 695 layered upon IP. ICMP provides error reporting, flow 696 control, first-hop router redirection, and other 697 maintenance and control functions. IGMP provides the 698 mechanisms by which hosts and routers can join and leave IP 699 multicast groups. 701 Reliable data delivery is provided in the Internet protocol 702 suite by Transport Layer protocols such as the Transmission 703 Control Protocol (TCP), which provides end-end 704 retransmission, resequencing and connection control. 705 Transport Layer connectionless service is provided by the 707 Draft Requirements for IP Version 4 Routers March 1995 709 User Datagram Protocol (UDP). 711 2.2 Elements of the Architecture 713 2.2.1 Protocol Layering 715 To communicate using the Internet system, a host must 716 implement the layered set of protocols comprising the 717 Internet protocol suite. A host typically must 718 implement at least one protocol from each layer. 720 The protocol layers used in the Internet architecture 721 are as follows [ARCH:7]: 723 + Application Layer 724 The Application Layer is the top layer of the 725 Internet protocol suite. The Internet suite does not 726 further subdivide the Application Layer, although 727 some application layer protocols do contain some 728 internal sub-layering. The application layer of the 729 Internet suite essentially combines the functions of 730 the top two layers - Presentation and Application - 731 of the OSI Reference Model [ARCH:8]. The Application 732 Layer in the Internet protocol suite also includes 733 some of the function relegated to the Session Layer 734 in the OSI Reference Model. 736 We distinguish two categories of application layer 737 protocols: user protocols that provide service 738 directly to users, and support protocols that provide 739 common system functions. The most common Internet 740 user protocols are: 741 - Telnet (remote login) 742 - FTP (file transfer) 743 - SMTP (electronic mail delivery) 745 There are a number of other standardized user 746 protocols and many private user protocols. 748 Support protocols, used for host name mapping, 749 booting, and management include SNMP, BOOTP, TFTP, 751 Draft Requirements for IP Version 4 Routers March 1995 753 the Domain Name System (DNS) protocol, and a variety 754 of routing protocols. 756 Application Layer protocols relevant to routers are 757 discussed in chapters 7, 8, and 9 of this memo. 759 + Transport Layer 760 The Transport Layer provides end-to-end communication 761 services. This layer is roughly equivalent to the 762 "Transport Layer" in the OSI Reference Model, except 763 that it also incorporates some of OSI's Session Layer 764 establishment and destruction functions. 766 There are two primary Transport Layer protocols at 767 present: 768 - Transmission Control Protocol (TCP) 769 - User Datagram Protocol (UDP) 771 TCP is a reliable connection-oriented transport 772 service that provides end-to-end reliability, 773 resequencing, and flow control. UDP is a 774 connectionless ("datagram") transport service. Other 775 transport protocols have been developed by the 776 research community, and the set of official Internet 777 transport protocols may be expanded in the future. 779 Transport Layer protocols relevant to routers are 780 discussed in Chapter 6. 782 + Internet Layer 783 All Internet transport protocols use the Internet 784 Protocol (IP) to carry data from source host to 785 destination host. IP is a connectionless or datagram 786 internetwork service, providing no end-to-end 787 delivery guarantees. IP datagrams may arrive at the 788 destination host damaged, duplicated, out of order, 789 or not at all. The layers above IP are responsible 790 for reliable delivery service when it is required. 791 The IP protocol includes provision for addressing, 792 type-of-service specification, fragmentation and 793 reassembly, and security. 795 The datagram or connectionless nature of IP is a 796 fundamental and characteristic feature of the 798 Draft Requirements for IP Version 4 Routers March 1995 800 Internet architecture. 802 The Internet Control Message Protocol (ICMP) is a 803 control protocol that is considered to be an integral 804 part of IP, although it is architecturally layered 805 upon IP - it uses IP to carry its data end-to-end. 806 ICMP provides error reporting, congestion reporting, 807 and first-hop router redirection. 809 The Internet Group Management Protocol (IGMP) is an 810 Internet layer protocol used for establishing dynamic 811 host groups for IP multicasting. 813 The Internet layer protocols IP, ICMP, and IGMP are 814 discussed in chapter 4. 816 + Link Layer 817 To communicate on a directly connected network, a 818 host must implement the communication protocol used 819 to interface to that network. We call this a Link 820 Layer protocol. 822 Some older Internet documents refer to this layer as 823 the "Network Layer", but it is not the same as the 824 "Network Layer" in the OSI Reference Model. 826 This layer contains everything "below" the Internet 827 Layer and "above" the Physical Layer (which is the 828 media connectivity, normally electrical or optical, 829 which encodes and transports messages). Its 830 responsibility is the correct delivery of messages, 831 among which it does not differentiate. 833 Protocols in this Layer are generally outside the 834 scope of Internet standardization; the Internet 835 (intentionally) uses existing standards whenever 836 possible. Thus, Internet Link Layer standards 837 usually address only address resolution and rules for 838 transmitting IP packets over specific Link Layer 839 protocols. Internet Link Layer standards are 840 discussed in chapter 3. 842 Draft Requirements for IP Version 4 Routers March 1995 844 2.2.2 Networks 846 The constituent networks of the Internet system are 847 required to provide only packet (connectionless) 848 transport. According to the IP service specification, 849 datagrams can be delivered out of order, be lost or 850 duplicated, and/or contain errors. 852 For reasonable performance of the protocols that use IP 853 (e.g., TCP), the loss rate of the network should be very 854 low. In networks providing connection-oriented service, 855 the extra reliability provided by virtual circuits 856 enhances the end-end robustness of the system, but is 857 not necessary for Internet operation. 859 Constituent networks may generally be divided into two 860 classes: 862 + Local-Area Networks (LANs) 863 LANs may have a variety of designs. LANs normally 864 cover a small geographical area (e.g., a single 865 building or plant site) and provide high bandwidth 866 with low delays. LANs may be passive (similar to 867 Ethernet) or they may be active (such as ATM). 869 + Wide-Area Networks (WANs) 870 Geographically dispersed hosts and LANs are 871 interconnected by wide-area networks, also called 872 long-haul networks. These networks may have a 873 complex internal structure of lines and packet- 874 switches, or they may be as simple as point-to- 875 point lines. 877 2.2.3 Routers 879 In the Internet model, constituent networks are 880 connected together by IP datagram forwarders which are 881 called "routers" or "IP routers". In this document, 882 every use of the term "router" is equivalent to "IP 883 router". Many older Internet documents refer to routers 884 as "gateways". 886 Historically, routers have been realized with packet- 888 Draft Requirements for IP Version 4 Routers March 1995 890 switching software executing on a general-purpose CPU. 891 However, as custom hardware development becomes cheaper 892 and as higher throughput is required, special purpose 893 hardware is becoming increasingly common. This 894 specification applies to routers regardless of how they 895 are implemented. 897 A router connects to two or more logical interfaces, 898 represented by IP subnets or unnumbered point to point 899 lines (discussed in section [2.2.7]). Thus, it has at 900 least one physical interface. Forwarding an IP datagram 901 generally requires the router to choose the address and 902 relevant interface of the next-hop router or (for the 903 final hop) the destination host. This choice, called 904 "relaying" or "forwarding depends upon a route database 905 within the router. The route database is also called a 906 routing table or forwarding table. The term "router" 907 derives from the process of building this route 908 database; routing protocols and configuration interact 909 in a process called "routing". 911 The routing database should be maintained dynamically to 912 reflect the current topology of the Internet system. A 913 router normally accomplishes this by participating in 914 distributed routing and reachability algorithms with 915 other routers. 917 Routers provide datagram transport only, and they seek 918 to minimize the state information necessary to sustain 919 this service in the interest of routing flexibility and 920 robustness. 922 Packet switching devices may also operate at the Link 923 Layer; such devices are usually called "bridges". 924 Network segments that are connected by bridges share the 925 same IP network prefix forming a single IP subnet. 926 These other devices are outside the scope of this 927 document. 929 2.2.4 Autonomous Systems 931 An Autonomous System (AS) is a connected segment of a | 932 network topology that consists of a collection of | 934 Draft Requirements for IP Version 4 Routers March 1995 936 subnetworks (with hosts attached) interconnected by a | 937 set of routes. The subnetworks and the routers are | 938 expected to be under the control of a single operations | 939 and maintenance (O&M) organization. Within an AS | 940 routers may use one or more interior routing protocols, | 941 and sometimes several sets of metrics. An AS is | 942 expected to present to other ASs an appearence of a | 943 coherent interior routing plan, and a consistent picture | 944 of the destinations reachable through the AS. An AS is | 945 identified by an Autonomous System number. 947 The concept of an AS plays an important role in the | 948 Internet routing (see Section 7.1). 950 2.2.5 Addressing Architecture 952 An IP datagram carries 32-bit source and destination 953 addresses, each of which is partitioned into two parts - 954 a constituent network prefix and a host number on that 955 network. Symbolically: 957 IP-address ::= { , } 959 To finally deliver the datagram, the last router in its 960 path must map the Host-number (or "rest") part of an IP 961 address to the host's Link Layer address. 963 2.2.5.1 Classical IP Addressing Architecture 965 Although well documented elsewhere [INTERNET:2], it 966 is useful to describe the historical use of the 967 network prefix. The language developed to describe 968 it is used in this and other documents and permeates 969 the thinking behind many protocols. 971 The simplest classical network prefix is the Class A, 972 B, C, D, or E network prefix. These address ranges 973 are discriminated by observing the values of the most 974 significant bits of the address, and break the 975 address into simple prefix and host number fields. 976 This is described in [INTERNET:18]. In short, the 978 Draft Requirements for IP Version 4 Routers March 1995 980 classification is: 982 0xxx - Class A - general purpose unicast 983 addresses with standard 8 bit prefix 984 10xx - Class B - general purpose unicast 985 addresses with standard 16 bit prefix 986 110x - Class C - general purpose unicast 987 addresses with standard 24 bit prefix 988 1110 - Class D - IP Multicast Addresses - 28 bit 989 prefix, non-aggregatable 990 1111 - Class E - reserved for experimental use 992 This simple notion has been extended by the concept 993 of "subnets". These were introduced to allow 994 arbitrary complexity of interconnected LAN structures 995 within an organization, while insulating the Internet 996 system against explosive growth in assigned network 997 prefixes and routing complexity. Subnets provide a 998 multi-level hierarchical routing structure for the 999 Internet system. The subnet extension, described in 1000 [INTERNET:2], is a required part of the Internet 1001 architecture. The basic idea is to partition the 1002 field into two parts: a subnet number, 1003 and a true host number on that subnet: 1005 IP-address ::= 1006 { , , } 1009 The interconnected physical networks within an 1010 organization use the same network prefix but 1011 different subnet numbers. The distinction between 1012 the subnets of such a subnetted network is not 1013 normally visible outside of that network. Thus, 1014 routing in the rest of the Internet uses only the 1015 part of the IP destination address. 1016 Routers outside the network treat 1017 and together as an uninterpreted "rest" 1018 part of the 32-bit IP address. Within the subnetted 1019 network, the routers use the extended network prefix: 1021 { , } 1023 The bit positions containing this extended network 1025 Draft Requirements for IP Version 4 Routers March 1995 1027 number have historically been indicated by a 32-bit 1028 mask called the "subnet mask". The 1029 bits SHOULD be contiguous and fall between the 1030 and the fields. More 1031 up to date protocols do not refer to a subnet mask, 1032 but to a "prefix length"; the "prefix" portion of an 1033 address is that which would be selected by a subnet 1034 mask whose most significant bits are all ones and the 1035 rest are zeroes. The length of the prefix equals the 1036 number of ones in the subnet mask. This document 1037 assumes that all subnet masks are expressible as 1038 prefix lengths. 1040 The inventors of the subnet mechanism presumed that 1041 each piece of an organization's network would have 1042 only a single subnet number. In practice, it has 1043 often proven necessary or useful to have several 1044 subnets share a single physical cable. For this 1045 reason, routers should be capable of configuring 1046 multiple subnets on the same physical interfaces, and 1047 treat them (from a routing or forwarding perspective) 1048 as though they were distinct physical interfaces. 1050 2.2.5.2 Classless Inter Domain Routing (CIDR) 1052 The explosive growth of the Internet has forced a 1053 review of address assignment policies. The 1054 traditional uses of general purpose (Class A, B, and 1055 C) networks have been modified to achieve better use 1056 of IP's 32-bit address space. Classless Inter Domain 1057 Routing (CIDR) [INTERNET:15] is a method currently 1058 being deployed in the Internet backbones to achieve 1059 this added efficiency. CIDR depends on deploying and 1060 routing to arbitrarily sized networks. In this 1061 model, hosts and routers make no assumptions about 1062 the use of addressing in the internet. The Class D 1063 (IP Multicast) and Class E (Experimental) address 1064 spaces are preserved, although this is primarily an 1065 assignment policy. 1067 By definition, CIDR comprises three elements: 1068 + topologically significant address assignment, 1070 Draft Requirements for IP Version 4 Routers March 1995 1072 + routing protocols that are capable of aggregating 1073 network layer reachability information, and 1074 + consistent forwarding algorithm ("longest 1075 match"). 1077 The use of networks and subnets is now historical, 1078 although the language used to describe them remains 1079 in current use. They have been replaced by the more 1080 tractable concept of a "network prefix". A network 1081 prefix is, by definition, a contiguous set of bits at 1082 the more significant end of the address that defines 1083 a set of systems; host numbers select among those 1084 systems. There is no requirement that all the 1085 internet use network prefixes uniformly. To collapse 1086 routing information, it is useful to divide the 1087 internet into addressing domains. Within such a 1088 domain, detailed information is available about 1089 constituent networks; outside it, only the common 1090 network prefix is advertised. 1092 The classical IP addressing architecture used 1093 addresses and subnet masks to discriminate the host 1094 number from the network prefix. With network 1095 prefixes, it is sufficient to indicate the number of 1096 bits in the prefix. Both representations are in 1097 common use. Architecturally correct subnet masks are 1098 capable of being represented using the prefix length 1099 description. They comprise that subset of all 1100 possible bits patterns that have 1101 + a contiguous string of ones at the more 1102 significant end, 1103 + a contiguous string of zeros at the less 1104 significant end, and 1105 + no intervening bits. 1107 Routers SHOULD always treat a route as a network 1108 prefix, and SHOULD reject configuration and routing 1109 information inconsistent with that model. 1111 IP-address ::= { , } | 1113 An effect of the use of CIDR is that the set of 1114 destinations associated with address prefixes in the 1115 routing table may exhibit subset relationship. A 1117 Draft Requirements for IP Version 4 Routers March 1995 1119 route describing a smaller set of destinations (a 1120 longer prefix) is said to be more specific than a 1121 route describing a larger set of destinations (a 1122 shorter prefix); similarly, a route describing a 1123 larger set of destinations (a shorter prefix) is said 1124 to be less specific than a route describing a smaller 1125 set of destinations (a longer prefix). Routers must 1126 use the most specific matching route (the longest 1127 matching network prefix) when forwarding traffic. 1129 2.2.6 IP Multicasting 1131 IP multicasting is an extension of Link Layer multicast 1132 to IP internets. Using IP multicasts, a single datagram 1133 can be addressed to multiple hosts without sending it to 1134 all. In the extended case, these hosts may reside in 1135 different address domains. This collection of hosts is 1136 called a multicast group. Each multicast group is 1137 represented as a Class D IP address. An IP datagram 1138 sent to the group is to be delivered to each group 1139 member with the same best-effort delivery as that 1140 provided for unicast IP traffic. The sender of the 1141 datagram does not itself need to be a member of the 1142 destination group. 1144 The semantics of IP multicast group membership are 1145 defined in [INTERNET:4]. That document describes how 1146 hosts and routers join and leave multicast groups. It 1147 also defines a protocol, the Internet Group Management 1148 Protocol (IGMP), that monitors IP multicast group 1149 membership. 1151 Forwarding of IP multicast datagrams is accomplished 1152 either through static routing information or via a 1153 multicast routing protocol. Devices that forward IP 1154 multicast datagrams are called multicast routers. They 1155 may or may not also forward IP unicasts. Multicast 1156 datagrams are forwarded on the basis of both their 1157 source and destination addresses. Forwarding of IP 1158 multicast packets is described in more detail in Section 1159 [5.2.1]. Appendix D discusses multicast routing 1160 protocols. 1162 Draft Requirements for IP Version 4 Routers March 1995 1164 2.2.7 Unnumbered Lines and Networks Prefixes 1166 Traditionally, each network interface on an IP host or 1167 router has its own IP address. This can cause 1168 inefficient use of the scarce IP address space, since it 1169 forces allocation of an IP network prefix to every 1170 point-to-point link. 1172 To solve this problem, a number of people have proposed 1173 and implemented the concept of "unnumbered point to 1174 point lines". An unnumbered point to point line does 1175 not have any network prefix associated with it. As a 1176 consequence, the network interfaces connected to an 1177 unnumbered point to point line do not have IP addresses. 1179 Because the IP architecture has traditionally assumed 1180 that all interfaces had IP addresses, these unnumbered 1181 interfaces cause some interesting dilemmas. For 1182 example, some IP options (e.g., Record Route) specify 1183 that a router must insert the interface address into the 1184 option, but an unnumbered interface has no IP address. 1185 Even more fundamental (as we shall see in chapter 5) is 1186 that routes contain the IP address of the next hop 1187 router. A router expects that this IP address will be 1188 on an IP (sub)net to which the router is connected. 1189 That assumption is of course violated if the only 1190 connection is an unnumbered point to point line. 1192 To get around these difficulties, two schemes have been 1193 conceived. The first scheme says that two routers 1194 connected by an unnumbered point to point line are not 1195 really two routers at all, but rather two "half-routers" 1196 that together make up a single virtual router. The 1197 unnumbered point to point line is essentially considered 1198 to be an internal bus in the virtual router. The two 1199 halves of the virtual router must coordinate their 1200 activities in such a way that they act exactly like a 1201 single router. 1203 This scheme fits in well with the IP architecture, but 1204 suffers from two important drawbacks. The first is 1205 that, although it handles the common case of a single 1206 unnumbered point to point line, it is not readily 1207 extensible to handle the case of a mesh of routers and 1209 Draft Requirements for IP Version 4 Routers March 1995 1211 unnumbered point to point lines. The second drawback is 1212 that the interactions between the half routers are 1213 necessarily complex and are not standardized, 1214 effectively precluding the connection of equipment from 1215 different vendors using unnumbered point to point lines. 1217 Because of these drawbacks, this memo has adopted an 1218 alternate scheme, which has been invented multiple times 1219 but which is probably originally attributable to Phil 1220 Karn. In this scheme, a router that has unnumbered 1221 point to point lines also has a special IP address, 1222 called a "router-id" in this memo. The router-id is one 1223 of the router's IP addresses (a router is required to 1224 have at least one IP address). This router-id is used 1225 as if it is the IP address of all unnumbered interfaces. 1227 2.2.8 Notable Oddities 1229 2.2.8.1 Embedded Routers 1231 A router may be a stand-alone computer system, 1232 dedicated to its IP router functions. Alternatively, 1233 it is possible to embed router functions within a 1234 host operating system that supports connections to 1235 two or more networks. The best-known example of an 1236 operating system with embedded router code is the 1237 Berkeley BSD system. The embedded router feature 1238 seems to make building a network easy, but it has a 1239 number of hidden pitfalls: 1241 (1) If a host has only a single constituent-network 1242 interface, it should not act as a router. 1244 For example, hosts with embedded router code 1245 that gratuitously forward broadcast packets or 1246 datagrams on the same net often cause packet 1247 avalanches. 1249 (2) If a (multihomed) host acts as a router, it is 1250 subject to the requirements for routers 1251 contained in this document. 1253 Draft Requirements for IP Version 4 Routers March 1995 1255 For example, the routing protocol issues and the 1256 router control and monitoring problems are as 1257 hard and important for embedded routers as for 1258 stand-alone routers. 1260 Internet router requirements and specifications 1261 may change independently of operating system 1262 changes. An administration that operates an 1263 embedded router in the Internet is strongly 1264 advised to maintain and update the router code. 1265 This might require router source code. 1267 (3) When a host executes embedded router code, it 1268 becomes part of the Internet infrastructure. 1269 Thus, errors in software or configuration can 1270 hinder communication between other hosts. As a 1271 consequence, the host administrator must lose 1272 some autonomy. 1274 In many circumstances, a host administrator will 1275 need to disable router code embedded in the 1276 operating system. For this reason, it should be 1277 straightforward to disable embedded router 1278 functionality. 1280 (4) When a host running embedded router code is 1281 concurrently used for other services, the 1282 Operation and Maintenance requirements for the 1283 two modes of use may conflict. 1285 For example, router O&M will in many cases be 1286 performed remotely by an operations center; this 1287 may require privileged system access that the 1288 host administrator would not normally want to 1289 distribute. 1291 2.2.8.2 Transparent Routers 1293 There are two basic models for interconnecting 1294 local-area networks and wide-area (or long-haul) 1295 networks in the Internet. In the first, the local- 1296 area network is assigned a network prefix and all 1297 routers in the Internet must know how to route to 1299 Draft Requirements for IP Version 4 Routers March 1995 1301 that network. In the second, the local-area network 1302 shares (a small part of) the address space of the 1303 wide-area network. Routers that support this second 1304 model are called "address sharing routers" or 1305 "transparent routers". The focus of this memo is on 1306 routers that support the first model, but this is not 1307 intended to exclude the use of transparent routers. 1309 The basic idea of a transparent router is that the 1310 hosts on the local-area network behind such a router 1311 share the address space of the wide-area network in 1312 front of the router. In certain situations this is a 1313 very useful approach and the limitations do not 1314 present significant drawbacks. 1316 The words "in front" and "behind" indicate one of the 1317 limitations of this approach: this model of 1318 interconnection is suitable only for a geographically 1319 (and topologically) limited stub environment. It 1320 requires that there be some form of logical 1321 addressing in the network level addressing of the 1322 wide-area network. IP addresses in the local 1323 environment map to a few (usually one) physical 1324 address in the wide-area network. This mapping 1325 occurs in a way consistent with the { IP address <-> 1326 network address } mapping used throughout the wide- 1327 area network. 1329 Multihoming is possible on one wide-area network, but 1330 may present routing problems if the interfaces are 1331 geographically or topologically separated. 1332 Multihoming on two (or more) wide-area networks is a 1333 problem due to the confusion of addresses. 1335 The behavior that hosts see from other hosts in what 1336 is apparently the same network may differ if the 1337 transparent router cannot fully emulate the normal 1338 wide-area network service. For example, the ARPANET 1339 used a Link Layer protocol that provided a 1340 "Destination Dead" indication in response to an 1341 attempt to send to a host that was off-line. 1342 However, if there were a transparent router between 1343 the ARPANET and an Ethernet, a host on the ARPANET 1344 would not receive a Destination Dead indication for 1346 Draft Requirements for IP Version 4 Routers March 1995 1348 Ethernet hosts. 1350 2.3 Router Characteristics 1352 An Internet router performs the following functions: 1354 (1) Conforms to specific Internet protocols specified in 1355 this document, including the Internet Protocol (IP), 1356 Internet Control Message Protocol (ICMP), and others 1357 as necessary. 1359 (2) Interfaces to two or more packet networks. For each 1360 connected network the router must implement the 1361 functions required by that network. These functions 1362 typically include: 1364 + Encapsulating and decapsulating the IP datagrams 1365 with the connected network framing (e.g., an 1366 Ethernet header and checksum), 1368 + Sending and receiving IP datagrams up to the maximum 1369 size supported by that network, this size is the 1370 network's "Maximum Transmission Unit" or "MTU", 1372 + Translating the IP destination address into an 1373 appropriate network-level address for the connected 1374 network (e.g., an Ethernet hardware address), if 1375 needed, and 1377 + Responding to network flow control and error 1378 indications, if any. 1380 See chapter 3 (Link Layer). 1382 (3) Receives and forwards Internet datagrams. Important 1383 issues in this process are buffer management, 1384 congestion control, and fairness. 1386 + Recognizes error conditions and generates ICMP error 1387 and information messages as required. 1389 + Drops datagrams whose time-to-live fields have 1390 reached zero. 1392 Draft Requirements for IP Version 4 Routers March 1995 1394 + Fragments datagrams when necessary to fit into the 1395 MTU of the next network. 1397 See chapter 4 (Internet Layer - Protocols) and chapter 1398 5 (Internet Layer - Forwarding) for more information. 1399 (4) Chooses a next-hop destination for each IP datagram, 1400 based on the information in its routing database. See 1401 chapter 5 (Internet Layer - Forwarding) for more 1402 information. 1404 (5) (Usually) supports an interior gateway protocol (IGP) 1405 to carry out distributed routing and reachability 1406 algorithms with the other routers in the same 1407 autonomous system. In addition, some routers will 1408 need to support an exterior gateway protocol (EGP) to 1409 exchange topological information with other autonomous 1410 systems. See chapter 7 (Application Layer - Routing 1411 Protocols) for more information. 1413 (6) Provides network management and system support 1414 facilities, including loading, debugging, status 1415 reporting, exception reporting and control. See 1416 chapter 8 (Application Layer - Network Management 1417 Protocols) and chapter 10 (Operation and Maintenance) 1418 for more information. 1420 A router vendor will have many choices on power, 1421 complexity, and features for a particular router product. 1422 It may be helpful to observe that the Internet system is 1423 neither homogeneous nor fully connected. For reasons of 1424 technology and geography it is growing into a global 1425 interconnect system plus a "fringe" of LANs around the 1426 "edge". More and more these fringe LANs are becoming 1427 richly interconnected, thus making them less out on the 1428 fringe and more demanding on router requirements. 1430 + The global interconnect system is composed of a number of 1431 wide-area networks to which are attached routers of 1432 several Autonomous Systems (AS); there are relatively 1433 few hosts connected directly to the system. 1435 + Most hosts are connected to LANs. Many organizations 1436 have clusters of LANs interconnected by local routers. 1437 Each such cluster is connected by routers at one or more 1439 Draft Requirements for IP Version 4 Routers March 1995 1441 points into the global interconnect system. If it is 1442 connected at only one point, a LAN is known as a "stub" 1443 network. 1445 Routers in the global interconnect system generally 1446 require: 1448 + Advanced Routing and Forwarding Algorithms 1450 These routers need routing algorithms that are highly 1451 dynamic, impose minimal processing and communication 1452 burdens, and offer type-of-service routing. Congestion 1453 is still not a completely resolved issue (see Section 1454 [5.3.6]). Improvements in these areas are expected, as 1455 the research community is actively working on these 1456 issues. 1458 + High Availability 1460 These routers need to be highly reliable, providing 24 1461 hours a day, 7 days a week service. Equipment and 1462 software faults can have a wide-spread (sometimes 1463 global) effect. In case of failure, they must recover 1464 quickly. In any environment, a router must be highly 1465 robust and able to operate, possibly in a degraded 1466 state, under conditions of extreme congestion or failure 1467 of network resources. 1469 + Advanced O&M Features 1471 Internet routers normally operate in an unattended mode. 1472 They will typically be operated remotely from a 1473 centralized monitoring center. They need to provide 1474 sophisticated means for monitoring and measuring traffic 1475 and other events and for diagnosing faults. 1477 + High Performance 1479 Long-haul lines in the Internet today are most 1480 frequently full duplex 56 KBPS, DS1 (1.544 Mbps), or DS3 1481 (45 Mbps) speeds. LANs, which are half duplex 1482 multiaccess media, are typically Ethernet (10Mbps) and, 1483 to a lesser degree, FDDI (100Mbps). However, network 1484 media technology is constantly advancing and higher 1486 Draft Requirements for IP Version 4 Routers March 1995 1488 speeds are likely in the future. 1490 The requirements for routers used in the LAN fringe (e.g., 1491 campus networks) depend greatly on the demands of the local 1492 networks. These may be high or medium-performance devices, 1493 probably competitively procured from several different 1494 vendors and operated by an internal organization (e.g., a 1495 campus computing center). The design of these routers 1496 should emphasize low average latency and good burst 1497 performance, together with delay and type-of-service 1498 sensitive resource management. In this environment there 1499 may be less formal O&M but it will not be less important. 1500 The need for the routing mechanism to be highly dynamic 1501 will become more important as networks become more complex 1502 and interconnected. Users will demand more out of their 1503 local connections because of the speed of the global 1504 interconnects. 1506 As networks have grown, and as more networks have become 1507 old enough that they are phasing out older equipment, it 1508 has become increasingly imperative that routers 1509 interoperate with routers from other vendors. 1511 Even though the Internet system is not fully 1512 interconnected, many parts of the system need to have 1513 redundant connectivity. Rich connectivity allows reliable 1514 service despite failures of communication lines and 1515 routers, and it can also improve service by shortening 1516 Internet paths and by providing additional capacity. 1517 Unfortunately, this richer topology can make it much more 1518 difficult to choose the best path to a particular 1519 destination. 1521 2.4 Architectural Assumptions 1523 The current Internet architecture is based on a set of 1524 assumptions about the communication system. The 1525 assumptions most relevant to routers are as follows: 1527 + The Internet is a network of networks. 1529 Each host is directly connected to some particular 1530 network(s); its connection to the Internet is only 1532 Draft Requirements for IP Version 4 Routers March 1995 1534 conceptual. Two hosts on the same network communicate 1535 with each other using the same set of protocols that 1536 they would use to communicate with hosts on distant 1537 networks. 1539 + Routers do not keep connection state information. 1541 To improve the robustness of the communication system, 1542 routers are designed to be stateless, forwarding each IP 1543 packet independently of other packets. As a result, 1544 redundant paths can be exploited to provide robust 1545 service in spite of failures of intervening routers and 1546 networks. 1548 All state information required for end-to-end flow 1549 control and reliability is implemented in the hosts, in 1550 the transport layer or in application programs. All 1551 connection control information is thus co-located with 1552 the end points of the communication, so it will be lost 1553 only if an end point fails. Routers control message 1554 flow only indirectly, by dropping packets or increasing 1555 network delay. 1557 Note that future protocol developments may well end up 1558 putting some more state into routers. This is 1559 especially likely for multicast routing, resource 1560 reservation, and flow based forwarding. 1562 + Routing complexity should be in the routers. 1564 Routing is a complex and difficult problem, and ought to 1565 be performed by the routers, not the hosts. An 1566 important objective is to insulate host software from 1567 changes caused by the inevitable evolution of the 1568 Internet routing architecture. 1570 + The system must tolerate wide network variation. 1572 A basic objective of the Internet design is to tolerate 1573 a wide range of network characteristics - e.g., 1574 bandwidth, delay, packet loss, packet reordering, and 1575 maximum packet size. Another objective is robustness 1576 against failure of individual networks, routers, and 1577 hosts, using whatever bandwidth is still available. 1579 Draft Requirements for IP Version 4 Routers March 1995 1581 Finally, the goal is full "open system interconnection": 1582 an Internet router must be able to interoperate robustly 1583 and effectively with any other router or Internet host, 1584 across diverse Internet paths. 1586 Sometimes implementors have designed for less ambitious 1587 goals. For example, the LAN environment is typically 1588 much more benign than the Internet as a whole; LANs have 1589 low packet loss and delay and do not reorder packets. 1590 Some vendors have fielded implementations that are 1591 adequate for a simple LAN environment, but work badly 1592 for general interoperation. The vendor justifies such a 1593 product as being economical within the restricted LAN 1594 market. However, isolated LANs seldom stay isolated for 1595 long. They are soon connected to each other, to 1596 organization-wide internets, and eventually to the 1597 global Internet system. In the end, neither the 1598 customer nor the vendor is served by incomplete or 1599 substandard routers. 1601 The requirements in this document are designed for a 1602 full-function router. It is intended that fully 1603 compliant routers will be usable in almost any part of 1604 the Internet. 1606 Draft Requirements for IP Version 4 Routers March 1995 1608 3. LINK LAYER 1610 Although [INTRO:1] covers Link Layer standards (IP over 1611 various link layers, ARP, etc.), this document anticipates 1612 that Link-Layer material will be covered in a separate Link 1613 Layer Requirements document. A Link-Layer Requirements 1614 document would be applicable to both hosts and routers. Thus, 1615 this document will not obsolete the parts of [INTRO:1] that 1616 deal with link-layer issues. 1618 3.1 INTRODUCTION 1620 Routers have essentially the same Link Layer protocol 1621 requirements as other sorts of Internet systems. These 1622 requirements are given in chapter 3 of "Requirements for 1623 Internet Gateways" [INTRO:1]. A router MUST comply with 1624 its requirements and SHOULD comply with its 1625 recommendations. Since some of the material in that 1626 document has become somewhat dated, some additional 1627 requirements and explanations are included below. 1629 DISCUSSION: 1630 It is expected that the Internet community will produce 1631 a "Requirements for Internet Link Layer" standard which 1632 will supersede both this chapter and the chapter 1633 entitled "INTERNET LAYER PROTOCOLS" in [INTRO:1]. 1635 3.2 LINK/INTERNET LAYER INTERFACE 1637 This document does not attempt to specify the interface 1638 between the Link Layer and the upper layers. However, note 1639 well that other parts of this document, particularly 1640 chapter 5, require various sorts of information to be 1641 passed across this layer boundary. 1643 This section uses the following definitions: 1645 + Source physical address 1647 The source physical address is the Link Layer address of 1648 the host or router from which the packet was received. 1650 Draft Requirements for IP Version 4 Routers March 1995 1652 + Destination physical address 1654 The destination physical address is the Link Layer 1655 address to which the packet was sent. 1657 The information that must pass from the Link Layer to the 1658 Internetwork Layer for each received packet is: 1660 (1) The IP packet [5.2.2], 1662 (2) The length of the data portion (i.e., not including the 1663 Link-Layer framing) of the Link Layer frame [5.2.2], 1665 (3) The identity of the physical interface from which the 1666 IP packet was received [5.2.3], and 1668 (4) The classification of the packet's destination physical 1669 address as a Link Layer unicast, broadcast, or 1670 multicast [4.3.2], [5.3.4]. 1672 In addition, the Link Layer also should provide: 1674 (5) The source physical address. 1676 The information that must pass from the Internetwork Layer 1677 to the Link Layer for each transmitted packet is: 1679 (1) The IP packet [5.2.1] 1681 (2) The length of the IP packet [5.2.1] 1683 (3) The destination physical interface [5.2.1] 1685 (4) The next hop IP address [5.2.1] 1687 In addition, the Internetwork Layer also should provide: 1689 (5) The Link Layer priority value [5.3.3.2] 1691 The Link Layer must also notify the Internetwork Layer if 1692 the packet to be transmitted causes a Link Layer 1693 precedence-related error [5.3.3.3]. 1695 Draft Requirements for IP Version 4 Routers March 1995 1697 3.3 SPECIFIC ISSUES 1699 3.3.1 Trailer Encapsulation 1701 Routers that can connect to ten megabit Ethernets MAY be 1702 able to receive and forward Ethernet packets 1703 encapsulated using the trailer encapsulation described 1704 in [LINK:1]. However, a router SHOULD NOT originate 1705 trailer encapsulated packets. A router MUST NOT 1706 originate trailer encapsulated packets without first 1707 verifying, using the mechanism described in [INTRO:2], 1708 that the immediate destination of the packet is willing 1709 and able to accept trailer-encapsulated packets. A 1710 router SHOULD NOT agree (using these mechanisms) to 1711 accept trailer-encapsulated packets. 1713 3.3.2 Address Resolution Protocol - ARP 1715 Routers that implement ARP MUST be compliant and SHOULD 1716 be unconditionally compliant with the requirements in 1717 [INTRO:2]. 1719 The link layer MUST NOT report a Destination Unreachable 1720 error to IP solely because there is no ARP cache entry 1721 for a destination; it SHOULD queue up to a small number 1722 of datagrams breifly while performing the ARP 1723 request/reply sequence, and reply that the destination 1724 is unreachable to one of the queued datagrams only when 1725 this proves fruitless. 1727 A router MUST not believe any ARP reply that claims that 1728 the Link Layer address of another host or router is a 1729 broadcast or multicast address. 1731 3.3.3 Ethernet and 802.3 Coexistence 1733 Routers that can connect to ten megabit Ethernets MUST 1734 be compliant and SHOULD be unconditionally compliant 1735 with the Ethernet requirements of [INTRO:2]. 1737 Draft Requirements for IP Version 4 Routers March 1995 1739 3.3.4 Maximum Transmission Unit - MTU 1741 The MTU of each logical interface MUST be configurable 1742 within the range of legal MTUs for the interface. 1744 Many Link Layer protocols define a maximum frame size 1745 that may be sent. In such cases, a router MUST NOT 1746 allow an MTU to be set which would allow sending of 1747 frames larger than those allowed by the Link Layer 1748 protocol. However, a router SHOULD be willing to 1749 receive a packet as large as the maximum frame size even 1750 if that is larger than the MTU. 1752 DISCUSSION: 1753 Note that this is a stricter requirement than imposed 1754 on hosts by [INTRO:2], which requires that the MTU of 1755 each physical interface be configurable. 1757 If a network is using an MTU smaller than the maximum 1758 frame size for the Link Layer, a router may receive 1759 packets larger than the MTU from misconfigured and 1760 incompletely initialized hosts. The Robustness 1761 Principle indicates that the router should 1762 successfully receive these packets if possible. 1764 3.3.5 Point-to-Point Protocol - PPP 1766 Contrary to [INTRO:1], the Internet does have a standard 1767 point to point line protocol: the Point-to-Point 1768 Protocol (PPP), defined in [LINK:2], [LINK:3], [LINK:4], 1769 and [LINK:5]. 1771 A "point to point interface" is any interface that is 1772 designed to send data over a point to point line. Such 1773 interfaces include telephone, leased, dedicated or 1774 direct lines (either 2 or 4 wire), and may use point to 1775 point channels or virtual circuits of multiplexed 1776 interfaces such as ISDN. They normally use a 1777 standardized modem or bit serial interface (such as RS- 1778 232, RS-449 or V.35), using either synchronous or 1779 asynchronous clocking. Multiplexed interfaces often 1780 have special physical interfaces. 1782 Draft Requirements for IP Version 4 Routers March 1995 1784 A "general purpose serial interface" uses the same 1785 physical media as a point to point line, but supports 1786 the use of link layer networks as well as point to point 1787 connectivity. Link layer networks (such as X.25 or 1788 Frame Relay) use an alternative IP link layer 1789 specification. 1791 Routers that implement point to point or general purpose 1792 serial interfaces MUST IMPLEMENT PPP. 1794 PPP MUST be supported on all general purpose serial 1795 interfaces on a router. The router MAY allow the line 1796 to be configured to use point to point line protocols 1797 other than PPP. Point to point interfaces SHOULD either 1798 default to using PPP when enabled or require 1799 configuration of the link layer protocol before being 1800 enabled. General purpose serial interfaces SHOULD 1801 require configuration of the link layer protocol before 1802 being enabled. 1804 3.3.5.1 Introduction 1806 This section provides guidelines to router 1807 implementors so that they can ensure interoperability 1808 with other routers using PPP over either synchronous 1809 or asynchronous links. 1811 It is critical that an implementor understand the 1812 semantics of the option negotiation mechanism. 1813 Options are a means for a local device to indicate to 1814 a remote peer what the local device will accept from 1815 the remote peer, not what it wishes to send. It is 1816 up to the remote peer to decide what is most 1817 convenient to send within the confines of the set of 1818 options that the local device has stated that it can 1819 accept. Therefore it is perfectly acceptable and 1820 normal for a remote peer to ACK all the options 1821 indicated in an LCP Configuration Request (CR) even 1822 if the remote peer does not support any of those 1823 options. Again, the options are simply a mechanism 1824 for either device to indicate to its peer what it 1825 will accept, not necessarily what it will send. 1827 Draft Requirements for IP Version 4 Routers March 1995 1829 3.3.5.2 Link Control Protocol (LCP) Options 1831 The PPP Link Control Protocol (LCP) offers a number 1832 of options that may be negotiated. These options 1833 include (among others) address and control field 1834 compression, protocol field compression, asynchronous 1835 character map, Maximum Receive Unit (MRU), Link 1836 Quality Monitoring (LQM), magic number (for loopback 1837 detection), Password Authentication Protocol (PAP), 1838 Challenge Handshake Authentication Protocol (CHAP), 1839 and the 32-bit Frame Check Sequence (FCS). 1841 A router MAY use address/control field compression on 1842 either synchronous or asynchronous links. A router 1843 MAY use protocol field compression on either 1844 synchronous or asynchronous links. A router that 1845 indicates that it can accept these compressions MUST 1846 be able to accept uncompressed PPP header information 1847 also. 1849 DISCUSSION: 1850 These options control the appearance of the PPP 1851 header. Normally the PPP header consists of the 1852 address, the control field, and the protocol 1853 field. The address, on a point to point line, is 1854 0xFF, indicating "broadcast". The control field 1855 is 0x03, indicating "Unnumbered Information." The 1856 Protocol Identifier is a two byte value indicating 1857 the contents of the data area of the frame. If a 1858 system negotiates address and control field 1859 compression it indicates to its peer that it will 1860 accept PPP frames that have or do not have these 1861 fields at the front of the header. It does not 1862 indicate that it will be sending frames with these 1863 fields removed. 1865 Protocol field compression, when negotiated, 1866 indicates that the system is willing to receive 1867 protocol fields compressed to one byte when this 1868 is legal. There is no requirement that the sender 1869 do so. 1871 Use of address/control field compression is 1872 inconsistent with the use of numbered mode 1874 Draft Requirements for IP Version 4 Routers March 1995 1876 (reliable) PPP. 1878 IMPLEMENTATION: 1879 Some hardware does not deal well with variable 1880 length header information. In those cases it 1881 makes most sense for the remote peer to send the 1882 full PPP header. Implementations may ensure this 1883 by not sending the address/control field and 1884 protocol field compression options to the remote 1885 peer. Even if the remote peer has indicated an 1886 ability to receive compressed headers there is no 1887 requirement for the local router to send 1888 compressed headers. 1890 A router MUST negotiate the Asynchronous Control 1891 Character Map (ACCM) for asynchronous PPP links, but 1892 SHOULD NOT negotiate the ACCM for synchronous links. 1893 If a router receives an attempt to negotiate the ACCM 1894 over a synchronous link, it MUST ACKnowledge the 1895 option and then ignore it. 1897 DISCUSSION: 1898 There are implementations that offer both 1899 synchronous and asynchronous modes of operation 1900 and may use the same code to implement the option 1901 negotiation. In this situation it is possible 1902 that one end or the other may send the ACCM option 1903 on a synchronous link. 1905 A router SHOULD properly negotiate the maximum 1906 receive unit (MRU). Even if a system negotiates an 1907 MRU smaller than 1,500 bytes, it MUST be able to 1908 receive a 1,500 byte frame. 1910 A router SHOULD negotiate and enable the link quality 1911 monitoring (LQM) option. 1913 DISCUSSION: 1914 This memo does not specify a policy for deciding 1915 whether the link's quality is adequate. However, 1916 it is important (see Section [3.3.6]) that a 1917 router disable failed links. 1919 Draft Requirements for IP Version 4 Routers March 1995 1921 A router SHOULD implement and negotiate the magic 1922 number option for loopback detection. 1924 A router MAY support the authentication options (PAP 1925 - Password Authentication Protocol, and/or CHAP - 1926 Challenge Handshake Authentication Protocol). 1928 A router MUST support 16-bit CRC frame check sequence 1929 (FCS) and MAY support the 32-bit CRC. 1931 3.3.5.3 IP Control Protocol (IPCP) Options 1933 A router MAY offer to perform IP address negotiation. 1934 A router MUST accept a refusal (REJect) to perform IP 1935 address negotiation from the peer. 1937 Routers operating at link speeds of 19,200 BPS or 1938 less SHOULD implement and offer to perform Van 1939 Jacobson header compression. Routers that implement 1940 VJ compression SHOULD implement an administrative 1941 control enabling or disabling it. 1943 3.3.6 Interface Testing 1945 A router MUST have a mechanism to allow routing software 1946 to determine whether a physical interface is available 1947 to send packets or not; on multiplexed interfaces where 1948 permanent virtual circuits are opened for limited sets 1949 of neighbors, the router must also be able to determine 1950 whether the virtual circuits are viable. A router 1951 SHOULD have a mechanism to allow routing software to 1952 judge the quality of a physical interface. A router 1953 MUST have a mechanism for informing the routing software 1954 when a physical interface becomes available or 1955 unavailable to send packets because of administrative 1956 action. A router MUST have a mechanism for informing 1957 the routing software when it detects a Link level 1958 interface has become available or unavailable, for any 1959 reason. 1961 DISCUSSION: 1962 It is crucial that routers have workable mechanisms 1964 Draft Requirements for IP Version 4 Routers March 1995 1966 for determining that their network connections are 1967 functioning properly. Failure to detect link loss, 1968 or failure to take the proper actions when a problem 1969 is detected, can lead to black holes. 1971 The mechanisms available for detecting problems with 1972 network connections vary considerably, depending on 1973 the Link Layer protocols in use and the interface 1974 hardware. The intent is to maximize the capability 1975 to detect failures within the Link-Layer constraints. 1977 Draft Requirements for IP Version 4 Routers March 1995 1979 4. INTERNET LAYER - PROTOCOLS 1981 4.1 INTRODUCTION 1983 This chapter and chapter 5 discuss the protocols used at 1984 the Internet Layer: IP, ICMP, and IGMP. Since forwarding 1985 is obviously a crucial topic in a document discussing 1986 routers, chapter 5 limits itself to the aspects of the 1987 protocols that directly relate to forwarding. The current 1988 chapter contains the remainder of the discussion of the 1989 Internet Layer protocols. 1991 4.2 INTERNET PROTOCOL - IP 1993 4.2.1 INTRODUCTION 1995 Routers MUST implement the IP protocol, as defined by 1996 [INTERNET:1]. They MUST also implement its mandatory 1997 extensions: subnets (defined in [INTERNET:2]), IP 1998 broadcast (defined in [INTERNET:3]), and Classless 1999 Inter-Domain Routing (CIDR, defined in [INTERNET:15]). 2001 Router implementors need not consider compliance with 2002 the section of [INTRO:2] entitled "Internet Protocol -- 2003 IP," as that section is entirely duplicated or 2004 superseded in this document. A router MUST be 2005 compliant, and SHOULD be unconditionally compliant, with 2006 the requirements of the section entitled "SPECIFIC 2007 ISSUES" relating to IP in [INTRO:2]. 2009 In the following, the action specified in certain cases 2010 is to "silently discard" a received datagram. This 2011 means that the datagram will be discarded without 2012 further processing and that the router will not send any 2013 ICMP error message (see Section [4.3]) as a result. 2014 However, for diagnosis of problems a router SHOULD 2015 provide the capability of logging the error (see Section 2016 [1.3.3]), including the contents of the silently 2017 discarded datagram, and SHOULD count datagrams 2019 Draft Requirements for IP Version 4 Routers March 1995 2021 discarded. 2023 4.2.2 PROTOCOL WALK-THROUGH 2025 RFC 791 [INTERNET:1] is the specification for the 2026 Internet Protocol. 2028 4.2.2.1 Options: RFC 791 Section 3.2 2030 In datagrams received by the router itself, the IP 2031 layer MUST interpret IP options that it understands 2032 and preserve the rest unchanged for use by higher 2033 layer protocols. 2035 Higher layer protocols may require the ability to set 2036 IP options in datagrams they send or examine IP 2037 options in datagrams they receive. Later sections of 2038 this document discuss specific IP option support 2039 required by higher layer protocols. 2041 DISCUSSION: 2042 Neither this memo nor [INTRO:2] define the order 2043 in which a receiver must process multiple options 2044 in the same IP header. Hosts and routers 2045 originating datagrams containing multiple options 2046 must be aware that this introduces an ambiguity in 2047 the meaning of certain options when combined with 2048 a source-route option. 2050 Here are the requirements for specific IP options: 2052 (a) Security Option 2054 Some environments require the Security option in 2055 every packet originated or received. Routers 2056 SHOULD IMPLEMENT the revised security option 2057 described in [INTERNET:5]. 2059 DISCUSSION: 2060 Note that the security options described in 2061 [INTERNET:1] and RFC 1038 ([INTERNET:16]) are 2062 obsolete. 2064 Draft Requirements for IP Version 4 Routers March 1995 2066 (b) Stream Identifier Option 2068 This option is obsolete; routers SHOULD NOT 2069 place this option in a datagram that the router 2070 originates. This option MUST be ignored in 2071 datagrams received by the router. 2073 (c) Source Route Options 2075 A router MUST be able to act as the final 2076 destination of a source route. If a router 2077 receives a packet containing a completed source 2078 route, the packet has reached its final 2079 destination. In such an option, the pointer 2080 points beyond the last field and the destination 2081 address in the IP header addresses the router. 2082 The option as received (the recorded route) MUST 2083 be passed up to the transport layer (or to ICMP 2084 message processing). 2086 In the general case, a correct response to a 2087 source-routed datagram traverses the same route. 2088 A router MUST provide a means whereby transport 2089 protocols and applications can reverse the 2090 source route in a received datagram. This 2091 reversed source route MUST be inserted into 2092 datagrams they originate (see [INTRO:2] for 2093 details) when the router is unaware of policy 2094 constraints. However, if the router is policy 2095 aware, it MAY select another path. 2097 Some applications in the router MAY require that 2098 the user be able to enter a source route. 2100 A router MUST NOT originate a datagram 2101 containing multiple source route options. What 2102 a router should do if asked to forward a packet 2103 containing multiple source route options is 2104 described in Section [5.2.4.1]. 2106 When a source route option is created (which 2107 would happen when the router is originating a 2108 source routed datagram or is inserting a source 2109 route option as a result of a special filter), 2111 Draft Requirements for IP Version 4 Routers March 1995 2113 it MUST be correctly formed even if it is being 2114 created by reversing a recorded route that 2115 erroneously includes the source host (see case 2116 (B) in the discussion below). 2118 DISCUSSION: 2119 Suppose a source routed datagram is to be 2120 routed from source S to destination D via 2121 routers G1, G2, Gn. Source S constructs a 2122 datagram with G1's IP address as its 2123 destination address, and a source route 2124 option to get the datagram the rest of the 2125 way to its destination. However, there is an 2126 ambiguity in the specification over whether 2127 the source route option in a datagram sent 2128 out by S should be (A) or (B): 2130 (A): {>>G2, G3, ... Gn, D} <--- CORRECT 2132 (B): {S, >>G2, G3, ... Gn, D} <---- WRONG 2134 (where >> represents the pointer). If (A) is 2135 sent, the datagram received at D will contain 2136 the option: {G1, G2, ... Gn >>}, with S and D 2137 as the IP source and destination addresses. 2138 If (B) were sent, the datagram received at D 2139 would again contain S and D as the same IP 2140 source and destination addresses, but the 2141 option would be: {S, G1, ...Gn >>}; i.e., the 2142 originating host would be the first hop in 2143 the route. 2145 (d) Record Route Option 2147 Routers MAY support the Record Route option in 2148 datagrams originated by the router. 2150 (e) Timestamp Option 2152 Routers MAY support the timestamp option in 2153 datagrams originated by the router. The 2154 following rules apply: 2156 + When originating a datagram containing a 2158 Draft Requirements for IP Version 4 Routers March 1995 2160 Timestamp Option, a router MUST record a 2161 timestamp in the option if 2163 - Its Internet address fields are not pre- 2164 specified or 2165 - Its first pre-specified address is the IP 2166 address of the logical interface over 2167 which the datagram is being sent (or the 2168 router's router-id if the datagram is 2169 being sent over an unnumbered interface). 2171 + If the router itself receives a datagram 2172 containing a Timestamp Option, the router 2173 MUST insert the current time into the 2174 Timestamp Option (if there is space in the 2175 option to do so) before passing the option to 2176 the transport layer or to ICMP for 2177 processing. If space is not present, the | 2178 router MUST increment the Overflow Count in | 2179 the option. 2181 + A timestamp value MUST follow the rules 2182 defined in [INTRO:2]. 2184 IMPLEMENTATION: 2185 To maximize the utility of the timestamps 2186 contained in the timestamp option, the 2187 timestamp inserted should be, as nearly as 2188 practical, the time at which the packet 2189 arrived at the router. For datagrams 2190 originated by the router, the timestamp 2191 inserted should be, as nearly as practical, 2192 the time at which the datagram was passed to 2193 the Link Layer for transmission. 2195 The timestamp option permits the use of a 2196 non-standard time clock, but the use of a 2197 non-synchronized clock limits the utility of 2198 the time stamp. Therefore, routers are well 2199 advised to implement the Network Time 2200 Protocol for the purpose of synchronizing 2201 their clocks. 2203 Draft Requirements for IP Version 4 Routers March 1995 2205 4.2.2.2 Addresses in Options: RFC 791 Section 3.1 2207 Routers are called upon to insert their address into 2208 Record Route, Strict Source and Record Route, Loose 2209 Source and Record Route, or Timestamp Options. When 2210 a router inserts its address into such an option, it 2211 MUST use the IP address of the logical interface on 2212 which the packet is being sent. Where this rule 2213 cannot be obeyed because the output interface has no 2214 IP address (i.e., is an unnumbered interface), the 2215 router MUST instead insert its "router-id". The 2216 router's router-id is one of the router's IP 2217 addresses. The Router ID may be specified on a 2218 system basis or on a per-link basis. Which of the 2219 router's addresses is used as the router-id MUST NOT 2220 change (even across reboots) unless changed by the 2221 network manager. Relevant management changes include 2222 reconfiguration of the router such that the IP 2223 address used as the router-id ceases to be one of the 2224 router's IP addresses. Routers with multiple 2225 unnumbered interfaces MAY have multiple router-id's. 2226 Each unnumbered interface MUST be associated with a 2227 particular router-id. This association MUST NOT 2228 change (even across reboots) without reconfiguration 2229 of the router. 2231 DISCUSSION: 2232 This specification does not allow for routers that 2233 do not have at least one IP address. We do not 2234 view this as a serious limitation, since a router 2235 needs an IP address to meet the manageability 2236 requirements of Chapter [8] even if the router is 2237 connected only to point-to-point links. 2239 IMPLEMENTATION: 2240 One possible method of choosing the router-id that 2241 fulfills this requirement is to use the 2242 numerically smallest (or greatest) IP address 2243 (treating the address as a 32-bit integer) that is 2244 assigned to the router. 2246 Draft Requirements for IP Version 4 Routers March 1995 2248 4.2.2.3 Unused IP Header Bits: RFC 791 Section 3.1 2250 The IP header contains two reserved bits: one in the 2251 Type of Service byte and the other in the Flags 2252 field. A router MUST NOT set either of these bits to 2253 one in datagrams originated by the router. A router 2254 MUST NOT drop (refuse to receive or forward) a packet 2255 merely because one or more of these reserved bits has 2256 a non-zero value; i.e., the router MUST NOT check the 2257 values of thes bits. 2259 DISCUSSION: 2260 Future revisions to the IP protocol may make use 2261 of these unused bits. These rules are intended to 2262 ensure that these revisions can be deployed 2263 without having to simultaneously upgrade all 2264 routers in the Internet. 2266 4.2.2.4 Type of Service: RFC 791 Section 3.1 2268 The "Type-of-Service" byte in the IP header is 2269 divided into three sections: the Precedence field 2270 (high-order 3 bits), a field that is customarily 2271 called "Type of Service" or "TOS" (next 4 bits), and 2272 a reserved bit (the low order bit). 2274 Rules governing the reserved bit were described in 2275 Section [4.2.2.3]. 2277 A more extensive discussion of the TOS field and its 2278 use can be found in [ROUTE:11]. 2280 The description of the IP Precedence field is 2281 superseded by Section [5.3.3]. RFC 795, "Service 2282 Mappings", is obsolete and SHOULD NOT be implemented. 2284 4.2.2.5 Header Checksum: RFC 791 Section 3.1 2286 As stated in Section [5.2.2], a router MUST verify 2287 the IP checksum of any packet that is received, and 2288 MUST discard messages containing invalid checksums. 2290 Draft Requirements for IP Version 4 Routers March 1995 2292 The router MUST NOT provide a means to disable this 2293 checksum verification. 2295 A router MAY use incremental IP header checksum 2296 updating when the only change to the IP header is the 2297 time to live. This will reduce the possibility of 2298 undetected corruption of the IP header by the router. 2299 See [INTERNET:6] for a discussion of incrementally 2300 updating the checksum. 2302 IMPLEMENTATION: 2303 A more extensive description of the IP checksum, 2304 including extensive implementation hints, can be 2305 found in [INTERNET:6] and [INTERNET:7]. 2307 4.2.2.6 Unrecognized Header Options: RFC 791 Section 3.1 2309 A router MUST ignore IP options which it does not 2310 recognize. A corollary of this requirement is that a 2311 router MUST implement the End of Option List option 2312 and the No Operation option, since neither contains 2313 an explicit length. 2315 DISCUSSION: 2316 All future IP options will include an explicit 2317 length. 2319 4.2.2.7 Fragmentation: RFC 791 Section 3.2 2321 Fragmentation, as described in [INTERNET:1], MUST be 2322 supported by a router. 2324 When a router fragments an IP datagram, it SHOULD 2325 minimize the number of fragments. When a router 2326 fragments an IP datagram, it SHOULD send the 2327 fragments in order. A fragmentation method that may 2328 generate one IP fragment that is significantly 2329 smaller than the other MAY cause the first IP 2330 fragment to be the smaller one. 2332 Draft Requirements for IP Version 4 Routers March 1995 2334 DISCUSSION: 2335 There are several fragmentation techniques in 2336 common use in the Internet. One involves 2337 splitting the IP datagram into IP fragments with 2338 the first being MTU sized, and the others being 2339 approximately the same size, smaller than the MTU. 2340 The reason for this is twofold. The first IP 2341 fragment in the sequence will be the effective MTU 2342 of the current path between the hosts, and the 2343 following IP fragments are sized to minimize the 2344 further fragmentation of the IP datagram. Another 2345 technique is to split the IP datagram into MTU 2346 sized IP fragments, with the last fragment being 2347 the only one smaller, as described in 2348 [INTERNET:1]. 2350 A common trick used by some implementations of 2351 TCP/IP is to fragment an IP datagram into IP 2352 fragments that are no larger than 576 bytes when 2353 the IP datagram is to travel through a router. 2354 This is intended to allow the resulting IP 2355 fragments to pass the rest of the path without 2356 further fragmentation. This would, though, create 2357 more of a load on the destination host, since it 2358 would have a larger number of IP fragments to 2359 reassemble into one IP datagram. It would also 2360 not be efficient on networks where the MTU only 2361 changes once and stays much larger than 576 bytes. 2362 Examples include LAN networks such as an IEEE 2363 802.5 network with a MTU of 2048 or an Ethernet 2364 network with an MTU of 1500). 2366 One other fragmentation technique discussed was 2367 splitting the IP datagram into approximately equal 2368 sized IP fragments, with the size less than or 2369 equal to the next hop network's MTU. This is 2370 intended to minimize the number of fragments that 2371 would result from additional fragmentation further 2372 down the path, and assure equal delay for each 2373 fragment. 2375 Routers SHOULD generate the least possible number 2376 of IP fragments. 2378 Draft Requirements for IP Version 4 Routers March 1995 2380 Work with slow machines leads us to believe that 2381 if it is necessary to fragment messages, sending 2382 the small IP fragment first maximizes the chance 2383 of a host with a slow interface of receiving all 2384 the fragments. 2386 4.2.2.8 Reassembly: RFC 791 Section 3.2 2388 As specified in the corresponding section of 2389 [INTRO:2], a router MUST support reassembly of 2390 datagrams that it delivers to itself. 2392 4.2.2.9 Time to Live: RFC 791 Section 3.2 2394 Time to Live (TTL) handling for packets originated or 2395 received by the router is governed by [INTRO:2]; this 2396 section changes none of its stipulations. However, 2397 since the remainder of the IP Protocol section of 2398 [INTRO:2] is rewritten, this section is as well. 2400 Note in particular that a router MUST NOT check the 2401 TTL of a packet except when forwarding it. 2403 A router MUST NOT originate or forward a datagram 2404 with a Time-to-Live (TTL) value of zero. 2406 A router MUST NOT discard a datagram just because it 2407 was received with TTL equal to zero or one; if it is 2408 to the router and otherwise valid, the router MUST 2409 attempt to receive it. 2411 On messages the router originates, the IP layer MUST 2412 provide a means for the transport layer to set the 2413 TTL field of every datagram that is sent. When a 2414 fixed TTL value is used, it MUST be configurable. 2415 The number SHOULD exceed the typical internet 2416 diameter, and current wisdom suggests that it should 2417 exceed twice the internet diameter to allow for 2418 growth. Current suggested values are normally posted 2419 in the Assigned Numbers RFC. The TTL field has two 2420 functions: limit the lifetime of TCP segments (see 2422 Draft Requirements for IP Version 4 Routers March 1995 2424 RFC 793 [TCP:1], p. 28), and terminate Internet 2425 routing loops. Although TTL is a time in seconds, it 2426 also has some attributes of a hop-count, since each 2427 router is required to reduce the TTL field by at 2428 least one. 2430 TTL expiration is intended to cause datagrams to be 2431 discarded by routers, but not by the destination 2432 host. Hosts that act as routers by forwarding 2433 datagrams must therefore follow the router's rules 2434 for TTL. 2436 A higher-layer protocol may want to set the TTL in 2437 order to implement an "expanding scope" search for 2438 some Internet resource. This is used by some 2439 diagnostic tools, and is expected to be useful for 2440 locating the "nearest" server of a given class using 2441 IP multicasting, for example. A particular transport 2442 protocol may also want to specify its own TTL bound 2443 on maximum datagram lifetime. 2445 A fixed default value must be at least big enough for 2446 the Internet "diameter," i.e., the longest possible 2447 path. A reasonable value is about twice the 2448 diameter, to allow for continued Internet growth. As 2449 of this writing, messages crossing the United States 2450 frequently traverse 15 to 20 routers; this argues for 2451 a default TTL value in excess of 40, and 64 is a 2452 common value. 2454 4.2.2.10 Multi-subnet Broadcasts: RFC 922 2456 All-subnets broadcasts (called "multi-subnet 2457 broadcasts" in [INTERNET:3]) have been deprecated. 2458 See Section [5.3.5.3]. 2460 4.2.2.11 Addressing: RFC 791 Section 3.2 2462 As noted in 2.2.5.1, there are now five classes of IP 2463 addresses: Class A through Class E. Class D 2464 addresses are used for IP multicasting [INTERNET:4], 2466 Draft Requirements for IP Version 4 Routers March 1995 2468 while Class E addresses are reserved for experimental 2469 use. The distinction between Class A, B, and C 2470 addresses is no longer important; they are used as 2471 generalized unicast network prefixes with only 2472 historical interest in their class. 2474 An IP multicast address is a 28-bit logical address 2475 that stands for a group of hosts, and may be either 2476 permanent or transient. Permanent multicast 2477 addresses are allocated by the Internet Assigned 2478 Number Authority [INTRO:7], while transient addresses 2479 may be allocated dynamically to transient groups. 2480 Group membership is determined dynamically using IGMP 2481 [INTERNET:4]. 2483 We now summarize the important special cases for 2484 general purpose unicast IP addresses, using the 2485 following notation for an IP address: 2487 { , } 2489 and the notation "-1" for a field that contains all 1 2490 bits and the notation "0" for a field that contains 2491 all 0 bits. 2493 (a) { 0, 0 } 2495 This host on this network. It MUST NOT be used 2496 as a source address by routers, except the 2497 router MAY use this as a source address as part 2498 of an initialization procedure (e.g., if the 2499 router is using BOOTP to load its configuration 2500 information). 2502 Incoming datagrams with a source address of { 0, 2503 0 } which are received for local delivery (see 2504 Section [5.2.3]), MUST be accepted if the router 2505 implements the associated protocol and that 2506 protocol clearly defines appropriate action to 2507 be taken. Otherwise, a router MUST silently 2508 discard any locally-delivered datagram whose 2509 source address is { 0, 0 }. 2511 DISCUSSION: 2513 Draft Requirements for IP Version 4 Routers March 1995 2515 Some protocols define specific actions to 2516 take in response to a received datagram whose 2517 source address is { 0, 0 }. Two examples are 2518 BOOTP and ICMP Mask Request. The proper 2519 operation of these protocols often depends on 2520 the ability to receive datagrams whose source 2521 address is { 0, 0 }. For most protocols, 2522 however, it is best to ignore datagrams 2523 having a source address of { 0, 0 } since 2524 they were probably generated by a 2525 misconfigured host or router. Thus, if a 2526 router knows how to deal with a given 2527 datagram having a { 0, 0 } source address, 2528 the router MUST accept it. Otherwise, the 2529 router MUST discard it. 2531 See also Section [4.2.3.1] for a non-standard 2532 use of { 0, 0 }. 2534 (b) { 0, } 2536 Specified host on this network. It MUST NOT be 2537 sent by routers except that the router MAY use 2538 this as a source address as part of an 2539 initialization procedure by which the it learns 2540 its own IP address. 2542 (c) { -1, -1 } 2544 Limited broadcast. It MUST NOT be used as a 2545 source address. 2547 A datagram with this destination address will be 2548 received by every host and router on the 2549 connected physical network, but will not be 2550 forwarded outside that network. 2552 (d) { , -1 } 2554 Directed Broadcast - a broadcast directed to the 2555 specified network prefix. It MUST NOT be used 2556 as a source address. A router MAY originate 2557 Network Directed Broadcast packets. A router 2558 MUST receive Network Directed Broadcast packets; 2560 Draft Requirements for IP Version 4 Routers March 1995 2562 however a router MAY have a configuration option 2563 to prevent reception of these packets. Such an 2564 option MUST default to allowing reception. 2566 (e) { 127, } 2568 Internal host loopback address. Addresses of 2569 this form MUST NOT appear outside a host. 2571 The is administratively assigned so 2572 that its value will be unique in the routing domain 2573 to which the device is connected. 2575 IP addresses are not permitted to have the value 0 or 2576 -1 for the or fields 2577 except in the special cases listed above. This 2578 implies that each of these fields will be at least 2579 two bits long. 2581 DISCUSSION: 2582 Previous versions of this document also noted that 2583 subnet numbers must be neither 0 nor -1, and must 2584 be at least two bits in length. In a CIDR world, 2585 the subnet number is clearly an extension of the 2586 network prefix and cannot be interpreted without 2587 the remainder of the prefix. This restriction of 2588 subnet numbers is therefore meaningless in view of 2589 CIDR and may be safely ignored. 2591 For further discussion of broadcast addresses, see 2592 Section [4.2.3.1]. 2594 When a router originates any datagram, the IP source 2595 address MUST be one of its own IP addresses (but not 2596 a broadcast or multicast address). The only 2597 exception is during initialization. 2599 For most purposes, a datagram addressed to a 2600 broadcast or multicast destination is processed as if 2601 it had been addressed to one of the router's IP 2602 addresses; that is to say: 2604 Draft Requirements for IP Version 4 Routers March 1995 2606 + A router MUST receive and process normally any 2607 packets with a broadcast destination address. 2609 + A router MUST receive and process normally any 2610 packets sent to a multicast destination address 2611 that the router has asked to receive. 2613 The term "specific-destination address" means the 2614 equivalent local IP address of the host. The 2615 specific-destination address is defined to be the 2616 destination address in the IP header unless the 2617 header contains a broadcast or multicast address, in 2618 which case the specific-destination is an IP address 2619 assigned to the physical interface on which the 2620 datagram arrived. 2622 A router MUST silently discard any received datagram 2623 containing an IP source address that is invalid by 2624 the rules of this section. This validation could be 2625 done either by the IP layer or (when appropriate) by 2626 each protocol in the transport layer. As with any 2627 datagram a router discards, the datagram discard 2628 SHOULD be counted. 2630 DISCUSSION: 2631 A misaddressed datagram might be caused by a Link 2632 Layer broadcast of a unicast datagram or by 2633 another router or host that is confused or 2634 misconfigured. 2636 4.2.3 SPECIFIC ISSUES 2638 4.2.3.1 IP Broadcast Addresses 2640 For historical reasons, there are a number of IP 2641 addresses (some standard and some not) which are used 2642 to indicate that an IP packet is an IP broadcast. A 2643 router 2645 (1) MUST treat as IP broadcasts packets addressed to 2647 Draft Requirements for IP Version 4 Routers March 1995 2649 255.255.255.255 or { , -1 }. 2651 (2) SHOULD silently discard on receipt (i.e., do not 2652 even deliver to applications in the router) any 2653 packet addressed to 0.0.0.0 or { , 0 }. If these packets are not silently 2655 discarded, they MUST be treated as IP broadcasts 2656 (see Section [5.3.5]). There MAY be a 2657 configuration option to allow receipt of these 2658 packets. This option SHOULD default to 2659 discarding them. 2661 (3) SHOULD (by default) use the limited broadcast 2662 address (255.255.255.255) when originating an IP 2663 broadcast destined for a connected (sub)network 2664 (except when sending an ICMP Address Mask Reply, 2665 as discussed in Section [4.3.3.9]). A router 2666 MUST receive limited broadcasts. 2668 (4) SHOULD NOT originate datagrams addressed to 2669 0.0.0.0 or { , 0 }. There MAY 2670 be a configuration option to allow generation of 2671 these packets (instead of using the relevant 2672 "1s" format broadcast). This option SHOULD 2673 default to not generating them. 2675 DISCUSSION: 2676 In the second bullet, the router obviously cannot 2677 recognize addresses of the form { , 0 } if the router has no interface to 2679 that network prefix. In that case, the rules of 2680 the second bullet do not apply because, from the 2681 point of view of the router, the packet is not an 2682 IP broadcast packet. 2684 4.2.3.2 IP Multicasting 2686 An IP router SHOULD satisfy the Host Requirements 2687 with respect to IP multicasting, as specified in 2688 [INTRO:2]. An IP router SHOULD support local IP 2689 multicasting on all connected networks. When a 2690 mapping from IP multicast addresses to link-layer 2692 Draft Requirements for IP Version 4 Routers March 1995 2694 addresses has been specified (see the various IP- 2695 over-xxx specifications), it SHOULD use that mapping, 2696 and MAY be configurable to use the link layer 2697 broadcast instead. On point-to-point links and all 2698 other interfaces, multicasts are encapsulated as link 2699 layer broadcasts. Support for local IP multicasting 2700 includes originating multicast datagrams, joining 2701 multicast groups and receiving multicast datagrams, 2702 and leaving multicast groups. This implies support 2703 for all of [INTERNET:4] including IGMP (see Section 2704 [4.4]). 2706 DISCUSSION: 2707 Although [INTERNET:4] is entitled Host Extensions 2708 for IP Multicasting, it applies to all IP systems, 2709 both hosts and routers. In particular, since 2710 routers may join multicast groups, it is correct 2711 for them to perform the "host" part of IGMP, 2712 reporting their group memberships to any multicast 2713 routers that may be present on their attached 2714 networks (whether or not they themselves are 2715 multicast routers). 2717 Some router protocols may specifically require 2718 support for IP multicasting (e.g., OSPF 2719 [ROUTE:1]), or may recommend it (e.g., ICMP Router 2720 Discovery [INTERNET:13]). 2722 4.2.3.3 Path MTU Discovery 2724 To eliminate fragmentation or minimize it, it is 2725 desirable to know what is the path MTU along the path 2726 from the source to destination. The path MTU is the 2727 minimum of the MTUs of each hop in the path. 2728 [INTERNET:14] describes a technique for dynamically 2729 discovering the maximum transmission unit (MTU) of an 2730 arbitrary internet path. For a path that passes 2731 through a router that does not support [INTERNET:14], 2732 this technique might not discover the correct Path 2733 MTU, but it will always choose a Path MTU as accurate 2734 as, and in many cases more accurate than, the Path 2735 MTU that would be chosen by older techniques or the 2737 Draft Requirements for IP Version 4 Routers March 1995 2739 current practice. 2741 When a router is originating an IP datagram, it 2742 SHOULD use the scheme described in [INTERNET:14] to 2743 limit the datagram's size. If the router's route to 2744 the datagram's destination was learned from a routing 2745 protocol that provides Path MTU information, the 2746 scheme described in [INTERNET:14] is still used, but 2747 the Path MTU information from the routing protocol 2748 SHOULD be used as the initial guess as to the Path 2749 MTU and also as an upper bound on the Path MTU. 2751 4.2.3.4 Subnetting 2753 Under certain circumstances, it may be desirable to 2754 support subnets of a particular network being 2755 interconnected only through a path that is not part 2756 of the subnetted network. This is known as 2757 discontiguous subnetwork support. 2759 Routers MUST support discontiguous subnetworks. 2761 IMPLEMENTATION: 2762 In classical IP networks, this was very difficult 2763 to achieve; in CIDR networks, it is a natural by- 2764 product. Therefore, a router SHOULD NOT make 2765 assumptions about subnet architecture, but SHOULD 2766 treat each route as a generalized network prefix. 2768 DISCUSSION: 2769 The Internet has been growing at a tremendous rate 2770 of late. This has been placing severe strains on 2771 the IP addressing technology. A major factor in 2772 this strain is the strict IP Address class 2773 boundaries. These make it difficult to 2774 efficiently size network prefixes to their 2775 networks and aggregate several network prefixes 2776 into a single route advertisement. By eliminating 2777 the strict class boundaries of the IP address and 2778 treating each route as a generalized network 2779 prefix, these strains may be greatly reduced. 2781 Draft Requirements for IP Version 4 Routers March 1995 2783 The technology for currently doing this is 2784 Classless Inter Domain Routing (CIDR) 2785 [INTERNET:15]. 2787 For similar reasons, an address block associated with 2788 a given network prefix could be subdivided into 2789 subblocks of different sizes, so that the network 2790 prefixes associated with the subblocks would have 2791 different length. For example, within a block whose 2792 network prefix is 8 bits long, one subblock may have 2793 a 16 bit network prefix, another may have an 18 bit 2794 network prefix, and a third a 14 bit network prefix. 2796 Routers MUST support variable length network prefixes 2797 in both their interface configurations and their 2798 routing databases. 2800 4.3 INTERNET CONTROL MESSAGE PROTOCOL - ICMP 2802 4.3.1 INTRODUCTION 2804 ICMP is an auxiliary protocol, which provides routing, 2805 diagnostic and error functionality for IP. It is 2806 described in [INTERNET:8]. A router MUST support ICMP. 2808 ICMP messages are grouped in two classes that are 2809 discussed in the following sections: 2811 ICMP error messages: 2813 Destination Unreachable Section 4.3.3.1 2814 Redirect Section 4.3.3.2 2815 Source Quench Section 4.3.3.3 2816 Time Exceeded Section 4.3.3.4 2817 Parameter Problem Section 4.3.3.5 2819 ICMP query messages: 2820 Echo Section 4.3.3.6 2821 Information Section 4.3.3.7 2822 Timestamp Section 4.3.3.8 2823 Address Mask Section 4.3.3.9 2825 Draft Requirements for IP Version 4 Routers March 1995 2827 Router Discovery Section 4.3.3.10 2829 General ICMP requirements and discussion are in the next 2830 section. 2832 4.3.2 GENERAL ISSUES 2834 4.3.2.1 Unknown Message Types 2836 If an ICMP message of unknown type is received, it 2837 MUST be passed to the ICMP user interface (if the 2838 router has one) or silently discarded (if the router 2839 does not have one). 2841 4.3.2.2 ICMP Message TTL 2843 When originating an ICMP message, the router MUST 2844 initialize the TTL. The TTL for ICMP responses must 2845 not be taken from the packet that triggered the 2846 response. 2848 4.3.2.3 Original Message Header 2850 Historically, every ICMP error message has included 2851 the Internet header and at least the first 8 data 2852 bytes of the datagram that triggered the error. This 2853 is no longer adequate, due to the use of IP-in-IP 2854 tunneling and other technologies. Therefore, the 2855 ICMP datagram SHOULD contain as much of the original 2856 datagram as possible without the length of the ICMP 2857 datagram exceeding 576 bytes. The returned IP header 2858 (and user data) MUST be identical to that which was 2859 received, except that the router is not required to 2860 undo any modifications to the IP header that are 2861 normally performed in forwarding that were performed 2862 before the error was detected (e.g., decrementing the 2863 TTL, or updating options). Note that the 2864 requirements of Section [4.3.3.5] supersede this 2866 Draft Requirements for IP Version 4 Routers March 1995 2868 requirement in some cases (i.e., for a Parameter 2869 Problem message, if the problem is in a modified 2870 field, the router must "undo" the modification). See 2871 Section [4.3.3.5]). 2873 4.3.2.4 ICMP Message Source Address 2875 Except where this document specifies otherwise, the 2876 IP source address in an ICMP message originated by 2877 the router MUST be one of the IP addresses associated 2878 with the physical interface over which the ICMP 2879 message is transmitted. If the interface has no IP 2880 addresses associated with it, the router's router-id 2881 (see Section [5.2.5]) is used instead. 2883 4.3.2.5 TOS and Precedence 2885 ICMP error messages SHOULD have their TOS bits set to 2886 the same value as the TOS bits in the packet that 2887 provoked the sending of the ICMP error message, 2888 unless setting them to that value would cause the 2889 ICMP error message to be immediately discarded 2890 because it could not be routed to its destination. 2891 Otherwise, ICMP error messages MUST be sent with a 2892 normal (i.e., zero) TOS. An ICMP reply message 2893 SHOULD have its TOS bits set to the same value as the 2894 TOS bits in the ICMP request that provoked the reply. 2896 ICMP Source Quench error messages, if sent at all, 2897 MUST have their IP Precedence field set to the same 2898 value as the IP Precedence field in the packet that 2899 provoked the sending of the ICMP Source Quench 2900 message. All other ICMP error messages (Destination 2901 Unreachable, Redirect, Time Exceeded, and Parameter 2902 Problem) SHOULD have their precedence value set to 6 2903 (INTERNETWORK CONTROL) or 7 (NETWORK CONTROL). The 2904 IP Precedence value for these error messages MAY be 2905 settable. 2907 An ICMP reply message MUST have its IP Precedence 2908 field set to the same value as the IP Precedence 2909 field in the ICMP request that provoked the reply. 2911 Draft Requirements for IP Version 4 Routers March 1995 2913 4.3.2.6 Source Route 2915 If the packet which provokes the sending of an ICMP 2916 error message contains a source route option, the 2917 ICMP error message SHOULD also contain a source route 2918 option of the same type (strict or loose), created by 2919 reversing the portion before the pointer of the route 2920 recorded in the source route option of the original 2921 packet UNLESS the ICMP error message is an ICMP 2922 Parameter Problem complaining about a source route 2923 option in the original packet, or unless the router 2924 is aware of policy that would prevent the delivery of 2925 the ICMP error message. 2927 DISCUSSION: 2928 In environments which use the U.S. Department of 2929 Defense security option (defined in [INTERNET:5]), 2930 ICMP messages may need to include a security 2931 option. Detailed information on this topic should 2932 be available from the Defense Communications 2933 Agency. 2935 4.3.2.7 When Not to Send ICMP Errors 2937 An ICMP error message MUST NOT be sent as the result 2938 of receiving: 2940 + An ICMP error message, or 2942 + A packet which fails the IP header validation tests 2943 described in Section [5.2.2] (except where that 2944 section specifically permits the sending of an 2945 ICMP error message), or 2947 + A packet destined to an IP broadcast or IP 2948 multicast address, or 2950 + A packet sent as a Link Layer broadcast or 2951 multicast, or 2953 + A packet whose source address has a network prefix 2954 of zero or is an invalid source address (as 2956 Draft Requirements for IP Version 4 Routers March 1995 2958 defined in Section [5.3.7]), or 2960 + Any fragment of a datagram other then the first 2961 fragment (i.e., a packet for which the fragment 2962 offset in the IP header is nonzero). 2964 Furthermore, an ICMP error message MUST NOT be sent 2965 in any case where this memo states that a packet is 2966 to be "silently discarded". 2968 NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY 2969 REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR SENDING 2970 ICMP ERROR MESSAGES. 2972 DISCUSSION: 2973 These rules aim to prevent the "broadcast storms" 2974 that have resulted from routers or hosts returning 2975 ICMP error messages in response to broadcast 2976 packets. For example, a broadcast UDP packet to a 2977 non-existent port could trigger a flood of ICMP 2978 Destination Unreachable datagrams from all devices 2979 that do not have a client for that destination 2980 port. On a large Ethernet, the resulting 2981 collisions can render the network useless for a 2982 second or more. 2984 Every packet that is broadcast on the connected 2985 network should have a valid IP broadcast address 2986 as its IP destination (see Section [5.3.4] and 2987 [INTRO:2]). However, some devices violate this 2988 rule. To be certain to detect broadcast packets, 2989 therefore, routers are required to check for a 2990 link-layer broadcast as well as an IP-layer 2991 address. 2993 IMPLEMENTATION: 2994 This requires that the link layer inform the IP 2995 layer when a link-layer broadcast packet has been 2996 received; see Section [3.1]. 2998 Draft Requirements for IP Version 4 Routers March 1995 3000 4.3.2.8 Rate Limiting 3002 A router which sends ICMP Source Quench messages MUST 3003 be able to limit the rate at which the messages can 3004 be generated. A router SHOULD also be able to limit 3005 the rate at which it sends other sorts of ICMP error 3006 messages (Destination Unreachable, Redirect, Time 3007 Exceeded, Parameter Problem). The rate limit 3008 parameters SHOULD be settable as part of the 3009 configuration of the router. How the limits are 3010 applied (e.g., per router or per interface) is left 3011 to the implementor's discretion. 3013 DISCUSSION: 3014 Two problems for a router sending ICMP error 3015 message are: 3016 (1) The consumption of bandwidth on the reverse 3017 path, and 3018 (2) The use of router resources (e.g., memory, CPU 3019 time) 3021 To help solve these problems a router can limit 3022 the frequency with which it generates ICMP error 3023 messages. For similar reasons, a router may limit 3024 the frequency at which some other sorts of 3025 messages, such as ICMP Echo Replies, are 3026 generated. 3028 IMPLEMENTATION: 3029 Various mechanisms have been used or proposed for 3030 limiting the rate at which ICMP messages are sent: 3032 (1) Count-based - for example, send an ICMP error 3033 message for every N dropped packets overall 3034 or per given source host. This mechanism 3035 might be appropriate for ICMP Source Quench, 3036 if used, but probably not for other types of 3037 ICMP messages. 3039 (2) Timer-based - for example, send an ICMP error 3040 message to a given source host or overall at 3041 most once per T milliseconds. 3043 Draft Requirements for IP Version 4 Routers March 1995 3045 (3) Bandwidth-based - for example, limit the rate 3046 at which ICMP messages are sent over a 3047 particular interface to some fraction of the 3048 attached network's bandwidth. 3050 4.3.3 SPECIFIC ISSUES 3052 4.3.3.1 Destination Unreachable 3054 If a route cannot forward a packet because it has no 3055 routes at all (including no default route) to the 3056 destination specified in the packet, then the router 3057 MUST generate a Destination Unreachable, Code 0 3058 (Network Unreachable) ICMP message. If the router 3059 does have routes to the destination network specified 3060 in the packet but the TOS specified for the routes is 3061 neither the default TOS (0000) nor the TOS of the 3062 packet that the router is attempting to route, then 3063 the router MUST generate a Destination Unreachable, 3064 Code 11 (Network Unreachable for TOS) ICMP message. 3066 If a packet is to be forwarded to a host on a network 3067 that is directly connected to the router (i.e., the 3068 router is the last-hop router) and the router has 3069 ascertained that there is no path to the destination 3070 host then the router MUST generate a Destination 3071 Unreachable, Code 1 (Host Unreachable) ICMP message. 3072 If a packet is to be forwarded to a host that is on a 3073 network that is directly connected to the router and 3074 the router cannot forward the packet because no route 3075 to the destination has a TOS that is either equal to 3076 the TOS requested in the packet or is the default TOS 3077 (0000) then the router MUST generate a Destination 3078 Unreachable, Code 12 (Host Unreachable for TOS) ICMP 3079 message. 3081 DISCUSSION: 3082 The intent is that a router generates the 3083 "generic" host/network unreachable if it has no 3084 path at all (including default routes) to the 3086 Draft Requirements for IP Version 4 Routers March 1995 3088 destination. If the router has one or more paths 3089 to the destination, but none of those paths have 3090 an acceptable TOS, then the router generates the 3091 "unreachable for TOS" message. 3093 4.3.3.2 Redirect 3095 The ICMP Redirect message is generated to inform a 3096 local host that it should use a different next hop 3097 router for certain traffic. 3099 Contrary to [INTRO:2], a router MAY ignore ICMP 3100 Redirects when choosing a path for a packet 3101 originated by the router if the router is running a 3102 routing protocol or if forwarding is enabled on the 3103 router and on the interface over which the packet is 3104 being sent. 3106 4.3.3.3 Source Quench 3108 A router SHOULD NOT originate ICMP Source Quench 3109 messages. As specified in Section [4.3.2], a router 3110 that does originate Source Quench messages MUST be 3111 able to limit the rate at which they are generated. 3113 DISCUSSION: 3114 Research seems to suggest that Source Quench 3115 consumes network bandwidth but is an ineffective 3116 (and unfair) antidote to congestion. See, for 3117 example, [INTERNET:9] and [INTERNET:10]. Section 3118 [5.3.6] discusses the current thinking on how 3119 routers ought to deal with overload and network 3120 congestion. 3122 A router MAY ignore any ICMP Source Quench messages 3123 it receives. 3125 DISCUSSION: 3126 A router itself may receive a Source Quench as the 3127 result of originating a packet sent to another 3128 router or host. Such datagrams might be, e.g., an 3130 Draft Requirements for IP Version 4 Routers March 1995 3132 EGP update sent to another router, or a telnet 3133 stream sent to a host. A mechanism has been 3134 proposed ([INTERNET:11], [INTERNET:12]) to make 3135 the IP layer respond directly to Source Quench by 3136 controlling the rate at which packets are sent, 3137 however, this proposal is currently experimental 3138 and not currently recommended. 3140 4.3.3.4 Time Exceeded 3142 When a router is forwarding a packet and the TTL 3143 field of the packet is reduced to 0, the requirements 3144 of section [5.2.3.8] apply. 3146 When the router is reassembling a packet that is 3147 destined for the router, it is acting as an Internet 3148 host. [INTRO:2]'s reassembly requirements therefore 3149 apply. 3151 When the router receives (i.e., is destined for the 3152 router) a Time Exceeded message, it MUST comply with 3153 [INTRO:2]. 3155 4.3.3.5 Parameter Problem 3157 A router MUST generate a Parameter Problem message 3158 for any error not specifically covered by another 3159 ICMP message. The IP header field or IP option 3160 including the byte indicated by the pointer field 3161 MUST be included unchanged in the IP header returned 3162 with this ICMP message. Section [4.3.2] defines an 3163 exception to this requirement. 3165 A new variant of the Parameter Problem message was 3166 defined in [INTRO:2]: 3167 Code 1 = required option is missing. 3169 DISCUSSION: 3170 This variant is currently in use in the military 3171 community for a missing security option. 3173 Draft Requirements for IP Version 4 Routers March 1995 3175 4.3.3.6 Echo Request/Reply 3177 A router MUST implement an ICMP Echo server function 3178 that receives Echo Requests sent to the router, and 3179 sends corresponding Echo Replies. A router MUST be 3180 prepared to receive, reassemble and echo an ICMP Echo 3181 Request datagram at least as the maximum of 576 and 3182 the MTUs of all the connected networks. 3184 The Echo server function MAY choose not to respond to 3185 ICMP echo requests addressed to IP broadcast or IP 3186 multicast addresses. 3188 A router SHOULD have a configuration option that, if 3189 enabled, causes the router to silently ignore all 3190 ICMP echo requests; if provided, this option MUST 3191 default to allowing responses. 3193 DISCUSSION: 3194 The neutral provision about responding to 3195 broadcast and multicast Echo Requests derives from 3196 [INTRO:2]'s "Echo Request/Reply" section. 3198 As stated in Section [10.3.3], a router MUST also 3199 implement a user/application-layer interface for 3200 sending an Echo Request and receiving an Echo Reply, 3201 for diagnostic purposes. All ICMP Echo Reply 3202 messages MUST be passed to this interface. 3204 The IP source address in an ICMP Echo Reply MUST be 3205 the same as the specific-destination address of the 3206 corresponding ICMP Echo Request message. 3208 Data received in an ICMP Echo Request MUST be 3209 entirely included in the resulting Echo Reply. 3211 If a Record Route and/or Timestamp option is received 3212 in an ICMP Echo Request, this option (these options) 3213 SHOULD be updated to include the current router and 3214 included in the IP header of the Echo Reply message, 3215 without "truncation". Thus, the recorded route will 3216 be for the entire round trip. 3218 If a Source Route option is received in an ICMP Echo 3220 Draft Requirements for IP Version 4 Routers March 1995 3222 Request, the return route MUST be reversed and used 3223 as a Source Route option for the Echo Reply message, 3224 unless the router is aware of policy that would 3225 prevent the delivery of the message. 3227 4.3.3.7 Information Request/Reply 3229 A router SHOULD NOT originate or respond to these 3230 messages. 3232 DISCUSSION: 3233 The Information Request/Reply pair was intended to 3234 support self-configuring systems such as diskless 3235 workstations, to allow them to discover their IP 3236 network prefixes at boot time. However, these 3237 messages are now obsolete. The RARP and BOOTP 3238 protocols provide better mechanisms for a host to 3239 discover its own IP address. 3241 4.3.3.8 Timestamp and Timestamp Reply 3243 A router MAY implement Timestamp and Timestamp Reply. 3244 If they are implemented then: 3246 + The ICMP Timestamp server function MUST return a 3247 Timestamp Reply to every Timestamp message that is 3248 received. It SHOULD be designed for minimum 3249 variability in delay. 3251 + An ICMP Timestamp Request message to an IP 3252 broadcast or IP multicast address MAY be silently 3253 discarded. 3255 + The IP source address in an ICMP Timestamp Reply 3256 MUST be the same as the specific-destination 3257 address of the corresponding Timestamp Request 3258 message. 3260 + If a Source Route option is received in an ICMP 3261 Timestamp Request, the return route MUST be 3262 reversed and used as a Source Route option for the 3264 Draft Requirements for IP Version 4 Routers March 1995 3266 Timestamp Reply message, unless the router is 3267 aware of policy that would prevent the delivery of 3268 the message. 3270 + If a Record Route and/or Timestamp option is 3271 received in a Timestamp Request, this (these) 3272 option(s) SHOULD be updated to include the current 3273 router and included in the IP header of the 3274 Timestamp Reply message. 3276 + If the router provides an application-layer 3277 interface for sending Timestamp Request messages 3278 then incoming Timestamp Reply messages MUST be 3279 passed up to the ICMP user interface. 3281 The preferred form for a timestamp value (the 3282 "standard value") is milliseconds since midnight, 3283 Universal Time. However, it may be difficult to 3284 provide this value with millisecond resolution. For 3285 example, many systems use clocks that update only at 3286 line frequency, 50 or 60 times per second. 3287 Therefore, some latitude is allowed in a "standard 3288 value": 3290 (a) A "standard value" MUST be updated at least 16 3291 times per second (i.e., at most the six low- 3292 order bits of the value may be undefined). 3294 (b) The accuracy of a "standard value" MUST 3295 approximate that of operator-set CPU clocks, 3296 i.e., correct within a few minutes. 3298 IMPLEMENTATION: 3299 To meet the second condition, a router may need to 3300 query some time server when the router is booted 3301 or restarted. It is recommended that the UDP Time 3302 Server Protocol be used for this purpose. A more 3303 advanced implementation would use the Network Time 3304 Protocol (NTP) to achieve nearly millisecond clock 3305 synchronization; however, this is not required. 3307 Draft Requirements for IP Version 4 Routers March 1995 3309 4.3.3.9 Address Mask Request/Reply 3311 A router MUST implement support for receiving ICMP 3312 Address Mask Request messages and responding with 3313 ICMP Address Mask Reply messages. These messages are 3314 defined in [INTERNET:2]. 3316 A router SHOULD have a configuration option for each 3317 logical interface specifying whether the router is 3318 allowed to answer Address Mask Requests for that 3319 interface; this option MUST default to allowing 3320 responses. A router MUST NOT respond to an Address 3321 Mask Request before the router knows the correct 3322 address mask. 3324 A router MUST NOT respond to an Address Mask Request 3325 that has a source address of 0.0.0.0 and which 3326 arrives on a physical interface that has associated 3327 with it multiple logical interfaces and the address 3328 masks for those interfaces are not all the same. 3330 A router SHOULD examine all ICMP Address Mask Replies 3331 that it receives to determine whether the information 3332 it contains matches the router's knowledge of the 3333 address mask. If the ICMP Address Mask Reply appears 3334 to be in error, the router SHOULD log the address 3335 mask and the sender's IP address. A router MUST NOT 3336 use the contents of an ICMP Address Mask Reply to 3337 determine the correct address mask. 3339 Because hosts may not be able to learn the address 3340 mask if a router is down when the host boots up, a 3341 router MAY broadcast a gratuitous ICMP Address Mask 3342 Reply on each of its logical interfaces after it has 3343 configured its own address masks. However, this 3344 feature can be dangerous in environments that use 3345 variable length address masks. Therefore, if this 3346 feature is implemented, gratuitous Address Mask 3347 Replies MUST NOT be broadcast over any logical 3348 interface(s) which either: 3350 + Are not configured to send gratuitous Address Mask 3351 Replies. Each logical interface MUST have a 3352 configuration parameter controlling this, and that 3354 Draft Requirements for IP Version 4 Routers March 1995 3356 parameter MUST default to not sending the 3357 gratuitous Address Mask Replies. 3359 + Share subsuming (but not identical) network 3360 prefixes and physical interface. 3362 The { , -1 } form of the IP broadcast 3363 address MUST be used for broadcast Address Mask 3364 Replies. 3366 DISCUSSION: 3367 The ability to disable sending Address Mask 3368 Replies by routers is required at a few sites that 3369 intentionally lie to their hosts about the address 3370 mask. The need for this is expected to go away as 3371 more and more hosts become compliant with the Host 3372 Requirements standards. 3374 The reason for both the second bullet above and 3375 the requirement about which IP broadcast address 3376 to use is to prevent problems when multiple IP 3377 network prefixes are in use on the same physical 3378 network. 3380 4.3.3.10 Router Advertisement and Solicitations 3382 An IP router MUST support the router part of the ICMP 3383 Router Discovery Protocol [INTERNET:13] on all 3384 connected networks on which the router supports 3385 either IP multicast or IP broadcast addressing. The 3386 implementation MUST include all the configuration 3387 variables specified for routers, with the specified 3388 defaults. 3390 DISCUSSION: 3391 Routers are not required to implement the host 3392 part of the ICMP Router Discovery Protocol, but 3393 might find it useful for operation while IP 3394 forwarding is disabled (i.e., when operating as a 3395 host). 3397 Draft Requirements for IP Version 4 Routers March 1995 3399 DISCUSSION: 3400 We note that it is quite common for hosts to use | 3401 RIP Version 1 as the "router discovery" protocol. 3402 Such hosts listen to RIP traffic and use and use 3403 information extracted from that traffic to 3404 discover routers and to make decisions as to which 3405 router to use as a first-hop router for a given 3406 destination. While this behavior is discouraged, 3407 it is still common and implementors should be 3408 aware of it. 3410 4.4 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP 3412 IGMP [INTERNET:4] is a protocol used between hosts and 3413 multicast routers on a single physical network to establish 3414 hosts' membership in particular multicast groups. 3415 Multicast routers use this information, in conjunction with 3416 a multicast routing protocol, to support IP multicast 3417 forwarding across the Internet. 3419 A router SHOULD implement the host part of IGMP. 3421 Draft Requirements for IP Version 4 Routers March 1995 3423 5. INTERNET LAYER - FORWARDING 3425 5.1 INTRODUCTION 3427 This section describes the process of forwarding packets. 3429 5.2 FORWARDING WALK-THROUGH 3431 There is no separate specification of the forwarding 3432 function in IP. Instead, forwarding is covered by the 3433 protocol specifications for the internet layer protocols 3434 ([INTERNET:1], [INTERNET:2], [INTERNET:3], [INTERNET:8], 3435 and [ROUTE:11]). 3437 5.2.1 Forwarding Algorithm 3439 Since none of the primary protocol documents describe 3440 the forwarding algorithm in any detail, we present it 3441 here. This is just a general outline, and omits 3442 important details, such as handling of congestion, that 3443 are dealt with in later sections. 3445 It is not required that an implementation follow exactly 3446 the algorithms given in sections [5.2.1.1], [5.2.1.2], 3447 and [5.2.1.3]. Much of the challenge of writing router 3448 software is to maximize the rate at which the router can 3449 forward packets while still achieving the same effect of 3450 the algorithm. Details of how to do that are beyond the 3451 scope of this document, in part because they are heavily 3452 dependent on the architecture of the router. Instead, 3453 we merely point out the order dependencies among the 3454 steps: 3456 (1) A router MUST verify the IP header, as described in 3457 section [5.2.2], before performing any actions 3458 based on the contents of the header. This allows 3459 the router to detect and discard bad packets before 3460 the expenditure of other resources. 3462 (2) Processing of certain IP options requires that the 3464 Draft Requirements for IP Version 4 Routers March 1995 3466 router insert its IP address into the option. As 3467 noted in Section [5.2.4], the address inserted MUST 3468 be the address of the logical interface on which 3469 the packet is sent or the router's router-id if the 3470 packet is sent over an unnumbered interface. Thus, 3471 processing of these options cannot be completed 3472 until after the output interface is chosen. 3474 (3) The router cannot check and decrement the TTL before 3475 checking whether the packet should be delivered to 3476 the router itself, for reasons mentioned in Section 3477 [4.2.2.9]. 3479 (4) More generally, when a packet is delivered locally 3480 to the router, its IP header MUST NOT be modified 3481 in any way (except that a router may be required to 3482 insert a timestamp into any Timestamp options in 3483 the IP header). Thus, before the router determines 3484 whether the packet is to be delivered locally to 3485 the router, it cannot update the IP header in any 3486 way that it is not prepared to undo. 3488 5.2.1.1 General 3490 This section covers the general forwarding algorithm. 3491 This algorithm applies to all forms of packets to be 3492 forwarded: unicast, multicast, and broadcast. 3494 (1) The router receives the IP packet (plus 3495 additional information about it, as described in 3496 Section [3.1]) from the Link Layer. 3498 (2) The router validates the IP header, as described 3499 in Section [5.2.2]. Note that IP reassembly is 3500 not done, except on IP fragments to be queued 3501 for local delivery in step (4). 3503 (3) The router performs most of the processing of any 3504 IP options. As described in Section [5.2.4], 3505 some IP options require additional processing 3506 after the routing decision has been made. 3508 Draft Requirements for IP Version 4 Routers March 1995 3510 (4) The router examines the destination IP address of 3511 the IP datagram, as described in Section 3512 [5.2.3], to determine how it should continue to 3513 process the IP datagram. There are three 3514 possibilities: 3516 + The IP datagram is destined for the router, 3517 and should be queued for local delivery, 3518 doing reassembly if needed. 3520 + The IP datagram is not destined for the 3521 router, and should be queued for forwarding. 3523 + The IP datagram should be queued for 3524 forwarding, but (a copy) must also be queued 3525 for local delivery. 3527 5.2.1.2 Unicast 3529 Since the local delivery case is well covered by 3530 [INTRO:2], the following assumes that the IP datagram 3531 was queued for forwarding. If the destination is an 3532 IP unicast address: 3534 (5) The forwarder determines the next hop IP address 3535 for the packet, usually by looking up the 3536 packet's destination in the router's routing 3537 table. This procedure is described in more 3538 detail in Section [5.2.4]. This procedure also 3539 decides which network interface should be used 3540 to send the packet. 3542 (6) The forwarder verifies that forwarding the packet 3543 is permitted. The source and destination 3544 addresses should be valid, as described in 3545 Section [5.3.7] and Section [5.3.4] If the 3546 router supports administrative constraints on 3547 forwarding, such as those described in Section 3548 [5.3.9], those constraints must be satisfied. 3550 (7) The forwarder decrements (by at least one) and 3551 checks the packet's TTL, as described in Section 3552 [5.3.1]. 3554 Draft Requirements for IP Version 4 Routers March 1995 3556 (8) The forwarder performs any IP option processing 3557 that could not be completed in step 3. 3559 (9) The forwarder performs any necessary IP 3560 fragmentation, as described in Section 3561 [4.2.2.7]. Since this step occurs after 3562 outbound interface selection (step 5), all 3563 fragments of the same datagram will be 3564 transmitted out the same interface. 3566 (10) The forwarder determines the Link Layer address 3567 of the packet's next hop. The mechanisms for 3568 doing this are Link Layer-dependent (see chapter 3569 3). 3571 (11) The forwarder encapsulates the IP datagram (or 3572 each of the fragments thereof) in an appropriate 3573 Link Layer frame and queues it for output on the 3574 interface selected in step 5. 3576 (12) The forwarder sends an ICMP redirect if 3577 necessary, as described in Section [4.3.3.2]. 3579 5.2.1.3 Multicast 3581 If the destination is an IP multicast, the following 3582 steps are taken. 3584 Note that the main differences between the forwarding 3585 of IP unicasts and the forwarding of IP multicasts 3586 are 3588 + IP multicasts are usually forwarded based on both 3589 the datagram's source and destination IP 3590 addresses, 3592 + IP multicast uses an expanding ring search, 3594 + IP multicasts are forwarded as Link Level 3595 multicasts, and 3597 + ICMP errors are never sent in response to IP 3598 multicast datagrams. 3600 Draft Requirements for IP Version 4 Routers March 1995 3602 Note that the forwarding of IP multicasts is still 3603 somewhat experimental. As a result, the algorithm 3604 presented below is not mandatory, and is provided as 3605 an example only. 3607 (5a) Based on the IP source and destination addresses 3608 found in the datagram header, the router 3609 determines whether the datagram has been 3610 received on the proper interface for forwarding. 3611 If not, the datagram is dropped silently. The 3612 method for determining the proper receiving 3613 interface depends on the multicast routing 3614 algorithm(s) in use. In one of the simplest 3615 algorithms, reverse path forwarding (RPF), the 3616 proper interface is the one that would be used 3617 to forward unicasts back to the datagram source. 3619 (6a) Based on the IP source and destination addresses 3620 found in the datagram header, the router 3621 determines the datagram's outgoing interfaces. 3622 To implement IP multicast's expanding ring 3623 search (see [INTERNET:4]) a minimum TTL value is 3624 specified for each outgoing interface. A copy 3625 of the multicast datagram is forwarded out each 3626 outgoing interface whose minimum TTL value is 3627 less than or equal to the TTL value in the 3628 datagram header, by separately applying the 3629 remaining steps on each such interface. 3631 (7a) The router decrements the packet's TTL by one. 3633 (8a) The forwarder performs any IP option processing 3634 that could not be completed in step (3). 3636 (9a) The forwarder performs any necessary IP 3637 fragmentation, as described in Section 3638 [4.2.2.7]. 3640 (10a) The forwarder determines the Link Layer address 3641 to use in the Link Level encapsulation. The 3642 mechanisms for doing this are Link Layer- 3643 dependent. On LANs a Link Level multicast or 3644 broadcast is selected, as an algorithmic 3645 translation of the datagrams' IP multicast 3647 Draft Requirements for IP Version 4 Routers March 1995 3649 address. See the various IP-over-xxx 3650 specifications for more details. 3652 (11a) The forwarder encapsulates the packet (or each 3653 of the fragments thereof) in an appropriate Link 3654 Layer frame and queues it for output on the 3655 appropriate interface. 3657 5.2.2 IP Header Validation 3659 Before a router can process any IP packet, it MUST 3660 perform a the following basic validity checks on the 3661 packet's IP header to ensure that the header is 3662 meaningful. If the packet fails any of the following 3663 tests, it MUST be silently discarded, and the error 3664 SHOULD be logged. 3666 (1) The packet length reported by the Link Layer must be 3667 large enough to hold the minimum length legal IP 3668 datagram (20 bytes). 3670 (2) The IP checksum must be correct. 3672 (3) The IP version number must be 4. If the version 3673 number is not 4 then the packet may be another 3674 version of IP, such as IPng or ST-II. 3676 (4) The IP header length field must be large enough to 3677 hold the minimum length legal IP datagram (20 bytes 3678 = 5 words). 3680 (5) The IP header length field must be large enough to 3681 hold the IP datagram header, whose length is 3682 specified in the IP header length field. 3684 A router MUST NOT have a configuration option that 3685 allows disabling any of these tests. 3687 If the packet passes the second and third tests, the IP 3688 header length field is at least 4, and both the IP total 3689 length field and the packet length reported by the Link 3690 Layer are at least 16 then, despite the above rule, the 3691 router MAY respond with an ICMP Parameter Problem 3693 Draft Requirements for IP Version 4 Routers March 1995 3695 message, whose pointer points at the IP header length 3696 field (if it failed the fourth test) or the IP total 3697 length field (if it failed the fifth test). However, it 3698 still MUST discard the packet and still SHOULD log the 3699 error. 3701 These rules (and this entire document) apply only to 3702 version 4 of the Internet Protocol. These rules should 3703 not be construed as prohibiting routers from supporting 3704 other versions of IP. Furthermore, if a router can 3705 truly classify a packet as being some other version of 3706 IP then it ought not treat that packet as an error 3707 packet within the context of this memo. 3709 IMPLEMENTATION: 3710 It is desirable for purposes of error reporting, 3711 though not always entirely possible, to determine why 3712 a header was invalid. There are four possible 3713 reasons: 3715 + The Link Layer truncated the IP header 3717 + The datagram is using a version of IP other than 3718 the standard one (version 4). 3720 + The IP header has been corrupted in transit. 3722 + The sender generated an illegal IP header. 3724 It is probably desirable to perform the checks in the 3725 order listed, since we believe that this ordering is 3726 most likely to correctly categorize the cause of the 3727 error. For purposes of error reporting, it may also 3728 be desirable to check if a packet that fails these 3729 tests has an IP version number indicating IPng or 3730 ST-II; these should be handled according to their 3731 respective specifications. 3733 Additionally, the router SHOULD verify that the packet 3734 length reported by the Link Layer is at least as large 3735 as the IP total length recorded in the packet's IP 3736 header. If it appears that the packet has been 3737 truncated, the packet MUST be discarded, the error 3738 SHOULD be logged, and the router SHOULD respond with an 3740 Draft Requirements for IP Version 4 Routers March 1995 3742 ICMP Parameter Problem message whose pointer points at 3743 the IP total length field. 3745 DISCUSSION: 3746 Because any higher layer protocol that concerns 3747 itself with data corruption will detect truncation of 3748 the packet data when it reaches its final 3749 destination, it is not absolutely necessary for 3750 routers to perform the check suggested above to 3751 maintain protocol correctness. However, by making 3752 this check a router can simplify considerably the 3753 task of determining which hop in the path is 3754 truncating the packets. It will also reduce the 3755 expenditure of resources "down-stream" from the 3756 router in that down-stream systems will not need to 3757 deal with the packet. 3759 Finally, if the destination address in the IP header is 3760 not one of the addresses of the router, the router 3761 SHOULD verify that the packet does not contain a Strict 3762 Source and Record Route option. If a packet fails this 3763 test (if it contains a strict source route option), the 3764 router SHOULD log the error and SHOULD respond with an 3765 ICMP Parameter Problem error with the pointer pointing 3766 at the offending packet's IP destination address. 3768 DISCUSSION: 3769 Some people might suggest that the router should 3770 respond with a Bad Source Route message instead of a 3771 Parameter Problem message. However, when a packet 3772 fails this test, it usually indicates a protocol 3773 error by the previous hop router, whereas Bad Source 3774 Route would suggest that the source host had 3775 requested a nonexistent or broken path through the 3776 network. 3778 5.2.3 Local Delivery Decision 3780 When a router receives an IP packet, it must decide 3781 whether the packet is addressed to the router (and 3782 should be delivered locally) or the packet is addressed 3783 to another system (and should be handled by the 3785 Draft Requirements for IP Version 4 Routers March 1995 3787 forwarder). There is also a hybrid case, where certain 3788 IP broadcasts and IP multicasts are both delivered 3789 locally and forwarded. A router MUST determine which of 3790 the these three cases applies using the following rules. 3792 + An unexpired source route option is one whose pointer 3793 value does not point past the last entry in the 3794 source route. If the packet contains an unexpired 3795 source route option, the pointer in the option is 3796 advanced until either the pointer does point past the 3797 last address in the option or else the next address 3798 is not one of the router's own addresses. In the 3799 latter (normal) case, the packet is forwarded (and 3800 not delivered locally) regardless of the rules below. 3802 + The packet is delivered locally and not considered for 3803 forwarding in the following cases: 3805 - The packet's destination address exactly matches 3806 one of the router's IP addresses, 3808 - The packet's destination address is a limited 3809 broadcast address ({-1, -1}), or 3811 - The packet's destination is an IP multicast address 3812 which is never forwarded (such as 224.0.0.1 or 3813 224.0.0.2) and (at least) one of the logical 3814 interfaces associated with the physical interface 3815 on which the packet arrived is a member of the 3816 destination multicast group. 3818 + The packet is passed to the forwarder AND delivered 3819 locally in the following cases: 3821 - The packet's destination address is an IP broadcast 3822 address that addresses at least one of the 3823 router's logical interfaces but does not address 3824 any of the logical interfaces associated with the 3825 physical interface on which the packet arrived 3827 - The packet's destination is an IP multicast address 3828 which is permitted to be forwarded (unlike 3829 224.0.0.1 and 224.0.0.2) and (at least) one of the 3831 Draft Requirements for IP Version 4 Routers March 1995 3833 logical interfaces associated with the physical 3834 interface on which the packet arrived is a member 3835 of the destination multicast group. 3837 + The packet is delivered locally if the packet's 3838 destination address is an IP broadcast address (other 3839 than a limited broadcast address) that addresses at 3840 least one of the logical interfaces associated with 3841 the physical interface on which the packet arrived. 3842 The packet is ALSO passed to the forwarder unless the 3843 link on which the packet arrived uses an IP 3844 encapsulation that does not encapsulate broadcasts 3845 differently than unicasts (e.g., by using different 3846 Link Layer destination addresses). 3848 + The packet is passed to the forwarder in all other 3849 cases. 3851 DISCUSSION: 3852 The purpose of the requirement in the last sentence 3853 of the fourth bullet is to deal with a directed 3854 broadcast to another network prefix on the same 3855 physical cable. Normally, this works as expected: 3856 the sender sends the broadcast to the router as a 3857 Link Layer unicast. The router notes that it arrived 3858 as a unicast, and therefore must be destined for a 3859 different network prefix than the sender sent it on. 3860 Therefore, the router can safely send it as a Link 3861 Layer broadcast out the same (physical) interface 3862 over which it arrived. However, if the router can't 3863 tell whether the packet was received as a Link Layer 3864 unicast, the sentence ensures that the router does 3865 the safe but wrong thing rather than the unsafe but 3866 right thing. 3868 IMPLEMENTATION: 3869 As described in Section [5.3.4], packets received as 3870 Link Layer broadcasts are generally not forwarded. 3871 It may be advantageous to avoid passing to the 3872 forwarder packets it would later discard because of 3873 the rules in that section. 3875 Some Link Layers (either because of the hardware or 3877 Draft Requirements for IP Version 4 Routers March 1995 3879 because of special code in the drivers) can deliver 3880 to the router copies of all Link Layer broadcasts and 3881 multicasts it transmits. Use of this feature can 3882 simplify the implementation of cases where a packet 3883 has to both be passed to the forwarder and delivered 3884 locally, since forwarding the packet will 3885 automatically cause the router to receive a copy of 3886 the packet that it can then deliver locally. One 3887 must use care in these circumstances to prevent 3888 treating a received loop-back packet as a normal 3889 packet that was received (and then being subject to 3890 the rules of forwarding, etc.). 3892 Even without such a Link Layer, it is of course 3893 hardly necessary to make a copy of an entire packet 3894 to queue it both for forwarding and for local 3895 delivery, though care must be taken with fragments, 3896 since reassembly is performed on locally delivered 3897 packets but not on forwarded packets. One simple 3898 scheme is to associate a flag with each packet on the 3899 router's output queue that indicates whether it 3900 should be queued for local delivery after it has been 3901 sent. 3903 5.2.4 Determining the Next Hop Address 3905 When a router is going to forward a packet, it must 3906 determine whether it can send it directly to its 3907 destination, or whether it needs to pass it through 3908 another router. If the latter, it needs to determine 3909 which router to use. This section explains how these 3910 determinations are made. 3912 This section makes use of the following definitions: 3914 + "LSRR" - IP Loose Source and Record Route option 3916 + "SSRR" - IP Strict Source and Record Route option 3918 + "Source Route Option" - an LSRR or an SSRR 3920 + "Ultimate Destination Address" - where the packet is 3921 being sent to: the last address in the source route 3923 Draft Requirements for IP Version 4 Routers March 1995 3925 of a source-routed packet, or the destination address 3926 in the IP header of a non-source-routed packet 3928 + "Adjacent" - reachable without going through any IP 3929 routers 3931 + "Next Hop Address" - the IP address of the adjacent 3932 host or router to which the packet should be sent 3933 next 3935 + "IP Destination Address" - the ultimate destination 3936 address, except in source routed packets, where it is 3937 the next address specified in the source route 3939 + Immediate Destination - the node, System, router, 3940 end-system, or whatever that is addressed by the IP 3941 Destination Address. 3943 5.2.4.1 IP Destination Address 3945 If : 3947 + the destination address in the IP header is one of 3948 the addresses of the router, 3950 + the packet contains a Source Route Option, and 3952 + the pointer in the Source Route Option does not 3953 point past the end of the option, 3955 then the next IP Destination Address is the address 3956 pointed at by the pointer in that option. If : 3958 + the destination address in the IP header is one of 3959 the addresses of the router, 3961 + the packet contains a Source Route Option, and 3963 + the pointer in the Source Route Option points past 3964 the end of the option, 3966 then the message is addressed to the system analyzing 3967 the message. 3969 Draft Requirements for IP Version 4 Routers March 1995 3971 A router MUST use the IP Destination Address, not the 3972 Ultimate Destination Address (the last address in the 3973 source route option), when determining how to handle 3974 a packet. 3976 It is an error for more than one source route option 3977 to appear in a datagram. If it receives such a 3978 datagram, it SHOULD discard the packet and reply with 3979 an ICMP Parameter Problem message whose pointer 3980 points at the beginning of the second source route 3981 option. 3983 5.2.4.2 Local/Remote Decision 3985 After it has been determined that the IP packet needs 3986 to be forwarded according to the rules specified in 3987 Section [5.2.3], the following algorithm MUST be used 3988 to determine if the Immediate Destination is directly 3989 accessible (see [INTERNET:2]). 3991 (1) For each network interface that has not been 3992 assigned any IP address (the "unnumbered lines" 3993 as described in Section [2.2.7]), compare the 3994 router-id of the other end of the line to the IP 3995 Destination Address. If they are exactly equal, 3996 the packet can be transmitted through this 3997 interface. 3999 DISCUSSION: 4000 In other words, the router or host at the 4001 remote end of the line is the destination of 4002 the packet or is the next step in the source 4003 route of a source routed packet. 4005 (2) If no network interface has been selected in the 4006 first step, for each IP address assigned to the 4007 router: 4008 (a) isolate the network prefix used by the 4009 interface. 4011 IMPLEMENTATION: 4012 The result of this operation will 4013 usually have been computed and saved 4015 Draft Requirements for IP Version 4 Routers March 1995 4017 during initialization. 4019 (b) Isolate the corresponding set of bits from 4020 the IP Destination Address of the packet. 4021 (c) Compare the resulting network prefixes. If 4022 they are equal to each other, the packet 4023 can be transmitted through the 4024 corresponding network interface. 4026 (3) If the destination was neither the router-id of a 4027 neighbor on an unnumbered interface nor a member 4028 of a directly connected network prefix, the IP 4029 Destination is accessible only through some 4030 other router. The selection of the router and 4031 the "next hop" IP address is described in 4032 Section [5.2.4.3]. In the case of a host that 4033 is not also a router, this may be the configured 4034 default router. Ongoing work in the IETF 4035 [ARCH:9, NRHP] considers some cases such as when 4036 multiple IP (sub)networks are overlaid on the 4037 same link layer network. Barring policy 4038 restrictions, hosts and routers using a common 4039 link layer network can directly communicate even 4040 if they are not in the same IP (sub)network, if 4041 there is adequate information present. The Next 4042 Hop Routing Protocol (NHRP) enables IP entities 4043 to determine the "optimal" link layer address to 4044 be used to traverse such a link layer network 4045 towards a remote destination. 4047 (4) If the selected "next hop" is reachable through an 4048 interface configured to use NHRP, then the 4049 following additional steps apply: 4050 (a) Compare the IP Destination Address to the 4051 destination addresses in the NHRP cache. If 4052 the address is in the cache, then send the 4053 datagram to the corresponding cached link 4054 layer address. 4055 (b) If the address is not in the cache, then 4056 construct an NHRP request packet containing 4057 the IP Destination Address. This message is 4058 sent to the NHRP server configured for that 4059 interface. This may be a logically separate 4060 process or entity in the router itself. 4062 Draft Requirements for IP Version 4 Routers March 1995 4064 (c) The NHRP server will respond with the proper 4065 link layer address to use to transmit the 4066 datagram and subsequent datagrams to the same 4067 destination. The system MAY transmit the 4068 datagram(s) to the traditional "next hop" 4069 router while awaiting the NHRP reply. 4071 5.2.4.3 Next Hop Address 4073 The router applies the algorithm in the previous section * 4074 to determine if the IP Destination Address is adjacent. 4075 If so, the next hop address is the same as the IP 4076 Destination Address. Otherwise, the packet must be 4077 forwarded through another router to reach its Immediate 4078 Destination. The selection of this router is the topic 4079 of this section. 4081 If the packet contains an SSRR, the router MUST discard 4082 the packet and reply with an ICMP Bad Source Route 4083 error. Otherwise, the router looks up the IP 4084 Destination Address in its routing table to determine an 4085 appropriate next hop address. 4087 DISCUSSION: 4088 Per the IP specification, a Strict Source Route must 4089 specify a sequence of nodes through which the packet 4090 must traverse; the packet must go from one node of 4091 the source route to the next, traversing intermediate 4092 networks only. Thus, if the router is not adjacent 4093 to the next step of the source route, the source 4094 route can not be fulfilled. Therefore, the router 4095 rejects such with an ICMP Bad Source Route error. 4097 The goal of the next-hop selection process is to examine 4098 the entries in the router's Forwarding Information Base 4099 (FIB) and select the best route (if there is one) for 4100 the packet from those available in the FIB. 4102 Conceptually, any route lookup algorithm starts out with 4103 a set of candidate routes that consists of the entire 4104 contents of the FIB. The algorithm consists of a series 4105 of steps that discard routes from the set. These steps 4107 Draft Requirements for IP Version 4 Routers March 1995 4109 are referred to as Pruning Rules. Normally, when the 4110 algorithm terminates there is exactly one route 4111 remaining in the set. If the set ever becomes empty, 4112 the packet is discarded because the destination is 4113 unreachable. It is also possible for the algorithm to 4114 terminate when more than one route remains in the set. 4115 In this case, the router may arbitrarily discard all but 4116 one of them, or may perform "load-splitting" by choosing 4117 whichever of the routes has been least recently used. 4119 With the exception of rule 3 (Weak TOS), a router MUST 4120 use the following Pruning Rules when selecting a next 4121 hop for a packet. If a router does consider TOS when 4122 making next-hop decisions, the Rule 3 must be applied in 4123 the order indicated below. These rules MUST be 4124 (conceptually) applied to the FIB in the order that they 4125 are presented. (For some historical perspective, 4126 additional pruning rules, and other common algorithms in 4127 use, see Appendix E.) 4129 DISCUSSION: 4130 Rule 3 is optional in that Section [5.3.2] says that 4131 a router only SHOULD consider TOS when making 4132 forwarding decisions. 4134 (1) Basic Match 4135 This rule discards any routes to destinations other 4136 than the IP Destination Address of the packet. For 4137 example, if a packet's IP Destination Address is | 4138 10.144.2.5, this step would discard a route to net 4139 128.12.0.0/16 but would retain any routes to the | 4140 network prefixes 10.0.0.0/8 and 10.144.0.0/16, and 4141 any default routes. 4143 More precisely, we assume that each route has a 4144 destination attribute, called route.dest, and a 4145 corresponding prefix length, called route.length, 4146 to specify which bits of route.dest are 4147 significant. The IP Destination Address of the 4148 packet being forwarded is ip.dest. This rule 4149 discards all routes from the set of candidates 4150 except those for which the most significant 4151 route.length bits of route.dest and ip.dest are 4153 Draft Requirements for IP Version 4 Routers March 1995 4155 equal. 4157 For example, if a packet's IP Destination Address | 4158 is 10.144.2.5 and there are network prefixes | 4159 10.144.1.0/24, 10.144.2.0/24, and 10.144.3.0/24, | 4160 this rule would keep only 10.144.2.0/24; it is the 4161 only route whose prefix has the same value as the 4162 corresponding bits in the IP Destination Address of 4163 the packet. 4165 (2) Longest Match 4166 Longest Match is a refinement of Basic Match, 4167 described above. After performing Basic Match 4168 pruning, the algorithm examines the remaining 4169 routes to determine which among them have the 4170 largest route.length values. All except these are 4171 discarded. 4173 For example, if a packet's IP Destination Address | 4174 is 10.144.2.5 and there are network prefixes | 4175 10.144.2.0/24, 10.144.0.0/16, and 10.0.0.0/8, then | 4176 this rule would keep only the first (10.144.2.0/24) 4177 because its prefix length is longest. 4179 (3) Weak TOS 4180 Each route has a type of service attribute, called 4181 route.tos, whose possible values are assumed to be 4182 identical to those used in the TOS field of the IP 4183 header. Routing protocols that distribute TOS 4184 information fill in route.tos appropriately in 4185 routes they add to the FIB; routes from other 4186 routing protocols are treated as if they have the 4187 default TOS (0000). The TOS field in the IP header 4188 of the packet being routed is called ip.tos. 4190 The set of candidate routes is examined to 4191 determine if it contains any routes for which 4192 route.tos = ip.tos. If so, all routes except those 4193 for which route.tos = ip.tos are discarded. If 4194 not, all routes except those for which route.tos = 4195 0000 are discarded from the set of candidate 4196 routes. 4198 Additional discussion of routing based on Weak TOS 4200 Draft Requirements for IP Version 4 Routers March 1995 4202 may be found in [ROUTE:11]. 4204 DISCUSSION: 4205 The effect of this rule is to select only those 4206 routes that have a TOS that matches the TOS 4207 requested in the packet. If no such routes 4208 exist then routes with the default TOS are 4209 considered. Routes with a non-default TOS that 4210 is not the TOS requested in the packet are never 4211 used, even if such routes are the only available 4212 routes that go to the packet's destination. 4214 (4) Best Metric 4215 Each route has a metric attribute, called 4216 route.metric, and a routing domain identifier, 4217 called route.domain. Each member of the set of 4218 candidate routes is compared with each other member 4219 of the set. If route.domain is equal for the two 4220 routes and route.metric is strictly "inferior" for 4221 one when compared with the other, then the one with 4222 the "inferior" metric is discarded from the set. 4223 The determination of "inferior" is usually by a 4224 simple arithmetic comparison, though some protocols 4225 may have structured metrics requiring more complex 4226 comparisons. 4228 (5) Vendor Policy 4229 Vendor Policy is sort of a catch-all to make up for 4230 the fact that the previously listed rules are often 4231 inadequate to choose from the possible routes. 4232 Vendor Policy pruning rules are extremely vendor- 4233 specific. See section [5.2.4.4]. 4235 This algorithm has two distinct disadvantages. 4236 Presumably, a router implementor might develop 4237 techniques to deal with these disadvantages and make 4238 them a part of the Vendor Policy pruning rule. 4240 (1) IS-IS and OSPF route classes are not directly 4241 handled. 4243 (2) Path properties other than type of service (e.g., 4244 MTU) are ignored. 4246 Draft Requirements for IP Version 4 Routers March 1995 4248 It is also worth noting a deficiency in the way that TOS 4249 is supported: routing protocols that support TOS are 4250 implicitly preferred when forwarding packets that have 4251 non-zero TOS values. 4253 The Basic Match and Longest Match pruning rules 4254 generalize the treatment of a number of particular types 4255 of routes. These routes are selected in the following, 4256 decreasing, order of preference: 4258 (1) Host Route: This is a route to a specific end 4259 system. 4261 (2) Hierarchical Network Prefix Routes: This is a route 4262 to a particular network prefix. Note that the FIB 4263 may contain several routes to network prefixes that 4264 subsume each other (one prefix is the other prefix 4265 with additional bits). These are selected in order 4266 of decreasing prefix length. 4268 (5) Default Route: This is a route to all networks for 4269 which there are no explicit routes. It is by 4270 definition the route whose prefix length is zero. 4272 If, after application of the pruning rules, the set of 4273 routes is empty (i.e., no routes were found), the packet 4274 MUST be discarded and an appropriate ICMP error 4275 generated (ICMP Bad Source Route if the IP Destination 4276 Address came from a source route option; otherwise, 4277 whichever of ICMP Destination Host Unreachable or 4278 Destination Network Unreachable is appropriate, as 4279 described in Section [4.3.3.1]). 4281 5.2.4.4 Administrative Preference 4283 One suggested mechanism for the Vendor Policy Pruning 4284 Rule is to use administrative preference, which is a 4285 simple prioritization algorithm. The idea is to 4286 manually prioritize the routes that one might need to 4287 select among. 4289 Each route has associated with it a "preference 4290 value", based on various attributes of the route 4292 Draft Requirements for IP Version 4 Routers March 1995 4294 (specific mechanisms for assignment of preference 4295 values are suggested below). This preference value 4296 is an integer in the range [0..255], with zero being 4297 the most preferred and 254 being the least preferred. 4298 255 is a special value that means that the route 4299 should never be used. The first step in the Vendor 4300 Policy pruning rule discards all but the most 4301 preferable routes (and always discards routes whose 4302 preference value is 255). 4304 This policy is not "safe" in that it can easily be 4305 misused to create routing loops. Since no protocol 4306 ensures that the preferences configured for a router 4307 is consistent with the preferences configured in its 4308 neighbors, network managers must exercise care in 4309 configuring preferences. 4311 + Address Match 4312 It is useful to be able to assign a single 4313 preference value to all routes (learned from the 4314 same routing domain) to any of a specified set of 4315 destinations, where the set of destinations is all 4316 destinations that match a specified network 4317 prefix. 4319 + Route Class 4320 For routing protocols which maintain the 4321 distinction, it is useful to be able to assign a 4322 single preference value to all routes (learned 4323 from the same routing domain) which have a 4324 particular route class (intra-area, inter-area, 4325 external with internal metrics, or external with 4326 external metrics). 4328 + Interface 4329 It is useful to be able to assign a single 4330 preference value to all routes (learned from a 4331 particular routing domain) that would cause 4332 packets to be routed out a particular logical 4333 interface on the router (logical interfaces 4334 generally map one-to-one onto the router's network 4335 interfaces, except that any network interface that 4336 has multiple IP addresses will have multiple 4337 logical interfaces associated with it). 4339 Draft Requirements for IP Version 4 Routers March 1995 4341 + Source router 4342 It is useful to be able to assign a single 4343 preference value to all routes (learned from the 4344 same routing domain) that were learned from any of 4345 a set of routers, where the set of routers are 4346 those whose updates have a source address that 4347 match a specified network prefix. 4349 + Originating AS 4350 For routing protocols which provide the 4351 information, it is useful to be able to assign a 4352 single preference value to all routes (learned 4353 from a particular routing domain) which originated 4354 in another particular routing domain. For BGP 4355 routes, the originating AS is the first AS listed 4356 in the route's AS_PATH attribute. For OSPF 4357 external routes, the originating AS may be 4358 considered to be the low order 16 bits of the 4359 route's external route tag if the tag's Automatic 4360 bit is set and the tag's Path Length is not equal 4361 to 3. 4363 + External route tag 4364 It is useful to be able to assign a single 4365 preference value to all OSPF external routes 4366 (learned from the same routing domain) whose 4367 external route tags match any of a list of 4368 specified values. Because the external route tag 4369 may contain a structured value, it may be useful 4370 to provide the ability to match particular 4371 subfields of the tag. 4373 + AS path 4374 It may be useful to be able to assign a single 4375 preference value to all BGP routes (learned from 4376 the same routing domain) whose AS path "matches" 4377 any of a set of specified values. It is not yet 4378 clear exactly what kinds of matches are most 4379 useful. A simple option would be to allow 4380 matching of all routes for which a particular AS 4381 number appears (or alternatively, does not appear) 4382 anywhere in the route's AS_PATH attribute. A more 4383 general but somewhat more difficult alternative 4384 would be to allow matching all routes for which 4386 Draft Requirements for IP Version 4 Routers March 1995 4388 the AS path matches a specified regular 4389 expression. 4391 5.2.4.6 Load Splitting 4393 At the end of the Next-hop selection process, 4394 multiple routes may still remain. A router has 4395 several options when this occurs. It may arbitrarily 4396 discard some of the routes. It may reduce the number 4397 of candidate routes by comparing metrics of routes 4398 from routing domains that are not considered 4399 equivalent. It may retain more than one route and 4400 employ a "load-splitting" mechanism to divide traffic 4401 among them. Perhaps the only thing that can be said 4402 about the relative merits of the options is that 4403 load-splitting is useful in some situations but not 4404 in others, so a wise implementor who implements 4405 load-splitting will also provide a way for the 4406 network manager to disable it. 4408 5.2.5 Unused IP Header Bits: RFC-791 Section 3.1 4410 The IP header contains several reserved bits, in the 4411 Type of Service field and in the Flags field. Routers 4412 MUST NOT drop packets merely because one or more of 4413 these reserved bits has a non-zero value. 4415 Routers MUST ignore and MUST pass through unchanged the 4416 values of these reserved bits. If a router fragments a 4417 packet, it MUST copy these bits into each fragment. 4419 DISCUSSION: 4420 Future revisions to the IP protocol may make use of 4421 these unused bits. These rules are intended to 4422 ensure that these revisions can be deployed without 4423 having to simultaneously upgrade all routers in the 4424 Internet. 4426 Draft Requirements for IP Version 4 Routers March 1995 4428 5.2.6 Fragmentation and Reassembly: RFC-791 Section 3.2 4430 As was discussed in Section [4.2.2.7], a router MUST 4431 support IP fragmentation. 4433 A router MUST NOT reassemble any datagram before 4434 forwarding it. 4436 DISCUSSION: 4437 A few people have suggested that there might be some 4438 topologies where reassembly of transit datagrams by 4439 routers might improve performance. The fact that 4440 fragments may take different paths to the destination 4441 precludes safe use of such a feature. 4443 Nothing in this section should be construed to 4444 control or limit fragmentation or reassembly 4445 performed as a link layer function by the router. 4447 Similarly, if an IP datagram is encapsulated in 4448 another IP datagram (e.g., it is tunnelled), that 4449 datagram is in turn fragmented, the fragments must be 4450 reassembled in order to forward the original 4451 datagram. This section does not preclude this. 4453 5.2.7 Internet Control Message Protocol - ICMP 4455 General requirements for ICMP were discussed in Section 4456 [4.3]. This section discusses ICMP messages that are 4457 sent only by routers. 4459 5.2.7.1 Destination Unreachable 4461 The ICMP Destination Unreachable message is sent by a 4462 router in response to a packet which it cannot 4463 forward because the destination (or next hop) is 4464 unreachable or a service is unavailable. Examples of 4465 such cases include a message addressed to a host 4466 which is not there and therefore does not respond to 4467 ARP requests, and messages addressed to network 4469 Draft Requirements for IP Version 4 Routers March 1995 4471 prefixes for which the router has no valid route. 4473 A router MUST be able to generate ICMP Destination 4474 Unreachable messages and SHOULD choose a response 4475 code that most closely matches the reason the message 4476 is being generated. 4478 The following codes are defined in [INTERNET:8] and 4479 [INTRO:2]: 4481 0 = Network Unreachable - generated by a router if a 4482 forwarding path (route) to the destination 4483 network is not available; 4485 1 = Host Unreachable - generated by a router if a 4486 forwarding path (route) to the destination host 4487 on a directly connected network is not available 4488 (does not respond to ARP); 4490 2 = Protocol Unreachable - generated if the transport 4491 protocol designated in a datagram is not 4492 supported in the transport layer of the final 4493 destination; 4495 3 = Port Unreachable - generated if the designated 4496 transport protocol (e.g., UDP) is unable to 4497 demultiplex the datagram in the transport layer 4498 of the final destination but has no protocol 4499 mechanism to inform the sender; 4501 4 = Fragmentation Needed and DF Set - generated if a 4502 router needs to fragment a datagram but cannot 4503 since the DF flag is set; 4505 5 = Source Route Failed - generated if a router 4506 cannot forward a packet to the next hop in a 4507 source route option; 4509 6 = Destination Network Unknown - This code SHOULD 4510 NOT be generated since it would imply on the 4511 part of the router that the destination network 4512 does not exist (net unreachable code 0 SHOULD be 4513 used in place of code 6); 4515 Draft Requirements for IP Version 4 Routers March 1995 4517 7 = Destination Host Unknown - generated only when a 4518 router can determine (from link layer advice) 4519 that the destination host does not exist; 4521 11 = Network Unreachable For Type Of Service - 4522 generated by a router if a forwarding path 4523 (route) to the destination network with the 4524 requested or default TOS is not available; 4526 12 = Host Unreachable For Type Of Service - generated 4527 if a router cannot forward a packet because its 4528 route(s) to the destination do not match either 4529 the TOS requested in the datagram or the default 4530 TOS (0). 4532 The following additional codes are hereby defined: 4534 13 = Communication Administratively Prohibited - 4535 generated if a router cannot forward a packet 4536 due to administrative filtering; 4538 14 = Host Precedence Violation. Sent by the first 4539 hop router to a host to indicate that a 4540 requested precedence is not permitted for the 4541 particular combination of source/destination 4542 host or network, upper layer protocol, and 4543 source/destination port; 4545 15 = Precedence cutoff in effect. The network 4546 operators have imposed a minimum level of 4547 precedence required for operation, the datagram 4548 was sent with a precedence below this level; 4550 NOTE: [INTRO:2] defined Code 8 for "source host 4551 isolated". Routers SHOULD NOT generate Code 8; 4552 whichever of Codes 0 (Network Unreachable) and 1 4553 (Host Unreachable) is appropriate SHOULD be used 4554 instead. [INTRO:2] also defined Code 9 for 4555 communication with destination network 4556 administratively prohibited and Code 10 for 4557 communication with destination host administratively 4558 prohibited. These codes were intended for use by 4559 end-to-end encryption devices used by U.S military 4560 agencies. Routers SHOULD use the newly defined Code 4562 Draft Requirements for IP Version 4 Routers March 1995 4564 13 (Communication Administratively Prohibited) if 4565 they administratively filter packets. 4567 Routers MAY have a configuration option that causes 4568 Code 13 (Communication Administratively Prohibited) 4569 messages not to be generated. When this option is 4570 enabled, no ICMP error message is sent in response to 4571 a packet that is dropped because its forwarding is 4572 administratively prohibited. 4574 Similarly, routers MAY have a configuration option 4575 that causes Code 14 (Host Precedence Violation) and 4576 Code 15 (Precedence Cutoff in Effect) messages not to 4577 be generated. When this option is enabled, no ICMP 4578 error message is sent in response to a packet that is 4579 dropped because of a precedence violation. 4581 Routers MUST use Host Unreachable or Destination Host 4582 Unknown codes whenever other hosts on the same 4583 destination network might be reachable; otherwise, 4584 the source host may erroneously conclude that all 4585 hosts on the network are unreachable, and that may 4586 not be the case. 4588 [INTERNET:14] describes a slight modification the 4589 form of Destination Unreachable messages containing 4590 Code 4 (Fragmentation needed and DF set). A router 4591 MUST use this modified form when originating Code 4 4592 Destination Unreachable messages. 4594 5.2.7.2 Redirect 4596 The ICMP Redirect message is generated to inform a 4597 local host the it should use a different next hop 4598 router for a certain class of traffic. 4600 Routers MUST NOT generate the Redirect for Network or 4601 Redirect for Network and Type of Service messages 4602 (Codes 0 and 2) specified in [INTERNET:8]. Routers 4603 MUST be able to generate the Redirect for Host 4604 message (Code 1) and SHOULD be able to generate the 4605 Redirect for Type of Service and Host message (Code 4606 3) specified in [INTERNET:8]. 4608 Draft Requirements for IP Version 4 Routers March 1995 4610 DISCUSSION: 4611 If the directly connected network is not subnetted 4612 (in the classical sense), a router can normally 4613 generate a network Redirect that applies to all 4614 hosts on a specified remote network. Using a 4615 network rather than a host Redirect may economize 4616 slightly on network traffic and on host routing 4617 table storage. However, the savings are not 4618 significant, and subnets create an ambiguity about 4619 the subnet mask to be used to interpret a network 4620 Redirect. In a CIDR environment, it is difficult 4621 to specify precisely the cases in which network 4622 Redirects can be used. Therefore, routers must 4623 send only host (or host and type of service) 4624 Redirects. 4626 A Code 3 (Redirect for Host and Type of Service) 4627 message is generated when the packet provoking the 4628 redirect has a destination for which the path chosen 4629 by the router would depend (in part) on the TOS 4630 requested. 4632 Routers that can generate Code 3 redirects (Host and 4633 Type of Service) MUST have a configuration option 4634 (which defaults to on) to enable Code 1 (Host) 4635 redirects to be substituted for Code 3 redirects. A 4636 router MUST send a Code 1 Redirect in place of a Code 4637 3 Redirect if it has been configured to do so. 4639 If a router is not able to generate Code 3 Redirects 4640 then it MUST generate Code 1 Redirects in situations 4641 where a Code 3 Redirect is called for. 4643 Routers MUST NOT generate a Redirect Message unless 4644 all the following conditions are met: 4646 + The packet is being forwarded out the same physical 4647 interface that it was received from, 4649 + The IP source address in the packet is on the same 4650 Logical IP (sub)network as the next-hop IP 4651 address, and 4653 + The packet does not contain an IP source route 4655 Draft Requirements for IP Version 4 Routers March 1995 4657 option. 4659 The source address used in the ICMP Redirect MUST 4660 belong to the same logical (sub)net as the 4661 destination address. 4663 A router using a routing protocol (other than static 4664 routes) MUST NOT consider paths learned from ICMP 4665 Redirects when forwarding a packet. If a router is 4666 not using a routing protocol, a router MAY have a 4667 configuration that, if set, allows the router to 4668 consider routes learned through ICMP Redirects when 4669 forwarding packets. 4671 DISCUSSION: 4672 ICMP Redirect is a mechanism for routers to convey 4673 routing information to hosts. Routers use other 4674 mechanisms to learn routing information, and 4675 therefore have no reason to obey redirects. 4676 Believing a redirect which contradicted the 4677 router's other information would likely create 4678 routing loops. 4680 On the other hand, when a router is not acting as 4681 a router, it MUST comply with the behavior 4682 required of a host. 4684 5.2.7.3 Time Exceeded 4686 A router MUST generate a Time Exceeded message Code 0 4687 (In Transit) when it discards a packet due to an 4688 expired TTL field. A router MAY have a per-interface 4689 option to disable origination of these messages on 4690 that interface, but that option MUST default to 4691 allowing the messages to be originated. 4693 5.2.8 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP 4695 IGMP [INTERNET:4] is a protocol used between hosts and 4696 multicast routers on a single physical network to 4697 establish hosts' membership in particular multicast 4699 Draft Requirements for IP Version 4 Routers March 1995 4701 groups. Multicast routers use this information, in 4702 conjunction with a multicast routing protocol, to 4703 support IP multicast forwarding across the Internet. 4705 A router SHOULD implement the multicast router part of 4706 IGMP. 4708 5.3 SPECIFIC ISSUES 4710 5.3.1 Time to Live (TTL) 4712 The Time-to-Live (TTL) field of the IP header is defined 4713 to be a timer limiting the lifetime of a datagram. It 4714 is an 8-bit field and the units are seconds. Each 4715 router (or other module) that handles a packet MUST 4716 decrement the TTL by at least one, even if the elapsed 4717 time was much less than a second. Since this is very 4718 often the case, the TTL is effectively a hop count limit 4719 on how far a datagram can propagate through the 4720 Internet. 4722 When a router forwards a packet, it MUST reduce the TTL 4723 by at least one. If it holds a packet for more than one 4724 second, it MAY decrement the TTL by one for each second. 4726 If the TTL is reduced to zero (or less), the packet MUST 4727 be discarded, and if the destination is not a multicast 4728 address the router MUST send an ICMP Time Exceeded 4729 message, Code 0 (TTL Exceeded in Transit) message to the 4730 source. Note that a router MUST NOT discard an IP 4731 unicast or broadcast packet with a non-zero TTL merely 4732 because it can predict that another router on the path 4733 to the packet's final destination will decrement the TTL 4734 to zero. However, a router MAY do so for IP multicasts, 4735 in order to more efficiently implement IP multicast's 4736 expanding ring search algorithm (see [INTERNET:4]). 4738 DISCUSSION: 4739 The IP TTL is used, somewhat schizophrenically, as 4740 both a hop count limit and a time limit. Its hop 4741 count function is critical to ensuring that routing 4743 Draft Requirements for IP Version 4 Routers March 1995 4745 problems can't melt down the network by causing 4746 packets to loop infinitely in the network. The time 4747 limit function is used by transport protocols such as 4748 TCP to ensure reliable data transfer. Many current 4749 implementations treat TTL as a pure hop count, and in 4750 parts of the Internet community there is a strong 4751 sentiment that the time limit function should instead 4752 be performed by the transport protocols that need it. 4754 In this specification, we have reluctantly decided to 4755 follow the strong belief among the router vendors 4756 that the time limit function should be optional. 4757 They argued that implementation of the time limit 4758 function is difficult enough that it is currently not 4759 generally done. They further pointed to the lack of 4760 documented cases where this shortcut has caused TCP 4761 to corrupt data (of course, we would expect the 4762 problems created to be rare and difficult to 4763 reproduce, so the lack of documented cases provides 4764 little reassurance that there haven't been a number 4765 of undocumented cases). 4767 IP multicast notions such as the expanding ring 4768 search may not work as expected unless the TTL is 4769 treated as a pure hop count. The same thing is 4770 somewhat true of traceroute. 4772 ICMP Time Exceeded messages are required because the 4773 traceroute diagnostic tool depends on them. 4775 Thus, the tradeoff is between severely crippling, if 4776 not eliminating, two very useful tools and avoiding a 4777 very rare and transient data transport problem that 4778 may not occur at all. We have chosen to preserve the 4779 tools. 4781 5.3.2 Type of Service (TOS) 4783 The "Type-of-Service" byte in the IP header is divided 4784 into three sections: the Precedence field (high-order 3 4785 bits), a field that is customarily called "Type of 4786 Service" or "TOS" (next 4 bits), and a reserved bit (the 4788 Draft Requirements for IP Version 4 Routers March 1995 4790 low order bit). Rules governing the reserved bit were 4791 described in Section [4.2.2.3]. The Precedence field 4792 will be discussed in Section [5.3.3]. A more extensive 4793 discussion of the TOS field and its use can be found in 4794 [ROUTE:11]. 4796 A router SHOULD consider the TOS field in a packet's IP 4797 header when deciding how to forward it. The remainder 4798 of this section describes the rules that apply to 4799 routers that conform to this requirement. 4801 A router MUST maintain a TOS value for each route in its 4802 routing table. Routes learned through a routing 4803 protocol that does not support TOS MUST be assigned a 4804 TOS of zero (the default TOS). 4806 To choose a route to a destination, a router MUST use an 4807 algorithm equivalent to the following: 4809 (1) The router locates in its routing table all 4810 available routes to the destination (see Section 4811 [5.2.4]). 4813 (2) If there are none, the router drops the packet 4814 because the destination is unreachable. See 4815 section [5.2.4]. 4817 (3) If one or more of those routes have a TOS that 4818 exactly matches the TOS specified in the packet, 4819 the router chooses the route with the best metric. 4821 (4) Otherwise, the router repeats the above step, except 4822 looking at routes whose TOS is zero. 4824 (5) If no route was chosen above, the router drops the 4825 packet because the destination is unreachable. The 4826 router returns an ICMP Destination Unreachable 4827 error specifying the appropriate code: either 4828 Network Unreachable with Type of Service (code 11) 4829 or Host Unreachable with Type of Service (code 12). 4831 DISCUSSION: 4832 Although TOS has been little used in the past, its 4833 use by hosts is now mandated by the Requirements for 4835 Draft Requirements for IP Version 4 Routers March 1995 4837 Internet Hosts RFCs ([INTRO:2] and [INTRO:3]). 4838 Support for TOS in routers may become a MUST in the 4839 future, but is a SHOULD for now until we get more 4840 experience with it and can better judge both its 4841 benefits and its costs. 4843 Various people have proposed that TOS should affect 4844 other aspects of the forwarding function. For 4845 example: 4847 (1) A router could place packets that have the "Low 4848 Delay" bit set ahead of other packets in its 4849 output queues. 4851 (2) a router is forced to discard packets, it could 4852 try to avoid discarding those which have the 4853 "High Reliability" bit set. 4855 These ideas have been explored in more detail in 4856 [INTERNET:17] but we don't yet have enough experience 4857 with such schemes to make requirements in this area. 4859 5.3.3 IP Precedence 4861 This section specifies requirements and guidelines for 4862 appropriate processing of the IP Precedence field in 4863 routers. Precedence is a scheme for allocating 4864 resources in the network based on the relative 4865 importance of different traffic flows. The IP 4866 specification defines specific values to be used in this 4867 field for various types of traffic. 4869 The basic mechanisms for precedence processing in a 4870 router are preferential resource allocation, including 4871 both precedence-ordered queue service and precedence- 4872 based congestion control, and selection of Link Layer 4873 priority features. The router also selects the IP 4874 precedence for routing, management and control traffic 4875 it originates. For a more extensive discussion of IP 4876 Precedence and its implementation see [FORWARD:6]. 4878 Precedence-ordered queue service, as discussed in this 4880 Draft Requirements for IP Version 4 Routers March 1995 4882 section, includes but is not limited to the queue for 4883 the forwarding process and queues for outgoing links. 4884 It is intended that a router supporting precedence 4885 should also use the precedence indication at whatever 4886 points in its processing are concerned with allocation 4887 of finite resources, such as packet buffers or Link 4888 Layer connections. The set of such points is 4889 implementation-dependent. 4891 DISCUSSION: 4892 Although the Precedence field was originally provided 4893 for use in DOD systems where large traffic surges or 4894 major damage to the network are viewed as inherent 4895 threats, it has useful applications for many non- 4896 military IP networks. Although the traffic handling 4897 capacity of networks has grown greatly in recent 4898 years, the traffic generating ability of the users 4899 has also grown, and network overload conditions still 4900 occur at times. Since IP-based routing and 4901 management protocols have become more critical to the 4902 successful operation of the Internet, overloads 4903 present two additional risks to the network: 4905 (1) High delays may result in routing protocol 4906 packets being lost. This may cause the routing 4907 protocol to falsely deduce a topology change and 4908 propagate this false information to other 4909 routers. Not only can this cause routes to 4910 oscillate, but an extra processing burden may be 4911 placed on other routers. 4913 (2) High delays may interfere with the use of network 4914 management tools to analyze and perhaps correct 4915 or relieve the problem in the network that 4916 caused the overload condition to occur. 4918 Implementation and appropriate use of the Precedence 4919 mechanism alleviates both of these problems. 4921 Draft Requirements for IP Version 4 Routers March 1995 4923 5.3.3.1 Precedence-Ordered Queue Service 4925 Routers SHOULD implement precedence-ordered queue 4926 service. Precedence-ordered queue service means that 4927 when a packet is selected for output on a (logical) 4928 link, the packet of highest precedence that has been 4929 queued for that link is sent. Routers that implement 4930 precedence-ordered queue service MUST also have a 4931 configuration option to suppress precedence-ordered 4932 queue service in the Internet Layer. 4934 Any router MAY implement other policy-based 4935 throughput management procedures that result in other 4936 than strict precedence ordering, but it MUST be 4937 configurable to suppress them (i.e., use strict 4938 ordering). 4940 As detailed in Section [5.3.6], routers that 4941 implement precedence-ordered queue service discard 4942 low precedence packets before discarding high 4943 precedence packets for congestion control purposes. 4945 Preemption (interruption of processing or 4946 transmission of a packet) is not envisioned as a 4947 function of the Internet Layer. Some protocols at 4948 other layers may provide preemption features. 4950 5.3.3.2 Lower Layer Precedence Mappings 4952 Routers that implement precedence-ordered queuing 4953 MUST IMPLEMENT, and other routers SHOULD IMPLEMENT, 4954 Lower Layer Precedence Mapping. 4956 A router that implements Lower Layer Precedence 4957 Mapping: 4959 + MUST be able to map IP Precedence to Link Layer 4960 priority mechanisms for link layers that have such 4961 a feature defined. 4963 + MUST have a configuration option to select the Link 4964 Layer's default priority treatment for all IP 4965 traffic 4967 Draft Requirements for IP Version 4 Routers March 1995 4969 + SHOULD be able to configure specific nonstandard 4970 mappings of IP precedence values to Link Layer 4971 priority values for each interface. 4973 DISCUSSION: 4974 Some research questions the workability of the 4975 priority features of some Link Layer protocols, 4976 and some networks may have faulty implementations 4977 of the link layer priority mechanism. It seems 4978 prudent to provide an escape mechanism in case 4979 such problems show up in a network. 4981 On the other hand, there are proposals to use 4982 novel queuing strategies to implement special 4983 services such as multimedia bandwidth reservation 4984 or low-delay service. Special services and 4985 queuing strategies to support them are current 4986 research subjects and are in the process of 4987 standardization. 4989 Implementors may wish to consider that correct 4990 link layer mapping of IP precedence is required by 4991 DOD policy for TCP/IP systems used on DOD 4992 networks. Since these requirements are intended 4993 to encourage (but not force) the use of precedence 4994 features in the hope of providing better Internet 4995 service to all users, routers supporting 4996 precedence-ordered queue service should default to 4997 maintaining strict precedence ordering regardless 4998 of the type of service requested. 5000 5.3.3.3 Precedence Handling For All Routers 5002 A router (whether or not it employs precedence- 5003 ordered queue service): 5005 (1) MUST accept and process incoming traffic of all 5006 precedence levels normally, unless it has been 5007 administratively configured to do otherwise. 5009 (2) MAY implement a validation filter to 5010 administratively restrict the use of precedence 5012 Draft Requirements for IP Version 4 Routers March 1995 5014 levels by particular traffic sources. If 5015 provided, this filter MUST NOT filter out or cut 5016 off the following sorts of ICMP error messages: 5017 Destination Unreachable, Redirect, Time 5018 Exceeded, and Parameter Problem. If this filter 5019 is provided, the procedures required for packet 5020 filtering by addresses are required for this 5021 filter also. 5023 DISCUSSION: 5024 Precedence filtering should be applicable to 5025 specific source/destination IP Address pairs, 5026 specific protocols, specific ports, and so 5027 on. 5029 An ICMP Destination Unreachable message with 5030 code 14 SHOULD be sent when a packet is dropped 5031 by the validation filter, unless this has been 5032 suppressed by configuration choice. 5034 (3) MAY implement a cutoff function that allows the 5035 router to be set to refuse or drop traffic with 5036 precedence below a specified level. This 5037 function may be activated by management actions 5038 or by some implementation dependent heuristics, 5039 but there MUST be a configuration option to 5040 disable any heuristic mechanism that operates 5041 without human intervention. An ICMP Destination 5042 Unreachable message with code 15 SHOULD be sent 5043 when a packet is dropped by the cutoff function, 5044 unless this has been suppressed by configuration 5045 choice. 5047 A router MUST NOT refuse to forward datagrams 5048 with IP precedence of 6 (Internetwork Control) 5049 or 7 (Network Control) solely due to precedence 5050 cutoff. However, other criteria may be used in 5051 conjunction with precedence cutoff to filter 5052 high precedence traffic. 5054 DISCUSSION: 5055 Unrestricted precedence cutoff could result 5056 in an unintentional cutoff of routing and 5057 control traffic. In the general case, host 5059 Draft Requirements for IP Version 4 Routers March 1995 5061 traffic should be restricted to a value of 5 5062 (CRITIC/ECP) or below; this is not a 5063 requirement and may not be correct in certain 5064 systems. 5066 (4) MUST NOT change precedence settings on packets it 5067 did not originate. 5069 (5) SHOULD be able to configure distinct precedence 5070 values to be used for each routing or management 5071 protocol supported (except for those protocols, 5072 such as OSPF, which specify which precedence 5073 value must be used). 5075 (6) MAY be able to configure routing or management 5076 traffic precedence values independently for each 5077 peer address. 5079 (7) MUST respond appropriately to Link Layer 5080 precedence-related error indications where 5081 provided. An ICMP Destination Unreachable 5082 message with code 15 SHOULD be sent when a 5083 packet is dropped because a link cannot accept 5084 it due to a precedence-related condition, unless 5085 this has been suppressed by configuration 5086 choice. 5088 DISCUSSION: 5089 The precedence cutoff mechanism described in 5090 (3) is somewhat controversial. Depending on 5091 the topological location of the area affected 5092 by the cutoff, transit traffic may be 5093 directed by routing protocols into the area 5094 of the cutoff, where it will be dropped. 5095 This is only a problem if another path that 5096 is unaffected by the cutoff exists between 5097 the communicating points. Proposed ways of 5098 avoiding this problem include providing some 5099 minimum bandwidth to all precedence levels 5100 even under overload conditions, or 5101 propagating cutoff information in routing 5102 protocols. In the absence of a widely 5103 accepted (and implemented) solution to this 5105 Draft Requirements for IP Version 4 Routers March 1995 5107 problem, great caution is recommended in 5108 activating cutoff mechanisms in transit 5109 networks. 5111 A transport layer relay could legitimately 5112 provide the function prohibited by (4) above. 5113 Changing precedence levels may cause subtle 5114 interactions with TCP and perhaps other 5115 protocols; a correct design is a non-trivial 5116 task. 5118 The intent of (5) and (6) (and the discussion 5119 of IP Precedence in ICMP messages in Section 5120 [4.3.2]) is that the IP precedence bits 5121 should be appropriately set, whether or not 5122 this router acts upon those bits in any other 5123 way. We expect that in the future 5124 specifications for routing protocols and 5125 network management protocols will specify how 5126 the IP Precedence should be set for messages 5127 sent by those protocols. 5129 The appropriate response for (7) depends on 5130 the link layer protocol in use. Typically, 5131 the router should stop trying to send 5132 "offensive" traffic to that destination for 5133 some period of time, and should return an 5134 ICMP Destination Unreachable message with 5135 code 15 (service not available for precedence 5136 requested) to the traffic source. It also 5137 should not try to reestablish a preempted 5138 Link Layer connection for some time. 5140 5.3.4 Forwarding of Link Layer Broadcasts 5142 The encapsulation of IP packets in most Link Layer 5143 protocols (except PPP) allows a receiver to distinguish 5144 broadcasts and multicasts from unicasts simply by 5145 examining the Link Layer protocol headers (most 5146 commonly, the Link Layer destination address). The 5147 rules in this section that refer to "Link Layer 5148 broadcasts" apply only to Link Layer protocols that 5150 Draft Requirements for IP Version 4 Routers March 1995 5152 allow broadcasts to be distinguished; likewise, the 5153 rules that refer to "Link Layer multicasts" apply only 5154 to Link Layer protocols that allow multicasts to be 5155 distinguished. 5157 A router MUST NOT forward any packet that the router 5158 received as a Link Layer broadcast, unless it is 5159 directed to an IP Multicast address. In this latter 5160 case, one would presume that link layer broadcast was 5161 used due to the lack of an effective multicast service. 5163 A router MUST NOT forward any packet which the router 5164 received as a Link Layer multicast unless the packet's 5165 destination address is an IP multicast address. 5167 A router SHOULD silently discard a packet that is 5168 received via a Link Layer broadcast but does not specify 5169 an IP multicast or IP broadcast destination address. 5171 When a router sends a packet as a Link Layer broadcast, 5172 the IP destination address MUST be a legal IP broadcast 5173 or IP multicast address. 5175 5.3.5 Forwarding of Internet Layer Broadcasts 5177 There are two major types of IP broadcast addresses; 5178 limited broadcast and directed broadcast. In addition, 5179 there are three subtypes of directed broadcast: a 5180 broadcast directed to a specified network prefix, a 5181 broadcast directed to a specified subnetwork, and a 5182 broadcast directed to all subnets of a specified 5183 network. Classification by a router of a broadcast into 5184 one of these categories depends on the broadcast address 5185 and on the router's understanding (if any) of the subnet 5186 structure of the destination network. The same 5187 broadcast will be classified differently by different 5188 routers. 5190 A limited IP broadcast address is defined to be all- 5191 ones: { -1, -1 } or 255.255.255.255. 5193 A network-prefix-directed broadcast is composed of the | 5194 network prefix of the IP address with a local part of | 5196 Draft Requirements for IP Version 4 Routers March 1995 5198 all-ones or { , -1 }. For example, a 5199 Class A net broadcast address is net.255.255.255, a 5200 Class B net broadcast address is net.net.255.255 and a 5201 Class C net broadcast address is net.net.net.255 where 5202 "net" is a byte of the network address. 5204 The all-subnets-directed-broadcast is not well defined 5205 in a CIDR environment, and was deprecated in version 1 5206 of this memo. 5208 As was described in Section [4.2.3.1], a router may 5209 encounter certain non-standard IP broadcast addresses: 5211 + 0.0.0.0 is an obsolete form of the limited broadcast 5212 address 5214 + { , 0 } is an obsolete form of a 5215 network-prefix-directed broadcast address. 5217 As was described in that section, packets addressed to 5218 any of these addresses SHOULD be silently discarded, but 5219 if they are not, they MUST be treated according to the 5220 same rules that apply to packets addressed to the non- 5221 obsolete forms of the broadcast addresses described 5222 above. These rules are described in the next few 5223 sections. 5225 5.3.5.1 Limited Broadcasts 5227 Limited broadcasts MUST NOT be forwarded. Limited 5228 broadcasts MUST NOT be discarded. Limited broadcasts 5229 MAY be sent and SHOULD be sent instead of directed 5230 broadcasts where limited broadcasts will suffice. 5232 DISCUSSION: 5233 Some routers contain UDP servers which function by 5234 resending the requests (as unicasts or directed 5235 broadcasts) to other servers. This requirement 5236 should not be interpreted as prohibiting such 5237 servers. Note, however, that such servers can 5238 easily cause packet looping if misconfigured. 5239 Thus, providers of such servers would probably be 5240 well advised to document their setup carefully and 5242 Draft Requirements for IP Version 4 Routers March 1995 5244 to consider carefully the TTL on packets that are 5245 sent. 5247 5.3.5.2 Directed Broadcasts 5249 A router MUST classify as network-prefix-directed | 5250 broadcasts all valid, directed broadcasts destined 5251 for a remote network or an attached nonsubnetted 5252 network. Note that in view of CIDR, such appear to | 5253 be host addresses within the network prefix; we 5254 preclude inspection of the host part of such network 5255 prefixes. Given a route and no overriding policy, | 5256 then, a router MUST forward network-prefix-directed 5257 broadcasts. Network-Prefix-Directed broadcasts MAY 5258 be sent. 5260 A router MAY have an option to disable receiving | 5261 network-prefix-directed broadcasts on an interface | 5262 and MUST have an option to disable forwarding | 5263 network-prefix-directed broadcasts. These options 5264 MUST default to permit receiving and forwarding 5265 network-prefix-directed broadcasts. 5267 DISCUSSION: 5268 There has been some debate about forwarding or not 5269 forwarding directed broadcasts. In this memo we 5270 have made the forwarding decision depend on the 5271 router's knowledge of the destination network 5272 prefix. Routers cannot determine that a message 5273 is unicast or directed broadcast apart from this 5274 knowledge. The decision to forward or not forward 5275 the message is by definition only possible in the 5276 last hop router. 5278 5.3.5.3 All-subnets-directed Broadcasts 5280 The first version of this memo described an algorithm 5281 for distributing a directed broadcast to all the 5282 subnets of a classical network number. This 5283 algorithm was stated to be "broken," and certain 5285 Draft Requirements for IP Version 4 Routers March 1995 5287 failure cases were specified. 5289 In a CIDR routing domain, wherein classical IP 5290 network numbers are meaningless, the concept of an 5291 all-subnets-directed-broadcast is also meaningless. 5292 To the knowledge of the working group, the facility 5293 was never implemented or deployed, and is now 5294 relegated to the dustbin of history. 5296 5.3.5.4 Network-Prefix-Directed Broadcasts 5298 The first version of this memo spelled out procedures 5299 for dealing with network-prefix-directed-broadcasts. 5300 In a CIDR routing domain, these are indistinguishable 5301 from network-prefix-directed-broadcasts. The two are 5302 therefore treated together in section [5.3.5.2 5303 Directed Broadcasts]. 5305 5.3.6 Congestion Control 5307 Congestion in a network is loosely defined as a 5308 condition where demand for resources (usually bandwidth 5309 or CPU time) exceeds capacity. Congestion avoidance 5310 tries to prevent demand from exceeding capacity, while 5311 congestion recovery tries to restore an operative state. 5312 It is possible for a router to contribute to both of 5313 these mechanisms. A great deal of effort has been spent 5314 studying the problem. The reader is encouraged to read 5315 [FORWARD:2] for a survey of the work. Important papers 5316 on the subject include [FORWARD:3], [FORWARD:4], 5317 [FORWARD:5], [FORWARD:10], [FORWARD:11], [FORWARD:12], 5318 [FORWARD:13], [FORWARD:14], and [INTERNET:10], among 5319 others. 5321 The amount of storage that router should have available 5322 to handle peak instantaneous demand when hosts use 5323 reasonable congestion policies, such as described in 5324 [FORWARD:5], is a function of the product of the 5325 bandwidth of the link times the path delay of the flows 5326 using the link, and therefore storage should increase as 5327 this Bandwidth*Delay product increases. The exact 5328 function relating storage capacity to probability of 5330 Draft Requirements for IP Version 4 Routers March 1995 5332 discard is not known. 5334 When a router receives a packet beyond its storage 5335 capacity it must (by definition, not by decree) discard 5336 it or some other packet or packets. Which packet to 5337 discard is the subject of much study but, unfortunately, 5338 little agreement so far. The best wisdom to date 5339 suggests discarding a packet from the data stream most 5340 heavily using the link. However, a number of additional 5341 factors may be relevant, including the precedence of the 5342 traffic, active bandwidth reservation, and the 5343 complexity associated with selecting that packet. 5345 A router MAY discard the packet it has just received; 5346 this is the simplest but not the best policy. Ideally, 5347 the router should select a packet from one of the 5348 sessions most heavily abusing the link, given that the 5349 applicable Quality of Service policy permits this. A 5350 recommended policy in datagram environments using FIFO 5351 queues is to discard a packet randomly selected from the 5352 queue (see [FORWARD:5]). An equivalent algorithm in 5353 routers using fair queues is to discard from the longest | 5354 queue or that using the greatest virtual time (see | 5355 [FORWARD:13]). A router MAY use these algorithms to 5356 determine which packet to discard. 5358 If a router implements a discard policy (such as Random 5359 Drop) under which it chooses a packet to discard from a 5360 pool of eligible packets: 5362 + If precedence-ordered queue service (described in 5363 Section [5.3.3.1]) is implemented and enabled, the 5364 router MUST NOT discard a packet whose IP precedence 5365 is higher than that of a packet that is not 5366 discarded. 5368 + A router MAY protect packets whose IP headers request 5369 the "maximize reliability" TOS, except where doing so 5370 would be in violation of the previous rule. 5372 + A router MAY protect fragmented IP packets, on the 5373 theory that dropping a fragment of a datagram may 5374 increase congestion by causing all fragments of the 5375 datagram to be retransmitted by the source. 5377 Draft Requirements for IP Version 4 Routers March 1995 5379 + To help prevent routing perturbations or disruption of 5380 management functions, the router MAY protect packets 5381 used for routing control, link control, or network 5382 management from being discarded. Dedicated routers 5383 (i.e., routers that are not also general purpose 5384 hosts, terminal servers, etc.) can achieve an 5385 approximation of this rule by protecting packets 5386 whose source or destination is the router itself. 5388 Advanced methods of congestion control include a notion 5389 of fairness, so that the 'user' that is penalized by 5390 losing a packet is the one that contributed the most to 5391 the congestion. No matter what mechanism is implemented 5392 to deal with bandwidth congestion control, it is 5393 important that the CPU effort expended be sufficiently 5394 small that the router is not driven into CPU congestion 5395 also. 5397 As described in Section [4.3.3.3], this document 5398 recommends that a router SHOULD NOT send a Source Quench 5399 to the sender of the packet that it is discarding. ICMP 5400 Source Quench is a very weak mechanism, so it is not 5401 necessary for a router to send it, and host software 5402 should not use it exclusively as an indicator of 5403 congestion. 5405 5.3.7 Martian Address Filtering 5407 An IP source address is invalid if it is a special IP 5408 address, as defined in 4.2.2.11 or 5.3.7, or is not a 5409 unicast address. 5411 An IP destination address is invalid if it is among 5412 those defined as illegal destinations in 4.2.3.1, or is 5413 a Class E address (except 255.255.255.255). 5415 A router SHOULD NOT forward any packet that has an 5416 invalid IP source address or a source address on network 5417 0. A router SHOULD NOT forward, except over a loopback 5418 interface, any packet that has a source address on 5419 network 127. A router MAY have a switch that allows the 5420 network manager to disable these checks. If such a 5421 switch is provided, it MUST default to performing the 5423 Draft Requirements for IP Version 4 Routers March 1995 5425 checks. 5427 A router SHOULD NOT forward any packet that has an 5428 invalid IP destination address or a destination address 5429 on network 0. A router SHOULD NOT forward, except over 5430 a loopback interface, any packet that has a destination 5431 address on network 127. A router MAY have a switch that 5432 allows the network manager to disable these checks. If 5433 such a switch is provided, it MUST default to performing 5434 the checks. 5436 If a router discards a packet because of these rules, it 5437 SHOULD log at least the IP source address, the IP 5438 destination address, and, if the problem was with the 5439 source address, the physical interface on which the 5440 packet was received and the Link Layer address of the 5441 host or router from which the packet was received. 5443 5.3.8 Source Address Validation 5445 A router SHOULD IMPLEMENT the ability to filter traffic 5446 based on a comparison of the source address of a packet 5447 and the forwarding table for a logical interface on 5448 which the packet was received. If this filtering is 5449 enabled, the router MUST silently discard a packet if 5450 the interface on which the packet was received is not 5451 the interface on which a packet would be forwarded to 5452 reach the address contained in the source address. In 5453 simpler terms, if a router wouldn't route a packet 5454 containing this address through a particular interface, 5455 it shouldn't believe the address if it appears as a 5456 source address in a packet read from this interface. 5458 If this feature is implemented, it MUST be disabled by 5459 default. 5461 DISCUSSION: 5462 This feature can provide useful security improvements 5463 in some situations, but can erroneously discard valid 5464 packets in situations where paths are asymmetric. 5466 Draft Requirements for IP Version 4 Routers March 1995 5468 5.3.9 Packet Filtering and Access Lists 5470 As a means of providing security and/or limiting traffic 5471 through portions of a network a router SHOULD provide 5472 the ability to selectively forward (or filter) packets. 5473 If this capability is provided, filtering of packets 5474 SHOULD be configurable either to forward all packets or 5475 to selectively forward them based upon the source and 5476 destination prefixes, and MAY filter on other message 5477 attributes. Each source and destination address SHOULD 5478 allow specification of an arbitrary prefix length. 5480 DISCUSSION: 5481 This feature can provide a measure of privacy, where 5482 systems outside a boundary are not permitted to 5483 exchange certain protocols with systems inside the 5484 boundary, or are limited as to which systems they may 5485 communicate with. It can also help prevent certain 5486 classes of security breach, wherein a system outside 5487 a boundary masquerades as a system inside the 5488 boundary and mimics a session with it. 5490 If supported, a router SHOULD be configurable to allow 5491 one of an 5493 + Include list - specification of a list of message 5494 definitions to be forwarded, or an 5496 + Exclude list - specification of a list of message 5497 definitions NOT to be forwarded. 5499 A "message definition", in this context, specifies the 5500 source and destination network prefix, and may include 5501 other identifying information such as IP Protocol Type 5502 or TCP port number. 5504 A router MAY provide a configuration switch that allows 5505 a choice between specifying an include or an exclude 5506 list, or other equivalent controls. 5508 A value matching any address (e.g., a keyword "any", an 5509 address with a mask of all 0's, or a network prefix 5511 Draft Requirements for IP Version 4 Routers March 1995 5513 whose length is zero) MUST be allowed as a source and/or 5514 destination address. 5516 In addition to address pairs, the router MAY allow any 5517 combination of transport and/or application protocol and 5518 source and destination ports to be specified. 5520 The router MUST allow packets to be silently discarded 5521 (i.e., discarded without an ICMP error message being 5522 sent). 5524 The router SHOULD allow an appropriate ICMP unreachable 5525 message to be sent when a packet is discarded. The ICMP 5526 message SHOULD specify Communication Administratively 5527 Prohibited (code 13) as the reason for the destination 5528 being unreachable. 5530 The router SHOULD allow the sending of ICMP destination 5531 unreachable messages (code 13) to be configured for each 5532 combination of address pairs, protocol types, and ports 5533 it allows to be specified. 5535 The router SHOULD count and SHOULD allow selective 5536 logging of packets not forwarded. 5538 5.3.10 Multicast Routing 5540 An IP router SHOULD support forwarding of IP multicast 5541 packets, based either on static multicast routes or on 5542 routes dynamically determined by a multicast routing 5543 protocol (e.g., DVMRP [ROUTE:9]). A router that 5544 forwards IP multicast packets is called a multicast 5545 router. 5547 5.3.11 Controls on Forwarding 5549 For each physical interface, a router SHOULD have a 5550 configuration option that specifies whether forwarding 5551 is enabled on that interface. When forwarding on an 5552 interface is disabled, the router: 5554 + MUST silently discard any packets which are received 5556 Draft Requirements for IP Version 4 Routers March 1995 5558 on that interface but are not addressed to the router 5560 + MUST NOT send packets out that interface, except for 5561 datagrams originated by the router 5563 + MUST NOT announce via any routing protocols the 5564 availability of paths through the interface 5566 DISCUSSION: 5567 This feature allows the network manager to 5568 essentially turn off an interface but leaves it 5569 accessible for network management. 5571 Ideally, this control would apply to logical rather 5572 than physical interfaces. It cannot, because there 5573 is no known way for a router to determine which 5574 logical interface a packet arrived absent a one-to- 5575 one correspondence between logical and physical 5576 interfaces. 5578 5.3.12 State Changes 5580 During router operation, interfaces may fail or be 5581 manually disabled, or may become available for use by 5582 the router. Similarly, forwarding may be disabled for a 5583 particular interface or for the entire router or may be 5584 (re)enabled. While such transitions are (usually) 5585 uncommon, it is important that routers handle them 5586 correctly. 5588 5.3.12.1 When a Router Ceases Forwarding 5590 When a router ceases forwarding it MUST stop 5591 advertising all routes, except for third party 5592 routes. It MAY continue to receive and use routes 5593 from other routers in its routing domains. If the 5594 forwarding database is retained, the router MUST NOT 5595 cease timing the routes in the forwarding database. 5596 If routes that have been received from other routers 5597 are remembered, the router MUST NOT cease timing the 5598 routes that it has remembered. It MUST discard any 5600 Draft Requirements for IP Version 4 Routers March 1995 5602 routes whose timers expire while forwarding is 5603 disabled, just as it would do if forwarding were 5604 enabled. 5606 DISCUSSION: 5607 When a router ceases forwarding, it essentially 5608 ceases being a router. It is still a host, and 5609 must follow all of the requirements of Host 5610 Requirements [INTRO:2]. The router may still be a 5611 passive member of one or more routing domains, 5612 however. As such, it is allowed to maintain its 5613 forwarding database by listening to other routers 5614 in its routing domain. It may not, however, 5615 advertise any of the routes in its forwarding 5616 database, since it itself is doing no forwarding. 5617 The only exception to this rule is when the router 5618 is advertising a route that uses only some other 5619 router, but which this router has been asked to 5620 advertise. 5622 A router MAY send ICMP destination unreachable (host 5623 unreachable) messages to the senders of packets that 5624 it is unable to forward. It SHOULD NOT send ICMP 5625 redirect messages. 5627 DISCUSSION: 5628 Note that sending an ICMP destination unreachable 5629 (host unreachable) is a router action. This 5630 message should not be sent by hosts. This 5631 exception to the rules for hosts is allowed so 5632 that packets may be rerouted in the shortest 5633 possible time, and so that "black holes" are 5634 avoided. 5636 5.3.12.2 When a Router Starts Forwarding 5638 When a router begins forwarding, it SHOULD expedite 5639 the sending of new routing information to all routers 5640 with which it normally exchanges routing information. 5642 Draft Requirements for IP Version 4 Routers March 1995 5644 5.3.12.3 When an Interface Fails or is Disabled 5646 If an interface fails or is disabled a router MUST 5647 remove and stop advertising all routes in its 5648 forwarding database that make use of that interface. 5649 It MUST disable all static routes that make use of 5650 that interface. If other routes to the same 5651 destination and TOS are learned or remembered by the 5652 router, the router MUST choose the best alternate, 5653 and add it to its forwarding database. The router 5654 SHOULD send ICMP destination unreachable or ICMP 5655 redirect messages, as appropriate, in reply to all 5656 packets that it is unable to forward due to the 5657 interface being unavailable. 5659 5.3.12.4 When an Interface is Enabled 5661 If an interface that had not been available becomes 5662 available, a router MUST reenable any static routes 5663 that use that interface. If routes that would use 5664 that interface are learned by the router, then these 5665 routes MUST be evaluated along with all the other 5666 learned routes, and the router MUST make a decision 5667 as to which routes should be placed in the forwarding 5668 database. The implementor is referred to Chapter 5669 [7], "Application Layer - Routing Protocols" for 5670 further information on how this decision is made. 5672 A router SHOULD expedite the sending of new routing 5673 information to all routers with which it normally 5674 exchanges routing information. 5676 5.3.13 IP Options 5678 Several options, such as Record Route and Timestamp, 5679 contain "slots" into which a router inserts its address 5680 when forwarding the packet. However, each such option 5681 has a finite number of slots, and therefore a router may 5682 find that there is not free slot into which it can 5683 insert its address. No requirement listed below should 5684 be construed as requiring a router to insert its address 5685 into an option that has no remaining slot to insert it 5687 Draft Requirements for IP Version 4 Routers March 1995 5689 into. Section [5.2.5] discusses how a router must 5690 choose which of its addresses to insert into an option. 5692 5.3.13.1 Unrecognized Options 5694 Unrecognized IP options in forwarded packets MUST be 5695 passed through unchanged. 5697 5.3.13.2 Security Option 5699 Some environments require the Security option in 5700 every packet; such a requirement is outside the scope 5701 of this document and the IP standard specification. 5702 Note, however, that the security options described in 5703 [INTERNET:1] and [INTERNET:16] are obsolete. Routers 5704 SHOULD IMPLEMENT the revised security option 5705 described in [INTERNET:5]. 5707 DISCUSSION: 5708 Routers intended for use in networks with multiple 5709 security levels should support packet filtering 5710 based on IPSO (RFC-1108) labels. To implement 5711 this support, the router would need to permit the 5712 router administrator to configure both a lower 5713 sensitivity limit (e.g. Unclassified) and an upper 5714 sensitivity limit (e.g. Secret) on each interface. 5715 It is commonly but not always the case that the 5716 two limits are the same (e.g. a single-level 5717 interface). Packets caught by an IPSO filter as 5718 being out of range should be silently dropped and 5719 a counter should note the number of packets 5720 dropped because of out of range IPSO labels. 5722 5.3.13.3 Stream Identifier Option 5724 This option is obsolete. If the Stream Identifier 5725 option is present in a packet forwarded by the 5726 router, the option MUST be ignored and passed through 5727 unchanged. 5729 Draft Requirements for IP Version 4 Routers March 1995 5731 5.3.13.4 Source Route Options 5733 A router MUST implement support for source route 5734 options in forwarded packets. A router MAY implement 5735 a configuration option that, when enabled, causes all 5736 source-routed packets to be discarded. However, such 5737 an option MUST NOT be enabled by default. 5739 DISCUSSION: 5740 The ability to source route datagrams through the 5741 Internet is important to various network 5742 diagnostic tools. However, source routing may be 5743 used to bypass administrative and security 5744 controls within a network. Specifically, those 5745 cases where manipulation of routing tables is used 5746 to provide administrative separation in lieu of 5747 other methods such as packet filtering may be 5748 vulnerable through source routed packets. 5750 EDITOR'S COMMENTS: 5751 Packet filtering can be defeated by source 5752 routing as well, if it is applied in any router 5753 except one on the final leg of the source 5754 routed path. Neither route nor packet filters 5755 constitute a complete solution for security. 5757 5.3.13.5 Record Route Option 5759 Routers MUST support the Record Route option in 5760 forwarded packets. 5762 A router MAY provide a configuration option that, if 5763 enabled, will cause the router to ignore (i.e., pass 5764 through unchanged) Record Route options in forwarded 5765 packets. If provided, such an option MUST default to 5766 enabling the record-route. This option should not 5767 affect the processing of Record Route options in 5768 datagrams received by the router itself (in 5769 particular, Record Route options in ICMP echo 5770 requests will still be processed according to Section 5771 [4.3.3.6]). 5773 Draft Requirements for IP Version 4 Routers March 1995 5775 DISCUSSION: 5776 There are some people who believe that Record 5777 Route is a security problem because it discloses 5778 information about the topology of the network. 5779 Thus, this document allows it to be disabled. 5781 5.3.13.6 Timestamp Option 5783 Routers MUST support the timestamp option in 5784 forwarded packets. A timestamp value MUST follow the 5785 rules given [INTRO:2]. 5787 If the flags field = 3 (timestamp and prespecified 5788 address), the router MUST add its timestamp if the 5789 next prespecified address matches any of the router's 5790 IP addresses. It is not necessary that the 5791 prespecified address be either the address of the 5792 interface on which the packet arrived or the address 5793 of the interface over which it will be sent. 5795 IMPLEMENTATION: 5796 To maximize the utility of the timestamps 5797 contained in the timestamp option, it is suggested 5798 that the timestamp inserted be, as nearly as 5799 practical, the time at which the packet arrived at 5800 the router. For datagrams originated by the 5801 router, the timestamp inserted should be, as 5802 nearly as practical, the time at which the 5803 datagram was passed to the network layer for 5804 transmission. 5806 A router MAY provide a configuration option which, if 5807 enabled, will cause the router to ignore (i.e., pass 5808 through unchanged) Timestamp options in forwarded 5809 datagrams when the flag word is set to zero 5810 (timestamps only) or one (timestamp and registering 5811 IP address). If provided, such an option MUST 5812 default to off (that is, the router does not ignore 5813 the timestamp). This option should not affect the 5814 processing of Timestamp options in datagrams received 5815 by the router itself (in particular, a router will 5816 insert timestamps into Timestamp options in datagrams 5818 Draft Requirements for IP Version 4 Routers March 1995 5820 received by the router, and Timestamp options in ICMP 5821 echo requests will still be processed according to 5822 Section [4.3.3.6]). 5824 DISCUSSION: 5825 Like the Record Route option, the Timestamp option 5826 can reveal information about a network's topology. 5827 Some people consider this to be a security 5828 concern. 5830 Draft Requirements for IP Version 4 Routers March 1995 5832 6. TRANSPORT LAYER 5834 A router is not required to implement any Transport Layer 5835 protocols except those required to support Application Layer 5836 protocols supported by the router. In practice, this means 5837 that most routers implement both the Transmission Control 5838 Protocol (TCP) and the User Datagram Protocol (UDP). 5840 6.1 USER DATAGRAM PROTOCOL - UDP 5842 The User Datagram Protocol (UDP) is specified in [TRANS:1]. 5844 A router that implements UDP MUST be compliant, and SHOULD 5845 be unconditionally compliant, with the requirements of 5846 [INTRO:2], except that: 5848 + This specification does not specify the interfaces 5849 between the various protocol layers. Thus, a router's 5850 interfaces need not comply with [INTRO:2], except where 5851 compliance is required for proper functioning of 5852 Application Layer protocols supported by the router. 5854 + Contrary to [INTRO:2], an application SHOULD NOT disable 5855 generation of UDP checksums. 5857 DISCUSSION: 5858 Although a particular application protocol may require 5859 that UDP datagrams it receives must contain a UDP 5860 checksum, there is no general requirement that received 5861 UDP datagrams contain UDP checksums. Of course, if a 5862 UDP checksum is present in a received datagram, the 5863 checksum must be verified and the datagram discarded if 5864 the checksum is incorrect. 5866 6.2 TRANSMISSION CONTROL PROTOCOL - TCP 5868 The Transmission Control Protocol (TCP) is specified in 5869 [TRANS:2]. 5871 A router that implements TCP MUST be compliant, and SHOULD 5873 Draft Requirements for IP Version 4 Routers March 1995 5875 be unconditionally compliant, with the requirements of 5876 [INTRO:2], except that: 5878 + This specification does not specify the interfaces 5879 between the various protocol layers. Thus, a router 5880 need not comply with the following requirements of 5881 [INTRO:2] (except of course where compliance is required 5882 for proper functioning of Application Layer protocols 5883 supported by the router): 5885 Use of Push: RFC-793 Section 2.8: 5886 "Passing a received PSH flag to the application 5887 layer is now OPTIONAL." 5889 Urgent Pointer: RFC-793 Section 3.1: 5890 "A TCP MUST inform the application layer 5891 asynchronously whenever it receives an Urgent 5892 pointer and there was previously no pending urgent 5893 data, or whenever the Urgent pointer advances in 5894 the data stream. There MUST be a way for the 5895 application to learn how much urgent data remains 5896 to be read from the connection, or at least to 5897 determine whether or not more urgent data remains 5898 to be read." 5900 TCP Connection Failures: 5901 "An application MUST be able to set the value for 5902 R2 for a particular connection. For example, an 5903 interactive application might set R2 to 5904 ``infinity,'' giving the user control over when to 5905 disconnect." 5907 TCP Multihoming: 5908 "If an application on a multihomed host does not 5909 specify the local IP address when actively opening 5910 a TCP connection, then the TCP MUST ask the IP 5911 layer to select a local IP address before sending 5912 the (first) SYN. See the function GET_SRCADDR() in 5913 Section 3.4." 5915 IP Options: 5916 "An application MUST be able to specify a source 5917 route when it actively opens a TCP connection, and 5918 this MUST take precedence over a source route 5920 Draft Requirements for IP Version 4 Routers March 1995 5922 received in a datagram." 5924 + For similar reasons, a router need not comply with any of 5925 the requirements of [INTRO:2]. 5927 + The requirements concerning the Maximum Segment Size 5928 Option in [INTRO:2] are amended as follows: a router 5929 that implements the host portion of MTU discovery 5930 (discussed in Section [4.2.3.3] of this memo) uses 536 5931 as the default value of SendMSS only if the path MTU is 5932 unknown; if the path MTU is known, the default value for 5933 SendMSS is the path MTU - 40. 5935 + The requirements concerning the Maximum Segment Size 5936 Option in [INTRO:2] are amended as follows: ICMP 5937 Destination Unreachable codes 11 and 12 are additional 5938 soft error conditions. Therefore, these message MUST 5939 NOT cause TCP to abort a connection. 5941 DISCUSSION: 5942 It should particularly be noted that a TCP 5943 implementation in a router must conform to the following 5944 requirements of [INTRO:2]: 5946 + Providing a configurable TTL. [Time to Live: RFC-793 5947 Section 3.9] 5949 + Providing an interface to configure keep-alive 5950 behavior, if keep-alives are used at all. [TCP 5951 Keep-Alives] 5953 + Providing an error reporting mechanism, and the 5954 ability to manage it. [Asynchronous Reports] 5956 + Specifying type of service. [Type-of-Service] 5958 The general paradigm applied is that if a particular 5959 interface is visible outside the router, then all 5960 requirements for the interface must be followed. For 5961 example, if a router provides a telnet function, then it 5962 will be generating traffic, likely to be routed in the 5963 external networks. Therefore, it must be able to set 5964 the type of service correctly or else the telnet traffic 5965 may not get through. 5967 Draft Requirements for IP Version 4 Routers March 1995 5969 7. APPLICATION LAYER - ROUTING PROTOCOLS 5971 7.1 INTRODUCTION 5973 For technical, managerial, and sometimes political reasons, | 5974 the Internet routing system consists of two components - | 5975 interior routing and exterior routing. The concept of an | 5976 Autonomous System (AS), as define in Section 2.2.4 of this | 5977 document, plays a key role in separating interior from an | 5978 exterior routing, as this concept allows to deliniate the | 5979 set of routers where a change from interior to exterior | 5980 routing occurs. An IP datagram may have to traverse the | 5981 routers of two or more Autonomous Systems to reach its | 5982 destination, and the Autonomous Systems must provide each | 5983 other with topology information to allow such forwarding. 5984 Interior gateway protocols (IGPs) are used to distribute | 5985 routing information within an AS (i.e., intra-AS routing). | 5986 Exterior gateway protocols are used to exchange routing | 5987 information among ASs (i.e., inter-AS routing). | 5989 7.1.1 Routing Security Considerations 5991 Routing is one of the few places where the Robustness 5992 Principle ("be liberal in what you accept") does not 5993 apply. Routers should be relatively suspicious in 5994 accepting routing data from other routing systems. 5996 A router SHOULD provide the ability to rank routing 5997 information sources from "most trustworthy" to "least 5998 trustworthy" and to accept routing information about any 5999 particular destination from the most trustworthy sources 6000 first. This was implicit in the original core/stub 6001 autonomous system routing model using EGP and various 6002 interior routing protocols. It is even more important 6003 with the demise of a central, "trusted" core. 6005 A router SHOULD provide a mechanism to filter out 6006 "obviously invalid" routes (such as those for net 127). 6008 Routers MUST NOT by default redistribute routing data 6010 Draft Requirements for IP Version 4 Routers March 1995 6012 they do not themselves use, trust or otherwise consider 6013 valid. In rare cases, it may be necessary to 6014 redistribute suspicious information, but this should 6015 only happen under direct intercession by some human 6016 agency. 6018 Routers must be at least a little paranoid about 6019 accepting routing data from anyone, and must be 6020 especially careful when they distribute routing 6021 information provided to them by another party. See 6022 below for specific guidelines. 6024 7.1.2 Precedence 6026 Except where the specification for a particular routing 6027 protocol specifies otherwise, a router SHOULD set the IP 6028 Precedence value for IP datagrams carrying routing 6029 traffic it originates to 6 (INTERNETWORK CONTROL). 6031 DISCUSSION: 6032 Routing traffic with VERY FEW exceptions should be 6033 the highest precedence traffic on any network. If a 6034 system's routing traffic can't get through, chances 6035 are nothing else will. 6037 7.1.3 Message Validation 6039 Peer-to-peer authentication involves several tests. The 6040 application of message passwords and explicit acceptable 6041 neighbor lists has in the past improved the robustness 6042 of the route database. Routers SHOULD IMPLEMENT 6043 management controls that enable explicit listing of 6044 valid routing neighbors. Routers SHOULD IMPLEMENT 6045 peer-to-peer authentication for those routing protocols 6046 that support them. 6048 Routers SHOULD validate routing neighbors based on their 6049 source address and the interface a message is received 6050 on; neighbors in a directly attached subnet SHOULD be 6051 restricted to communicate with the router via the 6053 Draft Requirements for IP Version 4 Routers March 1995 6055 interface that subnet is posited on or via unnumbered 6056 interfaces. Messages received on other interfaces 6057 SHOULD be silently discarded. 6059 DISCUSSION: 6060 Security breaches and numerous routing problems are 6061 avoided by this basic testing. 6063 7.2 INTERIOR GATEWAY PROTOCOLS 6065 7.2.1 INTRODUCTION 6067 An Interior Gateway Protocol (IGP) is used to distribute 6068 routing information between the various routers in a 6069 particular AS. Independent of the algorithm used to 6070 implement a particular IGP, it should perform the 6071 following functions: 6073 (1) Respond quickly to changes in the internal topology 6074 of an AS 6076 (2) Provide a mechanism such that circuit flapping does 6077 not cause continuous routing updates 6079 (3) Provide quick convergence to loop-free routing 6081 (4) Utilize minimal bandwidth 6083 (5) Provide "equal cost" routes to enable "load- 6084 splitting" 6086 (6) Provide a means for authentication of routing 6087 updates 6089 Current IGPs used in the internet today are 6090 characterized as either being based on a distance-vector 6091 or a link-state algorithm. 6093 Several IGPs are detailed in this section, including 6095 Draft Requirements for IP Version 4 Routers March 1995 6097 those most commonly used and some recently developed 6098 protocols that may be widely used in the future. 6099 Numerous other protocols intended for use in intra-AS 6100 routing exist in the Internet community. 6102 A router that implements any routing protocol (other 6103 than static routes) MUST IMPLEMENT OSPF (see Section 6104 [7.2.2]). A router MAY implement additional IGPs. 6106 7.2.2 OPEN SHORTEST PATH FIRST - OSPF 6108 Shortest Path First (SPF) based routing protocols are a 6109 class of link-state algorithms that are based on the 6110 shortest-path algorithm of Dijkstra. Although SPF based 6111 algorithms have been around since the inception of the 6112 ARPANET, it is only recently that they have achieved 6113 popularity both inside both the IP and the OSI 6114 communities. In an SPF based system, each router 6115 obtains the entire topology database through a process 6116 known as flooding. Flooding insures a reliable transfer 6117 of the information. Each router then runs the SPF 6118 algorithm on its database to build the IP routing table. 6119 The OSPF routing protocol is an implementation of an SPF 6120 algorithm. The current version, OSPF version 2, is 6121 specified in [ROUTE:1]. Note that RFC-1131, which 6122 describes OSPF version 1, is obsolete. 6124 Note that to comply with Section [8.3] of this memo, a 6125 router that implements OSPF MUST implement the OSPF MIB 6126 [MGT:14]. 6128 7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM - DUAL IS- 6129 IS 6131 The American National Standards Institute (ANSI) X3S3.3 6132 committee has defined an intra-domain routing protocol. 6133 This protocol is titled "Intermediate System to 6134 Intermediate System Routeing Exchange Protocol". 6136 Its application to an IP network has been defined in 6137 [ROUTE:2], and is referred to as Dual IS-IS (or 6138 sometimes as Integrated IS-IS). IS-IS is based on a 6140 Draft Requirements for IP Version 4 Routers March 1995 6142 link-state (SPF) routing algorithm and shares all the 6143 advantages for this class of protocols. 6145 7.3 EXTERIOR GATEWAY PROTOCOLS 6147 7.3.1 INTRODUCTION 6149 Exterior Gateway Protocols are utilized for inter- 6150 Autonomous System routing to exchange reachability 6151 information for a set of networks internal to a 6152 particular autonomous system to a neighboring autonomous 6153 system. 6155 The area of inter-AS routing is a current topic of 6156 research inside the Internet Engineering Task Force. 6157 The Exterior Gateway Protocol (EGP) described in Section 6158 [Appendix F.1] has traditionally been the inter-AS 6159 protocol of choice, but is now historical. The Border 6160 Gateway Protocol (BGP) eliminates many of the 6161 restrictions and limitations of EGP, and is therefore 6162 growing rapidly in popularity. A router is not required 6163 to implement any inter-AS routing protocol. However, if 6164 a router does implement EGP it also MUST IMPLEMENT BGP. 6165 Although it was not designed as an exterior gateway 6166 protocol, RIP (described in Section [7.2.4]) is 6167 sometimes used for inter-AS routing. 6169 7.3.2 BORDER GATEWAY PROTOCOL - BGP 6171 7.3.2.1 Introduction 6173 The Border Gateway Protocol (BGP-4) is an inter-AS 6174 routing protocol that exchanges network reachability 6175 information with other BGP speakers. The information 6176 for a network includes the complete list of ASs that 6177 traffic must transit to reach that network. This 6179 Draft Requirements for IP Version 4 Routers March 1995 6181 information can then be used to insure loop-free 6182 paths. This information is sufficient to construct a 6183 graph of AS connectivity from which routing loops may 6184 be pruned and some policy decisions at the AS level 6185 may be enforced. 6187 BGP is defined by [ROUTE:4]. [ROUTE:5] specifies the 6188 proper usage of BGP in the Internet, and provides 6189 some useful implementation hints and guidelines. 6190 [ROUTE:12] and [ROUTE:13] provide additional useful 6191 information. 6193 To comply with Section [8.3] of this memo, a router 6194 that implements BGP is required to implement the BGP 6195 MIB [MGT:15]. 6197 To characterize the set of policy decisions that can 6198 be enforced using BGP, one must focus on the rule 6199 that an AS advertises to its neighbor ASs only those 6200 routes that it itself uses. This rule reflects the 6201 "hop-by-hop" routing paradigm generally used 6202 throughout the current Internet. Note that some 6203 policies cannot be supported by the "hop-by-hop" 6204 routing paradigm and thus require techniques such as 6205 source routing to enforce. For example, BGP does not 6206 enable one AS to send traffic to a neighbor AS 6207 intending that traffic take a different route from 6208 that taken by traffic originating in the neighbor AS. 6209 On the other hand, BGP can support any policy 6210 conforming to the "hop-by-hop" routing paradigm. 6212 Implementors of BGP are strongly encouraged to follow 6213 the recommendations outlined in Section 6 of 6214 [ROUTE:5]. 6216 7.3.2.2 Protocol Walk-through 6218 While BGP provides support for quite complex routing 6219 policies (as an example see Section 4.2 in 6220 [ROUTE:5]), it is not required for all BGP 6221 implementors to support such policies. At a minimum, 6222 however, a BGP implementation: 6224 Draft Requirements for IP Version 4 Routers March 1995 6226 (1) SHOULD allow an AS to control announcements of 6227 the BGP learned routes to adjacent AS's. 6228 Implementations SHOULD support such control with 6229 at least the granularity of a single network. 6230 Implementations SHOULD also support such control 6231 with the granularity of an autonomous system, 6232 where the autonomous system may be either the 6233 autonomous system that originated the route, or 6234 the autonomous system that advertised the route 6235 to the local system (adjacent autonomous 6236 system). 6238 (2) SHOULD allow an AS to prefer a particular path to 6239 a destination (when more than one path is 6240 available). Such function SHOULD be implemented 6241 by allowing system administrator to assign 6242 "weights" to Autonomous Systems, and making 6243 route selection process to select a route with 6244 the lowest "weight" (where "weight" of a route 6245 is defined as a sum of "weights" of all AS's in 6246 the AS_PATH path attribute associated with that 6247 route). 6249 (3) SHOULD allow an AS to ignore routes with certain 6250 AS's in the AS_PATH path attribute. Such 6251 function can be implemented by using technique 6252 outlined in (2), and by assigning "infinity" as 6253 "weights" for such AS's. The route selection 6254 process must ignore routes that have "weight" 6255 equal to "infinity". 6257 7.3.3 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL 6259 It is possible to exchange routing information between 6260 two autonomous systems or routing domains without using 6261 a standard exterior routing protocol between two 6262 separate, standard interior routing protocols. The most 6263 common way of doing this is to run both interior 6264 protocols independently in one of the border routers 6265 with an exchange of route information between the two 6266 processes. 6268 As with the exchange of information from an EGP to an 6270 Draft Requirements for IP Version 4 Routers March 1995 6272 IGP, without appropriate controls these exchanges of 6273 routing information between two IGPs in a single router 6274 are subject to creation of routing loops. 6276 7.4 STATIC ROUTING 6278 Static routing provides a means of explicitly defining the 6279 next hop from a router for a particular destination. A 6280 router SHOULD provide a means for defining a static route 6281 to a destination, where the destination is defined by a 6282 network prefix. The mechanism SHOULD also allow for a 6283 metric to be specified for each static route. 6285 A router that supports a dynamic routing protocol MUST 6286 allow static routes to be defined with any metric valid for 6287 the routing protocol used. The router MUST provide the 6288 ability for the user to specify a list of static routes 6289 that may or may not be propagated through the routing 6290 protocol. In addition, a router SHOULD support the 6291 following additional information if it supports a routing 6292 protocol that could make use of the information. They are: 6294 + TOS, 6296 + Subnet Mask, or 6298 + Prefix Length, or 6300 + A metric specific to a given routing protocol that can 6301 import the route. 6303 DISCUSSION: 6304 We intend that one needs to support only the things 6305 useful to the given routing protocol. The need for TOS 6306 should not require the vendor to implement the other 6307 parts if they are not used. 6309 Whether a router prefers a static route over a dynamic 6310 route (or vice versa) or whether the associated metrics are 6311 used to choose between conflicting static and dynamic 6312 routes SHOULD be configurable for each static route. 6314 A router MUST allow a metric to be assigned to a static 6316 Draft Requirements for IP Version 4 Routers March 1995 6318 route for each routing domain that it supports. Each such 6319 metric MUST be explicitly assigned to a specific routing 6320 domain. For example: 6322 route 10.0.0.0/8 via 192.0.2.3 rip metric 3 | 6324 route 10.21.0.0/16 via 192.0.2.4 ospf inter-area | 6325 metric 27 6327 route 10.22.0.0/16 via 192.0.2.5 egp 123 metric 99 | 6329 DISCUSSION: 6330 It has been suggested that, ideally, static routes 6331 should have preference values rather than metrics (since 6332 metrics can only be compared with metrics of other 6333 routes in the same routing domain, the metric of a 6334 static route could only be compared with metrics of 6335 other static routes). This is contrary to some current 6336 implementations, where static routes really do have 6337 metrics, and those metrics are used to determine whether 6338 a particular dynamic route overrides the static route to 6339 the same destination. Thus, this document uses the term 6340 metric rather than preference. 6342 This technique essentially makes the static route into a 6343 RIP route, or an OSPF route (or whatever, depending on 6344 the domain of the metric). Thus, the route lookup 6345 algorithm of that domain applies. However, this is NOT 6346 route leaking, in that coercing a static route into a 6347 dynamic routing domain does not authorize the router to 6348 redistribute the route into the dynamic routing domain. 6350 For static routes not put into a specific routing 6351 domain, the route lookup algorithm is: 6353 (1) Basic match 6355 (2) Longest match 6357 (3) Weak TOS (if TOS supported) 6359 (4) Best metric (where metric are implementation- 6360 defined) 6362 Draft Requirements for IP Version 4 Routers March 1995 6364 The last step may not be necessary, but it's useful in 6365 the case where you want to have a primary static route 6366 over one interface and a secondary static route over an 6367 alternate interface, with failover to the alternate path 6368 if the interface for the primary route fails. 6370 7.5 FILTERING OF ROUTING INFORMATION 6372 Each router within a network makes forwarding decisions 6373 based upon information contained within its forwarding 6374 database. In a simple network the contents of the database 6375 may be configured statically. As the network grows more 6376 complex, the need for dynamic updating of the forwarding 6377 database becomes critical to the efficient operation of the 6378 network. 6380 If the data flow through a network is to be as efficient as 6381 possible, it is necessary to provide a mechanism for 6382 controlling the propagation of the information a router 6383 uses to build its forwarding database. This control takes 6384 the form of choosing which sources of routing information 6385 should be trusted and selecting which pieces of the 6386 information to believe. The resulting forwarding database 6387 is a filtered version of the available routing information. 6389 In addition to efficiency, controlling the propagation of 6390 routing information can reduce instability by preventing 6391 the spread of incorrect or bad routing information. 6393 In some cases local policy may require that complete 6394 routing information not be widely propagated. 6396 These filtering requirements apply only to non-SPF-based 6397 protocols (and therefore not at all to routers which don't 6398 implement any distance vector protocols). 6400 7.5.1 Route Validation 6402 A router SHOULD log as an error any routing update 6403 advertising a route that violates the specifications of 6404 this memo, unless the routing protocol from which the 6406 Draft Requirements for IP Version 4 Routers March 1995 6408 update was received uses those values to encode special 6409 routes (such as default routes). 6411 7.5.2 Basic Route Filtering 6413 Filtering of routing information allows control of paths 6414 used by a router to forward packets it receives. A 6415 router should be selective in which sources of routing 6416 information it listens to and what routes it believes. 6417 Therefore, a router MUST provide the ability to specify: 6419 + On which logical interfaces routing information will 6420 be accepted and which routes will be accepted from 6421 each logical interface. 6423 + Whether all routes or only a default route is 6424 advertised on a logical interface. 6426 Some routing protocols do not recognize logical 6427 interfaces as a source of routing information. In such 6428 cases the router MUST provide the ability to specify 6430 + from which other routers routing information will be 6431 accepted. 6433 For example, assume a router connecting one or more leaf 6434 networks to the main portion or backbone of a larger 6435 network. Since each of the leaf networks has only one 6436 path in and out, the router can simply send a default 6437 route to them. It advertises the leaf networks to the 6438 main network. 6440 7.5.3 Advanced Route Filtering 6442 As the topology of a network grows more complex, the 6443 need for more complex route filtering arises. 6444 Therefore, a router SHOULD provide the ability to 6445 specify independently for each routing protocol: 6447 + Which logical interfaces or routers routing 6448 information (routes) will be accepted from and which 6449 routes will be believed from each other router or 6451 Draft Requirements for IP Version 4 Routers March 1995 6453 logical interface, 6455 + Which routes will be sent via which logical 6456 interface(s), and 6458 + Which routers routing information will be sent to, if 6459 this is supported by the routing protocol in use. 6461 In many situations it is desirable to assign a 6462 reliability ordering to routing information received 6463 from another router instead of the simple believe or 6464 don't believe choice listed in the first bullet above. 6465 A router MAY provide the ability to specify: 6467 + A reliability or preference to be assigned to each 6468 route received. A route with higher reliability will 6469 be chosen over one with lower reliability regardless 6470 of the routing metric associated with each route. 6472 If a router supports assignment of preferences, the 6473 router MUST NOT propagate any routes it does not prefer 6474 as first party information. If the routing protocol 6475 being used to propagate the routes does not support 6476 distinguishing between first and third party 6477 information, the router MUST NOT propagate any routes it 6478 does not prefer. 6480 DISCUSSION: 6481 For example, assume a router receives a route to 6482 network C from router R and a route to the same 6483 network from router S. If router R is considered 6484 more reliable than router S traffic destined for 6485 network C will be forwarded to router R regardless of 6486 the route received from router S. 6488 Routing information for routes which the router does not 6489 use (router S in the above example) MUST NOT be passed 6490 to any other router. 6492 7.6 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE 6494 Routers MUST be able to exchange routing information 6495 between separate IP interior routing protocols, if 6497 Draft Requirements for IP Version 4 Routers March 1995 6499 independent IP routing processes can run in the same 6500 router. Routers MUST provide some mechanism for avoiding 6501 routing loops when routers are configured for bi- 6502 directional exchange of routing information between two 6503 separate interior routing processes. Routers MUST provide 6504 some priority mechanism for choosing routes from 6505 independent routing processes. Routers SHOULD provide 6506 administrative control of IGP-IGP exchange when used across 6507 administrative boundaries. 6509 Routers SHOULD provide some mechanism for translating or 6510 transforming metrics on a per network basis. Routers (or 6511 routing protocols) MAY allow for global preference of 6512 exterior routes imported into an IGP. 6514 DISCUSSION: 6515 Different IGPs use different metrics, requiring some 6516 translation technique when introducing information from 6517 one protocol into another protocol with a different form 6518 of metric. Some IGPs can run multiple instances within 6519 the same router or set of routers. In this case metric 6520 information can be preserved exactly or translated. 6522 There are at least two techniques for translation 6523 between different routing processes. The static (or 6524 reachability) approach uses the existence of a route 6525 advertisement in one IGP to generate a route 6526 advertisement in the other IGP with a given metric. The 6527 translation or tabular approach uses the metric in one 6528 IGP to create a metric in the other IGP through use of 6529 either a function (such as adding a constant) or a table 6530 lookup. 6532 Bi-directional exchange of routing information is 6533 dangerous without control mechanisms to limit feedback. 6534 This is the same problem that distance vector routing 6535 protocols must address with the split horizon technique 6536 and that EGP addresses with the third-party rule. 6537 Routing loops can be avoided explicitly through use of 6538 tables or lists of permitted/denied routes or implicitly 6539 through use of a split horizon rule, a no-third-party 6540 rule, or a route tagging mechanism. Vendors are 6541 encouraged to use implicit techniques where possible to 6542 make administration easier for network operators. 6544 Draft Requirements for IP Version 4 Routers March 1995 6546 8. APPLICATION LAYER - NETWORK MANAGEMENT PROTOCOLS 6548 Note that this chapter supersedes any requirements stated 6549 under "REMOTE MANAGEMENT" in [INTRO:3]. 6551 8.1 The Simple Network Management Protocol - SNMP 6553 8.1.1 SNMP Protocol Elements 6555 Routers MUST be manageable by SNMP [MGT:3]. The SNMP 6556 MUST operate using UDP/IP as its transport and network 6557 protocols. Others MAY be supported (e.g., see [MGT:25, 6558 MGT:26, MGT:27, and MGT:28]). SNMP management 6559 operations MUST operate as if the SNMP was implemented 6560 on the router itself. Specifically, management 6561 operations MUST be effected by sending SNMP management 6562 requests to any of the IP addresses assigned to any of 6563 the router's interfaces. The actual management 6564 operation may be performed either by the router or by a 6565 proxy for the router. 6567 DISCUSSION: 6568 This wording is intended to allow management either 6569 by proxy, where the proxy device responds to SNMP 6570 packets that have one of the router's IP addresses in 6571 the packets destination address field, or the SNMP is 6572 implemented directly in the router itself and 6573 receives packets and responds to them in the proper 6574 manner. 6576 It is important that management operations can be 6577 sent to one of the router's IP Addresses. In 6578 diagnosing network problems the only thing 6579 identifying the router that is available may be one 6580 of the router's IP address; obtained perhaps by 6581 looking through another router's routing table. 6583 All SNMP operations (get, get-next, get-response, set, 6584 and trap) MUST be implemented. 6586 Routers MUST provide a mechanism for rate-limiting the 6588 Draft Requirements for IP Version 4 Routers March 1995 6590 generation of SNMP trap messages. Routers MAY provide 6591 this mechanism through the algorithms for asynchronous 6592 alert management described in [MGT:5]. 6594 DISCUSSION: 6595 Although there is general agreement about the need to 6596 rate-limit traps, there is not yet consensus on how 6597 this is best achieved. The reference cited is 6598 considered experimental. 6600 8.2 Community Table 6602 For the purposes of this specification, we assume that 6603 there is an abstract `community table' in the router. This 6604 table contains several entries, each entry for a specific 6605 community and containing the parameters necessary to 6606 completely define the attributes of that community. The 6607 actual implementation method of the abstract community 6608 table is, of course, implementation specific. 6610 A router's community table MUST allow for at least one 6611 entry and SHOULD allow for at least two entries. 6613 DISCUSSION: 6614 A community table with zero capacity is useless. It 6615 means that the router will not recognize any communities 6616 and, therefore, all SNMP operations will be rejected. 6618 Therefore, one entry is the minimal useful size of the 6619 table. Having two entries allows one entry to be 6620 limited to read-only access while the other would have 6621 write capabilities. 6623 Routers MUST allow the user to manually (i.e., without 6624 using SNMP) examine, add, delete and change entries in the 6625 SNMP community table. The user MUST be able to set the 6626 community name or construct a MIB view. The user MUST be 6627 able to configure communities as read-only (i.e., they do 6628 not allow SETs) or read-write (i.e., they do allow SETs). 6630 The user MUST be able to define at least one IP address to 6631 which notifications are sent for each community or MIB 6633 Draft Requirements for IP Version 4 Routers March 1995 6635 view, if traps are used. These addresses SHOULD be 6636 definable on a community or MIB view basis. It SHOULD be 6637 possible to enable or disable notifications on a community 6638 or MIB view basis. 6640 A router SHOULD provide the ability to specify a list of 6641 valid network managers for any particular community. If 6642 enabled, a router MUST validate the source address of the 6643 SNMP datagram against the list and MUST discard the 6644 datagram if its address does not appear. If the datagram 6645 is discarded the router MUST take all actions appropriate 6646 to an SNMP authentication failure. 6648 DISCUSSION: 6649 This is a rather limited authentication system, but 6650 coupled with various forms of packet filtering may 6651 provide some small measure of increased security. 6653 The community table MUST be saved in non-volatile storage. 6655 The initial state of the community table SHOULD contain one 6656 entry, with the community name string "public" and read- 6657 only access. The default state of this entry MUST NOT send 6658 traps. If it is implemented, then this entry MUST remain 6659 in the community table until the administrator changes it 6660 or deletes it. 6662 DISCUSSION: 6663 By default, traps are not sent to this community. Trap 6664 PDUs are sent to unicast IP addresses. This address 6665 must be configured into the router in some manner. 6666 Before the configuration occurs, there is no such 6667 address, so to whom should the trap be sent? Therefore 6668 trap sending to the "public" community defaults to be 6669 disabled. This can, of course, be changed by an 6670 administrative operation once the router is operational. 6672 8.3 Standard MIBS 6674 All MIBS relevant to a router's configuration are to be 6675 implemented. To wit: 6677 Draft Requirements for IP Version 4 Routers March 1995 6679 + The System, Interface, IP, ICMP, and UDP groups of MIB-II 6680 [MGT:2] MUST be implemented. 6682 + The Interface Extensions MIB [MGT:18] MUST be 6683 implemented. 6685 + The IP Forwarding Table MIB [MGT:20] MUST be implemented. 6687 + If the router implements TCP (e.g., for Telnet) then the 6688 TCP group of MIB-II [MGT:2] MUST be implemented. 6690 + If the router implements EGP then the EGP group of MIB-II 6691 [MGT:2] MUST be implemented. 6693 + If the router supports OSPF then the OSPF MIB [MGT:14] 6694 MUST be implemented. 6696 + If the router supports BGP then the BGP MIB [MGT:15] MUST 6697 be implemented. 6699 + If the router has Ethernet, 802.3, or StarLan interfaces 6700 then the Ethernet-Like MIB [MGT:6] MUST be implemented. 6702 + If the router has 802.4 interfaces then the 802.4 MIB 6703 [MGT:7] MUST be implemented. 6705 + If the router has 802.5 interfaces then the 802.5 MIB 6706 [MGT:8] MUST be implemented. 6708 + If the router has FDDI interfaces that implement ANSI SMT 6709 7.3 then the FDDI MIB [MGT:9] MUST be implemented. 6711 + If the router has FDDI interfaces that implement ANSI SMT 6712 6.2 then the FDDI MIB [MGT:29] MUST be implemented. 6714 + If the router has RS-232 interfaces then the RS-232 6715 [MGT:10] MIB MUST be implemented. 6717 + If the router has T1/DS1 interfaces then the T1/DS1 MIB 6718 [MGT:16] MUST be implemented. 6720 + If the router has T3/DS3 interfaces then the T3/DS3 MIB 6721 [MGT:17] MUST be implemented. 6723 Draft Requirements for IP Version 4 Routers March 1995 6725 + If the router has SMDS interfaces then the SMDS Interface 6726 Protocol MIB [MGT:19] MUST be implemented. 6728 + If the router supports PPP over any of its interfaces 6729 then the PPP MIBs [MGT:11], [MGT:12], and [MGT:13] MUST 6730 be implemented. 6732 + If the router supports RIP Version 2 then the RIP Version 6733 2 MIB [MGT:21] MUST be implemented. 6735 + If the router supports X.25 over any of its interfaces 6736 then the X.25 MIBs [MGT:22, MGT:23 and MGT:24] MUST be 6737 implemented. 6739 8.4 Vendor Specific MIBS 6741 The Internet Standard and Experimental MIBs do not cover 6742 the entire range of statistical, state, configuration and 6743 control information that may be available in a network 6744 element. This information is, nevertheless, extremely 6745 useful. Vendors of routers (and other network devices) 6746 generally have developed MIB extensions that cover this 6747 information. These MIB extensions are called Vendor 6748 Specific MIBs. 6750 The Vendor Specific MIB for the router MUST provide access 6751 to all statistical, state, configuration, and control 6752 information that is not available through the Standard and 6753 Experimental MIBs that have been implemented. This 6754 information MUST be available for both monitoring and 6755 control operations. 6757 DISCUSSION: 6758 The intent of this requirement is to provide the ability 6759 to do anything on the router through SNMP that can be 6760 done through a console, and vice versa. A certain 6761 minimal amount of configuration is necessary before SNMP 6762 can operate (e.g., the router must have an IP address). 6763 This initial configuration can not be done through SNMP. 6764 However, once the initial configuration is done, full 6765 capabilities ought to be available through network 6766 management. 6768 Draft Requirements for IP Version 4 Routers March 1995 6770 The vendor SHOULD make available the specifications for all 6771 Vendor Specific MIB variables. These specifications MUST 6772 conform to the SMI [MGT:1] and the descriptions MUST be in 6773 the form specified in [MGT:4]. 6775 DISCUSSION: 6776 Making the Vendor Specific MIB available to the user is 6777 necessary. Without this information the users would not 6778 be able to configure their network management systems to 6779 be able to access the Vendor Specific parameters. These 6780 parameters would then be useless. 6782 The format of the MIB specification is also specified. 6783 Parsers that read MIB specifications and generate the 6784 needed tables for the network management station are 6785 available. These parsers generally understand only the 6786 standard MIB specification format. 6788 8.5 Saving Changes 6790 Parameters altered by SNMP MAY be saved to non-volatile 6791 storage. 6793 DISCUSSION: 6794 Reasons why this "requirement" is a MAY: 6796 + The exact physical nature of non-volatile storage is 6797 not specified in this document. Hence, parameters 6798 may be saved in NVRAM/EEPROM, local floppy or hard 6799 disk, or in some TFTP file server or BOOTP server, 6800 etc. Suppose that this information is in a file that 6801 is retrieved through TFTP. In that case, a change 6802 made to a configuration parameter on the router would 6803 need to be propagated back to the file server holding 6804 the configuration file. Alternatively, the SNMP 6805 operation would need to be directed to the file 6806 server, and then the change somehow propagated to the 6807 router. The answer to this problem does not seem 6808 obvious. 6810 This also places more requirements on the host 6811 holding the configuration information than just 6813 Draft Requirements for IP Version 4 Routers March 1995 6815 having an available TFTP server, so much more that 6816 its probably unsafe for a vendor to assume that any 6817 potential customer will have a suitable host 6818 available. 6820 + The timing of committing changed parameters to non- 6821 volatile storage is still an issue for debate. Some 6822 prefer to commit all changes immediately. Others 6823 prefer to commit changes to non-volatile storage only 6824 upon an explicit command. 6826 Draft Requirements for IP Version 4 Routers March 1995 6828 9. APPLICATION LAYER - MISCELLANEOUS PROTOCOLS 6830 For all additional application protocols that a router 6831 implements, the router MUST be compliant and SHOULD be 6832 unconditionally compliant with the relevant requirements of 6833 [INTRO:3]. 6835 9.1 BOOTP 6837 9.1.1 Introduction 6839 The Bootstrap Protocol (BOOTP) is a UDP/IP-based 6840 protocol that allows a booting host to configure itself 6841 dynamically and without user supervision. BOOTP 6842 provides a means to notify a host of its assigned IP 6843 address, the IP address of a boot server host, and the 6844 name of a file to be loaded into memory and executed 6845 ([APPL:1]). Other configuration information such as the 6846 local prefix length or subnet mask, the local time 6847 offset, the addresses of default routers, and the 6848 addresses of various Internet servers can also be 6849 communicated to a host using BOOTP ([APPL:2]). 6851 9.1.2 BOOTP Relay Agents 6853 In many cases, BOOTP clients and their associated BOOTP 6854 server(s) do not reside on the same IP (sub)network. In 6855 such cases, a third-party agent is required to transfer 6856 BOOTP messages between clients and servers. Such an 6857 agent was originally referred to as a "BOOTP forwarding 6858 agent." However, to avoid confusion with the IP 6859 forwarding function of a router, the name "BOOTP relay 6860 agent" has been adopted instead. 6862 DISCUSSION: 6863 A BOOTP relay agent performs a task that is distinct 6864 from a router's normal IP forwarding function. While 6865 a router normally switches IP datagrams between 6866 networks more-or-less transparently, a BOOTP relay 6867 agent may more properly be thought to receive BOOTP 6869 Draft Requirements for IP Version 4 Routers March 1995 6871 messages as a final destination and then generate new 6872 BOOTP messages as a result. One should resist the 6873 notion of simply forwarding a BOOTP message "straight 6874 through like a regular packet." 6876 This relay-agent functionality is most conveniently 6877 located in the routers that interconnect the clients and 6878 servers (although it may alternatively be located in a 6879 host that is directly connected to the client (sub)net). 6881 A router MAY provide BOOTP relay-agent capability. If 6882 it does, it MUST conform to the specifications in 6883 [APPL:3]. 6885 Section [5.2.3] discussed the circumstances under which 6886 a packet is delivered locally (to the router). All 6887 locally delivered UDP messages whose UDP destination 6888 port number is BOOTPS (67) are considered for special 6889 processing by the router's logical BOOTP relay agent. 6891 Sections [4.2.2.11] and [5.3.7] discussed invalid IP 6892 source addresses. According to these rules, a router 6893 must not forward any received datagram whose IP source 6894 address is 0.0.0.0. However, routers that support a 6895 BOOTP relay agent MUST accept for local delivery to the 6896 relay agent BOOTREQUEST messages whose IP source address 6897 is 0.0.0.0. 6899 Draft Requirements for IP Version 4 Routers March 1995 6901 10. OPERATIONS AND MAINTENANCE 6903 This chapter supersedes any requirements of [INTRO:3] relating 6904 to "Extensions to the IP Module." 6906 Facilities to support operation and maintenance (O&M) 6907 activities form an essential part of any router 6908 implementation. Although these functions do not seem to 6909 relate directly to interoperability, they are essential to the 6910 network manager who must make the router interoperate and must 6911 track down problems when it doesn't. This chapter also 6912 includes some discussion of router initialization and of 6913 facilities to assist network managers in securing and 6914 accounting for their networks. 6916 10.1 Introduction 6918 The following kinds of activities are included under router 6919 O&M: 6921 + Diagnosing hardware problems in the router's processor, 6922 in its network interfaces, or in its connected networks, 6923 modems, or communication lines. 6925 + Installing new hardware 6927 + Installing new software. 6929 + Restarting or rebooting the router after a crash. 6931 + Configuring (or reconfiguring) the router. 6933 + Detecting and diagnosing Internet problems such as 6934 congestion, routing loops, bad IP addresses, black 6935 holes, packet avalanches, and misbehaved hosts. 6937 + Changing network topology, either temporarily (e.g., to 6938 bypass a communication line problem) or permanently. 6940 + Monitoring the status and performance of the routers and 6941 the connected networks. 6943 + Collecting traffic statistics for use in (Inter-)network 6945 Draft Requirements for IP Version 4 Routers March 1995 6947 planning. 6949 + Coordinating the above activities with appropriate 6950 vendors and telecommunications specialists. 6952 Routers and their connected communication lines are often 6953 operated as a system by a centralized O&M organization. 6954 This organization may maintain a (Inter-)network operation 6955 center, or NOC, to carry out its O&M functions. It is 6956 essential that routers support remote control and 6957 monitoring from such a NOC through an Internet path, since 6958 routers might not be connected to the same network as their 6959 NOC. Since a network failure may temporarily preclude 6960 network access, many NOCs insist that routers be accessible 6961 for network management through an alternative means, often 6962 dial-up modems attached to console ports on the routers. 6964 Since an IP packet traversing an internet will often use 6965 routers under the control of more than one NOC, Internet 6966 problem diagnosis will often involve cooperation of 6967 personnel of more than one NOC. In some cases, the same 6968 router may need to be monitored by more than one NOC, but 6969 only if necessary, because excessive monitoring could 6970 impact a router's performance. 6972 The tools available for monitoring at a NOC may cover a 6973 wide range of sophistication. Current implementations 6974 include multi-window, dynamic displays of the entire router 6975 system. The use of AI techniques for automatic problem 6976 diagnosis is proposed for the future. 6978 Router O&M facilities discussed here are only a part of the 6979 large and difficult problem of Internet management. These 6980 problems encompass not only multiple management 6981 organizations, but also multiple protocol layers. For 6982 example, at the current stage of evolution of the Internet 6983 architecture, there is a strong coupling between host TCP 6984 implementations and eventual IP-level congestion in the 6985 router system [OPER:1]. Therefore, diagnosis of congestion 6986 problems will sometimes require the monitoring of TCP 6987 statistics in hosts. There are currently a number of R&D 6988 efforts in progress in the area of Internet management and 6989 more specifically router O&M. These R&D efforts have 6990 already produced standards for router O&M. This is also an 6992 Draft Requirements for IP Version 4 Routers March 1995 6994 area in which vendor creativity can make a significant 6995 contribution. 6997 10.2 Router Initialization 6999 10.2.1 Minimum Router Configuration 7001 There exists a minimum set of conditions that must be 7002 satisfied before a router may forward packets. A router 7003 MUST NOT enable forwarding on any physical interface 7004 unless either: 7006 (1) The router knows the IP address and associated 7007 subnet mask or network prefix length of at least 7008 one logical interface associated with that physical 7009 interface, or 7011 (2) The router knows that the interface is an unnumbered 7012 interface and knows its router-id. 7014 These parameters MUST be explicitly configured: 7016 + A router MUST NOT use factory-configured default 7017 values for its IP addresses, prefix lengths, or 7018 router-id, and 7020 + A router MUST NOT assume that an unconfigured 7021 interface is an unnumbered interface. 7023 DISCUSSION: 7024 There have been instances in which routers have been 7025 shipped with vendor-installed default addresses for 7026 interfaces. In a few cases, this has resulted in 7027 routers advertising these default addresses into 7028 active networks. 7030 Draft Requirements for IP Version 4 Routers March 1995 7032 10.2.2 Address and Prefix Initialization 7034 A router MUST allow its IP addresses and their address 7035 masks or prefix lengths to be statically configured and 7036 saved in non-volatile storage. 7038 A router MAY obtain its IP addresses and their 7039 corresponding address masks dynamically as a side effect 7040 of the system initialization process (see Section 7041 10.2.3]); 7043 If the dynamic method is provided, the choice of method 7044 to be used in a particular router MUST be configurable. 7046 As was described in Section [4.2.2.11], IP addresses are 7047 not permitted to have the value 0 or -1 in the or fields. Therefore, a router 7049 SHOULD NOT allow an IP address or address mask to be set 7050 to a value that would make any of the these fields above 7051 have the value zero or -1. 7053 DISCUSSION: 7054 It is possible using arbitrary address masks to 7055 create situations in which routing is ambiguous 7056 (i.e., two routes with different but equally specific 7057 subnet masks match a particular destination address). 7058 This is one of the strongest arguments for the use of 7059 network prefixes, and the reason the use of 7060 discontiguous subnet masks is not permitted. 7062 A router SHOULD make the following checks on any address 7063 mask it installs: 7065 + The mask is neither all ones nor all zeroes (the 7066 prefix length is neither zero nor 32). 7068 + The bits which correspond to the network prefix part 7069 of the address are all set to 1. 7071 + The bits that correspond to the network prefix are 7072 contiguous. 7074 DISCUSSION: 7076 Draft Requirements for IP Version 4 Routers March 1995 7078 The masks associated with routes are also sometimes 7079 called "subnet masks", this test should not be 7080 applied to them. 7082 10.2.3 Network Booting using BOOTP and TFTP 7084 There has been much discussion of how routers can and 7085 should be booted from the network. These discussions 7086 have revolved around BOOTP and TFTP. Currently, there 7087 are routers that boot with TFTP from the network. There 7088 is no reason that BOOTP could not be used for locating 7089 the server that the boot image should be loaded from. 7091 BOOTP is a protocol used to boot end systems, and 7092 requires some stretching to accommodate its use with 7093 routers. If a router is using BOOTP to locate the 7094 current boot host, it should send a BOOTP Request with 7095 its hardware address for its first interface, or, if it 7096 has been previously configured otherwise, with either 7097 another interface's hardware address, or another number 7098 to put in the hardware address field of the BOOTP 7099 packet. This is to allow routers without hardware 7100 addresses (like synchronous line only routers) to use 7101 BOOTP for bootload discovery. TFTP can then be used to 7102 retrieve the image found in the BOOTP Reply. If there 7103 are no configured interfaces or numbers to use, a router 7104 MAY cycle through the interface hardware addresses it 7105 has until a match is found by the BOOTP server. 7107 A router SHOULD IMPLEMENT the ability to store 7108 parameters learned through BOOTP into local non-volatile 7109 storage. A router MAY implement the ability to store a 7110 system image loaded over the network into local stable 7111 storage. 7113 A router MAY have a facility to allow a remote user to 7114 request that the router get a new boot image. 7115 Differentiation should be made between getting the new 7116 boot image from one of three locations: the one included 7117 in the request, from the last boot image server, and 7118 using BOOTP to locate a server. 7120 Draft Requirements for IP Version 4 Routers March 1995 7122 10.3 Operation and Maintenance 7124 10.3.1 Introduction 7126 There is a range of possible models for performing O&M 7127 functions on a router. At one extreme is the local-only 7128 model, under which the O&M functions can only be 7129 executed locally (e.g., from a terminal plugged into the 7130 router machine). At the other extreme, the fully remote 7131 model allows only an absolute minimum of functions to be 7132 performed locally (e.g., forcing a boot), with most O&M 7133 being done remotely from the NOC. There are 7134 intermediate models, such as one in which NOC personnel 7135 can log into the router as a host, using the Telnet 7136 protocol, to perform functions that can also be invoked 7137 locally. The local-only model may be adequate in a few 7138 router installations, but remote operation from a NOC is 7139 normally required, and therefore remote O&M provisions 7140 are required for most routers. 7142 Remote O&M functions may be exercised through a control 7143 agent (program). In the direct approach, the router 7144 would support remote O&M functions directly from the NOC 7145 using standard Internet protocols (e.g., SNMP, UDP or 7146 TCP); in the indirect approach, the control agent would 7147 support these protocols and control the router itself 7148 using proprietary protocols. The direct approach is 7149 preferred, although either approach is acceptable. The 7150 use of specialized host hardware and/or software 7151 requiring significant additional investment is 7152 discouraged; nevertheless, some vendors may elect to 7153 provide the control agent as an integrated part of the 7154 network in which the routers are a part. If this is the 7155 case, it is required that a means be available to 7156 operate the control agent from a remote site using 7157 Internet protocols and paths and with equivalent 7158 functionality with respect to a local agent terminal. 7160 It is desirable that a control agent and any other NOC 7161 software tools that a vendor provides operate as user 7162 programs in a standard operating system. The use of the 7163 standard Internet protocols UDP and TCP for 7165 Draft Requirements for IP Version 4 Routers March 1995 7167 communicating with the routers should facilitate this. 7169 Remote router monitoring and (especially) remote router 7170 control present important access control problems that 7171 must be addressed. Care must also be taken to ensure 7172 control of the use of router resources for these 7173 functions. It is not desirable to let router monitoring 7174 take more than some limited fraction of the router CPU 7175 time, for example. On the other hand, O&M functions 7176 must receive priority so they can be exercised when the 7177 router is congested, since often that is when O&M is 7178 most needed. 7180 10.3.2 Out Of Band Access 7182 Routers MUST support Out-Of-Band (OOB) access. OOB 7183 access SHOULD provide the same functionality as in-band 7184 access. This access SHOULD implement access controls, 7185 to prevent unauthorized access. 7187 DISCUSSION: 7188 This Out-Of-Band access will allow the NOC a way to 7189 access isolated routers during times when network 7190 access is not available. 7192 Out-Of-Band access is an important management tool 7193 for the network administrator. It allows the access 7194 of equipment independent of the network connections. 7195 There are many ways to achieve this access. 7196 Whichever one is used it is important that the access 7197 is independent of the network connections. An 7198 example of Out-Of-Band access would be a serial port 7199 connected to a modem that provides dial up access to 7200 the router. 7202 It is important that the OOB access provides the same 7203 functionality as in-band access. In-band access, or 7204 accessing equipment through the existing network 7205 connection, is limiting, because most of the time, 7206 administrators need to reach equipment to figure out 7207 why it is unreachable. In band access is still very 7208 important for configuring a router, and for 7209 troubleshooting more subtle problems. 7211 Draft Requirements for IP Version 4 Routers March 1995 7213 10.3.2 Router O&M Functions 7215 10.3.2.1 Maintenance - Hardware Diagnosis 7217 Each router SHOULD operate as a stand-alone device 7218 for the purposes of local hardware maintenance. 7219 Means SHOULD be available to run diagnostic programs 7220 at the router site using only on-site tools. A 7221 router SHOULD be able to run diagnostics in case of a 7222 fault. For suggested hardware and software 7223 diagnostics see Section [10.3.3]. 7225 10.3.2.2 Control - Dumping and Rebooting 7227 A router MUST include both in-band and out-of-band 7228 mechanisms to allow the network manager to reload, 7229 stop, and restart the router. A router SHOULD also 7230 contain a mechanism (such as a watchdog timer) which 7231 will reboot the router automatically if it "hangs" 7232 due to a software or hardware fault. 7234 A router SHOULD IMPLEMENT a mechanism for dumping the 7235 contents of a router's memory (and/or other state 7236 useful for vendor debugging after a crash), and 7237 either saving them on a stable storage device local 7238 to the router or saving them on another host via an 7239 up-line dump mechanism such as TFTP (see [OPER:2], 7240 [INTRO:3]). 7242 10.3.2.3 Control - Configuring the Router 7244 Every router has configuration parameters that may 7245 need to be set. It SHOULD be possible to update the 7246 parameters without rebooting the router; at worst, a 7247 restart MAY be required. There may be cases when it 7248 is not possible to change parameters without 7249 rebooting the router (for instance, changing the IP 7250 address of an interface). In these cases, care 7251 should be taken to minimize disruption to the router 7252 and the surrounding network. 7254 Draft Requirements for IP Version 4 Routers March 1995 7256 There SHOULD be a way to configure the router over 7257 the network either manually or automatically. A 7258 router SHOULD be able to upload or download its 7259 parameters from a host or another router. A means 7260 SHOULD be provided, either as an application program 7261 or a router function, to convert between the 7262 parameter format and a human-editable format. A 7263 router SHOULD have some sort of stable storage for 7264 its configuration. A router SHOULD NOT believe 7265 protocols such as RARP, ICMP Address Mask Reply, and 7266 MAY not believe BOOTP. 7268 DISCUSSION: 7269 It is necessary to note here that in the future 7270 RARP, ICMP Address Mask Reply, BOOTP and other 7271 mechanisms may be needed to allow a router to 7272 auto-configure. Although routers may in the 7273 future be able to configure automatically, the 7274 intent here is to discourage this practice in a 7275 production environment until auto-configuration 7276 has been tested more thoroughly. The intent is 7277 NOT to discourage auto-configuration all together. 7278 In cases where a router is expected to get its 7279 configuration automatically it may be wise to 7280 allow the router to believe these things as it 7281 comes up and then ignore them after it has gotten 7282 its configuration. 7284 10.3.2.4 Net Booting of System Software 7286 A router SHOULD keep its system image in local non- 7287 volatile storage such as PROM, NVRAM, or disk. It 7288 MAY also be able to load its system software over the 7289 network from a host or another router. 7291 A router that can keep its system image in local 7292 non-volatile storage MAY be configurable to boot its 7293 system image over the network. A router that offers 7294 this option SHOULD be configurable to boot the system 7295 image in its non-volatile local storage if it is 7296 unable to boot its system image over the network. 7298 Draft Requirements for IP Version 4 Routers March 1995 7300 DISCUSSION: 7301 It is important that the router be able to come up 7302 and run on its own. NVRAM may be a particular 7303 solution for routers used in large networks, since 7304 changing PROMs can be quite time consuming for a 7305 network manager responsible for numerous or 7306 geographically dispersed routers. It is important 7307 to be able to netboot the system image because 7308 there should be an easy way for a router to get a 7309 bug fix or new feature more quickly than getting 7310 PROMs installed. Also if the router has NVRAM 7311 instead of PROMs, it will netboot the image and 7312 then put it in NVRAM. 7314 Routers SHOULD perform some basic consistency 7315 check on any image loaded, to detect and perhaps 7316 prevent incorrect images. 7318 A router MAY also be able to distinguish between 7319 different configurations based on which software it 7320 is running. If configuration commands change from 7321 one software version to another, it would be helpful 7322 if the router could use the configuration that was 7323 compatible with the software. 7325 10.3.2.5 Detecting and responding to misconfiguration 7327 There MUST be mechanisms for detecting and responding 7328 to misconfigurations. If a command is executed 7329 incorrectly, the router SHOULD give an error message. 7330 The router SHOULD NOT accept a poorly formed command 7331 as if it were correct. 7333 DISCUSSION: 7334 There are cases where it is not possible to detect 7335 errors: the command is correctly formed, but 7336 incorrect with respect to the network. This may 7337 be detected by the router, but may not be 7338 possible. 7340 Another form of misconfiguration is misconfiguration 7341 of the network to which the router is attached. A 7342 router MAY detect misconfigurations in the network. 7344 Draft Requirements for IP Version 4 Routers March 1995 7346 The router MAY log these findings to a file, either 7347 on the router or a host, so that the network manager 7348 will see that there are possible problems on the 7349 network. 7351 DISCUSSION: 7352 Examples of such misconfigurations might be 7353 another router with the same address as the one in 7354 question or a router with the wrong address mask. 7355 If a router detects such problems it is probably 7356 not the best idea for the router to try to fix the 7357 situation. That could cause more harm than good. 7359 10.3.2.6 Minimizing Disruption 7361 Changing the configuration of a router SHOULD have 7362 minimal affect on the network. Routing tables SHOULD 7363 NOT be unnecessarily flushed when a simple change is 7364 made to the router. If a router is running several 7365 routing protocols, stopping one routing protocol 7366 SHOULD NOT disrupt other routing protocols, except in 7367 the case where one network is learned by more than 7368 one routing protocol. 7370 DISCUSSION: 7371 It is the goal of a network manager to run a 7372 network so that users of the network get the best 7373 connectivity possible. Reloading a router for 7374 simple configuration changes can cause disruptions 7375 in routing and ultimately cause disruptions to the 7376 network and its users. If routing tables are 7377 unnecessarily flushed, for instance, the default 7378 route will be lost as well as specific routes to 7379 sites within the network. This sort of disruption 7380 will cause significant downtime for the users. It 7381 is the purpose of this section to point out that 7382 whenever possible, these disruptions should be 7383 avoided. 7385 Draft Requirements for IP Version 4 Routers March 1995 7387 10.3.2.7 Control - Troubleshooting Problems 7389 (1) A router MUST provide in-band network access, but 7390 (except as required by Section [8.2]) for 7391 security considerations this access SHOULD be 7392 disabled by default. Vendors MUST document the 7393 default state of any in-band access. This 7394 access SHOULD implement access controls, to 7395 prevent unauthorized access. 7397 DISCUSSION: 7398 In-band access primarily refers to access 7399 through the normal network protocols that may 7400 or may not affect the permanent operational 7401 state of the router. This includes, but is 7402 not limited to Telnet/RLOGIN console access 7403 and SNMP operations. 7405 This was a point of contention between the 7406 "operational out of the box" and "secure out 7407 of The box" contingents. Any "automagic" 7408 access to the router may introduce 7409 insecurities, but it may be more important 7410 for the customer to have a router that is 7411 accessible over the network as soon as it is 7412 plugged in. At least one vendor supplies 7413 routers without any external console access 7414 and depends on being able to access the 7415 router through the network to complete its 7416 configuration. 7418 It is the vendors call whether in-band access 7419 is enabled by default; but it is also the 7420 vendor's responsibility to make its customers 7421 aware of possible insecurities. 7423 (2) A router MUST provide the ability to initiate an 7424 ICMP echo. The following options SHOULD be 7425 implemented: 7427 + Choice of data patterns 7429 + Choice of packet size 7431 Draft Requirements for IP Version 4 Routers March 1995 7433 + Record route 7435 and the following additional options MAY be 7436 implemented: 7438 + Loose source route 7440 + Strict source route 7442 + Timestamps 7444 (3) A router SHOULD provide the ability to initiate a 7445 traceroute. If traceroute is provided, then the 7446 3rd party traceroute SHOULD be implemented. 7448 Each of the above three facilities (if implemented) 7449 SHOULD have access restrictions placed on it to 7450 prevent its abuse by unauthorized persons. 7452 10.4 Security Considerations 7454 10.4.1 Auditing and Audit Trails 7456 Auditing and billing are the bane of the network 7457 operator, but are the two features most requested by 7458 those in charge of network security and those who are 7459 responsible for paying the bills. In the context of 7460 security, auditing is desirable if it helps you keep 7461 your network working and protects your resources from 7462 abuse, without costing you more than those resources are 7463 worth. 7465 (1) Configuration Changes 7467 Router SHOULD provide a method for auditing a 7468 configuration change of a router, even if it's 7469 something as simple as recording the operator's 7470 initials and time of change. 7472 DISCUSSION: 7473 Configuration change logging (who made a 7475 Draft Requirements for IP Version 4 Routers March 1995 7477 configuration change, what was changed, and 7478 when) is very useful, especially when traffic is 7479 suddenly routed through Alaska on its way across 7480 town. So is the ability to revert to a previous 7481 configuration. 7483 (2) Packet Accounting 7485 Vendors should strongly consider providing a system 7486 for tracking traffic levels between pairs of hosts 7487 or networks. A mechanism for limiting the 7488 collection of this information to specific pairs of 7489 hosts or networks is also strongly encouraged. 7491 DISCUSSION: 7492 A "host traffic matrix" as described above can 7493 give the network operator a glimpse of traffic 7494 trends not apparent from other statistics. It 7495 can also identify hosts or networks that are 7496 "probing" the structure of the attached networks 7497 - e.g., a single external host that tries to 7498 send packets to every IP address in the network 7499 address range for a connected network. 7501 (3) Security Auditing 7503 Routers MUST provide a method for auditing security 7504 related failures or violations to include: 7506 + Authorization Failures: bad passwords, invalid 7507 SNMP communities, invalid authorization tokens, 7509 + Violations of Policy Controls: Prohibited Source 7510 Routes, Filtered Destinations, and 7512 + Authorization Approvals: good passwords - Telnet 7513 in-band access, console access. 7515 Routers MUST provide a method of limiting or 7516 disabling such auditing but auditing SHOULD be on 7517 by default. Possible methods for auditing include 7518 listing violations to a console if present, logging 7519 or counting them internally, or logging them to a 7520 remote security server through the SNMP trap 7522 Draft Requirements for IP Version 4 Routers March 1995 7524 mechanism or the Unix logging mechanism as 7525 appropriate. A router MUST implement at least one 7526 of these reporting mechanisms - it MAY implement 7527 more than one. 7529 10.4.2 Configuration Control 7531 A vendor has a responsibility to use good configuration 7532 control practices in the creation of the 7533 software/firmware loads for their routers. In 7534 particular, if a vendor makes updates and loads 7535 available for retrieval over the Internet, the vendor 7536 should also provide a way for the customer to confirm 7537 the load is a valid one, perhaps by the verification of 7538 a checksum over the load. 7540 DISCUSSION: 7541 Many vendors currently provide short notice updates 7542 of their software products through the Internet. 7543 This a good trend and should be encouraged, but 7544 provides a point of vulnerability in the 7545 configuration control process. 7547 If a vendor provides the ability for the customer to 7548 change the configuration parameters of a router 7549 remotely, for example through a Telnet session, the 7550 ability to do so SHOULD be configurable and SHOULD 7551 default to off. The router SHOULD require a password or 7552 other valid authentication before permitting remote 7553 reconfiguration. 7555 DISCUSSION: 7556 Allowing your properly identified network operator to 7557 twiddle with your routers is necessary; allowing 7558 anyone else to do so is foolhardy. 7560 A router MUST NOT have undocumented "back door" access 7561 and "master passwords". A vendor MUST ensure any such 7562 access added for purposes of debugging or product 7563 development are deleted before the product is 7564 distributed to its customers. 7566 DISCUSSION: 7568 Draft Requirements for IP Version 4 Routers March 1995 7570 A vendor has a responsibility to its customers to 7571 ensure they are aware of the vulnerabilities present 7572 in its code by intention - e.g., in-band access. 7573 "Trap doors", "back doors" and "master passwords" 7574 intentional or unintentional can turn a relatively 7575 secure router into a major problem on an operational 7576 network. The supposed operational benefits are not 7577 matched by the potential problems. 7579 Draft Requirements for IP Version 4 Routers March 1995 7581 11. REFERENCES 7583 Implementors should be aware that Internet protocol standards 7584 are occasionally updated. These references are current as of 7585 this writing, but a cautious implementor will always check a 7586 recent version of the RFC index to ensure that an RFC has not 7587 been updated or superseded by another, more recent RFC. 7588 Reference [INTRO:6] explains various ways to obtain a current 7589 RFC index. 7591 APPL:1. 7592 B. Croft and J. Gilmore, "Bootstrap Protocol (BOOTP), 7593 Request For Comments (RFC) 951, DDN Network Information 7594 Center, SRI International, Menlo Park, California, USA, 7595 September 1985. 7597 APPL:2. 7598 S. Alexander and R. Droms, "DHCP Options and BOOTP 7599 Vendor Extensions", Request For Comments (RFC) 1533, 7600 October 1993. 7602 APPL:3. 7603 W. Wimer, "Clarifications and Extensions for the 7604 Bootstrap Protocol", Request For Comments (RFC) 1542, 7605 October 1993. 7607 ARCH:1. 7608 "DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 7609 (three volumes), DDN Network Information Center, SRI 7610 International, Menlo Park, California, USA, December 7611 1985. 7613 ARCH:2. 7614 V. Cerf and R. Kahn, "A Protocol for Packet Network 7615 Intercommunication," IEEE Transactions on Communication, 7616 May 1974. Also included in [ARCH:1]. 7618 ARCH:3. 7619 J. Postel, C. Sunshine, and D. Cohen, "The ARPA 7620 Internet Protocol," Computer Networks, volume 5, number 7621 4, July 1981. Also included in [ARCH:1]. 7623 ARCH:4. 7624 B. Leiner, J. Postel, R. Cole, and D. Mills, "The 7626 Draft Requirements for IP Version 4 Routers March 1995 7628 DARPA Internet Protocol Suite," Proceedings of INFOCOM 7629 '85, IEEE, Washington, DC, March 1985. Also in: IEEE 7630 Communications Magazine, March 1985. Also available from 7631 the Information Sciences Institute, University of 7632 Southern California as Technical Report ISI-RS-85-153. 7634 ARCH:5. 7635 D. Comer, "Internetworking With TCP/IP Volume 1: 7636 Principles, Protocols, and Architecture", Prentice Hall, 7637 Englewood Cliffs, NJ, 1991. 7639 ARCH:6. 7640 W. Stallings, "Handbook of Computer-Communications 7641 Standards Volume 3: The TCP/IP Protocol Suite", 7642 Macmillan, New York, NY, 1990. 7644 ARCH:7. 7645 J. Postel, "Internet Official Protocol Standards", 7646 Request For Comments (RFC) 1540, October 1993. 7648 ARCH:8. 7649 "Information processing systems - Open Systems 7650 Interconnection - Basic Reference Model", ISO 7489, 7651 International Standards Organization, 1984. 7653 ARCH:9 7654 R. Braden, J. Postel, Y. Rekhter, "Internet 7655 Architecture Extensions for Shared Media", 05/20/1994 7657 FORWARD:1. 7658 IETF CIP Working Group (C. Topolcic, Editor), 7659 "Experimental Internet Stream Protocol, Version 2 (ST- 7660 II)", Request For Comments (RFC) 1190, DDN Network 7661 Information Center, SRI International, Menlo Park, 7662 California, USA, October 1990. 7664 FORWARD:2. 7665 A. Mankin and K. Ramakrishnan, Editors, "Gateway 7666 Congestion Control Survey", Request For Comments (RFC) 7667 1254, DDN Network Information Center, SRI International, 7668 Menlo Park, California, USA, August 1991. 7670 FORWARD:3. 7671 J. Nagle, "On Packet Switches with Infinite Storage," 7673 Draft Requirements for IP Version 4 Routers March 1995 7675 IEEE Transactions on Communications, volume COM-35, 7676 number 4, April 1987. 7678 FORWARD:4. 7679 R. Jain, K. Ramakrishnan, and D. Chiu, "Congestion 7680 Avoidance in Computer Networks With a Connectionless 7681 Network Layer", Technical Report DEC-TR-506, Digital 7682 Equipment Corporation. 7684 FORWARD:5. 7685 V. Jacobson, "Congestion Avoidance and Control," 7686 Proceedings of SIGCOMM '88, Association for Computing 7687 Machinery, August 1988. 7689 FORWARD:6. 7690 W. Barns, "Precedence and Priority Access Implementation 7691 for Department of Defense Data Networks", Technical 7692 Report MTR-91W00029, The Mitre Corporation, McLean, 7693 Virginia, USA, July 1991. 7695 FORWARD:7 7696 Fang, Chen, Hutchins, "Simulation Results of TCP 7697 Performance over ATM with and without Flow Control", 7698 presentation to the ATM Forum, November 15, 1993. 7700 FORWARD:8 7701 V. Paxson, S. Floyd "Wide Area Traffic: the Failure of 7702 Poisson Modeling", short version in SIGCOMM '94 7704 FORWARD:9 7705 Leland, Taqqu, Willinger and Wilson, "On the Self-Similar 7706 Nature of Ethernet Traffic", Proceedings of SIGCOMM '93, 7707 September, 1993. 7709 FORWARD:10 7710 S. Keshav "A Control Theoretic Approach to Flow 7711 Control", SIGCOMM 91, pages 3-16 7713 FORWARD:11 7714 K.K. Ramakrishnan and R. Jain, "A Binary Feedback 7715 Scheme for Congestion Avoidance in Computer Networks," 7716 ACM Transactions of Computer Systems, volume 8, number 2, 7717 1980. 7719 Draft Requirements for IP Version 4 Routers March 1995 7721 FORWARD:12 7722 H. Kanakia, P. Mishara, and A. Reibman]. An adaptive 7723 congestion control scheme for real-time packet video 7724 transport. In Proceedings of ACM SIGCOMM 1994, pages 7725 20-31, San Francisco, California, September 1993. 7727 FORWARD:13 7728 A. Demers, S. Keshav, S. Shenker "Analysis and 7729 Simulation of a Fair Queuing Algorithm", 7730 93 pages 1-12 7732 FORWARD:14 7733 D. Clark, S. Shenker , L. Zhang, "Supporting Real-Time 7734 Applications in an Integrated Services Packet Network: 7735 Architecture and Mechanism", 92 pages 14-26 7737 INTERNET:1. 7738 J. Postel, "Internet Protocol", Request For Comments 7739 (RFC) 791, DDN Network Information Center, SRI 7740 International, Menlo Park, California, USA, September 7741 1981. 7743 INTERNET:2. 7744 J. Mogul and J. Postel, "Internet Standard Subnetting 7745 Procedure", Request For Comments (RFC) 950, DDN Network 7746 Information Center, SRI International, Menlo Park, 7747 California, USA, August 1985. 7749 INTERNET:3. 7750 J. Mogul, "Broadcasting Internet Datagrams in the 7751 Presence of Subnets", Request For Comments (RFC) 922, DDN 7752 Network Information Center, SRI International, Menlo 7753 Park, California, USA, October 1984. 7755 INTERNET:4. 7756 S. Deering, "Host Extensions for IP Multicasting", 7757 Request For Comments (RFC) 1112, DDN Network Information 7758 Center, SRI International, Menlo Park, California, USA, 7759 August 1989. 7761 INTERNET:5. 7762 S. Kent, "U.S. Department of Defense Security Options 7763 for the Internet Protocol", Request for Comments (RFC) 7764 1108, November 1991. 7766 Draft Requirements for IP Version 4 Routers March 1995 7768 INTERNET:6. 7769 R. Braden, D. Borman, and C. Partridge, "Computing the 7770 Internet Checksum", Request For Comments (RFC) 1071, DDN 7771 Network Information Center, SRI International, Menlo 7772 Park, California, USA, September 1988. 7774 INTERNET:7. 7775 T. Mallory and A. Kullberg, "Incremental Updating of 7776 the Internet Checksum", Request For Comments (RFC) 1141, | 7777 DDN Network Information Center, SRI International, Menlo 7778 Park, California, USA, January 1990. 7780 INTERNET:8. 7781 J. Postel, "Internet Control Message Protocol", Request 7782 For Comments (RFC) 792, DDN Network Information Center, 7783 SRI International, Menlo Park, California, USA, September 7784 1981. 7786 INTERNET:9. 7787 A. Mankin, G. Hollingsworth, G. Reichlen, K. 7788 Thompson, R. Wilder, and R. Zahavi, "Evaluation of 7789 Internet Performance - FY89", Technical Report MTR- 7790 89W00216, MITRE Corporation, February, 1990. 7792 INTERNET:10. 7793 G. Finn, "A Connectionless Congestion Control 7794 Algorithm," Computer Communications Review, volume 19, 7795 number 5, Association for Computing Machinery, October 7796 1989. 7798 INTERNET:11. 7799 W. Prue, "The Source Quench Introduced Delay (SQuID)", 7800 Request For Comments (RFC) 1016, DDN Network Information 7801 Center, SRI International, J. Postel, August 1987. 7803 INTERNET:12. 7804 A. McKenzie, "Some comments on SQuID", Request For 7805 Comments (RFC) 1018, DDN Network Information Center, SRI 7806 International, Menlo Park, California, USA, August 1987. 7808 INTERNET:13. 7809 S. Deering, "ICMP Router Discovery Messages", Request 7810 For Comments (RFC) 1256, DDN Network Information Center, 7811 SRI International, Menlo Park, California, USA, September 7813 Draft Requirements for IP Version 4 Routers March 1995 7815 1991. 7817 INTERNET:14. 7818 J. Mogul and S. Deering, "Path MTU Discovery", Request 7819 For Comments (RFC) 1191, DDN Network Information Center, 7820 SRI International, Menlo Park, California, USA, November 7821 1990. 7823 INTERNET:15 7824 V. Fuller, T. Li, J. Yi, and K. Varadhan, "Classless 7825 Inter-Domain Routing (CIDR): an Address Assignment and 7826 Aggregation Strategy" Request For Comments (RFC) 1519, 7827 DDN Network Information Center, SRI International Menlo 7828 Park, California, USA September 1993. 7830 INTERNET:16 7831 M. St. Johns, "Draft Revised IP Security Option", 7832 Request for Comments 1038, January 1988. 7834 INTERNET:17 7835 W. Prue and J. Postel, "Queuing Algorithm to Provide 7836 Type-of-service For IP Links", Request for Comments 1046, 7837 February 1988. 7839 INTERNET:18 7840 J. Postel, "Address Mappings ", Request for Comments 7841 796, September 1981. 7843 INTRO:1. 7844 R. Braden and J. Postel, "Requirements for Internet 7845 Gateways", Request For Comments (RFC) 1009, DDN Network 7846 Information Center, SRI International, Menlo Park, 7847 California, USA, June 1987. 7849 INTRO:2. 7850 Internet Engineering Task Force (R. Braden, Editor), 7851 "Requirements for Internet Hosts - Communication Layers", 7852 Request For Comments (RFC) 1122, DDN Network Information 7853 Center, SRI International, Menlo Park, California, USA, 7854 October 1989. 7856 INTRO:3. 7857 Internet Engineering Task Force (R. Braden, Editor), 7858 "Requirements for Internet Hosts - Application and 7860 Draft Requirements for IP Version 4 Routers March 1995 7862 Support", Request For Comments (RFC) 1123, DDN Network 7863 Information Center, SRI International, Menlo Park, 7864 California, USA, October 1989. 7866 INTRO:4. 7867 D. Clark, "Modularity and Efficiency in Protocol 7868 Implementations", Request For Comments (RFC) 817, DDN 7869 Network Information Center, SRI International, Menlo 7870 Park, California, USA, July 1982. 7872 INTRO:5. 7873 D. Clark, "The Structuring of Systems Using Upcalls," 7874 Proceedings of 10th ACM SOSP, December 1985. 7876 INTRO:6. 7877 O. Jacobsen and J. Postel, "Protocol Document Order 7878 Information", Request For Comments (RFC) 980, DDN Network 7879 Information Center, SRI International, Menlo Park, 7880 California, USA, March 1986. 7882 INTRO:7. 7883 J. Reynolds and J. Postel, "Assigned Numbers", Request 7884 For Comments (RFC) 1340, July 1992. This document is 7885 periodically updated and reissued with a new number. It 7886 is wise to verify occasionally that the version you have 7887 is still current. 7889 INTRO:8. 7890 "DoD Trusted Computer System Evaluation Criteria", DoD 7891 publication 5200.28-STD, U.S. Department of Defense, 7892 December 1985. 7894 INTRO:9 7895 G. Malkin and T. LaQuey Parker, "Internet Users' 7896 Glossary", Request for Comments (RFC) 1392 (also FYI 7897 0018), Network Information Center, January 1993. 7899 LINK:1. 7900 S. Leffler and M. Karels, "Trailer Encapsulations", 7901 Request For Comments (RFC) 893, DDN Network Information 7902 Center, SRI International, Menlo Park, California, USA, 7903 April 1984. 7905 LINK:2 7907 Draft Requirements for IP Version 4 Routers March 1995 7909 W. Simpson, "The Point-to-Point Protocol (PPP) for the 7910 Transmission of Multi-protocol Datagrams over Point-to- 7911 Point Links", Request For Comments (RFC) 1331, May 1992. 7913 LINK:3 7914 G. McGregor, "The PPP Internet Protocol Control Protocol 7915 (IPCP)", Request For Comments (RFC) 1332, May 1992. 7917 LINK:4 7918 B. Lloyd, W. Simpson, "PPP Authentication Protocols", 7919 Request For Comments (RFC) 1334, May 1992. 7921 LINK:5 7922 W. Simpson "PPP Link Quality Monitoring", Request For 7923 Comments (RFC) 1333, May 1992. 7925 MGT:1. 7926 M. Rose and K. McCloghrie, "Structure and 7927 Identification of Management Information of TCP/IP-based 7928 Internets", Request For Comments (RFC) 1155, DDN Network 7929 Information Center, SRI International, Menlo Park, 7930 California, USA, May 1990. 7932 MGT:2. 7933 K. McCloghrie and M. Rose (Editors), "Management 7934 Information Base of TCP/IP-Based Internets: MIB-II", 7935 Request For Comments (RFC) 1213, DDN Network Information 7936 Center, SRI International, Menlo Park, California, USA, 7937 March 1991. 7939 MGT:3. 7940 J. Case, M. Fedor, M. Schoffstall, and J. Davin, 7941 "Simple Network Management Protocol", Request For 7942 Comments (RFC) 1157, DDN Network Information Center, SRI 7943 International, Menlo Park, California, USA, May 1990. 7945 MGT:4. 7946 M. Rose and K. McCloghrie (Editors), "Towards Concise 7947 MIB Definitions", Request For Comments (RFC) 1212, DDN 7948 Network Information Center, SRI International, Menlo 7949 Park, California, USA, March 1991. 7951 MGT:5. 7952 L. Steinberg, "Techniques for Managing Asynchronously 7954 Draft Requirements for IP Version 4 Routers March 1995 7956 Generated Alerts", Request for Comments (RFC) 1224, May 7957 1991. 7959 MGT:6. 7960 F. Kastenholz, "Definitions of Managed Objects for the 7961 Ethernet-like Interface Types", Request for Comments 7962 (RFC) 1398, January 1993. 7964 MGT:7. 7965 R. Fox and K. McCloghrie, "IEEE 802.4 Token Bus MIB", 7966 Request for Comments (RFC) 1230, May 1991. 7968 MGT:8. 7969 E. Decker, R. Fox and K. McCloghrie, "IEEE 802.5 Token 7970 Ring MIB", Request for Comments (RFC) 1231, February 7971 1993. 7973 MGT:9. 7974 J. Case and A. Rijsinghani, "FDDI Management 7975 Information Base", Request for Comments (RFC) 1512, 7976 September 1993. 7978 MGT:10. 7979 B. Stewart, "Definitions of Managed Objects for RS-232- 7980 like Hardware Devices", Request for Comments (RFC) 1317, 7981 April 1992. 7983 MGT:11. 7984 F. Kastenholz, " Definitions of Managed Objects for the 7985 Link Control Protocol of the Point-to-Point Protocol", 7986 Request For Comments (RFC) 1471 June 1992. 7988 MGT:12. 7989 F. Kastenholz, "The Definitions of Managed Objects for 7990 the Security Protocols of the Point-to-Point Protocol", 7991 Request For Comments (RFC) 1472 June 1992. 7993 MGT:13. 7994 F. Kastenholz, "The Definitions of Managed Objects for 7995 the IP Network Control Protocol of the Point-to-Point 7996 Protocol", Request For Comments (RFC) 1473 June 1992. 7998 MGT:14. 7999 F. Baker and R. Coltun, "OSPF Version 2 Management 8001 Draft Requirements for IP Version 4 Routers March 1995 8003 Information Base", Request For Comments (RFC) 1253, 8004 August 1991. 8006 MGT:15. 8007 S. Willis and J. Burruss, "Definitions of Managed 8008 Objects for the Border Gateway Protocol (Version 3)", 8009 Request For Comments (RFC) 1269, October 1991. 8011 MGT:16. 8012 F. Baker, J. Watt, "Definitions of Managed Objects for 8013 the DS1 and E1 Interface Types", Request For Comments 8014 (RFC) 1406, January 1993. 8016 MGT:17. 8017 T. Cox and K. Tesink, "Definitions of Managed Objects 8018 for the DS3/E3 Interface Types", Request For Comments 8019 (RFC) 1407, January 1993. 8021 MGT:18. 8022 K. McCloghrie, "Extensions to the Generic-Interface 8023 MIB", Request For Comments (RFC) 1229, August 1992. 8025 MGT:19. 8026 T. Cox and K. Tesink, "Definitions of Managed Objects 8027 for the SIP Interface Type", Request For Comments (RFC) 8028 1304, February 1992. 8030 MGT:20 8031 F. Baker, "IP Forwarding Table MIB", Request For 8032 Comments (RFC) 1354, July 1992. 8034 MGT:21. 8035 G. Malkin and F. Baker, "RIP Version 2 MIB Extension", 8036 Request For Comments (RFC) 1389, January 1993. 8038 MGT:22. 8039 D. Throop, "SNMP MIB Extension for the X.25 Packet 8040 Layer", Request For Comments (RFC) 1382, November 1992. 8042 MGT:23. 8043 D. Throop and F. Baker, "SNMP MIB Extension for X.25 8044 LAPB", Request For Comments (RFC) 1381, November 1992. 8046 MGT:24. 8048 Draft Requirements for IP Version 4 Routers March 1995 8050 D. Throop and F. Baker, "SNMP MIB Extension for 8051 MultiProtocol Interconnect over X.25", Request For 8052 Comments (RFC) 1461, May 1993. 8054 MGT:25. 8055 M. Rose, "SNMP over OSI", Request For Comments (RFC) 8056 1418, March 1993. 8058 MGT:26. 8059 G. Minshall and M. Ritter, "SNMP over AppleTalk", 8060 Request For Comments (RFC) 1419, March 1993. 8062 MGT:27. 8063 S. Bostock, "SNMP over IPX", Request For Comments (RFC) 8064 1420, March 1993. 8066 MGT:28. 8067 M. Schoffstall, C. Davin, M. Fedor, J. Case, "SNMP 8068 over Ethernet", Request For Comments (RFC) 1089, February 8069 1989. 8071 MGT:29. 8072 J. Case, "FDDI Management Information Base", Request For 8073 Comments (RFC) 1285, January 1992. 8075 OPER:1. 8076 J. Nagle, "Congestion Control in IP/TCP Internetworks", 8077 Request For Comments (RFC) 896, DDN Network Information 8078 Center, SRI International, Menlo Park, California, USA, 8079 January 1984. 8081 OPER:2. 8082 K.R. Sollins, "TFTP Protocol (revision 2)", Request For 8083 Comments (RFC) 1350, July 1992. 8085 ROUTE:1. 8086 J. Moy, "OSPF Version 2", Request For Comments (RFC) 8087 1247, DDN Network Information Center, SRI International, 8088 Menlo Park, California, USA, July 1991. 8090 ROUTE:2. 8091 R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and 8092 Dual Environments", Request For Comments (RFC) 1195, DDN 8093 Network Information Center, SRI International, Menlo 8095 Draft Requirements for IP Version 4 Routers March 1995 8097 Park, California, USA, December 1990. 8099 ROUTE:3. 8100 C. L. Hedrick, "Routing Information Protocol", Request 8101 For Comments (RFC) 1058, DDN Network Information Center, 8102 SRI International, Menlo Park, California, USA, June 8103 1988. 8105 ROUTE:4. 8106 K. Lougheed and Y. Rekhter, "A Border Gateway Protocol 8107 3 (BGP-3)", Request For Comments (RFC) 1267, October 8108 1991. 8110 ROUTE:5. 8111 P. Gross and Y. Rekhter, "Application of the Border 8112 Gateway Protocol in the Internet", Request For Comments 8113 (RFC) 1268, October 1991. 8115 ROUTE:6. 8116 D. Mills, "Exterior Gateway Protocol Formal 8117 Specification", Request For Comments (RFC) 904, DDN 8118 Network Information Center, SRI International, Menlo 8119 Park, California, USA, April 1984. 8121 ROUTE:7. 8122 E. Rosen, "Exterior Gateway Protocol (EGP)", Request For 8123 Comments (RFC) 827, DDN Network Information Center, SRI 8124 International, Menlo Park, California, USA, October 1982. 8126 ROUTE:8. 8127 L. Seamonson and E. Rosen, ""STUB" Exterior Gateway 8128 Protocol", Request For Comments (RFC) 888, DDN Network 8129 Information Center, SRI International, Menlo Park, 8130 California, USA, January 1984. 8132 ROUTE:9. 8133 D. Waitzman, C. Partridge, and S. Deering, "Distance 8134 Vector Multicast Routing Protocol", Request For Comments 8135 (RFC) 1075, DDN Network Information Center, SRI 8136 International, Menlo Park, California, USA, November 8137 1988. 8139 ROUTE:10. 8140 S. Deering, "Multicast Routing in Internetworks and 8142 Draft Requirements for IP Version 4 Routers March 1995 8144 Extended LANs," Proceedings of '88, Association for 8145 Computing Machinery, August 1988. 8147 ROUTE:11. 8148 P. Almquist, "Type of Service in the Internet Protocol 8149 Suite", Request for Comments (RFC) 1349, July 1992. 8151 ROUTE:12. 8152 Y. Rekhter, "Experience with the BGP Protocol", Request 8153 For Comments (RFC) 1266, October 1991. 8155 ROUTE:13. 8156 Y. Rekhter, "BGP Protocol Analysis", Request For 8157 Comments (RFC) 1265, October 1991. 8159 TRANS:1. 8160 J. Postel, "User Datagram Protocol", Request For 8161 Comments (RFC) 768, DDN Network Information Center, SRI 8162 International, Menlo Park, California, USA, August 1980. 8164 TRANS:2. 8165 J. Postel, "Transmission Control Protocol", Request For 8166 Comments (RFC) 793, DDN Network Information Center, SRI 8167 International, Menlo Park, California, USA, September 8168 1981. 8170 Draft Requirements for IP Version 4 Routers March 1995 8172 APPENDIX A. REQUIREMENTS FOR SOURCE-ROUTING HOSTS 8174 Subject to restrictions given below, a host MAY be able to act 8175 as an intermediate hop in a source route, forwarding a 8176 source-routed datagram to the next specified hop. 8178 However, in performing this router-like function, the host 8179 MUST obey all the relevant rules for a router forwarding 8180 source-routed datagrams [INTRO:2]. This includes the 8181 following specific provisions: 8183 (A) TTL 8184 The TTL field MUST be decremented and the datagram 8185 perhaps discarded as specified for a router in [INTRO:2]. 8187 (B) ICMP Destination Unreachable 8188 A host MUST be able to generate Destination Unreachable 8189 messages with the following codes: 8190 4 (Fragmentation Required but DF Set) when a source- 8191 routed datagram cannot be fragmented to fit into the 8192 target network; 8193 5 (Source Route Failed) when a source-routed datagram 8194 cannot be forwarded, e.g., because of a routing problem 8195 or because the next hop of a strict source route is not 8196 on a connected network. 8198 (C) IP Source Address 8199 A source-routed datagram being forwarded MAY (and 8200 normally will) have a source address that is not one of 8201 the IP addresses of the forwarding host. 8203 (D) Record Route Option 8204 A host that is forwarding a source-routed datagram 8205 containing a Record Route option MUST update that option, 8206 if it has room. 8208 (E) Timestamp Option 8209 A host that is forwarding a source-routed datagram 8210 containing a Timestamp Option MUST add the current 8211 timestamp to that option, according to the rules for this 8212 option. 8214 To define the rules restricting host forwarding of source- 8215 routed datagrams, we use the term "local source-routing" if 8217 Draft Requirements for IP Version 4 Routers March 1995 8219 the next hop will be through the same physical interface 8220 through which the datagram arrived; otherwise, it is "non- 8221 local source-routing". 8223 A host is permitted to perform local source-routing without 8224 restriction. 8226 A host that supports non-local source-routing MUST have a 8227 configurable switch to disable forwarding, and this switch 8228 MUST default to disabled. 8230 The host MUST satisfy all router requirements for configurable 8231 policy filters [INTRO:2] restricting non-local forwarding. 8233 If a host receives a datagram with an incomplete source route 8234 but does not forward it for some reason, the host SHOULD 8235 return an ICMP Destination Unreachable (code 5, Source Route 8236 Failed) message, unless the datagram was itself an ICMP error 8237 message. 8239 Draft Requirements for IP Version 4 Routers March 1995 8241 APPENDIX B. GLOSSARY 8243 This Appendix defines specific terms used in this memo. It 8244 also defines some general purpose terms that may be of 8245 interest. See also [INTRO:9] for a more general set of 8246 definitions. 8248 Autonomous System (AS) | 8249 An Autonomous System (AS) is a connected segment of a | 8250 network topology that consists of a collection of | 8251 subnetworks (with hosts attached) interconnected by a set | 8252 of routes. The subnetworks and the routers are expected | 8253 to be under the control of a single operations and | 8254 maintenance (O&M) organization. Within an AS routers may | 8255 use one or more interior routing protocols, and sometimes | 8256 several sets of metrics. An AS is expected to present to | 8257 other ASs an appearence of a coherent interior routing | 8258 plan, and a consistent picture of the destinations | 8259 reachable through the AS. An AS is identified by an | 8260 Autonomous System number. 8261 Connected Network 8262 A network prefix to which a router is interfaced is often 8263 known as a "local network" or the "subnetwork" of that 8264 router. However, these terms can cause confusion, and 8265 therefore we use the term "Connected Network" in this 8266 memo. 8268 Connected (Sub)Network 8269 A Connected (Sub)Network is an IP subnetwork to which a 8270 router is interfaced, or a connected network if the 8271 connected network is not subnetted. See also Connected 8272 Network. 8274 Datagram 8275 The unit transmitted between a pair of internet modules. 8276 Data, called datagrams, from sources to destinations. 8277 The Internet Protocol does not provide a reliable 8278 communication facility. There are no acknowledgments 8279 either end-to-end or hop-by-hop. There is no error no 8280 retransmissions. There is no flow control. See IP. 8282 Default Route 8283 A routing table entry that is used to direct any data 8285 Draft Requirements for IP Version 4 Routers March 1995 8287 addressed to any network prefixes not explicitly listed 8288 in the routing table. 8290 Dense Mode 8291 In multicast forwarding, two paradigms are possible: in 8292 "Dense Mode" forwarding, a network multicast is forwarded 8293 as a data link layer multicast to all interfaces except 8294 that on which it was received, unless and until the 8295 router is instructed not to by a multicast routing 8296 neighbor. See Sparse Mode. 8298 EGP 8299 Exterior Gateway Protocol A protocol that distributes 8300 routing information to the gateways (routers) which 8301 connect autonomous systems. See IGP. 8303 EGP-2 8304 Exterior Gateway Protocol version 2 This is an EGP 8305 routing protocol developed to handle traffic between 8306 Autonomous Systems in the Internet. 8308 Forwarder 8309 The logical entity within a router that is responsible 8310 for switching packets among the router's interfaces. The 8311 Forwarder also makes the decisions to queue a packet for 8312 local delivery, to queue a packet for transmission out 8313 another interface, or both. 8315 Forwarding 8316 Forwarding is the process a router goes through for each 8317 packet received by the router. The packet may be 8318 consumed by the router, it may be output on one or more 8319 interfaces of the router, or both. Forwarding includes 8320 the process of deciding what to do with the packet as 8321 well as queuing it up for (possible) output or internal 8322 consumption. 8324 Forwarding Information Base (FIB) 8325 The table containing the information necessary to forward 8326 IP Datagrams, in this document, is called the Forwarding 8327 Information Base. At minimum, this contains the 8328 interface identifier and next hop information for each 8329 reachable destination network prefix. 8331 Draft Requirements for IP Version 4 Routers March 1995 8333 Fragment 8334 An IP datagram that represents a portion of a higher 8335 layer's packet that was too large to be sent in its 8336 entirety over the output network. 8338 General Purpose Serial Interface 8339 A physical medium capable of connecting exactly two 8340 systems, and therefore configurable as a point to point 8341 line, but also configurable to support link layer 8342 networking using protocols such as X.25 or Frame Relay. 8343 A link layer network connects another system to a switch, 8344 and a higher communication layer multiplexes virtual 8345 circuits on the connection. See Point to Point Line. 8347 IGP 8348 Interior Gateway Protocol A protocol that distributes 8349 routing information with an Autonomous System (AS). See 8350 EGP. 8352 Interface IP Address 8353 The IP Address and network prefix length that is assigned 8354 to a specific interface of a router. 8356 Internet Address 8357 An assigned number that identifies a host in an internet. 8358 It has two parts: an IP address and a prefix length. The 8359 prefix length indicates how many of the most specific 8360 bits of the address constitute the network prefix. 8362 IP 8363 Internet Protocol The network layer protocol for the 8364 Internet. It is a packet switching, datagram protocol 8365 defined in RFC 791. IP does not provide a reliable 8366 communications facility; that is, there are no end-to-end 8367 of hop-by-hop acknowledgments. 8369 IP Datagram 8370 An IP Datagram is the unit of end-to-end transmission in 8371 the Internet Protocol. An IP Datagram consists of an IP 8372 header followed by all of higher-layer data (such as TCP, 8373 UDP, ICMP, and the like). An IP Datagram is an IP header 8374 followed by a message. 8376 An IP Datagram is a complete IP end-to-end transmission 8378 Draft Requirements for IP Version 4 Routers March 1995 8380 unit. An IP Datagram is composed of one or more IP 8381 Fragments. 8383 In this memo, the unqualified term "Datagram" should be 8384 understood to refer to an IP Datagram. 8386 IP Fragment 8387 An IP Fragment is a component of an IP Datagram. An IP 8388 Fragment consists of an IP header followed by all or part 8389 of the higher-layer of the original IP Datagram. 8391 One or more IP Fragments comprises a single IP Datagram. 8393 In this memo, the unqualified term "Fragment" should be 8394 understood to refer to an IP Fragment. 8396 IP Packet 8397 An IP Datagram or an IP Fragment. 8399 In this memo, the unqualified term "Packet" should 8400 generally be understood to refer to an IP Packet. 8402 Logical [network] interface 8403 We define a logical [network] interface to be a logical 8404 path, distinguished by a unique IP address, to a 8405 connected network. 8407 Martian Filtering 8408 A packet that contains an invalid source or destination 8409 address is considered to be "martian" and discarded. 8411 MTU (Maximum Transmission Unit) 8412 The size of the largest packet that can be transmitted or 8413 received through a logical interface. This size includes 8414 the IP header but does not include the size of any Link 8415 Layer headers or framing. 8417 Multicast 8418 A packet that is destined for multiple hosts. See 8419 "broadcast". 8421 Multicast Address 8422 A special type of address that is recognizable by 8423 multiple hosts. 8425 Draft Requirements for IP Version 4 Routers March 1995 8427 A Multicast Address is sometimes known as a Functional 8428 Address or a Group Address. 8430 Network Prefix 8431 The portion of an IP Address that signifies a set of 8432 systems. It is selected from the IP Address by logically 8433 ANDing a subnet mask with the address, or (equivalently) 8434 setting the bits of the address not among the most 8435 significant bits of the address to zero. 8437 Originate 8438 Packets can be transmitted by a router for one of two 8439 reasons: 1) the packet was received and is being 8440 forwarded or 2) the router itself created the packet for 8441 transmission (such as route advertisements). Packets 8442 that the router creates for transmission are said to 8443 originate at the router. 8445 Packet 8446 A packet is the unit of data passed across the interface 8447 between the Internet Layer and the Link Layer. It 8448 includes an IP header and data. A packet may be a 8449 complete IP datagram or a fragment of an IP datagram. 8451 Path 8452 The sequence of routers and (sub-)networks that a packet 8453 traverses from a particular router to a particular 8454 destination host. Note that a path is uni-directional; 8455 it is not unusual to have different paths in the two 8456 directions between a given host pair. 8458 Physical Network 8459 A Physical Network is a network (or a piece of an 8460 internet) which is contiguous at the Link Layer. Its 8461 internal structure (if any) is transparent to the 8462 Internet Layer. 8464 In this memo, several media components that are connected 8465 using devices such as bridges or repeaters are considered 8466 to be a single Physical Network since such devices are 8467 transparent to the IP. 8469 Physical Network Interface 8470 This is a physical interface to a Connected Network and 8472 Draft Requirements for IP Version 4 Routers March 1995 8474 has a (possibly unique) Link-Layer address. Multiple 8475 Physical Network Interfaces on a single router may share 8476 the same Link-Layer address, but the address must be 8477 unique for different routers on the same Physical 8478 Network. 8480 Point to Point Line 8481 A physical medium capable of connecting exactly two 8482 systems. In this document, it is only used to refer to 8483 such a line when used to connect IP entities. See 8484 General Purpose Serial Interface. 8486 router 8487 A special-purpose dedicated computer that connects 8488 several networks. Routers switch packets between these 8489 networks in a process known as forwarding. This process 8490 may be repeated several times on a single packet by 8491 multiple routers until the packet can be delivered to the 8492 final destination - switching the packet from router to 8493 router to router... until the packet gets to its 8494 destination. 8496 RPF 8497 Reverse Path Forwarding - A method used to deduce the 8498 next hops for broadcast and multicast packets. 8500 Silently Discard 8501 This memo specifies several cases where a router is to 8502 "Silently Discard" a received packet (or datagram). This 8503 means that the router should discard the packet without 8504 further processing, and that the router will not send any 8505 ICMP error message (see Section [4.3.2]) as a result. 8506 However, for diagnosis of problems, the router should 8507 provide the capability of logging the error (see Section 8508 [1.3.3]), including the contents of the silently 8509 discarded packet, and should record the event in a 8510 statistics counter. 8512 Silently Ignore 8513 A router is said to "Silently Ignore" an error or 8514 condition if it takes no action other than possibly 8515 generating an error report in an error log or through 8516 some network management protocol, and discarding, or 8517 ignoring, the source of the error. In particular, the 8519 Draft Requirements for IP Version 4 Routers March 1995 8521 router does NOT generate an ICMP error message. 8523 Sparse Mode 8524 In multicast forwarding, two paradigms are possible: in 8525 "Sparse Mode" forwarding, a network layer multicast 8526 datagram is forwarded as a data link layer multicast 8527 frame to routers and hosts that have asked for it. The 8528 initial forwarding state is the inverse of dense-mode in 8529 that it assumes no part of the network wants the data. 8530 See Dense Mode. 8532 Specific-destination address 8533 This is defined to be the destination address in the IP 8534 header unless the header contains an IP broadcast or IP 8535 multicast address, in which case the specific-destination 8536 is an IP address assigned to the physical interface on 8537 which the packet arrived. 8539 subnet 8540 A portion of a network, which may be a physically 8541 independent network, which shares a network address with 8542 other portions of the network and is distinguished by a 8543 subnet number. A subnet is to a network what a network 8544 is to an internet. 8546 subnet number 8547 A part of the internet address that designates a subnet. 8548 It is ignored for the purposes internet routing, but is 8549 used for intranet routing. 8551 TOS 8552 Type Of Service A field in the IP header that represents 8553 the degree of reliability expected from the network layer 8554 by the transport layer or application. 8556 TTL 8557 Time To Live A field in the IP header that represents how 8558 long a packet is considered valid. It is a combination 8559 "hop count" and "timer value". 8561 Draft Requirements for IP Version 4 Routers March 1995 8563 APPENDIX C. FUTURE DIRECTIONS 8565 This appendix lists work that future revisions of this 8566 document may wish to address. 8568 In the preparation of Router Requirements, we stumbled across 8569 several other architectural issues. Each of these is dealt 8570 with somewhat in the document, but still ought to be 8571 classified as an open issue in the IP architecture. 8573 Most of the he topics presented here generally indicate areas 8574 where the technology is still relatively new and it is not 8575 appropriate to develop specific requirements since the 8576 community is still gaining operational experience. 8578 Other topics represent areas of ongoing research and indicate 8579 areas that the prudent developer would closely monitor. 8581 (1) SNMP Version 2 8583 (2) Additional SNMP MIBs | 8585 (7) More detailed requirements for leaking routes between | 8586 routing protocols 8588 (8) Router system security 8590 (9) Routing protocol security 8592 (10) Internetwork Protocol layer security. There has been 8593 extensive work refining the security of IP since the 8594 original work writing this document. This security work 8595 should be included in here. 8597 (12) Load Splitting 8599 (13) Sending fragments along different paths 8601 (15) Multiple logical (sub)nets on the same wire. Router 8602 Requirements does not require support for this. We made 8603 some attempt to identify pieces of the architecture 8604 (e.g., forwarding of directed broadcasts and issuing of 8605 Redirects) where the wording of the rules has to be done 8607 Draft Requirements for IP Version 4 Routers March 1995 8609 carefully to make "the right thing" happen, and tried to 8610 clearly distinguish logical interfaces from physical 8611 interfaces. However, we did not study this issue in 8612 detail, and we are not at all confident that all the 8613 rules in the document are correct in the presence of 8614 multiple logical (sub)nets on the same wire. 8616 (15) Congestion control and resource management. On the 8617 advice of the IETF's experts (Mankin and Ramakrishnan) we 8618 deprecated (SHOULD NOT) Source Quench and said little 8619 else concrete (Section 5.3.6). 8621 (16) Developing a Link-Layer requirements document that would 8622 be common for both routers and hosts. 8624 (17) Developing a common PPP LQM algorithm. 8626 (18) Investigate of other information (above and beyond 8627 section [3.2]) that passes between the layers, such as 8628 physical network MTU, mappings of IP precedence to Link 8629 Layer priority values, etc. 8631 (19) Should the Link Layer notify IP if address resolution 8632 failed (just like it notifies IP when there is a Link 8633 Layer priority value problem)? 8635 (20) Should all routers be required to implement a DNS 8636 resolver? 8638 (21) Should a human user be able to use a host name anywhere 8639 you can use an IP address when configuring the router? 8640 Even in ping and traceroute? 8642 (22) Almquist's draft ruminations on the next hop and 8643 ruminations on route leaking need to be reviewed, brought 8644 up to date, and published. 8646 (23) Investigation is needed to determine if a redirect 8647 message for precedence is needed or not. If not, are the 8648 type-of-service redirects acceptable? 8650 (24) RIPv2 and RIP+CIDR and variable length network prefixes. 8652 (25) BGP-4 CIDR is going to be important, and everyone is 8654 Draft Requirements for IP Version 4 Routers March 1995 8656 betting on BGP-4. We can't avoid mentioning it. 8657 Probably need to describe the differences between BGP-3 8658 and BGP-4, and explore upgrade issues... 8660 (26) Loose Source Route Mobile IP and some multicasting may 8661 require this. Perhaps it should be elevated to a SHOULD 8662 (per Fred Baker's Suggestion). 8664 Draft Requirements for IP Version 4 Routers March 1995 8666 APPENDIX D. Multicast Routing Protocols 8668 Multicasting is a relatively new technology within the 8669 Internet Protocol family. It is not widely deployed or 8670 commonly in use yet. Its importance, however, is expected to 8671 grow over the coming years. 8673 This Appendix describes some of the technologies being 8674 investigated for routing multicasts through the Internet. 8676 A diligent implementor will keep abreast of developments in 8677 this area to properly develop multicast facilities. 8679 This Appendix does not specify any standards or requirements. 8681 D.1 Introduction 8683 Multicast routing protocols enable the forwarding of IP 8684 multicast datagrams throughout a TCP/IP internet. 8685 Generally these algorithms forward the datagram based on 8686 its source and destination addresses. Additionally, the 8687 datagram may need to be forwarded to several multicast 8688 group members, at times requiring the datagram to be 8689 replicated and sent out multiple interfaces. 8691 The state of multicast routing protocols is less developed 8692 than the protocols available for the forwarding of IP 8693 unicasts. Three experimental multicast routing protocols 8694 have been documented for TCP/IP. Each uses the IGMP 8695 protocol (discussed in Section [4.4]) to monitor multicast 8696 group membership. 8698 D.2 Distance Vector Multicast Routing Protocol - DVMRP 8700 DVMRP, documented in [ROUTE:9], is based on Distance Vector 8701 or Bellman-Ford technology. It routes multicast datagrams 8702 only, and does so within a single Autonomous System. DVMRP 8703 is an implementation of the Truncated Reverse Path 8704 Broadcasting algorithm described in [ROUTE:10]. In 8705 addition, it specifies the tunneling of IP multicasts 8706 through non-multicast-routing-capable IP domains. 8708 Draft Requirements for IP Version 4 Routers March 1995 8710 D.3 Multicast Extensions to OSPF - MOSPF 8712 MOSPF, currently under development, is a backward- 8713 compatible addition to OSPF that allows the forwarding of 8714 both IP multicasts and unicasts within an Autonomous 8715 System. MOSPF routers can be mixed with OSPF routers 8716 within a routing domain, and they will interoperate in the 8717 forwarding of unicasts. OSPF is a link-state or SPF-based 8718 protocol. By adding link state advertisements that 8719 pinpoint group membership, MOSPF routers can calculate the 8720 path of a multicast datagram as a tree rooted at the 8721 datagram source. Those branches that do not contain group 8722 members can then be discarded, eliminating unnecessary 8723 datagram forwarding hops. 8725 D.4 Protocol Independent Multicast - PIM 8727 PIM, currently under development, is a multicast routing 8728 protocol that runs over an existing unicast infrastructure. 8729 PIM provides for both dense and sparse group membership. 8730 It is different from other protocols, since it uses an 8731 explicit join model for sparse groups. Joining occurs on a 8732 shared tree and can switch to a per-source tree. Where 8733 bandwidth is plentiful and group membership is dense, 8734 overhead can be reduced by flooding data out all links and 8735 later pruning exception cases where there are no group 8736 members. 8738 Draft Requirements for IP Version 4 Routers March 1995 8740 APPENDIX E Additional Next-Hop Selection Algorithms 8742 Section [5.2.4.3] specifies an algorithm that routers ought to 8743 use when selecting a next-hop for a packet. 8745 This appendix provides historical perspective for the next-hop 8746 selection problem. It also presents several additional 8747 pruning rules and next-hop selection algorithms that might be 8748 found in the Internet. 8750 This appendix presents material drawn from an earlier, 8751 unpublished, work by Philip Almquist; "Ruminations on the Next 8752 Hop". 8754 This Appendix does not specify any standards or requirements. 8756 E.1. Some Historical Perspective 8758 It is useful to briefly review the history of the topic, 8759 beginning with what is sometimes called the "classic model" 8760 of how a router makes routing decisions. This model 8761 predates IP. In this model, a router speaks some single 8762 routing protocol such as RIP. The protocol completely 8763 determines the contents of the router's Forwarding 8764 Information Base (FIB). The route lookup algorithm is 8765 trivial: the router looks in the FIB for a route whose 8766 destination attribute exactly matches the network prefix 8767 portion of the destination address in the packet. If one 8768 is found, it is used; if none is found, the destination is 8769 unreachable. Because the routing protocol keeps at most 8770 one route to each destination, the problem of what to do 8771 when there are multiple routes that match the same 8772 destination cannot arise. 8774 Over the years, this classic model has been augmented in 8775 small ways. With the deployment of default routes, 8776 subnets, and host routes, it became possible to have more 8777 than one routing table entry which in some sense matched 8778 the destination. This was easily resolved by a consensus 8779 that there was a hierarchy of routes: host routes should be 8780 preferred over subnet routes, subnet routes over net 8781 routes, and net routes over default routes. 8783 Draft Requirements for IP Version 4 Routers March 1995 8785 With the deployment of technologies supporting variable 8786 length subnet masks (variable length network prefixes), the 8787 general approach remained the same although its description 8788 became a little more complicated; network prefixes were 8789 introduced as a conscious simplification and regularization 8790 of the architecture. We now say that each route to a 8791 network prefix route has a prefix length associated with 8792 it. This prefix length indicates the number of bits in the 8793 prefix. This may also be represented using the classical 8794 subnet mask. A route cannot be used to route a packet 8795 unless each significant bit in the route's network prefix 8796 matches the corresponding bit in the packet's destination 8797 address. Routes with more bits set in their masks are 8798 preferred over routes that have fewer bits set in their 8799 masks. This is simply a generalization of the hierarchy of 8800 routes described above, and will be referred to for the 8801 rest of this memo as choosing a route by preferring longest 8802 match. 8804 Another way the classic model has been augmented is through 8805 a small amount of relaxation of the notion that a routing 8806 protocol has complete control over the contents of the 8807 routing table. First, static routes were introduced. For 8808 the first time, it was possible to simultaneously have two 8809 routes (one dynamic and one static) to the same 8810 destination. When this happened, a router had to have a 8811 policy (in some cases configurable, and in other cases 8812 chosen by the author of the router's software) which 8813 determined whether the static route or the dynamic route 8814 was preferred. However, this policy was only used as a 8815 tie-breaker when longest match didn't uniquely determine 8816 which route to use. Thus, for example, a static default 8817 route would never be preferred over a dynamic net route 8818 even if the policy preferred static routes over dynamic 8819 routes. 8821 The classic model had to be further augmented when inter- 8822 domain routing protocols were invented. Traditional 8823 routing protocols came to be called "interior gateway 8824 protocols" (IGPs), and at each Internet site there was a 8825 strange new beast called an "exterior gateway", a router 8826 that spoke EGP to several "BBN Core Gateways" (the routers 8827 that made up the Internet backbone at the time) at the same 8828 time as it spoke its IGP to the other routers at its site. 8830 Draft Requirements for IP Version 4 Routers March 1995 8832 Both protocols wanted to determine the contents of the 8833 router's routing table. Theoretically, this could result 8834 in a router having three routes (EGP, IGP, and static) to 8835 the same destination. Because of the Internet topology at 8836 the time, it was resolved with little debate that routers 8837 would be best served by a policy of preferring IGP routes 8838 over EGP routes. However, the sanctity of longest match 8839 remained unquestioned: a default route learned from the IGP 8840 would never be preferred over a net route from learned EGP. 8842 Although the Internet topology, and consequently routing in 8843 the Internet, have evolved considerably since then, this 8844 slightly augmented version of the classic model has 8845 survived intact to this day in the Internet (except that 8846 BGP has replaced EGP). Conceptually (and often in 8847 implementation) each router has a routing table and one or 8848 more routing protocol processes. Each of these processes 8849 can add any entry that it pleases, and can delete or modify 8850 any entry that it has created. When routing a packet, the 8851 router picks the best route using longest match, augmented 8852 with a policy mechanism to break ties. Although this 8853 augmented classic model has served us well, it has a number 8854 of shortcomings: 8856 + It ignores (although it could be augmented to consider) 8857 path characteristics such as quality of service and MTU. 8859 + It doesn't support routing protocols (such as OSPF and 8860 Integrated IS-IS) that require route lookup algorithms 8861 different than pure longest match. 8863 + There has not been a firm consensus on what the tie- 8864 breaking mechanism ought to be. Tie-breaking mechanisms 8865 have often been found to be difficult if not impossible 8866 to configure in such a way that the router will always 8867 pick what the network manger considers to be the 8868 "correct" route. 8870 E.2. Additional Pruning Rules 8872 Section [5.2.4.3] defined several pruning rules to use to 8873 select routes from the FIB. There are other rules that 8874 could also be used. 8876 Draft Requirements for IP Version 4 Routers March 1995 8878 + OSPF Route Class 8879 Routing protocols that have areas or make a distinction 8880 between internal and external routes divide their routes 8881 into classes by the type of information used to 8882 calculate the route. A route is always chosen from the 8883 most preferred class unless none is available, in which 8884 case one is chosen from the second most preferred class, 8885 and so on. In OSPF, the classes (in order from most 8886 preferred to least preferred) are intra-area, inter- 8887 area, type 1 external (external routes with internal 8888 metrics), and type 2 external. As an additional 8889 wrinkle, a router is configured to know what addresses 8890 ought to be accessible using intra-area routes, and will 8891 not use inter- area or external routes to reach these 8892 destinations even when no intra-area route is available. 8894 More precisely, we assume that each route has a class 8895 attribute, called route.class, which is assigned by the 8896 routing protocol. The set of candidate routes is 8897 examined to determine if it contains any for which 8898 route.class = intra-area. If so, all routes except 8899 those for which route.class = intra-area are discarded. 8900 Otherwise, router checks whether the packet's 8901 destination falls within the address ranges configured 8902 for the local area. If so, the entire set of candidate 8903 routes is deleted. Otherwise, the set of candidate 8904 routes is examined to determine if it contains any for 8905 which route.class = inter-area. If so, all routes 8906 except those for which route.class = inter-area are 8907 discarded. Otherwise, the set of candidate routes is 8908 examined to determine if it contains any for which 8909 route.class = type 1 external. If so, all routes except 8910 those for which route.class = type 1 external are 8911 discarded. 8913 + IS-IS Route Class 8914 IS-IS route classes work identically to OSPF's. 8915 However, the set of classes defined by Integrated IS-IS 8916 is different, such that there isn't a one-to-one mapping 8917 between IS-IS route classes and OSPF route classes. The 8918 route classes used by Integrated IS-IS are (in order 8919 from most preferred to least preferred) intra-area, 8920 inter-area, and external. 8922 Draft Requirements for IP Version 4 Routers March 1995 8924 The Integrated IS-IS internal class is equivalent to the 8925 OSPF internal class. Likewise, the Integrated IS-IS 8926 external class is equivalent to OSPF's type 2 external 8927 class. However, Integrated IS-IS does not make a 8928 distinction between inter-area routes and external 8929 routes with internal metrics - both are considered to be 8930 inter-area routes. Thus, OSPF prefers true inter-area 8931 routes over external routes with internal metrics, 8932 whereas Integrated IS-IS gives the two types of routes 8933 equal preference. 8935 + IDPR Policy 8936 A specific case of Policy. The IETF's Inter-domain 8937 Policy Routing Working Group is devising a routing 8938 protocol called Inter-Domain Policy Routing (IDPR) to 8939 support true policy-based routing in the Internet. 8940 Packets with certain combinations of header attributes 8941 (such as specific combinations of source and destination 8942 addresses or special IDPR source route options) are 8943 required to use routes provided by the IDPR protocol. 8944 Thus, unlike other Policy pruning rules, IDPR Policy 8945 would have to be applied before any other pruning rules 8946 except Basic Match. 8948 Specifically, IDPR Policy examines the packet being 8949 forwarded to ascertain if its attributes require that it 8950 be forwarded using policy-based routes. If so, IDPR 8951 Policy deletes all routes not provided by the IDPR 8952 protocol. 8954 E.3 Some Route Lookup Algorithms 8956 This section examines several route lookup algorithms that 8957 are in use or have been proposed. Each is described by 8958 giving the sequence of pruning rules it uses. The 8959 strengths and weaknesses of each algorithm are presented 8961 E.3.1 The Revised Classic Algorithm 8963 The Revised Classic Algorithm is the form of the 8964 traditional algorithm that was discussed in Section 8965 [E.1]. The steps of this algorithm are: 8967 Draft Requirements for IP Version 4 Routers March 1995 8969 1. Basic match 8970 2. Longest match 8971 3. Best metric 8972 4. Policy 8974 Some implementations omit the Policy step, since it is 8975 needed only when routes may have metrics that are not 8976 comparable (because they were learned from different 8977 routing domains). 8979 The advantages of this algorithm are: 8981 (1) It is widely implemented. 8983 (2) Except for the Policy step (which an implementor can 8984 choose to make arbitrarily complex) the algorithm 8985 is simple both to understand and to implement. 8987 Its disadvantages are: 8989 (1) It does not handle IS-IS or OSPF route classes, and 8990 therefore cannot be used for Integrated IS-IS or 8991 OSPF. 8993 (2) It does not handle TOS or other path attributes. 8995 (3) The policy mechanisms are not standardized in any 8996 way, and are therefore are often implementation- 8997 specific. This causes extra work for implementors 8998 (who must invent appropriate policy mechanisms) and 8999 for users (who must learn how to use the 9000 mechanisms. This lack of a standardized mechanism 9001 also makes it difficult to build consistent 9002 configurations for routers from different vendors. 9003 This presents a significant practical deterrent to 9004 multi-vendor interoperability. 9006 (4) The proprietary policy mechanisms currently provided 9007 by vendors are often inadequate in complex parts of 9008 the Internet. 9010 (5) The algorithm has not been written down in any 9011 generally available document or standard. It is, 9012 in effect, a part of the Internet Folklore. 9014 Draft Requirements for IP Version 4 Routers March 1995 9016 E.3.2 The Variant Router Requirements Algorithm 9018 Some Router Requirements Working Group members have 9019 proposed a slight variant of the algorithm described in 9020 the Section [5.2.4.3]. In this variant, matching the 9021 type of service requested is considered to be more 9022 important, rather than less important, than matching as 9023 much of the destination address as possible. For 9024 example, this algorithm would prefer a default route 9025 that had the correct type of service over a network 9026 route that had the default type of service, whereas the 9027 algorithm in [5.2.4.3] would make the opposite choice. 9029 The steps of the algorithm are: 9030 1. Basic match 9031 2. Weak TOS 9032 3. Longest match 9033 4. Best metric 9034 5. Policy 9036 Debate between the proponents of this algorithm and the 9037 regular Router Requirements Algorithm suggests that each 9038 side can show cases where its algorithm leads to 9039 simpler, more intuitive routing than the other's 9040 algorithm does. This variant has the same set of 9041 advantages and disadvantages that the algorithm 9042 specified in [5.2.4.3] does, except that pruning on Weak 9043 TOS before pruning on Longest Match makes this algorithm 9044 less compatible with OSPF and Integrated IS-IS than the 9045 standard Router Requirements Algorithm. 9047 E.3.3 The OSPF Algorithm 9049 OSPF uses an algorithm that is virtually identical to 9050 the Router Requirements Algorithm except for one crucial 9051 difference: OSPF considers OSPF route classes. 9053 The algorithm is: 9054 1. Basic match 9055 2. OSPF route class 9056 3. Longest match 9057 4. Weak TOS 9058 5. Best metric 9060 Draft Requirements for IP Version 4 Routers March 1995 9062 6. Policy 9064 Type of service support is not always present. If it is 9065 not present then, of course, the fourth step would be 9066 omitted 9068 This algorithm has some advantages over the Revised 9069 Classic Algorithm: 9071 (1) It supports type of service routing. 9073 (2) Its rules are written down, rather than merely being 9074 a part of the Internet folklore. 9076 (3) It (obviously) works with OSPF. 9078 However, this algorithm also retains some of the 9079 disadvantages of the Revised Classic Algorithm: 9081 (1) Path properties other than type of service (e.g., 9082 MTU) are ignored. 9084 (2) As in the Revised Classic Algorithm, the details (or 9085 even the existence) of the Policy step are left to 9086 the discretion of the implementor. 9088 The OSPF Algorithm also has a further disadvantage 9089 (which is not shared by the Revised Classic Algorithm). 9090 OSPF internal (intra-area or inter-area) routes are 9091 always considered to be superior to routes learned from 9092 other routing protocols, even in cases where the OSPF 9093 route matches fewer bits of the destination address. 9094 This is a policy decision that is inappropriate in some 9095 networks. 9097 Finally, it is worth noting that the OSPF Algorithm's 9098 TOS support suffers from a deficiency in that routing 9099 protocols that support TOS are implicitly preferred when 9100 forwarding packets that have non-zero TOS values. This 9101 may not be appropriate in some cases. 9103 Draft Requirements for IP Version 4 Routers March 1995 9105 E.3.4 The Integrated IS-IS Algorithm 9107 Integrated IS-IS uses an algorithm that is similar to 9108 but not quite identical to the OSPF Algorithm. 9109 Integrated IS-IS uses a different set of route classes, 9110 and differs slightly in its handling of type of service. 9111 The algorithm is: 9112 1. Basic Match 9113 2. IS-IS Route Classes 9114 3. Longest Match 9115 4. Weak TOS 9116 5. Best Metric 9117 6. Policy 9119 Although Integrated IS-IS uses Weak TOS, the protocol is 9120 only capable of carrying routes for a small specific 9121 subset of the possible values for the TOS field in the 9122 IP header. Packets containing other values in the TOS 9123 field are routed using the default TOS. 9125 Type of service support is optional; if disabled, the 9126 fourth step would be omitted. As in OSPF, the 9127 specification does not include the Policy step. 9129 This algorithm has some advantages over the Revised 9130 Classic Algorithm: 9131 (1) It supports type of service routing. 9132 (2) Its rules are written down, rather than merely being 9133 a part of the Internet folklore. 9134 (3) It (obviously) works with Integrated IS-IS. 9136 However, this algorithm also retains some of the 9137 disadvantages of the Revised Classic Algorithm: 9138 (1) Path properties other than type of service (e.g., 9139 MTU) are ignored. 9140 (2) As in the Revised Classic Algorithm, the details (or 9141 even the existence) of the Policy step are left to 9142 the discretion of the implementor. 9143 (3) It doesn't work with OSPF because of the differences 9144 between IS-IS route classes and OSPF route classes. 9145 Also, because IS-IS supports only a subset of the 9146 possible TOS values, some obvious implementations 9147 of the Integrated IS-IS algorithm would not support 9148 OSPF's interpretation of TOS. 9150 Draft Requirements for IP Version 4 Routers March 1995 9152 The Integrated IS-IS Algorithm also has a further 9153 disadvantage (which is not shared by the Revised Classic 9154 Algorithm): IS-IS internal (intra-area or inter-area) 9155 routes are always considered to be superior to routes 9156 learned from other routing protocols, even in cases 9157 where the IS-IS route matches fewer bits of the 9158 destination address and doesn't provide the requested 9159 type of service. This is a policy decision that may not 9160 be appropriate in all cases. 9162 Finally, it is worth noting that the Integrated IS-IS 9163 Algorithm's TOS support suffers from the same deficiency 9164 noted for the OSPF Algorithm. 9166 Draft Requirements for IP Version 4 Routers March 1995 9168 Security Considerations 9170 Although the focus of this document is interoperability rather 9171 than security, there are obviously many sections of this 9172 document that have some ramifications on network security. 9174 "Security" means different things to different people. 9175 Security from a router's point of view is anything that helps 9176 to keep its own networks operational and in addition helps to 9177 keep the Internet as a whole healthy. For the purposes of 9178 this document, the security services we are concerned with are 9179 "denial of service", "integrity", and "authentication" as it 9180 applies to the first two. "Privacy" as a security service is 9181 important, but only peripherally a concern of a router - at 9182 least as of the date of this document. 9184 In several places in this document there are sections entitled 9185 "... Security Considerations". These sections discuss 9186 specific considerations that apply to the general topic under 9187 discussion. 9189 Rarely does this document say "do this and your router/network 9190 will be secure". More likely, it says "this is a good idea 9191 and if you do it, it *may* improve the security of the 9192 Internet and your local system in general." 9194 Unfortunately, this is the state-of-the-art AT THIS TIME. Few 9195 if any of the network protocols a router is concerned with 9196 have reasonable, built-in security features. Industry and the 9197 protocol designers have been and are continuing to struggle 9198 with these issues. There is progress, but only small baby 9199 steps such as the peer-to-peer authentication available in the 9200 BGP and OSPF routing protocols. 9202 In particular, this document notes the current research into 9203 developing and enhancing network security. Specific areas of 9204 research, development, and engineering that are underway as of 9205 this writing (December 1993) are in IP Security, SNMP 9206 Security, and common authentication technologies. 9208 Notwithstanding all the above, there are things both vendors 9209 and users can do to improve the security of their router. 9210 Vendors should get a copy of "Trusted Computer System 9211 Interpretation" [INTRO:8]. Even if a vendor decides not to 9213 Draft Requirements for IP Version 4 Routers March 1995 9215 submit their device for formal verification under these 9216 guidelines, the publication provides excellent guidance on 9217 general security design and practices for computing devices. 9219 Draft Requirements for IP Version 4 Routers March 1995 9221 APPENDIX F: HISTORICAL ROUTING PROTOCOLS 9223 Certain routing protocols are common in the Internet, but the 9224 authors of this document cannot in good conscience recommend 9225 their use. This is not because they do not work correctly, 9226 but because the characteristics of the Internet assumed in 9227 their design (simple routing, no policy, a single "core 9228 router" network under common administration, limited 9229 complexity, or limited network diameter) are not attributes of 9230 today's Internet. Those parts of the Internet that still use 9231 them are generally limited "fringe" domains with limited 9232 complexity. 9234 As a matter of good faith, collected wisdom concerning their 9235 implementation is recorded in this section. 9237 F.1 EXTERIOR GATEWAY PROTOCOL - EGP 9239 F.1.1 Introduction 9241 The Exterior Gateway Protocol (EGP) specifies an EGP 9242 that is used to exchange reachability information 9243 between routers of the same or differing autonomous 9244 systems. EGP is not considered a routing protocol since 9245 there is no standard interpretation (i.e. metric) for 9246 the distance fields in the EGP update message, so 9247 distances are comparable only among routers of the same 9248 AS. It is however designed to provide high-quality 9249 reachability information, both about neighbor routers 9250 and about routes to non-neighbor routers. 9252 EGP is defined by [ROUTE:6]. An implementor almost 9253 certainly wants to read [ROUTE:7] and [ROUTE:8] as well, 9254 for they contain useful explanations and background 9255 material. 9257 DISCUSSION: 9258 The present EGP specification has serious 9259 limitations, most importantly a restriction that 9260 limits routers to advertising only those networks 9261 that are reachable from within the router's 9263 Draft Requirements for IP Version 4 Routers March 1995 9265 autonomous system. This restriction against 9266 propagating "third party" EGP information is to 9267 prevent long-lived routing loops. This effectively 9268 limits EGP to a two-level hierarchy. 9270 RFC-975 is not a part of the EGP specification, and 9271 should be ignored. 9273 F.1.2 Protocol Walk-through 9275 Indirect Neighbors: RFC-888, pp. 26 9277 An implementation of EGP MUST include indirect 9278 neighbor support. 9280 Polling Intervals: RFC-904, pp. 10 9282 The interval between Hello command retransmissions 9283 and the interval between Poll retransmissions SHOULD 9284 be configurable but there MUST be a minimum value 9285 defined. 9287 The interval at which an implementation will respond 9288 to Hello commands and Poll commands SHOULD be 9289 configurable but there MUST be a minimum value 9290 defined. 9292 Network Reachability: RFC-904, pp. 15 9294 An implementation MUST default to not providing the 9295 external list of routers in other autonomous systems; 9296 only the internal list of routers together with the 9297 nets that are reachable through those routers should 9298 be included in an Update Response/Indication packet. 9299 However, an implementation MAY elect to provide a 9300 configuration option enabling the external list to be 9301 provided. An implementation MUST NOT include in the 9302 external list routers that were learned through the 9303 external list provided by a router in another 9304 autonomous system. An implementation MUST NOT send a 9305 network back to the autonomous system from which it 9307 Draft Requirements for IP Version 4 Routers March 1995 9309 is learned, i.e. it MUST do split-horizon on an 9310 autonomous system level. 9312 If more than 255 internal or 255 external routers 9313 need to be specified in a Network Reachability 9314 update, the networks reachable from routers that can 9315 not be listed MUST be merged into the list for one of 9316 the listed routers. Which of the listed routers is 9317 chosen for this purpose SHOULD be user configurable, 9318 but SHOULD default to the source address of the EGP 9319 update being generated. 9321 An EGP update contains a series of blocks of network 9322 numbers, where each block contains a list of network 9323 numbers reachable at a particular distance through a 9324 particular router. If more than 255 networks are 9325 reachable at a particular distance through a 9326 particular router, they are split into multiple 9327 blocks (all of which have the same distance). 9328 Similarly, if more than 255 blocks are required to 9329 list the networks reachable through a particular 9330 router, the router's address is listed as many times 9331 as necessary to include all the blocks in the update. 9332 Unsolicited Updates: RFC-904, pp. 16 9334 If a network is shared with the peer, an 9335 implementation MUST send an unsolicited update upon 9336 entry to the Up state if the source network is the 9337 shared network. 9339 Neighbor Reachability: RFC-904, pp. 6, 13-15 9341 The table on page 6 that describes the values of j 9342 and k (the neighbor up and down thresholds) is 9343 incorrect. It is reproduced correctly here: 9345 Name Active Passive Description 9346 ----------------------------------------------- 9347 j 3 1 neighbor-up threshold 9348 k 1 0 neighbor-down threshold 9350 The value for k in passive mode also specified 9351 incorrectly in RFC-904, page 14 The values in 9352 parenthesis should read: 9354 Draft Requirements for IP Version 4 Routers March 1995 9356 (j = 1, k = 0, and T3/T1 = 4) 9358 As an optimization, an implementation can refrain 9359 from sending a Hello command when a Poll is due. If 9360 an implementation does so, it SHOULD provide a user 9361 configurable option to disable this optimization. 9363 Abort timer: RFC-904, pages 6, 12, 13 9365 An EGP implementation MUST include support for the 9366 abort timer (as documented in section 4.1.4 of RFC- 9367 904). An implementation SHOULD use the abort timer 9368 in the Idle state to automatically issue a Start 9369 event to restart the protocol machine. Recommended 9370 values are P4 for a critical error (Administratively 9371 prohibited, Protocol Violation and Parameter Problem) 9372 and P5 for all others. The abort timer SHOULD NOT be 9373 started when a Stop event was manually initiated 9374 (such as through a network management protocol). 9376 When the EGP state machine is in the Idle state, it 9377 MUST reply to Cease commands with a Cease-ack 9378 response. 9380 An EGP implementation MUST include support for both 9381 active and passive polling modes. 9383 As noted the Hello and Poll Intervals should only be 9384 present in Request and Confirm messages. Therefore 9385 the length of an EGP Neighbor Acquisition Message is 9386 14 bytes for a Request or Confirm message and 10 9387 bytes for a Refuse, Cease or Cease-ack message. 9388 Implementations MUST NOT send 14 bytes for Refuse, 9389 Cease or Cease-ack messages but MUST allow for 9390 implementations that send 14 bytes for these 9391 messages. 9393 Draft Requirements for IP Version 4 Routers March 1995 9395 Response or indication packets received with a 9396 sequence number not equal to S MUST be discarded. 9397 The send sequence number S MUST be incremented just 9398 before the time a Poll command is sent and at no 9399 other times. 9401 F.2 ROUTING INFORMATION PROTOCOL - RIP 9403 F.2.1 Introduction 9405 RIP is specified in [ROUTE:3]. Although RIP is still 9406 quite important in the Internet, it is being replaced in 9407 sophisticated applications by more modern IGPs such as 9408 the ones described above. A router implementing RIP 9409 SHOULD implement RIP Version 2 [ROUTE:?], as it supports 9410 CIDR routes. If occasional access networking is in use, 9411 a router implementing RIP SHOULD implement Demand RIP 9412 [ROUTE:?]. 9414 Another common use for RIP is as a "router discovery" 9415 protocol. Section [4.3.3.10] briefly touches upon this 9416 subject. 9418 F.2.2 Protocol Walk-Through 9420 Dealing with changes in topology: [ROUTE:3], pp. 11 9422 An implementation of RIP MUST provide a means for 9423 timing out routes. Since messages are occasionally 9424 lost, implementations MUST NOT invalidate a route 9425 based on a single missed update. 9427 Implementations MUST by default wait six times the 9428 update interval before invalidating a route. A 9429 router MAY have configuration options to alter this 9430 value. 9432 DISCUSSION: 9433 It is important to routing stability that all 9435 Draft Requirements for IP Version 4 Routers March 1995 9437 routers in a RIP autonomous system use similar 9438 timeout value for invalidating routes, and 9439 therefore it is important that an implementation 9440 default to the timeout value specified in the 9441 RIP specification. However, that timeout value 9442 is too conservative in environments where packet 9443 loss is reasonably rare. In such an 9444 environment, a network manager may wish to be 9445 able to decrease the timeout period to promote 9446 faster recovery from failures. 9448 IMPLEMENTATION: 9449 There is a very simple mechanism that a router 9450 may use to meet the requirement to invalidate 9451 routes promptly after they time out. Whenever 9452 the router scans the routing table to see if any 9453 routes have timed out, it also notes the age of 9454 the least recently updated route that has not 9455 yet timed out. Subtracting this age from the 9456 timeout period gives the amount of time until 9457 the router again needs to scan the table for 9458 timed out routes. 9460 Split Horizon: [ROUTE:3], pp. 14-15 9462 An implementation of RIP MUST implement "split 9463 horizon", a scheme used for avoiding problems 9464 caused by including routes in updates sent to the 9465 router from which they were learned. 9467 An implementation of RIP SHOULD implement "Split 9468 horizon with poisoned reverse", a variant of split 9469 horizon that includes routes learned from a router 9470 sent to that router, but sets their metric to 9471 infinity. Because of the routing overhead that may 9472 be incurred by implementing split horizon with 9473 poisoned reverse, implementations MAY include an 9474 option to select whether poisoned reverse is in 9475 effect. An implementation SHOULD limit the time in 9476 which it sends reverse routes at an infinite 9477 metric. 9479 Draft Requirements for IP Version 4 Routers March 1995 9481 IMPLEMENTATION: 9482 Each of the following algorithms can be used to 9483 limit the time for which poisoned reverse is 9484 applied to a route. The first algorithm is more 9485 complex but does a more thorough job of limiting 9486 poisoned reverse to only those cases where it is 9487 necessary. 9489 The goal of both algorithms is to ensure that 9490 poison reverse is done for any destination whose 9491 route has changed in the last Route Lifetime 9492 (typically 180 seconds), unless it can be sure 9493 that the previous route used the same output 9494 interface. The Route Lifetime is used because 9495 that is the amount of time RIP will keep around 9496 an old route before declaring it stale. 9498 The time intervals (and derived variables) used 9499 in the following algorithms are as follows: 9501 Tu The Update Timer; the number of seconds 9502 between RIP updates. This typically 9503 defaults to 30 seconds. 9505 Rl The Route Lifetime, in seconds. This is the 9506 amount of time that a route is presumed to 9507 be good, without requiring an update. This 9508 typically defaults to 180 seconds. 9510 Ul The Update Loss; the number of consecutive 9511 updates that have to be lost or fail to 9512 mention a route before RIP deletes the 9513 route. Ul is calculated to be (Rl/Tu)+1. 9514 The "+1" is to account for the fact that 9515 the first time the ifcounter is decremented 9516 will be less than Tu seconds after it is 9517 initialized. Typically, Ul will be 7: 9518 (180/30)+1. 9520 In The value to set ifcounter to when a 9521 destination is newly learned. This value 9522 is Ul-4, where the "4" is RIP's garbage 9523 collection timer/30 9525 Draft Requirements for IP Version 4 Routers March 1995 9527 The first algorithm is: 9529 - Associated with each destination is a counter, 9530 called the ifcounter below. Poison reverse 9531 is done for any route whose destination's 9532 ifcounter is greater than zero. 9534 - After a regular (not triggered or in response 9535 to a request) update is sent, all the non- 9536 zero ifcounters are decremented by one. 9538 - When a route to a destination is created, its 9539 ifcounter is set as follows: 9541 - If the new route is superseding a valid 9542 route, and the old route used a different 9543 (logical) output interface, then the 9544 ifcounter is set to Ul. 9546 - If the new route is superseding a stale 9547 route, and the old route used a different 9548 (logical) output interface, then the 9549 ifcounter is set to MAX(0, Ul - 9550 INT(seconds that the route has been 9551 stale/Ut). 9553 - If there was no previous route to the 9554 destination, the ifcounter is set to In. 9556 - Otherwise, the ifcounter is set to zero 9558 - RIP also maintains a timer, called the 9559 resettimer below. Poison reverse is done on 9560 all routes whenever resettimer has not 9561 expired (regardless of the ifcounter values). 9563 - When RIP is started, restarted, reset, or 9564 otherwise has its routing table cleared, it 9565 sets the resettimer to go off in Rl seconds. 9567 The second algorithm is identical to the first 9568 except that: 9570 - The rules which set the ifcounter to non-zero 9572 Draft Requirements for IP Version 4 Routers March 1995 9574 values are changed to always set it to Rl/Tu, 9575 and 9577 - The resettimer is eliminated. 9579 Triggered updates (also called "flash updates") 9580 are a mechanism for immediately notifying a 9581 router's neighbors when the router adds or 9582 deletes routes or changes their metrics. A 9583 router MUST send a triggered update when routes 9584 are deleted or their metrics are increased. A 9585 router MAY send a triggered update when routes 9586 are added or their metrics decreased. 9588 Since triggered updates can cause excessive 9589 routing overhead, implementations MUST use the 9590 following mechanism to limit the frequency of 9591 triggered updates: 9593 (1) When a router sends a triggered update, it 9594 sets a timer to a random time between one 9595 and five seconds in the future. The router 9596 must not generate additional triggered 9597 updates before this timer expires. 9599 (2) If the router would generate a triggered 9600 update during this interval it sets a flag 9601 indicating that a triggered update is 9602 desired. The router also logs the desired 9603 triggered update. 9605 (3) When the triggered update timer expires, the 9606 router checks the triggered update flag. 9607 If the flag is set then the router sends a 9608 single triggered update which includes all 9609 the changes that were logged. The router 9610 then clears the flag and, since a triggered 9611 update was sent, restarts this algorithm. 9613 (4) The flag is also cleared whenever a regular 9614 update is sent. 9616 Draft Requirements for IP Version 4 Routers March 1995 9618 Triggered updates SHOULD include all routes that 9619 have changed since the most recent regular 9620 (non-triggered) update. Triggered updates MUST 9621 NOT include routes that have not changed since 9622 the most recent regular update. 9624 DISCUSSION: 9625 Sending all routes, whether they have changed 9626 recently or not, is unacceptable in triggered 9627 updates because the tremendous size of many 9628 Internet routing tables could otherwise 9629 result in considerable bandwidth being wasted 9630 on triggered updates. 9632 Use of UDP: [ROUTE:3], pp. 18-19. 9634 RIP packets sent to an IP broadcast address 9635 SHOULD have their initial TTL set to one. 9637 Note that to comply with Section [6.1] of this 9638 memo, a router SHOULD use UDP checksums in RIP 9639 packets that it originates, MUST discard RIP 9640 packets received with invalid UDP checksums, but 9641 MUST NOT discard received RIP packets simply 9642 because they do not contain UDP checksums. 9644 Addressing Considerations: [ROUTE:3], pp. 22 9646 A RIP implementation SHOULD support host routes. 9647 of [ROUTE:3]) ignore host routes in received 9648 updates. A router MAY log ignored hosts routes. 9650 The special address 0.0.0.0 is used to describe 9651 a default route. A default route is used as the 9652 route of last resort (i.e., when a route to the 9653 specific net does not exist in the routing 9654 table). The router MUST be able to create a RIP 9655 entry for the address 0.0.0.0. 9657 Input Processing - Response: [ROUTE:3], pp. 26 9659 When processing an update, the following 9660 validity checks MUST be performed: 9662 Draft Requirements for IP Version 4 Routers March 1995 9664 + The response MUST be from UDP port 520. 9666 + The source address MUST be on a directly 9667 connected subnet (or on a directly connected, 9668 non-subnetted network) to be considered 9669 valid. 9671 + The source address MUST NOT be one of the 9672 router's addresses. 9674 DISCUSSION: 9675 Some networks, media, and interfaces allow 9676 a sending node to receive packets that it 9677 broadcasts. A router must not accept its 9678 own packets as valid routing updates and 9679 process them. The last requirement 9680 prevents a router from accepting its own 9681 routing updates and processing them (on 9682 the assumption that they were sent by some 9683 other router on the network). 9685 An implementation MUST NOT replace an existing 9686 route if the metric received is equal to the 9687 existing metric except in accordance with the 9688 following heuristic. 9690 An implementation MAY choose to implement the 9691 following heuristic to deal with the above 9692 situation. Normally, it is useless to change 9693 the route to a network from one router to 9694 another if both are advertised at the same 9695 metric. However, the route being advertised by 9696 one of the routers may be in the process of 9697 timing out. Instead of waiting for the route to 9698 timeout, the new route can be used after a 9699 specified amount of time has elapsed. If this 9700 heuristic is implemented, it MUST wait at least 9701 halfway to the expiration point before the new 9702 route is installed. 9704 Draft Requirements for IP Version 4 Routers March 1995 9706 F.2.3 Specific Issues 9708 RIP Shutdown 9710 An implementation of RIP SHOULD provide for a 9711 graceful shutdown using the following steps: 9713 (1) Input processing is terminated, 9715 (2) Four updates are generated at random intervals 9716 of between two and four seconds, These updates 9717 contain all routes that were previously 9718 announced, but with some metric changes. 9719 Routes that were being announced at a metric 9720 of infinity should continue to use this 9721 metric. Routes that had been announced with a 9722 non-infinite metric should be announced with a 9723 metric of 15 (infinity - 1). 9725 DISCUSSION: 9726 The metric used for the above really ought 9727 to be 16 (infinity); setting it to 15 is a 9728 kludge to avoid breaking certain old hosts 9729 that wiretap the RIP protocol. Such a host 9730 will (erroneously) abort a TCP connection 9731 if it tries to send a datagram on the 9732 connection while the host has no route to 9733 the destination (even if the period when 9734 the host has no route lasts only a few 9735 seconds while RIP chooses an alternate path 9736 to the destination). 9738 RIP Split Horizon and Static Routes 9740 Split horizon SHOULD be applied to static routes by 9741 default. An implementation SHOULD provide a way to 9742 specify, per static route, that split horizon 9743 should not be applied to this route. 9745 Draft Requirements for IP Version 4 Routers March 1995 9747 F.3 GATEWAY TO GATEWAY PROTOCOL - GGP | 9749 The Gateway to Gateway protocol is considered obsolete 9750 and SHOULD NOT be implemented. * 9752 Draft Requirements for IP Version 4 Routers March 1995 9754 Acknowledgments 9756 O that we now had here 9757 But one ten thousand of those men in England 9758 That do no work to-day! 9760 What's he that wishes so? 9761 My cousin Westmoreland? No, my fair cousin: 9762 If we are mark'd to die, we are enow 9763 To do our country loss; and if to live, 9764 The fewer men, the greater share of honour. 9765 God's will! I pray thee, wish not one man more. 9766 By Jove, I am not covetous for gold, 9767 Nor care I who doth feed upon my cost; 9768 It yearns me not if men my garments wear; 9769 Such outward things dwell not in my desires: 9770 But if it be a sin to covet honour, 9771 I am the most offending soul alive. 9772 No, faith, my coz, wish not a man from England: 9773 God's peace! I would not lose so great an honour 9774 As one man more, methinks, would share from me 9775 For the best hope I have. O, do not wish one more! 9776 Rather proclaim it, Westmoreland, through my host, 9777 That he which hath no stomach to this fight, 9778 Let him depart; his passport shall be made 9779 And crowns for convoy put into his purse: 9780 We would not die in that man's company 9781 That fears his fellowship to die with us. 9782 This day is called the feast of Crispian: 9783 He that outlives this day, and comes safe home, 9784 Will stand a tip-toe when the day is named, 9785 And rouse him at the name of Crispian. 9786 He that shall live this day, and see old age, 9787 Will yearly on the vigil feast his neighbours, 9788 And say 'To-morrow is Saint Crispian:' 9789 Then will he strip his sleeve and show his scars. 9790 And say 'These wounds I had on Crispin's day.' 9791 Old men forget: yet all shall be forgot, 9792 But he'll remember with advantages 9793 What feats he did that day: then shall our names. 9794 Familiar in his mouth as household words 9795 Harry the king, Bedford and Exeter, 9796 Warwick and Talbot, Salisbury and Gloucester, 9798 Draft Requirements for IP Version 4 Routers March 1995 9800 Be in their flowing cups freshly remember'd. 9801 This story shall the good man teach his son; 9802 And Crispin Crispian shall ne'er go by, 9803 From this day to the ending of the world, 9804 But we in it shall be remember'd; 9805 We few, we happy few, we band of brothers; 9806 For he to-day that sheds his blood with me 9807 Shall be my brother; be he ne'er so vile, 9808 This day shall gentle his condition: 9809 And gentlemen in England now a-bed 9810 Shall think themselves accursed they were not here, 9811 And hold their manhoods cheap whiles any speaks 9812 That fought with us upon Saint Crispin's day. 9814 This memo is a product of the IETF's Router Requirements 9815 Working Group. A memo such as this one is of necessity the 9816 work of many more people than could be listed here. A wide 9817 variety of vendors, network managers, and other experts from 9818 the Internet community graciously contributed their time and 9819 wisdom to improve the quality of this memo. The editor wishes 9820 to extend sincere thanks to all of them. 9822 The current editor also wishes to single out and extend his 9823 heartfelt gratitude and appreciation to the original editor of 9824 this document; Philip Almquist. Without Philip's work, both 9825 as the original editor and as the Chair of the working group, 9826 this document would not have been produced. He also wishes to 9827 express deep and heartfelt gratitude to the previous editor, 9828 Frank Kastenholz. Frank changed the original document from a 9829 collection of information to a useful description of IP 9830 technology - in his words, a "snapshot" of the technology in 9831 1991. One can only hope that this snapshot, of the technology 9832 in 1994, is as clear. 9834 Philip Almquist, Jeffrey Burgan, Frank Kastenholz, and Cathy 9835 Wittbrodt each wrote major chapters of this memo. Others who 9836 made major contributions to the document included Bill Barns, 9837 Steve Deering, Kent England, Jim Forster, Martin Gross, Jeff 9838 Honig, Steve Knowles, Yoni Malachi, Michael Reilly, and Walt 9839 Wimer. 9841 Additional text came from Andy Malis, Paul Traina, Art 9842 Berggreen, John Cavanaugh, Ross Callon, John Lekashman, Brian 9843 Lloyd, Gary Malkin, Milo Medin, John Moy, Craig Partridge, 9845 Draft Requirements for IP Version 4 Routers March 1995 9847 Stephanie Price, Yakov Rekhter, Steve Senum, Richard Smith, 9848 Frank Solensky, Rich Woundy, and others who have been 9849 inadvertently overlooked. 9851 Some of the text in this memo has been (shamelessly) 9852 plagiarized from earlier documents, most notably RFC-1122 by 9853 Bob Braden and the Host Requirements Working Group, and RFC- 9854 1009 by Bob Braden and Jon Postel. The work of these earlier 9855 authors is gratefully acknowledged. 9857 Jim Forster was a co-chair of the Router Requirements Working 9858 Group during its early meetings, and was instrumental in 9859 getting the group off to a good start. Jon Postel, Bob 9860 Braden, and Walt Prue also contributed to the success by 9861 providing a wealth of good advice before the group's first 9862 meeting. Later on, Phill Gross, Vint Cerf, and Noel Chiappa 9863 all provided valuable advice and support. 9865 Mike St. Johns coordinated the Working Group's interactions 9866 with the security community, and Frank Kastenholz coordinated 9867 the Working Group's interactions with the network management 9868 area. Allison Mankin and K.K. Ramakrishnan provided 9869 expertise on the issues of congestion control and resource 9870 allocation. 9872 Many more people than could possibly be listed or credited 9873 here participated in the deliberations of the Router 9874 Requirements Working Group, either through electronic mail or 9875 by attending meetings. However, the efforts of Ross Callon 9876 and Vince Fuller in sorting out the difficult issues of route 9877 choice and route leaking are especially acknowledged. 9879 The editor thanks his employer, Cisco Systems, for allowing 9880 him to spend the time necessary to produce the 1994 snapshot. 9882 Draft Requirements for IP Version 4 Routers March 1995 9884 Editor's Address 9886 The address of the current editor of this document is 9887 Fred Baker 9888 Cisco Systems 9889 519 Lado Drive 9890 Santa Barbara, California 93111 9891 USA 9893 Phone:+1 805-681-0115 9895 EMail: fred@cisco.com 9897 Draft Requirements for IP Version 4 Routers March 1995 9899 Table of Contents 9901 Status of this Memo .................................... i 9902 0. PREFACE ............................................. 1 9903 1. INTRODUCTION ........................................ 2 9904 1.1 Reading this Document .............................. 4 9905 1.1.1 Organization ..................................... 4 9906 1.1.2 Requirements ..................................... 5 9907 1.1.3 Compliance ....................................... 6 9908 1.2 Relationships to Other Standards ................... 8 9909 1.3 General Considerations ............................. 9 9910 1.3.1 Continuing Internet Evolution .................... 10 9911 1.3.2 Robustness Principle ............................. 10 9912 1.3.3 Error Logging .................................... 11 9913 1.3.4 Configuration .................................... 12 9914 1.4 Algorithms ......................................... 14 9915 2. INTERNET ARCHITECTURE ............................... 15 9916 2.1 Introduction ....................................... 15 9917 2.2 Elements of the Architecture ....................... 16 9918 2.2.1 Protocol Layering ................................ 16 9919 2.2.2 Networks ......................................... 19 9920 2.2.3 Routers .......................................... 19 9921 2.2.4 Autonomous Systems ............................... 20 9922 2.2.5 Addressing Architecture .......................... 21 9923 2.2.5.1 Classical IP Addressing Architecture ........... 21 9924 2.2.5.2 Classless Inter Domain Routing (CIDR) .......... 23 9925 2.2.6 IP Multicasting .................................. 25 9926 2.2.7 Unnumbered Lines and Networks Prefixes ........... 26 9927 2.2.8 Notable Oddities ................................. 27 9928 2.2.8.1 Embedded Routers ............................... 27 9929 2.2.8.2 Transparent Routers ............................ 28 9930 2.3 Router Characteristics ............................. 30 9931 2.4 Architectural Assumptions .......................... 33 9932 3. LINK LAYER .......................................... 36 9933 3.1 INTRODUCTION ....................................... 36 9934 3.2 LINK/INTERNET LAYER INTERFACE ...................... 36 9935 3.3 SPECIFIC ISSUES .................................... 38 9936 3.3.1 Trailer Encapsulation ............................ 38 9937 3.3.2 Address Resolution Protocol - ARP ................ 38 9938 3.3.3 Ethernet and 802.3 Coexistence ................... 38 9939 3.3.4 Maximum Transmission Unit - MTU .................. 39 9940 3.3.5 Point-to-Point Protocol - PPP .................... 39 9941 3.3.5.1 Introduction ................................... 40 9943 Draft Requirements for IP Version 4 Routers March 1995 9945 3.3.5.2 Link Control Protocol (LCP) Options ............ 41 9946 3.3.5.3 IP Control Protocol (IPCP) Options ............. 43 9947 3.3.6 Interface Testing ................................ 43 9948 4. INTERNET LAYER - PROTOCOLS .......................... 45 9949 4.1 INTRODUCTION ....................................... 45 9950 4.2 INTERNET PROTOCOL - IP ............................. 45 9951 4.2.1 INTRODUCTION ..................................... 45 9952 4.2.2 PROTOCOL WALK-THROUGH ............................ 46 9953 4.2.2.1 Options: RFC 791 Section 3.2 ................... 46 9954 4.2.2.2 Addresses in Options: RFC 791 Section 3.1 ...... 50 9955 4.2.2.3 Unused IP Header Bits: RFC 791 Section 3.1 ..... 51 9956 4.2.2.4 Type of Service: RFC 791 Section 3.1 ........... 51 9957 4.2.2.5 Header Checksum: RFC 791 Section 3.1 ........... 51 9958 4.2.2.6 Unrecognized Header Options: RFC 791 Section 9959 3.1 ................................................ 52 9960 4.2.2.7 Fragmentation: RFC 791 Section 3.2 ............. 52 9961 4.2.2.8 Reassembly: RFC 791 Section 3.2 ................ 54 9962 4.2.2.9 Time to Live: RFC 791 Section 3.2 .............. 54 9963 4.2.2.10 Multi-subnet Broadcasts: RFC 922 .............. 55 9964 4.2.2.11 Addressing: RFC 791 Section 3.2 ............... 55 9965 4.2.3 SPECIFIC ISSUES .................................. 59 9966 4.2.3.1 IP Broadcast Addresses ......................... 59 9967 4.2.3.2 IP Multicasting ................................ 60 9968 4.2.3.3 Path MTU Discovery ............................. 61 9969 4.2.3.4 Subnetting ..................................... 62 9970 4.3 INTERNET CONTROL MESSAGE PROTOCOL - ICMP ........... 63 9971 4.3.1 INTRODUCTION ..................................... 63 9972 4.3.2 GENERAL ISSUES ................................... 64 9973 4.3.2.1 Unknown Message Types .......................... 64 9974 4.3.2.2 ICMP Message TTL ............................... 64 9975 4.3.2.3 Original Message Header ........................ 64 9976 4.3.2.4 ICMP Message Source Address .................... 65 9977 4.3.2.5 TOS and Precedence ............................. 65 9978 4.3.2.6 Source Route ................................... 66 9979 4.3.2.7 When Not to Send ICMP Errors ................... 66 9980 4.3.2.8 Rate Limiting .................................. 68 9981 4.3.3 SPECIFIC ISSUES .................................. 69 9982 4.3.3.1 Destination Unreachable ........................ 69 9983 4.3.3.2 Redirect ....................................... 70 9984 4.3.3.3 Source Quench .................................. 70 9985 4.3.3.4 Time Exceeded .................................. 71 9986 4.3.3.5 Parameter Problem .............................. 71 9987 4.3.3.6 Echo Request/Reply ............................. 72 9988 4.3.3.7 Information Request/Reply ...................... 73 9990 Draft Requirements for IP Version 4 Routers March 1995 9992 4.3.3.8 Timestamp and Timestamp Reply .................. 73 9993 4.3.3.9 Address Mask Request/Reply ..................... 75 9994 4.3.3.10 Router Advertisement and Solicitations ........ 76 9995 4.4 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP .......... 77 9996 5. INTERNET LAYER - FORWARDING ......................... 78 9997 5.1 INTRODUCTION ....................................... 78 9998 5.2 FORWARDING WALK-THROUGH ............................ 78 9999 5.2.1 Forwarding Algorithm ............................. 78 10000 5.2.1.1 General ........................................ 79 10001 5.2.1.2 Unicast ........................................ 80 10002 5.2.1.3 Multicast ...................................... 81 10003 5.2.2 IP Header Validation ............................. 83 10004 5.2.3 Local Delivery Decision .......................... 85 10005 5.2.4 Determining the Next Hop Address ................. 88 10006 5.2.4.1 IP Destination Address ......................... 89 10007 5.2.4.2 Local/Remote Decision .......................... 90 10008 5.2.4.3 Next Hop Address ............................... 92 10009 5.2.4.4 Administrative Preference ...................... 96 10010 5.2.4.6 Load Splitting ................................. 99 10011 5.2.5 Unused IP Header Bits: RFC-791 Section 3.1 ....... 99 10012 5.2.6 Fragmentation and Reassembly: RFC-791 Section 10013 3.2 ................................................ 100 10014 5.2.7 Internet Control Message Protocol - ICMP ......... 100 10015 5.2.7.1 Destination Unreachable ........................ 100 10016 5.2.7.2 Redirect ....................................... 103 10017 5.2.7.3 Time Exceeded .................................. 105 10018 5.2.8 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP ........ 105 10019 5.3 SPECIFIC ISSUES .................................... 106 10020 5.3.1 Time to Live (TTL) ............................... 106 10021 5.3.2 Type of Service (TOS) ............................ 107 10022 5.3.3 IP Precedence .................................... 109 10023 5.3.3.1 Precedence-Ordered Queue Service ............... 111 10024 5.3.3.2 Lower Layer Precedence Mappings ................ 111 10025 5.3.3.3 Precedence Handling For All Routers ............ 112 10026 5.3.4 Forwarding of Link Layer Broadcasts .............. 115 10027 5.3.5 Forwarding of Internet Layer Broadcasts .......... 116 10028 5.3.5.1 Limited Broadcasts ............................. 117 10029 5.3.5.2 Directed Broadcasts ............................ 118 10030 5.3.5.3 All-subnets-directed Broadcasts ................ 118 10031 5.3.5.4 Network-Prefix-Directed Broadcasts ............. 119 10032 5.3.6 Congestion Control ............................... 119 10033 5.3.7 Martian Address Filtering ........................ 121 10034 5.3.8 Source Address Validation ........................ 122 10035 5.3.9 Packet Filtering and Access Lists ................ 123 10037 Draft Requirements for IP Version 4 Routers March 1995 10039 5.3.10 Multicast Routing ............................... 124 10040 5.3.11 Controls on Forwarding .......................... 124 10041 5.3.12 State Changes ................................... 125 10042 5.3.12.1 When a Router Ceases Forwarding ............... 125 10043 5.3.12.2 When a Router Starts Forwarding ............... 126 10044 5.3.12.3 When an Interface Fails or is Disabled ........ 127 10045 5.3.12.4 When an Interface is Enabled .................. 127 10046 5.3.13 IP Options ...................................... 127 10047 5.3.13.1 Unrecognized Options .......................... 128 10048 5.3.13.2 Security Option ............................... 128 10049 5.3.13.3 Stream Identifier Option ...................... 128 10050 5.3.13.4 Source Route Options .......................... 129 10051 5.3.13.5 Record Route Option ........................... 129 10052 5.3.13.6 Timestamp Option .............................. 130 10053 6. TRANSPORT LAYER ..................................... 132 10054 6.1 USER DATAGRAM PROTOCOL - UDP ....................... 132 10055 6.2 TRANSMISSION CONTROL PROTOCOL - TCP ................ 132 10056 7. APPLICATION LAYER - ROUTING PROTOCOLS ............... 135 10057 7.1 INTRODUCTION ....................................... 135 10058 7.1.1 Routing Security Considerations .................. 135 10059 7.1.2 Precedence ....................................... 136 10060 7.1.3 Message Validation ............................... 136 10061 7.2 INTERIOR GATEWAY PROTOCOLS ......................... 137 10062 7.2.1 INTRODUCTION ..................................... 137 10063 7.2.2 OPEN SHORTEST PATH FIRST - OSPF .................. 138 10064 7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM - 10065 DUAL IS-IS ......................................... 138 10066 7.3 EXTERIOR GATEWAY PROTOCOLS ........................ 139 10067 7.3.1 INTRODUCTION .................................... 139 10068 7.3.2 BORDER GATEWAY PROTOCOL - BGP .................... 139 10069 7.3.2.1 Introduction ................................... 139 10070 7.3.2.2 Protocol Walk-through .......................... 140 10071 7.3.3 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL 10072 .................................................... 141 10073 7.4 STATIC ROUTING ..................................... 142 10074 7.5 FILTERING OF ROUTING INFORMATION ................... 144 10075 7.5.1 Route Validation ................................. 144 10076 7.5.2 Basic Route Filtering ............................ 145 10077 7.5.3 Advanced Route Filtering ......................... 145 10078 7.6 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE ........ 146 10079 8. APPLICATION LAYER - NETWORK MANAGEMENT PROTOCOLS 10080 .................................................... 148 10081 8.1 The Simple Network Management Protocol - SNMP ...... 148 10082 8.1.1 SNMP Protocol Elements ........................... 148 10084 Draft Requirements for IP Version 4 Routers March 1995 10086 8.2 Community Table .................................... 149 10087 8.3 Standard MIBS ...................................... 150 10088 8.4 Vendor Specific MIBS ............................... 152 10089 8.5 Saving Changes ..................................... 153 10090 9. APPLICATION LAYER - MISCELLANEOUS PROTOCOLS ......... 155 10091 9.1 BOOTP .............................................. 155 10092 9.1.1 Introduction ..................................... 155 10093 9.1.2 BOOTP Relay Agents ............................... 155 10094 10. OPERATIONS AND MAINTENANCE ......................... 157 10095 10.1 Introduction ...................................... 157 10096 10.2 Router Initialization ............................. 159 10097 10.2.1 Minimum Router Configuration .................... 159 10098 10.2.2 Address and Prefix Initialization ............... 160 10099 10.2.3 Network Booting using BOOTP and TFTP ............ 161 10100 10.3 Operation and Maintenance ......................... 162 10101 10.3.1 Introduction .................................... 162 10102 10.3.2 Out Of Band Access .............................. 163 10103 10.3.2 Router O&M Functions ............................ 164 10104 10.3.2.1 Maintenance - Hardware Diagnosis .............. 164 10105 10.3.2.2 Control - Dumping and Rebooting ............... 164 10106 10.3.2.3 Control - Configuring the Router .............. 164 10107 10.3.2.4 Net Booting of System Software ................ 165 10108 10.3.2.5 Detecting and responding to misconfiguration 10109 .................................................... 166 10110 10.3.2.6 Minimizing Disruption ......................... 167 10111 10.3.2.7 Control - Troubleshooting Problems ............ 168 10112 10.4 Security Considerations ........................... 169 10113 10.4.1 Auditing and Audit Trails ....................... 169 10114 10.4.2 Configuration Control ........................... 171 10115 11. REFERENCES ......................................... 173 10116 APPENDIX A. REQUIREMENTS FOR SOURCE-ROUTING HOSTS ...... 186 10117 APPENDIX B. GLOSSARY ................................... 188 10118 APPENDIX C. FUTURE DIRECTIONS .......................... 195 10119 APPENDIX D. Multicast Routing Protocols ................ 198 10120 D.1 Introduction ....................................... 198 10121 D.2 Distance Vector Multicast Routing Protocol - 10122 DVMRP .............................................. 198 10123 D.3 Multicast Extensions to OSPF - MOSPF ............... 199 10124 D.4 Protocol Independent Multicast - PIM ............... 199 10125 APPENDIX E Additional Next-Hop Selection Algorithms 10126 .................................................... 200 10127 E.1. Some Historical Perspective ....................... 200 10128 E.2. Additional Pruning Rules .......................... 202 10129 E.3 Some Route Lookup Algorithms ....................... 204 10131 Draft Requirements for IP Version 4 Routers March 1995 10133 E.3.1 The Revised Classic Algorithm .................... 204 10134 E.3.2 The Variant Router Requirements Algorithm ........ 206 10135 E.3.3 The OSPF Algorithm ............................... 206 10136 E.3.4 The Integrated IS-IS Algorithm ................... 208 10137 Security Considerations ................................ 210 10138 APPENDIX F: HISTORICAL ROUTING PROTOCOLS ............... 212 10139 F.1 EXTERIOR GATEWAY PROTOCOL - EGP .................... 212 10140 F.1.1 Introduction ..................................... 212 10141 F.1.2 Protocol Walk-through ............................ 213 10142 F.2 ROUTING INFORMATION PROTOCOL - RIP ................. 216 10143 F.2.1 Introduction ..................................... 216 10144 F.2.2 Protocol Walk-Through ............................ 216 10145 F.2.3 Specific Issues .................................. 223 10146 F.3 GATEWAY TO GATEWAY PROTOCOL - GGP .................. 224 10147 Acknowledgments ........................................ 225 10148 Editor's Address ....................................... 228