idnits 2.17.1 draft-tsou-6man-hbh-header-update-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC2460, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4421 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Z. Chen 3 Internet-Draft China Telecom 4 Intended status: Standards Track S. Setty 5 Expires: September 13, 2012 Huawei Technologies India Pvt. 6 Ltd. 7 T. Tsou, Ed. 8 Huawei Technologies (USA) 9 March 12, 2012 11 hop-by-hop extension header update 12 draft-tsou-6man-hbh-header-update-01 14 Abstract 16 The Hop-by-Hop Options header is used to convey optional information 17 that must be examined by every node along a packet's delivery path. 18 This document updates RFC2460, removing the requirement that source 19 nodes must process the Hop-by-Hop extension header, on the basis that 20 it imposes a performance impact with no advantages. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 13, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 58 2. Processing of Hop-by-Hop Option Header . . . . . . . . . . . . 3 59 3. Updating RFC2460 . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 62 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 The Hop-by-Hop Options extension header is used to convery 68 information that must be examined by all nodes along the path. 69 [RFC2460] requires processing of the Hop-by-Hop Options extension 70 header in all nodes along the packet delivery path. However, this is 71 not really necessary for source node, and imposes a performance 72 penalty on the source node when such packets are employed. 74 Section 2 describes the Processing of Hop-by-hop Options header. 75 Section 3 formally updates the [RFC2460] such that the aforementioned 76 penalty on the source node is eliminated. 78 1.1. Requirements Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2. Processing of Hop-by-Hop Option Header 86 Section 4 of [RFC2460] states that the Hop-by-Hop Options header must 87 be examined and processed by every node along a packet's delivery 88 path, including the source and destination nodes. 90 The above requirement means that a node originating the packet that 91 contains a Hop-by-Hop Extension header will have to process that 92 header. Since source node is the one inserting the header in the 93 first place, there does not seem to be any advantages in such 94 requirement, but otherwise represents a performance penalty. 96 Some applications in the source node, e.g. firewall, may check the 97 network packets before they are sent out, the hop-by-hop option 98 header may be processed, which is optional. 100 As of the time of this writing, two options (other than the padding 101 options) have been specified for the Hop-by-Hop Options extension 102 header: 104 Router Alert Option This option is defined in [RFC2711], 105 intended for applications like MLD, RSVP, 106 etc. 108 Jumbo Payload Option This option is defined in [RFC2675], and 109 used to convey IPv6 payloads larger than 110 2^16 bytes. 112 In the above two cases, the source node does not need to process the 113 Hop-By-Hop options extension header. 115 3. Updating RFC2460 117 This document updates [RFC2460] as follows: 119 The Hop-by-Hop Options header MUST be examined and processed by every 120 node along a packet's delivery path (including the destination 121 nodes), except for the source node. 123 4. IANA Considerations 125 This specification does not require any IANA actions. 127 5. Security Considerations 129 This specification does not introduce new security issues. 131 6. Normative References 133 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 134 Requirement Levels", BCP 14, RFC 2119, March 1997. 136 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 137 (IPv6) Specification", RFC 2460, December 1998. 139 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 140 RFC 2675, August 1999. 142 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 143 RFC 2711, October 1999. 145 Authors' Addresses 147 Zhonghua Chen 148 China Telecom 149 Shanghai 150 China 152 Phone: 153 Email: 18918588897@189.cn 154 Sreenatha Setty 155 Huawei Technologies India Pvt. Ltd. 156 Airport Road 157 Bangalore 560008 158 India 160 Phone: +91 961 127 9232 161 Email: sreenathabs@huawei.com 163 Tina Tsou (editor) 164 Huawei Technologies (USA) 165 2330 Central Expressway 166 Santa Clara CA 95050 167 USA 169 Phone: +1 408 330 4424 170 Email: tina.tsou.zouting@huawei.com