Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: NETMOD

RFC 8519

YANG Data Model for Network Access Control Lists (ACLs)

Pages: 60
Proposed STD
Errata
Part 2 of 3 – Pages 24 to 46
First   Prev   Next

Top   ToC   RFC8519 - Page 24   prevText
4.2.  IETF Packet Fields Module

   The packet fields module defines the necessary groups for matching on
   fields in the packet including Ethernet, IPv4, IPv6, and transport-
   layer fields.  The "type" node determines which of these fields get
   included for any given ACL with the exception of TCP, UDP, and ICMP
   header fields.  Those fields can be used in conjunction with any of
   the above Layer 2 or Layer 3 fields.

   Since the number of match criteria are very large, the base
   specification does not include these directly but references them by
   the 'uses' statement to keep the base module simple.  In case more
   match conditions are needed, those can be added by augmenting choices
   within container "matches" in the ietf-access-control-list.yang data
   model.

   This module imports definitions from "Common YANG Data Types"
   [RFC6991] and references "Internet Protocol" [RFC791], "Internet
   Control Message Protocol" [RFC792], "Transmission Control Protocol"
   [RFC793], "Definition of the Differentiated Services Field (DS Field)
   in the IPv4 and IPv6 Headers" [RFC2474], "The Addition of Explicit
   Congestion Notification (ECN) to IP" [RFC3168], "IPv6 Scoped Address
Top   ToC   RFC8519 - Page 25
   Architecture" [RFC4007], "IP Version 6 Addressing Architecture"
   [RFC4291], "A Recommendation for IPv6 Address Text Representation"
   [RFC5952], and "Internet Protocol, Version 6 (IPv6) Specification"
   [RFC8200].

<CODE BEGINS> file "ietf-packet-fields@2019-03-04.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.";
  }

  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991 - Common YANG Data Types.";
  }

  import ietf-ethertypes {
    prefix eth;
    reference
      "RFC 8519 - YANG Data Model for Network Access Control
                  Lists (ACLs).";
  }

  organization
    "IETF NETMOD (Network Modeling) Working Group.";

  contact
    "WG Web:  <https://datatracker.ietf.org/wg/netmod/>
     WG List: netmod@ietf.org

     Editor: Mahesh Jethanandani
             mjethanandani@gmail.com
     Editor: Lisa Huang
             huangyi_99@yahoo.com
     Editor: Sonal Agarwal
             sagarwal12@gmail.com
     Editor: Dana Blair
             dana@blairhome.com";
