One document matched: draft-ietf-behave-syslog-nat-logging-02.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" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml">
<!ENTITY RFC2663 SYSTEM "reference.RFC.2663.xml">
<!ENTITY RFC2685 SYSTEM "reference.RFC.2685.xml">
<!ENTITY RFC3022 SYSTEM "reference.RFC.3022.xml">
<!ENTITY RFC4787 SYSTEM "reference.RFC.4787.xml">
<!ENTITY RFC5101 SYSTEM "reference.RFC.5101.xml">
<!ENTITY RFC5382 SYSTEM "reference.RFC.5382.xml">
<!ENTITY RFC5424 SYSTEM "reference.RFC.5424.xml">
<!ENTITY RFC5425 SYSTEM "reference.RFC.5425.xml">
<!ENTITY RFC5848 SYSTEM "reference.RFC.5848.xml">
<!ENTITY RFC5952 SYSTEM "reference.RFC.5952.xml">
<!ENTITY RFC5969 SYSTEM "reference.RFC.5969.xml">
<!ENTITY RFC6145 SYSTEM "reference.RFC.6145.xml">
<!ENTITY RFC6146 SYSTEM "reference.RFC.6146.xml">
<!ENTITY RFC6264 SYSTEM "reference.RFC.6264.xml">
<!ENTITY RFC6333 SYSTEM "reference.RFC.6333.xml">
<!ENTITY RFC6674 SYSTEM "reference.RFC.6674.xml">
<!ENTITY RFC6887 SYSTEM "reference.RFC.6887.xml">
<!ENTITY RFC6888 SYSTEM "reference.RFC.6888.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="std" docName="draft-ietf-behave-syslog-nat-logging-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
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>Syslog Format for NAT Logging</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Zhonghua Chen" initials="Z." surname="Chen">
<organization>China Telecom</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>18918588897@189.cn</email>
</address>
</author>
<author fullname="Cathy Zhou" initials="C." surname="Zhou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>cathy.zhou@huawei.com</email>
</address>
</author>
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone>+1 408 330 4424</phone>
<email>tina.tsou.zouting@huawei.com</email>
</address>
</author>
<author initials="T." surname="Taylor" fullname="T. Taylor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Ottawa</city>
<region></region>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<email>tom.taylor.stds@gmail.com</email>
</address>
</author>
<date year="2013" />
<!-- 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>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. -->
<abstract>
<t>With the wide deployment of Carrier Grade NAT (CGN) devices, the
logging of NAT-related events has become very important for various
operational purposes. The logs may be required for troubleshooting, to
identify a host that was used to launch malicious attacks, and/or for
accounting purposes. This document identifies the events that need to be
logged and the parameters that are required in the logs depending on the
context in which the NAT is being used. It goes on to standardize formats
for reporting these events and parameters using SYSLOG (RFC 5424). A
companion document specifies formats for reporting the same events and
parameters using IPFIX (RFC 5101). Applicability statements are provided
in this document and its companion to guide operators and implementors in
their choice of which technology to use for logging.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> Operators already need to record the addresses assigned to
subscribers at any point in time, for operational and regulatory
reasons. When operators introduce NAT devices which support address
sharing (e.g., Carrier Grade NATs (CGNs)) into their network,
additional information has to be logged. This document and
<xref target="I-D.behave-ipfix-nat-logging"/> are provided in order to
standardize the events and parameters to be recorded, using
SYSLOG <xref target="RFC5424"/> and IPFIX <xref target="RFC5101"/>
respectively. The content proposed to be logged by the two documents
is exactly the same, but as will be seen, the choice of which to use
in a given scenario is an engineering issue. </t>
<t>Detailed logging requirements will vary depending on the context in
which they are used. For example, different methods for transition
from IPv4 to IPv6 require different events and different parameters to
be logged. <xref target="deploy"/> covers this topic.</t>
<t><xref target="events"/> provides a more
detailed description of the events that need logging and the parameters
that may be required in the logs.</t>
<t>The use of SYSLOG <xref target="RFC5424"/> has advantages and
disadvantages compared with the use of IPFIX <xref target="RFC5101"/>.
<xref target="applic"/> provides a statement of applicability for the
SYSLOG approach.</t>
<t><xref target="recFMT"/> specifies SYSLOG record formats for logging
of the events and parameters described in <xref target="events"/>. The
definitions provide the flexibility to vary actual log contents based
on the requirements of the particular deployment.</t>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">
"Key words for use in RFCs to Indicate Requirement Levels"</xref>.</t>
<t>This document uses the term "Session" as it is defined in Section
2.3 of <xref target="RFC2663"/> and the term Binding Information Base
(BIB) as it is defined in Section 2 of <xref target="RFC6146"/>.</t>
<t>Except where a clear distinction is necessary, this document uses the
abbreviation "NAT" to encompass both Network Address Translation (NAT in
the strict sense) and Network Address and Port Translation (NAPT).</t>
</section>
</section> <!-- Introduction -->
<section anchor="deploy" title="Deployment Considerations">
<section anchor="statDyn" title="Static and Dynamic NATs">
<t>A NAT controls a set of resources in the form of one or more pools of
external addresses. If the NAT also does port translation (i.e., it is a
NAPT), it also controls the sets of UDP and TCP port numbers and ICMP
identifiers associated with each external address. </t>
<t>Logging requirements for a NAT depend heavily on its resource
allocation strategy. NATs can be classed as static or dynamic depending
on whether the resources provided to individual users are pre-configured
or allocated in real time as the NAT recognizes new flows. </t>
<t>Static assignments can be logged at configuration time by the NAT or
by network infrastructure. The logging volume associated with static
assignments will be relatively low, of the order of the volume of user
logons. As discussed below, static assignments are typically associated
with IPv6 transition methods rather than traditional NAT. The details of
what to log will depend on the transition method concerned. </t>
<t>Dynamic assignments typically require both more detail in the logs
and a higher volume of logs in total. A traditional Network Address Port
Translator (NAPT) as described in <xref target="RFC3022"/> and following
the recommendations of <xref target="RFC4787"/> and <xref
target="RFC5382"/> will generate a new mapping each time it encounters a
new internal <address, port> combination.</t>
<t>For statistical reasons, static assignments support lower address
sharing ratios than fully dynamic assignments as exemplified by the
traditional NAPT. The sharing ratio can be increased while restraining
log volumes by assigning ports to users in multi-port increments as
required rather than assigning just one port at a time. A subscriber may
start with no initial allocation, or may start with an initial permanent
allocation to which temporary increments are added when the initial set
is all being used. See <xref target="RFC6264"/> and
<xref target="I-D.tsou-behave-natx4-log-reduction"/> for details. If
this strategy is followed, logging will be required only when an
increment is allocated or reclaimed rather than every time an internal
<address, port> combination is mapped to an external <address,
port>. </t>
</section> <!-- statDyn -->
<section anchor="transition" title="NAT Logging Requirements For Different Transition Methods">
<t>A number of transition technologies have been or are being
developed to aid in the transition from IPv4 to IPv6. 6rd
<xref target="RFC5969"/> and DS-Lite <xref target="RFC6333"/> are at
the deployment stage. Several 'stateless' technologies: Public IPv4
over IPv6 <xref target="I-D.softwire-public-4over6"/>, MAP-E
<xref target="I-D.softwire-map"/>, and Lightweight 4over6
<xref target="I-D.softwire-lw4over6"/> have seen experimental
deployment and are in the process of being standardized at the time of
writing of this document. </t>
<t>Of the technologies just listed, 6rd and Public IPv4 over IPv6 do
not involve NATs and hence need not be considered further. The other
techniques involve NAT at the customer edge, at the border router, or
both, and hence are in scope.</t>
<t>A DS-Lite Address Family Transition Router (AFTR) includes a
large-scale session-stateful NAT44 processing potentially
millions of sessions per second. The special character of AFTR
operation over that of a traditional NAT44 is that the source IPv4
addresses of the interior hosts may not be unique. As a consequence,
the session tables need to include an alternative identifier associated
with the subscriber host. For basic DS-Lite, this will be the IPv6
address used to encapsulate the packets outgoing from the host. See
Section 6.6 of <xref target="RFC6333"/>. For gateway-initiated DS-Lite
<xref target="RFC6674"/>, an identifier associated with the incoming
tunnel from the host is used instead.</t>
<t>The DS-Lite customer edge equipment (the 'B4') may also perform
NAT44 functions, similar to the functions performed
by traditional NAT44 devices. This document does not include
any requirements specific to the B4, since logs are not usually
collected from customer equipment.</t>
<t>As a NAT44, the DS-Lite AFTR may be fully dynamic, or may allocate
ports in increments as described in the previous section. </t>
<t>Lightweight 4over6 <xref target="I-D.softwire-lw4over6"/> and MAP-E
<xref target="I-D.softwire-map"/> both require NAT44 operation at the
customer equipment (unified CPE,
<xref target="I-D.softwire-unified-cpe"/>). In both cases the resource
allocation strategy is static. Thus any logging of resource allocation
for these two transition techniques can be done by the network at
configuration time.</t>
<t> The border router (BR), for either Lightweight 4over6 or MAP-E, is
required to monitor port usage by outgoing IPv4 packets. If the ports
used by a host fall outside its configured port set, the border router
may return an ICMPv6 type 1, code 5 (source address failed
ingress/egress policy) error message to the unified CPE. It is also
possible for the same reason that the unified CPE receives incoming IPv4
packets with destination port numbers outside of its assigned range.</t>
<t>Out-of-range ports are a sign of misconfiguration or other problems,
so it is reasonable for the BR to log such events (subject to the rate
limiting). The log should capture the port set that the BR believes is
configured on the unified CPE. For both Lightweight 4over6 and MAP-E,
this is associated with an identifier, the 16-bit port set identifier
(PSID). </t>
</section> <!-- transition -->
<section anchor="PCP" title="The Port Control Protocol (PCP)">
<t>The Port Control Protocol (PCP) <xref target="RFC6887"/> and
its port set extension <xref target="I-D.pcp-port-set"/> can be viewed
as a way to provision ports by other means. However, PCP can be invoked on a
per-flow basis, so the volume of logs generated by a PCP server can be
closer to the volume associated with a fully dynamic NAT. The volume
really depends on how PCP is being used in a specific network.</t>
</section> <!-- PCP -->
<section anchor="edgeLogs" title="Logging At the Customer Edge">
<t>Logging at the customer edge (or at the ISP edge for NATs
protecting the ISP's internal networks) may be done by the customer
for purposes of internal management, or by the ISP for its own
administrative and regulatory purposes. Given the likelihood of a high
internal community of interest, it is possible but unlikely that a NAT
at the edge of a large enterprise network processes a number of new
packet flows per second which is comparable to the volume handled by a
carrier grade NAT. Most customer edge NATs will handle a much smaller
volume of flows.</t>
</section> <!-- edgeLogs -->
</section> <!-- deploy -->
<section anchor="events" title="NAT-Related Events and Parameters">
<t>The events which follow were initially gleaned, in the words of the
authors of <xref target="I-D.behave-ipfix-nat-logging"/>, from <xref
target="RFC4787"/> and <xref target="RFC5382"/>. Some details were
subsequently informed by the discussion in <xref
target="deploy"/>. Since the present document deals with SYSLOG rather
than IPFIX, the timestamp and the event type will appear in the log
header rather than as an explicit part of the structured data portion
of the log. Hence they are omitted from the parameter tabulations that
follow. </t>
<t>The listed parameters include an optional reporting device identifier
and an optional reporting device type in each case. The reporting device
identifier is potentially useful only if the HOSTNAME field in the log
header identifies an off-board device rather than the NAT itself. The
reporting device type identifies which of the reporting device types
listed in <xref target="DevTyp"/> is reporting the event.</t>
<t>Reference will be made below to a subscriber site identifier. IOn
practice, NATs use various means to distinguish customer endpoints, and
this will be reflected in what they log. From a strictly theoretical
point of view:
<list style="symbols">
<t>For traditional NATs, the source IPv4 address (for NAT44) or IPv6
address (for NAT64) is sufficient.</t>
<t>For the DS-Lite, Lightweight 4over6 or MAP-E transition methods,
the subscriber site can be identified by the IPv6 tunnel endpoint
prefix or address provisioned to that site.</t>
<t>Gateway-initiated DS-Lite uses the combination of a 32-bit context
identifier (CID) and a softwire identifier (SWID). Several different
realizations of these identifiers are described in Section 6 of <xref
target="RFC6674"/>.</t>
</list>
</t>
<section anchor="sessCrDe" title="NAT Session Creation and Deletion">
<t>NAT session creation and deletion events may be logged in a fully
dynamic NAT when a binding from a subscriber site identifier and source
port to an external address and port is recorded in or deleted from the
session database. See Section 3 of <xref target="RFC3022"/> for more
details about session creation and deletion.</t>
<t>The following specific events are defined:
<list style="symbols">
<t>NAT Session Creation</t>
<t>NAT Session Deletion</t>
</list>
</t>
<t>These take the same parameters for all types of NAT, aside from
the variation in subscriber site identifier noted above:
<list style="symbols">
<t>reporting device type (OPTIONAL);</t>
<t>reporting device identifier (OPTIONAL);</t>
<t>Subscriber site identifier (MANDATORY);</t>
<t>Mapped external IPv4 address (MANDATORY);</t>
<t>Protocol identifier (MANDATORY for NAPT);</t>
<t>Internal port or ICMP identifier (MANDATORY for NAPT);</t>
<t>Mapped external port or ICMP identifier (MANDATORY for NAPT);</t>
<t>Address realm (internal or external) of the source of the packet
triggering the creation of the session (OPTIONAL).</t>
</list>
</t>
<section anchor="destLog" title="Destination Logging">
<t>The logging of destination address and port for outgoing packets is
considered out of scope of this document, for several reasons. <xref
target="RFC6888"/> recommends against destination logging because of
the privacy issues it creates. From an operator's point of view,
destination logging is costly not just because of the volume of logs it
will generate, but because the NAT now has carry additional session
state so that it only needs to log once per session between two
transport end points rather than logging every packet. Finally, <xref
target="RFC4787"/>, etc. recommend the use of endpoint-independent
mapping to maximize the ability of applications to operate through the
NAT.</t>
<t>In short, destination logging will be a rarely-used procedure for
which standardization seems unnecessary.</t>
</section> <!-- destLog -->
</section> <!-- sessCrDe -->
<section anchor="addrBind" title="Address Binding Event">
<t>This event is recorded at a dynamic or hybrid NAT when a given
subscriber site identifier has been bound to an external source address.
An address binding occurs when the first packet in the first flow from
the host in the internal realm is received at the NAT. It MAY occur
under other circumstances (e.g., PCP request, or NAT policy permits
assignment of a new external address due to port conflict). The event
parameters are:
<list style="symbols">
<t>reporting device type (OPTIONAL);</t>
<t>reporting device identifier (OPTIONAL);</t>
<t>Subscriber site identifier (MANDATORY);</t>
<t>Mapped external IPv4 address (MANDATORY).</t>
</list></t>
</section> <!-- addrBind -->
<section anchor="portAssgn" title="Port Allocation Change">
<t>This event is recorded at a hybrid NAT whenever the set of ports
allocated to a given address binding changes. When ports are allocated,
the same ports are allocated for UDP and for TCP. The parameters for
this event are:
<list style="symbols">
<t>reporting device type (OPTIONAL);</t>
<t>reporting device identifier (OPTIONAL);</t>
<t>Subscriber site identifier (MANDATORY);</t>
<t>Mapped external IPv4 address (MANDATORY);</t>
<t>One or more contiguous port ranges specified by starting and ending
port number (MANDATORY).</t>
</list></t>
<t>The log MUST indicate the cumulative set of ports allocated to the address
binding (taking account both of allocations and deallocations) at the
time the log was generated. An implementation MAY show each individual
allocation as a separate range, or MAY consolidate adjacent ranges. For
example, suppose the address binding is initially allocated the range
1024-1535. The log at the time of the initial allocation will contain
that one range. Suppose now that an additional allocation is granted,
consisting of the range 1536-2047. The log generated may contain the two
ranges 1024-1535 and 1536-2047, or may contain the one consolidated
range 1024-2047. Finally, suppose that ports 1536-1791 are deallocated.
The resulting log will show the ranges 1024-1535 and 1792-2047 as the
current allocation to the address binding.</t>
</section> <!-- portAssgn -->
<section anchor="addrExh" title="NAT Address Exhaustion Event">
<t>This event will be generated when a NAT device runs out of global
IPv4 addresses in a given pool of addresses. Typically, this event
would mean that the NAT device will not be able to create any new
translations until some addresses or ports are freed. This event takes
the following parameters:
<list style="symbols">
<t>reporting device type (OPTIONAL);</t>
<t>reporting device identifier (OPTIONAL);</t>
<t>address pool identifier (MANDATORY).</t>
</list></t>
<t>Implementations MUST provide the ability to limit the rate at which
this log is generated, since the NAT may move back and forth between
exhausted and almost-exhausted state many times during a particular busy
episode. </t>
</section> <!-- addrExh -->
<section anchor="portExh" title="Port Exhaustion Event">
<t>This event will be generated when a NAT device runs out of ports
for a global IPv4 address. Port exhaustion shall be reported per
protocol (UDP, TCP) individually. The event parameters are:
<list style="symbols">
<t>reporting device type (OPTIONAL);</t>
<t>reporting device identifier (OPTIONAL);</t>
<t>Mapped external IPv4 address (MANDATORY);</t>
<t>Protocol identifier (MANDATORY).</t>
</list></t>
<t>Implementations MUST provide the ability to limit the rate at which
this log is generated, since the NAT may move back and forth between
exhausted and almost-exhausted state many times during a particular busy
episode. </t>
</section> <!-- portExh -->
<section anchor="quota" title="Quota Exceeded Event">
<t>A "Quota Exceeded" event is reported when the NAT cannot allocate a
new session because of an administratively imposed limit on the number
of sessions allowed for a given subscriber or set of subscribers, for a
given protocol or totalled over all protocols. The parameters
of this event are:
<list style="symbols">
<t>reporting device type (OPTIONAL);</t>
<t>reporting device identifier (OPTIONAL);</t>
<t>Site scope (MANDATORY);</t>
<t>Protocol (MANDATORY);</t>
<t>Subscriber site identifier (OPTIONAL);</t>
<t>VLAN identifier or VPN Routing and Forwarding (VRF) identifier
(OPTIONAL). </t>
</list>
Site scope is either single site, multiple sites served by the same VLAN
or VRF, or all sites served by the NAT. If the site scope is single
site, then the subscriber site identifier MUST be present and the VLAN
or VRF identifier MUST be absent. If the site scope is multiple sites,
then the reverse MUST be true. If the site scope is all sites, the
subscriber site identifier, the VRF idenbtifier, and the VLAN identifier
MUST NOT be present. Protocol scope is either a specific protocol (UDP,
TCP, ICMP) or all protocols, meaning that the quota concerned applies to the
total number of sessions supported by the NAT regardless of
protocol.</t>
<t>Implementations MUST provide the ability to limit the rate at which
this log is generated, since the NAT may move back and forth between
over-quota and within-quota state many times during a particular busy
episode. </t>
</section> <!-- quota -->
<section anchor="invPort" title="Invalid Port Detected">
<t>As discussed in <xref target="transition"/>, this event may be
reported at MAP-E or Lightweight 4over6 Border Router, either through
receipt of ICMP error messages or by direct observation of incoming IPv4
packets.
<list style="empty">
<t>List discussion has pointed out that enabling ICMP on the customer
edge device opens up the potential for denial of service attacks on
the Border Router. Hence direct observation will be the more likely
trigger for this event.</t>
</list>
The event report takes the following parameters:
<list style="symbols">
<t>reporting device identifier (OPTIONAL);</t>
<t>Subscriber site identifier (MANDATORY);</t>
<t>port set identifier for the subscriber site, as
provisioned at the Border Router (MANDATORY).</t>
</list>
</t>
</section> <!-- invPort -->
<section anchor="config" title="Static NAT Configuration Event">
<t>*** Should we anticipate logging of the configuration (IPv6 prefix,
IPv4 prefix/address, PSID) assigned to the Lightweight 4over6 or MAP-E
CPE? ***</t>
</section> <!-- config -->
</section> <!-- events -->
<section anchor="applic" title="SYSLOG Applicability">
<t>The primary advantage of SYSLOG is the human readability and
searchability of its contents. In addition, it has built-in priority
and severity fields that allow for separate routing of reports
requiring management action. Finally, it has a well-developed
underpinning of transport and security protocol infrastructure.</t>
<t>SYSLOG presents two obstacles to scalability: the fact that the
records will typically be larger than records based on a binary
protocol such as IPFIX, and, depending on the architectural context,
the reduced performance of a router that is forced to do text
manipulation in the data plane. One has to conclude that for larger
message volumes, IPFIX should be preferred as the reporting medium on
the NAT itself. It is possible that SYSLOG could be used as a back-end
format on an off-board device processing IPFIX records in real time,
but this would give a limited boost to scalability. One concern
expressed in list discussion is that when the SYSLOG formatting
process gets overloaded records will be lost.</t>
<t>As a result, the key question is what the practical cutoff point is
for the expected volume of SYSLOG records, on-board or off-board the
NAT. This obviously depends on the computing power of the formatting
platform, and also on the record lengths being generated. </t>
<t>Information has been provided to the BEHAVE list at the time of
writing to the effect that one production application is generating an
average of 150,000 call detail records per second, varying in length from
500 to 1500 bytes. Capacities several times this level have been
reported involving shorter records, but this particular application
has chosen to limit the average in order to handle peaks.</t>
<t>As illustrated by the examples in <xref target="evCode"/>, typical
record sizes for the high-volume logs are in the order of 150 to 200
bytes, so throughput capacity should be higher than in the call detail
case for the same amount of computing power. In private communication,
a discussant has noted a practical limit of a few hundred thousand
SYSLOG records per second on a router.</t>
</section> <!-- applic -->
<section anchor="recFMT" title="SYSLOG Record Format For NAT Logging">
<t>This section describes the SYSLOG record format for NAT logging in
terms of the field names used in <xref target="RFC5424"/> and
specified in Section 6 of that document. In particular,
this section specifies values for the APP-NAME and MSGID fields in the
record header, the SD-ID identifying the STRUCTURED-DATA section, and
the PARAM-NAMEs and PARAM-VALUE types for the individual possible
parameters within that section. The specification is in three parts,
covering the header, encoding of the individual parameters, and encoding
of the complete log record for each event type.</t>
<section anchor="hdrFMT" title="SYSLOG HEADER Fields">
<t>Within the HEADER portion of the SYSLOG record, the priority (PRI)
level is subject to local policy, but a default value of 8x is
suggested, representing a Facility value of 10
(security/authorization) and a Severity level varying with the event
type. The suggested value by event type is shown in <xref
target="tab_events"/>. Depending on where the SYSLOG record is
generated, the HOSTNAME field may identify the NAT or an offline
logging device. In the latter case, it may be desirable to identify
the NAT using the DevID field in the STRUCTURED-DATA section (see
below). The value of the HOSTNAME field is subject to the preferences
given in Section 6.2.4 of <xref target="RFC5424"/>.</t>
<t> The values of the APP-NAME and MSGID fields in the record header
determine the semantics of the record. The APP-NAME value
"NAT" indicates that the record relates to an event reported by a NAT
device. The MSGID values indicate the individual events.
They are listed in <xref target="tab_events"/> for each of the events
defined in <xref target="events"/>. The table also shows the SD-ID
value used to label the event-specific STRUCTURED-DATA element.</t>
<texttable anchor="tab_events" title="Recommended MSGID Encodings and Default PRI Values for the Events Defined In Section 3">
<ttcol align="left">Event</ttcol>
<ttcol align="left">MSGID</ttcol>
<ttcol align="left">PRI</ttcol>
<ttcol align="left">SD-ID</ttcol>
<c>NAT session creation</c>
<c>SessAdd</c>
<c>86 info</c>
<c>NATsess</c>
<c>NAT session deletion</c>
<c>SessDel</c>
<c>86 info</c>
<c>NATsess</c>
<c>Address binding event</c>
<c>AddrBind</c>
<c>86 info</c>
<c>NATBind</c>
<c>Port allocation change</c>
<c>PtAlloc</c>
<c>86 info</c>
<c>NATPBlk</c>
<c>NAT address exhaustion</c>
<c>AddrEx</c>
<c>82 critical</c>
<c>NATAddrEx</c>
<c>NAT port exhaustion</c>
<c>PortEx</c>
<c>84 warning</c>
<c>NATPEx</c>
<c>Quota exceeded</c>
<c>Quota</c>
<c>85 notice</c>
<c>NATQEx</c>
<c>Invalid port detected</c>
<c>InvPort</c>
<c>83 error</c>
<c>NATInvP</c>
</texttable>
</section> <!-- hdrFMT -->
<section anchor="params" title="Parameter Encodings">
<t>This section describes how to encode the individual parameters that
can appear in NAT-related logs. The parameters are taken from the event
descriptions in <xref target="events"/>, and are listed in <xref
target="tab_params"/>. Formally, as will be seen in <xref
target="iana"/>, a parameter used with more than one event is registered
as multiple separate parameters, one for each event report in which it
is used. However, there is no reason to change either the PARAM-NAME or
the encoding of the PARAM-VALUE between different instances of the same
parameter.</t>
<texttable anchor="tab_params" title="Parameters Used In NAT-Related Log Reports, By PARAM-NAME">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Parameter</ttcol>
<c>APoolId</c>
<c>Address pool identifier</c>
<c>DevID</c>
<c>reporting device identifier</c>
<c>DevTyp</c>
<c>reporting device type</c>
<c>PostS4</c>
<c>Mapped external IPv4 address</c>
<c>PostSPt</c>
<c>Mapped external port or ICMP identifier</c>
<c>PreSPt</c>
<c>Internal port or ICMP identifier</c>
<c>Proto</c>
<c>Protocol identifier</c>
<c>PScop</c>
<c>Protocol scope for quota</c>
<c>PSID</c>
<c>Port set identifier</c>
<c>PtRg</c>
<c>Range of consecutive port numbers</c>
<c>SiteID</c>
<c>Subscriber site identifier</c>
<c>SScop</c>
<c>Site scope for quota</c>
<c>TrigR</c>
<c>Address realm triggering the creation of the session</c>
<c>VLANid</c>
<c>VLAN identifier</c>
<c>VRFid</c>
<c>VPN routing and forwarding identifier</c>
</texttable>
<section anchor="APoolId" title="APoolId: Address Pool Identifier">
<t>PARAM-Value: decimal integer identifying a specific address pool at the
reporting NAT.</t>
</section> <!-- APoolId -->
<section anchor="DevID" title="DevID: Reporting Device Identifier">
<t>PARAM-VALUE: a UTF-8 string identifying the NAT or BR observing the
event which this record reports. Needed only if the necessary
identification is not provided by the HOSTNAME parameter in the log
record header. </t>
</section> <!-- DevID -->
<section anchor="DevTyp" title="DevTyp: Reporting Device Type">
<t>PARAM-VALUE: one of the values provided in the IANA SYSLOG
reporting device type registry established by this document. The
initial values in that registry are:
<list style="hanging" hangIndent="8">
<t hangText="44">NAT44 <xref target="RFC3022"/>;</t>
<t hangText="64">NAT64 <xref target="RFC6145"/> or
<xref target="RFC6146"/>;</t>
<t hangText="AFTR">DS-Lite AFTR <xref target="RFC6333"/>;</t>
<t hangText="BR">Lightweight 4over6 or MAP-E border router.</t>
</list></t>
<t>This parameter is primarily additional information for the human
reader of a log report, but could be used to provide a consistency
check on the contents of a log. Instances where parameter usage
depends on the reporting device type of the reporting NAT are noted in
<xref target="evCode"/>. </t>
</section> <!-- DevTyp -->
<section anchor="PostS4" title="PostS4: Mapped External IPv4 Address">
<t>PARAM-VALUE: IPv4 address, represented in dotted decimal form.</t>
</section> <!-- PostS4 -->
<section anchor="PostSPt" title="PostSPt: Mapped External Port or ICMP Identifier">
<t>PARAM-Value: decimal integer, port number or ICMP query
identifier.</t>
</section> <!-- PostSPt -->
<section anchor="PreSPt" title="PreSPt: Internal Port or ICMP Identifier">
<t>PARAM-Value: decimal integer, port number or ICMP query
identifier.</t>
</section> <!-- PreSPt -->
<section anchor="Proto" title="Proto: Protocol Identifier">
<t>PARAM-VALUE: an integer indicating the value of the Protocol header
field (IPv4) or Next Header field (IPv6) in the incoming packet(s)
(after decapsulation, for reporting device type "AFTR") to which the event
described by this record applies.</t>
</section> <!-- Proto -->
<section anchor="PScop" title="PScop: Protocol Scope For Quota">
<t>PARAM-VALUE: as for Proto for a specific protocol. "*" for sum over
all protocols.</t>
</section> <!-- PScop -->
<section anchor="PSID" title="PSID: Port Set Identifier">
<t>PARAM-VALUE: integer between 0 and 65535 designating a port set.
In practice the upper limit is likely to be two orders of magnitude
smaller.</t>
</section> <!-- PSID -->
<section anchor="PtRg" title="PtRg: Allocated Port Range">
<t>PARAM-VALUE: a field consisting of two decimal integers separated
by a minus sign/hyphen. The first integer is the lowest port number,
the second, the highest port number, in a range of consecutive
ports.</t>
</section> <!-- PtRg -->
<section anchor="SiteID" title="SiteID: Subscriber Site Identifier">
<t>A human-readable UTF-8 string identifying a specific host or CPE
served by the reporting device. The type of identifier depends on the
configuration of the reporting device, and is implementation and
deployment-specific. See <xref target="events"/> for a discussion of
the possible identifier types.</t>
</section> <!-- SiteID -->
<section anchor="SScop" title="SScop: Site Scope For Quota">
<t>PARAM-VALUE: "S" for single site, "M" for sum over multiple sites,
served by the same VLAN or VRF. "*" for sum over all sites served by
the NAT.</t>
</section> <!-- SScop -->
<section anchor="TrigR" title="TrigR: Realm Triggering Session Creation">
<t>PARAM-VALUE: "I" for internal, "E" for external.</t>
</section> <!-- TrigR -->
<section anchor="VLANid" title="VLANid: VLAN Identifier">
<t>PARAM-VALUE: a decimal integer representing the VLAN identifier
associated with the subscriber site.</t>
</section> <!-- VLANid -->
<section anchor="VRFid" title="VRFid: VPN Routing and Forwarding Identifier">
<t>PARAM-VALUE: a hexadecimal number representing a VPN identifier
<xref target="RFC2685"/> associated with the subscriber site. It is
RECOMMENDED that implementations be configurable to include or not
include the OUI portion of the identifier.</t>
</section> <!-- VRFid -->
</section> <!-- params -->
<section anchor="evCode" title="Encoding Of Complete Log Report For Each Event Type">
<t>This section describes the complete NAT-related contents of the logs
used to report the events listed in <xref target="tab_events"/>.</t>
<section anchor="SessCode" title="NAT Session Creation and Deletion">
<t>As shown in <xref target="tab_events"/>, the NAT session
creation event is indicated by MSG-ID set to "SessAdd". Similarly,
the NAT session deletion event is indicated by MSG-ID set to
"SessDel". For both events, the associated SD-ELEMENT is tagged by
SD-ID "NATsess". The contents of the NATsess SD-ELEMENT are shown in
<xref target="tab_NATsess"/>. The requirements for these contents are
derived from the description in <xref target="sessCrDe"/>.</t>
<texttable anchor="tab_NATsess" title="Contents Of the SD-ELEMENT Section For Logging the Session Creation and Deletion Events">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>DevTyp</c>
<c><xref target="DevTyp"/></c>
<c>OPTIONAL</c>
<c>DevID</c>
<c><xref target="DevID"/></c>
<c>OPTIONAL</c>
<c>SiteID</c>
<c><xref target="SiteID"/></c>
<c>MANDATORY</c>
<c>PostS4</c>
<c><xref target="PostS4"/></c>
<c>MANDATORY</c>
<c>Proto</c>
<c><xref target="Proto"/></c>
<c>MANDATORY</c>
<c>PreSPt</c>
<c><xref target="PreSPt"/></c>
<c>MANDATORY</c>
<c>PostSPt</c>
<c><xref target="PostSPt"/></c>
<c>MANDATORY</c>
<c>TrigR</c>
<c><xref target="TrigR"/></c>
<c>OPTIONAL</c>
</texttable>
<section anchor="sessEx" title="Examples">
<t>The first example is deliberately chosen to show how long a
complete session log might be. For this first example, assume the
log is formatted at an off-board device, which collects the
information from an AFTR. Thus HOSTNAME and DevID are both present.
IPv6 addresses are reported omitting a common /16 prefix and the IID
portion of the address (not to be too unrealistic!). All the
optional parameters are present. Note that the log could also
include other SD-ELEMENTs (e.g., timeQuality), but enough is
enough.</t>
<t>The log appears as a single record, but is wrapped between lines
for purposes of presentation.
<list style="empty">
<t><86>1 2013-05-07T22:14:15.03Z record.example.net NAT 5063 SessAdd
<vspace blankLines="0"/>
[NATsess DevTyp="AFTR" DevID="bgw211.example.net"
<vspace blankLines="0"/>
SiteID="A2E0:62" PostS4="198.51.100.127"
<vspace blankLines="0"/>
Proto="6" PreSPt="49156" PostSPt="6083" TrigR="I"]</t>
</list>
Character count: about 205.</t>
<t>The next example is perhaps more typical in size. Assume an
enterprise NAT44 generating its own logs. The optional
parameters are omitted. This is a session deletion event.
<list style="empty">
<t><86>1 2013-05-07T15:27:49.603-04:00 cerberus.example.com
<vspace blankLines="0"/>
NAT 175 SessDel [NATsess SiteID="192.0.2.5" PostS4="198.51.100.14"
<vspace blankLines="0"/>
Proto="6" PreSPt="51387" PostSPt="17865"]</t>
</list>
The character count: about 165.</t>
</section> <!-- sessEx -->
</section> <!-- SessCode -->
<section anchor="ABindCode" title="Address Binding Event">
<t>As shown in <xref target="tab_events"/>, the NAT address
binding event is indicated by MSG-ID set to "AddrBind". The associated
SD-ELEMENT is tagged by SD-ID "NATBind". The contents of the NATBind
SD-ELEMENT are shown in <xref target="tab_NATBind"/>. The requirements
for these contents are derived from the description in <xref
target="addrBind"/>.</t>
<texttable anchor="tab_NATBind" title="Contents Of the SD-ELEMENT Section For Logging the Address Binding Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>DevTyp</c>
<c> <xref target="DevTyp"/> </c>
<c>OPTIONAL</c>
<c>DevID</c>
<c> <xref target="DevID"/> </c>
<c>OPTIONAL</c>
<c>SiteID</c>
<c> <xref target="SiteID"/> </c>
<c>MANDATORY</c>
<c>PostS4</c>
<c> <xref target="PostS4"/> </c>
<c>MANDATORY</c>
</texttable>
<t>As an example, consider a DS-Lite AFTR <xref target="RFC6333"/>
incorporating a PCP server, where PCP is used to obtain an external
address binding and a port range. See Section 11 of <xref
target="RFC6887"/> for the address binding. (The port allocation is
shown in the next section's example.) As in the session creation
example, the first /16 prefix and the final 64 bits are omitted from
the encapsulating IPv6 address which is used as the subscriber site
identifier.
<list style="empty">
<t><86>1 2013-05-07T15:27:49.603Z yourd137mzmhow.example.net
<vspace blankLines="0"/>
NAT 68 AddrBind [NATBind SiteID="5A27:876E" PostS4="198.51.100.1"]</t>
</list>
Character count: about 125.</t>
</section> <!-- ABindCode -->
<section anchor="PBlkCode" title="Port Allocation Change">
<t>As indicated in <xref target="tab_events"/>, the port block
allocation change event is indicated by MSG-ID set to "PtAlloc". The
associated SD-ELEMENT is tagged by SD-ID "NATPBlk". The contents of
the NATPBlk SD-ELEMENT are shown in <xref target="tab_NATPBlk"/>. The
requirements for these contents are derived from the description in
<xref target="portAssgn"/>.</t>
<texttable anchor="tab_NATPBlk" title="Contents Of the SD-ELEMENT Section For Logging the Port Allocation Change Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>DevTyp</c>
<c><xref target="DevTyp"/></c>
<c>OPTIONAL</c>
<c>DevID</c>
<c><xref target="DevID"/></c>
<c>OPTIONAL</c>
<c>SiteID</c>
<c><xref target="SiteID"/></c>
<c>MANDATORY</c>
<c>PostS4</c>
<c><xref target="PostS4"/></c>
<c>MANDATORY</c>
<c>PtRg</c>
<c><xref target="PtRg"/></c>
<c>MANDATORY</c>
</texttable>
<t>As in the example in the previous section example, consider a DS-
Lite AFTR <xref target="RFC6333"/> incorporating a PCP server, where
PCP is used to obtain an external address binding and a port range.
See <xref target="I-D.pcp-port-set"/> for the port set part of this
operation.</t>
<t> Strictly for purposes of illustration, assume that the subscriber is
allocated two ranges of 64 consecutive values each, with the first
beginning at 2048 and the second at 4096.
<list style="empty">
<t><86>1 2013-05-07T15:27:49.751Z yourd137mzmhow.example.net
<vspace blankLines="0"/>
NAT 68 PtAlloc [NATPBlk SiteID="5A27:876E" PostS4="198.51.100.1"
<vspace blankLines="0"/>
PtRg="2048-2111" PtRg="4096-4159"]</t>
</list>
Character count: about 155.</t>
</section> <!-- PBlkCode -->
<section anchor="AExhCode" title="Address Exhaustion Event">
<t>As indicated in <xref target="tab_events"/>, the address
exhaustion event is indicated by MSG-ID set to "AddrEx". The
associated SD-ELEMENT is tagged by SD-ID "NATAddrEx". The contents of
the NATAddrEx SD-ELEMENT are shown in <xref target="tab_NATAddrEx"/>.
The requirements for these contents are derived from the description
in <xref target="addrExh"/>.</t>
<texttable anchor="tab_NATAddrEx" title="Contents Of the SD-ELEMENT Section For Logging the Address Exhaustion Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>DevTyp</c>
<c><xref target="DevTyp"/></c>
<c>OPTIONAL</c>
<c>DevID</c>
<c><xref target="DevID"/></c>
<c>OPTIONAL</c>
<c>APoolId</c>
<c><xref target="APoolId"/></c>
<c>MANDATORY</c>
</texttable>
<t>The example shows this event being reported by a DS-Lite AFTR.
Note the critical priority indication at the beginning of the log.
As with the session example, we assume off-board log generation.
<list style="empty">
<t><82>1 2013-05-07T22:14:15.03Z record.example.net NAT 5063
<vspace blankLines="0"/>
AddrEx [NATAddrEx DevID="bgw211.example.net" APoolId="2"]</t>
</list>
Character count: about 120.</t>
</section> <!-- AExhCode -->
<section anchor="PortExCode" title="NAT Port Exhaustion">
<t>As indicated in <xref target="tab_events"/>, the port
exhaustion event is indicated by MSG-ID set to "PortEx". The
associated SD-ELEMENT is tagged by SD-ID "NATPEx". The contents of
the NATPEx SD-ELEMENT are shown in <xref target="tab_NATPEx"/>.
The requirements for these contents are derived from the description
in <xref target="portExh"/>.</t>
<texttable anchor="tab_NATPEx" title="Contents Of the SD-ELEMENT Section For Logging the Port Exhaustion Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>DevTyp</c>
<c><xref target="DevTyp"/></c>
<c>OPTIONAL</c>
<c>DevID</c>
<c><xref target="DevID"/></c>
<c>OPTIONAL</c>
<c>PostS4</c>
<c> <xref target="PostS4"/> </c>
<c>MANDATORY</c>
<c>Proto</c>
<c><xref target="Proto"/></c>
<c>MANDATORY</c>
</texttable>
<t>The example is straightforward.
Note the warning priority indication at the beginning of the log.
<list style="empty">
<t><84>1 2013-05-07T22:14:15.03Z cerberus.example.com NAT 5063
<vspace blankLines="0"/>
PortEx [NATPEx PostS4="198.51.100.1" Proto="6"]</t>
</list>
Character count: about 110.</t>
</section> <!-- PortExCode -->
<section anchor="quotaCode" title="Quota Exceeded">
<t>As indicated in <xref target="tab_events"/>, the quota
exceeded event is indicated by MSG-ID set to "Quota". The
associated SD-ELEMENT is tagged by SD-ID "NATQEx". The contents of
the NATQEx SD-ELEMENT are shown in <xref target="tab_NATQEx"/>.
The requirements for these contents are derived from the description
in <xref target="quota"/>.</t>
<texttable anchor="tab_NATQEx" title="Contents Of the SD-ELEMENT Section For Logging the Quota Exceeded Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>DevTyp</c>
<c><xref target="DevTyp"/></c>
<c>OPTIONAL</c>
<c>DevID</c>
<c><xref target="DevID"/></c>
<c>OPTIONAL</c>
<c>SScop</c>
<c><xref target="SScop"/></c>
<c>MANDATORY</c>
<c>PScop</c>
<c><xref target="PScop"/></c>
<c>MANDATORY</c>
<c>SiteID</c>
<c><xref target="SiteID"/></c>
<c>OPTIONAL</c>
<c>VLANid</c>
<c><xref target="VLANid"/></c>
<c>OPTIONAL</c>
<c>VRFid</c>
<c><xref target="VRFid"/></c>
<c>OPTIONAL</c>
</texttable>
<t>Example 1: limit on TCP sessions for a specific user site reached
at an AFTR with off-board log generation.
<list style="empty">
<t><85>1 2013-05-07T22:14:15.03Z record.example.net NAT 5063
<vspace blankLines="0"/>
Quota [NATQEx DevID="bgw211.example.net" SScop="S" PScop="6"
<vspace blankLines="0"/>
SiteID="A2E0:62"]</t>
</list>
Character count: about 135.</t>
<t>Example 2: global limit on number of sessions for all subscribers
served by the same VLAN.
<list style="empty">
<t><85>1 2013-05-07T15:27:49.603-04:00 cerberus.example.com
<vspace blankLines="0"/>
NAT 175 Quota [NATQEx SScop="M" PScop="*" VLANid="1246"]</t>
</list>
Character count: about 115.</t>
<t>Example 3: limit on total number of sessions for TCP.
<list style="empty">
<t><85>1 2013-05-07T15:27:49.603-04:00 cerberus.example.com
<vspace blankLines="0"/>
NAT 175 Quota [NATQEx SScop="*" PScop="6"]</t>
</list>
Character count: about 100.</t>
</section> <!-- quotaCode -->
<section anchor="invPCode" title="Invalid Port Detected">
<t>As indicated in <xref target="tab_events"/>, the invalid port
detected event is indicated by MSG-ID set to "InvPort". The
associated SD-ELEMENT is tagged by SD-ID "NATInvP". The contents of
the NATInvP SD-ELEMENT are shown in <xref target="tab_NATInvP"/>.
The requirements for these contents are derived from the description
in <xref target="invPort"/>.</t>
<texttable anchor="tab_NATInvP" title="Contents Of the SD-ELEMENT Section For Logging the Invalid Port detected Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>DevID</c>
<c><xref target="DevID"/></c>
<c>OPTIONAL</c>
<c>SiteID</c>
<c><xref target="SiteID"/></c>
<c>MANDATORY</c>
<c>PSID</c>
<c><xref target="PSID"/></c>
<c>MANDATORY</c>
</texttable>
<t>Example: Lightweight 4over6 BR configured with PSID 15 for the
given subscriber site.
<list style="empty">
<t><83>1 2013-05-07T15:27:49.603Z yourd137mzmhow.example.net
<vspace blankLines="0"/>
NAT 68 InvPort [NATInvP SiteID="5A27:876E" PSID="15"]</t>
</list>
Character count: about 110.</t>
</section> <!-- invPCode -->
</section> <!-- evCode -->
</section> <!-- recFMT -->
<section anchor="IANA" title="IANA Considerations">
<t>This document requests IANA to make the following assignments to
the SYSLOG Structured Data ID Values registry. RFCxxxx refers to the
present document when approved.</t>
<texttable anchor="iana" title="NAT-Related STRUCTERED-DATA Registrations">
<ttcol align="left">Structured Data ID</ttcol>
<ttcol align="left">Structured Data Parameter</ttcol>
<ttcol align="left">Required or Optional</ttcol>
<ttcol align="left">Reference</ttcol>
<c>NATsess</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SiteID</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PostS4</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>Proto</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PreSPt</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PostSPt</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>TrigR</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATBind</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SiteID</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PostS4</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATPBlk</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SiteID</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PostS4</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PtRg</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATAddrEx</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>APoolId</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATPEx</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PostS4</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>Proto</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATQEx</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SScop</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PScop</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>SiteID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>VLANid</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>VRFid</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATInvP</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DevID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SiteID</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PSID</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
</texttable>
<t>IANA is further requested to establish a new registry entitled "syslog
NAT Types" within the "syslog Parameters" registry. The initial values for
this registry are shown in <xref target="tab_nattypes"/>. New values may
be added following the criterion of IETF Review.</t>
<texttable anchor="tab_nattypes" title="syslog NAT Type Values ">
<ttcol align="left">Value</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>44</c>
<c>NAT44</c>
<c>RFCxxxx</c>
<c>64</c>
<c>NAT64</c>
<c>RFCxxxx</c>
<c>AFTR</c>
<c>DS-Lite AFTR <xref target="RFC6333"/></c>
<c>RFCxxxx</c>
<c>BR</c>
<c>Lightweight 4over6 or MAP-E BR</c>
<c>RFCxxxx</c>
</texttable>
</section>
<section anchor="Security" title="Security Considerations">
<t>When logs are being recorded for regulatory reasons, preservation
of their integrity and authentication of their origin is essential. To
achieve this result, it is RECOMMENDED that the operator deploy
<xref target="RFC5848"/>. </t>
<t>Access to the logs defined here while the reported assignments are
in force could improve an attacker's chance of hijacking a session
through port-guessing. Even after an assignment has expired, the
information in the logs SHOULD be treated as confidential, since, if
revealed, it could help an attacker trace sessions back to a
particular subscriber or subscriber location. It is therefore
RECOMMENDED that these logs be transported securely, using <xref
target="RFC5425"/>, for example, and that they be stored securely at
the collector.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2663;
&RFC2685;
&RFC5424;
&RFC5425;
&RFC5848;
&RFC5952;
&RFC6145;
&RFC6146;
&RFC2119;
</references>
<references title="Informative References">
&RFC3022;
&RFC4787;
&RFC5101;
&RFC5382;
&RFC5969;
&RFC6264;
&RFC6333;
&RFC6674;
&RFC6887;
&RFC6888;
<reference anchor="I-D.behave-ipfix-nat-logging">
<front>
<title>IPFIX Information Elements for logging NAT Events (Work in progress)</title>
<author initials="S." surname="Sivakumar" fullname="S. Sivakumar">
<organization>Cisco Systems</organization>
</author>
<author initials="R." surname="Penno" fullname="R. Penno">
<organization>Cisco Systems</organization>
</author>
<date month="March" year="2013"/>
</front>
</reference>
<reference anchor="I-D.softwire-public-4over6">
<front>
<title>Public IPv4 over IPv6 Access Network (Work in progress)</title>
<author initials="Y." surname="Cui" fullname="Y. Cui">
<organization>Tsinghua University</organization>
</author>
<author initials="J." surname="Wu" fullname="J. Wu">
<organization>Tsinghua University</organization>
</author>
<author initials="P." surname="Wu" fullname="P. Wu">
<organization>Tsinghua University</organization>
</author>
<author initials="O." surname="Vautrin" fullname="O. Vautrin">
<organization>Juniper Networks</organization>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee">
<organization>Comcast</organization>
</author>
<date month="February" year="2013"/>
</front>
</reference>
<reference anchor="I-D.softwire-map">
<front>
<title>Mapping of Address and Port with Encapsulation (MAP) (Work in progress)</title>
<author initials="O." surname="Troan" fullname="O. Troan">
<organization>Cisco Systems</organization>
</author>
<author initials="W." surname="Dec" fullname="W. Dec">
<organization>Cisco Systems</organization>
</author>
<author initials="X." surname="Li" fullname="X. Li">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="C." surname="Bao" fullname="C. Bao">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="S." surname="Matsushima" fullname="S. Matsushima">
<organization>SoftBank Telecom</organization>
</author>
<author initials="T." surname="Murakami" fullname="T. Murakami">
<organization>IP Infusion</organization>
</author>
<date month="March" year="2013"/>
</front>
</reference>
<reference anchor="I-D.softwire-lw4over6">
<front>
<title>Lightweight 4over6: An Extension to the DS-Lite Architecture (Work in progress)</title>
<author initials="Y." surname="Cui" fullname="Y. Cui">
<organization>Tsinghua University</organization>
</author>
<author initials="Q." surname="Sun" fullname="Q. Sun">
<organization>China Telecom</organization>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="T." surname="Tsou" fullname="T. Tsou">
<organization>Huawei Technologies</organization>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee">
<organization>Comcast</organization>
</author>
<author initials="I." surname="Farrer" fullname="I. Farrer">
<organization>Deutsche Telekom AG</organization>
</author>
<date month="April" year="2013"/>
</front>
</reference>
<reference anchor="I-D.softwire-unified-cpe">
<front>
<title>Unified IPv4-in-IPv6 Softwire CPE (Work in progress)</title>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="I." surname="Farrer" fullname="I. Farrer">
<organization>Deutsche Telekom</organization>
</author>
<date month="March" year="2013"/>
</front>
</reference>
<reference anchor="I-D.tsou-behave-natx4-log-reduction">
<front>
<title>Port Management To Reduce Logging In
Large-Scale NATs (Work in progress)</title>
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies (USA)</organization>
</author>
<author fullname="Weibo Li" initials="W." surname="Li">
<organization>China Telecom</organization>
</author>
<author fullname="Tom Taylor" initials="T." surname="Taylor">
<organization>Huawei Technologies</organization>
</author>
<date month="May" year="2013"/>
</front>
</reference>
<reference anchor="I-D.pcp-port-set">
<front>
<title>Port Control Protocol (PCP) Extension for Port Set Allocation (Work in progress)</title>
<author initials="Q." surname="Sun" fullname="Q. Sun">
<organization>China Telecom</organization>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="S." surname="Sivakumar" fullname="S. Sivakumar">
<organization>Cisco Systems</organization>
</author>
<author initials="C." surname="Zhou" fullname="C. Zhou">
<organization>Huawei Technologies</organization>
</author>
<author initials="T." surname="Tsou" fullname="T. Tsou">
<organization>Huawei Technologies (USA)</organization>
</author>
<author initials="S." surname="Perreault" fullname="S. Perreault">
<organization>Viagenie</organization>
</author>
<date month="March" year="2013"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:19:08 |