idnits 2.17.1 draft-ietf-ipngwg-ipv6router-alert-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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-2205' is defined on line 196, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Craig Partridge, BBN 2 Alden Jackson, BBN 4 IPv6 Router Alert Option 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This draft expires XXXX and reflects comments received during an 30 earlier WG last call. It is intended to become an Internet Standard. 32 Abstract 34 This memo describes a new IPv6 Hop-by-Hop Option type that alerts 35 transit routers to more closely examine the contents of an IP 36 datagram. This option is useful for situations where a datagram 37 addressed to a particular destination contains information that may 38 require special processing by routers along the path. 40 1.0 Introduction 42 New protocols, such as RSVP, use control datagrams which, while 43 addressed to a particular destination, contain information that needs 44 to be examined, and in some case updated, by routers along the path 45 between the source and destination. It is desirable to forward 46 regular datagrams as rapidly as possible, while ensuring that the 47 router processes these special control datagrams appropriately. 48 Currently, however, the only way for a router to determine if it 49 needs to examine a datagram is to at least partially parse upper 50 layer data in all datagrams. This parsing is expensive and slow. 51 This situation is undesirable. 53 This document defines a new option within the IPv6 Hop-by-Hop Header. 54 The presence of this option in an IPv6 datagram informs the router 55 that the contents of this datagram is of interest to the router and 56 to handle any control data accordingly. The absence of this option 57 in an IPv6 datagram informs the router that the datagram does not 58 contain information needed by the router and hence can be safely 59 routed without further datagram parsing. Hosts originating IPv6 60 datagrams are required to include this option in certain 61 circumstances. 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC-2119]. 67 2.0 Approach 69 The goal is to provide an efficient mechanism whereby routers can 70 know when to intercept datagrams not addressed to them without having 71 to extensively examine every datagram. The described solution is to 72 define a new IPv6 Hop-by-Hop Header option having the semantic 73 "routers should examine this datagram more closely" and require 74 protocols such as RSVP to use this option. This approach incurs 75 little or no performance penalty on the forwarding of normal 76 datagrams. Not including this option tells the router that there is 77 no need to closely examine the contents of the datagram. 79 2.1 Syntax 81 The router alert option has the following format: 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 length = 2 88 The first three bits of the first byte are zero and the value 5 in 89 the remaining five bits is the Hop-by-Hop Option Type number. 90 [RFC-2460] specifies the meaning of the first three bits. By 91 zeroing all three, this specification requires that nodes not 92 recognizing this option type should skip over this option and 93 continue processing the header and that the option must not change 94 en route. 96 There MUST only be one option of this type, regardless of value, 97 per Hop-by-Hop header. 99 Value: A 2 octet code in network byte order with the following 100 values: 102 0 Datagram contains a Multicast Listener Discovery 103 message [RFC-XXXX]. 104 1 Datagram contains RSVP message. 105 2 Datagram contains an Active Networks message. 106 3-65535 Reserved to IANA for future use. 108 Alignment requirement: 2n+0 110 Values are registered and maintained by the IANA. See section 5.0 111 for more details. 113 2.2 Semantics 115 The option indicates that the contents of the datagram may be 116 interesting to the router. The router's interest and the actions 117 taken by employing Router Alert MUST be specified in the RFC of the 118 protocol that mandates or allows the use of Router Alert. 120 The final destination of the IPv6 datagram MUST ignore this option 121 upon receipt to prevent multiple evaluations of the datagram. 122 Unrecognized value fields MUST be silently ignored and the processing 123 of the header continued. 125 Routers that recognize the option will examine datagrams carrying it 126 more closely to determine whether or not further processing is 127 necessary. The router only needs to parse the packet in sufficient 128 detail to decide whether the packet contains something of interest. 129 The value field can be used by an implementation to speed processing 130 of the datagram within the transit router. 132 Observe that further processing can involve protocol layers above 133 IPv6. E.g., for RSVP messages, the datagram will have to undergo UDP 134 and RSVP protocol processing. Once the datagram leaves the IPv6 135 layer, there is considerable ambiguity about whether the router is 136 acting as an IPv6 host or an IPv6 router. Precisely how the router 137 handles the contents is value-field specific. However, if the 138 processing required for the datagram involves examining the payload 139 of the IPv6 datagram, then the interim router is performing a host 140 function and SHOULD interpret the data as a host. 142 3.0 Impact on Other Protocols 144 For this option to be effective, its use MUST be mandated in 145 protocols that expect routers to perform significant processing on 146 datagrams not directly addressed to them. Routers are not required 147 to examine the datagrams not addressed to them unless the datagrams 148 include the router alert option. 150 All IPv6 datagrams containing an RSVP message MUST contain this 151 option within the IPv6 Hop-by-Hop Options Header of such datagrams. 153 4.0 Security Considerations 155 Gratuitous use of this option can cause performance problems in 156 routers. A more severe attack is possible in which the router is 157 flooded by bogus datagrams containing router alert options. 159 The use of the option, if supported in a router, MAY therefore be 160 limited by rate or other means by the transit router. 162 5.0 IANA Considerations 164 The value field described in Section 2.1 is registered and maintained 165 by IANA. New values are to be assigned via IETF Consensus as defined 166 in RFC 2434 [RFC-2434]. 168 6.0 Notice on Intellectual Property 170 The IETF takes no position regarding the validity or scope of any 171 intellectual property or other rights that might be claimed to 172 pertain to the implementation or use of the technology described in 173 this document or the extent to which any license under such rights 174 might or might not be available; neither does it represent that it 175 has made any effort to identify any such rights. Information on the 176 IETF's procedures with respect to rights in standards-track and 177 standards-related documentation can be found in BCP-11. Copies of 178 claims of rights made available for publication and any assurances of 179 licenses to be made available, or the result of an attempt made to 180 obtain a general license or permission for the use of such 181 proprietary rights by implementors or users of this specification can 182 be obtained from the IETF Secretariat. 184 The IETF invites any interested party to bring to its attention any 185 copyrights, patents or patent applications, or other proprietary 186 rights which may cover technology that may be required to practice 187 this standard. Please address the information to the IETF Executive 188 Director. 190 7.0 References 192 [RFC-2119] Bradner, S., "Key words for use in RFC's to Indicate 193 Requirement Levels", Internet Request For Comments No. 194 2119, March 1977. 196 [RFC-2205] Braden, B. (ed.), L. Zhang, S. Berson, S. Herzog, S. 197 Jamin, "Resource ReSerVation Protocol (RSVP)," Internet 198 Request for Comments No. 2205, September 1997. 200 [RFC-2434] T. Narten and H. Alvestrand, "Guidelines for Writing an 201 IANA Considerations Section in RFCs", Internet Request For 202 Comments No. 2434, October 1998. 204 [RFC-2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 205 (IPv6) Specification," Internet Request for Comments No. 206 2460, December 1998. 208 [RFC-XXXX] S. Deering, W. Fenner and B. Haberman, "Multicast 209 Listener Discovery (MLD) for IPv6," Internet Draft (draft- 210 ietf-ipngwg-mld-02.txt), June 1999. 212 6.0 Authors' Addresses 214 Craig Partridge Phone: +1 (617) 873-3000 215 BBN Technologies Email: craig@bbn.com 216 10 Moulton Street 217 Cambridge, MA 02138 218 USA 220 Alden Jackson Phone: +1 (617) 873-3000 221 BBN Technologies Email: awjacks@bbn.com 222 10 Moulton Street 223 Cambridge, MA 02138 224 USA