Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments
RFC 7422
| Document | Type |
RFC - Informational
(December 2014; Errata)
Was draft-donley-behave-deterministic-cgn (individual)
|
|
|---|---|---|---|
| Last updated | 2014-12-29 | ||
| Stream | ISE | ||
| Formats | plain text pdf html bibtex | ||
| IETF conflict review | conflict-review-donley-behave-deterministic-cgn | ||
| Stream | ISE state | Published RFC | |
| Consensus Boilerplate | Unknown | ||
| Document shepherd | Adrian Farrel | ||
| 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 IANA Actions | ||
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
Show full document text