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