idnits 2.17.1 draft-aghule-intarea-oam-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 document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 7, 2019) is 1723 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'InfRef' is defined on line 265, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA Working Group A. Ghule 3 Internet-Draft R. Bonica 4 Intended status: Experimental Juniper Networks 5 Expires: February 8, 2020 August 7, 2019 7 Use of The IPv4 Reserved-flag for OAM 8 draft-aghule-intarea-oam-01 10 Abstract 12 This document defines new IPv4 Operations and Management (OAM) 13 capabilities. In order to support these capabilities, this document 14 defines a new interpretation of the IPv4 Reserved-flag. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on February 8, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 52 3. Redefining the IPv4 Reserved-Bit . . . . . . . . . . . . . . 2 53 4. OAM Flag Processing . . . . . . . . . . . . . . . . . . . . . 3 54 4.1. At Network Ingress Nodes . . . . . . . . . . . . . . . . 3 55 4.2. At Network Interior Nodes . . . . . . . . . . . . . . . . 3 56 4.3. At Network Egress Nodes . . . . . . . . . . . . . . . . . 4 57 5. The ICMP OAM Message . . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 9.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Problem Statement 68 This document defines new IPv4 [RFC0791] Operations and Management 69 (OAM) capabilities. In order to support these capabilities, this 70 document defines a new interpretation of the IPv4 Reserved-flag. 72 2. Requirements Language 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 76 "OPTIONAL" in this document are to be interpreted as described in BCP 77 14 [RFC2119] [RFC8174] when, and only when, they appear in all 78 capitals, as shown here. 80 3. Redefining the IPv4 Reserved-Bit 82 0 1 2 83 +---+---+---+ 84 | | D | M | 85 | 0 | F | F | 86 +---+---+---+ 88 Figure 1: Current Defintion Of The IPv4 Flags Field 90 Figure 1 depicts the IPv4 Flags field, as defined in [RFC0791]. It 91 contains the following fields: 93 o Bit 0: reserved, must be zero 95 o Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. 97 o Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. 99 0 1 2 100 +---+---+---+ 101 | O | D | M | 102 | A | F | F | 103 | M | | | 104 +---+---+---+ 106 Figure 2: Redefintion Of The IPv4 Flags Field 108 Figure 2 depicts a redefinition of the IPv4 flags field. It contains 109 the following fields: 111 o Bit 0: OAM 0 = No OAM Action, 1 = OAM Action 113 o Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. 115 o Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. 117 In the redefinition, the Reserved-flag is replaced by an OAM flag. 119 4. OAM Flag Processing 121 4.1. At Network Ingress Nodes 123 When a packet enters a provider network, the network ingress router 124 can subject the packet to policy. Policy includes match conditions 125 and actions. If the packet satisfies match conditions, the policy 126 can execute the following actions: 128 o Set the OAM-bit 130 o Recompute the IPv4 header checksum 132 If the ingress node sets the OAM bit, it MAY execute any of the OAM 133 actions described in Section 4.2. 135 4.2. At Network Interior Nodes 137 When a network interior node receives a packet and its OAM bit is 138 set, it MAY execute any combination of the following OAM actions. 140 +-----------+-------------------------------------------------------+ 141 | Action | Notes | 142 +-----------+-------------------------------------------------------+ 143 | Log the | The processing node creates a log entry. The log | 144 | packet | entry reflects the time at which it was created. It | 145 | | also reflects the time at which the packet arrived. | 146 | | | 147 | Count the | The processing node increments a counter. | 148 | packet | | 149 | | | 150 | Send an | The processing node sends an ICMP OAM message to the | 151 | ICMP OAM | packet's source. The OAM message indicates the time | 152 | message | at which the packet arrived. | 153 | | | 154 | Send | The processing node sends telemetry to a monitoring | 155 | telemetry | station. Telemetry includes the packet and the time | 156 | | at which the packet arrived. | 157 +-----------+-------------------------------------------------------+ 159 Table 1: OAM Actions 161 The action taken depends on local configuration. By default, no 162 action is taken 164 4.3. At Network Egress Nodes 166 When a network egress node receives a packet and the OAM bit is set, 167 it MAY execute any of the OAM actions described in Section 4.2. It 168 SHOULD clear the OAM bit. If it clears the OAM bit, it MUST 169 recompute the IPv4 Header Checksum. 171 5. The ICMP OAM Message 172 0 1 2 3 173 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Type | Code | Checksum | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Length | Reserved | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Timestamp (seconds) | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Timestamp (fraction) | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 + Original Datagram + 185 | | 187 Figure 3 189 Figure 3 depicts the ICMP OAM message. The ICMP OAM message contains 190 the following fields: 192 o Type - OAM. Value TBD by IANA. 194 o Code - MUST be set to (0) No Error. 196 o Checksum - See [RFC0792] 198 o Reserved - MUST be set to 0 and MUST be ignored upon receipt. 200 o Length - Represents the length of the padded "original datagram" 201 field, measured in 32-bit words. 203 o Timestamp (seconds) - Represents the time at which the original 204 packet arrived in Network Time Protocol (NTP) [RFC5905] format. 206 o Timestamp (fraction) - Represents the time at which the original 207 packet arrived in NTP [RFC5905] format. 209 o Original Datagram - As much of invoking packet as possible without 210 the ICMPv6 packet exceeding the minimum ICMP MTU (576 bytes). The 211 original datagram MUST be zero padded to the nearest 32-bit 212 boundary. 214 ICMP OAM messages SHOULD be rate limited by the sender. 216 The Timestamp fields SHOULD be as accurate as possible. They SHOULD 217 reflect the time at which the original packet arrived, not the time 218 at which the ICMPv6 OAM message was sent. 220 6. IANA Considerations 222 IANA is requested to add an entry to the ICMP Type registry 223 (https://www.iana.org/assignments/icmp-parameters/icmp- 224 parameters.xhtml#icmp-parameters-types). The ICMP message name is 225 OAM and its value is TBD by IANA. 227 7. Security Considerations 229 All OAM actions elicited by the OAM bit must be rate-limited, so that 230 they cannot be used as denial of service attack vectors. 232 8. Acknowledgements 234 The authors wish to acknowledge Ross Callon for his contributions to 235 this document. 237 9. References 239 9.1. Normative References 241 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 242 DOI 10.17487/RFC0791, September 1981, 243 . 245 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 246 RFC 792, DOI 10.17487/RFC0792, September 1981, 247 . 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 255 "Network Time Protocol Version 4: Protocol and Algorithms 256 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 257 . 259 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 260 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 261 May 2017, . 263 9.2. Informative References 265 [InfRef] , 2004. 267 Authors' Addresses 269 Ashish Ghule 270 Juniper Networks 271 Bangalore, KA 56009 272 India 274 Email: aghule@juniper.net 276 Ron Bonica 277 Juniper Networks 278 Herndon, Virginia 20171 279 USA 281 Email: rbonica@juniper.net