Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8512

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

Pages: 94
Proposed Standard
Part 1 of 8 – Pages 1 to 10
None   None   Next

Top   ToC   RFC8512 - Page 1
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.
Top   ToC   RFC8512 - Page 2
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.
Top   ToC   RFC8512 - Page 3

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
Top   ToC   RFC8512 - Page 4

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].
Top   ToC   RFC8512 - Page 5
   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].
Top   ToC   RFC8512 - Page 6

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.
Top   ToC   RFC8512 - Page 7

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.
Top   ToC   RFC8512 - Page 8
   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).
Top   ToC   RFC8512 - Page 9
   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].
Top   ToC   RFC8512 - Page 10
   o  Algorithmic: an algorithm is defined in [RFC7597] to characterize
      the set of ports that can be used.



(page 10 continued on part 2)

Next Section