A.3.  CGN Pass-Through

   Figure 1 illustrates an example of the CGN pass-through feature.

                     X1:x1            X1':x1'            X2:x2
                     +---+from X1:x1  +---+from X1:x1    +---+
                     | C |  to X2:x2  |   |  to X2:x2    | S |
                     | l |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e |
                     | i |            | G |              | r |
                     | e |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v |
                     | n |from X2:x2  |   |from X2:x2    | e |
                     | t |  to X1:x1  |   |  to X1:x1    | r |
                     +---+            +---+              +---+

                        Figure 1: CGN Pass-Through

   For example, in order to disable NAT for communications issued by the
   client (192.0.2.1), the following configuration parameter must be
   set:

   <nat-pass-through>
     ...
     <prefix>192.0.2.1/32</prefix>
     ...
   </nat-pass-through>

A.4.  NAT64

   Let's consider the example of a NAT64 that should use
   2001:db8:122:300::/56 to perform IPv6 address synthesis [RFC6052].
   The XML snippet to configure the NAT64 prefix in such case is
   depicted below:

   <nat64-prefixes>
     <nat64-prefix>
       2001:db8:122:300::/56
     </nat64-prefix>
   </nat64-prefixes>

   Let's now consider the example of a NAT64 that should use
   2001:db8:122::/48 to perform IPv6 address synthesis [RFC6052] only if
   the destination address matches 198.51.100.0/24.  The XML snippet to
   configure the NAT64 prefix in such case is shown below:

   <nat64-prefixes>
     <nat64-prefix>
       2001:db8:122::/48
     </nat64-prefix>
     <destination-ipv4-prefix>
       <ipv4-prefix>
         198.51.100.0/24
       </ipv4-prefix>
     </destination-ipv4-prefix>
   </nat64-prefixes>

A.5.  Stateless IP/ICMP Translation (SIIT)

   Let's consider the example of a stateless translator that is
   configured with 2001:db8:100::/40 to perform IPv6 address synthesis
   [RFC6052].  Similar to the NAT64 case, the XML snippet to configure
   the NAT64 prefix in such case is depicted below:

   <nat64-prefixes>
     <nat64-prefix>
       2001:db8:100::/40
     </nat64-prefix>
   </nat64-prefixes>

   When the translator receives an IPv6 packet, for example, with a
   source address (2001:db8:1c0:2:21::) and destination address
   (2001:db8:1c6:3364:2::), it extracts embedded IPv4 addresses
   following rules per RFC 6052 with 2001:db8:100::/40 as the NSP:

   o  192.0.2.33 is extracted from 2001:db8:1c0:2:21::

   o  198.51.100.2 is extracted from 2001:db8:1c6:3364:2::

   The translator transforms the IPv6 header into an IPv4 header using
   the IP/ICMP Translation Algorithm [RFC7915].  The IPv4 packets will
   include 192.0.2.33 as the source address and 198.51.100.2 as the
   destination address.

   Also, a NAT64 can be instructed to behave in the stateless mode by
   providing the following configuration.  The same NAT64 prefix is used
   for constructing both IPv4-translatable IPv6 addresses and
   IPv4-converted IPv6 addresses (see Section 3.3 of [RFC6052]).

   <nat64-prefixes>
     <nat64-prefix>
       2001:db8:122:300::/56
     </nat64-prefix>
     <stateless-enable>
       true
     </stateless-enable>
   </nat64-prefixes>

