From: <internet-drafts <at> ietf.org>
Date: July 2, 2012 11:55:12 PM PDT
To: <cathy.zhou <at> huawei.com>
Cc: <tina.tsou.zouting <at> huawei.com>, <18918588897 <at> 189.cn>
Subject: New Version Notification for draft-zhou-behave-syslog-nat-logging-00.txt

A new version of I-D, draft-zhou-behave-syslog-nat-logging-00.txt
has been successfully submitted by Cathy Zhou and posted to the
IETF repository.

Filename:     draft-zhou-behave-syslog-nat-logging
Revision:     00
Title:         The Syslog Requirements to Support NAT Log in Traceback Solutions
Creation date:     2012-07-03
WG ID:         Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-zhou-behave-syslog-nat-logging-00.txt
Status:          http://datatracker.ietf.org/doc/draft-zhou-behave-syslog-nat-logging
Htmlized:        http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00


Abstract:
  This document describes the syslog information that are required for
  NAT logging.  The document will define the NAT logging server which
  supports traceback and explain the procedure of network location and
  service support for traceback.  The requirements of syslog interface
  and Radius interface to support NAT log are introduced.




The IETF Secretariat

<div>
<div>For your comments.<br><br>
Tina</div>
<div>
<br>
Begin forwarded message:<br><br>
</div>
<blockquote type="cite">
<div>From: &lt;<a href="mailto:internet-drafts <at> ietf.org">internet-drafts <at> ietf.org</a>&gt;<br>Date: July 2, 2012 11:55:12 PM PDT<br>To: &lt;<a href="mailto:cathy.zhou <at> huawei.com">cathy.zhou <at> huawei.com</a>&gt;<br>Cc: &lt;<a href="mailto:tina.tsou.zouting <at> huawei.com">tina.tsou.zouting <at> huawei.com</a>&gt;, &lt;<a href="mailto:18918588897 <at> 189.cn">18918588897 <at> 189.cn</a>&gt;<br>Subject: New Version Notification for draft-zhou-behave-syslog-nat-logging-00.txt<br><br>
</div>
</blockquote>
<div></div>
<blockquote type="cite">
<div>
<span></span><br><span>A new version of I-D, draft-zhou-behave-syslog-nat-logging-00.txt</span><br><span>has been successfully submitted by Cathy Zhou and posted to the</span><br><span>IETF repository.</span><br><span></span><br><span>Filename: &nbsp; &nbsp; draft-zhou-behave-syslog-nat-logging</span><br><span>Revision: &nbsp; &nbsp; 00</span><br><span>Title: &nbsp; &nbsp; &nbsp; &nbsp; The Syslog Requirements to Support NAT Log in Traceback Solutions</span><br><span>Creation date: &nbsp; &nbsp; 2012-07-03</span><br><span>WG ID: &nbsp; &nbsp; &nbsp; &nbsp; Individual Submission</span><br><span>Number of pages: 12</span><br><span>URL: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://www.ietf.org/internet-drafts/draft-zhou-behave-syslog-nat-logging-00.txt">http://www.ietf.org/internet-drafts/draft-zhou-behave-syslog-nat-logging-00.txt</a></span><br><span>Status: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://datatracker.ietf.org/doc/draft-zhou-behave-syslog-nat-logging">http://datatracker.ietf.org/doc/draft-zhou-behave-syslog-nat-logging</a></span><br><span>Htmlized: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00">http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00</a></span><br><span></span><br><span></span><br><span>Abstract:</span><br><span>&nbsp;&nbsp;This document describes the syslog information that are required for</span><br><span>&nbsp;&nbsp;NAT logging. &nbsp;The document will define the NAT logging server which</span><br><span>&nbsp;&nbsp;supports traceback and explain the procedure of network location and</span><br><span>&nbsp;&nbsp;service support for traceback. &nbsp;The requirements of syslog interface</span><br><span>&nbsp;&nbsp;and Radius interface to support NAT log are introduced.</span><br><span></span><br><span></span><br><span></span><br><span></span><br><span>The IETF Secretariat</span><br>
</div>
</blockquote>
</div>

Hi  Chen：

   I have read the draft about NAT syslog logging. Here are two questions.

   1) In section 1.1 you summarize 4 solution, I think the content of draft is about the first solution, am I right?

   2) The draft wants to  present us a kind of message format or even a kind of log format about NAT syslog . Is it the key of the text?

Thanks,
W. Meng

-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

<div>
<br>Hi &nbsp;Chen&#65306;
<br><br>&nbsp; &nbsp;I have read the draft about
NAT syslog logging. Here are two questions.
<br><br>&nbsp; &nbsp;1) In section 1.1 you summarize
4 solution, I think the content of draft is about the first solution, am
I right?
<br><br>&nbsp; &nbsp;2) The draft wants to &nbsp;present
us a kind of message format or even a kind of log format about NAT syslog
. Is it the key of the text?
<br><br>Thanks,
<br>W. Meng
<br><br>
--------------------------------------------------------
ZTE&nbsp;Information&nbsp;Security&nbsp;Notice:&nbsp;The&nbsp;information&nbsp;contained&nbsp;in&nbsp;this&nbsp;mail&nbsp;(and&nbsp;any&nbsp;attachment&nbsp;transmitted&nbsp;herewith)&nbsp;is&nbsp;privileged&nbsp;and&nbsp;confidential&nbsp;and&nbsp;is&nbsp;intended&nbsp;for&nbsp;the&nbsp;exclusive&nbsp;use&nbsp;of&nbsp;the&nbsp;addressee(s).&nbsp;&nbsp;If&nbsp;you&nbsp;are&nbsp;not&nbsp;an&nbsp;intended&nbsp;recipient,&nbsp;any&nbsp;disclosure,&nbsp;reproduction,&nbsp;distribution&nbsp;or&nbsp;other&nbsp;dissemination&nbsp;or&nbsp;use&nbsp;of&nbsp;the&nbsp;information&nbsp;contained&nbsp;is&nbsp;strictly&nbsp;prohibited.&nbsp;&nbsp;If&nbsp;you&nbsp;have&nbsp;received&nbsp;this&nbsp;mail&nbsp;in&nbsp;error,&nbsp;please&nbsp;delete&nbsp;it&nbsp;and&nbsp;notify&nbsp;us&nbsp;immediately.