Top   ToC   RFC8519 - Page 26
  description
    "This YANG module defines groupings that are used by
     the ietf-access-control-list YANG module.  Their usage
     is not limited to ietf-access-control-list and can be
     used anywhere as applicable.

     Copyright (c) 2019 IETF Trust and the persons identified as
     the document authors.  All rights reserved.

     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 8519; see
     the RFC itself for full legal notices.";

  revision 2019-03-04 {
    description
      "Initial version.";
    reference
      "RFC 8519: YANG Data Model for Network Access Control
                 Lists (ACLs).";
  }

  /*
   * Typedefs
   */
  typedef operator {
    type enumeration {
      enum lte {
        description
          "Less than or equal to.";
      }
      enum gte {
        description
          "Greater than or equal to.";
      }
      enum eq {
        description
          "Equal to.";
      }
      enum neq {
        description
          "Not equal to.";
      }
Top   ToC   RFC8519 - Page 27
    }
    description
      "The source and destination port range definitions
       can be further qualified using an operator.  An
       operator is needed only if the lower-port is specified
       and the upper-port is not specified.  The operator
       therefore further qualifies the lower-port only.";
  }

  /*
   * Groupings
   */
  grouping port-range-or-operator {
    choice port-range-or-operator {
      case range {
        leaf lower-port {
          type inet:port-number;
          must '. <= ../upper-port' {
            error-message
              "The lower-port must be less than or equal to
               the upper-port.";
          }
          mandatory true;
          description
            "Lower boundary for a port.";
        }
        leaf upper-port {
          type inet:port-number;
          mandatory true;
          description
            "Upper boundary for a port.";
        }
      }
      case operator {
        leaf operator {
          type operator;
          default "eq";
          description
            "Operator to be applied on the port below.";
        }
        leaf port {
          type inet:port-number;
          mandatory true;
          description
            "Port number along with the operator on which to
             match.";
        }
      }
Top   ToC   RFC8519 - Page 28
      description
        "Choice of specifying a port range or a single
         port along with an operator.";
    }
    description
      "Grouping for port definitions in the form of a
       choice statement.";
  }

  grouping acl-ip-header-fields {
    description
      "IP header fields common to IPv4 and IPv6";
    reference
      "RFC 791: Internet Protocol.";

    leaf dscp {
      type inet:dscp;
      description
        "Differentiated Services Code Point.";
      reference
        "RFC 2474: Definition of the Differentiated Services
                   Field (DS Field) in the IPv4 and IPv6
                   Headers.";
    }

    leaf ecn {
      type uint8 {
        range "0..3";
      }
      description
        "Explicit Congestion Notification.";
      reference
        "RFC 3168: The Addition of Explicit Congestion
                   Notification (ECN) to IP.";
    }

    leaf length {
      type uint16;
      description
        "In the 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 the IPv6 header field, this field is known as the Payload
         Length, which is the length of the IPv6 payload, i.e., the rest
         of the packet following the IPv6 header, in octets.";
      reference
        "RFC 791: Internet Protocol
Top   ToC   RFC8519 - Page 29
         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: 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',
         and if extension headers are present, the protocol is
         present in the 'upper-layer' header.";
      reference
        "RFC 791: Internet Protocol
         RFC 8200: Internet Protocol, Version 6 (IPv6) Specification.";
    }
  }

  grouping acl-ipv4-header-fields {
    description
      "Fields in the IPv4 header.";
    leaf ihl {
      type uint8 {
        range "5..60";
      }
      description
        "In an IPv4 header field, the Internet Header Length (IHL) is
         the length of the internet header in 32-bit words and
         thus points to the beginning of the data.  Note that the
         minimum value for a correct header is 5.";
    }
    leaf flags {
      type bits {
        bit reserved {
          position 0;
          description
            "Reserved.  Must be zero.";
        }
        bit fragment {
Top   ToC   RFC8519 - Page 30
          position 1;
          description
            "Setting the value to 0 indicates may fragment, while
             setting the value to 1 indicates do not fragment.";
        }
        bit more {
          position 2;
          description
            "Setting the value to 0 indicates this is the last fragment,
             and setting the value to 1 indicates more fragments are
             coming.";
        }
      }
      description
        "Bit definitions for the Flags field in the IPv4 header.";
    }
    leaf offset {
      type uint16 {
        range "20..65535";
      }
      description
        "The fragment offset is measured in units of 8 octets (64 bits).
         The first fragment has offset zero.  The length is 13 bits";
    }
    leaf identification {
      type uint16;
      description
        "An identifying value assigned by the sender to aid in
         assembling the fragments of a datagram.";
    }

    choice destination-network {
      case destination-ipv4-network {
        leaf destination-ipv4-network {
          type inet:ipv4-prefix;
          description
            "Destination IPv4 address prefix.";
        }
      }
      description
        "Choice of specifying a destination IPv4 address or
         referring to a group of IPv4 destination addresses.";
    }

    choice source-network {
      case source-ipv4-network {
        leaf source-ipv4-network {
          type inet:ipv4-prefix;
Top   ToC   RFC8519 - Page 31
          description
            "Source IPv4 address prefix.";
        }
      }
      description
        "Choice of specifying a source IPv4 address or
         referring to a group of IPv4 source addresses.";
    }
  }

  grouping acl-ipv6-header-fields {
    description
      "Fields in the IPv6 header.";

    choice destination-network {
      case destination-ipv6-network {
        leaf destination-ipv6-network {
          type inet:ipv6-prefix;
          description
            "Destination IPv6 address prefix.";
        }
      }
      description
        "Choice of specifying a destination IPv6 address
         or referring to a group of IPv6 destination
         addresses.";
    }

    choice source-network {
      case source-ipv6-network {
        leaf source-ipv6-network {
          type inet:ipv6-prefix;
          description
            "Source IPv6 address prefix.";
        }
      }
      description
        "Choice of specifying a source IPv6 address or
         referring to a group of IPv6 source addresses.";
    }

    leaf flow-label {
      type inet:ipv6-flow-label;
      description
        "IPv6 Flow label.";
    }
    reference
      "RFC 4291: IP Version 6 Addressing Architecture
Top   ToC   RFC8519 - Page 32
       RFC 4007: IPv6 Scoped Address Architecture
       RFC 5952: A Recommendation for IPv6 Address Text
                 Representation.";
  }

  grouping acl-eth-header-fields {
    description
      "Fields in the Ethernet header.";
    leaf destination-mac-address {
      type yang:mac-address;
      description
        "Destination IEEE 802 Media Access Control (MAC)
         address.";
    }
    leaf destination-mac-address-mask {
      type yang:mac-address;
      description
        "Destination IEEE 802 MAC address mask.";
    }
    leaf source-mac-address {
      type yang:mac-address;
      description
        "Source IEEE 802 MAC address.";
    }
    leaf source-mac-address-mask {
      type yang:mac-address;
      description
        "Source IEEE 802 MAC address mask.";
    }
    leaf ethertype {
      type eth:ethertype;
      description
        "The Ethernet Type (or Length) value represented
         in the canonical order defined by IEEE 802.
         The canonical representation uses lowercase
         characters.";
      reference
        "IEEE 802-2014, Clause 9.2.";
    }
    reference
      "IEEE 802: IEEE Standard for Local and Metropolitan
       Area Networks: Overview and Architecture.";
  }

  grouping acl-tcp-header-fields {
    description
      "Collection of TCP header fields that can be used to
       set up a match filter.";
Top   ToC   RFC8519 - Page 33
    leaf sequence-number {
      type uint32;
      description
        "Sequence number that appears in the packet.";
    }
    leaf acknowledgement-number {
      type uint32;
      description
        "The acknowledgement number that appears in the
         packet.";
    }
    leaf data-offset {
      type uint8 {
        range "5..15";
      }
      description
        "Specifies the size of the TCP header in 32-bit
         words.  The minimum size header is 5 words and
         the maximum is 15 words; thus, this gives a
         minimum size of 20 bytes and a maximum of 60
         bytes, allowing for up to 40 bytes of options
         in the header.";
    }
    leaf reserved {
      type uint8;
      description
        "Reserved for future use.";
    }
    leaf flags {
      type bits {
        bit cwr {
          position 1;
          description
            "The Congestion Window Reduced (CWR) flag is set
             by the sending host to indicate that it received
             a TCP segment with the ECN-Echo (ECE) flag set
             and had responded in the congestion control
             mechanism.";
          reference
            "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 the following: if
             the SYN flag is set (1), the TCP peer is ECN
Top   ToC   RFC8519 - Page 34
             capable, and if the SYN flag is clear (0), a packet
             with the Congestion Experienced flag set (ECN=11)
             in the IP header was received during normal
             transmission (added to the header by RFC 3168).
             This serves as an indication of network congestion
             (or impending congestion) to the TCP sender.";
          reference
            "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 Acknowledgement field is significant.
             All packets after the initial SYN packet sent by the
             client should have this flag set.";
        }
        bit psh {
          position 5;
          description
            "Push function.  Asks to push the buffered data to the
             receiving application.";
        }
        bit rst {
          position 6;
          description
            "Reset the connection.";
        }
        bit syn {
          position 7;
          description
            "Synchronize sequence numbers.  Only the first packet
             sent from each end should have this flag set.  Some
             other flags and fields change meaning based on this
             flag, and some are only valid for when it is set,
             and others when it is clear.";
        }
        bit fin {
          position 8;
          description
            "Last package from the sender.";
        }
      }
Top   ToC   RFC8519 - Page 35
      description
        "Also known as Control Bits.  Contains nine 1-bit flags.";
      reference
        "RFC 793: Transmission Control Protocol.";
    }
    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 Acknowledgement
         field that the sender of this segment is currently
         willing to receive.";
    }
    leaf urgent-pointer {
      type uint16;
      description
        "This field is an offset from the sequence number
         indicating the last urgent data byte.";
    }
    leaf options {
      type binary {
        length "1..40";
      }
      description
        "The length of this field is determined by the
         Data Offset field.  Options have up to three
         fields: Option-Kind (1 byte), Option-Length
         (1 byte), and Option-Data (variable).  The Option-Kind
         field indicates the type of option and is the
         only field that is not optional.  Depending on
         what kind of option we are dealing with,
         the next two fields may be set: the Option-Length
         field indicates the total length of the option,
         and the Option-Data field contains the value of
         the option, if applicable.";
    }
  }

  grouping acl-udp-header-fields {
    description
      "Collection of UDP header fields that can be used
       to set up a match filter.";
    leaf length {
      type uint16;
      description
        "A field that specifies the length in bytes of
Top   ToC   RFC8519 - Page 36
         the UDP header and UDP data.  The minimum
         length is 8 bytes because that is the length of
         the header.  The field size sets a theoretical
         limit of 65,535 bytes (8-byte header plus 65,527
         bytes of data) for a UDP datagram.  However, the
         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 a 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 set up a match filter.";
    leaf type {
      type uint8;
      description
        "Also known as control messages.";
      reference
        "RFC 792: Internet Control Message Protocol
         RFC 4443: Internet Control Message Protocol (ICMPv6)
                   for Internet Protocol Version 6 (IPv6)
                   Specification.";
    }
    leaf code {
      type uint8;
      description
        "ICMP subtype.  Also known as control messages.";
      reference
        "RFC 792: Internet Control Message Protocol
         RFC 4443: Internet Control Message Protocol (ICMPv6)
                   for Internet Protocol Version 6 (IPv6)
                   Specification.";
    }
    leaf rest-of-header {
      type binary;
      description
        "Unbounded in length, the contents vary based on the
         ICMP type and code.  Also referred to as 'Message Body'
         in ICMPv6.";
Top   ToC   RFC8519 - Page 37
      reference
        "RFC 792: Internet Control Message Protocol
         RFC 4443: Internet Control Message Protocol (ICMPv6)
                   for Internet Protocol Version 6 (IPv6)
                   Specification.";
    }
  }
}

