Independent Submission T. Tsou
Request for Comments: 7768 Philips Lighting
Category: Informational W. Li
ISSN: 2070-1721 China Telecom
T. Taylor
J. Huang
Huawei Technologies
January 2016
Independent Submission T. Tsou
Request for Comments: 7768 Philips Lighting
Category: Informational W. Li
ISSN: 2070-1721 China Telecom
T. Taylor
J. Huang
Huawei Technologies
January 2016
Port Management to Reduce Logging in Large-Scale NATs
端口管理以减少大规模NAT中的日志记录
Abstract
摘要
Various IPv6 transition strategies require the introduction of large-scale NATs (e.g., AFTR and 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.
各种IPv6转换策略要求引入大规模NAT（如AFTR和NAT64），以共享网络中有限的可用IPv4地址，直到转换完成。最近就如何管理共享同一IPv4地址的不同订户之间的端口共享展开了辩论。讨论中的一个因素是记录传输地址分配给订户的操作要求。有人认为，在订户之间动态分配各个端口需要生成过多的日志。本文档提出了一种在保持低日志量的同时实现动态端口共享的方法。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7768.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7768.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. A Suggested Solution . . . . . . . . . . . . . . . . . . . . 3
3. Issues Of Traceability . . . . . . . . . . . . . . . . . . . 4
4. Other Considerations . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Appendix A. Configure Server Software to Log Source Port . . . . 9
A.1. Apache . . . . . . . . . . . . . . . . . . . . . . . . . 9
A.2. Postfix . . . . . . . . . . . . . . . . . . . . . . . . . 9
A.3. Sendmail . . . . . . . . . . . . . . . . . . . . . . . . 9
A.4. sshd . . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.5. Cyrus IMAP and UW IMAP . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. A Suggested Solution . . . . . . . . . . . . . . . . . . . . 3
3. Issues Of Traceability . . . . . . . . . . . . . . . . . . . 4
4. Other Considerations . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Appendix A. Configure Server Software to Log Source Port . . . . 9
A.1. Apache . . . . . . . . . . . . . . . . . . . . . . . . . 9
A.2. Postfix . . . . . . . . . . . . . . . . . . . . . . . . . 9
A.3. Sendmail . . . . . . . . . . . . . . . . . . . . . . . . 9
A.4. sshd . . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.5. Cyrus IMAP and UW IMAP . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
During the IPv6 transition period, some large-scale NAT devices may be introduced, e.g., Dual-Stack Lite (DS-Lite), Address Family Transition Router (AFTR), and NAT64. When a NAT device needs to set up a new connection for a given internal address behind the NAT, it needs to create a new mapping entry for the new connection, which will contain source IP address, source port or ICMP identifier, converted source IP address, converted source port, protocol (TCP/ UDP), etc.
在IPv6过渡期间，可能会引入一些大型NAT设备，例如双栈Lite（DS Lite）、地址族转换路由器（AFTR）和NAT64。当NAT设备需要为NAT后面的给定内部地址建立新连接时，它需要为新连接创建一个新的映射条目，该条目将包含源IP地址、源端口或ICMP标识符、转换的源IP地址、转换的源端口、协议（TCP/UDP）等。
Due to legislation and law enforcement requirement, sometimes it is necessary to log these mappings for a period of time, such as 6 months. The mapping information is highly privacy sensitive; if possible, the information should be deleted as soon as possible. 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
由于立法和执法要求，有时需要将这些映射记录一段时间，例如6个月。地图信息对隐私高度敏感；如果可能，应尽快删除这些信息。一些高性能NAT设备可能需要每秒创建大量新会话。如果为每个映射条目生成日志，则日志通信量可能达到每秒数十兆字节或更高，这对于日志生成、传输和恢复都是一个问题
storage. According to a test discussed in "Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses" [ALLOC-METHODS], in a network with 20,000 subscribers, over a 60-day period, the raw log size can reach 42.5 TB if it is based on per-session log, while the log size will be 40.6 GB if it is based on port blocks. Although compression technologies can be used before log storage, the log size is still big.
存储根据“共享IPv4地址的NAT64端口分配方法分析”[ALLOC-Methods]中讨论的一项测试，在一个拥有20000个订户的网络中，在60天的时间内，如果基于每个会话日志，原始日志大小可以达到42.5 TB，而如果基于端口块，日志大小将达到40.6 GB。虽然在日志存储之前可以使用压缩技术，但是日志大小仍然很大。
[RFC6888], REQ-13 suggests "maximize port utilization" and REQ-14 suggests "minimize log volume". However, it is difficult to achieve both; there will be a trade-off between the efficiency with which ports are used and the rate of generation of log records.
[RFC6888]，REQ-13建议“最大化端口利用率”，REQ-14建议“最小化日志容量”。然而，两者都难以实现；在使用端口的效率和日志记录的生成速率之间，需要进行权衡。
This document proposes 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.
本文档提出了一种解决方案，允许用户之间动态共享端口范围，同时最小化必须生成的日志数量。简单地说，端口以块的形式分配给用户。只有在分配或解除分配块时才会生成日志。与完全动态端口分配相比，这提供了必要的可跟踪性，同时将日志生成量减少了一个等于块大小的因子。
This is how the proposal works in greater detail. When the user sends out the first packet, a port resource pool is allocated for the user, e.g., assigning ports 2001~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, e.g., ports 3501~3800, to the user's resource pool. Again, just one log needs to be generated for this port block.
这是该提案更详细的运作方式。当用户发送第一分组时，为用户分配端口资源池，例如，将公共IP地址的端口2001～2300分配给用户的资源池。只应为此端口块生成一个日志。当NAT需要为用户设置新的映射条目时，它可以使用用户资源池中的端口和相应的公共IP地址。如果用户需要更多的端口资源，NAT可以向用户的资源池分配另一个端口块，例如端口3501~3800。同样，只需为此端口块生成一个日志。
[RFC6431] takes this idea further by allocating non-contiguous sets of ports using a pseudorandom function. Scattering the allocated ports in this way provides a modest barrier to port guessing attacks. The use of randomization is discussed further in Section 5.
[RFC6431]通过使用伪随机函数分配不连续的端口集，进一步发挥了这一思想。以这种方式分散分配的端口为端口猜测攻击提供了适度的障碍。第5节将进一步讨论随机化的使用。
Suppose now that a given internal address has been assigned more than one block of ports. The individual sessions using ports within a port block will start and end at different times. If no ports in some port block are used for some configurable time, the NAT can remove the port block from the resource pool allocated to a given internal address and make it available for other users. In theory, it is unnecessary to log deallocations of blocks of ports, because
现在假设一个给定的内部地址被分配了多个端口块。使用端口块中的端口的各个会话将在不同的时间开始和结束。如果某个端口块中的端口在某个可配置的时间内没有使用，NAT可以从分配给给定内部地址的资源池中删除该端口块，并使其可供其他用户使用。理论上，不需要记录端口块的释放，因为
the ports in deallocated blocks will not be used again until the blocks are reallocated. However, the deallocation may be logged when it occurs adding robustness to troubleshooting or other procedures.
在重新分配块之前，将不会再次使用解除分配块中的端口。但是，解除分配在发生时可能会被记录下来，从而增强故障排除或其他过程的健壮性。
The deallocation procedure presents a number of difficulties in practice. The first problem is the choice of timeout value for the block. If idle timers are applied for the individual mappings (sessions) within the block, and these conform to the recommendations for NAT behavior for the protocol concerned, then the additional time that might be configured as a guard for the block as a whole need not be more than a few minutes. The block timer in this case serves only as a slightly more conservative extension of the individual session idle timers. If, instead, a single idle timer is used for the whole block, it must itself conform to the recommendations for the protocol with which that block of ports is associated. For example, REQ-5 of [RFC5382] requires an idle timer expiry duration of at least 2 hours and 4 minutes for TCP.
解除分配程序在实践中存在许多困难。第一个问题是选择块的超时值。如果为块内的各个映射（会话）应用空闲计时器，并且这些空闲计时器符合有关协议的NAT行为建议，则可能配置为块整体防护的额外时间不需要超过几分钟。在这种情况下，块计时器仅作为单个会话空闲计时器的稍微保守的扩展。相反，如果对整个块使用单个空闲计时器，则它本身必须符合与该端口块关联的协议的建议。例如，[RFC5382]的REQ-5要求TCP的空闲计时器到期时间至少为2小时4分钟。
The next issue with port block deallocation is the conflict between the desire to randomize port allocation and the desire to make unused resources available to other internal addresses. As mentioned above, ideally port selection will take place over the entire set of blocks allocated to the internal address. However, taken to its fullest extent, such a policy will minimize the probability that all ports in any given block are idle long enough for it to be released.
端口块解除分配的下一个问题是随机端口分配与将未使用的资源提供给其他内部地址之间的冲突。如上所述，理想情况下，端口选择将在分配给内部地址的整个块集上进行。然而，在最大程度上，这种策略将最小化任何给定块中的所有端口空闲足够长时间以使其释放的可能性。
As an alternative, it is suggested that when choosing which block to select a port from, the NAT should omit from its range of choice the block that has been idle the longest, unless no ports are available in any of the other blocks. The expression "block that has been idle the longest" designates the block in which the time since the last packet was observed in any of its sessions, in either direction, is earlier than the corresponding time in any of the other blocks assigned to that internal address.
作为替代方案，建议在选择从哪个块选择端口时，NAT应从其选择范围中忽略空闲时间最长的块，除非在任何其他块中没有可用的端口。表达式“空闲时间最长的块”指定自在其任何会话中在任一方向上观察到最后一个分组以来的时间早于分配给该内部地址的任何其他块中的相应时间的块。
Section 12 of [RFC6269] provides a good discussion of the traceability issue. Complete traceability given the NAT-logging practices proposed in this document requires that the remote destination record the source port of a request along with the source address (and presumably protocol, if not implicit). In addition, the logs at each end must be timestamped, and the clocks must be synchronized within a certain degree of accuracy. Here is one reason for the guard timing on block release, to increase the tolerable level of clock skew between the two ends.
[RFC6269]第12节对可追溯性问题进行了很好的讨论。鉴于本文档中提出的NAT日志记录实践，完整的可追溯性要求远程目的地记录请求的源端口以及源地址（如果不是隐式的，则可能是协议）。此外，每一端的日志必须加上时间戳，并且时钟必须在一定的精度范围内同步。这是块释放时保护计时的一个原因，以增加两端之间的可容忍时钟偏差水平。
The ability to configure various server applications to record source ports has been investigated, with the following results:
研究了配置各种服务器应用程序以记录源端口的能力，结果如下：
o Source-port recording can be configured in Apache, Postfix, sendmail, and sshd. Please refer to the Appendix for the configuration guide.
o 源端口记录可以在Apache、Postfix、sendmail和sshd中配置。有关配置指南，请参阅附录。
o Source-port recording is not supported by IIS, Cyrus IMAP, and UW IMAP. But it should not be too difficult to get Cyrus IMAP and UW IMAP to support it by modifying the source code.
o IIS、Cyrus IMAP和UW IMAP不支持源端口录制。但是，通过修改源代码让Cyrus IMAP和UW IMAP支持它应该不会太困难。
Where source-port logging can be enabled, this memo strongly urges the operators to do so. Similarly, intrusion detection systems should capture source port as well as source address of suspect packets.
如果可以启用源端口日志记录，此备忘录强烈敦促操作员这样做。类似地，入侵检测系统应该捕获可疑数据包的源端口和源地址。
In some cases [RFC6269], a server may not record the source port of a connection. To allow traceability, the NAT device needs to record the destination IP address of a connection. As [RFC6269] points out, this will provide an incomplete solution to the issue of traceability because multiple users of the same shared public IP address may access the service at the same time. From the point of view of this document, in such situations the game is lost, so to speak, and port allocation at the NAT might as well be completely dynamic.
在某些情况下[RFC6269]，服务器可能不会记录连接的源端口。为了允许跟踪，NAT设备需要记录连接的目标IP地址。正如[RFC6269]所指出的，这将为可追溯性问题提供一个不完整的解决方案，因为具有相同共享公共IP地址的多个用户可能同时访问该服务。从本文的观点来看，在这种情况下，可以说游戏是失败的，NAT的端口分配也可能是完全动态的。
The final possibility to consider is where the NAT does not do per-session logging even given the possibility that the remote end is failing to capture source ports. In that case, the port allocation policy proposed in this document can be used. The impact on traceability is that analysis of the logs would yield only the list of all internal addresses mapped to a given public address during the period of time concerned. This has an impact on privacy as well as traceability, depending on the follow-up actions taken.
考虑到远程端未能捕获源端口的可能性，最后考虑的可能性是NAT不在每个会话日志中进行。在这种情况下，可以使用本文档中提出的端口分配策略。对可追溯性的影响是，对日志的分析只会产生在相关时间段内映射到给定公共广播的所有内部地址的列表。这会影响隐私和可追溯性，具体取决于采取的后续行动。
[RFC6269] notes several issues introduced by the use of dynamic, as opposed to static, port assignment. For example, Section 13.2 of that document notes the effect on authentication procedures. These issues must be resolved, but are not specific to the port allocation policy described in this document.
[RFC6269]注意到使用动态端口分配（相对于静态端口分配）带来的几个问题。例如，该文件第13.2节说明了对认证程序的影响。必须解决这些问题，但这些问题并不特定于本文档中描述的端口分配策略。
The discussion that follows addresses an issue that is particularly relevant to the proposal made in this document. The security considerations applicable to NAT operation for various protocols as documented in, for example, [RFC4787] and [RFC5382] also apply to this proposal.
下面的讨论涉及一个与本文件中的提案特别相关的问题。例如，[RFC4787]和[RFC5382]中记录的适用于各种协议NAT操作的安全注意事项也适用于本提案。
[RFC6056] summarizes the TCP port-guessing attack, by means of which an attacker can hijack one end of a TCP connection. One mitigating measure is to make the source port number used for a TCP connection less predictable. [RFC6056] provides various algorithms for this purpose.
[RFC6056]总结了TCP端口猜测攻击，通过这种攻击，攻击者可以劫持TCP连接的一端。一种缓解措施是降低TCP连接所用源端口号的可预测性。[RFC6056]为此提供了各种算法。
As Section 3.1 of that RFC notes: "...provided adequate algorithms are in use, the larger the range from which ephemeral ports are selected, the smaller the chances of an attacker are to guess the selected port number." Conversely, the reduced range sizes proposed by the present document increase the attacker's chances of guessing correctly. This result cannot be totally avoided. However, mitigating measures to improve this situation can be taken both at port-block assignment time and when selecting individual ports from the blocks that have been allocated to a given user.
如RFC第3.1节所述：“……如果使用了适当的算法，选择临时端口的范围越大，攻击者猜测所选端口号的机会就越小。”相反，本文档提出的缩小范围大小增加了攻击者正确猜测的机会。这一结果无法完全避免。但是，可以在端口块分配时以及从已分配给给定用户的块中选择单个端口时采取缓解措施来改善这种情况。
At assignment time, one possibility is to assign ports as non-contiguous sets of values as proposed in [RFC6431]. However, this approach creates a lot of complexity for operations, and the pseudorandomization can create uncertainty when the accuracy of logs is important to protect someone's life or liberty.
在分配时，一种可能性是按照[RFC6431]中的建议，将端口分配为非连续的值集。然而，这种方法给操作带来了很大的复杂性，当日志的准确性对于保护某人的生命或自由很重要时，伪随机化会产生不确定性。
Alternatively, the NAT can assign blocks of contiguous ports. However, at assignment time, the NAT could attempt to randomize its choice of which of the available idle blocks it would assign to a given user. This strategy has to be traded-off against the desirability of minimizing the chance of conflict between what [RFC6056] calls "transport protocol instances" by assigning the most-idle block, as suggested in Section 2. A compromise policy might be to assign blocks only if they have been idle for a certain amount of time, and select pseudorandomly between the blocks available according to this criterion. In this case, it is suggested that the time value used be greater than the guard timing mentioned in Section 2, and that no block should ever be reassigned until it has been idle at least for the duration given by the guard timer.
或者，NAT可以分配连续端口的块。然而，在分配时，NAT可以尝试随机选择将分配给给定用户的可用空闲块。如第2节所述，这种策略必须与通过分配最空闲的块来最小化[RFC6056]所称的“传输协议实例”之间冲突的可能性的可取性进行权衡。折衷策略可能是仅在块空闲一定时间时分配块，并根据此标准在可用块之间伪随机选择。在这种情况下，建议使用的时间值大于第2节中提到的保护定时，并且在至少在保护定时器给定的持续时间内空闲之前，不应重新分配任何块。
While the block assignment strategy can provide some mitigation of the port-guessing attack, the largest contribution will come from pseudorandomization at port-selection time. [RFC6056] provides a number of algorithms for achieving this pseudorandomization. When
虽然块分配策略可以在一定程度上缓解端口猜测攻击，但最大的贡献将来自端口选择时的伪随机化。[RFC6056]提供了许多实现这种伪随机化的算法。什么时候
the available ports are contained in blocks, which are not in general consecutive, the algorithms clearly need some adaptation. The task is complicated by the fact that the number of blocks allocated to the user may vary over time. Adaptation is left as an exercise for the implementor.
可用端口包含在块中，这些块通常不是连续的，算法显然需要一些自适应。分配给用户的块的数量可能随时间而变化，这使得任务变得复杂。适应是留给实施者的一项练习。
[ALLOC-METHODS] Chen, G., Li, W., Tsou, T., Huang, J., Taylor, T., and J. Tremblay, "Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses", Work in Progress, draft-ietf-sunset4-nat64-port-allocation-02, January 2016.
[ALLOC-METHODS]Chen，G.，Li，W.，Tsou，T.，Huang，J.，Taylor，T.，和J.Tremblay，“共享IPv4地址的NAT64端口分配方法分析”，正在进行的工作，草稿-ietf-sunset4-NAT64-Port-Allocation-022016年1月。
[APACHE_LOG_CONFIG] The Apache Software Foundation, "Apache Module mod_log_config", <http://httpd.apache.org/docs/2.4/mod/ mod_log_config.html>.
Apache eSoftware基金会，“Apache模块MODYLogLog-CONFIG”，<http://httpd.apache.org/docs/2.4/mod/ mod_log_config.html>。
[POSTFIX_LOG_CONFIG] "Postfix Configuration Parameters", <http://www.postfix.org/postconf.5.html>.
[POSTFIX\u LOG\u CONFIG]“POSTFIX配置参数”<http://www.postfix.org/postconf.5.html>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC4787]Audet，F.，Ed.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，DOI 10.17487/RFC4787，2007年1月<http://www.rfc-editor.org/info/rfc4787>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <http://www.rfc-editor.org/info/rfc5382>.
[RFC5382]Guha，S.，Ed.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，DOI 10.17487/RFC5382，2008年10月<http://www.rfc-editor.org/info/rfc5382>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.
[RFC6056]Larsen，M.和F.Gont，“运输协议端口随机化建议”，BCP 156，RFC 6056，DOI 10.17487/RFC6056，2011年1月<http://www.rfc-editor.org/info/rfc6056>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.
[RFC6269]福特，M.，Ed.，Boucadair，M.，Durand，A.，Levis，P.，和P.Roberts，“IP地址共享问题”，RFC 6269，DOI 10.17487/RFC62692011年6月<http://www.rfc-editor.org/info/rfc6269>.
[RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and T. Tsou, "Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)", RFC 6431, DOI 10.17487/RFC6431, November 2011, <http://www.rfc-editor.org/info/rfc6431>.
[RFC6431]Boucadair，M.，Levis，P.，Bajko，G.，Savolainen，T.，和T.Tsou，“华为PPP IP控制协议（IPCP）的端口范围配置选项”，RFC 6431，DOI 10.17487/RFC6431，2011年11月<http://www.rfc-editor.org/info/rfc6431>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC6888]Perreault，S.，Ed.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，BCP 127，RFC 6888，DOI 10.17487/RFC6888，2013年4月<http://www.rfc-editor.org/info/rfc6888>.
[SENDMAIL_LOG_CONFIG] O'Reilly, "Sendmail, 3rd Edition, Page 798", December 2002.
[SENDMAIL_LOG_CONFIG]O'Reilly，“SENDMAIL，第三版，第798页”，2002年12月。
[SSHD_LOG_CONFIG] "sshd_config OpenSSH SSH daemon configuration file", <http://www.openbsd.org/cgi-bin/ man.cgi?query=sshd_config&sektion=5>.
[SSHD\u LOG\u CONFIG]“SSHD\u CONFIG OpenSSH-SSH守护程序配置文件”<http://www.openbsd.org/cgi-bin/ man.cgi？query=sshd\u config&sektion=5>。
The user can use the LogFormat command to define a customized log format and use the CustomLog command to apply that log format. "%a" and "%{remote}p" can be used in the format string to require logging the client's IP address and source port, respectively. This feature has been available since Apache version 2.1.
用户可以使用LogFormat命令定义自定义日志格式，并使用CustomLog命令应用该日志格式。“%a”和“%{remote}p”可以在格式字符串中使用，以分别要求记录客户端的IP地址和源端口。此功能从Apache 2.1版开始提供。
A detailed configuration guide can be found at [APACHE_LOG_CONFIG].
详细的配置指南可在[APACHE_LOG_CONFIG]中找到。
In order to log the client source port, macro smtpd_client_port_logging should be set to "yes" in the configuration file [POSTFIX_LOG_CONFIG].
为了记录客户端源端口，应在配置文件[POSTFIX\u log\u CONFIG]中将宏smtpd\u client\u port\u logging设置为“是”。
This feature has been available since Postfix version 2.5.
此功能自Postfix版本2.5以来一直可用。
Sendmail has a macro ${client_port} storing the client port. To log the source port, the user can define some check rules. Here is an example that should be in the .mc configuration macro [SENDMAIL_LOG_CONFIG]:
Sendmail有一个宏${client\u port}存储客户端端口。要记录源端口，用户可以定义一些检查规则。下面是一个应位于.mc配置宏[SENDMAIL\u LOG\u CONFIG]中的示例：
LOCAL_CONFIG Klog syslog
本地配置Klog syslog
LOCAL_RULESETS
SLocal_check_mail
R $* $@ $(log Port_Stat $&{client_addr} $&{client_port} $)
LOCAL_RULESETS
SLocal_check_mail
R $* $@ $(log Port_Stat $&{client_addr} $&{client_port} $)
This feature has been available since version 8.10.
此功能从8.10版开始提供。
SSHD_CONFIG(5) OpenBSD Programmer's Manual SSHD_CONFIG(5) NAME sshd_config - OpenSSH SSH daemon configuration file LogLevel Gives the verbosity level that is used when logging messages from sshd(8). The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of debugging output. Logging with a DEBUG level violates the privacy of users and is not recommended. SyslogFacility Gives the facility code that is used when logging messages from sshd(8). The possible values are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, and LOCAL7. The default is AUTH.
SSHD_CONFIG（5）OpenBSD程序员手册SSHD_CONFIG（5）名称SSHD_CONFIG-OpenSSH-SSH-SSH-daemon配置文件LogLevel提供了记录来自SSHD的消息时使用的详细级别（8）。可能的值有：QUIET、FATAL、ERROR、INFO、VERBOSE、DEBUG、DEBUG1、DEBUG2和DEBUG3。默认值是INFO。DEBUG和DEBUG1是等效的。DEBUG2和DEBUG3各自指定更高级别的调试输出。使用调试级别进行日志记录会侵犯用户的隐私，因此不建议使用。SyslogFacility提供记录来自sshd（8）的消息时使用的设备代码。可能的值是：守护进程、用户、身份验证、LOCAL0、LOCAL1、LOCAL2、LOCAL3、LOCAL4、LOCAL5、LOCAL6和LOCAL7。默认值是AUTH。
sshd supports logging the client IP address and client port when a client starts connection since version 1.2.2; here is the source code in sshd.c:
sshd支持从版本1.2.2开始，当客户端开始连接时记录客户端IP地址和客户端端口；以下是sshd.c中的源代码：
... verbose("Connection from %.500s port %d", remote_ip, remote_port); ...
... 详细（“从%.500s端口%d的连接”，远程ip，远程端口）。。。
sshd supports logging the client IP address when a client disconnects in version 1.2.2 to version 5.0. Since version 5.1, sshd supports logging the client IP address and source port. Here is the source code in sshd.c:
在版本1.2.2到版本5.0中，当客户端断开连接时，sshd支持记录客户端IP地址。从版本5.1开始，sshd支持记录客户端IP地址和源端口。以下是sshd.c中的源代码：
...
/* from version 1.2.2 to 5.0*/
verbose("Closing connection to %.100s", remote_ip);
...
...
/* from version 1.2.2 to 5.0*/
verbose("Closing connection to %.100s", remote_ip);
...
/* since version 5.1*/
verbose("Closing connection to %.500s port %d",
remote_ip, remote_port);
/* since version 5.1*/
verbose("Closing connection to %.500s port %d",
remote_ip, remote_port);
In order to log the source port, the LogLevel should be set to VERBOSE [SSHD_LOG_CONFIG] in the configuration file:
为了记录源端口，应在配置文件中将日志级别设置为VERBOSE[SSHD_log_CONFIG]：
LogLevel VERBOSE
日志级详细
Cyrus IMAP and UW IMAP do not support logging the source port for the time being. Both software use syslog to create logs; it should not be too difficult to get it supported by adding some new code.
Cyrus IMAP和UW IMAP暂时不支持记录源端口。两个软件都使用syslog创建日志；通过添加一些新代码来获得支持应该不会太困难。
Acknowledgements
致谢
Mohamed Boucadair reviewed the initial document and provided useful comments to improve it. Reinaldo Penno, Joel Jaeggli, and Dan Wing provided comments on the subsequent draft version that resulted in major revisions. Serafim Petsis provided encouragement to publish the document after a hiatus of two years.
Mohamed Boucadair审查了最初的文件，并提供了有用的意见以改进它。Reinaldo Penno、Joel Jaeggli和Dan Wing就随后的草案版本提供了意见，这些版本导致了重大修订。Serafim Petsis鼓励在中断两年后发布该文件。
The authors are grateful to Dan Wing for his help in moving this document forward, and in particular for his helpful comments on its content.
作者感谢Dan Wing在推进本文件方面的帮助，特别是他对本文件内容的有益评论。
Authors' Addresses
作者地址
Tina Tsou Philips Lighting 3 Burlington Woods Dr #4t Burlington, MA 01803 United States
Tina Tsou Philips Lighting 3 Burlington Woods Dr#4t Burlington，MA 01803美国
Email: tina.tsou@philips.com
Email: tina.tsou@philips.com
Weibo Li China Telecom 109, Zhongshan Ave. West, Tianhe District Guangzhou 510630 P.R. China
中国广东省广州市天河区中山大道西109号威博力中国电信510630
Email: mweiboli@gmail.com
Email: mweiboli@gmail.com
Tom Taylor Huawei Technologies Ottawa Canada
加拿大渥太华华为技术有限公司
Email: tom.taylor.stds@gmail.com
Email: tom.taylor.stds@gmail.com
James Huang Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China
James Huang华为技术有限公司，中国深圳市龙岗区坂田，邮编：518129
Email: James.huang@huawei.com
Email: James.huang@huawei.com