A.6.  Explicit Address Mappings (EAM) for Stateless IP/ICMP Translation
      (SIIT)

   As specified in [RFC7757], an EAM consists of an IPv4 prefix and an
   IPv6 prefix.  Let's consider the set of EAM examples in Table 8.

                  +----------------+----------------------+
                  |  IPv4 Prefix   |     IPv6 Prefix      |
                  +----------------+----------------------+
                  | 192.0.2.1      | 2001:db8:aaaa::      |
                  | 192.0.2.2/32   | 2001:db8:bbbb::b/128 |
                  | 192.0.2.16/28  | 2001:db8:cccc::/124  |
                  | 192.0.2.128/26 | 2001:db8:dddd::/64   |
                  | 192.0.2.192/29 | 2001:db8:eeee:8::/62 |
                  | 192.0.2.224/31 | 64:ff9b::/127        |
                  +----------------+----------------------+

                        Table 8: EAM Examples (RFC 7757)

   The following XML excerpt illustrates how these EAMs can be
   configured using the NAT YANG module:

   <eam>
     <ipv4-prefix>
       192.0.2.1/32
     </ipv4-prefix>
     <ipv6-prefix>
       2001:db8:aaaa::/128
     </ipv6-prefix>
   </eam>
   <eam>
     <ipv4-prefix>
       192.0.2.2/32
     </ipv4-prefix>
     <ipv6-prefix>
       2001:db8:bbbb::b/128
     </ipv6-prefix>
   </eam>

   <eam>
     <ipv4-prefix>
       192.0.2.16/28
     </ipv4-prefix>
     <ipv6-prefix>
       2001:db8:cccc::/124
     </ipv6-prefix>
   </eam>
   <eam>
     <ipv4-prefix>
       192.0.2.128/26
     </ipv4-prefix>
     <ipv6-prefix>
       2001:db8:dddd::/64
     </ipv6-prefix>
   </eam>
   <eam>
     <ipv4-prefix>
       192.0.2.192/29
     </ipv4-prefix>
     <ipv6-prefix>
       2001:db8:eeee:8::/62
     </ipv6-prefix>
   </eam>
   <eam>
     <ipv4-prefix>
       192.0.2.224/31
     </ipv4-prefix>
     <ipv6-prefix>
       64:ff9b::/127
     </ipv6-prefix>
   </eam>

   EAMs may be enabled jointly with stateful NAT64.  This example shows
   a NAT64 function that supports static mappings:

   <capabilities>
     <nat-flavor>
       nat64
     </nat-flavor>
     <static-mapping-support>
       true
     </static-mapping-support>
     <port-randomization-support>
       true
     </port-randomization-support>
     <port-range-allocation-support>
       true
     </port-range-allocation-support>
     <port-preservation-suport>
       true
     </port-preservation-suport>
     <address-roundrobin-support>
       true
     </address-roundrobin-support>
     <paired-address-pooling-support>
       true
     </paired-address-pooling-support>
     <endpoint-independent-mapping-support>
       true
     </endpoint-independent-mapping-support>
     <endpoint-independent-filtering-support>
       true
     </endpoint-independent-filtering-support>
   </capabilities>

A.7.  Static Mappings with Port Ranges

   The following example shows a static mapping that instructs a NAT to
   translate packets issued from 192.0.2.1 and with source ports in the
   100-500 range to 198.51.100.1:1100-1500.

   <mapping-entry>
     <index>1</index>
     <type>
       static
     </type>
     <transport-protocol>
       6
     </transport-protocol>
     <internal-src-address>
       192.0.2.1/32
     </internal-src-address>
     <internal-src-port>
       <start-port-number>
         100
       </start-port-number>
       <end-port-number>
         500
       </end-port-number>
     </internal-src-port>
     <external-src-address>
       198.51.100.1/32
     </external-src-address>
     <external-src-port>
       <start-port-number>
         1100
       </start-port-number>
       <end-port-number>
         1500
       </end-port-number>
     </external-src-port>
     ...
   </mapping-entry>

A.8.  Static Mappings with IP Prefixes

   The following example shows a static mapping that instructs a NAT to
   translate TCP packets issued from 192.0.2.0/24 to 198.51.100.0/24.

   <mapping-entry>
     <index>1</index>
     <type>
       static
     </type>
     <transport-protocol>
       6
     </transport-protocol>
     <internal-src-address>
       192.0.2.0/24
     </internal-src-address>
     <external-src-address>
       198.51.100.0/24
     </external-src-address>
     ...
   </mapping-entry>

