idnits 2.17.1 draft-ietf-netmod-acl-model-19.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 250 has weird spacing: '...rw name str...' == Line 380 has weird spacing: '...warding ide...' == Line 387 has weird spacing: '...face-id if:...' == Line 2267 has weird spacing: '...keyword enu...' -- The document date (April 27, 2018) is 2188 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 informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD WG M. Jethanandani 3 Internet-Draft 4 Intended status: Standards Track L. Huang 5 Expires: October 29, 2018 General Electric 6 S. Agarwal 7 D. Blair 8 Cisco Systems, Inc. 9 April 27, 2018 11 Network Access Control List (ACL) YANG Data Model 12 draft-ietf-netmod-acl-model-19 14 Abstract 16 This document defines a data model for Access Control List (ACL). An 17 ACL is a user-ordered set of rules, used to configure the forwarding 18 behavior in device. Each rule is used to find a match on a packet, 19 and define actions that will be performed on the packet. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 29, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 4 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Understanding ACL's Filters and Actions . . . . . . . . . . . 5 61 3.1. ACL Modules . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. ACL YANG Models . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.1. IETF Access Control List module . . . . . . . . . . . . . 9 64 4.2. IETF Packet Fields module . . . . . . . . . . . . . . . . 24 65 4.3. An ACL Example . . . . . . . . . . . . . . . . . . . . . 36 66 4.4. Port Range Usage and Other Examples . . . . . . . . . . . 38 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 42 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 69 6.1. URI Registration . . . . . . . . . . . . . . . . . . . . 43 70 6.2. YANG Module Name Registration . . . . . . . . . . . . . . 43 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 44 74 8.2. Informative References . . . . . . . . . . . . . . . . . 45 75 Appendix A. Extending ACL model examples . . . . . . . . . . . . 46 76 A.1. A company proprietary module example . . . . . . . . . . 46 77 A.2. Linux nftables . . . . . . . . . . . . . . . . . . . . . 50 78 A.3. Ethertypes . . . . . . . . . . . . . . . . . . . . . . . 51 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 81 1. Introduction 83 Access Control List (ACL) is one of the basic elements used to 84 configure device forwarding behavior. It is used in many networking 85 technologies such as Policy Based Routing, Firewalls etc. 87 An ACL is an user-ordered set of rules, that is used to filter 88 traffic on a networking device. Each rule is represented by an 89 Access Control Entry (ACE). 91 Each ACE has a group of match criteria and a group of action 92 criteria. 94 The match criteria allows for definition of packet headers and 95 metadata, all of which must be true for the match to occur. 97 o Packet header matches apply to fields visible in the packet such 98 as address or Class of Service (CoS) or port numbers. 100 o In case a vendor supports it, metadata matches apply to fields 101 associated with the packet but not in the packet header such as 102 input interface or overall packet length 104 The actions specify what to do with the packet when the matching 105 criteria is met. These actions are any operations that would apply 106 to the packet, such as counting, policing, or simply forwarding. The 107 list of potential actions is unbounded depending on the capabilities 108 of the networking devices. 110 Access Control List is also widely knowns as ACL (pronounce as [ak-uh 111 l]) or Access List. In this document, Access Control List, ACL and 112 Access List are used interchangeably. 114 The matching of filters and actions in an ACE/ACL are triggered only 115 after application/attachment of the ACL to an interface, VRF, vty/tty 116 session, QoS policy, routing protocols amongst various other config 117 attachment points. Once attached, it is used for filtering traffic 118 using the match criteria in the ACE's and taking appropriate 119 action(s) that have been configured against that ACE. In order to 120 apply an ACL to any attachment point other than an interface, vendors 121 would have to augment the ACL YANG model. 123 Editorial Note (To be removed by RFC Editor) 125 This draft contains many placeholder values that need to be replaced 126 with finalized values at the time of publication. This note 127 summarizes all of the substitutions that are needed. Please note 128 that no other RFC Editor instructions are specified anywhere else in 129 this document. 131 Artwork in this document contains shorthand references to drafts in 132 progress. Please apply the following replacements 134 o "XXXX" --> the assigned RFC value for this draft both in this 135 draft and in the YANG models under the revision statement. 137 o Revision date in model, in the format 2018-04-27 needs to get 138 updated with the date the draft gets approved. The date also 139 needs to get reflected on the line with . 141 o Replace "I-D.ietf-netmod-yang-tree-diagrams" with the assigned RFC 142 number. 144 1.1. Definitions and Acronyms 146 ACE: Access Control Entry 148 ACL: Access Control List 150 CoS: Class of Service 152 DSCP: Differentiated Services Code Point 154 ICMP: Internet Control Message Protocol 156 IP: Internet Protocol 158 IPv4: Internet Protocol version 4 160 IPv6: Internet Protocol version 6 162 MAC: Media Access Control 164 TCP: Transmission Control Protocol 166 UDP: User Datagram Protocol 168 1.2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in BCP 173 14 [RFC2119] [RFC8174] when, and only when, they appear in all 174 capitals, as shown here. 176 1.3. Tree Diagram 178 For a reference to the annotations used in tree diagrams included in 179 this draft, please see YANG Tree Diagrams [RFC8340]. 181 2. Problem Statement 183 This document defines a YANG 1.1 [RFC7950] data model for the 184 configuration of ACLs. It is very important that model can be used 185 easily by applications/attachments. 187 ACL implementations in every device may vary greatly in terms of the 188 filter constructs and actions that they support. Therefore this 189 draft proposes a model that can be augmented by standard extensions 190 and vendor proprietary models. 192 3. Understanding ACL's Filters and Actions 194 Although different vendors have different ACL data models, there is a 195 common understanding of what Access Control List (ACL) is. A network 196 system usually has a list of ACLs, and each ACL contains an ordered 197 list of rules, also known as Access Control Entries (ACE). Each ACE 198 has a group of match criteria and a group of action criteria. The 199 match criteria allows for definition of packet headers or metadata, 200 if supported by the vendor. Packet header matching applies to fields 201 visible in the packet such as address or CoS or port numbers. 202 Metadata matching applies to fields associated with the packet, but 203 not in the packet header such as input interface, packet length, or 204 source or destination prefix length. The actions can be any sort of 205 operation from logging to rate limiting or dropping to simply 206 forwarding. Actions on the first matching ACE are applied with no 207 processing of subsequent ACEs. 209 The model also includes a container to hold overall operational state 210 for each ACL and operational state for each ACE. One ACL can be 211 applied to multiple targets within the device, such as interface of a 212 networking device, applications or features running in the device, 213 etc. When applied to interfaces of a networked device, distinct ACLs 214 are defined for the ingress (input) or egress (output) interface. 216 This draft tries to address the commonalities between all vendors and 217 create a common model, which can be augmented with proprietary 218 models. The base model is simple in design, and we hope to achieve 219 enough flexibility for each vendor to extend the base model. 221 The use of feature statements in the model allows vendors to 222 advertise match rules they are capable and willing to support. There 223 are two sets of feature statements a device needs to advertise. The 224 first set of feature statements specify the capability of the device. 225 These include features such as "Device can support ethernet headers" 226 or "Device can support of IPv4 headers". The second set of feature 227 statements specify the combinations of headers the device is willing 228 to support. These include features such as "Plain IPv6 ACL 229 supported" or "Ethernet, IPv4 and IPv6 ACL combinations supported". 231 3.1. ACL Modules 233 There are two YANG modules in the model. The first module, "ietf- 234 access-control-list", defines generic ACL aspects which are common to 235 all ACLs regardless of their type or vendor. In effect, the module 236 can be viewed as providing a generic ACL "superclass". It imports 237 the second module, "ietf-packet-fields". The match container in 238 "ietf-access-control-list" uses groupings in "ietf-packet-fields" to 239 specify match fields such as port numbers or protocol. The 240 combination of 'if-feature' checks and 'must' statements allow for 241 the selection of relevant match fields that a user can define rules 242 for. 244 If there is a need to define a new "matches" choice, such as IPFIX 245 [RFC7011], the container "matches" can be augmented. 247 module: ietf-access-control-list 248 +--rw acls 249 +--rw acl* [name] 250 | +--rw name string 251 | +--rw type? acl-type 252 | +--rw aces 253 | +--rw ace* [name] 254 | +--rw name string 255 | +--rw matches 256 | | +--rw (l2)? 257 | | | +--:(eth) 258 | | | +--rw eth {match-on-eth}? 259 | | | +--rw destination-mac-address? 260 | | | | yang:mac-address 261 | | | +--rw destination-mac-address-mask? 262 | | | | yang:mac-address 263 | | | +--rw source-mac-address? 264 | | | | yang:mac-address 265 | | | +--rw source-mac-address-mask? 266 | | | | yang:mac-address 267 | | | +--rw ethertype? 268 | | | eth:ethertype 269 | | +--rw (l3)? 270 | | | +--:(ipv4) 271 | | | | +--rw ipv4 {match-on-ipv4}? 272 | | | | +--rw dscp? inet:dscp 273 | | | | +--rw ecn? uint8 274 | | | | +--rw length? uint16 275 | | | | +--rw ttl? uint8 276 | | | | +--rw protocol? uint8 277 | | | | +--rw ihl? uint8 278 | | | | +--rw flags? bits 279 | | | | +--rw offset? uint16 280 | | | | +--rw identification? uint16 281 | | | | +--rw (destination-network)? 282 | | | | | +--:(destination-ipv4-network) 283 | | | | | +--rw destination-ipv4-network? 284 | | | | | inet:ipv4-prefix 285 | | | | +--rw (source-network)? 286 | | | | +--:(source-ipv4-network) 287 | | | | +--rw source-ipv4-network? 288 | | | | inet:ipv4-prefix 289 | | | +--:(ipv6) 290 | | | +--rw ipv6 {match-on-ipv6}? 291 | | | +--rw dscp? inet:dscp 292 | | | +--rw ecn? uint8 293 | | | +--rw length? uint16 294 | | | +--rw ttl? uint8 295 | | | +--rw protocol? uint8 296 | | | +--rw (destination-network)? 297 | | | | +--:(destination-ipv6-network) 298 | | | | +--rw destination-ipv6-network? 299 | | | | inet:ipv6-prefix 300 | | | +--rw (source-network)? 301 | | | | +--:(source-ipv6-network) 302 | | | | +--rw source-ipv6-network? 303 | | | | inet:ipv6-prefix 304 | | | +--rw flow-label? 305 | | | inet:ipv6-flow-label 306 | | +--rw (l4)? 307 | | | +--:(tcp) 308 | | | | +--rw tcp {match-on-tcp}? 309 | | | | +--rw sequence-number? uint32 310 | | | | +--rw acknowledgement-number? uint32 311 | | | | +--rw data-offset? uint8 312 | | | | +--rw reserved? uint8 313 | | | | +--rw flags? bits 314 | | | | +--rw window-size? uint16 315 | | | | +--rw urgent-pointer? uint16 316 | | | | +--rw options? uint32 317 | | | | +--rw source-port 318 | | | | | +--rw (source-port)? 319 | | | | | +--:(range-or-operator) 320 | | | | | +--rw (port-range-or-operator)? 321 | | | | | +--:(range) 322 | | | | | | +--rw lower-port 323 | | | | | | | inet:port-number 324 | | | | | | +--rw upper-port 325 | | | | | | inet:port-number 326 | | | | | +--:(operator) 327 | | | | | +--rw operator? operator 328 | | | | | +--rw port 329 | | | | | inet:port-number 330 | | | | +--rw destination-port 331 | | | | +--rw (destination-port)? 332 | | | | +--:(range-or-operator) 333 | | | | +--rw (port-range-or-operator)? 334 | | | | +--:(range) 335 | | | | | +--rw lower-port 336 | | | | | | inet:port-number 337 | | | | | +--rw upper-port 338 | | | | | inet:port-number 339 | | | | +--:(operator) 340 | | | | +--rw operator? operator 341 | | | | +--rw port 342 | | | | inet:port-number 343 | | | +--:(udp) 344 | | | | +--rw udp {match-on-udp}? 345 | | | | +--rw length? uint16 346 | | | | +--rw source-port 347 | | | | | +--rw (source-port)? 348 | | | | | +--:(range-or-operator) 349 | | | | | +--rw (port-range-or-operator)? 350 | | | | | +--:(range) 351 | | | | | | +--rw lower-port 352 | | | | | | | inet:port-number 353 | | | | | | +--rw upper-port 354 | | | | | | inet:port-number 355 | | | | | +--:(operator) 356 | | | | | +--rw operator? operator 357 | | | | | +--rw port 358 | | | | | inet:port-number 359 | | | | +--rw destination-port 360 | | | | +--rw (destination-port)? 361 | | | | +--:(range-or-operator) 362 | | | | +--rw (port-range-or-operator)? 363 | | | | +--:(range) 364 | | | | | +--rw lower-port 365 | | | | | | inet:port-number 366 | | | | | +--rw upper-port 367 | | | | | inet:port-number 368 | | | | +--:(operator) 369 | | | | +--rw operator? operator 370 | | | | +--rw port 371 | | | | inet:port-number 372 | | | +--:(icmp) 373 | | | +--rw icmp {match-on-icmp}? 374 | | | +--rw type? uint8 375 | | | +--rw code? uint8 376 | | | +--rw rest-of-header? uint32 377 | | +--rw egress-interface? if:interface-ref 378 | | +--rw ingress-interface? if:interface-ref 379 | +--rw actions 380 | | +--rw forwarding identityref 381 | | +--rw logging? identityref 382 | +--ro statistics {acl-aggregate-stats}? 383 | +--ro matched-packets? yang:counter64 384 | +--ro matched-octets? yang:counter64 385 +--rw attachment-points 386 +--rw interface* [interface-id] {interface-attachment}? 387 +--rw interface-id if:interface-ref 388 +--rw ingress 389 | +--rw acl-sets 390 | +--rw acl-set* [name] 391 | +--rw name -> /acls/acl/name 392 | +--ro ace-statistics* [name] {interface-stats}? 393 | +--ro name 394 | | -> /acls/acl/aces/ace/name 395 | +--ro matched-packets? yang:counter64 396 | +--ro matched-octets? yang:counter64 397 +--rw egress 398 +--rw acl-sets 399 +--rw acl-set* [name] 400 +--rw name -> /acls/acl/name 401 +--ro ace-statistics* [name] {interface-stats}? 402 +--ro name 403 | -> /acls/acl/aces/ace/name 404 +--ro matched-packets? yang:counter64 405 +--ro matched-octets? yang:counter64 407 4. ACL YANG Models 409 4.1. IETF Access Control List module 411 "ietf-access-control-list" module defines the "acls" container that 412 has a list of "acl". Each "acl" has information identifying the 413 access list by a name ("name") and a list ("aces") of rules 414 associated with the "name". Each of the entries in the list 415 ("aces"), indexed by the string "name", has containers defining 416 "matches" and "actions". 418 The model defines several ACL types and actions in the form of 419 identities and features. Features are used by implementors to select 420 the ACL types the system can support and identities are used to 421 validate the types that have been selected. These types are 422 implicitly inherited by the "ace", thus safeguarding against 423 misconfiguration of "ace" types in an "acl". 425 The "matches" define criteria used to identify patterns in "ietf- 426 packet-fields". The choice statements within the match container 427 allow for selection of one header within each of "l2", "l3", or "l4" 428 headers. The "actions" define behavior to undertake once a "match" 429 has been identified. In addition to permit and deny for actions, a 430 logging option allows for a match to be logged that can later be used 431 to determine which rule was matched upon. The model also defines the 432 ability for ACLs to be attached to a particular interface. 434 Statistics in the ACL can be collected for an "ace" or for an 435 "interface". The feature statements defined for statistics can be 436 used to determine whether statistics are being collected per "ace", 437 or per "interface". 439 This module imports definitions from Common YANG Data Types 440 [RFC6991], and A YANG Data Model for Interface Management [RFC8343]. 442 file "ietf-access-control-list@2018-04-27.yang" 444 module ietf-access-control-list { 445 yang-version 1.1; 446 namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list"; 447 prefix acl; 449 import ietf-yang-types { 450 prefix yang; 451 reference 452 "RFC 6991 - Common YANG Data Types."; 453 } 455 import ietf-packet-fields { 456 prefix pf; 457 reference 458 "RFC XXXX - Network ACL YANG Model."; 459 } 461 import ietf-interfaces { 462 prefix if; 463 reference 464 "RFC 8343 - A YANG Data Model for Interface Management."; 465 } 467 organization 468 "IETF NETMOD (Network Modeling Language) 469 Working Group"; 471 contact 472 "WG Web: http://tools.ietf.org/wg/netmod/ 473 WG List: netmod@ietf.org 475 Editor: Mahesh Jethanandani 476 mjethanandani@gmail.com 477 Editor: Lisa Huang 478 lyihuang16@gmail.com 480 Editor: Sonal Agarwal 481 sagarwal12@gmail.com 482 Editor: Dana Blair 483 dblair@cisco.com"; 485 description 486 "This YANG module defines a component that describe the 487 configuration of Access Control Lists (ACLs). 489 Copyright (c) 2018 IETF Trust and the persons identified as 490 the document authors. All rights reserved. 491 Redistribution and use in source and binary forms, with or 492 without modification, is permitted pursuant to, and subject 493 to the license terms contained in, the Simplified BSD 494 License set forth in Section 4.c of the IETF Trust's Legal 495 Provisions Relating to IETF Documents 496 (http://trustee.ietf.org/license-info). 498 This version of this YANG module is part of RFC XXXX; see 499 the RFC itself for full legal notices."; 501 revision 2018-04-27 { 502 description 503 "Initial version."; 504 reference 505 "RFC XXX: Network Access Control List (ACL) YANG Data Model."; 506 } 508 /* 509 * Identities 510 */ 512 /* 513 * Forwarding actions for a packet 514 */ 515 identity forwarding-action { 516 description 517 "Base identity for actions in the forwarding category"; 518 } 520 identity accept { 521 base forwarding-action; 522 description 523 "Accept the packet"; 524 } 526 identity drop { 527 base forwarding-action; 528 description 529 "Drop packet without sending any ICMP error message"; 530 } 532 identity reject { 533 base forwarding-action; 534 description 535 "Drop the packet and send an ICMP error message to the source"; 536 } 538 /* 539 * Logging actions for a packet 540 */ 541 identity log-action { 542 description 543 "Base identity for defining the destination for logging actions"; 544 } 546 identity log-syslog { 547 base log-action; 548 description 549 "System log (syslog) the information for the packet"; 550 } 552 identity log-none { 553 base log-action; 554 description 555 "No logging for the packet"; 556 } 558 /* 559 * ACL type identities 560 */ 561 identity acl-base { 562 description 563 "Base Access Control List type for all Access Control List type 564 identifiers."; 565 } 567 identity ipv4-acl-type { 568 base acl:acl-base; 569 if-feature "ipv4"; 570 description 571 "An ACL that matches on fields from the IPv4 header 572 (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP 573 destination port). An acl of type ipv4 does not contain 574 matches on fields in the ethernet header or the IPv6 header."; 575 } 576 identity ipv6-acl-type { 577 base acl:acl-base; 578 if-feature "ipv6"; 579 description 580 "An ACL that matches on fields from the IPv6 header 581 (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP 582 destination port). An acl of type ipv6 does not contain 583 matches on fields in the ethernet header or the IPv4 header."; 584 } 586 identity eth-acl-type { 587 base acl:acl-base; 588 if-feature "eth"; 589 description 590 "An ACL that matches on fields in the ethernet header, 591 like 10/100/1000baseT or WiFi Access Control List. An acl of 592 type ethernet does not contain matches on fields in the IPv4 593 header, IPv6 header or layer 4 headers."; 594 } 596 identity mixed-eth-ipv4-acl-type { 597 base "acl:eth-acl-type"; 598 base "acl:ipv4-acl-type"; 599 if-feature "mixed-eth-ipv4"; 600 description 601 "An ACL that contains a mix of entries that 602 match on fields in ethernet headers, 603 entries that match on IPv4 headers. 604 Matching on layer 4 header fields may also exist in the 605 list."; 606 } 608 identity mixed-eth-ipv6-acl-type { 609 base "acl:eth-acl-type"; 610 base "acl:ipv6-acl-type"; 611 if-feature "mixed-eth-ipv6"; 612 description 613 "ACL that contains a mix of entries that 614 match on fields in ethernet headers, entries 615 that match on fields in IPv6 headers. Matching on 616 layer 4 header fields may also exist in the list."; 617 } 619 identity mixed-eth-ipv4-ipv6-acl-type { 620 base "acl:eth-acl-type"; 621 base "acl:ipv4-acl-type"; 622 base "acl:ipv6-acl-type"; 623 if-feature "mixed-eth-ipv4-ipv6"; 624 description 625 "ACL that contains a mix of entries that 626 match on fields in ethernet headers, entries 627 that match on fields in IPv4 headers, and entries 628 that match on fields in IPv6 headers. Matching on 629 layer 4 header fields may also exist in the list."; 630 } 632 /* 633 * Features 634 */ 636 /* 637 * Features supported by device 638 */ 639 feature match-on-eth { 640 description 641 "The device can support matching on ethernet headers."; 642 } 644 feature match-on-ipv4 { 645 description 646 "The device can support matching on IPv4 headers."; 647 } 649 feature match-on-ipv6 { 650 description 651 "The device can support matching on IPv6 headers."; 652 } 654 feature match-on-tcp { 655 description 656 "The device can support TCP headers."; 657 } 659 feature match-on-udp { 660 description 661 "The device can support UDP header."; 662 } 664 feature match-on-icmp { 665 description 666 "The device can support ICMP header."; 667 } 669 /* 670 * Header classifications combinations supported by 671 * device 672 */ 673 feature eth { 674 if-feature "match-on-eth"; 675 description 676 "Plain Ethernet ACL supported"; 677 } 679 feature ipv4 { 680 if-feature "match-on-ipv4"; 681 description 682 "Plain IPv4 ACL supported"; 683 } 685 feature ipv6 { 686 if-feature "match-on-ipv6"; 687 description 688 "Plain IPv6 ACL supported"; 689 } 691 feature mixed-eth-ipv4 { 692 if-feature "match-on-eth and match-on-ipv4"; 693 description 694 "Ethernet and IPv4 ACL combinations supported"; 695 } 697 feature mixed-eth-ipv6 { 698 if-feature "match-on-eth and match-on-ipv6"; 699 description 700 "Ethernet and IPv6 ACL combinations supported"; 701 } 703 feature mixed-eth-ipv4-ipv6 { 704 if-feature "match-on-eth and match-on-ipv4 705 and match-on-ipv6"; 706 description 707 "Ethernet, IPv4 and IPv6 ACL combinations supported."; 708 } 710 /* 711 * Stats Features 712 */ 713 feature interface-stats { 714 description 715 "ACL counters are available and reported only per interface"; 716 } 718 feature acl-aggregate-stats { 719 description 720 "ACL counters are aggregated over all interfaces, and reported 721 only per ACL entry"; 722 } 724 /* 725 * Attachment point features 726 */ 727 feature interface-attachment { 728 description 729 "ACLs are set on interfaces."; 730 } 732 /* 733 * Typedefs 734 */ 735 typedef acl-type { 736 type identityref { 737 base acl-base; 738 } 739 description 740 "This type is used to refer to an Access Control List 741 (ACL) type"; 742 } 744 /* 745 * Groupings 746 */ 747 grouping acl-counters { 748 description 749 "Common grouping for ACL counters"; 751 leaf matched-packets { 752 type yang:counter64; 753 config false; 754 description 755 "Count of the number of packets matching the current ACL 756 entry. 758 An implementation should provide this counter on a 759 per-interface per-ACL-entry if possible. 761 If an implementation only supports ACL counters per entry 762 (i.e., not broken out per interface), then the value 763 should be equal to the aggregate count across all interfaces. 765 An implementation that provides counters per entry per 766 interface is not required to also provide an aggregate count, 767 e.g., per entry -- the user is expected to be able implement 768 the required aggregation if such a count is needed."; 769 } 771 leaf matched-octets { 772 type yang:counter64; 773 config false; 774 description 775 "Count of the number of octets (bytes) matching the current 776 ACL entry. 778 An implementation should provide this counter on a 779 per-interface per-ACL-entry if possible. 781 If an implementation only supports ACL counters per entry 782 (i.e., not broken out per interface), then the value 783 should be equal to the aggregate count across all interfaces. 785 An implementation that provides counters per entry per 786 interface is not required to also provide an aggregate count, 787 e.g., per entry -- the user is expected to be able implement 788 the required aggregation if such a count is needed."; 789 } 790 } 792 /* 793 * Configuration data nodes 794 */ 795 container acls { 796 description 797 "This is a top level container for Access Control Lists. 798 It can have one or more acl nodes."; 799 list acl { 800 key "name"; 801 description 802 "An Access Control List (ACL) is an ordered list of 803 Access Control Entries (ACE). Each ACE has a 804 list of match criteria and a list of actions. 805 Since there are several kinds of Access Control Lists 806 implemented with different attributes for 807 different vendors, this model accommodates customizing 808 Access Control Lists for each kind and, for each vendor."; 809 leaf name { 810 type string { 811 length "1..64"; 812 } 813 description 814 "The name of access list. A device MAY restrict the length 815 and value of this name, possibly space and special 816 characters are not allowed."; 817 } 818 leaf type { 819 type acl-type; 820 description 821 "Type of access control list. Indicates the primary intended 822 type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, 823 etc) used in the list instance."; 824 } 825 container aces { 826 description 827 "The aces container contains one or more ace nodes."; 828 list ace { 829 key "name"; 830 ordered-by user; 831 description 832 "List of Access Control Entries (ACEs)"; 833 leaf name { 834 type string { 835 length "1..64"; 836 } 837 description 838 "A unique name identifying this Access Control 839 Entry (ACE)."; 840 } 842 container matches { 843 description 844 "The rules in this set determine what fields will be 845 matched upon before any action is taken on them. 846 The rules are selected based on the feature set 847 defined by the server and the acl-type defined. 848 If no matches are defined in a particular container, 849 then any packet will match that container. If no 850 matches are specified at all in an ACE, then any 851 packet will match the ACE."; 853 choice l2 { 854 container eth { 855 when "derived-from-or-self(/acls/acl/type, " + 856 "'acl:eth-acl-type')"; 857 if-feature match-on-eth; 858 uses pf:acl-eth-header-fields; 859 description 860 "Rule set that matches ethernet headers."; 861 } 862 description 863 "Match layer 2 headers, for example ethernet 864 header fields."; 865 } 867 choice l3 { 868 container ipv4 { 869 when "derived-from-or-self(/acls/acl/type, " + 870 "'acl:ipv4-acl-type')"; 871 if-feature match-on-ipv4; 872 uses pf:acl-ip-header-fields; 873 uses pf:acl-ipv4-header-fields; 874 description 875 "Rule set that matches IPv4 headers."; 876 } 878 container ipv6 { 879 when "derived-from-or-self(/acls/acl/type, " + 880 "'acl:ipv6-acl-type')"; 881 if-feature match-on-ipv6; 882 uses pf:acl-ip-header-fields; 883 uses pf:acl-ipv6-header-fields; 884 description 885 "Rule set that matches IPv6 headers."; 886 } 887 description 888 "Choice of either ipv4 or ipv6 headers"; 889 } 891 choice l4 { 892 container tcp { 893 if-feature match-on-tcp; 894 uses pf:acl-tcp-header-fields; 895 container source-port { 896 choice source-port { 897 case range-or-operator { 898 uses pf:port-range-or-operator; 899 description 900 "Source port definition from range or 901 operator."; 902 } 903 description 904 "Choice of source port definition using 905 range/operator or a choice to support future 906 'case' statements, such as one enabling a 907 group of source ports to be referenced."; 908 } 909 description 910 "Source port definition."; 911 } 912 container destination-port { 913 choice destination-port { 914 case range-or-operator { 915 uses pf:port-range-or-operator; 916 description 917 "Destination port definition from range or 918 operator."; 919 } 920 description 921 "Choice of destination port definition using 922 range/operator or a choice to support future 923 'case' statements, such as one enabling a 924 group of destination ports to be referenced."; 925 } 926 description 927 "Destination port definition."; 928 } 929 description 930 "Rule set that matches TCP headers."; 931 } 933 container udp { 934 if-feature match-on-udp; 935 uses pf:acl-udp-header-fields; 936 container source-port { 937 choice source-port { 938 case range-or-operator { 939 uses pf:port-range-or-operator; 940 description 941 "Source port definition from range or 942 operator."; 943 } 944 description 945 "Choice of source port definition using 946 range/operator or a choice to support future 947 'case' statements, such as one enabling a 948 group of source ports to be referenced."; 949 } 950 description 951 "Source port definition."; 952 } 953 container destination-port { 954 choice destination-port { 955 case range-or-operator { 956 uses pf:port-range-or-operator; 957 description 958 "Destination port definition from range or 959 operator."; 961 } 962 description 963 "Choice of destination port definition using 964 range/operator or a choice to support future 965 'case' statements, such as one enabling a 966 group of destination ports to be referenced."; 967 } 968 description 969 "Destination port definition."; 970 } 971 description 972 "Rule set that matches UDP headers."; 973 } 975 container icmp { 976 if-feature match-on-icmp; 977 uses pf:acl-icmp-header-fields; 978 description 979 "Rule set that matches ICMP headers."; 980 } 981 description 982 "Choice of TCP, UDP or ICMP headers."; 983 } 985 leaf egress-interface { 986 type if:interface-ref; 987 description 988 "Egress interface. This should not be used if this ACL 989 is attached as an egress ACL (or the value should 990 equal the interface to which the ACL is attached)."; 991 } 993 leaf ingress-interface { 994 type if:interface-ref; 995 description 996 "Ingress interface. This should not be used if this ACL 997 is attached as an ingress ACL (or the value should 998 equal the interface to which the ACL is attached)"; 999 } 1000 } 1002 container actions { 1003 description 1004 "Definitions of action for this ace entry"; 1005 leaf forwarding { 1006 type identityref { 1007 base forwarding-action; 1008 } 1009 mandatory true; 1010 description 1011 "Specifies the forwarding action per ace entry"; 1012 } 1014 leaf logging { 1015 type identityref { 1016 base log-action; 1017 } 1018 default log-none; 1019 description 1020 "Specifies the log action and destination for 1021 matched packets. Default value is not to log the 1022 packet."; 1023 } 1024 } 1025 container statistics { 1026 if-feature "acl-aggregate-stats"; 1027 config false; 1028 description 1029 "Statistics gathered across all attachment points for the 1030 given ACL."; 1031 uses acl-counters; 1032 } 1033 } 1034 } 1035 } 1036 container attachment-points { 1037 description 1038 "Enclosing container for the list of 1039 attachment-points on which ACLs are set"; 1041 /* 1042 * Groupings 1043 */ 1044 grouping interface-acl { 1045 description 1046 "Grouping for per-interface ingress ACL data"; 1048 container acl-sets { 1049 description 1050 "Enclosing container the list of ingress ACLs on the 1051 interface"; 1053 list acl-set { 1054 key "name"; 1055 ordered-by user; 1056 description 1057 "List of ingress ACLs on the interface"; 1059 leaf name { 1060 type leafref { 1061 path "/acls/acl/name"; 1062 } 1063 description 1064 "Reference to the ACL name applied on ingress"; 1065 } 1067 list ace-statistics { 1068 if-feature "interface-stats"; 1069 key "name"; 1070 config false; 1071 description 1072 "List of Access Control Entries (ACEs)"; 1073 leaf name { 1074 type leafref { 1075 path "/acls/acl/aces/ace/name"; 1076 } 1077 description 1078 "The ace name"; 1079 } 1080 uses acl-counters; 1081 } 1082 } 1083 } 1084 } 1086 list interface { 1087 if-feature interface-attachment; 1088 key "interface-id"; 1089 description 1090 "List of interfaces on which ACLs are set"; 1092 leaf interface-id { 1093 type if:interface-ref; 1094 description 1095 "Reference to the interface id list key"; 1096 } 1098 container ingress { 1099 uses interface-acl; 1100 description 1101 "The ACLs applied to ingress interface"; 1102 } 1103 container egress { 1104 uses interface-acl; 1105 description 1106 "The ACLs applied to egress interface"; 1107 } 1108 } 1109 } 1110 } 1111 } 1113 1115 4.2. IETF Packet Fields module 1117 The packet fields module defines the necessary groups for matching on 1118 fields in the packet including ethernet, ipv4, ipv6, and transport 1119 layer fields. The "type" node determines which of these fields get 1120 included for any given ACL with the exception of TCP, UDP and ICMP 1121 header fields. Those fields can be used in conjunction with any of 1122 the above layer 2 or layer 3 fields. 1124 Since the number of match criteria is very large, the base draft does 1125 not include these directly but references them by 'uses' statement to 1126 keep the base module simple. In case more match conditions are 1127 needed, those can be added by augmenting choices within container 1128 "matches" in ietf-access-control-list.yang model. 1130 This module imports definitions from Common YANG Data Types [RFC6991] 1131 and references IP [RFC0791], ICMP [RFC0792], Definition of the 1132 Differentiated Services Field in the IPv4 and IPv6 Headers [RFC2474], 1133 The Addition of Explicit Congestion Notification (ECN) to IP 1134 [RFC3168], , IPv6 Scoped Address Architecture [RFC4007], IPv6 1135 Addressing Architecture [RFC4291], A Recommendation for IPv6 Address 1136 Text Representation [RFC5952], IPv6 [RFC8200]. 1138 file "ietf-packet-fields@2018-04-27.yang" 1140 module ietf-packet-fields { 1141 yang-version 1.1; 1142 namespace "urn:ietf:params:xml:ns:yang:ietf-packet-fields"; 1143 prefix packet-fields; 1145 import ietf-inet-types { 1146 prefix inet; 1147 reference 1148 "RFC 6991 - Common YANG Data Types."; 1149 } 1151 import ietf-yang-types { 1152 prefix yang; 1153 reference 1154 "RFC 6991 - Common YANG Data Types."; 1155 } 1157 import ietf-ethertypes { 1158 prefix eth; 1159 reference 1160 "RFC XXXX - Network ACL YANG Model."; 1161 } 1163 organization 1164 "IETF NETMOD (Network Modeling Language) Working 1165 Group"; 1167 contact 1168 "WG Web: http://tools.ietf.org/wg/netmod/ 1169 WG List: netmod@ietf.org 1171 Editor: Mahesh Jethanandani 1172 mjethanandani@gmail.com 1173 Editor: Lisa Huang 1174 lyihuang16@gmail.com 1175 Editor: Sonal Agarwal 1176 sagarwal12@gmail.com 1177 Editor: Dana Blair 1178 dblair@cisco.com"; 1180 description 1181 "This YANG module defines groupings that are used by 1182 ietf-access-control-list YANG module. Their usage is not 1183 limited to ietf-access-control-list and can be 1184 used anywhere as applicable. 1186 Copyright (c) 2018 IETF Trust and the persons identified as 1187 the document authors. All rights reserved. 1188 Redistribution and use in source and binary forms, with or 1189 without modification, is permitted pursuant to, and subject 1190 to the license terms contained in, the Simplified BSD 1191 License set forth in Section 4.c of the IETF Trust's Legal 1192 Provisions Relating to IETF Documents 1193 (http://trustee.ietf.org/license-info). 1195 This version of this YANG module is part of RFC XXXX; see 1196 the RFC itself for full legal notices."; 1198 revision 2018-04-27 { 1199 description 1200 "Initial version."; 1202 reference 1203 "RFC XXX: Network Access Control List (ACL) YANG Data Model."; 1204 } 1206 /* 1207 * Typedefs 1208 */ 1209 typedef operator { 1210 type enumeration { 1211 enum lte { 1212 description 1213 "Less than or equal."; 1214 } 1215 enum gte { 1216 description 1217 "Greater than or equal."; 1218 } 1219 enum eq { 1220 description 1221 "Equal to."; 1222 } 1223 enum neq { 1224 description 1225 "Not equal to."; 1226 } 1227 } 1228 description 1229 "The source and destination port range definitions 1230 can be further qualified using an operator. An 1231 operator is needed only if lower-port is specified 1232 and upper-port is not specified. The operator 1233 therefore further qualifies lower-port only."; 1234 } 1236 /* 1237 * Groupings 1238 */ 1239 grouping port-range-or-operator { 1240 choice port-range-or-operator { 1241 case range { 1242 leaf lower-port { 1243 type inet:port-number; 1244 must ". <= ../upper-port" { 1245 error-message 1246 "The lower-port must be less than or equal to 1247 upper-port."; 1248 } 1249 mandatory true; 1250 description 1251 "Lower boundry for a port."; 1252 } 1253 leaf upper-port { 1254 type inet:port-number; 1255 mandatory true; 1256 description 1257 "Upper boundry for port."; 1258 } 1259 } 1260 case operator { 1261 leaf operator { 1262 type operator; 1263 default eq; 1264 description 1265 "Operator to be applied on the port below."; 1266 } 1267 leaf port { 1268 type inet:port-number; 1269 mandatory true; 1270 description 1271 "Port number along with operator on which to 1272 match."; 1273 } 1274 } 1275 description 1276 "Choice of specifying a port range or a single 1277 port along with an operator."; 1278 } 1279 description 1280 "Grouping for port definitions in the form of a 1281 choice statement."; 1282 } 1284 grouping acl-ip-header-fields { 1285 description 1286 "IP header fields common to ipv4 and ipv6"; 1287 reference 1288 "RFC 791: Internet Protocol."; 1290 leaf dscp { 1291 type inet:dscp; 1292 description 1293 "Differentiated Services Code Point."; 1294 reference 1295 "RFC 2474: Definition of Differentiated services field 1296 (DS field) in the IPv4 and IPv6 headers."; 1297 } 1298 leaf ecn { 1299 type uint8 { 1300 range 0..3; 1301 } 1302 description 1303 "Explicit Congestion Notification."; 1304 reference 1305 "RFC 3168: Explicit Congestion Notification."; 1306 } 1308 leaf length { 1309 type uint16; 1310 description 1311 "In IPv4 header field, this field is known as the Total Length. 1312 Total Length is the length of the datagram, measured in octets, 1313 including internet header and data. 1315 In IPv6 header field, this field is known as the Payload 1316 Length, the length of the IPv6 payload, i.e. the rest of 1317 the packet following the IPv6 header, in octets."; 1318 reference 1319 "RFC 791: Internet Protocol, 1320 RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; 1321 } 1323 leaf ttl { 1324 type uint8; 1325 description 1326 "This field indicates the maximum time the datagram is allowed 1327 to remain in the internet system. If this field contains the 1328 value zero, then the datagram must be dropped. 1330 In IPv6, this field is known as the Hop Limit."; 1331 reference 1332 "RFC 791: Internet Protocol, 1333 RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; 1334 } 1336 leaf protocol { 1337 type uint8; 1338 description 1339 "Internet Protocol number. Refers to the protocol of the 1340 payload. In IPv6, this field is known as 'next-header, 1341 and if extension headers are present, the protocol is 1342 present in the 'upper-layer' header."; 1343 reference 1344 "RFC 791: Internet Protocol, 1345 RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; 1347 } 1348 } 1350 grouping acl-ipv4-header-fields { 1351 description 1352 "Fields in IPv4 header."; 1354 leaf ihl { 1355 type uint8 { 1356 range "5..60"; 1357 } 1358 description 1359 "An IPv4 header field, the Internet Header Length (IHL) is 1360 the length of the internet header in 32 bit words, and 1361 thus points to the beginning of the data. Note that the 1362 minimum value for a correct header is 5."; 1363 } 1365 leaf flags { 1366 type bits { 1367 bit reserved { 1368 position 0; 1369 description 1370 "Reserved. Must be zero."; 1371 } 1372 bit fragment { 1373 position 1; 1374 description 1375 "Setting value to 0 indicates may fragment, while setting 1376 the value to 1 indicates do not fragment."; 1377 } 1378 bit more { 1379 position 2; 1380 description 1381 "Setting the value to 0 indicates this is the last fragment, 1382 and setting the value to 1 indicates more fragments are 1383 coming."; 1384 } 1385 } 1386 description 1387 "Bit definitions for the flags field in IPv4 header."; 1388 } 1390 leaf offset { 1391 type uint16 { 1392 range "20..65535"; 1393 } 1394 description 1395 "The fragment offset is measured in units of 8 octets (64 bits). 1396 The first fragment has offset zero. The length is 13 bits"; 1397 } 1399 leaf identification { 1400 type uint16; 1401 description 1402 "An identifying value assigned by the sender to aid in 1403 assembling the fragments of a datagram."; 1404 } 1406 choice destination-network { 1407 case destination-ipv4-network { 1408 leaf destination-ipv4-network { 1409 type inet:ipv4-prefix; 1410 description 1411 "Destination IPv4 address prefix."; 1412 } 1413 } 1414 description 1415 "Choice of specifying a destination IPv4 address or 1416 referring to a group of IPv4 destination addresses."; 1417 } 1418 choice source-network { 1419 case source-ipv4-network { 1420 leaf source-ipv4-network { 1421 type inet:ipv4-prefix; 1422 description 1423 "Source IPv4 address prefix."; 1424 } 1425 } 1426 description 1427 "Choice of specifying a source IPv4 address or 1428 referring to a group of IPv4 source addresses."; 1429 } 1430 } 1432 grouping acl-ipv6-header-fields { 1433 description 1434 "Fields in IPv6 header"; 1436 choice destination-network { 1437 case destination-ipv6-network { 1438 leaf destination-ipv6-network { 1439 type inet:ipv6-prefix; 1440 description 1441 "Destination IPv6 address prefix."; 1442 } 1444 } 1445 description 1446 "Choice of specifying a destination IPv6 address 1447 or referring to a group of IPv6 destination 1448 addresses."; 1449 } 1451 choice source-network { 1452 case source-ipv6-network { 1453 leaf source-ipv6-network { 1454 type inet:ipv6-prefix; 1455 description 1456 "Source IPv6 address prefix."; 1457 } 1458 } 1459 description 1460 "Choice of specifying a source IPv6 address or 1461 referring to a group of IPv6 source addresses."; 1462 } 1464 leaf flow-label { 1465 type inet:ipv6-flow-label; 1466 description 1467 "IPv6 Flow label."; 1468 } 1469 reference 1470 "RFC 4291: IP Version 6 Addressing Architecture 1471 RFC 4007: IPv6 Scoped Address Architecture 1472 RFC 5952: A Recommendation for IPv6 Address Text 1473 Representation"; 1474 } 1476 grouping acl-eth-header-fields { 1477 description 1478 "Fields in Ethernet header."; 1480 leaf destination-mac-address { 1481 type yang:mac-address; 1482 description 1483 "Destination IEEE 802 MAC address."; 1484 } 1485 leaf destination-mac-address-mask { 1486 type yang:mac-address; 1487 description 1488 "Destination IEEE 802 MAC address mask."; 1489 } 1490 leaf source-mac-address { 1491 type yang:mac-address; 1492 description 1493 "Source IEEE 802 MAC address."; 1494 } 1495 leaf source-mac-address-mask { 1496 type yang:mac-address; 1497 description 1498 "Source IEEE 802 MAC address mask."; 1499 } 1500 leaf ethertype { 1501 type eth:ethertype; 1502 description 1503 "The Ethernet Type (or Length) value represented 1504 in the canonical order defined by IEEE 802. 1505 The canonical representation uses lowercase 1506 characters."; 1507 reference 1508 "IEEE 802-2014 Clause 9.2"; 1509 } 1510 reference 1511 "IEEE 802: IEEE Standard for Local and Metropolitan 1512 Area Networks: Overview and Architecture."; 1513 } 1515 grouping acl-tcp-header-fields { 1516 description 1517 "Collection of TCP header fields that can be used to 1518 setup a match filter."; 1520 leaf sequence-number { 1521 type uint32; 1522 description 1523 "Sequence number that appears in the packet."; 1524 } 1526 leaf acknowledgement-number { 1527 type uint32; 1528 description 1529 "The acknowledgement number that appears in the 1530 packet."; 1531 } 1533 leaf data-offset { 1534 type uint8 { 1535 range "5..15"; 1536 } 1537 description 1538 "Specifies the size of the TCP header in 32-bit 1539 words. The minimum size header is 5 words and 1540 the maximum is 15 words thus giving the minimum 1541 size of 20 bytes and maximum of 60 bytes, 1542 allowing for up to 40 bytes of options in the 1543 header."; 1544 } 1546 leaf reserved { 1547 type uint8; 1548 description 1549 "Reserved for future use."; 1550 } 1552 leaf flags { 1553 type bits { 1554 bit cwr { 1555 position 1; 1556 description 1557 "Congestion Window Reduced (CWR) flag is set by 1558 the sending host to indicate that it received 1559 a TCP segment with the ECE flag set and had 1560 responded in congestion control mechanism."; 1561 reference 1562 "RFC 3168: The Addition of Explicit Congestion 1563 Notification (ECN) to IP."; 1564 } 1565 bit ece { 1566 position 2; 1567 description 1568 "ECN-Echo has a dual role, depending on the value 1569 of the SYN flag. It indicates: 1570 If the SYN flag is set (1), that the TCP peer is ECN 1571 capable. If the SYN flag is clear (0), that a packet 1572 with Congestion Experienced flag set (ECN=11) in IP 1573 header was received during normal transmission 1574 (added to header by RFC 3168). This serves as an 1575 indication of network congestion (or impending 1576 congestion) to the TCP sender."; 1577 reference 1578 "RFC 3168: The Addition of Explicit Congestion 1579 Notification (ECN) to IP."; 1580 } 1581 bit urg { 1582 position 3; 1583 description 1584 "Indicates that the Urgent pointer field is significant."; 1585 } 1586 bit ack { 1587 position 4; 1588 description 1589 "Indicates that the Acknowledgment field is significant. 1590 All packets after the initial SYN packet sent by the 1591 client should have this flag set."; 1592 } 1593 bit psh { 1594 position 5; 1595 description 1596 "Push function. Asks to push the buffered data to the 1597 receiving application."; 1598 } 1599 bit rst { 1600 position 6; 1601 description 1602 "Reset the connection."; 1603 } 1604 bit syn { 1605 position 7; 1606 description 1607 "Synchronize sequence numbers. Only the first packet 1608 sent from each end should have this flag set. Some 1609 other flags and fields change meaning based on this 1610 flag, and some are only valid for when it is set, 1611 and others when it is clear."; 1612 } 1613 bit fin { 1614 position 8; 1615 description 1616 "Last package from sender."; 1617 } 1618 } 1619 description 1620 "Also known as Control Bits. Contains 9 1-bit flags."; 1621 reference 1622 "RFC 793: Transmission Control Protocol (TCP)."; 1623 } 1625 leaf window-size { 1626 type uint16; 1627 units "bytes"; 1628 description 1629 "The size of the receive window, which specifies 1630 the number of window size units beyond the segment 1631 identified by the sequence number in the acknowledgment 1632 field that the sender of this segment is currently 1633 willing to receive."; 1634 } 1635 leaf urgent-pointer { 1636 type uint16; 1637 description 1638 "This field is an offset from the sequence number 1639 indicating the last urgent data byte."; 1640 } 1642 leaf options { 1643 type uint32; 1644 description 1645 "The length of this field is determined by the 1646 data offset field. Options have up to three 1647 fields: Option-Kind (1 byte), Option-Length 1648 (1 byte), Option-Data (variable). The Option-Kind 1649 field indicates the type of option, and is the 1650 only field that is not optional. Depending on 1651 what kind of option we are dealing with, 1652 the next two fields may be set: the Option-Length 1653 field indicates the total length of the option, 1654 and the Option-Data field contains the value of 1655 the option, if applicable."; 1656 } 1657 } 1659 grouping acl-udp-header-fields { 1660 description 1661 "Collection of UDP header fields that can be used 1662 to setup a match filter."; 1664 leaf length { 1665 type uint16; 1666 description 1667 "A field that specifies the length in bytes of 1668 the UDP header and UDP data. The minimum 1669 length is 8 bytes because that is the length of 1670 the header. The field size sets a theoretical 1671 limit of 65,535 bytes (8 byte header + 65,527 1672 bytes of data) for a UDP datagram. However the 1673 actual limit for the data length, which is 1674 imposed by the underlying IPv4 protocol, is 1675 65,507 bytes (65,535 minus 8 byte UDP header 1676 minus 20 byte IP header). 1678 In IPv6 jumbograms it is possible to have 1679 UDP packets of size greater than 65,535 bytes. 1680 RFC 2675 specifies that the length field is set 1681 to zero if the length of the UDP header plus 1682 UDP data is greater than 65,535."; 1684 } 1685 } 1687 grouping acl-icmp-header-fields { 1688 description 1689 "Collection of ICMP header fields that can be 1690 used to setup a match filter."; 1692 leaf type { 1693 type uint8; 1694 description 1695 "Also known as Control messages."; 1696 reference 1697 "RFC 792: Internet Control Message Protocol (ICMP)."; 1698 } 1700 leaf code { 1701 type uint8; 1702 description 1703 "ICMP subtype. Also known as Control messages."; 1704 } 1706 leaf rest-of-header { 1707 type uint32; 1708 description 1709 "Four-bytes field, contents vary based on the 1710 ICMP type and code."; 1711 } 1712 } 1713 } 1715 1717 4.3. An ACL Example 1719 Requirement: Deny tcp traffic from 192.0.2.0/24, destined to 1720 198.51.100.0/24. 1722 Here is the acl configuration xml for this Access Control List: 1724 [note: '\' line wrapping for formatting only] 1726 1727 1728 1730 1731 sample-ipv4-acl 1732 ipv4-acl-type 1733 1734 1735 rule1 1736 1737 1738 6 1739 198.51.100.0/24 1741 192.0.2.0/24 1743 1744 1745 1746 drop 1747 1748 1749 1750 1751 1752 1754 The acl and aces can be described in CLI as the following: 1756 acl ipv4 sample-ipv4-acl 1757 deny tcp 192.0.2.0/24 198.51.100.0/24 1759 Requirement: Accept all DNS traffic destined for 2001:db8::/32 on 1760 port 53. 1762 [note: '\' line wrapping for formatting only] 1764 1765 1766 1768 1769 allow-dns-packets 1770 ipv6-acl-type 1771 1772 1773 rule1 1774 1775 1776 2001:db8::/32 1778 1779 1780 1781 eq 1782 53 1783 1784 1785 1786 1787 accept 1788 1789 1790 1791 1792 1793 1795 4.4. Port Range Usage and Other Examples 1797 When a lower-port and an upper-port are both present, it represents a 1798 range between lower-port and upper-port with both the lower-port and 1799 upper-port included. When only a port is present, it represents a 1800 port, with the operator specifying the range. 1802 The following XML example represents a configuration where TCP 1803 traffic from source ports 16384, 16385, 16386, and 16387 is dropped. 1805 1806 1807 1809 1810 sample-port-acl 1811 ipv4-acl-type 1812 1813 1814 rule1 1815 1816 1817 1818 16384 1819 16387 1820 1821 1822 1823 1824 drop 1825 1826 1827 1828 1829 1830 1832 The following XML example represents a configuration where all IPv4 1833 ICMP echo requests are dropped. 1835 1836 1837 1839 1840 sample-icmp-acl 1841 1842 1843 rule1 1844 1845 1846 1 1847 1848 1849 8 1850 0 1851 1852 1853 1854 drop 1855 1856 1857 1858 1859 1860 1862 The following XML example represents a configuration of a single 1863 port, port 21 that accepts TCP traffic. 1865 1866 1867 1869 1870 sample-ipv4-acl 1871 ipv4-acl-type 1872 1873 1874 rule1 1875 1876 1877 1878 eq 1879 21 1880 1881 1882 1883 1884 accept 1885 1886 1887 1888 1889 1890 1892 The following XML example represents a configuration specifying all 1893 ports that are not equal to 21, that will drop TCP packets destined 1894 for those ports. 1896 1897 1898 1900 1901 sample-ipv4-acl 1902 ipv4-acl-type 1903 1904 1905 rule1 1906 1907 1908 1909 neq 1910 21 1911 1912 1913 1914 1915 drop 1916 1917 1918 1919 1920 1921 1923 5. Security Considerations 1925 The YANG module specified in this document defines a schema for data 1926 that is designed to be accessed via network management protocol such 1927 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1928 is the secure transport layer and the mandatory-to-implement secure 1929 transport is SSH [RFC6242]. The lowest RESTCONF layer is HTTPS, and 1930 the mandatory-to-implement secure transport is TLS [RFC5246]. 1932 The NETCONF Access Control Model (NACM [RFC8341]) provides the means 1933 to restrict access for particular NETCONF users to a pre-configured 1934 subset of all available NETCONF protocol operations and content. 1936 There are a number of data nodes defined in the YANG module which are 1937 writable/creatable/deletable (i.e., config true, which is the 1938 default). These data nodes may be considered sensitive or vulnerable 1939 in some network environments. Write operations (e.g., ) 1940 to these data nodes without proper protection can have a negative 1941 effect on network operations. 1943 These are the subtrees and data nodes and their sensitivity/ 1944 vulnerability: 1946 /acls/acl/aces: This list specifies all the configured access 1947 control entries on the device. Unauthorized write access to this 1948 list can allow intruders to access and control the system. 1949 Unauthorized read access to this list can allow intruders to spoof 1950 packets with authorized addresses thereby compromising the system. 1952 6. IANA Considerations 1954 This document registers three URIs and three YANG modules. 1956 6.1. URI Registration 1958 This document registers three URIs in the IETF XML registry 1959 [RFC3688]. Following the format in RFC 3688, the following 1960 registration is requested to be made: 1962 URI: urn:ietf:params:xml:ns:yang:ietf-access-control-list 1963 URI: urn:ietf:params:xml:ns:yang:ietf-packet-fields 1964 URI: urn:ietf:params:xml:ns:yang:ietf-ethertypes 1966 Registrant Contact: The IESG. 1968 XML: N/A, the requested URI is an XML namespace. 1970 6.2. YANG Module Name Registration 1972 This document registers three YANG module in the YANG Module Names 1973 registry YANG [RFC6020]. 1975 name: ietf-access-control-list 1976 namespace: urn:ietf:params:xml:ns:yang:ietf-access-control-list 1977 prefix: acl 1978 reference: RFC XXXX 1980 name: ietf-packet-fields 1981 namespace: urn:ietf:params:xml:ns:yang:ietf-packet-fields 1982 prefix: packet-fields 1983 reference: RFC XXXX 1985 name: ietf-ethertypes 1986 namespace: urn:ietf:params:xml:ns:yang:ietf-ethertypes 1987 prefix: ethertypes 1988 reference: RFC XXXX 1990 7. Acknowledgements 1992 Alex Clemm, Andy Bierman and Lisa Huang started it by sketching out 1993 an initial IETF draft in several past IETF meetings. That draft 1994 included an ACL YANG model structure and a rich set of match filters, 1995 and acknowledged contributions by Louis Fourie, Dana Blair, Tula 1996 Kraiser, Patrick Gili, George Serpa, Martin Bjorklund, Kent Watsen, 1997 and Phil Shafer. Many people have reviewed the various earlier 1998 drafts that made the draft went into IETF charter. 2000 Dean Bogdanovic, Kiran Agrahara Sreenivasa, Lisa Huang, and Dana 2001 Blair each evaluated the YANG model in previous drafts separately, 2002 and then worked together to created a ACL draft that was supported by 2003 different vendors. That draft removed vendor specific features, and 2004 gave examples to allow vendors to extend in their own proprietary 2005 ACL. The earlier draft was superseded with this updated draft and 2006 received more participation from many vendors. 2008 Authors would like to thank Jason Sterne, Lada Lhotka, Juergen 2009 Schoenwalder, David Bannister, Jeff Haas, Kristian Larsson and Einar 2010 Nilsen-Nygaard for their review of and suggestions to the draft. 2012 8. References 2014 8.1. Normative References 2016 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2017 DOI 10.17487/RFC0791, September 1981, 2018 . 2020 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2021 RFC 792, DOI 10.17487/RFC0792, September 1981, 2022 . 2024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2025 Requirement Levels", BCP 14, RFC 2119, 2026 DOI 10.17487/RFC2119, March 1997, 2027 . 2029 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2030 "Definition of the Differentiated Services Field (DS 2031 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2032 DOI 10.17487/RFC2474, December 1998, 2033 . 2035 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2036 of Explicit Congestion Notification (ECN) to IP", 2037 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2038 . 2040 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 2041 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 2042 DOI 10.17487/RFC4007, March 2005, 2043 . 2045 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2046 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2047 2006, . 2049 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2050 Address Text Representation", RFC 5952, 2051 DOI 10.17487/RFC5952, August 2010, 2052 . 2054 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2055 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2056 . 2058 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2059 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2060 . 2062 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2063 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2064 May 2017, . 2066 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2067 (IPv6) Specification", STD 86, RFC 8200, 2068 DOI 10.17487/RFC8200, July 2017, 2069 . 2071 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 2072 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 2073 . 2075 8.2. Informative References 2077 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2078 DOI 10.17487/RFC3688, January 2004, 2079 . 2081 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2082 (TLS) Protocol Version 1.2", RFC 5246, 2083 DOI 10.17487/RFC5246, August 2008, 2084 . 2086 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2087 the Network Configuration Protocol (NETCONF)", RFC 6020, 2088 DOI 10.17487/RFC6020, October 2010, 2089 . 2091 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2092 and A. Bierman, Ed., "Network Configuration Protocol 2093 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2094 . 2096 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2097 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2098 . 2100 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2101 "Specification of the IP Flow Information Export (IPFIX) 2102 Protocol for the Exchange of Flow Information", STD 77, 2103 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2104 . 2106 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2107 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2108 . 2110 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2111 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2112 . 2114 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2115 Access Control Model", STD 91, RFC 8341, 2116 DOI 10.17487/RFC8341, March 2018, 2117 . 2119 Appendix A. Extending ACL model examples 2121 A.1. A company proprietary module example 2123 Module "example-newco-acl" is an example of company proprietary model 2124 that augments "ietf-acl" module. It shows how to use 'augment' with 2125 an XPath expression to add additional match criteria, action 2126 criteria, and default actions when no ACE matches are found. All 2127 these are company proprietary extensions or system feature 2128 extensions. "example-newco-acl" is just an example and it is 2129 expected that vendors will create their own proprietary models. 2131 module example-newco-acl { 2133 yang-version 1.1; 2135 namespace "http://example.com/ns/example-newco-acl"; 2137 prefix example-newco-acl; 2139 import ietf-access-control-list { 2140 prefix "acl"; 2141 } 2143 organization 2144 "Newco model group."; 2146 contact 2147 "abc@newco.com"; 2148 description 2149 "This YANG module augments IETF ACL Yang."; 2151 revision 2018-04-27 { 2152 description 2153 "Creating NewCo proprietary extensions to ietf-acl model"; 2155 reference 2156 "RFC XXXX: Network Access Control List (ACL) 2157 YANG Data Model"; 2158 } 2160 augment "/acl:acls/acl:acl/" + 2161 "acl:aces/acl:ace/" + 2162 "acl:matches" { 2163 description "Newco proprietary simple filter matches"; 2164 choice protocol-payload-choice { 2165 description "Newco proprietary payload match condition"; 2166 list protocol-payload { 2167 key value-keyword; 2168 ordered-by user; 2169 description "Match protocol payload"; 2170 uses match-simple-payload-protocol-value; 2171 } 2172 } 2174 choice metadata { 2175 description "Newco proprietary interface match condition"; 2176 leaf packet-length { 2177 type uint16; 2178 description "Match on packet length"; 2179 } 2180 } 2181 } 2183 augment "/acl:acls/acl:acl/" + 2184 "acl:aces/acl:ace/" + 2185 "acl:actions" { 2186 description "Newco proprietary simple filter actions"; 2187 choice action { 2188 description ""; 2189 case count { 2190 description "Count the packet in the named counter"; 2191 leaf count { 2192 type uint32; 2193 description "Count"; 2194 } 2195 } 2196 case policer { 2197 description "Name of policer to use to rate-limit traffic"; 2198 leaf policer { 2199 type string; 2200 description "Name of the policer"; 2201 } 2202 } 2203 case hiearchical-policer { 2204 leaf hierarchitacl-policer { 2205 type string; 2206 description 2207 "Name of the hierarchical policer."; 2208 } 2209 description 2210 "Name of hierarchical policer to use to 2211 rate-limit traffic"; 2212 } 2213 } 2214 } 2216 augment "/acl:acls/acl:acl" + 2217 "/acl:aces/acl:ace/" + 2218 "acl:actions" { 2219 leaf default-action { 2220 type identityref { 2221 base acl:forwarding-action; 2222 } 2223 default acl:drop; 2224 description 2225 "Actions that occur if no ace is matched."; 2226 } 2227 description 2228 "Newco proprietary default action"; 2229 } 2231 grouping match-simple-payload-protocol-value { 2232 description "Newco proprietary payload"; 2233 leaf value-keyword { 2234 type enumeration { 2235 enum icmp { 2236 description "Internet Control Message Protocol"; 2237 } 2238 enum icmp6 { 2239 description 2240 "Internet Control Message Protocol 2241 Version 6"; 2242 } 2243 enum range { 2244 description "Range of values"; 2245 } 2246 } 2247 description "(null)"; 2248 } 2249 } 2250 } 2252 The following figure is the tree diagram of example-newco-acl. In 2253 this example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ 2254 ietf-acl:matches are augmented with two new choices, protocol- 2255 payload-choice and metadata. The protocol-payload-choice uses a 2256 grouping with an enumeration of all supported protocol values. 2257 Metadata matches apply to fields associated with the packet but not 2258 in the packet header such as overall packet length. In another 2259 example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf- 2260 acl:actions are augmented with a new choice of actions. 2262 module: example-newco-acl 2263 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: 2264 +--rw (protocol-payload-choice)? 2265 | +--:(protocol-payload) 2266 | +--rw protocol-payload* [value-keyword] 2267 | +--rw value-keyword enumeration 2268 +--rw (metadata)? 2269 +--:(packet-length) 2270 +--rw packet-length? uint16 2271 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions: 2272 +--rw (action)? 2273 +--:(count) 2274 | +--rw count? uint32 2275 +--:(policer) 2276 | +--rw policer? string 2277 +--:(hiearchical-policer) 2278 +--rw hierarchitacl-policer? string 2279 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions: 2280 +--rw default-action? identityref 2282 A.2. Linux nftables 2284 As Linux platform is becoming more popular as networking platform, 2285 the Linux data model is changing. Previously ACLs in Linux were 2286 highly protocol specific and different utilities were used (iptables, 2287 ip6tables, arptables, ebtables), so each one had separate data model. 2288 Recently, this has changed and a single utility, nftables, has been 2289 developed. With a single application, it has a single data model for 2290 filewall filters and it follows very similarly to the ietf-access- 2291 control list module proposed in this draft. The nftables support 2292 input and output ACEs and each ACE can be defined with match and 2293 action. 2295 The example in Section 4.3 can be configured using nftable tool as 2296 below. 2298 nft add table ip filter 2299 nft add chain filter input 2300 nft add rule ip filter input ip protocol tcp ip saddr \ 2301 192.0.2.1/24 drop 2303 The configuration entries added in nftable would be. 2305 table ip filter { 2306 chain input { 2307 ip protocol tcp ip saddr 192.0.2.1/24 drop 2308 } 2309 } 2311 We can see that there are many similarities between Linux nftables 2312 and IETF ACL YANG data models and its extension models. It should be 2313 fairly easy to do translation between ACL YANG model described in 2314 this draft and Linux nftables. 2316 A.3. Ethertypes 2318 The ACL module is dependent on the definition of ethertypes. IEEE 2319 owns the allocation of those ethertypes. This model is being 2320 included here to enable definition of those types till such time that 2321 IEEE takes up the task of publication of the model that defines those 2322 ethertypes. At that time, this model can be deprecated. 2324 file "ietf-ethertypes@2018-04-27.yang" 2326 module ietf-ethertypes { 2327 namespace "urn:ietf:params:xml:ns:yang:ietf-ethertypes"; 2328 prefix ethertypes; 2330 organization 2331 "IETF NETMOD (NETCONF Data Modeling Language)"; 2333 contact 2334 "WG Web: 2335 WG List: 2337 Editor: Mahesh Jethanandani 2338 "; 2340 description 2341 "This module contains the common definitions for the 2342 Ethertype used by different modules. It is a 2343 placeholder module, till such time that IEEE 2344 starts a project to define these Ethertypes 2345 and publishes a standard. 2347 At that time this module can be deprecated."; 2349 revision 2018-04-27 { 2350 description 2351 "Initial revision."; 2353 reference 2354 "RFC XXXX: IETF Ethertype YANG Data Module."; 2355 } 2357 typedef ethertype { 2358 type union { 2359 type uint16; 2360 type enumeration { 2361 enum ipv4 { 2362 value 2048; 2363 description 2364 "Internet Protocol version 4 (IPv4) with a 2365 hex value of 0x0800."; 2366 reference 2367 "RFC 791: Internet Protocol."; 2368 } 2369 enum arp { 2370 value 2054; 2371 description 2372 "Address Resolution Protocol (ARP) with a 2373 hex value of 0x0806."; 2374 reference 2375 "RFC 826: An Ethernet Address Resolution Protocol."; 2376 } 2377 enum wlan { 2378 value 2114; 2379 description 2380 "Wake-on-LAN. Hex value of 0x0842."; 2381 } 2382 enum trill { 2383 value 8947; 2384 description 2385 "Transparent Interconnection of Lots of Links. 2386 Hex value of 0x22F3."; 2387 reference 2388 "RFC 6325: Routing Bridges (RBridges): Base Protocol 2389 Specification."; 2390 } 2391 enum srp { 2392 value 8938; 2393 description 2394 "Stream Reservation Protocol. Hex value of 2395 0x22EA."; 2396 reference 2397 "IEEE 801.1Q-2011."; 2398 } 2399 enum decnet { 2400 value 24579; 2401 description 2402 "DECnet Phase IV. Hex value of 0x6003."; 2403 } 2404 enum rarp { 2405 value 32821; 2406 description 2407 "Reverse Address Resolution Protocol. 2408 Hex value 0x8035."; 2409 reference 2410 "RFC 903. A Reverse Address Resolution Protocol."; 2411 } 2412 enum appletalk { 2413 value 32923; 2414 description 2415 "Appletalk (Ethertalk). Hex value 0x809B."; 2416 } 2417 enum aarp { 2418 value 33011; 2419 description 2420 "Appletalk Address Resolution Protocol. Hex value 2421 of 0x80F3."; 2422 } 2423 enum vlan { 2424 value 33024; 2425 description 2426 "VLAN-tagged frame (802.1Q) and Shortest Path 2427 Bridging IEEE 802.1aq with NNI compatibility. 2428 Hex value 0x8100."; 2429 reference 2430 "802.1Q."; 2431 } 2432 enum ipx { 2433 value 33079; 2434 description 2435 "Internetwork Packet Exchange (IPX). Hex value 2436 of 0x8137."; 2437 } 2438 enum qnx { 2439 value 33284; 2440 description 2441 "QNX Qnet. Hex value of 0x8204."; 2442 } 2443 enum ipv6 { 2444 value 34525; 2445 description 2446 "Internet Protocol Version 6 (IPv6). Hex value 2447 of 0x86DD."; 2448 reference 2449 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2450 Specification 2451 RFC 8201: Path MTU Discovery for IPv6."; 2452 } 2453 enum efc { 2454 value 34824; 2455 description 2456 "Ethernet flow control using pause frames. 2457 Hex value of 0x8808"; 2458 reference 2459 "IEEE Std. 802.1Qbb."; 2460 } 2461 enum esp { 2462 value 34825; 2463 description 2464 "Ethernet Slow Protocol. Hex value of 0x8809."; 2465 reference 2466 "IEEE Std. 802.3-2015"; 2467 } 2468 enum cobranet { 2469 value 34841; 2470 description 2471 "CobraNet. Hex value of 0x"; 2472 } 2473 enum mpls-unicast { 2474 value 34887; 2475 description 2476 "MultiProtocol Label Switch (MPLS) unicast traffic. 2477 Hex value of 0x8847."; 2478 reference 2479 "RFC 3031: Multiprotocol Label Switching Architecture."; 2480 } 2481 enum mpls-multicast { 2482 value 34888; 2483 description 2484 "MultiProtocol Label Switch (MPLS) multicast traffic. 2485 Hex value of 0x8848."; 2486 reference 2487 "RFC 3031: Multiprotocol Label Switching Architecture."; 2488 } 2489 enum pppoe-discovery { 2490 value 34915; 2491 description 2492 "Point-to-Point Protocol over Ethernet. Used during 2493 the discovery process. Hex value of 0x8863."; 2494 reference 2495 "RFC 2516: A method for Transmitting PPP over Ethernet 2496 PPPoE."; 2498 } 2499 enum pppoe-session { 2500 value 34916; 2501 description 2502 "Point-to-Point Protocol over Ethernet. Used during 2503 session stage. Hex value of 0x8864."; 2504 reference 2505 "RFC 2516: A method for Transmitting PPP over Ethernet 2506 PPPoE."; 2507 } 2508 enum intel-ans { 2509 value 34925; 2510 description 2511 "Intel Advanced Networking Services. Hex value of 2512 0x886D."; 2513 } 2514 enum jumbo-frames { 2515 value 34928; 2516 description 2517 "Jumbo frames or Ethernet frames with more than 2518 1500 bytes of payload, upto 9000 bytes."; 2519 } 2520 enum homeplug { 2521 value 34939; 2522 description 2523 "Family name for the various power line 2524 communications. Hex value of 0x887B."; 2525 } 2526 enum eap { 2527 value 34958; 2528 description 2529 "Ethernet Access Protocol (EAP) over LAN. Hex value 2530 of 0x888E."; 2531 reference 2532 "IEEE 802.1X"; 2533 } 2534 enum profinet { 2535 value 34962; 2536 description 2537 "PROcess FIeld Net (PROFINET). Hex value of 0x8892."; 2538 } 2539 enum hyperscsi { 2540 value 34970; 2541 description 2542 "SCSI over Ethernet. Hex value of 0x889A"; 2543 } 2544 enum aoe { 2545 value 34978; 2546 description 2547 "Advanced Technology Advancement (ATA) over Ethernet. 2548 Hex value of 0x88A2."; 2549 } 2550 enum ethercat { 2551 value 34980; 2552 description 2553 "Ethernet for Control Automation Technology (EtherCAT). 2554 Hex value of 0x88A4."; 2555 } 2556 enum provider-bridging { 2557 value 34984; 2558 description 2559 "Provider Bridging (802.1ad) and Shortest Path Bridging 2560 (801.1aq). Hex value of 0x88A8."; 2561 reference 2562 "IEEE 802.1ad, IEEE 802.1aq)."; 2563 } 2564 enum ethernet-powerlink { 2565 value 34987; 2566 description 2567 "Ethernet Powerlink. Hex value of 0x88AB."; 2568 } 2569 enum goose { 2570 value 35000; 2571 description 2572 "Generic Object Oriented Substation Event (GOOSE). 2573 Hex value of 0x88B8."; 2574 reference 2575 "IEC/ISO 8802-2 and 8802-3."; 2576 } 2577 enum gse { 2578 value 35001; 2579 description 2580 "Generic Substation Events. Hex value of 88B9."; 2581 reference 2582 "IEC 61850."; 2583 } 2584 enum sv { 2585 value 35002; 2586 description 2587 "Sampled Value Transmission. Hex value of 0x88BA."; 2588 reference 2589 "IEC 61850."; 2590 } 2591 enum lldp { 2592 value 35020; 2593 description 2594 "Link Layer Discovery Protocol (LLDP). Hex value of 2595 0x88CC."; 2596 reference 2597 "IEEE 802.1AB."; 2598 } 2599 enum sercos { 2600 value 35021; 2601 description 2602 "Sercos Interface. Hex value of 0x88CD."; 2603 } 2604 enum wsmp { 2605 value 35036; 2606 description 2607 "WAVE Short Message Protocl (WSMP). Hex value of 2608 0x88DC."; 2609 } 2610 enum homeplug-av-mme { 2611 value 35041; 2612 description 2613 "HomePlug AV MME. Hex value of 88E1."; 2614 } 2615 enum mrp { 2616 value 35043; 2617 description 2618 "Media Redundancy Protocol (MRP). Hex value of 2619 0x88E3."; 2620 reference 2621 "IEC62439-2."; 2622 } 2623 enum macsec { 2624 value 35045; 2625 description 2626 "MAC Security. Hex value of 0x88E5."; 2627 reference 2628 "IEEE 802.1AE."; 2629 } 2630 enum pbb { 2631 value 35047; 2632 description 2633 "Provider Backbone Bridges (PBB). Hex value of 2634 0x88E7."; 2635 reference 2636 "IEEE 802.1ah."; 2637 } 2638 enum cfm { 2639 value 35074; 2640 description 2641 "Connectivity Fault Management (CFM). Hex value of 2642 0x8902."; 2643 reference 2644 "IEEE 802.1ag."; 2645 } 2646 enum fcoe { 2647 value 35078; 2648 description 2649 "Fiber Channel over Ethernet (FCoE). Hex value of 2650 0x8906."; 2651 reference 2652 "T11 FC-BB-5."; 2653 } 2654 enum fcoe-ip { 2655 value 35092; 2656 description 2657 "FCoE Initialization Protocol. Hex value of 0x8914."; 2658 } 2659 enum roce { 2660 value 35093; 2661 description 2662 "RDMA over Converged Ethernet (RoCE). Hex value of 2663 0x8915."; 2664 } 2665 enum tte { 2666 value 35101; 2667 description 2668 "TTEthernet Protocol Control Frame (TTE). Hex value 2669 of 0x891D."; 2670 reference 2671 "SAE AS6802."; 2672 } 2673 enum hsr { 2674 value 35119; 2675 description 2676 "High-availability Seamless Redundancy (HSR). Hex 2677 value of 0x892F."; 2678 reference 2679 "IEC 62439-3:2016."; 2680 } 2681 } 2682 } 2683 description 2684 "The uint16 type placeholder is defined to enable 2685 users to manage their own ethertypes not 2686 covered by the module. Otherwise the module contains 2687 enum definitions for the more commonly used ethertypes."; 2688 } 2689 } 2690 2692 Authors' Addresses 2694 Mahesh Jethanandani 2696 Email: mjethanandani@gmail.com 2698 Lisa Huang 2699 General Electric 2701 Email: lyihuang16@gmail.com 2703 Sonal Agarwal 2704 Cisco Systems, Inc. 2706 Email: sagarwal12@gmail.com 2708 Dana Blair 2709 Cisco Systems, Inc. 2711 Email: dblair@cisco.com