idnits 2.17.1 draft-katz-router-alert-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2, 1996) is 10008 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Dave Katz 2 Expiration: June 1997 cisco Systems 3 File: draft-katz-router-alert-03.txt December 2, 1996 5 IP Router Alert Option 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 23 Rim). 25 IESG Note: 27 Internet Engineering Steering Group comment from the co-Area 28 Director for Transport Services: This is a Proposed Standard. It 29 is a matter of individual choice as to how to implement the 30 specification. Implementation as a temporary feature or in a test 31 version of the product may be appropriate. 33 Abstract 35 This memo describes a new IP Option type that alerts transit routers 36 to more closely examine the contents of an IP packet. This is useful 37 for, but not limited to, new protocols that are addressed to a 38 destination but require relatively complex processing in routers 39 along the path. 41 1.0 Introduction 43 A recent trend in routing protocols is to loosely couple new routing 44 functionality to existing unicast routing. The motivation for this 45 is simple and elegant -- it allows deployment of new routing 46 functionality without having to reinvent all of the basic routing 47 protocol functions, greatly reducing specification and implementation 48 complexity. 50 The downside of this is that the new functionality can only depend on 51 the least common denominator in unicast routing, the next hop toward 52 the destination. No assumptions can be made about the existence of 53 more richly detailed information (such as a link state database). 55 It is also desirable to be able to gradually deploy the new 56 technology, specifically to avoid having to upgrade all routers in 57 the path between source and destination. This goal is somewhat at 58 odds with the least common denominator information available, since a 59 router that is not immediately adjacent to another router supporting 60 the new protocol has no way of determining the location or identity 61 of other such routers (unless something like a flooding algorithm is 62 implemented over unicast forwarding, which conflicts with the 63 simplicity goal). 65 One obvious approach to leveraging unicast routing is to do hop-by- 66 hop forwarding of the new protocol packets along the path toward the 67 ultimate destination. Each system that implements the new protocol 68 would be responsible for addressing the packet to the next system in 69 the path that understood it. As noted above, however, it is 70 difficult to know the next system implementing the protocol. The 71 simple, degenerate case is to assume that every system along the path 72 implements the protocol. This is a barrier to phased deployment of 73 the new protocol, however. 75 RSVP [1] finesses the problem by instead putting the address of the 76 ultimate destination in the IP Destination Address field, and then 77 asking that every RSVP router make a "small change in its ... 78 forwarding path" to look for the specific RSVP packet type and pull 79 such packets out of the mainline forwarding path, performing local 80 processing on the packets before forwarding them on. This has the 81 decided advantage of allowing automatic tunneling through routers 82 that don't understand RSVP, since the packets will naturally flow 83 toward the ultimate destination. However, the performance cost of 84 making this Small Change may be unacceptable, since the mainline 85 forwarding path of routers tends to be highly tuned--even the 86 addition of a single instruction may incur penalties of hundreds of 87 packets per second in performance. 89 2.0 Router Alert Option 91 The goal, then, is to provide a mechanism whereby routers can 92 intercept packets not addressed to them directly, without incurring 93 any significant performance penalty. This document defines a new IP 94 option type, Router Alert, for this purpose. 96 The Router Alert option has the semantic "routers should examine this 97 packet more closely". By including the Router Alert option in the IP 98 header of its protocol message, RSVP can cause the message to be 99 intercepted while causing little or no performance penalty on the 100 forwarding of normal data packets. 102 Routers that support option processing in the fast path already 103 demultiplex processing based on the option type field. If all option 104 types are supported in the fast path, then the addition of another 105 option type to process is unlikely to impact performance. If some 106 option types are not supported in the fast path, this new option type 107 will be unrecognized and cause packets carrying it to be kicked out 108 into the slow path, so no change to the fast path is necessary, and 109 no performance penalty will be incurred for regular data packets. 111 Routers that do not support option processing in the fast path will 112 cause packets carrying this new option to be forwarded through the 113 slow path, so no change to the fast path is necessary and no 114 performance penalty will be incurred for regular data packets. 116 2.1 Syntax 118 The Router Alert option has the following format: 120 +--------+--------+--------+--------+ 121 |10010100|00000100| 2 octet value | 122 +--------+--------+--------+--------+ 124 Type: 125 Copied flag: 1 (all fragments must carry the option) 126 Option class: 0 (control) 127 Option number: 20 (decimal) 129 Length: 4 131 Value: A two octet code with the following values: 132 0 - Router shall examine packet 133 1-65535 - Reserved 135 2.2 Semantics 137 Hosts shall ignore this option. Routers that do not recognize this 138 option shall ignore it. Routers that recognize this option shall 139 examine packets carrying it more closely (check the IP Protocol 140 field, for example) to determine whether or not further processing is 141 necessary. Unrecognized value fields shall be silently ignored. 143 The semantics of other values in the Value field are for further 144 study. 146 3.0 Impact on Other Protocols 148 For this option to be effective, its use must be mandated in 149 protocols that expect routers to perform significant processing on 150 packets not directly addressed to them. Currently such protocols 151 include RSVP [1] and IGMP [2]. 153 4.0 References 155 [1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin, 156 "Resource ReSerVation Protocol (RSVP)," work in progress, March 157 1996. 159 [2] Fenner, W., "Internet Group Management Protocol, Version 2 160 (IGMPv2)," work in progress, October 1996. 162 Author's Address 164 Dave Katz 165 cisco Systems 166 170 W. Tasman Dr. 167 San Jose, CA 95134-1706 USA 169 Phone: +1 408 526 8284 170 Email: dkatz@cisco.com