Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8512

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

Pages: 94
Proposed Standard
Part 8 of 8 – Pages 80 to 94
First   Prev   None

Top   ToC   RFC8512 - Page 80   prevText

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>
Top   ToC   RFC8512 - Page 81
   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]).
Top   ToC   RFC8512 - Page 82
   <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>
Top   ToC   RFC8512 - Page 83
   <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>
Top   ToC   RFC8512 - Page 84
   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>
Top   ToC   RFC8512 - Page 85

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

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>
Top   ToC   RFC8512 - Page 87
   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>
Top   ToC   RFC8512 - Page 88
   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>
Top   ToC   RFC8512 - Page 89
   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>
Top   ToC   RFC8512 - Page 90

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>
Top   ToC   RFC8512 - Page 91
   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
Top   ToC   RFC8512 - Page 92
   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>
Top   ToC   RFC8512 - Page 93

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

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