--- 1/draft-ietf-netmod-acl-model-18.txt 2018-04-27 13:14:08.739788600 -0700 +++ 2/draft-ietf-netmod-acl-model-19.txt 2018-04-27 13:14:08.839790998 -0700 @@ -1,22 +1,22 @@ NETMOD WG M. Jethanandani Internet-Draft Intended status: Standards Track L. Huang -Expires: September 16, 2018 General Electric +Expires: October 29, 2018 General Electric S. Agarwal D. Blair Cisco Systems, Inc. - March 15, 2018 + April 27, 2018 Network Access Control List (ACL) YANG Data Model - draft-ietf-netmod-acl-model-18 + draft-ietf-netmod-acl-model-19 Abstract This document defines a data model for Access Control List (ACL). An ACL is a user-ordered set of rules, used to configure the forwarding behavior in device. Each rule is used to find a match on a packet, and define actions that will be performed on the packet. Status of This Memo @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 16, 2018. + This Internet-Draft will expire on October 29, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -56,34 +56,34 @@ 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Understanding ACL's Filters and Actions . . . . . . . . . . . 5 3.1. ACL Modules . . . . . . . . . . . . . . . . . . . . . . . 5 4. ACL YANG Models . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. IETF Access Control List module . . . . . . . . . . . . . 9 4.2. IETF Packet Fields module . . . . . . . . . . . . . . . . 24 4.3. An ACL Example . . . . . . . . . . . . . . . . . . . . . 36 - 4.4. Port Range Usage and Other Examples . . . . . . . . . . . 37 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 41 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 - 6.1. URI Registration . . . . . . . . . . . . . . . . . . . . 42 - 6.2. YANG Module Name Registration . . . . . . . . . . . . . . 42 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 43 + 4.4. Port Range Usage and Other Examples . . . . . . . . . . . 38 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 42 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 + 6.1. URI Registration . . . . . . . . . . . . . . . . . . . . 43 + 6.2. YANG Module Name Registration . . . . . . . . . . . . . . 43 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 44 8.2. Informative References . . . . . . . . . . . . . . . . . 45 Appendix A. Extending ACL model examples . . . . . . . . . . . . 46 A.1. A company proprietary module example . . . . . . . . . . 46 - A.2. Linux nftables . . . . . . . . . . . . . . . . . . . . . 49 - A.3. Ethertypes . . . . . . . . . . . . . . . . . . . . . . . 50 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 + A.2. Linux nftables . . . . . . . . . . . . . . . . . . . . . 50 + A.3. Ethertypes . . . . . . . . . . . . . . . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 1. Introduction Access Control List (ACL) is one of the basic elements used to configure device forwarding behavior. It is used in many networking technologies such as Policy Based Routing, Firewalls etc. An ACL is an user-ordered set of rules, that is used to filter traffic on a networking device. Each rule is represented by an Access Control Entry (ACE). @@ -127,21 +127,21 @@ summarizes all of the substitutions that are needed. Please note that no other RFC Editor instructions are specified anywhere else in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements o "XXXX" --> the assigned RFC value for this draft both in this draft and in the YANG models under the revision statement. - o Revision date in model, in the format 2018-03-15 needs to get + o Revision date in model, in the format 2018-04-27 needs to get updated with the date the draft gets approved. The date also needs to get reflected on the line with . o Replace "I-D.ietf-netmod-yang-tree-diagrams" with the assigned RFC number. 1.1. Definitions and Acronyms ACE: Access Control Entry @@ -169,26 +169,25 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. Tree Diagram For a reference to the annotations used in tree diagrams included in - this draft, please see YANG Tree Diagrams - [I-D.ietf-netmod-yang-tree-diagrams]. + this draft, please see YANG Tree Diagrams [RFC8340]. 2. Problem Statement - This document defines a YANG [RFC7950] data model for the + This document defines a YANG 1.1 [RFC7950] data model for the configuration of ACLs. It is very important that model can be used easily by applications/attachments. ACL implementations in every device may vary greatly in terms of the filter constructs and actions that they support. Therefore this draft proposes a model that can be augmented by standard extensions and vendor proprietary models. 3. Understanding ACL's Filters and Actions @@ -431,24 +430,23 @@ logging option allows for a match to be logged that can later be used to determine which rule was matched upon. The model also defines the ability for ACLs to be attached to a particular interface. Statistics in the ACL can be collected for an "ace" or for an "interface". The feature statements defined for statistics can be used to determine whether statistics are being collected per "ace", or per "interface". This module imports definitions from Common YANG Data Types - [RFC6991], and A YANG Data Model for Interface Management - [I-D.ietf-netmod-rfc7223bis]. + [RFC6991], and A YANG Data Model for Interface Management [RFC8343]. - file "ietf-access-control-list@2018-03-15.yang" + file "ietf-access-control-list@2018-04-27.yang" module ietf-access-control-list { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list"; prefix acl; import ietf-yang-types { prefix yang; reference "RFC 6991 - Common YANG Data Types."; @@ -456,22 +454,21 @@ import ietf-packet-fields { prefix pf; reference "RFC XXXX - Network ACL YANG Model."; } import ietf-interfaces { prefix if; reference - "I-D.draft-ietf-netmod-rfc7223bis - A YANG Data Model for - Interface Management."; + "RFC 8343 - A YANG Data Model for Interface Management."; } organization "IETF NETMOD (Network Modeling Language) Working Group"; contact "WG Web: http://tools.ietf.org/wg/netmod/ WG List: netmod@ietf.org @@ -494,21 +491,21 @@ Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2018-03-15 { + revision 2018-04-27 { description "Initial version."; reference "RFC XXX: Network Access Control List (ACL) YANG Data Model."; } /* * Identities */ @@ -1128,21 +1128,21 @@ "matches" in ietf-access-control-list.yang model. This module imports definitions from Common YANG Data Types [RFC6991] and references IP [RFC0791], ICMP [RFC0792], Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers [RFC2474], The Addition of Explicit Congestion Notification (ECN) to IP [RFC3168], , IPv6 Scoped Address Architecture [RFC4007], IPv6 Addressing Architecture [RFC4291], A Recommendation for IPv6 Address Text Representation [RFC5952], IPv6 [RFC8200]. - file "ietf-packet-fields@2018-03-15.yang" + file "ietf-packet-fields@2018-04-27.yang" module ietf-packet-fields { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-packet-fields"; prefix packet-fields; import ietf-inet-types { prefix inet; reference "RFC 6991 - Common YANG Data Types."; @@ -1187,23 +1188,24 @@ Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2018-03-15 { + revision 2018-04-27 { description "Initial version."; + reference "RFC XXX: Network Access Control List (ACL) YANG Data Model."; } /* * Typedefs */ typedef operator { type enumeration { enum lte { @@ -1310,44 +1310,47 @@ description "In IPv4 header field, this field is known as the Total Length. Total Length is the length of the datagram, measured in octets, including internet header and data. In IPv6 header field, this field is known as the Payload Length, the length of the IPv6 payload, i.e. the rest of the packet following the IPv6 header, in octets."; reference "RFC 791: Internet Protocol, - RFC 8200: IPv6."; + RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; } leaf ttl { type uint8; description "This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram must be dropped. In IPv6, this field is known as the Hop Limit."; reference "RFC 791: Internet Protocol, - RFC 8200: IPv6."; + RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; } leaf protocol { type uint8; description "Internet Protocol number. Refers to the protocol of the - payload. In IPv6, this field is known as 'next-header."; + payload. In IPv6, this field is known as 'next-header, + and if extension headers are present, the protocol is + present in the 'upper-layer' header."; reference "RFC 791: Internet Protocol, - RFC 8200: IPv6."; + RFC 8200: Internet Protocol, Version 6 (IPv6) Specification."; + } } grouping acl-ipv4-header-fields { description "Fields in IPv4 header."; leaf ihl { type uint8 { range "5..60"; @@ -1549,36 +1552,38 @@ leaf flags { type bits { bit cwr { position 1; description "Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism."; reference - "RFC 3168: Explicit Congestion Notification."; + "RFC 3168: The Addition of Explicit Congestion + Notification (ECN) to IP."; } bit ece { position 2; description "ECN-Echo has a dual role, depending on the value of the SYN flag. It indicates: If the SYN flag is set (1), that the TCP peer is ECN capable. If the SYN flag is clear (0), that a packet with Congestion Experienced flag set (ECN=11) in IP header was received during normal transmission (added to header by RFC 3168). This serves as an indication of network congestion (or impending congestion) to the TCP sender."; reference - "RFC 3168: Explicit Congestion Notification."; + "RFC 3168: The Addition of Explicit Congestion + Notification (ECN) to IP."; } bit urg { position 3; description "Indicates that the Urgent pointer field is significant."; } bit ack { position 4; description "Indicates that the Acknowledgment field is significant. @@ -1607,21 +1612,21 @@ } bit fin { position 8; description "Last package from sender."; } } description "Also known as Control Bits. Contains 9 1-bit flags."; reference - "RFC 793: TCP."; + "RFC 793: Transmission Control Protocol (TCP)."; } leaf window-size { type uint16; units "bytes"; description "The size of the receive window, which specifies the number of window size units beyond the segment identified by the sequence number in the acknowledgment field that the sender of this segment is currently @@ -1669,35 +1673,35 @@ actual limit for the data length, which is imposed by the underlying IPv4 protocol, is 65,507 bytes (65,535 minus 8 byte UDP header minus 20 byte IP header). In IPv6 jumbograms it is possible to have UDP packets of size greater than 65,535 bytes. RFC 2675 specifies that the length field is set to zero if the length of the UDP header plus UDP data is greater than 65,535."; - } } + } grouping acl-icmp-header-fields { description "Collection of ICMP header fields that can be used to setup a match filter."; leaf type { type uint8; description "Also known as Control messages."; reference - "RFC 792: ICMP."; + "RFC 792: Internet Control Message Protocol (ICMP)."; } leaf code { type uint8; description "ICMP subtype. Also known as Control messages."; } leaf rest-of-header { type uint32; @@ -1745,31 +1749,65 @@ The acl and aces can be described in CLI as the following: acl ipv4 sample-ipv4-acl deny tcp 192.0.2.0/24 198.51.100.0/24 + Requirement: Accept all DNS traffic destined for 2001:db8::/32 on + port 53. + + [note: '\' line wrapping for formatting only] + + + + + + allow-dns-packets + ipv6-acl-type + + + rule1 + + + 2001:db8::/32 + + + + eq + 53 + + + + + accept + + + + + + + 4.4. Port Range Usage and Other Examples When a lower-port and an upper-port are both present, it represents a range between lower-port and upper-port with both the lower-port and upper-port included. When only a port is present, it represents a port, with the operator specifying the range. - The following XML example represents a configuration where traffic to - source ports 16384, 16385, 16386, and 16387 is dropped. - - [note: '\' line wrapping for formatting only] + The following XML example represents a configuration where TCP + traffic from source ports 16384, 16385, 16386, and 16387 is dropped. sample-port-acl ipv4-acl-type @@ -1784,124 +1822,121 @@ drop - The following XML example represents a configuration where all ping - echo requests are dropped. - - [note: '\' line wrapping for formatting only] + The following XML example represents a configuration where all IPv4 + ICMP echo requests are dropped. sample-icmp-acl rule1 + + 1 + 8 0 drop The following XML example represents a configuration of a single - port, port 21 that accepts traffic. - - [note: '\' line wrapping for formatting only] + port, port 21 that accepts TCP traffic. sample-ipv4-acl ipv4-acl-type rule1 - + eq 21 - + accept The following XML example represents a configuration specifying all - ports that are not equal to 21, that will drop packets destined for - those ports. - - [note: '\' line wrapping for formatting only] + ports that are not equal to 21, that will drop TCP packets destined + for those ports. sample-ipv4-acl ipv4-acl-type rule1 - + neq 21 - + drop 5. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocol such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. - The NETCONF Access Control Model (NACM [RFC6536]) provides the means + The NETCONF Access Control Model (NACM [RFC8341]) provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content. There are a number of data nodes defined in the YANG module which are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., ) to these data nodes without proper protection can have a negative effect on network operations. @@ -1971,25 +2006,20 @@ received more participation from many vendors. Authors would like to thank Jason Sterne, Lada Lhotka, Juergen Schoenwalder, David Bannister, Jeff Haas, Kristian Larsson and Einar Nilsen-Nygaard for their review of and suggestions to the draft. 8. References 8.1. Normative References - [I-D.ietf-netmod-rfc7223bis] - Bjorklund, M., "A YANG Data Model for Interface - Management", draft-ietf-netmod-rfc7223bis-03 (work in - progress), January 2018. - [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, @@ -2000,138 +2030,140 @@ "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . - [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, - DOI 10.17487/RFC3688, January 2004, - . - [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, March 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . - [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.2", RFC 5246, - DOI 10.17487/RFC5246, August 2008, - . - [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . - [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for - the Network Configuration Protocol (NETCONF)", RFC 6020, - DOI 10.17487/RFC6020, October 2010, - . - - [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., - and A. Bierman, Ed., "Network Configuration Protocol - (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, - . - - [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure - Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, - . - - [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration - Protocol (NETCONF) Access Control Model", RFC 6536, - DOI 10.17487/RFC6536, March 2012, - . - [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . - [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF - Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, - . - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . + [RFC8343] Bjorklund, M., "A YANG Data Model for Interface + Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, + . + 8.2. Informative References - [I-D.ietf-netmod-yang-tree-diagrams] - Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- - ietf-netmod-yang-tree-diagrams-06 (work in progress), - February 2018. + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for + the Network Configuration Protocol (NETCONF)", RFC 6020, + DOI 10.17487/RFC6020, October 2010, + . + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + . + + [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure + Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, + . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . + + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + . + + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration + Access Control Model", STD 91, RFC 8341, + DOI 10.17487/RFC8341, March 2018, + . + Appendix A. Extending ACL model examples A.1. A company proprietary module example Module "example-newco-acl" is an example of company proprietary model that augments "ietf-acl" module. It shows how to use 'augment' with an XPath expression to add additional match criteria, action criteria, and default actions when no ACE matches are found. All these are company proprietary extensions or system feature extensions. "example-newco-acl" is just an example and it is expected that vendors will create their own proprietary models. - [note: '\' line wrapping for formatting only] - module example-newco-acl { yang-version 1.1; namespace "http://example.com/ns/example-newco-acl"; prefix example-newco-acl; import ietf-access-control-list { prefix "acl"; } organization "Newco model group."; contact "abc@newco.com"; description "This YANG module augments IETF ACL Yang."; - revision 2018-03-15 { + revision 2018-04-27 { description "Creating NewCo proprietary extensions to ietf-acl model"; reference "RFC XXXX: Network Access Control List (ACL) YANG Data Model"; } + augment "/acl:acls/acl:acl/" + "acl:aces/acl:ace/" + "acl:matches" { description "Newco proprietary simple filter matches"; choice protocol-payload-choice { description "Newco proprietary payload match condition"; list protocol-payload { key value-keyword; ordered-by user; description "Match protocol payload"; @@ -2221,22 +2252,20 @@ The following figure is the tree diagram of example-newco-acl. In this example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ ietf-acl:matches are augmented with two new choices, protocol- payload-choice and metadata. The protocol-payload-choice uses a grouping with an enumeration of all supported protocol values. Metadata matches apply to fields associated with the packet but not in the packet header such as overall packet length. In another example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf- acl:actions are augmented with a new choice of actions. - [note: '\' line wrapping for formatting only] - module: example-newco-acl augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: +--rw (protocol-payload-choice)? | +--:(protocol-payload) | +--rw protocol-payload* [value-keyword] | +--rw value-keyword enumeration +--rw (metadata)? +--:(packet-length) +--rw packet-length? uint16 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions: @@ -2285,21 +2314,21 @@ this draft and Linux nftables. A.3. Ethertypes The ACL module is dependent on the definition of ethertypes. IEEE owns the allocation of those ethertypes. This model is being included here to enable definition of those types till such time that IEEE takes up the task of publication of the model that defines those ethertypes. At that time, this model can be deprecated. - file "ietf-ethertypes@2018-03-15.yang" + file "ietf-ethertypes@2018-04-27.yang" module ietf-ethertypes { namespace "urn:ietf:params:xml:ns:yang:ietf-ethertypes"; prefix ethertypes; organization "IETF NETMOD (NETCONF Data Modeling Language)"; contact "WG Web: @@ -2310,23 +2339,24 @@ description "This module contains the common definitions for the Ethertype used by different modules. It is a placeholder module, till such time that IEEE starts a project to define these Ethertypes and publishes a standard. At that time this module can be deprecated."; - revision 2018-03-15 { + revision 2018-04-27 { description "Initial revision."; + reference "RFC XXXX: IETF Ethertype YANG Data Module."; } typedef ethertype { type union { type uint16; type enumeration { enum ipv4 { value 2048; @@ -2348,21 +2378,21 @@ value 2114; description "Wake-on-LAN. Hex value of 0x0842."; } enum trill { value 8947; description "Transparent Interconnection of Lots of Links. Hex value of 0x22F3."; reference - "RFC 6325 Routing Bridges (RBridges): Base Protocol + "RFC 6325: Routing Bridges (RBridges): Base Protocol Specification."; } enum srp { value 8938; description "Stream Reservation Protocol. Hex value of 0x22EA."; reference "IEEE 801.1Q-2011."; } @@ -2402,29 +2432,29 @@ enum ipx { value 33079; description "Internetwork Packet Exchange (IPX). Hex value of 0x8137."; } enum qnx { value 33284; description "QNX Qnet. Hex value of 0x8204."; - } enum ipv6 { value 34525; description "Internet Protocol Version 6 (IPv6). Hex value of 0x86DD."; reference - "RFC 8200: IPv6 + "RFC 8200: Internet Protocol, Version 6 (IPv6) + Specification RFC 8201: Path MTU Discovery for IPv6."; } enum efc { value 34824; description "Ethernet flow control using pause frames. Hex value of 0x8808"; reference "IEEE Std. 802.1Qbb."; } @@ -2439,45 +2469,48 @@ value 34841; description "CobraNet. Hex value of 0x"; } enum mpls-unicast { value 34887; description "MultiProtocol Label Switch (MPLS) unicast traffic. Hex value of 0x8847."; reference - "RFC 3031: MPLS Architecture."; + "RFC 3031: Multiprotocol Label Switching Architecture."; } enum mpls-multicast { value 34888; description "MultiProtocol Label Switch (MPLS) multicast traffic. Hex value of 0x8848."; reference - "RFC 3031: MPLS Architecture."; + "RFC 3031: Multiprotocol Label Switching Architecture."; } enum pppoe-discovery { value 34915; description "Point-to-Point Protocol over Ethernet. Used during the discovery process. Hex value of 0x8863."; reference - "RFC 2516: A method for Transmitting PPPoE."; + "RFC 2516: A method for Transmitting PPP over Ethernet + PPPoE."; + } enum pppoe-session { value 34916; description "Point-to-Point Protocol over Ethernet. Used during session stage. Hex value of 0x8864."; reference - "RFC 2516: A method for Transmitting PPPoE."; + "RFC 2516: A method for Transmitting PPP over Ethernet + PPPoE."; } enum intel-ans { value 34925; description "Intel Advanced Networking Services. Hex value of 0x886D."; } enum jumbo-frames { value 34928; description