Network Working Group Internet Engineering Task Force INTERNET DRAFT Philip Almquist, Editor October 1, 1991 Requirements for IP Routers | Non-status of This Memo This memo is a product of the IETF's Router Requirements Working Group. To date, this memo has benefitted from over a year of public comment and hard work by a wide range of protocol experts, vendors, and network managers. The authors hope that this memo will be ready to be formally proposed for Internet standardization at the November 1991 IETF meeting. Until then, of course, this memo is NOT a standard. Distribution of this memo is unlimited. Summary The memo is a draft replacement for RFC-1009, "Requirements for Internet Gateways" ([INTRO:1]). It defines and discusses the requirements for devices which perform the network layer forwarding function of the Internet protocol suite. The Internet community usually refers to such devices as "routers". This document is intended to provide guidance for vendors, implementors, and sophisticated purchasers of IP routers. Because this memo is rapidly nearing completion, we would very much appreciate it if you would take the time to read this draft and send us any comments as soon as possible. Instructions for doing so are included on page 3. We would also appreciate it if you would pass this along to colleagues who might be interested, so that this document can also benefit from their opinions and expertise. Internet Engineering Task Force [Page 1] DRAFT PREFACE October 1, 1991 Information for Readers Because this document is nearing completion, we would appreciate prompt feedback from any and all interested parties. Instructions for sending us comments are included on the next page. You may well find it useful to have at hand copies of RFC-1122 and RFC-1009 when reading this document. You may notice that some topic which you believe to be important is either not covered or is discussed only superficially. If you notice such an omission, please help us correct it. At a minimum, please send us a comment; better yet, contribute some text. Because Internet standards are primarily the work of volunteers who have many other professional responsibilities, the system only works if many people contribute a little. It takes very little time to write a few paragraphs, and by doing so you can ensure that your topic isn't one of the ones that gets omitted simply because there's nobody who has the time and energy to write about it (and you can also get your name in the credits section of this document). Topics which we intend to cover but have not yet done so are listed beginning on page 5. If there are topics which you think should be covered but are not listed there, please let us know. As an aid to readers of previous versions of the draft, this draft | uses change bars to highlight recent changes. Changes made since | the previous draft (Internet Draft draft-ietf-rreq-iprouters-02.txt,| dared July 25, 1991) are marked with "|". Please be warned, however: although I have endeavored to make sure that all substantive changes are marked, this process is a manual and therefore not necessarily infallible one. Please also be warned that the comments labelled | SOURCE are generally out of date, and should not be relied on to | acurately describe the relationship between the requirements found in| this document and the requirements found in earlier documents. | Please note also that I have begun the editorial cleanup of the document. Because this cleanup isn't supposed to alter the technical content, I did not mark all of these sections with change bars, but I would nonetheless like those who have time to give me feedback. Internet Engineering Task Force [Page 2] DRAFT PREFACE October 1, 1991 How to Submit Comments Readers of this draft are invited and encouraged to comment and to propose text for inclusion in future versions of this draft. Comments on the technical content should be sent to the IETF Router Requirements Working Group at: ietf-rreq@Jessica.Stanford.EDU. Editorial (non-technical) comments should be sent to the editor at: ietf-rreq-editor@Jessica.Stanford.EDU. Comments which cannot be sent electronically may be sent to: IETF Router Requirements Working Group c/o Philip Almquist 214 Cole Street, Suite 2 San Francisco, CA 94117-1916 USA If your comment pertains to a particular piece of text, please remember to mention the section number as well as the line number(s), since page numbers change frequently as we edit the document. Please also mention the date of this draft (October 1, 1991). We appreciate your help and input in making this a good standard for the Internet. Internet Engineering Task Force [Page 3] DRAFT PREFACE October 1, 1991 Information for Contributors We solicit contributions from everyone and anyone, whether or not they are "experts" or regular participants in the IETF's Router Requirements Working Group. Polish is not required, since we have an editor. Neither is knowing all of the answers; as you will notice, the present draft has a number of comments noting open questions. What should you write about? Ask yourself: do I have any areas of particular expertise related to routers or the protocols they speak? Are there things that I particularly like, or particularly hate, about some existing router implementation(s)? Did I notice when I read the draft that some topics were missing or inadequately covered? Do I have an opinion about any of the numerous open questions posed in the CONTRIBUTOR'S COMMENTS or EDITOR'S COMMENTS sections? In general, I'd also like contributions of DISCUSSION text describing the rationale behind the requirements. Somewhere, there needs to be some discussion of unnumbered point-to-point links. I'm not sure where, but I'll figure that out if somebody will write it. Finally, it has been suggested that we should have an appendix on "Future Directions". Please let me know if you have any questions. Philip Almquist ietf-rreq-editor@Jessica.Stanford.EDU Internet Engineering Task Force [Page 4] DRAFT TO BE DONE October 1, 1991 The following tasks probably should be done, but at this writing nobody has been willing to commit to doing any of them. The editor might do some of them, but the rest will be unceremoneously forgotten unless people step forward to do them: (1) Write Appendix D (an annotated bibliography). (2) Write Appendix E (on future directions), (3) Update Appendix A (configuration parameters) to match the rest of the document. Internet Engineering Task Force [Page 5] DRAFT TO BE DONE October 1, 1991 The following tasks are still to be done, but have people committed to perform them: (1) Determine when/if the RFC on the (DOD) IP security option might be issued. (2) Finish writing the Architecture chapter. Include the assumption that a destination is directly reachable iff it is on the same (sub)net as the sender. (3) Update chapters 5 and 7 to be consistent with "Ruminations on the Next Hop" and "Ruminations on Route Leaking". (4) Update the document to be consistent with "Type of Service in the Internet Protocol" (partially done). (5) Write a discussion of route cacheing schemes. (6) Expand the coverage of security issues. (7) Write some text about load-splitting. Internet Engineering Task Force [Page 6] DRAFT TO BE DONE October 1, 1991 The following issues still need to be addressed by the Router Requirements Working Group: (1) Should we say anything about sending different fragments of the same datagram via different paths? (2) RIP question: what (if anything) should we say about holddowns (the RIP RFC does not mention them)? (3) Resolve a few remaining issues in regard to route selection and route leaking. Internet Engineering Task Force [Page 7] DRAFT TO BE DONE October 1, 1991 The following tasks are to be done by the editor: (1) Shuffle stuff between chapters 4 and 5 so that all the forwarding stuff is in chapter 5 and all of the stuff related to sourcing and sinking datagrams is in chapter 4. (2) Update the SOURCE comments to clarify and more accurately reflect the requirements that differ from those in RFCs 1122, 1123, and 1009. (3) Replace parts of chapter 4 with pointers to similar sections of RFC-1122 (based on Robert Elz's text). (4) Continue general editorial cleanup of the document (suggested improvements to ietf-rreq-editor@Jessica.Stanford.EDU gratefully accepted). (5) Resolve disagreement about packet filtering text. (6) Update NIC phone numbers in INTRO:6 reference to reflect BNIC transfer to GSI. Internet Engineering Task Force [Page 8] DRAFT CONTENTS October 1, 1991 Table of Contents 1. INTRODUCTION ............................................... 14 1.1 Reading this Document .................................. 16 1.1.1 Organization ...................................... 16 1.1.2 Requirements ...................................... 18 1.1.3 Compliance ........................................ 19 1.1.4 Terminology ....................................... 20 1.2 Relationships to Other Standards ....................... 22 1.3 General Considerations ................................. 23 1.3.1 Continuing Internet Evolution ..................... 23 1.3.2 Robustness Principle .............................. 24 1.3.3 Error Logging ..................................... 25 1.3.4 Configuration ..................................... 26 1.3.5 Security Considerations ........................... 27 1.4 Acknowledgments ........................................ 28 2. INTERNET ARCHITECTURE ...................................... 30 2.1 Internet Protocols ..................................... 30 2.1.1 Introduction ...................................... 30 2.1.2 Protocol Layering ................................. 31 2.2 Networks and Routers ................................... 33 2.3 Router Characteristics ................................. 35 2.4 Architectural Miscellany ............................... 38 2.4.1 Autonomous Systems ................................ 38 2.4.2 Addresses and Subnets ............................. 38 2.4.3 IP Multicasting ................................... 40 2.4.4 Networks, Subnets, and Unnumbered Lines ........... 41 2.4.5 Interfaces ........................................ 42 2.4.6 Notable Oddities .................................. 42 2.4.6.1 Embedded Routers ............................. 42 2.4.6.2 Transparent Routers .......................... 43 2.5 Architectural Assumptions .............................. 44 3. LINK LAYER ................................................. 47 3.1 INTRODUCTION ........................................... 47 3.2 SPECIFIC ISSUES ........................................ 48 3.2.1 Trailer Encapsulation ............................. 48 3.2.2 Address Resolution Protocol -- ARP ................ 49 3.2.3 Ethernet and 802.3 Coexistence .................... 49 3.2.4 Maximum Transmission Unit -- MTU .................. 49 3.2.5 Point-to-Point Protocol -- PPP .................... 49 3.2.5.1 Introduction ................................. 50 Internet Engineering Task Force [Page 9] DRAFT CONTENTS October 1, 1991 3.2.5.2 Requirements and Recommendations ............. 50 3.2.6 Interface Testing ................................. 52 3.3 Requirements Summary ................................... 53 4. INTERNET LAYER -- PROTOCOLS ................................ 54 4.1 INTRODUCTION ........................................... 54 4.2 INTERNET PROTOCOL -- IP ................................ 54 4.2.1 INTRODUCTION ...................................... 54 4.2.2 PROTOCOL WALK-THROUGH ............................. 54 4.2.2.1 Options ...................................... 54 4.2.2.2 Unused IP Header Bits ........................ 59 4.2.2.3 Type of Service .............................. 59 4.2.2.4 Header Checksum .............................. 60 4.2.2.5 Unrecognized Header Options .................. 60 4.2.2.6 Fragmentation ................................ 60 4.2.2.7 Reassembly ................................... 62 4.2.2.8 Time to Live ................................. 62 4.2.2.9 Routing of Broadcasts ........................ 62 4.2.2.10 Addressing .................................. 62 4.2.3 SPECIFIC ISSUES ................................... 66 4.2.3.1 IP Broadcast Addresses ....................... 66 4.2.3.2 IP Multicasting .............................. 67 4.2.3.3 Path MTU Discovery ........................... 68 4.3 INTERNET CONTROL MESSAGE PROTOCOL -- ICMP .............. 69 4.3.1 INTRODUCTION ...................................... 69 4.3.2 GENERAL ISSUES .................................... 69 4.3.3 SPECIFIC ISSUES ................................... 73 4.3.3.1 Destination Unreachable ...................... 73 4.3.3.2 Redirect ..................................... 75 4.3.3.3 Source Quench ................................ 77 4.3.3.4 Time Exceeded ................................ 78 4.3.3.5 Parameter Problem ............................ 78 4.3.3.6 Echo Request/Reply ........................... 78 4.3.3.7 Information Request/Reply .................... 79 4.3.3.8 Timestamp and Timestamp Reply ................ 80 4.3.3.9 Address Mask Request/Reply ................... 81 4.3.3.10 Router Advertisement and Solicitations ...... 82 4.4 INTERNET GROUP MANAGEMENT PROTOCOL -- IGMP ............. 83 4.5 REQUIREMENTS SUMMARY ................................... 83 5. INTERNET LAYER -- FORWARDING ............................... 84 5.1 INTRODUCTION ........................................... 84 5.2 FORWARDING WALK-THROUGH ................................ 84 5.2.1 Forwarding Algorithm .............................. 84 5.2.2 IP Header Validation .............................. 88 5.2.3 Local Delivery Decision ........................... 90 5.2.4 Determining the Next Hop Address .................. 93 5.2.4.1 Immediate Destination Address ................ 93 Internet Engineering Task Force [Page 10] DRAFT CONTENTS October 1, 1991 5.2.4.2 Local/Remote Decision ........................ 94 5.2.4.3 Next Hop Address ............................. 95 5.2.5 Addresses in Options .............................. 97 5.3 SPECIFIC ISSUES ........................................ 98 5.3.1 Time to Live (TTL) ................................ 98 5.3.2 Type of Service (TOS) ............................. 99 5.3.3 IP Precedence ..................................... 101 5.3.3.1 Precedence-Ordered Queue Service ............. 102 5.3.3.2 Lower Layer Precedence Mappings .............. 103 5.3.3.3 Precedence Handling For All Routers .......... 103 5.3.4 Forwarding of Link Layer Broadcasts ............... 106 5.3.5 Forwarding of Internet Layer Broadcasts ........... 107 5.3.5.1 Limited Broadcasts ........................... 108 5.3.5.2 Net-directed Broadcasts ...................... 108 5.3.5.3 All-subnets-directed Broadcasts .............. 109 5.3.5.4 Subnet-directed Broadcasts ................... 111 5.3.6 Congestion Control ................................ 111 5.3.7 Martian Address Filtering ......................... 113 5.3.8 Source Address Validation ......................... 114 5.3.9 Packet Filtering and Access Lists ................. 114 5.3.10 Multicast Routing ................................ 115 5.3.11 Controls on Forwarding ........................... 115 5.3.12 State Changes .................................... 116 5.3.12.1 When a Router Ceases Forwarding ............. 116 5.3.12.2 When an Interfaces Fails or is Disabled ..... 117 5.3.12.3 When an Interface is Enabled ................ 117 5.4 REQUIREMENTS SUMMARY ................................... 118 6. TRANSPORT LAYER ............................................ 119 6.1 USER DATAGRAM PROTOCOL -- UDP .......................... 119 6.2 TRANSMISSION CONTROL PROTOCOL -- TCP ................... 120 6.3 REQUIREMENTS SUMMARY ................................... 121 7. APPLICATION LAYER -- ROUTING PROTOCOLS ..................... 122 7.1 INTRODUCTION ........................................... 122 7.1.1 Routing Security Considerations ................... 122 7.2 INTERIOR GATEWAY PROTOCOLS ............................. 123 7.2.1 INTRODUCTION ...................................... 123 7.2.2 OPEN SHORTEST PATH FIRST -- OSPF .................. 124 7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM ........ 124 7.2.4 ROUTING INFORMATION PROTOCOL -- RIP ............... 124 7.2.4.1 Introduction ................................. 124 7.2.4.2 Protocol Walk-Through ........................ 125 7.2.4.3 Specific Issues .............................. 130 7.2.5 GATEWAY TO GATEWAY PROTOCOL -- GGP ................ 130 7.3 EXTERIOR GATEWAY PROTOCOLS ............................. 131 7.3.1 INTRODUCTION ...................................... 131 7.3.2 BORDER GATEWAY PROTOCOL -- BGP .................... 131 Internet Engineering Task Force [Page 11] DRAFT CONTENTS October 1, 1991 7.3.2.1 Introduction ................................. 131 7.3.2.2 Protocol Walk-through ........................ 132 7.3.3 EXTERIOR GATEWAY PROTOCOL -- EGP .................. 133 7.3.3.1 Introduction ................................. 133 7.3.3.2 Protocol Walk-through ........................ 133 7.3.4 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL ..... 136 7.4 Multicast routing protocols ............................ 136 7.4.1 Introduction ...................................... 137 7.4.2 DVMRP (Distance Vector Multicast Routing Protoc ... 137 7.4.3 MOSPF (Multicast extensions to OSPF) .............. 137 7.5 STATIC ROUTING ......................................... 137 7.6 FILTERING OF ROUTING INFORMATION ....................... 139 7.6.1 Route Validation .................................. 140 7.6.2 Basic Route Filtering ............................. 140 7.6.3 Advanced Route Filtering .......................... 141 7.7 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE ............ 142 7.8 REQUIREMENTS SUMMARY ................................... 143 8. APPLICATION LAYER -- NETWORK MANAGEMENT PROTOCOLS .......... 144 8.1 The Simple Network Management Protocol -- SNMP ......... 144 8.1.1 SNMP Protocol Elements ............................ 144 8.2 Community Table ........................................ 145 8.3 Standard MIBS .......................................... 146 8.4 Vendor Specific MIBS ................................... 147 8.5 Saving Changes ......................................... 148 8.6 REQUIREMENTS SUMMARY ................................... 148 9. APPLICATION LAYER -- MISCELLANEOUS PROTOCOLS ............... 149 9.1 Bootstrap Protocol (BOOTP) ............................. 149 9.1.1 Introduction ...................................... 149 9.1.2 BOOTP Relay Agents ................................ 149 9.2 REQUIREMENTS SUMMARY ................................... 150 10. OPERATIONS AND MAINTENANCE ................................ 151 10.1 Introduction .......................................... 151 10.2 Router Initialization ................................. 152 10.2.1 Minimum Router Configuration ..................... 152 10.2.2 Address and Address Mask Initialization .......... 153 10.2.3 Network Booting using BOOTP and TFTP ............. 154 10.3 Operation and Maintenance ............................. 155 10.3.1 Router O&M Models ................................ 155 10.3.2 Router O&M Functions ............................. 157 10.3.3 Router Hardware and Software Diagnostics ......... 162 10.4 Security Considerations ............................... 163 10.4.1 Auditing and Audit Trails ........................ 163 10.4.2 Configuration Control ............................ 164 10.5 REQUIREMENTS SUMMARY .................................. 164 Internet Engineering Task Force [Page 12] DRAFT CONTENTS October 1, 1991 11. REFERENCES ................................................ 165 APPENDIX A. CONFIGURATION PARAMETERS .......................... 174 A.1 Required Configuration Parameters ...................... 174 A.2 Recommended Configuration Parameters ................... 175 APPENDIX B. REQUIREMENTS FOR SOURCE-ROUTING HOSTS ............. 176 APPENDIX C. GLOSSARY .......................................... 178 APPENDIX D. BIBLIOGRAPHY ...................................... 189 APPENDIX E. FUTURE DIRECTIONS ................................. 190 APPENDIX F. INDEX ............................................. 191 Internet Engineering Task Force [Page 13] DRAFT INTRODUCTION October 1, 1991 1. INTRODUCTION 1 SOURCE: 2 Chapter 1 source: RFC-1122 chapter 1 3 Relationship to HRRFC: A heavily hacked up version of the intro 4 from RFC-1122, adjusted to reflect the fact that this document 5 is about routers rather than hosts and to delete the Internet 6 architecture discussion (since that is a separate chapter in 7 this document). 8 The only known area of possible non-alignment with the HRRFCs is 9 the definition of compliance. This document includes a longer, 10 more detailed, but (Almquist believes) basically compatible 11 description of compliance. 12 This DRAFT defines and discusses requirements for devices which 13 perform the network layer forwarding function of the Internet 14 protocol suite. The Internet community usually refers to such | 15 devices as "IP routers" or simply "routers"; The OSI community refers | 16 to such devices as "intermediate systems". Many older Internet | 17 documents refer to these devices as "gateways", a name which more | 18 recently has largely passed out of favor to avoid confusion with | 19 application gateways. | 20 An IP router can be distinguished from other sorts of packet | 21 switching devices in that a router examines the IP protocol header as | 22 part of the switching process. It generally has to modify the IP | 23 header and to strip off and replace the Link Layer framing. 24 The authors of this memo recognize, as should its readers, that many 25 routers support multiple protocol suites, and that support for 26 multiple protocol suites will be required in increasingly large parts 27 of the Internet in the future. This memo, however, does not attempt 28 to specify Internet requirements for protocol suites other than 29 TCP/IP. 30 This DRAFT enumerates standard protocols that a router connected to 31 the Internet must use, and it incorporates by reference the RFCs and 32 other documents describing the current specifications for these 33 protocols. It corrects errors in the referenced documents and adds 34 additional discussion and guidance for an implementor. 35 For each protocol, this memo also contains an explicit set of 36 requirements, recommendations, and options. The reader must 37 understand that the list of requirements in this memo is incomplete 38 by itself; the complete set of requirements for an Internet protocol 39 router is primarily defined in the standard protocol specification Internet Engineering Task Force [Page 14] DRAFT INTRODUCTION October 1, 1991 40 documents, with the corrections, amendments, and supplements 41 contained in this DRAFT. 42 This memo should be read in conjunction with [INTRO:2] and [INTRO:3], 43 which define the requirements for Internet hosts. Internet hosts and 44 routers must both be capable of originating IP datagrams and 45 receiving IP datagrams destined for them. The major distinction 46 between Internet hosts and routers is that routers are required to 47 implement forwarding algorithms and Internet hosts do not require 48 forwarding capabilities. Any Internet host acting as a router must 49 adhere to the requirements contained in this memo. 50 The goal of "open system interconnection" dictates that routers must 51 function correctly as Internet hosts when necessary. In order to 52 achieve such interconnection, this memo provides guidelines for 53 instances in which routers act as Internet hosts. For simplification 54 and ease of document updates, this memo avoids overlapping 55 discussions of host requirements with [INTRO:2] and [INTRO:3], but 56 references the documents where necessary. Each major section in this 57 memo contains a subsection which enumerates all applicable scenarios 58 in which a router must act as an Internet host, and specifies 59 acceptable actions in such cases. 60 EDITOR'S COMMENTS: 61 The previous sentence isn't yet(!) true 62 This memo is intended to provide guidance for vendors, implementors, 63 and users of Internet communication software. It represents the 64 consensus of a large body of technical experience and wisdom, 65 contributed by the members of the Internet research and vendor 66 communities. 67 A good-faith implementation of the protocols that was produced after 68 careful reading of the RFCs and with some interaction with the 69 Internet technical community, and that followed good communications 70 software engineering practices, should differ from the requirements 71 of this memo in only minor ways. Thus, in many cases, the 72 "requirements" in this DRAFT are already stated or implied in the 73 standard protocol documents, so that their inclusion here is, in a 74 sense, redundant. However, they were included because some past 75 implementation has made the wrong choice, causing problems of 76 interoperability, performance, and/or robustness. 77 This memo includes discussion and explanation of many of the 78 requirements and recommendations. A simple list of requirements 79 would be dangerous, because: 80 o Some required features are more important than others, and some Internet Engineering Task Force [Page 15] DRAFT INTRODUCTION October 1, 1991 81 features are optional. 82 o Some features are critical in some applications of routers but 83 irrelevant in others. 84 o There may be valid reasons why particular vendor products that 85 are designed for restricted contexts might choose to use 86 different specifications. 87 However, the specifications of this memo must be followed to meet the 88 general goal of arbitrary router interoperation across the diversity 89 and complexity of the Internet system. Although most current 90 implementations fail to meet these requirements in various ways, some 91 minor and some major, this specification is the ideal towards which 92 we need to move. 93 These requirements are based on the current level of Internet 94 architecture. This memo will be updated as required to provide 95 additional clarifications or to include additional information in 96 those areas in which specifications are still evolving. 1.1 Reading this Document 1.1.1 Organization 1 This memo emulates the layerist organization used by [INTRO:2] 2 and [INTRO:3]. Thus, Chapter 2 describes the layers found in 3 the Internet architecture. Chapter 3 covers the Link Layer. 4 Chapters 4 and 5 are concerned with the Internet Layer 5 protocols and routing. Chapter 6 covers the Transport Layer. 6 Upper layer protocols are divided between Chapter 7, which 7 discusses the protocols which routers use to exchange routing 8 information with each other, Chapter 8, which discusses the 9 vitally important area of network management, and Chapter 9, 10 which discusses other upper layer protocols. The final chapter 11 covers operations and maintenance features. This layerist 12 organization was chosen for simplicity, clarity, and 13 consistency with the Host Requirements RFCs. 14 In describing the rules, we assume that an implementation does 15 strictly mirror the layering of the protocols. However, strict 16 layering is an imperfect model, both for the protocol suite and 17 for recommended implementation approaches. Protocols in 18 different layers interact in complex and sometimes subtle ways, 19 and particular functions often involve multiple layers. There 20 are many design choices in an implementation, many of which 21 involve creative "breaking" of strict layering. Every 22 implementor is urged to read references [INTRO:4] and Internet Engineering Task Force [Page 16] DRAFT INTRODUCTION October 1, 1991 23 [INTRO:5]. 24 In general, each major section of this memo is organized into 25 the following subsections: 26 (1) Introduction 27 (2) Protocol Walk-Through -- considers the protocol 28 specification documents section-by-section, correcting 29 errors, stating requirements that may be ambiguous or 30 ill-defined, and providing further clarification or 31 explanation. 32 (3) Specific Issues -- discusses protocol design and 33 implementation issues that were not included in the walk- 34 through. 35 Under many of the individual topics in this memo, there is 36 parenthetical material labeled "DISCUSSION" or 37 "IMPLEMENTATION". This material is intended to give 38 clarification and explanation of the preceding requirements 39 text. It also includes some suggestions on possible future 40 directions or developments. The implementation material 41 contains suggested approaches that an implementor may want to 42 consider. The DISCUSSION and IMPLEMENTATION sections are not 43 part of the standard. 44 EDITOR'S COMMENTS: 45 Draft versions of this memo also contain parenthetical 46 material labeled CONTRIBUTOR'S COMMENTS, EDITOR'S 47 COMMENTS, and SOURCE. These are included only for the 48 convenience of the authors, the editor, and the Router 49 Requirements Working Group. They are also not part of the 50 standard, and will be removed before this memo is 51 submitted to the RFC editor. 52 Each chapter concludes with a table summarizing the 53 requirements included in that chapter and a list of references. 54 The summary tables are intended to be guides and indexes to the 55 text, but are necessarily cryptic and incomplete. The 56 summaries should never be used or referenced separately from 57 the complete DRAFT. Appendices to this memo include a summary 58 of required router configuration parameters, a bibliography, a 59 glossary, some conjectures about future directions of router 60 standards, and an index. 61 EDITOR'S COMMENTS: 62 I have not yet created the summary tables, but they are Internet Engineering Task Force [Page 17] DRAFT INTRODUCTION October 1, 1991 63 expected to be similar in style to those in RFC-1122 and 64 RFC-1123. 1.1.2 Requirements 1 In this memo, the words that are used to define the 2 significance of each particular requirement are capitalized. 3 These words are: 4 o "MUST" 5 This word means that the item is an absolute requirement 6 of the specification. 7 o "MUST IMPLEMENT" 8 This phrase means that this specification requires that 9 the item be implemented, but does not require that it be 10 enabled by default. 11 o "MUST NOT" 12 This phrase means that the item is an absolute prohibition 13 of the specification. 14 o "SHOULD" 15 This word means that there may exist valid reasons in 16 particular circumstances to ignore this item, but the full 17 implications should be understood and the case carefully 18 weighed before choosing a different course. 19 o "SHOULD IMPLEMENT" 20 This phrase is similar in meaning to SHOULD, but is used 21 when we recommend that a particular feature be provided 22 but don't necessarily recommend that it be enabled by 23 default. 24 o "SHOULD NOT" 25 This phrase means that there may exist valid reasons in 26 particular circumstances when the listed behavior is 27 acceptable or even useful, but the full implications 28 should be understood and the case carefully weighed before 29 implementing any behavior described with this label. 30 o "MAY" Internet Engineering Task Force [Page 18] DRAFT INTRODUCTION October 1, 1991 31 This word means that this item is truly optional. One 32 vendor may choose to include the item because a particular 33 marketplace requires it or because it enhances the 34 product, for example; another vendor may omit the same 35 item. 1.1.3 Compliance 1 Some requirements are applicable to all routers. Other 2 requirements are applicable only to those which implement 3 particular features or protocols. In the following paragraphs, 4 "relevant" refers to the union of the requirements applicable 5 to all routers and the set of requirements applicable to a 6 particular router because of the set of features and protocols 7 it has implemented. 8 Note that not all relevant requirements are stated directly in | 9 this memo. Various parts of this memo incorporate by reference | 10 sections of the Host Requirements specification, [INTRO:2] and | 11 [INTRO:3]. For purposes of determining compliance with this | 12 memo, it is irrelevant whether a relevant requirement is stated | 13 directly in this memo or merely incorporated by reference from | 14 one of those documents. | 15 An implementation is said to be "conditionally compliant" if it 16 satisfies all of the relevant MUST, MUST IMPLEMENT, and MUST 17 NOT requirements. An implementation is said to be 18 "unconditionally compliant" if it is conditionally compliant 19 and also satisfies all of the relevant SHOULD, SHOULD 20 IMPLEMENT, and SHOULD NOT requirements. An implementation is 21 not compliant if it is not conditionally compliant (i.e., it 22 fails to satisfy one or more of the relevant MUST, MUST 23 IMPLEMENT, or MUST NOT requirements). 24 For any of the SHOULD and SHOULD NOT requirements, a router may 25 provide a configuration option that will cause the router to 26 act other than as specified by the SHOULD or SHOULD NOT 27 requirement. Having such configuration options does not void a 28 router's claim to unconditional compliance as long as each of 29 these options has a default setting, and that leaving each of 30 these options at its default value causes the router to operate 31 in a manner which meets all of the relevant MUST, MUST NOT, 32 SHOULD, and SHOULD NOT requirements. 33 Likewise, routers may provide, except where explicitly 34 prohibited by this memo, options which cause them to violate 35 MUST or MUST NOT requirements. A router which provides such 36 options is not compliant (either fully or conditionally) unless Internet Engineering Task Force [Page 19] DRAFT INTRODUCTION October 1, 1991 37 each such option has a default setting which causes the router 38 to conform to the requirements of this memo. Please note that 39 the authors of this memo, although aware of market realities, 40 strongly recommend against provision of such options. 41 Requirements are labeled MUST or MUST NOT because experts in 42 the field have judged them to be particularly important to 43 interoperability or proper functioning in the Internet. 44 Vendors should weigh carefully the customer support costs of 45 providing options which violate those rules. 46 Of course, this memo is not a complete specification of an IP | 47 router, but rather is closer to what in the OSI world is called | 48 a profile. For example, specification requires that a number | 49 of protocols be implemented. Although most of the contents of | 50 their protocol specifications are not repeated in this memo, | 51 implemetors are nonetheless required to implement the protocols | 52 according to those specifications. | 53 AUTHOR'S COMMENTS: 54 There's a problem with the distinction between MUST/SHOULD 55 be implemented and MUST/SHOULD be enabled. In response to 56 this problem, I have added the MUST IMPLEMENT and SHOULD 57 IMPLEMENT terms, but we need to figure out which 58 requirements in this document should be changed to use 59 these new terms. 1.1.4 Terminology 1 This memo uses the following technical terms: 2 IP datagram 3 An IP datagram is the unit of end-to-end transmission in 4 the IP protocol. An IP datagram consists of an IP header 5 followed by transport layer data, i.e., of an IP header 6 followed by a message. 7 In this memo, the unqualified term "datagram" should be 8 understood to refer to an IP datagram. 9 Packet 10 A packet is the unit of data passed across the interface 11 between the internet layer and the link layer. It 12 includes an IP header and data. A packet may be a 13 complete IP datagram or a fragment of an IP datagram. 14 Frame 15 A frame is the unit of transmission in a link layer 16 protocol, and consists of a link-layer header followed by Internet Engineering Task Force [Page 20] DRAFT INTRODUCTION October 1, 1991 17 a packet. 18 Connected network 19 A network to which a router is interfaced is often known 20 as the "local network" or the "subnetwork" relative to 21 that router. However, these terms can cause confusion, 22 and therefore we use the term "connected network" in this 23 memo. 24 Connected (sub)network 25 A connected (sub)network is an IP subnet to which a router 26 is interfaced, or a connected network if the connected 27 network is not subnetted. 28 Physical network 29 A physical network is a network (or a piece of an 30 internet) which is contiguous at the Link Layer. Its 31 internal structure (if any) is therefore transparent to 32 the Internet Layer. 33 Physical network interface 34 This is a physical interface to a connected network and 35 has a (possibly unique) link-layer address. Multiple 36 physical network interfaces on a single router may share 37 the same link-layer address, but the address must be 38 unique for different routers on the same physical network. 39 Logical [network] interface 40 We define a logical [network] interface to be a logical 41 path, distinguished by a unique IP address, to a connected 42 network. See Section [????] 43 Specific-destination address 44 This is defined to be the destination address in the IP 45 header unless the header contains an IP broadcast or IP 46 multicast address, in which case the specific-destination 47 is an IP address assigned to the physical interface on 48 which the packet arrived. 49 Path 50 At a given moment, all the IP packets from a particular 51 router to a particular destination host will typically 52 traverse the same sequence of routers. We use the term 53 "path" for this sequence. Note that a path is uni- 54 directional; it is not unusual to have different paths in 55 the two directions between a given host pair. 56 MTU Internet Engineering Task Force [Page 21] DRAFT INTRODUCTION October 1, 1991 57 The maximum transmission unit, i.e., the size of the | 58 largest packet that can be transmitted or received through | 59 a logical interface. The size includes the IP protocol | 60 header but does not include the size of any Link Layer | 61 headers or framing. | 62 Silently discard | 63 This memo specifies several case where a router is to 64 "silently discard" a received packet (or datagram). This 65 means that the router should discard the packet without 66 further processing, and that the router will not send any 67 ICMP error message (see Section [4.3.2]) as a result. 68 However, for diagnosis of problems, the router SHOULD 69 provide the capability of logging the error (see Section 70 [1.3.3]), including the contents of the silently-discarded 71 packet, and SHOULD record the event in a statistics 72 counter. 73 Silently ignore 74 A router is said to "silently ignore" an error or 75 condition if it takes no action other than possibly 76 generating an error report in an error log or via some 77 network management protocol, and discarding, or ignoring, 78 the source of the error. In particular, the router does 79 NOT generate an ICMP error message. 80 EDITOR'S COMMENTS: 81 Most of the above list is the subset of the definitions 82 from the introduction to RFC-1122 which seemed as if they 83 might be useful. When this document matures somewhat, we 84 should revisit the above list. 1.2 Relationships to Other Standards 1 SOURCE: 2 Section 1.2 source: RFC-1130 section 4 3 Content is almost identical to RFC-1130, except that 4 irrelevant information was deleted and references to the 5 current RFC numbers for the documents listed below were 6 deleted (as likely to become obsolete faster than this memo). 7 There are several reference documents of interest in checking the 8 current status of protocol specifications and standardization: | 9 o IAB Official Protocols | 10 This document describes the Internet standards process and | Internet Engineering Task Force [Page 22] DRAFT INTRODUCTION October 1, 1991 11 lists the standards status of the protocols. 12 o Assigned Numbers 13 This document lists the assigned values of the parameters 14 used in the various protocols. For example, IP protocol 15 codes, TCP port numbers, Telnet Option Codes, ARP hardware 16 types, and Terminal Type names. 17 o Official Protocols 18 This document lists the protocols and describes any known 19 problems and ongoing experiments. 20 o Host Requirements 21 This pair of documents reviews the specifications that apply 22 to hosts and supplies guidance and clarification for any 23 ambiguities. Note that these requirements also apply to 24 routers, except where otherwise specified in this memo. 25 o Link Layer Requirements (proposed document) 26 This document reviews the specifications that apply to the 27 use of the Link Layer by routers and other IP entities. 28 o Router Requirements (formerly Gateway Requirements) 29 This memo. 30 Note that these documents are revised and updated at different 31 times; in case of differences between these documents, the most 32 recent must prevail. 33 Reference [INTRO:6] describes several procedures for obtaining 34 Internet protocol documents. 1.3 General Considerations 1 There are several important lessons that vendors of Internet 2 software have learned and which a new vendor should consider 3 seriously. 1.3.1 Continuing Internet Evolution 1 The enormous growth of the Internet has revealed problems of 2 management and scaling in a large datagram-based packet 3 communication system. These problems are being addressed, and Internet Engineering Task Force [Page 23] DRAFT INTRODUCTION October 1, 1991 4 as a result there will be continuing evolution of the 5 specifications described in this memo. Because routers play 6 such a crucial role in the Internet, and because the number of 7 routers deployed in the Internet is much smaller than the 8 number of hosts, vendors should expect that router standards 9 will continue to evolve much more quickly than host standards. 10 These changes will be carefully planned and controlled, since 11 there is extensive participation in this planning by the 12 vendors and by the organizations responsible for operation of 13 the networks. 14 Development, evolution, and revision are characteristic of 15 computer network protocols today, and this situation will 16 persist for some years. A vendor who develops computer 17 communication software for the Internet protocol suite (or any 18 other protocol suite!) and then fails to maintain and update 19 that software for changing specifications is going to leave a 20 trail of unhappy customers. The Internet is a large 21 communication network, and the users are in constant contact 22 through it. Experience has shown that knowledge of 23 deficiencies in vendor software propagates quickly through the 24 Internet technical community. 1.3.2 Robustness Principle 1 At every layer of the protocols, there is a general rule (from 2 [TRANS:2] by Jon Postel) whose application can lead to enormous 3 benefits in robustness and interoperability: 4 "[B]e conservative in what you do, | 5 be liberal in what you accept from others." | 6 EDITOR'S COMMENTS: | 7 RFC-1122 attributes a quote similar to the above to RFC- | 8 791, but no such quote appears there. This needs to be | 9 added to the errata list for RFC-1122. | 10 Software should be written to deal with every conceivable 11 error, no matter how unlikely; sooner or later a packet will 12 come in with that particular combination of errors and 13 attributes, and unless the software is prepared, chaos can 14 ensue. In general, it is best to assume that the network is 15 filled with malevolent entities that will send in packets 16 designed to have the worst possible effect. This assumption 17 will lead to suitably protective design, although the most 18 serious problems in the Internet have been caused by 19 unenvisaged mechanisms triggered by low-probability events; 20 mere human malice would never have taken so devious a course! Internet Engineering Task Force [Page 24] DRAFT INTRODUCTION October 1, 1991 21 EDITOR'S COMMENTS: 22 "unenvisaged mechanisms": bad wording; Deering suggests 23 "unanticipated mechanisms" 24 Adaptability to change must be designed into all levels of 25 router software. As a simple example, consider a protocol 26 specification that contains an enumeration of values for a 27 particular header field -- e.g., a type field, a port number, 28 or an error code; this enumeration must be assumed to be 29 incomplete. If the protocol specification defines four 30 possible error codes, the software must not break when a fifth 31 code shows up. An undefined code might be logged (see below), 32 but it must not cause a failure. 33 The second part of the principle is almost as important: 34 software on hosts or other routers may contain deficiencies 35 that make it unwise to exploit legal but obscure protocol 36 features. It is unwise to stray far from the obvious and 37 simple, lest untoward effects result elsewhere. A corollary of 38 this is "watch out for misbehaving hosts"; router software 39 should be prepared to survive in the presence of misbehaving 40 hosts. An important function of routers in the Internet is to 41 limit the amount of disruption such hosts can inflict on the 42 shared communication facility. 1.3.3 Error Logging 1 The Internet includes a great variety of systems, each 2 implementing many protocols and protocol layers, and some of 3 these contain bugs and misfeatures in their Internet protocol 4 software. As a result of complexity, diversity, and 5 distribution of function, the diagnosis of Internet problems is 6 often very difficult. 7 Problem diagnosis will be aided if routers include a carefully 8 designed facility for logging erroneous or "strange" protocol 9 events. It is important to include as much diagnostic 10 information as possible when an error is logged. In 11 particular, it is often useful to record the header(s) of a 12 packet that caused an error. However, care must be taken to 13 ensure that error logging does not consume prohibitive amounts 14 of resources or otherwise interfere with the operation of the 15 router. 16 There is a tendency for abnormal but harmless protocol events 17 to overflow error logging files; this can be avoided by using a 18 "circular" log, or by enabling logging only while diagnosing a 19 known failure. It may be useful to filter and count duplicate Internet Engineering Task Force [Page 25] DRAFT INTRODUCTION October 1, 1991 20 successive messages. One strategy that seems to work well is 21 to both: | 22 o always count abnormalities and make such counts accessible | 23 through the management protocol (see Chapter [8]); and 24 o allow the logging of a great variety of events to be 25 selectively enabled. For example, it might useful to be 26 able to "log everything" or to "log everything for host 27 X". 28 This topic is further discussed in [NETMAN:7]. 29 Note that different managements may have differing policies 30 about the amount of error logging that they want normally 31 enabled in a router. Some will say, "if it doesn't hurt me, I 32 don't want to know about it", while others will want to take a 33 more watchful and aggressive attitude about detecting and 34 removing protocol abnormalities. 1.3.4 Configuration 1 In an ideal world, routers would be easy to configure, and 2 perhaps even entirely self-configuring. However, practical 3 experience in the real world suggests that this is an 4 impossible goal, and that in fact many attempts by vendors to 5 make configuration easy actually cause customers more grief 6 than they prevent. As an extreme example, a router which was 7 designed so that it could come up and start routing packets 8 without requiring any configuration information at all would 9 almost certainly choose some incorrect parameter which could 10 cause serious problems on any networks unfortunate enough to be 11 connected to it. 12 At many points in this memo, you will find a requirement that a 13 parameter be a configurable option. There are several 14 different reasons behind such requirements. In a few cases, 15 there is current uncertainty or disagreement about the best 16 value, and it may be necessary to update the recommended value 17 in the future. In other cases, the value really depends on 18 external factors -- e.g., the distribution of its communication 19 load, or the speeds and topology of nearby networks -- and 20 self-tuning algorithms are unavailable and may be insufficient. 21 In some cases, configurability is needed because of 22 administrative requirements. 23 Finally, some configuration options are required to communicate 24 with obsolete or incorrect implementations of the protocols, Internet Engineering Task Force [Page 26] DRAFT INTRODUCTION October 1, 1991 25 distributed without sources, that unfortunately persist in many 26 parts of the Internet. To make correct systems coexist with 27 these faulty systems, administrators occasionally have to 28 misconfigure the correct systems. This problem will correct 29 itself gradually as the faulty systems are retired, but cannot 30 be ignored by vendors. 31 When we say that a parameter must be configurable, we do not 32 intend to require that its value be explicitly read from a 33 configuration file at every boot time. For many parameters, 34 there is one value that is appropriate for all but the most 35 unusual situations. In such cases, it is quite reasonable that 36 the parameter default to that value if not explicitly set. 37 This memo requires a particular value for such defaults in some 38 cases. The choice of default is a sensitive issue when the 39 configuration item controls the accommodation to existing 40 faulty systems. If the Internet is to converge successfully to 41 complete interoperability, the default values built into 42 implementations must implement the official protocol, not 43 misconfigurations to accommodate faulty implementations. 44 Although marketing considerations have led some vendors to 45 choose misconfiguration defaults, we urge vendors to choose 46 defaults that will conform to the standard. 47 Finally, we note that a vendor needs to provide adequate 48 documentation on all configuration parameters, their limits and 49 effects. 1.3.5 Security Considerations 1 "Security" means different things to different people. 2 Security from a router's point of view is anything that helps 3 to keep its own networks operational and in addition helps to 4 keep the Internet as a whole healthy. For the purposes of this 5 document, the security services we are concerned with are 6 "denial of service", "integrity", and "authentication" as it 7 applies to the first two. "Privacy" as a security service is 8 important, but only peripherally a concern of a router -- at 9 least as of the date of this document. 10 Throughout this document you will find sections or subsections 11 entitled "... Security Considerations". In general, these 12 sections contain "motherhood" rather than hard and fast rules 13 and implementation guidelines or requirements. Rarely will we 14 say "do this and your router/network will be secure". More 15 likely, we'll say "this is a good idea and if you do it, it 16 *may* improve the security of the Internet and your local Internet Engineering Task Force [Page 27] DRAFT INTRODUCTION October 1, 1991 17 system in general." 18 Unfortunately, this is the state-of-the-art AT THIS TIME. Few 19 if any of the network protocols a router is concerned with have 20 reasonable, built-in security features. Industry and the 21 protocol designers have been and are continuing to struggle 22 with these issues. There is progress, but only small baby 23 steps such as the peer-to-peer authentication available in the 24 BGP and OSPF routing protocols. 25 Notwithstanding all of the above, there are things both vendors 26 and users can do to improve the security of their boxes. 27 Vendors should get a copy of "Trusted Computer System 28 Interpretation" [INTRO:8]. Even if a vendor decides not to 29 submit his box for formal verification under these guidelines, 30 the publication provides excellent guidance on general security 31 design and practices for computing devices. 1.4 Acknowledgments 1 This memo is a product of the IETF's Router Requirements Working 2 Group. A memo such as this one is of necessity the work of many 3 more people than could be listed here. A wide variety of vendors, 4 network managers, and other experts from the Internet community 5 graciously contributed their time and wisdom to improve the 6 quality of this memo. The editor wishes to extend sincere thanks 7 to all of them. 8 Philip Almquist, Jeffrey Burgan, Frank Kastenholz, and Cathy 9 Wittbrodt each authored major chapters of this memo. Others who 10 made major contributions to the document included Bill Barns, 11 Steve Deering, Kent England, Jim Forster, Martin Gross, Jeff 12 Honig, Stev Knowles, Yoni Malachi, Michael Reilly, and Walt Wimer. 13 Additional text came from Art Berggreen, John Cavanaugh, Ross 14 Callon, John Lekashman, Brian Lloyd, Gary Malkin, Milo Medin, John 15 Moy, Craig Partridge, Stephanie Price, Yakov Rekhter, Steve Senum, 16 Richard Smith, Frank Solensky, Rich Woundy, (and probably others 17 whom I have overlooked). 18 Some of the text in this memo has been (shamelessly) plagiarized 19 from earlier documents, most notably RFC-1122 by Bob Braden and 20 the Host Requirements Working Group, and RFC-1009 by Bob Braden 21 and Jon Postel. The work of these earlier authors is gratefully 22 acknowledged. 23 Jim Forster was a co-chair of the Router Requirements Working 24 Group during its early meetings, and was instrumental in getting Internet Engineering Task Force [Page 28] DRAFT INTRODUCTION October 1, 1991 25 the group off to a good start. Jon Postel, Bob Braden, and Walt 26 Prue also contributed to the success by providing a wealth of good 27 advice prior to the group's first meeting. Later on, Phill Gross, 28 Vint Cerf, and Noel Chiappa all provided valuable advice and 29 support. 30 Mike StJohns coordinated the Working Group's interactions with the 31 security community, and Frank Kastenholz coordinated the Working 32 Group's interactions with the network management experts. Allison 33 Mankin and K.K. Ramakrishnan provided expertise on the issues of 34 congestion control and resource allocation. 35 Many more people than I could possibly credit here participated in 36 the deliberations of the Router Requirements Working Group, either 37 through electronic mail or by attending meetings. I'd like to 38 particularly acknowledge the efforts of Ross Callon and Vince 39 Fuller for their help in sorting out the difficult issues of route 40 choice and route leaking. 41 Finally, credit is due to the editor's former employers, Stanford 42 University and BARRNet, for allowing him to spend a large fraction 43 (probably far more than they ever imagined when he started on 44 this) of his time working on this project. Internet Engineering Task Force [Page 29] DRAFT ARCHITECTURE October 1, 1991 2. INTERNET ARCHITECTURE 1 SOURCE: 2 Chapter 2 source: hacked up RFC-1009 and RFC-1122 3 General background and discussion on the Internet architecture and 4 supporting protocol suite can be found in the DDN Protocol Handbook 5 [ARCH:1]; for background see for example [ARCH:2], [ARCH:3], and 6 [ARCH:4]. The Internet architecture and protocols are also covered 7 in an ever-growing number of textbooks, such as [ARCH:5] and [ARCH:6] 8 2.1 Internet Protocols 2.1.1 Introduction 1 3 The Internet system consists of a number of interconnected 4 packet networks supporting communication among host computers 5 using the Internet protocols. These protocols include the 6 Internet Protocol (IP), the Internet Control Message Protocol 7 (ICMP), the Internet Group Management Protocol (IGMP), and a 8 variety transport and application protocols that depend upon 9 them. As was described in Section [1.2], the Internet 10 Activities Board periodically releases an "Official Protocols" 11 memo listing all of the Internet protocols. 12 All Internet protocols use IP as the basic data transport 13 mechanism. IP is a datagram, or connectionless, internetwork 14 service and includes provision for addressing, type-of-service 15 specification, fragmentation and reassembly, and security 16 information. ICMP and IGMP are considered integral parts of 17 IP, although they are architecturally layered upon IP. ICMP 18 provides error reporting, flow control and first-hop router 19 redirection. IGMP provides the mechanisms by which hosts (and 20 routers) can join and leave IP multicast groups. 21 Reliable data delivery is provided in the Internet protocol 22 suite by Transport Layer protocols such as the Transmission 23 Control Protocol (TCP), which provides end-end retransmission, 24 resequencing and connection control. Transport Layer 25 connectionless service is provided by the User Datagram 26 Protocol (UDP). Internet Engineering Task Force [Page 30] DRAFT ARCHITECTURE October 1, 1991 2.1.2 Protocol Layering 1 To communicate using the Internet system, a host must implement 2 the layered set of protocols comprising the Internet protocol 3 suite. A host typically must implement at least one protocol 4 from each layer. 5 The protocol layers used in the Internet architecture are as 6 follows [ARCH:7]: 7 o Application Layer 8 The Application Layer is the top layer of the Internet 9 protocol suite. The Internet suite does not further 10 subdivide the Application Layer, although some of the 11 Internet application layer protocols do contain some 12 internal sub-layering. The application layer of the 13 Internet suite essentially combines the functions of the 14 top two layers -- Presentation and Application -- of the 15 OSI Reference Model [ARCH:8]. The Application Layer in 16 the Internet protocol suite also includes some of the 17 function relegated to the Session Layer in the OSI 18 Reference Model. 19 We distinguish two categories of application layer 20 protocols: user protocols that provide service directly 21 to users, and support protocols that provide common system 22 functions. The most common Internet user protocols are: 23 o Telnet (remote login) 24 o FTP (file transfer) 25 o SMTP (electronic mail delivery) 26 There are a number of other standardized user protocols 27 and many private user protocols. 28 Support protocols, used for host name mapping, booting, 29 and management, include SNMP, BOOTP, TFTP, the Domain Name 30 System (DNS) protocol, and a variety of routing protocols. 31 Many Application Layer protocols use either the Telnet 32 protocol or the OSI ASN.1 basic encoding rules to perform 33 the function of OSI's Presentation Layer. 34 Application Layer protocols are discussed in chapters 7, 35 8, and 9 of this memo. Internet Engineering Task Force [Page 31] DRAFT ARCHITECTURE October 1, 1991 36 o Transport Layer 37 The Transport Layer provides end-to-end communication 38 services for applications. This layer is roughly 39 equivalent to the "Transport Layer" in the OSI Reference 40 Model, except that it also incorporates some of the 41 session establishment and destruction functions of OSI's 42 Session Layer. 43 There are two primary Transport Layer protocols at 44 present: 45 o Transmission Control Protocol (TCP) 46 o User Datagram Protocol (UDP) 47 TCP is a reliable connection-oriented transport service 48 that provides end-to-end reliability, resequencing, and 49 flow control. UDP is a connectionless ("datagram") 50 transport service. Other transport protocols have been 51 developed by the research community, and the set of 52 official Internet transport protocols may be expanded in 53 the future. 54 Transport layer protocols are discussed in Chapter [6]. 55 o Internet Layer 56 All Internet transport protocols use the Internet Protocol 57 (IP) to carry data from source host to destination host. 58 IP is a connectionless or datagram internetwork service, 59 providing no end-to-end delivery guarantees. Thus, IP 60 datagrams may arrive at the destination host damaged, 61 duplicated, out of order, or not at all. The layers above 62 IP are responsible for reliable delivery service when it 63 is required. The IP protocol includes provision for 64 addressing, type-of-service specification, fragmentation 65 and reassembly, and security information. 66 The datagram or connectionless nature of the IP protocol 67 is a fundamental and characteristic feature of the 68 Internet architecture. Internet IP was the model for the 69 OSI Connectionless Network Protocol [INTRO:12]. 70 ICMP is a control protocol that is considered to be an 71 integral part of IP, although it is architecturally 72 layered upon IP, i.e., it uses IP to carry its data end- 73 to-end just as a transport protocol like TCP or UDP does. Internet Engineering Task Force [Page 32] DRAFT ARCHITECTURE October 1, 1991 74 ICMP provides error reporting, congestion reporting, and 75 first-hop router redirection. 76 IGMP is an Internet layer protocol used for establishing 77 dynamic host groups for IP multicasting. 78 The Internet layer protocols IP, ICMP, and IGMP are 79 discussed in Chapter [4]. 80 o Link Layer 81 To communicate on its directly-connected network, a host 82 must implement the communication protocol used to 83 interface to that network. We call this a Link Layer or 84 media-access layer protocol. Some older Internet 85 documents refer to this layer as the "Network Layer", but 86 it is not the same as the "Network Layer" in the OSI 87 Reference Model. 88 This layer contains everything "below" the Internet Layer. 89 However, protocols included in what the OSI Reference 90 Model would call the "Link Layer" and the "Physical Layer" 91 are generally outside the scope of Internet 92 standardization; the Internet (intentionally) uses 93 existing standards whenever possible. Thus, Internet Link 94 Layer standards usually address only address resolution 95 and rules for transmitting IP packets over specific Link 96 Layer protocols. Internet Link Layer standards are 97 discussed in Chapter [3]. 2.2 Networks and Routers 1 The constituent networks of the Internet system are required only 2 to provide packet (connectionless) transport. This requires only 3 delivery of individual packets. According to the IP service 4 specification, datagrams can be delivered out of order, be lost or 5 duplicated, and/or contain errors. Reasonable performance of the 6 protocols that use IP (e.g., TCP) requires an IP datagram loss 7 rate of less than 5%. In those networks providing connection- 8 oriented service, the extra reliability provided by virtual 9 circuits enhances the end-end robustness of the system, but is not 10 necessary for Internet operation. 11 Constituent networks may generally be divided into two classes: 12 o Local-Area Networks (LANs) 13 LANs may have a variety of designs, typically based upon bus, Internet Engineering Task Force [Page 33] DRAFT ARCHITECTURE October 1, 1991 14 ring, or star topologies. In general, a LAN will cover a 15 small geographical area (e.g., a single building or plant 16 site) and provide high bandwidth with low delays. 17 o Wide-Area Networks (WANs) 18 Geographically-dispersed hosts and LANs are interconnected by 19 wide-area networks, also called long-haul networks. These 20 networks may have a complex internal structure of lines and 21 packet-routers, or they may be as simple as point-to-point 22 lines. 23 In the Internet model, constituent networks are connected together 24 by IP datagram forwarders which are called "routers" or "IP 25 routers". In this document, every use of the term "router" is 26 equivalent to "IP router". In current practice, routers are 27 normally realized with packet-switching software executing on a 28 general-purpose CPU, but special-purpose hardware may also be used 29 (and may be required for future higher-throughput routers). Many 30 older Internet documents refer to routers as "gateways". 31 A router is connected to two or more networks, appearing to each 32 of these networks as a connected host. Thus, it has (at least) 33 one physical interface and (at least) one IP address on each of 34 the connected networks. Forwarding an IP datagram generally 35 requires the router to choose the address of the next-hop router 36 or (for the final hop) the destination host. This choice, called 37 "routing", depends upon a routing database within the router. 38 This routing database should be maintained dynamically to reflect 39 the current topology of the Internet system; a router normally 40 accomplishes this by participating in distributed routing and 41 reachability algorithms with other routers. Routers provide 42 datagram transport only, and they seek to minimize the state 43 information necessary to sustain this service in the interest of 44 routing flexibility and robustness. 45 Routing devices may also operate at the Link Layer; such devices 46 are usually called "bridges". Network segments which are connected 47 by bridges share the same IP network number, i.e., they logically 48 form a single IP network. 49 Another variation on the simple model of networks connected with 50 routers sometimes occurs: a set of routers may be interconnected 51 with only serial lines, to effectively form a network in which the 52 routing is performed at the Internetwork (IP) Layer rather than 53 the Link Layer. Internet Engineering Task Force [Page 34] DRAFT ARCHITECTURE October 1, 1991 2.3 Router Characteristics 1 An Internet router performs the following functions: 2 (1) Conforms to specific Internet protocols specified in this 3 document, including the Internet Protocol (IP), Internet 4 Control Message Protocol (ICMP), and others as necessary. 5 (2) Interfaces to two or more packet networks. For each 6 connected network the router must implement the functions 7 required by that network. These functions typically include: 8 o encapsulating and decapsulating the IP datagrams with 9 the connected network framing (e.g., an Ethernet header 10 and checksum); 11 o sending and receiving IP datagrams up to the maximum 12 size supported by that network, this size is the 13 network's "Maximum Transmission Unit" or "MTU"; 14 o translating the IP destination address into an 15 appropriate network-level address for the connected 16 network (e.g., an Ethernet hardware address); 17 o responding to the network flow control and error 18 indication, if any. 19 See Chapter [3] (Link Layer). 20 (3) Receives and forwards Internet datagrams. Important issues 21 are buffer management, congestion control, and fairness. 22 (a) Recognizes various error conditions and generates ICMP 23 error and information messages as required. 24 (b) Drops datagrams whose time-to-live fields have reached 25 zero. 26 (c) Fragments datagrams when necessary to fit into the MTU 27 of the next network. 28 (4) Chooses a next-hop destination for each IP datagram, based on 29 the information in its routing database. See Chapter [4] 30 (Internet Layer -- Protocols) and Chapter [5] (Internet Layer 31 -- Forwarding). 32 (5) Supports an interior gateway protocol (IGP) to carry out Internet Engineering Task Force [Page 35] DRAFT ARCHITECTURE October 1, 1991 33 distributed routing and reachability algorithms with the 34 other routers in the same autonomous system. In addition, 35 some routers will need to support an exterior gateway 36 protocol to exchange topological information with other 37 autonomous systems. See Chapter [7] (Application Layer -- 38 Routing Protocols). 39 (6) Provides system support facilities, including loading, 40 debugging, status reporting, exception reporting and control. 41 See Chapter [10] (Operation and Maintenance). 42 SOURCE: 43 Remainder of Section 2.3 source: heavily modified RFC1009 44 Relationship to HRRFC: none 45 CONTRIBUTOR'S COMMENTS: 46 This section is still really centered around the long haul 47 backbone networks. It needs to be rewritten to deal more 48 with the needs of the campus LANS... 49 A router vendor will have many choices on power, complexity, and 50 features for a particular router product. It may be helpful to 51 observe that the Internet system is neither homogeneous nor 52 fully-connected. For reasons of technology and geography, it is 53 growing into a global-interconnect system plus a "fringe" of LANs 54 around the "edge". More and more these fringe LANs are becoming 55 richly interconnected, thus making them less out on the fringe and 56 more demanding on router requirements. 57 o The global-interconnect system is comprised of a number of 58 wide-area networks to which are attached routers of several 59 ASs; there are relatively few hosts connected directly to it. 60 This global system includes networks such as the NSFNET, 61 ESnet, and NSN "backbones", as well as scores of campus and 62 regional networks. 63 o Most hosts are connected to LANs, and many organizations have 64 clusters of LANs interconnected by local routers. Each such 65 cluster is connected by routers at one or more points into 66 the global-interconnect system. If it is connected at only 67 one point, a LAN is known as a "stub" network. 68 Routers in the global-interconnect system generally require: 69 o Advanced routing and forwarding algorithms 70 These routers need routing algorithms which are highly Internet Engineering Task Force [Page 36] DRAFT ARCHITECTURE October 1, 1991 71 dynamic and also offer type-of-service routing. Congestion 72 is still not a completely resolved issue (see Section 73 [5.3.6]). Improvements to the current situation will be 74 implemented soon, as the research community is actively 75 working on these issues. 76 o High availability 77 These routers need to be highly reliable, providing 24 hour a 78 day, 7 days a week service. In case of failure, they must 79 recover quickly. It is important to realize that Internet 80 routers normally operate in an unattended mode, but that 81 equipment and software faults can have a wide-spread 82 (sometimes global) effect. In any environment, a router must 83 be highly robust and able to operate, possibly in a degraded 84 state, under conditions of extreme congestion or failure of 85 network resources. 86 o Advanced O&M features 87 These routers will typically be operated remotely from a 88 centralized monitoring center. In their interconnect role, 89 they will need to provide sophisticated means for monitoring 90 and measuring traffic and other events and for diagnosing 91 faults. 92 o High performance 93 Although long-haul lines in the Internet today are most 94 frequently 56 Kbps and DS1 lines (1.5 Mbps), DS3 lines will 95 become increasingly important, and even higher speeds are 96 likely in the future. Full-duplex operation is provided at 97 any of these speeds. 98 Routers used in the LAN fringe (e.g., campus networks) 99 requirements depend greatly on the demands of the local networks. 100 These may be high or medium-performance devices, probably 101 competitively procured from several different vendors and operated 102 by an internal organization (e.g., a campus computing center). 103 The design of these routers should emphasize low average delay and 104 good burst performance, together with delay and type-of-service 105 sensitive resource management. In this environment, there will be 106 less formal O&M, but it will not be less important. There will be 107 more need for inter-operation with routers of other vendors. This 108 inter-operation will become essential, because the routing 109 mechanism will need to be very flexible. The need for the routing 110 mechanism to be highly dynamic will become more important as 111 networks become more complex and interconnected. Users will Internet Engineering Task Force [Page 37] DRAFT ARCHITECTURE October 1, 1991 112 demand more out of their local connections because of the speed of 113 the global interconnects. 114 Even though the Internet system is not fully-interconnected, many 115 parts of the system do need to have redundant connectivity. A 116 rich connectivity allows reliable service despite failures of 117 communication lines and routers, and it can also improve service 118 by shortening Internet paths and by providing additional capacity. 119 The engineering tradeoff between cost and reliability must be made 120 for each component of the Internet system. 2.4 Architectural Miscellany 1 CONTRIBUTOR'S COMMENT: 2 This section obviously needs a real title and a real 3 organization. For now, its got everything that didn't go 4 anywhere else. 2.4.1 Autonomous Systems 1 For technical, managerial, and sometimes political reasons, the 2 routers of the Internet system are grouped into collections 3 called "autonomous systems". The routers included in a single 4 autonomous system (AS) are expected to: 5 o Be under the control of a single operations and 6 maintenance (O&M) organization; 7 o Employ common routing protocols among themselves, to 8 maintain their routing databases dynamically. 9 A number of different dynamic routing protocols have been 10 developed (see Section [7.2]); the particular choice of routing 11 protocol within a single AS is generically called an interior 12 gateway protocol or IGP. 13 An IP datagram may have to traverse the routers of two or more 14 ASs to reach its destination, and the ASs must provide each 15 other with topology information to allow such forwarding. An 16 exterior gateway protocol (generally BGP or EGP) is used for 17 this purpose. 2.4.2 Addresses and Subnets 1 An IP datagram carries 32-bit source and destination addresses, 2 each of which is partitioned into two parts -- a constituent 3 network number and a host number on that network. 4 Symbolically: Internet Engineering Task Force [Page 38] DRAFT ARCHITECTURE October 1, 1991 5 IP-address ::= { , } 6 To finally deliver the datagram, the last router in its path 7 must map the Host-number (or "rest") part of an IP address into 8 the physical address of a host connection to the constituent 9 network. 10 This simple notion has been extended by the concept of 11 "subnets", which were introduced in order to allow arbitrary 12 complexity of interconnected LAN structures within an 13 organization, while insulating the Internet system against 14 explosive growth in network numbers and routing complexity. 15 Subnets essentially provide a multi-level hierarchical routing 16 structure for the Internet system. The subnet extension, 17 described in [INTERNET:2], is now a required part of the 18 Internet architecture. The basic idea is to partition the 19 field into two parts: a subnet number, and a true 20 host number on that subnet: 21 IP-address ::= 22 { , , } 23 The interconnected LANs of an organization will be given the 24 same network number but different subnet numbers. The | 25 distinction between the subnets of such a subnetted network is | 26 normally not visible outside of that network. Thus, wide-area 27 routing in the rest of the Internet will be based only upon the 28 part of the IP destination address; routers 29 outside the network will lump and 30 together to form an uninterpreted "rest" part of the 32-bit IP 31 address. Within the subnetted network, the local routers must 32 route on the basis of an extended network number: 33 { , }. 34 Under certain circumstances, it may be desirable to support | 35 subnets of a particular network being interconnected only via a | 36 network which is not part of the subnetted network number. In | 37 general, routers should not make assumptions about what are | 38 subnets and what are not, but simply ignore the concept of | 39 Class in networks, and treat each route as a {network,mask} | 40 tuple. Routers MUST be able to support this configuration of | 41 subnetting, even though many IGP's and no EGP's currently | 42 support this configuration effectively. OSPF [ROUTE:1] does | 43 support this configuration however. | 44 DISCUSSION: | 45 It is becoming clear that as the Internet grows larger and | Internet Engineering Task Force [Page 39] DRAFT ARCHITECTURE October 1, 1991 46 larger, the traditional uses of Class A,B, and C networks | 47 may need to be modified in order to achieve better use of | 48 IP's 32-bit address space. Several common ways of | 49 achieving this added efficiency depend on the ability of | 50 assigning and routing to networks that are not based on | 51 Class A,B, or C networks. Thus, routers should always | 52 treat a route as a network with a mask. | 53 Furthermore, for similar reasons, a subnetted network need not | 54 have a consistent subnet mask through all parts of the network. | 55 For example, one subnet may use an 8 bit subnet mask, another | 56 10 bit, and another 6 bit. Routers MUST be able to this type | 57 of configuration. | 58 The bit positions containing this extended network number are 59 indicated by a 32-bit mask called the "subnet mask"; it is 60 recommended but not required that the bits be 61 contiguous and fall between the and the 62 fields. No subnet should be assigned the value 63 zero or -1 (all one bits). 64 Although the inventors of the subnet mechanism probably 65 expected that each piece of an organization's network would 66 have only a single subnet number, in practice it has often 67 proven necessary or useful to have several subnets share a 68 single physical cable. This is discussed further in Section 69 [2.4.4]. 70 There are special considerations for the router when a 71 connected network provides a broadcast or multicast capability; 72 these will be discussed later. 2.4.3 IP Multicasting 1 IP multicasting is an extension of Link Layer multicast to IP | 2 internets. Using IP multicasts, a single datagram can be | 3 addressed to multiple hosts. This collection of hosts is called | 4 a multicast group. Each multicast group is represented as a | 5 class D IP address. An IP datagram sent to the group is to be | 6 delivered to each group member with the same best-effort | 7 delivery as that provided for unicast IP traffic. The sender of | 8 the datagram does not itself need to be a member of the | 9 destination group. | 10 Examples of the uses of IP multicasting include distributed | 11 databases, simulations, and distributed applications such as | 12 teleconferencing. | Internet Engineering Task Force [Page 40] DRAFT ARCHITECTURE October 1, 1991 13 The semantics of IP multicast group membership is defined in | 14 [INTERNET:4]. This document describes how hosts join and leave | 15 multicast group. It also defines a protocol, the Internet Group | 16 Membership Protocol (IGMP), that monitors IP multicast group | 17 membership. | 18 Forwarding of IP multicast datagrams is accomplished either | 19 through static routing information or via a multicast routing | 20 protocol. Devices that forward IP multicast datagrams are | 21 called multicast routers. They may or may not also forward IP | 22 unicasts. In general, multicast datagrams are forwarded on the | 23 basis of both their source and destination addresses. | 2.4.4 Networks, Subnets, and Unnumbered Lines 1 2 3 Traditionally, each network interface on an IP host or router | 4 has its own IP address. Over the years, people have observed | 5 that this can cause inefficient use of the scarce IP address | 6 space, since it forces allocation of an IP network number, or | 7 at least a subnet number, to every point-to-point link. | 8 To solve this problem, a number have proposed and implemented | 9 the concept of "unnumbered serial lines". An unnumbered serial | 10 line does not have any IP network or subnet number associated | 11 with it. As a consequence, the network interfaces connected to | 12 an unnumbered serial line do not have IP addresses. | 13 Because the IP architecture has traditionally assumed that all | 14 interfaces had IP addresses, these unnumbered interfaces cause | 15 some interesting dilemmas. For example, some IP options (e.g. | 16 Record Route) specify that a router must insert the interface | 17 address into the option, but an unnumbered interface has no IP | 18 address. Even more fundamental (as we shall see in Chapter | 19 [5]) is that routes contain the IP address of the next hop | 20 router. A router expecta that that IP address will be on an IP | 21 (sub)net that the router is connected to. That assumption is | 22 of course violated if the only connection is an unnumbered | 23 serial line. | 24 To get around these difficulties, two schemes have been | 25 invented. The first scheme says that two routers connected by | 26 an unnumbered serial line aren't really two routers at all, but | 27 rather two "half-routers" which together make up a single | 28 (virtual) router. The unnumbered serial line is essentially | Internet Engineering Task Force [Page 41] DRAFT ARCHITECTURE October 1, 1991 29 considered to be an internal bus in the virtual router. The | 30 two halves of the virtual router must coordinate their | 31 activities in such a way that they act exactly like a single | 32 router. | 33 This scheme fits in well with IP architecture, but suffers from | 34 two important drawbacks. The first is that, although it | 35 handles the common case of a single unnumbered serial line, it | 36 is not readily extensible to handle the case of a mesh of | 37 routers an unnumbered serial lines. The second drawback is | 38 that the interactions between the half routers are necessarily | 39 complex and are not standardized, effectively precluding the | 40 connection of equipment from different vendors using unnumbered | 41 serial lines. | 42 Because fo these drawbacks, this memo has adopted an | 43 alternative scheme, which has been invented multiple times but | 44 which is probably originally attributable to Phil Karn. In | 45 this scheme, a router which has unnumbered serial lines also | 46 has a special IP address, called a "router-id" in this memo. | 47 The router-id is one of the router's IP addresses (a router is | 48 required to have at least one IP address). This router-id is | 49 essentially used as if it were the IP address of all unnumbered | 50 interfaces. | 2.4.5 Interfaces 1 2.4.6 Notable Oddities 1 EDITOR'S COMMENTS: 2 There has been a suggestion that this section should also 3 mention the existence of the various flavors of bridges 4 that do some router-like things (fragmenting bridges, 5 multi-media bridges, ...) 2.4.6.1 Embedded Routers 1 A router may be a stand-alone computer system, dedicated to 2 its IP router functions. Alternatively, it is possible to 3 embed router functionality within a host operating system 4 which supports connections to two or more networks. The 5 best-known example of an operating system with embedded 6 router code is the Berkeley BSD system. The embedded router 7 feature seems to make internetting easy, but it has a number 8 of hidden pitfalls: Internet Engineering Task Force [Page 42] DRAFT ARCHITECTURE October 1, 1991 9 (1) If a host has only a single constituent-network 10 interface, it should not act as a router. 11 For example, hosts with embedded router code that 12 gratuitously forward broadcast packets or datagrams on 13 the same net often cause packet avalanches. 14 (2) If a (multihomed) host acts as a router, it must 15 implement ALL the relevant router requirements 16 contained in this document. 17 For example, the routing protocol issues (see Sections 18 2.6 and 4.1) and the control and monitoring problems 19 are as hard and important for embedded routers as for 20 stand-alone routers. 21 Since Internet router requirements and specifications 22 may change independently of operating system changes, 23 an administration that operates an embedded router in 24 the Internet is strongly advised to have an ability to 25 maintain and update the router code (e.g., this might 26 require router code source). 27 (3) Once a host runs embedded router code, it becomes part 28 of the Internet system. Thus, errors in software or 29 configuration of such a host can hinder communication 30 between other hosts. As a consequence, the host 31 administrator must lose some autonomy. 32 In many circumstances, a host administrator will need 33 to disable router coded embedded in the operating 34 system, and any embedded router code must be organized 35 so it can be easily disabled. 36 (4) If a host running embedded router code is concurrently 37 used for other services, the O&M (operation and 38 maintenance) requirements for the two modes of use may 39 be in serious conflict. 40 For example, router O&M will in many cases be performed 41 remotely by an operations center; this may require 42 privileged system access which the host administrator 43 would not normally want to distribute. 2.4.6.2 Transparent Routers 1 There are two basic models for interconnecting local-area 2 networks and wide-area (or long-haul) networks in the Internet Engineering Task Force [Page 43] DRAFT ARCHITECTURE October 1, 1991 3 Internet. In the first, the local-area network is assigned 4 a network number and all routers in the Internet must know 5 how to route to that network. In the second, the local-area 6 network shares (a small part of) the address space of the 7 wide-area network. Routers that support this second model 8 are called "address sharing routers" or "transparent 9 routers". The focus of this memo is on routers that support 10 the first model, but this is not intended to exclude the use 11 of transparent routers. 12 The basic idea of a transparent router is that the hosts on 13 the local-area network behind such a router share the 14 address space of the wide-area network in front of the 15 router. In certain situations this is a very useful 16 approach and the limitations do not present significant 17 drawbacks. 18 The words "in front" and "behind" indicate one of the 19 limitations of this approach: this model of interconnection 20 is suitable only for a geographically (and topologically) 21 limited stub environment. It requires that there be some 22 form of logical addressing in the network level addressing 23 of the wide-area network (that is, all the IP addresses in 24 the local environment map to a few (usually one) physical 25 address in the wide-area network, in a way consistent with 26 the { IP address <-> network address } mapping used 27 throughout the wide-area network). 28 Multihoming is possible on one wide-area network, but may 29 present routing problems if the interfaces are 30 geographically or topologically separated. Multihoming on 31 two (or more) wide-area networks is a problem due to the 32 confusion of addresses. 33 The behavior that hosts see from other hosts in what is 34 apparently the same network may differ if the transparent 35 router cannot fully emulate the normal wide-area network 36 service. For example, if there were a transparent router 37 between the ARPANET and an Ethernet, a remote host would not 38 receive a Destination Dead message [3] if it sent a datagram 39 to an Ethernet host that was powered off. 2.5 Architectural Assumptions 1 SOURCE: 2 Section 2.2 source: RFC-1122 section 1.1.2 3 The current Internet architecture is based on a set of assumptions Internet Engineering Task Force [Page 44] DRAFT ARCHITECTURE October 1, 1991 4 about the communication system. The assumptions most relevant to 5 routers are as follows: 6 o The Internet is a network of networks. 7 Each host is directly connected to some particular 8 network(s); its connection to the Internet is only 9 conceptual. Two hosts on the same network communicate with 10 each other using the same set of protocols that they would 11 use to communicate with hosts on distant networks. 12 o Routers don't keep connection state information. 13 To improve robustness of the communication system, routers 14 are designed to be stateless, forwarding each IP packet 15 independently of other packets. As a result, redundant paths 16 can be exploited to provide robust service in spite of 17 failures of intervening routers and networks. 18 All state information required for end-to-end flow control 19 and reliability is implemented in the hosts, in the transport 20 layer or in application programs. All connection control 21 information is thus co-located with the end points of the 22 communication, so it will be lost only if an end point fails. 23 Routers effect flow control only indirectly, by dropping 24 packets or increasing network delay. 25 o Routing complexity should be in the routers. 26 Routing is a complex and difficult problem, and ought to be 27 performed by the routers, not the hosts. An important 28 objective is to insulate host software from changes caused by 29 the inevitable evolution of the Internet routing 30 architecture. 31 o The System must tolerate wide network variation. 32 A basic objective of the Internet design is to tolerate a 33 wide range of network characteristics -- e.g., bandwidth, 34 delay, packet loss, packet reordering, and maximum packet 35 size. Another objective is robustness against failure of 36 individual networks, routers, and hosts, using whatever 37 bandwidth is still available. Finally, the goal is full 38 "open system interconnection": an Internet host must be able 39 to interoperate robustly and effectively with any other 40 Internet host, across diverse Internet paths. 41 Sometimes host implementors have designed for less ambitious Internet Engineering Task Force [Page 45] DRAFT ARCHITECTURE October 1, 1991 42 goals. For example, the LAN environment is typically much 43 more benign than the Internet as a whole; LANs have low 44 packet loss and delay and do not reorder packets. Some 45 vendors have fielded host implementations that are adequate 46 for a simple LAN environment, but work badly for general 47 interoperation. The vendor justifies such a product as being 48 economical within the restricted LAN market. However, 49 isolated LANs seldom stay isolated for long; they are soon 50 gatewayed to each other, to organization-wide internets, and 51 eventually to the global Internet system. In the end, 52 neither the customer nor the vendor is served by incomplete 53 or substandard routers. 54 The requirements spelled out in this document are designed 55 for a full-function router. It is intended that fully 56 compliant routers will be useable in almost any part of the 57 Internet. 58 CONTRIBUTOR'S COMMENTS: 59 Need to reread and cite Dave Clark's Sigcomm '88 paper 60 (CLA88) Internet Engineering Task Force [Page 46] DRAFT LINK LAYER October 1, 1991 3. LINK LAYER 1 SOURCE: 2 Relationship to HRRFC: Takes a stronger stand against trailer 3 encapsulation. Makes MTU an attribute of logical rather than 4 physical interfaces. 3.1 INTRODUCTION 1 All Internet systems, both hosts and gateways, have the same 2 requirements for link layer protocols. These requirements are 3 given in Chapter 3 of "Requirements for Internet Gateways" 4 [INTRO:1], augmented with the material in the remainder of this 5 chapter. 6 DISCUSSION: 7 It is intended that the Internet community will produce a 8 "Requirements for Internet Link Layer" standard in the near 9 future which will supersede this chapter. 10 Although this document does not attempt to specify the interface | 11 between the Link Layer and the upper layers, it is worth noting | 12 here that other parts of this document, particularly Chapter [5], | 13 require various sorts of information to be passed across this | 14 layer boundary. | 15 This section uses the following definitions: | 16 Source physical address | 17 The source physical address is the Link Layer address of the | 18 host or router from which the packet was received. | 19 Destination physical address | 20 The destination physical address is the Link Layer address to | 21 which the packet was sent. | 22 The information that must pass from the Link Layer to the | 23 Internetwork Layer for each received packet is: | 24 (1) the IP packet [5.2.2] | 25 (2) the length of the IP packet [5.2.2] | 26 (3) the physical interface from which the IP packet was received | 27 [5.2.3] | Internet Engineering Task Force [Page 47] DRAFT LINK LAYER October 1, 1991 28 (4) classification of the packet's destination physical address | 29 as a Link Layer unicast, broadcast, or multicast [4.3.2], | 30 [5.3.4]. | 31 In addition, the Link Layer also should provide: | 32 (5) the source physical address [5.3.7] | 33 The information that must pass from the Internetwork Layer to the | 34 Link Layer for each transmitted packet is: | 35 (1) the IP packet [5.2.1] | 36 (2) the length of the IP packet [5.2.1] | 37 (3) the destination physical interface [5.2.1] | 38 (4) the next hop IP address [5.2.1] | 39 In addition, the Internetwork Layer also should provide: | 40 (5) the Link Layer priority value [5.3.3.2] | 41 The Link Layer must also notify the Internetwork Layer if the | 42 packet to be transmitted causes a Link Layer precedence-related | 43 error [5.3.3.3]. | 44 AUTHOR'S COMMENTS: | 45 Should I go investigate other information that passes between | 46 the layers, such as physical network MTU, mappings of IP | 47 precedence to Link Layer priority values, etc.? | 48 Should the Link Layer notify IP if address resolution failed | 49 (just like it notifies IP when there is a Link Layer priority | 50 value problem)? | 3.2 SPECIFIC ISSUES 3.2.1 Trailer Encapsulation 1 Routers which can connect to 10Mb Ethernets MAY be able to | 2 receive and forward Ethernet packets encapsulated using the | 3 trailer encapsulation described in [LINK:1]. However, a router 4 SHOULD NOT send trailer encapsulated packets. A router MUST 5 NOT send trailer encapsulated packets without first verifying, 6 using the mechanism described in section 2.3.1 of [INTRO:2], 7 that the immediate destination of the packet is willing and 8 able to accept trailer-encapsulated packets. A router SHOULD Internet Engineering Task Force [Page 48] DRAFT LINK LAYER October 1, 1991 9 NOT agree (using these same mechanisms) to accept trailer- 10 encapsulated packets. 3.2.2 Address Resolution Protocol -- ARP 1 Routers which implement ARP must conform to the requirements in 2 section 2.3.2 of [INTRO:2]. 3 The link layer MUST NOT report a Destination Unreachable error 4 to IP solely because there is no ARP cache entry for a 5 destination. 6 A router MUST disbelieve any ARP reply which claims that the 7 Link Layer address of another host or router is a broadcast or 8 multicast address. 3.2.3 Ethernet and 802.3 Coexistence 1 Routers which can connect to 10Mb Ethernets must conform to the 2 requirements of Section [2.3.3] of [INTRO:2]. 3.2.4 Maximum Transmission Unit -- MTU 1 The MTU of each logical interface MUST be configurable. Many | 2 Link Layer protocols define a maximum frame size that may be | 3 sent. In such cases, a router MUST NOT allow an MTU to be set | 4 which would allow sending of frames larger than those allowed | 5 by the Link Layer protocol. | 6 DISCUSSION: 7 Note that this is a stricter requirement than imposed on 8 hosts by RFC-1122, which requires that the MTU of each 9 physical interface be configurable. 3.2.5 Point-to-Point Protocol -- PPP 1 Contrary to [INTRO:1], the Internet does have a standard serial 2 line protocol. 3 A serial line interface is any interface which is designed to | 4 send data over a telephone, leased, dedicated or direct line | 5 (either 2 or 4 wire) using a standardized modem or bit serial | 6 interface (such as RS-232, RS-449 or V.35), using either | 7 synchronous or asynchronous clocking. | 8 A general purpose serial interface is a serial line interface | 9 which is not solely for use as an access line to a network for | 10 which an alternative IP link layer specification exists (such | Internet Engineering Task Force [Page 49] DRAFT LINK LAYER October 1, 1991 11 as X.25 or Frame Relay). | 12 Routers which contain such general purpose serial interfaces | 13 MUST IMPLEMENT the Internet standard serial line protocol | 14 Point-to-Point Protocol (PPP), defined in [LINK:2] and | 15 [LINK:3]. PPP MUST be supported on all general purpose serial | 16 interfaces on a router. The router MAY allow the line to be | 17 configured to use proprietary serial line protocols other than | 18 PPP. | 19 All general purpose serial interfaces MUST default to using | 20 PPP. | 21 CONTRIBUTOR'S COMMENTS: | 22 do we want to be this tough? | 3.2.5.1 Introduction | 1 The purpose of this section of the router requirements | 2 document is to provide a guideline to router implementors so | 3 that they can ensure interoperability with other routers | 4 using the Point-to-Point Protocol (PPP) over low to medium | 5 speed synchronous serial links (9,600 bps through T1 rates). | 6 The option negotiation mechanism will ensure interoperabilty | 7 if the implementor understands that options are a means for | 8 a local device to indicate to a remote peer what the local | 9 device will --accept-- from the remote peer, not what it | 10 wishes to send. It is up to the remote peer to decide what | 11 is most convenient to send WITHIN THE CONFINES OF THE SET OF | 12 OPTIONS THAT THE LOCAL DEVICE HAS STATED THAT IT CAN ACCEPT. | 13 Therefore it is perfectly acceptable and normal for a remote | 14 peer to ACK all the options indicated in an LCP | 15 Configuration Request (CR) even if the remote peer does not | 16 support any of those options. Again, the options are simply | 17 a mechanism for either device to indicate to its peer what | 18 it will accept, not necessarily what it will send. Please | 19 keep this in mind while reading the rest of this section. | 3.2.5.2 Requirements and Recommendations | 1 The PPP Link Control Protocol (LCP) offers a number of | 2 options that may be negotiated. These options include but | 3 are not limited to address and control field compression, | 4 protocol field compression, async character map, Maximum | 5 Receive Unit (MRU), Link Quality Monitoring (LQM), magic | 6 number (for loopback detection), Password Authentication | 7 Protocol (PAP), Challenge Handshake Authentication Protocol | 8 (CHAP), and the 32-bit Frame Check Sequence (FCS). | Internet Engineering Task Force [Page 50] DRAFT LINK LAYER October 1, 1991 9 1) A router MAY do address/control field compression on | 10 either synchronous or asynchronous links. (See the | 11 following discussion.) | 12 2) A router MAY do protocol field compression on either | 13 synchronous or asynchronous links. (See the following | 14 discussion.) | 15 The first two options control the appearance of the PPP | 16 header. Normally the PPP header consists of the address | 17 field (one octet containing the value 0xff), the control | 18 field (one octet containing the value 0x03), and the two- | 19 octet protocol field that identifies the contents of the | 20 data area of the frame. If a system negotiates address and | 21 control field compression it indicates to its peer that it | 22 will accept PPP frames that have or do not have these fields | 23 at the front of the header. IT DOES NOT INDICATE THAT IT | 24 WILL BE SENDING FRAMES WITH THESE FIELDS REMOVED. The | 25 protocol field may also be compressed from two to one octet | 26 in most cases. A router MAY indicate that it can accept | 27 these compressions but it MUST be able to accept | 28 uncompressed PPP header information even if it has indicated | 29 a willingness to receive compressed PPP headers. | 30 An implementation note here: some hardware does not deal | 31 well with variable length header information. In those | 32 cases it makes most sense for the remote peer to send the | 33 full PPP header. This may be accomplished by NOT sending | 34 the address/control field and protocol field compression | 35 options to the remote peer. Even if the remote peer has | 36 indicated an ability to receive compressed headers there is | 37 no requirement for the local router to send compressed | 38 headers. | 39 3) Asynchronous PPP implementations MUST negotiate the | 40 Async Control Character Map (ACCM). A router SHOULD | 41 NOT attempt to negotiate the ACCM for a synchronous | 42 link. | 43 There are implementations that offer both sync and async | 44 modes of operation and may use the same code to implement | 45 the option negotiation. In this situation it is possible | 46 that one end or the other may send the ACCM option on a | 47 synchronous link. This is acceptable and the peer MUST | 48 ACKnowledge the option and then ignore it. | 49 4) A router SHOULD properly negotiate the maximum receive | 50 unit (MRU). | Internet Engineering Task Force [Page 51] DRAFT LINK LAYER October 1, 1991 51 The MRU option is a special case. The MRU option allows a | 52 device to indicate that it will accept frames that are | 53 larger than the default value of 1,500 octets (this size is | 54 applied to the data area of the frame only and does not | 55 include the flags, the header, and/or the FCS of the PPP | 56 frame). Even if a system negotiates an MRU smaller than | 57 1,500 octets, it MUST be able to receive a 1,500 octet | 58 frame. | 59 5) A router SHOULD negotiate and enable the link quality | 60 monitoring (LQM) option. | 61 6) A router SHOULD implement and negotiate the magic | 62 number option for loopback detection. | 63 7) A router MAY support the authentication options (PAP - | 64 password authentication protocol, and/or CHAP - | 65 challenge handshake authentication protocol). | 66 8) A router MUST support 16-bit CRC frame check sequence | 67 (FCS) and MAY support the 32-bit CRC. | 68 Routers supporting IP SHOULD also negotiate the following | 69 options in the PPP IP Control Protocol: | 70 1) A router MAY offer to perform IP address negotiation. | 71 A router MUST accept a refusal (REJect) to perform IP | 72 address negotiation from the peer. | 73 2) A router SHOULD NOT perform Van Jacobson header | 74 compression of IP/TCP packets if the link speed is in | 75 excess of 64 Kbps. Below that speed the router MAY | 76 perform VJ header compression. At link speeds of | 77 19,200 bps or less the router SHOULD perform VJ header | 78 compression. | 3.2.6 Interface Testing 1 A router also MUST have a mechanism to allow routing software | 2 to determine whether a physical interface is available to send | 3 packets, or not. A router SHOULD have a mechanism to allow | 4 routing software to judge the quality of a physical interface. | 5 A router MUST have a mechanism for informing the routing | 6 software when a physical interface becomes available or | 7 unavailable to send packets because of administrative action. A | 8 router SHOULD have a mechanism for informing the routing | 9 software when it detects a Link level interface has become | 10 available or unavailable. | Internet Engineering Task Force [Page 52] DRAFT LINK LAYER October 1, 1991 11 DISCUSSION: 12 It is crucial that routers have workable mechanisms for 13 determining that their network connections are functioning 14 properly, since failure to do so (or failure to take the 15 proper actions when a problem is detected) can lead to 16 black holes. 17 The mechanisms available for detecting problems with 18 network connections vary considerably, depending on the 19 Link Layer protocols in use and also in some cases on the 20 interface hardware chosen by the router manufacturer. 3.3 Requirements Summary 1 TBD Internet Engineering Task Force [Page 53] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 4. INTERNET LAYER -- PROTOCOLS 4.1 INTRODUCTION 4.2 INTERNET PROTOCOL -- IP 4.2.1 INTRODUCTION 1 Routers MUST implement the IP protocol, as defined by 2 [INTERNET:1]. They MUST also implement its mandatory 3 extensions: subnets (defined in [INTERNET:2]), and IP broadcast 4 (defined in [INTERNET:3]). 4.2.2 PROTOCOL WALK-THROUGH 4.2.2.1 Options: RFC-791 Section 3.2 1 SOURCE: 2 Section 4.2.2.1 source: RFC-1122 section 3.2.1.8 3 Relationship to HRRFC: identical text, except for 4 deletion of host-specific text. No technical changes. 5 In datagrams received by the router itself, the IP layer 6 MUST each interpret those IP options that it understands and 7 preserve the rest unchanged for use by higher layer 8 protocols. Unrecognized IP options in forwarded packets 9 MUST be passed through unchanged. 10 Higher layer protocols may require the ability to set IP 11 options in datagrams they send or examine IP options in 12 datagrams they receive. Later sections of this document 13 discuss specific IP option support required by higher layer 14 protocols. 15 EDITOR'S COMMENTS: 16 Handling of options in forwarded datagrams needs to be 17 moved to chapter 5. 18 Most of the discussion of options in datagrams 19 originated or received by the router ought to be 20 replaced by references to RFC-1122. Some argument 21 could be made that this document should retain handling 22 of options on received ICMP packets; I'm open to 23 comments on this. 24 DISCUSSION: 25 Passing all received IP options to the transport layer Internet Engineering Task Force [Page 54] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 26 is a deliberate "violation of strict layering" that is 27 designed to ease the introduction of new transport- 28 relevant IP options in the future. Each layer must 29 pick out any options that are relevant to its own 30 processing and ignore the rest. For this purpose, 31 every IP option except NOOP and END-OF-LIST will 32 include a specification of its own length. 33 This document does not define the order in which a 34 receiver must process multiple options in the same IP 35 header. Hosts and routers originating datagrams 36 containing multiple options must be aware that this 37 introduces an ambiguity in the meaning of certain 38 options when combined with a source-route option. 39 Several options, such as Record Route and Timestamp, 40 contain "slots" into which a router inserts its address 41 when forwarding the packet. However, each such option 42 has a finite number of slots, and therefore a router 43 may find that there is not free slot into which it can 44 insert its address. No requirement listed below should 45 be construed as requiring a router to insert its 46 address into an option that has no remaining slot to 47 insert it into. Section [5.2.5] discusses how a router 48 must choose which of its addresses to insert into an 49 option. 50 EDITOR'S COMMENTS: 51 Is the second discussion item still true? I know we 52 have come with rules covering several ambiguities 53 (multiple source routes, source route + record route, 54 source route + timestamp). Are there others? 55 Here are the requirements for specific IP options: 56 (a) Security Option 57 Some environments require the Security option in every 58 packet; such a requirement is outside the scope of this 59 document and the IP standard specification. Note, 60 however, that the security options described in RFC-791 61 and RFC-1038 are obsolete. Routers MAY support the | 62 revised security option described in [INTERNET:5]. | 63 EDITOR'S COMMENTS: | 64 The above MAY was a SHOULD IMPLEMENT, but got | 65 changed to a MAY in Atlanta because it was unclear | 66 that RFC-1108 would be released any decade soon. | Internet Engineering Task Force [Page 55] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 67 Since then, I have been assured that the | 68 responsible parties are on the verge of resolving | 69 the issues that have held up the issue of that | 70 RFC; if they do, we may want to go back to SHOULD | 71 IMPLEMENT. | 72 (b) Stream Identifier Option 73 This option is obsolete; it SHOULD NOT ever be present 74 in datagrams originated by the router, and MUST be 75 ignored in datagrams received by the router. If the 76 Stream Identifier option is present in a packet 77 forwarded by the router, the option MUST be ignored and 78 passed through unchanged. 79 (c) Source Route Options 80 A router MUST implement support for source route 81 options in forwarded packets. As described in Section 82 [????], a router MAY implement a policy mechanism 83 which, when enabled, causes all source-routed packets 84 to be discarded. However, such an option MUST NOT be 85 enabled by default. 86 DISCUSSION: 87 The ability to source route datagrams through the 88 Internet is important to various network 89 diagnostic tools. However, some people believe 90 that security problems can result from the use of 91 source route options. 92 A router MUST be able to act as the final destination 93 of a source route. If a router receives a packet 94 containing a completed source route (i.e., the pointer 95 points beyond the last field and the destination 96 address in the IP header addresses the router), the 97 packet has reached its final destination; the option as 98 received (the recorded route) MUST be passed up to the 99 transport layer (or to ICMP message processing). 100 In order to respond correctly to source-routed 101 datagrams it receives, a router MUST provide a means 102 whereby transport protocols and applications can 103 reverse the source route in a received datagram and 104 insert the reversed source route into datagrams they 105 originate (see Section 4 of [INTRO:2] for details). 106 As described in Chapter 9, certain applications may Internet Engineering Task Force [Page 56] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 107 require that the user be able to enter a source route. 108 EDITOR'S COMMENTS: 109 Later sections of the document should clarify 110 whether, for each application or transport 111 protocol, source routes should be used in 112 constructing replies to source-routed messages. 113 When a source route option is created, it MUST be 114 correctly formed even if it is being created by 115 reversing a recorded route that erroneously includes 116 the source host (see case (B) in the discussion below). 117 A router MUST NOT originate a datagram containing 118 multiple source route options. What a router should do 119 if asked to forward a packet containing multiple source 120 route options is described in Section [5.2.4.1]. 121 DISCUSSION: 122 Suppose a source routed datagram is to be routed 123 from source S to destination D via routers G1, G2, 124 ... Gn. Source S constructs a datagram with G1's 125 IP address as its destination address, and a 126 source route option to get the datagram the rest 127 of the way to its destination. However, there is 128 an ambiguity in the specification over whether the 129 source route option in a datagram sent out by S 130 should be (A) or (B): 131 (A): {>>G2, G3, ... Gn, D} <--- CORRECT 132 (B): {S, >>G2, G3, ... Gn, D} <---- WRONG 133 (where >> represents the pointer). If (A) is 134 sent, the datagram received at D will contain the 135 option: {G1, G2, ... Gn >>}, with S and D as the 136 IP source and destination addresses. If (B) were 137 sent, the datagram received at D would again 138 contain S and D as the same IP source and 139 destination addresses, but the option would be: 140 {S, G1, ...Gn >>}; i.e., the originating host 141 would be the first hop in the route. 142 (d) Record Route Option 143 Routers MUST support the Record Route option in 144 forwarded packets, and MAY support it in datagrams 145 originated by the router. Internet Engineering Task Force [Page 57] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 146 A router MAY provide a configuration option which, if 147 enabled, will cause the router to ignore (i.e. pass 148 through unchanged) Record Route options in forwarded 149 packets. If provided, such an option MUST default to 150 off. This option does not affect the processing of 151 Record Route options in datagrams received by the 152 router itself (in particular, Record Route options in 153 ICMP echo requests will still be processed in 154 accordance with Section [4.3.3.6]). 155 DISCUSSION: 156 There are apparently a few people who believe that 157 Record Route is a security problem because it 158 discloses information about the topology of the 159 network. 160 (e) Timestamp Option 161 Routers MUST support the timestamp option in forwarded 162 packets, and MAY support it in datagrams originated by 163 the router. The following rules apply: 164 o When originating a datagram containing a Timestamp 165 Option, a router MUST record a timestamp in the 166 option if its Internet address fields are not 167 pre-specified or if its first pre-specified 168 address is the router's interface address. 169 o If the router itself receives a datagram 170 containing a Timestamp Option, the router MUST 171 insert the current timestamp into the Timestamp 172 Option (if there is space in the option to do so) 173 before passing the option to the transport layer 174 or to ICMP for processing. 175 o A timestamp value MUST follow the rules given in 176 Section [3.2.2.8] of [INTRO:2]. 177 If the flags field = 3 (timestamp and prespecified 178 address), the router MUST add its timestamp if the next 179 prespecified address matches any of the router's IP 180 addresses. It is not necessary that the prespecified 181 address be either the address of the interface on which 182 the packet arrived or the address of the interface over 183 which it will be sent. 184 IMPLEMENTATION: 185 To maximize the utility of the timestamps contained in Internet Engineering Task Force [Page 58] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 186 the timestamp option, it is suggested that the 187 timestamp inserted be, as nearly as practical, the time 188 at which the packet arrived at the router. For 189 datagrams originated by the router, the timestamp 190 inserted should be, as nearly as practical, the time at 191 which the datagram was passed to the network layer for 192 transmission. 193 A router MAY provide a configuration option which, if 194 enabled, will cause the router to ignore (i.e. pass through 195 unchanged) Timestamp options in forwarded datagrams when the 196 flag word is set to zero (timestamps only) or one (timestamp 197 and registering IP address). If provided, such an option 198 MUST default to off. This option does not affect the 199 processing of Timestamp options in datagrams received by the 200 router itself (in particular, a router will insert 201 timestamps into Timestamp options in received datagrams as 202 described above, and Timestamp options in ICMP echo requests 203 will still be processed in accordance with Section 204 [4.3.3.6]). 205 DISCUSSION: 206 Like the Record Route option, the Timestamp option can 207 reveal information about a network's topology. Some 208 people consider this to be a security concern. 4.2.2.2 Unused IP Header Bits: RFC-791 Section 3.1 1 The IP header contains several reserved bits, in the Type of 2 Service field and in the Flags field. Routers MUST NOT drop 3 packets merely because one or more of these reserved bits 4 has a non-zero value. 5 Routers MUST ignore (and pass through unchanged) the values 6 of these reserved bits. If a router fragments a packet, it 7 MUST copy these bits into each fragment. 8 DISCUSSION: | 9 Future revisions to the IP protocol may make use of | 10 these unused bits. These rules are intended to ensure | 11 that these revisions can be deployed without having to | 12 simultaneously upgrade all routers in the Internet. | 4.2.2.3 Type of Service: RFC-791 Section 3.1 1 The description of the IP Precedence field is superseded by 2 Section [5.3.3]. Section [5.3.2] discusses how the type of 3 service bits are interpreted in packets which are being Internet Engineering Task Force [Page 59] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 4 forwarded. 5 RFC-795, "Service Mappings", is obsolete and SHOULD NOT be 6 implemented. 4.2.2.4 Header Checksum: RFC-791 Section 3.1 1 As stated in Section [5.2.2], a router is required to verify 2 the IP checksum of any packet which is received or 3 forwarded. The router MUST NOT provide a means to disable 4 this checksum verification. 5 IMPLEMENTATION: 6 A more extensive description of the IP checksum, 7 including extensive implementation hints, can be found 8 in [INTERNET:6] and [INTERNET:7]. 4.2.2.5 Unrecognized Header Options: RFC-791 Section 3.1 1 A router MUST ignore (and pass through unchanged) IP options 2 which it does not recognize. A corollary of this 3 requirement is that a router MUST implement the End of 4 Option List option and the No Operation option, since 5 neither contains an explicit length. 6 DISCUSSION: 7 All future IP options will include an explicit length. 4.2.2.6 Fragmentation: RFC-791 Section 3.2 1 Fragmentation, as described in the IP RFC ([INTERNET:1]), 2 MUST be supported by a router. This allows for the 3 transmission of IP datagrams on a destination or next hop 4 network, when the next network's MTU is smaller than the 5 packet being sent. 6 DISCUSSION: 7 Some people mistakenly believe that that a router which 8 supports only a single type of network interface 9 (Ethernet, for example) does not need to support 10 fragmentation, since fragmentation is not required 11 unless one of the connected networks has a smaller MTU 12 than the rest. This view is erroneous because the MTU 13 of any network is administratively settable (see 14 Section [3.2.4]). 15 When a router fragments a packet, it SHOULD minimize the 16 number of fragments. When a router fragments a packet, it Internet Engineering Task Force [Page 60] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 17 MUST send the fragments in order. A fragmentation method 18 which may generate one fragment which is significantly 19 smaller than the other MAY cause the first fragment to be 20 the small one. 21 DISCUSSION: 22 There are several common fragmentation techniques in 23 common use in the Internet. One involves splitting the 24 packet into chunks with the first being MTU sized, and 25 the others being approximately the same size, smaller 26 than the MTU. The reason for this is twofold. The 27 first packet in the logical sequence (even if it 28 arrives out of sequence) will be the effective MTU of 29 the current path between the hosts, and the following 30 packets are sized to hopefully minimize the further 31 fragmentation of the packet. Another technique is to 32 split the packet into MTU sized chunks, with the last 33 fragment being the only one smaller, as per RFC 791 34 (IP), page 26. 35 A common trick used by some implementations of TCP/IP 36 is to not send packet bigger than 576 bytes when 37 packets are traveling through a router. In general, 38 this allows the resulting packets to pass the rest of 39 the path without further fragmentation. This would, 40 though, create more of a load on the destination host, 41 since it would have a larger number of physical packets 42 to reassemble into one logical packet. It would also 43 not be efficient on networks where the MTU only changes 44 once, and stays much larger than 576 bytes (such as an 45 802.5 network with a MTU of 2048 or an Ethernet network 46 with an MTU of 1536). 47 One other fragmentation technique discussed was 48 splitting the packet into approximately equal sized 49 chunks, with the size being smaller than the next hop 50 network's MTU. This is intended to minimize the number 51 of fragments that would result from additional 52 fragmentation further down the path. 53 In most cases, routers should try and create situations 54 that will generate the lowest number of fragments 55 possible. Work with slow machines leads us to believe 56 that if it is necessary to send small packets in a 57 fragmentation scheme, that sending the small packet 58 first maximizes the chance of a host with a slow 59 interface of receiving all the fragments. Internet Engineering Task Force [Page 61] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 4.2.2.7 Reassembly: RFC-791 Section 3.2 1 As specified in Section 3.3.2 of [INTRO:2], a router MUST 2 support reassembly of datagrams which it delivers to itself. 3 A router MUST NOT reassemble any datagram before forwarding 4 it. 5 DISCUSSION: 6 A few people have suggested that there might be some 7 topologies where reassembly of transit datagrams by 8 routers might improve performance. In general, 9 however, the fact that fragments may take different 10 paths to the destination precludes safe use of such a 11 feature. 12 Nothing in this section should be construed to control 13 or limit fragmentation or reassembly performed as a 14 link layer function by the router. 4.2.2.8 Time to Live: RFC-791 Section 3.2 1 Time to Live (TTL) handling for packets originated or 2 received by the router is governed by [INTRO:2]. Note in 3 particular that a router MUST NOT check the TTL of a packet 4 except when forwarding it. 5 TTL processing of forwarded packets is discussed in Section 6 [5.3.1]. 4.2.2.9 Routing of Broadcasts: RFC-922 Section 6 1 This section is superseded by Section [5.3.5]. In 2 particular, all-subnets broadcasts (called "multi-subnet 3 broadcasts" in [INTERNET:3]) have been deprecated. 4.2.2.10 Addressing: RFC-791 Section 3.2 1 There are now five classes of IP addresses: Class A through 2 Class E. Class D addresses are used for IP multicasting 3 [INTERNET:4], while Class E addresses are reserved for 4 experimental use. 5 A multicast (Class D) address is a 28-bit logical address 6 that stands for a group of hosts, and may be either 7 permanent or transient. Permanent multicast addresses are 8 allocated by the Internet Assigned Number Authority 9 [INTRO:7], while transient addresses may be allocated Internet Engineering Task Force [Page 62] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 10 dynamically to transient groups. Group membership is 11 determined dynamically using IGMP [INTERNET:4]. 12 We now summarize the important special cases for Class A, B, 13 and C IP addresses, using the following notation for an IP 14 address: 15 { , } 16 or 17 { , , } 18 and the notation "-1" for a field that contains all 1 bits. 19 This notation is not intended to imply that the 1-bits in an 20 subnet mask need be contiguous. 21 (a) { 0, 0 } 22 This host on this network. MUST NOT be used as a | 23 source address by routers (a host, but not a router, | 24 may use this as a source address as part of an | 25 initialization procedure by which the host learns its | 26 own IP address). | 27 See also Section [4.2.3.1] for a non-standard use of 28 { 0, 0 }. 29 EDITOR'S COMMENTS: | 30 Is the prohibition of the use of 0.0.0.0 as a | 31 source address by routers in conflict with Section | 32 [10.2.3]? | 33 Also, we need to talk more about how routers | 34 handle packets received with a 0.0.0.0 (or | 35 { 0, } 51 Specified host on this network. It MUST NOT be sent by 52 routers (a host, but not a router, may use this as a 53 source address as part of an initialization procedure 54 by which the host learns its own IP address). 55 (c) { -1, -1 } 56 Limited broadcast. It MUST NOT be used as a source 57 address. 58 A datagram with this destination address will be 59 received by every host and router on the connected 60 physical network, but will not be forwarded outside 61 that network. 62 (d) { , -1 } 63 Directed broadcast to the specified network. It MUST 64 NOT be used as a source address. 65 (e) { , , -1 } 66 Directed broadcast to the specified subnet. It MUST 67 NOT be used as a source address. 68 (f) { , -1, -1 } 69 Directed broadcast to all subnets of the specified 70 subnetted network. It MUST NOT be used as a source 71 address. 72 (g) { 127, } 73 Internal host loopback address. Addresses of this form 74 MUST NOT appear outside a host. 75 The is administratively assigned so that 76 its value will be unique in the entire world. 77 IP addresses are not permitted to have the value 0 or -1 for 78 any of the , , or 79 fields (except in the special cases listed 80 above). This implies that each of these fields will be at Internet Engineering Task Force [Page 64] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 81 least two bits long. 82 For further discussion of broadcast addresses, see Section 83 [4.2.3.1]. 84 Since (as described in Section [4.2.1]) a router must 85 support the subnet extensions to IP, there will be a subnet 86 mask of the form: { -1, -1, 0 } associated with each of the 87 host's local IP addresses; see Sections [4.3.3.9], 88 [5.2.4.2], and [10.2.2]. 89 When a router originates any datagram, the IP source address 90 MUST be one of its own IP addresses (but not a broadcast or 91 multicast address). 92 For most purposes, a datagram addressed to a broadcast or 93 multicast destination is processed as if it had been 94 addressed to one of the router's IP addresses; we use the 95 term "specific-destination address" for the equivalent local 96 IP address of the host. The specific-destination address is 97 defined to be the destination address in the IP header 98 unless the header contains a broadcast or multicast address, 99 in which case the specific-destination is an IP address 100 assigned to the physical interface on which the datagram 101 arrived. 102 EDITOR'S COMMENTS: | 103 "physical interface" in the previous sentence seems | 104 wrong. You can't always tell which logical interface a | 105 packet arrived on, but you can usually narrow down the | 106 possibilities by looking at the source and destination | 107 addresses. The principle of least astonishment would | 108 seem to suggest that you should do so, and then pick | 109 from one of the logical interfaces that you couldn't | 110 weed out in that manner? | 111 A router MUST silently discard any received datagram 112 containing an IP source address that is invalid by the rules 113 of this section. This validation could be done either by 114 the IP layer or by each protocol in the transport layer. 115 Rules governing invalid source addresses in forwarded 116 packets are covered in Section [5.3.7]. 117 EDITOR'S COMMENTS: 118 This whole section is generally in need of a rewrite. 119 As part of that, overlap with section [5.3.7] should be 120 eliminated. Internet Engineering Task Force [Page 65] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 121 This section needs a reference to Noel's IP address | 122 hacks. 123 DISCUSSION: 124 A misaddressed datagram might be caused by a Link Layer 125 broadcast of a unicast datagram or by another router or 126 host that is confused or misconfigured. 4.2.3 SPECIFIC ISSUES 4.2.3.1 IP Broadcast Addresses 1 SOURCE: 2 Section 4.2.3.1 source: new text 3 Relationship to HRRFC: takes a slightly stronger stance 4 against zero-filled broadcast addresses. 5 For historical reasons, there are a number of IP addresses 6 (some standard and some not) which are used to indicate that 7 an IP packet is an IP broadcast. A router 8 (1) MUST treat as IP broadcasts packets addressed to 9 255.255.255.255, { , -1 }, 10 { , , -1 }, and 11 { , -1, -1 }. 12 (2) SHOULD (by default) silently discard on receipt (ie, 13 don't even deliver to applications in the router) any 14 packet addressed to 0.0.0.0, { , 0 }, 15 { , , 0 }, or 16 { , 0, 0 }; if these packets are not 17 silently discarded, they MUST be treated as IP 18 broadcasts (see Section [5.3.5]). 19 (3) SHOULD (by default) use the limited broadcast address 20 (255.255.255.255) when originating an IP broadcast 21 destined for a connected network or subnet (except when 22 sending an ICMP Address Mask Reply, as discussed in 23 Section [4.3.3.9]) 24 (4) SHOULD NOT (by default) originate datagrams addressed 25 to 0.0.0.0, { , 0 }, 26 { , , 0 }, or 27 { , 0, 0 }. 28 DISCUSSION: | 29 In the second bullet, the router obviously cannot | Internet Engineering Task Force [Page 66] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 30 recognize addresses of the form | 31 { , , 0 } if the router | 32 does not know how the particular network is subnetted. | 33 In that case, the rules of the second bullet do not | 34 apply because, from the point of view of the router, | 35 the packet is not an IP broadcast packet. | 4.2.3.2 IP Multicasting 1 SOURCE: 2 Section 4.2.3.2 source: new text 3 Relationship to HRRFC: identical for "host" functions 4 but adds discussion of multicast router functions. 5 An IP router SHOULD satisfy the Host Requirements with 6 respect to IP multicasting, as specified in Section 3.3.7 of 7 [INTRO:2]. That is, an IP router SHOULD support local IP 8 multicasting on all connected networks for which a mapping 9 from Class D IP adresses to link-layer addresses has been 10 specified (see the various IP-over-xxx specifications), and 11 on all connected point-to-point links. Support for local IP 12 multicasting includes originating multicast datagrams, 13 joining multicast groups and receiving multicast datagrams, 14 and leaving multicast groups. This implies support for all 15 of [INTERNET:4] except IGMP, which is optional (see Section 16 [4.4]). 17 DISCUSSION: 18 Although [INTERNET:4] is entitled Host Extensions for 19 IP Multicasting, it applies to all IP systems, both 20 hosts and routers. In particular, since routers may 21 join multicast groups, it is correct for them to 22 perform the "host" part of IGMP, reporting their group 23 memberships to any multicast routers that may be 24 present on their attached networks (whether or not they 25 themselves are multicast routers). -1z Some router 26 protocols may specifically require support for IP 27 multicasting (e.g., OSPF [ROUTE:1]), or may recommend 28 it (e.g., ICMP Router Discovery [INTERNET:13]). 29 An IP router MAY also perform the multicast router part of | 30 IGMP to discover the presence of multicast group members on | 31 its connected networks; if so, it should perform some sort | 32 of election procedure or protocol with its neighboring | 33 multicast routers, so that only one router on each physical | 34 network issues periodic Host Membership Queries. | Internet Engineering Task Force [Page 67] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 35 DISCUSSION: 36 The election procedure, and the time constants 37 associated with IGMP (such as the periodic query 38 interval) are specified as part of a particular 39 multicast routing protocol. 4.2.3.3 Path MTU Discovery 1 SOURCE: 2 Section 4.2.3.3 source: new text mostly stolen from RFC 3 1191 4 Relationship to HRRFC and RFC-1009: new requirements 5 In order to eliminate fragmentation or minimize it, it is 6 desirable to know what is the path MTU along the path from 7 the source to destination. The path MTU is the minimum of 8 the MTUs of each hop in the path. [INTERNET:14] describes a 9 new technique for dynamically discovering the maximum 10 transmission unit (MTU) of an arbitrary internet path. To 11 support this technique router need to generate special ICMP 12 messages. For a path that passes through a router that has 13 not been so changed, this technique might not discover the 14 correct Path MTU, but it will always choose a Path MTU as 15 accurate as, and in many cases more accurate than, the Path 16 MTU that would be chosen by older techniques or the current 17 practice. 18 Routers MUST implement the modified ICMP "Destination 19 Unreachable/Fragmentation needed and DF set" message 20 specified in [INTERNET:14] (Hosts forwarding source-routed 21 datagrams are considered to be routers, in this respect). 22 Note that a router does not drop a packet or send the ICMP 23 error message specified above unless the next hop hop in the 24 path is too small to accomodate the packet, even if the 25 router knows that a subsequent hop in the path will be too 26 small. When a router is originating an IP datagram, it 27 SHOULD use the scheme described in [INTERNET:14] to limit 28 the datagram's size. If the router's route to the 29 datagram's destination was learned from a routing protocol 30 that provides Path MTU information, the scheme described in 31 [INTERNET:14] is still used, but the Path MTU information 32 from the routing SHOULD be used as the initial guess as to 33 the Path MTU and also as an upper bound on the Path MTU. Internet Engineering Task Force [Page 68] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 4.3 INTERNET CONTROL MESSAGE PROTOCOL -- ICMP 1 SOURCE: 2 Section 4.3 source: RFC 1122 Section 3.2.2 and RFC 1009 3 Section 2.2 4 Relationship to HRRFC: Adds destination unreachable code 13, 5 14, and 15, and deletes codes 8 and 9. Routers are 6 authoritative providers of subnet masks by default, and never 7 believe ICMP Address Mask Replies. 4.3.1 INTRODUCTION 1 ICMP is an auxiliary protocol, which provides routing, 2 diagnostic and and error functionality for IP. It is described 3 in [INTERNET:8]. A router MUST support ICMP. 4 ICMP messages are grouped in two classes which are discussed in 5 the following sections: 6 ICMP error messages: 7 Destination Unreachable Section 4.3.3.1 8 Redirect Section 4.3.3.2 9 Source Quench Section 4.3.3.3 10 Time Exceeded Section 4.3.3.4 11 Parameter Problem Section 4.3.3.5 12 ICMP query messages: 13 Echo Section 4.3.3.6 14 Information Section 4.3.3.7 15 Timestamp Section 4.3.3.8 16 Address Mask Section 4.3.3.9 17 Router Discovery Section 4.3.3.10 18 General ICMP requirements and discussion are in the next 19 section. 4.3.2 GENERAL ISSUES 1 If an ICMP message of unknown type is received, it MUST be 2 passed to the ICMP user interface (if the router has one) or 3 silently discarded (if the router doesn't have one). 4 EDITOR'S COMMENTS: 5 The part about the ICMP user interface was suggested by 6 Steve Deering. It is contrary to RFC-1122, but this is Internet Engineering Task Force [Page 69] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 7 probably a case where RFC-1122 is erroneous. 8 When originating an ICMP message, the router MUST initialize 9 the TTL. The TTL for ICMP responses must not be taken from the 10 packet which triggered the response. 11 Every ICMP error message includes the Internet header and at 12 least the first 8 data octets of the datagram that triggered 13 the error. More than 8 octets MAY be sent, but the resulting 14 ICMP datagram SHOULD have a length of less than or equal to 576 15 octets. The returned IP header (and user data) MUST be 16 identical to that which was received, except that (except where 17 required by Section [4.3.3.5]) the router is not required to 18 undo any modifications to the IP header that are normally 19 performed in forwarding that were performed before the error 20 was detected (e.g. decrementing the TTL, updating options). 21 Except where this document specifies otherwise, the IP source 22 address in an ICMP message originated by the router MUST be one 23 of the IP addresses associated with the physical interface over 24 which the ICMP message is transmitted. If the interface has no | 25 IP addresses associated with it, the router's router-id (see | 26 Section [5.2.5]) is uused instead of an IP address. | 27 ICMP error messages SHOULD have their TOS bits set to the same 28 value as the TOS bits in the packet which provoked the sending 29 of the ICMP error message, unless setting them to that value 30 would cause the ICMP error message to be immediately discarded 31 because it could not be routed to its destination. Otherwise, 32 ICMP error messages MUST be sent with a normal (i.e. zero) TOS. | 33 An ICMP reply message SHOULD have its TOS bits set to the same | 34 value as the TOS bits in the ICMP request that provoked the | 35 reply. | 36 ICMP error messages MUST have their IP Precedence field set to | 37 the same value as the IP Precedence field in the packet which | 38 provoked the sending of the ICMP error message, except that the | 39 precedence value MUST be 6 (INTERNETWORK CONTROL) or 7 (NETWORK | 40 CONTROL), SHOULD be 7, and MAY be settable for the following | 41 types of ICMP error messages: Unreachable, Redirect, Time | 42 Exceeded, and Parameter Problem. | 43 An ICMP reply message MUST have its IP Precedence field set to | 44 the same value as the IP Precedence field in the ICMP request | 45 that provoked the reply. | 46 If the packet which provokes the sending of an ICMP error | 47 message contains a source route option, the ICMP error message | Internet Engineering Task Force [Page 70] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 48 SHOULD also contain a source route option of the same type | 49 (strict or loose), created by reversing the portion before the | 50 pointer of the route recorded in the source route option of the | 51 original packet UNLESS the ICMP error message is an ICMP | 52 Parameter Problem complaining about a source route option in | 53 the original packet. | 54 DISCUSSION: 55 In environments which use the U.S. Deparment of Defense 56 security option (defined in [INTERNET:5]), ICMP messages 57 may need to include a security option. Detailed 58 information on this topic should be available from the 59 Defense Communications Agency. 60 EDITOR'S COMMENTS: 61 The above stuff about security options in ICMP messages is 62 probably temporary, until I get the "real story" from 63 Steve Kent. 64 An ICMP error message MUST NOT be sent as the result of 65 receiving: 66 o an ICMP error message, or 67 o a packet which fails the IP header validation tests 68 described in Section [5.2.2] (except where that section 69 specifically permits the sending of an ICMP error 70 message), or 71 o a packet destined to an IP broadcast or IP multicast 72 address, or | 73 o a packet sent as a Link Layer broadcast or multicast, or 74 o a packet whose source address has a network number of zero 75 or is an invalid source address (as defined in Section 76 [5.3.7]), or 77 o any fragment of a datagram other then the first fragment 78 (ie, a packet for which the fragment offset in the IP 79 header is nonzero). 80 NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT 81 ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES. 82 DISCUSSION: 83 These rules aim to prevent the "broadcast storms" that 84 have resulted from routers or hosts returning ICMP error Internet Engineering Task Force [Page 71] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 85 messages in response to broadcast packets. For example, a 86 broadcast UDP segment to a non-existent port could trigger 87 a flood of ICMP Destination Unreachable datagrams from all 88 devices that do not have a client for that destination 89 port. On a large Ethernet, the resulting collisions can 90 render the network useless for a second or more. 91 Every packet that is broadcast on the connected network 92 should have a valid IP broadcast address as its IP 93 destination (see Section [5.3.4] and [INTRO:2]). However, 94 some devices violate this rule. To be certain to detect 95 broadcast packets, therefore, routers are required to 96 check for a link-layer broadcast as well as an IP-layer 97 broadcast address. 98 IMPLEMENTATION: 99 This requires that the link layer inform the IP layer when 100 a link-layer broadcast packet has been received; see 101 Section [3.1]. 102 A router which sends ICMP Source Quench messages MUST be able 103 to limit the rate at which the messages can be generated. A 104 router SHOULD also be able to limit the rate at which it sends 105 other sorts of ICMP error messages (Destination Unreachable, 106 Redirect, Time Exceeded, Parameter Problem). The limits SHOULD 107 be settable as part of the configuration of the router. How 108 the limits are applied (e.g., per router or per interface) is 109 left to the implementor's discretion. 110 DISCUSSION: 111 Two problems for a router sending ICMP error message are: 112 (1) the consumption of bandwidth on the reverse path, and 113 (2) the use of router resources (e.g., memory, CPU time) 114 To help solve these problems a router can limit the 115 frequency with which it generates ICMP error messages. 116 For similar reasons, a router may limit the frequency at 117 which some other sorts of messages, such as ICMP Echo 118 Replies, are generated. 119 IMPLEMENTATION: 120 Various mechanisms have been used or proposed for limiting 121 the rate at which ICMP messages are sent: 122 (1) Count-based -- for example, send an ICMP error 123 message for every N dropped packets overall or per Internet Engineering Task Force [Page 72] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 124 given source host. This mechanism might be 125 appropriate for ICMP Source Quench, but probably not 126 for other types of ICMP messages. 127 (2) Timer-based -- for example, send an ICMP error 128 message to a given source host or overall at most 129 once per T milliseconds. 130 (3) Bandwidth-based -- for example, limit the rate at 131 which ICMP messages are sent over a particular 132 interface to some fraction of the attached network's 133 bandwidth. 4.3.3 SPECIFIC ISSUES 4.3.3.1 Destination Unreachable 1 The ICMP Destination Unreachable message is sent by a router 2 in response to a packet which it cannot forward because the 3 destination (or next hop) is unreachable or a service is 4 unavailable 5 A router MUST be able to generate ICMP Destination 6 Unreachable messages and SHOULD choose a response code that 7 most closely matches the reason why the message is being 8 generated. 9 The following codes are defined in [INTERNET:8] and 10 [INTRO:2]: 11 0 = net unreachable - generated by a router if a forwarding 12 path (route) to the destination network is not 13 available; 14 1 = host unreachable - generated by a router if a 15 forwarding path (route) to the destination host on a 16 directly connected network is not available. 17 2 = protocol unreachable - generated if the transport 18 protocol designated in a datagram is not supported in 19 the transport layer of the final destination; 20 3 = port unreachable - generated if the designated 21 transport protocol (e.g. UDP) is unable to demultiplex 22 the datagram in the transport layer of the final 23 destination but has no protocol mechanism to inform the 24 sender; Internet Engineering Task Force [Page 73] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 25 4 = fragmentation needed and DF set - generated if a router 26 needs to fragment a datagram but cannot since the DF 27 flag is set; 28 5 = source route failed - generated if a router cannot 29 forward a packet to the next hop in a source route 30 option; 31 6 = destination network unknown - SHOULD NOT be generated 32 since it would imply on the part of the router that the 33 destination network does not exist (net unreachable 34 code 0 SHOULD be used in place of code 6); 35 7 = destination host unknown - generated only when a router 36 can determine (from link layer advice) that the 37 destination host does not exist; 38 11 = network unreachable for type of service - generated by 39 a router if a forwarding path (route) to the 40 destination network with the requested or default TOS 41 is not available; 42 12 = host unreachable for type of service - generated if a 43 router cannot forward a packet because its route(s) to 44 the destination do not match either the TOS requested 45 in the datagram or the default TOS (0). 46 The following additional codes are hereby defined: 47 13 = communication administratively prohibited - generated 48 if a router cannot forward a packet due to 49 administrative filtering. 50 14 = Host precedence violation. Sent by the first hop 51 gateway to a host to indicate that a requested 52 precedence is not permitted for the particular 53 combination of source/destination host or network, ULP, 54 and source/destination port. 55 15 = Precedence cutoff in effect. The network operators 56 have imposed a minimum level of precedence required for 57 operation, the datagram was sent with a precedence 58 below this level. 59 NOTE: RFC-1122 defined code 8 for "source host isolated". | 60 Routers SHOULD NOT generate code 8; whichever of codes 0 and | 61 1 is appropriate should be used instead. RFC-1122 also 62 defined code 9 for communication with destination network Internet Engineering Task Force [Page 74] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 63 administratively prohibited and code 10 for communication 64 with destination host administratively prohibited. These 65 codes were intended for use by end-to-end encryption devices 66 used by U.S military agencies. Routers SHOULD use the newly 67 defined code 13 if they administratively filter packets. 68 Routers MAY have a configuration option that causes code 13 69 messages not to be generated. When this option is enabled, 70 no ICMP error message is sent in response to a packet which 71 is dropped because its forwarding is administratively 72 prohibited. 73 Routers MAY have a configuration option that causes codes 14 74 and 15 messages not to be generated. When this option is 75 enabled, no ICMP error message is sent in response to a 76 packet which is dropped because of a precedence violation. 77 EDITOR'S COMMENTS: 78 Codes 13, 14, and 15 are not yet official; I need to 79 request official assignment from the IANA. 80 Routers MUST use host unreachable or host unknown codes 81 whenever other hosts on the same destination network might 82 be reachable; otherwise, the source host may erroneously 83 conclude that all hosts on the network are unreachable, and 84 that may not be the case. 85 [INTERNET:14] describes a slight modification the form of 86 Destination Unreachable messages containing code 4 87 (Fragmentation needed and DF set). As was stated in Section 88 [4.2.3.3], a router must use this modified form when 89 originating code 4 Destination Unreachable messages. 4.3.3.2 Redirect 1 The ICMP Redirect message is generated to inform a host on 2 the same subnet that the router used by the host to route 3 certain packets should be changed. 4 Routers MUST NOT generate the network redirect messages 5 (codes 0 and 2) specified in [INTERNET:8]. Routers MUST be 6 able to generate the Host redirect message (code 1) and 7 SHOULD be able to generate the Type of Service and Host 8 redirect message (code 3) specified in [INTERNET:8]. 9 DISCUSSION: 10 If the directly-connected network is not subnetted, a 11 router can normally generate a network Redirect which Internet Engineering Task Force [Page 75] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 12 applies to all hosts on a specified remote network. 13 Using a network rather than a host Redirect may 14 economize slightly on network traffic and on host 15 routing table storage. However, the savings are not 16 significant, and subnets create an ambiguity about the 17 subnet mask to be used to interpret a network Redirect. 18 In a general subnet environment, it is difficult to 19 specify precisely the cases in which network Redirects 20 can be used. Therefore, routers must send only host 21 (or host and type of service) Redirects. 22 A code 3 redirect is generated when the packet provoking the 23 redirect has a destination for which the path chosen by the 24 router would depend (in part) on the TOS requested. 25 However, the router MUST (to ensure backwards compatability) 26 substitute a type 1 redirect for a type 3 redirect if any of 27 the following are true: 28 o The router is configured to perform this substitution. 29 Routers which implement the origination of code 3 30 redirects MUST have a configuration option (which 31 defaults to on) to enable this substitution. 32 o The router does not support generation of type 3 33 redirects 34 Routers MUST NOT generate a Redirect unless all of the | 35 following conditions are met: | 36 o The packet is being forwarded out the same physical | 37 interface that it was received from. | 38 o The IP source address in the packet is on the same | 39 Logical IP (sub)network as the next-hop IP address. | 40 o The packet does not contain an IP source route option. | 41 The source address used in the ICMP Redirect MUST belong to | 42 the same logical (sub)net as the destination address. 43 A router using a routing protocol (other than static routes) | 44 MUST NOT consider paths learned from ICMP Redirects when | 45 forwarding a packet. If a router is not using a routing | 46 protocol, a router MAY have a configuration which, if set, | 47 allows the router to consider routes learned via ICMP | 48 Redirects when forwarding packets. | 49 Contrary to section 3.2.2.2 of [INTRO:2], a router MAY | Internet Engineering Task Force [Page 76] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 50 ignore ICMP Redirects when choosing s path for a packet | 51 originated by the router if the router is running a routing | 52 protocol or if forwarding is enabled on the router and on | 53 the interface over which the packet is being sent. | 54 DISCUSSION: 55 ICMP Redirect is a mechanism for routers to convey 56 routing information to hosts. Routers use other 57 mechanisms to learn routing information, and therefore 58 have no reason to obey redirects. Believing a redirect 59 which contradicted the router's other information would 60 likely create routing loops. 61 On the other hand, when a router is not acting as a 62 router, it must comply with the behavior required of a 63 host. 64 EDITOR'S COMMENTS: 65 A question left over from St. Louis: is there a 66 redirect for precedence? If not, should the Host + 67 Type of Service redirect (code 3) also be used for 68 precedence? 4.3.3.3 Source Quench 1 A router SHOULD NOT originate ICMP Source Quench messages. 2 As specified in Section [4.3.2], a router which does 3 originate Source Quench messages must be able to limit the 4 rate at which they are generated. 5 A router MAY ignore any ICMP Source Quench messages it 6 receives. 7 DISCUSSION: 8 Research seems to suggest that Source Quench consumes 9 network bandwidth but is an ineffective (and unfair) 10 antidote to congestion. See, for example, [INTERNET:9] 11 and [INTERNET:10]. Section [5.3.6] discusses the 12 current thinking on how routers ought to deal with 13 overload and network congestion. 14 A router itself may receive a Source Quench as the 15 result of sending a packet targeted to another router. 16 Such datagrams might be an EGP update, for example. A 17 mechanism has been proposed ([INTERNET:11], 18 [INTERNET:12]) to make the IP layer respond directly to 19 Source Quench by controlling the rate at which packets 20 are sent, however, this proposal is currently Internet Engineering Task Force [Page 77] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 21 experimental and not currently recommended. 4.3.3.4 Time Exceeded 1 A router MUST generate a Time Exceeded message Code 0 (In 2 Transit) when it discards a packet due to an expired TTL 3 field. A router MAY have a per-interface option to disable 4 origination of these messages on that interface, but that 5 option MUST default to allowing the messages to be 6 originated. 4.3.3.5 Parameter Problem 1 A router MUST generate a Parameter Problem message for any 2 error not specifically covered by another ICMP message. The 3 IP header field or IP option including the octet indicated 4 by the pointer field MUST be included unchanged in the IP 5 header returned with this ICMP message. 6 A new variant of the Parameter Problem message was defined 7 in [INTRO:2]: 8 Code 1 = required option is missing. 9 DISCUSSION: 10 This variant is currently in use in the military 11 community for a missing security option. 4.3.3.6 Echo Request/Reply 1 A router MUST implement an ICMP Echo server function that 2 receives Echo Requests and sends corresponding Echo Replies. 3 A router MUST be prepared to receive, reassemble and echo an 4 ICMP Echo Request datagram at least as large as the maximum 5 of 576 and the MTUs of all the connected networks. 6 The Echo server function MAY choose not to respond to ICMP 7 echo requests addressed to IP broadcast or IP multicast 8 addresses. 9 A router SHOULD have a configuration option which, if 10 enabled, causes the router to silently ignore all ICMP echo 11 requests; if provided, this option MUST default to allowing 12 responses. 13 DISCUSSION: 14 The neutral provision about responding to broadcast and 15 muticast Echo Requests results from the conclusions Internet Engineering Task Force [Page 78] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 16 reached in [INTRO:2]. 17 As stated in Section [10.3.3], a router must also implement 18 an application-layer interface for sending an Echo Request 19 and receiving an Echo Reply, for diagnostic purposes. 20 The IP source address in an ICMP Echo Reply MUST be the same 21 as the specific-destination address of the corresponding 22 ICMP Echo Request message. 23 EDITOR'S COMMENTS: 24 The previous paragraph is an example of a more general 25 problem: there is no clear definition of how to decide 26 the specific-destination address of a packet received 27 as an IP broadcast or IP multicast on an interface that 28 has multiple IP addresses. Anybody have any good ideas 29 about what we should say about this? 30 Data received in an ICMP Echo Request MUST be entirely 31 included in the resulting Echo Reply. 32 If a Record Route and/or Timestamp option is received in an 33 ICMP Echo Request, this option (these options) SHOULD be 34 updated to include the current router and included in the IP 35 header of the Echo Reply message, without "truncation". 36 Thus, the recorded route will be for the entire round trip. 37 If a Source Route option is received in an ICMP Echo 38 Request, the return route MUST be reversed and used as a 39 Source Route option for the Echo Reply message. 40 If a router implements an application-layer interface for 41 sending an ICMP Echo Request then all ICMP Echo Reply 42 messages MUST be passed to the ICMP user interface. 4.3.3.7 Information Request/Reply 1 A router SHOULD NOT implement these messages. 2 DISCUSSION: 3 The Information Request/Reply pair was intended to 4 support self-configuring systems such as diskless 5 workstations, to allow them to discover their IP 6 network numbers at boot time. However, these messages 7 are now obsolete. The RARP and BOOTP protocols provide 8 better mechanisms for a host to discover its own IP 9 address. Internet Engineering Task Force [Page 79] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 4.3.3.8 Timestamp and Timestamp Reply 1 A router MAY implement Timestamp and Timestamp Reply. If 2 they are implemented, the following rules MUST be followed. 3 o The ICMP Timestamp server function returns a Timestamp 4 Reply to every Timestamp message that is received. If 5 this function is implemented, it SHOULD be designed for 6 minimum variability in delay. 7 The following cases for Timestamp are to be handled 8 according to the corresponding rules for ICMP Echo: 9 o An ICMP Timestamp Request message to an IP broadcast or 10 IP multicast address MAY be silently discarded. 11 o The IP source address in an ICMP Timestamp Reply MUST 12 be the same as the specific-destination address of the 13 corresponding Timestamp Request message. 14 o If a Source Route option is received in an ICMP 15 Timestamp Request, the return route MUST be reversed 16 and used as a Source Route option for the Timestamp 17 Reply message. 18 o If a Record Route and/or Timestamp option is received 19 in a Timestamp Request, this (these) option(s) SHOULD 20 be updated to include the current router and included 21 in the IP header of the Timestamp Reply message. 22 o If the router provides an application-layer interface 23 for sending Timestamp Request messages then incoming 24 Timestamp Reply messages MUST be passed up to the ICMP 25 user interface. 26 The preferred form for a timestamp value (the "standard 27 value") is in units of milliseconds since midnight Universal 28 Time. However, it may be difficult to provide this value 29 with millisecond resolution. For example, many systems use 30 clocks that update only at line frequency, 50 or 60 times 31 per second. Therefore, some latitude is allowed in a 32 "standard value": 33 (a) A "standard value" MUST be updated at least 16 times 34 per second (i.e., at most the six low-order bits of the 35 value may be undefined). 36 (b) The accuracy of a "standard value" MUST approximate Internet Engineering Task Force [Page 80] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 37 that of operator-set CPU clocks, i.e., correct within a 38 few minutes. 39 EDITOR'S COMMENTS: 40 Host Requirements says 15 instead of 16 above. This is 41 a bug in Host Requirements that I need to mail to 42 Braden. 43 IMPLEMENTATION: 44 To meet the second condition, a router may need to 45 query some time server host when the router is booted 46 or restarted. It is recommended that the UDP Time 47 Server Protocol be used for this purpose. A more 48 advanced implementation would use the Network Time 49 Protocol (NTP) to achieve nearly millisecond clock 50 synchronization; however, this is not required. 4.3.3.9 Address Mask Request/Reply 1 SOURCE: 2 Relationship to HRRFC: RFC-1122 requires that mask 3 providers perform gratuitous Address Mask Replies, and 4 specifies host algorithms that depend on this behavior, 5 whereas by default routers do not send gratuitous 6 Address Mask Replies. 7 A router MUST implement support for receiving ICMP Address 8 Mask Request messages and responding with ICMP Address Mask 9 Reply messages. A router SHOULD have a configuration option 10 for each logical interface specifying whether the router is 11 allowed to answer Address Mask Requests for that interface; 12 this option MUST default to allowing responses. A router 13 MUST NOT respond to an Address Mask Request before the 14 router knows the correct subnet mask. 15 A router also MUST NOT respond to an Address Mask Request | 16 which has a source address of 0.0.0.0 and which arrives on a | 17 physical interface which has associated with it multiple | 18 logical interfaces, not all of which have the same subnet | 19 mask. | 20 A router SHOULD examine all ICMP Address Mask Replies which 21 it receives to determine whether the information it contains 22 matches the the router's knowledge of the subnet mask. If 23 the ICMP Address Mask Reply appears to be in error, the 24 router SHOULD log the subnet mask and the sender's IP 25 address. A router MUST NOT use the contents of an ICMP 26 Address Mask Reply to determine the correct subnet mask. Internet Engineering Task Force [Page 81] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 27 Because hosts may not be able to learn the subnet mask if a 28 router is down when the host boots up, a router MAY 29 broadcast a gratuitous ICMP Address Mask Reply on each of 30 its logical interfaces after it has configured its own 31 subnet masks. However, this feature can be dangerous in 32 environments which use variable length subnet masks. 33 Therefore, if this feature is implemented, gratuitous 34 Address Mask Replies MUST NOT be broadcast over any logical 35 interface(s) which either: 36 o are not configured to send gratuitous Address Mask 37 Replies. Each logical interface MUST have a 38 configuration parameter controlling this, and that 39 parameter MUST default to not sending the gratuitous 40 Address Mask Replies. 41 o share the same IP network number and physical interface 42 but have different subnet masks. 43 The { , -1, -1 } form (on subnetted 44 networks) or the { , -1 } form (on non- 45 subnetted networks) of the IP broadcast address MUST be used 46 for broadcast Address Mask Replies. 47 DISCUSSION: 48 The ability to disable sending Address Mask Replies by 49 routers is required at a few sites which intentionally 50 lie to their hosts about the subnet mask. The need for 51 this is expected to go away as more and more hosts 52 become compliant with the Host Requirements standards. 53 The reason for both the second bullet above and the 54 requirement about which IP broadcast address to use is 55 to prevent problems when multiple IP networks or 56 subnets are in use on the same physical network. 4.3.3.10 Router Advertisement and Solicitations 1 SOURCE: 2 Relationship to HRRFC: RFC-1122 predates the Router 3 Discovery work 4 An IP router MUST support the router part of the ICMP Router 5 Discovery Protocol [INTERNET:13] on all connected networks 6 on which the router supports either IP multicast or IP 7 broadcast addressing. The implementation MUST include all 8 of the configuration variables specified for routers, with 9 the specified defaults. Internet Engineering Task Force [Page 82] DRAFT INTERNET LAYER: PROTOCOLS October 1, 1991 10 DISCUSSION: 11 Routers are not required to implement the host part of 12 the ICMP Router Discovery Protocol, but might find it 13 useful for operation while IP forwarding is disabled 14 (i.e., when operating as a host). 4.4 INTERNET GROUP MANAGEMENT PROTOCOL -- IGMP 1 SOURCE: 2 Section 4.4 source: new text 3 Relationship to HRRFC: identical requirements 4 IGMP [INTERNET:4] is a protocol used between hosts and multicast 5 routers on a single physical network to establish hosts' 6 membership in particular multicast groups. Multicast routers use 7 this information, in conjunction with a multicast routing 8 protocol, to support IP multicast forwarding across the Internet. 9 A router MAY implement the host part an MAY implement the 10 multicast router part of IGMP. 11 DISCUSSION: | 12 Both are likely to be required in the future, See Section | 13 [4.2.3.1] for more information on IP multicasting. | 4.5 REQUIREMENTS SUMMARY 1 TBD Internet Engineering Task Force [Page 83] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 5. INTERNET LAYER -- FORWARDING 1 SOURCE: 2 Chapter 5 source: new text 3 Relationship to HRRFC: topics (mostly) are ones not covered 4 in HRRFC. Partially contradicts HRRFC on all-subnets 5 broadcast and (possibly) on IP precedence. Definitely 6 contradicts HRRFC on the issue of how many bits are in the 7 TOS field. 8 CONTRIBUTOR'S COMMENTS: 9 This chapter has (mostly) not been updated to be consistent 10 with [FORWARD:6] and [ROUTE:12]. Since those documents 11 represent the author's current thinking, readers should 12 expect that disagreements between those documents and this 13 chapter will be resolved by changes to this chapter. 5.1 INTRODUCTION 1 This section describes the process of forwarding packets. 5.2 FORWARDING WALK-THROUGH 1 There is no separate specification of the forwarding function in 2 IP. Instead, forwarding is covered by the protocol specifications 3 for the internet layer protocols ([INTERNET:1], [INTERNET:2], 4 [INTERNET:3], [INTERNET:8], and [ROUTE:12]). Essential background 5 information can be found in [FORWARD:6]. 5.2.1 Forwarding Algorithm 1 Since none of the primary protocol documents describe the 2 forwarding algorithm in any detail, we present it here. This 3 is just a general outline, and omits important details, such as 4 handling of congestion, that are dealt with in later sections. 5 (1) The router receives the packet (plus additional 6 information about it, as described in Section [3.1]) from 7 the Link Layer. 8 (2) The router validates the IP header, as described in 9 Section [5.2.2]. Note that IP reassembly is not done, 10 except on packets queued for local delivery in step (4). 11 (3) The router performs most of the processing of any IP 12 options. As described in Section [5.2.5], some IP options 13 require additional processing after the routing decision Internet Engineering Task Force [Page 84] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 14 has been made. 15 (4) The router examines the destination of the packet, as 16 described in Section [5.2.3], to determine how it should 17 continue to process the packet. There are three 18 possibilities: 19 o The packet is destined for the router, and should be 20 queued for local delivery. 21 o The packet is not destined for the router, and should 22 be queued for forwarding. 23 o The packet should be queued for forwarding, but (a 24 copy) must also be queued for local delivery. 25 Since the local delivery case is well-covered by [INTRO:2], the 26 following assumes that the packet was queued for forwarding. | 27 If the destination is an IP unicast address: 28 (5) The forwarder determines the next hop IP address for the 29 packet, usually by looking up the packet's destination in 30 the router's routing table. This procedure is described 31 in more detail in Section [5.2.4]. This procedure also 32 decides which network interface should be used to send to 33 packet. 34 (6) The forwarder verifies that forwarding the packet is 35 permitted. The source and destination addresses should be 36 valid, as described in Section [5.3.7] and Section [5.3.4] 37 If the router supports administrative constraints on 38 forwarding, such as those described in Section [5.3.9], 39 those constraints must be satisfied. 40 (7) The forwarder decrements (by at least one) and checks the 41 packet's TTL, as described in Section [5.3.1]. 42 (8) The forwarder performs any IP option processing that could 43 not be completed in step (3). 44 (9) The forwarder performs any necessary IP fragmentation, as 45 described in Section [4.2.2.6]. 46 (10) The forwarder determines the Link Layer address of the 47 packet's next hop. The mechanisms for doing this are Link 48 Layer-dependent (see Chapter [3]). Internet Engineering Task Force [Page 85] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 49 (11) The forwarder encapsulates the packet (or each of the 50 fragments thereof) in an appropriate Link Layer frame and 51 queues it for output on the appropriate interface. 52 (12) The forwarder sends an ICMP redirect if necessary, as 53 described in Section [4.3.3.2]. 54 If the destination is an IP multicast, the following steps are | 55 taken. Note that the main differences between the forwarding | 56 of IP unicasts and the forwarding of IP multicasts are 1) IP | 57 multicasts are usually forwarded based on both the datagram's | 58 source and destination 2) IP multicast has an expanding ring | 59 search 3) IP multicasts are forwarded as Link Level multicasts | 60 and 4) ICMP errors are never sent in response to IP multicast | 61 datagrams. | 62 Note that the forwarding of IP multicasts is still somewhat | 63 experimental. As a result, the algorithm presented below is not | 64 mandatory, and is provided as an example only. | 65 (5a) Based on the IP source and destination addresses found in | 66 the datagram header, the router determines whether the | 67 datagram has been received on the proper interface for | 68 forwarding. If not, the datagram is dropped silently. As | 69 for determination of the proper receiving interface, this | 70 depends on the multicast routing algorithm(s) in use. In | 71 one of the simplest algorithms, reverse path forwarding | 72 (RPF), the proper interface is the one that would be used | 73 to forward unicasts back to the datagram source. | 74 (6a) Based on the IP source and destination addresses found in | 75 the datagram header, the router determines the datagram's | 76 outgoing interfaces. In order to implement IP multicast's | 77 expanding ring search (see [INTERNET:4]) a minimum TTL | 78 value is specified for each outgoing interface. A copy of | 79 the multicast datagram is forwarded out each outgoing | 80 interface whose minimum TTL value is less than or equal to | 81 the TTL value in the datagram header, by separately | 82 applying the remaining steps on each such interface. | 83 (7a) The router decrements the packet's TTL by one. | 84 (8a) The forwarder performs any IP option processing that could | 85 not be completed in step (3). | 86 (9a) The forwarder performs any necessary IP fragmentation, as | 87 described in Section [4.2.2.6]. | Internet Engineering Task Force [Page 86] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 88 (10a)The forwarder determines the Link Layer address to use in | 89 the Link Level encapsulation. The mechanisms for doing | 90 this are Link Layer-dependent. On LANs a Link Level | 91 multicast or broadcast is selected, as an algorithmic | 92 translation of the datagrams' class D destination address. | 93 See the various IP-over-xxx specifications for more | 94 details. | 95 (11a)The forwarder encapsulates the packet (or each of the | 96 fragments thereof) in an appropriate Link Layer frame and | 97 queues it for output on the appropriate interface. | 98 It is not required that an implementation follow exactly the 99 algorithm given above. Much of the challenge of writing router 100 software is to maximize the rate at which the router can 101 forward packets while still achieving the same effect of the 102 above algorithm. Details of how to do that are beyond the 103 scope of this document, in part because they are heavily 104 dependent on the architecture of the router. Instead, we 105 merely point out the order dependencies among the steps: 106 (1) A router MUST verify the IP header, as described in 107 section [5.2.2], before performing any actions based on 108 the contents of the header. 109 (2) Processing of certain IP options requires that the router 110 insert its IP address into the option. As noted in 111 Section [5.2.5], the address inserted is required to be 112 the address of the logical interface on which the packet 113 is sent (or the router's router-id if the packet is sent 114 over an unnumbered interface). Thus, processing of these 115 options cannot be completed until after the output 116 interface is chosen. Processing of these options cannot 117 be completed until after fragmentation in implementations 118 that do a form of load splitting that may send different 119 fragments over different paths. 120 (3) The router cannot check and decrement the TTL before 121 checking whether the packet should be delivered to the 122 router itself, for reasons mentioned in Section [4.2.2.8]. 123 (4) More generally, when a packet is delivered locally to the 124 router, its IP header MUST NOT be modified in any way 125 (except that a router may be required to insert a 126 timestamp into any Timestamp options in the IP header). 127 Thus, before the router determines whether the packet is 128 to be delivered locally to the router, it cannot update 129 the IP header in any way that it is not prepared to undo. Internet Engineering Task Force [Page 87] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 130 CONTRIBUTOR'S COMMENTS: 131 We should note somewhere that an IP broadcast address may 132 appear as the last address in a source route but an IP 133 multicast address may not, and that neither is legal in 134 the middle of a source route. Include explicit references 135 to the relevant specs. Note the reason why this is true | 136 for multicasts: Since IP multicasts are forwarded on the | 137 basis of both their source and destination addresses, a | 138 source route option would subvert the multicast routing | 139 algorithms determination of proper receiving interface by | 140 altering the datagram's path. | 5.2.2 IP Header Validation 1 Before a router can process any IP packet, it must perform at 2 least some basic validity checks on the packet's IP header to 3 ensure that the header is meaningful. If the packet fails any 4 of the following tests, it MUST be silently discarded, and the 5 error SHOULD be logged: 6 o The packet length reported by the Link Layer must be 7 large enough to hold the minimum length legal IP 8 datagram (20 octets). 9 o The IP checksum must be correct 10 o The IP version number must be 4 11 o The IP header length field must be at least 5 12 o The IP total length field must be at least 4 * IP 13 header length field. 14 If the packet passes the second and third tests, the IP header 15 length field is at least 4, and both the IP total length field 16 and the packet length reported by the Link Layer are at least 17 16 then, despite the above rule, the router MAY respond with an 18 ICMP parameter problem message, whose pointer points at the IP 19 header length field (if it failed the fourth test) or the IP 20 total length field (if it failed the fifth test). However, it 21 still MUST discard the packet and still SHOULD log the error. 22 These rules (and this entire document) apply only to version 4 23 of the Internet Protocol (the standard version of IP). These 24 rules should not be construed as prohibiting routers from 25 supporting other versions of IP. 26 IMPLEMENTATION: Internet Engineering Task Force [Page 88] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 27 It is desirable for purposes of error reporting, though 28 not always entirely possible, to determine why a header 29 was invalid. There are four possible reasons: 30 o The Link Layer truncated the IP header 31 o The datagram is using a version of IP other than the 32 standard one (version 4). 33 o The IP header has been corrupted in transit. 34 o The sender generated an illegal IP header. 35 It is probably desirable to perform the checks in the 36 order listed, since we believe that this ordering is most 37 likely to correctly categorize the cause of the error. | 38 For purposes of error reporting, it may also be desirable | 39 to check if a packet which fails these tests has an IP | 40 version number equal to 6. If it does, the packet is | 41 probably an ST-II datagram. ST-II is described in | 42 [FORWARD:1]. | 43 In environments where reading invalid memory locations can 44 cause faults, the checksum routine might be implemented to 45 declare the checksum invalid if the IP header length 46 claims to be larger than the size of the packet. 47 Additionally, the router SHOULD verify that the packet length 48 reported by the Link Layer is at least as large as the IP total 49 length recorded in the packet's IP header. If it appears that | 50 the packet has been truncated, the packet MUST be discarded, | 51 the error SHOULD be logged, and the router SHOULD respond with | 52 an ICMP Parameter Problem message whose pointer points at the | 53 IP total length field. | 54 DISCUSSION: 55 Because any higher layer protocol which concerns itself 56 with data corruption will detect truncation of the packet 57 data when it reaches its final destination, it is not 58 absolutely necessary for routers to perform the check 59 suggested above in order to maintain protocol correctness. 60 However, by making this check a router can simplify 61 considerably the task of determining which hop in the path 62 is truncating the packets. 63 AUTHOR'S COMMENTS: 64 Ideally this case would result in an ICMP error reply, but 65 I don't think that there are any appropriate ones defined. Internet Engineering Task Force [Page 89] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 66 Should there be a new ICMP message which means "your 67 datagram was mangled in transit"? 68 Finally, if the destination address in the IP header is not one 69 of the addresses of the router, the router SHOULD verify that 70 the packet does not contain a Strict Source and Record Route 71 option. If a packet fails this test, the router SHOULD log the 72 error and SHOULD respond with an ICMP Parameter Problem error 73 with the pointer pointing at the offending packet's IP 74 destination address. 75 DISCUSSION: 76 Some people might suggest that the router should respond 77 with a Bad Source Route message instead of a Parameter 78 Problem message. However, when a packet fails this test, 79 it usually indicates a protocol error by the previous hop 80 router, whereas Bad Source Route would suggest that the 81 source host had requested a nonexistent or broken path 82 through the network. 5.2.3 Local Delivery Decision 1 When a router receives an IP packet, it must decide whether the 2 packet is addressed to the router (and should be delivered 3 locally) or the packet is addressed to another system (and 4 should be handled by the forwarder). There is also a hybrid 5 case, where certain IP broadcasts and IP multicasts are both 6 delivered locally and forwarded. A router MUST determine which 7 of the these three cases applies using the following rules: 8 o An unexpired source route option is one whose pointer 9 value does not point past the last entry in the source 10 route. If the packet contains an unexpired source route 11 option, the pointer in the option is advanced until either 12 the pointer does point past the last address in the option 13 or else the next address is not one of the router's own 14 addresses. In the latter (normal) case, the packet is 15 forwarded (and not delivered locally) regardless of the 16 rules below. 17 o The packet is delivered locally (and not considered for 18 forwarding) in the following cases: 19 - the packet's destination address exactly matches one 20 of the router's IP addresses 21 - the packet's destination address is a limited 22 broadcast address | Internet Engineering Task Force [Page 90] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 23 - the packet's destination is an IP multicast address | 24 in the range 224.0.0.1 - 224.0.0.255 and (at least) | 25 one of the logical interfaces associated with the | 26 physical interface on which the packet arrived is a | 27 member of the destination multicast group. | 28 o The packet is passed to the forwarder AND delivered 29 locally in the following cases: 30 - the packet's destination address is an IP broadcast 31 address that addresses at least one of the router's 32 logical interfaces but does not address any of the 33 logical interfaces associated with the physical 34 interface on which the packet arrived | 35 - the packet's destination is an IP multicast address | 36 which is not in the range 224.0.0.1 - 224.0.0.255 and | 37 (at least) one of the logical interfaces associated | 38 with the physical interface on which the packet | 39 arrived is a member of the destination multicast | 40 group. | 41 o The packet is delivered locally if the packet's 42 destination address is an IP broadcast address (other than 43 a limited broadcast address) that addresses at least one 44 of the logical interfaces associated with the physical 45 interface on which the packet arrived. The packet is ALSO 46 passed to the forwarder unless the link on which the 47 packet arrived uses an IP encapsulation that does not 48 encapsulate broadcasts differently than unicasts (e.g. by 49 using different Link Layer destination addresses). 50 o The packet is passed to the forwarder in all other cases. 51 DISCUSSION: 52 The purpose of the requirement in the last sentence of the 53 fourth bullet is to deal with a directed broadcast to 54 another net or subnet on the same physical cable. 55 Normally, this works as expected: the sender sends the 56 broadcast to the router as a Link Layer unicast. The 57 router notes that it arrived as a unicast, and therefore 58 must be destined for a different logical net (or subnet) 59 than the sender sent it on. Therefore, the router can 60 safely send it as a Link Layer broadcast out the same 61 (physical) interface over which it arrived. However, if 62 the router can't tell whether the packet was received as a 63 Link Layer unicast, the sentence ensures that the router 64 does the safe but wrong thing rather than the unsafe but Internet Engineering Task Force [Page 91] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 65 right thing. 66 IMPLEMENTATION: 67 As described in Section [5.3.4], packets received as Link 68 Layer broadcasts are generally not forwarded. It may be 69 advantageous to avoid passing to the forwarder packets it 70 would later discard because of the rules in that section. 71 Some Link Layers (either because of the hardware or 72 because of special code in the drivers) can deliver to the 73 router copies of all Link Layer broadcasts and multicasts 74 it transmits. Use of this feature can simplify the 75 implementation of cases where a packet has to both be 76 passed to the forwarder and delivered locally, since 77 forwarding the packet will automatically cause the router 78 to receive a copy of the packet that it can then deliver 79 locally. 80 Even in the absence of such a Link Layer, it is of course | 81 hardly necessary to make a copy of an entire packet in | 82 order to queue it both for forwarding and for local | 83 delivery, though care must be taken with fragments, since | 84 reassembly is performed on locally delivered packets but | 85 not on forwarded packets. One simple schemem is to | 86 associate a flag with each packet onthe router's output | 87 queue which indicates whether it should be queued for | 88 local deliverey after it has been sent. | 89 CONTRIBUTOR'S COMMENTS: 90 I would be much appreciative if some people would stare at 91 the above rules and make sure that directed broadcasts are 92 forwarded when they should be (and not forwarded when they 93 shouldn't be) when you have multiple subnets on a single 94 physical net, routers with multiple interfaces on the same 95 subnet, etc. 96 Most of the bullets (especially the third and fourth) need 97 to provide a more intuitive explanation of the cases they 98 cover. 99 General wording needs to be added mentioning that packets 100 which the above says are queued for forwarding get 101 (silently) discarded if forwarding is disabled on the 102 interface on which the packet arrived or on the router as 103 a whole. This doesn't affect local delivery (except 104 internal forwarding to addresses associated with other 105 interfaces???). Internet Engineering Task Force [Page 92] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 5.2.4 Determining the Next Hop Address 1 When a router is going to forward a packet, it must determine 2 whether it can send it directly to its destination, or whether 3 it needs to pass it to forward it through another router. If 4 the latter, it needs to determine which router to use. This 5 section explains how these determinations are made. 6 This section makes use of the following definitions: 7 o "LSRR" -- IP Loose Source and Record Route option 8 o "SSRR" -- IP Strict Source and Record Route option 9 o "source route option" -- an LSRR or an SSRR 10 o "ultimate destination address", or simply "destination 11 address" -- where the packet is being sent to: the last 12 address in the source route of a source-routed packet, or 13 the destination address in the IP header of a non-source- 14 routed packet 15 o "adjacent" -- reachable without going through any IP 16 routers 17 o "next hop address" -- the IP address of the adjacent host 18 or router to which the packet should be sent next 19 o "immediate destination address" -- the ultimate 20 destination address, except in source routed packets, 21 where it is the next address specified in the source route 5.2.4.1 Immediate Destination Address 1 If the destination address in the IP header is one of the 2 addresses of the router and the packet contains a source 3 route option, the immediate destination address is the 4 address pointed at by the pointer in that option if the 5 pointer does not point past the end of the option. 6 Otherwise, the immediate destination address is the same as 7 the IP destination address in the IP header. 8 A router MUST use the immediate destination address, not the 9 ultimate destination address, when determining how to handle 10 a packet. 11 It is an error for more than one source route option to 12 appear in a datagram. A router MUST NOT originate such a Internet Engineering Task Force [Page 93] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 13 packet. If it receives one, it SHOULD discard the packet 14 and reply with an ICMP Parameter Problem message whose 15 pointer points at the beginning of the second source route 16 option. 17 EDITOR'S COMMENTS: 18 Some of the previous paragraph really belongs in 19 chapter 4. 5.2.4.2 Local/Remote Decision 1 SOURCE: 2 Section 5.2.4.2 source: new text 3 Relationship to HRRFC: adds Router-ID kluge, ??? 4 Relationship to RFC-1009: ??? 5 After it has been determined that the IP packet needs to be 6 forwarded in accordance with the rules specified in Section 7 [5.2.3], the following algorithm MUST be used to determine 8 if the immediate destination is directly accessible (see 9 [INTERNET:2]): 10 (1) For each network interface that has not been assigned 11 any IP address (the "unnumbered lines" as described in 12 Section [2.4.4]), compare the router-id of the other 13 end of the line to the immediate destination address. 14 If they are exactly equal, the packet can be 15 transmitted through this interface. 16 (2) If no network interface has been selected in the first 17 step, for each IP address assigned to the router: 18 (a) Apply the subnet mask associated with the address 19 to this IP address. 20 IMPLEMENTATION: 21 The result of this operation will usually 22 have been computed and saved during 23 initialization. 24 (b) Apply the same subnet mask to the immediate 25 destination address of the packet. 26 (c) Compare the resulting values. If they are equal to 27 each other, the packet can be transmitted through 28 the corresponding network interface. Internet Engineering Task Force [Page 94] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 29 (3) If an interface has still not been selected, the 30 immediate destination is accessible only through some 31 other router. The selection of the router and the 32 "next hop" IP address is described in Section 33 [5.2.4.3]. 5.2.4.3 Next Hop Address 1 The router applies the algorithm in the previous section to 2 determine if the immediate destination address is reachable 3 without going through another router. If so, the next hop 4 address is the same as the immediate destination address. 5 Otherwise, the packet must be forwarded through another 6 router to reach its immediate destination. If the packet 7 contains an SSRR, the router MUST discard the packet and 8 reply with an ICMP Bad Source Route error. Otherwise, the 9 router looks up the immediate destination address in its 10 routing table to determine an appropriate next hop address. 11 EDITOR'S COMMENTS: | 12 WARNING: While little in this section is "wrong", the | 13 current description is overly simplistic. See | 14 "Ruminations on the Next Hop" [FORWARD:6] to get a | 15 flavor of what this section will say when it's | 16 finished. | 17 A routing table may contain several types of routes. Routes | 18 can in general be represented as a network with an | 19 associated mask. Routes are selected by searching for the | 20 best match. The best match is the longest or most specific | 21 match, starting at the front part of the address. A match | 22 is defined to occur if the packet's destination address when | 23 logically AND'd with a route's network's mask equals the | 24 route itself. | 25 DISCUSSION: | 26 An example would be a packet bound for a destination | 27 address of 128.102.18.22, and the routing table | 28 contains a route for 128.102.18.0 with a mask of | 29 0xffffff00. If 128.102.18.22 is logically anded with | 30 0xffffff00, the result is 128.102.18.0, which matches | 31 the network part of the route; i.e. 128.102.18.0. In | 32 this example, there is 24 bits of match, since the mask | 33 is a contiguous string of 24 1's starting with the left | 34 most bit. | 35 Now, if the routing table also contained a route for | Internet Engineering Task Force [Page 95] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 36 128.102.18.22, with mask of 0xffffffff, this would have | 37 yielded 32 bits of match, and this is a "better" match | 38 than the previous example's 24 bits of match. | 39 EDITOR'S COMMENTS: | 40 "starting at the front part of the address"? | 41 This approach generalizes the treatment of a number of | 42 particular types of routes, such as (in order of decreasing | 43 preference): | 44 (1) a host route is a route to a particular end system. 45 (2) a subnet route is a route to a particular subnet of a 46 network. | 47 (3) a default subnet route is a route to all subnets of a | 48 particular net for which there are not (explicit) | 49 subnet routes. | 50 (4) a net route is a route to a particular network. | 51 (5) a default net route (commonly called a "default route") | 52 is a route to all networks for which there are no | 53 (explicit) routes to the net or any of its subnets. | 54 EDITOR'S COMMENTS: | 55 It was pointed out in Atlanta that it is important to | 56 note that using a default route to forward to a class D | 57 (multicast) address is a "bad idea". More generally, | 58 this chapter needs to be clearer about what special | 59 rules exist for multicast routing and which general | 60 rules do not apply to multicast forwarding. A | 61 volunteer is (hopefully) working on this. | 62 CONTRIBUTOR'S COMMENTS: 63 The previous classification, while useful in certain 64 circumstances, is basically OBE in the modern world... 65 The idea of the routing table lookup is to find most 66 explicit routes that match the immediate destination address 67 of the packet. The result is a set of candidate routes. 68 This set MUST NOT contain any default (type 5) routes if the 69 routing table contains subnet routes whose network part 70 matches the network part of the packet's immediate 71 destination address. Internet Engineering Task Force [Page 96] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 72 IMPLEMENTATION: 73 Meeting the requirement of the last sentence is not 74 automatic if algorithms such as Patricia or Cecilia are 75 used for route lookup. If one of these algorithms is 76 used, it is necessary to add to the tree for each 77 subnetted network a special node that matches just the 78 network number. When the search ends at one of these 79 special nodes (indicating that the packet is destined 80 to a nonexistent subnet), the destination is 81 unreachable. 82 It is not appropriate for this document to require a | 83 particular structure for a router's routing table, | 84 however, the router must be able to support forwarding | 85 based on best match as defined earlier. Structures | 86 based on Patricia or Cecilia algorithms certain would | 87 support this kind of forwarding. Note that nowhere in | 88 the generalized description is any mention of class of | 89 network or subnets. | 90 If the set is empty (ie, no routes were found), the packet 91 MUST be discarded and an appropriate ICMP error generated 92 (ICMP Bad Source Route if the immediate destination address 93 came from a source route option; otherwise, whichever of 94 ICMP Destination Host Unreachable or Destination Network 95 Unreachable is appropriate, as described in Section 96 [4.3.3.1]). 97 Otherwise, the router deletes those routes from the set 98 which have inappropriate TOS values, as described in Section 99 [5.3.2]. If this leaves the set empty, the packet MUST be 100 discarded and an ICMP TOS Unreachable sent. 101 Otherwise, the router chooses from among the remaining 102 routes based on metrics and administrative preference, as 103 discussed in Section [????]. 104 CONTRIBUTOR'S COMMENTS: 105 The section referenced by the previous paragraph has 106 yet to be written. See [FORWARD:6] to see what it is 107 expected to say. 5.2.5 Addresses in Options: RFC-791 Section 3.1 1 When a router inserts its address into a Record Route, Strict 2 Source and Record Route, Loose Source and Record Route, or 3 Timestamp, it MUST use the IP address of the logical interface 4 on which the packet is being sent. Where this rule cannot be Internet Engineering Task Force [Page 97] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 5 obeyed because the output interface has no IP address (i.e. is 6 an unnumbered interface), the router MUST instead insert its 7 "router-id". The router's router-id is one of the router's IP | 8 addresses. Which of the router's addresses is used as the | 9 router-id MUST NOT change (even across reboots) unless changed | 10 by the network manager or unless the configuration of the | 11 router is changed such that the IP address used as the router- | 12 id ceases to be one of the router's IP addresses. | 13 DISCUSSION: | 14 This specification does not allow for routers which do not | 15 have at least one IP address. We do not view this as a | 16 serious limitation, since a router needs an IP address to | 17 meet the manageability requirements of Chapter [8] even if | 18 the router is connected only to point-to-point links. | 5.3 SPECIFIC ISSUES 5.3.1 Time to Live (TTL) 1 SOURCE: 2 Section 5.3.1 source: modified RFC-1009 3 Relationship to HRRFC: none 4 The Time-to-Live (TTL) field of the IP header is defined to be 5 a timer limiting the lifetime of a datagram. It is an 8-bit 6 field and the units are seconds. Each router (or other module) 7 that handles a packet must decrement the TTL by at least one, 8 even if the elapsed time was much less than a second. Since 9 this is very often the case, the TTL is effectively a hop count 10 limit on how far a datagram can propagate through the Internet. 11 When a router forwards a packet, it MUST reduce the TTL by at 12 least one. If it holds a packet for more than one second, it 13 MAY decrement the TTL by one for each second. 14 If the TTL is reduced to zero (or less), the packet MUST be | 15 discarded, and if the destination is not a multicast address | 16 the router MUST send an ICMP Time Exceeded message to the | 17 source. Note that a router MUST NOT discard an IP unicast or | 18 broadcast packet with a non-zero TTL merely because it can | 19 predict that another router on the path to the packet's final | 20 destination will decrement the TTL to zero. However, a router | 21 MAY do so for IP multicasts, in order to more efficiently | 22 implement IP multicast's expanding ring search algorithm (see | 23 [INTERNET:4]). | Internet Engineering Task Force [Page 98] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 24 SOURCE: 25 Section 5.3.1 source: new text 26 Relationship to HRRFC: none 27 DISCUSSION: 28 The IP TTL is used, somewhat schizophrenically, as both a 29 hop count limit and a time limit. Its hop count function 30 is critical to ensuring that routing problems can't melt 31 down the network by causing packets to loop infinitely in 32 the network. The time limit function is used by transport 33 protocols such as TCP to ensure reliable data transfer. 34 Many current implementations treat TTL as a pure hop 35 count, and in parts of the Internet community there is a 36 strong sentiment that the time limit function should 37 instead be performed by the transport protocols that need 38 it. 39 In this specification, we have reluctantly decided to 40 follow the strong belief among the router vendors that the 41 time limit function should be optional. They argued that 42 implementation of the time limit function is difficult 43 enough that it is currently not generally done. They 44 further pointed to the lack of documented cases where this 45 shortcut has caused TCP to corrupt data (of course, we 46 would expect the problems created to be rare and difficult 47 to reproduce, so the lack of documented cases provides 48 little reassurance that there haven't been a number of 49 undocumented cases). 50 IP multicast notions such as the expanding ring search may 51 not work as expected unless the TTL is treated as a pure 52 hop count. The same thing is somewhat true of traceroute. 53 ICMP Time Exceeded messages are required because the 54 traceroute diagnostic tool depends on them. 5.3.2 Type of Service (TOS) 1 The "Type-of-Service" byte in the IP header is divided into 2 three sections: the Precedence field (high-order 3 bits), a 3 field that is customarily called "Type of Service" or "TOS" 4 (next 4 bits), and a reserved bit (the low order bit). Rules 5 governing the reserved bit were described in Section [4.2.2.2]. 6 The Precedence field will be discussed in Section [5.3.3]. A 7 more extensive discussion of the TOS field and its use can be 8 found in [ROUTE:12]. Internet Engineering Task Force [Page 99] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 9 A router SHOULD consider the TOS field in a packet's IP header 10 when deciding how to forward it. The remainder of this section 11 describes the rules that apply to routers that conform to this 12 requirement. 13 A router MUST maintain a TOS value for each route in its 14 routing table. Routes learned via a routing protocol which 15 does not support TOS MUST be assigned a TOS of zero. 16 To choose a route to a destination, a router MUST use an 17 algorithm equivalent to the following: 18 (1) The router locates in its routing table all available 19 routes to the destination. 20 (2) If there are none, the router drops the packet because the 21 destination is unreachable. The router returns an ICMP 22 Destination Unreachable error specifying the appropriate 23 code: either Network Unreachable (code 0) or the Host 24 Unreachable code (code 1), as specified in Section 25 [4.3.3.1]. 26 (3) If one or more of those routes have a TOS that exactly 27 matches the TOS specified in the packet, the router 28 chooses the route with the best metric. 29 (4) Otherwise, the router repeats the above step, except 30 looking at routes whose TOS is zero. 31 (5) If no route was chosen above, the router drops the packet 32 because the destination is unreachable. The router 33 returns an ICMP Destination Unreachable error specifying 34 the appropriate code: either Network Unreachable with Type 35 of Service (code 11) or Host Unreachable with Type of 36 Service (code 12), as specified in Section [4.3.3.1]. 37 DISCUSSION: 38 Although TOS has been little used in the past, its use by 39 hosts is now mandated by the Requirements for Internet 40 Hosts RFCs ([INTRO:2] and [INTRO:3]). Support for TOS in | 41 routers may become a MUST in the future, but is a SHOULD | 42 for now until we get more experience with it and can | 43 better judge both its benefits and its costs. | 44 Various people have proposed that TOS should affect other 45 aspects of the forwarding function. For example: 46 (1) A router could place packets which have the "Low Internet Engineering Task Force [Page 100] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 47 Delay" bit set ahead of other packets in its output 48 queues. 49 (2) If a router is forced to discard packets, it could 50 try to avoid discarding those which have the "High 51 Reliability" bit set. 52 These ideas have been explored in more detail in RFC-1046, 53 but we don't yet have enough experience with such schemes 54 to make requirements in this area. 5.3.3 IP Precedence 1 SOURCE: 2 Section 5.3.3 source: new text 3 Relationship to HRRFC: RFC-1122 restricts precedence to 4 DOD applications 5 This section specifies requirements and guidelines for 6 appropriate processing of the IP Precedence field in routers. 7 Precedence is a scheme for allocating resources in the network 8 based on the relative importance of different traffic flows. 9 The IP specification defines specific values to be used in this 10 field for various types of traffic. 11 The basic mechanisms for precedence processing in a router are 12 preferential resource allocation, including both precedence- 13 ordered queue service and precedence-based congestion control, 14 and selection of Link Layer priority features. The router also 15 selects the IP precedence for routing, management and control 16 traffic it originates. 17 Precedence-ordered queue service, as discussed in this section, 18 includes but is not limited to the queue for the forwarding 19 process and queues for outgoing links. It is intended that a 20 router supporting precedence should also use the precedence 21 indication at whatever points in its processing are concerned 22 with allocation of finite resources, such as packet buffers or 23 Link Layer connections. The set of such points is 24 implementation-dependent. 25 DISCUSSION: 26 Although the Precedence field was originally provided for 27 use in DOD systems where large traffic surges or major 28 damage to the network are viewed as inherent threats, it 29 has useful applications for many non-military IP networks. 30 Although the traffic handling capacity of networks has Internet Engineering Task Force [Page 101] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 31 grown greatly in recent years, the traffic generating 32 ability of the users has also grown, and network overload 33 conditions still occur at times. Since IP-based routing 34 and management protocols have become more critical to the 35 successful operation of the Internet, overloads present 36 two additional risks to the network: 37 (1) High delays may result in routing protocol packets 38 being lost. This may cause the routing protocol to 39 deduce a topology change and propagate this 40 information to other routers. Not only can this 41 cause routes to oscillate, but an extra processing 42 burden may be placed on other routers. 43 (2) High delays may interfere with the use of network 44 management tools to analyze and perhaps correct or 45 relieve the problem in the network that caused the 46 overload condition to occur. 47 Implementation and appropriate use of the Precedence 48 mechanism alleviates both of these problems. 5.3.3.1 Precedence-Ordered Queue Service 1 Routers SHOULD implement precedence-ordered queue service. 2 Precedence-ordered queue service means that when a packet is 3 selected for output on a (logical) link, the packet of 4 highest precedence that has been queued for that link is 5 sent. Routers that implement precedence-ordered queue 6 service MUST also have a configuration option to suppress 7 precedence-ordered queue service in the Internet Layer. 8 Any router MAY implement other policy-based throughput 9 management procedures that result in other than strict 10 precedence ordering, but it MUST be configurable to suppress 11 them (i.e., use strict ordering). 12 As detailed in Section [5.3.6], routers that implement 13 precedence-ordered queue service discards low precedence 14 packets before discarding high precedence packets for 15 congestion control purposes. 16 Preemption (interruption of processing or transmission of a 17 packet) is not envisioned as a function of the Internet 18 Layer. Some protocols at other layers may provide 19 preemption features. Internet Engineering Task Force [Page 102] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 5.3.3.2 Lower Layer Precedence Mappings 1 Routers that implement precedence-ordered queueing MUST | 2 IMPLEMENT, and other routers SHOULD IMPLEMENT, Lower Layer | 3 Precedence Mapping. | 4 A router which implements Lower Layer Precedence Mapping: | 5 MUST be able to map IP Precedence to Link Layer | 6 priority mechanisms for link layers that have such a | 7 feature defined. | 8 MUST have a configuration option to select the Link | 9 Layer's default priority treatment for all IP traffic | 10 SHOULD be able to configure specific nonstandard | 11 mappings of IP precedence values to Link Layer priority | 12 values for each interface. | 13 DISCUSSION: 14 Some research questions the workability of the priority 15 features of some Link Layer protocols, and some 16 networks may have faulty implementations of the link 17 layer priority mechanism. It seems prudent to provide 18 an escape mechanism in case such problems show up in a 19 network. 20 On the other hand, there are proposals to use novel 21 queueing strategies to implement special services such 22 as low-delay service. Special services and queueing 23 strategies to support them need further research and 24 experimentation before they are put into widespread use 25 in the Internet. Since these requirements are intended 26 to encourage (but not force) the use of precedence 27 features in the hope of providing better Internet 28 service to all users, routers supporting precedence- 29 ordered queue service should default to maintaining 30 strict precedence ordering regardless of the type of 31 service requested. 32 Implementors may wish to consider that correct link 33 layer mapping of IP precedence is required by DOD 34 policy for TCP/IP systems used on DOD networks. 5.3.3.3 Precedence Handling For All Routers 1 A router (whether or not it employs precedence-ordered queue 2 service): Internet Engineering Task Force [Page 103] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 3 (1) MUST accept and process incoming traffic of all 4 precedence levels normally, unless it has been 5 administratively configured to do otherwise. 6 (2) MAY implement a validation filter to administratively 7 restrict the use of precedence levels by particular 8 traffic sources. If provided, this filter MUST NOT 9 filter out or cut off the following sorts of ICMP error 10 messages: Unreachable, Redirect, Time Exceeded, and 11 Parameter Problem. If this filter is provided, the 12 procedures required for packet filtering by addresses 13 are required for this filter also. 14 EDITOR'S COMMENTS: 15 The previous sentence is supposed to mean that, a 16 la Section [5.3.9], precedence filtering ought to 17 be able to be applied to particular 18 source/destination pairs, particular protocols, 19 particular ports, etc. I need to add a nice 20 sentence that says that (and also clean up the 21 wording of [5.3.9]). 22 An ICMP Destination Unreachable message with code 14 23 SHOULD be sent when a packet is dropped by the 24 validation filter, unless this has been suppressed by 25 configuration choice. 26 (3) MAY implement a cutoff function which allows the router 27 to be set to refuse or drop traffic with precedence 28 below a specified level. This function may be 29 activated by management actions or by some 30 implementation dependent heuristics, but there MUST be 31 a configuration option to disable any heuristic 32 mechanism that operates without human intervention. An 33 ICMP Destination Unreachable message with code 15 34 SHOULD be sent when a packet is dropped by the cutoff 35 function, unless this has been suppressed by 36 configuration choice. 37 (4) MUST NOT change precedence settings on packets it did 38 not originate. | 39 (5) SHOULD be able to configure distinct precedence values | 40 to be used for each routing or management protocol | 41 supported (except for those protocols, such as OSPF, | 42 which specify which precedence value must be used). | 43 (6) MAY be able to configure routing or management traffic | Internet Engineering Task Force [Page 104] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 44 precedence values independently for each peer address. 45 (7) MUST respond appropriately to Link Layer precedence- 46 related error indications where provided. An ICMP 47 Destination Unreachable message with code 15 SHOULD be 48 sent when a packet is dropped because a link cannot 49 accept it due to a precedence-related condition, unless 50 this has been suppressed by configuration choice. 51 DISCUSSION: 52 The precedence cutoff mechanism described in (3) is 53 somewhat controversial. Depending on the topological 54 location of the area affected by the cutoff, transit 55 traffic may be directed by routing protocols into the 56 area of the cutoff, where it will be dropped. This is 57 only a problem if another path unaffected by the cutoff 58 exists between the communicating points. Proposed ways 59 of avoiding this problem include providing some minimum 60 bandwidth to all precedence levels even under overload 61 conditions, or propagating cutoff information in 62 routing protocols. In the absence of a widely accepted 63 (and implemented) solution to this problem, great 64 caution is recommended in activating cutoff mechanisms 65 in transit networks. 66 A transport layer relay could legitimately provide the 67 function prohibited by (4) above. Changing precedence 68 levels causes subtle interactions with TCP and perhaps 69 other protocols; a correct design is a non-trivial 70 task. 71 The intent of (5) and (6) (and the discussion of IP 72 Precedence in ICMP messages in Section [4.3.2]) is that 73 the IP precedence bits should be appropriately set, 74 whether or not this router acts upon those bits in any 75 other way. We expect that in the future specifications | 76 for routing protocols and network management protocols | 77 will specify how the IP Precedence should be set for | 78 messages sent by those protocols. | 79 The appropriate response for (7) depends on the link 80 layer protocol in use. Typically, the router should 81 stop trying to send "offensive" traffic to that 82 destination for some period of time, and should return 83 an ICMP Destination Unreachable message with code 15 84 (service not available for precedence requested) to the 85 traffic source. It also should not try to reestablish 86 a preempted Link Layer connection for some period of Internet Engineering Task Force [Page 105] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 87 time. 5.3.4 Forwarding of Link Layer Broadcasts 1 SOURCE: 2 Section 5.3.4 source: new text 3 Relationship to HRRFC: none 4 Relationship to RFC-1009: new requirement? 5 The encapsulation of IP packets in most Link Layer protocols | 6 (except PPP) allows a receiver to distinguish broadcasts and | 7 multicasts from unicasts simply by examining the Link Layer | 8 protocol headers (most commonly, the Link Layer destination | 9 address). The rules in this section which refer to "Link Layer | 10 broadcasts" apply only to Link Layer protocols which allow | 11 broadcasts to be distinguished; likewise, the rules which refer | 12 to "Link Layer multicasts" apply only to Link Layer protocols | 13 which allow multicasts to be distinguished. | 14 A router MUST NOT forward any packet which the router received | 15 as a Link Layer broadcast (even if the IP destination address | 16 is also some form of broadcast address) unless the packet is an | 17 all-subnets-directed broadcast being forwarded as specified in | 18 [INTERNET:3]. | 19 DISCUSSION: | 20 As noted in Section [5.3.5.3], forwarding of all-subnets- | 21 directed broadcasts in accordance with [INTERNET:3] is | 22 optional and is not something that routers do by default. | 23 A router MUST NOT forward any packet which the router received 24 as a Link Layer multicast unless the packet's destination 25 address is an IP multicast address. 26 SOURCE: 27 Section 5.3.4, source: RFC-1122 Section 3.3.6 28 A router SHOULD silently discard a packet that is received via 29 a Link Layer broadcast but does not specify an IP multicast or 30 IP broadcast destination address. 31 When a router sends a packet as a Link Layer broadcast, the IP 32 destination address MUST be a legal IP broadcast or IP 33 multicast address. 34 EDITOR'S COMMENTS: Internet Engineering Task Force [Page 106] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 35 The requirements in this section are probably not exactly 36 correct, due to the existence of Link Layer protocols 37 (such as PPP) which encapsulate all packets, including IP 38 unicasts, as Link Layer broadcasts. 5.3.5 Forwarding of Internet Layer Broadcasts 1 SOURCE: 2 Section 5.3.5 source: new text 3 Relationship to HRRFC: hosts are also required to 4 understand 0-filled broadcasts? 5 There are two major types of IP broadcast addresses; limited 6 broadcast and directed broadcast. In addition, there are three 7 subtypes of directed broadcast; a broadcast directed to a 8 specified network, a broadcast directed to a specified 9 subnetwork, and a broadcast directed to all subnets of a 10 specified network. Classification by a router of a broadcast 11 into one of these categories depends on the broadcast address 12 and on the router's understanding (if any) of the subnet 13 structure of the destination network. The same broadcast will 14 be classified differently by different routers. 15 A limited IP broadcast address is defined to be all-ones: 16 { -1, -1 } or 255.255.255.255. 17 A net-directed broadcast is composed of the network portion of 18 the IP address with a local part of all-ones, 19 { , -1 }. For example, a Class A net broadcast 20 address is net.255.255.255, a Class B net broadcast address is 21 net.net.255.255 and a Class C net broadcast address is 22 net.net.net.255 where "net" is an octet of network address. 23 An all-subnets-directed broadcast is composed of the network 24 part of the IP address with a subnet and a host part of all- 25 ones, { , -1, -1 }. For example, an all- 26 subnets broadcast on a subnetted class B network is 27 net.net.255.255. A network must be known to be subnetted and 28 the subnet part must be all-ones before a broadcast can be 29 classified as all-subnets-directed. 30 A subnet-directed broadcast address is composed of the network 31 and subnet part of the IP address with a host part of all-ones, 32 { , , -1 }. For example, a 33 subnet-directed broadcast to subnet 2 of a class B network 34 might be net.net.2.255 (if the subnet mask was 255.255.255.0) 35 or net.net.1.127 (if the subnet mask was 255.255.255.128). A Internet Engineering Task Force [Page 107] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 36 network must be known to be subnetted and the net and subnet 37 part must not be all-ones before an IP broadcast can be 38 classified as subnet-directed. 39 As was described in Section [4.2.3.1], a router may encounter | 40 certain non-standard IP broadcast addresses: | 41 0.0.0.0 is an obsolete form of the limited broadcast | 42 address | 43 { , 0 } is an obsolete form of a net- | 44 directed broadcast address. | 45 { , 0, 0 } is an obsolete form of a all- | 46 subnets-directed broadcast address. | 47 { , , 0 } is an obsolete | 48 form of a subnet-directed broadcast address. | 49 As was described in that section, packets addressed to any of | 50 these addresses should be silently discarded, but if they are | 51 not, they must be treated in accordance with the same rules | 52 that apply to packets addressed to the non-obsolete forms of | 53 the broadcast addresses described above. These rules are | 54 described in the next few sections. | 5.3.5.1 Limited Broadcasts 1 Limited broadcasts MUST NOT be forwarded. Limited 2 broadcasts MUST NOT be discarded. Limited broadcasts MAY be 3 sent and SHOULD be sent instead of directed broadcasts where 4 limited broadcasts will suffice. 5 DISCUSSION: 6 Some routers contain UDP servers which function by 7 resending the requests (as unicasts or directed 8 broadcasts) to other servers. This requirement should 9 not be interpreted as prohibiting such servers. Note, 10 however, that such servers can easily cause packet 11 looping if misconfigured. Thus, providers of such 12 servers would probably be well-advised to document 13 their setup carefully and to consider carefully the TTL 14 on packets which are sent. 5.3.5.2 Net-directed Broadcasts 1 A router MUST classify as net-directed broadcasts all valid, 2 directed broadcasts destined for a remote network or an Internet Engineering Task Force [Page 108] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 3 attached nonsubnetted network. A router MUST forward net- 4 directed broadcasts. Net-directed broadcasts MAY be sent. 5 A router MAY have an option to disable receiving net- 6 directed broadcasts on an interface and MUST have an option 7 to disable forwarding net-directed broadcasts. These 8 options MUST default to permit receiving and forwarding 9 net-directed broadcasts. 10 CONTRIBUTOR'S COMMENTS: 11 Should we continue the prohibition of sending ICMP 12 error messages when dropping directed broadcasts? If 13 not, what message is returned? 14 There has been some debate about forwarding or not 15 forwarding directed broadcasts. I addressed the 16 problem by making the forwarding decision depend on the 17 router's knowledge of the subnet mask for the 18 destination network. Forwarding decisions for 19 subnetted networks should be made by routers with an 20 understanding of the subnet structure. Therefore, in 21 general, routers must forward directed broadcasts for 22 networks they are not attached to and for which they do 23 not understand the subnet structure, if we are going to 24 allow directed broadcasting and broadcasting from one 25 net to another (which I think we should do). One 26 router may interpret and handle the same IP broadcast 27 packet differently than another, depending on its own 28 understanding of the structure of the destination 29 (sub)network. Of course, we can allow options to turn 30 off these kinds of nonlocal directed broadcasts for 31 network administrators. 5.3.5.3 All-subnets-directed Broadcasts 1 A router MUST classify as all-subnets-directed broadcasts 2 all valid directed broadcasts destined for a directly 3 attached subnetted network which have all-ones in the subnet 4 part of the address. If the destination network is not 5 subnetted, the broadcast MUST be treated as a net-directed 6 broadcast. 7 A router MUST forward an all-subnets-directed broadcast as a | 8 link level broadcast out all physical interfaces connected | 9 to the IP network addressed by the broadcast, except that: | 10 A router MUST NOT forward an all-subnet-directed | 11 broadcast that was received by the router as a Link | Internet Engineering Task Force [Page 109] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 12 Layer broadcast, unless the router is forwarding the | 13 broadcast in accordance with [INTERNET:3] (see below). | 14 If a router receives an all-subnets-directed broadcast | 15 over a network which does not indicate via Link Layer | 16 framing whether the frame is a broadcast or a unicast, | 17 the packet MUST NOT be forwarded to any network which | 18 likewise does not indicate whether a frame is a | 19 broadcast. | 20 A router MUST NOT forward an all-subnets-directed | 21 broadcast if the router is configured not to forward | 22 such broadcasts. A router MUST have a configuration 23 option to deny forwarding of all-subnets-directed 24 broadcasts. The configuration option MUST default to 25 permit forwarding of all-subnets-directed broadcasts. 26 CONTRIBUTOR'S COMMENTS: 27 Should we continue the prohibition of sending ICMP 28 error messages when dropping directed broadcasts? If 29 not, what message is returned? -kwe 30 RFC-922 describes an alternative set of rules for forwarding | 31 of all-subnets-directed broadcasts (called multi-subnet- | 32 broadcasts in that document). A router MAY IMPLEMENT that | 33 alternative set of rules, but MUST use the set of rules | 34 described above unless explicitly configured to use the | 35 RFC-922 rules. | 36 DISCUSSION: | 37 As far as we know, the rules for multi-subnet | 38 broadcasts described in RFC-922 have never been | 39 implemented, suggesting that either they are too | 40 complex or the utility of multi-subnet broadcasts is | 41 low. The rules described in this section match current | 42 practice. In the future, we expect that IP multicast | 43 (see [INTERNET:4]) will be used to better solve the | 44 sorts of problems that multi-subnets broadcasts were | 45 intended to address. | 46 We were also concerned that hosts whose system managers | 47 neglected to configure with a subnet mask could | 48 unintentionally send multi-subnet broadcasts. | 49 A router SHOULD NOT originate all-subnets broadcasts, except 50 as required by Section [4.3.3.9] when sending ICMP Address 51 Mask Replies on subnetted networks. Internet Engineering Task Force [Page 110] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 52 EDITOR'S COMMENTS: 53 The current intention is to decree that (like 0-filled 54 IP broadcasts) the notion of the all-subnets broadcast 55 is obsolete. It should be treated as a directed 56 broadcast to the first subnet of the net in question 57 that it appears on. Routers MAY implement a switch 58 (default off) which if turned on enables the RFC-922 59 behavior for all-subnets broadcasts. 60 DISCUSSION: 61 If a router has a configuration option to allow for 62 forwarding all-subnet broadcasts, it should use a 63 spanning tree or other multicast forwarding algorithm 64 (which may be computed for other purposes such as 65 bridging or OSPF) to distribute the all-subnets 66 broadcast efficiently. In general, it is better to use 67 an IP multicast address rather than an all-subnets 68 broadcast. 5.3.5.4 Subnet-directed Broadcasts 1 A router MUST classify as subnet-directed broadcasts all 2 valid directed broadcasts destined for a directly attached 3 subnetted network in which the subnet part is not all-ones. 4 If the destination network is not subnetted, the broadcast 5 MUST be treated as a net-directed broadcast. 6 A router MUST forward subnet-directed broadcasts. 7 A router MUST have a configuration option to prohibit 8 forwarding of subnet-directed broadcasts. Its default 9 setting MUST permit forwarding of subnet-directed 10 broadcasts. 11 A router MAY have a configuration option to prohibit 12 forwarding of subnet-directed broadcasts from a source on a 13 network on which the router has an interface. If such an 14 option is provided, its default setting MUST permit 15 forwarding of subnet-directed broadcasts. 5.3.6 Congestion Control 1 SOURCE: 2 Section 5.3.6, source: new text 3 Relationship to HRRFC: none 4 Congestion in a network is loosely defined as a condition where Internet Engineering Task Force [Page 111] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 5 demand for resources (usually bandwidth or CPU time) exceeds 6 capacity. Congestion avoidance tries to prevent demand from 7 exceeding capacity, while congestion recovery tries to restore 8 an operative state. It is possible for a router to contribute 9 to both of these mechanisms. A great deal of effort has been 10 spent studying the problem. The reader is encouraged to read 11 [FORWARD:2] for a survey of the work. Important papers on the 12 subject include [FORWARD:3], [FORWARD:4], [FORWARD:5], and 13 [INTERNET:10], among others. 14 The amount of storage that router should have available to 15 handle peak instantaneous demand when hosts use reasonable 16 congestion policies, such as described in [FORWARD:5], is a 17 function of the product of the bandwidth of the link times the 18 path delay of the flows using the link, and therefore storage 19 should increase as this Bandwidth*Delay product increases. The 20 exact function relating storage capacity to probability of 21 discard is not known. 22 When a router receives a packet beyond its storage capacity it 23 must (by definition, not by decree) discard it or some other 24 packet or packets. Which packet to discard is the subject of | 25 much study but, unfortunately, little agreement so far. | 26 A router MAY discard the packet it has just received; this is | 27 the simplest but not the best policy. It is considered better | 28 policy to randomly pick some transit packet on the queue and | 29 discard it (see [FORWARD:2]). A router MAY use this Random | 30 Drop algorithm to determine which packet to discard. | 31 If a router implements a discard policy (such as Random Drop) | 32 under which it chooses a packet to discard from among a pool of | 33 eligible packets: | 34 If precedence-ordered queue service (described in Section | 35 [5.3.3.1]) is implemented and enabled, the router MUST NOT | 36 discard a packet whose IP precedence is higher than that | 37 of a packet which is not discarded. | 38 A router MAY protect packets whose IP headers request the | 39 "maximize reliabilty" TOS, except where doing so would be | 40 in violation of the previous rule. | 41 A router MAY protect fragmented IP packets, on the theory | 42 that dropping a piece of a may increase congestion by | 43 causing all pieces of the datagram to be retransmitted by | 44 the source. | Internet Engineering Task Force [Page 112] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 45 To help prevent routing perturbations or disruption of | 46 management functions, the router MAY protect packets used | 47 for routing control, link control, or network management | 48 from being discarded. Dedicated routers (ie. routers | 49 which are not also general purpose hosts, terminal | 50 servers, etc.) can achieve an approximation of this rule | 51 by protecting packets whose source or destination is the | 52 router itself. | 53 Advanced methods of congestion control include a notion of 54 fairness, so that the 'user' that is penalized by losing a 55 packet is the one that contributed the most to the congestion. 56 No matter what mechanism is implemented to deal with bandwidth 57 congestion control, it is important that the CPU effort 58 expended be sufficiently small that the router is not driven 59 into CPU congestion also. 60 As described in Section [4.3.3.3], this DRAFT recommends that a 61 router should not send a Source Quench to the sender of the 62 packet that it is discarding. ICMP Source Quench is a very 63 weak mechanism, so it is not necessary for a router to send it, 64 and host software should not use it exclusively as an indicator 65 of congestion. 5.3.7 Martian Address Filtering 1 EDITOR'S COMMENTS: | 2 Does anything here need to be adjusted for Noel's short | 3 term address hacks? | 4 An IP source address is invalid if it is an IP broadcast 5 address or is not a class A, B, or C address. 6 An IP destination address is invalid if it is not a class A, B, 7 C, or D address. 8 A router SHOULD NOT forward any packet which has an invalid IP 9 source address or a source address on network 0. A router 10 SHOULD NOT forward, except over a loopback interface, any 11 packet which has a source address on network 127. A router MAY 12 have a switch which allows the network manager to disable these 13 checks. 14 A router SHOULD NOT forward any packet which has an invalid IP 15 destination address or a destination address on network 0. A 16 router SHOULD NOT forward, except over a loopback interface, 17 any packet which has a destination address on network 127. A 18 router MAY have a switch which allows the network manager to Internet Engineering Task Force [Page 113] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 19 disable these checks. 20 If a router discards a packet because of these rules, it SHOULD 21 log at least the IP source address, the IP destination address, 22 and, if the problem was with the source address, the physical 23 interface on which the packet was received and the Link Layer 24 address of the host or router from which the packet was 25 received. 5.3.8 Source Address Validation 1 A router SHOULD provide the ability to filter traffic based on | 2 a comparison of the source address of a packet to the | 3 forwarding table for a logical interface on which the packet | 4 was received. If this filtering is enabled, the router MUST 5 silently discard a packet if the interface on which the packet 6 was received is not the interface on which a packet would be 7 forwarded to reach the address contained in the source address. 8 In simpler terms, if a router wouldn't route a packet 9 containing this address through a particular interface, don't 10 believe the address if it appears as a source address in a 11 packet read from this interface. 12 DISCUSSION: | 13 This feature can provide useful security improvements in | 14 some situations, but can erroneously discard valid packets | 15 in situations where paths are assymetric. | 5.3.9 Packet Filtering and Access Lists 1 SOURCE: 2 Section 5.3.9 source: new text 3 Relationship to HRRFC: none 4 As a means of providing security and/or limited traffic through 5 portions of a network a router SHOULD provide the ability to 6 selectively forward (or filter) packets. If this capability is 7 provided, filtering of packets MUST be configurable either to 8 forward all packets or to selectively forward them based upon 9 the source and destination addresses. Each source and 10 destination address SHOULD allow specification of an arbitrary 11 mask. 12 If supported, a router MUST be configurable to allow one of an 13 o Include list -- specification of a list of address pairs 14 to be forwarded, or an Internet Engineering Task Force [Page 114] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 15 o Exclude list -- specification of a list of address pairs 16 NOT to be forwarded. 17 A router MAY provide a configuration switch which allows a 18 choice between specifying an include or an exclude list. 19 A value matching any address (e.g. a keyword "any" or an 20 address with a mask of all 0's) MUST be allowed as a source 21 and/or destination address. 22 In addition to address pairs, the router MAY allow any 23 combination of transport and/or application protocol and source 24 and destination ports to be specified. 25 The router MUST allow packets to be silently discarded (ie. 26 discarded without an ICMP error message being sent). 27 The router SHOULD allow an appropriate ICMP unreachable message 28 to be sent when a packet is discarded. The ICMP message SHOULD 29 specify Communication Administratively Prohibited (code 13) as 30 the reason for the destination being unreachable. 31 The router SHOULD allow the sending of ICMP destination 32 unreachable messages (code 13) to be configured for each 33 combination of address pairs, protocol types, and ports it 34 allows to be specified. 35 The router SHOULD count and SHOULD allow selective logging of | 36 packets not forwarded. | 5.3.10 Multicast Routing 1 An IP router MAY support forwarding of IP multicast packets, 2 based either on static multicast routes or on routes 3 dynamically determined by a multicast routing protocol (e.g., 4 DVMRP [ROUTE:10]). A router that forwards IP multicast packets 5 is called a multicast router. 5.3.11 Controls on Forwarding 1 SOURCE: 2 Section 5.3.12 source: new text 3 Relationship to HRRFC: none 4 For each physical interface, a router SHOULD have a 5 configuration option which specifies whether forwarding is 6 enabled on that interface. When forwarding on an interface is Internet Engineering Task Force [Page 115] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 7 disabled, the router: 8 o silently discards any packets which are received on that 9 interface but are not addressed to the router 10 o does not send packets out that interface, except for 11 datagrams originated by the router 12 o does not announce via any routing protocols the 13 availability of paths through the interface 14 DISCUSSION: 15 This feature allows the network manager to essentially 16 turn off an interface but leaves it accessible for network 17 management. 18 Ideally, this control would apply to logical rather than 19 physical interfaces, but cannot because there is no known 20 way for a router to determine which logical interface a 21 packet arrived on when there is not a one-to-one 22 correspondence between logical and physical interfaces. 5.3.12 State Changes | 1 During the course of router operation, interfaces may fail or | 2 be manually disabled, or may become available for use by the | 3 router. Similarly, forwarding may be disabled for a particular | 4 interface or for the entire router or may be (re)enabled. | 5 While such transitions are (usually) uncommon, it is important | 6 that routers handle them correctly. | 5.3.12.1 When a Router Ceases Forwarding | 1 When a router ceases forwarding it MUST stop advertising all | 2 routes, except for third party routes. It MAY continue to | 3 receive and use routes from other routers in its routing | 4 domains. If the forwarding database is retained, the router | 5 MUST NOT cease timing the routes in the forwarding database. | 6 If routes that have been received from other routers are | 7 remembered, the router MUST NOT cease timing the routes | 8 which it has remembered. It MUST discard any routes whose | 9 timers expire while forwarding is disabled, just as it would | 10 do if forwarding were enabled. | 11 A router MAY send ICMP destination unreachable (host | 12 unreachable) messages to the senders of packets that it is | 13 unable to forward. It SHOULD NOT send ICMP redirect | 14 messages. | Internet Engineering Task Force [Page 116] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 15 When a router begins forwarding, it SHOULD expedite the | 16 sending of new routing information to all routers with which | 17 it normally exchanges routing information. | 18 DISCUSSION: | 19 When a router ceases forwarding, it essentially ceases | 20 being a router. It is still a host, and must follow | 21 all of the requirements in the Host Requirements RFC | 22 [INTRO: 2]. The router may still be a passive member | 23 of one or more routing domains, however. As such, it | 24 is allowed to maintain its forwarding database by | 25 listening to other routers in its routing domain. It | 26 may not, however, advertise any of the routes in its | 27 forwarding database, since it itself is doing no | 28 forwarding. The only exception to this rule is when | 29 the router is advertising a route which uses only some | 30 other router, but which this router has been asked to | 31 advertise. | 32 A router is also cannot allow its forwarding database or any | 33 remembered routes to become stale. Thus, a router must | 34 continue to time all remembered routes. | 35 Note that sending an ICMP destination unreachable (host | 36 unreachable) is a router action. This message should not be | 37 sent by hosts. This exception to the rules for hosts is | 38 allowed so that packets may be rerouted in the shortest | 39 possible time, and so that "black holes" are avoided. | 5.3.12.2 When an Interfaces Fails or is Disabled | 1 If an interface fails or is disabled a router MUST remove | 2 and stop advertising all routes in its forwarding database | 3 which make use of that interface. It MUST disable all | 4 static routes which make use of that interface. If other | 5 routes to the same destination and TOS are learned or | 6 remembered by the router, the router MUST choose the best | 7 alternate, and add it to its forwarding database. The | 8 router SHOULD send ICMP destination unreachable or ICMP | 9 redirect messages, as appropriate, in reply to all packets | 10 which it is unable to forward due to the interface being | 11 unavailable. | 5.3.12.3 When an Interface is Enabled | 1 If an interface which had not been available is enabled, or | 2 comes back to life, a router MUST reenable any static routes | 3 which use that interface. If routes which would use that | Internet Engineering Task Force [Page 117] DRAFT INTERNET LAYER: FORWARDING October 1, 1991 4 interface are learned by the router, then these routes MUST | 5 be evaluated along with all of the other learned routes, and | 6 the router MUST make a decision as to which routes should be | 7 placed in the forwarding database. The implementor is | 8 referred to Chapter [7], "Application Layer -- Routing | 9 Protocols" for further information on how this decision is | 10 made. | 11 A router SHOULD expedite the sending of new routing | 12 information to all routers with which it normally exchanges | 13 routing information. | 5.4 REQUIREMENTS SUMMARY 1 TBD Internet Engineering Task Force [Page 118] DRAFT TRANSPORT LAYER October 1, 1991 6. TRANSPORT LAYER 1 A router is not required to implement any Transport Layer protocols 2 except those required to support Application Layer protocols 3 supported by the router. In practice, this means that most routers 4 implement both the Transmission Control Protocol (TCP) and the User 5 Datagram Protocol (UDP). 6.1 USER DATAGRAM PROTOCOL -- UDP 1 The User Datagram Protocol (UDP), defined by [TRANS:1], offers 2 only a minimal transport service -- non-guaranteed datagram 3 delivery -- and gives applications direct access to the datagram 4 service of the IP layer. UDP is used by applications that do not 5 require the level of service of TCP or that wish to use 6 communications services (e.g., multicast or broadcast delivery) 7 not available from TCP. 8 UDP is almost a null protocol; the only services it provides over 9 IP are checksumming of data and multiplexing by port number. 10 Therefore, an application program running over UDP must deal 11 directly with end-to-end communication problems that a 12 connection-oriented protocol would have handled -- e.g., 13 retransmission for reliable delivery, packetization and 14 reassembly, flow control, congestion avoidance, etc., when these 15 are required. The fairly complex coupling between IP and TCP will 16 be mirrored in the coupling between UDP and many applications 17 using UDP. 18 A router which implements UDP MUST be compliant, and SHOULD be 19 unconditionally compliant, with the requirements of section 4.1 of 20 [INTRO:2], except that: 21 o This specification does not specify the interfaces between 22 the various protocol layers. Thus, a router need not comply 23 with sections 4.1.3.2, 4.1.3.3, and 4.1.3.6 of [INTRO:2] 24 (except of course where compliance is required for proper 25 functioning of Application Layer protocols supported by the 26 router). 27 o Contrary to section 4.1.3.4 of [INTRO:2], an application MUST 28 NOT be able to disable to generation of UDP checksums. 29 DISCUSSION: 30 Although a particular application protocol may require that 31 UDP datagrams it receives must contain a UDP checksum, there 32 is no general requirement that received UDP datagrams contain 33 UDP checksums. Of course, if a UDP checksum is present in a Internet Engineering Task Force [Page 119] DRAFT TRANSPORT LAYER October 1, 1991 34 received datagram, the checksum must be veried and the 35 datagram discarded if the checksum proves to be incorrect. 6.2 TRANSMISSION CONTROL PROTOCOL -- TCP 1 The Transmission Control Protocol (TCP), defined by [TRANS:2], is 2 the primary virtual-circuit transport protocol for the Internet 3 suite. TCP provides reliable, in-sequence delivery of a full- 4 duplex stream of octets (8-bit bytes). TCP is used by those 5 applications needing reliable, connection-oriented transport 6 service. 7 A router which implements TCP MUST be compliant, and SHOULD be 8 unconditionally compliant, with the requirements of section 4.2 of 9 [INTRO:2], except that: 10 o This specification does not specify the interfaces between 11 the various protocol layers. Thus, a router need not comply | 12 with requirements of [INTRO:2] (except of course where | 13 compliance is required for proper functioning of Application | 14 Layer protocols supported by the router): | 15 - Notification of the application of PSH bit set. | 16 [4.2.2.2] | 17 - Notification of the application of urgent data. | 18 [4.2.2.4] | 19 - Providing application layer interface to retransmit | 20 timers. [4.2.3.5] | 21 - Application layer specification of source route. | 22 [4.2.3.8] | 23 - Flush Call. [4.2.4.3] | 24 - Multi-homing. [4.2.4.4] | 25 o The requirements of section 4.2.2.6 of [INTRO:2] are amended | 26 as follows: a router which implements the host portion of MTU | 27 discovery (discussed in Section [4.2.3.3] of this memo) uses | 28 536 as the default value of SendMSS only if the path MTU is | 29 unknown; if the path MTU is known, the default value for | 30 SendMSS is the path MTU - 40. | 31 DISCUSSION: | 32 It should particularly be noted that a TCP implementation in | Internet Engineering Task Force [Page 120] DRAFT TRANSPORT LAYER October 1, 1991 33 a router must conform to the following requirements of | 34 [INTRO:2]: | 35 - Providing a configurable TTL. [4.2.2.1] | 36 - Providing an interface to configure keep-alive behavior, | 37 if keep-alives are used at all. [4.2.3.6] | 38 - Providing an error reporting mechanism, and the ability | 39 to manage it. [4.2.4.1] | 40 - Specifying type of service. [4.2.4.2] | 41 The general paradigm applied is that if a particular | 42 interface is visible outside the router, then the interface | 43 must be followed. For example, if a router provides a telnet | 44 function, then it will be generating traffic, likely to be | 45 routed in the external networks. Therefore, it must be able | 46 to set the type of service correctly, else the telnet traffic | 47 may not get through. | 48 AUTHOR'S COMMENTS: | 49 Do we need to state, in these sections that exempt routers | 50 from pieces of Host Requirements, that routers which | 51 implement an application programming interface are not exempt | 52 from the layer interface requirements? | 6.3 REQUIREMENTS SUMMARY 1 TBD Internet Engineering Task Force [Page 121] DRAFT ROUTING PROTOCOLS October 1, 1991 7. APPLICATION LAYER -- ROUTING PROTOCOLS 1 SOURCE: 2 Chapter 7 source: new text 3 Relationship to HRRFC: none 7.1 INTRODUCTION 1 An Autonomous System (AS) is defined as a set of routers all 2 belonging under the same authority and all subject to a consistent 3 set of routing policies. Interior Gateway Protocols (IGPs) are 4 used to distribute routing information inside of an AS (i.e. 5 intra-AS routing). Exterior Gateway Protocols are used to exchange 6 routing information between ASs (i.e. inter-AS routing). 7 EDITOR'S COMMENTS: 8 What, if anything, should we say about multicast routing, 9 other than what's in Section [5.3.10]? 7.1.1 Routing Security Considerations 1 Routing is one of the few places where the Robustness Principle 2 ("be liberal in what you accept", discussed in Section [1.3.2]) 3 does not apply. Routers should be relatively suspicious in 4 accepting routing data from other routing systems. 5 A router SHOULD provide the ability to rank routing information 6 sources from "most trustworthy" to "least trustworthy" and to 7 accept routing information about any particular destination 8 from the most trustworthy sources first. This was implicit in 9 the original core/stub autonomous system routing model using 10 EGP and various interior routing protocols. It is even more 11 important now with the demise of a central, "trusted" core. 12 A router SHOULD provide a mechanism to filter out "obviously 13 invalid" routes (such as those for net 127). 14 Routers MUST NOT by default redistribute routing data they do 15 not themselves use, trust or otherwise consider invalid. In 16 rare cases, it may be necessary to redistribute suspicious 17 information, but this should only happen under direct 18 intercession by some human agency. 19 In general, routers must be at least a little paranoid about 20 accepting routing data from anyone, and must be especially 21 careful when they distribute routing information provided to 22 them by another party. See below for specific guidelines. Internet Engineering Task Force [Page 122] DRAFT ROUTING PROTOCOLS October 1, 1991 23 Vendors SHOULD IMPLEMENT peer-to-peer authentication for those 24 routing protocols that support them. 25 EDITOR'S COMMENTS: 26 Some of the above may want to be moved elsewhere, and 27 needs to be checked for consistency with text being 28 added/changed for route leaking and route filtering. 7.2 INTERIOR GATEWAY PROTOCOLS 7.2.1 INTRODUCTION 1 An IGP is used to distribute routing information between the 2 various routers in a particular AS. Independent of the 3 algorithm used to implement a particular IGP, it should perform 4 the following functions: 5 (1) Respond quickly to changes in the internal topology of an 6 AS 7 (2) Provide a mechanism such that circuit flapping does not 8 cause continuous routing updates 9 (3) Provide loop-free routing 10 (4) Utilize minimal bandwidth 11 (5) Provide "equal cost" routes to enable "load-splitting" 12 (6) Provide a means for authentication of routing updates 13 EDITOR'S COMMENTS: 14 Some have suggested that the above should discuss services 15 that EGPs need from IGPs. I'm not sure if I agree. 16 Current IGPs used in the internet today are characterized as 17 either being being based on a distance-vector or a link-state 18 algorithm. 19 Several IGPs are detailed in this section, including those most 20 commonly used and some recently developed protocols which are 21 candidates for Internet standardization by the IAB. Numerous 22 other protocols intended for use in intra-AS routing exist in 23 the internet community. 24 A router which implements any routing protocol (other than | 25 static routes) MUST IMPLEMENT OSPF (see Section [7.2.2]) and | 26 MUST IMPLEMENT RIP (see Section [7.2.4]). A router may | Internet Engineering Task Force [Page 123] DRAFT ROUTING PROTOCOLS October 1, 1991 27 implement additional IGPs. | 7.2.2 OPEN SHORTEST PATH FIRST -- OSPF 1 SPF based routing protocols are a class of link-state 2 algorithms which are based on the shortest-path algorithm of 3 Dijkstra. Although SPF based algorithms have been around since 4 the inception of the ARPANet, it is only recently that they 5 have achieved popularity both inside the IP as well as the OSI 6 communities. In an SPF based system, each router obtains an 7 exact replica of the entire topology database via a process 8 known as flooding, which insures a reliable transfer of the 9 information. Each individual router then runs the SPF algorithm 10 on its database to build the IP routing table. The OSPF 11 routing protocol is an implementation of an SPF algorithm. The 12 current version, OSPF version 2, is specified in [ROUTE:1]. 13 Note that RFC-1131, which describes OSPF version 1, is 14 obsolete. 15 Note that to comply with Section [8.3] of this memo, a router 16 which implements OSPF must also implement the OSPF MIB 17 [NETMAN:14]. 7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM -- DUAL IS-IS 1 The American National Standards Institute (ANSI) X3S3.3 2 committee is currently defining an intra-domain routing 3 protocol for use with the OSI protocols. This protocol is 4 titled "Intermediate System to Intermediate System Intra-Domain 5 Routeing Exchange Protocol". 6 Its application to an IP network has been defined in [ROUTE:2], 7 and is referred to as Dual IS-IS (or sometimes as Integrated 8 IS-IS). IS-IS is based on a link-state (SPF) routing algorithm 9 and shares all the advantages for this class of protocols. 7.2.4 ROUTING INFORMATION PROTOCOL -- RIP 7.2.4.1 Introduction 1 The most widely used and implemented IGP is known as RIP, 2 and is based upon the Xerox PUP and XNS routing protocols. 3 It falls under the class of protocols which use a distance- 4 vector algorithm for calculating the IP routing table. The 5 current specification is contained in [ROUTE:3]. Although 6 RIP is still quite important in the Internet, it is being 7 replaced in sophisticated applications by more modern IGPs 8 such as the ones described above. Internet Engineering Task Force [Page 124] DRAFT ROUTING PROTOCOLS October 1, 1991 7.2.4.2 Protocol Walk-Through 1 Dealing with changes in topology: RFC-1058, pp. 11 2 An implementation of RIP MUST provide a means for timing 3 out routes. Since messages are occasionally lost, 4 implementations must not invalidate a route based on a 5 single missed update. 6 Implementations MUST by default wait six times the update 7 interval before invalidating a route. A router MAY have 8 configuration options to alter this value. An | 9 implementation MUST invalidate a route promptly (within a | 10 few seconds) once it becomes eligible to be invalidated. | 11 DISCUSSION: 12 It is important to routing stability that all 13 routers in a RIP autonomous system use similar 14 timeout value for invalidating routes, and therefore 15 it is important that an implementation default to 16 the timeout value specified in the RIP 17 specification. However, that timeout value is 18 overly conservative in environments where packet 19 loss is reasonably rare. In such an environment, a 20 network manager may wish to be able to decrease the 21 timeout period in order to promote faster recovery 22 from failures. 23 IMPLEMENTATION: | 24 There is a very simple mechanism which a router may | 25 use to meet the requirement to invalidate routes | 26 promptly after they time out. Whenever the router | 27 scans the routing table to see if any routes have | 28 timed out, it also notes the age of the least | 29 recently updated route which has not yet timed out. | 30 Subtracting this age from the timeout period gives | 31 the amount of time until the router again needs to | 32 scan the table for timed out routes. | 33 Split Horizon: RFC-1058, pp. 14-15 34 An implementation of RIP MUST implement "split horizon", 35 a scheme used for avoiding problems caused by including 36 routes in updates sent to the router from which they were 37 learned. 38 An implementation of RIP SHOULD implement "Split horizon 39 with poisoned reverse", a variant of split horizon which Internet Engineering Task Force [Page 125] DRAFT ROUTING PROTOCOLS October 1, 1991 40 includes routes learned from a router sent to that 41 router, but sets their metric to infinity. Because of 42 the routing overhead which may be incurred by 43 implementing split horizon with poisoned reverse, 44 implementations MAY include an option to select whether 45 poisoned reverse is in effect. Also, an implementation 46 SHOULD limit the period of time in which it sends reverse 47 routes at an infinite metric. 48 IMPLEMENTATION: 49 Each of the following algorithms can be used to 50 limit the period of time for which poisoned reverse 51 is applied to a route. The first algorithm is more 52 complex but does a more complete job of limiting 53 poisoned reverse to only those cases where it is 54 necessary. 55 The goal of both algorithms is to ensure that poison 56 reverse is done for any destination whose route has 57 changed in the last 180 seconds, unless it can be 58 sure that the previous route used the same output 59 interface. 180 seconds is used because that is the 60 amount of time RIP will keep around an old, bogus 61 route before declaring it stale. 62 The first algorithm is: 63 - Associated with each destination is a 64 counter, called the "ifcounter" below. 65 Poison reverse is done for any route whose 66 destination's ifcounter is greater than 67 zero. | 68 - after a regular (not triggered or in | 69 response to a request) update is sent, all | 70 of the non-zero ifcounters are decremented | 71 by one. | 72 - When a route to a destination is created, | 73 its ifcounter is set as follows: | 74 - if the new route is superseding a | 75 valid route, and the old route used a | 76 different (logical) output interface, | 77 then the ifcounter is set to 7. | 78 - if the new route is superseding a | 79 stale route, and the old route used a | Internet Engineering Task Force [Page 126] DRAFT ROUTING PROTOCOLS October 1, 1991 80 different (logical) output interface, | 81 then the ifcounter is set to MAX(0, 7 | 82 - INT(seconds that the route has been | 83 stale/30). | 84 - if there was no previous route to the | 85 destination, the ifcounter is set to | 86 3. 87 - otherwise, the ifcounter is set to 88 zero 89 - RIP also maintains a timer, called the 90 "resettimer" below. Poison reverse is 91 done on all routes whenever resettimer has 92 not expired (regardless of the ifcounter 93 values). 94 - When RIP is started, restarted, reset, or 95 otherwise has its routing table cleared, 96 it sets the resettimer to go off in 180 97 seconds. 98 In the above, the magic numbers are: 99 30 the number of seconds between RIP updates 100 180 if RIP doesn't hear any news about a 101 route for 180 seconds, it assumes that the 102 route has gone away | 103 7 (180/30)+1, or (more or less) the number | 104 of successive updates which have to be | 105 lost or fail to mention a route before RIP | 106 decides the route is gone. The "+1" is to | 107 account for the fact that the first time | 108 the ifcounter is decremented will be less | 109 than 30 seconds after it is initialized. | 110 3 7-4, where "7" is the "7" above and "4" is | 111 RIP's garbage collection timer/30 | 112 The second algorithm is identical to the first 113 except that: 114 - The rules which set the ifcounter to non- 115 zero values are changed to always set it 116 to 6 Internet Engineering Task Force [Page 127] DRAFT ROUTING PROTOCOLS October 1, 1991 117 - The resettimer is eliminated 118 CONTRIBUTOR'S COMMENTS: 119 The numbers above all assume the standard timeout 120 period of six 30-second update periods. Given that 121 we allow the timeout period to be adjusted, I need 122 to fix the text to reflect that. 123 Also, we allow the router to take as much as an 124 additional update period to get around to 125 invalidating a dead route. Thus, the algorithm 126 above really should assume that to be sure that a 127 stale route has been deleted one needs to wait one 128 more update period than the numbers above assume 129 (i.e. seven update periods = 210 seconds total using 130 the default timer values). 131 Triggered updates: RFC-1058, pp. 15-16; pp. 29 132 Triggered updates (also called "flash updates") are a 133 mechanism for immediately notifying a router's neighbors 134 when the router adds or deletes routes or changes their 135 metrics. A router MUST send a triggered update when 136 routes are deleted or their metrics are increased. A 137 router MAY send a triggered update when routes are added 138 or their metrics decreased. 139 Since triggered updates can cause excessive routing 140 overhead, implementations MUST use the following 141 mechanism to limit the frequency of triggered updates: 142 when a router sends a triggered update, it sets a timer 143 to a random time between one and five seconds in the 144 future. The router must not generate additional 145 triggered updates before the timer expires. During this 146 time, if the router would otherwise generate a triggered 147 update, it instead sets a flag indicating that a 148 triggered update is needed. When the timer expires, the 149 router checks to see whether the flag is set. If so, the 150 router sends a single triggered update which includes all 151 of the changes (and clears the flag and resets the 152 timer). The flag is also cleared whenever a regular 153 update is sent. 154 Triggered updates SHOULD include all routes that have 155 changed since the most recent regular (non-triggered) 156 update. Triggered updates MUST NOT include routes that 157 have not changed since the most recent regular update. Internet Engineering Task Force [Page 128] DRAFT ROUTING PROTOCOLS October 1, 1991 158 DISCUSSION: 159 Sending all routes, whether they have changed 160 recently or not, is unacceptable in triggered 161 updates because the tremendous size of many Internet 162 routing tables could otherwise result in 163 considerable bandwidth being wasted on triggered 164 updates. 165 Use of UDP: RFC-1058, pp. 18-19. 166 Any RIP protocol packet sent to an IP broadcast address 167 SHOULD have its initial TTL set to one. 168 Note that to comply with Section [6.1] of this memo, the | 169 router must use UDP checksums in RIP packets which it | 170 originates, must discard RIP packets received with | 171 invalid UDP checksums, but must not discard received RIP | 172 packets simply becuse they do not contain UDP checksums. | 173 Addressing Considerations: RFC-1058, pp. 22 174 A RIP implementation SHOULD support host routes. If it 175 does not, it MUST (as described on page 27 of [ROUTE:3]) 176 ignore (but MAY log) host routes in received updates. 177 The special address 0.0.0.0 is used to describe a default 178 route. A default route is used as the route of last 179 resort (i.e. when a route to the specific net does not 180 exist in the routing table). The router MUST be able to 181 create a RIP entry for the address 0.0.0.0. 182 Input Processing - Response: RFC-1058, pp. 26 183 When processing an update, the following validity checks 184 MUST be performed. The response MUST be from UDP port 185 520. The source address MUST be on a directly connected 186 subnet (or on a directly connected, non-subnetted 187 network) to be considered valid. Also, if an interface 188 on a broadcast network receives its own broadcasts, these 189 updates MUST NOT be used in route processing. 190 An implementation MUST NOT replace an existing route if 191 the metric received is equal to the existing metric 192 except in accordance with the following heuristic. 193 An implementation MAY choose to implement the following 194 heuristic to deal with the above situation. Normally, it 195 is useless to change the route to a network from one Internet Engineering Task Force [Page 129] DRAFT ROUTING PROTOCOLS October 1, 1991 196 router to another if both are advertised at the same 197 metric. However, the route being advertised by one of the 198 routers may be in the process of timing out. Instead of 199 waiting for the route to timeout (180 seconds), the new 200 route can be used after a specified amount of time has 201 elapsed. If this heuristic is implemented, it MUST wait 202 at least halfway to the expiration point before the new 203 route is installed. 7.2.4.3 Specific Issues 1 RIP Shutdown 2 An implementation of RIP SHOULD provide for a graceful 3 shutdown. This is accomplished by first terminating 4 input processing. Then four updates at random intervals 5 of between two and four seconds should be generated. 6 These updates contain all routes that were previously 7 announced, but with some metric changes. Routes that 8 were being announced at a metric of infinity should 9 continue to use this metric. Routes that had been 10 announced with a non-infinite metric should be announced 11 with a metric of 15 (infinity - 1). 12 DISCUSSION: 13 The metric used for the above really ought to be 16 14 (infinity); setting it to 15 is a kludge to avoid 15 breaking certain old hosts which wiretap the RIP 16 protocol. Such a host will (erroneously) abort a 17 TCP connection if it tries to send a datagram on the 18 connection while the host has no route to the 19 destination (even if the the period when the host 20 has no route lasts only a few seconds while RIP 21 chooses an alternate path to the destination). 22 RIP Split Horizon and Static Routes 23 Split horizon SHOULD be applied to static routes by 24 default. An implementation SHOULD provide a way to 25 specify, per static route, that split horizon should not 26 be applied to this route. 7.2.5 GATEWAY TO GATEWAY PROTOCOL -- GGP 1 The Gateway to Gateway protocol is considered obsolete and 2 should not be implemented. Internet Engineering Task Force [Page 130] DRAFT ROUTING PROTOCOLS October 1, 1991 7.3 EXTERIOR GATEWAY PROTOCOLS 7.3.1 INTRODUCTION 1 Exterior Gateway Protocols are utilized for inter-Autonomous 2 System routing to exchange reachability information for a set 3 of networks internal to a particular autonomous system to a 4 neighboring autonomous system. 5 The area of inter-AS routing is a current topic of research 6 inside the Internet Engineering Task Force. The Exterior 7 Gateway Protocol (EGP) described in Section [7.3.3] has 8 traditionally been the inter-AS protocol of choice. The Border 9 Gateway Protocol (BGP) eliminates many of the restrictions and 10 limitations of EGP, and is therefore growing rapidly in 11 popularity. A router is not required to implement any inter-AS 12 routing protocol. However, if a router does implement EGP it 13 also MUST IMPLEMENT BGP. 14 Although it was not designed as an exterior gateway protocol, 15 RIP (described in Section [7.2.4]) is sometimes used for 16 inter-AS routing. 7.3.2 BORDER GATEWAY PROTOCOL -- BGP 7.3.2.1 Introduction 1 The Border Gateway Protocol (BGP) is an inter-AS routing 2 protocol which exchanges network reachability information 3 with other BGP speakers. The information for a network 4 includes the complete list of ASs that traffic must transit 5 to reach that network. This information can then be used to 6 insure loop-free paths. 7 BGP is defined by the IAB as a Proposed Standard protocol, 8 and is defined by [ROUTE:4]. [ROUTE:5] specifies the proper 9 usage of BGP in the Internet, and provides some useful 10 implementation hints and guidelines. Note that to comply | 11 with Section [8.3] of this memo, a router which implements | 12 BGP must also implement the BGP MIB [NETMAN:15]. | 13 The primary function of a BGP speaking system is to exchange 14 network reachability information with other BGP systems. 15 This network reachability information includes the sequence 16 of Autonomous Systems (ASs) that traffic must transit to 17 reach these networks. This information is sufficient to 18 construct a graph of AS connectivity from which routing 19 loops may be pruned and some policy decisions at the AS Internet Engineering Task Force [Page 131] DRAFT ROUTING PROTOCOLS October 1, 1991 20 level may be enforced. 21 To characterize the set of policy decisions that can be 22 enforced using BGP, one must focus on the rule that an AS 23 advertizes to its neighbor ASs only those routes that it 24 itself uses. This rule reflects the "hop-by-hop" routing 25 paradigm generally used throughout the current Internet. 26 Note that some policies cannot be supported by the "hop-by- 27 hop" routing paradigm and thus require techniques such as 28 source routing to enforce. For example, BGP does not enable 29 one AS to send traffic to a neighbor AS intending that that 30 traffic take a different route from that taken by traffic 31 originating in the neighbor AS. On the other hand, BGP can 32 support any policy conforming to the "hop-by-hop" routing 33 paradigm. 34 Implementors of BGP are strongly encouraged to follow the 35 recommendations outlined in Section 6 of RFC-1164. 7.3.2.2 Protocol Walk-through 1 While BGP provides support for quite complex routing 2 policies (as an example see Section 4.2 in RFC-1164), it is 3 not required for all BGP implementors to support such 4 policies. At a minimum, however, a BGP implementation: | 5 (1) SHOULD allow an AS to control announcements of the BGP | 6 learned routes to adjacent AS's. Implementations SHOULD | 7 support such control with at least the granularity of a | 8 single network. Implementations SHOULD also support | 9 such control with the granularity of an autonomous | 10 system, where the autonomous system may be either the | 11 autonomous system that originated the route, or the | 12 autonomous system that advertised the route to the | 13 local system (adjacent autonomous system). | 14 (2) SHOULD allow an AS to prefer a particular path to a | 15 destination (when more than one path is available). | 16 Such function SHOULD be implemented by allowing system | 17 administrator to assign "weights" to Autonomous | 18 Systems, and making route selection process to select a | 19 route with the lowest "weight" (where "weight" of a | 20 route is defined as a sum of "weights" of all AS's in | 21 the AS_PATH path attribute associated with that route). | 22 (3) SHOULD allow an AS to ignore routes with certain AS's | 23 in the AS_PATH path attribute. Such function can be | 24 implemented by using technique outlined in (2), and by | Internet Engineering Task Force [Page 132] DRAFT ROUTING PROTOCOLS October 1, 1991 25 assigning "infinity" as "weights" for such AS's. The | 26 route selection process must ignore routes that have | 27 "weight" equal to "infinity". | 7.3.3 EXTERIOR GATEWAY PROTOCOL -- EGP 7.3.3.1 Introduction 1 The Exterior Gateway Protocol (EGP) specifies an EGP which 2 is used to exchange reachability information between routers 3 of the same or differing autonomous systems. EGP is not 4 considered a routing protocol since there is no standard 5 interpretation (i.e. metric) for the distance fields in the 6 EGP update message, so distances are comparable only among 7 routers of the same AS. It is however designed to provide 8 high-quality reachability information, both about neighbor 9 routers and about routes to non-neighbor routers. 10 EGP is defined by [ROUTE:7]. An implementor almost 11 certainly wants to read [ROUTE:8] and [ROUTE:9] as well, for 12 they contain useful explanations and background material. 13 DISCUSSION: 14 The present EGP specification, as defined in RFC-904 15 has serious limitations, most importantly a restriction 16 which limits routers to advertising only those networks 17 which are reachable from within the router's autonomous 18 system. This restriction against propagating "third 19 party" EGP information is to prevent long-lived routing 20 loops. This effectively limits EGP to a two-level 21 hierarchy. 22 RFC-975 is not a part of the EGP specification, and 23 should be ignored. 7.3.3.2 Protocol Walk-through 1 Indirect Neighbors: RFC-888, pp. 26 2 An implementation of EGP MUST include indirect neighbor 3 support. 4 Polling Intervals: RFC-904, pp. 10 5 The interval between Hello command retransmissions and 6 the interval between Poll retransmissions SHOULD be 7 configurable but there MUST be a minimum value defined. Internet Engineering Task Force [Page 133] DRAFT ROUTING PROTOCOLS October 1, 1991 8 The interval at which an implementation will respond to 9 Hello commands and Poll commands SHOULD be configurable 10 but there MUST be a minimum value defined. 11 Network Reachability: RFC-904, pp. 15 12 An implementation MUST default to not providing the 13 external list of routers in other autonomous systems; 14 only the internal list of routers together with the nets 15 which are reachable via those routers should be included 16 in an Update Response/Indication packet. However, an 17 implementation MAY elect to provide a configuration 18 option enabling the external list to be provided. An 19 implementation MUST NOT include in the external list 20 routers which were learned via the external list provided 21 by a router in another autonomous system. An 22 implementation MUST NOT send a network back to the 23 autonomous system from which it is learned, i.e. it MUST 24 do split-horizon on an autonomous system level. 25 If more than 255 internal or 255 external routers need to | 26 be specified in a Network Reachability update, the | 27 networks reachable from routers that can not be listed | 28 MUST be merged into the list for one of the listed | 29 routers. Which of the listed routers is chosen for this | 30 purpose SHOULD be user configurable, but SHOULD default | 31 to the source address of the EGP update being generated. | 32 An EGP update contains a series of blocks of network | 33 numbers, where each block contains a list of network | 34 numbers reachable at a particular distance via a | 35 particular router. If more than 255 networks are | 36 reachable at a particular distance via a particular | 37 router, they are split into multiple blocks (all of which | 38 have the same distance). Similarly, if more than 255 | 39 blocks are required to list the networks reachable via a | 40 particular router, the router's address is listed as many | 41 times as necessary to include all of the blocks in the | 42 update. | 43 EDITOR'S COMMENTS; | 44 The wording of the previous paragraph is terrible. | 45 Anybody want to try to improve it? | 46 Unsolicited Updates: RFC-904, pp. 16 47 If a network is shared with this peer, an implementation 48 MUST send an unsolicited update upon entry to the Up Internet Engineering Task Force [Page 134] DRAFT ROUTING PROTOCOLS October 1, 1991 49 state assuming that the source network is the shared 50 network. 51 Neighbor Reachability: RFC-904, pp. 6, 13-15 52 The table on page 6 which describes the values of j and k 53 (the neighbor up and down thresholds) is incorrect. It 54 is reproduced correctly here: 55 Name Active Passive Description 56 ----------------------------------------------- 57 j 3 1 neighbor-up threshold 58 k 1 0 neighbor-down threshold 59 The value for k in passive mode also specified 60 incorrectly in RFC-904, pp. 14 The values in parenthesis 61 should read: 62 (j = 1, k = 0, and T3/T1 = 4) 63 As an optimization, an implementation can refrain from | 64 sending a Hello command when a Poll is due. If an | 65 implementation does so, it SHOULD provide a user | 66 configurable option to disable this optimization. | 67 EDITOR'S COMMENTS: | 68 Is the above sentence in the right place in this | 69 document? Does it make sense? I was told to fix | 70 the wording, and I did, but without the EGP spec in | 71 front of me I'm not sure I understand what it's | 72 supposed to mean. | 73 Abort timer: RFC-904, pp. 6, 12, 13 74 An EGP implementation MUST include support for the abort 75 timer (as documented in section 4.1.4 of RFC-904). An 76 implementation SHOULD use the abort timer in the Idle 77 state to automatically issue a Start event to restart the 78 protocol machine. Recommended values are P4 for a 79 critical error (Administratively prohibited, Protocol 80 Violation and Parameter problem) and P5 for all others. 81 The abort timer SHOULD NOT be started when a Stop event 82 was manually initiated (such as via a network management 83 protocol). Internet Engineering Task Force [Page 135] DRAFT ROUTING PROTOCOLS October 1, 1991 84 Cease command received in Idle state: RFC-904, pp. 13 85 When the EGP state machine is in the Idle state, it MUST 86 reply to Cease commands with a Cease-ack response. 87 Hello Polling Mode: RFC-904, pp. 11 88 An EGP implementation MUST include support for both 89 active and passive polling modes. 90 Neighbor Acquisition Messages: RFC-904, pp. 18 91 As noted the Hello and Poll Intervals should only be 92 present in Request and Confirm messages. Therefore the 93 length of an EGP Neighbor Acquisition Message is 14 94 octets for a Request or Confirm message and 10 octets for 95 a Refuse, Cease or Cease-ack message. Implementations 96 MUST NOT send 14 octets for Refuse, Cease or Cease-ack 97 messages but MUST allow for implementations that send 14 98 octets for these messages. 99 Sequence Numbers: RFC-904, pp. 10 100 Response or indication packets received with a sequence 101 number not equal to S MUST be discarded. The send 102 sequence number S MUST be incremented just before the 103 time a Poll command is sent and at no other times. 7.3.4 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL 1 It is possible to exchange routing information between two 2 autonomous systems or routing domains without using a standard 3 exterior routing protocol between two separate, standard 4 interior routing protocols. The most common way of doing this 5 is to run both interior protocols independently in one of the 6 border routers with an exchange of route information between 7 the two processes. 8 As with the exchange of information from an EGP to an IGP, 9 without appropriate controls these exchanges of routing 10 information between two IGPs in a single router are subject to 11 creation of routing loops. 7.4 Multicast routing protocols | Internet Engineering Task Force [Page 136] DRAFT ROUTING PROTOCOLS October 1, 1991 7.4.1 Introduction | 1 Multicast routing protocols enable the forwarding of IP | 2 multicast datagrams throughout a TCP/IP internet. Generally | 3 these algorithms forward the datagram based on its source and | 4 destination addresses. Additionally, the datagram may need to | 5 be forwarded to several multicast group members, at times | 6 requiring the datagram to be replicated and sent out multiple | 7 interfaces. | 8 The state of multicast routing protocols is less developed than | 9 the protocols available for the forwarding of IP unicasts. Two | 10 multicasts rotuing protocols have been documented for TCP/IP; | 11 both are currently listed as experimental. Both also use the | 12 IGMP protocol to monitor multicast group membership. | 7.4.2 DVMRP (Distance Vector Multicast Routing Protocol) | 1 DVMRP, documented in [ROUTE:10], is based on Distance Vector or | 2 Bellman-Ford technology. It routes multicast datagrams only, | 3 and does so within a single Autonomous System. DVMRP is an | 4 implementation of the Truncated Reverse Path Broadcasting | 5 algorithm described in . In addition, it specifies the | 6 tunneling of IP multicasts through non-multicast-routing- | 7 capable IP domains. | 7.4.3 MOSPF (Multicast extensions to OSPF) | 1 MOSPF, documented in , is a backward-compatible addition to | 2 OSPF that allows the forwarding of both IP multicasts and | 3 unicasts within an Autonomous System. MOSPF routers can be | 4 mixed with OSPF routers within a routing domain, and they will | 5 interoperate in the forwarding of unicasts. OSPF is a link- | 6 state or SPF-based protocol. By adding link state | 7 advertisements that pinpoint group membership, MOSPF routers | 8 can calculate the path of a multicast datagram as a tree rooted | 9 at the datagram source. Those branches that do not contain | 10 group members can then be discarded, eliminating unnecessary | 11 datagram forwarding hops. | 7.5 STATIC ROUTING 1 Static routing provides a means of explicitly defining the next 2 hop from a router for a particular destination. A router SHOULD 3 provide a means for defining a static route to a destination, 4 where the destination is defined by an address and an address 5 mask. The mechanism SHOULD also allow for a metric to be 6 specified for each static route. Internet Engineering Task Force [Page 137] DRAFT ROUTING PROTOCOLS October 1, 1991 7 A router which supports a dynamic routing protocol MUST allow 8 static routes to be defined with any metric valid for the routing 9 protocol used. The router MUST provide the ability for the user 10 to specify a list of static routes which may or may not be 11 propagated via the routing protocol. In addition, a router SHOULD 12 support the following additional information if it supports a 13 routing protocol that could make use of the information. They are: 14 TOS, subnet mask, or a metric specific to a given routing protocol 15 that can import the route. 16 DISCUSSION: 17 It was intended that one needed to support only the things 18 useful to the given routing protocol. the need for TOS should 19 not require the vendor to implement the other parts if they 20 are not used. 21 Whether a router prefers a static route over a dynamic route (or 22 vice versa) or whether the associated metrics are used to choose 23 between conflicting static and dynamic routes SHOULD be 24 configurable for each static route. 25 EDITOR'S COMMENTS: 26 Tony Li has pointed out that, to be consistent with 27 "Ruminations on the Next Hop", static routes probably have 28 preference values rather than metrics (since metrics can only 29 be compared with metrics of other routes in the same routing 30 domain, the metric of a static route could only be compared 31 with metrics of other static routes). This is contrary to 32 some current implementations, where static routes really do 33 have metrics, and those metrics are used to determine whether 34 a particular dynamic route overrides the static route to the 35 same destination. 36 In Atlanta the group agreed that static routes can have | 37 metrics (in addition to preference values) but that the | 38 metrics are defined for specific routing domains, e.g.: | 39 route 36.0.0.0 255.0.0.0 via 192.19.200.3 rip metric 3 | 40 route 36.21.0.0 255.255.0.0 via 192.19.200.4 ospf | 41 inter-area metric 27 | 42 route 36.22.0.0 255.255.0.0 via 192.19.200.5 egp 123 | 43 metric 99 | 44 route 36.23.0.0 255.255.0.0 via 192.19.200.6 igrp 47 | 45 metric 1 2 3 4 5 | Internet Engineering Task Force [Page 138] DRAFT ROUTING PROTOCOLS October 1, 1991 46 I need to incorporate this into the mainline text, along with | 47 a note that either a static route needs to be allowed to have | 48 multiple metrics or else that a router needs to support | 49 multiple static routes which are identical except that their | 50 metrics are in different routing domains. | 51 I have also realized (and need to state) that this solution | 52 essentially makes the static route into a RIP route, or an | 53 OSPF route (or whatever, depending on the domain of the | 54 metric). Thus, the route lookup algorithm of that domain | 55 applies. However, this is NOT route leaking, in that | 56 coercing a static route into a dynamic routing domain does | 57 not authorize the router to redistribute the route into the | 58 dynamic routing domain. | 59 For static routes not put into a specific routing domain, the | 60 route lookup algorithm needs to be specified: | 61 1) Basic match | 62 2) Longest match | 63 3) Weak TOS (if TOS supported) | 64 4) Best metric (where metric are implementation-defined) | 65 I'm not sure that the last step is necessary, but it's useful | 66 in the case where you want to have a primary static route | 67 over one interface and a secondary static route over an | 68 alternate interface, with failover to the alternate path if | 69 the interface for the primary route fails. | 7.6 FILTERING OF ROUTING INFORMATION 1 EDITOR'S COMMENTS: 2 This section needs to be reworded to note that these 3 filtering requirements apply only to non-SPF-based protocols 4 (and therefore not at all to routers which don't implement 5 any distance vector protocols). 6 Also, the preference value of 255 used in [FORWARD:6] is an | 7 alternative mechanism to the ones described in this section, | 8 and so a router which implements the preference 255 stuff | 9 doesn't need to do what this section says. This section | 10 needs to say that once there is a section (containing text | 11 about the preference value stuff) in chapter 5 for me to | 12 reference here. | Internet Engineering Task Force [Page 139] DRAFT ROUTING PROTOCOLS October 1, 1991 13 Each router within a network makes forwarding decisions based upon 14 information contained within its forwarding database. In a simple 15 network the contents of the database may be statically configured. 16 As the network grows more complex, the need for dynamic updating 17 of the forwarding database becomes critical to the efficient 18 operation of the network. 19 If the data flow through a network is to be as efficient as 20 possible, it is necessary to provide a mechanism for controlling 21 the propagation of the information a router uses to build its 22 forwarding database. This control takes the form of choosing 23 which sources of routing information should be trusted and 24 selecting which pieces of the information to believe. The 25 resulting forwarding database is a filtered version of the 26 available routing information. 27 In addition to efficiency, controlling the propagation of routing 28 information can reduce instability by preventing the spread of 29 incorrect or bad routing information. 30 In some cases local policy may require that complete routing 31 information not be widely propagated. 7.6.1 Route Validation 1 A router SHOULD log as an error any routing update advertising 2 a route to network zero, subnet zero, or subnet -1, unless the 3 routing protocol from which the update was received uses those 4 values to encode special routes (such as default routes). 7.6.2 Basic Route Filtering 1 Filtering of routing information allows control of paths used 2 by a router to forward packets it receives. A router should be 3 selective in which sources of routing information it listens to 4 and what routes it believes. Therefore, a router MUST provide 5 the ability to specify: 6 o which logical interfaces routing information will be 7 accepted from and which routes will be accepted from each 8 logical interface. 9 o whether all routes or only a default route is advertised 10 on a logical interface. 11 Some routing protocols do not recognize logical interfaces as a 12 source of routing information. In such cases the router MUST 13 provide the ability to specify Internet Engineering Task Force [Page 140] DRAFT ROUTING PROTOCOLS October 1, 1991 14 o from which other routers routing information will be 15 accepted. 16 For example, assume a router connecting one or more leaf 17 networks to the main portion or backbone of a larger network. 18 Since each of the leaf networks has only one path in and out, 19 the router can simply send a default route to them. It 20 advertises the leaf networks to the main network. 7.6.3 Advanced Route Filtering 1 As the topology of a network grows more complex, the need for 2 more complex route filtering arises. Therefore, a router 3 SHOULD provide the ability to specify independently for each 4 routing protocol: 5 o which logical interfaces or routers routing information 6 (routes) will be accepted from and which routes will be 7 believed from each host or logical interface. 8 o which routes will be sent via which logical interface(s). 9 o which routers routing information will be sent to, if this 10 is supported by the routing protocol in use. 11 In many situations it is desirable to assign a reliability 12 ordering to routing information received from another router 13 instead of the simple believe or don't believe choice listed in 14 the first bullet above. A router MAY provide the ability to 15 specify: 16 o a reliability or preference to be assigned to each route 17 received from a host. A route with higher reliability 18 will be chosen over one with lower reliability regardless 19 of the routing metric associated with each route. 20 If a router supports assignment of preferences, the router MUST 21 NOT propagate any routes it does not prefer as first party 22 information. If the routing protocol being used to propagate 23 the routes does not support distinguishing between first and 24 third party information, the router MUST NOT propagate any 25 routes it does not prefer. 26 EDITOR'S COMMENTS: 27 Need to define "first party" and "third party", both for 28 this section and Section [7.7]. 29 For example, assume a router receives a route to network C from Internet Engineering Task Force [Page 141] DRAFT ROUTING PROTOCOLS October 1, 1991 30 router R and a route to the same network from router S. If 31 router R is considered more reliable than router S traffic 32 destined for network C will be forwarded to router R regardless 33 of the route received from router S. 34 Routing information for routes which the router does not use 35 (router S in the above example) MUST NOT be passed to any other 36 router. 7.7 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE 1 EDITOR'S COMMENTS: 2 I intend to replace virtually all of this section with text 3 consistent with the recommendations in [ROUTE:11]. 4 Routers MUST be able to exchange routing information between 5 separate IP interior routing protocols, if independent IP 6 processes can run in the same router. Routers MUST provide some 7 mechanism for avoiding routing loops when routers are configured 8 for bi-directional exchange of routing information between two 9 separate interior routing processes. Routers MUST provide some 10 priority mechanism for choosing routes from among independent 11 routing processes. Routers SHOULD provide administrative control 12 of IGP-IGP exchange when used across administrative boundaries. 13 CONTRIBUTOR'S COMMENTS: 14 needs to be consistent with Sections in 7.3 15 Routers SHOULD provide some mechanism for translating or 16 transforming metrics on a per network basis. Routers (or routing 17 protocols) MAY allow for global preference of exterior routes 18 imported into an IGP. 19 DISCUSSION: 20 Different IGPs use different metrics, requiring some 21 translation technique when introducing information from one 22 protocol into another protocol with a different form of 23 metric. Some IGPs can run multiple instances within the same 24 router or set of routers. In this case metric information 25 can be preserved exactly or translated. 26 CONTRIBUTOR'S COMMENTS: 27 This problem of EGP-to-IGP metric translation should be 28 addressed in the other EGP sections too. 29 There are at least two techniques for translation between 30 different routing processes. The static (or reachability) 31 approach uses the existence of a route advertisement in one Internet Engineering Task Force [Page 142] DRAFT ROUTING PROTOCOLS October 1, 1991 32 IGP to generate a route advertisement in the other IGP with a 33 given metric. The translation or tabular approach uses the 34 metric in one IGP to create a metric in the other IGP through 35 use of either a function (such as adding a constant) or a 36 table lookup. 37 Bi-directional exchange of routing information is dangerous 38 without control mechanisms to limit feedback. This is the 39 same problem that distance vector routing protocols must 40 address with the split horizon technique and that EGP 41 addresses with the third-party rule. Routing loops can be 42 avoided explicitly through use of tables or lists of 43 permitted/denied routes or implicitly through use of a split 44 horizon rule, a no-third-party rule, or a route tagging 45 mechanism. Vendors are encouraged to use implicit techniques 46 where possible to make administration easier for network 47 operators. 7.8 REQUIREMENTS SUMMARY 1 TBD Internet Engineering Task Force [Page 143] DRAFT NETWORK MANAGEMENT PROTOCOLS October 1, 1991 8. APPLICATION LAYER -- NETWORK MANAGEMENT PROTOCOLS 1 EDITOR'S COMMENTS: 2 This chapter could perhaps also cover CMIP/CMOT if there is 3 interest. 4 SOURCE: 5 Chapter 8 source: new text 6 Relationship to RFC-1009: none (RFC-1009 predates SNMP) 7 Relationship to HRRFC: none 8.1 The Simple Network Management Protocol -- SNMP 8.1.1 SNMP Protocol Elements 1 Routers MUST be manageable by SNMP [NETMAN:5]. The SNMP MUST | 2 operate using UDP/IP as its transport and network protocols. | 3 SNMP management operations MUST operate as if the SNMP was | 4 implemented on the router itself. Specifically, management | 5 operations MUST be effected by sending SNMP management requests | 6 to any of the IP addresses assigned to any of the router's | 7 interfaces. The actual management operation may be performed | 8 either by the router or by a proxy for the router. | 9 DISCUSSION: | 10 This wording is intended to allow management either by | 11 proxy, where the proxy device responds to SNMP packets | 12 which have one of the router's IP addresses in the packets | 13 destination address field, or the SNMP is implemented | 14 directly in the router itself and receives packets and | 15 responds to them in the proper manner. | 16 All SNMP functions MUST be implemented. 17 Routers MAY support the algorithms for asynchronous alert 18 management described in [NETMAN:7]. 19 DISCUSSION: 20 Although there is general agreement about the need to 21 rate-limit traps, there is not yet consensus on how this 22 is best achieved. The reference cited above is still 23 considered experimental. Internet Engineering Task Force [Page 144] DRAFT NETWORK MANAGEMENT PROTOCOLS October 1, 1991 8.2 Community Table 1 For the purposes of this specification, we assume that there is an 2 abstract `community table' in the router. This table contains 3 several entries, each entry for a specific community and 4 containing the parameters necessary to completely define the 5 attributes of that community. The actual implementation method of 6 the abstract community table is, of course, implementation 7 specific. 8 A router's community table MUST allow for at least one entry and 9 SHOULD allow for at least two entries. 10 DISCUSSION: 11 A community table with zero capacity is useless. It means 12 that the router will not recognize any communities and, 13 therefore, all SNMP operations will be rejected. 14 Routers MUST allow the user to examine, add, delete and change 15 entries in the SNMP community table. The user MUST be able to set 16 the community name. The user MUST be able to configure | 17 communities as read-only (i.e., they do not allow SETs) or read- | 18 write (i.e., they do allow SETs). | 19 The user MUST be able to define the IP address to which traps are 20 sent. This address MUST be definable on a per-community basis. 21 Traps MUST be enablable/disablable on a per-community basis. 22 A router SHOULD provide the ability to specify a list of valid 23 network managers for any particular community. If enabled, a 24 router MUST validate the source address of the SNMP datagram 25 against the list and MUST discard the datagram if its address does 26 not appear. If the datagram is discarded the router MUST take all 27 actions appropriate to an SNMP authentication failure. 28 DISCUSSION: 29 This is a rather limited authentication system, but coupled 30 with various forms of packet filtering may provide some small 31 measure of increased security. 32 The community table MUST be saved in non-volatile storage. 33 AUTHOR'S COMMENTS: 34 The wording for this section should be consistent with the 35 wording in section 10 where that section discusses saving 36 config information. The community table must also be added 37 to the list of config data in Appendix A. Internet Engineering Task Force [Page 145] DRAFT NETWORK MANAGEMENT PROTOCOLS October 1, 1991 38 The initial state of the community table SHOULD contain one entry, | 39 with the community name string "public" and read-only access. The 40 default state of this entry MUST NOT send traps. If it is 41 implemented, then this entry MUST remain in the community table 42 until the administrator changes it or deletes it. 43 DISCUSSION: 44 By default, traps are not sent to this community. Trap PDUs 45 are sent to unicast IP addresses. This address must be 46 configured into the router in some manner. Before the 47 configuration occurs, there is no such address, so to whom 48 should the trap be sent? Therefore trap sending to the 49 "public" community defaults to be disabled. This can, of 50 course, be changed by an administrative operation once the 51 router is operational. 8.3 Standard MIBS 1 All standard MIBS relevant to a router's configuration MUST be 2 implemented. To wit: 3 o The System, Interface, IP, ICMP, and UDP groups of MIB-II 4 [NETMAN:4] MUST be implemented. 5 o The Interface Extensions MIB [NETMAN:19] MUST be implemented. 6 o If the router implements TCP (e.g. for Telnet) then the TCP 7 group of MIB-II [NETMAN:4] must be implemented. 8 o If the router implements EGP then the EGP group of MIB-II 9 [NETMAN:4] must be implemented. 10 o If the router has Ethernet, 802.3, or StarLan interfaces then 11 the Ethernet-Like MIB [NETMAN:8] MUST be implemented. 12 o If the router has 802.4 interfaces then the 802.4 MIB 13 [NETMAN:9] MUST be implemented. 14 o If the router has 802.5 interfaces then the 802.5 MIB 15 [NETMAN:10] MUST be implemented. 16 o If the router has FDDI interfaces then the FDDI MIB 17 [NETMAN:11] MUST be implemented. 18 o If the router has RS-232 interfaces then the RS-232 19 [NETMAN:12] MIB MUST be implemented. 20 o If the router has T1/DS1 interfaces then the T1/DS1 MIB Internet Engineering Task Force [Page 146] DRAFT NETWORK MANAGEMENT PROTOCOLS October 1, 1991 21 [NETMAN:17] MUST be implemented. 22 o If the router has T3/DS3 interfaces then the T3/DS3 MIB 23 [NETMAN:18] MUST be implemented. 24 o If the router has SMDS interfaces then the SMDS Interface 25 Protocol MIB [NETMAN:20] MUST be implemented. 26 o If the router supports PPP over any of its interfaces then 27 the PPP MIB [NETMAN:13] MUST be implemented. 28 o If the router supports OSPF then the OSPF MIB [NETMAN:14] 29 MUST be implemented. 30 o If the router supports BGP then the BGP MIB [NETMAN:15] MUST 31 be implemented. 8.4 Vendor Specific MIBS 1 The Internet Standard and Experimental MIBs do not cover the 2 entire range of statistical, state, configuration and control 3 information that may be available in a network element. This 4 information is, never the less, extremely useful. Vendors of 5 routers (and other network devices) generally have developed MIB 6 extensions that cover this information. These MIB extensions are 7 called Vendor Specific MIBs. 8 The Vendor Specific MIB for the router MUST provide access to all 9 statistical, state, configuration, and control information that is 10 not available through the Standard and Experimental MIBs that have 11 been implemented. 12 DISCUSSION: 13 The intent of this requirement is to provide the ability to 14 do anything on the router via SNMP that can be done via a 15 console. A certain minimal amount of configuration is 16 necessary before SNMP can operate (e.g., the router must have 17 an IP address). This initial configuration can not be done 18 via SNMP. However, once the initial configuration is done, 19 full capabilities ought to be available via network 20 management. 21 The vendor SHOULD make available the specifications for all Vendor 22 Specific MIB variables. These specifications MUST conform to the 23 SMI [NETMAN:3] and the descriptions MUST be in the form specified 24 in [NETMAN:6] -- "Concise MIB Definition". 25 DISCUSSION: Internet Engineering Task Force [Page 147] DRAFT NETWORK MANAGEMENT PROTOCOLS October 1, 1991 26 Making the Vendor Specific MIB available to the user is 27 necessary. Without this information the users would not be 28 able to configure their network management systems to be able 29 to access the Vendor Specific parameters. These parameters 30 would then be useless. 31 The format of the MIB specification is also specified. 32 Parsers which read MIB specifications and generate the needed 33 tables for the network management station are available. 34 These parsers generally understand only the standard MIB 35 specification format. 8.5 Saving Changes 1 Parameters altered by SNMP MAY be saved to non-volatile storage. 2 DISCUSSION: 3 Reasons why this "requirement" is a MAY: 4 o The exact physical nature of non-volatile storage is not 5 specified in this document. Hence, parameters may be 6 saved in NVRAM/EEPROM, local floppy or hard disk, or in 7 some TFTP file server or BOOTP server, etc. Suppose that 8 that this information is in a file that is retrieved via 9 TFTP. In that case, a change made to a configuration 10 parameter on the router would need to be propagated back 11 to the file server holding the configuration file. 12 Alternatively, the SNMP operation would need to be 13 directed to the file server, and then the change somehow 14 propagated to the router. The answer to this problem 15 does not seem obvious. 16 This also places more requirements on the host holding 17 the configuration information than just having an 18 available tftp server, so much more that its probably 19 unsafe for a vendor to assume that any potential 20 customer will have a suitable host available. 21 o The timing of committing changed parameters to non- 22 volatile storage is still an issue for debate. Some 23 prefer to commit all changes immediately. Others prefer 24 to commit changes to non-volatile storage only upon an 25 explicit command. 8.6 REQUIREMENTS SUMMARY Internet Engineering Task Force [Page 148] DRAFT MISCELLANEOUS APPLICATION PROTOCOLS October 1, 1991 9. APPLICATION LAYER -- MISCELLANEOUS PROTOCOLS 1 A router MUST be compliant and SHOULD be unconditionally compliant | 2 with the requirements of [INTRO:3], except that: | 3 Section 6.2 of that memo need not be followed (routers instead | 4 comply with the requirements of Chapter [10] of the memo). | 5 Section 6.3 of that memo need not be followed (routers instead | 6 comply with the requirements of Chapter [8] of the memo). | 7 EDITOR'S COMMENTS: | 8 Should all routers be required to implement a resolver? Do the | 9 above requirements imply that you should be able to use a host | 10 name anywhere you can use an IP address when configuring the | 11 router? How about in ping and traceroute? | 9.1 Bootstrap Protocol (BOOTP) 1 SOURCE: 2 Section 9.1 source: new text (+ bits of RFC-951 and RFC-1054) 3 Relationship to HRRFC: believed consistent with RFC-1123 4 section 6.2.2 9.1.1 Introduction 1 The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol which 2 allows a booting host to configure itself dynamically and 3 without user supervision. BOOTP provides a means to notify a 4 host of its assigned IP address, the IP address of a boot 5 server host, and the name of a file to be loaded into memory 6 and executed ([APPL:1]). Other configuration information such 7 as the local subnet mask, the local time offset, the addresses 8 of default routers, and the addresses of various Internet 9 servers can also be communicated to a host using BOOTP 10 ([APPL:2]). 9.1.2 BOOTP Relay Agents 1 In many cases, BOOTP clients and their associated BOOTP 2 server(s) do not reside on the same IP network or subnet. In 3 such cases, a third-party agent is required to transfer BOOTP 4 messages between clients and servers. Such an agent was 5 originally referred to as a "BOOTP forwarding agent." However, 6 in order to avoid confusion with the IP forwarding function of 7 a router, the name "BOOTP relay agent" has been adopted 8 instead. Internet Engineering Task Force [Page 149] DRAFT MISCELLANEOUS APPLICATION PROTOCOLS October 1, 1991 9 DISCUSSION: 10 A BOOTP relay agent performs a task which is distinct from 11 a router's normal IP forwarding function. While a router 12 normally switches IP datagrams between networks more-or- 13 less transparently, a BOOTP relay agent may more properly 14 be thought to receive BOOTP messages as a final 15 destination and then generate new BOOTP messages as a 16 result. One should resist the notion of simply forwarding 17 a BOOTP message "straight through like a regular packet." 18 This relay-agent functionality is most conveniently located in 19 the routers which interconnect the clients and servers 20 (although it may alternatively be located in a host which is 21 directly connected to the client subnet). 22 A router MAY provide BOOTP relay-agent capability. If it does, 23 it MUST conform to the specifications in [APPL:3]. 24 Section [5.2.3] discussed the circumstances under which a 25 packet is delivered locally (to the router). All locally 26 delivered UDP messages whose UDP destination port number is 27 BOOTPS (67) are considered for special processing by the 28 router's logical BOOTP relay agent. 29 Sections [4.2.2.10] and [5.3.7] discussed invalid IP source | 30 addresses. According to these rules, a router must silently | 31 discard any received datagram whose IP source address is | 32 0.0.0.0. However, routers which support a BOOTP relay agent 33 MUST accept for local delivery to the relay agent BOOTREQUEST 34 messages whose IP source address is 0.0.0.0. 9.2 REQUIREMENTS SUMMARY 1 TBD Internet Engineering Task Force [Page 150] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 10. OPERATIONS AND MAINTENANCE 1 Facilities to support operation and maintenance (O&M) activities form 2 an essential part of any router implementation. Although these 3 functions do not seem to relate directly to interoperability, they 4 are essential to the network manager who must make the router 5 interoperate and track down problems when it doesn't. This chapter 6 also includes some discussion of router initialization and some 7 discussion of facilities to assist the network manager in securing 8 and accounting for the network. 10.1 Introduction 1 The following kinds of activity are included under router O&M: 2 o Diagnosing hardware problems in the router processor, in its 3 network interfaces, or in the connected networks, modems, or 4 communication lines. 5 o Installing new hardware 6 o Installing a new version of the router software. 7 o Restarting or rebooting a router after a crash. 8 o Configuring (or reconfiguring) the router. 9 o Detecting and diagnosing Internet problems such as 10 congestion, routing loops, bad IP addresses, black holes, 11 packet avalanches, and misbehaved hosts. 12 o Changing network topology, either temporarily (e.g., to 13 diagnose a communication line problem) or permanently. 14 o Monitoring the status and performance of the routers and the 15 connected networks. 16 o Collecting traffic statistics for use in (Inter-)network 17 planning. 18 o Coordinating the above activities with appropriate vendors 19 and telecommunications specialists. 20 Routers, packet-switches, and their connected communication lines 21 are often operated as a system by a centralized O&M organization. 22 This organization may maintain a (Inter-)network operation center, 23 or NOC, to carry out its O&M functions. It is essential that 24 routers support remote control and monitoring from such a NOC, Internet Engineering Task Force [Page 151] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 25 through an Internet path (since routers might not be connected to 26 the same network as their NOC). Since a network failure may 27 temporarily preclude network access, many NOCs insist that routers 28 be accessible for network management via an alternative means, 29 often dialup modems attached to console ports on the routers. 30 Since an IP packet traversing the Internet will often use routers 31 under the control of more than one NOC, Internet problem diagnosis 32 will often involve cooperation of personnel of more than one NOC. 33 In some cases, the same router may need to be monitored by more 34 than one NOC, but only if necessary, because excessive monitoring 35 could impact a router's performance. 36 The tools available for monitoring at a NOC may cover a wide range 37 of sophistication. Current implementations include multi-window, 38 dynamic displays of the entire router system. The use of AI 39 techniques for automatic problem diagnosis is proposed for the 40 future. 41 Router O&M facilities discussed here are only a part of the large 42 and difficult problem of Internet management. These problems 43 encompass not only multiple management organizations, but also 44 multiple protocol layers. For example, at the current stage of 45 evolution of the Internet architecture, there is a strong coupling 46 between host TCP implementations and eventual IP-level congestion 47 in the router system [OPER:1]. Therefore, diagnosis of congestion 48 problems will sometimes require the monitoring of TCP statistics 49 in hosts. There are currently a number of R&D efforts in progress 50 in the area of Internet management and more specifically router 51 O&M. These R&D efforts have already produced standards for router 52 O&M. This is also an area in which vendor creativity can make a 53 significant contribution. 10.2 Router Initialization 10.2.1 Minimum Router Configuration 1 SOURCE: 2 Section 10.2.1 source: new text 3 Relationship to HRRFC: none 4 There exists a minimum set of conditions that must be satisfied 5 before a router may forward packets. These conditions are: 6 (1) the router must know at least one of its IP addresses, 7 along with the subnet mask of that address. | Internet Engineering Task Force [Page 152] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 8 (2) IP forwarding must be enabled on at least one of the | 9 router's logical interfaces. 10 Every time a router boots, it MUST confirm that both of these 11 conditions ("sanity checks") are met. If these conditions are 12 not met, the router MUST NOT forward IP packets. Furthermore, 13 these configuration items MUST NOT have defaults. 14 DISCUSSION: 15 There have been instances in which routers have been 16 shipped with vendor-installed default addresses for 17 interfaces. In a few cases, this has resulted in routers 18 advertising these default addresses into active networks. 10.2.2 Address and Address Mask Initialization | 1 A router MUST support the first, and MAY implement both, of the | 2 following methods for determining its IP addresses and their | 3 corresponding subnet masks: | 4 (1) static configuration information; | 5 (2) obtaining the information dynamically as a side effect of | 6 the system initialization process (see Section 10.2.3]); 7 The choice of method to be used in a particular router MUST be 8 configurable. 9 As was described in Section [4.2.2.10], IP addresses are not 10 permitted to have the value 0 or -1 for any of the 11 , , or fields. 12 Therefore, a router SHOULD NOT allow an IP address or subnet 13 mask to be set to a value which would make any of the the three 14 fields above have the value zero or -1. 15 DISCUSSION: 16 It is possible using variable length subnet masks to 17 create situations in which routing is ambiguous (i.e., two 18 routes with different but equally-specific subnet masks 19 match a particular destination address). We suspect that 20 a router could, when setting a subnet mask, check whether 21 the mask would cause routing to be ambiguous, and that 22 implementors might be able to decrease their customer 23 support costs by having routers prohibit or log such 24 erroneous configurations. However, at this time we do not 25 require routers to make such checks because we know of no 26 published method for accurately making this check. Internet Engineering Task Force [Page 153] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 27 EDITOR'S COMMENTS: | 28 The above comment might be OBE if we can get our act | 29 together to discourage non-contiguous subnet masks. | 30 Ideally this would reference Robert Elz's variable length | 31 subnets draft, but I suspect it won't be done in time. | 32 A router SHOULD make some reasonableness check on any subnet 33 mask it installs; see IMPLEMENTATION section below. 34 IMPLEMENTATION: 35 The following reasonableness check on an subnet mask is 36 suggested: the mask is not all 1 bits, and all bits which 37 correspond to the network number part of the address are 38 set. 39 EDITOR'S COMMENTS: 40 In Boulder, it was suggested that the test in the 41 implementation hint is wrong (for some cases of point-to- 42 point links?). If so, RFC-1122 is also broken. 10.2.3 Network Booting using BOOTP and TFTP 1 There has been a lot of discussion on how routers can and 2 should be booted from the network. In general, these 3 discussions have centered around BOOTP and TFTP. Currently, 4 there are routers that boot with TFTP from the network. There 5 is no reason that BOOTP could not be used for locating the 6 server that the boot image should be loaded from. 7 In general, BOOTP is a protocol used to boot end systems, and 8 requires some stretching to accommodate its use with routers. 9 If a router is using BOOTP to locate the current boot host, it 10 should send a BOOTP Request with its hardware address for its 11 first interface, or, if it has been previously configured 12 otherwise, with either another interface's hardware address, or 13 another number to put in the hardware address field of the 14 BOOTP packet. This is to allow routers without hardware 15 addresses (like sync line only routers) to use BOOTP for 16 bootload discovery. TFTP can then be used to retrieve the 17 image found in the BOOTP Reply. If there are no configured 18 interfaces or numbers to use, a router MAY cycle through the 19 interface hardware addresses it has until a match is found by 20 the BOOTP server. 21 A router SHOULD IMPLEMENT the ability to store parameters | 22 learned via BOOTP into local stable storage. A router MAY | 23 implement the ability to store a system image loaded over the | Internet Engineering Task Force [Page 154] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 24 network into local stable storage. | 25 A router MAY have a facility to allow a remote user to request 26 that the router get a new boot image. Differentiation should 27 be made between getting the new boot image from one of three 28 locations: the one included in the request, from the last boot 29 image server, and using BOOTP to locate a server. 30 DISCUSSION: 31 Someone needs to come up with a remote configuration 32 protocol for routers. A remote booting protocol is not 33 necessary at this point, but may want to be considered in 34 light of the configuration protocol. This protocol should 35 not require the operator to configure a router to install 36 it, but should allow for new routers to be installed, and 37 for autoconfiguring them. 10.3 Operation and Maintenance 1 SOURCE: 2 Section 10.3 source: heavily modified RFC1009 10.3.1 Router O&M Models 1 There is a range of possible models for performing O&M 2 functions on a router. At one extreme is the local-only model, 3 under which the O&M functions can only be executed locally, 4 e.g., from a terminal plugged into the router machine. At the 5 other extreme, the fully-remote model allows only an absolute 6 minimum of functions to be performed locally (e.g., forcing a 7 boot), with most O&M being done remotely from the NOC. There 8 intermediate models, e.g., one in which NOC personnel can log 9 into the router as a host, using the Telnet protocol, to 10 perform functions which can also be invoked locally. The 11 local-only model may be adequate in a few router installations, 12 but in general remote operation from a NOC will be required, 13 and therefore remote O&M provisions are required for most 14 routers. 15 Remote O&M functions may be exercised through a control agent 16 (program). In the direct approach, the router would support 17 remote O&M functions directly from the NOC using standard 18 Internet protocols (e.g., UDP or TCP); in the indirect 19 approach, the control agent would support these protocols and 20 control the router itself using proprietary protocols. The 21 direct approach is preferred, although either approach is 22 acceptable. The use of specialized host hardware and/or 23 software requiring significant additional investment is Internet Engineering Task Force [Page 155] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 24 discouraged; nevertheless, some vendors may elect to provide 25 the control agent as an integrated part of the network in which 26 the routers are a part. If this is the case, it is required 27 that a means be available to operate the control agent from a 28 remote site using Internet protocols and paths and with 29 equivalent functionality with respect to a local agent 30 terminal. 31 It is desirable that a control agent and any other NOC software 32 tools which a vendor provides operate as user programs in a 33 standard operating system. The use of the standard Internet 34 protocols UDP and TCP for communicating with the routers should 35 facilitate this. 36 EDITOR'S COMMENTS: | 37 SNMP may make the previous 1.5 paragraphs OBE? | 38 Remote router monitoring and (especially) remote router control 39 present important access control problems which must be 40 addressed. Care must also be taken to ensure control of the 41 use of router resources for these functions. It is not 42 desirable to let router monitoring take more than some limited 43 fraction of the router CPU time, for example. On the other 44 hand, O&M functions must receive priority so they can be 45 exercised when the router is congested, i.e., when O&M is most 46 needed. 47 Routers MUST support out of band access. This out of band 48 access will allow the NOC a way to access isolated routers 49 during times when network access is not available. Out of band 50 access should provide the same functionality as in band access, 51 but may be implemented in a different way. 52 DISCUSSION: 53 Out of band access is an important management tool for the 54 network administrator. It allows the access of equipment 55 independent of the network connections. There are many 56 ways to achieve this access. Which ever one is used it is 57 important that the access is independent of the network 58 connections. An example of out of band access would be a 59 serial port connected to a modem that provides dial up 60 access to the router. It is important that the out of band 61 access provides the same functionality as in band access, 62 at times when in band access is unavailable. In band 63 access, or accessing equipment through the existing 64 network connection, is limiting, because most of the time, 65 administrators need to reach equipment to figure out why 66 it is unreachable. In band access is still very important Internet Engineering Task Force [Page 156] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 67 for configuring a router, and for troubleshooting more 68 subtle problems. 69 Limiting query access to a router might be a way of ensuring 70 the control of router resources for necessary functions. There 71 are several current Internet standards for control and 72 monitoring protocols. The one that is most widely used is 73 Simple Network Management Protocol, or SNMP. See Chapter 8 of 74 this document for further details. 10.3.2 Router O&M Functions 1 The following O&M functions need to be performed in a router: 2 A. Maintenance -- Hardware Diagnosis 3 Each router SHOULD operate as a stand-alone device for the 4 purposes of local hardware maintenance. Means SHOULD be 5 available to run diagnostic programs at the router site 6 using only on-site tools. A router SHOULD be able to run 7 diagnostics in case of a fault. For suggested hardware 8 and software diagnostics see Section [10.3.3]. 9 B. Control -- Dumping and Rebooting 10 A router MUST include both in-band and out-of-band | 11 mechanisms to allow the network manager to reload, stop, | 12 and restart the router. A router SHOULD also contain a | 13 mechanism (such as a watchdog timer) which will reboot the | 14 router automatically if it "hangs" due to a software or | 15 hardware fault. | 16 A router SHOULD IMPLEMENT a mechanism for dumping the | 17 contents of a router's memory (and/or other state useful | 18 for vendor debugging after a crash), and either saving | 19 them on a stable storage device local to the router or | 20 saving them on another host via an up-line dump mechanism. | 21 TFTP (see [OPER:2], as updated by [INTRO:3]) may be an | 22 appropriate protocol for an up-line dump function. 23 C. Control -- Configuring the Router 24 Every router has configuration parameters which may need 25 to be set (see Appendix A). It SHOULD be possible to 26 update the parameters without rebooting the router; at 27 worst, a restart MAY be required. There may be cases when 28 it is not possible to change parameters without rebooting 29 the router (for instance, changing the IP address of an Internet Engineering Task Force [Page 157] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 30 interface). In these cases, care should be taken to 31 minimize disruption to the router and the surrounding 32 network. 33 There SHOULD be a way to configure the router over the 34 network either manually or automatically. A router SHOULD 35 be able to upload or download its parameters from a host 36 or another router, and these parameters SHOULD be 37 convertible into some sort of text format for making 38 changes and then back to the form the router can read. A 39 router SHOULD have some sort of stable storage for its 40 configuration. A router SHOULD NOT believe protocols such 41 as RARP, ICMP Address Mask Reply, and MAY not believe 42 BOOTP, which try to tell the router about what its 43 configuration is. 44 DISCUSSION: 45 It is necessary to note here that in the future RARP, 46 ICMP Address Mask Reply, BOOTP and other mechanisms 47 may be needed to allow a router to auto-configure. 48 Although routers may in the future be able to 49 configure automatically, the intent here is to 50 discourage this practice in a production environment 51 until such time as auto-configuration has been tested 52 more thoroughly. The intent is NOT to discourage 53 auto-configuration all together. In cases where a 54 router is expected to get its configuration 55 automatically it may be wise to allow the router to 56 believe these things as it comes up and then ignore 57 them after it has gotten its configuration. 58 Netbooting of System Software 59 A router SHOULD keep its system image local non- 60 volatile storage such as PROM, NVRAM, or disk. It MAY 61 also be able to load its system software over the 62 network from a host or another router. It is important 63 that the router be able to come up and run on its own. 64 In a large network NVRAM may be the solution because it 65 is time consuming to change the PROMs in a large 66 network of routers. It is important to be able to 67 netboot the system image because there should be an 68 easy way for a router to get a bug fix or new feature 69 more quickly than getting PROMS installed. Also if the 70 router has NVRAM instead of PROMs, it will netboot the 71 image and then put it in NVRAM. 72 If the router has a non-volatile way to save its system Internet Engineering Task Force [Page 158] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 73 image, and the ability to netboot its image, then the 74 router SHOULD be able to default to the version if the 75 netbootable image is not available. 76 A router MAY also be able to distinguish between 77 different configurations based on which software it is 78 running. If configuration commands change from one 79 software version to another, it would be helpful if the 80 router could use the configuration that was compatible 81 with the software. 82 Detecting and responding to misconfiguration 83 There MUST be mechanisms for detecting and responding 84 to misconfigurations. If a command is executed 85 incorrectly, the router SHOULD give an error message. 86 The router SHOULD NOT accept a poorly formed command as 87 if it were correct. There are cases where it is not 88 possible to detect errors: the command is correctly 89 formed, but incorrect with respect to the network. 90 This may be detected by the router, but may not be 91 possible. 92 Another form of misconfiguration is misconfiguration of 93 the network to which the router is attached. A router 94 MAY detect misconfigurations in the network. Examples 95 of such misconfigurations might be a router with the 96 same address as the one in question or a router with 97 the wrong subnet mask. If a router detects such 98 problems it is probably not the best idea for the 99 router to try to fix the situation. That could cause 100 more harm than good. The router MAY log these findings 101 to a file, either on the router or a host, so that the 102 network manager will see that there are possible 103 problems on the network. 104 Minimizing network disruption when changing parameters 105 Changing the configuration of a router SHOULD have 106 minimal affect on the network. Routing tables SHOULD 107 NOT be unnecessarily flushed when a simple change is 108 made to the router. If a router is running several 109 routing protocols, stopping one routing protocol SHOULD 110 NOT disrupt other routing protocols, except in the case 111 where one network is learned by more than one routing 112 protocol. 113 DISCUSSION: Internet Engineering Task Force [Page 159] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 114 It is the goal of a network manager to run a 115 network so that users of the network get the best 116 connectivity possible. Reloading a router for 117 simple configuration changes can cause disruptions 118 in routing and ultimately cause disruptions to the 119 network and its users. If routing tables are 120 unnecessarily flushed, for instance, the default 121 route will be lost as well as specific routes to 122 sites within the network. This sort of disruption 123 will cause significant downtime for the users. It 124 is the purpose of this section to point out that 125 whenever possible, these disruptions should be 126 avoided. 127 D. Control -- Troubleshooting Problems 128 To aid in troubleshooting of network problems a router: 129 (1) MUST provide in-band network access, but for security | 130 considerations this access SHOULD be disabled by | 131 default. 132 (2) MUST provide the ability to initiate an ICMP echo. 133 The following options SHOULD be implemented: 134 o choice of data patterns 135 o choice of packet size 136 o record route 137 and the following additional options MAY be 138 implemented: 139 o loose source route 140 o strict source route 141 o timestamps 142 (3) SHOULD provide the ability to initiate a traceroute. 143 If traceroute is provided, then the 3rd party 144 traceroute SHOULD be implemented. 145 Each of the above three facilities (if implemented) SHOULD 146 have access restrictions placed on it to prevent its abuse 147 by unauthorized persons. Internet Engineering Task Force [Page 160] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 148 EDITOR'S COMMENTS: 149 Should define "traceroute" and "third party 150 traceroute" 151 E. Monitoring -- Status and Performance 152 A mechanism must be provided for retrieving status and 153 statistical information from a router. A router must 154 supply such information in response to a polling message 155 from the NOC. In addition, it may be desirable to 156 configure a router to transmit status spontaneously and 157 periodically to a NOC (or set of NOCs), for recording and 158 display. The router SHOULD timestamp all such updates 159 before they leave the router. This allows the network 160 manager to determine exactly when problems occurred. This | 161 mechanism for retrieving status and statistical | 162 information is required to be SNMP (see Chapter 8), and | 163 SNMP could be supplemented with some other vendor specific | 164 mechinism. The current SNMP MIB could be expanded to | 165 include other interesting variables. Some examples are | 166 below. | 167 Examples of interesting status information include: link 168 status, queue lengths, buffer availability, CPU and memory 169 utilization, the routing data-base, error counts, and 170 packet counts, for each protocol. Counts should be kept 171 for dropped packets, separated by reason. Counts of ICMP 172 datagrams should be kept by type and categorized into 173 those originating at the router, and those destined for 174 the router. It would be useful to maintain many of these 175 statistics by network interface, by source/destination 176 network pair, and/or by source/destination host pair. 177 Note that a great deal of useful monitoring data is often 178 to be found in the routing data-base. It is therefore 179 useful to be able to tap into this data-base from the NOC. 180 EDITOR'S COMMENTS: 181 It has been suggested that the above 3 paragraphs are | 182 perhaps obsolete in the face of SNMP. Opinions? | 183 Frank Solensky's notes from Atlanta indicate that we | 184 agreed to delete them, but neither my notes nor Cathy | 185 Wittbrodt's notes concur. | 186 F. Monitoring -- Error Logging 187 EDITOR'S COMMENTS: | 188 Should we specify the trap mechanism. Syslog? SNMP? | Internet Engineering Task Force [Page 161] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 189 If this means SNMP, the MUST requiring limiting the | 190 frequency with which traps are generated is | 191 inconsistent with the weaker requirement (MAY) in | 192 Section [8.1.1]. | 193 A router SHOULD be capable of asynchronously sending | 194 exception ("trap") reports to one or more specified | 195 Internet addresses, one of which will presumably be the | 196 NOC host. The router SHOULD timestamp these traps. 197 There MUST also be a mechanism to limit the frequency of | 198 such trap reports, and the parameters controlling this | 199 frequency must be settable in the router configuration. 200 See [NETMAN:7]. 201 Examples of conditions which should result in traps 202 include: packets discarded because of TTL expiration (an 203 indicator of possible routing loops); resource shortages; 204 or an interface changing its up/down status. See also | 205 Section [1.3.3]. 10.3.3 Router Hardware and Software Diagnostics 1 Below are a list of suggested hardware and software debug 2 (diagnostic) options. It is certainly not an exhaustive list. 3 o The ability to look at routing updates in and out of a 4 router for a specific protocol 5 o The ability to look at errors as the occur on interfaces 6 o The ability to reload the router over the network, or via 7 dial up (out of band service) 8 o Resettable error counters 9 o The ability of a router to ping its own interface and have 10 that ping actually traverse the link between routers on a 11 serial link (as if the modem on the far end was in 12 loopback). 13 Internal error logging and internal debugging: 14 o MUST NOT take precedence over normal router functions and 15 direct commands from the console 16 o MUST be easily toggled on and off without reloading the 17 router Internet Engineering Task Force [Page 162] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 18 DISCUSSION: 19 Sometimes debug output is required on routers which are 20 carrying traffic on a production network. In these 21 situations it is desireable that the debug impact the 22 traffic as little as possible. When debug is turned on, 23 there should be a way to limit it so that the network 24 connectivity is not compromised. There also needs to be a 25 way to interrupt the debug output so that it can be shut 26 off without action as drastic as a reload. There are 27 reasons to want all of the debug regardless of the impact 28 on the network, but the choice should be up to the 29 network administrator. 10.4 Security Considerations 10.4.1 Auditing and Audit Trails 1 Auditing and billing are the bane of the network operator, but 2 are the two features most requested by those in charge of 3 network security and those who are responsible for paying the 4 bills. In the context of security, auditing is desirable if it 5 helps you keep your network working and protects your resources 6 from abuse, without costing you more than those resources are 7 worth. 8 A. Configuration Changes 9 Vendors should provide a method for auditing a 10 configuration change of a router, even if its something as 11 simple as recording the operators initials and time of 12 change: 13 DISCUSSION: 14 Having the ability to track who made changes and when 15 is highly desirable, especially if your packets 16 suddenly start getting routed through Alaska on their 17 way across town. 18 B. Packet Accounting 19 Vendors should strongly consider providing a system for 20 tracking traffic levels between pairs of hosts or 21 networks. A mechanism for limiting the collection of this 22 information to specific pairs of hosts or networks is also 23 strongly encouraged. 24 DISCUSSION: 25 A "host traffic matrix" as described above can give Internet Engineering Task Force [Page 163] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 26 the network operator a glimpse of traffic trends not 27 apparent from other statistics. It can also identify 28 hosts or networks which are "probing" the structure 29 of the attached networks - e.g. a single external 30 host which tries to send packets to every IP address 31 in the network address range for a connected network. 32 C. Security Auditing 33 Vendors MUST provide a method of auditing security related 34 failures or violations such as invalid password or 35 attempts to bypass access controls. This can be as simple 36 as listing the violations on the console, or logging them 37 to a remote security server via the SNMP trap mechanism or 38 the Unix logging mechanism. 10.4.2 Configuration Control 1 A vendor has a responsibility to use good configuration control 2 practices in the creation of the software/firmware loads for 3 their routers. In particular, if a vendor makes updates and 4 loads available for retrieval over the Internet, the vendor 5 should also provide a way for the customer to confirm the load 6 is a valid one, perhaps by the verification of a checksum over 7 the load. 8 DISCUSSION: 9 Many vendors currently provide short notice updates of 10 their software products via the Internet. This a good 11 trend and should be encouraged, but provides a point of 12 vulnerability in the configuration control process. 13 If a vendor provides the ability for the customer to change the 14 configuration parameters of a router remotely, for example via 15 a Telnet session, the ability to do so SHOULD be configurable 16 and SHOULD default to off. The router SHOULD require a 17 password or other valid authentication before permitting remote 18 reconfiguration. 19 DISCUSSION: 20 Allowing your properly identified network operator to 21 twiddle with your routers is necessary; allowing anyone 22 else to do so is foolhardy. 10.5 REQUIREMENTS SUMMARY 1 TBD Internet Engineering Task Force [Page 164] DRAFT OPERATIONS AND MAINTENANCE October 1, 1991 11. REFERENCES 1 Implementors should be aware that Internet protocol standards are 2 occasionally updated. These references are current as of this 3 writing, but a cautious implementor will always check a recent 4 version of the RFC index to ensure that an RFC has not been updated 5 or superseded by another, more recent RFC. Reference [INTRO:6] 6 explains various ways to obtain a current RFC index. 7 APPL:1. 8 B. Croft and J. Gilmore, Bootstrap Protocol (BOOTP), Request For 9 Comments (RFC) 951, DDN Network Information Center, SRI 10 International, Menlo Park, California, USA, September 1985. 11 APPL:2. 12 J. Reynolds, BOOTP Vendor Information Extensions, Request For 13 Comments (RFC) 1084, DDN Network Information Center, SRI 14 International, Menlo Park, California, USA, December 1988. 15 APPL:3. 16 W. Wimer, Clarifications and Extensions for the Bootstrap 17 Protocol, Work In Progress. To be published as an RFC; 18 currently a unpublished draft. 19 ARCH:1. 20 DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 (three 21 volumes), DDN Network Information Center, SRI International, 22 Menlo Park, California, USA, December 1985. 23 ARCH:2. 24 V. Cerf and R. Kahn, "A Protocol for Packet Network 25 Intercommunication," IEEE Transactions on Communication, May 26 1974. Also included in [ARCH:1]. 27 ARCH:3. 28 J. Postel, C. Sunshine, and D. Cohen, "The ARPA Internet 29 Protocol," Computer Networks, vol. 5, no. 4, July 1981. Also 30 included in [ARCH:1]. 31 ARCH:4. 32 B. Leiner, J. Postel, R. Cole, and D. Mills, "The DARPA Internet 33 Protocol Suite," Proceedings INFOCOM 85, IEEE, Washington, DC, 34 March 1985. Also in: IEEE Communications Magazine, March 1985. 35 Also available from the Information Sciences Institute, 36 University of Southern California as Technical Report ISI-RS- 37 85-153. Internet Engineering Task Force [Page 165] DRAFT REFERENCES October 1, 1991 38 ARCH:5. 39 D. Comer, Internetworking With TCP/IP Volume 1: Principles, 40 Protocols, and Architecture, Prentice Hall, Englewood Cliffs, 41 NJ, 1991. 42 ARCH:6. 43 W. Stallings, Handbook of Computer-Communications Standards 44 Volume 3: The TCP/IP Protocol Suite, Macmillan, New York, NY, 45 1990. 46 ARCH:7. 47 J.K. Reynolds and J.B. Postel, Official Internet Protocols, 48 Request For Comments (RFC) 1011, DDN Network Information Center, 49 SRI International, Menlo Park, California, USA, May 1987. 50 ARCH:8. 51 Information processing systems -- Open Systems Interconnection 52 -- Basic Reference Model, ISO 7489, International Standards 53 Organization, 1984. 54 FORWARD:1. 55 IETF CIP Working Group (C. Topolcic, Editor), Experimental 56 Internet Stream Protocol, Version 2 (ST-II), Request For 57 Comments (RFC) 1190, DDN Network Information Center, SRI 58 International, Menlo Park, California, USA, October 1990. 59 FORWARD:2. 60 A. Mankin and K. Ramakrishnan, Editors, Gateway Congestion 61 Control Survey, Request For Comments (RFC) 1254, DDN Network 62 Information Center, SRI International, Menlo Park, California, 63 USA, August 1991. 64 FORWARD:3. 65 J. Nagle, "On Packet Switches with Infinite Storage," IEEE 66 Transactions on Communications, vol. COM-35, no. 4, April 1987. 67 FORWARD:4. 68 R. Jain, K. Ramakrishnan, and D. Chiu, Congestion Avoidance in 69 Computer Networks With a Connectionless Network Layer, Technical 70 Report DEC-TR-506, Digital Equipment Corporation. 71 FORWARD:5. 72 V. Jacobson, "Congestion Avoidance and Control," Proceeding of 73 SIGCOMM '88, Association for Computing Machinery. 74 FORWARD:6. 75 P. Almquist, Ruminations on the Next Hop, July 1991. To be 76 published as an RFC; currently an INTERNET-DRAFT. Internet Engineering Task Force [Page 166] DRAFT REFERENCES October 1, 1991 77 INTERNET:1. 78 J. Postel, Internet Protocol, Request For Comments (RFC) 791, 79 DDN Network Information Center, SRI International, Menlo Park, 80 California, USA, September 1981. 81 INTERNET:2. 82 J. Mogul and J. Postel, Internet Standard Subnetting Procedure, 83 Request For Comments (RFC) 950, DDN Network Information Center, 84 SRI International, Menlo Park, California, USA, August 1985. 85 INTERNET:3. 86 J. Mogul, Broadcasting Internet Datagrams in the Presence of 87 Subnets, Request For Comments (RFC) 922, DDN Network Information 88 Center, SRI International, Menlo Park, California, USA, October 89 1984. 90 INTERNET:4. 91 S. Deering, Host Extensions for IP Multicasting, Request For 92 Comments (RFC) 1112, DDN Network Information Center, SRI 93 International, Menlo Park, California, USA, August 1989. 94 INTERNET:5. 95 ???, ??? (IP security option), Request For Comments (RFC) 1108?, 96 DDN Network Information Center, SRI International, Menlo Park, 97 California, USA, to be issued at a future date. In the 98 meantime, implementors who wish to sell to US Government 99 agencies which require support for the security option should 100 contact those agencies for appropriate specifications. 101 INTERNET:6. 102 R. Braden, D. Borman, and C. Partridge, Computing the Internet 103 Checksum, Request For Comments (RFC) 1071, DDN Network 104 Information Center, SRI International, Menlo Park, California, 105 USA, September 1988. 106 INTERNET:7. 107 T. Mallory and A. Kullberg, Incremental Updating of the Internet 108 Checksum, Request For Comments (RFC) 1141, DDN Network 109 Information Center, SRI International, Menlo Park, California, 110 USA, January 1990. 111 INTERNET:8. 112 J. Postel, Internet Control Message Protocol, Request For 113 Comments (RFC) 792, DDN Network Information Center, SRI 114 International, Menlo Park, California, USA, September 1981. 115 INTERNET:9. 116 A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R. Internet Engineering Task Force [Page 167] DRAFT REFERENCES October 1, 1991 117 Wilder, and R. Zahavi, Evaluation of Internet Performance -- 118 FY89, Technical Report MTR-89W00216, MITRE Corporation, 119 February, 1990. 120 INTERNET:10. 121 G. Finn, "A Connectionless Congestion Control Algorithm," 122 Computer Communications Review, vol. 19, no. 5, Association for 123 Computing Machinery, October 1989. 124 INTERNET:11. 125 W. Prue, The Source Quench Introduced Delay (SQuID), Request For 126 Comments (RFC) 1016, DDN Network Information Center, SRI 127 International, J. Postel, August 1987. 128 INTERNET:12. 129 A. McKenzie, Some comments on SQuID, Request For Comments (RFC) 130 1018, DDN Network Information Center, SRI International, Menlo 131 Park, California, USA, August 1987. 132 INTERNET:13. 133 S. Deering, ICMP Router Discovery Messages, July 1991. To be 134 published as an RFC; currently an INTERNET-DRAFT. 135 INTERNET:14. 136 J. Mogul and S. Deering, Path MTU Discovery, Request For 137 Comments (RFC) 1191, DDN Network Information Center, SRI 138 International, Menlo Park, California, USA, November 1990. 139 INTRO:1. 140 R. Braden and J. Postel, Requirements for Internet Gateways, 141 Request For Comments (RFC) 1009, DDN Network Information Center, 142 SRI International, Menlo Park, California, USA, June 1987. 143 INTRO:2. 144 Internet Engineering Task Force (R. Braden, Editor), 145 Requirements for Internet Hosts -- Communication Layers, Request 146 For Comments (RFC) 1122, DDN Network Information Center, SRI 147 International, Menlo Park, California, USA, October 1989. 148 INTRO:3. 149 Internet Engineering Task Force (R. Braden, Editor), 150 Requirements for Internet Hosts -- Application and Support, 151 Request For Comments (RFC) 1123, DDN Network Information Center, 152 SRI International, Menlo Park, California, USA, October 1989. 153 INTRO:4. 154 D. Clark, Modularity and Efficiency in Protocol Implementations, 155 Request For Comments (RFC) 817, DDN Network Information Center, Internet Engineering Task Force [Page 168] DRAFT REFERENCES October 1, 1991 156 SRI International, Menlo Park, California, USA, July 1982. 157 INTRO:5. 158 D. Clark, "The Structuring of Systems Using Upcalls," 159 Proceedings of 10th ACM SOSP, December 1985. 160 INTRO:6. 161 O. Jacobsen and J. Postel, Protocol Document Order Information, 162 Request For Comments (RFC) 980, DDN Network Information Center, 163 SRI International, Menlo Park, California, USA, March 1986. If 164 you are unable to locate a copy of this document, contact the 165 publisher at the above address, or by electronic mail to 166 nic@nic.ddn.mil, or by phone at 800-235-3155 or 415-859-3695. 167 INTRO:7. 168 J. Reynolds and J. Postel, Assigned Numbers, Request For 169 Comments (RFC) 1060, DDN Network Information Center, SRI 170 International, Menlo Park, California, USA, March 1990. This 171 document is periodically updated and reissued with a new number. 172 It is wise to verify occasionally that the version you have is 173 still current. 174 INTRO:8. 175 DoD Trusted Computer System Evaluation Criteria, DoD publication 176 5200.28-STD, U.S. Department of Defense, December 1985. 177 LINK:1. 178 S. Leffler and M. Karels, Trailer Encapsulations, Request For 179 Comments (RFC) 893, DDN Network Information Center, SRI 180 International, Menlo Park, California, USA, April 1984. 181 LINK:2. 182 D. Perkins, Point-to-Point Protocol for the transmission of 183 multi-protocol datagrams over Point-to-Point links, Request For 184 Comments (RFC) 1171, DDN Network Information Center, SRI 185 International, Menlo Park, California, USA, July 1990. 186 LINK:3. 187 D. Perkins and R. Hobby, Point-to-Point Protocol (PPP) initial 188 configuration options, Request For Comments (RFC) 1172, DDN 189 Network Information Center, SRI International, Menlo Park, 190 California, USA, July 1990. 191 NETMAN:3. 192 M. Rose and K. McCloghrie, Structure and Identification of 193 Management Information of TCP/IP-based Internets, Request For 194 Comments (RFC) 1155, DDN Network Information Center, SRI 195 International, Menlo Park, California, USA, May 1990. Internet Engineering Task Force [Page 169] DRAFT REFERENCES October 1, 1991 196 NETMAN:4. 197 M. Rose (Editor), Management Information Base of TCP/IP-Based 198 Internets, Request For Comments (RFC) 1158, DDN Network 199 Information Center, SRI International, Menlo Park, California, 200 USA, May 1990. 201 NETMAN:5. 202 J. Case, M. Fedor, M. Schofstall, and J. Davin, Simple Network 203 Management Protocol, Request For Comments (RFC) 1157, DDN 204 Network Information Center, SRI International, Menlo Park, 205 California, USA, May 1990. 206 NETMAN:6. 207 M. Rose and K. McCloghrie (Editors), Towards Concise MIB 208 Definitions, Request For Comments (RFC) 1212, DDN Network 209 Information Center, SRI International, Menlo Park, California, 210 USA, March 1991. 211 NETMAN:7. 212 L. Steinberg, Techniques for Managing Asynchronously Generated 213 Alerts, March 1990. To be published as an RFC; currently an 214 INTERNET-DRAFT. 215 NETMAN:8. 216 J. Cook, Definitions of Managed Objects for the Ethernet-like 217 Interface Types, Work In Progress. To be published as an RFC; 218 currently an INTERNET-DRAFT. 219 NETMAN:9. 220 K. McCloghrie and R. Fox, IEEE 802.4 Token Bus MIB, Work In 221 Progress. To be published as an RFC; currently an INTERNET- 222 DRAFT. 223 NETMAN:10. 224 K. McCloghrie, R. Fox, and E. Decker, IEEE 802.5 Token Ring MIB, 225 Work In Progress. To be published as an RFC; currently an 226 INTERNET-DRAFT. 227 NETMAN:11. 228 J. Case (Editor), Definitions of Managed Objects for FDDI, Work 229 In Progress. To be published as an RFC; currently an INTERNET- 230 DRAFT. 231 NETMAN:12. 232 R. Stewart, Definitions of Managed Objects for RS-232-like 233 Hardware Devices, Work In Progress. To be published as an RFC; 234 currently an INTERNET-DRAFT. Internet Engineering Task Force [Page 170] DRAFT REFERENCES October 1, 1991 235 NETMAN:13. 236 F. Kastenholz, Experimental Definitions of Managed Objects for 237 the Point-to-Point Protocol, Work In Progress. To be published 238 as an RFC; currently an INTERNET-DRAFT. 239 NETMAN:14. 240 F. Baker and R. Coltun, OSPF Version 2 Management Information 241 Base, Request For Comments (RFC) 1248, DDN Network Information 242 Center, SRI International, Menlo Park, California, USA, August 243 1991. 244 NETMAN:15. 245 S. Willis and J. Burruss, Experimental Definitions of Managed 246 Objects for the Border Gateway Protocol (Version 2), Work In 247 Progress. To be published as an RFC; currently an INTERNET- 248 DRAFT. 249 NETMAN:17. 250 F. Baker and C. Kolb, Definitions of Managed Objects for the DS1 251 Interface Type, Work In Progress. To be published as an RFC; 252 currently an INTERNET-DRAFT. 253 NETMAN:18. 254 T. Cox and K. Tesink, Definitions of Managed Objects for the DS3 255 Interface Type, Work In Progress. To be published as an RFC; 256 currently an INTERNET-DRAFT. 257 NETMAN:19. 258 K. McCloghrie, Extensions to the Generic-Interface MIB, Work In 259 Progress. To be published as an RFC; currently an INTERNET- 260 DRAFT. 261 NETMAN:20. 262 K. Tesink (Editor), Definitions of Managed Objects for the SIP 263 Interface Type, Work In Progress. To be published as an RFC; 264 currently an INTERNET-DRAFT. 265 OPER:1. 266 J. Nagle, Congestion Control in IP/TCP Internetworks, Request 267 For Comments (RFC) 896, DDN Network Information Center, SRI 268 International, Menlo Park, California, USA, January 1984. 269 OPER:2. 270 K.R. Sollins, TFTP Protocol (revision 2), Request For Comments 271 (RFC) 783, DDN Network Information Center, SRI International, 272 Menlo Park, California, USA, June 1981. 273 ROUTE:1. Internet Engineering Task Force [Page 171] DRAFT REFERENCES October 1, 1991 274 J. Moy, OSPF Version 2, Request For Comments (RFC) 1247, DDN 275 Network Information Center, SRI International, Menlo Park, 276 California, USA, July 1991. 277 ROUTE:2. 278 R. Callon, Use of OSI IS-IS for Routing in TCP/IP and Dual 279 Environments, Request For Comments (RFC) 1195, DDN Network 280 Information Center, SRI International, Menlo Park, California, 281 USA, December 1990. 282 ROUTE:3. 283 C. L. Hedrick, Routing Information Protocol, Request For 284 Comments (RFC) 1058, DDN Network Information Center, SRI 285 International, Menlo Park, California, USA, June 1988. 286 ROUTE:4. 287 K. Lougheed and Y. Rekhter, Border Gateway Protocol (BGP), 288 Request For Comments (RFC) 1163, DDN Network Information Center, 289 SRI International, Menlo Park, California, USA, June 1990. 290 ROUTE:5. 291 J. C. Honig, D. Katz, M. Mathis, Y. Rekhter, and J. Yu, 292 Application of the Border Gateway Protocol in the Internet, 293 Request For Comments (RFC) 1164, DDN Network Information Center, 294 SRI International, Menlo Park, California, USA, June 1990. 295 ROUTE:7. 296 D. Mills, Exterior Gateway Protocol Formal Specification, 297 Request For Comments (RFC) 904, DDN Network Information Center, 298 SRI International, Menlo Park, California, USA, April 1984. 299 ROUTE:8. 300 E. Rosen, Exterior Gateway Protocol (EGP), Request For Comments 301 (RFC) 827, DDN Network Information Center, SRI International, 302 Menlo Park, California, USA, October 1982. 303 ROUTE:9. 304 L. Seamonson and E. Rosen, "STUB" Exterior Gateway Protocol, 305 Request For Comments (RFC) 888, DDN Network Information Center, 306 SRI International, Menlo Park, California, USA, January 1984. 307 ROUTE:10. 308 D. Waitzman, C. Partridge, and S. Deering, Distance Vector 309 Multicast Routing Protocol, Request For Comments (RFC) 1075, DDN 310 Network Information Center, SRI International, Menlo Park, 311 California, USA, November 1988. 312 ROUTE:11. Internet Engineering Task Force [Page 172] DRAFT REFERENCES October 1, 1991 313 P. Almquist, Ruminations on Route Leaking, July 1991. To be 314 published as an RFC; currently an INTERNET-DRAFT. 315 ROUTE:12. 316 P. Almquist, Type of Service in the Internet Protocol, July 317 1991. To be published as an RFC; currently an INTERNET-DRAFT. 318 TRANS:1. 319 J. Postel, User Datagram Protocol, Request For Comments (RFC) 320 768, DDN Network Information Center, SRI International, Menlo 321 Park, California, USA, August 1980. 322 TRANS:2. 323 J. Postel, Transmission Control Protocol, Request For Comments 324 (RFC) 793, DDN Network Information Center, SRI International, 325 Menlo Park, California, USA, September 1981. Internet Engineering Task Force [Page 173] DRAFT CONFIGURATION PARAMETERS October 1, 1991 APPENDIX A. CONFIGURATION PARAMETERS 1 SOURCE: 2 Appendix A source: RFC-1009 3 This section summarizes the configuration parameters required or 4 recommented by this memo. 5 EDITOR'S COMMENTS: 6 This is still based on RFC-1009; it needs to be aligned with the 7 requirements of this document and of the documents incorporated 8 by reference. 9 I have some doubts about the value of this appendix. If time 10 crunch seems to warrant, I'll be tempted to punt this appendix 11 rather than actually doing the necessary work to make it correct 12 (unless I get feedback that this is important, ideally from 13 somebody who's willing to do the work). 14 Every router MUST have a set of configuration parameters controlling 15 its operation. It MUST be possible to set these parameters remotely 16 from the NOC or locally at any time, without taking the router down. 17 It SHOULD be possible for these parameters to be executed as a batch. A.1 Required Configuration Parameters 1 The following is a partial but representative list of possible 2 configuration parameters for a full-function router. The items 3 marked with "(i)" should be settable independently for each 4 network interface. 5 o(i) IP (sub-) network address 6 o(i) Subnet mask 7 o(i) MTU of local network 8 o(i) Hardware interface address 9 o(i) Broadcast compatibility option (0s or 1s) 10 o EGP parameters -- neighbors, Autonomous System number, and 11 polling parameters 12 o Static routes, if any 13 o Default Networks, if any Internet Engineering Task Force [Page 174] DRAFT CONFIGURATION PARAMETERS October 1, 1991 14 o Default Subnets, if any 15 o Enable/Disable Proxy ARP 16 o Source Quench parameters 17 o Address filter configuration 18 o Boot-host address 19 o IP address of time server host 20 o IP address(es) of logging host(s) 21 o IP address(es) of hosts to receive traps 22 o IP address(es) of hosts authorized to issue control commands 23 o Error level for logging 24 o Maximum trap frequency 25 o Hold-down period (if any) A.2 Recommended Configuration Parameters Internet Engineering Task Force [Page 175] DRAFT SOURCE-ROUTING HOSTS October 1, 1991 APPENDIX B. REQUIREMENTS FOR SOURCE-ROUTING HOSTS 1 SOURCE: | 2 Source: RFC-1122 section 3.3.5 | 3 EDITOR'S COMMENTS: | 4 Copied verbatim; needs to be looked at, section number | 5 references updated, references to RFC-1009 deleted, etc. | 6 Subject to restrictions given below, a host MAY be able to act as an | 7 intermediate hop in a source route, forwarding a source-routed | 8 datagram to the next specified hop. | 9 However, in performing this router-like function, the host MUST obey | 10 all the relevant rules for a gateway forwarding source-routed | 11 datagrams [INTRO:2]. This includes the following specific | 12 provisions, which override the corresponding host provisions given | 13 earlier in this document: | 14 (A) TTL (ref. Section 3.2.1.7) | 15 The TTL field MUST be decremented and the datagram perhaps | 16 discarded as specified for a gateway in [INTRO:2]. | 17 (B) ICMP Destination Unreachable (ref. Section 3.2.2.1) | 18 A host MUST be able to generate Destination Unreachable messages | 19 with the following codes: | 20 4 (Fragmentation Required but DF Set) when a source- routed | 21 datagram cannot be fragmented to fit into the target network; | 22 5 (Source Route Failed) when a source-routed datagram cannot be | 23 forwarded, e.g., because of a routing problem or because the | 24 next hop of a strict source route is not on a connected network. | 25 (C) IP Source Address (ref. Section 3.2.1.3) | 26 A source-routed datagram being forwarded MAY (and normally will) | 27 have a source address that is not one of the IP addresses of the | 28 forwarding host. | 29 (D) Record Route Option (ref. Section 3.2.1.8d) | 30 A host that is forwarding a source-routed datagram containing a | 31 Record Route option MUST update that option, if it has room. | Internet Engineering Task Force [Page 176] DRAFT SOURCE-ROUTING HOSTS October 1, 1991 32 (E) Timestamp Option (ref. Section 3.2.1.8e) | 33 A host that is forwarding a source-routed datagram containing a | 34 Timestamp Option MUST add the current timestamp to that option, | 35 according to the rules for this option. | 36 To define the rules restricting host forwarding of source- routed | 37 datagrams, we use the term "local source-routing" if the next hop | 38 will be through the same physical interface through which the | 39 datagram arrived; otherwise, it is "non-local source-routing". | 40 A host is permitted to perform local source-routing without | 41 restriction. | 42 A host that supports non-local source-routing MUST have a | 43 configurable switch to disable forwarding, and this switch MUST | 44 default to disabled. | 45 The host MUST satisfy all gateway requirements for configurable | 46 policy filters [INTRO:2] restricting non- local forwarding. | 47 If a host receives a datagram with an incomplete source route but | 48 does not forward it for some reason, the host SHOULD return an ICMP | 49 Destination Unreachable (code 5, Source Route Failed) message, unless | 50 the datagram was itself an ICMP error message. Internet Engineering Task Force [Page 177] DRAFT GLOSSARY October 1, 1991 APPENDIX C. GLOSSARY 1 address | 2 There are three separate uses of this term in | 3 internet networking: "electronic mail address", | 4 "internet address", and "MAC address". An | 5 electronic mail address is the string of characters | 6 that you must give an electronic mail program to | 7 direct a message to a particular person. See | 8 "internet address" and "MAC address" for their | 9 definitions. | 10 ARP Address Resolution Protocol | 11 An Internet protocol which maps internet addresses | 12 to MAC addresses. | 13 ARPANET Advanced Research Projects Agency Network | 14 A pioneering long haul network funded by ARPA. It | 15 served as the basis for early networking research | 16 as well as a central backbone during the | 17 development of the Internet. The ARPANET consisted | 18 of individual packet switching computers | 19 interconnected by leased lines. | 20 application gateway | 21 See the definition of gateway. | 22 AS Autonomous System | 23 A collection of gateways (routers) under a single | 24 administrative authority using a common Interior | 25 Gateway Protocol for routing packets. | 26 B Byte | 27 One character of information, usually eight bits | 28 wide. | 29 b bit - binary digit | 30 The smallest amount of information which may be | 31 stored in a computer. | 32 BBN Bolt Beranek and Newman, Inc. | 33 The Cambridge, MA company responsible for | 34 development, operation and monitoring of the | 35 ARPANET, and later, the Internet core gateway | 36 system, the CSNET Coordination and Information | 37 Center (CIC), and NSFNET Network Service Center | 38 (NNSC). | Internet Engineering Task Force [Page 178] DRAFT GLOSSARY October 1, 1991 39 BGP Border Gateway Protocol | 40 An IP EGP. | 41 bps bits per second | 42 A measure of data transmission speed. | 43 bridge | 44 A device which joins network segments at the link | 45 layer. These segments would have the same IP | 46 network address. | 47 broadcast | 48 A packet which is destined for all hosts. On a | 49 LAN, this means "all hosts on the LAN". | 50 broadcast address | 51 A special type of address which is recognized by | 52 all hosts. | 53 BSD Berkeley Software Distribution | 54 Term used when describing different versions of the | 55 Berkeley UNIX software, as in "4.3BSD UNIX". | 56 checksum | 57 An error detection field in a packet header which | 58 can be used to detect packet corruption. IP uses a | 59 one's complement, 16-bit checksum algorithm. | 60 core gateway | 61 Historically, one of a set of gateways (routers) | 62 operated by the Internet Network Operations Center | 63 at BBN. The core gateway system forms a central | 64 part of Internet routing in that all groups had to | 65 advertise | 66 CSNET Computer + Science Network | 67 A large data communications network for | 68 institutions doing research in computer science.It | 69 uses several different protocols including some of | 70 its own. CSNET sites include universities, | 71 research laboratories, and commercial companies. | 72 See CREN. | 73 DARPA U.S. Department of Defense Advanced Research | 74 Projects Agency | 75 The government agency that funded the ARPANET and | 76 later started the Internet. | Internet Engineering Task Force [Page 179] DRAFT GLOSSARY October 1, 1991 77 datagram | 78 The unit transmitted between a pair of internet | 79 modules. data, called datagrams, from sources to | 80 destinations. The Internet Protocol does not | 81 provide a reliable communication facility. There | 82 are no acknowledgements either end-to-end or hop- | 83 by-hop. There is no error no retransmissions. | 84 There is no flow control. See IP. | 85 DDN Defense Data Network | 86 DDN NIC The network information center at SRI | 87 International. | 88 It is the primary repository for RFCs and Internet | 89 Drafts, as well as providing other services. | 90 default route | 91 A routing table entry which is used to direct any | 92 data addressed to any network numbers not | 93 explicitly listed in the routing table. | 94 DNS The Domain Name System is a mechanism used in | 95 the Internet for translating names of host | 96 computers into addresses. The DNS also allows host | 97 computers not directly on the Internet to have | 98 registered names in the same style, but returns the | 99 electronic mail gateway which accesses the non- | 100 Internet network instead of an IP address. | 101 dot address (also called dotted address notation) | 102 Dot address refers to the common notation for | 103 Internet addresses of the form A.B.C.D; where each | 104 letter represents, in decimal, one byte of the four | 105 byte IP address. | 106 EGP Exterior Gateway Protocol | 107 A protocol which distributes routing information to | 108 the gateways (routers) which connect autonomous | 109 systems. See IGP. | 110 EGP-2 Exterior Gateway Protocol version 2 | 111 This is an EGP routing protocol developed to handle | 112 traffic between AS's in the Internet. | 113 ES End System | 114 The OSI term for host. | 115 Ethernet | Internet Engineering Task Force [Page 180] DRAFT GLOSSARY October 1, 1991 116 A network standard for the hardware and data link | 117 levels. Originally, there was Digital/Intel/Xerox | 118 (DIX) Ethernet which the IEEE later standardized | 119 (with changes) as 802.3. | 120 FDDI Fiber Distributed Data Interface | 121 FDDI is a high-speed (100Mb) token ring LAN. | 122 fragment | 123 An IP datagram which represents a portion of a | 124 higher layer's packet which was too large to be | 125 sent in its entirety over the output network. | 126 FTP File Transfer Protocol | 127 The Internet standard high-level protocol for | 128 transferring files from one computer to another. | 129 gateway | 130 The name "router" is now used in place of the | 131 original definition of gateway (see the definition | 132 of router). Currently, gateway is a communications | 133 program which translates between interfaces having | 134 related servies and incompatible implementations. | 135 A router would then be a level 3 (network layer) | 136 gateway; a mail gateway would be a level 7 | 137 (application layer) gateway. | 138 GB Gigabyte | 139 A unit of data storage size which represents 10^9 | 140 (over 1 billion) characters of information. | 141 Gb Gigabit | 142 2^30 bits of information (usually used to express a | 143 data transfer rate; as in, 1 gigabit/second = | 144 1Gbps). | 145 hardware address | 146 See the definition of MAC address. | 147 header | 148 The portion of a packet, preceding the actual data, | 149 containing source and destination addresses and | 150 error-checking fields. | 151 host number | 152 The part of an internet address that designates | 153 which node on the (sub)network is being addressed. | Internet Engineering Task Force [Page 181] DRAFT GLOSSARY October 1, 1991 154 IAB Internet Activities Board | 155 The IAB is the coordinating committee for Internet | 156 design, engineering and management. | 157 ICMP Internet Control Message Protocol | 158 ICMP is an extension to the Internet Protocol. It | 159 allows for the generation of error messages, test | 160 packets and informational messages related to IP. | 161 IEEE Institute for Electrical and Electronics Engineers | 162 IETF Internet Engineering Task Force | 163 The IETF is a large open community of network | 164 designers, operators, vendors, and researchers | 165 whose purpose is to coordinate the operation, | 166 management and evolution of the Internet, and to | 167 resolve short- and mid-range protocol and | 168 architectural issues. It is a major source of | 169 proposed protocol standards which are submitted to | 170 the Internet Activities Board for final approval. | 171 The IETF meets three times a year and extensive | 172 minutes of the plenary proceedings are issued. | 173 IGP Interior Gateway Protocol | 174 A protocol which distributes routing information | 175 with an Autonomous System (AS). See EGP. | 176 internet internetwork | 177 Internet | 178 The global collection of interconnected local, | 179 mid-level and protocol. | 180 internet address | 181 An assigned number which identifies a host in an | 182 internet. It has two or three parts: network | 183 number, optional subnet number, and host number. | 184 IP Internet Protocol | 185 The network layer protocol for the Internet. It is | 186 a packet switching, datagram protocol defined in | 187 RFC 791. IP does not provide a reliable | 188 communications facility; that is, there are no | 189 end-to-end of hop-by-hop acknowledgements. There | 190 are | 191 IRTF Internet Research Task Force | 192 The IRTF is a community of network researchers, | Internet Engineering Task Force [Page 182] DRAFT GLOSSARY October 1, 1991 193 generally with an Internet focus. The work of the | 194 IRTF is governed by its Internet Research Steering | 195 Group (IRSG). | 196 IS Intermediate System | 197 The OSI term for a bridge or router. | 198 IS-IS | 199 The OSI IGP. A version of IS-IS may be used as an | 200 IP IGP. | 201 ISO International Organization for Standardization | 202 KB Kilobyte | 203 A unit of data storage size which represents 2^10 | 204 (1024) characters of information. | 205 Kb Kilobit | 206 10^3 bits of information (usually used to express a | 207 data transfer rate; as in, 1 kilobit/second = 1Kbps | 208 = 1Kb). | 209 LAN Local Area Network | 210 A network that takes advantage of the proximity of | 211 computers to offer relatively efficient, higher | 212 speed communications | 213 MAC Medium Access Control | 214 to determine which device has line access at any | 215 given time. | 216 MAC address | 217 The physical address of a device usually available | 218 to the hardware on PROM. Ethernet, for example, | 219 has a 48 bit MAC address. | 220 MAN Metropolitan Area Network | 221 martian filtering | 222 A packet which contains an invalid source or | 223 destination address is considered to be "martian" | 224 and discarded. | 225 mayonnaise | 226 A thick salad dressing or condiment made with oil | 227 and egg | 228 MB Megabyte | Internet Engineering Task Force [Page 183] DRAFT GLOSSARY October 1, 1991 229 A unit of data storage size which represents over | 230 2^18 (just over one million) characters of | 231 information. | 232 Mb Megabit | 233 10^6 bits of information (usually used to express a | 234 data transfer rate; as in, 1 megabit/second = | 235 1Mbps). | 236 MIB Management Information Base | 237 The description of the SNMP manageable objects. | 238 There are MIBs for many protocols, hardware and | 239 vendors. | 240 MILNET Military Network | 241 A network used for unclassified military production | 242 applications. It is part of the DDN and the | 243 Internet. | 244 MTU Maximum Transmission Unit | 245 The largest packet which may be sent over the | 246 specified media excluding the media overhead | 247 (headers and trailers). | 248 multicast | 249 A packet which is destined for multiple hosts. See | 250 "broadcast". | 251 multicast address | 252 A special type of address which is recognized by | 253 multiple hosts. See "broadcast address". | 254 network number | 255 The part of an internet address which designates | 256 the network to which the addressed node belongs. | 257 NIC Network Information Center | 258 An organization which provides network users with | 259 information about services provided by the network. | 260 NOC Network Operations Center | 261 An organization that is responsible for maintaining | 262 a network. | 263 NSF National Science Foundation | 264 NSFNET National Science Foundation Network | 265 hierarchical in nature. At the highest level is a | Internet Engineering Task Force [Page 184] DRAFT GLOSSARY October 1, 1991 266 network that spans the continental United States. | 267 Attached to that of the U.S. to Canada, Mexico, | 268 Europe, and the Pacific Rim. The NSFNET is part of | 269 the Internet. | 270 NSFNET Mid-level Level Network | 271 A network connected to the highest level of the | 272 NSFNET that covers a region of the United States. | 273 It is to mid-level were once called "regionals". | 274 OSI Open Systems Interconnection | 275 A set of protocols designed to be an international | 276 standard has done most of the work developing OSI | 277 and will probably use it as soon as possible. | 278 OSI Reference Model | 279 An "outline" of OSI which defines its seven layers | 280 and their functions. Sometimes used to help | 281 describe other | 282 OSPF Open Shortest-Path First Interior Gateway Protocol | 283 A proposed replacement for RIP. It addresses some | 284 problems of RIP and is based upon principles that | 285 have been well-tested in non-internet protocols. | 286 Originally acronymed as OSPFIGP. | 287 packet | 288 The unit of data sent across a packet switching | 289 network. The term is used loosely. While some | 290 Internet literature uses it to refer specifically | 291 to data sent across a physical network, other | 292 literature views the Internet as a packet switching | 293 network and describes IP datagrams as packets. | 294 PPP Point-to-Point Protocol | 295 The Point-to-Point Protocol (PPP) provides a method | 296 for | 297 protocol | 298 A formal description of message formats and the | 299 rules two computers must follow to exchange those | 300 messages. Protocols can describe low-level details | 301 of machine-to-machine interfaces (e.g., the order | 302 in which bits and bytes are sent across a wire) or | 303 high-level exchanges between allocation programs | 304 (e.g., the way in which two programs transfer a | 305 file across the Internet). | Internet Engineering Task Force [Page 185] DRAFT GLOSSARY October 1, 1991 306 RFC The Internet's Request for Comments documents | 307 series | 308 The RFCs are working notes of the Internet research | 309 and development community. A document in this | 310 series may be on essentially any topic related to | 311 computer communication, and may be anything from a | 312 meeting report to the specification of a standard. | 313 RIP Routing Interchange Protocol | 314 One protocol which may be used on internets simply | 315 to pass routing information between gateways.It is | 316 used on many | 317 router | 318 A special-purpose dedicated computer that attaches | 319 to network to the other. In particular, an | 320 Internet connects. Gateways route packets to other | 321 gateways until they can be delivered to the final | 322 destination directly across one physical network. | 323 serial line | 324 A physical media which we cannot define, but which | 325 we recognize when we see one. See the Supreme | 326 Court's definitions on pornography. | 327 SLIP Serial Line Internet Protocol | 328 SLIP is currently a defacto standard, commonly used | 329 for point-to-point serial connections running | 330 TCP/IP. It is not an Internet standard but is | 331 defined in RFC 1055. | 332 SNMP Simple Network Management Protocol | 333 The Simple Network Management Protocol (RFC 1157) | 334 is the Internet's standard for remote monitoring | 335 and management of hosts, routers and other nodes | 336 and devices on a network. | 337 subnet | 338 A portion of a network, which may be a physically | 339 independent network, which shares a network address | 340 with other portions of the network and is | 341 distinguished by a subnet number. A subnet is to a | 342 network what a network is to an internet. | 343 subnet number | 344 A part of the internet address which designates a | 345 subnet. It is ignored for the purposes internet | 346 routing, but is used for intranet routing. | Internet Engineering Task Force [Page 186] DRAFT GLOSSARY October 1, 1991 347 T1 | 348 A term for a digital carrier facility used to | 349 transmit a DS-1 formatted digital signal at 1.544 | 350 megabits per second. | 351 T3 | 352 A term for a digital carrier facility used to | 353 transmit a DS-3 formatted digital signal at 44.746 | 354 megabits per second. | 355 TCP Transmission Control Protocol | 356 A transport layer protocol for the Internet. It is | 357 a connection oriented, stream protocol defined by | 358 RFC 793. | 359 TCP/IP Transmission Control Protocol/Internet Protocol | 360 This is a common shorthand which refers to the | 361 suite of application and transport protocols which | 362 run over IP. These include FTP, TELNET, SMTP, and | 363 UDP (a transport layer protocol). | 364 TELNET The Internet standard protocol for remote terminal | 365 connection service. TELNET allows a user at one | 366 site to interact with a remote timesharing system | 367 at another site as if the user's terminal was | 368 connected directly to the remote computer. | 369 TOS Type Of Service | 370 A field in the IP header which represents the | 371 degree of reliability expected from the network | 372 layer by the transport layer or application. | 373 TTL Time To Live | 374 A field in the IP header which represents how long | 375 a packet is considered valid. It is a combination | 376 "hop count" and "timer value". | 377 Token Ring | 378 A type of LAN. Examples are IEEE 802.5, ProNET- | 379 10/80 and FDDI. The term "token ring" is often | 380 used to denote 802.5 | 381 UDP User Datagram Protocol | 382 A transport layer protocol for the Internet. It is | 383 a datagram protocol which adds a level of | 384 reliability and multiplexing to IP datagrams. It | 385 is defined in RFC 768. | Internet Engineering Task Force [Page 187] DRAFT GLOSSARY October 1, 1991 386 UNIX An operating system developed by Bell Laboratories | 387 that | 388 supports multiuser and multitasking operations. | 389 WAN Wide Area Network | 390 X.25 | 391 A data communications interface specification | 392 developed to describe how data passes into and out | 393 of public data Sprintnet and Tymnet use X.25 to | 394 interface to customer computers. Internet Engineering Task Force [Page 188] DRAFT BIBLIOGRAPHY October 1, 1991 APPENDIX D. BIBLIOGRAPHY Maybe TBD (probably going away) Internet Engineering Task Force [Page 189] DRAFT FUTURE DIRECTIONS October 1, 1991 APPENDIX E. FUTURE DIRECTIONS 1 TBD. Topics might include: | 2 SNMP security | 3 more MIBS (including Routing Table MIB) | 4 IDPR | 5 CIPSO | Internet Engineering Task Force [Page 190] DRAFT INDEX October 1, 1991 F. INDEX TBD Internet Engineering Task Force [Page 191] DRAFT October 1, 1991 Security Considerations Although the focus of this document is interoperability rather than security, there are obviously many sections of this document which have some ramifications on network security. EDITOR'S COMMENTS: The editor of this document has noted that the RFC format now seems to include a section called "Security Considerations", but he has no idea what it is supposed to contain. Author's Address Philip Almquist 214 Cole Street, Suite 2 San Francisco, CA, 94117-1916 USA Phone: 415-752-2427 EMail: almquist@Jessica.Stanford.EDU Internet Engineering Task Force [Page 192]