A.9.  Destination NAT

   The following XML snippet shows an example of a Destination NAT that
   is instructed to translate all packets having 192.0.2.1 as a
   destination IP address to 198.51.100.1.

   <dst-ip-address-pool>
     <pool-id>1</pool-id>
     <dst-in-ip-pool>
       192.0.2.1/32
     </dst-in-ip-pool>
     <dst-out-ip-pool>
       198.51.100.1/32
     </dst-out-ip-pool>
   </dst-ip-address-pool>

   In order to instruct a NAT to translate TCP packets destined to
   '192.0.2.1:80' to '198.51.100.1:8080', the following XML snippet
   shows the static mapping configured on the NAT:

   <mapping-entry>
     <index>1568</index>
     <type>
       static
     </type>
     <transport-protocol>
       6
     </transport-protocol>
     <internal-dst-address>
       192.0.2.1/32
     </internal-dst-address>
     <internal-dst-port>
       <start-port-number>
         80
       </start-port-number>
     </internal-dst-port>
     <external-dst-address>
       198.51.100.1/32
     </external-dst-address>
     <external-dst-port>
       <start-port-number>
         8080
       </start-port-number>
     </external-dst-port>
   </mapping-entry>

   In order to instruct a NAT to translate TCP packets destined to
   '192.0.2.1:80' (HTTP traffic) to 198.51.100.1 and '192.0.2.1:22' (SSH
   traffic) to 198.51.100.2, the following XML snippet shows the static
   mappings configured on the NAT:

   <mapping-entry>
     <index>123</index>
     <type>
       static
     </type>
     <transport-protocol>
       6
     </transport-protocol>
     <internal-dst-address>
       192.0.2.1/32
     </internal-dst-address>
     <internal-dst-port>
       <start-port-number>
         80
       </start-port-number>
     </internal-dst-port>
     <external-dst-address>
       198.51.100.1/32
     </external-dst-address>
     ...
   </mapping-entry>
   <mapping-entry>
     <index>1236</index>
     <type>
       static
     </type>
     <transport-protocol>
        6
     </transport-protocol>
     <internal-dst-address>
       192.0.2.1/32
     </internal-dst-address>
     <internal-dst-port>
       <start-port-number>
         22
       </start-port-number>
     </internal-dst-port>
     <external-dst-address>
       198.51.100.2/32
     </external-dst-address>
     ...
   </mapping-entry>

   The NAT may also be instructed to proceed with both source and
   Destination NAT.  To do so, in addition to the above example to
   configure Destination NAT, the NAT may be provided, for example with
   a pool of external IP addresses (198.51.100.0/24) to use for source
   address translation.  An example of the corresponding XML snippet is
   provided hereafter:

   <external-ip-address-pool>
     <pool-id>1</pool-id>
     <external-ip-pool>
       198.51.100.0/24
     </external-ip-pool>
   </external-ip-address-pool>

   Instead of providing an external IP address to share, the NAT may be
   configured with static mapping entries that modify the internal IP
   address and/or port number.

A.10.  Customer-Side Translator (CLAT)

   The following XML snippet shows the example of a CLAT that is
   configured with 2001:db8:1234::/96 as a PLAT-side IPv6 prefix and
   2001:db8:aaaa::/96 as a CLAT-side IPv6 prefix.  The CLAT is also
   provided with 192.0.0.1/32 (which is selected from the IPv4 service
   continuity prefix defined in [RFC7335]).

   <clat-ipv6-prefixes>
     <ipv6-prefix>
       2001:db8:aaaa::/96
     </ipv6-prefix>
   </clat-ipv6-prefixes>
   <clat-ipv4-prefixes>
     <ipv4-prefix>
       192.0.0.1/32
     </ipv4-prefix>
   </clat-ipv4-prefixes>
   <nat64-prefixes>
     <nat64-prefix>
       2001:db8:1234::/96
     </nat64-prefix>
   </nat64-prefixes>

