idnits 2.17.1 draft-ietf-ipngwg-ipv6router-alert-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (13 February 1998) is 9569 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) == Unused Reference: 'RFC-1883' is defined on line 163, but no explicit reference was found in the text == Unused Reference: 'RFC-2205' is defined on line 167, but no explicit reference was found in the text == Unused Reference: 'RFC-2113' is defined on line 176, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Dave Katz, Juniper Networks 3 Craig Partridge, BBN 4 Alden Jackson, BBN 5 13 February 1998 7 IPv6 Router Alert Option 9 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress." 24 Please check the I-D abstract listing contained in each Internet 25 Draft directory to learn the current status of this or any Internet 26 Draft. 28 This draft expires 24 August 1998 and reflects comments received 29 during the WG last call. 31 Abstract 33 This memo describes a new IPv6 Hop-by-Hop Option type that alerts 34 transit routers to more closely examine the contents of an IP 35 datagram. This option is useful for situations where a datagram 36 addressed to a particular destination contains information that may 37 require special processing by routers along the path. 39 1.0 Introduction 41 New protocols, such as RSVP, use control datagrams which, while 42 addressed to a particular destination, contain information that needs 43 to be examined, and in some case updated, by routers along the path 44 between the source and destination. It is desirable to forward 45 regular datagrams as rapidly as possible, while ensuring that the 46 router processes these special control datagrams appropriately. 47 Currently, however, the only way for a router to determine if it 48 needs to examine a datagram is to at least partially parse upper 49 layer data in all datagrams. This parsing is expensive and slow. 50 This situation is undesirable. 52 This draft defines a new option within the IPv6 Hop-by-Hop Header. 53 The presence of this option in an IPv6 datagram informs the router 54 that the contents of this datagram is of interest to the router and 55 to handle any control data accordingly. The absence of this option 56 in an IPv6 datagram informs the router that the datagram does not 57 contain information needed by the router and hence can be safely 58 routed without further datagram parsing. Hosts originating IPv6 59 datagrams are required to include this option in certain 60 circumstances. 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC-2119]. 66 2.0 Approach 68 The goal is to provide an efficient mechanism whereby routers can 69 know when to intercept datagrams not addressed to them without having 70 to extensively examine every datagram. The described solution is to 71 define a new IPv6 Hop-by-Hop Header option having the semantic 72 "routers should examine this datagram more closely" and require 73 protocols such as RSVP to use this option. This approach incurs 74 little or no performance penalty on the forwarding of normal 75 datagrams. Not including this option tells the router that there is 76 no need to closely examine the contents of the datagram. 78 2.1 Syntax 80 The router alert option has the following format: 82 +--------+--------+--------+--------+ 83 |00| TBD |00000010| Value (2 octets)| 84 +--------+--------+--------+--------+ 85 len= 2 87 "TBD" is the Hop-by-Hop Option Type number (To be allocated by the 88 IANA). [DO WE NEED A NUMBER FROM IANA BEFORE WE CAN SUBMIT THIS? 89 IF SO, I SUGGEST 20.] 91 Nodes not recognizing this option type MUST skip over this option 92 and continue processing the header. This option MUST NOT change 93 en route. There MUST only be one option of this type, regardless 94 of value, per Hop-by-Hop header. 96 Value: A 2 octet code in network byte order with the following 97 values: 99 0 Datagram contains ICMPv6 Group Membership message. 100 1 Datagram contains RSVP message. 101 2 Datagram contains an Active Networks message. 102 3-65535 Reserved. 104 New value codes must be registered with the IANA. 106 2.2 Semantics 108 The destination identified in the IPv6 header MUST ignore this option 109 upon receipt. Nodes that do not recognize the option MUST ignore it 110 and continue processing the header. Unrecognized value fields MUST 111 be silently ignored and the processing of the header continued. The 112 destination node identified in the IPv6 header MUST ignore the option 113 upon receipt to prevent multiple evaluations of the packet. 115 Routers that recognize this option MUST examine datagrams carrying it 116 more closely to determine whether or not further processing is 117 necessary. The router only needs to parse the packet in sufficient 118 detail to decide whether the packet contains something of interest. 119 The value field can be used by an implementation to speed processing 120 of the datagram within the transit router. 122 Observe that further processing can involve protocol layers above 123 IPv6. E.g., for RSVP messages, the datagram will have to undergo UDP 124 and RSVP protocol processing. Once the datagram leaves the IPv6 125 layer, there is considerable ambiguity about whether the router is 126 acting as an IPv6 host or an IPv6 router. Precisely how the router 127 handles the contents is value-field specific. However, if the 128 processing required for the datagram involves examining the payload 129 of the IPv6 datagram, then the interim router is performing a host 130 function and SHOULD interpret the data as a host. 132 The option indicates that the contents of the datagram may be 133 interesting to the router. The router's interest and the actions 134 taken by employing Router Alert MUST be specified in the RFC of the 135 protocol that mandates or allows the use of Router Alert. 137 3.0 Impact on Other Protocols 139 For this option to be effective, its use MUST be mandated in 140 protocols that expect routers to perform significant processing on 141 datagrams not directly addressed to them. 143 All IPv6 datagrams containing an ICMPv6 Group Membership message MUST 144 contain this option within the IPv6 Hop-by-Hop Options Header of such 145 datagrams. 147 All IPv6 datagrams containing an RSVP message MUST contain this 148 option within the IPv6 Hop-by-Hop Options Header of such datagrams. 150 4.0 Security Considerations 152 If the Router Alert option is not set and should be set, the behavior 153 of the protocol using Router Alert will be adversely affected since 154 the protocol relies on the use of the Router Alert option. 156 If the Router Alert option is set when it should not be set, it is 157 likely that the packet will experience a performance penalty, as it 158 may not be processed by the router in the same fashion as if the 159 option were not set. 161 5.0 References 163 [RFC-1883] Deering, S. & R. Hinden, "Internet Protocol, Version 6 164 (IPv6) Specification, RFC-1883, Internet Engineering Task 165 Force, December 1995. 167 [RFC-2205] Braden, R. (ed.), L. Zhang, S. Berson, S. Herzog, S. 168 Jamin, "Resource ReSerVation Protocol (RSVP)-- Version 1 169 Functional Specification", Internet Engineering Task 170 Force, September 1997. 172 [RFC-2119] Bradner, S., "Key words for use in RFC's to Indicate 173 Requirement Levels", RFC-2119, Internet Engineering Task 174 Force, March 1977. 176 [RFC-2113] Katz, D., IP Router Alert Option, RFC-2113, Internet 177 Engineering Task Force, February 1997. 179 6.0 Authors' Addresses 181 Dave Katz Phone: +1 (408) 327-0173 182 Juniper Networks Email: dkatz@jnx.com 183 3260 Jay Street 184 Santa Clara, CA 95054 185 USA 187 Craig Partridge Phone: +1 (617) 873-3000 188 BBN Technologies Email: craig@bbn.com 189 10 Moulton Street 190 Cambridge, MA 02138 191 USA 193 Alden Jackson Phone: +1 (617) 873-3000 194 BBN Technologies Email: awjacks@bbn.com 195 10 Moulton Street 196 Cambridge, MA 02138 197 USA