<CODE ENDS>

4.3.  ACL Examples

   Requirement: Deny tcp traffic from 192.0.2.0/24, destined to
   198.51.100.0/24.

   Here is the ACL configuration xml for this Access Control List:

   [note: '\' line wrapping for formatting only]

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <acls
       xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
       <acl>
         <name>sample-ipv4-acl</name>
         <type>ipv4-acl-type</type>
         <aces>
           <ace>
             <name>rule1</name>
             <matches>
               <ipv4>
                 <protocol>6</protocol>
                 <destination-ipv4-network>198.51.100.0/24</destination\
   -ipv4-network>
                 <source-ipv4-network>192.0.2.0/24</source-ipv4-network>
               </ipv4>
             </matches>
             <actions>
               <forwarding>drop</forwarding>
             </actions>
           </ace>
         </aces>
       </acl>
     </acls>
   </config>
Top   ToC   RFC8519 - Page 38
   The ACL and ACEs can be described in the command-line interface (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]

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <acls
       xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
       <acl>
         <name>allow-dns-packets</name>
         <type>ipv6-acl-type</type>
         <aces>
           <ace>
             <name>rule1</name>
             <matches>
               <ipv6>
                 <destination-ipv6-network>2001:db8::/32</destination-i\
   pv6-network>
               </ipv6>
               <udp>
                 <destination-port>
                   <operator>eq</operator>
                   <port>53</port>
                 </destination-port>
               </udp>
             </matches>
             <actions>
               <forwarding>accept</forwarding>
             </actions>
           </ace>
         </aces>
       </acl>
     </acls>
   </config>
Top   ToC   RFC8519 - Page 39
4.4.  Port Range Usage and Other Examples

   When a lower-port and an upper-port are both present, it represents a
   range between the 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 TCP
   traffic from source ports 16384, 16385, 16386, and 16387 is dropped.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <acls
       xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
       <acl>
         <name>sample-port-acl</name>
         <type>ipv4-acl-type</type>
         <aces>
           <ace>
             <name>rule1</name>
             <matches>
               <tcp>
                 <source-port>
                   <lower-port>16384</lower-port>
                   <upper-port>16387</upper-port>
                 </source-port>
               </tcp>
             </matches>
             <actions>
               <forwarding>drop</forwarding>
             </actions>
           </ace>
         </aces>
       </acl>
     </acls>
   </config>
Top   ToC   RFC8519 - Page 40
   The following XML example represents a configuration where all IPv4
   ICMP echo requests are dropped.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <acls
       xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
       <acl>
         <name>sample-icmp-acl</name>
         <aces>
           <ace>
             <name>rule1</name>
             <matches>
               <ipv4>
                 <protocol>1</protocol>
               </ipv4>
               <icmp>
                 <type>8</type>
                 <code>0</code>
               </icmp>
             </matches>
             <actions>
               <forwarding>drop</forwarding>
             </actions>
           </ace>
         </aces>
       </acl>
     </acls>
   </config>
Top   ToC   RFC8519 - Page 41
   The following XML example represents a configuration of a single
   port, port 21, that accepts TCP traffic.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <acls
       xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
       <acl>
         <name>sample-ipv4-acl</name>
         <type>ipv4-acl-type</type>
         <aces>
           <ace>
             <name>rule1</name>
             <matches>
               <tcp>
                 <destination-port>
                   <operator>eq</operator>
                   <port>21</port>
                 </destination-port>
               </tcp>
             </matches>
             <actions>
               <forwarding>accept</forwarding>
             </actions>
           </ace>
         </aces>
       </acl>
     </acls>
   </config>
Top   ToC   RFC8519 - Page 42
   The following XML example represents a configuration specifying all
   ports that are not equal to 21 that will drop TCP packets destined
   for those ports.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <acls
       xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
       <acl>
         <name>sample-ipv4-acl</name>
         <type>ipv4-acl-type</type>
         <aces>
           <ace>
             <name>rule1</name>
             <matches>
               <tcp>
                 <destination-port>
                   <operator>neq</operator>
                   <port>21</port>
                 </destination-port>
               </tcp>
             </matches>
             <actions>
               <forwarding>drop</forwarding>
             </actions>
           </ace>
         </aces>
       </acl>
     </acls>
   </config>

5.  Security Considerations

   The YANG modules specified in this document define 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 Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC8446].

   The NETCONF Access Control Model (NACM) [RFC8341] provides the means
   to restrict access for particular NETCONF or RESTCONF users to a
   preconfigured subset of all available NETCONF or RESTCONF protocol
   operations and content.
