Difference between revisions of "VPP/NAT"
From fd.io
< VPP
(→Work list) |
(→API) |
||
| Line 132: | Line 132: | ||
== API == | == API == | ||
| + | define snat_add_static_mapping { | ||
| + | u32 client_index; | ||
| + | u32 context; | ||
| + | u8 is_add; | ||
| + | u8 is_ip4; | ||
| + | u8 addr_only; | ||
| + | u8 local_ip_address[16]; | ||
| + | u8 external_ip_address[16]; | ||
| + | u16 local_port; | ||
| + | u16 external_port; | ||
| + | }; | ||
== CLI == | == CLI == | ||
Revision as of 11:09, 27 September 2016
Contents
[hide]VPP NAT implementation
Introduction
The VPP SNAT is an implementation of NAT44. It is a plugin and is meant to replace the VCGN component. The target use case is a general IPv4 CPE NAT, a CGN and to act as a NAT44 in a Openstack deployment.
It is intended to be pluggable, in the sense that it should be possible to plug the NAT44 function together with the MAP-E IPv4 to IPv6 translator to create a MAP-E CE, likewise one can plug the NAT44 together with MAP-T to create a MAP-T CE or 464XLAT.
What are we building?
A general purpose stateful NAT44 that can be used as IPv4 CPE NAT, CGN or as an 1:1 NAT in a data centre environment.
It can also be combined with other features to build e.g. 464XLAT or a MAP-E CE.
Requirements
- Scale to millions of bindings
- Performance goal of 10Mpps/core.
- Configurable address and port selection algorithm.
- User quotas for sessions.
- Thread safe
- Efficient port utilisation. Endpoint independent for applications requiring it, address and port filtering otherwise
- No ALGs
- Configurable IP address pooling behavour
- Plugable with MAP-E/T to create MAP-E/T CE, 464XLAT
- Stateful NAT64
- Support for NAT on a stick (single inside / outside interface)
Work list
| Task | Owner | Priority | Status | Description |
|---|---|---|---|---|
| 1:1 NAT | Matus | 0 | Committed | VPP-339 |
| 1:1 NAT with ports | Matus | 0 | Committed | VPP-339 |
| 1:1 NAT with disabled dynamic translation | Matus | 0 | Committed | VPP-339 add "static mapping only [connection tracking]" to snat startup config. |
| VRF awareness | Matus | 0 | Committed | One tenant == One VRF. One VRF == multiple interfaces / multiple subnets, add vrf to static mapping API/CLI. |
| 1:1 NAT delete and dump API | Matus | 0 | WIP | |
| Multiple inside interface - Multiple subnets | 0 | Multiple inside interfaces for the same "tenant" with non-overlapping address space. | ||
| Inside overlapping interfaces | 0 | Tenants on separate interfaces, separate VRFs with overlapping address space. | ||
| Thread safe | 0 | |||
| Hairpinning | 1 | Hosts communicating behind the same NAT using the external representation of their address. | ||
| Logging | 1 | Netflow - IPFix | ||
| API (Java and Python) | ||||
| Input ACL support before NAT | ||||
| Multiple outside interfaces | ||||
| ICMP error packet translation | ||||
| DS-lite | ||||
| NAT64 |
API
define snat_add_static_mapping {
u32 client_index;
u32 context;
u8 is_add;
u8 is_ip4;
u8 addr_only;
u8 local_ip_address[16];
u8 external_ip_address[16];
u16 local_port;
u16 external_port;
};
CLI
YANG model
References
- RFC2663 - NAT terminology and considerations
- RFC4787 - NAT requirements for UDP
- RFC5382 - NAT requirements for TCP
- RFC5508 - NAT requirements for ICMP
- RFC6888 - CGN requirements - qualify and plan dev sequence:
- RFC7422 - Deterministic address mapping
- draft-ietf-behave-ipfix-nat-logging - IPFIX Information Elements for logging NAT Events
