Internet Engineering Task Force (IETF)                 M. Boucadair, Ed.
Request for Comments: 8512                                        Orange
Category: Standards Track                                   S. Sivakumar
ISSN: 2070-1721                                            Cisco Systems
                                                            C. Jacquenet
                                                                  Orange
                                                           S. Vinapamula
                                                        Juniper Networks
                                                                   Q. Wu
                                                                  Huawei
                                                            January 2019


                           A YANG Module for
 Network Address Translation (NAT) and Network Prefix Translation (NPT)

Abstract

   This document defines a YANG module for the Network Address
   Translation (NAT) function.

   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 (EAM) for SIIT,
   IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT
   are covered in this document.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8512.

Copyright Notice

   Copyright (c) 2019 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Overview of the NAT YANG Data Model . . . . . . . . . . . . .   6
     2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Various Translation Flavors . . . . . . . . . . . . . . .   7
     2.3.  TCP/UDP/ICMP NAT Behavioral Requirements  . . . . . . . .   8
     2.4.  Other Transport Protocols . . . . . . . . . . . . . . . .   8
     2.5.  IP Addresses Used for Translation . . . . . . . . . . . .   9
     2.6.  Port-Set Assignment . . . . . . . . . . . . . . . . . . .   9
     2.7.  Port-Restricted IP Addresses  . . . . . . . . . . . . . .   9
     2.8.  NAT Mapping Entries . . . . . . . . . . . . . . . . . . .  10
     2.9.  Resource Limits . . . . . . . . . . . . . . . . . . . . .  13
     2.10. Binding the NAT Function to an External Interface . . . .  16
     2.11. Relationship to NATV2-MIB . . . . . . . . . . . . . . . .  16
     2.12. Tree Structure  . . . . . . . . . . . . . . . . . . . . .  17
   3.  NAT YANG Module . . . . . . . . . . . . . . . . . . . . . . .  24
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  68
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  70
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  70
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  70
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  73
   Appendix A.  Some Examples  . . . . . . . . . . . . . . . . . . .  75
     A.1.  Traditional NAT44 . . . . . . . . . . . . . . . . . . . .  75
     A.2.  Carrier Grade NAT (CGN) . . . . . . . . . . . . . . . . .  76
     A.3.  CGN Pass-Through  . . . . . . . . . . . . . . . . . . . .  80
     A.4.  NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . .  80
     A.5.  Stateless IP/ICMP Translation (SIIT)  . . . . . . . . . .  81
     A.6.  Explicit Address Mappings (EAM) for Stateless IP/ICMP
           Translation (SIIT)  . . . . . . . . . . . . . . . . . . .  82
     A.7.  Static Mappings with Port Ranges  . . . . . . . . . . . .  85
     A.8.  Static Mappings with IP Prefixes  . . . . . . . . . . . .  86
     A.9.  Destination NAT . . . . . . . . . . . . . . . . . . . . .  86
     A.10. Customer-Side Translator (CLAT) . . . . . . . . . . . . .  89
     A.11. IPv6 Network Prefix Translation (NPTv6) . . . . . . . . .  90
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  93
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  94

