--- 1/draft-ietf-opsawg-nat-yang-13.txt 2018-03-23 05:15:11.177654951 -0700 +++ 2/draft-ietf-opsawg-nat-yang-14.txt 2018-03-23 05:15:12.101676823 -0700 @@ -1,110 +1,113 @@ Network Working Group M. Boucadair, Ed. Internet-Draft Orange Intended status: Standards Track S. Sivakumar -Expires: August 26, 2018 Cisco Systems +Expires: September 24, 2018 Cisco Systems C. Jacquenet Orange S. Vinapamula Juniper Networks Q. Wu Huawei - February 22, 2018 + March 23, 2018 A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) - draft-ietf-opsawg-nat-yang-13 + draft-ietf-opsawg-nat-yang-14 Abstract For the sake of network automation and the need for programming Network Address Translation (NAT) function in particular, a data model for configuring and managing the NAT is essential. This document defines a YANG module for the NAT function. - NAT44, Network Address and Protocol Translation from IPv6 Clients to - IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Stateless IP/ - ICMP Translation (SIIT), Explicit Address Mappings for Stateless IP/ - ICMP Translation (SIIT EAM), IPv6 Network Prefix Translation (NPTv6), - and Destination NAT are covered in this document. + Network Address Translation from IPv4 to IPv4 (NAT44), Network + Address and Protocol Translation from IPv6 Clients to IPv4 Servers + (NAT64), Customer-side transLATor (CLAT), Stateless IP/ICMP + Translation (SIIT), Explicit Address Mappings for Stateless IP/ICMP + Translation (SIIT EAM), IPv6 Network Prefix Translation (NPTv6), and + Destination NAT are covered in this document. Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: "This version of this YANG module is part of RFC XXXX;" "RFC XXXX: A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)" "reference: RFC XXXX" + Please update the "revision" date of the YANG module. + Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 August 26, 2018. + This Internet-Draft will expire on September 24, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview of the NAT YANG Data Model . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Various Translation Flavors . . . . . . . . . . . . . . . 6 - 2.3. TCP/UDP/ICMP NAT Behavioral Requirements . . . . . . . . 7 - 2.4. Other Transport Protocols . . . . . . . . . . . . . . . . 7 + 2.3. TCP/UDP/ICMP NAT Behavioral Requirements . . . . . . . . 8 + 2.4. Other Transport Protocols . . . . . . . . . . . . . . . . 8 2.5. IP Addresses Used for Translation . . . . . . . . . . . . 8 2.6. Port Set Assignment . . . . . . . . . . . . . . . . . . . 8 - 2.7. Port-Restricted IP Addresses . . . . . . . . . . . . . . 8 - 2.8. NAT Mapping Entries . . . . . . . . . . . . . . . . . . . 8 + 2.7. Port-Restricted IP Addresses . . . . . . . . . . . . . . 9 + 2.8. NAT Mapping Entries . . . . . . . . . . . . . . . . . . . 9 2.9. Resource Limits . . . . . . . . . . . . . . . . . . . . . 12 2.10. Binding the NAT Function to an External Interface . . . . 15 2.11. Relationship to NATV2-MIB . . . . . . . . . . . . . . . . 15 2.12. Tree Structure . . . . . . . . . . . . . . . . . . . . . 16 3. NAT YANG Module . . . . . . . . . . . . . . . . . . . . . . . 22 4. Security Considerations . . . . . . . . . . . . . . . . . . . 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 74 - 7.2. Informative References . . . . . . . . . . . . . . . . . 76 + 7.2. Informative References . . . . . . . . . . . . . . . . . 77 Appendix A. Sample Examples . . . . . . . . . . . . . . . . . . 78 - A.1. Traditional NAT44 . . . . . . . . . . . . . . . . . . . . 78 + A.1. Traditional NAT44 . . . . . . . . . . . . . . . . . . . . 79 A.2. Carrier Grade NAT (CGN) . . . . . . . . . . . . . . . . . 80 A.3. CGN Pass-Through . . . . . . . . . . . . . . . . . . . . 83 A.4. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 84 A.5. Stateless IP/ICMP Translation (SIIT) . . . . . . . . . . 84 A.6. Explicit Address Mappings for Stateless IP/ICMP Translation (EAM SIIT) . . . . . . . . . . . . . . . . . 85 A.7. Static Mappings with Port Ranges . . . . . . . . . . . . 88 A.8. Static Mappings with IP Prefixes . . . . . . . . . . . . 89 A.9. Destination NAT . . . . . . . . . . . . . . . . . . . . . 90 A.10. Customer-side Translator (CLAT) . . . . . . . . . . . . . 93 @@ -130,22 +133,23 @@ Destination NAT. The full set of translation schemes that are in scope is included in Section 2.2. Sample examples are provided in Appendix A. These examples are not intended to be exhaustive. 1.1. Terminology This document makes use of the following terms: - o Basic NAT44: translation is limited to IP addresses alone - (Section 2.1 of [RFC3022]). + o Basic Network Address Translation from IPv4 to IPv4 (NAT44): + translation is limited to IP addresses alone (Section 2.1 of + [RFC3022]). o Network Address/Port Translator (NAPT): translation in NAPT is extended to include IP addresses and transport identifiers (such as a TCP/UDP port or ICMP query ID); refer to Section 2.2 of [RFC3022]. A NAPT may use an extra identifier, in addition to the five transport tuple, to disambiguate bindings [RFC6619]. o Destination NAT: is a translation that acts on the destination IP address and/or destination port number. This flavor is usually deployed in load balancers or at devices in front of public @@ -185,22 +189,24 @@ o Static explicit mapping: is created using, e.g., a CLI interface. This mapping is likely to be maintained by the NAT function till an explicit action is executed to remove it. The usage of the term NAT in this document refers to any translation flavor (NAT44, NAT64, etc.) indifferently. This document uses the term "session" as defined in [RFC2663] and [RFC6146] for NAT64. - The meaning of the symbols in tree diagrams is defined in - [I-D.ietf-netmod-yang-tree-diagrams]. + This document follows the guidelines of [RFC6087], uses the common + YANG types defined in [RFC6991], and adopts the Network Management + Datastore Architecture (NMDA). The meaning of the symbols in tree + diagrams is defined in [RFC8340]. 2. Overview of the NAT YANG Data Model 2.1. Overview The NAT YANG module is designed to cover dynamic implicit mappings and static explicit mappings. The required functionality to instruct dynamic explicit mappings is defined in separate documents such as [I-D.boucadair-pcp-yang]. Considerations about instructing explicit dynamic means (e.g., [RFC6887], [RFC6736], or [RFC8045]) are out of @@ -222,24 +228,24 @@ The NAT YANG module allows for a NAT instance to be provided with multiple NAT policies (/nat/instances/instance/policy). The document does not make any assumption about how flows are associated with a given NAT policy of a given NAT instance. Classification filters are out of scope. Defining multiple NAT instances or configuring multiple NAT policies within one single NAT instance is implementation- and deployment- specific. - This YANG module allows to instruct a NAT function to enable the - logging feature (Section 2.3 of [RFC6908] and REQ-12 of [RFC6888]). - Nevertheless, configuration parameters specific to logging protocols - are out of the scope of this document. + This YANG module provides a method to instruct a NAT function to + enable the logging feature (Section 2.3 of [RFC6908] and REQ-12 of + [RFC6888]). Nevertheless, configuration parameters specific to + logging protocols are out of the scope of this document. 2.2. Various Translation Flavors The following translation modes are supported: o Basic NAT44 o NAPT o Destination NAT o Port-restricted NAT o Stateful NAT64 (including with destination-based Pref64::/n @@ -290,51 +295,52 @@ o Combination of NAT64 and EAM: This mode corresponds to configuring static mappings for NAT64. o Stateful and stateless NAT64: A NAT64 implementation can be instructed to behave in the stateless mode for a given prefix by setting the parameter (nat64-prefixes/stateless-enable). A NAT64 implementation may behave in both stateful and stateless modes if, in addition to appropriately setting the parameter (nat64- prefixes/stateless-enable), an external IPv4 address pool is configured. - The NAT YANG module allows to retrieve the capabilities of a NAT - instance (including, list of supported translation modes, list of - supported protocols, port restriction support status, supported NAT - mapping types, supported NAT filtering types, port range allocation - support status, port parity preservation support status, port - preservation support status, the behavior for handling fragments + The NAT YANG module provides a method to retrieve the capabilities of + a NAT instance (including, list of supported translation modes, list + of supported protocols, port restriction support status, supported + NAT mapping types, supported NAT filtering types, port range + allocation support status, port parity preservation support status, + port preservation support status, the behavior for handling fragments (all, out-of-order, in-order)). 2.3. TCP/UDP/ICMP NAT Behavioral Requirements This document assumes NAT behavioral recommendations for UDP [RFC4787], TCP [RFC5382], and ICMP [RFC5508] are enabled by default. Furthermore, the NAT YANG module relies upon the recommendations detailed in [RFC6888] and [RFC7857]. 2.4. Other Transport Protocols - The module is structured to support other protocols than UDP, TCP, + The module is structured to support protocols other than UDP, TCP, and ICMP. The mapping table is designed so that it can indicate any transport protocol. For example, this module may be used to manage a DCCP-capable NAT that adheres to [RFC5597]. - Future extensions can be defined to cover NAT-related considerations + Future extensions may be needed to cover NAT-related considerations that are specific to other transport protocols such as SCTP [I-D.ietf-tsvwg-natsupp]. Typically, the mapping entry can be extended to record two optional SCTP-specific parameters: Internal Verification Tag (Int-VTag) and External Verification Tag (Ext-VTag). - Also, the module allows to enable translation for these protocols - when required (/nat/instances/instance/policy/transport-protocols). + Also, the module allows the operator to enable translation for these + protocols when required (/nat/instances/instance/policy/transport- + protocols). 2.5. IP Addresses Used for Translation The NAT YANG module assumes that blocks of IP external addresses (external-ip-address-pool) can be provisioned to the NAT function. These blocks may be contiguous or not. This behavior is aligned with [RFC6888] which specifies that a NAT function should not have any limitations on the size or the contiguity of the external address pool. In particular, the NAT @@ -342,36 +348,37 @@ external IPv4 address ranges. To accommodate traditional NAT, the module allows for a single IP address to be configured for external- ip-address-pool. Likewise, one or multiple IP address pools may be configured for Destination NAT (dst-ip-address-pool). 2.6. Port Set Assignment Port numbers can be assigned by a NAT individually (that is, a single - port is assigned on a per session basis). Nevertheless, this port - allocation scheme may not be optimal for logging purposes (Section 12 - of [RFC6269]). Therefore, a NAT function should be able to assign - port sets (e.g., [RFC7753]) to optimize the volume of the logging - data (REQ-14 of [RFC6888]). Both allocation schemes are supported in - the NAT YANG module. + port is assigned on a per session basis), but this port allocation + scheme may not be optimal for logging purposes (Section 12 of + [RFC6269]). A NAT function should be able to assign port sets (e.g., + + [RFC7753]) to optimize the volume of the logging data (REQ-14 of + [RFC6888]). Both allocation schemes are supported in the NAT YANG + module. When port set assignment is activated (i.e., port-allocation- type==port-range-allocation), the NAT can be provided with the size of the port set to be assigned (port-set-size). 2.7. Port-Restricted IP Addresses - Some NATs require to restrict the source port numbers (e.g., - Lightweight 4over6 [RFC7596], MAP-E [RFC7597]). Two schemes of port - set assignments (port-set-restrict) are supported in this document: + Some NATs restrict the source port numbers (e.g., Lightweight 4over6 + [RFC7596], MAP-E [RFC7597]). Two schemes of port set assignments + (port-set-restrict) are supported in this document: o Simple port range: is defined by two port values, the start and the end of the port range [RFC8045]. o Algorithmic: an algorithm is defined in [RFC7597] to characterize the set of ports that can be used. 2.8. NAT Mapping Entries A TCP/UDP mapping entry maintains an association between the @@ -421,23 +428,23 @@ an internal host when sending a packet to a remote host. external-dst-address: Indicates the destination IP address/prefix used by a NAT when processing a packet issued by an internal host towards a remote host. external-dst-port: Indicates the destination port number used by a NAT when processing a packet issued by an internal host towards a remote host. - In order to cover both NAT64 and NAT44 flavors in particular, the NAT - mapping structure allows to include an IPv4 or an IPv6 address as an - internal IP address. Remaining fields are common to both NAT + In order to cover both NAT64 and NAT44 flavors, the NAT mapping + structure allows for the inclusion of an IPv4 or an IPv6 address as + an internal IP address. Remaining fields are common to both NAT schemes. For example, the mapping that will be created by a NAT64 upon receipt of a TCP SYN from source address 2001:db8:aaaa::1 and source port number 25636 to destination IP address 2001:db8:1234::198.51.100.1 and destination port number 8080 is shown in Table 2. This example assumes EDM (Endpoint-Dependent Mapping). +-----------------------+-------------------------------------------+ | Mapping Entry | Value | @@ -538,128 +545,123 @@ Table 5 lists the various limits that can be set using the NAT YANG module. Once a limit is reached, packets that would normally trigger new port mappings or be translated because they match existing mappings, are dropped by the translator. +-------------------+-----------------------------------------------+ | Limit | Description | +-------------------+-----------------------------------------------+ | port-quota | Specifies a port quota to be assigned per | - | | subscriber. It corresponds to the | - | | maximum number of ports to be used by a | - | | subscriber. The port quota can be configured | - | | to apply to all protocols or to a | - | | specific protocol. Distinct port quota may be | - | | configured per protocol. | + | | subscriber. It corresponds to the maximum | + | | number of ports to be used by a subscriber. | + | | The port quota can be configured to apply to | + | | all protocols or to a specific protocol. | + | | Distinct port quota may be configured per | + | | protocol. | +-------------------+-----------------------------------------------+ | fragments-limit | In order to prevent denial of service attacks | - | | that can be caused by fragments, | - | | this parameter is used to limit the number of | - | | out-of-order fragments that can be handled by | - | | a translator. | + | | that can be caused by fragments, this | + | | parameter is used to limit the number of out- | + | | of-order fragments that can be handled by a | + | | translator. | +-------------------+-----------------------------------------------+ | mapping-limits | This parameter can be used to control the | - | | maximum number of subscribers that | - | | can be serviced by a NAT instance | - | | (limit-subscriber) and the maximum number of | - | | address and/or port mappings that | - | | can be maintained by a NAT instance | - | | (limit-address-mappings and limit-port- | - | | mappings). Also, limits specific to | + | | maximum number of subscribers that can be | + | | serviced by a NAT instance (limit-subscriber) | + | | and the maximum number of address and/or port | + | | mappings that can be maintained by a NAT | + | | instance (limit-address-mappings and limit- | + | | port-mappings). Also, limits specific to | | | protocols (e.g., TCP, UDP, ICMP) can also be | | | specified (limit-per-protocol). | +-------------------+-----------------------------------------------+ | connection-limits | In order to prevent exhausting the resources | - | | of a NAT implementation and to | - | | ensure fairness usage among subscribers, | - | | various rate-limits can be specified. Rate- | - | | limiting can be enforced per | - | | subscriber ((limit-subscriber), per NAT | - | | instance (limit-per-instance), | - | | and/or be specified for each supported | - | | protocol (limit-per-protocol). | + | | of a NAT implementation and to ensure | + | | fairness usage among subscribers, various | + | | rate-limits can be specified. Rate-limiting | + | | can be enforced per subscriber ((limit- | + | | subscriber), per NAT instance (limit-per- | + | | instance), and/or be specified for each | + | | supported protocol (limit-per-protocol). | +-------------------+-----------------------------------------------+ Table 5: NAT Limits Table 6 describes limits, that once exceeded, will trigger notifications to be generated: +--------------------------+----------------------------------------+ | Notification Threshold | Description | +--------------------------+----------------------------------------+ | high-threshold | Used to notify high address | | | utilization of a given pool. When | | | exceeded, a nat-pool-event | | | notification will be generated. | +--------------------------+----------------------------------------+ | low-threshold | Used to notify low address utilization | - | | of a given pool. An | - | | administrator is supposed to configure | - | | low-threshold so that it can | - | | reflect an abnormal usage of NAT | - | | resources. When exceeded, a | + | | of a given pool. An administrator is | + | | supposed to configure low-threshold so | + | | that it can reflect an abnormal usage | + | | of NAT resources. When exceeded, a | | | nat-pool-event notification will be | | | generated. | +--------------------------+----------------------------------------+ | notify-addresses-usage | Used to notify high address | - | | utilization of all pools configured | - | | to a NAT instance. When exceeded, a | - | | nat-instance-event will be | - | | generated. | + | | utilization of all pools configured to | + | | a NAT instance. When exceeded, a nat- | + | | instance-event will be generated. | +--------------------------+----------------------------------------+ | notify-ports-usage | Used to notify high port allocation | | | taking into account all pools | | | configured to a NAT instance. When | | | exceeded, a nat-instance-event | | | notification will be generated. | +--------------------------+----------------------------------------+ | notify-subscribers-limit | Used to notify a high number of active | - | | subscribers that are | - | | serviced by a NAT instance. When | - | | exceeded, a nat-instance-event | - | | notification will be generated. | + | | subscribers that are serviced by a NAT | + | | instance. When exceeded, a nat- | + | | instance-event notification will be | + | | generated. | +--------------------------+----------------------------------------+ Table 6: Notification Thresholds - In order to prevent from generating frequent notifications, the NAT - YANG module supports the following limits (Table 7) used to control - how frequent notifications can be generated. That is, notifications - are subject to rate-limiting imposed by these intervals. + In order to prevent a NAT implementation from generating frequent + notifications, the NAT YANG module supports the following limits + (Table 7) used to control how frequent notifications can be + generated. That is, notifications are subject to rate-limiting + imposed by these intervals. +-------------------------------------+-----------------------------+ | Interval | Description | +-------------------------------------+-----------------------------+ | notify-pool-usage/notify-interval | Indicates the minimum | | | number of seconds between | - | | successive | - | | notifications for a given | - | | address pool. | + | | successive notifications | + | | for a given address pool. | +-------------------------------------+-----------------------------+ | notification-limits/notify-interval | Indicates the minimum | | | number of seconds between | - | | successive | - | | notifications for a NAT | - | | instance. | + | | successive notifications | + | | for a NAT instance. | +-------------------------------------+-----------------------------+ Table 7: Notification Intervals 2.10. Binding the NAT Function to an External Interface The module is designed to specify an external realm on which the NAT function must be applied (external-realm). The module supports - indicating an interface as an external realm, but the module is - extensible so that other choices can be indicated in the future - (e.g., Virtual Routing and Forwarding (VRF) instance). + indicating an interface as an external realm [RFC8343], but the + module is extensible so that other choices can be indicated in the + future (e.g., Virtual Routing and Forwarding (VRF) instance). Distinct external realms can be provided as a function of the NAT policy (see for example, Section 4 of [RFC7289]). If no external realm is provided, this assumes that the system is able to determine the external interface (VRF instance, etc.) on which the NAT will be applied. Typically, the WAN and LAN interfaces of a CPE are determined by the CPE. 2.11. Relationship to NATV2-MIB @@ -989,24 +991,37 @@ 3. NAT YANG Module file "ietf-nat@2018-02-23.yang" module ietf-nat { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-nat"; prefix "nat"; - import ietf-inet-types { prefix inet; } - import ietf-yang-types { prefix yang; } - import ietf-interfaces { prefix if; } + import ietf-inet-types { + prefix inet; + reference + "Section 4 of RFC 6991"; + } + + import ietf-yang-types { + prefix yang; + reference + "Section 3 of RFC 6991"; + } + import ietf-interfaces { + prefix if; + reference + "RFC 8343: A YANG Data Model for Interface Management"; + } organization "IETF OPSAWG (Operations and Management Area Working Group)"; contact "WG Web: WG List: Editor: Mohamed Boucadair @@ -3377,35 +3398,35 @@ discussed in [RFC6888], [RFC6146], [RFC6877], [RFC6296], and [RFC7757]. The YANG module defined in this document is designed to be accessed via network management protocols 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 [RFC5246]. - The NETCONF access control model [RFC6536] provides the means to + The NETCONF access control model [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. All data nodes defined in the YANG module which can be created, modified and deleted (i.e., config true, which is the default) are considered sensitive. Write operations (e.g., edit-config) applied to these data nodes without proper protection can negatively affect - network operations. The NAT YANG module allows to set parameters to - prevent a user from aggressively using NAT resources (port-quota), - rate-limit connections as a guard against Denial-of-Service, or to - enable notifications so that appropriate measures are enforced to - anticipate traffic drops. Nevertheless, an attacker who is able to - access to the NAT can undertake various attacks, such as: + network operations. The NAT YANG module provides a method to set + parameters to prevent a user from aggressively using NAT resources + (port-quota), rate-limit connections as a guard against Denial-of- + Service, or to enable notifications so that appropriate measures are + enforced to anticipate traffic drops. Nevertheless, an attacker who + is able to access the NAT can undertake various attacks, such as: o Set a high or low resource limit to cause a DoS attack: * /nat/instances/instance/policy/port-quota * /nat/instances/instance/policy/fragments-limit * /nat/instances/instance/mapping-limits * /nat/instances/instance/connection-limits @@ -3460,21 +3482,22 @@ This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950]. name: ietf-nat namespace: urn:ietf:params:xml:ns:yang:ietf-nat prefix: nat reference: RFC XXXX 6. Acknowledgements - Many thanks to Dan Wing, Tianran Zhou, and Tom Petch for the review. + Many thanks to Dan Wing, Tianran Zhou, Tom Petch, and Warren Kumari + for the review. Thanks to Juergen Schoenwaelder for the comments on the YANG structure and the suggestion to use NMDA. Mahesh Jethanandani provided useful comments. Thanks to Lee Howard and Jordi Palet for the CLAT comments, Fred Baker for the NPTv6 comments, Tore Anderson for EAM SIIT review, and Kristian Poscic for the CGN review. Special thanks to Maros Marsalek and Marek Gradzki for sharing their @@ -3534,40 +3557,39 @@ . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, . - [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration - Protocol (NETCONF) Access Control Model", RFC 6536, - DOI 10.17487/RFC6536, March 2012, - . - [RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable Operation of Address Translators with Per-Interface Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012, . [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, . [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, . + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", + RFC 6991, DOI 10.17487/RFC6991, July 2013, + . + [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual- Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, . [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, . @@ -3589,37 +3611,41 @@ . [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, . + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration + Access Control Model", STD 91, RFC 8341, + DOI 10.17487/RFC8341, March 2018, + . + + [RFC8343] Bjorklund, M., "A YANG Data Model for Interface + Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, + . + 7.2. Informative References [I-D.boucadair-pcp-yang] Boucadair, M., Jacquenet, C., Sivakumar, S., and S. Vinapamula, "YANG Modules for the Port Control Protocol (PCP)", draft-boucadair-pcp-yang-05 (work in progress), October 2017. - [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. - [I-D.ietf-softwire-dslite-yang] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG Data Module for Dual-Stack Lite (DS-Lite)", draft-ietf- - softwire-dslite-yang-14 (work in progress), January 2018. + softwire-dslite-yang-15 (work in progress), February 2018. [I-D.ietf-tsvwg-natsupp] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", draft-ietf-tsvwg-natsupp-11 (work in progress), July 2017. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, @@ -3629,20 +3655,24 @@ Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, . [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol", BCP 150, RFC 5597, DOI 10.17487/RFC5597, September 2009, . + [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG + Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, + January 2011, . + [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, . [RFC6736] Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, "Diameter Network Address and Port Translation Control Application", RFC 6736, DOI 10.17487/RFC6736, October 2012, . @@ -3678,20 +3708,24 @@ [RFC7753] Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., and S. Perreault, "Port Control Protocol (PCP) Extension for Port-Set Allocation", RFC 7753, DOI 10.17487/RFC7753, February 2016, . [RFC8045] Cheng, D., Korhonen, J., Boucadair, M., and S. Sivakumar, "RADIUS Extensions for IP Port Configuration and Reporting", RFC 8045, DOI 10.17487/RFC8045, January 2017, . + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + . + Appendix A. Sample Examples This section provides a non-exhaustive set of examples to illustrate the use of the NAT YANG module. A.1. Traditional NAT44 Traditional NAT44 is a Basic NAT44 or NAPT that is used to share the same IPv4 address among hosts that are owned by the same subscriber. This is typically the NAT that is embedded in CPE devices.