One document matched: draft-tsou-behave-natx4-log-reduction-00.txt

Internet Engineering Task Force                                  T. Tsou
Internet-Draft                                                 T. Taylor
Intended status: Informational                       Huawei Technologies
Expires: February 25, 2011                               August 24, 2010


         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



Tsou & Taylor           Expires February 25, 2011               [Page 1]

Internet-Draft              Abbreviated Title                August 2010


   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  A Suggested Solution  . . . . . . . . . . . . . . . . . . . . . 3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  Informative References  . . . . . . . . . . . . . . . . . . . . 4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5



































Tsou & Taylor           Expires February 25, 2011               [Page 2]

Internet-Draft              Abbreviated Title                August 2010


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] 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].

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



Tsou & Taylor           Expires February 25, 2011               [Page 3]

Internet-Draft              Abbreviated Title                August 2010


   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] and [RFC5382] also
   apply to this proposal.


5.  Informative References

   [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.

   [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.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,



Tsou & Taylor           Expires February 25, 2011               [Page 4]

Internet-Draft              Abbreviated Title                August 2010


              RFC 5382, October 2008.


Authors' Addresses

   Tina Tsou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Phone:
   Email: tena@huawei.com


   Tom Taylor
   Huawei Technologies
   1852 Lorraine Ave.
   Ottawa  K1H 6Z8
   Canada

   Phone:
   Email: tom111.taylor@bell.net




























Tsou & Taylor           Expires February 25, 2011               [Page 5]