Network Working Group Internet Engineering Task Force INTERNET-DRAFT Philip Almquist, Editor March 1991 Requirements for Internet IP Routers 0Non-status of This Memo 1 The document is a preliminary, incomplete draft document of the IETF 2 Router Requirements Working Group. Its authors hope that, after its 3 completion in early 1991, this document will be accepted as an 4 Internet standard which would supercede RFC-1009, "Requirements for 5 Internet Gateways" ([INTRO:1]). This document incorporates by 6 reference and attempts to amend, correct, and supplement the primary 7 protocol standards documents relating to IP routers. Distribution of 8 this document is unlimited. 9 Readers of this draft are invited and encouraged to comment and to 10 propose text for inclusion in future versions of this draft. 11 Comments on the technical content should be sent to the IETF Router 12 Requirements Working Group at: 13 ietf-rreq@Jessica.Stanford.EDU. 14 Editorial (non-technical) comments should be sent to the editor at: 15 ietf-rreq-editor@Jessica.Stanford.EDU. 16 Comments which cannot be sent electronically may be sent to: 17 IETF Router Requirements Working Group 18 c/o Philip Almquist 19 214 Cole Street, Suite #2 20 San Francisco, CA 94117-1916 21 USA 0Summary 1 This draft attempts to define and discuss requirements for devices 2 which perform the network layer forwarding function of the Internet 3 protocol suite. The Internet community usually refers to such 4 devices as "routers". This document is intended to provide guidance 5 for vendors, implementors, and purchasers of IP routers. Internet Engineering Task Force [Page 1] INTERNET-DRAFT PREFACE March 6, 1991 Information for Readers This document is still a fairly preliminary draft. We would very much appreciate comments. Instructions for sending us comments are included on the previous page. You may well find it useful to have at hand copies of RFC-1122 and RFC-1009 when reading this document. This document is part of a two document set. This document describes IP routers, covering the Internet Layer and above. The second document is not yet available, but will cover the Link Layer for both hosts and routers. You will notice that numerous important topics are currently not covered, or are discussed only superficially. When you notice these omissions, please help us correct them by contributing some text. It takes very little time to write a few paragraphs, yet if every reader of this document were to do so, the document would be almost done! This is a good opportunity for you to contribute to an important Internet standard. Topics which we intend to cover but have not yet done so are listed in the next section. If there are topics which you think should be covered but are not listed there, please let us know. If you do not have time to read the entire document, you may wish to pay particular attention to the following topics, which have proven particularly contentious: - Compliance (Section [1.1.3]) * - TOS (Sections [4.2.2.3] and [5.3.2]) - Fragmentation and reassembly (Sections [4.2.2.6] and [4.2.2.7]) - Forwarding algorithm overview (Section [5.2.1]) - TTL (Sections [4.2.2.8] and [5.3.1]) - Broadcast handling (Section [5.3.5]) - Martian filtering (Section [5.3.7]) As an aid to readers of previous versions of the draft, this draft | uses change bars to highlight changes made since the Boulder IETF | Meeting. Changes which occurred before then but since the previous | (September 16) Internet Draft version are marked with asterisks in | the right margin. Please be warned, however, that although I have | endeavored to make sure that all substantive changes are marked, this| process is a manual and therefore not necessarily infallible one. | We appreciate your help and input in making this a good standard for the Internet. Internet Engineering Task Force [Page 2] INTERNET-DRAFT PREFACE March 6, 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? For those of you who still don't know what to write about, the rest of this section talks about what we currently plan to cover, and what parts I (the editor) think someone is (and is not) already working on. Chapters 1 and 2 are introductory material. Chapter 1 is (I think) pretty complete, but needs additional work on the sections on compliance and definitions. Chapter 2 is still something of an | outline, but work is proceeding. Let me know if you note any | omissions other than sections which need fleshing out. Chapter 3 is basically just a pointer to the draft Link Layer standard. There are plans to describe the interface between the Link| Layer and the Internet Layer, and also to specify what a router needs| to do when an interface dies (or is intentionally disabled). I need volunteers to help write the Link Layer standard; let me know if you are interested. I particularly need someone who would like to think (and write) about link and interface failure detection and recovery. Chapter 4 covers IP and related protocols. I think this is pretty | complete, except that the parts which are the same as RFC-1122 will | probably just be replaced with references to RFC-1122. Chapter 5 covers forwarding. Since this is at the heart of what a router does, it is hardly surprising that this chapter is the least stable and most contentious in the document. I would very much like contributions on resource management in the router. The existing handwaving about IP multicast needs to be replaced with meaningful text. Someone (or several people) need to carefully think through the implications of multiple nets/subnets on the same cable, and whether the rules as written handle all cases correctly. Ditto for variable length subnet masks. There should be a description of the | Internet Engineering Task Force [Page 3] INTERNET-DRAFT PREFACE March 6, 1991 Patricia algorithm, but I think I may have a volunteer to write it. Finally, suggestions on how to express the ideas in this chapter more clearly, precisely, or succinctly would be much appreciated. Chapter 6 covers Transport Layer protocols. The current version is | an initial rough cut. Chapter 7 covers routing protocols and the related topics of filtering routing information and leaking it between routing protocols. A good start has been made on this chapter, but we need people to flesh out the parts which are currently rather sketchy. We need someone to write something on multicast routing. We also need * more text on leaking routing information between routing protocols. * Chapter 8 will cover network management protocols. I am hoping to receive a draft of a section on SNMP shortly. There will also be sections on CMIP or CMOT if (and only if) someone volunteers to write them. Chapter 9 will cover miscellaneous application layer protocols (BOOTP, TFTP, Telnet) that routers often implement. Like Chapter 6, this is expected to be mostly if not entirely pointers to RFC-1123. | I don't think anyone is currently working on this chapter. Chapter 10 will cover operations and maintenance issues for routers. This is kind of a catch-all chapter, to which a great many topics might be germane. Let me know if you note any that are missing. 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] INTERNET-DRAFT CONTENTS March 6, 1991 Table of Contents 1. INTRODUCTION ............................................ 9 1.1 Reading this Document ............................... 11 1.1.1 Organization ................................... 11 1.1.2 Requirements ................................... 13 1.1.3 Compliance ..................................... 14 1.1.4 Terminology .................................... 15 1.2 Relationships to Other Standards .................... 17 1.3 General Considerations .............................. 18 1.3.1 Continuing Internet Evolution .................. 18 1.3.2 Robustness Principle ........................... 19 1.3.3 Error Logging .................................. 20 1.3.4 Configuration .................................. 21 1.4 Acknowledgments ..................................... 22 2. INTERNET ARCHITECTURE ................................... 23 2.1 Internet Protocols .................................. 23 2.1.1 Introduction ................................... 23 2.1.2 Protocol Layering .............................. 24 2.2 Networks and Routers ................................ 26 2.3 Router Characteristics .............................. 28 2.4 Architectural Miscellany ............................ 31 2.4.1 Autonomous Systems ............................. 31 2.4.2 Addresses and Subnets .......................... 31 2.4.3 IP Multicasting ................................ 33 2.4.4 Networks, Subnets, and Unnumbered Lines ........ 33 2.4.5 Interfaces ..................................... 33 2.4.6 Notable Oddities ............................... 33 2.4.6.1 Half-Routers .............................. 33 2.4.6.2 Embedded Routers .......................... 33 2.4.6.3 Transparent Routers ....................... 34 2.5 Architectural Assumptions ........................ 35 3. LINK LAYER .............................................. 38 3.1 Requirements Summary ................................ 38 4. INTERNET LAYER -- PROTOCOLS ............................. 39 4.1 INTRODUCTION ........................................ 39 4.2 INTERNET PROTOCOL -- IP ............................. 39 4.2.1 INTRODUCTION ................................... 39 4.2.2 PROTOCOL WALK-THROUGH .......................... 39 Internet Engineering Task Force [Page 5] INTERNET-DRAFT CONTENTS March 6, 1991 4.2.2.1 Options ................................... 39 4.2.2.2 Unused IP Header Bits ..................... 44 4.2.2.3 Type of Service ........................... 45 4.2.2.4 Header Checksum ........................... 45 4.2.2.5 Unrecognized Header Options ............... 45 4.2.2.6 Fragmentation ............................. 45 4.2.2.7 Reassembly ................................ 47 4.2.2.8 Time to Live .............................. 47 4.2.2.9 Routing of Broadcasts ..................... 48 4.2.2.10 Addressing ............................... 48 4.2.3 SPECIFIC ISSUES ................................ 50 4.2.3.1 IP Broadcast Addresses .................... 51 4.2.3.2 IP Multicasting ........................... 51 4.2.3.3 Path MTU Discovery ........................ 52 4.3 INTERNET CONTROL MESSAGE PROTOCOL -- ICMP ........... 53 4.3.1 INTRODUCTION ................................... 54 4.3.2 GENERAL ISSUES ................................. 54 4.3.3 SPECIFIC ISSUES ................................ 57 4.3.3.1 Destination Unreachable ................... 57 4.3.3.2 Redirect .................................. 59 4.3.3.3 Source Quench ............................. 60 4.3.3.4 Time Exceeded ............................. 61 4.3.3.5 Parameter Problem ......................... 61 4.3.3.6 Echo Request/Reply ........................ 62 4.3.3.7 Information Request/Reply ................. 63 4.3.3.8 Timestamp and Timestamp Reply ............. 63 4.3.3.9 Address Mask Request/Reply ................ 64 4.3.3.10 Router Advertisement and Solicitations ... 65 4.4 INTERNET GROUP MANAGEMENT PROTOCOL -- IGMP .......... 66 4.5 REQUIREMENTS SUMMARY ................................ 66 5. INTERNET LAYER -- FORWARDING ............................ 67 5.1 INTRODUCTION ........................................ 67 5.2 FORWARDING WALK-THROUGH ............................. 67 5.2.1 Forwarding Algorithm ........................... 67 5.2.2 IP Header Validation ........................... 69 5.2.3 Local Delivery Decision ........................ 72 5.2.4 Determining the Next Hop Address ............... 74 5.2.4.1 Immediate Destination Address ............. 75 5.2.4.2 Local/Remote Decision ..................... 75 5.2.4.3 Next Hop Address .......................... 76 5.2.5 Addresses in Options ........................... 77 5.3 SPECIFIC ISSUES ..................................... 77 5.3.1 Time to Live (TTL) ............................. 77 5.3.2 Type of Service (TOS) .......................... 79 5.3.3 IP Precedence .................................. 80 5.3.3.1 Precedence-Ordered Queue Service .......... 81 5.3.3.2 Lower Layer Precedence Mappings ........... 82 Internet Engineering Task Force [Page 6] INTERNET-DRAFT CONTENTS March 6, 1991 5.3.3.3 Precedence Handling For All Routers ....... 83 5.3.4 Forwarding of Link Layer Broadcasts ............ 85 5.3.5 Forwarding of Internet Layer Broadcasts ........ 86 5.3.5.1 Limited Broadcasts ........................ 88 5.3.5.2 Net-directed Broadcasts ................... 88 5.3.5.3 All-subnets-directed Broadcasts ........... 89 5.3.5.4 Subnet-directed Broadcasts ................ 90 5.3.6 Congestion Control ............................. 91 5.3.7 Martian Address Filtering ...................... 92 5.3.8 Packet Filtering and Access Lists .............. 93 5.3.9 Controls on Forwarding ......................... 94 5.4 REQUIREMENTS SUMMARY ................................ 94 6. TRANSPORT LAYER ......................................... 95 6.1 USER DATAGRAM PROTOCOL -- UDP ....................... 95 6.2 TRANSMISSION CONTROL PROTOCOL -- TCP ................ 99 7. APPLICATION LAYER -- ROUTING PROTOCOLS .................. 127 7.1 INTRODUCTION ........................................ 127 7.2 INTERIOR GATEWAY PROTOCOLS .......................... 127 7.2.1 INTRODUCTION ................................... 127 7.2.2 OPEN SHORTEST PATH FIRST -- OSPF ............... 128 7.2.2.1 Introduction .............................. 128 7.2.2.2 Protocol Walk-through ..................... 128 7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM -- ............................................................. 129 7.2.3.1 Introduction .............................. 129 7.2.4 ROUTING INFORMATION PROTOCOL -- RIP ............ 129 7.2.4.1 Introduction .............................. 129 7.2.4.2 Protocol Walk-Through ..................... 129 7.2.4.3 Specific Issues ........................... 132 7.2.5 GATEWAY TO GATEWAY PROTOCOL -- GGP ............. 132 7.3 EXTERIOR GATEWAY PROTOCOLS .......................... 132 7.3.1 INTRODUCTION ................................... 132 7.3.2 BORDER GATEWAY PROTOCOL -- BGP ................. 133 7.3.2.1 Introduction .............................. 133 7.3.2.2 Protocol Walk-through ..................... 135 7.3.3 EXTERIOR GATEWAY PROTOCOL -- EGP ............... 135 7.3.3.1 Introduction .............................. 135 7.3.3.2 Protocol Walk-through ..................... 135 7.3.4 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL ............................................................. 138 7.4 STATIC ROUTING ...................................... 138 7.5 FILTERING OF ROUTING INFORMATION .................... 139 7.5.1 Basic Route Filtering .......................... 139 7.5.2 Advanced Route Filtering ....................... 140 7.6 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE ......... 141 7.7 REQUIREMENTS SUMMARY ................................ 142 Internet Engineering Task Force [Page 7] INTERNET-DRAFT CONTENTS March 6, 1991 8. APPLICATION LAYER -- NETWORK MANAGEMENT PROTOCOLS ....... 143 9. APPLICATION LAYER -- MISCELLANEOUS PROTOCOLS ............ 144 9.1 Bootstrap Protocol (BOOTP) .......................... 144 9.1.1 Introduction ................................... 144 9.1.2 BOOTP Processing ............................... 145 9.1.3 BOOTREQUEST Messages ........................... 146 9.1.4 BOOTREPLY Messages ............................. 148 9.2 REQUIREMENTS SUMMARY ................................ 149 10. OPERATIONS AND MAINTENANCE ............................. 150 10.1 Minimum Router Configuration ....................... 150 10.2 Address Mask Initialization ........................ 150 10.3 Operation and Maintenance .......................... 151 10.3.1 Introduction .................................. 151 10.3.2 Router O&M Models ............................. 153 10.3.3 Router O&M Functions .......................... 155 10.3.4 Router Configuration Parameters ............... 159 10.3.5 Router Hardware and Software Diagnostics ...... 160 10.4 REQUIREMENTS SUMMARY ............................... 161 11. REFERENCES ............................................. 162 Internet Engineering Task Force [Page 8] INTERNET-DRAFT INTRODUCTION March 6, 1991 01. INTRODUCTION 1 SOURCE: 2 Chapter 1 source: RFC-1122 chapter 1, contributor: Philip 3 Almquist. 4 Relationship to HRRFC: A heavily hacked up version of the intro 5 from RFC-1122, adjusted to reflect the fact that this document 6 is about routers rather than hosts and to delete the Internet 7 architecture discussion (since that is a separate chapter in 8 this document). 9 The only known area of possible non-alignment with the HRRFCs is 10 the definition of compliance. This document includes a longer, 11 more detailed, but (Almquist believes) basically compatible 12 description of compliance. 13 This DRAFT attempts to define and discuss requirements for devices 14 which perform the network layer forwarding function of the Internet 15 protocol suite. The Internet community usually refers to such 16 devices as "IP routers" or simply "routers". Other names which are 17 sometimes used for these devices include "intermediate systems" and, 18 less correctly, "gateways". Portions of this specification also 19 apply to hosts which are not routers but which are able to forward 20 source-routed IP packets. 21 The authors of this memo recognize, as should its readers, that many 22 routers support multiple protocol suites, and that support for 23 multiple protocol suites will be required in increasingly large parts 24 of the Internet in the future. This memo, however, does not attempt 25 to specify Internet requirements for protocol suites other than 26 TCP/IP. 27 This DRAFT enumerates standard protocols that a router connected to 28 the Internet must use, and it incorporates by reference the RFCs and 29 other documents describing the current specifications for these 30 protocols. It corrects errors in the referenced documents and adds 31 additional discussion and guidance for an implementor. 32 For each protocol, this memo also contains an explicit set of 33 requirements, recommendations, and options. The reader must 34 understand that the list of requirements in this memo is incomplete 35 by itself; the complete set of requirements for an Internet protocol 36 router is primarily defined in the standard protocol specification 37 documents, with the corrections, amendments, and supplements 38 contained in this DRAFT. 39 SOURCE: Internet Engineering Task Force [Page 9] INTERNET-DRAFT INTRODUCTION March 6, 1991 40 next 2 paragraphs source: new text, contributor: Stephanie Price 41 Relationship to HRRFC: none 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: Internet Engineering Task Force [Page 10] INTERNET-DRAFT INTRODUCTION March 6, 1991 80 o Some required features are more important than others, and some 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. 0 1.1 Reading this Document 0 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 Internet Engineering Task Force [Page 11] INTERNET-DRAFT INTRODUCTION March 6, 1991 22 implementor is urged to read references [INTRO:4] and 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 58 bibliography, a glossary, Internet-specific requirements, and 59 some conjectures about future directions of router standards. 60 EDITOR'S COMMENTS: 61 I have not yet created the summary tables, but they are Internet Engineering Task Force [Page 12] INTERNET-DRAFT INTRODUCTION March 6, 1991 62 expected to be similar in style to those in RFC-1122 and 63 RFC-1123. 64 I also have not yet created the appendices. 65 It's not clear whether or not the Internet-specific 66 requirements appendix will ever exist. There is some 67 question whether this document is a TCP/IP standard or 68 merely a standard for the (capital "I") Internet. It has 69 been suggested, for example, that it might be appropriate 70 to mandate that routers on the Internet allow some sort of 71 minimal public SNMP access unless the owner has explicitly 72 decided to disable it. While such a policy would make it 73 easier to resolve Internet problems, it's not clear it 74 would be appropriate for a TCP/IP standard. 0 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 or the adjective "REQUIRED" means that the item 6 is an absolute requirement 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 or the adjective "RECOMMENDED" means that there 16 may exist valid reasons in particular circumstances to 17 ignore this item, but the full implications should be 18 understood and the case carefully weighed before choosing 19 a different course. 20 o "SHOULD IMPLEMENT" * Internet Engineering Task Force [Page 13] INTERNET-DRAFT INTRODUCTION March 6, 1991 21 This phrase is similar in meaning to SHOULD, but is used * 22 when we recommend that a particular feature be provided * 23 but don't necessarily recommend that it be enabled by * 24 default. * 25 o "SHOULD NOT" 26 This phrase means that there may exist valid reasons in 27 particular circumstances when the listed behavior is 28 acceptable or even useful, but the full implications 29 should be understood and the case carefully weighed before 30 implementing any behavior described with this label. 31 o "MAY" 32 This word or the adjective "OPTIONAL" means that this item 33 is truly optional. One vendor may choose to include the 34 item because a particular marketplace requires it or 35 because it enhances the product, for example; another 36 vendor may omit the same item. 0 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 paragraph, 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 An implementation is said to be "conditionally compliant" if it | 9 satisfies all of the relevant MUST, MUST IMPLEMENT, and MUST | 10 NOT requirements. An implementation is said to be | 11 "unconditionally compliant" if it is conditionally compliant | 12 and also satisfies all of the relevant SHOULD, SHOULD | 13 IMPLEMENT, and SHOULD NOT requirements. An implementation is | 14 not compliant if it is not conditionally compliant (ie, it | 15 fails to satisfy one or more of the relevant MUST, MUST | 16 IMPLEMENT, or MUST NOT requirements). 17 For any of the SHOULD and SHOULD NOT requirements, a router may 18 provide a configuration option that will cause the router to 19 act other than as specified by the SHOULD or SHOULD NOT 20 requirement. Having such configuration options does not void a 21 router's claim to unconditional compliance as long as each of 22 these options has a default setting, and that leaving each of 23 these options at its default value causes the router to operate Internet Engineering Task Force [Page 14] INTERNET-DRAFT INTRODUCTION March 6, 1991 24 in a manner which meets all of the relevant MUST, MUST NOT, 25 SHOULD, and SHOULD NOT requirements. 26 Likewise, routers may provide, except where explicitly | 27 prohibited by this memo, options which cause them to violate | 28 MUST or MUST NOT requirements. A router which provides such * 29 options is not compliant (either fully or conditionally) unless * 30 each such option has a default setting which causes the router * 31 to conform to the requirements of this memo. Please note that * 32 the authors of this memo, although aware of market realities, * 33 strongly recommend against provision of such options. * 34 Requirements are labeled MUST or MUST NOT because experts in * 35 the field have judged them to be particularly important to * 36 interoperability or proper functioning in the Internet. * 37 Vendors should weigh carefully the customer support costs of * 38 providing options which violate those rules. * 39 AUTHOR'S COMMENTS: 40 Compliance with this document requires compliance with 41 parts of RFC-1122 and RFC-1123, and with the (proposed) 42 Link Layer Requirements document. What, if anything, do 43 we need to say about that here? 44 There's a problem with the distinction between MUST/SHOULD 45 be implemented and MUST/SHOULD be enabled. In response to * 46 this problem, I have added the MUST IMPLEMENT and SHOULD * 47 IMPLEMENT terms, but we need to figure out which * 48 requirements in this document should be changed to use * 49 these new terms. * 0 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. Internet Engineering Task Force [Page 15] INTERNET-DRAFT INTRODUCTION March 6, 1991 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 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 Internet Engineering Task Force [Page 16] INTERNET-DRAFT INTRODUCTION March 6, 1991 55 the two directions between a given host pair. 56 MTU 57 The maximum transmission unit, i.e., the size of the 58 largest packet that can be transmitted or received on a 59 physical network. 60 Silently discard 61 This memo specifies several case where a router is to 62 "silently discard" a received packet (or datagram). This 63 means that the router should discard the packet without 64 further processing, and that the router will not send any 65 ICMP error message (see Section [4.3.2]) as a result. 66 However, for diagnosis of problems, the router SHOULD 67 provide the capability of logging the error (see Section 68 [1.3.3]), including the contents of the silently-discarded 69 packet, and SHOULD record the event in a statistics 70 counter. 71 Silently ignore 72 A router is said to "silently ignore" an error or 73 condition if it takes no action other than possibly 74 generating an error report in an error log or via some 75 network management protocol, and discarding, or ignoring, 76 the source of the error. In particular, the router does 77 NOT generate an ICMP error message. 78 EDITOR'S COMMENTS: 79 Most of the above list is the subset of the definitions 80 from the introduction to RFC-1122 which seemed as if they 81 might be useful. When this document matures somewhat, we 82 should revisit the above list. 0 1.2 Relationships to Other Standards 1 SOURCE: 2 Section 1.2 source: RFC-1130 section 4, contributor: Philip 3 Almquist. 4 Content is almost identical to RFC-1130, except that 5 irrelevant information was deleted and references to the 6 current RFC numbers for the documents listed below were 7 deleted (as likely to become obsolete faster than this memo). 8 There are several reference documents of interest in checking the 9 current status of protocol specifications and standardization: 10 o Assigned Numbers Internet Engineering Task Force [Page 17] INTERNET-DRAFT INTRODUCTION March 6, 1991 11 This document lists the assigned values of the parameters 12 used in the various protocols. For example, IP protocol 13 codes, TCP port numbers, Telnet Option Codes, ARP hardware 14 types, and Terminal Type names. 15 o Official Protocols 16 This document lists the protocols and describes any known 17 problems and ongoing experiments. 18 o Host Requirements 19 This pair of documents reviews the specifications that apply 20 to hosts and supplies guidance and clarification for any 21 ambiguities. Note that these requirements also apply to 22 routers, except where otherwise specified in this memo. 23 o Link Layer Requirements (proposed document) * 24 This document reviews the specifications that apply to the * 25 use of the Link Layer by routers and other IP entities. * 26 o Router Requirements (formerly Gateway Requirements) 27 This memo. 28 Note that these documents are revised and updated at different 29 times; in case of differences between these documents, the most 30 recent must prevail. 31 Reference [INTRO:6] describes several procedures for obtaining 32 Internet protocol documents. 0 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. 0 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 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 Internet Engineering Task Force [Page 18] INTERNET-DRAFT INTRODUCTION March 6, 1991 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. 0 1.3.2 Robustness Principle 1 At every layer of the protocols, there is a general rule (from 2 [INTERNET:1] by Jon Postel) whose application can lead to 3 enormous benefits in robustness and interoperability: 4 "Be liberal in what you accept, and 5 conservative in what you send" 6 Software should be written to deal with every conceivable 7 error, no matter how unlikely; sooner or later a packet will 8 come in with that particular combination of errors and 9 attributes, and unless the software is prepared, chaos can 10 ensue. In general, it is best to assume that the network is 11 filled with malevolent entities that will send in packets 12 designed to have the worst possible effect. This assumption 13 will lead to suitably protective design, although the most 14 serious problems in the Internet have been caused by 15 unenvisaged mechanisms triggered by low-probability events; 16 mere human malice would never have taken so devious a course! 17 EDITOR'S COMMENTS: 18 "unenvisaged mechanisms": bad wording; Deering suggests 19 "unanticipated mechanisms" 20 Adaptability to change must be designed into all levels of 21 router software. As a simple example, consider a protocol 22 specification that contains an enumeration of values for a 23 particular header field -- e.g., a type field, a port number, Internet Engineering Task Force [Page 19] INTERNET-DRAFT INTRODUCTION March 6, 1991 24 or an error code; this enumeration must be assumed to be 25 incomplete. If the protocol specification defines four 26 possible error codes, the software must not break when a fifth 27 code shows up. An undefined code might be logged (see below), 28 but it must not cause a failure. 29 The second part of the principle is almost as important: 30 software on hosts or other routers may contain deficiencies 31 that make it unwise to exploit legal but obscure protocol 32 features. It is unwise to stray far from the obvious and 33 simple, lest untoward effects result elsewhere. A corollary of 34 this is "watch out for misbehaving hosts"; router software 35 should be prepared to survive in the presence of misbehaving 36 hosts. An important function of routers in the Internet is to 37 limit the amount of disruption such hosts can inflict on the 38 shared communication facility. 0 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 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 [INTRO:3]); and 24 o allow the logging of a great variety of events to be 25 selectively enabled. For example, it might useful to be Internet Engineering Task Force [Page 20] INTERNET-DRAFT INTRODUCTION March 6, 1991 26 able to "log everything" or to "log everything for host 27 X". 28 This topic is further discussed in [OPER:2]. | 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. 0 1.3.4 Configuration 1 Perhaps in the ideal world, routers would be easy to configure, 2 and 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, 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 often have to misconfigure 28 the correct systems. This problem will correct itself 29 gradually as the faulty systems are retired, but cannot be 30 ignored by vendors. Internet Engineering Task Force [Page 21] INTERNET-DRAFT INTRODUCTION March 6, 1991 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 mis-configuration 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. 0 1.4 Acknowledgments 1 TBD Internet Engineering Task Force [Page 22] INTERNET-DRAFT ARCHITECTURE March 6, 1991 02. INTERNET ARCHITECTURE 1 SOURCE: 2 Chapter 2 source: hacked up RFC-1009 andRFC-1122, contributor: 3 Philip Almquist 4 General background and discussion on the Internet architecture and | 5 supporting protocol suite can be found in the DDN Protocol Handbook | 6 [ARCH:1]; for background see for example [ARCH:2], [ARCH:3], and | 7 [ARCH:4]. The Internet archtecture and protocols are also covered in | 8 an ever-growing number of textbooks, such as[ARCH:5] and[ARCH:6] | 9 | 0 2.1 Internet Protocols | 0 2.1.1 Introduction | 1 The Internet system consists of a number of interconnected | 2 packet networks supporting communication among host computers | 3 using the Internet protocols. These protocols include the | 4 Internet Protocol (IP), the Internet Control Message Protocol | 5 (ICMP), the Internet Group Management Protocol (IGMP), and a | 6 variety transport and application protocols that depend upon | 7 them. As was described in Section [1.2], the Internet | 8 Activities Board periodically releases an "Official Protocols" | 9 memo listing all of the Internet protocols. | 10 All Internet protocols use IP as the basic data transport | 11 mechanism. IP is a datagram, or connectionless, internetwork | 12 service and includes provision for addressing, type-of-service | 13 specification, fragmentation and reassembly, and security | 14 information. ICMP and IGMP are considered integral parts of | 15 IP, although they are architecturally layered upon IP. ICMP | 16 provides error reporting, flow control and first-hop router | 17 redirection. IGMP provides the mechanisms by which hosts (and | 18 routers) can join and leave IP multicast groups. | 19 Reliable data delivery is provided in the Internet protocol | 20 suite by Transport Layer protocols such as the Transmission | 21 Control Protocol (TCP), which provides end-end retransmission, | 22 resequencing and connection control. Transport Layer | 23 connectionless service is provided by the User Datagram | 24 Protocol (UDP). | Internet Engineering Task Force [Page 23] INTERNET-DRAFT ARCHITECTURE March 6, 1991 0 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 [RFC-1011]: | 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:7]. 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 [RFC- | 27 1011] and many private user protocols. | 28 Support protocols, used for host name mapping, booting, and | 29 management, include SNMP, BOOTP, TFTP, the Domain Name System | 30 (DNS) protocol, and a variety of routing protocols. | 31 Many Application Layer protocols use either the Telnet protocol | 32 or the OSI ASN.1 basic encoding rules to perform the function | 33 of OSI's Presentation Layer. | 34 Application Layer protocols are discussed in chapters 7, 8, and | 35 9 of this memo. | Internet Engineering Task Force [Page 24] INTERNET-DRAFT ARCHITECTURE March 6, 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 that | 48 provides end-to-end reliability, resequencing, and flow | 49 control. UDP is a connectionless ("datagram") transport | 50 service. Other transport protocols have been developed by the | 51 research community, and the set of official Internet transport | 52 protocols may be expanded in the future. | 53 Transport layer protocols are discussed in Chapter [6]. | 54 o Internet Layer | 55 All Internet transport protocols use the Internet Protocol | 56 (IP) to carry data from source host to destination host. | 57 IP is a connectionless or datagram internetwork service, | 58 providing no end-to-end delivery guarantees. Thus, IP | 59 datagrams may arrive at the destination host damaged, | 60 duplicated, out of order, or not at all. The layers above | 61 IP are responsible for reliable delivery service when it | 62 is required. The IP protocol includes provision for | 63 addressing, type-of-service specification, fragmentation | 64 and reassembly, and security information. | 65 The datagram or connectionless nature of the IP protocol | 66 is a fundamental and characteristic feature of the | 67 Internet architecture. Internet IP was the model for the | 68 OSI Connectionless Network Protocol [INTRO:12]. | 69 ICMP is a control protocol that is considered to be an | 70 integral part of IP, although it is architecturally | 71 layered upon IP, i.e., it uses IP to carry its data end- | 72 to-end just as a transport protocol like TCP or UDP does. | 73 ICMP provides error reporting, congestion reporting, and | Internet Engineering Task Force [Page 25] INTERNET-DRAFT ARCHITECTURE March 6, 1991 74 first-hop router redirection. | 75 IGMP is an Internet layer protocol used for establishing | 76 dynamic host groups for IP multicasting. | 77 The Internet layer protocols IP, ICMP, and IGMP are | 78 discussed in Chapter [4]. | 79 o Link Layer | 80 To communicate on its directly-connected network, a host | 81 must implement the communication protocol used to | 82 interface to that network. We call this a Link Layer or | 83 media-access layer protocol. Some older Internet | 84 documents refer to this layer as the "Network Layer", but | 85 it is not the same as the "Network Layer" in the OSI | 86 Reference Model. | 87 This layer contains everything "below" the Internet Layer. | 88 However, protocols included in what the OSI Reference | 89 Model would call the "Link Layer" and the "Physical Layer" | 90 are generally outside the scope of Internet | 91 standardization; the Internet (intentionally) uses | 92 existing standards whenever possible. Thus, Internet Link | 93 Layer standards usually address only address resolution | 94 and rules for transmitting IP packets over specific Link | 95 Layer protocols. Internet Link Layer standards are | 96 discussed in Chapter [3]. | 0 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 | Internet Engineering Task Force [Page 26] INTERNET-DRAFT ARCHITECTURE March 6, 1991 14 buss, ring, or star topologies. In general, a LAN will cover | 15 a 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 a physical | 33 interface and (at least) one IP address on each of the connected | 34 networks. Forwarding an IP datagram generally requires the router | 35 to choose the address of the next-hop router or (for the final | 36 hop) the destination host. This choice, called "routing", depends | 37 upon a routing data-base within the router. This routing data- | 38 base should be maintained dynamically to reflect the current | 39 topology of the Internet system; a router normally accomplishes | 40 this by participating in distributed routing and reachability | 41 algorithms with other routers. Routers provide datagram transport | 42 only, and they seek to minimize the state information necessary to | 43 sustain this service in the interest of routing flexibility and | 44 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 27] INTERNET-DRAFT ARCHITECTURE March 6, 1991 0 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 data-base. 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 28] INTERNET-DRAFT ARCHITECTURE March 6, 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 contributor: Cathy Wittbrodt * 45 Relationship to HRRFC: none * 46 CONTRIBUTOR'S COMMENTS: * 47 This section is still really centered around the long haul * 48 backbone networks. It needs to be rewritten to deal more * 49 with the needs of the campus LANS... * 50 A router vendor will have many choices on power, complexity, and * 51 features for a particular router product. It may be helpful to * 52 observe that the Internet system is neither homogeneous nor * 53 fully-connected. For reasons of technology and geography, it is * 54 growing into a global-interconnect system plus a "fringe" of LANs * 55 around the "edge". More and more these fringe LANs are becoming * 56 richly interconnected, thus making them less out on the fringe and * 57 a more demanding on router requirements. * 58 o The global-interconnect system is comprised of a number of * 59 wide-area networks to which are attached routers of several * 60 ASs; there are relatively few hosts connected directly to it. * 61 This global system includes networks such as the NSFNET, * 62 ESnet, and NSN "backbones", as well as scores of campus and * 63 regional networks. * 64 o Most hosts are connected to LANs, and many organizations have * 65 clusters of LANs interconnected by local routers. Each such * 66 cluster is connected by routers at one or more points into * 67 the global-interconnect system. If it is connected at only * 68 one point, a LAN is known as a "stub" network. * 69 Routers in the global-interconnect system generally require: * 70 o Advanced routing and forwarding algorithms * Internet Engineering Task Force [Page 29] INTERNET-DRAFT ARCHITECTURE March 6, 1991 71 These routers need routing algorithms which are highly * 72 dynamic and also offer type-of-service routing. Congestion * 73 is still not a completely resolved issue (see Section * 74 [5.3.6]). Improvements to the current situation will be * 75 implemented soon, as the research community is actively * 76 working on these issues. * 77 o High availability * 78 These routers need to be highly reliable, providing 24 hour a * 79 day, 7 days a week service. In case of failure, they must * 80 recover quickly. It is important to realize that Internet * 81 routers normally operate in an unattended mode, but that * 82 equipment and software faults can have a wide-spread * 83 (sometimes global) effect. In any environment, a router must * 84 be highly robust and able to operate, possibly in a degraded * 85 state, under conditions of extreme congestion or failure of * 86 network resources. * 87 o Advanced O&M features * 88 These routers will typically be operated remotely from a * 89 centralized monitoring center. In their interconnect role, * 90 they will need to provide sophisticated means for monitoring * 91 and measuring traffic and other events and for diagnosing * 92 faults. * 93 o High performance * 94 Although long-haul lines in the Internet today are most * 95 frequently 56 Kbps and DS1 lines (1.5 Mbps), DS3 lines will * 96 become increasingly important, and even higher speeds are * 97 likely in the future. Full-duplex operation is provided at * 98 any of these speeds. * 99 Routers used in the LAN fringe (e.g., campus networks) * 100 requirements depend greatly on the demands of the local networks. * 101 These may be high or medium-performance devices, probably * 102 competitively procured from several different vendors and operated * 103 by an internal organization (e.g., a campus computing center). * 104 The design of these routers should emphasize low average delay and * 105 good burst performance, together with delay and type-of-service * 106 sensitive resource management. In this environment, there will be * 107 less formal O&M, but it will not be less important. There will be * 108 more need for inter-operation with routers of other vendors. This * 109 inter-operation will become essential, because the routing * 110 mechanism will need to be very flexible. The need for the routing * 111 mechanism to be highly dynamic will become more important as * Internet Engineering Task Force [Page 30] INTERNET-DRAFT ARCHITECTURE March 6, 1991 112 networks become more complex and interconnected. Users will * 113 demand more out of their local connections because of the speed of * 114 the global interconnects. * 115 Even though the Internet system is not fully-interconnected, many * 116 parts of the system do need to have redundant connectivity. A * 117 rich connectivity allows reliable service despite failures of * 118 communication lines and routers, and it can also improve service * 119 by shortening Internet paths and by providing additional capacity. * 120 The engineering tradeoff between cost and reliability must be made * 121 for each component of the Internet system. * 0 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. | 0 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 data-bases 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. | 0 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. | Internet Engineering Task Force [Page 31] INTERNET-DRAFT ARCHITECTURE March 6, 1991 4 Symbolically: | 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 two-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 | 26 must not be visible outside 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 The bit positions containing this extended network number are | 35 indicated by a 32-bit mask called the "subnet mask"; it is | 36 recommended but not required that the bits be | 37 contiguous and fall between the and the | 38 fields. No subnet should be assigned the value | 39 zero or -1 (all one bits). | 40 Although the inventors of the subnet mechanism probably | 41 expected that each piece of an organization's network would | 42 have only a single subnet number, in practice it has often | 43 proven necessary or useful to have several subnets share a | Internet Engineering Task Force [Page 32] INTERNET-DRAFT ARCHITECTURE March 6, 1991 44 single physical cable. This is discussed further in Section | 45 [2.4.4]. | 46 Flexible use of the available address space will be | 47 increasingly important in coping with the anticipated growth of | 48 the Internet. Thus, we allow a particular subnetted network to | 49 use more than one subnet mask. Several campuses with very | 50 large LAN configurations are also creating nested hierarchies | 51 of subnets, sub-subnets, etc. | 52 There are special considerations for the router when a | 53 connected network provides a broadcast or multicast capability; | 54 these will be discussed later. | 0 2.4.3 IP Multicasting | 1 TBD | 0 2.4.4 Networks, Subnets, and Unnumbered Lines | 1 | 2 | 0 2.4.5 Interfaces | 1 | 0 2.4.6 Notable Oddities | 0 2.4.6.1 Half-Routers | 0 2.4.6.2 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: | 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 | Internet Engineering Task Force [Page 33] INTERNET-DRAFT ARCHITECTURE March 6, 1991 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. | 0 2.4.6.3 Transparent Routers | 1 There are two basic models for interconnecting local-area | 2 networks and wide-area (or long-haul) networks in the | 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 | Internet Engineering Task Force [Page 34] INTERNET-DRAFT ARCHITECTURE March 6, 1991 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. | 0 2.5 Architectural Assumptions | 1 SOURCE: | 2 Section 2.2 source: RFC-1122 section 1.1.2, contributor: | 3 Philip Almquist | 4 The current Internet architecture is based on a set of | 5 assumptions about the communication system. The assumptions | 6 most relevant to routers are as follows: | Internet Engineering Task Force [Page 35] INTERNET-DRAFT ARCHITECTURE March 6, 1991 7 o The Internet is a network of networks. | 8 Each host is directly connected to some particular | 9 network(s); its connection to the Internet is only | 10 conceptual. Two hosts on the same network communicate | 11 with each other using the same set of protocols that they | 12 would use to communicate with hosts on distant networks. | 13 o Routers don't keep connection state information. | 14 To improve robustness of the communication system, routers | 15 are designed to be stateless, forwarding each IP packet | 16 independently of other packets. As a result, redundant | 17 paths can be exploited to provide robust service in spite | 18 of failures of intervening routers and networks. | 19 All state information required for end-to-end flow control | 20 and reliability is implemented in the hosts, in the | 21 transport layer or in application programs. All | 22 connection control information is thus co-located with the | 23 end points of the communication, so it will be lost only | 24 if an end point fails. Routers effect flow control only | 25 indirectly, by dropping packets or increasing network | 26 delay. | 27 o Routing complexity should be in the routers. | 28 Routing is a complex and difficult problem, and ought to | 29 be performed by the routers, not the hosts. An important | 30 objective is to insulate host software from changes caused | 31 by the inevitable evolution of the Internet routing | 32 architecture. | 33 o The System must tolerate wide network variation. | 34 A basic objective of the Internet design is to tolerate a | 35 wide range of network characteristics -- e.g., bandwidth, | 36 delay, packet loss, packet reordering, and maximum packet | 37 size. Another objective is robustness against failure of | 38 individual networks, routers, and hosts, using whatever | 39 bandwidth is still available. Finally, the goal is full | 40 "open system interconnection": an Internet host must be | 41 able to interoperate robustly and effectively with any | 42 other Internet host, across diverse Internet paths. | 43 Sometimes host implementors have designed for less | 44 ambitious goals. For example, the LAN environment is | 45 typically much more benign than the Internet as a whole; | Internet Engineering Task Force [Page 36] INTERNET-DRAFT ARCHITECTURE March 6, 1991 46 LANs have low packet loss and delay and do not reorder | 47 packets. Some vendors have fielded host implementations | 48 that are adequate for a simple LAN environment, but work | 49 badly for general interoperation. The vendor justifies | 50 such a product as being economical within the restricted | 51 LAN market. However, isolated LANs seldom stay isolated | 52 for long; they are soon gatewayed to each other, to | 53 organization-wide internets, and eventually to the global | 54 Internet system. In the end, neither the customer nor the | 55 vendor is served by incomplete or substandard routers. | 56 The requirements spelled out in this document are designed | 57 for a full-function router. It is intended that fully | 58 compliant routers will be useable in almost any part of | 59 the Internet. | 60 CONTRIBUTOR'S COMMENTS: | 61 Need to reread and cite Dave Clark's Sigcomm '88 paper | 62 (CLA88) | Internet Engineering Task Force [Page 37] INTERNET-DRAFT LINK LAYER March 6, 1991 03. LINK LAYER 1 SOURCE: 2 Chapter 3 source: new text, contributor: Philip Almquist. 3 Relationship to HRRFC: None 4 Routers follow the link layer standards described in [LINK:1]. The 5 requirements of that document are incorporated by reference into this 6 document. 7 EDITOR'S COMMENTS: 8 There seem to be a few differences between the link layer 9 requirements for hosts and routers. For example, a router which 10 implements dynamic routing protocols has to be able to tell if 11 its interfaces are broken, in order to avoid advertising black 12 hole routes. A host on the other hand (at least one which is 13 singly homed) can do little with such knowledge other than 14 perhaps make it a little easier for the system manager to 15 diagnose the problem. It's unclear at this juncture whether 16 such differences should be documented here (and in the Host 17 Requirements) or in [LINK:1]. 18 MTU is required to be configurable on a per-(logical)-interface | 19 basis. I'm not sure if that belongs here or in [LINK:1]. | 20 Topics which definitely belong in the Link Layer document and | 21 should not be forgotten when we get to it include: trailers, | 22 proxy ARP, ... | 0 3.1 Requirements Summary 1 TBD Internet Engineering Task Force [Page 38] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 04. INTERNET LAYER -- PROTOCOLS 0 4.1 INTRODUCTION 0 4.2 INTERNET PROTOCOL -- IP 0 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]). 0 4.2.2 PROTOCOL WALK-THROUGH 1 SOURCE: 2 Sections 4.2.2.[2,3,4,5,8,9] source: new text, 3 contributor: Almquist 4 Relationship to HRRFC: most topics overlap RFC-1122. No 5 known contradictions; whether some of these could be 6 replaced by references to RFC-1122 should be determined. 0 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 contributor: Steve Senum. 4 Relationship to HRRFC: identical text, except for 5 deletion of host-specific text. No technical changes. 6 In datagrams received by the router itself, the IP layer | 7 MUST each interpret those IP options that it understands and | 8 preserve the rest unchanged for use by higher layer | 9 protocols. Unrecognized IP options in forwarded packets | 10 MUST be passed through unchanged. 11 Higher layer protocols may require the ability to set IP 12 options in datagrams they send or examine IP options in 13 datagrams they receive. Later sections of this document 14 discuss specific IP option support required by higher layer 15 protocols. 16 CONTRIBUTOR'S COMMENTS: 17 Note: Should the reference to TCP and UDP be deleted? 18 EDITOR'S COMMENTS: Internet Engineering Task Force [Page 39] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 19 Should we replace all references to handling of IP 20 options in packets received by the router with a 21 pointer to RFC-1122? This section would retain 22 information about IP option processing during 23 forwarding. I've gotten some comments so far which say 24 "yes". 25 Some argument could be made that this document should 26 retain handling of options on received ICMP packets; 27 I'm open to comments on this. 28 Chapter 6 needs to talk about IP option handling by 29 transport protocols. 30 DISCUSSION: 31 Passing all received IP options to the transport layer 32 is a deliberate "violation of strict layering" that is 33 designed to ease the introduction of new transport- 34 relevant IP options in the future. Each layer must 35 pick out any options that are relevant to its own 36 processing and ignore the rest. For this purpose, 37 every IP option except NOOP and END-OF-LIST will 38 include a specification of its own length. 39 This document does not define the order in which a 40 receiver must process multiple options in the same IP 41 header. Hosts and routers originating datagrams 42 containing multiple options must be aware that this 43 introduces an ambiguity in the meaning of certain 44 options when combined with a source-route option. 45 Several options, such as Record Route and Timestamp, | 46 contain "slots" into which a router inserts its address | 47 when forwarding the packet. However, each such option | 48 has a finite number of slots, and therefore a router | 49 may find that there is not free slot into which it can | 50 insert its address. No requirement listed below should | 51 be construed as requiring a router to insert its | 52 address into an option that has no remaining slot to | 53 insert it into. Section [5.2.5] discusses how a router | 54 must choose which of its addresses to insert into an | 55 option. | 56 EDITOR'S COMMENTS: | 57 Is the second discussion item still true? I know we | 58 have come with rules covering several ambiguities | 59 (multiple source routes, source route + record route, | 60 source route + timestamp). Are there others? | Internet Engineering Task Force [Page 40] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 61 Here are the requirements for specific IP options: 62 (a) Security Option 63 Some environments require the Security option in every 64 packet; such a requirement is outside the scope of this 65 document and the IP standard specification. Note, 66 however, that the security options described in RFC-791 67 and RFC-1038 are obsolete. Routers SHOULD IMPLEMENT | 68 support for the revised security option described in | 69 [INTERNET:5]. 70 (b) Stream Identifier Option 71 This option is obsolete; it SHOULD NOT ever be present | 72 in datagrams originated by the router, and MUST be | 73 ignored in datagrams received by the router. If the | 74 Stream Identifier option is present in a packet | 75 forwarded by the router, the option MUST be ignored and | 76 passed through unchanged. 77 (c) Source Route Options 78 A router MUST implement support for source route 79 options in forwarded packets. As described in Section 80 [????], a router MAY implement a policy mechanism 81 which, when enabled, causes all source-routed packets 82 to be discarded. However, such an option MUST NOT be | 83 enabled by default. | 84 DISCUSSION: 85 The ability to source route datagrams through the 86 Internet is important to various network 87 diagnostic tools. However, some people believe 88 that security problems can result from the use of 89 source route options. 90 A router MUST be able to act as the final destination | 91 of a source route. If a router receives a packet | 92 containing a completed source route (i.e., the pointer | 93 points beyond the last field and the destination | 94 address in the IP header addresses the router), the | 95 packet has reached its final destination; the option as | 96 received (the recorded route) MUST be passed up to the | 97 transport layer (or to ICMP message processing). | 98 In order to respond correctly to source-routed | 99 datagrams it receives, a router MUST provide a means | Internet Engineering Task Force [Page 41] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 100 whereby transport protocols and applications can | 101 reverse the source route in a received datagram and | 102 insert the reversed source route into datagrams they | 103 originate (see Section 4 of[INTRO:2] for details). | 104 As described in Chapter 9, certain applications may | 105 require that the user be able to enter a source route. | 106 EDITOR'S COMMENTS: | 107 Later sections of the document should clarify | 108 whether, for each application or transport | 109 protocol, source routes should be used in | 110 constructing replies to source-routed messages. | 111 When a source route option is created, it MUST be | 112 correctly formed even if the recorded route included | 113 the source host (see case (B) in the discussion below). | 114 A router MUST NOT originate a datagram containing 115 multiple source route options. What a router should do 116 if asked to forward a packet containing multiple source 117 route options is described in Section [5.2.4.1]. 118 CONTRIBUTOR'S COMMENTS: 119 There is also a section in RFC-1122 (ref. section 120 3.3.5) on source route forwarding, but I do not 121 think it is needed in the router requirements RFC. 122 DISCUSSION: 123 Suppose a source routed datagram is to be routed 124 from source S to destination D via routers G1, G2, 125 ... Gn. Source S constructs a datagram with G1's | 126 IP address as its destination address, and a | 127 source route option to get the datagram the rest | 128 of the way to its destination. However, there is 129 an ambiguity in the specification over whether the 130 source route option in a datagram sent out by S 131 should be (A) or (B): 132 (A): {>>G2, G3, ... Gn, D} <--- CORRECT 133 (B): {S, >>G2, G3, ... Gn, D} <---- WRONG 134 (where >> represents the pointer). If (A) is 135 sent, the datagram received at D will contain the 136 option: {G1, G2, ... Gn >>}, with S and D as the 137 IP source and destination addresses. If (B) were 138 sent, the datagram received at D would again Internet Engineering Task Force [Page 42] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 139 contain S and D as the same IP source and 140 destination addresses, but the option would be: 141 {S, G1, ...Gn >>}; i.e., the originating host 142 would be the first hop in the route. 143 (d) Record Route Option 144 Routers MUST support the Record Route option in 145 forwarded packets, and MAY support it in datagrams 146 originated by the router. 147 A router MAY provide a configuration option which, if 148 enabled, will cause the router to ignore (i.e. pass 149 through unchanged) Record Route options in forwarded 150 packets. If provided, such an option MUST default to 151 off. This option does not affect the processing of | 152 Record Route options in datagrams received by the | 153 router itself (in particular, Record Route options in | 154 ICMP echo requests will still be processed in | 155 accordance with Section [4.3.3.6]). | 156 DISCUSSION: | 157 There are apparently a few people who believe that | 158 Record Route is a security problem because it | 159 discloses information about the topology of the | 160 network. | 161 (e) Timestamp Option 162 Routers MUST support the timestamp option in forwarded 163 packets, and MAY support it in datagrams originated by 164 the router. The following rules apply: 165 o When originating a datagram containing a Timestamp | 166 Option, a router MUST record a timestamp in the | 167 option if its Internet address fields are not | 168 pre-specified or if its first pre-specified | 169 address is the router's interface address. | 170 o If the router itself receives a datagram | 171 containing a Timestamp Option, the router MUST | 172 insert the current timestamp into the Timestamp | 173 Option (if there is space in the option to do so) | 174 before passing the option to the transport layer | 175 or to ICMP for processing. | 176 o A timestamp value MUST follow the rules given in | 177 Section [3.2.2.8] of [INTRO:2]. | Internet Engineering Task Force [Page 43] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 178 If the flags field = 3 (timestamp and prespecified | 179 address), the router MUST add its timestamp if the next | 180 prespecified address matches any of the router's IP | 181 addresses. It is not necessary that the prespecified | 182 address be either the address of the interface on which | 183 the packet arrived or the address of the interface over | 184 which it will be sent. 185 IMPLEMENTATION: 186 To maximize the utility of the timestamps contained in 187 the timestamp option, it is suggested that the 188 timestamp inserted be, as nearly as practical, the time 189 at which the packet arrived at the router. For | 190 datagrams originated by the router, the timestamp | 191 inserted should be, as nearly as practical, the time at | 192 which the datagram was passed to the network layer for | 193 transmission. | 194 A router MAY provide a configuration option which, if | 195 enabled, will cause the router to ignore (i.e. pass through | 196 unchanged) Timestamp options in forwarded datagrams when the | 197 flag word is set to zero (timestamps only) or one (timestamp | 198 and registering IP address). If provided, such an option | 199 MUST default to off. This option does not affect the | 200 processing of Timestamp options in datagrams received by the | 201 router itself (in particular, a router will insert | 202 timestamps into Timestamp options in received datagrams as | 203 described above, and Timestamp options in ICMP echo requests | 204 will still be processed in accordance with Section | 205 [4.3.3.6]). | 206 DISCUSSION: | 207 Like the Record Route option, the Timestamp option can | 208 reveal information about a network's topology. Some | 209 people consider this to be a security concern. | 0 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. Internet Engineering Task Force [Page 44] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 0 4.2.2.3 Type of Service: RFC-791 Section 3.1 1 The description of the IP Precedence field is superceded 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 | 4 forwarded. | 5 RFC-795, "Service Mappings", is obsolete and SHOULD NOT be 6 implemented. 0 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]. 0 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. 0 4.2.2.6 Fragmentation: RFC-791 Section 3.2 1 SOURCE: 2 Section 4.2.2.6 source: new text, contributor: Stev 3 Knowles 4 Fragmentation, as described in the IP RFC ([INTERNET:1]), 5 MUST be supported by a router. This allows for the 6 transmission of IP datagrams on a destination or next hop 7 network, when the next network's MTU is smaller than the 8 packet being sent. 9 DISCUSSION: | 10 Some people mistakenly believe that that a router which | 11 supports only a single type of network interface | Internet Engineering Task Force [Page 45] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 12 (Ethernet, for example) does not need to support | 13 fragmentation, since fragmentation is not required | 14 unless one of the connected networks has a smaller MTU | 15 than the rest. This view is erroneous because the MTU | 16 of any network is administratively settable (see | 17 [LINK:1] and Section [3.3.3] of [INTRO:2]). | 18 When a router fragments a packet, it SHOULD minimize the 19 number of fragments. When a router fragments a packet, it 20 MUST send the fragments in order. A fragmentation method | 21 which may generate one fragment which is significantly | 22 smaller than the other MAY cause the first fragment to be | 23 the small one. 24 DISCUSSION: 25 There are several common fragmentation techniques in 26 common use in the Internet. One involves splitting the 27 packet into chunks with the first being MTU sized, and 28 the others being approximately the same size, smaller 29 than the MTU. the reason for this is twofold. The 30 first packet in the logical sequence (even if it 31 arrives out of sequence) will be the effective MTU of 32 the current path between the hosts, and the following 33 packets are sized to hopefully minimize the further 34 fragmentation of the packet. Another technique is to 35 split the packet into MTU sized chunks, with the last 36 fragment being the only one smaller, as per RFC 791 37 (IP), page 26. 38 A common trick used by some implementations of TCP/IP 39 is to not send packet bigger than 576 bytes when 40 packets are traveling through a router. In general, 41 this allows the resulting packets to pass the rest of 42 the path without further fragmentation. This would, 43 though, create more of a load on the destination host, 44 since it would have a larger number of physical packets 45 to reassemble into one logical packet. It would also 46 not be efficient on networks where the MTU only changes 47 once, and stays much larger than 576 bytes (such as an 48 802.5 network with a MTU of 2048 or an Ethernet network 49 with an MTU of 1536). 50 One other fragmentation technique discussed was 51 splitting the packet into approximately equal sized 52 chunks, with the size being smaller than the 53 destination network's MTU. This is intended to 54 minimize the number of fragments that would result from 55 additional fragmentation further down the path. Internet Engineering Task Force [Page 46] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 56 In general, routers should try and create situations 57 that will generate the lowest number of fragments 58 possible. Work with slow machines leads us to believe 59 that if it is necessary to send small packets in a 60 fragmentation scheme, that sending the small packet 61 first maximizes the chance of a host with a slow 62 interface of receiving all the fragments. 63 EDITOR'S COMMENTS: 64 In Boulder it was suggested that "In general, this 65 allows..." be changed to "In most cases, this 66 allows...". I should do this if that sentence survives 67 Stev's rewrite. 68 Ditto for changing "...smaller than the destination 69 network's MTU" into "...smaller than the next hop 70 network's MTU". 0 4.2.2.7 Reassembly: RFC-791 Section 3.2 1 SOURCE: 2 Section 4.2.2.7 source: new text, contributor: Stev 3 Knowles 4 As specified in Section 3.3.2 of [INTRO:2], a router MUST 5 support reassembly of datagrams which it delivers to itself. 6 A router MUST NOT reassemble any datagram before forwarding 7 it. 8 DISCUSSION: 9 A few people have suggested that there might be some 10 topologies where reassembly of transit datagrams by 11 routers might improve performance. In general, 12 however, the fact that fragments may take different 13 paths to the destination precludes safe use of such a 14 feature. 15 Nothing in this section should be construed to control 16 or limit fragmentation or reassembly performed as a 17 link layer function by the router. 0 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. | Internet Engineering Task Force [Page 47] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 5 TTL processing of forwarded packets is discussed in Section 6 [5.3.1]. 0 4.2.2.9 Routing of Broadcasts: RFC-922 Section 6 1 This section is superceded by Section [5.3.5]. In 2 particular, all-subnets broadcasts (called "multi-subnet 3 broadcasts" in [INTERNET:3]) have been deprecated. 4 4.2.2.10 Addressing: RFC-791 Section 3.2 | 5 SOURCE: | 6 Section 4.2.2.10 source: RFC-1122 section 3.2.1.3, | 7 contributor: Philip Almquist | 8 Relationship to HRRFC: identical requirements | 9 Relationship to RFC-1009: identical requirements? | 10 There are now five classes of IP addresses: Class A through | 11 Class E. Class D addresses are used for IP multicasting | 12 [INTERNET:4], while Class E addresses are reserved for | 13 experimental use. | 14 A multicast (Class D) address is a 28-bit logical address that | 15 stands for a group of hosts, and may be either permanent or | 16 transient. Permanent multicast addresses are allocated by the | 17 Internet Assigned Number Authority [ASSNUM], while transient | 18 addresses may be allocated dynamically to transient groups. | 19 Group membership is determined dynamically using IGMP | 20 [INTERNET:4]. | 21 We now summarize the important special cases for Class A, B, | 22 and C IP addresses, using the following notation for an IP | 23 address: | 24 { , } | 25 or | 26 { , , } | 27 and the notation "-1" for a field that contains all 1 bits. | 28 This notation is not intended to imply that the 1-bits in an | 29 address mask need be contiguous. | 30 (a) { 0, 0 } | Internet Engineering Task Force [Page 48] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 31 This host on this network. MUST NOT be sent by routers (a | 32 host, but not a router, may use this as a source address | 33 as part of an initialization procedure by which the host | 34 learns its own IP address). | 35 See also Section 3.3.6 for a non-standard use of { 0, 0 }. | 36 (b) { 0, } | 37 Specified host on this network. It MUST NOT be sent by | 38 routers (a host, but not a router, may use this as a | 39 source address as part of an initialization procedure by | 40 which the host learns its own IP address). | 41 (c) { -1, -1 } | 42 Limited broadcast. It MUST NOT be used as a source | 43 address. | 44 A datagram with this destination address will be received | 45 by every host and router on the connected physical | 46 network, but will not be forwarded outside that network. | 47 (d) { , -1 } | 48 Directed broadcast to the specified network. It MUST NOT | 49 be used as a source address. | 50 (e) { , , -1 } | 51 Directed broadcast to the specified subnet. It MUST NOT | 52 be used as a source address. | 53 (f) { , -1, -1 } | 54 Directed broadcast to all subnets of the specified | 55 subnetted network. It MUST NOT be used as a source | 56 address. | 57 (g) { 127, } | 58 Internal host loopback address. Addresses of this form | 59 MUST NOT appear outside a host. | 60 The is administratively assigned so that its | 61 value will be unique in the entire world. | 62 IP addresses are not permitted to have the value 0 or -1 for | Internet Engineering Task Force [Page 49] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 63 any of the , , or | 64 fields (except in the special cases listed above). This | 65 implies that each of these fields will be at least two bits | 66 long. | 67 For further discussion of broadcast addresses, see Section | 68 3.3.6. | 69 A router must support the subnet extensions to IP. As a | 70 result, there will be an address mask of the form: | 71 { -1, -1, 0 } associated with each of the host's local IP | 72 addresses; see Sections 3.2.2.9 and 3.3.1.1. | 73 When a router originates any datagram, the IP source address | 74 MUST be one of its own IP addresses (but not a broadcast or | 75 multicast address). | 76 For most purposes, a datagram addressed to a broadcast or | 77 multicast destination is processed as if it had been addressed | 78 to one of the router's IP addresses; we use the term | 79 "specific-destination address" for the equivalent local IP | 80 address of the host. The specific-destination address is | 81 defined to be the destination address in the IP header unless | 82 the header contains a broadcast or multicast address, in which | 83 case the specific-destination is an IP address assigned to the | 84 physical interface on which the datagram arrived. | 85 A router MUST silently discard an incoming datagram containing | 86 an IP source address that is invalid by the rules of this | 87 section. This validation could be done in either the IP layer | 88 or by each protocol in the transport layer. | 89 DISCUSSION: | 90 A mis-addressed datagram might be caused by a link- layer | 91 broadcast of a unicast datagram or by another router or | 92 host that is confused or misconfigured. | 93 Implementers should be aware that applications depending | 94 upon the all-subnets directed broadcast address (f) may be | 95 unusable on some networks. All- subnets broadcast is not | 96 widely implemented in vendor routers at present, and even | 97 when it is implemented, a particular network | 98 administration may disable it in the router configuration. | 0 4.2.3 SPECIFIC ISSUES Internet Engineering Task Force [Page 50] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 0 4.2.3.1 IP Broadcast Addresses | 1 SOURCE: | 2 Section 4.2.3.1 source: new text, contributor: Philip | 3 Almquist. | 4 Relationship to HRRFC: takes a slightly stronger stance | 5 on deprecating zero-filled addresses. | 6 For historical reasons, there are a number of IP addresses | 7 (some standard and some not) which are used to indicate that | 8 an IP packet is an IP broadcast. A router | 9 (1) MUST treat as IP broadcasts packets addressed to | 10 255.255.255.255, net.255, net.subnet.255, and | 11 net.255.255 | 12 (2) SHOULD silently discard on receipt (ie, don't even | 13 deliver to applications in the router) any packet | 14 addressed to 0.0.0.0, net.0, net.subnet.0, or net.0.0; | 15 if these packets are not silently discarded, they MUST | 16 be treated as IP broadcasts. | 17 (3) SHOULD use the limited broadcast address | 18 (255.255.255.255) when originating an IP broadcast | 19 destined for a connected network or subnet (except when | 20 sending an ICMP Mask Reply, as discussed in Section | 21 [4.3.3.9]) | 22 (4) SHOULD NOT originate datagrams addressed to 0.0.0.0, | 23 net.0, net.subnet.0, or net.0.0 | 0 4.2.3.2 IP Multicasting | 1 SOURCE: | 2 Section 4.2.3.2 source: new text, contributor: Steve | 3 Deering. | 4 Relationship to HRRFC: identical for "host" functions | 5 but adds discussion of multicast router functions. | 6 An IP router SHOULD satisfy the Host Requirements with | 7 respect to IP multicasting, as specified in Section 3.3.7 of | 8 [INTRO:2]. That is, an IP router SHOULD support local IP | 9 multicasting on all connected networks for which a mapping | 10 from Class D IP adresses to link-layer addresses has been | 11 specified (see the various IP-over-xxx specifications), and | Internet Engineering Task Force [Page 51] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 12 on all connected point-to-point links. Support for local IP | 13 multicasting includes originating multicast datagrams, | 14 joining multicast groups and receiving multicast datagrams, | 15 and leaving multicast groups. This implies support for all | 16 of [INTERNET:4] except IGMP, which is OPTIONAL. | 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). | 26 Some router protocols may specifically require support | 27 for IP multicasting (e.g., OSPF [ROUTE:1]), or may | 28 recommend it (e.g., ICMP Router Discovery | 29 [INTERNET:13]). | 30 An IP router MAY support forwarding of IP multicast packets, | 31 based either on static multicast routes or on routes | 32 dynamically determined by a multicast routing protocol | 33 (e.g., DVMRP [ROUTE:10]). A router that forwards IP | 34 multicast packets is called a multicast router. | 35 An IP router MAY also perform the multicast router part of | 36 IGMP to discover the presence of multicast group members on | 37 its connected networks; if so, it SHOULD perform some sort | 38 of election procedure or protocol with its neighboring | 39 multicast routers, so that only one router on each physical | 40 network issues periodic Host Membership Queries. | 41 DISCUSSION: | 42 The election procedure, and the time constants | 43 associated with IGMP (such as the periodic query | 44 interval) are specified as part of a particular | 45 multicast routing protocol. | 46 Note that a multicast router may perform both the host | 47 part and the multicast router part of IGMP | 48 concurrently. | 0 4.2.3.3 Path MTU Discovery | 1 SOURCE: | 2 Section 4.2.3.3 source: new text mostly stolen from RFC | Internet Engineering Task Force [Page 52] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 3 1191, contributor: Yoni Malachi | 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:15] 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 Proposed Requirements Level: | 19 o Routers MUST implement the modified ICMP ``Destination | 20 Unreachable/Fragmentation needed and DF set'' message | 21 specified in [INTERNET:15] (Hosts forwarding source- | 22 routed datagrams are considered to be routers, in this | 23 respect). | 24 o Routers SHOULD use the scheme described in[INTERNET:15] | 25 to discover Path MTU values and to limit the sizes of | 26 IP packets originated by the router. | 27 CONTRIBUTOR'S COMMENTS: | 28 If the PMTU is derived from the routing protocol there | 29 might not be a need to use the technique describe here | 30 for router to router communication. On the other hand | 31 while we do not specify here routing protocols we might | 32 recommend in this section that router use the PMTU | 33 discovered by the technique of RFC 1191 as the MTU in | 34 the routing table for destination network for which the | 35 PMTU is found. This might require further involvement | 36 of the router in the protocol by snooping on "Datagram | 37 too big" ICMP forwarded by the router along the reverse | 38 path. | 0 4.3 INTERNET CONTROL MESSAGE PROTOCOL -- ICMP 1 SOURCE: 2 Section 4.3 source: RFC 1122 Section 3.2.2 and RFC 1009 Internet Engineering Task Force [Page 53] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 3 Section 2.2. contributor: Martin Gross 4 Relationship to HRRFC: Adds destination unreachable code 13 5 and deletes codes 8 and 9. Routers are authoritative 6 providers of netmasks by default, and never believe netmask 7 replies. 0 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]. Implementation of ICMP is REQUIRED. 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 Section 4.3.2 0 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 otherwise. 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 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. Internet Engineering Task Force [Page 54] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 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 ICMP error messages SHOULD be sent with normal (i.e., zero) TOS 22 bits. Any ICMP message (whether an ICMP error message or not) | 23 generated in response to a packet which contains an IP security | 24 option (as defined in [INTERNET:5]), SHOULD include in its IP | 25 header a security option identical to the one in the packet | 26 which provoked the response. | 27 EDITOR'S COMMENTS: 28 Is normal TOS always correct? 29 When, if ever, should ICMP error messages be source | 30 routed? | 31 Does there need to be text specifying which source address | 32 should be used for ICMP messages? I think this is | 33 currently addressed only for Echo Reply. As an example, | 34 Mike St. Johns asks whether Time Exceeded should use the | 35 address of the incoming interface if the packet is | 36 received with TTL 0 and the address of the output | 37 interface if the packt is received with TTL 1. | 38 An ICMP error message MUST NOT be sent as the result of 39 receiving: 40 o an ICMP error message, or 41 o a packet with a corrupted header checksum, or 42 o a packet with an incorrect version number, or 43 o a packet with an incorrect header length, or 44 o a packet destined to an IP broadcast or IP multicast 45 address, or 46 o a packet sent as a link-layer broadcast, or Internet Engineering Task Force [Page 55] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 47 o a packet whose source address has a network number of zero | 48 or is an invalid source address (as defined in Section | 49 [5.3.7]), or | 50 o any fragment of a datagram other then the first fragment | 51 (ie, a fragment for which the fragment offset in the IP | 52 header is nonzero). | 53 NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT 54 ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES. 55 DISCUSSION: 56 These rules aim to prevent the "broadcast storms" that 57 have resulted from routers or hosts returning ICMP error 58 messages in response to broadcast packets. For example, a 59 broadcast UDP segment to a non-existent port could trigger 60 a flood of ICMP Destination Unreachable datagrams from all 61 devices that do not have a client for that destination 62 port. On a large Ethernet, the resulting collisions can 63 render the network useless for a second or more. 64 Every packet that is broadcast on the connected network 65 should have a valid IP broadcast address as its IP 66 destination (see Section [5.3.4] and [INTRO:2]). However, 67 some devices violate this rule. To be certain to detect 68 broadcast packets, therefore, routers are required to 69 check for a link-layer broadcast as well as an IP-layer 70 broadcast address. 71 IMPLEMENTATION: 72 This requires that the link layer inform the IP layer when 73 a link-layer broadcast packet has been received; see 74 Section [????]. 75 As described in Section [4.3.3.3], a router must limit the rate 76 at which it sends ICMP Source Quench messages. A router MAY 77 also limit the rate at which it sends other sorts of ICMP error 78 messages (Destination Unreachable, Redirect, Time Exceeded, 79 Parameter Problem). If a router does limit the sending of ICMP 80 error messages, the limit SHOULD be settable as part of the 81 configuration of the router. How this limit is applied (e.g., 82 per router or per interface) is left to the implementor's 83 discretion. 84 DISCUSSION: 85 Two problems for a router sending ICMP error message are: 86 (1) the consumption of bandwidth on the reverse path, and Internet Engineering Task Force [Page 56] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 87 (2) the use of router resources (e.g., memory, CPU time) 88 To help solve these problems a router can limit the 89 frequency with which it generates ICMP Error messages. 90 This may be on the basis of a count (e.g., only send a 91 ICMP Error message for every N dropped packets overall or 92 per given source host), or on the basis of a timer (e.g., 93 send a Source Quench to a given source host or overall at 94 most once per T milliseconds). 95 EDITOR'S COMMENTS: | 96 Regarding the "at most once per T milliseconds" above, | 97 Frank Solensky suggests: | 98 it may be a better idea to limit the metric to some | 99 portion of the media's bandwidth: measuring the | 100 interval on the basis of time would cause a much | 101 greater portion of a slower media to be consumed by | 102 these messages than a faster one. (Then again, this | 103 wouldn't be completely fail-safe, since these | 104 messages may be routed back from a fast medium to a | 105 slow one, consuming a greater portion of bandwidth | 106 once it got to the slower one) | 107 CONTRIBUTOR'S COMMENTS: 108 The same discussion might be applied to other ICMP 109 messages like echo replies, and certain TCP 110 acknowledgments. 111 What would be a good default rate? 0 4.3.3 SPECIFIC ISSUES 0 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 for use in [INTERNET:8] and 10 [INTRO:2]: | 11 0 = net unreachable - generated by a router if a forwarding | Internet Engineering Task Force [Page 57] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 12 path (route) to the destination network is not | 13 available; 14 1 = host unreachable - generated if a router is unable to 15 forward a packet due to the destination host being 16 down; 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; 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 8 = source host isolated - generated by the source host to 39 inform the originator (on the same host) that it is 40 isolated; | 41 11 = network unreachable for type of service - generated by | 42 a router if a forwarding path (route) to the | 43 destination network with the requested or default TOS | 44 is not available; 45 12 = host unreachable for type of service - generated if a 46 router cannot forward a packet because its route(s) to 47 the destination do not match either the TOS requested 48 in the datagram or the default TOS (0). Internet Engineering Task Force [Page 58] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 49 The following additional code is hereby defined: 50 13 = communication administratively prohibited - generated 51 if a router cannot forward a packet due to 52 administrative filtering. 53 NOTE: RFC-1122 defined code 9 for communication with 54 destination network administratively prohibited and code 10 55 for communication with destination host administratively 56 prohibited. These codes were intended for use by end-to-end 57 encryption devices in the DoD. Routers SHOULD use the newly 58 defined code 13 if they administratively filter packets. 59 Routers MAY have a configuration option that causes code 13 60 messages not to be generated. When this option is enabled, 61 no ICMP error message is sent in response to a packet which 62 is dropped because its forwarding is administratively 63 prohibited. 64 EDITOR'S COMMENTS: 65 Code 13 is not yet official; I need to request an 66 official assignment from Jon. 67 Routers MUST use host unreachable or host unknown codes 68 whenever other hosts on the same destination network might 69 be reachable; otherwise, the source host may erroneously 70 conclude that all hosts on the network are unreachable, and 71 that may not be the case. 72 slightly modified the form of Destination Unreachable | 73 messages containing code 4 (Fragmentation needed and DF | 74 set). As was stated in Section [4.2.3.3], a router must use | 75 this modified form when originating code 4 Destination | 76 Unreachable messages. 0 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]. 6 Routers MUST be able to generate host redirect messages 7 (codes 1 and 3) specified in [INTERNET:8]. 8 DISCUSSION: Internet Engineering Task Force [Page 59] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 9 If the directly-connected network is not subnetted, a 10 router can normally generate a network Redirect which 11 applies to all hosts on a specified remote network. 12 Using a network rather than a host Redirect may 13 economize slightly on network traffic and on host 14 routing table storage. However, the savings are not 15 significant, and subnets create an ambiguity about the 16 subnet mask to be used to interpret a network Redirect. 17 In a general subnet environment, it is difficult to 18 specify precisely the cases in which network Redirects 19 can be used. Therefore, routers must send only host 20 (or host and type of service) Redirects. 21 EDITOR'S COMMENTS: 22 Do we need to say more about TOS redirects? 23 Do we need to say what a router does when it receives a 24 redirect (i.e., nothing)? 25 There was some discussion in Vancouver of the problems 26 of forwarding redirects. Unfortunately, my notes 27 contain only an indication that redirects containing 28 source routes should be dropped, a rule which might 29 make sense for hosts but not for routers. Did we make 30 a decision on this? 31 There was also some discussion in Vancouver about 32 allowing network redirects in cases where they are 33 safe. Could someone write up a description of how the 34 router can tell which cases are indeed safe? Related: 35 is the last paragraph of the previous section, which 36 describes when Host Unreachable must be used instead of 37 Network Unreachable, correct and complete? 0 4.3.3.3 Source Quench 1 A router SHOULD NOT originate Source Quench messages. * 2 A router which originates Source Quench messages MUST be * 3 prepared to limit the frequency with which it generates * 4 Source Quench messages. This MAY be on the basis of a count 5 (e.g., only send a Source Quench for every N dropped packets 6 overall or per given source host), or on the basis of a 7 timer (e.g., send a Source Quench to a given source host or 8 overall at most once per T milliseconds). The parameters 9 (e.g., N and T) MUST be settable as part of the 10 configuration of the router; furthermore, there should be 11 some configuration setting which disables (or enables) Internet Engineering Task Force [Page 60] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 12 sending Source Quenches. These configuration parameters 13 SHOULD be specifiable separately for each network interface. 14 DISCUSSION: 15 Research seems to suggest that Source Quench consumes * 16 network bandwidth but is an ineffective (and unfair) * 17 antidote to congestion. See, for example, [INTERNET:9] * 18 and [INTERNET:10]. * 19 A router itself may receive a Source Quench as the 20 result of sending a packet targeted to another router. 21 Such datagrams might be an EGP update, for example. A 22 mechanism has been proposed ([INTERNET:11], 23 [INTERNET:12]) to make the IP layer respond directly to 24 Source Quench by controlling the rate at which packets 25 are sent, however, this proposal is currently 26 experimental and not currently recommended. 0 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. 7 A router MUST generate a Time Exceeded message Code 1 8 (Reassembly Timeout) if it is unable to reassemble a 9 datagram addressed to the router. 0 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. Internet Engineering Task Force [Page 61] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 0 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. A router SHOULD have a configuration option | 9 which, if enabled, causes the router to silently ignore all | 10 ICMP echo requests; if provided, this option MUST default to | 11 allowing responses. | 12 DISCUSSION: 13 The neutral provision about responding to broadcast and 14 muticast Echo Requests results from the conclusions 15 reached in [INTRO:2]. 16 As stated in Section [10.3.3], a router must also implement 17 an application-layer interface for sending an Echo Request 18 and receiving an Echo Reply, for diagnostic purposes. 19 The IP source address in an ICMP Echo Reply MUST be the same 20 as the specific-destination address of the corresponding 21 ICMP Echo Request message. 22 EDITOR'S COMMENTS: 23 The previous paragraph is an example of a more general 24 problem: there is no clear definition of how to decide 25 the specific-destination address of a packet received 26 as an IP broadcast or IP multicast on an interface that 27 has multiple IP addresses. Anybody have any good ideas 28 about what we should say about this? 29 Data received in an ICMP Echo Request MUST be entirely 30 included in the resulting Echo Reply. 31 If a Record Route and/or Timestamp option is received in an 32 ICMP Echo Request, this option (these options) SHOULD be 33 updated to include the current router and included in the IP 34 header of the Echo Reply message, without "truncation". 35 Thus, the recorded route will be for the entire round trip. 36 If a Source Route option is received in an ICMP Echo 37 Request, the return route MUST be reversed and used as a 38 Source Route option for the Echo Reply message. Internet Engineering Task Force [Page 62] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 39 If a router implements an application-layer interface for 40 sending an ICMP Echo Request then all ICMP Echo Reply 41 messages MUST be passed to the ICMP user interface. 0 4.3.3.7 Information Request/Reply 1 A router SHOULD NOT implement these messages. 2 EDITOR'S COMMENTS: 3 In this section and the next, do we need to distinguish 4 in our requirements between client and server 5 implementations? 6 DISCUSSION: 7 The Information Request/Reply pair was intended to 8 support self-configuring systems such as diskless 9 workstations, to allow them to discover their IP 10 network numbers at boot time. However, these messages 11 are now obsolete. The RARP and BOOTP protocols provide 12 better mechanisms for a host to discover its own IP 13 address. 0 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 Internet Engineering Task Force [Page 63] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 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 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. 0 4.3.3.9 Address Mask Request/Reply 1 A router MUST implement support for receiving ICMP Address 2 Mask Request messages and responding with ICMP Address Mask 3 Reply messages. A router SHOULD have a configuration option | 4 for each logical interface specifying whether the router is | 5 allowed to answer Address Mask Requests for that interface. 6 A router MUST NOT respond to an Address Mask Request before 7 the router knows the correct address mask. Internet Engineering Task Force [Page 64] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 8 A router SHOULD examine all ICMP Mask Replies which it | 9 receives to determine whether the information it contains | 10 matches the the router's knowledge of the subnet mask. If | 11 the Mask Reply appears to be in error, the router SHOULD log | 12 the mask and the sender's IP address. A router MUST NOT use | 13 the contents of an ICMP Mask Reply to determine the correct | 14 subnet mask. | 15 When it initializes, the router MUST broadcast an Address | 16 Mask Reply for the mask on each logical interface, except | 17 that the replies MUST NOT be sent on: | 18 o any logical interface(s) for which the router is not | 19 allowed (because of administrative configuration) to | 20 respond to Address Mask Requests | 21 o any logical interface(s) which share the same IP | 22 network number and physical interface but have | 23 different subnet masks. The router SHOULD log this | 24 case (as an illegal subnet configuration). | 25 The net.-1.-1 form (on subnetted networks) or the net.-1 | 26 form (on non-subnetted networks) of the IP broadcast address | 27 MUST be used for broadcast Address Mask Replies. 28 DISCUSSION: 29 The ability to disable sending Address Mask Replies by 30 routers is required at a few sites which intentionally 31 lie to their hosts about the subnet mask. The need for 32 this is expected to go away as more and more hosts 33 become compliant with the Host Requirements standards. 34 The reason for both the second bullet above and the | 35 requirement about which IP broadcast address to use is | 36 to prevent problems when multiple IP networks or | 37 subnets are in use on the same physical network. 0 4.3.3.10 Router Advertisement and Solicitations 1 SOURCE: 2 Section 4.3.3.10 source: new text, contributor Steve | 3 Deering. | 4 Relationship to HRRFC: RFC-1122 predates the Router | 5 Discovery work | 6 CONTRIBUTOR'S COMMENTS: | 7 The IETF Router Discovery Working Group has specified | Internet Engineering Task Force [Page 65] INTERNET-DRAFT INTERNET LAYER: PROTOCOLS March 6, 1991 8 an ICMP extension to enable hosts attached to multicast | 9 or broadcast networks to discover the IP addresses of | 10 their neighboring routers. It is anticipated that this | 11 protocol extension will progess along the Internet | 12 Standards track; if so, this subsection will contain | 13 the routers' requirements vis a vis the router | 14 discovery protocol. | 15 An IP router MUST support the router part of the ICMP Router | 16 Discovery Protocol [INTERNET:13] on all connected networks | 17 on which the router supports either IP multicast or IP | 18 broadcast addressing. The implementation MUST include all | 19 of the configuration variables specified for routers, with | 20 the specified defaults. | 21 An IP router MUST also support the host part of the ICMP | 22 Router Discovery Protocol for operation while IP forwarding | 23 is disabled (i.e., when operating as a host). 0 4.4 INTERNET GROUP MANAGEMENT PROTOCOL -- IGMP 1 SOURCE: | 2 Section 4.4 source: new text, contributor Steve Deering. | 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 At this time, implementation of IGMP, either the host part or the | 10 multicast router part, is OPTIONAL; see Section [4.2.3.1] for more | 11 information. 0 4.5 REQUIREMENTS SUMMARY 1 TBD Internet Engineering Task Force [Page 66] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 05. INTERNET LAYER -- FORWARDING 1 SOURCE: 2 Chapter 5 source: new text, contributor: Philip Almquist. 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 whether TOS is 3 or 5 bits. 0 5.1 INTRODUCTION 1 This section describes the process of forwarding packets. 0 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], and [INTERNET:8]). 0 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 [????]) 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 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. Internet Engineering Task Force [Page 67] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 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 (5) The forwarder determines the next hop IP address for the 28 packet, usually by looking up the packet's destination in 29 the router's routing table. This procedure is described 30 in more detail in Section [5.2.4]. This procedure also 31 decides which network interface should be used to send to 32 packet. In the case of an IP multicast destination, it | 33 may identify more than one outgoing interface, in which | 34 case the remaining steps apply separately to a copy of the | 35 packet for each interface. 36 (6) The forwarder verifies that forwarding the packet is 37 permitted. The source and destination addresses should be 38 valid, as described in Section [5.3.7] and Section [5.3.4] 39 If the router supports administrative constraints on 40 forwarding, such as those described in Section [5.3.8], 41 those constraints must be satisfied. 42 (7) The router decrements the packet's TTL by at least one, as 43 described in Section [5.3.1]. 44 (8) The forwarder performs any IP option processing that could 45 not be completed in step (3). 46 (9) The forwarder performs any necessary IP fragmentation, as 47 described in Section [4.2.2.6]. 48 (10) The forwarder determines the link layer address of the 49 packet's next hop. The mechanisms for doing this are 50 link-layer dependent, and are discussed in [LINK:1]. 51 (11) The forwarder encapsulates the packet (or each of the 52 fragments thereof) in an appropriate link layer frame and 53 queues it for output on the appropriate interface. 54 (12) The forwarder sends an ICMP redirect if necessary, as 55 described in Section [4.3.3.2]. 56 It is not required that an implementation follow exactly the Internet Engineering Task Force [Page 68] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 57 algorithm given above. Much of the challenge of writing router 58 software is to maximize the rate at which the router can 59 forward packets while still achieving the same effect of the 60 above algorithm. Details of how to do that are beyond the 61 scope of this document, in part because they are heavily 62 dependent on the architecture of the router. Instead, we 63 merely point out the order dependencies among the steps: 64 (1) A router MUST verify the IP header, as described in 65 section [5.2.2], before performing any actions based on 66 the contents of the header. 67 (2) Processing of certain IP options requires that the router 68 insert its IP address into the option. As noted in 69 Section [5.2.5], the address inserted is required to be 70 the address of the logical interface on which the packet 71 is sent. Thus, processing of these options cannot be 72 completed until after the output interface is chosen. 73 Processing of these options cannot be completed until 74 after fragmentation in implementations that do a form of 75 load splitting that may send different fragments over 76 different paths. 77 (3) The router cannot check and decrement the TTL before 78 checking whether the packet should be delivered to the 79 router itself, for reasons mentioned in Section [4.2.2.8]. 80 (4) More generally, when a packet is delivered locally to the | 81 router, its IP header MUST NOT be modified in any way | 82 (except that a router may be required to insert a | 83 timestamp into any Timestamp options in the IP header). 84 Thus, before the router determines whether the packet is 85 to be delivered locally to the router, it cannot update 86 the IP header in any way that it is not prepared to undo. 87 CONTRIBUTOR'S COMMENTS: 88 We should note somewhere that an IP broadcast address may | 89 appear as the last address in a source route but an IP | 90 multicast address may not, and that neither is legal in | 91 the middle of a source route. Include explicit references | 92 to the relevant specs. 0 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 Internet Engineering Task Force [Page 69] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 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 first three 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 filed (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: * 27 It is desireable 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 desireable 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 desireable * 39 to check if a packet which fails these tests is in fact an * Internet Engineering Task Force [Page 70] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 40 IP version 5 datagram. IP version 5, a.k.a. ST-II, is * 41 described in [FORWARD:1]. * 42 In environments where reading invalid memory locations can 43 cause faults, the checksum routine might be implemented to 44 declare the checksum invalid if the IP header length 45 claims to be larger than the size of the packet. 46 Additionally, the router SHOULD verify that the packet length * 47 reported by the link layer is at least as large as the IP total * 48 length recorded in the packet's IP header. If it appears that * 49 the packet has been truncated, the packet MUST be silently * 50 discarded and the error SHOULD be logged. 51 DISCUSSION: | 52 Because any higher layer protocol which concerns itself | 53 with data corruption (except NFS :~) will detect | 54 truncation of the packet data when it reaches its final | 55 destination, it is not absolutely necessary for routers to | 56 perform the check suggested above in order to maintain | 57 protocol correctness. However, by making this check a | 58 router can simplify considerably the task of determining | 59 which hop in the path is truncating the packets. | 60 AUTHOR'S COMMENTS: * 61 Ideally this case would result in an ICMP error reply, but * 62 I don't think that there are any appropriate ones defined. * 63 Should there be a new ICMP message which means "your * 64 datagram was mangled in transit"? * 65 Finally, if the destination address in the IP header is not one * 66 of the addresses of the router, the router SHOULD verify that * 67 the packet does not contain a Strict Source and Record Route * 68 option. If a packet fails this test, the router SHOULD log the * 69 error and SHOULD respond with an ICMP Parameter Problem error * 70 with the pointer pointing at the offending packet's IP * 71 destination address. 72 DISCUSSION: | 73 This test probably really reveals a protocol error by the | 74 previous hop router, rather than by the host which | 75 originated the datagram. However, ICMP does not allow the | 76 router to choose to address the ICMP error datagram to the | 77 previous hop router rather than the source host. | Internet Engineering Task Force [Page 71] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 0 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 Regardless of the remaining rules, a packet is forwarded 9 (and not delivered locally) if it contains an unexpired 10 source route option. An unexpired source route option is 11 one whose pointer value does not point past the last entry 12 in the source route. 13 o The packet is delivered locally (and not considered for 14 forwarding) in the following cases: 15 - the packet's destination address exactly matches one 16 the router's IP addresses 17 - the packet's destination address is a limited 18 broadcast address 19 o The packet is passed to the forwarder AND delivered 20 locally in the following cases: 21 - the packet's destination address is an IP broadcast 22 address that addresses at least one of the router's 23 logical interfaces but does not address any of the 24 logical interfaces associated with the physical 25 interface on which the packet arrived 26 - the packet's destination is an IP multicast address | 27 and the router belongs to the destination multicast | 28 group on the interface on which the packet arrived. 29 o The packet is delivered locally if the packet's 30 destination address is an IP broadcast address (other than 31 a limited broadcast address) that addresses at least one 32 of the logical interfaces associated with the physical 33 interface on which the packet arrived. The packet is ALSO 34 passed to the forwarder unless the link on which the 35 packet arrived uses an IP encapsulation that does not 36 encapsulate broadcasts differently than unicasts (e.g. by 37 using different link layer destination addresses). Internet Engineering Task Force [Page 72] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 38 EDITOR'S COMMENTS: 39 I don't like the wording of the previous sentence, 40 but so far haven't been able to do better. Any 41 ideas? 42 The purpose of the sentence is to deal with a 43 directed broadcast to another net or subnet on the 44 same physical cable. Normally, this works as 45 expected: the sender sends the broadcast to the 46 router as a link layer unicast. The router notes 47 that it arrived as a unicast, and therefore must be 48 destined for a different logical net (or subnet) than 49 the sender sent it on. Therefore, the router can 50 safely send it as a link layer broadcast out the same 51 (physical) interface over which it arrived. However, 52 if the router can't tell whether the packet was 53 received as a link layer unicast, the sentence 54 ensures that the router does the safe but wrong thing 55 rather than the unsafe but right thing. 56 o The packet is passed to the forwarder in all other cases. 57 IMPLEMENTATION: 58 Some link layers (either because of the hardware or 59 because of special code in the drivers) can deliver to the 60 router copies of all link layer broadcasts and multicasts 61 it transmits. Use of this feature can simplify the 62 implementation of cases where a packet has to both be 63 passed to the forwarder and delivered locally, since 64 forwarding the packet will automatically cause the router 65 to receive a copy of the packet that it can then deliver 66 locally. 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 CONTRIBUTOR'S COMMENTS: 72 I would be much appreciative if some people would stare at 73 the above rules and make sure that directed broadcasts are 74 forwarded when they should be (and not forwarded when they 75 shouldn't be) when you have multiple subnets on a single 76 physical net, routers with multiple interfaces on the same 77 subnet, etc. 78 The first bullet of the rule doesn't properly allow for 79 the case where the router has to forward the packet to Internet Engineering Task Force [Page 73] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 80 another of its own interfaces. 81 These rules also don't really handle the case where the | 82 router is both the current and the next destination in a | 83 source route (we decided in Boulder that such a source | 84 route is legal). | 85 Most of the bullets (especially the third and fourth) need | 86 to provide a more intuitive explanation of the cases they | 87 cover. | 88 General wording needs to be added mentioning that packets | 89 which the above says are queued for forwarding get | 90 (silently) discarded if forwarding is disabled on the | 91 interface on which the packet arrived or on the router as | 92 a whole. This doesn't affect local delivery (except | 93 internal forwarding to addresses associated with other | 94 interfaces???). | 0 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 Internet Engineering Task Force [Page 74] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 20 destination address, except in source routed packets, 21 where it is the next address specified in the source route 0 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 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. 0 5.2.4.2 Local/Remote Decision 1 SOURCE: 2 Section 5.2.4.2 source: RFC-1122 section 3.3.1.1, 3 contributor: Philip Almquist. 4 To decide if the immediate destination is on a connected 5 network, the following algorithm MUST be used (see 6 [INTERNET:2]): 7 (a) The address mask (particular to a local IP address for 8 a multihomed host) is a 32-bit mask that selects the 9 network number and subnet number fields of the 10 corresponding IP address. 11 (b) If the IP destination address bits extracted by the 12 address mask match the IP source address bits extracted 13 by the same mask, then the destination is on the 14 corresponding connected network, and the packet is to 15 be transmitted directly to the destination host. 16 (c) If not, then the destination is accessible only through 17 a router. Selection of a router is described below (in 18 Section [????]). Internet Engineering Task Force [Page 75] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 19 A special-case destination address is handled as follows: 20 o For a limited broadcast or an IP multicast address, 21 simply pass the packet to the link layer for the 22 appropriate interface. 23 o For a (network or subnet) directed broadcast, the 24 packet can use the standard routing algorithms. 25 EDITOR'S COMMENTS: 26 This section is known to be broken in several ways. A 27 replacement for it is supposedly being written. Also, * 28 I think this probably the place to handle the case * 29 where the next hop address is a router-id (across an * 30 unnumbered link), since a router-id designates a * 31 directly reachable entity. * 0 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 A routing table may contain several types of routes. The 12 kinds of routes are listed here, in order of decreasing 13 preference: 14 (1) a host route is a route to a particular end system. 15 (2) a subnet route is a route to a particular subnet of a 16 network. 17 (3) a default subnet route is a default route to any subnet 18 of a particular net for which there are not explicit 19 subnet routes 20 (4) a net route is a route to a particular network 21 (5) a default route is default route to any network for * 22 which there are no explicit network or subnet routes * Internet Engineering Task Force [Page 76] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 23 The idea of the routing table lookup is to find most 24 explicit routes that match the immediate destination address 25 of the packet. The result is a set of candidate routes. 26 This set MUST NOT contain any default (type 5) routes if the 27 routing table contains subnet routes whose network part 28 matches the network part of the packet's immediate 29 destination address. 30 If the set is empty (ie, no routes were found), the packet 31 MUST be discarded and an appropriate ICMP error generated 32 (ICMP Bad Source Route if the immediate destination address 33 came from a source route option; otherwise, whichever of 34 ICMP Destination Host Unreachable or Destination Network 35 Unreachable is appropriate, as described in Section [????]). 36 Otherwise, the router deletes those routes from the set 37 which have inappropriate TOS values, as described in Section 38 [5.3.2]. If this leaves the set empty, the packet MUST be 39 discarded and an ICMP TOS Unreachable sent. 40 Otherwise, the router chooses from among the remaining 41 routes based on metrics and administrative preference, as 42 discussed in Section [????]. 0 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 * 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 should be an invariant 32 * 8 bit quantity which is one of the router's IP addresses. * 0 5.3 SPECIFIC ISSUES 0 5.3.1 Time to Live (TTL) 1 Time-to-Live 2 SOURCE: 3 Section 5.3.1 source: modified RFC-1009, contributor: John 4 Cavanaugh 5 Relationship to HRRFC: none 6 The Time-to-Live (TTL) field of the IP header is defined to be Internet Engineering Task Force [Page 77] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 7 a timer limiting the lifetime of a datagram. It is an 8-bit 8 field and the units are seconds. Each router (or other module) 9 that handles a packet must decrement the TTL by at least one, 10 even if the elapsed time was much less than a second. Since 11 this is very often the case, the TTL is effectively a hop count 12 limit on how far a datagram can propagate through the Internet. 13 When a router forwards a packet, it MUST reduce the TTL by at 14 least one. If it holds a packet for more than one second, it 15 MAY decrement the TTL by one for each second. 16 If the TTL is reduced to zero (or less), the packet MUST be 17 discarded, and the router MUST send an ICMP Time Exceeded 18 message to the source. Note that a router MUST NOT discard a 19 packet with a non-zero TTL merely because it can predict that 20 another router on the path to the packet's final destination 21 will decrement the TTL to zero. 22 SOURCE: 23 Section 5.3.1 source: new text, contributor: Philip 24 Almquist 25 Relationship to HRRFC: none 26 DISCUSSION: 27 The IP TTL is used, somewhat schizophrenically, as both a 28 hop count limit and a time limit. Its hop count function 29 is critical to ensuring that routing problems can't melt 30 down the network by causing packets to loop infinitely in 31 the network. The time limit function is used by transport 32 protocols such as TCP to ensure reliable data transfer. 33 Many current implementations treat TTL as a pure hop 34 count, and in parts of the Internet community there is a 35 strong sentiment that the time limit function should 36 instead be performed by the transport protocols that need 37 it. 38 In this specification, we have reluctantly decided to 39 follow the strong belief among the router vendors that the 40 time limit function should be optional. They argued that 41 implementation of the time limit function is difficult 42 enough that it is currently not generally done. They 43 further pointed to the lack of documented cases where this 44 shortcut has caused TCP to corrupt data (of course, we 45 would expect the problems created to be rare and difficult 46 to reproduce, so the lack of documented cases provides 47 little reassurance that there haven't been a number of 48 undocumented cases). Internet Engineering Task Force [Page 78] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 49 IP multicast notions such as the expanding ring search may 50 not work as expected unless the TTL is treated as a pure 51 hop count. The same thing is somewhat true of traceroute. 52 ICMP Time Exceeded messages are required because the 53 traceroute diagnostic tool depends on them. 0 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 3 bits), and two reserved bits (low order 2 bits). Rules 5 governing the reserved bits were described in Section 6 [4.2.2.2]. The Precedence field will be discussed in Section 7 [5.3.3]. 8 A router MUST maintain a TOS value for each route in its 9 routing table. Routes learned via a routing protocol which 10 does not support TOS MUST be assigned a TOS of zero. 11 To choose a route to a destination, a router MUST use an 12 algorithm equivalent to the following: 13 (1) The router locates in its routing table all available 14 routes to the destination. | 15 (2) If there are none, the router drops the packet because the | 16 destination is unreachable. The router returns an ICMP | 17 Destination Unreachable error specifying the Host | 18 Unreachable code (code 1), as specified in Section | 19 [4.3.3.1]. | 20 (3) If one or more of those routes have a TOS that exactly 21 matches the TOS specified in the packet, the router 22 chooses the route with the best metric. 23 (4) Otherwise, the router repeats the above step, except 24 looking at routes whose TOS is zero. 25 (5) If no route was chosen above, the router drops the packet 26 because the destination is unreachable. The router 27 returns an ICMP Destination Unreachable error specifying 28 the TOS Unreachable code (code 12). 29 The only variation permitted is that an implementor may, but * 30 SHOULD NOT, provide an option which, if enabled, omits step * 31 (4). If such an option is provided, it MUST be disabled by * Internet Engineering Task Force [Page 79] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 32 default. DISCUSSION: 33 Although TOS has been little used in the past, its use by 34 hosts is now mandated by the Requirements for Internet 35 Hosts RFCs ([INTRO:2] and [INTRO:3]). 36 Various people have proposed that TOS should affect other 37 aspects of the forwarding function. For example: 38 (1) A router could place packets which have the "Low 39 Delay" bit set ahead of other packets in its output 40 queues. 41 (2) If a router is forced to discard packets, it could 42 try to avoid discarding those which have the "High 43 Reliability" bit set. 44 However, we don't yet have enough experience with such 45 schemes to make requirements in this area. 46 EDITOR'S COMMENTS: 47 Comment from IAB Chair Vint Cerf: 48 If the present HR and IP specs (among others) say 49 that the TOS is 5 bits long, I urge you to keep it 50 that way. If we are going to do anything to change IP 51 semantics, let's not to it piecemeal. 52 The IESG has promised to settle the 3 bit vs 5 bit | 53 question. The proposed solution is to have it be four | 54 bits, with the fourth being a "minimize monetary cost" | 55 bit. | 0 5.3.3 IP Precedence 1 SOURCE: 2 Section 5.3.3 source: new text, contributor: Bill Barns 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- * Internet Engineering Task Force [Page 80] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 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 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. 0 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 Internet Engineering Task Force [Page 81] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 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 Routers that implement precedence-ordered queue service MUST * 13 also discard low precedence packets before discarding high * 14 precedence packets for congestion control purposes. See * 15 Section [5.3.6] for further information. * 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. 0 5.3.3.2 Lower Layer Precedence Mappings 1 Routers that implement precedence-ordered queueing MUST map 2 IP precedence to link layer priority mechanisms for link 3 layers that have such a feature defined. Also, they MUST 4 have a configuration option to select the link layer's 5 default priority treatment for all IP traffic, and SHOULD be 6 able to configure specific nonstandard mappings of IP 7 precedence values to link layer priority values for each 8 interface. 9 Routers that do not implement precedence-ordered queueing 10 SHOULD provide the features described above. 11 DISCUSSION: 12 Some research questions the workability of the priority 13 features of some link layer protocols, and some 14 networks may have faulty implementations of the link 15 layer priority mechanism. It seems prudent to provide 16 an escape mechanism in case such problems show up in a 17 network. 18 On the other hand, there are proposals to use novel 19 queueing strategies to implement special services such 20 as low-delay service. Special services and queueing 21 strategies to support them need further research and 22 experimentation before they are put into widespread use 23 in the Internet. Since these requirements are intended 24 to encourage (but not force) the use of precedence Internet Engineering Task Force [Page 82] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 25 features in the hope of providing better Internet 26 service to all users, routers supporting precedence- 27 ordered queue service should default to maintaining 28 strict precedence ordering regardless of the type of 29 service requested. 30 Implementors may wish to consider that correct link 31 layer mapping of IP precedence is required by DOD 32 policy for TCP/IP systems used on DOD networks. 0 5.3.3.3 Precedence Handling For All Routers 1 A router (whether or not it employs precedence-ordered queue 2 service): 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, snd | 11 Parameter Problem. If this filter is provided, the 12 procedures required for packet filtering by addresses 13 are required for this filter also. EDITOR'S COMMENTS: | 14 What does the previous sentence mean? Should it | 15 contain a MUST? | 16 An ICMP Destination Unreachable message with code 13 | 17 SHOULD be sent when a packet is dropped by the | 18 validation filter, unless this has been suppressed by | 19 configuration choice. | 20 (3) MAY implement a cutoff function which allows the router 21 to be set to refuse or drop traffic with precedence 22 below a specified level. This function may be 23 activated by management actions or by some 24 implementation dependent heuristics, but there MUST be 25 a configuration option to disable any heuristic 26 mechanism that operates without human intervention. An | 27 ICMP Destination Unreachable message with code 13 | 28 SHOULD be sent when a packet is dropped by the cutoff | 29 function, unless this has been suppressed by | 30 configuration choice. | 31 (4) MUST NOT change precedence settings on packets it did Internet Engineering Task Force [Page 83] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 32 not originate. 33 (5) MUST set the IP precedence value appropriately in all 34 ICMP responses it generates. The value is taken from | 35 the packet that elicited the response, except that the | 36 precedence value SHOULD always be 7 (NETWORK CONTROL) | 37 for the following types of ICMP error messages: | 38 Unreachable, Redirect, Time Exceeded, and Parameter | 39 Problem. 40 (6) MUST be able to configure distinct precedence values to 41 be used for each routing or management protocol 42 supported. 43 (7) SHOULD be able to configure routing or management 44 traffic precedence values independently for each peer 45 address. 46 (8) MUST respond appropriately to link layer precedence- 47 related error indications where provided. An ICMP | 48 Destination Unreachable message with code 13 SHOULD be | 49 sent when a packet is dropped because a link cannot | 50 accept it due to a precedence-related condition, unless | 51 this has been suppressed by configuration choice. | 52 DISCUSSION: 53 The precedence cutoff mechanism described in (3) is 54 somewhat controversial. Depending on the topological 55 location of the area affected by the cutoff, transit 56 traffic may be directed by routing protocols into the 57 area of the cutoff, where it will be dropped. This is 58 only a problem if another path unaffected by the cutoff 59 exists between the communicating points. Proposed ways 60 of avoiding this problem include providing some minimum 61 bandwidth to all precedence levels even under overload 62 conditions, or propagating cutoff information in 63 routing protocols. In the absence of a widely accepted 64 (and implemented) solution to this problem, great 65 caution is recommended in activating cutoff mechanisms 66 in transit networks. 67 A transport layer relay could legitimately provide the 68 function prohibited by (4) above. Changing precedence 69 levels causes subtle interactions with TCP and perhaps 70 other protocols; a correct design is a non-trivial 71 task. 72 The intent of (5), (6), and (7) is that the IP Internet Engineering Task Force [Page 84] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 73 precedence bits should be appropriately set, whether or 74 not this router acts upon those bits in any other way. 75 The appropriate response for (8) depends on the link 76 layer protocol in use. Typically, the router should | 77 stop trying to send "offensive" traffic to that | 78 destination for some period of time, and should return | 79 an ICMP Destination Unreachable message with code 13 | 80 (service not available for precedence requested). to | 81 the traffic source. It also should not try to 82 reestablish a preempted link layer connection for some 83 period of time. 84 CONTRIBUTOR'S COMMENTS: 85 Is (5) the right thing to do? Alternatives: (1) All at * 86 Internetwork Control precedence, except reply-type * 87 messages (Echo Reply, ??) at precedence of stimulus * 88 packet; (2) All error messages at Internetwork Control, * 89 non-errors at precedence of stimulus; (3) Everything at * 90 Internetwork Control. Argument against #3 is that it * 91 might be useful to do pinging with selectable * 92 (symmetric) precedence. * 93 Possibly need list of management/routing protocols in 94 which precedence ought to be set to Internetwork 95 Control. EGP, BGP, SNMP?? Maybe there should be a 96 notion of responding at precedence level selected by 97 management agent, in case of SNMP, etc. High 98 precedence is sometimes needed here, but not always. 99 Braden thinks SHOULD be able to configure specific 100 nonstandard link layer mappings might be too strong. 101 Uncertain/unresolved. 0 5.3.4 Forwarding of Link Layer Broadcasts 1 SOURCE: 2 Section 5.3.4 source: new text, contributor: Stev Knowles 3 Relationship to HRRFC: none 4 Relationship to RFC-1009: new requirement? 5 A valid IP Link Layer broadcast is a Link Layer frame with a | 6 Link Layer broadcast or multicast address and containing an IP | 7 packet whose destination address is an IP broadcast or IP | 8 multicast address. | Internet Engineering Task Force [Page 85] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 9 EDITOR'S COMMENTS: | 10 Is the above definition needed. If so, it makes the | 11 following paragraph confusing because it uses "link layer | 12 broadcast" to mean something other that what is meant by | 13 "valid IP Link Layer broadcast" above except for PPP | 14 packets. | 15 I wonder if it's too late to fix PPP? | 16 A router MUST NOT forward any packet which the router received 17 as a Link Layer broadcast. A router MUST NOT forward any 18 packet which the router received as a Link Layer multicast 19 unless the packet's destination address is an IP multicast 20 address. 21 SOURCE: 22 Section 5.3.4, source: RFC-1122 Section 3.3.6, 23 contributor: Philip Almquist 24 A router SHOULD silently discard a packet that is received via 25 a link-layer broadcast but does not specify an IP multicast or 26 IP broadcast destination address. 27 When a router sends a packet to a link-layer broadcast address, 28 the IP destination address MUST be a legal IP broadcast or IP 29 multicast address. 30 EDITOR'S COMMENTS: 31 The requirements in this section are probably not exactly 32 correct, due to the existence of link layer protocols 33 (such as PPP) which encapsulate all packets, including IP 34 unicasts, as link layer broadcasts. 0 5.3.5 Forwarding of Internet Layer Broadcasts 1 SOURCE: 2 Section 5.3.5 source: new text, contributors: Stev 3 Knowles, Kent England, Philip Almquist 4 Relationship to HRRFC: hosts are also required to 5 understand 0-filled broadcasts? 6 There are two major types of IP broadcast addresses; limited * 7 broadcast and directed broadcast. In addition, there are three * 8 subtypes of directed broadcast; a broadcast directed to a * 9 specified network, a broadcast directed to a specified * 10 subnetwork, and a broadcast directed to all subnets of a * 11 specified network. Classification by a router of a broadcast * Internet Engineering Task Force [Page 86] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 12 into one of these categories depends on the broadcast address * 13 and on the router's understanding (if any) of the subnet * 14 structure of the destination network. The same broadcast will * 15 be classified differently by different routers. * 16 A limited IP broadcast address is defined to be all-ones, * 17 { -1, -1 } or 255.255.255.255. * 18 A net-directed broadcast is composed of the network portion of * 19 the IP address with a local part of all-ones, * 20 { , -1 }. For example, a Class A net broadcast * 21 address is net.255.255.255, a Class B net broadcast address is * 22 net.net.255.255 and a Class C net broadcast address is * 23 net.net.net.255 where "net" is an octet of network address. * 24 An all-subnets-directed broadcast is composed of the network * 25 part of the IP address with a subnet and a host part of all- * 26 ones, { , -1, -1 }. For example, an all- * 27 subnets broadcast on a subnetted class B network is * 28 net.net.255.255. A network must be known to be subnetted and * 29 the subnet part must be all-ones before a broadcast can be * 30 classified as all-subnets-directed. * 31 A subnet-directed broadcast address is composed of the network * 32 and subnet part of the IP address with a host part of all-ones, * 33 { , , -1 }. For example, a | 34 subnet-directed broadcast to subnet 2 of a class B network | 35 might be net.net.2.255 (if the subnet mask was 255.255.255.0) | 36 or net.net.1.127 (if the subnet mask was 255.255.254.0). A * 37 network must be known to be subnetted and the net and subnet * 38 part must not be all-ones before an IP broadcast can be * 39 classified as subnet-directed. * 40 A router MUST understand these internet standard IP broadcast * 41 addresses for IP. A router SHOULD be configurable to accept IP * 42 broadcast addresses where the broadcast fill pattern is all- * 43 zeroes instead of all-ones. The configuration default MUST * 44 permit an all-ones IP broadcast fill pattern. * 45 A router MUST be able to send certain of these standard IP * 46 broadcast addresses. A router MAY be configurable to send IP * 47 broadcast addresses where the broadcast fill pattern is all- * 48 zeroes instead of all-ones. * 49 A router MUST NOT forward any broadcast to the logical * 50 interface from whence it came. * 51 AUTHOR'S COMMENTS: * Internet Engineering Task Force [Page 87] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 52 is the sort of warning in the last sentence necessary? * 53 Well, it's safe. -kwe * 0 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. 0 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 * 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 * Internet Engineering Task Force [Page 88] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 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. * 0 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, unless the all-subnets-directed * 9 broadcast was received as a link level broadcast, in which * 10 case it should be processed locally. A router MUST NOT * 11 forward an all-subnets-directed broadcast that was received * 12 as a link level broadcast. * 13 CONTRIBUTOR'S COMMENTS: * 14 We did say somewhere that routers must know about link * 15 level bcasts? And are these precautions sufficient? - * 16 kwe * 17 A router MUST have a configuration option to deny forwarding | 18 of all-subnets-directed broadcasts. The configuration | 19 option MUST default to permit forwarding of all-subnets- | 20 directed broadcasts. | 21 CONTRIBUTOR'S COMMENTS: * 22 Should we continue the prohibition of sending ICMP * 23 error messages when dropping directed broadcasts? If * 24 not, what message is returned? -kwe * 25 RFC 922 behavior is obsolete and superceded by IP * 26 multicasting [cite rfc1112?], but may be permitted as a * 27 configuration option. 28 A router SHOULD NOT originate all-subnets broadcasts, except | 29 as required by Section [4.3.3.9] when sending ICMP Mask | 30 Replies on subnetted networks. Internet Engineering Task Force [Page 89] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 31 EDITOR'S COMMENTS: 32 The current intention is to decree that (like 0-filled 33 IP broadcasts) the notion of the all-subnets broadcast 34 is obsolete. It should be treated as a directed 35 broadcast to the first subnet of the net in question 36 that it appears on. Routers MAY implement a switch 37 (default off) which if turned on enables the RFC-922 38 behavior for all-subnets broadcasts. 39 CONTRIBUTOR'S COMMENTS: * 40 I would argue against this. If you were going to allow * 41 some kind of forwarding, the router would have to * 42 convert the broadcast into an acceptable form (else * 43 some other router would also forward). In general if a * 44 router is entirely inside a subnetted network and * 45 receives an all-subnets-directed broadcast it will have * 46 a hard time deciding exactly which one interface to * 47 send the converted-to-subnet-directed broadcast on. * 48 Therefore, all-subnets-directed broadcasts should not * 49 be forwarded or they should be forwarded multicast * 50 style. -kwe * 51 DISCUSSION: * 52 If a router has a configuration option to allow for * 53 forwarding all-subnet broadcasts, it should use a * 54 spanning tree or other multicast forwarding algorithm * 55 (which may be computed for other purposes such as * 56 bridging or OSPF) to distribute the all-subnets * 57 broadcast efficiently. In general, it is better to use * 58 an IP multicast address rather than an all-subnets * 59 broadcast. * 0 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. If such an option * 9 is provided, its default setting MUST permit forwarding of * 10 subnet-directed broadcasts. * 11 A router MAY have a configuration option to prohibit * Internet Engineering Task Force [Page 90] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 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. * 0 5.3.6 Congestion Control 1 SOURCE: 2 Section 5.3.6, source: new text, contributor: Jim Forster 3 Relationship to HRRFC: none 4 Congestion in a network is loosely defined as a condition where 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. A router MAY discard the packet it has just 25 received. The router SHOULD discard lower precedence packets * 26 before discarding higher precedence packets. To help prevent * 27 routing perturbations or disruption of management functions, * 28 the router MAY protect packets used for routing control, link * 29 control, or network management from being discarded. * 30 As described in Section [4.3.3.3], this DRAFT recommends that a * 31 router should not send a Source Quench to the sender of the * 32 packet that it is discarding. ICMP Source Quench is a very 33 weak mechanism, so it is not necessary for a router to send it, 34 and host software should not use it exclusively as an indicator 35 of congestion. Internet Engineering Task Force [Page 91] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 36 Which packet to discard is the subject of much study. Dropping 37 the packet just received is the simplest, but not the best 38 policy. It is considered better policy to randomly pick some 39 other transit packet on the queue and discard it. A router MAY 40 use this Random Choice algorithm to determine which packet to 41 discard. When precedence and random choice are both considered * 42 in choosing a packet to drop, the random choice algorithm is * 43 applied to the lowest precedence packets first. * 44 Advanced methods of congestion control include a notion of 45 fairness, so that the 'user' that is penalized by loosing a 46 packet is the one that contributed the most to the congestion. 47 No matter what mechanism is implemented to deal with bandwidth 48 congestion control, it is important that the CPU effort 49 expended be sufficiently small that the router is not driven 50 into CPU congestion also. 0 5.3.7 Martian Address Filtering 1 An IP source address is invalid if it is an IP broadcast 2 address or is not a class A, B, or C address. 3 An IP destination address is invalid if it is not a class A, B, 4 C, or D address. 5 A router SHOULD NOT forward any packet which has an invalid IP 6 source address or a source address on network 0. A router 7 SHOULD NOT forward, except over a loopback interface, any 8 packet which has a source address on network 127. A router MAY 9 have a switch which allows the network manager to disable these 10 checks. 11 A router SHOULD NOT forward any packet which has an invalid IP 12 destination address or a destination address on network 0. A 13 router SHOULD NOT forward, except over a loopback interface, 14 any packet which has a destination address on network 127. A 15 router MAY have a switch which allows the network manager to 16 disable these checks. 17 If a router discards a packet because of these rules, it SHOULD 18 log at least the IP source address, the IP destination address, 19 and, if the problem was with the source address, the physical 20 interface on which the packet was received and the link layer 21 address of the host or router from which the packet was 22 received. Internet Engineering Task Force [Page 92] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 0 5.3.8 Packet Filtering and Access Lists 1 SOURCE: 2 Section 5.3.8 source: new text, contributor: Michael 3 Reilly. 4 Relationship to HRRFC: none 5 As a means of providing security and/or limited traffic through * 6 portions of a network a router SHOULD provide the ability to * 7 selectively forward (or filter) packets. If this capability is * 8 provided, filtering of packets MUST be configurable either to * 9 forward all packets or to selectively forward them based upon * 10 the source and destination addresses. Each source and * 11 destination address SHOULD allow specification of an arbitrary * 12 mask. * 13 If supported, a router MUST be configurable to allow one of an * 14 o Include list -- specification of a list of address pairs 15 to be forwarded, or an 16 o Exclude list -- specification of a list of address pairs 17 NOT to be forwarded. 18 A router MAY provide a configuration switch which allows a 19 choice between specifying an include or an exclude list. 20 The value "any" MUST be allowed as a source and/or destination 21 address or a mask of all 0's MUST be supported. 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. 26 The router SHOULD allow an appropriate ICMP unreachable message 27 to be sent when a packet is discarded. The ICMP message SHOULD * 28 specify Communication Administratively Prohibited (code 13) as * 29 the reason for the destination being unreachable. * 30 The router SHOULD allow the sending of ICMP destination * 31 unreachable messages (code 13) to be configured for each * 32 combination of address pairs protocol types and ports it allows * 33 to be specified. * 34 The router SHOULD allow selective logging of packets not Internet Engineering Task Force [Page 93] INTERNET-DRAFT INTERNET LAYER: FORWARDING March 6, 1991 35 forwarded. 0 5.3.9 Controls on Forwarding 1 SOURCE: 2 Section 5.3.9 source: new text, contributor: Philip 3 Almquist. 4 Relationship to HRRFC: none 5 For each logical interface, a router SHOULD have a * 6 configuration option which specifies whether forwarding is * 7 enabled on that interface. When forwarding on an interface is * 8 disabled, the router: * 9 o silently discards any packets which are received on that * 10 interface but are not addressed to the router * 11 o does not send packets out that interface, except for * 12 datagrams originated by the router * 13 o does not announce via any routing protocols the * 14 availability of paths through the interface * 15 CONTRIBUTOR'S COMMENTS: | 16 The above states that the option is per-logical-interface. | 17 Although this seems intuitively right to me, it's not | 18 clear to me that the router can always tell which logical | 19 interface a packet arrived on or which logical interface a | 20 packet is being sent on. Comments? | 0 5.4 REQUIREMENTS SUMMARY 1 TBD Internet Engineering Task Force [Page 94] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 06. TRANSPORT LAYER 1 EDITOR'S COMMENTS: 2 This chapter covers transport protocols which routers may choose 3 to implement. 4 It needs to cover, among other things: handling of IP options by | 5 the Transport Layer, UDP checksums, ... | 6 A router is not required to implement any Transport Layer protocols | 7 except those required to support Application Layer protocols | 8 supported by the router. In practice, this means that most routers | 9 implement both the Transmission Control Protocol (TCP) and the User | 10 Datagram Protocol (UDP). | 0 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 | Internet Engineering Task Force [Page 95] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 28 SHOULD NOT be able to disable to generation of UDP checksums. | 29 EDITOR'S COMMENTS: | 30 For reference, I reproduce the relevant section of RFC-1122 | 31 here. It is not my intention that this will remain in the | 32 final version of this memo. | 33 Note that references to other documents use the reference | 34 list from RFC-1122, not the one in this document. Likewise, | 35 cross-references refer to sections of RFC-1122. | 36 4.1.2 PROTOCOL WALK-THROUGH | 37 There are no known errors in the specification of UDP. | 38 4.1.3 SPECIFIC ISSUES | 39 4.1.3.1 Ports | 40 UDP well-known ports follow the same rules as TCP well-known | 41 ports; see Section 4.2.2.1 below. | 42 If a datagram arrives addressed to a UDP port for which | 43 there is no pending LISTEN call, UDP SHOULD send an ICMP | 44 Port Unreachable message. | 45 4.1.3.2 IP Options | 46 UDP MUST pass any IP option that it receives from the IP | 47 layer transparently to the application layer. | 48 An application MUST be able to specify IP options to be sent | 49 in its UDP datagrams, and UDP MUST pass these options to the | 50 IP layer. | 51 DISCUSSION: | 52 At present, the only options that need be passed | 53 through UDP are Source Route, Record Route, and Time | 54 Stamp. However, new options may be defined in the | 55 future, and UDP need not and should not make any | 56 assumptions about the format or content of options it | 57 passes to or from the application; an exception to this | 58 might be an IP-layer security option. | 59 An application based on UDP will need to obtain a | 60 source route from a request datagram and supply a | 61 reversed route for sending the corresponding reply. | Internet Engineering Task Force [Page 96] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 62 4.1.3.3 ICMP Messages | 63 UDP MUST pass to the application layer all ICMP error | 64 messages that it receives from the IP layer. Conceptually | 65 at least, this may be accomplished with an upcall to the | 66 ERROR_REPORT routine (see Section 4.2.4.1). | 67 DISCUSSION: | 68 Note that ICMP error messages resulting from sending a | 69 UDP datagram are received asynchronously. A UDP-based | 70 application that wants to receive ICMP error messages | 71 is responsible for maintaining the state necessary to | 72 demultiplex these messages when they arrive; for | 73 example, the application may keep a pending receive | 74 operation for this purpose. The application is also | 75 responsible to avoid confusion from a delayed ICMP | 76 error message resulting from an earlier use of the same | 77 port(s). | 78 4.1.3.4 UDP Checksums | 79 A host MUST implement the facility to generate and validate | 80 UDP checksums. An application MAY optionally be able to | 81 control whether a UDP checksum will be generated, but it | 82 MUST default to checksumming on. | 83 If a UDP datagram is received with a checksum that is non- | 84 zero and invalid, UDP MUST silently discard the datagram. | 85 An application MAY optionally be able to control whether UDP | 86 datagrams without checksums should be discarded or passed to | 87 the application. | 88 DISCUSSION: | 89 Some applications that normally run only across local | 90 area networks have chosen to turn off UDP checksums for | 91 efficiency. As a result, numerous cases of undetected | 92 errors have been reported. The advisability of ever | 93 turning off UDP checksumming is very controversial. | 94 IMPLEMENTATION: | 95 There is a common implementation error in UDP | 96 checksums. Unlike the TCP checksum, the UDP checksum | 97 is optional; the value zero is transmitted in the | 98 checksum field of a UDP header to indicate the absence | 99 of a checksum. If the transmitter really calculates a | 100 UDP checksum of zero, it must transmit the checksum as | 101 all 1's (65535). No special action is required at the | 102 receiver, since zero and 65535 are equivalent in 1's | Internet Engineering Task Force [Page 97] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 103 complement arithmetic. | 104 4.1.3.5 UDP Multihoming | 105 When a UDP datagram is received, its specific-destination | 106 address MUST be passed up to the application layer. | 107 An application program MUST be able to specify the IP source | 108 address to be used for sending a UDP datagram or to leave it | 109 unspecified (in which case the networking software will | 110 choose an appropriate source address). There SHOULD be a | 111 way to communicate the chosen source address up to the | 112 application layer (e.g, so that the application can later | 113 receive a reply datagram only from the corresponding | 114 interface). | 115 DISCUSSION: | 116 A request/response application that uses UDP should use | 117 a source address for the response that is the same as | 118 the specific destination address of the request. See | 119 the "General Issues" section of [INTRO:1]. | 120 4.1.3.6 Invalid Addresses | 121 A UDP datagram received with an invalid IP source address | 122 (e.g., a broadcast or multicast address) must be discarded | 123 by UDP or by the IP layer (see Section 3.2.1.3). | 124 When a host sends a UDP datagram, the source address MUST be | 125 (one of) the IP address(es) of the host. | 126 4.1.4 UDP/APPLICATION LAYER INTERFACE | 127 The application interface to UDP MUST provide the full services | 128 of the IP/transport interface described in Section 3.4 of this | 129 document. Thus, an application using UDP needs the functions | 130 of the GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB(), and | 131 RECV_ICMP() calls described in Section 3.4. For example, | 132 GET_MAXSIZES() can be used to learn the effective maximum UDP | 133 maximum datagram size for a particular {interface,remote | 134 host,TOS} triplet. | 135 An application-layer program MUST be able to set the TTL and | 136 TOS values as well as IP options for sending a UDP datagram, | 137 and these values must be passed transparently to the IP layer. | 138 UDP MAY pass the received TOS up to the application layer. | 139 [INTRO:1] "Requirements for Internet Hosts -- Application and Support,"| Internet Engineering Task Force [Page 98] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 140 IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123,| 141 October 1989. | 0 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 section 4.2.4 of [INTRO:2] (except of course where | 13 compliance is required for proper functioning of Application | 14 Layer protocols supported by the router). | 15 o The requirements of section 4.2.2.6 of[INTRO:2] are amended | 16 as follows: a router which implements the host portion of MTU | 17 discovery (discussed in Section [4.2.3.3] of this memo) uses | 18 536 as the default value of SendMSS only if the path MTU is | 19 unknown; if the path MTU is known, the default value for | 20 SendMSS is the path MTU - 40. | 21 EDITOR'S COMMENTS: | 22 For reference, I reproduce the relevant section of RFC-1122 | 23 here. It is not my intention that this will remain in the | 24 final version of this memo. | 25 Note that references to other documents use the reference | 26 list from RFC-1122, not the one in this document. Likewise, | 27 cross-references refer to sections of RFC-1122. | 28 4.2.2 PROTOCOL WALK-THROUGH | 29 4.2.2.1 Well-Known Ports: RFC-793 Section 2.7 | 30 DISCUSSION: | 31 TCP reserves port numbers in the range 0-255 for | 32 "well-known" ports, used to access services that are | 33 standardized across the Internet. The remainder of the | 34 port space can be freely allocated to application | 35 processes. Current well-known port definitions are | Internet Engineering Task Force [Page 99] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 36 listed in the RFC entitled "Assigned Numbers" | 37 [INTRO:6]. A prerequisite for defining a new well- | 38 known port is an RFC documenting the proposed service | 39 in enough detail to allow new implementations. | 40 Some systems extend this notion by adding a third | 41 subdivision of the TCP port space: reserved ports, | 42 which are generally used for operating-system-specific | 43 services. For example, reserved ports might fall | 44 between 256 and some system-dependent upper limit. | 45 Some systems further choose to protect well-known and | 46 reserved ports by permitting only privileged users to | 47 open TCP connections with those port values. This is | 48 perfectly reasonable as long as the host does not | 49 assume that all hosts protect their low-numbered ports | 50 in this manner. | 51 4.2.2.2 Use of Push: RFC-793 Section 2.8 | 52 When an application issues a series of SEND calls without | 53 setting the PUSH flag, the TCP MAY aggregate the data | 54 internally without sending it. Similarly, when a series of | 55 segments is received without the PSH bit, a TCP MAY queue | 56 the data internally without passing it to the receiving | 57 application. | 58 The PSH bit is not a record marker and is independent of | 59 segment boundaries. The transmitter SHOULD collapse | 60 successive PSH bits when it packetizes data, to send the | 61 largest possible segment. | 62 A TCP MAY implement PUSH flags on SEND calls. If PUSH flags | 63 are not implemented, then the sending TCP: (1) must not | 64 buffer data indefinitely, and (2) MUST set the PSH bit in | 65 the last buffered segment (i.e., when there is no more | 66 queued data to be sent). | 67 The discussion in RFC-793 on pages 48, 50, and 74 | 68 erroneously implies that a received PSH flag must be passed | 69 to the application layer. Passing a received PSH flag to | 70 the application layer is now OPTIONAL. | 71 An application program is logically required to set the PUSH | 72 flag in a SEND call whenever it needs to force delivery of | 73 the data to avoid a communication deadlock. However, a TCP | 74 SHOULD send a maximum-sized segment whenever possible, to | 75 improve performance (see Section 4.2.3.4). | Internet Engineering Task Force [Page 100] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 76 DISCUSSION: | 77 When the PUSH flag is not implemented on SEND calls, | 78 i.e., when the application/TCP interface uses a pure | 79 streaming model, responsibility for aggregating any | 80 tiny data fragments to form reasonable sized segments | 81 is partially borne by the application layer. | 82 Generally, an interactive application protocol must set | 83 the PUSH flag at least in the last SEND call in each | 84 command or response sequence. A bulk transfer protocol | 85 like FTP should set the PUSH flag on the last segment | 86 of a file or when necessary to prevent buffer deadlock. | 87 At the receiver, the PSH bit forces buffered data to be | 88 delivered to the application (even if less than a full | 89 buffer has been received). Conversely, the lack of a | 90 PSH bit can be used to avoid unnecessary wakeup calls | 91 to the application process; this can be an important | 92 performance optimization for large timesharing hosts. | 93 Passing the PSH bit to the receiving application allows | 94 an analogous optimization within the application. | 95 4.2.2.3 Window Size: RFC-793 Section 3.1 | 96 The window size MUST be treated as an unsigned number, or | 97 else large window sizes will appear like negative windows | 98 and TCP will not work. It is RECOMMENDED that | 99 implementations reserve 32-bit fields for the send and | 100 receive window sizes in the connection record and do all | 101 window computations with 32 bits. | 102 DISCUSSION: | 103 It is known that the window field in the TCP header is | 104 too small for high-speed, long-delay paths. | 105 Experimental TCP options have been defined to extend | 106 the window size; see for example [TCP:11]. In | 107 anticipation of the adoption of such an extension, TCP | 108 implementors should treat windows as 32 bits. | 109 4.2.2.4 Urgent Pointer: RFC-793 Section 3.1 | 110 The second sentence is in error: the urgent pointer points | 111 to the sequence number of the LAST octet (not LAST+1) in a | 112 sequence of urgent data. The description on page 56 (last | 113 sentence) is correct. | 114 A TCP MUST support a sequence of urgent data of any length. | Internet Engineering Task Force [Page 101] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 115 A TCP MUST inform the application layer asynchronously | 116 whenever it receives an Urgent pointer and there was | 117 previously no pending urgent data, or whenever the Urgent | 118 pointer advances in the data stream. There MUST be a way | 119 for the application to learn how much urgent data remains to | 120 be read from the connection, or at least to determine | 121 whether or not more urgent data remains to be read. | 122 DISCUSSION: | 123 Although the Urgent mechanism may be used for any | 124 application, it is normally used to send "interrupt"- | 125 type commands to a Telnet program (see "Using Telnet | 126 Synch Sequence" section in [INTRO:1]). | 127 The asynchronous or "out-of-band" notification will | 128 allow the application to go into "urgent mode", reading | 129 data from the TCP connection. This allows control | 130 commands to be sent to an application whose normal | 131 input buffers are full of unprocessed data. | 132 IMPLEMENTATION: | 133 The generic ERROR-REPORT() upcall described in Section | 134 4.2.4.1 is a possible mechanism for informing the | 135 application of the arrival of urgent data. | 136 4.2.2.5 TCP Options: RFC-793 Section 3.1 | 137 A TCP MUST be able to receive a TCP option in any segment. | 138 A TCP MUST ignore without error any TCP option it does not | 139 implement, assuming that the option has a length field (all | 140 TCP options defined in the future will have length fields). | 141 TCP MUST be prepared to handle an illegal option length | 142 (e.g., zero) without crashing; a suggested procedure is to | 143 reset the connection and log the reason. | 144 4.2.2.6 Maximum Segment Size Option: RFC-793 Section 3.1 | 145 TCP MUST implement both sending and receiving the Maximum | 146 Segment Size option [TCP:4]. | 147 TCP SHOULD send an MSS (Maximum Segment Size) option in | 148 every SYN segment when its receive MSS differs from the | 149 default 536, and MAY send it always. | 150 If an MSS option is not received at connection setup, TCP | 151 MUST assume a default send MSS of 536 (576-40) [TCP:4]. | 152 The maximum size of a segment that TCP really sends, the | Internet Engineering Task Force [Page 102] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 153 "effective send MSS," MUST be the smaller of the send MSS | 154 (which reflects the available reassembly buffer size at the | 155 remote host) and the largest size permitted by the IP layer: | 156 Eff.snd.MSS = | 157 min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize | 158 where: | 159 * SendMSS is the MSS value received from the remote host, | 160 or the default 536 if no MSS option is received. | 161 * MMS_S is the maximum size for a transport-layer message | 162 that TCP may send. | 163 * TCPhdrsize is the size of the TCP header; this is | 164 normally 20, but may be larger if TCP options are to be | 165 sent. | 166 * IPoptionsize is the size of any IP options that TCP | 167 will pass to the IP layer with the current message. | 168 The MSS value to be sent in an MSS option must be less than | 169 or equal to: | 170 MMS_R - 20 | 171 where MMS_R is the maximum size for a transport-layer | 172 message that can be received (and reassembled). TCP obtains | 173 MMS_R and MMS_S from the IP layer; see the generic call | 174 GET_MAXSIZES in Section 3.4. | 175 DISCUSSION: | 176 The choice of TCP segment size has a strong effect on | 177 performance. Larger segments increase throughput by | 178 amortizing header size and per-datagram processing | 179 overhead over more data bytes; however, if the packet | 180 is so large that it causes IP fragmentation, efficiency | 181 drops sharply if any fragments are lost [IP:9]. | 182 Some TCP implementations send an MSS option only if the | 183 destination host is on a non-connected network. | 184 However, in general the TCP layer may not have the | 185 appropriate information to make this decision, so it is | 186 preferable to leave to the IP layer the task of | 187 determining a suitable MTU for the Internet path. We | Internet Engineering Task Force [Page 103] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 188 therefore recommend that TCP always send the option (if | 189 not 536) and that the IP layer determine MMS_R as | 190 specified in 3.3.3 and 3.4. A proposed IP-layer | 191 mechanism to measure the MTU would then modify the IP | 192 layer without changing TCP. | 193 4.2.2.7 TCP Checksum: RFC-793 Section 3.1 | 194 Unlike the UDP checksum (see Section 4.1.3.4), the TCP | 195 checksum is never optional. The sender MUST generate it and | 196 the receiver MUST check it. | 197 4.2.2.8 TCP Connection State Diagram: RFC-793 Section 3.2, | 198 page 23 | 199 There are several problems with this diagram: | 200 (a) The arrow from SYN-SENT to SYN-RCVD should be labeled | 201 with "snd SYN,ACK", to agree with the text on page 68 | 202 and with Figure 8. | 203 (b) There could be an arrow from SYN-RCVD state to LISTEN | 204 state, conditioned on receiving a RST after a passive | 205 open (see text page 70). | 206 (c) It is possible to go directly from FIN-WAIT-1 to the | 207 TIME-WAIT state (see page 75 of the spec). | 208 4.2.2.9 Initial Sequence Number Selection: RFC-793 Section | 209 3.3, page 27 | 210 A TCP MUST use the specified clock-driven selection of | 211 initial sequence numbers. | 212 4.2.2.10 Simultaneous Open Attempts: RFC-793 Section 3.4, page | 213 32 | 214 There is an error in Figure 8: the packet on line 7 should | 215 be identical to the packet on line 5. | 216 A TCP MUST support simultaneous open attempts. | 217 DISCUSSION: | 218 It sometimes surprises implementors that if two | 219 applications attempt to simultaneously connect to each | 220 other, only one connection is generated instead of two. | 221 This was an intentional design decision; don't try to | 222 "fix" it. | Internet Engineering Task Force [Page 104] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 223 4.2.2.11 Recovery from Old Duplicate SYN: RFC-793 Section 3.4, | 224 page 33 | 225 Note that a TCP implementation MUST keep track of whether a | 226 connection has reached SYN_RCVD state as the result of a | 227 passive OPEN or an active OPEN. | 228 4.2.2.12 RST Segment: RFC-793 Section 3.4 | 229 A TCP SHOULD allow a received RST segment to include data. | 230 DISCUSSION | 231 It has been suggested that a RST segment could contain | 232 ASCII text that encoded and explained the cause of the | 233 RST. No standard has yet been established for such | 234 data. | 235 4.2.2.13 Closing a Connection: RFC-793 Section 3.5 | 236 A TCP connection may terminate in two ways: (1) the normal | 237 TCP close sequence using a FIN handshake, and (2) an "abort" | 238 in which one or more RST segments are sent and the | 239 connection state is immediately discarded. If a TCP | 240 connection is closed by the remote site, the local | 241 application MUST be informed whether it closed normally or | 242 was aborted. | 243 The normal TCP close sequence delivers buffered data | 244 reliably in both directions. Since the two directions of a | 245 TCP connection are closed independently, it is possible for | 246 a connection to be "half closed," i.e., closed in only one | 247 direction, and a host is permitted to continue sending data | 248 in the open direction on a half-closed connection. | 249 A host MAY implement a "half-duplex" TCP close sequence, so | 250 that an application that has called CLOSE cannot continue to | 251 read data from the connection. If such a host issues a | 252 CLOSE call while received data is still pending in TCP, or | 253 if new data is received after CLOSE is called, its TCP | 254 SHOULD send a RST to show that data was lost. | 255 When a connection is closed actively, it MUST linger in | 256 TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime). | 257 However, it MAY accept a new SYN from the remote TCP to | 258 reopen the connection directly from TIME-WAIT state, if it: | 259 (1) assigns its initial sequence number for the new | 260 connection to be larger than the largest sequence | Internet Engineering Task Force [Page 105] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 261 number it used on the previous connection incarnation, | 262 and | 263 (2) returns to TIME-WAIT state if the SYN turns out to be | 264 an old duplicate. | 265 DISCUSSION: | 266 TCP's full-duplex data-preserving close is a feature | 267 that is not included in the analogous ISO transport | 268 protocol TP4. | 269 Some systems have not implemented half-closed | 270 connections, presumably because they do not fit into | 271 the I/O model of their particular operating system. On | 272 these systems, once an application has called CLOSE, it | 273 can no longer read input data from the connection; this | 274 is referred to as a "half-duplex" TCP close sequence. | 275 The graceful close algorithm of TCP requires that the | 276 connection state remain defined on (at least) one end | 277 of the connection, for a timeout period of 2xMSL, i.e., | 278 4 minutes. During this period, the (remote socket, | 279 local socket) pair that defines the connection is busy | 280 and cannot be reused. To shorten the time that a given | 281 port pair is tied up, some TCPs allow a new SYN to be | 282 accepted in TIME-WAIT state. | 283 4.2.2.14 Data Communication: RFC-793 Section 3.7, page 40 | 284 Since RFC-793 was written, there has been extensive work on | 285 TCP algorithms to achieve efficient data communication. | 286 Later sections of the present document describe required and | 287 recommended TCP algorithms to determine when to send data | 288 (Section 4.2.3.4), when to send an acknowledgment (Section | 289 4.2.3.2), and when to update the window (Section 4.2.3.3). | 290 DISCUSSION: | 291 One important performance issue is "Silly Window | 292 Syndrome" or "SWS" [TCP:5], a stable pattern of small | 293 incremental window movements resulting in extremely | 294 poor TCP performance. Algorithms to avoid SWS are | 295 described below for both the sending side (Section | 296 4.2.3.4) and the receiving side (Section 4.2.3.3). | 297 In brief, SWS is caused by the receiver advancing the | 298 right window edge whenever it has any new buffer space | 299 available to receive data and by the sender using any | Internet Engineering Task Force [Page 106] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 300 incremental window, no matter how small, to send more | 301 data [TCP:5]. The result can be a stable pattern of | 302 sending tiny data segments, even though both sender and | 303 receiver have a large total buffer space for the | 304 connection. SWS can only occur during the transmission | 305 of a large amount of data; if the connection goes | 306 quiescent, the problem will disappear. It is caused by | 307 typical straightforward implementation of window | 308 management, but the sender and receiver algorithms | 309 given below will avoid it. | 310 Another important TCP performance issue is that some | 311 applications, especially remote login to character-at- | 312 a-time hosts, tend to send streams of one-octet data | 313 segments. To avoid deadlocks, every TCP SEND call from | 314 such applications must be "pushed", either explicitly | 315 by the application or else implicitly by TCP. The | 316 result may be a stream of TCP segments that contain one | 317 data octet each, which makes very inefficient use of | 318 the Internet and contributes to Internet congestion. | 319 The Nagle Algorithm described in Section 4.2.3.4 | 320 provides a simple and effective solution to this | 321 problem. It does have the effect of clumping | 322 characters over Telnet connections; this may initially | 323 surprise users accustomed to single-character echo, but | 324 user acceptance has not been a problem. | 325 Note that the Nagle algorithm and the send SWS | 326 avoidance algorithm play complementary roles in | 327 improving performance. The Nagle algorithm discourages | 328 sending tiny segments when the data to be sent | 329 increases in small increments, while the SWS avoidance | 330 algorithm discourages small segments resulting from the | 331 right window edge advancing in small increments. | 332 A careless implementation can send two or more | 333 acknowledgment segments per data segment received. For | 334 example, suppose the receiver acknowledges every data | 335 segment immediately. When the application program | 336 subsequently consumes the data and increases the | 337 available receive buffer space again, the receiver may | 338 send a second acknowledgment segment to update the | 339 window at the sender. The extreme case occurs with | 340 single-character segments on TCP connections using the | 341 Telnet protocol for remote login service. Some | 342 implementations have been observed in which each | 343 incoming 1-character segment generates three return | 344 segments: (1) the acknowledgment, (2) a one byte | Internet Engineering Task Force [Page 107] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 345 increase in the window, and (3) the echoed character, | 346 respectively. | 347 4.2.2.15 Retransmission Timeout: RFC-793 Section 3.7, page 41 | 348 The algorithm suggested in RFC-793 for calculating the | 349 retransmission timeout is now known to be inadequate; see | 350 Section 4.2.3.1 below. | 351 Recent work by Jacobson [TCP:7] on Internet congestion and | 352 TCP retransmission stability has produced a transmission | 353 algorithm combining "slow start" with "congestion | 354 avoidance". A TCP MUST implement this algorithm. | 355 If a retransmitted packet is identical to the original | 356 packet (which implies not only that the data boundaries have | 357 not changed, but also that the window and acknowledgment | 358 fields of the header have not changed), then the same IP | 359 Identification field MAY be used (see Section 3.2.1.5). | 360 IMPLEMENTATION: | 361 Some TCP implementors have chosen to "packetize" the | 362 data stream, i.e., to pick segment boundaries when | 363 segments are originally sent and to queue these | 364 segments in a "retransmission queue" until they are | 365 acknowledged. Another design (which may be simpler) is | 366 to defer packetizing until each time data is | 367 transmitted or retransmitted, so there will be no | 368 segment retransmission queue. | 369 In an implementation with a segment retransmission | 370 queue, TCP performance may be enhanced by repacketizing | 371 the segments awaiting acknowledgment when the first | 372 retransmission timeout occurs. That is, the | 373 outstanding segments that fitted would be combined into | 374 one maximum-sized segment, with a new IP Identification | 375 value. The TCP would then retain this combined segment | 376 in the retransmit queue until it was acknowledged. | 377 However, if the first two segments in the | 378 retransmission queue totalled more than one maximum- | 379 sized segment, the TCP would retransmit only the first | 380 segment using the original IP Identification field. | 381 4.2.2.16 Managing the Window: RFC-793 Section 3.7, page 41 | 382 A TCP receiver SHOULD NOT shrink the window, i.e., move the | 383 right window edge to the left. However, a sending TCP MUST | 384 be robust against window shrinking, which may cause the | Internet Engineering Task Force [Page 108] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 385 "useable window" (see Section 4.2.3.4) to become negative. | 386 If this happens, the sender SHOULD NOT send new data, but | 387 SHOULD retransmit normally the old unacknowledged data | 388 between SND.UNA and SND.UNA+SND.WND. The sender MAY also | 389 retransmit old data beyond SND.UNA+SND.WND, but SHOULD NOT | 390 time out the connection if data beyond the right window edge | 391 is not acknowledged. If the window shrinks to zero, the TCP | 392 MUST probe it in the standard way (see next Section). | 393 DISCUSSION: | 394 Many TCP implementations become confused if the window | 395 shrinks from the right after data has been sent into a | 396 larger window. Note that TCP has a heuristic to select | 397 the latest window update despite possible datagram | 398 reordering; as a result, it may ignore a window update | 399 with a smaller window than previously offered if | 400 neither the sequence number nor the acknowledgment | 401 number is increased. | 402 4.2.2.17 Probing Zero Windows: RFC-793 Section 3.7, page 42 | 403 Probing of zero (offered) windows MUST be supported. | 404 A TCP MAY keep its offered receive window closed | 405 indefinitely. As long as the receiving TCP continues to | 406 send acknowledgments in response to the probe segments, the | 407 sending TCP MUST allow the connection to stay open. | 408 DISCUSSION: | 409 It is extremely important to remember that ACK | 410 (acknowledgment) segments that contain no data are not | 411 reliably transmitted by TCP. If zero window probing is | 412 not supported, a connection may hang forever when an | 413 ACK segment that re-opens the window is lost. | 414 The delay in opening a zero window generally occurs | 415 when the receiving application stops taking data from | 416 its TCP. For example, consider a printer daemon | 417 application, stopped because the printer ran out of | 418 paper. | 419 The transmitting host SHOULD send the first zero-window | 420 probe when a zero window has existed for the retransmission | 421 timeout period (see Section 4.2.2.15), and SHOULD increase | 422 exponentially the interval between successive probes. | 423 DISCUSSION: | Internet Engineering Task Force [Page 109] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 424 This procedure minimizes delay if the zero-window | 425 condition is due to a lost ACK segment containing a | 426 window-opening update. Exponential backoff is | 427 recommended, possibly with some maximum interval not | 428 specified here. This procedure is similar to that of | 429 the retransmission algorithm, and it may be possible to | 430 combine the two procedures in the implementation. | 431 4.2.2.18 Passive OPEN Calls: RFC-793 Section 3.8 | 432 Every passive OPEN call either creates a new connection | 433 record in LISTEN state, or it returns an error; it MUST NOT | 434 affect any previously created connection record. | 435 A TCP that supports multiple concurrent users MUST provide | 436 an OPEN call that will functionally allow an application to | 437 LISTEN on a port while a connection block with the same | 438 local port is in SYN-SENT or SYN-RECEIVED state. | 439 DISCUSSION: | 440 Some applications (e.g., SMTP servers) may need to | 441 handle multiple connection attempts at about the same | 442 time. The probability of a connection attempt failing | 443 is reduced by giving the application some means of | 444 listening for a new connection at the same time that an | 445 earlier connection attempt is going through the three- | 446 way handshake. | 447 IMPLEMENTATION: | 448 Acceptable implementations of concurrent opens may | 449 permit multiple passive OPEN calls, or they may allow | 450 "cloning" of LISTEN-state connections from a single | 451 passive OPEN call. | 452 4.2.2.19 Time to Live: RFC-793 Section 3.9, page 52 | 453 RFC-793 specified that TCP was to request the IP layer to | 454 send TCP segments with TTL = 60. This is obsolete; the TTL | 455 value used to send TCP segments MUST be configurable. See | 456 Section 3.2.1.7 for discussion. | 457 4.2.2.20 Event Processing: RFC-793 Section 3.9 | 458 While it is not strictly required, a TCP SHOULD be capable | 459 of queueing out-of-order TCP segments. Change the "may" in | 460 the last sentence of the first paragraph on page 70 to | 461 "should". | Internet Engineering Task Force [Page 110] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 462 DISCUSSION: | 463 Some small-host implementations have omitted segment | 464 queueing because of limited buffer space. This | 465 omission may be expected to adversely affect TCP | 466 throughput, since loss of a single segment causes all | 467 later segments to appear to be "out of sequence". | 468 In general, the processing of received segments MUST be | 469 implemented to aggregate ACK segments whenever possible. | 470 For example, if the TCP is processing a series of queued | 471 segments, it MUST process them all before sending any ACK | 472 segments. | 473 Here are some detailed error corrections and notes on the | 474 Event Processing section of RFC-793. | 475 (a) CLOSE Call, CLOSE-WAIT state, p. 61: enter LAST-ACK | 476 state, not CLOSING. | 477 (b) LISTEN state, check for SYN (pp. 65, 66): With a SYN | 478 bit, if the security/compartment or the precedence is | 479 wrong for the segment, a reset is sent. The wrong form | 480 of reset is shown in the text; it should be: | 481 | 482 (c) SYN-SENT state, Check for SYN, p. 68: When the | 483 connection enters ESTABLISHED state, the following | 484 variables must be set: | 485 SND.WND <- SEG.WND | 486 SND.WL1 <- SEG.SEQ | 487 SND.WL2 <- SEG.ACK | 488 (d) Check security and precedence, p. 71: The first heading | 489 "ESTABLISHED STATE" should really be a list of all | 490 states other than SYN-RECEIVED: ESTABLISHED, FIN-WAIT- | 491 1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and | 492 TIME-WAIT. | 493 (e) Check SYN bit, p. 71: "In SYN-RECEIVED state and if | 494 the connection was initiated with a passive OPEN, then | 495 return this connection to the LISTEN state and return. | 496 Otherwise...". | 497 (f) Check ACK field, SYN-RECEIVED state, p. 72: When the | 498 connection enters ESTABLISHED state, the variables | Internet Engineering Task Force [Page 111] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 499 listed in (c) must be set. | 500 (g) Check ACK field, ESTABLISHED state, p. 72: The ACK is a | 501 duplicate if SEG.ACK =< SND.UNA (the = was omitted). | 502 Similarly, the window should be updated if: SND.UNA =< | 503 SEG.ACK =< SND.NXT. | 504 (h) USER TIMEOUT, p. 77: | 505 It would be better to notify the application of the | 506 timeout rather than letting TCP force the connection | 507 closed. However, see also Section 4.2.3.5. | 508 4.2.2.21 Acknowledging Queued Segments: RFC-793 Section 3.9 | 509 A TCP MAY send an ACK segment acknowledging RCV.NXT when a | 510 valid segment arrives that is in the window but not at the | 511 left window edge. | 512 DISCUSSION: | 513 RFC-793 (see page 74) was ambiguous about whether or | 514 not an ACK segment should be sent when an out-of-order | 515 segment was received, i.e., when SEG.SEQ was unequal to | 516 RCV.NXT. | 517 One reason for ACKing out-of-order segments might be to | 518 support an experimental algorithm known as "fast | 519 retransmit". With this algorithm, the sender uses the | 520 "redundant" ACK's to deduce that a segment has been | 521 lost before the retransmission timer has expired. It | 522 counts the number of times an ACK has been received | 523 with the same value of SEG.ACK and with the same right | 524 window edge. If more than a threshold number of such | 525 ACK's is received, then the segment containing the | 526 octets starting at SEG.ACK is assumed to have been lost | 527 and is retransmitted, without awaiting a timeout. The | 528 threshold is chosen to compensate for the maximum | 529 likely segment reordering in the Internet. There is | 530 not yet enough experience with the fast retransmit | 531 algorithm to determine how useful it is. | 532 4.2.3 SPECIFIC ISSUES | 533 4.2.3.1 Retransmission Timeout Calculation | 534 A host TCP MUST implement Karn's algorithm and Jacobson's | 535 algorithm for computing the retransmission timeout ("RTO"). | Internet Engineering Task Force [Page 112] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 536 o Jacobson's algorithm for computing the smoothed round- | 537 trip ("RTT") time incorporates a simple measure of the | 538 variance [TCP:7]. | 539 o Karn's algorithm for selecting RTT measurements ensures | 540 that ambiguous round-trip times will not corrupt the | 541 calculation of the smoothed round-trip time [TCP:6]. | 542 This implementation also MUST include "exponential backoff" | 543 for successive RTO values for the same segment. | 544 Retransmission of SYN segments SHOULD use the same algorithm | 545 as data segments. | 546 DISCUSSION: | 547 There were two known problems with the RTO calculations | 548 specified in RFC-793. First, the accurate measurement | 549 of RTTs is difficult when there are retransmissions. | 550 Second, the algorithm to compute the smoothed round- | 551 trip time is inadequate [TCP:7], because it incorrectly | 552 assumed that the variance in RTT values would be small | 553 and constant. These problems were solved by Karn's and | 554 Jacobson's algorithm, respectively. | 555 The performance increase resulting from the use of | 556 these improvements varies from noticeable to dramatic. | 557 Jacobson's algorithm for incorporating the measured RTT | 558 variance is especially important on a low-speed link, | 559 where the natural variation of packet sizes causes a | 560 large variation in RTT. One vendor found link | 561 utilization on a 9.6kb line went from 10% to 90% as a | 562 result of implementing Jacobson's variance algorithm in | 563 TCP. | 564 The following values SHOULD be used to initialize the | 565 estimation parameters for a new connection: | 566 (a) RTT = 0 seconds. | 567 (b) RTO = 3 seconds. (The smoothed variance is to be | 568 initialized to the value that will result in this RTO). | 569 The recommended upper and lower bounds on the RTO are known | 570 to be inadequate on large internets. The lower bound SHOULD | 571 be measured in fractions of a second (to accommodate high | 572 speed LANs) and the upper bound should be 2*MSL, i.e., 240 | 573 seconds. | 574 DISCUSSION: | Internet Engineering Task Force [Page 113] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 575 Experience has shown that these initialization values | 576 are reasonable, and that in any case the Karn and | 577 Jacobson algorithms make TCP behavior reasonably | 578 insensitive to the initial parameter choices. | 579 4.2.3.2 When to Send an ACK Segment | 580 A host that is receiving a stream of TCP data segments can | 581 increase efficiency in both the Internet and the hosts by | 582 sending fewer than one ACK (acknowledgment) segment per data | 583 segment received; this is known as a "delayed ACK" [TCP:5]. | 584 A TCP SHOULD implement a delayed ACK, but an ACK should not | 585 be excessively delayed; in particular, the delay MUST be | 586 less than 0.5 seconds, and in a stream of full-sized | 587 segments there SHOULD be an ACK for at least every second | 588 segment. | 589 DISCUSSION: | 590 A delayed ACK gives the application an opportunity to | 591 update the window and perhaps to send an immediate | 592 response. In particular, in the case of character-mode | 593 remote login, a delayed ACK can reduce the number of | 594 segments sent by the server by a factor of 3 (ACK, | 595 window update, and echo character all combined in one | 596 segment). | 597 In addition, on some large multi-user hosts, a delayed | 598 ACK can substantially reduce protocol processing | 599 overhead by reducing the total number of packets to be | 600 processed [TCP:5]. However, excessive delays on ACK's | 601 can disturb the round-trip timing and packet "clocking" | 602 algorithms [TCP:7]. | 603 4.2.3.3 When to Send a Window Update | 604 A TCP MUST include a SWS avoidance algorithm in the receiver | 605 [TCP:5]. | 606 IMPLEMENTATION: | 607 The receiver's SWS avoidance algorithm determines when | 608 the right window edge may be advanced; this is | 609 customarily known as "updating the window". This | 610 algorithm combines with the delayed ACK algorithm (see | 611 Section 4.2.3.2) to determine when an ACK segment | 612 containing the current window will really be sent to | 613 the receiver. We use the notation of RFC-793; see | 614 Figures 4 and 5 in that document. | Internet Engineering Task Force [Page 114] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 615 The solution to receiver SWS is to avoid advancing the | 616 right window edge RCV.NXT+RCV.WND in small increments, | 617 even if data is received from the network in small | 618 segments. | 619 Suppose the total receive buffer space is RCV.BUFF. At | 620 any given moment, RCV.USER octets of this total may be | 621 tied up with data that has been received and | 622 acknowledged but which the user process has not yet | 623 consumed. When the connection is quiescent, RCV.WND = | 624 RCV.BUFF and RCV.USER = 0. | 625 Keeping the right window edge fixed as data arrives and | 626 is acknowledged requires that the receiver offer less | 627 than its full buffer space, i.e., the receiver must | 628 specify a RCV.WND that keeps RCV.NXT+RCV.WND constant | 629 as RCV.NXT increases. Thus, the total buffer space | 630 RCV.BUFF is generally divided into three parts: | 631 |<------- RCV.BUFF ---------------->| | 632 1 2 3 | 633 ----|---------|------------------|------|---- | 634 RCV.NXT ^ | 635 (Fixed) | 636 1 - RCV.USER = data received but not yet consumed; | 637 2 - RCV.WND = space advertised to sender; | 638 3 - Reduction = space available but not yet | 639 advertised. | 640 The suggested SWS avoidance algorithm for the receiver | 641 is to keep RCV.NXT+RCV.WND fixed until the reduction | 642 satisfies: | 643 RCV.BUFF - RCV.USER - RCV.WND >= | 644 min( Fr * RCV.BUFF, Eff.snd.MSS ) | 645 where Fr is a fraction whose recommended value is 1/2, | 646 and Eff.snd.MSS is the effective send MSS for the | 647 connection (see Section 4.2.2.6). When the inequality | 648 is satisfied, RCV.WND is set to RCV.BUFF-RCV.USER. | 649 Note that the general effect of this algorithm is to | 650 advance RCV.WND in increments of Eff.snd.MSS (for | 651 realistic receive buffers: Eff.snd.MSS < RCV.BUFF/2). | 652 Note also that the receiver must use its own | Internet Engineering Task Force [Page 115] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 653 Eff.snd.MSS, assuming it is the same as the sender's. | 654 4.2.3.4 When to Send Data | 655 A TCP MUST include a SWS avoidance algorithm in the sender. | 656 A TCP SHOULD implement the Nagle Algorithm [TCP:9] to | 657 coalesce short segments. However, there MUST be a way for | 658 an application to disable the Nagle algorithm on an | 659 individual connection. In all cases, sending data is also | 660 subject to the limitation imposed by the Slow Start | 661 algorithm (Section 4.2.2.15). | 662 DISCUSSION: | 663 The Nagle algorithm is generally as follows: | 664 If there is unacknowledged data (i.e., SND.NXT > | 665 SND.UNA), then the sending TCP buffers all user | 666 data (regardless of the PSH bit), until the | 667 outstanding data has been acknowledged or until | 668 the TCP can send a full-sized segment (Eff.snd.MSS | 669 bytes; see Section 4.2.2.6). | 670 Some applications (e.g., real-time display window | 671 updates) require that the Nagle algorithm be turned | 672 off, so small data segments can be streamed out at the | 673 maximum rate. | 674 IMPLEMENTATION: | 675 The sender's SWS avoidance algorithm is more difficult | 676 than the receivers's, because the sender does not know | 677 (directly) the receiver's total buffer space RCV.BUFF. | 678 An approach which has been found to work well is for | 679 the sender to calculate Max(SND.WND), the maximum send | 680 window it has seen so far on the connection, and to use | 681 this value as an estimate of RCV.BUFF. Unfortunately, | 682 this can only be an estimate; the receiver may at any | 683 time reduce the size of RCV.BUFF. To avoid a resulting | 684 deadlock, it is necessary to have a timeout to force | 685 transmission of data, overriding the SWS avoidance | 686 algorithm. In practice, this timeout should seldom | 687 occur. | 688 The "useable window" [TCP:5] is: | 689 U = SND.UNA + SND.WND - SND.NXT | 690 i.e., the offered window less the amount of data sent | Internet Engineering Task Force [Page 116] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 691 but not acknowledged. If D is the amount of data | 692 queued in the sending TCP but not yet sent, then the | 693 following set of rules is recommended. | 694 Send data: | 695 (1) if a maximum-sized segment can be sent, i.e, if: | 696 min(D,U) >= Eff.snd.MSS; | 697 (2) or if the data is pushed and all queued data can | 698 be sent now, i.e., if: | 699 [SND.NXT = SND.UNA and] PUSHED and D <= U | 700 (the bracketed condition is imposed by the Nagle | 701 algorithm); | 702 (3) or if at least a fraction Fs of the maximum window | 703 can be sent, i.e., if: | 704 [SND.NXT = SND.UNA and] | 705 min(D.U) >= Fs * Max(SND.WND); | 706 (4) or if data is PUSHed and the override timeout | 707 occurs. | 708 Here Fs is a fraction whose recommended value is 1/2. | 709 The override timeout should be in the range 0.1 - 1.0 | 710 seconds. It may be convenient to combine this timer | 711 with the timer used to probe zero windows (Section | 712 4.2.2.17). | 713 Finally, note that the SWS avoidance algorithm just | 714 specified is to be used instead of the sender-side | 715 algorithm contained in [TCP:5]. | 716 4.2.3.5 TCP Connection Failures | 717 Excessive retransmission of the same segment by TCP | 718 indicates some failure of the remote host or the Internet | 719 path. This failure may be of short or long duration. The | 720 following procedure MUST be used to handle excessive | 721 retransmissions of data segments [IP:11]: | Internet Engineering Task Force [Page 117] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 722 (a) There are two thresholds R1 and R2 measuring the amount | 723 of retransmission that has occurred for the same | 724 segment. R1 and R2 might be measured in time units or | 725 as a count of retransmissions. | 726 (b) When the number of transmissions of the same segment | 727 reaches or exceeds threshold R1, pass negative advice | 728 (see Section 3.3.1.4) to the IP layer, to trigger | 729 dead-gateway diagnosis. | 730 (c) When the number of transmissions of the same segment | 731 reaches a threshold R2 greater than R1, close the | 732 connection. | 733 (d) An application MUST be able to set the value for R2 for | 734 a particular connection. For example, an interactive | 735 application might set R2 to "infinity," giving the user | 736 control over when to disconnect. | 737 (d) TCP SHOULD inform the application of the delivery | 738 problem (unless such information has been disabled by | 739 the application; see Section 4.2.4.1), when R1 is | 740 reached and before R2. This will allow a remote login | 741 (User Telnet) application program to inform the user, | 742 for example. | 743 The value of R1 SHOULD correspond to at least 3 | 744 retransmissions, at the current RTO. The value of R2 SHOULD | 745 correspond to at least 100 seconds. | 746 An attempt to open a TCP connection could fail with | 747 excessive retransmissions of the SYN segment or by receipt | 748 of a RST segment or an ICMP Port Unreachable. SYN | 749 retransmissions MUST be handled in the general way just | 750 described for data retransmissions, including notification | 751 of the application layer. | 752 However, the values of R1 and R2 may be different for SYN | 753 and data segments. In particular, R2 for a SYN segment MUST | 754 be set large enough to provide retransmission of the segment | 755 for at least 3 minutes. The application can close the | 756 connection (i.e., give up on the open attempt) sooner, of | 757 course. | 758 DISCUSSION: | 759 Some Internet paths have significant setup times, and | 760 the number of such paths is likely to increase in the | 761 future. | Internet Engineering Task Force [Page 118] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 762 4.2.3.6 TCP Keep-Alives | 763 Implementors MAY include "keep-alives" in their TCP | 764 implementations, although this practice is not universally | 765 accepted. If keep-alives are included, the application MUST | 766 be able to turn them on or off for each TCP connection, and | 767 they MUST default to off. | 768 Keep-alive packets MUST only be sent when no data or | 769 acknowledgement packets have been received for the | 770 connection within an interval. This interval MUST be | 771 configurable and MUST default to no less than two hours. | 772 It is extremely important to remember that ACK segments that | 773 contain no data are not reliably transmitted by TCP. | 774 Consequently, if a keep-alive mechanism is implemented it | 775 MUST NOT interpret failure to respond to any specific probe | 776 as a dead connection. | 777 An implementation SHOULD send a keep-alive segment with no | 778 data; however, it MAY be configurable to send a keep-alive | 779 segment containing one garbage octet, for compatibility with | 780 erroneous TCP implementations. | 781 DISCUSSION: | 782 A "keep-alive" mechanism periodically probes the other | 783 end of a connection when the connection is otherwise | 784 idle, even when there is no data to be sent. The TCP | 785 specification does not include a keep-alive mechanism | 786 because it could: (1) cause perfectly good connections | 787 to break during transient Internet failures; (2) | 788 consume unnecessary bandwidth ("if no one is using the | 789 connection, who cares if it is still good?"); and (3) | 790 cost money for an Internet path that charges for | 791 packets. | 792 Some TCP implementations, however, have included a | 793 keep-alive mechanism. To confirm that an idle | 794 connection is still active, these implementations send | 795 a probe segment designed to elicit a response from the | 796 peer TCP. Such a segment generally contains SEG.SEQ = | 797 SND.NXT-1 and may or may not contain one garbage octet | 798 of data. Note that on a quiet connection SND.NXT = | 799 RCV.NXT, so that this SEG.SEQ will be outside the | 800 window. Therefore, the probe causes the receiver to | 801 return an acknowledgment segment, confirming that the | 802 connection is still live. If the peer has dropped the | 803 connection due to a network partition or a crash, it | Internet Engineering Task Force [Page 119] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 804 will respond with a RST instead of an acknowledgment | 805 segment. | 806 Unfortunately, some misbehaved TCP implementations fail | 807 to respond to a segment with SEG.SEQ = SND.NXT-1 unless | 808 the segment contains data. Alternatively, an | 809 implementation could determine whether a peer responded | 810 correctly to keep-alive packets with no garbage data | 811 octet. | 812 A TCP keep-alive mechanism should only be invoked in | 813 server applications that might otherwise hang | 814 indefinitely and consume resources unnecessarily if a | 815 client crashes or aborts a connection during a network | 816 failure. | 817 4.2.3.7 TCP Multihoming | 818 If an application on a multihomed host does not specify the | 819 local IP address when actively opening a TCP connection, | 820 then the TCP MUST ask the IP layer to select a local IP | 821 address before sending the (first) SYN. See the function | 822 GET_SRCADDR() in Section 3.4. | 823 At all other times, a previous segment has either been sent | 824 or received on this connection, and TCP MUST use the same | 825 local address is used that was used in those previous | 826 segments. | 827 4.2.3.8 IP Options | 828 When received options are passed up to TCP from the IP | 829 layer, TCP MUST ignore options that it does not understand. | 830 A TCP MAY support the Time Stamp and Record Route options. | 831 An application MUST be able to specify a source route when | 832 it actively opens a TCP connection, and this MUST take | 833 precedence over a source route received in a datagram. | 834 When a TCP connection is OPENed passively and a packet | 835 arrives with a completed IP Source Route option (containing | 836 a return route), TCP MUST save the return route and use it | 837 for all segments sent on this connection. If a different | 838 source route arrives in a later segment, the later | 839 definition SHOULD override the earlier one. | 840 4.2.3.9 ICMP Messages | Internet Engineering Task Force [Page 120] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 841 TCP MUST act on an ICMP error message passed up from the IP | 842 layer, directing it to the connection that created the | 843 error. The necessary demultiplexing information can be | 844 found in the IP header contained within the ICMP message. | 845 o Source Quench | 846 TCP MUST react to a Source Quench by slowing | 847 transmission on the connection. The RECOMMENDED | 848 procedure is for a Source Quench to trigger a "slow | 849 start," as if a retransmission timeout had occurred. | 850 o Destination Unreachable -- codes 0, 1, 5 | 851 Since these Unreachable messages indicate soft error | 852 conditions, TCP MUST NOT abort the connection, and it | 853 SHOULD make the information available to the | 854 application. | 855 DISCUSSION: | 856 TCP could report the soft error condition directly | 857 to the application layer with an upcall to the | 858 ERROR_REPORT routine, or it could merely note the | 859 message and report it to the application only when | 860 and if the TCP connection times out. | 861 o Destination Unreachable -- codes 2-4 | 862 These are hard error conditions, so TCP SHOULD abort | 863 the connection. | 864 o Time Exceeded -- codes 0, 1 | 865 This should be handled the same way as Destination | 866 Unreachable codes 0, 1, 5 (see above). | 867 o Parameter Problem | 868 This should be handled the same way as Destination | 869 Unreachable codes 0, 1, 5 (see above). | 870 4.2.3.10 Remote Address Validation | 871 A TCP implementation MUST reject as an error a local OPEN | 872 call for an invalid remote IP address (e.g., a broadcast or | 873 multicast address). | Internet Engineering Task Force [Page 121] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 874 An incoming SYN with an invalid source address must be | 875 ignored either by TCP or by the IP layer (see Section | 876 3.2.1.3). | 877 A TCP implementation MUST silently discard an incoming SYN | 878 segment that is addressed to a broadcast or multicast | 879 address. | 880 4.2.3.11 TCP Traffic Patterns | 881 IMPLEMENTATION: | 882 The TCP protocol specification [TCP:1] gives the | 883 implementor much freedom in designing the algorithms | 884 that control the message flow over the connection -- | 885 packetizing, managing the window, sending | 886 acknowledgments, etc. These design decisions are | 887 difficult because a TCP must adapt to a wide range of | 888 traffic patterns. Experience has shown that a TCP | 889 implementor needs to verify the design on two extreme | 890 traffic patterns: | 891 o Single-character Segments | 892 Even if the sender is using the Nagle Algorithm, | 893 when a TCP connection carries remote login traffic | 894 across a low-delay LAN the receiver will generally | 895 get a stream of single-character segments. If | 896 remote terminal echo mode is in effect, the | 897 receiver's system will generally echo each | 898 character as it is received. | 899 o Bulk Transfer | 900 When TCP is used for bulk transfer, the data | 901 stream should be made up (almost) entirely of | 902 segments of the size of the effective MSS. | 903 Although TCP uses a sequence number space with | 904 byte (octet) granularity, in bulk-transfer mode | 905 its operation should be as if TCP used a sequence | 906 space that counted only segments. | 907 Experience has furthermore shown that a single TCP can | 908 effectively and efficiently handle these two extremes. | 909 The most important tool for verifying a new TCP | 910 implementation is a packet trace program. There is a | 911 large volume of experience showing the importance of | 912 tracing a variety of traffic patterns with other TCP | Internet Engineering Task Force [Page 122] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 913 implementations and studying the results carefully. | 914 4.2.3.12 Efficiency | 915 IMPLEMENTATION: | 916 Extensive experience has led to the following | 917 suggestions for efficient implementation of TCP: | 918 (a) Don't Copy Data | 919 In bulk data transfer, the primary CPU-intensive | 920 tasks are copying data from one place to another | 921 and checksumming the data. It is vital to | 922 minimize the number of copies of TCP data. Since | 923 the ultimate speed limitation may be fetching data | 924 across the memory bus, it may be useful to combine | 925 the copy with checksumming, doing both with a | 926 single memory fetch. | 927 (b) Hand-Craft the Checksum Routine | 928 A good TCP checksumming routine is typically two | 929 to five times faster than a simple and direct | 930 implementation of the definition. Great care and | 931 clever coding are often required and advisable to | 932 make the checksumming code "blazing fast". See | 933 [TCP:10]. | 934 (c) Code for the Common Case | 935 TCP protocol processing can be complicated, but | 936 for most segments there are only a few simple | 937 decisions to be made. Per-segment processing will | 938 be greatly speeded up by coding the main line to | 939 minimize the number of decisions in the most | 940 common case. | 941 4.2.4 TCP/APPLICATION LAYER INTERFACE | 942 4.2.4.1 Asynchronous Reports | 943 There MUST be a mechanism for reporting soft TCP error | 944 conditions to the application. Generically, we assume this | 945 takes the form of an application-supplied ERROR_REPORT | 946 routine that may be upcalled [INTRO:7] asynchronously from | 947 the transport layer: | Internet Engineering Task Force [Page 123] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 948 ERROR_REPORT(local connection name, reason, subreason) | 949 The precise encoding of the reason and subreason parameters | 950 is not specified here. However, the conditions that are | 951 reported asynchronously to the application MUST include: | 952 * ICMP error message arrived (see 4.2.3.9) | 953 * Excessive retransmissions (see 4.2.3.5) | 954 * Urgent pointer advance (see 4.2.2.4). | 955 However, an application program that does not want to | 956 receive such ERROR_REPORT calls SHOULD be able to | 957 effectively disable these calls. | 958 DISCUSSION: | 959 These error reports generally reflect soft errors that | 960 can be ignored without harm by many applications. It | 961 has been suggested that these error report calls should | 962 default to "disabled," but this is not required. | 963 4.2.4.2 Type-of-Service | 964 The application layer MUST be able to specify the Type-of- | 965 Service (TOS) for segments that are sent on a connection. | 966 It not required, but the application SHOULD be able to | 967 change the TOS during the connection lifetime. TCP SHOULD | 968 pass the current TOS value without change to the IP layer, | 969 when it sends segments on the connection. | 970 The TOS will be specified independently in each direction on | 971 the connection, so that the receiver application will | 972 specify the TOS used for ACK segments. | 973 TCP MAY pass the most recently received TOS up to the | 974 application. | 975 DISCUSSION | 976 Some applications (e.g., SMTP) change the nature of | 977 their communication during the lifetime of a | 978 connection, and therefore would like to change the TOS | 979 specification. | 980 Note also that the OPEN call specified in RFC-793 | 981 includes a parameter ("options") in which the caller | 982 can specify IP options such as source route, record | 983 route, or timestamp. | Internet Engineering Task Force [Page 124] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 984 4.2.4.3 Flush Call | 985 Some TCP implementations have included a FLUSH call, which | 986 will empty the TCP send queue of any data for which the user | 987 has issued SEND calls but which is still to the right of the | 988 current send window. That is, it flushes as much queued | 989 send data as possible without losing sequence number | 990 synchronization. This is useful for implementing the "abort | 991 output" function of Telnet. | 992 4.2.4.4 Multihoming | 993 The user interface outlined in sections 2.7 and 3.8 of RFC- | 994 793 needs to be extended for multihoming. The OPEN call | 995 MUST have an optional parameter: | 996 OPEN( ... [local IP address,] ... ) | 997 to allow the specification of the local IP address. | 998 DISCUSSION: | 999 Some TCP-based applications need to specify the local | 1000 IP address to be used to open a particular connection; | 1001 FTP is an example. | 1002 IMPLEMENTATION: | 1003 A passive OPEN call with a specified "local IP address" | 1004 parameter will await an incoming connection request to | 1005 that address. If the parameter is unspecified, a | 1006 passive OPEN will await an incoming connection request | 1007 to any local IP address, and then bind the local IP | 1008 address of the connection to the particular address | 1009 that is used. | 1010 For an active OPEN call, a specified "local IP address" | 1011 parameter will be used for opening the connection. If | 1012 the parameter is unspecified, the networking software | 1013 will choose an appropriate local IP address (see | 1014 Section 3.3.4.2) for the connection | 1015 [INTRO:1] "Requirements for Internet Hosts -- Application and Support,"| 1016 IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123,| 1017 October 1989. | 1018 [INTRO:6] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May| 1019 1987. | 1020 This document is republished periodically with new RFC numbers; the| Internet Engineering Task Force [Page 125] INTERNET-DRAFT TRANSPORT LAYER March 6, 1991 1021 latest version must be used. | 1022 [INTRO:7] "Modularity and Efficiency in Protocol Implementations," D.| 1023 Clark, RFC-817, July 1982. | 1024 [IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM| 1025 SIGCOMM-87, August 1987. Published as ACM Comp Comm Review, Vol.| 1026 17, no. 5. | 1027 This useful paper discusses the problems created by Internet | 1028 fragmentation and presents alternative solutions. | 1029 [IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982.| 1030 [TCP:1] "Transmission Control Protocol," J. Postel, RFC-793, September| 1031 1981. | 1032 [TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel,| 1033 RFC-879, November 1983. | 1034 [TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC-813,| 1035 July 1982. | 1036 [TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM | 1037 SIGCOMM-87, August 1987. | 1038 [TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,| 1039 August 1988. | 1040 [TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984.| 1041 [TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C.| 1042 Partridge, RFC-1071, September 1988. | 1043 [TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden,| 1044 RFC-1072, October 1988. | Internet Engineering Task Force [Page 126] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 07. APPLICATION LAYER -- ROUTING PROTOCOLS 1 SOURCE: 2 Chapter 7 source: new text, contributor: Jeffrey Burgan. 3 Relationship to HRRFC: none 0 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? | 0 7.2 INTERIOR GATEWAY PROTOCOLS 0 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 Internet Engineering Task Force [Page 127] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 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 EDITOR'S COMMENTS: 25 This space reserved for text from the IESG or the IAB 26 which decrees which IGPs MUST, SHOULD, and MAY be 27 implemented. 0 7.2.2 OPEN SHORTEST PATH FIRST -- OSPF 0 7.2.2.1 Introduction 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 4 since the inception of the ARPANet, it is only recently that 5 they have achieved popularity both inside the IP as well as 6 the OSI communities. In an SPF based system, each router 7 obtains an exact replica of the entire topology database via 8 a process known as flooding, which insures a reliable 9 transfer of the information. Each individual router then 10 runs the SPF algorithm on its database to build the IP 11 routing table. The OSPF routing protocol is an 12 implementation of an SPF algorithm. The current version, | 13 OSPF version 2, is specified in [ROUTE:1]. Note that RFC- | 14 1131, which describes OSPF version 1, is obsolete. | 0 7.2.2.2 Protocol Walk-through | 1 SOURCE: | 2 Section 7.2.2.2 source: new text, contributor: Philip | 3 Almquist | 4 Bullet items taken from Rob Coltun's mail message to | 5 the ietf-rreq list | 6 The following problems in the OSPF specification were noted | 7 during interoperability testing: | 8 o The specification should say that the "Network mask" | 9 field should not be verified in OSPF Hellos received | 10 over virtual links. | Internet Engineering Task Force [Page 128] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 11 o The specification should say that on multi-access | 12 networks neighbors are identified by their IP address, | 13 and on point-to-point networks and virtual links by | 14 their OSPF Router ID. This eliminates confusion when, | 15 for example, a router is restarted and comes up with | 16 the same IP address but a different Router ID. | 0 7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM -- DUAL IS-IS 0 7.2.3.1 Introduction 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- 5 Domain Routing Exchange Protocol". Its application to an IP 6 network has been defined in [ROUTE:2], and is referred to as 7 Dual IS-IS. IS-IS is based on a link state (SPF) routing 8 algorithm and shares all the advantages for this class of 9 protocols. 0 7.2.4 ROUTING INFORMATION PROTOCOL -- RIP 0 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. 0 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 SHOULD wait a minimum of six times the * 7 update interval before invalidating a route. * Internet Engineering Task Force [Page 129] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 8 Split Horizon: RFC-1058, pp. 14-15 9 An implementation of RIP MUST implement "split horizon", 10 which is is a scheme used for avoiding problems caused by 11 including routes in updates sent to the router from which 12 they were learned. 13 "Split horizon with poisoned reverse" SHOULD be 14 implemented which includes routes learned from a router 15 sent to that router, but sets their metric to infinity. * 16 Because of the routing overhead which may be incurred by * 17 implementing split horizon with poisoned reverse, * 18 implementations MAY include an option to select whether * 19 poisoned reverse is in effect. Also, an implementation | 20 SHOULD limit the period of time in which it sends reverse | 21 routes at an infinite metric. | 22 Triggered updates: RFC-1058, pp. 15-16; pp. 29 23 Triggered updates is a method for immediately notifying a * 24 routers' neighbors when the router changes the metric for * 25 one of its routes. Since triggered updates can cause * 26 excessive routing overhead, implementations MUST include * 27 provisions for limiting the frequency of updates. If * 28 triggered updates are implemented, a timer MUST be set * 29 for a random time between 1 and 5 seconds. An update is * 30 sent when the timer expires unless a regular update is * 31 due by that time. * 32 Triggered updates MUST NOT include routes that have not | 33 changed since the most recent regular (non-triggered) | 34 update. | 35 DISCUSSION: | 36 Sending all routes, whether they have changed | 37 recently or not, is unacceptable in triggered | 38 updates because the tremendous size of many Internet | 39 routing tables could otherwise result in | 40 considerable bandwidth being wasted on triggered | 41 updates. | 42 Use of UDP: RFC-1058, pp. 18-19. | 43 A RIP implementation MUST include a valid, non-zero UDP | 44 checksum in all RIP protocol packets it originates. | 45 Simularly, a RIP implementation MUST verify the UDP | 46 checksum of any received RIP protocol packet before | 47 acting on its contents. | Internet Engineering Task Force [Page 130] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 48 Any RIP protocol packet sent to an IP broadcast address | 49 SHOULD have its initial TTL set to one. | 50 EDITOR'S COMMENTS: | 51 Perhaps the checksum requirements should be in the | 52 UDP section (and thus apply to all UDP-based | 53 protocols) rather than here. | 54 What should a RIP implementation do if it receives | 55 an update which has no checksum? | 56 Addressing Considerations: RFC-1058, pp. 22 57 A RIP implementation SHOULD support host routes. If it | 58 does not, it MUST (as described on page 27 of [ROUTE:3]) | 59 ignore (but MAY log) host routes in received updates. | 60 The special address 0.0.0.0 is used to describe a default 61 route. A default route is used as the route of last 62 resort (i.e. when a route to the specific net does not 63 exist in the routing table). The router MUST be able to 64 create a RIP entry for the address 0.0.0.0. 65 Input Processing - Response: RFC-1058, pp. 26 * 66 When processing an update, the following validity checks * 67 MUST be performed. The response MUST be from UDP port * 68 520. The source address MUST be on a directly connected * 69 network to be considered valid. Also, if an interface on * 70 a broadcast network receives its own broadcasts, these * 71 updates MUST NOT be used in route processing. * 72 An implementation MUST NOT replace an existing route if * 73 the metric received is equal to the existing metric * 74 except in accordance with the following heuristic. * 75 An implementation MAY choose to implement the following * 76 heuristic to deal with the above situation. Normally, it * 77 is useless to change the route to a network from one * 78 router to another if both are advertised at the same * 79 metric. However, the route being advertised by one of the * 80 routers may be in the process of timing out. Instead of * 81 waiting for the route to timeout (180 seconds), the new * 82 route can be used after a specified amount of time has * 83 elapsed. If this heuristic is implemented, it MUST wait * 84 at least halfway to the expiration point before the new * 85 route is installed. * Internet Engineering Task Force [Page 131] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 0 7.2.4.3 Specific Issues | 1 SOURCE: | 2 Section 7.2.4.3 source: new text, contributor: Jeff | 3 Honig | 4 RIP Shutdown | 5 An implementation of RIP SHOULD provide for a graceful | 6 shutdown. This is accomplished by first terminating | 7 input processing. Then four updates at random intervals | 8 of between two and four seconds should be generated. | 9 These updates contain all routes that were previously | 10 announced, but with some metric changes. Routes that | 11 were being announced at a metric of infinity should | 12 continue to use this metric. Routes that had been | 13 announced with a non-infinite metric should be announced | 14 with a metric of 15 (infinity - 1). | 15 DISCUSSION: | 16 The metric used for the above really ought to be 16 | 17 (infinity); setting it to 15 is a kluge to avoid | 18 breaking certain old hosts which wiretap the RIP | 19 protocol and which abort a TCP connections if it | 20 tries to send a packet while the host has no route | 21 to the destination (even if the period when the host | 22 has no route lasts only a few seconds). | 23 RIP Split Horizon and Static Routes | 24 Split horizon SHOULD be applied to static routes by | 25 default. An implementation SHOULD provide to way | 26 specify, per static route, that split horizon should not | 27 be applied to this route. | 0 7.2.5 GATEWAY TO GATEWAY PROTOCOL -- GGP 1 The Gateway to Gateway protocol is considered obsolete and | 2 should not be implemented. | 0 7.3 EXTERIOR GATEWAY PROTOCOLS 0 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 Internet Engineering Task Force [Page 132] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 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 Border Gateway 7 Protocol has recently been proposed after much discussion as a 8 way of addressing many of the restrictions and limitations of 9 EGP. 10 Although it was not designed as an exterior gateway protocol, * 11 RIP (described in Section [7.2.4]) is sometimes used for * 12 inter-AS routing. * 0 7.3.2 BORDER GATEWAY PROTOCOL -- BGP 0 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. A router which | 11 supports both BGP and SNMP SHOULD support the BGP MIB | 12 defined in [ROUTE:6]. | 13 SOURCE: 14 next 2 paragraphs, source: new text, contributor: Yakov 15 Rekhter. 16 The primary function of a BGP speaking system is to exchange 17 network reachability information with other BGP systems. 18 This network reachability information includes information 19 on the full path of Autonomous Systems (ASs) that traffic 20 must transit to reach these networks. This information is 21 sufficient to construct a graph of AS connectivity from 22 which routing loops may be pruned and some policy decisions 23 at the AS level may be enforced. 24 To characterize the set of policy decisions that can be 25 enforced using BGP, one must focus on the rule that an AS 26 advertize to its neighbor ASs only those routes that it 27 itself uses. This rule reflects the "hop-by-hop" routing 28 paradigm generally used throughout the current Internet. Internet Engineering Task Force [Page 133] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 29 Note that some policies cannot be supported by the "hop-by- 30 hop" routing paradigm and thus require techniques such as 31 source routing to enforce. For example, BGP does not enable 32 one AS to send traffic to a neighbor AS intending that that 33 traffic take a different route from that taken by traffic 34 originating in the neighbor AS. On the other hand, BGP can 35 support any policy conforming to the "hop-by-hop" routing 36 paradigm. 37 Implementors of BGP are strongly encouraged to follow the | 38 recommendations outlined in Section 6 of RFC1164. Since BGP | 39 uses TCP as a transport, TCP implementation must conform to | 40 the Host Requirements RFC. | 41 EDITOR'S COMMENTS: | 42 The previous sentence should probably be struck once | 43 the Transport Layer chapter is written. | 44 While BGP provides support for quite complex routing | 45 policies (as an example see Section 4.2 in RFC1164), it is | 46 not required for all BGP implementors to support such | 47 policies. While not attempting to standardize on the routing | 48 policies that must be supported in every BGP implementation, | 49 we strongly encourage all implementors to support the | 50 following set of routing policies: | 51 (1) BGP implementation should allow an AS to control | 52 announcements of the BGP learned routes to adjacent | 53 AS's. Implementors should support such control with at | 54 least the granularity of a single network. Implementors | 55 should also support such control with the granularity | 56 of an autonomous system, where the autonomous system | 57 may be either the autonomous system that originated the | 58 route, or the autonomous system that advertised the | 59 route to the local system (adjacent autonomous system). | 60 (2) BGP implementation should allow an AS to prefer a | 61 particular path to a destination (when more than one | 62 path is available). Such function should be implemented | 63 by allowing system administrator to assign "weights" to | 64 Autonomous Systems, and making route selection process | 65 to select a route with the lowest "weight" (where | 66 "weight" of a route is defined as a sum of "weights" of | 67 all AS's in the AS_PATH path attribute associated with | 68 that route). | 69 (3) BGP implementation should allow an AS to ignore routes | 70 with certain AS's in the AS_PATH path attribute. Such | Internet Engineering Task Force [Page 134] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 71 function can be implemented by using technique outlined | 72 in (2), and by assigning "infinity" as "weights" for | 73 such AS's. The route selection process must ignore | 74 routes that have "weight" equal to "infinity". | 0 7.3.2.2 Protocol Walk-through 1 No known problems - experimental protocol 0 7.3.3 EXTERIOR GATEWAY PROTOCOL -- EGP 0 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]. Useful background information | 11 can be found in [ROUTE:8] and [ROUTE:9]. | 12 DISCUSSION: 13 The present EGP specification, as defined in RFC-904 14 has serious limitations, most importantly a restriction 15 which limits routers to advertising only those networks 16 which are reachable from within the router's autonomous 17 system. This restriction against propagating "third 18 party" EGP information is to prevent long-lived routing 19 loops. This effectively limits EGP to a two-level 20 hierarchy. 21 RFC-975 is not a part of the EGP specification, and 22 should be ignored. 0 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. Internet Engineering Task Force [Page 135] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 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. 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 SOURCE: | 12 The remainder of this section was contributed by | 13 Jeff Honig | 14 Network Reachability: RFC-904, pp. 15 | 15 An implementation MUST default to not providing the | 16 external list of gateways in other autonomous systems; | 17 only the internal list of gateways together with the nets | 18 which are reachable via those gateways should be included | 19 in an Update Response/Indication packet. However, an | 20 implementation MAY elect to provide a configuration | 21 option enabling the external list to be provided. An | 22 implementation MUST NOT include in the external list | 23 gateways which were learned via the external list | 24 provided by a gateway in another autonomous system. An | 25 implementation MUST NOT send a network back to the | 26 autonomous system from which it is learned, i.e. it MUST | 27 do split-horizon on an autonomous system level. | 28 If more than 255 internal or 255 external gateways need | 29 to be specified in a Network Reachability update, the | 30 networks reachable from gateways that can not be listed | 31 MUST be merged into the list for a single gateway. This | 32 gateway SHOULD be user configurable, but should default | 33 to the address of this gateway. | 34 Unsolicited Updates: RFC-904, pp. 16 | 35 If a network is shared with this peer, an implementation | 36 MUST send an unsolicited update upon entry to the Up | 37 state assuming that the source network is the shared | 38 network. | 39 Neighbor Reachability: RFC-904, pp. 6, 14, 15 | 40 The table describing the values of j and k (the neighbor | 41 up and down thresholds) is incorrect. It is reproduced | Internet Engineering Task Force [Page 136] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 42 correctly here: | 43 Name Active Passive Description | 44 ----------------------------------------------- | 45 j 3 1 neighbor-up threshold | 46 k 1 0 neighbor-down threshold | 47 The value for k in passive mode also specified | 48 incorrectly in RFC-904, pp. 14 The values in parenthesis | 49 should read: | 50 (j = 1. k = 0 and T3/T1 = 4) | 51 If an implementation defaults to not sending a Hello | 52 command when a Poll is due, it SHOULD provide a user | 53 configurable option to disable this optimization. | 54 Abort timer: RFC-904, pp. 6, 12, 13 | 55 An EGP implementation MUST include support for the abort | 56 timer (as documented in section 4.1.4). An | 57 implementation SHOULD use the abort timer in the Idle | 58 state to automatically issue a Start event to restart the | 59 protocol machine. Recommended values are P4 for a | 60 critical error (Administratively prohibited, Protocol | 61 Violation and Parameter problem) and P5 for all others. | 62 The abort timer SHOULD NOT be started when a Stop event | 63 was manually initiated (such as via a network management | 64 protocol). | 65 Cease command received in Idle state: RFC-904, pp. 13 | 66 When the EGP state machine is in the Idle state, it MUST | 67 reply to Cease commands with a Cease-ack response. | 68 Hello Polling Mode: RFC-904, pp. 11 | 69 An EGP implementation MUST include support for both | 70 active and passive polling modes. | 71 Neighbor Acquisition Messages: RFC-904, pp. 18 | 72 As noted the Hello and Poll Intervals should only be | 73 present in Request and Confirm messages. Therefore the | 74 length of an EGP Neighbor Acquisition Message is 14 | 75 octets for a Request or Confirm message and 10 octets for | 76 a Refuse, Cease or Cease-ack message. Implementations | 77 MUST NOT send 14 octets for Refuse, Cease or Cease-ack | Internet Engineering Task Force [Page 137] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 78 messages but MUST allow for implementations that send 14 | 79 octets for these messages. | 80 Sequence Numbers: RFC-904, pp. 10 | 81 Response or indication packets received with a sequence | 82 number not equal to S MUST be discarded. The send | 83 sequence number S MUST be incremented just before the | 84 time a Poll command is sent and at no other times. 0 7.3.4 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL * 1 SOURCE: * 2 Section 7.3.4 source: new text, contributor: Kent England * 3 Relation to HRRFC: none * 4 It is possible to exchange routing information between two * 5 autonomous systems or routing domains without using a standard * 6 exterior routing protocol between two separate, standard * 7 interior routing protocols. The most common way of doing this * 8 is to run both interior protocols independently in one of the * 9 border routers with an exchange of route information between * 10 the two processes. * 11 As with the exchange of information from an EGP to an IGP, * 12 without appropriate controls these exchanges of routing * 13 information between two IGPs in a single router are subject to * 14 creation of routing loops. * 0 7.4 STATIC ROUTING 1 Static routing provides a means of explicitly defining the next * 2 hop from a router for a particular network. A router SHOULD * 3 provide a means for defining a static route along with a metric. * 4 A router which supports a dynamic routing protocol MUST allow 5 static routes to be defined with any metric valid for the routing 6 protocol used. The router MUST provide the ability for the user 7 to specify a list of static routes which may or may not be 8 propagated via the routing protocol. 9 Whether a router prefers a static route over a dynamic route (or * 10 vice versa) or whether the associated metrics are used to choose * 11 between conflicting static and dynamic routes SHOULD be * 12 configurable for each static route. * Internet Engineering Task Force [Page 138] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 0 7.5 FILTERING OF ROUTING INFORMATION 1 SOURCE: 2 Section 7.5 source: new text, contributor: Michael Reilly, 3 with Philip Almquist, Vince Fuller, and Milo Medin. 4 Relationship to HRRFC: none 5 Each router within a network makes forwarding decisions based upon 6 information contained within its forwarding database. In a simple 7 network the contents of the database may be statically configured. 8 As the network grows more complex, the need for dynamic updating 9 of the forwarding database becomes critical to the efficient 10 operation of the network. 11 If the data flow through a network is to be as efficient as 12 possible, it is necessary to provide a mechanism for controlling 13 the propagation of the information a router uses to build its 14 forwarding database. This control takes the form of choosing 15 which sources of routing information should be trusted and 16 selecting which pieces of the information to believe. The 17 resulting forwarding database is a filtered version of the 18 available routing information. 19 In addition to efficiency, controlling the propagation of routing 20 information can reduce instability by preventing the spread of 21 incorrect or bad routing information. 22 In some cases local policy may require that complete routing 23 information not be widely propagated. 0 7.5.1 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 choosing to whom to listen and what to believe. 4 In order to do this a router MUST provide the ability to 5 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 Internet Engineering Task Force [Page 139] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 13 provide the ability to specify 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. 0 7.5.2 Advanced Route Filtering 1 As the topology of a network grows more complex, the need for 2 more complex route filtering arises. In order to provide * 3 stability and efficient forwarding of packets, the router * 4 SHOULD provide the ability to specify independently for each * 5 routing protocol: * 6 o which logical interfaces or routers routing information 7 (routes) will be accepted from and which routes will be 8 believed from each host or logical interface. 9 o which routes will be sent via which logical interface(s). 10 o which routers routing information will be sent to, if this 11 is supported by the routing protocol in use. 12 In many situations it is desirable to assign a reliability 13 ordering to routing information received from another router 14 instead of the simple believe or don't believe choice listed in 15 the first bullet above. A router MAY provide the ability to 16 specify: 17 o a reliability or preference to be assigned to each route 18 received from a host. A route with higher reliability 19 will be chosen over one with lower reliability regardless 20 of the routing metric associated with each route. 21 If a router supports assignment of preferences, the router MUST 22 NOT propagate any routes it does not prefer as first party 23 information. If the routing protocol being used to propagate 24 the routes does not support distinguishing between first and 25 third party information, the router MUST NOT propogate any 26 routes it does not prefer. 27 For example, assume a router receives a route to network C from 28 router R and a route to the same network from router S. If Internet Engineering Task Force [Page 140] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 1991 29 router R is considered more reliable than router S traffic 30 destined for network C will be forwarded to router R regardless 31 of the route received from router S. 32 Routing information for routes which the router does not use * 33 (router S in the above example) MUST NOT be passed to any other * 34 router. * 0 7.6 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE 1 SOURCE: 2 Section 7.6 source: new text, contributor: Kent England 3 Relation to HRRFC: none 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 141] INTERNET-DRAFT ROUTING PROTOCOLS March 6, 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. * 0 7.7 REQUIREMENTS SUMMARY 1 TBD Internet Engineering Task Force [Page 142] INTERNET-DRAFT NETWORK MANAGEMENT PROTOCOLS March 6, 1991 08. APPLICATION LAYER -- NETWORK MANAGEMENT PROTOCOLS 1 EDITOR'S COMMENTS: 2 This chapter will cover SNMP, and perhaps CMIP/CMOT if there is 3 interest. 4 TBD Internet Engineering Task Force [Page 143] INTERNET-DRAFT MISCELLANEOUS APPLICATION PROTOCOLS March 6, 1991 09. APPLICATION LAYER -- MISCELLANEOUS PROTOCOLS 1 EDITOR'S COMMENTS: 2 This chapter will cover other application layer protocols 3 commonly used by routers, such as Telnet and TFTP. It is 4 expected to consist largely of pointers to RFC-1123. 0 9.1 Bootstrap Protocol (BOOTP) | 1 SOURCE: | 2 Section 9.1 source: new text (+ bits of RFC-951 and RFC- | 3 1054), contributor: Walt Wimer | 4 Relationship to HRRFC: believed consistent with RFC-1123 | 5 section 6.2.2 | 0 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]). | 11 In many cases, BOOTP clients and their associated BOOTP | 12 server(s) do not reside on the same IP network or subnet. In | 13 such cases, a "BOOTP forwarding agent" is required to transfer | 14 BOOTP messages between clients and servers. This forwarding- | 15 agent functionality is most conveniently located in the routers | 16 which interconnect the clients and servers. | 17 Any Internet router which wishes to provide BOOTP forwarding- | 18 agent capability must conform to the following specification. | 19 This section uses the following terms: | 20 BOOTREQUEST | 21 A BOOTREQUEST is a BOOTP message (encapsulated within UDP) | 22 whose opcode is 1 (BOOTREQUEST). | 23 BOOTREPLY | 24 A BOOTREPLY is a BOOTP message (encapsulated within UDP) | 25 whose opcode is 2 (BOOTREPLY). | Internet Engineering Task Force [Page 144] INTERNET-DRAFT MISCELLANEOUS APPLICATION PROTOCOLS March 6, 1991 0 9.1.2 BOOTP Processing | 1 NOTE: | 2 Although the term "forwarding" is applied throughout this | 3 section, it must be understood that "forwarding" in the | 4 context of BOOTP is distinct from a router's normal IP | 5 forwarding function (whose task is to switch packets | 6 more-or-less transparently between networks). A BOOTP | 7 forwarder may more properly be thought to receive BOOTP | 8 messages as a final destination and then generate new | 9 BOOTP messages as a result. One should resist the notion | 10 of simply sending a BOOTP message through like a "regular | 11 packet." | 12 CONTRIBUTOR'S COMMENTS: | 13 Is this note just more confusing? Insulting to one's | 14 intelligence? | 15 Section [5.2.3] discussed the circumstances under which a | 16 packet is delivered locally (to the router). All locally | 17 delivered UDP messages whose UDP destination port number is | 18 BOOTPS (67) are considered for special processing by the | 19 router's logical BOOTP forwarding agent. | 20 CONTRIBUTOR'S COMMENTS: | 21 What is the convention for referencing UDP port numbers? | 22 Should this be a pointer to Assigned Numbers? | 23 Section [5.3.7] discussed "Martian Address Filtering." | 24 According to these rules a router should not forward packets | 25 whose IP source address is 0.0.0.0. However, routers which | 26 support a BOOTP forwarding agent MUST accept for local delivery | 27 to the forwarding agent BOOTREQUEST messages whose IP source | 28 address is 0.0.0.0. | 29 CONTRIBUTOR'S COMMENTS: | 30 Should Section [5.3.7] be amended to explicitly permit | 31 local delivery of IP source == 0.0.0.0 datagrams? Or is | 32 the above statement in the BOOTP section the right thing | 33 to do? | 34 DISCUSSION: | 35 Ideally, a router would properly participate in the BOOTP | 36 protocol when it forwarded ANY BOOTP message. | 37 Realistically, this is impractical since it would have a | 38 negative impact on overall router performance (since the | 39 router would have to examine higher-level protocol headers | 40 on each and every datagram). Therefore, this document | Internet Engineering Task Force [Page 145] INTERNET-DRAFT MISCELLANEOUS APPLICATION PROTOCOLS March 6, 1991 41 only specifies required behavior when a router receives | 42 BOOTP messages for local delivery. | 43 The following consistency checks SHOULD be performed on BOOTP | 44 messages: | 45 o The IP Total Length and UDP Length must be large enough to | 46 contain the minimal BOOTP header of 300 octets (in the UDP | 47 data field) specified in [APPL:1]. | 48 Because future extensions to the BOOTP protocol may | 49 increase the size of BOOTP messages. Therefore, BOOTP | 50 messages which, according to the IP Total Length and UDP | 51 Length fields, are larger than the minimum size specified | 52 by [APPL:1] MUST also be accepted. | 53 o The 'op' (opcode) field of the message must contain either | 54 the code for a BOOTREQUEST (1) or the code for a BOOTREPLY | 55 (2). | 56 BOOTP messages not meeting these consistency checks MUST be | 57 silently discarded. | 58 CONTRIBUTOR'S COMMENTS: | 59 Should the consistency checks be a MUST? If they remain a | 60 SHOULD, the "MUST be silently discarded" sentence doesn't | 61 make much sense. | 0 9.1.3 BOOTREQUEST Messages | 1 Routers SHOULD provide some configuration mechanism for | 2 enabling or disabling the forwarding of BOOTREQUEST messages. | 3 CONTRIBUTOR'S COMMENTS: | 4 Should we require this to default to something (most | 5 likely "off")? | 6 When the router's BOOTP forwarding agent receives a BOOTREQUEST | 7 message, it MAY use the value of the 'secs' (seconds since | 8 client began booting) field of the request as a factor in | 9 deciding whether to forward the request. If such a policy | 10 mechanism is implemented, its threshold SHOULD be configurable. | 11 DISCUSSION: | 12 To date, this feature of the BOOTP protocol has not | 13 necessarily been shown to be useful. The definition of | 14 the represents the time since the first BOOTREQUEST was | Internet Engineering Task Force [Page 146] INTERNET-DRAFT MISCELLANEOUS APPLICATION PROTOCOLS March 6, 1991 15 sent or some other time period such as the time since the | 16 client machine was powered-up. (The former definition is | 17 probably the most useful from a protocol standpoint.) | 18 Furthermore, certain client implementations have been | 19 known to simply set this field to a constant value or use | 20 incorrect byte-ordering (usually resulting in very | 21 inflated figures). | 22 The forwarding agent SHOULD silently discard requests whose | 23 configurable. | 24 CONTRIBUTOR'S COMMENTS: | 25 Should we recommend some reasonable default value for this | 26 threshold? 3? 5? | 27 If the router does decide to forward the request, it MUST | 28 examine the 'giaddr' (gateway IP address) field. If this field | 29 is zero, the router MUST fill this field with the IP address of | 30 the logical interface on which the request was received. If | 31 the 'giaddr' field contains some non-zero value, the 'giaddr' | 32 field MUST NOT be modified. | 33 The value of the 'hops' field SHOULD be incremented. | 34 CONTRIBUTOR'S COMMENTS: | 35 Should this be a MUST? | 36 All other fields MUST be preserved intact. | 37 At this point, the request is forwarded to its new destination | 38 (or destinations). This destination MUST be configurable. | 39 Further, this destination configuration SHOULD be independent | 40 of the destination configuration for any other "broadcast | 41 forwarders" (e.g. for the UDP-based TFTP, DNS, Time, etc. | 42 protocols). | 43 DISCUSSION: | 44 The network manager may wish the forwarding destination to | 45 be an IP unicast, multicast, broadcast, or some | 46 combination. A configurable list of destination IP | 47 addresses provides good flexibility. More flexible | 48 configuration schemes are encouraged. For example, it may | 49 be desirable to send to the limited broadcast address on | 50 specific logical interfaces. As noted in Section [5.3.5], | 51 however, a router MUST NOT forward any broadcast to the | 52 logical interface from whence it came. | 53 The IP source address of the forwarded request MUST be set to | Internet Engineering Task Force [Page 147] INTERNET-DRAFT MISCELLANEOUS APPLICATION PROTOCOLS March 6, 1991 54 the IP address of one of the router's logical interfaces. It | 55 is RECOMMENDED that this be the IP address of the interface on | 56 which the original request was received. | 57 When transmitting the request to its next destination, the | 58 forwarding agent may set the IP time-to-live field to either | 59 the default value for new datagrams originated by the router, | 60 or to a value derived from the received request (i.e. the IP | 61 TTL of original request datagram minus one). This | 62 specification takes no stand on this issue. | 63 CONTRIBUTOR'S COMMENTS: | 64 It is probably better to use the decremented TTL from the | 65 request, but this may be difficult under certain | 66 implementations. How do others feel? | 67 The UDP checksum must be recalculated before transmitting the | 68 request. | 0 9.1.4 BOOTREPLY Messages | 1 BOOTREPLY messages are forwarded only to BOOTP clients. Since | 2 it is the responsibility of BOOTP servers to send BOOTREPLY | 3 messages directly to the router closest to a given client, a | 4 router may assume that all BOOTREPLY messages it receives are | 5 intended for BOOTP clients on the router's directly-connected | 6 networks. | 7 When a router receives a BOOTREPLY message, it should examine | 8 the BOOTP 'giaddr', 'yiaddr', 'chaddr', 'htype', and 'hlen' | 9 fields. These fields should provide adequate information for a | 10 router to deliver the BOOTREPLY message to the client. | 11 The 'giaddr' field can be used to identify the logical | 12 interface to which the reply must be forwarded (i.e. the router | 13 interface connected to the same network as the BOOTP client). | 14 If the content of the logical interfaces, the BOOTREPLY | 15 messsage MUST be silently discarded. | 16 The 'htype', 'hlen', and 'chaddr' fields supply the link-layer | 17 hardware type, hardware address length, and hardware address of | 18 the client as defined in the ARP protocol and the Assigned | 19 Numbers document. The 'yiaddr' field is the IP address of the | 20 client, as assigned by the BOOTP server. | 21 The reply SHOULD be sent as an IP unicast to the IP address | 22 specified by the 'yiaddr' field and the link-layer address | 23 specified in the be sent to the link-layer broadcast address | Internet Engineering Task Force [Page 148] INTERNET-DRAFT MISCELLANEOUS APPLICATION PROTOCOLS March 6, 1991 24 using either the contents of the 'yiaddr' field or the IP | 25 limited broadcast address as the IP destination address. | 26 The reply MUST have its UDP destination port set to BOOTPC | 27 (68). | 28 CONTRIBUTOR'S COMMENTS: | 29 What is the convention for referencing UDP port numbers? | 30 Should this be a pointer to Assigned Numbers? | 31 Should the BOOTREPLY message have its source address | 32 changed to the address of the router (or should it be left | 33 as the address of the BOOTP server)? | 34 The UDP checksum must be recalculated before transmitting the | 35 reply. | 0 9.2 REQUIREMENTS SUMMARY 1 TBD Internet Engineering Task Force [Page 149] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 010. OPERATIONS AND MAINTENANCE 1 EDITOR'S COMMENTS: 2 This chapter is kind of a catchall for topics relevant to 3 routers which have little to do with correct protocol 4 processing. 5 This chapter doesn't really have any organization yet. 0 10.1 Minimum Router Configuration 1 SOURCE: 2 Section 10.1 source: new text, contributor: Craig Partridge. 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, along 7 with the subnet mask of that address. 8 (2) IP forwarding must be enabled on at least one of the routers 9 interfaces. 10 Every time a router boots, it MUST confirm that both of these 11 conditions ("sanity checks") are met. If these conditions are not 12 met, the router MUST NOT forward IP packets. Furthermore, these 13 conditions MUST NOT have defaults. 14 EDITOR'S COMMENTS: | 15 In Boulder there was some inconclusive discussion of the | 16 above conditions. Are they adequate? Does the interface on | 17 which forwarding is enabled have to be the same one which has | 18 a known IP address? This seems to need more thought. | 19 DISCUSSION: 20 There have been instances in which routers have been shipped 21 with vendor-installed default addresses for interfaces. In a 22 few cases, this has resulted in routers advertising these 23 default addresses into active networks. 0 10.2 Address Mask Initialization 1 A router MUST support the first, and MAY implement both, of the 2 following methods for determining the address mask(s) 3 corresponding to its IP address(es): Internet Engineering Task Force [Page 150] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 4 (1) static configuration information; 5 (2) obtaining the address mask(s) dynamically as a side effect of 6 the system initialization process (see [INTRO:3]); 7 The choice of method to be used in a particular router MUST be 8 configurable. 9 A router SHOULD make some reasonableness check on any address mask 10 it installs; see IMPLEMENTATION section below. 11 IMPLEMENTATION: 12 The following reasonableness check on an address mask is 13 suggested: the mask is not all 1 bits, and all bits which 14 correspond to the network number part of the address are set. 15 EDITOR'S COMMENTS: | 16 In Boulder, it was suggested that the test in the | 17 implementation hint is wrong (for some cases of point-to- | 18 point links?). If so, RFC-1122 is also broken. | 0 10.3 Operation and Maintenance * 1 SOURCE: * 2 Section 10.3 source: heavily modified RFC1009, contributor: * 3 Cathy Wittbrodt * 0 10.3.1 Introduction * 1 Facilities to support operation and maintenance (O&M) * 2 activities form an essential part of any router implementation. * 3 Although these functions do not seem to relate directly to * 4 interoperability, they are essential to the network manager who * 5 must make the router interoperate and track down problems when * 6 it doesn't. The following kinds of activity are included under * 7 router O&M: * 8 o Diagnosing hardware problems in the router processor, in * 9 its network interfaces, or in the connected networks, * 10 modems, or communication lines. * 11 o Installing new hardware * 12 o Installing a new version of the router software. * 13 o Restarting or rebooting a router after a crash. * 14 o Configuring (or reconfiguring) the router. * Internet Engineering Task Force [Page 151] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 15 o Detecting and diagnosing Internet problems such as * 16 congestion, routing loops, bad IP addresses, black holes, * 17 packet avalanches, and misbehaved hosts. * 18 o Changing network topology, either temporarily (e.g., to * 19 diagnose a communication line problem) or permanently. * 20 o Monitoring the status and performance of the routers and * 21 the connected networks. * 22 o Collecting traffic statistics for use in (Inter-)network * 23 planning. * 24 o Coordinating the above activities with appropriate vendors * 25 and telecommunications specialists. * 26 Routers, packet-switches, and their connected communication * 27 lines are often operated as a system by a centralized O&M * 28 organization. This organization may maintain a (Inter-)network * 29 operation center, or NOC, to carry out its O&M functions. It * 30 is essential that routers support remote control and monitoring * 31 from such a NOC, through an Internet path (since routers might * 32 not be connected to the same network as their NOC). * 33 Furthermore, an IP packet traversing the Internet will often * 34 use routers under the control of more than one NOC; therefore, * 35 Internet problem diagnosis will often involve cooperation of * 36 personnel of more than one NOC. In some cases, the same router * 37 may need to be monitored by more than one NOC, but only if * 38 necessary, because excessive monitoring could impact a router's * 39 performance. * 40 The tools available for monitoring at a NOC may cover a wide * 41 range of sophistication. Current implementations include * 42 multi-window, dynamic displays of the entire router system. The * 43 use of AI techniques for automatic problem diagnosis is * 44 proposed for the future. * 45 The most important aspect of any monitoring tool is that it * 46 alert someone that there is a problem. It is much more * 47 important to know what is down, than to know what is up and * 48 running. It is also important that this tool be multi-tasking * 49 because there may be more than one technician working on more * 50 than one problem at the same time. * 51 Router O&M facilities discussed here are only a part of the * 52 large and difficult problem of Internet management. These * 53 problems encompass not only multiple management organizations, * 54 but also multiple protocol layers. For example, at the current * Internet Engineering Task Force [Page 152] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 55 stage of evolution of the Internet architecture, there is a * 56 strong coupling between host TCP implementations and eventual * 57 IP-level congestion in the router system [OPER:1]. Therefore, * 58 diagnosis of congestion problems will sometimes require the * 59 monitoring of TCP statistics in hosts. Routing algorithms also * 60 interact with local network performance, especially through * 61 handling of broadcast packets and ARP, and again diagnosis will * 62 require access to hosts (e.g., examining ARP caches). However, * 63 consideration of host monitoring is beyond the scope of this * 64 DRAFT. * 65 There are currently a number of R&D efforts in progress in the * 66 area of Internet management and more specifically router O&M. * 67 These R&D efforts have already produced standards for router * 68 O&M. This is also an area in which vendor creativity can make a * 69 significant contribution. * 0 10.3.2 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 * 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 * Internet Engineering Task Force [Page 153] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 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 Remote router monitoring and (especially) remote router control * 37 present important access control problems which must be * 38 addressed. Care must also be taken to ensure control of the * 39 use of router resources for these functions. It is not * 40 desirable to let router monitoring take more than some limited * 41 fraction of the router CPU time, for example. On the other * 42 hand, O&M functions must receive priority so they can be * 43 exercised when the router is congested, i.e., when O&M is most * 44 needed. * 45 Routers SHOULD support out of band access. This out of band | 46 access will allow the NOC a way to access isolated routers | 47 during times when netork access is not available. This out of | 48 band access should be the same as in band access in that it | 49 allows the network manager to issue commands as if he were | 50 typing them on the console of the router. | 51 DISCUSSION: | 52 Out of band access is an important management tool for the | 53 network administrator. It allows the access of equipment | 54 whether or not the network connection is up. There are | 55 many ways to achieve this access, and the method is not | 56 that important. What is important is that there be | 57 console-like access of the router at times when the | 58 network access is not available. In band access, or | 59 accessing equipment through the existing network | 60 connection, is limiting, because most of the time, | 61 adminstrators need to reach equipment to figure out why it | 62 is unreachable. In band access is still very important | 63 for configuring a router, and for troubleshooting more | 64 subtle problems. Both in band and out of band access | 65 should appear to the administrator as if he/she were | 66 typing commands from the console. | 67 Limiting query access to a router might be a way of ensuring * 68 the control of router resources for necessary functions. There * 69 are several current Internet standards for control and * 70 monitoring protocols. The one that is most widely used is * 71 Simple Network Management Protocol, or SNMP. See Chapter 8 of * 72 this document for further details. * Internet Engineering Task Force [Page 154] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 0 10.3.3 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 or dump the router via the network in case of * 8 fault. For suggested hardware and software diagnostics * 9 see section 10.3.5. * 10 B. Control -- Dumping and Rebooting * 11 It MUST be possible to reboot a stand-alone router. This | 12 reboot mechanism SHOULD be in the form of a watchdog timer | 13 that either initiates a reboot automatically or signals a | 14 remote control site if not reset periodically by the | 15 software. There SHOULD also be an automated way to dump a | 16 router. * 17 C. Control -- Configuring the Router * 18 Every router will have a number of configuration * 19 parameters which MUST be set (see the next section for * 20 examples). It SHOULD be possible to update the parameters | 21 without rebooting the router; at worst, a restart MAY be | 22 required. There are cases when it is not possible to | 23 change parameters without rebooting the router, for | 24 instance, changing the IP address, or the MAC layer | 25 address. In these cases, care should be taken to minimize | 26 disruption to the router and the surrounding network. | 27 There SHOULD be an easy way to configure the router over | 28 the network either manually or automatically. A router | 29 SHOULD be able to upload or download its parameters from a | 30 host or another router, and these parameters should be | 31 convertible into some sort of ASCII form for making | 32 changes and then back to the form the router can read. A | 33 router SHOULD have some sort of stable storage for its | 34 configuration. A router SHOULD NOT believe protocols such * 35 as RARP, ICMP mask reply, and MAY not believe BOOTP, which * 36 try to tell the router about what its configuration is. * Internet Engineering Task Force [Page 155] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 37 Netbooting of System Software * 38 A router MAY keep its system image in PROM, NVRAM, * 39 disk, or it MAY also load its system over the network * 40 from a host or another router. It is important that * 41 the router be able to come up and run on its own. In a * 42 large network NVRAM may be the solution because it is * 43 time consuming to change the PROMs in a large network * 44 of routers. It is important to be able to netboot the * 45 system image because there should be an easy way for a * 46 router to get a bug fix or new feature more quickly * 47 than getting PROMS installed. Also if the router has * 48 NVRAM instead of PROMs, it will netboot the image and * 49 then put it in NVRAM. * 50 If the router has a non-volatile way to save its system * 51 image, and the ability to netboot its image, then the * 52 router SHOULD be able to default to the version if the * 53 netbootable image is not available. * 54 A router MAY also be able to distinguish between * 55 different configurations based on which software it is * 56 running. If configuration commands change from one * 57 software version to another, it would be nice (MAY?) if * 58 the router could use the configuration that was * 59 compatible with the software. * 60 Detecting and responding to misconfiguration * 61 There MUST be mechanisms for detecting and responding * 62 to misconfigurations. If a command is executed * 63 incorrectly, the router SHOULD give an error message. * 64 The router SHOULD NOT accept a poorly formed command as * 65 if it is correct. There are cases where it is not * 66 possible to detect errors, cases of logic errors. The * 67 command is correctly formed, but incorrect with respect * 68 to the network. This may be detected by the router, * 69 but may not be possible. * 70 Another form of misconfiguration is misconfiguration of * 71 the network to which the router is attached. A router * 72 MAY detect misconfigurations in the network. Examples * 73 of such misconfigurations might be, a router with the * 74 same address as the one in question, a router with the * 75 wrong subnet mask, etc. If a router detects such * 76 problems it is probably not the best idea for the * 77 router to try to fix the situation. That could cause * 78 more harm than good. The router MAY log these findings * Internet Engineering Task Force [Page 156] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 79 to a file, either on the router or a host, so that the * 80 network manager will see that there are possible * 81 problems on the network. * 82 Minimizing network disruption when changing parameters * 83 Changing the configuration of a router SHOULD have * 84 minimal affect on the network. Routing tables SHOULD * 85 NOT be unnecessarily flushed when a simple change is * 86 made to the router. If a router is running several * 87 routing protocols, stopping one routing protocol SHOULD * 88 NOT disrupt other routing protocols, except in the case * 89 where one network is learned by more than one routing * 90 protocol. * 91 DISCUSSION: | 92 It is the goal of a network manager to run a | 93 network so that users of the network get the best | 94 connectivity possible. Reloading a router for | 95 simple configuration changes can cause disruptions | 96 in routing and ultimately cause service | 97 disruptions to users of the network. If routing | 98 tables are unnecessarily flushed, for instance, | 99 the default route will be lost as well as specific | 100 routes to sites within the network. This sort of | 101 disruption will cause significant downtime for the | 102 users. It is the purpose of this section to point | 103 out that whenever possible, these disruptions | 104 should be avoided. | 105 CONTRIBUTOR'S COMMENTS: * 106 I am starting to think that traceroute should be a * 107 MAY. Since most folks have the ability to do loose * 108 source traceroutes from their UNIX hosts, it doesn't * 109 seem as important as it once was. It is indeed a * 110 helpful tool to have and I encourage folks to * 111 implement it. * 112 D. Control -- Troubleshooting Problems * 113 To aid in troubleshooting of network problems a router: | 114 (1) MUST provide in-band network access in the form of remote | 115 login. | 116 (2) MUST provide the ability to ping. If ping is implemented, | 117 then the following options SHOULD also be implemented: | Internet Engineering Task Force [Page 157] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 118 o choice of data patterns | 119 o size of ping packets | 120 o record route | 121 and the following additional options MAY be implemented: | 122 o loose source route | 123 o strict/loose source routing | 124 o timestamps | 125 (3) SHOULD provide the ability to run a traceroute. If | 126 traceroute is provided, then the 3rd party traceroute | 127 SHOULD be implemented | 128 Each of the above three facilities (if implemented) SHOULD | 129 have access restrictions placed on it to prevent its abuse | 130 by unauthorized persons. * 131 E. Monitoring -- Status and Performance * 132 A mechanism must be provided for retrieving status and * 133 statistical information from a router. A router must * 134 supply such information in response to a polling message * 135 from the NOC. In addition, it may be desirable to * 136 configure a router to transmit status spontaneously and * 137 periodically to a NOC (or set of NOCs), for recording and * 138 display. The router SHOULD timestamp all such updates * 139 before they leave the router. This allows the network * 140 manager to determine exactly when problems occurred. * 141 Examples of interesting status information include: link * 142 status, queue lengths, buffer availability, CPU and memory * 143 utilization, the routing data-base, error counts, and * 144 packet counts, for each protocol. Counts should be kept * 145 for dropped packets, separated by reason. Counts of ICMP * 146 datagrams should be kept by type and categorized into * 147 those originating at the router, and those destined for * 148 the router. It would be useful to maintain many of these * 149 statistics by network interface, by source/destination * 150 network pair, and/or by source/destination host pair. * 151 Note that a great deal of useful monitoring data is often * 152 to be found in the routing data-base. It is therefore * 153 useful to be able to tap into this data-base from the NOC. * Internet Engineering Task Force [Page 158] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 154 F. Monitoring -- Error Logging * 155 A router should be capable of asynchronously sending * 156 exception ("trap") reports to one or more specified * 157 Internet addresses, one of which will presumably be the * 158 NOC host. The router SHOULD timestamp these traps. * 159 There must also be a mechanism to limit the frequency of * 160 such trap reports, and the parameters controlling this * 161 frequency must be settable in the router configuration. | 162 See [OPER:2]. | 163 Examples of conditions which should result in traps * 164 include: packets discarded because of TTL expiration (an * 165 indicator of possible routing loops); resource shortages; * 166 or an interface changing its up/down status. See also * 167 section 1.3.3 of [INTRO:1]. * 0 10.3.4 Router Configuration Parameters * 1 Every router will have a set of configuration parameters * 2 controlling its operation. It must be possible to set these * 3 parameters remotely from the NOC or locally at any time, * 4 without taking the router down. * 5 The following is a partial but representative list of possible * 6 configuration parameters for a full-function router. The items * 7 marked with "(i)" should be settable independently for each * 8 network interface. * 9 o(i) IP (sub-) network address * 10 o(i) Subnet address mask * 11 o(i) MTU of local network * 12 o(i) Hardware interface address * 13 o(i) Broadcast compatibility option (0s or 1s) * 14 o EGP parameters -- neighbors, Autonomous System number, and * 15 polling parameters | 16 o Static routes, if any | 17 o Default Networks, if any | Internet Engineering Task Force [Page 159] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 18 o Default Subnets, if any * 19 o Enable/Disable Proxy ARP * 20 o Source Quench parameters * 21 o Address filter configuration * 22 o Boot-host address * 23 o IP address of time server host * 24 o IP address(es) of logging host(s) * 25 o IP address(es) of hosts to receive traps * 26 o IP address(es) of hosts authorized to issue control * 27 commands * 28 o Error level for logging * 29 o Maximum trap frequency * 30 o Hold-down period (if any) * 0 10.3.5 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 MUST: * 14 o NOT take precedence over normal router functions and * Internet Engineering Task Force [Page 160] INTERNET-DRAFT OPERATIONS AND MAINTENANCE March 6, 1991 15 direct commands from the console * 16 o be easily toggled on and off without reloading the router * 17 o NOT degrade the performance of the router (normal router * 18 functions, such as routing, should not be compromised so * 19 that diagnostics may be run, unless requested by the * 20 administrator.) * 0 10.4 REQUIREMENTS SUMMARY 1 TBD Internet Engineering Task Force [Page 161] INTERNET-DRAFT REFERENCES March 6, 1991 011. REFERENCES 1 APPL:1. 2 Bill Croft and John Gilmore, Bootstrap Protocol (BOOTP), Request 3 For Comments (RFC) 951, DDN Network Information Center, SRI 4 International, Menlo Park, California, USA, September 1985. 5 APPL:2. 6 J. Reynolds, BOOTP Vendor Information Extensions, Request For 7 Comments (RFC) 1084, DDN Network Information Center, SRI 8 International, Menlo Park, California, USA, December 1988. 9 ARCH:1. 10 DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 (three 11 volumes), DDN Network Information Center, SRI International, 12 Menlo Park, California, USA, December 1985. 13 ARCH:2. 14 Vint Cerf and Robert Kahn, "A Protocol for Packet Network 15 Intercommunication," IEEE Transactions on Communication, May 16 1974. : Also included in [ARCH:1] 17 ARCH:3. 18 Jon Postel, Carl Sunshine, and Danny Cohen, "The ARPA Internet 19 Protocol," Computer Networks, vol. 5, no. 4, July 1981. : Also 20 included in [ARCH:1] 21 ARCH:4. 22 Barry Leiner, Jon Postel, R. Cole, and Dave Mills, "The DARPA 23 Internet Protocol Suite," Proceedings INFOCOM 85, IEEE, 24 Washington, DC, March 1985. Also in: IEEE Communications 25 Magazine, March 1985. Also available from the Information 26 Sciences Institute, University of Southern California as 27 Technical Report ISI-RS-85-153 28 ARCH:5. 29 Douglas E. Comer, Internetworking With TCP/IP: Principles, 30 Protocols, and Architecture, Prentice Hall, Englewood Cliffs, 31 NJ, 1988. 32 ARCH:6. 33 William Stallings, Handbook of Computer-Communications Standards 34 Volume 3: The TCP/IP Protocol Suite, Macmillan, New York, NY, 35 1990. 36 ARCH:7. 37 Information processing systems -- Open Systems Interconnection 38 -- Basic Reference Model, ISO 7489, International Standards Internet Engineering Task Force [Page 162] INTERNET-DRAFT REFERENCES March 6, 1991 39 Organization, 1984. 40 FORWARD:1. 41 IETF CIP Working Group (Claudio Topolcic, Editor), Experimental 42 Internet Stream Protocol, Version 2 (ST-II), Request For 43 Comments (RFC) 1190, DDN Network Information Center, SRI 44 International, Menlo Park, California, USA, October 1990. 45 FORWARD:2. 46 Internet Engineering Task Force (A. J. Mankin and K. K. 47 Ramakishnan, Editors), Gateway Congestion Control Policies, July 48 1989. To be published as an RFC; currently an INTERNET-DRAFT. 49 FORWARD:3. 50 J. Nagle, "On Packet Switches with Infinite Storage," IEEE 51 Transactions on Communications, vol. COM-35, no. 4, April 1987. 52 FORWARD:4. 53 R. Jain, K. Ramakrishnan, and D. Chiu, Congestion Avoidance in 54 Computer Networks With a Connectionless Network Layer, Technical 55 Report DEC-TR-506, Digital Equipment Corporation. 56 FORWARD:5. 57 V. Jacobson, "Congestion Avoidance and Control," Proceeding of 58 SIGCOMM '88, Association for Computing Machinery. 59 INTERNET:1. 60 Jon Postel, Internet Protocol, Request For Comments (RFC) 791, 61 DDN Network Information Center, SRI International, Menlo Park, 62 California, USA, September 1981. 63 INTERNET:10. 64 G. Finn, "A Connectionless Congestion Control Algorithm," 65 Computer Communications Review, vol. 19, no. 5, Association for 66 Computing Machinery, October 1989. 67 INTERNET:11. 68 Walt Prue, The Source Quench Introduced Delay (SQuID), Request 69 For Comments (RFC) 1016, DDN Network Information Center, SRI 70 International, Jon Postel, August 1987. 71 INTERNET:12. 72 A. M. McKenzie, Some comments on SQuID, Request For Comments 73 (RFC) 1018, DDN Network Information Center, SRI International, 74 Menlo Park, California, USA, August 1987. 75 INTERNET:13. 76 Steve Deering, ICMP Messages for Router Discovery, July 1989. Internet Engineering Task Force [Page 163] INTERNET-DRAFT REFERENCES March 6, 1991 77 To be published as an RFC; currently an INTERNET-DRAFT. 78 INTERNET:15. 79 J. Mogul and S. Deering, Path MTU Discovery, Request For 80 Comments (RFC) 1191, DDN Network Information Center, SRI 81 International, Menlo Park, California, USA, November 1990. 82 INTERNET:2. 83 Jeffery Mogul and Jon Postel, Internet Standard Subnetting 84 Procedure, Request For Comments (RFC) 950, DDN Network 85 Information Center, SRI International, Menlo Park, California, 86 USA, August 1985. 87 INTERNET:3. 88 Jeffery Mogul, Broadcasting Internet Datagrams in the Presence 89 of Subnets, Request For Comments (RFC) 922, DDN Network 90 Information Center, SRI International, Menlo Park, California, 91 USA, October 1984. 92 INTERNET:4. 93 Steve Deering, Host Extensions for IP Multicasting, Request For 94 Comments (RFC) 1112, DDN Network Information Center, SRI 95 International, Menlo Park, California, USA, August 1989. 96 INTERNET:5. 97 ???, ??? (IP security option), Request For Comments (RFC) 1108?, 98 DDN Network Information Center, SRI International, Menlo Park, 99 California, USA, to be released "real soon now". 100 INTERNET:6. 101 Robert Braden, Dave Borman, and Craig Partridge, Computing the 102 Internet Checksum, Request For Comments (RFC) 1071, DDN Network 103 Information Center, SRI International, Menlo Park, California, 104 USA, September 1988. 105 INTERNET:7. 106 T. Mallory and A. Kullberg, Incremental Updating of the Internet 107 Checksum, Request For Comments (RFC) 1141, DDN Network 108 Information Center, SRI International, Menlo Park, California, 109 USA, January 1990. 110 INTERNET:8. 111 Jon Postel, Internet Control Message Protocol, Request For 112 Comments (RFC) 792, DDN Network Information Center, SRI 113 International, Menlo Park, California, USA, September 1981. 114 INTERNET:9. 115 A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R. Internet Engineering Task Force [Page 164] INTERNET-DRAFT REFERENCES March 6, 1991 116 Wilder, and R. Zahavi, Evaluation of Internet Performance -- 117 FY89, Technical Report MTR-89W00216, MITRE Corporation, 118 February, 1990. 119 INTRO:1. 120 Robert Braden and Jon Postel, Requirements for Internet 121 Gateways, Request For Comments (RFC) 1009, DDN Network 122 Information Center, SRI International, Menlo Park, California, 123 USA, June 1987. 124 INTRO:2. 125 Internet Engineering Task Force (Robert Braden, Editor), 126 Requirements for Internet Hosts -- Communication Layers, Request 127 For Comments (RFC) 1122, DDN Network Information Center, SRI 128 International, Menlo Park, California, USA, October 1989. 129 INTRO:3. 130 Internet Engineering Task Force (Robert Braden, Editor), 131 Requirements for Internet Hosts -- Application and Support, 132 Request For Comments (RFC) 1123, DDN Network Information Center, 133 SRI International, Menlo Park, California, USA, October 1989. 134 INTRO:4. 135 Dave Clark, Modularity and Efficiency in Protocol 136 Implementations, Request For Comments (RFC) 817, DDN Network 137 Information Center, SRI International, Menlo Park, California, 138 USA, July 1982. 139 INTRO:5. 140 Dave Clark, "The Structuring of Systems Using Upcalls," 141 Proceedings of 10th ACM SOSP, December 1985. 142 INTRO:6. 143 Ole Jacobsen and Jon Postel, Protocol Document Order 144 Information, Request For Comments (RFC) 980, DDN Network 145 Information Center, SRI International, Menlo Park, California, 146 USA, March 1986. If you are unable to locate a copy of this 147 document, contact the publisher at the above address, or by 148 electronic mail to nic@nic.ddn.mil, or by phone at 800-235-3155 149 or 415-859-3695. 150 LINK:1. 151 Internet Engineering Task Force (Philip Almquist, Editor), 152 Requirements for the Internet Link Layer, (proposed document -- 153 not yet available). 154 OPER:1. 155 John Nagle, Congestion Control in IP/TCP Internetworks, Request Internet Engineering Task Force [Page 165] INTERNET-DRAFT REFERENCES March 6, 1991 156 For Comments (RFC) 896, DDN Network Information Center, SRI 157 International, Menlo Park, California, USA, January 1984. 158 OPER:2. 159 Lou Steinberg, Techniques for Managing Asynchronously Generated 160 Alerts, March 1990. To be published as an RFC; currently an 161 INTERNET-DRAFT. 162 ROUTE:1. 163 John Moy, OSPF Specification Version 2, January 1991. To be 164 published as an RFC; currently an INTERNET-DRAFT. 165 ROUTE:10. 166 D. Waitzman, C. Partridge, and S. E. Deering, Distance Vector 167 Multicast Routing Protocol, Request For Comments (RFC) 1075, DDN 168 Network Information Center, SRI International, Menlo Park, 169 California, USA, November 1988. 170 ROUTE:2. 171 Ross W. Callon, Use of OSI IS-IS for Routing in TCP/IP and Dual 172 Environments, Request For Comments (RFC) 1195, DDN Network 173 Information Center, SRI International, Menlo Park, California, 174 USA, December 1990. 175 ROUTE:3. 176 C. L. Hedrick, Routing Information Protocol, Request For 177 Comments (RFC) 1058, DDN Network Information Center, SRI 178 International, Menlo Park, California, USA, June 1988. 179 ROUTE:4. 180 Kirk Lougheed and Yakov Rekhter, Border Gateway Protocol (BGP), 181 Request For Comments (RFC) 1163, DDN Network Information Center, 182 SRI International, Menlo Park, California, USA, June 1990. 183 ROUTE:5. 184 J. C. Honig, D. Katz, M. Mathis, Y. Rekhter, and J. Y. Yu, 185 Application of the Border Gateway Protocol in the Internet, 186 Request For Comments (RFC) 1164, DDN Network Information Center, 187 SRI International, Menlo Park, California, USA, June 1990. 188 ROUTE:6. 189 Steven Willis and John Burrus, Experimental Definitions of 190 Managed Objects for the Border Gateway Protocol (Version 2), 191 September 1990. To be published as an RFC; currently an 192 INTERNET-DRAFT. 193 ROUTE:7. 194 David L. Mills, Exterior Gateway Protocol Formal Specification, Internet Engineering Task Force [Page 166] INTERNET-DRAFT REFERENCES March 6, 1991 195 Request For Comments (RFC) 904, DDN Network Information Center, 196 SRI International, Menlo Park, California, USA, April 1984. 197 ROUTE:8. 198 Eric C. Rosen, Exterior Gateway Protocol (EGP), Request For 199 Comments (RFC) 827, DDN Network Information Center, SRI 200 International, Menlo Park, California, USA, October 1982. 201 ROUTE:9. 202 Linda J. Seamonson and Eric C. Rosen, "STUB" Exterior Gateway 203 Protocol, Request For Comments (RFC) 888, DDN Network 204 Information Center, SRI International, Menlo Park, California, 205 USA, January 1984. 206 TRANS:1. 207 J. Postel, User Datagram Protocol, Request For Comments (RFC) 208 768, DDN Network Information Center, SRI International, Menlo 209 Park, California, USA, August 1980. 210 TRANS:2. 211 J. Postel, Transmission Control Protocol, Request For Comments 212 (RFC) 793, DDN Network Information Center, SRI International, 213 Menlo Park, California, USA, September 1981. Internet Engineering Task Force [Page 167] INTERNET-DRAFT March 6, 1991 214Security Considerations 215 Although the focus of this document is interoperability rather than 216 security, there are obviously many sections of this document which 217 have some ramifications on network security. 218 EDITOR'S COMMENTS: 219 The editor of this document has noted that the RFC format now 220 seems to include a section called "Security Considerations", 221 but he has no idea what it is supposed to contain. 222Author's Address 223 Philip Almquist 224 214 Cole Street, Suite #2 225 San Francisco, CA, 94117-1916 226 USA 227 Phone: 415-752-2427 or 415-723-2229 228 EMail: almquist@Jessica.Stanford.EDU Internet Engineering Task Force [Page 168]