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

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4787 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC5382 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5382.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-
Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-tsou-behave-natx4-log-reduction-00"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902,
noDerivativesTrust200902,
        or pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only
necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Abbreviated Title">Port Management To Reduce Logging In 
       Large-Scale NATs</title>

    <author fullname="Tina Tsou" initials="T." 
            surname="Tsou">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Bantian, Longgang District</street>

          <!-- Reorder these if your country does things differently -->

          <city>Shenzhen</city>

          <code>518129</code>

          <country>P.R. China</country>
        </postal>

        <phone></phone>

        <email>tena@huawei.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Tom Taylor" initials="T." 
            surname="Taylor">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>1852 Lorraine Ave.</street>

          <!-- Reorder these if your country does things differently -->

          <city>Ottawa</city>

          <code>K1H 6Z8</code>

          <country>Canada</country>
        </postal>

        <phone></phone>

        <email>tom111.taylor@bell.net</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2010" />

    <!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current year is
specified, xml2rfc will fill in the current day and month for you. If the year
is not the current one, it is necessary to specify at least a month (xml2rfc
assumes day="1" if not specified for the purpose of calculating the expiry
date).  With drafts it is normally sufficient to specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -
->

    <keyword></keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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.</t>

   <t>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.</t>   
   
<t>   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.</t>
   
<t>To reduce the cost of log storage, <xref target="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 
   <xref target="I-D.softwire-dual-stack-lite"/>.</t>

      <section title="Requirements Language">
        <t>This draft includes no requirements language.</t>
      </section>
    </section>

<section anchor="proposal" title="A Suggested Solution">

<t>   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.</t>

<t> 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.</t>

<t> 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.</t>
   
   <t>This solution can reduce the number of logs significantly and also make 
   good use of the public IP address resource.</t>

</section><!-- proposal -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations applicable to NAT operation
      for various protocols as documented in, for example, 
      <xref target="RFC4787"/> and <xref target="RFC5382"/> also
      apply to this proposal. </t>

    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

    <references title="Informative References">

&RFC4787;
&RFC5382;

      <reference anchor="I-D.nishitani-cgn">
        <front>
          <title>Common requirements for IP address sharing schemes
(Work in progress)</title>

          <author initials="I." surname="Yamagata">
            <organization>NTT Communications</organization>
          </author>

          <author initials="S." surname="Miyakawa">
            <organization>NTT Communications</organization>
          </author>

          <author initials="A." surname="Nakagawa">
            <organization>Japan Internet Exchange (JPIX)</organization>
          </author>

          <author initials="H." surname="Ashida">
            <organization>iTSCOM</organization>
          </author>

          <date month="July" year="2010" />
        </front>
      </reference>

      <reference anchor="I-D.softwire-dual-stack-lite">
        <front>
          <title>Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
(Work in progress)</title>

          <author initials="A." surname="Durand">
            <organization>Juniper Networks</organization>
          </author>

          <author initials="R." surname="Droms">
            <organization>Cisco</organization>
          </author>

          <author initials="J." surname="Woodyatt">
            <organization>Apple</organization>
          </author>

          <author initials="Y." surname="Lee">
            <organization>Comcast</organization>
          </author>

          <date month="August" year="2010" />
        </front>
      </reference>
    </references>

  </back>
</rfc>