doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc7422.txt b/doc/rfc/rfc7422.txt
new file mode 100644
index 0000000..c2b7fc7
--- /dev/null
+++ b/doc/rfc/rfc7422.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Independent Submission                                         C. Donley
+Request for Comments: 7422                                     CableLabs
+Category: Informational                                    C. Grundemann
+ISSN: 2070-1721                                         Internet Society
+                                                              V. Sarawat
+                                                           K. Sundaresan
+                                                               CableLabs
+                                                              O. Vautrin
+                                                        Juniper Networks
+                                                           December 2014
+
+
+           Deterministic Address Mapping to Reduce Logging in
+                     Carrier-Grade NAT Deployments
+
+Abstract
+
+   In some instances, Service Providers (SPs) have a legal logging
+   requirement to be able to map a subscriber's inside address with the
+   address used on the public Internet (e.g., for abuse response).
+   Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs)
+   require active logging of dynamic translations.  CGN port assignments
+   are often per connection, but they could optionally use port ranges.
+   Research indicates that per-connection logging is not scalable in
+   many residential broadband services.  This document suggests a way to
+   manage CGN translations in such a way as to significantly reduce the
+   amount of logging required while providing traceability for abuse
+   response.  IPv6 is, of course, the preferred solution.  While
+   deployment is in progress, SPs are forced by business imperatives to
+   maintain support for IPv4.  This note addresses the IPv4 part of the
+   network when a CGN solution is in use.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7422.
+
+
+
+
+Donley, et al.                Informational                     [Page 1]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Requirements Language ......................................4
+   2. Deterministic Port Ranges .......................................4
+      2.1. IPv4 Port Utilization Efficiency ...........................7
+      2.2. Planning and Dimensioning ..................................7
+      2.3. Deterministic CGN Example ..................................8
+   3. Additional Logging Considerations ...............................9
+      3.1. Failover Considerations ...................................10
+   4. Impact on the IPv6 Transition ..................................10
+   5. Privacy Considerations .........................................11
+   6. Security Considerations ........................................11
+   7. References .....................................................11
+      7.1. Normative References ......................................11
+      7.2. Informative References ....................................12
+   Acknowledgements ..................................................13
+   Authors' Addresses ................................................14
+
+1.  Introduction
+
+   It is becoming increasingly difficult to obtain new IPv4 address
+   assignments from Regional/Local Internet Registries due to depleting
+   supplies of unallocated IPv4 address space.  To meet the growing
+   demand for Internet connectivity from new subscribers, devices, and
+   service types, some operators will be forced to share a single public
+   IPv4 address among multiple subscribers using techniques such as
+   Carrier-Grade NAT (CGN) [RFC6264] (e.g., NAT444 [NAT444], Dual-Stack
+   Lite (DS-Lite) [RFC6333], NAT64 [RFC6146], etc.).  However, address
+   sharing poses additional challenges to operators when considering how
+   they manage service entitlement, public safety requests, or
+   attack/abuse/fraud reports [RFC6269].  In order to identify a
+   specific user associated with an IP address in response to such a
+   request or for service entitlement, an operator will need to map a
+   subscriber's internal source IP address and source port with the
+
+
+
+
+Donley, et al.                Informational                     [Page 2]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+   global public IP address and source port provided by the CGN for
+   every connection initiated by the user.
+
+   CGN connection logging satisfies the need to identify attackers and
+   respond to abuse/public safety requests, but it imposes significant
+   operational challenges to operators.  In lab testing, we have
+   observed CGN log messages to be approximately 150 bytes long for
+   NAT444 [NAT444] and 175 bytes for DS-Lite [RFC6333] (individual log
+   messages vary somewhat in size).  Although we are not aware of
+   definitive studies of connection rates per subscriber, reports from
+   several operators in the US sets the average number of connections
+   per household at approximately 33,000 connections per day.  If each
+   connection is individually logged, this translates to a data volume
+   of approximately 5 MB per subscriber per day, or about 150 MB per
+   subscriber per month; however, specific data volumes may vary across
+   different operators based on myriad factors.  Based on available
+   data, a 1-million-subscriber SP will generate approximately 150
+   terabytes of log data per month, or 1.8 petabytes per year.  Note
+   that many SPs compress log data after collection; compression factors
+   of 2:1 or 3:1 are common.
+
+   The volume of log data poses a problem for both operators and the
+   public safety community.  On the operator side, it requires a
+   significant infrastructure investment by operators implementing CGN.
+   It also requires updated operational practices to maintain the
+   logging infrastructure, and requires approximately 23 Mbps of
+   bandwidth between the CGN devices and the logging infrastructure per
+   50,000 users.  On the public safety side, it increases the time
+   required for an operator to search the logs in response to an abuse
+   report, and it could delay investigations.  Accordingly, an
+   international group of operators and public safety officials
+   approached the authors to identify a way to reduce this impact while
+   improving abuse response.
+
+   The volume of CGN logging can be reduced by assigning port ranges
+   instead of individual ports.  Using this method, only the assignment
+   of a new port range is logged.  This may massively reduce logging
+   volume.  The log reduction may vary depending on the length of the
+   assigned port range, whether the port range is static or dynamic,
+   etc.  This has been acknowledged in [RFC6269], which recommends the
+   logging of source ports at the server and/or destination logging at
+   the CGN, and [NAT-LOGGING], which describes information to be logged
+   at a NAT.
+
+   However, the existing solutions still pose an impact on operators and
+   public safety officials for logging and searching.  Instead, CGNs
+   could be designed and/or configured to deterministically map internal
+   addresses to {external address + port range} in such a way as to be
+
+
+
+Donley, et al.                Informational                     [Page 3]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+   able to algorithmically calculate the mapping.  Only inputs and
+   configuration of the algorithm need to be logged.  This approach
+   reduces both logging volume and subscriber identification times.  In
+   some cases, when full deterministic allocation is used, this approach
+   can eliminate the need for translation logging.
+
+   This document describes a method for such CGN address mapping,
+   combined with block port reservations, that significantly reduces the
+   burden on operators while offering the ability to map a subscriber's
+   inside IP address with an outside address and external port number
+   observed on the Internet.
+
+   The activation of the proposed port range allocation scheme is
+   compliant with BEHAVE requirements such as the support of
+   Application-specific functions (APP).
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  Deterministic Port Ranges
+
+   While a subscriber uses thousands of connections per day, most
+   subscribers use far fewer resources at any given time.  When the
+   compression ratio (see Appendix B of RFC 6269 [RFC6269]) is low
+   (e.g., the ratio of the number of subscribers to the number of public
+   IPv4 addresses allocated to a CGN is closer to 10:1 than 1000:1),
+   each subscriber could expect to have access to thousands of TCP/UDP
+   ports at any given time.  Thus, as an alternative to logging each
+   connection, CGNs could deterministically map customer private
+   addresses (received on the customer-facing interface of the CGN,
+   a.k.a., internal side) to public addresses extended with port ranges
+   (used on the Internet-facing interface of the CGN, a.k.a., external
+   side).  This algorithm allows an operator to identify a subscriber
+   internal IP address when provided the public side IP and port number
+   without having to examine the CGN translation logs.  This prevents an
+   operator from having to transport and store massive amounts of
+   session data from the CGN and then process it to identify a
+   subscriber.
+
+   The algorithmic mapping can be expressed as:
+
+   (External IP Address, Port Range) = function 1 (Internal IP Address)
+
+   Internal IP Address = function 2 (External IP Address, Port Number)
+
+
+
+
+Donley, et al.                Informational                     [Page 4]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+   The CGN SHOULD provide a method for administrators to test both
+   mapping functions (e.g., enter an External IP Address + Port Number
+   and receive the corresponding Internal IP Address).
+
+   Deterministic Port Range allocation requires configuration of the
+   following variables:
+
+   o  Inside IPv4/IPv6 address range (I);
+
+   o  Outside IPv4 address range (O);
+
+   o  Compression ratio (e.g., inside IP addresses I / outside IP
+      addresses O) (C);
+
+   o  Dynamic address pool factor (D), to be added to the compression
+      ratio in order to create an overflow address pool;
+
+   o  Maximum ports per user (M);
+
+   o  Address assignment algorithm (A) (see below); and
+
+   o  Reserved TCP/UDP port list (R)
+
+   Note: The inside address range (I) will be an IPv4 range in NAT444
+   operation (NAT444 [NAT444]) and an IPv6 range in DS-Lite operation
+   (DS-Lite [RFC6333]).
+
+   A subscriber is identified by an internal IPv4 address (e.g., NAT44)
+   or an IPv6 prefix (e.g., DS-Lite or NAT64).
+
+   The algorithm may be generalized to L2-aware NAT [L2NAT], but this
+   requires the configuration of the Internal interface identifiers
+   (e.g., Media Access Control (MAC) addresses).
+
+   The algorithm is not designed to retrieve an internal host among
+   those sharing the same internal IP address (e.g., in a DS-Lite
+   context, only an IPv6 address/prefix can be retrieved using the
+   algorithm while the internal IPv4 address used for the encapsulated
+   IPv4 datagram is lost).
+
+   Several address-assignment algorithms are possible.  Using predefined
+   algorithms, such as those that follow, simplifies the process of
+   reversing the algorithm when needed.  However, the CGN MAY support
+   additional algorithms.  Also, the CGN is not required to support all
+   of the algorithms described below.  Subscribers could be restricted
+
+
+
+
+
+
+Donley, et al.                Informational                     [Page 5]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+   to ports from a single IPv4 address or could be allocated ports
+   across all addresses in a pool, for example.  The following
+   algorithms and corresponding values of A are as follows:
+
+   0: Sequential (e.g., the first block goes to address 1, the second
+      block to address 2, etc.).
+
+   1: Staggered (e.g., for every n between 0 and ((65536-R)/(C+D))-1 ,
+      address 1 receives ports n*C+R, address 2 receives ports
+      (1+n)*C+R, etc.).
+
+   2: Round robin (e.g., the subscriber receives the same port number
+      across a pool of external IP addresses.  If the subscriber is to
+      be assigned more ports than there are in the external IP pool, the
+      subscriber receives the next highest port across the IP pool, and
+      so on.  Thus, if there are 10 IP addresses in a pool and a
+      subscriber is assigned 1000 ports, the subscriber would receive a
+      range such as ports 2000-2099 across all 10 external IP
+      addresses).
+
+   3: Interlaced horizontally (e.g., each address receives every Cth
+      port spread across a pool of external IP addresses).
+
+   4: Cryptographically random port assignment (Section 2.2 of RFC6431
+      [RFC6431]).  If this algorithm is used, the SP needs to retain the
+      keying material and specific cryptographic function to support
+      reversibility.
+
+   5: Vendor-specific.  Other vendor-specific algorithms may also be
+      supported.
+
+   The assigned range of ports MAY also be used when translating ICMP
+   requests (when rewriting the Identifier field).
+
+   The CGN then reserves ports as follows:
+
+   1.  The CGN removes reserved ports (R) from the port candidate list
+       (e.g., 0-1023 for TCP and UDP).  At a minimum, the CGN SHOULD
+       remove system ports [RFC6335] from the port candidate list
+       reserved for deterministic assignment.
+
+   2.  The CGN calculates the total compression ratio (C+D), and
+       allocates 1/(C+D) of the available ports to each internal IP
+       address.  Specific port allocation is determined by the algorithm
+       (A) configured on the CGN.  Any remaining ports are allocated to
+       the dynamic pool.
+
+
+
+
+
+Donley, et al.                Informational                     [Page 6]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+       Note: Setting D to 0 disables the dynamic pool.  This option
+       eliminates the need for per-subscriber logging at the expense of
+       limiting the number of concurrent connections that 'power users'
+       can initiate.
+
+   3.  When a subscriber initiates a connection, the CGN creates a
+       translation mapping between the subscriber's inside local IP
+       address/port and the CGN outside global IP address/port.  The CGN
+       MUST use one of the ports allocated in step 2 for the translation
+       as long as such ports are available.  The CGN SHOULD allocate
+       ports randomly within the port range assigned by the
+       deterministic algorithm.  This is to increase subscriber privacy.
+       The CGN MUST use the pre-allocated port range from step 2 for
+       Port Control Protocol (PCP, [RFC6887]) reservations as long as
+       such ports are available.  While the CGN maintains its mapping
+       table, it need not generate a log entry for translation mappings
+       created in this step.
+
+   4.  If D>0, the CGN will have a pool of ports left for dynamic
+       assignment.  If a subscriber uses more than the range of ports
+       allocated in step 2 (but fewer than the configured maximum ports
+       M), the CGN assigns a block of ports from the dynamic assignment
+       range for such a connection or for PCP reservations.  The CGN
+       MUST log dynamically assigned port blocks to facilitate
+       subscriber-to-address mapping.  The CGN SHOULD manage dynamic
+       ports as described in [LOG-REDUCTION].
+
+   5.  Configuration of reserved ports (e.g., system ports) is left to
+       operator configuration.
+
+   Thus, the CGN will maintain translation mapping information for all
+   connections within its internal translation tables; however, it only
+   needs to externally log translations for dynamically assigned ports.
+
+2.1.  IPv4 Port Utilization Efficiency
+
+   For SPs requiring an aggressive address-sharing ratio, the use of the
+   algorithmic mapping may impact the efficiency of the address sharing.
+   A dynamic port range allocation assignment is more suitable in those
+   cases.
+
+2.2.  Planning and Dimensioning
+
+   Unlike dynamic approaches, the use of the algorithmic mapping
+   requires more effort from operational teams to tweak the algorithm
+   (e.g., size of the port range, address sharing ratio, etc.).
+   Dedicated alarms SHOULD be configured when some port utilization
+   thresholds are fired so that the configuration can be refined.
+
+
+
+Donley, et al.                Informational                     [Page 7]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+   The use of algorithmic mapping also affects geolocation.  Changes to
+   the inside and outside address ranges (e.g., due to growth, address
+   allocation planning, etc.) would require external geolocation
+   providers to recalibrate their mappings.
+
+2.3.  Deterministic CGN Example
+
+   To illustrate the use of deterministic NAT, let's consider a simple
+   example.  The operator configures an inside address range (I) of
+   198.51.100.0/28 [RFC6598] and outside address (O) of 192.0.2.1.  The
+   dynamic address pool factor (D) is set to '2'.  Thus, the total
+   compression ratio is 1:(14+2) = 1:16.  Only the system ports (e.g.,
+   ports < 1024) are reserved (R).  This configuration causes the CGN to
+   pre-allocate ((65536-1024)/16 =) 4032 TCP and 4032 UDP ports per
+   inside IPv4 address.  For the purposes of this example, let's assume
+   that they are allocated sequentially, where 198.51.100.1 maps to
+   192.0.2.1 ports 1024-5055, 198.51.100.2 maps to 192.0.2.1 ports
+   5056-9087, etc.  The dynamic port range thus contains ports
+   57472-65535 (port allocation illustrated in the table below).
+   Finally, the maximum ports/subscriber is set to 5040.
+
+            +-----------------------+------------------------+
+            | Inside Address / Pool | Outside Address & Port |
+            +-----------------------+------------------------+
+            | Reserved              | 192.0.2.1:0-1023       |
+            | 198.51.100.1          | 192.0.2.1:1024-5055    |
+            | 198.51.100.2          | 192.0.2.1:5056-9087    |
+            | 198.51.100.3          | 192.0.2.1:9088-13119   |
+            | 198.51.100.4          | 192.0.2.1:13120-17151  |
+            | 198.51.100.5          | 192.0.2.1:17152-21183  |
+            | 198.51.100.6          | 192.0.2.1:21184-25215  |
+            | 198.51.100.7          | 192.0.2.1:25216-29247  |
+            | 198.51.100.8          | 192.0.2.1:29248-33279  |
+            | 198.51.100.9          | 192.0.2.1:33280-37311  |
+            | 198.51.100.10         | 192.0.2.1:37312-41343  |
+            | 198.51.100.11         | 192.0.2.1:41344-45375  |
+            | 198.51.100.12         | 192.0.2.1:45376-49407  |
+            | 198.51.100.13         | 192.0.2.1:49408-53439  |
+            | 198.51.100.14         | 192.0.2.1:53440-57471  |
+            | Dynamic               | 192.0.2.1:57472-65535  |
+            +-----------------------+------------------------+
+
+   When subscriber 1 using 198.51.100.1 initiates a low volume of
+   connections (e.g., < 4032 concurrent connections), the CGN maps the
+   outgoing source address/port to the pre-allocated range.  These
+   translation mappings are not logged.
+
+
+
+
+
+Donley, et al.                Informational                     [Page 8]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+   Subscriber 2 concurrently uses more than the allocated 4032 ports
+   (e.g., for peer-to-peer, mapping, video streaming, or other
+   connection-intensive traffic types), the CGN allocates up to an
+   additional 1008 ports using bulk port reservations.  In this example,
+   subscriber 2 uses outside ports 5056-9087, and then 100-port blocks
+   between 58000-58999.  Connections using ports 5056-9087 are not
+   logged, while 10 log entries are created for ports 58000-58099,
+   58100-58199, 58200-58299, ..., 58900-58999.
+
+   In order to identify a subscriber behind a CGN (regardless of port
+   allocation method), public safety agencies need to collect source
+   address and port information from content provider log files.  Thus,
+   content providers are advised to log source address, source port, and
+   timestamp for all log entries, per [RFC6302].  If a public safety
+   agency collects such information from a content provider and reports
+   abuse from 192.0.2.1, port 2001, the operator can reverse the mapping
+   algorithm to determine that the internal IP address subscriber 1 has
+   been assigned generated the traffic without consulting CGN logs (by
+   correlating the internal IP address with DHCP/PPP lease connection
+   records).  If a second abuse report comes in for 192.0.2.1, port
+   58204, the operator will determine that port 58204 is within the
+   dynamic pool range, consult the log file, correlate with connection
+   records, and determine that subscriber 2 generated the traffic
+   (assuming that the public safety timestamp matches the operator
+   timestamp.  As noted in RFC 6292 [RFC6292], accurate timekeeping
+   (e.g., use of NTP or Simple NTP) is vital).
+
+   In this example, there are no log entries for the majority of
+   subscribers, who only use pre-allocated ports.  Only minimal logging
+   would be needed for those few subscribers who exceed their pre-
+   allocated ports and obtain extra bulk port assignments from the
+   dynamic pool.  Logging data for those users will include inside
+   address, outside address, outside port range, and timestamp.
+
+   Note that in a production environment, operators are encouraged to
+   consider [RFC6598] for assigning inside addresses.
+
+3.  Additional Logging Considerations
+
+   In order to be able to identify a subscriber based on observed
+   external IPv4 address, port, and timestamp, an operator needs to know
+   how the CGN was configured with regard to internal and external IP
+   addresses, dynamic address pool factor, maximum ports per user, and
+   reserved port range at any given time.  Therefore, the CGN MUST
+   generate a record any time such variables are changed.  The CGN
+   SHOULD generate a log message any time such variables are changed.
+   The CGN MAY keep such a record in the form of a router configuration
+   file.  If the CGN does not generate a log message, it would be up to
+
+
+
+Donley, et al.                Informational                     [Page 9]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+   the operator to maintain version control of router config changes.
+   Also, the CGN SHOULD generate such a log message once per day to
+   facilitate quick identification of the relevant configuration in the
+   event of an abuse notification.
+
+   Such a log message MUST, at minimum, include the timestamp, inside
+   prefix I, inside mask, outside prefix O, outside mask, D, M, A, and
+   reserved port list R; for example:
+
+   [Wed Oct 11 14:32:52
+   2000]:198.51.100.0:28:192.0.2.0:32:2:5040:0:1-1023,5004,5060.
+
+3.1.  Failover Considerations
+
+   Due to the deterministic nature of algorithmically assigned
+   translations, no additional logging is required during failover
+   conditions provided that inside address ranges are unique within a
+   given failover domain.  Even when directed to a different CGN server,
+   translations within the deterministic port range on either the
+   primary or secondary server can be algorithmically reversed, provided
+   the algorithm is known.  Thus, if 198.51.100.1 port 3456 maps to
+   192.0.2.1 port 1000 on CGN 1 and 198.51.100.1 port 1000 on Failover
+   CGN 2, an operator can identify the subscriber based on outside
+   source address and port information.
+
+   Similarly, assignments made from the dynamic overflow pool need to be
+   logged as described above, whether translations are performed on the
+   primary or failover CGN.
+
+4.  Impact on the IPv6 Transition
+
+   The solution described in this document is applicable to CGN
+   transition technologies (e.g., NAT444, DS-Lite, and NAT64).  As
+   discussed in [RFC7021], the authors acknowledge that native IPv6 will
+   offer subscribers a better experience than CGN.  However, many
+   Customer Premises Equipment (CPE) devices only support IPv4.
+   Likewise, as of October 2014, only approximately 5.2% of the top 1
+   million websites were available using IPv6.  Accordingly,
+   Deterministic CGN should in no way be understood as making CGN a
+   replacement for IPv6 service; however, until such time as IPv6
+   content and devices are widely available, Deterministic CGN will
+   provide operators with the ability to quickly respond to public
+   safety requests without requiring excessive infrastructure,
+   operations, and bandwidth to support per-connection logging.
+
+
+
+
+
+
+
+Donley, et al.                Informational                    [Page 10]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+5.  Privacy Considerations
+
+   The algorithm described above makes it easier for SPs and public
+   safety officials to identify the IP address of a subscriber through a
+   CGN system.  This is the equivalent level of privacy users could
+   expect when they are assigned a public IP address and their traffic
+   is not translated.  However, this algorithm could be used by other
+   actors on the Internet to map multiple transactions to a single
+   subscriber, particularly if ports are distributed sequentially.
+   While still preserving traceability, subscriber privacy can be
+   increased by using one of the other values of the Address Assignment
+   Algorithm (A), which would require interested parties to know more
+   about the Service Provider's CGN configuration to be able to tie
+   multiple connections to a particular subscriber.
+
+6.  Security Considerations
+
+   The security considerations applicable to NAT operation for various
+   protocols as documented in, for example, RFC 4787 [RFC4787] and RFC
+   5382 [RFC5382] also apply to this document.
+
+   Note that, with the possible exception of cryptographically based
+   port allocations, attackers could reverse-engineer algorithmically
+   derived port allocations to either target a specific subscriber or to
+   spoof traffic to make it appear to have been generated by a specific
+   subscriber.  However, this is exactly the same level of security that
+   the subscriber would experience in the absence of CGN.  CGN is not
+   intended to provide additional security by obscurity.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
+              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+              RFC 4787, January 2007,
+              <http://www.rfc-editor.org/info/rfc4787>.
+
+   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
+              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
+              RFC 5382, October 2008,
+              <http://www.rfc-editor.org/info/rfc5382>.
+
+
+
+
+
+Donley, et al.                Informational                    [Page 11]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+   [RFC6264]  Jiang, S., Guo, D., and B. Carpenter, "An Incremental
+              Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
+              June 2011, <http://www.rfc-editor.org/info/rfc6264>.
+
+   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
+              Roberts, "Issues with IP Address Sharing", RFC 6269, June
+              2011, <http://www.rfc-editor.org/info/rfc6269>.
+
+7.2.  Informative References
+
+   [L2NAT]    Miles, D. and M. Townsley, "Layer2-Aware NAT", Work in
+              Progress, draft-miles-behave-l2nat-00, March 2009.
+
+   [LOG-REDUCTION]
+              Tsou, T., Li, W., Taylor, T., and J. Huang, "Port
+              Management To Reduce Logging In Large-Scale NATs", Work in
+              Progress, draft-tsou-behave-natx4-log-reduction-04, July
+              2013.
+
+   [NAT-LOGGING]
+              Sivakumar, S. and R. Penno, "IPFIX Information Elements
+              for logging NAT Events", Work in Progress,
+              draft-ietf-behave-ipfix-nat-logging-04, July 2014.
+
+   [NAT444]   Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
+              and H. Ashida, "NAT444", Work in Progress,
+              draft-shirasaki-nat444-06, July 2012.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, April 2011,
+              <http://www.rfc-editor.org/info/rfc6146>.
+
+   [RFC6292]  Hoffman, P., "Requirements for a Working Group Charter
+              Tool", RFC 6292, June 2011,
+              <http://www.rfc-editor.org/info/rfc6292>.
+
+   [RFC6302]  Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
+              "Logging Recommendations for Internet-Facing Servers", BCP
+              162, RFC 6302, June 2011,
+              <http://www.rfc-editor.org/info/rfc6302>.
+
+   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+              Stack Lite Broadband Deployments Following IPv4
+              Exhaustion", RFC 6333, August 2011,
+              <http://www.rfc-editor.org/info/rfc6333>.
+
+
+
+
+
+Donley, et al.                Informational                    [Page 12]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
+              Cheshire, "Internet Assigned Numbers Authority (IANA)
+              Procedures for the Management of the Service Name and
+              Transport Protocol Port Number Registry", BCP 165, RFC
+              6335, August 2011,
+              <http://www.rfc-editor.org/info/rfc6335>.
+
+   [RFC6431]  Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and
+              T. Tsou, "Huawei Port Range Configuration Options for PPP
+              IP Control Protocol (IPCP)", RFC 6431, November 2011,
+              <http://www.rfc-editor.org/info/rfc6431>.
+
+   [RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
+              M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
+              Space", BCP 153, RFC 6598, April 2012,
+              <http://www.rfc-editor.org/info/rfc6598>.
+
+   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
+              Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
+              2013, <http://www.rfc-editor.org/info/rfc6887>.
+
+   [RFC7021]  Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J.
+              Doshi, "Assessing the Impact of Carrier-Grade NAT on
+              Network Applications", RFC 7021, September 2013,
+              <http://www.rfc-editor.org/info/rfc7021>.
+
+Acknowledgements
+
+   The authors would like to thank the following people for their
+   suggestions and feedback: Bobby Flaim, Lee Howard, Wes George, Jean-
+   Francois Tremblay, Mohammed Boucadair, Alain Durand, David Miles,
+   Andy Anchev, Victor Kuarsingh, Miguel Cros Cecilia, Fred Baker, Brian
+   Carpenter, and Reinaldo Penno.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donley, et al.                Informational                    [Page 13]
+
+RFC 7422                    deterministic-cgn              December 2014
+
+
+Authors' Addresses
+
+   Chris Donley
+   CableLabs
+   858 Coal Creek Cir
+   Louisville, CO  80027
+   United States
+
+   EMail: c.donley@cablelabs.com
+
+
+   Chris Grundemann
+   Internet Society
+   Denver, CO
+   United States
+
+   EMail: cgrundemann@gmail.com
+
+
+   Vikas Sarawat
+   CableLabs
+   858 Coal Creek Cir
+   Louisville, CO  80027
+   United States
+
+   EMail: v.sarawat@cablelabs.com
+
+
+   Karthik Sundaresan
+   CableLabs
+   858 Coal Creek Cir
+   Louisville, CO  80027
+   United States
+
+   EMail: k.sundaresan@cablelabs.com
+
+
+   Olivier Vautrin
+   Juniper Networks
+   1194 N Mathilda Avenue
+   Sunnyvale, CA  94089
+   United States
+
+   EMail: olivier@juniper.net
+
+
+
+
+
+
+
+Donley, et al.                Informational                    [Page 14]
+