Pros and Cons of IPv6 Transition Technologies for IPv4aaS
draft-lmhp-v6ops-transition-comparison-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Gábor Lencse , Jordi Palet Martinez , Lee Howard , Richard Patterson | ||
| Last updated | 2018-10-06 | ||
| Replaced by | draft-ietf-v6ops-transition-comparison, RFC 9313 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lmhp-v6ops-transition-comparison-00
IPv6 Operations Working Group G. Lencse
Internet Draft BUTE
Intended status: Informational J. Palet Martinez
Expires: April 2018 The IPv6 Company
L. Howard
Retevia
R. Patterson
Sky UK
October 6, 2018
Pros and Cons of IPv6 Transition Technologies for IPv4aaS
draft-lmhp-v6ops-transition-comparison-00.txt
Abstract
Several IPv6 transition technologies can be used to provide IPv4-as-
a-service (IPv4aaS) to the customers, while the ISPs have only IPv6
in their access and or core network. All these technologies have
their advantages and disadvantages. Depending on several various
conditions and preferences, different technologies may prove to be
the most appropriate solution. This document examines the five most
prominent IPv4aaS technologies considering several different aspects
in order to provide network operators with an easy to use guideline
for selecting the technology that suit their needs the best.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Lencse et al. Expires April 6, 2019 [Page 1]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
This Internet-Draft will expire on April 6, 2019.
Copyright Notice
Copyright (c) 2018 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
(http://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 ................................................ 3
2. High-level Architectures and their Consequences ............. 3
2.1. Service Provider Network Traversal ..................... 3
2.2. IPv4 Address Sharing ................................... 4
3. More Detailed Analysis ...................................... 4
3.1. Details of Architectural Differences ................... 4
3.1.1. 464XLAT ........................................... 4
3.1.2. DS-Lite ........................................... 4
3.1.3. Lw4o6 ............................................. 4
3.1.4. MAP-E ............................................. 5
3.1.5. MAP-T ............................................. 5
3.2. Tradeoff between Port Number Efficiency and Stateless
Operation .............................................. 5
3.3. Support for Server Operation ........................... 6
3.4. Support and Implementations ............................ 6
3.4.1. OS Support......................................... 6
3.4.2. Support in Cellular and Broadband Networks......... 6
3.4.3. Implementation Code Sizes ......................... 6
4. Performance Comparison ...................................... 7
5. Security Considerations ..................................... 7
6. IANA Considerations ........................................ 8
7. Conclusions ................................................. 8
8. References .................................................. 8
8.1. Normative References ................................... 8
8.2. Informative References ................................. 9
9. Acknowledgments ............................................ 10
Lencse et al. Expires April 6, 2019 [Page 2]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
1. Introduction
IETF has standardized a high number of IPv6 transition technologies
[Len2017] and occupied a neutral position trusting the selection to
the market. In the upcoming years, several network operators would
like to get rid of the burden of maintaining IPv4 in their access
and/or core networks. This document deals with five different
solutions, each of which can be used to provide an IPv4 service
using an IPv6-only access/core network. The following IPv6
transition technologies are covered: 464XLAT [RFC6877], DS-Lite
(Dual Stack Lite) [RFC6333], lw4o6 (Lightweight 4over6) [RFC7596],
MAP-E [RFC7597] and MAP-T [RFC7599].
2. High-level Architectures and their Consequences
2.1. Service Provider Network Traversal
As for the high-level solution of the IPv6 service provider network
traversal, MAP-T use double translation (first at the CE from IPv4
to IPv6, NAT46, and then from IPv6 to IPv4, NAT64, at the service
provider network), 464XLAT may use single (NAT64, IPv6 to IPv4) or
double translation (as MAP-T), depending on different factors, such
as the use of DNS by the applications and the availability of a
DNS64. DS-Lite, lw4o6 and MAP-E encapsulate the IPv4 packets into
IPv6 packets. Each solution has its own advantages and drawbacks.
Double translation results in only 20 bytes overhead (the difference
in the minimum header size between IPv4 and IPv6), whereas the
overhead of the encapsulation is 40 bytes (because both, the IPv4
and IPv6 headers are needed, compared with only the IPv4 one). The
difference may be significant in the case of small packet sizes or
when the larger one results in fragmentation.
On the one hand, the first step of the double translation case is a
stateless NAT from IPv4 to IPv6 implemented as SIIT (Stateless
IP/ICMP Translation Algorithm) [RFC7915], which does not translate
IPv4 options and/or multicast IP/ICMP packets, whereas with
encapsulation-based technologies these remain intact.
On the other hand, single and double translation results in "normal"
IPv6 traffic which can be inspected, e.g., by hashing algorithms,
and firewalls, whereas encapsulation results in IPv4-embedded IPv6
packets and their interpretation requires special software/hardware
for DPI (deep-packet-inspection).
The worst case is DS-Lite, which is also doing double stateful
translation (NAT44 at the CE, NAT44 at the AFTR).
Lencse et al. Expires April 6, 2019 [Page 3]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
Another consequence is that the solutions using double translation
can carry only TCP, UDP or ICMP over IP, when they are used with
IPv4 address sharing (please refer to section 3.3 for more details),
whereas the solutions using encapsulation can carry any other
protocols over IP, too.
2.2. IPv4 Address Sharing
All five technologies support IPv4 address sharing, which has severe
consequences described in [RFC6269].
The efficiency of the address sharing of the five technologies is
significantly different, it is discussed in section 3.2.
We note that lw4o6, MAP-E and MAP-T may not necessarily be
configured to do IPv4 address sharing, see the details in Section
3.3, however in that case there is no advantage in terms of public
IPv4 addresses saving.
3. More Detailed Analysis
3.1. Details of Architectural Differences
3.1.1. 464XLAT
CLAT performs a stateless translation from IPv4 to IPv6 [RFC7915].
It uses IPv4-embedded IPv6 addresses [RFC6052] for both source
address and destination address. PLAT performs stateful NAT64
[RFC6146].
3.1.2. DS-Lite
The B4 (Basic Bridging BroadBand) element encapsulates the IPv4
packets into IPv6 packets. The AFTR (Address Family Transition
Router) de-encapsulates the IPv4 packets from the IPv6 packets and
performs stateful NAPT (Network Address and Port Translation).
3.1.3. Lw4o6
Lightweight 4over6 is a variant of DS-Lite. The difference is, that
the stateful NAPT is moved from the AFTR to the B4 element. It uses
a provisioning mechanism to determine the size of the limited port
set per user.
Lencse et al. Expires April 6, 2019 [Page 4]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
Internet-Draft YANG Module for NAT September 2018
will stay active without packets traversing the NAT.";
reference
"RFC 4787: Network Address Translation (NAT)
Behavioral Requirements for Unicast UDP";
}
leaf tcp-idle-timeout {
type uint32;
units "seconds";
default 7440;
description
"TCP Idle timeout should be 2 hours and 4 minutes.";
reference
"RFC 5382: NAT Behavioral Requirements for TCP";
}
leaf tcp-trans-open-timeout {
type uint32;
units "seconds";
default 240;
description
"The value of the transitory open connection
idle-timeout.
A NAT should provide different configurable
parameters for configuring the open and
closing idle timeouts.
To accommodate deployments that consider
a partially open timeout of 4 minutes as being
excessive from a security standpoint, a NAT may
allow the configured timeout to be less than
4 minutes.
However, a minimum default transitory connection
idle-timeout of 4 minutes is recommended.";
reference
"Section 2.1 of RFC 7857.";
}
leaf tcp-trans-close-timeout {
type uint32;
units "seconds";
default 240;
description
"The value of the transitory close connection
idle-timeout.
Boucadair, et al. Expires March 31, 2019 [Page 53]
Internet-Draft YANG Module for NAT September 2018
A NAT should provide different configurable
parameters for configuring the open and
closing idle timeouts.";
reference
"Section 2.1 of RFC 7857.";
}
leaf tcp-in-syn-timeout {
type uint32;
units "seconds";
default 6;
description
"A NAT must not respond to an unsolicited
inbound SYN packet for at least 6 seconds
after the packet is received. If during
this interval the NAT receives and translates
an outbound SYN for the connection the NAT
must silently drop the original unsolicited
inbound SYN packet.";
reference
"RFC 5382 NAT Behavioral Requirements for TCP";
}
leaf fragment-min-timeout {
when "../../fragment-behavior='out-of-order'";
type uint32;
units "seconds";
default 2;
description
"As long as the NAT has available resources,
the NAT allows the fragments to arrive
over fragment-min-timeout interval.
The default value is inspired from RFC6146.";
}
leaf icmp-timeout {
type uint32;
units "seconds";
default 60;
description
"An ICMP Query session timer must not expire
in less than 60 seconds. It is recommended
that the ICMP Query session timer be made
configurable";
reference
"RFC 5508: NAT Behavioral Requirements for ICMP";
}
Boucadair, et al. Expires March 31, 2019 [Page 54]
Internet-Draft YANG Module for NAT September 2018
list per-port-timeout {
key port-number;
description
"Some NATs are configurable with short timeouts
for some ports, e.g., as 10 seconds on
port 53 (DNS) and 123 (NTP) and longer timeouts
on other ports.";
leaf port-number {
type inet:port-number;
description
"A port number.";
}
leaf protocol {
type uint8;
description
"Upper-layer protocol associated with this port.
Values are taken from the IANA protocol registry.
If no protocol is indicated, this means 'any
protocol'.";
}
leaf timeout {
type uint32;
units "seconds";
mandatory true;
description
"Timeout for this port number";
}
}
leaf hold-down-timeout {
type uint32;
units "seconds";
default 120;
description
"Hold down timer.
Ports in the hold down pool are not reassigned until
hold-down-timeout expires.
The length of time and the maximum number of ports in
this state must be configurable by the administrator.
This is necessary in order to prevent collisions
Boucadair, et al. Expires March 31, 2019 [Page 55]
Internet-Draft YANG Module for NAT September 2018
between old and new mappings and sessions. It ensures
that all established sessions are broken instead of
redirected to a different peer.";
reference
"REQ#8 of RFC 6888.";
}
leaf hold-down-max {
type uint32;
description
"Maximum ports in the hold down port pool.";
reference
"REQ#8 of RFC 6888.";
}
}
leaf fragments-limit{
when "../fragment-behavior='out-of-order'";
type uint32;
description
"Limits the number of out of order fragments that can
be handled.";
reference
"Section 11 of RFC 4787.";
}
list algs {
key name;
description
"ALG-related features.";
leaf name {
type string;
description
"The name of the ALG.";
}
leaf transport-protocol {
type uint32;
description
"The transport protocol used by the ALG
(e.g., TCP, UDP).";
}
container dst-transport-port {
uses port-number;
description
"The destination port number(s) used by the ALG.
Boucadair, et al. Expires March 31, 2019 [Page 56]
Internet-Draft YANG Module for NAT September 2018
For example,
- 21 for the FTP ALG
- 53 for the DNS ALG.";
}
container src-transport-port {
uses port-number;
description
"The source port number(s) used by the ALG.";
}
leaf status {
type boolean;
description
"Enable/disable the ALG.";
}
}
leaf all-algs-enable {
type boolean;
description
"Disable/enable all ALGs.
When specified, this parameter overrides the one
that may be indicated, eventually, by the 'status'
of an individual ALG.";
}
container notify-pool-usage {
if-feature "basic-nat44 or napt44 or nat64";
description
"Notification of pool usage when certain criteria
are met.";
leaf pool-id {
type uint32;
description
"Pool-ID for which the notification criteria
is defined";
}
leaf low-threshold {
type percent;
description
"Notification must be generated when the defined low
threshold is reached.
For example, if a notification is required when the
Boucadair, et al. Expires March 31, 2019 [Page 57]
Internet-Draft YANG Module for NAT September 2018
pool utilization reaches below 10%, this
configuration parameter must be set to 10.
0% indicates that low-threshold notification is
disabled.";
}
leaf high-threshold {
type percent;
must ". >= ../low-threshold" {
error-message
"The high threshold must be greater than or equal
to the low threshold.";
}
description
"Notification must be generated when the defined high
threshold is reached.
For example, if a notification is required when the
pool utilization reaches 90%, this configuration
parameter must be set to 90.
Setting the same value as low-threshold is equivalent
to disabling high-threshold notification.";
}
leaf notify-interval {
type uint32 {
range "1 .. 3600";
}
units "seconds";
default '20';
description
"Minimum number of seconds between successive
notifications for this pool.";
reference
"RFC 7659: Definitions of Managed Objects for
Network Address Translators (NATs)";
}
}
container external-realm {
description
"Identifies the external realm of the NAT instance.";
choice realm-type {
description
Boucadair, et al. Expires March 31, 2019 [Page 58]
Internet-Draft YANG Module for NAT September 2018
"Can be an interface, VRF instance, etc.";
case interface {
description
"External interface.";
leaf external-interface {
type if:interface-ref;
description
"Name of the external interface.";
}
}
}
}
}
container mapping-limits {
if-feature "napt44 or nat64";
description
"Information about the configuration parameters that
limits the mappings based upon various criteria.";
leaf limit-subscribers {
type uint32;
description
"Maximum number of subscribers that can be serviced
by a NAT instance.
A subscriber is identified by a given prefix.";
reference
"RFC 7659: Definitions of Managed Objects for
Network Address Translators (NATs)";
}
leaf limit-address-mappings {
type uint32;
description
"Maximum number of address mappings that can be
handled by a NAT instance.
When this limit is reached, packets that would
normally trigger translation, will be dropped.";
reference
"RFC 7659: Definitions of Managed Objects
for Network Address Translators
(NATs)";
}
Boucadair, et al. Expires March 31, 2019 [Page 59]
Internet-Draft YANG Module for NAT September 2018
leaf limit-port-mappings {
type uint32;
description
"Maximum number of port mappings that can be handled
by a NAT instance.
When this limit is reached, packets that would
normally trigger translation, will be dropped.";
reference
"RFC 7659: Definitions of Managed Objects for
Network Address Translators (NATs)";
}
list limit-per-protocol {
if-feature "napt44 or nat64 or dst-nat";
key protocol-id;
description
"Configure limits per transport protocol";
leaf protocol-id {
type uint8;
mandatory true;
description
"Upper-layer protocol.
Values are taken from the IANA protocol registry.
For example, this field contains 6 for TCP,
17 for UDP, 33 for DCCP, or 132 for SCTP.";
}
leaf limit {
type uint32;
description
"Maximum number of protocol-specific NAT mappings
per instance.";
}
}
}
container connection-limits {
if-feature "basic-nat44 or napt44 or nat64";
description
"Information about the configuration parameters that
rate limit the translation based upon various criteria.";
leaf limit-per-subscriber {
Boucadair, et al. Expires March 31, 2019 [Page 60]
Internet-Draft YANG Module for NAT September 2018
type uint32;
units "bits/second";
description
"Rate-limit the number of new mappings and sessions
per subscriber.";
}
leaf limit-per-instance {
type uint32;
units "bits/second";
description
"Rate-limit the number of new mappings and sessions
per instance.";
}
list limit-per-protocol {
if-feature "napt44 or nat64";
key protocol-id;
description
"Configure limits per transport protocol";
leaf protocol-id {
type uint8;
mandatory true;
description
"Upper-layer protocol.
Values are taken from the IANA protocol registry.
For example, this field contains 6 for TCP,
17 for UDP, 33 for DCCP, or 132 for SCTP.";
}
leaf limit {
type uint32;
description
"Limit the number of protocol-specific mappings
and sessions per instance.";
}
}
}
container notification-limits {
description "Sets notification limits.";
leaf notify-interval {
if-feature "basic-nat44 or napt44 or nat64";
type uint32 {
Boucadair, et al. Expires March 31, 2019 [Page 61]
Internet-Draft YANG Module for NAT September 2018
range "1 .. 3600";
}
units "seconds";
default '10';
description
"Minimum number of seconds between successive
notifications for this NAT instance.";
reference
"RFC 7659: Definitions of Managed Objects
for Network Address Translators (NATs)";
}
leaf notify-addresses-usage {
if-feature "basic-nat44 or napt44 or nat64";
type percent;
description
"Notification of address mappings usage over
the whole NAT instance.
Notification must be generated when the defined
threshold is reached.
For example, if a notification is required when
the address mappings utilization reaches 90%,
this configuration parameter must be set
to 90.";
}
leaf notify-ports-usage {
if-feature "napt44 or nat64";
type percent;
description
"Notification of port mappings usage over the
whole NAT instance.
Notification must be generated when the defined
threshold is reached.
For example, if a notification is required when
the port mappings utilization reaches 90%, this
configuration parameter must be set to 90.";
}
leaf notify-subscribers-limit {
if-feature "basic-nat44 or napt44 or nat64";
type uint32;
description
"Notification of active subscribers per NAT
Boucadair, et al. Expires March 31, 2019 [Page 62]
Internet-Draft YANG Module for NAT September 2018
instance.
Notification must be generated when the defined
threshold is reached.";
}
}
container mapping-table {
if-feature "basic-nat44 or napt44 " +
"or nat64 or clat or dst-nat";
description
"NAT mapping table. Applicable for functions which maintain
static and/or dynamic mappings, such as NAT44, Destination
NAT, NAT64, or CLAT.";
list mapping-entry {
key "index";
description "NAT mapping entry.";
uses mapping-entry;
}
}
container statistics {
config false;
description
"Statistics related to the NAT instance.";
leaf discontinuity-time {
type yang:date-and-time;
mandatory true;
description
"The time on the most recent occasion at which the NAT
instance suffered a discontinuity. This must be
initialized when the NAT instance is configured
or rebooted.";
}
container traffic-statistics {
description
"Generic traffic statistics.";
leaf sent-packets {
type yang:zero-based-counter64;
description
"Number of packets sent.";
}
Boucadair, et al. Expires March 31, 2019 [Page 63]
Internet-Draft YANG Module for NAT September 2018
leaf sent-bytes {
type yang:zero-based-counter64;
units 'bytes';
description
"Counter for sent traffic in bytes.";
}
leaf rcvd-packets {
type yang:zero-based-counter64;
description
"Number of received packets.";
}
leaf rcvd-bytes {
type yang:zero-based-counter64;
units 'bytes';
description
"Counter for received traffic in bytes.";
}
leaf dropped-packets {
type yang:zero-based-counter64;
description
"Number of dropped packets.";
}
leaf dropped-bytes {
type yang:zero-based-counter64;
units 'bytes';
description
"Counter for dropped traffic in bytes.";
}
leaf dropped-fragments {
if-feature "napt44 or nat64";
type yang:zero-based-counter64;
description
"Number of dropped fragments on the external realm.";
}
leaf dropped-address-limit-packets {
if-feature "basic-nat44 or napt44 or nat64";
type yang:zero-based-counter64;
description
"Number of dropped packets because an address limit
is reached.";
}
Boucadair, et al. Expires March 31, 2019 [Page 64]
Internet-Draft YANG Module for NAT September 2018
leaf dropped-address-limit-bytes {
if-feature "basic-nat44 or napt44 or nat64";
type yang:zero-based-counter64;
units 'bytes';
description
"Counter of dropped packets because an address limit
is reached, in bytes.";
}
leaf dropped-address-packets {
if-feature "basic-nat44 or napt44 or nat64";
type yang:zero-based-counter64;
description
"Number of dropped packets because no address is
available for allocation.";
}
leaf dropped-address-bytes {
if-feature "basic-nat44 or napt44 or nat64";
type yang:zero-based-counter64;
units 'bytes';
description
"Counter of dropped packets because no address is
available for allocation, in bytes.";
}
leaf dropped-port-limit-packets {
if-feature "napt44 or nat64";
type yang:zero-based-counter64;
description
"Number of dropped packets because a port limit
is reached.";
}
leaf dropped-port-limit-bytes {
if-feature "napt44 or nat64";
type yang:zero-based-counter64;
units 'bytes';
description
"Counter of dropped packets because a port limit
is reached, in bytes.";
}
leaf dropped-port-packets {
if-feature "napt44 or nat64";
type yang:zero-based-counter64;
description
"Number of dropped packets because no port is
Boucadair, et al. Expires March 31, 2019 [Page 65]
Internet-Draft YANG Module for NAT September 2018
available for allocation.";
}
leaf dropped-port-bytes {
if-feature "napt44 or nat64";
type yang:zero-based-counter64;
units 'bytes';
description
"Counter of dropped packets because no port is
available for allocation, in bytes.";
}
leaf dropped-subscriber-limit-packets {
if-feature "basic-nat44 or napt44 or nat64";
type yang:zero-based-counter64;
description
"Number of dropped packets because the subscriber
limit per instance is reached.";
}
leaf dropped-subscriber-limit-bytes {
if-feature "basic-nat44 or napt44 or nat64";
type yang:zero-based-counter64;
units 'bytes';
description
"Counter of dropped packets because the subscriber
limit per instance is reached, in bytes.";
}
}
container mappings-statistics {
description
"Mappings statistics.";
leaf total-active-subscribers {
if-feature "basic-nat44 or napt44 or nat64";
type yang:gauge32;
description
"Total number of active subscribers (that is,
subscribers for which the NAT maintains active
mappings.
A subscriber is identified by a subnet,
subscriber-mask, etc.";
}
leaf total-address-mappings {
if-feature "basic-nat44 or napt44 " +
Boucadair, et al. Expires March 31, 2019 [Page 66]
Internet-Draft YANG Module for NAT September 2018
"or nat64 or clat or dst-nat";
type yang:gauge32;
description
"Total number of address mappings present at a given
time. It includes both static and dynamic mappings.";
reference
"Section 3.3.8 of RFC 7659";
}
leaf total-port-mappings {
if-feature "napt44 or nat64";
type yang:gauge32;
description
"Total number of NAT port mappings present at
a given time. It includes both static and dynamic
mappings.";
reference
"Section 3.3.9 of RFC 7659";
}
list total-per-protocol {
if-feature "napt44 or nat64";
key protocol-id;
description
"Total mappings for each enabled/supported protocol.";
leaf protocol-id {
type uint8;
mandatory true;
description
"Upper-layer protocol.
For example, this field contains 6 for TCP,
17 for UDP, 33 for DCCP, or 132 for SCTP.";
}
leaf total {
type yang:gauge32;
description
"Total number of a protocol-specific mappings present
at a given time. The protocol is identified by
protocol-id.";
}
}
}
container pools-stats {
if-feature "basic-nat44 or napt44 or nat64";
description
Boucadair, et al. Expires March 31, 2019 [Page 67]
Internet-Draft YANG Module for NAT September 2018
"Statistics related to address/prefix pools
usage";
leaf addresses-allocated {
type yang:gauge32;
description
"Number of all allocated addresses.";
}
leaf addresses-free {
type yang:gauge32;
description
"Number of unallocated addresses of all pools at
a given time. The sum of unallocated and allocated
addresses is the total number of addresses of
the pools.";
}
container ports-stats {
if-feature "napt44 or nat64";
description
"Statistics related to port numbers usage.";
leaf ports-allocated {
type yang:gauge32;
description
"Number of allocated ports from all pools.";
}
leaf ports-free {
type yang:gauge32;
description
"Number of unallocated addresses from all pools.";
}
}
list per-pool-stats {
if-feature "basic-nat44 or napt44 or nat64";
key "pool-id";
description
"Statistics related to address/prefix pool usage";
leaf pool-id {
type uint32;
description
"Unique Identifier that represents a pool of
addresses/prefixes.";
Boucadair, et al. Expires March 31, 2019 [Page 68]
Internet-Draft YANG Module for NAT September 2018
}
leaf discontinuity-time {
type yang:date-and-time;
mandatory true;
description
"The time on the most recent occasion at which this
pool counters suffered a discontinuity. This must
be initialized when the address pool is
configured.";
}
container pool-stats {
description
"Statistics related to address/prefix pool usage";
leaf addresses-allocated {
type yang:gauge32;
description
"Number of allocated addresses from this pool.";
}
leaf addresses-free {
type yang:gauge32;
description
"Number of unallocated addresses in this pool.";
}
}
container port-stats {
if-feature "napt44 or nat64";
description
"Statistics related to port numbers usage.";
leaf ports-allocated {
type yang:gauge32;
description
"Number of allocated ports from this pool.";
}
leaf ports-free {
type yang:gauge32;
description
"Number of unallocated addresses from this pool.";
}
}
}
}
Boucadair, et al. Expires March 31, 2019 [Page 69]
Internet-Draft YANG Module for NAT September 2018
}
}
}
}
/*
* Notifications
*/
notification nat-pool-event {
if-feature "basic-nat44 or napt44 or nat64";
description
"Notifications must be generated when the defined high/low
threshold is reached. Related configuration parameters
must be provided to trigger the notifications.";
leaf id {
type leafref {
path "/nat/instances/instance/id";
}
mandatory true;
description
"NAT instance Identifier.";
}
leaf policy-id {
type leafref {
path "/nat/instances/instance/policy/id";
}
description
"Policy Identifier.";
}
leaf pool-id {
type leafref {
path "/nat/instances/instance/policy/" +
"external-ip-address-pool/pool-id";
}
mandatory true;
description
"Pool Identifier.";
}
leaf notify-pool-threshold {
type percent;
mandatory true;
description
Boucadair, et al. Expires March 31, 2019 [Page 70]
Internet-Draft YANG Module for NAT September 2018
"A threshold (high-threshold or low-threshold) has
been fired.";
}
}
notification nat-instance-event {
if-feature "basic-nat44 or napt44 or nat64";
description
"Notifications must be generated when notify-addresses-usage
and/or notify-ports-usage threshold are reached.";
leaf id {
type leafref {
path "/nat/instances/instance/id";
}
mandatory true;
description
"NAT instance Identifier.";
}
leaf notify-subscribers-threshold {
type uint32;
description
"The notify-subscribers-limit threshold has been fired.";
}
leaf notify-addresses-threshold {
type percent;
description
"The notify-addresses-usage threshold has been fired.";
}
leaf notify-ports-threshold {
type percent;
description
"The notify-ports-usage threshold has been fired.";
}
}
}
<CODE ENDS>
4. Security Considerations
Security considerations related to address and prefix translation are
discussed in [RFC6888], [RFC6146], [RFC6877], [RFC6296], and
[RFC7757].
Boucadair, et al. Expires March 31, 2019 [Page 71]
Internet-Draft YANG Module for NAT September 2018
The YANG module defined in this document is designed to be accessed
via network management protocols such as NETCONF [RFC6241] or
RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
layer, and the mandatory-to-implement secure transport is Secure
Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS [RFC5246].
The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
All data nodes defined in the YANG module which can be created,
modified and deleted (i.e., config true, which is the default) are
considered sensitive. Write operations (e.g., edit-config) applied
to these data nodes without proper protection can negatively affect
network operations. The NAT YANG module provides a method to set
parameters to prevent a user from aggressively using NAT resources
(port-quota), rate-limit connections as a guard against Denial-of-
Service, or to enable notifications so that appropriate measures are
enforced to anticipate traffic drops. Nevertheless, an attacker who
is able to access the NAT can undertake various attacks, such as:
o Set a high or low resource limit to cause a DoS attack:
* /nat/instances/instance/policy/port-quota
* /nat/instances/instance/policy/fragments-limit
* /nat/instances/instance/mapping-limits
* /nat/instances/instance/connection-limits
o Set a low notification threshold to cause useless notifications to
be generated:
* /nat/instances/instance/policy/notify-pool-usage/high-threshold
* /nat/instances/instance/notification-limits/notify-addresses-
usage
* /nat/instances/instance/notification-limits/notify-ports-usage
* /nat/instances/instance/notification-limits/notify-subscribers-
limit
o Set an arbitrarily high threshold, which may lead to the
deactivation of notifications:
Boucadair, et al. Expires March 31, 2019 [Page 72]
Internet-Draft YANG Module for NAT September 2018
* /nat/instances/instance/policy/notify-pool-usage/high-threshold
* /nat/instances/instance/notification-limits/notify-addresses-
usage
* /nat/instances/instance/notification-limits/notify-ports-usage
* /nat/instances/instance/notification-limits/notify-subscribers-
limit
o Set a low notification interval and a low notification threshold
to induce useless notifications to be generated:
* /nat/instances/instance/policy/notify-pool-usage/notify-
interval
* /nat/instances/instance/notification-limits/notify-interval
o Access to privacy data maintained in the mapping table. Such data
can be misused to track the activity of a host:
* /nat/instances/instance/mapping-table
5. IANA Considerations
This document requests IANA to register the following URI in the
"IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-nat
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in
the "YANG Module Names" registry [RFC7950].
name: ietf-nat
namespace: urn:ietf:params:xml:ns:yang:ietf-nat
prefix: nat
reference: RFC XXXX
6. Acknowledgements
Many thanks to Dan Wing, Tianran Zhou, Tom Petch, Warren Kumari, and
Benjamin Kaduk for the review.
Boucadair, et al. Expires March 31, 2019 [Page 73]
Internet-Draft YANG Module for NAT September 2018
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 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 to clarify how the module applies for both
stateless and stateful NAT64.
Juergen Schoenwaelder provided an early yandgoctors review. Many
thanks to him.
Thanks to Roni Even, Mach Chen, Tim Chown, and Stephen Farrel 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.
7. References
7.1. Normative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, DOI 10.17487/RFC5382, October 2008,
<https://www.rfc-editor.org/info/rfc5382>.
Boucadair, et al. Expires March 31, 2019 [Page 74]
Internet-Draft YANG Module for NAT September 2018
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
DOI 10.17487/RFC5508, April 2009,
<https://www.rfc-editor.org/info/rfc5508>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>.
[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable
Operation of Address Translators with Per-Interface
Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012,
<https://www.rfc-editor.org/info/rfc6619>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
Boucadair, et al. Expires March 31, 2019 [Page 75]
Internet-Draft YANG Module for NAT September 2018
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <https://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<https://www.rfc-editor.org/info/rfc7597>.
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address
Mappings for Stateless IP/ICMP Translation", RFC 7757,
DOI 10.17487/RFC7757, February 2016,
<https://www.rfc-editor.org/info/rfc7757>.
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
S., and K. Naito, "Updates to Network Address Translation
(NAT) Behavioral Requirements", BCP 127, RFC 7857,
DOI 10.17487/RFC7857, April 2016,
<https://www.rfc-editor.org/info/rfc7857>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/info/rfc7915>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
Boucadair, et al. Expires March 31, 2019 [Page 76]
Internet-Draft YANG Module for NAT September 2018
7.2. Informative References
[I-D.boucadair-pcp-yang]
Boucadair, M., Jacquenet, C., Sivakumar, S., and S.
Vinapamula, "YANG Modules for the Port Control Protocol
(PCP)", draft-boucadair-pcp-yang-05 (work in progress),
October 2017.
[I-D.ietf-softwire-dslite-yang]
Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG
Data Model for Dual-Stack Lite (DS-Lite)", draft-ietf-
softwire-dslite-yang-17 (work in progress), May 2018.
[I-D.ietf-tsvwg-natsupp]
Stewart, R., Tuexen, M., and I. Ruengeler, &3.1.4. MAP-E
The CE (Customer-Edge) router first encapsulates IPv4-in-IPv6.
Packets must traverse a MAP BR to be [de-]encapsulated.
3.1.5. MAP-T
The CE (Customer Edge) router first performs a NAT44 to transform
the source addresses and source port numbers of the IPv4 packets
into a predefined range, the size of which is a design parameter.
The CE router then performs stateless translation from IPv4 to IPv6
[RFC7915], which translates the IPv4 address and the port numbers
into the IPv6 address space. The transformations may be fine-tuned
by the mapping rules. The MAP BR (Border Relay) performs stateless
translation from IPv4 to IPv6 [RFC7915].
3.2. Tradeoff between Port Number Efficiency and Stateless Operation
464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices,
respectively. This may cause scalability issues. Lw4o6, MAP-E and
MAP-T avoid using NAPT in the service provider network. Its cost is
that they have to limit the port numbers available for a user, which
is also the case for DS-Lite. Determining the optimal size of the
port set is not an easy task. On the one hand, the lack of port
situation may cause serious problems in the operation of certain
programs (e.g. the consequences of the session number limitation due
to port number shortage were impressively demonstrated using Google
Map in [Miy2010]). The port number consumption of different
applications is highly varying and e.g. in the case of web browsing
it depends on several factors [Rep2014]. And there may be several
users behind a CPE, especially in the wired case (e.g. Internet is
used by different members of a family simultaneously), thus
sometimes even a few thousands ports may not be enough. However, on
the other hand, assigning too many ports per user will result in
waste of public IPv4 addresses, which is a scarce and expensive
resource. Therefore, 464XLAT is much more efficient in terms of port
number and thus public IP address saving. The price is the stateful
operation in the service provider network, which is allegedly does
not scale up well. XXX MEASUREMENTS ARE PLANNED TO DECIDE IF IT IS
TRUE. XXX
We also note that NAT64 does not pre-allocate ports for customers
but allocates them "on the fly" (which means that even the same
customer is using ports from different addresses, and most of the
time, different customers get ports from any given addresses), and
in fact this creates many application/service providers (Sony
Lencse et al. Expires April 6, 2019 [Page 5]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
PlayStation Network, OpenDNS, etc.) to permanently black-list the
IPv4 ranges once they are detected to be used for address sharing.
3.3. Support for Server Operation
Lw4o6, MAP-E and MAP-T may be configured without IPv4 address
sharing, allowing exclusive use of all ports, and non-port-based
layer 4 protocols. Thus, they may also be used to support server
operation, when public IPv4 addresses are assigned to the
subscribers, however, then there is no advantage in terms of IPv4
public addresses saving.
It is also possible to configure specific ports mapping in
464XLAT/NAT64 using EAMT [RFC7757], which means that only those
ports are "lost" from the pool of addresses, so there is a higher
maximization of the total usage of IPv4/port resources.
3.4. Support and Implementations
3.4.1. OS Support
As for 464XLAT, client support exists in Windows 10, Linux
(including Android), Windows Mobile, and Chrome OS, but it is
missing from iOS and MacOS. For the other four solutions, we are not
aware of any OS support.
3.4.2. Support in Cellular and Broadband Networks
Several cellular networks use 464XLAT, whereas we are not aware of
any deployment of the four other technologies in cellular networks,
as they are not supported.
In broadband networks, there are some deployments of 464XLAT, MAP-E
and MAP-T. Both, lw4o6 and DS-Lite have more deployments, having
been up now DS-Lite the most used one, but lw4o6 taking over in the
last years.
3.4.3. Implementation Code Sizes
As for complexity hint, the code size reported from OpenWRT
implementation is 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT,
lw4o6, DS-Lite, MAP-E, MAP-T, and lw4o6, respectively
(https://openwrt.org/packages/start).
We note that the support for all five technologies requires much
less code size than the total sum of the above quantities, because
Lencse et al. Expires April 6, 2019 [Page 6]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
they contain a lot of common functions (data plane is shared among
several of them).
4. Performance Comparison
We plan to compare the performances of the most prominent free
software implementations of the five IPv6 transition technologies
using the methodology described in "Benchmarking Methodology for
IPv6 Transition Technologies" [RFC8219].
On the one hand, the Dual DUT Setup of RFC8219 makes it possible to
use the existing "Benchmarking Methodology for Network Interconnect
Devices" [RFC2544] compliant measurement devices, however, this
setup has the drawback that the performances of the CE and of the
ISP side device (e.g. the CLAT and the PLAT of 464XLAT) are measured
together. In order to measure the performance of only one of them,
we need to ensure that the desired one is the bottleneck.
On the other hand, the Single DUT Setup of [RFC8219] makes it
possible to benchmark the selected device separately, however, no
[RFC8219] compliant testers available yet. A DPDK-based software
Tester for stateless NAT64 is currently under development and it is
expected to be available this autumn as a free software. XXX FROM
WHERE XXX
Any volunteers for developing [RFC8219] compliant measurement
software?
5. Security Considerations
According to the simplest model, the number of bugs is proportional
to the number of code lines. Please refer to section 3.4.3 for code
sizes of CE implementations.
For all five technologies, the CE device should contain a DNS proxy.
However, the user may change DNS settings. If it happens and lw4o6,
MAP-E and MAP-T are used with significantly restricted port set,
which is required for an efficient public IPv4 address sharing, the
entropy of the source ports is significantly lowered (e.g. from 16
bits to 10 bits, when 1024 port numbers are assigned to each
subscriber) and thus these technologies are theoretically less
resilient against cache poisoning, see [RFC5452]. However, an
efficient cache poisoning attack requires that the subscriber
operates an own caching DNS server and the attack is performed in
the service provider network. Thus, we consider the chance of the
successful exploitation of this vulnerability as low.
Lencse et al. Expires April 6, 2019 [Page 7]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
An in-depth security analysis of all five IPv6 transition
technologies and their most prominent free software implementations
according to the methodology defined in [Len2018] is planned.
6. IANA Considerations
TBD.
7. Conclusions
TBD.
8. References
8.1. Normative References
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, DOI
10.17487/RFC2544, March 1999, <http://www.rfc-
editor.org/info/rfc2544>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010, <http://www.rfc-
editor.org/info/rfc6052>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269, DOI
10.17487/RFC6269, June 2011, <http://www.rfc-
editor.org/info/rfc6269.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC
6877, DOI 10.17487/RFC6877, April 2013, <http://www.rfc-
editor.org/info/rfc6877>.
Lencse et al. Expires April 6, 2019 [Page 8]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597, DOI
10.17487/RFC7597, July 2015, <http://www.rfc-
editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <http://www.rfc-editor.org/info/rfc7599>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP translation algorithm", RFC 7915, DOI:
10.17487/RFC7915, June 2016, <http://www.rfc-
editor.org/info/rfc7915>.
[RFC7757] Anderson, T., and A. Leiva Popper "Explicit Address
Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI
10.17487/RFC7757, February 2016, <http://www.rfc-
editor.org/info/rfc77757>.
[RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking
Methodology for IPv6 Transition Technologies", IETF RFC
8219, DOI: 10.17487/RFC8219, Aug. 2017, <http://www.rfc-
editor.org/info/rfc8219>.
8.2. Informative References
[Len2017] Lencse, G., and Y. Kadobayashi, "Survey of IPv6 Transition
Technologies for Security Analysis", IEICE Communications
Society Internet Architecture Workshop, Tokyo, Japan, Aug.
28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24.
http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-
survey.pdf
Lencse et al. Expires April 6, 2019 [Page 9]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
[Len2018] Lencse, G., and Y. Kadobayashi, "Methodology for the
identification of potential security issues of different
IPv6 transition technologies: Threat analysis of DNS64 and
stateful NAT64", Computers & Security (Elsevier), vol. 77,
no. 1, pp. 397-411, August 1, 2018, DOI:
10.1016/j.cose.2018.04.012,
http://www.hit.bme.hu/~lencse/publications/ECS-2018-
Methodology-revised.pdf
[Miy2010] Miyakawa, S., "IPv4 to IPv6 transformation schemes", IEICE
Trans. Commun., vol.E93-B, no.5, pp.1078-1084, May 2010.
DOI:10.1587/transcom.E93.B.1078
[Rep2014] Repas, S., Hajas, T., and G. Lencse, "Port number
consumption of the NAT64 IPv6 transition technology",
Proc. 37th Internat. Conf. on Telecommunications and
Signal Processing (TSP 2014), Berlin, Germany, pp.66-72,
Jul. 1-3, 2014. DOI: 10.1109/TSP.2015.7296411
9. Acknowledgments
The authors would like to acknowledge the inputs of Ole Troan, Mark
Andrews, Edwin Cordeiro, Fred Baker, Alexandre Petrescu, and TBD.
This document was prepared using 2-Word-v2.0.template.dot.
Copyright (c) 2018 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
Lencse et al. Expires April 6, 2019 [Page 10]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
Authors' Addresses
quot;Stream Control
Transmission Protocol (SCTP) Network Address Translation
Support", draft-ietf-tsvwg-natsupp-12 (work in progress),
July 2018.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/info/rfc2663>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>.
[RFC5597] Denis-Courmont, R., "Network Address Translation (NAT)
Behavioral Requirements for the Datagram Congestion
Control Protocol", BCP 150, RFC 5597,
DOI 10.17487/RFC5597, September 2009,
<https://www.rfc-editor.org/info/rfc5597>.
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
January 2011, <https://www.rfc-editor.org/info/rfc6087>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011,
<https://www.rfc-editor.org/info/rfc6269>.
[RFC6736] Brockners, F., Bhandari, S., Singh, V., and V. Fajardo,
"Diameter Network Address and Port Translation Control
Application", RFC 6736, DOI 10.17487/RFC6736, October
2012, <https://www.rfc-editor.org/info/rfc6736>.
Boucadair, et al. Expires March 31, 2019 [Page 77]
Internet-Draft YANG Module for NAT September 2018
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>.
[RFC6908] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.
Boucadair, "Deployment Considerations for Dual-Stack
Lite", RFC 6908, DOI 10.17487/RFC6908, March 2013,
<https://www.rfc-editor.org/info/rfc6908>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>.
[RFC7289] Kuarsingh, V., Ed. and J. Cianfarani, "Carrier-Grade NAT
(CGN) Deployment with BGP/MPLS IP VPNs", RFC 7289,
DOI 10.17487/RFC7289, June 2014,
<https://www.rfc-editor.org/info/rfc7289>.
[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335,
DOI 10.17487/RFC7335, August 2014,
<https://www.rfc-editor.org/info/rfc7335>.
[RFC7659] Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor,
"Definitions of Managed Objects for Network Address
Translators (NATs)", RFC 7659, DOI 10.17487/RFC7659,
October 2015, <https://www.rfc-editor.org/info/rfc7659>.
[RFC7753] Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T.,
and S. Perreault, "Port Control Protocol (PCP) Extension
for Port-Set Allocation", RFC 7753, DOI 10.17487/RFC7753,
February 2016, <https://www.rfc-editor.org/info/rfc7753>.
[RFC8045] Cheng, D., Korhonen, J., Boucadair, M., and S. Sivakumar,
"RADIUS Extensions for IP Port Configuration and
Reporting", RFC 8045, DOI 10.17487/RFC8045, January 2017,
<https://www.rfc-editor.org/info/rfc8045>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
Appendix A. Sample Examples
This section provides a non-exhaustive set of examples to illustrate
the use of the NAT YANG module.
Boucadair, et al. Expires March 31, 2019 [Page 78]
Internet-Draft YANG Module for NAT September 2018
A.1. Traditional NAT44
Traditional NAT44 is a Basic NAT44 or NAPT that is used to share the
same IPv4 address among hosts that are owned by the same subscriber.
This is typically the NAT that is embedded in CPE devices.
This NAT is usually provided with one single external IPv4 address;
disambiguating connections is achieved by rewriting the source port
number. The XML snippet to configure the external IPv4 address in
such case together with a mapping entry is depicted below:
<instances>
<instance>
<id>1</id>
<name>NAT_Subscriber_A</name>
....
<external-ip-address-pool>
<pool-id>1</pool-id>
<external-ip-pool>
198.51.100.1/32
</external-ip-pool>
</external-ip-address-pool>
....
<mapping-table>
....
<external-src-address>
198.51.100.1/32
</external-src-address>
....
</mapping-table>
</instance>
</instances>
The following shows the XML excerpt depicting a dynamic UDP mapping
entry maintained by a traditional NAPT44. In reference to this
example, the UDP packet received with a source IPv4 address
(192.0.2.1) and source port number (1568) is translated into a UDP
packet having a source IPv4 address (198.51.100.1) and source port
(15000). The remaining lifetime of this mapping is 300 seconds.
Boucadair, et al. Expires March 31, 2019 [Page 79]
Internet-Draft YANG Module for NAT September 2018
<mapping-entry>
<index>15</index>
<type>
dynamic-explicit
</type>
<transport-protocol>
17
</transport-protocol>
<internal-src-address>
192.0.2.1/32
</internal-src-address>
<internal-src-port>
<start-port-number>
1568
</start-port-number>
</internal-src-port>
<external-src-address>
198.51.100.1/32
</external-src-address>
<external-src-port>
<start-port-number>
15000
</start-port-number>
</external-src-port>
<lifetime>
300
</lifetime>
</mapping-entry>
A.2. Carrier Grade NAT (CGN)
The following XML snippet shows the example of the capabilities
supported by a CGN as retrieved using NETCONF.
<capabilities
<nat-flavor>napt44</nat-flavor>
<transport-protocols>
<protocol-id>1</protocol-id>
</transport-protocols>
<transport-protocols>
<protocol-id>6</protocol-id>
</transport-protocols>
<transport-protocols>
<protocol-id>17</protocol-id>
</transport-protocols>
<restricted-port-support>
false
</restricted-port-support>
Boucadair, et al. Expires March 31, 2019 [Page 80]
Internet-Draft YANG Module for NAT September 2018
<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>
<port-parity-preservation-support>
false
</port-parity-preservation-support>
<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>
<address-dependent-mapping-support>
true
</address-dependent-mapping-support>
<address-and-port-dependent-mapping-support>
true
</address-and-port-dependent-mapping-support>
<endpoint-independent-filtering-support>
true
</endpoint-independent-filtering-support>
<address-dependent-filtering>
true
</address-dependent-filtering>
<address-and-port-dependent-filtering>
true
</address-and-port-dependent-filtering>
</capabilities>
The following XML snippet shows the example of a CGN that is
provisioned with one contiguous pool of external IPv4 addresses
(198.51.100.0/24). Further, the CGN is instructed to limit the
number of allocated ports per subscriber to 1024. Ports can be
allocated by the CGN by assigning ranges of 256 ports (that is, a
subscriber can be allocated up to four port ranges of 256 ports
each).
Boucadair, et al. Expires March 31, 2019 [Page 81]
Internet-Draft YANG Module for NAT September 2018
<instances>
<instance>
<id>1</id>
<name>myCGN</name>
....
<external-ip-address-pool>
<pool-id>1</pool-id>
<external-ip-pool&Gabor Lencse
Budapest University of Technology and Economics
Magyar Tudosok korutja 2.
H-1117 Budapest, Hungary
Email: lencse@hit.bme.hu
Jordi Palet Martinez
The IPv6 Company
Molino de la Navata, 75
La Navata - Galapagar, Madrid - 28420
Spain
Email: jordi.palet@theipv6company.com
Lee Howard
Retevia
9940 Main St., Suite 200
Fairfax
Virginia
22031, USA
Email: lee@asgard.org
Richard Patterson
Sky UK
1 Brick Lane
London, E1 6PU
United Kingdom
Email: richard.patterson@sky.uk
Lencse et al. Expires April 6, 2019 [Page 11]