A.11.  IPv6 Network Prefix Translation (NPTv6)

   Let's consider the example of an NPTv6 translator that should rewrite
   packets with the source prefix (fd03:c03a:ecab::/48) with the
   external prefix (2001:db8:1::/48).  The internal interface is "eth0"
   while the external interface is "eth1" (Figure 2).

                  External Network:  Prefix = 2001:db8:1::/48
                      --------------------------------------
                                        |
                                        |eth1
                                 +-------------+
                             eth4|     NPTv6   |eth2
                         ...-----|             |------...
                                 +-------------+
                                        |eth0
                                        |
                      --------------------------------------
                  Internal Network:  Prefix = fd03:c03a:ecab::/48

                        Figure 2: Example of NPTv6

   The XML snippet to configure NPTv6 prefixes in such case is depicted
   below:

   <nptv6-prefixes>
     <internal-ipv6-prefix>
       fd03:c03a:ecab::/48
     </internal-ipv6-prefix>
     <external-ipv6-prefix>
       2001:db8:1::/48
     </external-ipv6-prefix>
   </nptv6-prefixes>
   ...
   <external-realm>
     <external-interface>
       eth1
     </external-interface>
   </external-realm>

   Figure 3 shows an example of an NPTv6 translator that interconnects
   two internal networks (fd03:c03a:ecab::/48 and fda8:d5cb:14f3::/48);
   each is translated using a dedicated prefix (2001:db8:1::/48 and
   2001:db8:6666::/48, respectively).

                     Internal Prefix = fda8:d5cb:14f3::/48
                     --------------------------------------
                          V            |      External Prefix
                          V            |eth1   2001:db8:1::/48
                          V        +---------+      ^
                          V        |  NPTv6  |      ^
                          V        |         |      ^
                          V        +---------+      ^
                 External Prefix       |eth0        ^
                 2001:db8:6666::/48    |            ^
                     --------------------------------------
                     Internal Prefix = fd03:c03a:ecab::/48

                  Figure 3: Connecting Two Peer Networks

   To that aim, the following configuration is provided to the NPTv6
   translator:

   <policy>
     <id>1</id>
     <nptv6-prefixes>
       <internal-ipv6-prefix>
         fd03:c03a:ecab::/48
       </internal-ipv6-prefix>
       <external-ipv6-prefix>
         2001:db8:1::/48
       </external-ipv6-prefix>
     </nptv6-prefixes>
     <external-realm>
       <external-interface>
         eth1
       </external-interface>
     </external-realm>
   </policy>
   <policy>
     <id>2</id>
     <nptv6-prefixes>
       <internal-ipv6-prefix>
         fda8:d5cb:14f3::/48
       </internal-ipv6-prefix>
       <external-ipv6-prefix>
         2001:db8:6666::/48
       </external-ipv6-prefix>
     </nptv6-prefixes>
     <external-realm>
       <external-interface>
         eth0
       </external-interface>
     </external-realm>
   </policy>

Acknowledgements

   Many thanks to Dan Wing, Tianran Zhou, Tom Petch, Warren Kumari, and
   Benjamin Kaduk for their 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 the EAM SIIT review,
   and Kristian Poscic for the CGN review.

   Special thanks to Maros Marsalek and Marek Gradzki for sharing their
   comments based on the FD.io implementation of this module
   (https://git.fd.io/hc2vpp/tree/nat/nat-api/src/main/yang).

   Rajiv Asati suggested clarifying how the module applies for both
   stateless and stateful NAT64.

   Juergen Schoenwaelder provided an early YANG Doctors review.  Many
   thanks to him.

   Thanks to Roni Even, Mach(Guoyi) Chen, Tim Chown, and Stephen Farrell
   for the directorates review.  Igor Ryzhov identified a nit in one
   example.

   Mirja Kuehlewind made a comment about the reuse of some TCP timers
   for any connection-oriented protocol.

Authors' Addresses

   Mohamed Boucadair (editor)
   Orange
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com


   Senthil Sivakumar
   Cisco Systems
   7100-8 Kit Creek Road
   Research Triangle Park, North Carolina  27709
   United States of America

   Phone: +1 919 392 5158
   Email: ssenthil@cisco.com


   Christian Jacquenet
   Orange
   Rennes  35000
   France

   Email: christian.jacquenet@orange.com


   Suresh Vinapamula
   Juniper Networks
   1133 Innovation Way
   Sunnyvale  94089
   United States of America

   Email: sureshk@juniper.net


   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com