1.  Introduction

   This document defines a data model for Network Address Translation
   (NAT) and Network Prefix Translation (NPT) capabilities using the
   YANG data modeling language [RFC7950].

   Traditional NAT is defined in [RFC2663], while Carrier Grade NAT
   (CGN) is defined in [RFC6888].  Unlike traditional NAT, the CGN is
   used to optimize the usage of global IP address space at the scale of
   a domain: a CGN is not managed by end users but by service providers
   instead.  This document covers both traditional NATs and CGNs.

   This document also covers NAT64 [RFC6146], customer-side translator
   (CLAT) [RFC6877], Stateless IP/ICMP Translation (SIIT) [RFC7915],
   Explicit Address Mappings (EAM) for SIIT [RFC7757], IPv6 Network
   Prefix Translation (NPTv6) [RFC6296], and Destination NAT.  The full
   set of translation schemes that are in scope is included in
   Section 2.2.

   Some 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 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 tuples, 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
      servers.

   o  Port-restricted IPv4 address: an IPv4 address with a restricted
      port set.  Multiple hosts may share the same IPv4 address;
      however, their port sets must not overlap [RFC7596].

   o  Restricted port set: a non-overlapping range of allowed external
      ports to use for NAT operation.  Source ports of IPv4 packets
      translated by a NAT must belong to the assigned port set.  The
      port set is used for all port-aware IP protocols [RFC7596].

   o  Internal host: a host that may need to use a translation
      capability to send to and receive traffic from the Internet.

   o  Internal address/prefix: the IP address/prefix of an internal
      host.

   o  External address: the IP address/prefix assigned by a translator
      to an internal host; this is the address that will be seen by a
      remote host on the Internet.

   o  Mapping: denotes a state at the translator that is necessary for
      network address and/or port translation.

   o  Dynamic implicit mapping: is created implicitly as a side effect
      of processing a packet (e.g., an initial TCP SYN packet) that
      requires a new mapping.  A validity lifetime is associated with
      this mapping.

   o  Dynamic explicit mapping: is created as a result of an explicit
      request, e.g., a Port Control Protocol (PCP) message [RFC6887].  A
      validity lifetime is associated with this mapping.

   o  Static explicit mapping: is created using, e.g., a command-line
      interface (CLI).  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.

   This document follows the guidelines of [RFC8407], 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
   [YANG-PCP].  Considerations about instructing by explicit dynamic
   means (e.g., [RFC6887], [RFC6736], or [RFC8045]) are out of scope.
   As a reminder, REQ-9 of [RFC6888] requires that a CGN must implement
   a protocol giving subscribers explicit control over NAT mappings;
   that protocol should be the Port Control Protocol [RFC6887].

   A single NAT device can have multiple NAT instances; each of these
   instances can be provided with its own policies (e.g., be responsible
   for serving a group of hosts).  This document does not make any
   assumption about how internal hosts or flows are associated with a
   given NAT instance.

   The NAT YANG module assumes that each NAT instance can be enabled/
   disabled, be provisioned with a specific set of configuration data,
   and maintain its own mapping tables.

   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 does not provide any method to instruct a NAT
   function to enable the logging feature or to specify the information
   to be logged for administrative or regulatory reasons (Section 2.3 of
   [RFC6908] and REQ-12 of [RFC6888]).  Those considerations 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
      [RFC7050])
   o  SIIT
   o  CLAT
   o  EAM
   o  NPTv6
   o  Combination of Basic NAT/NAPT and Destination NAT
   o  Combination of port-restricted and Destination NAT
   o  Combination of NAT64 and EAM
   o  Stateful and Stateless NAT64

   [RFC8513] specifies an extension to the NAT YANG module to support
   Dual-Stack Lite (DS-Lite).

   The YANG "feature" statement is used to indicate which of the
   different translation modes is relevant for a specific data node.
   Table 1 lists defined features:

            +---------------------------------+--------------+
            |                Translation Mode | YANG Feature |
            +---------------------------------+--------------+
            |                     Basic NAT44 | basic-nat44  |
            |                            NAPT | napt44       |
            |                 Destination NAT | dst-nat      |
            |                  Stateful NAT64 | nat64        |
            | Stateless IPv4/IPv6 Translation | siit         |
            |                            CLAT | clat         |
            |                             EAM | eam          |
            |                           NPTv6 | nptv6        |
            +---------------------------------+--------------+

                        Table 1: NAT YANG Features

   The following translation modes do not require that dedicated
   features be defined:

   o  Port-restricted NAT: This mode corresponds to supplying port-
      restriction policies to a NAPT or NAT64 (port-set-restrict).
   o  Combination of Basic NAT/NAPT and Destination NAT: This mode
      corresponds to setting 'dst-nat-enable' for Basic NAT44 or NAPT.

   o  Combination of port-restricted and Destination NAT: This mode can
      be achieved by configuring a NAPT with port restriction policies
      (port-set-restrict) together with a destination IP address pool
      (dst-ip-address-pool).
   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 provides a method to retrieve the capabilities of
   a NAT instance (including a list of supported translation modes, a
   list of supported protocols, the supported NAT mapping types, the
   supported NAT filtering types, the behavior for handling fragments
   (all, out-of-order, in-order), and the support statuses for the
   following: port restriction, port range allocation, port parity
   preservation, and port preservation).

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 protocols other than UDP, TCP,
   and ICMP.  Concretely, the module allows the operator to enable
   translation for other transport protocols when required
   (/nat/instances/instance/policy/transport-protocols).  Moreover, the
   mapping table is designed so that it can indicate any transport
   protocol.  For example, this module may be used to manage a NAT
   capable of the Datagram Congestion Control Protocol (DCCP) that
   adheres to [RFC5597].

   Future extensions may be needed to cover NAT-related considerations
   that are specific to other transport protocols such as the Stream
   Control Transmission Protocol (SCTP) [NAT-SUPP].  Typically, the
   mapping entry can be extended to record two optional SCTP-specific
   parameters: the Internal Verification Tag (Int-VTag) and External
   Verification Tag (Ext-VTag).

   This document only specifies transport-protocol-specific timers for
   UDP, TCP, and ICMP.  While some timers could potentially be
   generalized for other connection-oriented protocols, this document
   does not follow such an approach because there is no standard
   document specifying such generic behavior.  Future documents may be
   edited to clarify how to reuse TCP-specific timers when needed.

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
   function must be configurable with contiguous or non-contiguous
   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), 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 restrict the source port numbers (e.g., Lightweight 4over6
   [RFC7596] and Mapping of Address and Port with Encapsulation (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.