Port Management to Reduce Logging in Large-Scale NATs
RFC 7768

Document Type RFC - Informational (January 2016; No errata)
Last updated 2016-01-29
Stream ISE
Formats plain text pdf html bibtex
IETF conflict review conflict-review-tsou-behave-natx4-log-reduction
Stream ISE state Published RFC
Consensus Boilerplate Unknown
Document shepherd Nevil Brownlee
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 IC
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]
Show full document text