</div>

On 2012-07-09 11:03, George, Wes wrote:

While the NAT specified by this

document itself may only act on IPv4 traffic, as you note above it's

not limited to just NAT444 or even an IPv4-only *network*. The

recommendations in this doc will work for an IPv4 NAT associated with

DSLite just as easily as a more traditional IPv4 transport. This is

an important distinction, IMO.

Right, I understand now. It's the logical NAT function that is IPv4-only, not the global use case. I'll add some text to make this clear, and I'll specifically point out the DS-Lite example.

How about "Common Requirements for IPv4 Carrier Grade NATs

(CGNs)"?

[WEG] This helps, but only in conjunction with additional

clarification about the application - that is, just because the NAT

is IPv4-only doesn't mean that the network must also be IPv4-only.

Understood.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
_______________________________________________
sunset4 mailing list
sunset4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/sunset4

<div>
<div>
<div>There are few things that in my opinion should be added.</div>
<div>&nbsp;</div>
<div>First, the port numbers to be allocated to CPE. Excluding Well known port numbers should be mentioned. Moreover if port numbers are allocated to each CPE, what is the criteria for allocation. As mentioned in the document : &ldquo; There should be no limit on
 the size of the address pool&rdquo;, does this address pool imply the one that would be allocated to the CPE? According to the requirement of the CPE, the pool should be allocated or a fixed number of addresses in the address pool should be allocated to each CPE?
 Some amount of clarity in this respect would be helpful.</div>
<div>&nbsp;</div>
<div>Moreover, the document advocates the use of Endpoint independent filtering. If AID is used, there would be a delay of 120 seconds for each port reallocation. So should EIF be used only with those applications that can&rsquo;t function without it, instead of
 applying it for all.</div>
<div>&nbsp;</div>
<div>The need to maintain a record or database of the allocated ports and their lifetime would be helpful. If this is maintained, the ports that are near to expiring their lifetime would be considered first and allocated before and in a order. In such
 cases there will be less chances of the traffic being dropped due to ports not being available. There should be a definite lifetime defined, before connection is refused due to unavailability of ports. If there is a threshold of say,180 seconds, during which
 allocated ports database can be scanned and if any ports is recently available, can be allocated. This would lead to efficient use of ports.</div>
<br>
Tina</div>
<div>
<br>
On Jul 9, 2012, at 8:08 AM, "Simon Perreault" &lt;<a href="mailto:simon.perreault <at> viagenie.ca">simon.perreault <at> viagenie.ca</a>&gt; wrote:<br><br>
</div>
<div></div>
<blockquote type="cite">
<div>
<span>On 2012-07-09 11:03, George, Wes wrote:</span><br><blockquote type="cite">
<span>While the NAT specified by this</span><br>
</blockquote>
<blockquote type="cite">
<span>document itself may only act on IPv4 traffic, as you note above it's</span><br>
</blockquote>
<blockquote type="cite">
<span>not limited to just NAT444 or even an IPv4-only *network*. The</span><br>
</blockquote>
<blockquote type="cite">
<span>recommendations in this doc will work for an IPv4 NAT associated with</span><br>
</blockquote>
<blockquote type="cite">
<span>DSLite just as easily as a more traditional IPv4 transport. This is</span><br>
</blockquote>
<blockquote type="cite">
<span>an important distinction, IMO.</span><br>
</blockquote>
<span></span><br><span>Right, I understand now. It's the logical NAT function that is IPv4-only, not the global use case. I'll add some text to make this clear, and I'll specifically point out the DS-Lite example.</span><br><span></span><br><blockquote type="cite">
<blockquote type="cite">
<span>How about "Common Requirements for IPv4 Carrier Grade NATs</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<span>(CGNs)"?</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<span>[WEG] This helps, but only in conjunction with additional</span><br>
</blockquote>
<blockquote type="cite">
<span>clarification about the application - that is, just because the NAT</span><br>
</blockquote>
<blockquote type="cite">
<span>is IPv4-only doesn't mean that the network must also be IPv4-only.</span><br>
</blockquote>
<span></span><br><span>Understood.</span><br><span></span><br><span>Simon</span><br><span>-- </span><br><span>DTN made easy, lean, and smart --&gt; <a href="http://postellation.viagenie.ca">
http://postellation.viagenie.ca</a></span><br><span>NAT64/DNS64 open-source &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--&gt; <a href="http://ecdysis.viagenie.ca">http://ecdysis.viagenie.ca</a></span><br><span>STUN/TURN server &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--&gt; <a href="http://numb.viagenie.ca">http://numb.viagenie.ca</a></span><br><span>_______________________________________________</span><br><span>sunset4 mailing list</span><br><span><a href="mailto:sunset4 <at> ietf.org">sunset4 <at> ietf.org</a></span><br><span><a href="https://www.ietf.org/mailman/listinfo/sunset4">https://www.ietf.org/mailman/listinfo/sunset4</a></span><br>
</div>
</blockquote>
</div>