Top   ToC   RFC8519 - Page 43
   There are a number of data nodes defined in these YANG modules that
   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., edit-config)
   to these data nodes without proper protection can have a negative
   effect on network operations.  These are the subtrees and data nodes
   and their sensitivity/vulnerability:

      /acls/acl/aces: This list specifies all the configured access
      control entries on the device.  Unauthorized write access to this
      list can allow intruders to modify the entries so as to permit
      traffic that should not be permitted, or deny traffic that should
      be permitted.  The former may result in a DoS attack, or
      compromise the device.  The latter may result in a DoS attack.
      The impact of an unauthorized read access of the list will allow
      the attacker to determine which rules are in effect, to better
      craft an attack.

      /acls/acl/aces/ace/actions/logging: This node specifies ability to
      log packets that match this ace entry.  Unauthorized write access
      to this node can allow intruders to enable logging on one or many
      ace entries, overwhelming the server in the process.  Unauthorized
      read access of this node can allow intruders to access logging
      information, which could be used to craft an attack the server.

6.  IANA Considerations

   This document registers three URIs and three YANG modules.

6.1.  URI Registration

   This document registers three URIs in the "IETF XML Registry"
   [RFC3688] as follows:

   URI: urn:ietf:params:xml:ns:yang:ietf-access-control-list
   URI: urn:ietf:params:xml:ns:yang:ietf-packet-fields
   URI: urn:ietf:params:xml:ns:yang:ietf-ethertypes

   Registrant Contact: The IESG.

   XML: N/A; the requested URI is an XML namespace.
