Port Management To Reduce Logging In Large-Scale NATs
draft-tsou-behave-natx4-log-reduction-00

Abstract

Various V6 transition strategies require the introduction of large-scale NATs (NAT444, 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 assigned 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 sharing of 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on February 25, 2011.

Copyright Notice

Copyright (c) 2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  A Suggested Solution
3.  IANA Considerations
4.  Security Considerations
5.  Informative References
§  Authors' Addresses

1.  Introduction

During the IPv6 transition period, some large-scale NAT devices may be introduced, e.g. NAT444 (CGN - Carrier Grade NAT), NAT64, etc. When a NAT device needs to set up a new connection for the user behind the NAT, it needs to create a new mapping entry for the new connection, which will contain source IP address, source port, converted source IP address, converted source port, protocol(TCP/UDP/ICMP), etc.

For the purpose of troubleshooting, and also required by regulations, operators must keep logs of network NAT mapping entries for a period of time, e.g. 6 months, so the NAT device needs to generate logs for mapping entries. A traditional method is to generate a log for each mapping entry. When a connection expires, the mapping entry will be deleted, and the corresponding log will be sent to a log storage server.

Some high performance CGN devices may need to create a million or more new sessions per second. If logs are generated for each mapping entry, the log traffic could reach fifty megabytes per second or more, which would be a problem for log generation, transmission and storage.

To reduce the cost of log storage, [I‑D.nishitani‑cgn] (Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, “Common requirements for IP address sharing schemes (Work in progress),” July 2010.) proposes to fix the port range for each user/CPE, and only one log will be generated for each user. But this would significantly reduce the number of subscribers that could share a public IP address, as discussed in [I‑D.softwire‑dual‑stack‑lite] (Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (Work in progress),” August 2010.).

1.1.  Requirements Language

This draft includes no requirements language.

2.  A Suggested Solution

We propose a solution that allows dynamic sharing of port ranges between users while minimizing the number of logs that have to be generated. Briefly, ports are allocated to the user in blocks. Logs are generated only when blocks are allocated or deallocated. This provides the necessary traceability while reducing log generation by a factor equal to the block size, as compared with fully dynamic port allocation.

Here is how the proposal would work in greater detail. When the user sends out the first packet, a port resource pool is allocated for the user, e.g. assign ports 2000~2300 of a public IP address to the user's resource pool. Only one log should be generated for this port segment. When the CGN needs to set up a new mapping entry for the user, it can use a port in the user's resource pool and the corresponding public IP address. If the user needs more port resources, the CGN can allocate another port segment, ports 3000~3050, to the user's resource pool. Again , just one log needs to be generated for this port segment.

If some port segment is not used for some configurable time, e.g., one minute, after initial allocation or after the mapping timer has expired for every port in the segment, the CGN can remove the port segment from the user's resource pool, and make it available for other users. The deallocation is logged when it occurs.

This solution can reduce the number of logs significantly and also make good use of the public IP address resource.

3.  IANA Considerations

This memo includes no request to IANA.

4.  Security Considerations

The security considerations applicable to NAT operation for various protocols as documented in, for example, [RFC4787] (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) and [RFC5382] (Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, “NAT Behavioral Requirements for TCP,” October 2008.) also apply to this proposal.

5. Informative References

Authors' Addresses