One document matched: draft-tsou-behave-natx4-log-reduction-01.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-01"
     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="NATx4 Log Reduction">Port Management To Reduce Logging In
       Large-Scale NATs</title>

    <author fullname="Tina Tsou" initials="T." surname="Tsou" role="editor">
      <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>Transport</area>

    <workgroup>Behavior Engineering for Hindrance Avoidance</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 IPv6 transition strategies require the introduction of large
        -scale NATs (e.g. AFTR, 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.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
        During the IPv6 transition period, some large-scale NAT devices may
       be introduced, e.g. DS-Lite AFTR, NAT64. 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), etc. If the connection is ICMP, a  mapping entry may include
       source IP address, couverted source IP address, source identifier, converted
       source identifier, 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 or one year <xref target="I-D.ietf-intarea-shared-addressing-issues"/>, 
        so the NAT device needs to generate logs for mapping entries in addition 
        to other information. 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 is stored locally or sent to a log storage server.
      </t>
   


      <t>
        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 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 block. 
        When the NAT 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 NAT can allocate 
        another port block, ports 3000~3050, to the user's resource pool. 
        Again , just one log needs to be generated for this port block.
        A log may contain the following information: source IP address, converted
        source IP address, port range, start time, end time, and some other necessary
        information.   
      </t>

      <t> 
        There is an alternative way of allocating port blocks <xref target="I-D.bajko-pripaddrassign"/>. 
        The ports in a block do not have to be continuous, due to security
        concerns; the port numbers could be worked out using some random algorithm 
        along with some initial parameters. When generating a log message, these 
        parameters instead of the port range would be included in the log.  
      </t>

      <t> 
        If some port block is not used for some configurable time, e.g. TBD minutes, 
        after initial allocation or after the mapping timer has expired 
        for every port in the block, the NAT can remove the port block 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>

      <t>
        In some case <xref target="I-D.ietf-intarea-shared-addressing-issues"/>, 
        a server may not record the source port of a connection, and NAT device 
        needs to record the destination IP address of a connection. In such 
        a case, the suggested solution is not applicable. But a reasonable solution 
        is still for the server to record the source port.
      </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>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
        Mohamed Boucadair reviewed the document and provided useful comments to improve it.
      </t>
    </section>

  </middle>

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

  <back>
    <references title="Normative References">

      <reference anchor="I-D.ietf-intarea-shared-addressing-issues">
        <front>
          <title>Issues with IP Address Sharing (Work in progress)</title>
  
          <author initials="M." surname="Ford">
            <organization>Internet Society</organization>
          </author>
  
          <author initials="M." surname="Boucadair">
            <organization>France Telecom</organization>
          </author>
  
          <author initials="A." surname="Durand">
            <organization>Juniper Networks</organization>
          </author>
  
          <author initials="P." surname="Levis">
            <organization>France Telecom</organization>
          </author>

          <author initials="P." surname="Roberts">
            <organization>Internet Society</organization>
          </author>
  
          <date month="June" year="2010" />
        </front>
      </reference>

      <reference anchor="I-D.bajko-pripaddrassign">
        <front>
          <title>Port Restricted IP Address Assignment (Work in progress)</title>
  
          <author initials="G." surname="Bajko">
            <organization>Nokia</organization>
          </author>
  
          <author initials="T." surname="Savolainen">
            <organization>Nokia</organization>
          </author>
  
          <author initials="M." surname="Boucadair">
            <organization>France Telecom</organization>
          </author>
  
          <author initials="P." surname="Levis">
            <organization>France Telecom</organization>
          </author>
  
          <date month="October" year="2009" />
        </front>
      </reference>

    </references>

    <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="July" year="2010" />
        </front>
      </reference>
    </references>

  </back>
</rfc>