idnits 2.17.1 draft-ietf-netmod-acl-model-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 251 has weird spacing: '...rw name str...' == Line 381 has weird spacing: '...warding ide...' == Line 388 has weird spacing: '...face-id if:...' == Line 2238 has weird spacing: '...keyword enu...' -- The document date (March 15, 2018) is 2233 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 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 2 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: September 16, 2018 General Electric 6 S. Agarwal 7 D. Blair 8 Cisco Systems, Inc. 9 March 15, 2018 11 Network Access Control List (ACL) YANG Data Model 12 draft-ietf-netmod-acl-model-18 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 September 16, 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 . . . . . . . . . . . 37 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 41 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 69 6.1. URI Registration . . . . . . . . . . . . . . . . . . . . 42 70 6.2. YANG Module Name Registration . . . . . . . . . . . . . . 42 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 43 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 . . . . . . . . . . . . . . . . . . . . . 49 78 A.3. Ethertypes . . . . . . . . . . . . . . . . . . . . . . . 50 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 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-03-15 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 180 [I-D.ietf-netmod-yang-tree-diagrams]. 182 2. Problem Statement 184 This document defines a YANG [RFC7950] data model for the 185 configuration of ACLs. It is very important that model can be used 186 easily by applications/attachments. 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 action criteria. The 200 match criteria allows for definition of packet headers or metadata, 201 if supported by the vendor. Packet header matching applies to fields 202 visible in the packet such as address or CoS or port numbers. 203 Metadata matching applies to fields associated with the packet, but 204 not in the packet header such as input interface, packet length, or 205 source or destination prefix length. The actions can be any sort of 206 operation from logging to rate limiting or dropping to simply 207 forwarding. Actions on the first matching ACE are applied with no 208 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 ethernet headers" 227 or "Device can support of IPv4 headers". The second set of feature 228 statements specify the combinations of headers the device is willing 229 to support. These include features such as "Plain IPv6 ACL 230 supported" or "Ethernet, IPv4 and IPv6 ACL combinations supported". 232 3.1. ACL Modules 234 There are two YANG modules in the model. The first module, "ietf- 235 access-control-list", defines generic ACL aspects which are common to 236 all ACLs regardless of their type or vendor. In effect, the module 237 can be viewed as providing a generic ACL "superclass". It imports 238 the second module, "ietf-packet-fields". The match container in 239 "ietf-access-control-list" uses groupings in "ietf-packet-fields" to 240 specify match fields such as port numbers or protocol. The 241 combination of 'if-feature' checks and 'must' statements allow for 242 the selection of relevant match fields that a user can define rules 243 for. 245 If there is a need to define a new "matches" choice, such as IPFIX 246 [RFC7011], the container "matches" can be augmented. 248 module: ietf-access-control-list 249 +--rw acls 250 +--rw acl* [name] 251 | +--rw name string 252 | +--rw type? acl-type 253 | +--rw aces 254 | +--rw ace* [name] 255 | +--rw name string 256 | +--rw matches 257 | | +--rw (l2)? 258 | | | +--:(eth) 259 | | | +--rw eth {match-on-eth}? 260 | | | +--rw destination-mac-address? 261 | | | | yang:mac-address 262 | | | +--rw destination-mac-address-mask? 263 | | | | yang:mac-address 264 | | | +--rw source-mac-address? 265 | | | | yang:mac-address 266 | | | +--rw source-mac-address-mask? 267 | | | | yang:mac-address 268 | | | +--rw ethertype? 269 | | | eth:ethertype 270 | | +--rw (l3)? 271 | | | +--:(ipv4) 272 | | | | +--rw ipv4 {match-on-ipv4}? 273 | | | | +--rw dscp? inet:dscp 274 | | | | +--rw ecn? uint8 275 | | | | +--rw length? uint16 276 | | | | +--rw ttl? uint8 277 | | | | +--rw protocol? uint8 278 | | | | +--rw ihl? uint8 279 | | | | +--rw flags? bits 280 | | | | +--rw offset? uint16 281 | | | | +--rw identification? uint16 282 | | | | +--rw (destination-network)? 283 | | | | | +--:(destination-ipv4-network) 284 | | | | | +--rw destination-ipv4-network? 285 | | | | | inet:ipv4-prefix 286 | | | | +--rw (source-network)? 287 | | | | +--:(source-ipv4-network) 288 | | | | +--rw source-ipv4-network? 289 | | | | inet:ipv4-prefix 290 | | | +--:(ipv6) 291 | | | +--rw ipv6 {match-on-ipv6}? 292 | | | +--rw dscp? inet:dscp 293 | | | +--rw ecn? uint8 294 | | | +--rw length? uint16 295 | | | +--rw ttl? uint8 296 | | | +--rw protocol? uint8 297 | | | +--rw (destination-network)? 298 | | | | +--:(destination-ipv6-network) 299 | | | | +--rw destination-ipv6-network? 300 | | | | inet:ipv6-prefix 301 | | | +--rw (source-network)? 302 | | | | +--:(source-ipv6-network) 303 | | | | +--rw source-ipv6-network? 304 | | | | inet:ipv6-prefix 305 | | | +--rw flow-label? 306 | | | inet:ipv6-flow-label 307 | | +--rw (l4)? 308 | | | +--:(tcp) 309 | | | | +--rw tcp {match-on-tcp}? 310 | | | | +--rw sequence-number? uint32 311 | | | | +--rw acknowledgement-number? uint32 312 | | | | +--rw data-offset? uint8 313 | | | | +--rw reserved? uint8 314 | | | | +--rw flags? bits 315 | | | | +--rw window-size? uint16 316 | | | | +--rw urgent-pointer? uint16 317 | | | | +--rw options? uint32 318 | | | | +--rw source-port 319 | | | | | +--rw (source-port)? 320 | | | | | +--:(range-or-operator) 321 | | | | | +--rw (port-range-or-operator)? 322 | | | | | +--:(range) 323 | | | | | | +--rw lower-port 324 | | | | | | | inet:port-number 325 | | | | | | +--rw upper-port 326 | | | | | | inet:port-number 327 | | | | | +--:(operator) 328 | | | | | +--rw operator? operator 329 | | | | | +--rw port 330 | | | | | inet:port-number 331 | | | | +--rw destination-port 332 | | | | +--rw (destination-port)? 333 | | | | +--:(range-or-operator) 334 | | | | +--rw (port-range-or-operator)? 335 | | | | +--:(range) 336 | | | | | +--rw lower-port 337 | | | | | | inet:port-number 338 | | | | | +--rw upper-port 339 | | | | | inet:port-number 340 | | | | +--:(operator) 341 | | | | +--rw operator? operator 342 | | | | +--rw port 343 | | | | inet:port-number 344 | | | +--:(udp) 345 | | | | +--rw udp {match-on-udp}? 346 | | | | +--rw length? uint16 347 | | | | +--rw source-port 348 | | | | | +--rw (source-port)? 349 | | | | | +--:(range-or-operator) 350 | | | | | +--rw (port-range-or-operator)? 351 | | | | | +--:(range) 352 | | | | | | +--rw lower-port 353 | | | | | | | inet:port-number 354 | | | | | | +--rw upper-port 355 | | | | | | inet:port-number 356 | | | | | +--:(operator) 357 | | | | | +--rw operator? operator 358 | | | | | +--rw port 359 | | | | | inet:port-number 360 | | | | +--rw destination-port 361 | | | | +--rw (destination-port)? 362 | | | | +--:(range-or-operator) 363 | | | | +--rw (port-range-or-operator)? 364 | | | | +--:(range) 365 | | | | | +--rw lower-port 366 | | | | | | inet:port-number 367 | | | | | +--rw upper-port 368 | | | | | inet:port-number 369 | | | | +--:(operator) 370 | | | | +--rw operator? operator 371 | | | | +--rw port 372 | | | | inet:port-number 373 | | | +--:(icmp) 374 | | | +--rw icmp {match-on-icmp}? 375 | | | +--rw type? uint8 376 | | | +--rw code? uint8 377 | | | +--rw rest-of-header? uint32 378 | | +--rw egress-interface? if:interface-ref 379 | | +--rw ingress-interface? if:interface-ref 380 | +--rw actions 381 | | +--rw forwarding identityref 382 | | +--rw logging? identityref 383 | +--ro statistics {acl-aggregate-stats}? 384 | +--ro matched-packets? yang:counter64 385 | +--ro matched-octets? yang:counter64 386 +--rw attachment-points 387 +--rw interface* [interface-id] {interface-attachment}? 388 +--rw interface-id if:interface-ref 389 +--rw ingress 390 | +--rw acl-sets 391 | +--rw acl-set* [name] 392 | +--rw name -> /acls/acl/name 393 | +--ro ace-statistics* [name] {interface-stats}? 394 | +--ro name 395 | | -> /acls/acl/aces/ace/name 396 | +--ro matched-packets? yang:counter64 397 | +--ro matched-octets? yang:counter64 398 +--rw egress 399 +--rw acl-sets 400 +--rw acl-set* [name] 401 +--rw name -> /acls/acl/name 402 +--ro ace-statistics* [name] {interface-stats}? 403 +--ro name 404 | -> /acls/acl/aces/ace/name 405 +--ro matched-packets? yang:counter64 406 +--ro matched-octets? yang:counter64 408 4. ACL YANG Models 410 4.1. IETF Access Control List module 412 "ietf-access-control-list" module defines the "acls" container that 413 has a list of "acl". Each "acl" has information identifying the 414 access list by a name ("name") and a list ("aces") of rules 415 associated with the "name". Each of the entries in the list 416 ("aces"), indexed by the string "name", has containers defining 417 "matches" and "actions". 419 The model defines several ACL types and actions in the form of 420 identities and features. Features are used by implementors to select 421 the ACL types the system can support and identities are used to 422 validate the types that have been selected. These types are 423 implicitly inherited by the "ace", thus safeguarding against 424 misconfiguration of "ace" types in an "acl". 426 The "matches" define criteria used to identify patterns in "ietf- 427 packet-fields". The choice statements within the match container 428 allow for selection of one header within each of "l2", "l3", or "l4" 429 headers. The "actions" define behavior to undertake once a "match" 430 has been identified. In addition to permit and deny for actions, a 431 logging option allows for a match to be logged that can later be used 432 to determine which rule was matched upon. The model also defines the 433 ability for ACLs to be attached to a particular interface. 435 Statistics in the ACL can be collected for an "ace" or for an 436 "interface". The feature statements defined for statistics can be 437 used to determine whether statistics are being collected per "ace", 438 or per "interface". 440 This module imports definitions from Common YANG Data Types 441 [RFC6991], and A YANG Data Model for Interface Management 442 [I-D.ietf-netmod-rfc7223bis]. 444 file "ietf-access-control-list@2018-03-15.yang" 446 module ietf-access-control-list { 447 yang-version 1.1; 448 namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list"; 449 prefix acl; 451 import ietf-yang-types { 452 prefix yang; 453 reference 454 "RFC 6991 - Common YANG Data Types."; 455 } 457 import ietf-packet-fields { 458 prefix pf; 459 reference 460 "RFC XXXX - Network ACL YANG Model."; 461 } 463 import ietf-interfaces { 464 prefix if; 465 reference 466 "I-D.draft-ietf-netmod-rfc7223bis - A YANG Data Model for 467 Interface Management."; 468 } 470 organization 471 "IETF NETMOD (Network Modeling Language) 472 Working Group"; 474 contact 475 "WG Web: http://tools.ietf.org/wg/netmod/ 476 WG List: netmod@ietf.org 478 Editor: Mahesh Jethanandani 479 mjethanandani@gmail.com 481 Editor: Lisa Huang 482 lyihuang16@gmail.com 483 Editor: Sonal Agarwal 484 sagarwal12@gmail.com 485 Editor: Dana Blair 486 dblair@cisco.com"; 488 description 489 "This YANG module defines a component that describe the 490 configuration of Access Control Lists (ACLs). 492 Copyright (c) 2018 IETF Trust and the persons identified as 493 the document authors. All rights reserved. 494 Redistribution and use in source and binary forms, with or 495 without modification, is permitted pursuant to, and subject 496 to the license terms contained in, the Simplified BSD 497 License set forth in Section 4.c of the IETF Trust's Legal 498 Provisions Relating to IETF Documents 499 (http://trustee.ietf.org/license-info). 501 This version of this YANG module is part of RFC XXXX; see 502 the RFC itself for full legal notices."; 504 revision 2018-03-15 { 505 description 506 "Initial version."; 507 reference 508 "RFC XXX: Network Access Control List (ACL) YANG Data Model."; 509 } 511 /* 512 * Identities 513 */ 515 /* 516 * Forwarding actions for a packet 517 */ 518 identity forwarding-action { 519 description 520 "Base identity for actions in the forwarding category"; 521 } 523 identity accept { 524 base forwarding-action; 525 description 526 "Accept the packet"; 527 } 528 identity drop { 529 base forwarding-action; 530 description 531 "Drop packet without sending any ICMP error message"; 532 } 534 identity reject { 535 base forwarding-action; 536 description 537 "Drop the packet and send an ICMP error message to the source"; 538 } 540 /* 541 * Logging actions for a packet 542 */ 543 identity log-action { 544 description 545 "Base identity for defining the destination for logging actions"; 546 } 548 identity log-syslog { 549 base log-action; 550 description 551 "System log (syslog) the information for the packet"; 552 } 554 identity log-none { 555 base log-action; 556 description 557 "No logging for the packet"; 558 } 560 /* 561 * ACL type identities 562 */ 563 identity acl-base { 564 description 565 "Base Access Control List type for all Access Control List type 566 identifiers."; 567 } 569 identity ipv4-acl-type { 570 base acl:acl-base; 571 if-feature "ipv4"; 572 description 573 "An ACL that matches on fields from the IPv4 header 574 (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP 575 destination port). An acl of type ipv4 does not contain 576 matches on fields in the ethernet header or the IPv6 header."; 577 } 579 identity ipv6-acl-type { 580 base acl:acl-base; 581 if-feature "ipv6"; 582 description 583 "An ACL that matches on fields from the IPv6 header 584 (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP 585 destination port). An acl of type ipv6 does not contain 586 matches on fields in the ethernet header or the IPv4 header."; 587 } 589 identity eth-acl-type { 590 base acl:acl-base; 591 if-feature "eth"; 592 description 593 "An ACL that matches on fields in the ethernet header, 594 like 10/100/1000baseT or WiFi Access Control List. An acl of 595 type ethernet does not contain matches on fields in the IPv4 596 header, IPv6 header or layer 4 headers."; 597 } 599 identity mixed-eth-ipv4-acl-type { 600 base "acl:eth-acl-type"; 601 base "acl:ipv4-acl-type"; 602 if-feature "mixed-eth-ipv4"; 603 description 604 "An ACL that contains a mix of entries that 605 match on fields in ethernet headers, 606 entries that match on IPv4 headers. 607 Matching on layer 4 header fields may also exist in the 608 list."; 609 } 611 identity mixed-eth-ipv6-acl-type { 612 base "acl:eth-acl-type"; 613 base "acl:ipv6-acl-type"; 614 if-feature "mixed-eth-ipv6"; 615 description 616 "ACL that contains a mix of entries that 617 match on fields in ethernet headers, entries 618 that match on fields in IPv6 headers. Matching on 619 layer 4 header fields may also exist in the list."; 620 } 622 identity mixed-eth-ipv4-ipv6-acl-type { 623 base "acl:eth-acl-type"; 624 base "acl:ipv4-acl-type"; 625 base "acl:ipv6-acl-type"; 626 if-feature "mixed-eth-ipv4-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 IPv4 headers, and entries 631 that match on fields in IPv6 headers. Matching on 632 layer 4 header fields may also exist in the list."; 633 } 635 /* 636 * Features 637 */ 639 /* 640 * Features supported by device 641 */ 642 feature match-on-eth { 643 description 644 "The device can support matching on ethernet headers."; 645 } 647 feature match-on-ipv4 { 648 description 649 "The device can support matching on IPv4 headers."; 650 } 652 feature match-on-ipv6 { 653 description 654 "The device can support matching on IPv6 headers."; 655 } 657 feature match-on-tcp { 658 description 659 "The device can support TCP headers."; 660 } 662 feature match-on-udp { 663 description 664 "The device can support UDP header."; 665 } 667 feature match-on-icmp { 668 description 669 "The device can support ICMP header."; 670 } 671 /* 672 * Header classifications combinations supported by 673 * device 674 */ 675 feature eth { 676 if-feature "match-on-eth"; 677 description 678 "Plain Ethernet ACL supported"; 679 } 681 feature ipv4 { 682 if-feature "match-on-ipv4"; 683 description 684 "Plain IPv4 ACL supported"; 685 } 687 feature ipv6 { 688 if-feature "match-on-ipv6"; 689 description 690 "Plain IPv6 ACL supported"; 691 } 693 feature mixed-eth-ipv4 { 694 if-feature "match-on-eth and match-on-ipv4"; 695 description 696 "Ethernet and IPv4 ACL combinations supported"; 697 } 699 feature mixed-eth-ipv6 { 700 if-feature "match-on-eth and match-on-ipv6"; 701 description 702 "Ethernet and IPv6 ACL combinations supported"; 703 } 705 feature mixed-eth-ipv4-ipv6 { 706 if-feature "match-on-eth and match-on-ipv4 707 and match-on-ipv6"; 708 description 709 "Ethernet, IPv4 and IPv6 ACL combinations supported."; 710 } 712 /* 713 * Stats Features 714 */ 715 feature interface-stats { 716 description 717 "ACL counters are available and reported only per interface"; 718 } 719 feature acl-aggregate-stats { 720 description 721 "ACL counters are aggregated over all interfaces, and reported 722 only per ACL entry"; 723 } 725 /* 726 * Attachment point features 727 */ 728 feature interface-attachment { 729 description 730 "ACLs are set on interfaces."; 731 } 733 /* 734 * Typedefs 735 */ 736 typedef acl-type { 737 type identityref { 738 base acl-base; 739 } 740 description 741 "This type is used to refer to an Access Control List 742 (ACL) type"; 743 } 745 /* 746 * Groupings 747 */ 748 grouping acl-counters { 749 description 750 "Common grouping for ACL counters"; 752 leaf matched-packets { 753 type yang:counter64; 754 config false; 755 description 756 "Count of the number of packets matching the current ACL 757 entry. 759 An implementation should provide this counter on a 760 per-interface per-ACL-entry if possible. 762 If an implementation only supports ACL counters per entry 763 (i.e., not broken out per interface), then the value 764 should be equal to the aggregate count across all interfaces. 766 An implementation that provides counters per entry per 767 interface is not required to also provide an aggregate count, 768 e.g., per entry -- the user is expected to be able implement 769 the required aggregation if such a count is needed."; 770 } 772 leaf matched-octets { 773 type yang:counter64; 774 config false; 775 description 776 "Count of the number of octets (bytes) matching the current 777 ACL entry. 779 An implementation should provide this counter on a 780 per-interface per-ACL-entry if possible. 782 If an implementation only supports ACL counters per entry 783 (i.e., not broken out per interface), then the value 784 should be equal to the aggregate count across all interfaces. 786 An implementation that provides counters per entry per 787 interface is not required to also provide an aggregate count, 788 e.g., per entry -- the user is expected to be able implement 789 the required aggregation if such a count is needed."; 790 } 791 } 793 /* 794 * Configuration data nodes 795 */ 796 container acls { 797 description 798 "This is a top level container for Access Control Lists. 799 It can have one or more acl nodes."; 800 list acl { 801 key "name"; 802 description 803 "An Access Control List (ACL) is an ordered list of 804 Access Control Entries (ACE). Each ACE has a 805 list of match criteria and a list of actions. 806 Since there are several kinds of Access Control Lists 807 implemented with different attributes for 808 different vendors, this model accommodates customizing 809 Access Control Lists for each kind and, for each vendor."; 810 leaf name { 811 type string { 812 length "1..64"; 813 } 814 description 815 "The name of access list. A device MAY restrict the length 816 and value of this name, possibly space and special 817 characters are not allowed."; 818 } 819 leaf type { 820 type acl-type; 821 description 822 "Type of access control list. Indicates the primary intended 823 type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, 824 etc) used in the list instance."; 825 } 826 container aces { 827 description 828 "The aces container contains one or more ace nodes."; 829 list ace { 830 key "name"; 831 ordered-by user; 832 description 833 "List of Access Control Entries (ACEs)"; 834 leaf name { 835 type string { 836 length "1..64"; 837 } 838 description 839 "A unique name identifying this Access Control 840 Entry (ACE)."; 841 } 843 container matches { 844 description 845 "The rules in this set determine what fields will be 846 matched upon before any action is taken on them. 847 The rules are selected based on the feature set 848 defined by the server and the acl-type defined. 849 If no matches are defined in a particular container, 850 then any packet will match that container. If no 851 matches are specified at all in an ACE, then any 852 packet will match the ACE."; 854 choice l2 { 855 container eth { 856 when "derived-from-or-self(/acls/acl/type, " + 857 "'acl:eth-acl-type')"; 858 if-feature match-on-eth; 859 uses pf:acl-eth-header-fields; 860 description 861 "Rule set that matches ethernet headers."; 862 } 863 description 864 "Match layer 2 headers, for example ethernet 865 header fields."; 866 } 868 choice l3 { 869 container ipv4 { 870 when "derived-from-or-self(/acls/acl/type, " + 871 "'acl:ipv4-acl-type')"; 872 if-feature match-on-ipv4; 873 uses pf:acl-ip-header-fields; 874 uses pf:acl-ipv4-header-fields; 875 description 876 "Rule set that matches IPv4 headers."; 877 } 879 container ipv6 { 880 when "derived-from-or-self(/acls/acl/type, " + 881 "'acl:ipv6-acl-type')"; 882 if-feature match-on-ipv6; 883 uses pf:acl-ip-header-fields; 884 uses pf:acl-ipv6-header-fields; 885 description 886 "Rule set that matches IPv6 headers."; 887 } 888 description 889 "Choice of either ipv4 or ipv6 headers"; 890 } 892 choice l4 { 893 container tcp { 894 if-feature match-on-tcp; 895 uses pf:acl-tcp-header-fields; 896 container source-port { 897 choice source-port { 898 case range-or-operator { 899 uses pf:port-range-or-operator; 900 description 901 "Source port definition from range or 902 operator."; 903 } 904 description 905 "Choice of source port definition using 906 range/operator or a choice to support future 907 'case' statements, such as one enabling a 908 group of source ports to be referenced."; 909 } 910 description 911 "Source port definition."; 912 } 913 container destination-port { 914 choice destination-port { 915 case range-or-operator { 916 uses pf:port-range-or-operator; 917 description 918 "Destination port definition from range or 919 operator."; 920 } 921 description 922 "Choice of destination port definition using 923 range/operator or a choice to support future 924 'case' statements, such as one enabling a 925 group of destination ports to be referenced."; 926 } 927 description 928 "Destination port definition."; 929 } 930 description 931 "Rule set that matches TCP headers."; 932 } 934 container udp { 935 if-feature match-on-udp; 936 uses pf:acl-udp-header-fields; 937 container source-port { 938 choice source-port { 939 case range-or-operator { 940 uses pf:port-range-or-operator; 941 description 942 "Source port definition from range or 943 operator."; 944 } 945 description 946 "Choice of source port definition using 947 range/operator or a choice to support future 948 'case' statements, such as one enabling a 949 group of source ports to be referenced."; 950 } 951 description 952 "Source port definition."; 953 } 954 container destination-port { 955 choice destination-port { 956 case range-or-operator { 957 uses pf:port-range-or-operator; 958 description 959 "Destination port definition from range or 960 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-03-15.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 } 1150 import ietf-yang-types { 1151 prefix yang; 1152 reference 1153 "RFC 6991 - Common YANG Data Types."; 1154 } 1156 import ietf-ethertypes { 1157 prefix eth; 1158 reference 1159 "RFC XXXX - Network ACL YANG Model."; 1160 } 1162 organization 1163 "IETF NETMOD (Network Modeling Language) Working 1164 Group"; 1166 contact 1167 "WG Web: http://tools.ietf.org/wg/netmod/ 1168 WG List: netmod@ietf.org 1170 Editor: Mahesh Jethanandani 1171 mjethanandani@gmail.com 1172 Editor: Lisa Huang 1173 lyihuang16@gmail.com 1174 Editor: Sonal Agarwal 1175 sagarwal12@gmail.com 1176 Editor: Dana Blair 1177 dblair@cisco.com"; 1179 description 1180 "This YANG module defines groupings that are used by 1181 ietf-access-control-list YANG module. Their usage is not 1182 limited to ietf-access-control-list and can be 1183 used anywhere as applicable. 1185 Copyright (c) 2018 IETF Trust and the persons identified as 1186 the document authors. All rights reserved. 1187 Redistribution and use in source and binary forms, with or 1188 without modification, is permitted pursuant to, and subject 1189 to the license terms contained in, the Simplified BSD 1190 License set forth in Section 4.c of the IETF Trust's Legal 1191 Provisions Relating to IETF Documents 1192 (http://trustee.ietf.org/license-info). 1194 This version of this YANG module is part of RFC XXXX; see 1195 the RFC itself for full legal notices."; 1197 revision 2018-03-15 { 1198 description 1199 "Initial version."; 1200 reference 1201 "RFC XXX: Network Access Control List (ACL) YANG Data Model."; 1202 } 1204 /* 1205 * Typedefs 1206 */ 1207 typedef operator { 1208 type enumeration { 1209 enum lte { 1210 description 1211 "Less than or equal."; 1212 } 1213 enum gte { 1214 description 1215 "Greater than or equal."; 1216 } 1217 enum eq { 1218 description 1219 "Equal to."; 1220 } 1221 enum neq { 1222 description 1223 "Not equal to."; 1224 } 1225 } 1226 description 1227 "The source and destination port range definitions 1228 can be further qualified using an operator. An 1229 operator is needed only if lower-port is specified 1230 and upper-port is not specified. The operator 1231 therefore further qualifies lower-port only."; 1232 } 1234 /* 1235 * Groupings 1236 */ 1237 grouping port-range-or-operator { 1238 choice port-range-or-operator { 1239 case range { 1240 leaf lower-port { 1241 type inet:port-number; 1242 must ". <= ../upper-port" { 1243 error-message 1244 "The lower-port must be less than or equal to 1245 upper-port."; 1247 } 1248 mandatory true; 1249 description 1250 "Lower boundry for a port."; 1251 } 1252 leaf upper-port { 1253 type inet:port-number; 1254 mandatory true; 1255 description 1256 "Upper boundry for port."; 1257 } 1258 } 1259 case operator { 1260 leaf operator { 1261 type operator; 1262 default eq; 1263 description 1264 "Operator to be applied on the port below."; 1265 } 1266 leaf port { 1267 type inet:port-number; 1268 mandatory true; 1269 description 1270 "Port number along with operator on which to 1271 match."; 1272 } 1273 } 1274 description 1275 "Choice of specifying a port range or a single 1276 port along with an operator."; 1277 } 1278 description 1279 "Grouping for port definitions in the form of a 1280 choice statement."; 1281 } 1283 grouping acl-ip-header-fields { 1284 description 1285 "IP header fields common to ipv4 and ipv6"; 1286 reference 1287 "RFC 791: Internet Protocol."; 1289 leaf dscp { 1290 type inet:dscp; 1291 description 1292 "Differentiated Services Code Point."; 1293 reference 1294 "RFC 2474: Definition of Differentiated services field 1295 (DS field) in the IPv4 and IPv6 headers."; 1296 } 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: IPv6."; 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: IPv6."; 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 reference 1342 "RFC 791: Internet Protocol, 1343 RFC 8200: IPv6."; 1344 } 1345 } 1347 grouping acl-ipv4-header-fields { 1348 description 1349 "Fields in IPv4 header."; 1351 leaf ihl { 1352 type uint8 { 1353 range "5..60"; 1354 } 1355 description 1356 "An IPv4 header field, the Internet Header Length (IHL) is 1357 the length of the internet header in 32 bit words, and 1358 thus points to the beginning of the data. Note that the 1359 minimum value for a correct header is 5."; 1360 } 1362 leaf flags { 1363 type bits { 1364 bit reserved { 1365 position 0; 1366 description 1367 "Reserved. Must be zero."; 1368 } 1369 bit fragment { 1370 position 1; 1371 description 1372 "Setting value to 0 indicates may fragment, while setting 1373 the value to 1 indicates do not fragment."; 1374 } 1375 bit more { 1376 position 2; 1377 description 1378 "Setting the value to 0 indicates this is the last fragment, 1379 and setting the value to 1 indicates more fragments are 1380 coming."; 1381 } 1382 } 1383 description 1384 "Bit definitions for the flags field in IPv4 header."; 1385 } 1387 leaf offset { 1388 type uint16 { 1389 range "20..65535"; 1390 } 1391 description 1392 "The fragment offset is measured in units of 8 octets (64 bits). 1393 The first fragment has offset zero. The length is 13 bits"; 1394 } 1396 leaf identification { 1397 type uint16; 1398 description 1399 "An identifying value assigned by the sender to aid in 1400 assembling the fragments of a datagram."; 1401 } 1403 choice destination-network { 1404 case destination-ipv4-network { 1405 leaf destination-ipv4-network { 1406 type inet:ipv4-prefix; 1407 description 1408 "Destination IPv4 address prefix."; 1409 } 1410 } 1411 description 1412 "Choice of specifying a destination IPv4 address or 1413 referring to a group of IPv4 destination addresses."; 1414 } 1415 choice source-network { 1416 case source-ipv4-network { 1417 leaf source-ipv4-network { 1418 type inet:ipv4-prefix; 1419 description 1420 "Source IPv4 address prefix."; 1421 } 1422 } 1423 description 1424 "Choice of specifying a source IPv4 address or 1425 referring to a group of IPv4 source addresses."; 1426 } 1427 } 1429 grouping acl-ipv6-header-fields { 1430 description 1431 "Fields in IPv6 header"; 1433 choice destination-network { 1434 case destination-ipv6-network { 1435 leaf destination-ipv6-network { 1436 type inet:ipv6-prefix; 1437 description 1438 "Destination IPv6 address prefix."; 1440 } 1441 } 1442 description 1443 "Choice of specifying a destination IPv6 address 1444 or referring to a group of IPv6 destination 1445 addresses."; 1446 } 1448 choice source-network { 1449 case source-ipv6-network { 1450 leaf source-ipv6-network { 1451 type inet:ipv6-prefix; 1452 description 1453 "Source IPv6 address prefix."; 1454 } 1455 } 1456 description 1457 "Choice of specifying a source IPv6 address or 1458 referring to a group of IPv6 source addresses."; 1459 } 1461 leaf flow-label { 1462 type inet:ipv6-flow-label; 1463 description 1464 "IPv6 Flow label."; 1465 } 1466 reference 1467 "RFC 4291: IP Version 6 Addressing Architecture 1468 RFC 4007: IPv6 Scoped Address Architecture 1469 RFC 5952: A Recommendation for IPv6 Address Text 1470 Representation"; 1471 } 1473 grouping acl-eth-header-fields { 1474 description 1475 "Fields in Ethernet header."; 1477 leaf destination-mac-address { 1478 type yang:mac-address; 1479 description 1480 "Destination IEEE 802 MAC address."; 1481 } 1482 leaf destination-mac-address-mask { 1483 type yang:mac-address; 1484 description 1485 "Destination IEEE 802 MAC address mask."; 1486 } 1487 leaf source-mac-address { 1488 type yang:mac-address; 1489 description 1490 "Source IEEE 802 MAC address."; 1491 } 1492 leaf source-mac-address-mask { 1493 type yang:mac-address; 1494 description 1495 "Source IEEE 802 MAC address mask."; 1496 } 1497 leaf ethertype { 1498 type eth:ethertype; 1499 description 1500 "The Ethernet Type (or Length) value represented 1501 in the canonical order defined by IEEE 802. 1502 The canonical representation uses lowercase 1503 characters."; 1504 reference 1505 "IEEE 802-2014 Clause 9.2"; 1506 } 1507 reference 1508 "IEEE 802: IEEE Standard for Local and Metropolitan 1509 Area Networks: Overview and Architecture."; 1510 } 1512 grouping acl-tcp-header-fields { 1513 description 1514 "Collection of TCP header fields that can be used to 1515 setup a match filter."; 1517 leaf sequence-number { 1518 type uint32; 1519 description 1520 "Sequence number that appears in the packet."; 1521 } 1523 leaf acknowledgement-number { 1524 type uint32; 1525 description 1526 "The acknowledgement number that appears in the 1527 packet."; 1528 } 1530 leaf data-offset { 1531 type uint8 { 1532 range "5..15"; 1533 } 1534 description 1535 "Specifies the size of the TCP header in 32-bit 1536 words. The minimum size header is 5 words and 1537 the maximum is 15 words thus giving the minimum 1538 size of 20 bytes and maximum of 60 bytes, 1539 allowing for up to 40 bytes of options in the 1540 header."; 1541 } 1543 leaf reserved { 1544 type uint8; 1545 description 1546 "Reserved for future use."; 1547 } 1549 leaf flags { 1550 type bits { 1551 bit cwr { 1552 position 1; 1553 description 1554 "Congestion Window Reduced (CWR) flag is set by 1555 the sending host to indicate that it received 1556 a TCP segment with the ECE flag set and had 1557 responded in congestion control mechanism."; 1558 reference 1559 "RFC 3168: Explicit Congestion Notification."; 1560 } 1561 bit ece { 1562 position 2; 1563 description 1564 "ECN-Echo has a dual role, depending on the value 1565 of the SYN flag. It indicates: 1566 If the SYN flag is set (1), that the TCP peer is ECN 1567 capable. If the SYN flag is clear (0), that a packet 1568 with Congestion Experienced flag set (ECN=11) in IP 1569 header was received during normal transmission 1570 (added to header by RFC 3168). This serves as an 1571 indication of network congestion (or impending 1572 congestion) to the TCP sender."; 1573 reference 1574 "RFC 3168: Explicit Congestion Notification."; 1575 } 1576 bit urg { 1577 position 3; 1578 description 1579 "Indicates that the Urgent pointer field is significant."; 1580 } 1581 bit ack { 1582 position 4; 1583 description 1584 "Indicates that the Acknowledgment field is significant. 1585 All packets after the initial SYN packet sent by the 1586 client should have this flag set."; 1587 } 1588 bit psh { 1589 position 5; 1590 description 1591 "Push function. Asks to push the buffered data to the 1592 receiving application."; 1593 } 1594 bit rst { 1595 position 6; 1596 description 1597 "Reset the connection."; 1598 } 1599 bit syn { 1600 position 7; 1601 description 1602 "Synchronize sequence numbers. Only the first packet 1603 sent from each end should have this flag set. Some 1604 other flags and fields change meaning based on this 1605 flag, and some are only valid for when it is set, 1606 and others when it is clear."; 1607 } 1608 bit fin { 1609 position 8; 1610 description 1611 "Last package from sender."; 1612 } 1613 } 1614 description 1615 "Also known as Control Bits. Contains 9 1-bit flags."; 1616 reference 1617 "RFC 793: TCP."; 1618 } 1620 leaf window-size { 1621 type uint16; 1622 units "bytes"; 1623 description 1624 "The size of the receive window, which specifies 1625 the number of window size units beyond the segment 1626 identified by the sequence number in the acknowledgment 1627 field that the sender of this segment is currently 1628 willing to receive."; 1629 } 1631 leaf urgent-pointer { 1632 type uint16; 1633 description 1634 "This field is an offset from the sequence number 1635 indicating the last urgent data byte."; 1636 } 1638 leaf options { 1639 type uint32; 1640 description 1641 "The length of this field is determined by the 1642 data offset field. Options have up to three 1643 fields: Option-Kind (1 byte), Option-Length 1644 (1 byte), Option-Data (variable). The Option-Kind 1645 field indicates the type of option, and is the 1646 only field that is not optional. Depending on 1647 what kind of option we are dealing with, 1648 the next two fields may be set: the Option-Length 1649 field indicates the total length of the option, 1650 and the Option-Data field contains the value of 1651 the option, if applicable."; 1652 } 1653 } 1655 grouping acl-udp-header-fields { 1656 description 1657 "Collection of UDP header fields that can be used 1658 to setup a match filter."; 1660 leaf length { 1661 type uint16; 1662 description 1663 "A field that specifies the length in bytes of 1664 the UDP header and UDP data. The minimum 1665 length is 8 bytes because that is the length of 1666 the header. The field size sets a theoretical 1667 limit of 65,535 bytes (8 byte header + 65,527 1668 bytes of data) for a UDP datagram. However the 1669 actual limit for the data length, which is 1670 imposed by the underlying IPv4 protocol, is 1671 65,507 bytes (65,535 minus 8 byte UDP header 1672 minus 20 byte IP header). 1674 In IPv6 jumbograms it is possible to have 1675 UDP packets of size greater than 65,535 bytes. 1676 RFC 2675 specifies that the length field is set 1677 to zero if the length of the UDP header plus 1678 UDP data is greater than 65,535."; 1679 } 1681 } 1683 grouping acl-icmp-header-fields { 1684 description 1685 "Collection of ICMP header fields that can be 1686 used to setup a match filter."; 1688 leaf type { 1689 type uint8; 1690 description 1691 "Also known as Control messages."; 1692 reference 1693 "RFC 792: ICMP."; 1694 } 1696 leaf code { 1697 type uint8; 1698 description 1699 "ICMP subtype. Also known as Control messages."; 1700 } 1702 leaf rest-of-header { 1703 type uint32; 1704 description 1705 "Four-bytes field, contents vary based on the 1706 ICMP type and code."; 1707 } 1708 } 1709 } 1711 1713 4.3. An ACL Example 1715 Requirement: Deny tcp traffic from 192.0.2.0/24, destined to 1716 198.51.100.0/24. 1718 Here is the acl configuration xml for this Access Control List: 1720 [note: '\' line wrapping for formatting only] 1722 1723 1724 1726 1727 sample-ipv4-acl 1728 ipv4-acl-type 1729 1730 1731 rule1 1732 1733 1734 6 1735 198.51.100.0/24 1737 192.0.2.0/24 1739 1740 1741 1742 drop 1743 1744 1745 1746 1747 1748 1750 The acl and aces can be described in CLI as the following: 1752 acl ipv4 sample-ipv4-acl 1753 deny tcp 192.0.2.0/24 198.51.100.0/24 1755 4.4. Port Range Usage and Other Examples 1757 When a lower-port and an upper-port are both present, it represents a 1758 range between lower-port and upper-port with both the lower-port and 1759 upper-port included. When only a port is present, it represents a 1760 port, with the operator specifying the range. 1762 The following XML example represents a configuration where traffic to 1763 source ports 16384, 16385, 16386, and 16387 is dropped. 1765 [note: '\' line wrapping for formatting only] 1767 1768 1769 1771 1772 sample-port-acl 1773 ipv4-acl-type 1774 1775 1776 rule1 1777 1778 1779 1780 16384 1781 16387 1782 1783 1784 1785 1786 drop 1787 1788 1789 1790 1791 1792 1794 The following XML example represents a configuration where all ping 1795 echo requests are dropped. 1797 [note: '\' line wrapping for formatting only] 1799 1800 1801 1803 1804 sample-icmp-acl 1805 1806 1807 rule1 1808 1809 1810 8 1811 0 1812 1813 1814 1815 drop 1816 1817 1818 1819 1820 1821 1823 The following XML example represents a configuration of a single 1824 port, port 21 that accepts traffic. 1826 [note: '\' line wrapping for formatting only] 1828 1829 1830 1832 1833 sample-ipv4-acl 1834 ipv4-acl-type 1835 1836 1837 rule1 1838 1839 1840 1841 eq 1842 21 1843 1844 1845 1846 1847 accept 1848 1849 1850 1851 1852 1853 1855 The following XML example represents a configuration specifying all 1856 ports that are not equal to 21, that will drop packets destined for 1857 those ports. 1859 [note: '\' line wrapping for formatting only] 1861 1862 1863 1865 1866 sample-ipv4-acl 1867 ipv4-acl-type 1868 1869 1870 rule1 1871 1872 1873 1874 neq 1875 21 1876 1877 1878 1879 1880 drop 1881 1882 1883 1884 1885 1886 1888 5. Security Considerations 1890 The YANG module specified in this document defines a schema for data 1891 that is designed to be accessed via network management protocol such 1892 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1893 is the secure transport layer and the mandatory-to-implement secure 1894 transport is SSH [RFC6242]. The lowest RESTCONF layer is HTTPS, and 1895 the mandatory-to-implement secure transport is TLS [RFC5246]. 1897 The NETCONF Access Control Model (NACM [RFC6536]) provides the means 1898 to restrict access for particular NETCONF users to a pre-configured 1899 subset of all available NETCONF protocol operations and content. 1901 There are a number of data nodes defined in the YANG module which are 1902 writable/creatable/deletable (i.e., config true, which is the 1903 default). These data nodes may be considered sensitive or vulnerable 1904 in some network environments. Write operations (e.g., ) 1905 to these data nodes without proper protection can have a negative 1906 effect on network operations. 1908 These are the subtrees and data nodes and their sensitivity/ 1909 vulnerability: 1911 /acls/acl/aces: This list specifies all the configured access 1912 control entries on the device. Unauthorized write access to this 1913 list can allow intruders to access and control the system. 1914 Unauthorized read access to this list can allow intruders to spoof 1915 packets with authorized addresses thereby compromising the system. 1917 6. IANA Considerations 1919 This document registers three URIs and three YANG modules. 1921 6.1. URI Registration 1923 This document registers three URIs in the IETF XML registry 1924 [RFC3688]. Following the format in RFC 3688, the following 1925 registration is requested to be made: 1927 URI: urn:ietf:params:xml:ns:yang:ietf-access-control-list 1928 URI: urn:ietf:params:xml:ns:yang:ietf-packet-fields 1929 URI: urn:ietf:params:xml:ns:yang:ietf-ethertypes 1931 Registrant Contact: The IESG. 1933 XML: N/A, the requested URI is an XML namespace. 1935 6.2. YANG Module Name Registration 1937 This document registers three YANG module in the YANG Module Names 1938 registry YANG [RFC6020]. 1940 name: ietf-access-control-list 1941 namespace: urn:ietf:params:xml:ns:yang:ietf-access-control-list 1942 prefix: acl 1943 reference: RFC XXXX 1945 name: ietf-packet-fields 1946 namespace: urn:ietf:params:xml:ns:yang:ietf-packet-fields 1947 prefix: packet-fields 1948 reference: RFC XXXX 1950 name: ietf-ethertypes 1951 namespace: urn:ietf:params:xml:ns:yang:ietf-ethertypes 1952 prefix: ethertypes 1953 reference: RFC XXXX 1955 7. Acknowledgements 1957 Alex Clemm, Andy Bierman and Lisa Huang started it by sketching out 1958 an initial IETF draft in several past IETF meetings. That draft 1959 included an ACL YANG model structure and a rich set of match filters, 1960 and acknowledged contributions by Louis Fourie, Dana Blair, Tula 1961 Kraiser, Patrick Gili, George Serpa, Martin Bjorklund, Kent Watsen, 1962 and Phil Shafer. Many people have reviewed the various earlier 1963 drafts that made the draft went into IETF charter. 1965 Dean Bogdanovic, Kiran Agrahara Sreenivasa, Lisa Huang, and Dana 1966 Blair each evaluated the YANG model in previous drafts separately, 1967 and then worked together to created a ACL draft that was supported by 1968 different vendors. That draft removed vendor specific features, and 1969 gave examples to allow vendors to extend in their own proprietary 1970 ACL. The earlier draft was superseded with this updated draft and 1971 received more participation from many vendors. 1973 Authors would like to thank Jason Sterne, Lada Lhotka, Juergen 1974 Schoenwalder, David Bannister, Jeff Haas, Kristian Larsson and Einar 1975 Nilsen-Nygaard for their review of and suggestions to the draft. 1977 8. References 1979 8.1. Normative References 1981 [I-D.ietf-netmod-rfc7223bis] 1982 Bjorklund, M., "A YANG Data Model for Interface 1983 Management", draft-ietf-netmod-rfc7223bis-03 (work in 1984 progress), January 2018. 1986 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1987 DOI 10.17487/RFC0791, September 1981, 1988 . 1990 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1991 RFC 792, DOI 10.17487/RFC0792, September 1981, 1992 . 1994 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1995 Requirement Levels", BCP 14, RFC 2119, 1996 DOI 10.17487/RFC2119, March 1997, 1997 . 1999 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2000 "Definition of the Differentiated Services Field (DS 2001 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2002 DOI 10.17487/RFC2474, December 1998, 2003 . 2005 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2006 of Explicit Congestion Notification (ECN) to IP", 2007 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2008 . 2010 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2011 DOI 10.17487/RFC3688, January 2004, 2012 . 2014 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 2015 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 2016 DOI 10.17487/RFC4007, March 2005, 2017 . 2019 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2020 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2021 2006, . 2023 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2024 (TLS) Protocol Version 1.2", RFC 5246, 2025 DOI 10.17487/RFC5246, August 2008, 2026 . 2028 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2029 Address Text Representation", RFC 5952, 2030 DOI 10.17487/RFC5952, August 2010, 2031 . 2033 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2034 the Network Configuration Protocol (NETCONF)", RFC 6020, 2035 DOI 10.17487/RFC6020, October 2010, 2036 . 2038 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2039 and A. Bierman, Ed., "Network Configuration Protocol 2040 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2041 . 2043 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2044 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2045 . 2047 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2048 Protocol (NETCONF) Access Control Model", RFC 6536, 2049 DOI 10.17487/RFC6536, March 2012, 2050 . 2052 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2053 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2054 . 2056 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2057 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2058 . 2060 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2061 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2062 . 2064 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2065 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2066 May 2017, . 2068 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2069 (IPv6) Specification", STD 86, RFC 8200, 2070 DOI 10.17487/RFC8200, July 2017, 2071 . 2073 8.2. Informative References 2075 [I-D.ietf-netmod-yang-tree-diagrams] 2076 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 2077 ietf-netmod-yang-tree-diagrams-06 (work in progress), 2078 February 2018. 2080 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2081 "Specification of the IP Flow Information Export (IPFIX) 2082 Protocol for the Exchange of Flow Information", STD 77, 2083 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2084 . 2086 Appendix A. Extending ACL model examples 2088 A.1. A company proprietary module example 2090 Module "example-newco-acl" is an example of company proprietary model 2091 that augments "ietf-acl" module. It shows how to use 'augment' with 2092 an XPath expression to add additional match criteria, action 2093 criteria, and default actions when no ACE matches are found. All 2094 these are company proprietary extensions or system feature 2095 extensions. "example-newco-acl" is just an example and it is 2096 expected that vendors will create their own proprietary models. 2098 [note: '\' line wrapping for formatting only] 2100 module example-newco-acl { 2102 yang-version 1.1; 2104 namespace "http://example.com/ns/example-newco-acl"; 2106 prefix example-newco-acl; 2108 import ietf-access-control-list { 2109 prefix "acl"; 2110 } 2112 organization 2113 "Newco model group."; 2115 contact 2116 "abc@newco.com"; 2117 description 2118 "This YANG module augments IETF ACL Yang."; 2120 revision 2018-03-15 { 2121 description 2122 "Creating NewCo proprietary extensions to ietf-acl model"; 2124 reference 2125 "RFC XXXX: Network Access Control List (ACL) 2126 YANG Data Model"; 2127 } 2128 augment "/acl:acls/acl:acl/" + 2129 "acl:aces/acl:ace/" + 2130 "acl:matches" { 2131 description "Newco proprietary simple filter matches"; 2132 choice protocol-payload-choice { 2133 description "Newco proprietary payload match condition"; 2134 list protocol-payload { 2135 key value-keyword; 2136 ordered-by user; 2137 description "Match protocol payload"; 2138 uses match-simple-payload-protocol-value; 2139 } 2140 } 2142 choice metadata { 2143 description "Newco proprietary interface match condition"; 2144 leaf packet-length { 2145 type uint16; 2146 description "Match on packet length"; 2147 } 2148 } 2149 } 2151 augment "/acl:acls/acl:acl/" + 2152 "acl:aces/acl:ace/" + 2153 "acl:actions" { 2154 description "Newco proprietary simple filter actions"; 2155 choice action { 2156 description ""; 2157 case count { 2158 description "Count the packet in the named counter"; 2159 leaf count { 2160 type uint32; 2161 description "Count"; 2162 } 2163 } 2164 case policer { 2165 description "Name of policer to use to rate-limit traffic"; 2166 leaf policer { 2167 type string; 2168 description "Name of the policer"; 2169 } 2170 } 2171 case hiearchical-policer { 2172 leaf hierarchitacl-policer { 2173 type string; 2174 description 2175 "Name of the hierarchical policer."; 2177 } 2178 description 2179 "Name of hierarchical policer to use to 2180 rate-limit traffic"; 2181 } 2182 } 2183 } 2185 augment "/acl:acls/acl:acl" + 2186 "/acl:aces/acl:ace/" + 2187 "acl:actions" { 2188 leaf default-action { 2189 type identityref { 2190 base acl:forwarding-action; 2191 } 2192 default acl:drop; 2193 description 2194 "Actions that occur if no ace is matched."; 2195 } 2196 description 2197 "Newco proprietary default action"; 2198 } 2200 grouping match-simple-payload-protocol-value { 2201 description "Newco proprietary payload"; 2202 leaf value-keyword { 2203 type enumeration { 2204 enum icmp { 2205 description "Internet Control Message Protocol"; 2206 } 2207 enum icmp6 { 2208 description 2209 "Internet Control Message Protocol 2210 Version 6"; 2211 } 2212 enum range { 2213 description "Range of values"; 2214 } 2215 } 2216 description "(null)"; 2217 } 2218 } 2219 } 2221 The following figure is the tree diagram of example-newco-acl. In 2222 this example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ 2223 ietf-acl:matches are augmented with two new choices, protocol- 2224 payload-choice and metadata. The protocol-payload-choice uses a 2225 grouping with an enumeration of all supported protocol values. 2226 Metadata matches apply to fields associated with the packet but not 2227 in the packet header such as overall packet length. In another 2228 example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf- 2229 acl:actions are augmented with a new choice of actions. 2231 [note: '\' line wrapping for formatting only] 2233 module: example-newco-acl 2234 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: 2235 +--rw (protocol-payload-choice)? 2236 | +--:(protocol-payload) 2237 | +--rw protocol-payload* [value-keyword] 2238 | +--rw value-keyword enumeration 2239 +--rw (metadata)? 2240 +--:(packet-length) 2241 +--rw packet-length? uint16 2242 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions: 2243 +--rw (action)? 2244 +--:(count) 2245 | +--rw count? uint32 2246 +--:(policer) 2247 | +--rw policer? string 2248 +--:(hiearchical-policer) 2249 +--rw hierarchitacl-policer? string 2250 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions: 2251 +--rw default-action? identityref 2253 A.2. Linux nftables 2255 As Linux platform is becoming more popular as networking platform, 2256 the Linux data model is changing. Previously ACLs in Linux were 2257 highly protocol specific and different utilities were used (iptables, 2258 ip6tables, arptables, ebtables), so each one had separate data model. 2259 Recently, this has changed and a single utility, nftables, has been 2260 developed. With a single application, it has a single data model for 2261 filewall filters and it follows very similarly to the ietf-access- 2262 control list module proposed in this draft. The nftables support 2263 input and output ACEs and each ACE can be defined with match and 2264 action. 2266 The example in Section 4.3 can be configured using nftable tool as 2267 below. 2269 nft add table ip filter 2270 nft add chain filter input 2271 nft add rule ip filter input ip protocol tcp ip saddr \ 2272 192.0.2.1/24 drop 2274 The configuration entries added in nftable would be. 2276 table ip filter { 2277 chain input { 2278 ip protocol tcp ip saddr 192.0.2.1/24 drop 2279 } 2280 } 2282 We can see that there are many similarities between Linux nftables 2283 and IETF ACL YANG data models and its extension models. It should be 2284 fairly easy to do translation between ACL YANG model described in 2285 this draft and Linux nftables. 2287 A.3. Ethertypes 2289 The ACL module is dependent on the definition of ethertypes. IEEE 2290 owns the allocation of those ethertypes. This model is being 2291 included here to enable definition of those types till such time that 2292 IEEE takes up the task of publication of the model that defines those 2293 ethertypes. At that time, this model can be deprecated. 2295 file "ietf-ethertypes@2018-03-15.yang" 2297 module ietf-ethertypes { 2298 namespace "urn:ietf:params:xml:ns:yang:ietf-ethertypes"; 2299 prefix ethertypes; 2301 organization 2302 "IETF NETMOD (NETCONF Data Modeling Language)"; 2304 contact 2305 "WG Web: 2306 WG List: 2308 Editor: Mahesh Jethanandani 2309 "; 2311 description 2312 "This module contains the common definitions for the 2313 Ethertype used by different modules. It is a 2314 placeholder module, till such time that IEEE 2315 starts a project to define these Ethertypes 2316 and publishes a standard. 2318 At that time this module can be deprecated."; 2320 revision 2018-03-15 { 2321 description 2322 "Initial revision."; 2323 reference 2324 "RFC XXXX: IETF Ethertype YANG Data Module."; 2325 } 2327 typedef ethertype { 2328 type union { 2329 type uint16; 2330 type enumeration { 2331 enum ipv4 { 2332 value 2048; 2333 description 2334 "Internet Protocol version 4 (IPv4) with a 2335 hex value of 0x0800."; 2336 reference 2337 "RFC 791: Internet Protocol."; 2338 } 2339 enum arp { 2340 value 2054; 2341 description 2342 "Address Resolution Protocol (ARP) with a 2343 hex value of 0x0806."; 2344 reference 2345 "RFC 826: An Ethernet Address Resolution Protocol."; 2346 } 2347 enum wlan { 2348 value 2114; 2349 description 2350 "Wake-on-LAN. Hex value of 0x0842."; 2351 } 2352 enum trill { 2353 value 8947; 2354 description 2355 "Transparent Interconnection of Lots of Links. 2356 Hex value of 0x22F3."; 2357 reference 2358 "RFC 6325 Routing Bridges (RBridges): Base Protocol 2359 Specification."; 2360 } 2361 enum srp { 2362 value 8938; 2363 description 2364 "Stream Reservation Protocol. Hex value of 2365 0x22EA."; 2366 reference 2367 "IEEE 801.1Q-2011."; 2368 } 2369 enum decnet { 2370 value 24579; 2371 description 2372 "DECnet Phase IV. Hex value of 0x6003."; 2373 } 2374 enum rarp { 2375 value 32821; 2376 description 2377 "Reverse Address Resolution Protocol. 2378 Hex value 0x8035."; 2379 reference 2380 "RFC 903. A Reverse Address Resolution Protocol."; 2381 } 2382 enum appletalk { 2383 value 32923; 2384 description 2385 "Appletalk (Ethertalk). Hex value 0x809B."; 2386 } 2387 enum aarp { 2388 value 33011; 2389 description 2390 "Appletalk Address Resolution Protocol. Hex value 2391 of 0x80F3."; 2392 } 2393 enum vlan { 2394 value 33024; 2395 description 2396 "VLAN-tagged frame (802.1Q) and Shortest Path 2397 Bridging IEEE 802.1aq with NNI compatibility. 2398 Hex value 0x8100."; 2399 reference 2400 "802.1Q."; 2401 } 2402 enum ipx { 2403 value 33079; 2404 description 2405 "Internetwork Packet Exchange (IPX). Hex value 2406 of 0x8137."; 2407 } 2408 enum qnx { 2409 value 33284; 2410 description 2411 "QNX Qnet. Hex value of 0x8204."; 2413 } 2414 enum ipv6 { 2415 value 34525; 2416 description 2417 "Internet Protocol Version 6 (IPv6). Hex value 2418 of 0x86DD."; 2419 reference 2420 "RFC 8200: IPv6 2421 RFC 8201: Path MTU Discovery for IPv6."; 2422 } 2423 enum efc { 2424 value 34824; 2425 description 2426 "Ethernet flow control using pause frames. 2427 Hex value of 0x8808"; 2428 reference 2429 "IEEE Std. 802.1Qbb."; 2430 } 2431 enum esp { 2432 value 34825; 2433 description 2434 "Ethernet Slow Protocol. Hex value of 0x8809."; 2435 reference 2436 "IEEE Std. 802.3-2015"; 2437 } 2438 enum cobranet { 2439 value 34841; 2440 description 2441 "CobraNet. Hex value of 0x"; 2442 } 2443 enum mpls-unicast { 2444 value 34887; 2445 description 2446 "MultiProtocol Label Switch (MPLS) unicast traffic. 2447 Hex value of 0x8847."; 2448 reference 2449 "RFC 3031: MPLS Architecture."; 2450 } 2451 enum mpls-multicast { 2452 value 34888; 2453 description 2454 "MultiProtocol Label Switch (MPLS) multicast traffic. 2455 Hex value of 0x8848."; 2456 reference 2457 "RFC 3031: MPLS Architecture."; 2458 } 2459 enum pppoe-discovery { 2460 value 34915; 2461 description 2462 "Point-to-Point Protocol over Ethernet. Used during 2463 the discovery process. Hex value of 0x8863."; 2464 reference 2465 "RFC 2516: A method for Transmitting PPPoE."; 2466 } 2467 enum pppoe-session { 2468 value 34916; 2469 description 2470 "Point-to-Point Protocol over Ethernet. Used during 2471 session stage. Hex value of 0x8864."; 2472 reference 2473 "RFC 2516: A method for Transmitting PPPoE."; 2474 } 2475 enum intel-ans { 2476 value 34925; 2477 description 2478 "Intel Advanced Networking Services. Hex value of 2479 0x886D."; 2480 } 2481 enum jumbo-frames { 2482 value 34928; 2483 description 2484 "Jumbo frames or Ethernet frames with more than 2485 1500 bytes of payload, upto 9000 bytes."; 2486 } 2487 enum homeplug { 2488 value 34939; 2489 description 2490 "Family name for the various power line 2491 communications. Hex value of 0x887B."; 2492 } 2493 enum eap { 2494 value 34958; 2495 description 2496 "Ethernet Access Protocol (EAP) over LAN. Hex value 2497 of 0x888E."; 2498 reference 2499 "IEEE 802.1X"; 2500 } 2501 enum profinet { 2502 value 34962; 2503 description 2504 "PROcess FIeld Net (PROFINET). Hex value of 0x8892."; 2505 } 2506 enum hyperscsi { 2507 value 34970; 2508 description 2509 "SCSI over Ethernet. Hex value of 0x889A"; 2510 } 2511 enum aoe { 2512 value 34978; 2513 description 2514 "Advanced Technology Advancement (ATA) over Ethernet. 2515 Hex value of 0x88A2."; 2516 } 2517 enum ethercat { 2518 value 34980; 2519 description 2520 "Ethernet for Control Automation Technology (EtherCAT). 2521 Hex value of 0x88A4."; 2522 } 2523 enum provider-bridging { 2524 value 34984; 2525 description 2526 "Provider Bridging (802.1ad) and Shortest Path Bridging 2527 (801.1aq). Hex value of 0x88A8."; 2528 reference 2529 "IEEE 802.1ad, IEEE 802.1aq)."; 2530 } 2531 enum ethernet-powerlink { 2532 value 34987; 2533 description 2534 "Ethernet Powerlink. Hex value of 0x88AB."; 2535 } 2536 enum goose { 2537 value 35000; 2538 description 2539 "Generic Object Oriented Substation Event (GOOSE). 2540 Hex value of 0x88B8."; 2541 reference 2542 "IEC/ISO 8802-2 and 8802-3."; 2543 } 2544 enum gse { 2545 value 35001; 2546 description 2547 "Generic Substation Events. Hex value of 88B9."; 2548 reference 2549 "IEC 61850."; 2550 } 2551 enum sv { 2552 value 35002; 2553 description 2554 "Sampled Value Transmission. Hex value of 0x88BA."; 2555 reference 2556 "IEC 61850."; 2558 } 2559 enum lldp { 2560 value 35020; 2561 description 2562 "Link Layer Discovery Protocol (LLDP). Hex value of 2563 0x88CC."; 2564 reference 2565 "IEEE 802.1AB."; 2566 } 2567 enum sercos { 2568 value 35021; 2569 description 2570 "Sercos Interface. Hex value of 0x88CD."; 2571 } 2572 enum wsmp { 2573 value 35036; 2574 description 2575 "WAVE Short Message Protocl (WSMP). Hex value of 2576 0x88DC."; 2577 } 2578 enum homeplug-av-mme { 2579 value 35041; 2580 description 2581 "HomePlug AV MME. Hex value of 88E1."; 2582 } 2583 enum mrp { 2584 value 35043; 2585 description 2586 "Media Redundancy Protocol (MRP). Hex value of 2587 0x88E3."; 2588 reference 2589 "IEC62439-2."; 2590 } 2591 enum macsec { 2592 value 35045; 2593 description 2594 "MAC Security. Hex value of 0x88E5."; 2595 reference 2596 "IEEE 802.1AE."; 2597 } 2598 enum pbb { 2599 value 35047; 2600 description 2601 "Provider Backbone Bridges (PBB). Hex value of 2602 0x88E7."; 2603 reference 2604 "IEEE 802.1ah."; 2605 } 2606 enum cfm { 2607 value 35074; 2608 description 2609 "Connectivity Fault Management (CFM). Hex value of 2610 0x8902."; 2611 reference 2612 "IEEE 802.1ag."; 2613 } 2614 enum fcoe { 2615 value 35078; 2616 description 2617 "Fiber Channel over Ethernet (FCoE). Hex value of 2618 0x8906."; 2619 reference 2620 "T11 FC-BB-5."; 2621 } 2622 enum fcoe-ip { 2623 value 35092; 2624 description 2625 "FCoE Initialization Protocol. Hex value of 0x8914."; 2626 } 2627 enum roce { 2628 value 35093; 2629 description 2630 "RDMA over Converged Ethernet (RoCE). Hex value of 2631 0x8915."; 2632 } 2633 enum tte { 2634 value 35101; 2635 description 2636 "TTEthernet Protocol Control Frame (TTE). Hex value 2637 of 0x891D."; 2638 reference 2639 "SAE AS6802."; 2640 } 2641 enum hsr { 2642 value 35119; 2643 description 2644 "High-availability Seamless Redundancy (HSR). Hex 2645 value of 0x892F."; 2646 reference 2647 "IEC 62439-3:2016."; 2648 } 2649 } 2650 } 2651 description 2652 "The uint16 type placeholder is defined to enable 2653 users to manage their own ethertypes not 2654 covered by the module. Otherwise the module contains 2655 enum definitions for the more commonly used ethertypes."; 2656 } 2657 } 2659 2661 Authors' Addresses 2663 Mahesh Jethanandani 2665 Email: mjethanandani@gmail.com 2667 Lisa Huang 2668 General Electric 2670 Email: lyihuang16@gmail.com 2672 Sonal Agarwal 2673 Cisco Systems, Inc. 2675 Email: sagarwal12@gmail.com 2677 Dana Blair 2678 Cisco Systems, Inc. 2680 Email: dblair@cisco.com