Port Management to Reduce Logging in Large-Scale NATs
RFC 7768
| Document | Type |
RFC - Informational
(January 2016; No errata)
Was draft-tsou-behave-natx4-log-reduction (individual)
|
|
|---|---|---|---|
| Last updated | 2016-01-29 | ||
| Stream | ISE | ||
| Formats | plain text html pdf htmlized bibtex | ||
| IETF conflict review | conflict-review-tsou-behave-natx4-log-reduction | ||
| Stream | ISE state | Published RFC | |
| Consensus Boilerplate | Unknown | ||
| Document shepherd | Adrian Farrel | ||
| Shepherd write-up | Show (last changed 2015-05-04) | ||
| IESG | IESG state | RFC 7768 (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 T. Tsou
Request for Comments: 7768 Philips Lighting
Category: Informational W. Li
ISSN: 2070-1721 China Telecom
T. Taylor
J. Huang
Huawei Technologies
January 2016
Port Management to Reduce Logging in Large-Scale NATs
Abstract
Various IPv6 transition strategies require the introduction of large-
scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4
addresses available in the network until transition is complete.
There has recently been debate over how to manage the sharing of
ports between different subscribers sharing the same IPv4 address.
One factor in the discussion is the operational requirement to log
the assignment of transport addresses to subscribers. It has been
argued that dynamic assignment of individual ports between
subscribers requires the generation of an excessive volume of logs.
This document suggests a way to achieve dynamic port sharing while
keeping log volumes low.
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/rfc7768.
Tsou, et al. Informational [Page 1]
RFC 7768 NATx4 Log Reduction January 2016
Copyright Notice
Copyright (c) 2016 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
2. A Suggested Solution . . . . . . . . . . . . . . . . . . . . 3
3. Issues Of Traceability . . . . . . . . . . . . . . . . . . . 4
4. Other Considerations . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Appendix A. Configure Server Software to Log Source Port . . . . 9
A.1. Apache . . . . . . . . . . . . . . . . . . . . . . . . . 9
A.2. Postfix . . . . . . . . . . . . . . . . . . . . . . . . . 9
A.3. Sendmail . . . . . . . . . . . . . . . . . . . . . . . . 9
A.4. sshd . . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.5. Cyrus IMAP and UW IMAP . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
During the IPv6 transition period, some large-scale NAT devices may
be introduced, e.g., Dual-Stack Lite (DS-Lite), Address Family
Transition Router (AFTR), and NAT64. When a NAT device needs to set
up a new connection for a given internal address behind the NAT, it
needs to create a new mapping entry for the new connection, which
will contain source IP address, source port or ICMP identifier,
converted source IP address, converted source port, protocol (TCP/
UDP), etc.
Due to legislation and law enforcement requirement, sometimes it is
necessary to log these mappings for a period of time, such as 6
months. The mapping information is highly privacy sensitive; if
possible, the information should be deleted as soon as possible.
Some high-performance NAT devices may need to create a large amount
of new sessions per second. If logs are generated for each mapping
entry, the log traffic could reach tens of megabytes per second or
more, which would be a problem for log generation, transmission and
Tsou, et al. Informational [Page 2]
RFC 7768 NATx4 Log Reduction January 2016
storage. According to a test discussed in "Analysis of NAT64 Port
Show full document text