One document matched: draft-ietf-behave-syslog-nat-logging-06.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 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2663 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2663.xml">
<!ENTITY RFC2685 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2685.xml">
<!ENTITY RFC2863 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml">
<!ENTITY RFC3022 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4026.xml">
<!ENTITY RFC4026 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml">
<!ENTITY RFC4265 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4265.xml">
<!ENTITY RFC4363 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4363.xml">
<!ENTITY RFC4784 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4784.xml">
<!ENTITY RFC4787 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC5382 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5382.xml">
<!ENTITY RFC5424 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
<!ENTITY RFC5425 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5425.xml">
<!ENTITY RFC5848 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5848.xml">
<!ENTITY RFC5952 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5952.xml">
<!ENTITY RFC5969 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969.xml">
<!ENTITY RFC6145 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6145.xml">
<!ENTITY RFC6146 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml">
<!ENTITY RFC6264 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6264.xml">
<!ENTITY RFC6333 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6333.xml">
<!ENTITY RFC6674 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6674.xml">
<!ENTITY RFC6887 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6887.xml">
<!ENTITY RFC6888 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6888.xml">
<!ENTITY RFC7011 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7011.xml">
<!ENTITY RFC7040 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7040.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-06" 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 -->
<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</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>tina.tsou.zouting@huawei.com</email>
</address>
</author>
<author initials="T." surname="Taylor" fullname="T. Taylor" role="editor">
<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="2014" />
<!-- 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>Behave Working Group</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> NAT devices are required to log events like creation and deletion of
translations and information about the resources the NAT is managing. The
logs are required to identify an attacker or a host that was used to
launch malicious attacks, and for various other purposes of accounting and
management. Since there is no standard way of logging this information,
different NAT devices behave differently. The lack of a consistent way
makes it difficult to write the collector applications that would receive
this data and process it to present useful information.</t>
<t>This document describes the information that is required to be logged
by the NAT devices. 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 7011). 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>This document deals with logging of NAT activity in two categories: NAT
translations and NAT resource usage. </t>
<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 that 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="RFC7011"/>
respectively. The same content is proposed to be logged by both
documents. </t>
<t>In addition to records of subscriber activity, some operators use logs
to indicate when utilization of critical resources is approaching or has
reached limits set by the operator or implementation. This document and
the IPFIX document therefore provide logs in two categories: thresholds
exceeded and limits exceeded. Operators have the alternative to receive
the threshold limits as SNMP notifications (see the NAT MIB <xref
target="I-D.behave-NAT-MIB"/>).</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 detailed description of the events
that need logging and the parameters that may be required in the logs.
<xref target="resAlloc"/> describes events related to subscriber activity,
<xref target="threshEv"/> covers threshold events, and <xref
target="limitEv"/> covers events where hard limits have been reached.</t>
<t>The use of SYSLOG <xref target="RFC5424"/> has advantages and
disadvantages compared with the use of IPFIX <xref target="RFC7011"/>.
<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"/>. <xref
target="hdrFMT"/> describes the SYSLOG header format for each report,
<xref target="params"/> lists and describes the encoding of parameters
that can appear in the logs, and <xref target="evCode"/> specifies the
encoding of the body of each event report. The definitions provide the
flexibility to vary actual log contents based on the requirements of the
particular deployment.</t>
<section anchor="terms" 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 makes frequent reference to the NAT MIB. That reference
is to the document <xref target="I-D.behave-NAT-MIB"/>.</t>
<t>This document makes frequent reference to NAT behaviours defined in
<xref target="RFC4784"/>. In particular it refers to
<list style="symbols">
<t>the recommended pooling behaviour "pooled" and its contrary pooling
behaviour "arbitrary"; and</t>
<t>the recommended mapping behaviour "endpoint-independent"
and its contrary mapping behaviour "endpoint-dependent".</t>
</list></t>
<t>This document uses the term "address mapping" to denote an
association between an internal IP address and an IP address in a
selected external realm. See <xref target="realms"/> for a further
discussion of this process.
<list style="empty">
<t>The natMapIntAddrTable in the NAT MIB provides details on all
currently active address mappings. Note that this table is applicable
only when NAT pooling behaviour is "paired".</t>
</list>
</t>
<t>This document uses the <xref target="RFC4787"/> term "address and
port mapping" to denote a three-tuple association between an internal IP
address and port and an IP address and port in a selected external
realm, or between an internal <IP address, ICMP identifier> pair and
an <IP address, ICMP identifier> pair in the selected realm. For
implementations which maintain a Binding Information Base (BIB) (as
described in Section 2 of <xref target="RFC6146"/>, for example), the
content of a BIB entry is an address and port mapping.
<list style="empty">
<t>The natMappingTable in the NAT MIB provides details on all
currently active address and port mappings.</t>
</list>
</t>
<t>This document uses the term "session" as it is defined in <xref
target="RFC2663"/>, Section 2.3. From the point of view of this
document, session creation involves the combination of a source address
and port mapping with a mapping between internal and external
destination address and port to create a full five-tuple mapping.</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). The
event report descriptions provided in this document apply to NAPT, and
can be simplified for pure NAT operation.</t>
<t>To match the terminology used by the NAT MIB, this document uses the
term "subscriber" to denote any device being served by the NAT, whether
individual host or customer edge router. That is, despite the
carrier-oriented terminology, the intended scope of applicability of
this document is both to NATs in the carrier network and managed NATs in
the customer network. </t>
<t>Finally, with two exceptions, when the terms "source" or
"destination" are used below, they denote the source and destination of
packets that are flowing from the internal to the external realm,
regardless of the direction of session establishment or the direction of
flow of an individual packet. The exceptions relate to the global
address and port mapping limit event and the pending fragment limit
event, when the actual source and destination addresses in the header of
the packet that hit the limit are reported.</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. </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 address and port 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="realms" title="Realms and Address Pools">
<t>A realm identifies an IP numbering space. A NAT session always maps
between an internal and an external realm. In simple NAT
configurations, it may be possible to identify a default internal
realm and/or a default external realm for all sessions. In more complex
NAT configurations a given realm may be an internal realm for some
sessions and an external realm for others. Realms without subscriber
sites are always external.</t>
<t>Address pools are associated with specific realms in their external
role.</t>
<t>It is necessary to define multiple realms when the NAT supports
overlapping IP numbering spaces. In such a case, the NAT must determine
the source realm and subscriber using additional information associated
with the incoming packet. See further discussion in <xref
target="subsID"/>.</t>
<section anchor="pools" title="Address Pools">
<t>An address pool is a mechanism for configuring the set of addresses
to which a given internal address can be mapped in a given realm. The
pool may be used simply to ration the available addresses within that
realm, or may be selected for other reasons such as to add additional
semantics (e.g., type of service required) to the external address
within the target realm. Clearly a given internal address may be mapped
into more than one address pool at a given time.</t>
<t>The model of an address pool assumed in this document and in the
NAT MIB is that the pool offers a fixed range of port/ICMP identifier
values, the same over all addresses within the pool. How these are
allocated to individual mappings depends on the pooling behaviour.
With a pooling behaviour of "arbitrary", the NAT can select any
address in the pool with a free port value for the required protocol
and map the internal address to it. With the recommended pooling
behaviour of "paired", the NAT restricts itself to finding a free port
at the address to which the internal address is already mapped, if
there is one.</t>
<t>From this description, one can see that ports are a limited
resource, subject to exhaustion at the pool level and, with "paired"
behaviour, at the level of the individual address. Log events are
defined in <xref target="poolThresh"/> that allow monitoring of port
utilization at the pool level. <xref target="thrSet"/> discusses
how the thresholds for triggering these events should be varied
depending on pooling behaviour.</t>
</section> <!-- pools -->
</section> <!-- realms -->
<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="RFC7040"/>, 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 internal hosts will not be unique. As a consequence,
identification of the realm and subscriber from which the packet was
sent needs to include an additional 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"/>, two identifiers are needed: an identifier of the
softwire from the gateway to the NAT, and an identifier associated with
the incoming tunnel to the gateway.</t>
<t>The DS-Lite customer edge equipment (the 'B4') may also perform NAT44
functions, similar to the functions performed by traditional NAT44
devices.</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 edge. 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>
</section> <!-- transition -->
<section anchor="subsID" title="Subscriber Identification">
<t>The ability to identify the particular subscriber involved in an
event is required for the events defined in <xref target="resAlloc"/>,
and desirable for technician follow-up for those defined in <xref
target="subsThresh"/> and <xref target="limitEv"/>.</t>
<t>As mentioned above, in some NAT configurations the source address is
insufficient to identify an individual subscriber because of overlapping
address space, and additional information is required. For example, if the
NAT supports DS-Lite [RFC 6333], the source address of incoming packets
from DS-Lite subscribers will always be in the range 192.0.0/29. The
additional information required in this case is the IPv6 address of the
encapsulating header.</t>
<t>The natSubscribersTable in the NAT MIB contains the additional
information needed, if any, to identify each subscriber. Thus it is
sufficient to include the index to this table in the event report to
provide the needed identification. However, this implies that for full
interpretation of the event report, the configuration information stored
in the natSubscribersTable must be stored (along with AAA information
relating the additional identifiers to the subscriber profiles, which
must be stored in any event). To relieve the operator of the need to
store the configuration data (given that the logs may be needed months
or years after they were recorded), the reports specified in <xref
target="resAlloc"/> include the additional identifying information that
is found in the natSubscribersTable.</t>
<t>This document standardizes the presentation of the following possible
additional classifying information within NAT-related log reports:
<list style="symbols">
<t>interface index <xref target="RFC2863"/>;</t>
<t>VLAN index <xref target="RFC4363"/>;</t>
<t>VPN identifier <xref target="RFC4265"/>;</t>
<t>DS-Lite encapsulating IPv6 address <xref target="RFC6333"/>.</t>
</list>
Which of these is actually used in a given NAT depends on implementation
and deployment.</t>
<t>
<list style="empty">
<t>Gateway-Initiated DS-Lite <xref target="RFC6674"/> identifiers
could also be specified, but it seems premature to do so because it is
not clear which of the variety of possibilities presented in Section 6
and Appendix A.2 of <xref target="RFC6674"/> are actually being
deployed.</t>
</list>
</t>
</section> <!-- subsID -->
<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"/> and by provisions within the NAT MIB. Section 4 of <xref
target="RFC6888"/> also provides a brief statement of logging requirements
for carrier grade NATs.</t>
<t>In SYSLOG, 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>Parameters marked CONDITIONAL are REQUIRED under some circumstances
but not others. Details are provided for each event.</t>
<!-- ================================ -->
<section anchor="resAlloc" title="Events Relating To Allocation Of Resources To Hosts">
<t>Setting up a NAT session proceeds in a series of logical steps:
creation of an address mapping, creation of an address and port mapping,
and finally, creation of the session. </t>
<t>The reports corresponding to these three steps are defined in <xref
target="addrBind"/>, <xref target="MapCrDe"/>, and <xref
target="sessCrDe"/> respectively. Which of these reports is enabled
depends on the NAT implementation and operator preferences, subject to
the considerations of the next paragraph.</t>
<t>If the NAT implements the recommended pooling behaviour of
"paired", address mapping creation is an event distinct in general
from the creation of a subsequent address and port mapping based on
that address mapping. However, if the pooling behaviour is "arbitrary"
<xref target="RFC4787"/>, the two events occur simultaneously and
there is no point in reporting both. Similarly, if the NAT implements
the recommended mapping behaviour of "endpoint-independent mapping", the
two events of address and port mapping creation and session creation
based on that mapping are distinct and may meaningfully be reported
separately. However, if the mapping behaviour is "endpoint-dependent",
the two events occur simultaneously and it is only meaningful to report
session creation.</t>
<t>The fourth report type in this section describes the bulk allocation
of ports to an address mapping, which the NAT may implement if the
pooling behaviour is "paired" <xref target="RFC4787"/>. It, along with
the other reports, is needed to provide complete accountability for
resources allocated to the subscriber.</t>
<section anchor="addrBind" title="NAT Address Mapping Creation and Deletion">
<t>Two specific events are provided:
<list style="symbols">
<t>NAT address mapping creation;</t>
<t>NAT address mapping deletion.</t>
</list>
Implementations MUST NOT report these events unless pooling
behaviour is "paired".
</t>
<t>Address mapping is discussed in detail in <xref target="realms"/>. </t>
<t>One address mapping creation event is associated with potentially
many succeeding address and port mapping creation events, as
individual port values are mapped for specific protocols. Similarly,
an address mapping deletion event may be associated with potentially
many address and port mapping deletion events, which may have preceded
it over a period of time or may occur at the same time as a result of
the address unbinding.</t>
<t>The address mapping events take the following specific parameters:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Source subscriber index (MANDATORY);</t>
<t>Additional source subscriber classifier value as recognized at
the ingress to the internal realm (CONDITIONAL);</t>
<t>Internal realm (CONDITIONAL);</t>
<t>Internal address type (MANDATORY);</t>
<t>Internal source IP address (MANDATORY);</t>
<t>External realm (CONDITIONAL);</t>
<t>External address type (MANDATORY);</t>
<t>External source IP address (MANDATORY);</t>
<t>Trigger for address mapping creation or deletion (OPTIONAL):
<list style="symbols">
<t>outgoing packet; </t>
<t>administrative action (e.g., via the Port Control Protocol
<xref target="RFC6887"/>); or</t>
<t>autonomous action of the NAT.</t>
</list>
</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
<t>Additional source subscriber classifier value REQUIRED if the
internal source IP address is not enough to identify the subscriber
unambiguously, else MUST NOT appear.</t>
<t>Internal or external realm REQUIRED if not the default internal
or external realm, respectively, else MAY appear.</t>
</list>
</t>
</section> <!-- addrBind -->
<section anchor="MapCrDe" title="NAT Address and Port Mapping Creation and Deletion">
<t>The address and port mapping creation or deletion event reports the
addition or deletion of an address and port mapping as defined in <xref
target="terms"/>. If the implementation maintains a Binding Information
Base (BIB), this is equivalent to the creation or deletion of a BIB
entry. Implementations MUST support the generation of the address and
port mapping creation/deletion event reports if they implement the
recommended mapping behaviour "endpoint-independent". They MAY support
reporting of these events in the contrary case. </t>
<t>The address and port mapping creation/deletion event report
provides the same information as the session creation/deletion event,
except for the destination-related fields and (in general) timestamp
values in the latter. With "endpoint-independent" mapping behaviour,
one address and port mapping creation event is associated with
potentially many succeeding session creation events. Similarly, an
address and port mapping deletion event will be associated with
potentially many session deletion events, which may have preceded it
over a period of time or may occur at the same time as a result of the
address and port mapping deletion.</t>
<t>Operators should disable the reporting of address and port mapping
creation and deletion events when destination logging is enabled,
because of the redundancy between the address and port mapping and
session event reports. However, if destination logging is disabled and
the NAT uses the recommended "endpoint-independent" mapping behaviour,
it is the session events that are redundant and should be
disabled.</t>
<t>The following specific events are defined:
<list style="symbols">
<t>NAT address and port mapping creation</t>
<t>NAT address and port mapping deletion</t>
</list>
</t>
<t>These take the same parameters for all types of NAT. The internal
realm, subscriber-identifying information, internal source IP address,
external realm, and external source IP address capture the underlying
address mapping. The port values and protocol are unique to the
address and port mapping.</t>
<t>The parameters for the address and port mapping creation/deletion
event are:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Source subscriber index (MANDATORY);</t>
<t>Additional source subscriber classifier value as recognized at
the ingress to the internal realm (CONDITIONAL);</t>
<t>Internal realm (CONDITIONAL);</t>
<t>Internal address type (MANDATORY);</t>
<t>Internal source IP address (MANDATORY);</t>
<t>Internal source port or ICMP identifier (MANDATORY);</t>
<t>External realm (CONDITIONAL);</t>
<t>External address type (MANDATORY);</t>
<t>External source IP address (MANDATORY);</t>
<t>External source port or ICMP identifier (MANDATORY);</t>
<t>Protocol identifier (MANDATORY);</t>
<t>Trigger for address and port mapping creation or deletion (OPTIONAL):
<list style="symbols">
<t>outgoing packet received; </t>
<t>incoming packet received;</t>
<t>administrative action (e.g., via the Port Control Protocol
<xref target="RFC6887"/>); or</t>
<t>deletion of the underlying address mapping (applicable only if
pooling behaviour is "paired" <xref target="RFC4787"/>).</t>
</list>
</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
<t>Additional source subscriber classifier value REQUIRED if the
internal source IP address is not enough to identify the subscriber
unambiguously, else MUST NOT appear.</t>
<t>Internal or external realm REQUIRED if not the default internal
or external realm, respectively, else MAY appear.</t>
</list>
</t>
</section> <!-- MapCrDe -->
<section anchor="sessCrDe" title="NAT Session Creation and Deletion">
<t>A NAT session creation or deletion event is logged when a address
and port mapping is further bound to or unbound from a specific
destination address and port in the external realm. One to many
sessions can be based on the same address and port mapping.</t>
<t>Implementations MUST provide a means for the operator to specify
whether destination information is to be included in the reports of
these events (see discussion below).
</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. Parameters
"internal realm" through "protocol identifier" capture the underlying
address and port mapping. Subsequent parameters capture the
destination address and destination subscriber identity (if
applicable).</t>
<t>The parameters for the session creation/deletion event are:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Internal source subscriber index, equal to the natSubscriberIndex
value in the natSubscribersTable in the NAT MIB (MANDATORY);</t>
<t>Additional internal subscriber classifier value (CONDITIONAL);</t>
<t>Internal realm (CONDITIONAL);</t>
<t>Internal address type (MANDATORY);</t>
<t>Internal source IP address (MANDATORY);</t>
<t>Internal source port or ICMP identifier (MANDATORY);</t>
<t>External realm (CONDITIONAL);</t>
<t>External address type (MANDATORY);</t>
<t>External source IP address (MANDATORY);</t>
<t>External source port or ICMP identifier (MANDATORY);</t>
<t>Protocol identifier (MANDATORY);</t>
<t>Internal destination IP address (CONDITIONAL);</t>
<t>Internal destination port or ICMP identifier (CONDITIONAL);</t>
<t>Destination subscriber index (CONDITIONAL);</t>
<t>Additional destination subscriber classifier value as recognized
at the ingress to the external realm (CONDITIONAL);</t>
<t>External destination IP address (CONDITIONAL);</t>
<t>External destination port or ICMP identifier (CONDITIONAL);</t>
<t>Trigger for session creation or deletion (OPTIONAL):
<list style="symbols">
<t>outgoing packet received; </t>
<t>incoming packet received;</t>
<t>administrative action (e.g., via the Port Control Protocol
<xref target="RFC6887"/>); or</t>
<t>deletion of the underlying address and port mapping (applicable
only if the NAT mapping behaviour is "endpoint-independent".</t>
</list>
</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
<t>Additional source subscriber classifier value REQUIRED if the
internal source IP address is not enough to identify the subscriber
unambiguously, else MUST NOT appear.</t>
<t>Internal or external realm REQUIRED if not the default internal
or external realm, respectively, else MAY appear.</t>
<t>Internal destination address and port REQUIRED if destination
logging is enabled and these need to be remapped to external
destination address and port. Otherwise, if destination logging is
disabled, they MUST NOT appear, and if destination logging is
enabled, they SHOULD NOT appear because of redundancy.</t>
<t>External destination subscriber index REQUIRED if destination
logging is enabled and the destination is a subscriber served by the
NAT, else MUST NOT appear.</t>
<t>Additional external subscriber classifier value REQUIRED if
destination logging is enabled and the destination is a subscriber
served by the NAT and the external destination address is not enough
to identify the external destination subscriber unambiguously, else
MUST NOT appear. </t>
<t>External destination address and port REQUIRED if destination
logging is enabled, else MUST NOT appear. </t>
</list>
</t>
<section anchor="destLog" title="Destination Logging">
<t>The logging of destination address and port is
undesirable, 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 to 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. In that case, most
of the contents of the session creation event report will be repeated
for one destination after another.</t>
<t>One possibility is that the implementation provides the operator
with the ability to log destinations only for particular subscribers
or particular mapped addresses on a special study basis. This facility
could be used for trouble-shooting or malicious activity tracing in
particular cases as required. If such a capability is provided, the
implementation MUST report destination information for sessions
matching the specified criteria, but MUST NOT report these events
for other sessions.</t>
</section> <!-- destLog -->
</section> <!-- sessCrDe -->
<section anchor="portAssgn" title="Port Range Allocation and Deallocation">
<t>This event is recorded at a hybrid NAT whenever the set of ports
allocated to a given address mapping changes. It is assumed that when
ports are allocated in bulk, the same values are allocated for all
protocols.</t>
<t>The following specific events are defined:
<list style="symbols">
<t>Port range allocation;</t>
<t>Port range deallocation.</t>
</list>
</t>
<t>The parameters for these events are:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Source subscriber index (MANDATORY);</t>
<t>Additional source subscriber classifier value as recognized at
the ingress to the internal realm (CONDITIONAL);</t>
<t>Internal realm (CONDITIONAL);</t>
<t>Internal address type (MANDATORY);</t>
<t>Internal source IP address (MANDATORY);</t>
<t>External realm (CONDITIONAL);</t>
<t>External address type (MANDATORY);</t>
<t>External source IP address (MANDATORY);</t>
<t>Lowest port number of the range being allocated or
deallocated (MANDATORY).</t>
<t>Highest port number of the range being allocated or
deallocated (MANDATORY).</t>
<t>Trigger for port range allocation or deallocation (OPTIONAL):
<list style="symbols">
<t>outgoing packet received; </t>
<t>incoming packet received;</t>
<t>administrative action (e.g., via the Port Control Protocol
<xref target="RFC6887"/>); or</t>
<t>autonomous action of the NAT.</t>
</list>
</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
<t>Additional source subscriber classifier value REQUIRED if the
internal source IP address is not enough to identify the subscriber
unambiguously, else MUST NOT appear.</t>
<t>Internal or external realm REQUIRED if not the default internal
or external realm, respectively, else MAY appear.</t>
</list>
</t>
<t>It will be necessary to use multiple event reports to report more
complex allocations or deallocations.</t>
</section> <!-- portAssgn -->
</section> <!-- resAlloc -->
<!-- ======================================== -->
<section anchor="threshEv" title="Threshold Events">
<t>The events of this section are based on thresholds set by the
operator within the NAT MIB. Cross-references to the associated MIB
objects are provided for each event. With the exception of the address
pool low-water-mark event, the threshold events provide early warning of
potential dropped packets due to resource exhaustion or
administrator-imposed limits.</t>
<section anchor="poolThresh" title="Address Pool High- and Low-Water-Mark Threshold Events">
<t>Two specific events provide reports on address pool utilization:
<list style="symbols">
<t>High-water-mark threshold reached or exceeded;</t>
<t>Low-water-mark threshold reached or under-shot.</t>
</list>
Depending on deployment the operator has the alternative of using the
SNMP notifications natNotifPoolWater-MarkHigh and
natNotifPoolWater-MarkLow defined in the NAT MIB rather than
logging these events. </t>
<t>Address pools are discussed in <xref target="pools"/>. The
natPoolTable object in the NAT MIB
provides access to parameters describing the utilization level of
address-port combinations within a given pool. Since a new
mapping cannot be allocated unless a mappable address and a free port on
that address are available, it is important to know when the available
set of address-port combinations within a given pool is nearing
exhaustion. Hence the natPoolTable contains a high-water-mark
threshold settable by the operator. An address pool high-water-mark
event report is generated when a new mapping into the pool is
requested and aggregate address-port utilization is equal to or
greater the threshold.</t>
<t>Similarly it can be of interest to know when a pool is
under-utilized. Hence the natPoolTable also provides a low-water-mark
threshold. An address pool low-water-mark event report is generated
when aggregate address-port utilization is equal to or less than the
low-water-mark threshold.</t>
<t><xref target="thrSet"/> discusses factors affecting the choice
of the threshold values.</t>
<t>The high-water-mark threshold event provides a warning that the
address-port combinations offered by the pool are nearing exhaustion.
Upon exhaustion, subscribers may be unable to establish new connections
because no address has enough free port values left to be allocated to
an address mapping ("address exhaustion"). This applies to the case of
"paired" pooling behaviour, where typically an
address will not be allocated unless it has a sufficient number of free
ports. Alternatively, new connections cannot be established simply
because no address in the pool has a free port number for the required
protocol ("port exhaustion").</t>
<t>Packets triggering failed attempts to establish new connections due
to address exhaustion are included in the following NAT MIB
dropped packet counters:
<list style="symbols">
<t>globally, natResourceErrors in the natCounters table;</t>
<t>per protocol, natProtocolResourceErrors in natProtocolTable;</t>
<t>per subscriber, natSubscriberResourceErrors in
natSubscribersTable.</t>
</list>
</t>
<t>Packets triggering failed attempts to establish new connections due
to port exhaustion are counted in the following NAT MIB
dropped packet counters:
<list style="symbols">
<t>globally, natOutOfPortErrors in the natCounters table;</t>
<t>per protocol, natProtocolOutOfPortErrors in natProtocolTable;</t>
<t>per subscriber, natSubscriberOutOfPortErrors in
natSubscribersTable.</t>
</list>
</t>
<t>An address pool threshold event report contains the following
specific parameters:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Pool identifier (MANDATORY);</t>
<t>The threshold value set by the administrator (MANDATORY).</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
</section> <!-- poolThresh -->
<!-- ================= -->
<section anchor="addrThresh" title="Global Address Mapping High-Water-Mark Threshold Event">
<t>One specific event allows monitoring of the total number of mappings
between internal and external addresses:
<list style="symbols">
<t>Address mapping high-water-mark threshold exceeded.</t>
</list>
Implementations MUST NOT generate this event report unless the pooling
behaviour is "paired". Depending on
deployment, operators can choose instead to use the SNMP notification
natNotifAddrMappings defined in the NAT MIB.</t>
<t>The NAT MIB displays cumulative counts of address mappings created
and removed in the natCounters table. When the difference between
these two counters is greater than the threshold
natAddrMapNotifyThreshold provided in the natLimits table the global
address binding high-water-mark threshold event is reported.</t>
<t>The specific parameters provided by this event report are:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Current number of active address mappings (MANDATORY).</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
</section> <!-- addrThresh -->
<!-- ================= -->
<section anchor="transThresh" title="Global Address and Port Mapping High-Water-Mark Threshold Event">
<t>One specific event allows monitoring of the total number of active
address and port mappings. Where the NAT implements a BIB, this is
equivalent to the total number of BIB entries.
<list style="symbols">
<t>address and port mapping high-water-mark threshold exceeded.</t>
</list>
Depending on deployment, operators can choose instead to use the SNMP
notification natNotifMappings defined in the NAT MIB.</t>
<t>The NAT MIB displays cumulative counts of address and port mappings
created and removed in the natCounters table. When the difference
between these two counters is greater than the threshold
natMappingsNotifyThreshold provided in the natLimits table the global
mapping high-water-mark threshold event is reported.</t>
<t>The specific parameters provided by this event report are:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Current number of active address and port mappings
(MANDATORY).</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
</section> <!-- transThresh -->
<!-- ================= -->
<section anchor="subsThresh" title="Subscriber-Specific Address and Port Mapping Threshold Event">
<t>An event is provided to allow monitoring of the total number of
active mappings per subscriber:
<list style="symbols">
<t>Subscriber-specific mapping high-water-mark threshold exceeded.</t>
</list>
Depending on deployment, operators can choose instead to
use the SNMP notification natNotifSubscriberMappings defined in the NAT
MIB.</t>
<t>The NAT MIB displays cumulative counts of address and port mappings
created and removed per subscriber in the natSubscribersTable. When
the difference between these two counters is greater than the
threshold natSubscriberMapNotifyThresh provided in that table the
subscriber address and port mapping high-water-mark threshold event is
reported.</t>
<t>The specific parameters provided by this event report are:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Index of the affected subscriber (MANDATORY).</t>
<t>Current number of active mappings for this subscriber
(MANDATORY).</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
</section> <!-- subsThresh -->
</section> <!-- threshEv -->
<!-- ========================================================== -->
<section anchor="limitEv" title="Limit-Related Events">
<t>The events of this section are generated when hard limits set by the
operator are exceeded. The consequence for service will be dropped
packets. As with the threshold events, the description of each report
includes cross-references to the associated MIB objects.</t>
<section anchor="addrMapLim" title="Global Address Mapping Limit Exceeded">
<t>The global address mapping limit exceeded event is reported when a
new address mapping is requested but the total number of address
mappings would exceed an administrative limit if it were added. The
limit is given by object natLimitAddressMappings in the natLimits table
of the NAT MIB. MIB counters giving number of packets dropped due to
resource limitations including this one are:
<list style="symbols">
<t>globally, natResourceErrors in the natCounters table;</t>
<t>per protocol, natProtocolResourceErrors in natProtocolTable;</t>
<t>per subscriber, natSubscriberResourceErrors in
natSubscribersTable.</t>
</list>
</t>
<t>Implementations MUST NOT generate this event report unless the pooling
behaviour is "paired". Depending on
deployment, operators can choose instead to use the SNMP notification
natNotifAddrMappings defined in the NAT MIB.</t>
<t>The parameters for this event are:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Index of the affected subscriber (MANDATORY).</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
<t>The subscriber index is provided to allow the operator to correlate
the event with any subscriber complaints or possible abuse.</t>
</section> <!-- addrMapLim -->
<!-- ================= -->
<section anchor="transMapLim" title="Global Address and Port Mapping Limit Exceeded">
<t>The global address and port mapping limit exceeded event is
reported when a new address and port mapping is requested but the
total number of address and port mappings would exceed an
administrative limit if it were added. The limit is given by object
natLimitMappings in the natLimits table of the NAT MIB. MIB counters
giving number of packets dropped due to resource limitations including
this one are:
<list style="symbols">
<t>globally, natResourceErrors in the natCounters table;</t>
<t>per protocol, natProtocolResourceErrors in natProtocolTable;</t>
<t>per subscriber, natSubscriberResourceErrors in
natSubscribersTable.</t>
</list>
</t>
<t>The parameters for this event are:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Index of the internal subscriber (CONDITIONAL);</t>
<t>Index of the external subscriber (CONDITIONAL);</t>
<t>Source realm of the triggering packet (MANDATORY);</t>
<t>Incoming packet header IP address type (CONDITIONAL);</t>
<t>Incoming packet source IP address (CONDITIONAL).</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
<t>The index of the internal subscriber is REQUIRED if the mapping
was triggered by a packet outgoing from the internal to the external
realm, else MUST NOT appear.</t>
<t>The index of the external subscriber is REQUIRED if
the mapping was triggered by a packet incoming from a subscriber
served by the NAT and located in the external realm (i.e., using an
address mapping created previously by the internal subscriber), else
MUST NOT appear.</t>
<t>The address type and source IP address from the initiating packet
are REQUIRED if the mapping was triggered by a packet incoming from
a purely external realm (i.e., using an address mapping created
previously by the internal subscriber), else MAY appear.</t>
</list>
</t>
<t>The subscriber index or packet source address is provided to allow
the operator to correlate the event with any subscriber complaints or
possible abuse.</t>
</section> <!-- transMapLim -->
<!-- ================= -->
<section anchor="actSubsLim" title="Global Limit On Number of Active Hosts Exceeded">
<t>The global limit on number of active hosts exceeded event is
reported when an address mapping is requested (at least at the logical
level) for a host with no previous active mappings, but the total
number of active hosts would exceed an administrative limit if it
were added. The limit is given by object natLimitSubscribers in the
natLimits table of the NAT MIB. MIB counters giving number of packets
dropped due to resource limitations including this one are:
<list style="symbols">
<t>globally, natResourceErrors in the natCounters table;</t>
<t>per protocol, natProtocolResourceErrors in natProtocolTable;</t>
<t>per subscriber, natSubscriberResourceErrors in
natSubscribersTable.</t>
</list>
</t>
<t>The parameters for this event are:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Index of the affected subscriber (MANDATORY).</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
<t>The subscriber index is provided to allow the operator to correlate
the event with any subscriber complaints.</t>
</section> <!-- actSubsLim -->
<section anchor="subsMapLim" title="Subscriber-Specific Limit On Number of Address and Port Mappings Exceeded">
<t>The subscriber-specific limit on number of address and port
mappings exceeded event is reported when a new mapping is requested,
but the total number of active mappings for that subscriber would
exceed an administrative limit if it were added. The limit is given by
object natSubscriberLimitMappings in natSubscribersTable in the NAT
MIB. MIB counters giving number of packets dropped due to resource
limitations including this one are:
<list style="symbols">
<t>globally, natResourceErrors in the natCounters table;</t>
<t>per protocol, natProtocolResourceErrors in natProtocolTable;</t>
<t>per subscriber, natSubscriberResourceErrors in
natSubscribersTable.</t>
</list>
</t>
<t>The parameters for this event are:
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Index of the affected subscriber (MANDATORY).</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
<t>The subscriber index is provided to allow the operator to take
administrative action or to correlate the event with any subscriber
complaints or possible abuse.</t>
</section> <!-- subsMapLim -->
<section anchor="fragLim" title="Global Limit On Number Of Fragments Pending Reassembly Exceeded">
<t>The global limit on number of fragments pending reassembly exceeded
event is reported when a new fragment is received and the number of
fragments currently awaiting reassembly is already equal to an
administrative limit. That limit is given by the natLimitFragments
object in the natLimits table. This event MUST NOT be reported unless
the NAT supports the "receive fragments out of order" behavior <xref
target="RFC4787"/>. MIB counters giving number of packets
dropped due to resource limitations including this one are:
<list style="symbols">
<t>globally, natResourceErrors in the natCounters table;</t>
<t>per protocol, natProtocolResourceErrors in natProtocolTable;</t>
<t>per subscriber, natSubscriberResourceErrors in
natSubscribersTable.</t>
</list>
</t>
<t>The parameters for this event provide the contents of the IP header
of the received fragment that triggered it. If the source of the
packet is a subscriber served by the NAT and the subscriber index can
be determined, it MUST also be included.
<list style="symbols">
<t>NAT instance identifier (CONDITIONAL);</t>
<t>Source realm of the packet (MANDATORY);</t>
<t>Packet header IP address type (MANDATORY);</t>
<t>Packet source IP address (MANDATORY);</t>
<t>Packet destination IP address (MANDATORY);</t>
<t>Source subscriber index (CONDITIONAL).</t>
</list>
</t>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
<t>Source subscriber index REQUIRED if the source of the packet is a
subscriber served by the NAT and can be determined, else MUST NOT
appear.</t>
</list>
</t>
</section> <!-- fragLim -->
</section> <!-- limitEv -->
</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 other header 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 example in <xref target="SessCode"/>, if
destination logging is enabled, typical record sizes for session event
logs are in the order of 300 bytes, so throughput capacity should be
higher than in the call detail case for the same amount of computing
power. However, note that bursts of session deletion events may occur as
a result of deletion of the underlying mapping or address mapping. </t>
<t>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 Severity value of 6
(Informational) is suggested for the events relating to creation and
deletion of sessions, mappings, address mappings, and port allocation,
combined with a suitable Facility value in the range 16-23 (local use)
to ensure routing to a secure collector. The Facility value(s) for the
threshold and limit events will presumably be chosen to route
them to maintenance for immediate action and/or to provisioning for less
urgent consideration. The suggested value of Severity by event type is
shown in <xref target="tab_events"/>, but in practice has a clear
dependency on the context within which the NAT is operating. </t>
<t>The TIMESTAMP field SHOULD be expressed with sufficient precision to
distinguish non-simultaneous event occurrences, subject to the accuracy
of the local clock. This specification does not assume the ability to
correlate the events reported by the subject device with events recorded
by other devices, although that may be required for other reasons. Hence
from the point of view of this specification only relative rather than
absolute accuracy is of interest.</t>
<t>The HOSTNAME header field MUST identify the NAT device. 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. To simplify log collection
procedures, the APP-NAME value "NAT" MUST be used for the event reports
specified in <xref target="resAllocCode"/>, the APP-NAME value "NATTHR"
MUST be used for the event types defined in <xref
target="threshEvCode"/>, and the APP-NAME value "NATLIM"
MUST be used for the event types defined in <xref
target="limitEvCode"/>.</t>
<t>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 Severity Values for the Events Defined In Section 3">
<ttcol align="left">Event</ttcol>
<ttcol align="left">APP-NAME</ttcol>
<ttcol align="left">MSGID</ttcol>
<ttcol align="left">Severity</ttcol>
<ttcol align="left">SD-ID</ttcol>
<c>NAT address mapping creation</c>
<c>NAT</c>
<c>AMADD</c>
<c>6 info</c>
<c>namap</c>
<c>NAT address mapping deletion</c>
<c>NAT</c>
<c>AMDEL</c>
<c>6 info</c>
<c>namap</c>
<c>NAT address and port mapping creation</c>
<c>NAT</c>
<c>APMADD</c>
<c>6 info</c>
<c>napmap</c>
<c>NAT address and port mapping deletion</c>
<c>NAT</c>
<c>APMDEL</c>
<c>6 info</c>
<c>napmap</c>
<c>NAT session creation</c>
<c>NAT</c>
<c>SADD</c>
<c>6 info</c>
<c>nsess</c>
<c>NAT session deletion</c>
<c>NAT</c>
<c>SDEL</c>
<c>6 info</c>
<c>nsess</c>
<c>Port range allocation</c>
<c>NAT</c>
<c>PTADD</c>
<c>6 info</c>
<c>nprng</c>
<c>Port range deallocation</c>
<c>NAT</c>
<c>PTDEL</c>
<c>6 info</c>
<c>nprng</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Address pool high threshold</c>
<c>NATTHR</c>
<c>POOLHT</c>
<c>4 warning</c>
<c>npool</c>
<c>Address pool low threshold</c>
<c>NATTHR</c>
<c>POOLLT</c>
<c>6 info</c>
<c>npool</c>
<c>Global address mapping high threshold</c>
<c>NATTHR</c>
<c>GAMHT</c>
<c>4 warning</c>
<c>ngamht</c>
<c>Global address and port mapping high threshold</c>
<c>NATTHR</c>
<c>GAPMHT</c>
<c>4 warning</c>
<c>ngapmht</c>
<c>Subscriber-specific mapping high threshold</c>
<c>NATTHR</c>
<c>SAPMHT</c>
<c>5 notice</c>
<c>nsapmht</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Global address mapping limit</c>
<c>NATLIM</c>
<c>GAMLIM</c>
<c>3 error</c>
<c>ngaml</c>
<c>Global address and port mapping limit</c>
<c>NATLIM</c>
<c>GAPMLIM</c>
<c>3 error</c>
<c>ngapml</c>
<c>Global active subscriber limit</c>
<c>NATLIM</c>
<c>GSLIM</c>
<c>3 error</c>
<c>ngsl</c>
<c>Subscriber-specific address and port mapping limit</c>
<c>NATLIM</c>
<c>SAPMLIM</c>
<c>5 notice</c>
<c>nsapml</c>
<c>Pending fragment limit</c>
<c>NATLIM</c>
<c>FRAG</c>
<c>4 warning</c>
<c>nfpkt</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"/>. The PARAM-NAMEs, brief
descriptions, and encoding are listed in <xref target="tab_param_enc"/>,
with reference to the general and special case encoding rules which
follow.
</t>
<texttable anchor="tab_param_enc" title="Parameters Used In NAT-Related Log Reports">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Encoding</ttcol>
<c></c>
<c>Miscellaneous</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>NATINST</c>
<c>NAT instance identifier</c>
<c>Text</c>
<c>TRIG</c>
<c>Trigger for event</c>
<c>Special case</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Subscriber-identifying information</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>SSUBIX</c>
<c>Source subscriber index</c>
<c>32-bit field</c>
<c>SIFIX</c>
<c>Source subscriber ingress interface index list</c>
<c>Special case</c>
<c>SVLAN</c>
<c>Source subscriber ingress VLAN index</c>
<c>32-bit field</c>
<c>SVPN</c>
<c>Source subscriber ingress VPN Id</c>
<c>Special case</c>
<c>SV6ENC</c>
<c>Source subscriber ingress RFC6333 encapsulating IPv6 address</c>
<c>IPv6 address</c>
<c>DSUBIX</c>
<c>Destination subscriber index</c>
<c>32-bit field</c>
<c>DIFIX</c>
<c>Destination subscriber ingress interface index list</c>
<c>Special case</c>
<c>DVLAN</c>
<c>Destination subscriber ingress VLAN index</c>
<c>32-bit field</c>
<c>DVPN</c>
<c>Destination subscriber ingress VPN Id</c>
<c>Special case</c>
<c>DV6ENC</c>
<c>Destination subscriber ingress RFC6333 encapsulating IPv6 address</c>
<c>IPv6 address</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Internal packet description</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>IRLM</c>
<c>Internal realm</c>
<c>Text</c>
<c>IATYP</c>
<c>Internal IP address type</c>
<c>"IPv4" or "IPv6"</c>
<c>ISADDR</c>
<c>Internal source IP address value</c>
<c>IPv4 or IPv6 address</c>
<c>ISPORT</c>
<c>Internal source port or ICMP identifier value</c>
<c>16-bit field</c>
<c>IDADDR</c>
<c>Internal destination IP address value</c>
<c>IPv4 or IPv6 address</c>
<c>IDPORT</c>
<c>Internal destination port or ICMP identifier value</c>
<c>16-bit field</c>
<c>PROTO</c>
<c>Protocol identifier (from the IANA Assigned Internet Protocol
Numbers registry)</c>
<c>8-bit field</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>External (mapped) packet description</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>XRLM</c>
<c>External realm</c>
<c>Text</c>
<c>XATYP</c>
<c>External IP address type</c>
<c>"IPv4" or "IPv6"</c>
<c>XSADDR</c>
<c>External source IP address value</c>
<c>IPv4 or IPv6 address</c>
<c>XSPORT</c>
<c>External source port or ICMP identifier value</c>
<c>16-bit field</c>
<c>XDADDR</c>
<c>External destination IP address value</c>
<c>IPv4 or IPv6 address</c>
<c>XDPORT</c>
<c>External destination port or ICMP identifier value</c>
<c>16-bit field</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Port range description</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>PORTMN</c>
<c>Port range lowest value</c>
<c>16-bit field</c>
<c>PORTMX</c>
<c>Port range highest value</c>
<c>16-bit field</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Values related to thresholds</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>POOLID</c>
<c>Address pool identifier</c>
<c>32-bit field</c>
<c>POOLHW</c>
<c>Address pool high water mark threshold</c>
<c>Unsigned decimal</c>
<c>POOLID</c>
<c>Address pool low water mark threshold</c>
<c>Unsigned decimal</c>
<c>GAMCNT</c>
<c>Current global number of address mappings</c>
<c>Unsigned decimal</c>
<c>GAPMCNT</c>
<c>Current global number of address and port mappings</c>
<c>Unsigned decimal</c>
<c>SAPMCNT</c>
<c>Current subscriber-specific number of address and port mappings</c>
<c>Unsigned decimal</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Specific incoming packet description</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>PSRLM</c>
<c>Packet source realm</c>
<c>Text</c>
<c>PATYP</c>
<c>Packet IP address type</c>
<c>"IPv4" or "IPv6"</c>
<c>PSADDR</c>
<c>Packet source IP address</c>
<c>IPv4 or IPv6 address</c>
<c>PDADDR</c>
<c>Packet destination IP address</c>
<c>IPv4 or IPv6 address</c>
</texttable>
<section anchor="genEncod" title="General Encoding Rules">
<t>All fields MUST be encoded as 7-bit US ASCII
<xref target="US-ASCII"/>.</t>
<t>Complete IPv6 addresses MUST be presented according to the rules
specified in Sections 4 and 5 of <xref target="RFC5952"/>, without a
succeeding prefix length. The Section 5 rules MUST NOT be applied unless
the address can be distinguished as having an IPv4 address embedded in
the lower 32 bits solely from the IPv6 prefix portion (e.g., based on
well-known prefix, flag), without external information. In such cases,
the IPv6 prefix portion MUST be presented according to the Section 4
rules. Stand-alone IPv6 prefixes (i.e., outside of special addresses)
MUST be presented according to the Section 4 rules, with the slash
character (/) appended, followed by a decimal value with leading
zeroes suppressed, giving the prefix length (0 to 127) in bits. </t>
<t>Similarly, complete IPv4 addresses MUST be presented in dotted
decimal format, with no succeeding prefix length. IPv4 prefixes MUST
be presented as if they were full addresses, with the slash character
(/) appended, followed by a decimal value with leading zeroes
suppressed, giving the prefix length (0 to 31) in bits.</t>
<t>N-bit fields and unsigned decimals are both presented as unsigned
decimal integers with no leading zeroes.</t>
</section> <!-- genEncod -->
<section anchor="specEncod" title="Special Cases">
<t>Three special cases are identified in <xref
target="tab_param_enc"/>: encoding of the interface index list
(PARAM-NAMEs SIFIX and DIFIX), encoding of the VPN identifier
(PARAM-NAMEs SVPN and DVPN), and encoding of the trigger for resource
allocation events (PARAM-NAME TRIG).</t>
<t>The interface index list is presented as a series of individual
interface indexes separated by commas, e.g., SIFIX="5,15". Each
individual interface index is presented as a 32-bit field (i.e., as an
unsigned decimal integer with no leading zeroes).</t>
<t>The VPN Identifier is standardized in <xref target="RFC2685"/>, and
consists of a three octet VPN Authority (Organizationally Unique
Identifier, OUI) followed by a four octet VPN index identifying the
VPN according to OUI. For SYSLOG, the OUI portion is presented as a
string of six hexadecimal digits in lower case. The VPN index is
presented as a 32-bit field. A colon (:) is used to separate the OUI
from the succeeding index value. The OUI and separator MAY be omitted.
If so, the applicable OUI is the default value for the NAT
instance.</t>
<t>The trigger is an enumeration of text values which were not spelled
out in the table itself for lack of space. The possible values for
TRIG are:
<list style="hanging">
<t hangText='"OPKT":'>outgoing packet received at NAT.</t>
<t hangText='"IPKT":'>incoming packet received at NAT.</t>
<t hangText='"ADMIN":'>administrative action.</t>
<t hangText='"APMDEL":'>deletion of the underlying address
and port mapping.</t>
<t hangText='"AMDEL":'>deletion of the underlying address
mapping.</t>
<t hangText='"AUTO":'>autonomous action of the NAT.</t>
</list>
The values applicable for any specific event are a subset of this list
and are spelled out for each event in <xref target="evCode"/>.</t>
</section> <!-- specEncod -->
<section anchor="parmToMIB" title="Relationship To Objects In the NAT MIB">
<t> <xref target="tab_param_mib"/> lists the parameters in the same
order as <xref target="tab_param_enc"/> and relates each parameter to
its corresponding object in the NAT MIB.</t>
<texttable anchor="tab_param_mib" title="Relationship of Parameters To Objects In the NAT MIB">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Related MIB Object(s)</ttcol>
<c>Miscellaneous</c>
<c></c>
<c></c>
<c></c>
<c>NATINST</c>
<c>natInstanceAlias in natInstanceTable</c>
<c>TRIG</c>
<c>None</c>
<c></c>
<c></c>
<c>Subscriber-identifying information</c>
<c></c>
<c></c>
<c></c>
<c>SSUBIX</c>
<c>natSubscriberIndex in natSubscribersTable</c>
<c>SIFIX</c>
<c>natSubsInterfaceIndex in natSubsInterfaceIdentifierTable</c>
<c>SVLAN</c>
<c>natSubscriberVlanIdentifier in natSubscribersTable</c>
<c>SVPN</c>
<c>natSubscriberVpnIdentifier in natSubscribersTable</c>
<c>SV6ENC</c>
<c>natSubscriberIPEncapsIdType and natSubscriberIPEncapsIdAddr
in natSubscribersTable</c>
<c>DSUBIX</c>
<c>natSubscriberIndex in natSubscribersTable</c>
<c>DIFIX</c>
<c>natSubsInterfaceIndex in natSubsInterfaceIdentifierTable</c>
<c>DVLAN</c>
<c>natSubscriberVlanIdentifier in natSubscribersTable</c>
<c>DVPN</c>
<c>natSubscriberVpnIdentifier in natSubscribersTable</c>
<c>DV6ENC</c>
<c>natSubscriberIPEncapsIdType and natSubscriberIPEncapsIdAddr
in natSubscribersTable</c>
<c></c>
<c></c>
<c>Internal packet description</c>
<c></c>
<c></c>
<c></c>
<c>IRLM</c>
<c>natSubscriberRealm in natSubscribersTable</c>
<c>IATYP</c>
<c>natMapIntAddrIntType in natMapIntAddrTable or
natMappingIntAddressType in natMappingTable</c>
<c>ISADDR</c>
<c>natMapIntAddrInt in natMapIntAddrTable or
natMappingIntAddress in natMappingTable</c>
<c>ISPORT</c>
<c>natMappingIntPort in natMappingTable</c>
<c>IDADDR</c>
<c>None</c>
<c>IDPORT</c>
<c>None</c>
<c>PROTO</c>
<c>natMappingProto in natMappingTable</c>
<c></c>
<c></c>
<c>External (mapped) packet description</c>
<c></c>
<c></c>
<c></c>
<c>XRLM</c>
<c>natPoolRealm in natPoolTable</c>
<c>XATYP</c>
<c>natMapIntAddrExtType in natMapIntAddrTable or
natMappingExtAddressType in natMappingTable</c>
<c>XSADDR</c>
<c>natMapIntAddrExt in natMapIntAddrTable or
natMappingExtAddress in natMappingTable</c>
<c>XSPORT</c>
<c>natMappingExtPort in natMappingTable</c>
<c>XDADDR</c>
<c>None</c>
<c>XDPORT</c>
<c>None</c>
<c></c>
<c></c>
<c>Port range description</c>
<c></c>
<c></c>
<c></c>
<c>PORTMN</c>
<c>None</c>
<c>PORTMX</c>
<c>None</c>
<c></c>
<c></c>
<c>Values related to thresholds</c>
<c></c>
<c></c>
<c></c>
<c>POOLID</c>
<c>natPoolIndex in natPoolTable</c>
<c>POOLHW</c>
<c>natPoolWatermarkHigh in natPoolTable</c>
<c>POOLLW</c>
<c>natPoolWatermarkLow in natPoolTable</c>
<c>GAMCNT</c>
<c>natAddressMappingCreations - natAddressMappingRemovals in
natCountersTable</c>
<c>GAPMCNT</c>
<c>natMappingCreations - natMappingRemovals in
natCountersTable</c>
<c>SAPMCNT</c>
<c>natSubscriberMappingCreations - natSubscriberMappingRemovals
in natSubscribersTable</c>
<c></c>
<c></c>
<c>Specific incoming packet description</c>
<c></c>
<c></c>
<c></c>
<c>PSRLM</c>
<c>natSubscriberRealm in natSubscribersTable in the case of a packet
originated by an identifiable subscriber</c>
<c>PATYP</c>
<c>None</c>
<c>PSADDR</c>
<c>None</c>
<c>PDADDR</c>
<c>None</c>
</texttable>
</section> <!-- parmToMIB -->
</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="resAllocCode" title="Encoding of Events Relating To Allocation Of Resources To Hosts">
<t>As indicated in <xref target="hdrFMT"/>, the event reports
specified in this section MUST have APP-NAME="NAT" in the message
header.</t>
<!-- =============== -->
<section anchor="ABindCode" title="NAT Address Mapping Creation and Deletion">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>NAT address mapping creation event is indicated by MSGID set to
"AMADD";</t>
<t>NAT address mapping deletion event is indicated by MSGID set to
"AMDEL".</t>
</list>
For both events, the associated SD-ELEMENT is tagged by SD-ID "namap".
The contents of the namap SD-ELEMENT are shown in <xref
target="tab_namap"/>. The requirements for these contents are derived
from the description in <xref target="addrBind"/>.</t>
<texttable anchor="tab_namap" title="Contents Of the SD-ELEMENT Section For Logging the Address Mapping Creation and Deletion Events">
<ttcol align="left">Description</ttcol>
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Source subscriber index</c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>Additional source subscriber classifier value as recognized at
the ingress to the internal realm</c>
<c>One of SIFIX, SVLAN, SVPN, or SV6ENC</c>
<c>CONDITIONAL</c>
<c>Internal realm</c>
<c>IRLM</c>
<c>CONDITIONAL</c>
<c>Internal address type</c>
<c>IATYP</c>
<c>MANDATORY</c>
<c>Internal source IP address</c>
<c>ISADDR</c>
<c>MANDATORY</c>
<c>External realm</c>
<c>XRLM</c>
<c>CONDITIONAL</c>
<c>External address type</c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>External source IP address</c>
<c>XSADDR</c>
<c>MANDATORY</c>
<c>Trigger for address mapping creation or deletion</c>
<c>TRIG</c>
<c>OPTIONAL</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than one instance, else
MAY appear.</t>
<t>One of SIFIX, SVLAN, SVPN, or SV6ENC REQUIRED if the
internal source IP address is not enough to identify the subscriber
unambiguously, else MUST NOT appear.</t>
<t>IRLM or XRLM REQUIRED if not the default internal
or external realm, respectively, else MAY appear.</t>
</list>
</t>
<t>For the AMADD event type (MSGID), TRIG can take on the values
"OPKT" or "ADMIN". For the AMDEL event type, TRIG can take on
the values "ADMIN" or "AUTO".</t>
<t>Example: DS-Lite AFTR. One NAT instance. Multiple internal IPv4
realms containing the subscribers, divided by higher-level IPv6
prefix (details unnecessary). One default global IPv4 external
realm. Intra-subscriber sessions use mappings into this realm.</t>
<t>Subscriber A in realm Internal05 sends an outgoing packet, causing
the creation of an address mapping from the DS-Lite well-known
address 192.0.0.2 to the global IPv4 address 198.51.100.127.
Subscriber A's encapsulating IPv6 tunnel address is
2001:db8:a5e6:39b0:bd6a:35ad:1d33:6df6.</t>
<t>The event report for the address mapping creation is as follows
(line folded into several for presentation):
<list style="empty">
<t><142>1 2013-05-07T22:14:15.03487Z record.example.net NAT 5063
<vspace blankLines="0"/>
AMADD [namap SSUBIX="489321"
<vspace blankLines="0"/>
SV6ENC="2001:db8:a5e6:3900:bd6a:35ad:1d33:6df6" IRLM="Internal05"
<vspace blankLines="0"/>
IATYP="IPv4" ISADDR="192.0.0.2" XATYP="IPv4" XSADDR="198.51.100.127"
<vspace blankLines="0"/>
TRIG="OPKT"]</t>
</list>
Character count is about 240.
</t>
</section> <!-- ABindCode -->
<!-- ===================== -->
<section anchor="MapCode" title="NAT Address and Port Mapping Creation and Deletion">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>NAT address and port mapping creation event is indicated by
MSGID set to "APMADD";</t>
<t>NAT mapping deletion event is indicated by MSGID set to
"APMDEL".</t>
</list>
For both events, the associated SD-ELEMENT is tagged by SD-ID "napmap".
The contents of the nmap SD-ELEMENT are shown in <xref
target="tab_napmap"/>. The requirements for these contents are derived
from the description in <xref target="MapCrDe"/>.</t>
<texttable anchor="tab_napmap" title="Contents Of the SD-ELEMENT Section For Logging the mapping Creation and Deletion Events">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Source subscriber index</c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>Additional source subscriber classifier value as recognized at
the ingress to the internal realm</c>
<c>One of SIFIX, SVLAN, SVPN, or SV6ENC</c>
<c>CONDITIONAL</c>
<c>Internal realm</c>
<c>IRLM</c>
<c>CONDITIONAL</c>
<c>Internal address type</c>
<c>IATYP</c>
<c>MANDATORY</c>
<c>Internal source IP address</c>
<c>ISADDR</c>
<c>MANDATORY</c>
<c>Internal source port or ICMP identifier</c>
<c>ISPORT</c>
<c>MANDATORY</c>
<c>External realm</c>
<c>XRLM</c>
<c>CONDITIONAL</c>
<c>External address type</c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>External source IP address</c>
<c>XSADDR</c>
<c>MANDATORY</c>
<c>External source port or ICMP identifier</c>
<c>XSPORT</c>
<c>MANDATORY</c>
<c>Protocol identifier</c>
<c>PROTO</c>
<c>MANDATORY</c>
<c>Trigger for address and port mapping creation or deletion</c>
<c>TRIG</c>
<c>OPTIONAL</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than one instance, else
MAY appear.</t>
<t>One of SIFIX, SVLAN, SVPN, or SV6ENC REQUIRED if the
internal source IP address is not enough to identify the subscriber
unambiguously, else MUST NOT appear.</t>
<t>IRLM or XRLM REQUIRED if not the default internal
or external realm, respectively, else MAY appear.</t>
</list>
</t>
<t>For the APMADD event type (MSGID), TRIG can take on the values
"OPKT", IPKT", or "ADMIN".
<list style="empty">
<t>Note: it is not clear how the internal source port is selected
if an address and port mapping is triggered by an incoming TCP
packet. The NAT could select one based on its knowledge of
subscriber port usage, but this knowledge may be incomplete. Some
type of negotiation may be necessary, or else TCP address and port
mappings can only be triggered by outbound packets as in the
example below.</t>
</list>
For the APMDEL event type, TRIG can take on
the values "ADMIN", "AMDEL", or "AUTO".</t>
<t>Example: The triggering outgoing packet in the previous case was
a TCP packet with internal source port 49178. As well as triggering
the creation of an address mapping, the packet triggers the creation
of an address and port mapping between that port and an external
source port 6803. The corresponding mapping creation report would
look like this:
<list style="empty">
<t><142>1 2013-05-07T22:14:15.03487Z record.example.net NAT 5063
<vspace blankLines="0"/>
APMADD [napmap SSUBIX="489321"
<vspace blankLines="0"/>
SV6ENC="2001:db8:a5e6:3900:bd6a:35ad:1d33:6df6" IRLM="Internal05"
<vspace blankLines="0"/>
IATYP="IPv4" ISADDR="192.0.0.2" ISPORT="49178"
<vspace blankLines="0"/>
XATYP="IPv4" XSADDR="198.51.100.127" XSPORT=6803"
<vspace blankLines="0"/>
PROTO="6" TRIG="OPKT"]</t>
</list>
Character count is about 280.
</t>
</section> <!-- MapCode -->
<!-- ====================== -->
<section anchor="SessCode" title="NAT Session Creation and Deletion">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>NAT session creation event is indicated by MSGID set to
"SADD";</t>
<t>NAT session deletion event is indicated by MSGID set to
"SDEL".</t>
</list>
For both events, the associated SD-ELEMENT is tagged by SD-ID "nsess".
The contents of the nsess SD-ELEMENT are shown in <xref
target="tab_nsess"/>. The requirements for these contents are derived
from the description in <xref target="sessCrDe"/>.</t>
<texttable anchor="tab_nsess" 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>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Source subscriber index</c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>Additional source subscriber classifier value as recognized at
the ingress to the internal realm</c>
<c>One of SIFIX, SVLAN, SVPN, or SV6ENC</c>
<c>CONDITIONAL</c>
<c>Internal realm</c>
<c>IRLM</c>
<c>CONDITIONAL</c>
<c>Internal address type</c>
<c>IATYP</c>
<c>MANDATORY</c>
<c>Internal source IP address</c>
<c>ISADDR</c>
<c>MANDATORY</c>
<c>Internal source port or ICMP identifier</c>
<c>ISPORT</c>
<c>MANDATORY</c>
<c>External realm</c>
<c>XRLM</c>
<c>CONDITIONAL</c>
<c>External address type</c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>External source IP address</c>
<c>XSADDR</c>
<c>MANDATORY</c>
<c>External source port or ICMP identifier</c>
<c>XSPORT</c>
<c>MANDATORY</c>
<c>Protocol identifier</c>
<c>PROTO</c>
<c>MANDATORY</c>
<c>Internal destination IP address</c>
<c>IDADDR</c>
<c>CONDITIONAL</c>
<c>Internal destination port or ICMP identifier</c>
<c>IDPORT</c>
<c>CONDITIONAL</c>
<c>Destination subscriber index</c>
<c>DSUBIX</c>
<c>CONDITIONAL</c>
<c>Additional destination subscriber classifier value as recognized
at the ingress to the external realm</c>
<c>One of DIFIX, DVLAN, DVPN, or DV6ENC</c>
<c>CONDITIONAL</c>
<c>External destination IP address</c>
<c>XDADDR</c>
<c>CONDITIONAL</c>
<c>External destination port or ICMP identifier</c>
<c>XDPORT</c>
<c>CONDITIONAL</c>
<c>Trigger for session creation or deletion</c>
<c>TRIG</c>
<c>OPTIONAL</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than one instance, else
MAY appear.</t>
<t>One of SIFIX, SVLAN, SVPN, or SV6ENC REQUIRED if the
internal source IP address is not enough to identify the subscriber
unambiguously, else MUST NOT appear.</t>
<t>IRLM or XRLM REQUIRED if not the default internal
or external realm, respectively, else MAY appear.</t>
<t>IDADDR and IDPORT REQUIRED if destination logging is enabled
and these need to be remapped to external destination address and
port. Otherwise, if destination logging is disabled, they MUST NOT
appear, and if destination logging is enabled, they SHOULD NOT
appear because of redundancy.</t>
<t>DSUBIX REQUIRED if destination logging is enabled and the
destination is a subscriber served by the NAT, else MUST NOT
appear.</t>
<t>One of DIFIX, DVLAN, DVPN, or DV6ENC REQUIRED if destination
logging is enabled and the destination is a subscriber served by
the NAT and the external destination address is not enough to
identify the external destination subscriber unambiguously, else
MUST NOT appear. </t>
<t>XDADDR and XDPORT REQUIRED if destination logging is enabled,
else MUST NOT appear. </t>
</list>
</t>
<t>For the SADD event type (MSGID), TRIG can take on the values
"OPKT", IPKT", or "ADMIN". For the SDEL event type, TRIG can take on
the values "ADMIN", "MDEL", or "AUTO".</t>
<t>Example: destination logging is enabled. The outgoing packet that
triggered the address and port mapping in the previous section was
sent to 192.0.2.57 port 80. The session creation event report appears
as follows:
<list style="empty">
<t><142>1 2013-05-07T22:14:15.03487Z record.example.net NAT 5063
<vspace blankLines="0"/>
SESSADD [nsess SSUBIX="489321"
<vspace blankLines="0"/>
SV6ENC="2001:db8:a5e6:3900:bd6a:35ad:1d33:6df6" IRLM="Internal05"
<vspace blankLines="0"/>
IATYP="IPv4" ISADDR="192.0.0.2" ISPORT="49178"
<vspace blankLines="0"/>
XATYP="IPv4" XSADDR="198.51.100.127" XSPORT=6803"
<vspace blankLines="0"/>
PROTO="6" XDADDR="192.0.2.57" XDPORT="80" TRIG="OPKT"]</t>
</list>
Character count is about 310.
</t>
</section> <!-- SessCode -->
<!-- ================= -->
<section anchor="PSetCode" title="Port Range Allocation and Deallocation">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Port range allocation event is indicated by MSGID set to
"PTADD";</t>
<t>Port range deallocation event is indicated by MSGID set to
"PTDEL".</t>
</list>
For both events, the associated SD-ELEMENT is tagged by SD-ID "nprng".
The contents of the npset SD-ELEMENT are shown in <xref
target="tab_nprng"/>. The requirements for these contents are derived
from the description in <xref target="portAssgn"/>.</t>
<texttable anchor="tab_nprng" title="Contents Of the SD-ELEMENT Section For Logging the Port Set Allocation and Deallocation Events">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Source subscriber index</c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>Additional source subscriber classifier value as recognized at
the ingress to the internal realm</c>
<c>One of SIFIX, SVLAN, SVPN, or SV6ENC</c>
<c>CONDITIONAL</c>
<c>Internal realm</c>
<c>IRLM</c>
<c>CONDITIONAL</c>
<c>Internal address type</c>
<c>IATYP</c>
<c>MANDATORY</c>
<c>Internal source IP address</c>
<c>ISADDR</c>
<c>MANDATORY</c>
<c>External realm</c>
<c>XRLM</c>
<c>CONDITIONAL</c>
<c>External address type</c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>External source IP address</c>
<c>XSADDR</c>
<c>MANDATORY</c>
<c>Port range lowest value</c>
<c>PORTMN</c>
<c>MANDATORY</c>
<c>Port range highest value</c>
<c>PORTMX</c>
<c>MANDATORY</c>
<c>Trigger for port range allocation or deallocation</c>
<c>TRIG</c>
<c>OPTIONAL</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than one instance, else
MAY appear.</t>
<t>One of SIFIX, SVLAN, SVPN, or SV6ENC REQUIRED if the
internal source IP address is not enough to identify the subscriber
unambiguously, else MUST NOT appear.</t>
<t>IRLM or XRLM REQUIRED if not the default internal
or external realm, respectively, else MAY appear.</t>
</list>
</t>
<t>For the PTADD event type (MSGID), TRIG can take on the values
"OPKT", "IPKT", "ADMIN", or "AUTO". For the PTDEL event type, TRIG can
take on the values "ADMIN" or "AUTO".</t>
<t>Consider an example where the range 1024-1535 is allocated to the
address mapping on which the example in <xref target="ABindCode"/>
is based. The corresponding port range allocation report would look
like this:
<list style="empty">
<t><142>1 2013-05-07T22:14:15.03487Z record.example.net NAT 5063
<vspace blankLines="0"/>
PTADD [nprng SSUBIX="489321"
<vspace blankLines="0"/>
SV6ENC="2001:db8:a5e6:3900:bd6a:35ad:1d33:6df6" IRLM="Internal05"
<vspace blankLines="0"/>
IATYP="IPv4" ISADDR="192.0.0.2" XATYP="IPv4" XSADDR="198.51.100.127"
<vspace blankLines="0"/>
PORTMN="1024" PORTMX="1535" TRIG="OPKT"]</t>
</list>
Character count is about 270.
</t>
</section> <!-- PSetCode -->
</section> <!-- resAllocCode -->
<!-- ============= -->
<section anchor="threshEvCode" title="Encoding of Threshold Events">
<t>As indicated in <xref target="hdrFMT"/>, the event reports
specified in this section MUST have APP-NAME="NATTHR" in the SYSLOG
message header.</t>
<section anchor="PoolTCode" title="NAT Address Pool High- and Low-Water-Mark Threshold Events">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>NAT address pool high-water-mark threshold event is indicated by
MSGID set to "POOLHT";</t>
<t>NAT address pool low-water-mark threshold event is indicated by
MSGID set to "POOLLT".</t>
</list>
For both events, the associated SD-ELEMENT is tagged by SD-ID "npool".
The contents of the npool SD-ELEMENT are shown in <xref
target="tab_npool"/>. The requirements for these contents are derived
from the description in <xref target="poolThresh"/>.</t>
<texttable anchor="tab_npool" title="Contents Of the SD-ELEMENT Section For Logging the Address Pool High- and Low-Water-Mark Threshold Events">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Pool identifier</c>
<c>POOLID</c>
<c>MANDATORY</c>
<c>The threshold value set by the administrator</c>
<c>POOLHW or POOLLW as applicable</c>
<c>CONDITIONAL</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than
one instance, else MAY appear.</t>
<t>POOLHW REQUIRED for high-water-mark event, else MUST NOT appear.</t>
<t>POOLLW REQUIRED for low-water-mark event, else MUST NOT appear.</t>
</list>
</t>
<t>Example, assuming a high-water-mark threshold of 80% aggregate
address-port utilization::
<list style="empty">
<t><132>1 2013-08-15T09:15:16.08716Z record.example.net NATTHR 5025
<vspace blankLines="0"/>
POOLHT [npool POOLID="13" POOLHW="80"]</t>
</list>
Character count is about 105.</t>
</section> <!-- PoolTCode -->
<!-- =========================== -->
<section anchor="GAMHTCode" title="Global Address Mapping High-Water-Mark Threshold Exceeded">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Global address mapping high-water-mark threshold event is
indicated by MSGID set to "GAMHT"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "ngamht".</t>
</list>
The contents of the ngamht SD-ELEMENT are shown in <xref
target="tab_ngamht"/>. The requirements for these contents are derived
from the description in <xref target="addrThresh"/>.</t>
<texttable anchor="tab_ngamht" title="Contents Of the SD-ELEMENT Section For Logging the Global Address Map High-Water-Mark Threshold Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Current number of active address mappings</c>
<c>GAMCNT</c>
<c>MANDATORY</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
<t>Example, assuming a threshold was set to 690000, already
exceeded. As a result, prior events of this type were detected and
logged, unless they were suppressed by the sort of controls discussed
in <xref target="mgmtConsid"/>.
<list style="empty">
<t><132>1 2013-08-15T09:15:16.08716Z record.example.net NATTHR 5025
<vspace blankLines="0"/>
GAMHT [ngamht GAMCNT="690015"]</t>
</list>
Character count is about 95.</t>
</section> <!-- GAMHTCode -->
<!-- ======================== -->
<section anchor="GMHTCode" title="Global Address and Port Mapping High-Water-Mark Threshold Event">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Global address and port mapping high-water-mark threshold event
is indicated by MSGID set to "GAPMHT"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "ngapmht".</t>
</list>
The contents of the ngmht SD-ELEMENT are shown in <xref
target="tab_ngapmht"/>. The requirements for these contents are derived
from the description in <xref target="transThresh"/>.</t>
<texttable anchor="tab_ngapmht" title="Contents Of the SD-ELEMENT Section For Logging the Global Address and Port Mapping High-Water-Mark Threshold Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Current global number of address and port mappings</c>
<c>GAPMCNT</c>
<c>MANDATORY</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
<t>Example: suppose the threshold was set to 2000000, so it has
already been exceeded. As in the previous section, prior events of
this type were detected and logged, unless they were suppressed by
the sort of controls discussed in <xref target="mgmtConsid"/>.
<list style="empty">
<t><132>1 2013-08-15T09:15:16.08716Z record.example.net NATTHR 5025
<vspace blankLines="0"/>
GAPMHT [ngapmht GAPMCNT="2000023"]</t>
</list>
Character count is about 100.</t>
</section> <!-- GMHTCode -->
<!-- ========================= -->
<section anchor="SMHTCode"
title="Subscriber-Specific Address and Port Mapping High-Water-Mark Threshold Event">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t> Subscriber-specific address and port mapping high-water-mark
threshold event is indicated by MSGID set to "SAPMHT"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "nsapmht".</t>
</list>
The contents of the nsapmht SD-ELEMENT are shown in <xref
target="tab_nsapmht"/>. The requirements for these contents are derived
from the description in <xref target="subsThresh"/>.</t>
<texttable anchor="tab_nsapmht" title="Contents Of the SD-ELEMENT Section For Logging the Subscriber-Specific Address and Port Mapping High-Water-Mark Threshold Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Index of the affected subscriber</c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>Current number of address and port mappings for this subscriber</c>
<c>SAPMCNT</c>
<c>MANDATORY</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
<t>Example: suppose the threshold was set to 1500 and the number of
mappings for this subscriber has been increasing. Then this is the
first threshold-exceeded event detected of what could possibly be a
series of such events until subscriber consumption of outgoing ports
drops below threshold again.
<list style="empty">
<t><133>1 2013-08-15T09:15:16.08853Z record.example.net NATTHR 5025
<vspace blankLines="0"/>
SAPMHT [nsapmht SSUBIX="489321" SAPMCNT="1501"]</t>
</list>
Character count is about 115.</t>
</section> <!-- SMHTCode -->
</section> <!-- threshEvCode -->
<!-- ============= -->
<section anchor="limitEvCode" title="Encoding of Limit Events">
<t>As indicated in <xref target="hdrFMT"/>, the event reports
specified in this section MUST have APP-NAME="NATLIM" in the SYSLOG
message header.</t>
<section anchor="GAMLIMCode" title="Global Address Mapping Limit Exceeded">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Global address mapping limit exceeded event is indicated by
MSGID set to "GAMLIM"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "ngaml".</t>
</list>
The contents of the ngaml SD-ELEMENT are shown in <xref
target="tab_ngaml"/>. The requirements for these contents are derived
from the description in <xref target="addrMapLim"/>.</t>
<texttable anchor="tab_ngaml" title="Contents Of the SD-ELEMENT Section For Logging the Global Address Map Limit Exceeded Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Index of the affected subscriber</c>
<c>SSUBIX</c>
<c>MANDATORY</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
<t>Example:
<list style="empty">
<t><131>1 2013-08-15T09:15:16.08716Z record.example.net NATLIM 5025
<vspace blankLines="0"/>
GAMLIM [ngaml NATINST="VRF-Cust-X" SSUBIX="278067"]</t>
</list>
Character count is about 115.</t>
</section> <!-- GAMLIMCode -->
<!-- =============== -->
<section anchor="GMLIMCode" title="Global Address and Port Mapping Limit Exceeded">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Global adress and port mapping limit exceeded event is indicated by
MSGID set to "GAPMLIM"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "ngapml".</t>
</list>
The contents of the ngapml SD-ELEMENT are shown in <xref
target="tab_ngapml"/>. The requirements for these contents are derived
from the description in <xref target="transMapLim"/>.</t>
<texttable anchor="tab_ngapml" title="Contents Of the SD-ELEMENT Section For Logging the Global Address and Port Mapping Limit Exceeded Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Index of the internal subscriber</c>
<c>SSUBIX</c>
<c>CONDITIONAL</c>
<c>Index of the external subscriber</c>
<c>DSUBIX</c>
<c>CONDITIONAL</c>
<c>Source realm of the triggering packet</c>
<c>PSRLM</c>
<c>MANDATORY</c>
<c>Incoming packet header IP address type</c>
<c>PATYP</c>
<c>CONDITIONAL</c>
<c>Incoming packet source IP address</c>
<c>PSADDR</c>
<c>CONDITIONAL</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than
one instance, else MAY appear.</t>
<t>SSUBIX REQUIRED if the mapping was triggered by a packet outgoing
from the internal to the external realm, else MUST NOT appear.</t>
<t>DSUBIX is REQUIRED if the mapping was triggered by a packet
incoming from a subscriber served by the NAT and located in the
external realm (i.e., using an address mapping created previously by
the internal subscriber), else MUST NOT appear.</t>
<t>PATYP and PSADDR from the initiating packet are REQUIRED if the
mapping was triggered by a packet incoming from a purely external
realm (i.e., using an address mapping created previously by the
internal subscriber), else MAY appear.</t>
</list>
</t>
<t>Example: limit event triggered by a packet coming from 192.0.2.57
in realm "externv4".
<list style="empty">
<t><131>1 2013-08-15T09:15:16.08716Z record.example.net NATLIM 5025
<vspace blankLines="0"/>
GAPMLIM [ngapml NATINST="VRF-Cust-X" PSRLM="externv4"
<vspace blankLines="0"/>
PATYP="IPv4" PSADDR="192.0.2.57"]</t>
</list>
Character count is about 150.
</t>
</section> <!-- GMLIMCode -->
<!-- =================== -->
<section anchor="GSLIMCode" title="Global Limit On Number of Active Hosts Exceeded">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Global active hosts limit exceeded event is indicated by
MSGID set to "GSLIM"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "ngsl".</t>
</list>
The contents of the ngsl SD-ELEMENT are shown in <xref
target="tab_ngsl"/>. The requirements for these contents are derived
from the description in <xref target="actSubsLim"/>.</t>
<texttable anchor="tab_ngsl" title="Contents Of the SD-ELEMENT Section For Logging the Global Active Host Limit Exceeded Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Index of the affected subscriber</c>
<c>SSUBIX</c>
<c>MANDATORY</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
<t>An example would look exactly like that in <xref
target="GAMLIMCode"/> with the substitution of GSLIM for GAMLIM and
ngsl for ngaml.</t>
</section> <!-- GSLIMCode -->
<!-- ======================= -->
<section anchor="SBLIMCode" title="Subscriber-Specific Limit On Number of Address and Port Mappings Exceeded">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Subscriber-specific mapping limit exceeded event is indicated by
MSGID set to "SMLIM"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "nsml".</t>
</list>
The contents of the nsml SD-ELEMENT are shown in <xref
target="tab_nsml"/>. The requirements for these contents are derived
from the description in <xref target="subsMapLim"/>.</t>
<texttable anchor="tab_nsml" title="Contents Of the SD-ELEMENT Section For Logging the Subscriber-Specific Mapping Limit Exceeded Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Index of the affected subscriber</c>
<c>SSUBIX</c>
<c>MANDATORY</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NATINST REQUIRED if device supports more than
one instance, else MAY appear.</t>
</list>
</t>
<t>An example would look exactly like that in <xref
target="GAMLIMCode"/> with the substitution of SAPMLIM for GAMLIM and
nsapml for ngaml.</t>
</section> <!-- SBLIMCode -->
<!-- ====================== -->
<section anchor="FRAGCode" title="Pending Fragment Limit Exceeded">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Pending fragment limit exceeded event is indicated by
MSGID set to "FRAG"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "nfpkt".</t>
</list>
The contents of the nfpkt SD-ELEMENT are shown in <xref
target="tab_nfpkt"/>. The requirements for these contents are derived
from the description in <xref target="fragLim"/>.</t>
<texttable anchor="tab_nfpkt" title="Contents Of the SD-ELEMENT Section For Logging the Pending Fragment Limit Exceeded Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NAT instance identifier</c>
<c>NATINST</c>
<c>CONDITIONAL</c>
<c>Source realm of the packet</c>
<c>PSRLM</c>
<c>MANDATORY</c>
<c>Packet header IP address type</c>
<c>PATYP</c>
<c>MANDATORY</c>
<c>Packet source IP address</c>
<c>PSADDR</c>
<c>MANDATORY</c>
<c>Packet destination IP address</c>
<c>PDADDR</c>
<c>MANDATORY</c>
<c>Source subscriber index</c>
<c>SSUBIX</c>
<c>CONDITIONAL</c>
</texttable>
<t>Conditions:
<list style="symbols">
<t>NAT instance identifier REQUIRED if device supports more than
one instance, else MAY appear.</t>
<t>Source subscriber index REQUIRED if the source of the packet is a
subscriber served by the NAT and can be determined, else MUST NOT
appear.</t>
</list>
</t>
<t>Example: assuming the packet passing the limit came from an
internal host and was dropped as a result of the limit.
<list style="empty">
<t><132>1 2013-08-15T09:15:16.08Z record.example.net NATLIM 5025
<vspace blankLines="0"/>
FRAG [nfpkt PSRLM="DsLite-089" PATYP="IPv4" PSADDR="192.0.0.2"
<vspace blankLines="0"/>
PDADDR="203.0.113.26" SSUBIX="32791"]</t>
</list>
Character count is about 160.</t>
</section> <!-- FRAGCode -->
</section> <!-- limitEvCode -->
</section> <!-- evCode -->
</section> <!-- recFMT -->
<section anchor="mgmtConsid" title="Management Considerations">
<t>This section considers requirements for management of the log system to
support logging of the events described above. It first covers
requirements applicable to log management in general. Any additional
standardization required to fulfil these requirements is out of scope of
the present document. Subsequent sub-sections discuss management issues
related to specific event report types. The identifiers PRI, APP-NAME, and
MSGID used below refer to fields in the SYSLOG header <xref
target="RFC5424"/></t>
<section anchor="genMgmt" title="General Requirements For Control Of Logging">
<t>This document assumes that any implementation provides the following
capabilities, discussed in more detail below:
<list style="symbols">
<t>ability to configure the PRI value of each event report type at the
granularity of (APP-NAME, MSGID) combination;</t>
<t>ability at each collector to determine that event reports that it
should have received have been lost. The required granularity is at
least at the level of PRI and may be finer for some event
types.</t>
<t>ability to configure criteria to automatically suppress the
generation of event reports while the criteria are met, at the
granularity of (APP-NAME, MSGID) combination.</t>
</list>
</t>
<section anchor="configPRI" title="Configuration of PRI Value">
<t>The PRI value is composed of two numbers, the Facility value and
the Severity. It may be used at the origin for selecting logs to
streams being dispatched to different collectors, and in applications
beyond the collectors to prioritize display of logs to operators. The
event reports in this document have been structured such that the
Severity level varies between event types as represented by (APP-NAME,
MSGID) combination. As an extreme example, the address pool
high-water-mark threshold event (APP-NAME="NATTHR", MSGID="POOLHT") is
obviously more urgent than the low-water-mark threshold event
(APP-NAME="NATTHR", MSGID="POOLLT").</t>
<t>To some extent, this document tries to simplify message routing by
making a general distinction between event types recording the
allocation of resources to hosts (with APP-NAME="NAT") and events of
interest to operations and maintenance (with APP-NAME="NATTHR" and
APP-NAME="NATLIM"). The need to provide different Severity levels for
different event types remains.</t>
</section> <!-- configPRI -->
<section anchor="lostDetect" title="Ability For Each Collector To Detect Lost Event Reports">
<t>Operators have a need to know when a given collector has not
received all of the event reports it should have. It probably does not
matter if less-important events are tracked at the granularity of
event type (APP-NAME, MSGID combination), by APP-NAME, or just by PRI
value. </t>
<t>The event types defined in this document relating to allocation of
resources to hosts are a special case. Regulatory requirements or the
possibility that such reports might be introduced into court in cases
such as abuse impose a requirement that the record of allocations to a
particular host be complete. This requirement is important enough to
be stated in the Security Considerations section (<xref
target="Security"/>), where the implementation of signed SYSLOG
messages <xref target="RFC5848"/>, which also provides message
sequencing, is mandated as part of this specification.</t>
<t>In deploying <xref target="RFC5848"/>, the operator needs to decide
the level of granularity of tracking, whether it should be over the
whole set of reports covered by APP-NAME="NAT" or at a finer level. This
judgement has to be tempered by local circumstances. One point to note
is that since both creations/allocations and deletions/deallocations
are recorded, a certain amount of redundancy is available in the
reports being generated. However, without both the creation and
deletion timestamps, there is no definitive evidence of the specific
period of time during which the resources concerned were allocated to
a specific host.</t>
</section> <!-- lostDetect -->
<section anchor="suppress" title="Ability To Rate Limit Or Disable Event Reports">
<t>The event report types specified with APP-NAME="NATTHR" and APP-
NAME="NATLIM" all relate to thresholds or limits. By their nature,
events of this sort will come in bursts. The threshold or limit will
be hit, the resource concerned will remain busy for a period, then
pressure on the resource will ease. Depending on the resource,
possibly hundreds of instances of the event concerned will be detected
during a single busy period.</t>
<t>Where repeated events involve the same resource, it makes little
sense to report all of them, since the NAT MIB counters provide the
necessary information more succinctly. On the other hand, it can be
useful to know that the fragmentation limit, for instance, is being
hit by successive packets from the same source address.</t>
<t>As a result of these considerations, this document requires that
implementations MUST provide means to configure limits on the rate at
which event reports of a given type (APP-NAME, MSGID combination) are
generated. It is RECOMMENDED that it be possible to specify two
values per (APP-NAME, MSGID) combination:
<list style="symbols">
<t>minimum time between initial instances of a given event report
type;</t>
<t>maximum number of instances of the event report to generate per
busy period.</t>
</list>
</t>
<t>Regardless of the detailed method the implementation provides for
specifying the rate limiting of individual event report types, all
implementations MUST allow the operator to indicate through
configuration that a given event report type is to be completely
disabled. This is particularly required to disable logging of either
session or mapping creations and deletions when not required (see
discussion in <xref target="MapCrDe"/>). It is also required when the
operator prefers to receive threshold event notifications via SNMP
rather than SYSLOG. </t>
<t>The ability to rate limit or disable event reports MUST NOT
interfere with the requirement to detect lost messages. This has
implications for any sequence numbering used for that purpose. It is
RECOMMENDED in any event that the implementation provide MIB counters
of numbers of messages not generated due to rate limiting by event
type supported. If this is done, counters for disabled event report
types SHOULD NOT be incremented, since that could require keeping
unnecessary additional state.</t>
</section> <!-- suppress -->
</section> <!-- genMgmt -->
<section anchor="thrSet" title="Setting Limits and Thresholds">
<t>The "NATTHR" and "NATLIM" events specified in this document depend on
the thresholds and limits configured in the NAT MIB
<xref target="I-D.behave-NAT-MIB"/>. The limits have to do with policy
in some cases (e.g., most especially the subscriber-specific limits), but
generally depend on the implementation and the device in which it is
deployed. </t>
<t>The purpose of high-water-mark thresholds is, of course, to give
sufficient advance warning that utilization of a particular resource is
approaching its limit, so that appropriate provisioning or
reconfiguration action can be undertaken to preserve target service
levels on the NAT device. Thus the following general principles apply:
<list style="symbols">
<t>A high-water-mark threshold should be derived as a percentage of
the relevant limit.</t>
<t>The more quickly that utilization of a given resource can
build up, the lower the threshold must be to provide an adequate
response time.</t>
<t>Some limits are more important than others in terms of their effect
on overall service levels provided by the NAT device. To focus
attention on the more important limits, their corresponding thresholds
should be set lower than those for less-important limits, all other
things being equal.</t>
</list>
In practice, thresholds will require tuning to fit the particular
characteristics of the NAT device and its users.
</t>
<t>The setting of the high-water-mark-thresholds for address pools
(<xref target="poolThresh"/>) poses additional challenges. The problem
is that the bottleneck for port availability will generally be a single
protocol, which may vary from one time to another. However, the
threshold is based on overall port utilization. If port usage is such
that one protocol generally predominates, the required threshold value
has to be lower than if usage is more balanced between protocols.
Clearly the appropriate threshold value depends on the characteristics
of the traffic handled by the particular address pool concerned. </t>
<t>Pooling behaviour adds another factor for consideration. With a
pooling behaviour of "arbitrary" <xref target="RFC4787"/>, port
utilization for the bottleneck protocol can be quite high before service
levels offered by the pool are in danger. On the other hand, with a
pooling behaviour of "paired", possible utilization levels will be much
lower because typically a number of port values will be reserved to each
address mapping and only some of those will be in use on the average.
The difference between "arbitrary" and "paired" utilization for a given
level of service may be quite dramatic.</t>
</section> <!-- thrSet -->
<section anchor="othMgmt" title="Other Management Requirements">
<t>The identification of internal realms is contingent on the the
existence and applicability of default internal and external realms. If
the implementation is capable of supporting more than one internal or
external realm, it MUST provide the means for the operator to specify
which realm is the default internal and/or external realm, as the case
may be.</t>
</section> <!-- othMgmt -->
</section> <!-- mgmtConsid -->
<section anchor="Security" title="Security Considerations">
<t>When logs are being recorded for regulatory reasons or as potential
evidence in abuse cases, preservation of their integrity and
authentication of their origin is essential. To achieve this result,
signed SYSLOG messages <xref target="RFC5848"/> MUST be implemented as
part of this specification. It is RECOMMENDED that the operator deploy
<xref target="RFC5848"/> where local requirements on integrity and
authentication of origin are stringent. In conjunction with <xref
target="RFC5848"/> and as recommended in Section 3 of that document, TLS
transport as specified in <xref target="RFC5425"/> SHOULD be used between
the origin and the collector(s) and MUST be implemented. Section 5.2.1 of
<xref target="RFC5848"/> specifies the minimum support for Key Blob Type
that must be provided by implementations of that specification. </t>
<t>Access to the logs defined in <xref target="resAlloc"/> and <xref
target="resAllocCode"/> 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 user or user location. It
is therefore RECOMMENDED that these logs be transported securely, using
<xref target="RFC5425"/>, for example, even if <xref target="RFC5848"/> is
not deployed, that they be stored securely at the collector, and that
access to them at the collector and in applications be tightly
controlled.</t>
<t>The logs defined in <xref target="threshEv"/> and <xref
target="limitEv"/> are less sensitive in general, but since many of them
contain the subscriber identifier, they could be used to get some sense of
subscriber activity. The fragmentation limit event provides actual
packet header contents. Operators SHOULD at the least deploy secure
transport to ensure that this information is not misused.</t>
</section> <!-- Security -->
<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>
<t>Some PARAM-NAMES appear under more than one SD-ID in <xref
target="tab_iana"/>. Formally, 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 if the parameters have the same meaning in both
event reports.</t>
<t>While a number of parameters are marked CONDITIONAL in the body of
this document, the SYSLOG registry provides only for MANDATORY and
OPTIONAL parameters. All CONDITIONAL parameters have been placed in the
OPTIONAL category in <xref target="tab_iana"/>.</t>
<texttable anchor="tab_iana" title="NAT-Related STRUCTURED-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>namap</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>SIFIX</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SVLAN</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SVPN</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SV6ENC</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IRLM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>ISADDR</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XRLM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XSADDR</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>TRIG</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>napmap</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>SIFIX</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SVLAN</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SVPN</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SV6ENC</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IRLM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>ISADDR</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>ISPORT</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XRLM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XSADDR</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XSPORT</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PROTO</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>TRIG</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>nsess</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>SIFIX</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SVLAN</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SVPN</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SV6ENC</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IRLM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>ISADDR</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>ISPORT</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XRLM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XSADDR</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XSPORT</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PROTO</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>IDADDR</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IDPORT</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DSUBIX</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DIFIX</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DVLAN</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DVPN</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DV6ENC</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>XDADDR</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>XDPORT</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>TRIG</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>nprng</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>SIFIX</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SVLAN</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SVPN</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SV6ENC</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IRLM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>ISADDR</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XRLM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XSADDR</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PORTMN</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PORTMX</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>TRIG</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>npool</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>POOLID</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>POOLLT</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>POOLHT</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>ngamht</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>GAMCNT</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>ngapmht</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>GAPMCNT</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>nsapmht</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>SAPMCNT</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>ngaml</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>ngapml</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SSUBIX</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>DSUBIX</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PSRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PATYP</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PSADDR</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>ngsl</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>nsapml</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>SSUBIX</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>nfpkt</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NATINST</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PSRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PSADDR</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PDADDR</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>SSUBIX</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
</texttable>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2663;
&RFC2685;
&RFC2863;
&RFC4265;
&RFC4363;
&RFC4784;
&RFC4787;
&RFC5424;
&RFC5425;
&RFC5848;
&RFC5952;
&RFC6145;
&RFC6146;
&RFC6333;
<reference anchor="US-ASCII">
<front>
<title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title>
<author initials="" surname="American National Standards Institute">
<organization></organization>
</author>
<date month="" year="1986"/>
</front>
<seriesInfo name='ANSI' value='X3.4' />
</reference>
<reference anchor="I-D.behave-NAT-MIB">
<front>
<title>Additional Managed Objects for Network Address Translators (NAT) (Work in progress)</title>
<author initials="S." surname="Perreault">
<organization>Viagenie</organization>
</author>
<author initials="T." surname="Tsou">
<organization>Huawei</organization>
</author>
<author initials="S." surname="Sivakumar">
<organization>Cisco Systems</organization>
</author>
<date month="September" year="2013"/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC3022;
&RFC4026;
&RFC7011;
&RFC5382;
&RFC5969;
&RFC6264;
&RFC6674;
&RFC6887;
&RFC6888;
&RFC7040;
<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="August" 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>
<author fullname="Tom Taylor" initials="T." surname="Taylor">
<organization>Huawei Technologies</organization>
</author>
<date month="August" 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="July" 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="July" 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="July" year="2013"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:57 |