Top   ToC   RFC8519 - Page 44
6.2.  YANG Module Name Registration

   This document registers three YANG modules in the "YANG Module Names"
   registry [RFC6020].

   Name: ietf-access-control-list
   Namespace: urn:ietf:params:xml:ns:yang:ietf-access-control-list
   Prefix: acl
   Reference: RFC 8519

   Name: ietf-packet-fields
   Namespace: urn:ietf:params:xml:ns:yang:ietf-packet-fields
   Prefix: packet-fields
   Reference: RFC 8519

   Name: ietf-ethertypes
   Namespace: urn:ietf:params:xml:ns:yang:ietf-ethertypes
   Prefix: ethertypes
   Reference: RFC 8519

7.  References

7.1.  Normative References

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC792]   Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <https://www.rfc-editor.org/info/rfc792>.

   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.
Top   ToC   RFC8519 - Page 45
   [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,
              <https://www.rfc-editor.org/info/rfc3168>.

   [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
              B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
              DOI 10.17487/RFC4007, March 2005,
              <https://www.rfc-editor.org/info/rfc4007>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952,
              DOI 10.17487/RFC5952, August 2010,
              <https://www.rfc-editor.org/info/rfc5952>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
              <https://www.rfc-editor.org/info/rfc8343>.
Top   ToC   RFC8519 - Page 46
7.2.  Informative References

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [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,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [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,
              <https://www.rfc-editor.org/info/rfc7011>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.


Next Section