Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments
RFC 7422

 
Document Type RFC - Informational (December 2014; Errata)
Last updated 2014-12-29
Stream ISE
Formats plain text pdf html
IETF conflict review conflict-review-donley-behave-deterministic-cgn
Stream ISE state Published RFC
Document shepherd Nevil Brownlee
Shepherd write-up Show (last changed 2014-10-02)
IESG IESG state RFC 7422 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
IANA IANA review state Version Changed - Review Needed
IANA action state No IC
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
Show full document text