One document matched: draft-ietf-behave-syslog-nat-logging-05.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 RFC3022 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml">
<!ENTITY RFC4787 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC5101 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5101.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">
]>
<?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-05" 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 (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone>+1 408 330 4424</phone>
<email>tina.tsou.zouting@huawei.com</email>
</address>
</author>
<author initials="T." surname="Taylor" fullname="T. Taylor" 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="2013" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current year is
specified, xml2rfc will fill in the current day and month for you. If the
year is not the current one, it is necessary to specify at least a month
(xml2rfc assumes day="1" if not specified for the purpose of calculating
the expiry date). With drafts it is normally sufficient to specify just
the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>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>With the wide deployment of Carrier Grade NAT (CGN) devices, the
logging of NAT-related events has become very important for various
operational purposes. The logs may be required for troubleshooting, to
identify a host that was used to launch malicious attacks, and/or for
accounting purposes. This document identifies the events that need to be
logged and the parameters that are required in the logs depending on the
context in which the NAT is being used. It goes on to standardize formats
for reporting these events and parameters using SYSLOG (RFC 5424). A
companion document specifies formats for reporting the same events and
parameters using IPFIX (RFC 5101). Applicability statements are provided
in this document and its companion to guide operators and implementors in
their choice of which technology to use for logging.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> Operators already need to record the addresses assigned to
subscribers at any point in time, for operational and regulatory
reasons. When operators introduce NAT devices which support address
sharing (e.g., Carrier Grade NATs (CGNs)) into their network,
additional information has to be logged. This document and
<xref target="I-D.behave-ipfix-nat-logging"/> are provided in order to
standardize the events and parameters to be recorded, using
SYSLOG <xref target="RFC5424"/> and IPFIX <xref target="RFC5101"/>
respectively. The content proposed to be logged by the two documents
is exactly the same, but as will be seen, the choice of which to use
in a given scenario is an engineering issue. </t>
<t>Detailed logging requirements will vary depending on the context in
which they are used. For example, different methods for transition
from IPv4 to IPv6 require different events and different parameters to
be logged. <xref target="deploy"/> covers this topic.</t>
<t><xref target="events"/> provides a more
detailed description of the events that need logging and the parameters
that may be required in the logs.</t>
<t>The use of SYSLOG <xref target="RFC5424"/> has advantages and
disadvantages compared with the use of IPFIX <xref target="RFC5101"/>.
<xref target="applic"/> provides a statement of applicability for the
SYSLOG approach.</t>
<t><xref target="recFMT"/> specifies SYSLOG record formats for logging
of the events and parameters described in <xref target="events"/>. The
definitions provide the flexibility to vary actual log contents based
on the requirements of the particular deployment.</t>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">
"Key words for use in RFCs to Indicate Requirement Levels"</xref>.</t>
<t>This document uses the terms "session" and Binding
Information Base (BIB) as they are defined in Section 2 of <xref
target="RFC6146"/>. Note that this definition of "session" is
destination-specific, where the original definition of a NAT session in
<xref target="RFC2663"/> is destination-independent.</t>
<t>This document uses the term "address mapping" to denote the initial
logical step required to set up a session, as described in <xref
target="realms"/>. It uses the term "transport binding" to denote the
content of a BIB entry.</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>
</section>
</section> <!-- Introduction -->
<section anchor="deploy" title="Deployment Considerations">
<section anchor="statDyn" title="Static and Dynamic NATs">
<t>A NAT controls a set of resources in the form of one or more pools of
external addresses. If the NAT also does port translation (i.e., it is a
NAPT), it also controls the sets of UDP and TCP port numbers and ICMP
identifiers associated with each external address. </t>
<t>Logging requirements for a NAT depend heavily on its resource
allocation strategy. NATs can be classed as static or dynamic depending
on whether the resources provided to individual users are pre-configured
or allocated in real time as the NAT recognizes new flows. </t>
<t>Static assignments can be logged at configuration time by the NAT or
by network infrastructure. The logging volume associated with static
assignments will be relatively low, of the order of the volume of user
logons. As discussed below, static assignments are typically associated
with IPv6 transition methods rather than traditional NAT. The details of
what to log will depend on the transition method concerned. </t>
<t>Dynamic assignments typically require both more detail in the logs
and a higher volume of logs in total. A traditional Network Address Port
Translator (NAPT) as described in <xref target="RFC3022"/> and following
the recommendations of <xref target="RFC4787"/> and <xref
target="RFC5382"/> will generate a new mapping each time it encounters a
new internal <address, port> combination.</t>
<t>For statistical reasons, static assignments support lower address
sharing ratios than fully dynamic assignments as exemplified by the
traditional NAPT. The sharing ratio can be increased while restraining
log volumes by assigning ports to users in multi-port increments as
required rather than assigning just one port at a time. A subscriber may
start with no initial allocation, or may start with an initial permanent
allocation to which temporary increments are added when the initial set
is all being used. See <xref target="RFC6264"/> and
<xref target="I-D.tsou-behave-natx4-log-reduction"/> for details. If
this strategy is followed, logging will be required only when an
increment is allocated or reclaimed rather than every time an internal
<address, port> combination is mapped to an external <address,
port>. </t>
</section> <!-- statDyn -->
<section anchor="realms" title="Realms and Address Pools">
<t>A realm defines the scope within which a specific set of addresses
are unique. In general these will be IPv4 or IPv6 addresses, but not
necessarily. A counter-example specifically addressed by this document
is the case of Gateway-Initiated DS-Lite <xref target="RFC6674"/>,
where individual host sites are identified by context identifiers of
various types. See further discussion in <xref target="transition"/> and
<xref target="genAddr"/>.</t>
<t>From the point of view of a specific NAT session, only two realms
are involved: an internal realm and an external realm. However, the
NAT as a whole may support a number of realms, for example:
<list style="symbols">
<t>multiple internal realms with overlapping address spaces;</t>
<t>an external IPv4 public realm; and/or</t>
<t>an external IPv6 public realm.</t>
</list>
</t>
<t>As described in [RFC6146], for example, setting up a NAT session
proceeds in a series of logical steps. The first step in particular may
not be implemented explicitly in a given implementation, but logically
it has to happen before the next step can be taken.
<list style="numbers">
<t>An address mapping is created between the internal realm and
an external realm chosen based on information in the triggering packet
or administrative request.</t>
<t>Using that address mapping, a transport binding is created between
specific transport endpoints (e.g., between specific port values) in
the two realms for the protocol required by the session, and added to
the Binding Information Base (BIB).</t>
<t>Setup of the session is completed by mapping the destination
address and port (if necessary) into the selected external realm.</t>
</list>
</t>
<t>This section is concerned only with the address mapping step. That
step is always triggered either by a packet outgoing from the internal
host to a given destination, or by administrative action providing
equivalent information. The external realm for the mapping is chosen
based on the destination.</t>
<t>To summarize where we are: an address mapping binds an internal
address with an external address in a selected external realm.
One address mapping can serve as the basis for one to many transport
bindings in the BIB, and one BIB entry can serve as the basis for one to
many sessions. A single internal address may be associated with multiple
address mappings at one time.</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 [I-D.behave-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 transport bindings in the
BIB depends on the pooling behaviour. With a pooling behaviour of
"arbitrary" [RFC4787], 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" [RFC4787],
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="I-D.softwire-public-4over6"/>, MAP-E
<xref target="I-D.softwire-map"/>, and Lightweight 4over6
<xref target="I-D.softwire-lw4over6"/> have seen experimental
deployment and are in the process of being standardized at the time of
writing of this document. </t>
<t>Of the technologies just listed, 6rd and Public IPv4 over IPv6 do
not involve NATs and hence need not be considered further. The other
techniques involve NAT at the customer edge, at the border router, or
both, and hence are in scope.</t>
<t>A DS-Lite Address Family Transition Router (AFTR) includes a
large-scale session-stateful NAT44 processing potentially
millions of sessions per second. The special character of AFTR
operation over that of a traditional NAT44 is that the source IPv4
addresses of the internal hosts may not be unique. As a consequence,
the session tables need to include an alternative identifier associated
with the subscriber host. For basic DS-Lite, this will be the IPv6
address used to encapsulate the packets outgoing from the host. See
Section 6.6 of <xref target="RFC6333"/>. For gateway-initiated DS-Lite
<xref target="RFC6674"/>, an identifier associated with the incoming
tunnel from the host is used instead.</t>
<t>The DS-Lite customer edge equipment (the 'B4') may also perform
NAT44 functions, similar to the functions performed
by traditional NAT44 devices.</t>
<t>As a NAT44, the DS-Lite AFTR may be fully dynamic, or may allocate
ports in increments as described in the previous section. </t>
<t>Lightweight 4over6 <xref target="I-D.softwire-lw4over6"/> and MAP-E
<xref target="I-D.softwire-map"/> both require NAT44 operation at the
customer equipment (unified CPE,
<xref target="I-D.softwire-unified-cpe"/>). In both cases the resource
allocation strategy is static. Thus any logging of resource allocation
for these two transition techniques can be done by the network at
configuration time.</t>
<section anchor="genAddr" title="IP Addresses and Generalized Internal Addresses">
<t>In the event reports described below, external addresses and
destination addresses will always be true IPv4 or IPv6 addresses. Source
addresses of outgoing packets before mapping will also be IP addresses,
but will not always be meaningful because they will not be unique within
their realm. This is true in particular of some of the transition methods
described in the previous section.</t>
<t>For this reason, the event report descriptions introduce the term
"generalized internal address" to describe internal addresses (as
opposed to source addresses within packets). The detailed description
of the encoding of a generalized address in <xref target="params"/>
provides for an address type and address/prefix value, similarly to
the encoding of an IP address. However, the range of generalized
address types is expanded to support the following:
<list style="symbols">
<t>For traditional NATs, the source IPv4 address (for NAT44) or IPv6
address (for NAT64) is sufficient.</t>
<t>For the DS-Lite, Lightweight 4over6 or MAP-E transition methods,
the subscriber site can be identified by the IPv6 tunnel endpoint
prefix or address provisioned to that site.</t>
<t>Gateway-initiated DS-Lite uses the combination of a (typically)
32-bit context identifier (CID) and a softwire identifier
(SWID). Several different realizations of these identifiers are
described in Section 6 of <xref target="RFC6674"/>. From the point
of view of this document, the SWID is represented by a realm
identifier, leaving the CID as the value of the generalized internal
address itself.</t>
</list>
</t>
</section> <!-- genAddr -->
</section> <!-- transition -->
<section anchor="PCP" title="The Port Control Protocol (PCP)">
<t>The Port Control Protocol (PCP) <xref target="RFC6887"/> and
its port set extension <xref target="I-D.pcp-port-set"/> can be viewed
as a way to provision ports by other means. However, PCP can be invoked on a
per-flow basis, so the volume of logs generated by a PCP server can be
closer to the volume associated with a fully dynamic NAT. The volume
really depends on how PCP is being used in a specific network.</t>
</section> <!-- PCP -->
<section anchor="edgeLogs" title="Logging At the Customer Edge">
<t>Logging at the customer edge (or at the ISP edge for NATs
protecting the ISP's internal networks) may be done by the customer
for purposes of internal management, or by the ISP for its own
administrative and regulatory purposes. Given the likelihood of a high
internal community of interest, it is possible but unlikely that a NAT
at the edge of a large enterprise network processes a number of new
packet flows per second which is comparable to the volume handled by a
carrier grade NAT. Most customer edge NATs will handle a much smaller
volume of flows.</t>
</section> <!-- edgeLogs -->
</section> <!-- deploy -->
<section anchor="events" title="NAT-Related Events and Parameters">
<t>The events which follow were initially gleaned, in the words of the
authors of <xref target="I-D.behave-ipfix-nat-logging"/>, from <xref
target="RFC4787"/> and <xref target="RFC5382"/>. Some details were
subsequently informed by the discussion in <xref
target="deploy"/> and by provisions within the NAT MIB
<xref target="I-D.behave-NAT-MIB"/>. Section 4 of <xref target="RFC6888"/>
also provides a brief statement of logging requirements for carrier grade
NATs.</t>
<t>Since the present document deals with SYSLOG rather
than IPFIX, the timestamp and the event type will appear in the log
header rather than as an explicit part of the structured data portion
of the log. Hence they are omitted from the parameter tabulations that
follow. </t>
<section anchor="resAlloc" title="Events Relating To Allocation Of Resources To Hosts">
<section anchor="sessCrDe" title="NAT Session Creation and Deletion">
<t>A NAT session creation or deletion event is logged when a transport
binding 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 transport binding.</t>
<t>Implementations MUST NOT report session creation and deletion
events unless destination logging is enabled (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
transport binding. The destination IP address and port and possibly the
trigger are unique to the session. If the destination IP and port do not
require remapping into the external realm, the internal values are
redundant and SHOULD be omitted from the report. So long as the
underlying BIB entry exists, the internal values can in any event be
retrieved from the natMappingTable in the NAT MIB
<xref target="I-D.behave-NAT-MIB"/> using the combination of protocol,
external realm, external destination address, and external destination
port as key.
<list style="symbols">
<t>Internal realm (MANDATORY);</t>
<t>Generalized internal address (MANDATORY);</t>
<t>Internal port or ICMP identifier (MANDATORY);</t>
<t>External realm (MANDATORY);</t>
<t>External IP address (MANDATORY);</t>
<t>External port or ICMP identifier (MANDATORY);</t>
<t>Protocol identifier (MANDATORY);</t>
<t>Internal destination IP address (as given in outgoing packets)
(OPTIONAL);</t>
<t>Internal destination port or ICMP identifier (as given in
outgoing packets) (OPTIONAL);</t>
<t>External destination IP address (as given in outgoing packets)
(MANDATORY). It is unnecessary to specify the address type in the
detailed encoding of this value, since the type will be the same as
that of the external address parameter.</t>
<t>External destination port or ICMP identifier (as given in
outgoing packets) (MANDATORY);</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 BIB entry.</t>
</list>
</t>
</list>
</t>
<section anchor="destLog" title="Destination Logging">
<t>The logging of destination address and port is generally
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 session creation and deletion events for
sessions matching the specified criteria, but MUST NOT report these
events for other sessions.</t>
</section> <!-- destLog -->
</section> <!-- sessCrDe -->
<section anchor="BIBCrDe" title="Binding Information Base Entry Creation and Deletion">
<t>A transport binding as recorded in the Binding Information Base (BIB)
corresponds to the older definition of NAT session as defined in Section
2.3 of <xref target="RFC2663"/>. The BIB entry creation or deletion
event reports the addition or deletion of a mapping between an internal
transport endpoint and an external transport address. The event report
provides the same information as the session creation/deletion event,
except for the destination-related fields in the latter. </t>
<t>Particularly with endpoint-independent mapping behaviour <xref
target="RFC4787"/>, one BIB entry creation event is associated with
potentially many succeeding session creation events, as individual
destinations are mapped into the session table. Similarly, a BIB entry
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 BIB entry deletion.</t>
<t>Operators SHOULD disable the reporting of BIB entry creation and
deletion events when destination logging is enabled, because of the
redundancy between the BIB and session event reports. However, in the
case of endpoint-independent mapping behaviour <xref target="RFC4787"/>,
the BIB event provides a compact summary of most of the content of what
could be a large number of corresponding session events.</t>
<t>The following specific events are defined:
<list style="symbols">
<t>BIB entry creation</t>
<t>BIB entry deletion</t>
</list>
</t>
<t>These take the same parameters for all types of NAT. The internal
realm, generalized internal address, external realm, and external
address capture the underlying address mapping. The port values,
protocol, and possibly the trigger are unique to the BIB entry.
<list style="symbols">
<t>Internal realm (MANDATORY);</t>
<t>Generalized internal address (MANDATORY);</t>
<t>Internal port or ICMP identifier (MANDATORY);</t>
<t>External realm (MANDATORY);</t>
<t>External address (MANDATORY);</t>
<t>External port or ICMP identifier (MANDATORY);</t>
<t>Protocol identifier (MANDATORY);</t>
<t>Trigger for transport binding 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.</t>
</list>
</t>
</list>
</t>
</section> <!-- BIBCrDe -->
<section anchor="addrBind" title="Address Mapping Creation and Deletion Events">
<t>Two specific events are provided:
<list style="symbols">
<t>Address mapping creation;</t>
<t>Address mapping deletion.</t>
</list>
</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 BIB entry creation events, as individual port values are
mapped into the BIB for specific protocols. Similarly, an address
mapping deletion event will be associated with potentially many BIB
entry 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>Internal realm (MANDATORY);</t>
<t>Generalized internal address (MANDATORY);</t>
<t>External realm (MANDATORY);</t>
<t>External 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>
</section> <!-- addrBind -->
<section anchor="portAssgn" title="Port Set 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 set allocation;</t>
<t>Port set deallocation.</t>
</list>
</t>
<t>The parameters for these events are:
<list style="symbols">
<t>Internal realm (MANDATORY);</t>
<t>Generalized internal address (MANDATORY);</t>
<t>External realm (MANDATORY);</t>
<t>External IP address (MANDATORY);</t>
<t>A set of ports available for transport binding, newly allocated to
or deallocated from the given address mapping. The representation of a
port set is described in the next paragraph (MANDATORY).</t>
<t>Trigger for port set 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>A port set is represented by four parameters. The full set of
parameters describes a sequence of equally-spaced and equally-sized
ranges of consecutive port values. If only a single range is allocated
or deallocated, two of the parameters can be omitted. The four
parameters are:
<list style="symbols">
<t>Starting port number, the lowest port number in the entire port
set (MANDATORY);</t>
<t>Ending port number, the highest port number in the entire port
set (MANDATORY);</t>
<t>Range length, the number of port values in each range (OPTIONAL);</t>
<t>Range step, the difference between the first port number in one
range and the first port number in the immediately preceding range of
the port set (OPTIONAL).</t>
</list>
In the case of a single range, range length SHOULD be omitted
and range step MUST be omitted because it is meaningless.</t>
<t>Examples:
<list style="numbers">
<t>Two ranges, 1024-1535 and 2048-2559 are allocated. Each range
consists of 512 consecutive port numbers. The parameter values to
represent this allocation are:
<list style="symbols">
<t>starting port = 1024</t>
<t>ending port = 2559</t>
<t>range length = 512</t>
<t>range step = 1024.</t>
</list>
</t>
<t>Strictly for purposes of illustration, assume a sequence of 512
even-numbered ports is allocated, beginning at 1024, then 1026, ending
at 2046. The parameter values to represent this allocation are:
<list style="symbols">
<t>starting port = 1024</t>
<t>ending port = 2046</t>
<t>range length = 1</t>
<t>range step = 2.</t>
</list>
</t>
<t>A single range of ports is allocated, running consecutively from
1024 to 2046. The parameter values to represent this allocation
are:
<list style="symbols">
<t>starting port = 1024</t>
<t>ending port = 2046.</t>
</list>
</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="omEvents" title="Events Directed Toward Operations and Maintenance">
<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
<xref target="I-D.behave-NAT-MIB"/> rather than logging these events.
</t>
<t>Address pools are discussed in <xref target="pools"/>. The
natPoolTable object in the NAT MIB <xref target="I-D.behave-NAT-MIB"/>
provides access to parameters describing the utilization level of
address-port combinations within a given pool. Since a new transport
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
wwhen 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 <xref target="RFC4787"/>, 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
<xref target="I-D.behave-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
<xref target="I-D.behave-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 parameter:
<list style="symbols">
<t>Pool identifier, equal to the value of the natPoolIndex object
presented in the natPoolTable in the MIB (MANDATORY).</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>
This event report is most meaningful when the pooling type behaviour is
"paired" <xref target="RFC4787"/>, and is especially
applicable to devices implementing NAT functionality only and not port
translation. Depending on deployment, operators can choose instead to
use the SNMP notification natNotifAddrMappings defined in the NAT MIB
<xref target="I-D.behave-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 parameter provided by this event report is:
<list style="symbols">
<t>Current number of active address mappings, equal to the difference
between the natAddressMappingCreations and natAddressMappingRemovals
counters displayed in the natCounters table in the NAT MIB
(MANDATORY).</t>
</list>
</t>
</section> <!-- addrThresh -->
<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>The parameter for this event is:
<list style="symbols">
<t>Trigger for address mapping creation (MANDATORY):
<list style="symbols">
<t>outgoing packet; </t>
<t>administrative action (e.g., via the Port Control Protocol
<xref target="RFC6887"/>).</t>
</list>
</t>
</list>
</t>
</section> <!-- addrMapLim -->
<section anchor="transThresh" title="Global BIB Entry High-Water-Mark Threshold Event">
<t>One specific event allows monitoring of the total number of
transport mapping entries in the Binding Information Base (BIB):
<list style="symbols">
<t>BIB entry 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
<xref target="I-D.behave-NAT-MIB"/>.</t>
<t>The NAT MIB displays cumulative counts of mappings created in and
removed from the BIB 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 parameter provided by this event report is:
<list style="symbols">
<t>Current number of active mappings, equal to the difference between
the natMappingCreations and natMappingRemovals counters displayed in
the natCounters table in the NAT MIB (MANDATORY).</t>
</list>
</t>
</section> <!-- transThresh -->
<section anchor="transMapLim" title="Global BIB Entry Limit Exceeded">
<t>The global BIB entry limit exceeded event is reported when
a new transport binding (i.e., BIB entry creation) is requested but the
total number of transport bindings 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 parameter for this event is:
<list style="symbols">
<t>Trigger for BIB entry creation (MANDATORY):
<list style="symbols">
<t>incoming packet;</t>
<t>outgoing packet; </t>
<t>administrative action (e.g., via the Port Control Protocol
<xref target="RFC6887"/>).</t>
</list>
</t>
</list>
</t>
</section> <!-- transMapLim -->
<section anchor="subsThresh" title="Subscriber-Specific BIB Entry Threshold Event">
<t>An event is provided to allow monitoring of the total number of BIB
entries per subscriber:
<list style="symbols">
<t>Subscriber-specific BIB entry 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 <xref target="I-D.behave-NAT-MIB"/>.</t>
<t>The NAT MIB displays cumulative counts of BIB entries 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
BIB entry high-water-mark threshold event is reported.</t>
<t>The specific parameters provided by this event report are:
<list style="symbols">
<t>Internal realm of the subscriber (MANDATORY);</t>
<t>Generalized internal address of the subscriber (MANDATORY);</t>
<t>Current number of active BIB entries for this subscriber, equal
to the difference between the natSubscriberMappingCreations and
natSubscriberMappingRemovals counters displayed in the
natSubscribersTable table in the NAT MIB (MANDATORY).</t>
</list>
</t>
</section> <!-- subsThresh -->
<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 parameter for this event is:
<list style="symbols">
<t>Trigger for mapping creation (MANDATORY):
<list style="symbols">
<t>outgoing packet; </t>
<t>administrative action (e.g., via the Port Control Protocol
<xref target="RFC6887"/>).</t>
</list>
</t>
</list>
</t>
</section> <!-- actSubsLim -->
<section anchor="subsMapLim" title="Subscriber-Specific Limit On Number of BIB Entries Exceeded">
<t>The subscriber-specific limit on number of BIB entries exceeded
event is reported when a new BIB entry is requested, but the total
number of BIB entries 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>Internal realm of the subscriber (MANDATORY);</t>
<t>Generalized internal address of the subscriber (MANDATORY);</t>
<t>Trigger for BIB entry creation (MANDATORY):
<list style="symbols">
<t>incoming packet;</t>
<t>outgoing packet; </t>
<t>administrative action (e.g., via the Port Control Protocol
<xref target="RFC6887"/>).</t>
</list>
</t>
</list>
</t>
</section> <!-- subsMapLim -->
<section anchor="quota" title="Quota Exceeded">
<t>A quota exceeded event is reported when the NAT cannot allocate a
new address mapping, transport binding, or session because an
administrative quota has been reached. Quotas may be applied on absolute
quantities or on rates. The specific types of quota capability offered
by a device are implementation dependent, hence the "Quota Exceeded"
event reports only the minimum of information needed to identify and
interpret the quota. Table natQuotaTable in the NAT MIB lists quota
identifiers and corresponding total counts of packets dropped because
of quota violations. This table may be extended to provide
information on the configuration of the particular quota, depending on
the implementation.
</t>
<t>A number of counters within the NAT MIB record the number of packets
dropped due to quota violations:
<list style="symbols">
<t>by individual quota, in the natQuotaDrops counter in the
natQuotaTable;</t>
<t>by protocol, in the natProtocolQuotaDrops counter in the
natProtocolTable;</t>
<t>per subscriber, in counter natSubscriberQuotaDrops in the
natSubscribersTable.</t>
</list>
</t>
<t>In the list of report parameters that follows, the internal realm and
generalized internal address MUST be provided if they are available. If
the trigger for the quota violation is a packet, the contents of the
received packet header and the realm that the packet came from MUST be
reported. If the trigger was an administrative action, the equivalent to
as much of this information as possible SHOULD be reported.
<list style="symbols">
<t>Quota identifier, equal to the value of natQuotaIndex in table
natQuotaTable of the MIB (MANDATORY);</t>
<t>Internal realm (OPTIONAL);</t>
<t>Generalized internal address (OPTIONAL);</t>
<t>Source realm for triggering packet (OPTIONAL);</t>
<t>Source IP address (OPTIONAL);</t>
<t>Source port or ICMP identifier (OPTIONAL);</t>
<t>Destination IP address (OPTIONAL);</t>
<t>Destination port (OPTIONAL);</t>
<t>Protocol (OPTIONAL);</t>
<t>Trigger for quota violation (OPTIONAL)
<list style="symbols">
<t>packet received at the NAT; </t>
<t>administrative action (e.g., via the Port Control Protocol
<xref target="RFC6887"/>).</t>
</list>
</t>
</list>
</t>
<t>In the special case where the quota addresses bulk port allocation,
the parameters listed above MUST be interpreted and populated as
follows, so as to capture the address mapping to which the ports would
have been allocated:
<list style="symbols">
<t>Internal realm and generalized internal address retain their
usual meanings;</t>
<t>Source realm and source IP address present the external realm and
address portion of the address mapping;</t>
<t>port numbers, protocol, and destination address MUST be
omitted.</t>
</list>
</t>
</section> <!-- quota -->
<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 realm is
internal and the generalized internal address is available, it MUST also
be included.
<list style="symbols">
<t>Source realm of the packet (MANDATORY);</t>
<t>Source IP address (MANDATORY);</t>
<t>Destination IP address (MANDATORY);</t>
<t>Generalized internal address of the source (OPTIONAL).</t>
</list>
</t>
</section> <!-- fragLim -->
</section> <!-- omEvents -->
</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="sessEx"/>, 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 BIB entry 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, BIB entries, 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, limit, and quota 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. 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 "NATMTC"
MUST be used for the event types defined in <xref
target="omEventsCode"/>.</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 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>BIB entry creation</c>
<c>NAT</c>
<c>BADD</c>
<c>6 info</c>
<c>nbib</c>
<c>BIB entry deletion</c>
<c>NAT</c>
<c>BDEL</c>
<c>6 info</c>
<c>nbib</c>
<c>Address mapping creation</c>
<c>NAT</c>
<c>AMADD</c>
<c>6 info</c>
<c>namap</c>
<c>Address mapping deletion</c>
<c>NAT</c>
<c>AMDEL</c>
<c>6 info</c>
<c>namap</c>
<c>Port set allocation</c>
<c>NAT</c>
<c>PTADD</c>
<c>6 info</c>
<c>npset</c>
<c>Port set deallocation</c>
<c>NAT</c>
<c>PTDEL</c>
<c>6 info</c>
<c>npset</c>
<c>Address pool high threshold</c>
<c>NATMTC</c>
<c>POOLHT</c>
<c>4 warning</c>
<c>npool</c>
<c>Address pool low threshold</c>
<c>NATMTC</c>
<c>POOLLT</c>
<c>6 info</c>
<c>npool</c>
<c>Global address map high threshold</c>
<c>NATMTC</c>
<c>GAMHT</c>
<c>4 warning</c>
<c>ngamht</c>
<c>Global address map limit</c>
<c>NATMTC</c>
<c>GAMLIM</c>
<c>3 error</c>
<c>ngaml</c>
<c>Global BIB entry high threshold</c>
<c>NATMTC</c>
<c>GBHT</c>
<c>4 warning</c>
<c>ngbht</c>
<c>Global BIB entry limit</c>
<c>NATMTC</c>
<c>GBLIM</c>
<c>3 error</c>
<c>ngbl</c>
<c>Subscriber-specific BIB entry high threshold</c>
<c>NATMTC</c>
<c>SBHT</c>
<c>5 notice</c>
<c>nsbht</c>
<c>Global active subscriber limit</c>
<c>NATMTC</c>
<c>GSLIM</c>
<c>3 error</c>
<c>ngsl</c>
<c>Subscriber-specific BIB entry limit</c>
<c>NATMTC</c>
<c>SBLIM</c>
<c>5 notice</c>
<c>nsbl</c>
<c>Quota exceeded</c>
<c>NATMTC</c>
<c>QUOTA</c>
<c>3-5 depending</c>
<c>nqpkt</c>
<c>Pending fragment limit</c>
<c>NATMTC</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"/>, and the PARAM-NAMES and brief
descriptions are listed in <xref target="tab_params"/>. They are then
described more fully in the same order in succeeding sub-sections.
</t>
<texttable anchor="tab_params" title="Parameters Used In NAT-Related Log Reports, By PARAM-NAME">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<c>GAMCNT</c>
<c>Current global number of address mappings</c>
<c>GBCNT</c>
<c>Current global number of BIB entries</c>
<c>GIATYP</c>
<c>Generalized internal address type</c>
<c>GIAVAL</c>
<c>Generalized internal address/prefix value</c>
<c>IDATYP</c>
<c>Internal destination IP address type</c>
<c>IDAVAL</c>
<c>Internal destination IP address value</c>
<c>IDPNUM</c>
<c>Internal destination port or ICMP identifier value</c>
<c>IRLM</c>
<c>Internal realm</c>
<c>IPNUM</c>
<c>Internal port or ICMP identifier value (in BIB entry)</c>
<c>PDAVAL</c>
<c>Packet destination IP address value</c>
<c>PDPNUM</c>
<c>Packet destination port or ICMP identifier value</c>
<c>POOLID</c>
<c>Address pool identifier</c>
<c>PROTO</c>
<c>Protocol identifier</c>
<c>PSRLM</c>
<c>Packet source realm</c>
<c>PSATYP</c>
<c>Packet source IP address type</c>
<c>PSAVAL</c>
<c>Packet source IP address value</c>
<c>PSPNUM</c>
<c>Packet source port or ICMP identifier value</c>
<c>PTENUM</c>
<c>Port set ending number</c>
<c>PTSNUM</c>
<c>Port set starting number</c>
<c>QID</c>
<c>Quota identifier</c>
<c>RGLEN</c>
<c>Number of port values per range</c>
<c>RGSTEP</c>
<c>Difference between first values of successive port ranges</c>
<c>SBCNT</c>
<c>Current subscriber-specific number of active BIB entries</c>
<c>TRIG</c>
<c>Trigger for event</c>
<c>XATYP</c>
<c>External IP address type (in address mapping etc.)</c>
<c>XAVAL</c>
<c>External IP address value (in address mapping etc.)</c>
<c>XDAVAL</c>
<c>External destination IP address value (in session entry)</c>
<c>XDPNUM</c>
<c>External destination port or ICMP identifier value (in
session entry)</c>
<c>XPNUM</c>
<c>External port or ICMP identifier value (in BIB entry)</c>
<c>XRLM</c>
<c>External realm (in address mapping etc.)</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>
</section> <!-- genEncod -->
<section anchor="encGAMCNT"
title="PARAM-NAME GAMCNT: Current global number of address mappings">
<t>PARAM-VALUE: decimal number presented without leading zeroes. </t>
<t>Used with event types (MSGIDs): GAMHT.</t>
</section> <!-- encGAMCNT -->
<section anchor="encGBCNT"
title="PARAM-NAME GBCNT: Current global number of BIB entries">
<t>PARAM-VALUE: decimal number presented without leading zeroes.</t>
<t>Used with event types (MSGIDs): GBHT.</t>
</section> <!-- encGBCNT -->
<section anchor="encGIATYP"
title="PARAM-NAME GIATYP: Generalized internal address type">
<t>PARAM-VALUE: enumeration giving the type of the generalized
address. Possible values:
<list style="hanging">
<t hangText='"IPv4":'>IPv4 address or prefix;</t>
<t hangText='"IPv6":'>IPv6 address or prefix;</t>
<t hangText='"GRE":'>Gateway-initiated DS-Lite <xref
target="RFC6674"/> Context Identifier (CID) configured as a
GRE key.</t>
<t hangText='"MPLS":'>Gateway-initiated DS-Lite <xref
target="RFC6674"/> Context Identifier (CID) configured as an
MPLS label.</t>
<t hangText='"FL":'>Gateway-initiated DS-Lite <xref
target="RFC6674"/> Context Identifier (CID) configured as an
IPv6 Flow Label.</t>
</list>
</t>
<t>Used with event types (MSGIDs): SADD, SDEL, BADD, BDEL, AMADD,
AMDEL, PTADD, PTDEL, SBHT, SBLIM, QUOTA, FRAG.</t>
</section> <!-- encGIATYP -->
<section anchor="encGIAVAL"
title="PARAM-NAME GIAVAL: Generalized internal address/prefix value">
<t>PARAM-VAL: If the value of GIATYP is "IPv4" or IPv6", the content
of the GIAVAL parameter MUST be presented as an IPv4 or IPv6 address
or prefix respectively as specified in <xref target="genEncod"/>.
For all other types, the address MUST be presented as a decimal
number without leading zeroes.</t>
<t>Used with event types (MSGIDs): SADD, SDEL, BADD, BDEL, AMADD,
AMDEL, PTADD, PTDEL, SBHT, SBLIM, QUOTA, FRAG.</t>
</section> <!-- encGIAVAL -->
<section anchor="encIDATYP"
title="PARAM-NAME IDATYP: Internal destination IP address type">
<t>PARAM-VAL: IP address type. Possible values:
<list style="hanging">
<t hangText='"IPv4":'>IPv4 address;</t>
<t hangText='"IPv6":'>IPv6 address.</t>
</list>
</t>
<t>Used with event types (MSGIDs): SADD, SDEL.</t>
</section> <!-- encIDATYP -->
<section anchor="encIDAVAL"
title="PARAM-NAME IDAVAL: Internal destination IP address value">
<t>PARAM-VAL: IPv4 or IPv6 address, presented as specified in
<xref target="genEncod"/>.</t>
<t>Used with event types (MSGIDs): SADD, SDEL.</t>
</section> <!-- IDAVAL -->
<section anchor="encIDPNUM"
title="PARAM-NAME IDPNUM: Internal destination port or ICMP identifier value">
<t>PARAM-VAL: 16-bit value presented as a decimal number without
leading zeroes.</t>
<t>Used with event types (MSGIDs): SADD, SDEL.</t>
</section> <!-- IDPNUM -->
<section anchor="encIRLM" title="PARAM-NAME IRLM: Internal realm">
<t>PARAM-VAL: administratively-provided string of text.</t>
<t>Used with event types (MSGIDs): SADD, SDEL, BADD, BDEL, AMADD,
AMDEL, PTADD, PTDEL, SBHT, SBLIM, QUOTA.</t>
</section> <!-- encIRLM -->
<section anchor="encIPNUM"
title="PARAM-NAME IPNUM: Internal port or ICMP identifier value (in BIB entry)">
<t>PARAM-VAL: 16-bit value presented as a decimal number without
leading zeroes.</t>
<t>Used with event types (MSGIDs): SADD, SDEL, BADD, BDEL.</t>
</section> <!-- encIPNUM -->
<section anchor="encPDAVAL"
title="PARAM-NAME PDAVAL: Packet destination IP address value">
<t>PARAM-VAL: IPv4 or IPv6 address, presented as specified in
<xref target="genEncod"/>.</t>
<t>Used with event types (MSGIDs): QUOTA, FRAG.</t>
</section> <!-- encPDAVAL -->
<section anchor="encPDPNUM"
title="PARAM-NAME PDPNUM: Packet destination port or ICMP identifier value">
<t>PARAM-VAL: 16-bit value presented as a decimal number without
leading zeroes.</t>
<t>Used with event types (MSGIDs): QUOTA.</t>
</section> <!-- encPDPNUM -->
<section anchor="encPOOLID"
title="PARAM-NAME POOLID: Address pool identifier">
<t>PARAM-VAL: 32-bit value presented as a decimal number without
leading zeroes.</t>
<t>Used with event types (MSGIDs): POOLHT, POOLLT.</t>
</section> <!-- encPOOLID -->
<section anchor="encPROTO"
title="PARAM-NAME PROTO: Protocol identifier">
<t>PARAM-VAL: A transport protocol number, from the "protocol-numbers"
IANA registry, presented as a decimal number between 0 and 255 without
leading zeroes.</t>
<t>Used with event types (MSGIDs): SADD, SDEL, BADD, BDEL, QUOTA.</t>
</section> <!-- encPROTO -->
<section anchor="encPSRLM"
title="PARAM-NAME PSRLM: Packet source realm">
<t>PARAM-VAL: administratively-provided string of text.</t>
<t>Used with event types (MSGIDs): QUOTA, FRAG.</t>
</section> <!-- encPSRLM -->
<section anchor="encPSATYP"
title="PARAM-NAME PSATYP: Packet source IP address type">
<t>PARAM-VAL: IP address type. Possible values:
<list style="hanging">
<t hangText='"IPv4":'>IPv4 address;</t>
<t hangText='"IPv6":'>IPv6 address.</t>
</list>
</t>
<t>Used with event types (MSGIDs): QUOTA, FRAG.</t>
</section> <!-- encPSATYP -->
<section anchor="encPSAVAL"
title="PARAM-NAME PSAVAL: Packet source IP address value">
<t>PARAM-VAL: IPv4 or IPv6 address, presented as specified in
<xref target="genEncod"/>.</t>
<t>Used with event types (MSGIDs): QUOTA, FRAG.</t>
</section> <!-- encPSAVAL -->
<section anchor="encPSPNUM"
title="PARAM-NAME PSPNUM: Packet source port or ICMP identifier value">
<t>PARAM-VAL: 16-bit value presented as a decimal number without
leading zeroes.</t>
<t>Used with event types (MSGIDs): QUOTA.</t>
</section> <!-- encPSPNUM -->
<section anchor="encPTENUM"
title="PARAM-NAME PTENUM: Port set ending number">
<t>PARAM-VAL: 16-bit value presented as a decimal number without
leading zeroes.</t>
<t>Used with event types (MSGIDs): PTADD, PTDEL.</t>
</section> <!-- encPTENUM -->
<section anchor="encPTSNUM"
title="PARAM-NAME PTSNUM: Port set starting number">
<t>PARAM-VAL: 16-bit value presented as a decimal number without
leading zeroes.</t>
<t>Used with event types (MSGIDs): PTADD, PTDEL.</t>
</section> <!-- encPTSNUM -->
<section anchor="encQID"
title="PARAM-NAME QID: Quota identifier">
<t>PARAM-VAL: 32-bit value presented as a decimal number without
leading zeroes.</t>
<t>Used with event types (MSGIDs): QUOTA.</t>
</section> <!-- encQID -->
<section anchor="encRGLEN"
title="PARAM-NAME RGLEN: Number of port values per range">
<t>PARAM-VAL: positive value presented as a decimal
number without leading zeroes.</t>
<t>Used with event types (MSGIDs): PTADD, PTDEL.</t>
</section> <!-- encRGLEN -->
<section anchor="encRGSTEP"
title="PARAM-NAME RGSTEP: Difference between first values of successive port ranges">
<t>PARAM-VAL: up to 16-bit value presented as a decimal
number without leading zeroes.</t>
<t>Used with event types (MSGIDs): PTADD, PTDEL.</t>
</section> <!-- encRGSTEP -->
<section anchor="encSBCNT"
title="PARAM-NAME SBCNT: Current subscriber-specific number of active BIB entries">
<t>PARAM-VAL: value presented as a decimal number without leading
zeroes.</t>
<t>Used with event types (MSGIDs): SBHT.</t>
</section> <!-- encSBCNT -->
<section anchor="encTRIG"
title="PARAM-NAME TRIG: Trigger for event">
<t>PARAM-VAL: enumeration. Possible values:
<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='"BDEL":'>deletion of the underlying BIB entry.</t>
<t hangText='"AMDEL":'>deletion of the underlying address mapping.</t>
<t hangText='"AUTO":'>autonomous action of the NAT.</t>
</list></t>
<t>Used with event types (MSGIDs): SADD, SDEL, BADD, BDEL, AMADD,
AMDEL, PTADD, PTDEL, GAMLIM, GBLIM, GSLIM, SBLIM, QUOTA. Note that no
event type supports all of the values listed above. The set of
supported values is listed for each using event type in <xref
target="evCode"/>.</t>
</section> <!-- encTRIG -->
<section anchor="encXATYP"
title="PARAM-NAME XATYP: External IP address type (in address mapping)">
<t>PARAM-VAL: IP address type. Possible values:
<list style="hanging">
<t hangText='"IPv4":'>IPv4 address;</t>
<t hangText='"IPv6":'>IPv6 address.</t>
</list>
</t>
<t>Used with event types (MSGIDs): SADD, SDEL, BADD, BDEL, AMADD,
AMDEL, PTADD, PTDEL.</t>
</section> <!-- encXATYP -->
<section anchor="encXAVAL"
title="PARAM-NAME XAVAL: External IP address value (in address mapping)">
<t>PARAM-VAL: IPv4 or IPv6 address, presented as specified in
<xref target="genEncod"/>.</t>
<t>Used with event types (MSGIDs): SADD, SDEL, BADD, BDEL, AMADD,
AMDEL, PTADD, PTDEL.</t>
</section> <!-- encXAVAL -->
<section anchor="encXDAVAL"
title="PARAM-NAME XDAVAL: External destination IP address value">
<t>PARAM-VAL: IPv4 or IPv6 address, presented as specified in
<xref target="genEncod"/>. Note that the type of address is given by
XATYP, which will also be present in the event report.</t>
<t>Used with event types (MSGIDs): SADD, SDEL.</t>
</section> <!-- encXDAVAL -->
<section anchor="encXDPNUM"
title="PARAM-NAME XDPNUM: External destination port or ICMP identifier value">
<t>PARAM-VAL: 16-bit value presented as a decimal number without
leading zeroes.</t>
<t>Used with event types (MSGIDs): SADD, SDEL.</t>
</section> <!-- encXDPNUM -->
<section anchor="encXPNUM"
title="PARAM-NAME XPNUM: External port or ICMP identifier value (in BIB entry)">
<t>PARAM-VAL: 16-bit value presented as a decimal number without
leading zeroes.</t>
<t>Used with event types (MSGIDs): SADD, SDEL, BADD, BDEL.</t>
</section> <!-- encXPNUM -->
<section anchor="encXRLM"
title="PARAM-NAME XRLM: External realm (in address mapping)">
<t>PARAM-VAL: administratively-provided string of text.</t>
<t>Used with event types (MSGIDs): SADD, SDEL, BADD, BDEL, AMADD,
AMDEL, PTADD, PTDEL.</t>
</section> <!-- encXRLM -->
</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="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="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>IRLM</c>
<c><xref target="encIRLM"/></c>
<c>MANDATORY</c>
<c>GIATYP</c>
<c><xref target="encGIATYP"/></c>
<c>MANDATORY</c>
<c>GIAVAL</c>
<c><xref target="encGIAVAL"/></c>
<c>MANDATORY</c>
<c>IPNUM</c>
<c><xref target="encIPNUM"/></c>
<c>MANDATORY</c>
<c>XRLM</c>
<c><xref target="encXRLM"/></c>
<c>MANDATORY</c>
<c>XATYP</c>
<c><xref target="encXATYP"/></c>
<c>MANDATORY</c>
<c>XAVAL</c>
<c><xref target="encXAVAL"/></c>
<c>MANDATORY</c>
<c>XPNUM</c>
<c><xref target="encXPNUM"/></c>
<c>MANDATORY</c>
<c>PROTO</c>
<c><xref target="encPROTO"/></c>
<c>MANDATORY</c>
<c>IDATYP</c>
<c><xref target="encIDATYP"/></c>
<c>OPTIONAL</c>
<c>IDAVAL</c>
<c><xref target="encIDAVAL"/></c>
<c>OPTIONAL</c>
<c>IDPNUM</c>
<c><xref target="encIDPNUM"/></c>
<c>OPTIONAL</c>
<c>XDAVAL</c>
<c><xref target="encXDAVAL"/></c>
<c>MANDATORY</c>
<c>XDPNUM</c>
<c><xref target="encXDPNUM"/></c>
<c>MANDATORY</c>
<c>TRIG</c>
<c><xref target="encTRIG"/></c>
<c>OPTIONAL</c>
</texttable>
<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", "BDEL", or "AUTO".</t>
<section anchor="sessEx" title="Example">
<t>This example is for a DS-Lite AFTR, hence the external addresses
will be IPv4, as will the internal destination address. It is
assumed that remapping of the destination address is unnecessary, so
the internal values of that address are omitted. The generalized
internal address is the IPv6 /56 prefix assigned to the site. The
TRIG optional parameter is present. The PRI value at
the beginning of the log assumes a local use Facility value of 17
and Severity value 6. Note that the log could also include other SD-
ELEMENTs (e.g., timeQuality).</t>
<t>The log appears as a single record, but is wrapped between lines
for purposes of presentation.
<list style="empty">
<t><142>1 2013-05-07T22:14:15.03487Z record.example.net NAT 5063
<vspace blankLines="0"/>
SADD [nsess IRLM="MonteCristo-089" GIATYP="IPv6"
<vspace blankLines="0"/>
GIAVAL="2001:db8:a5e6:3900::/56" IPNUM="49178" XRLM="EXTv4"
<vspace blankLines="0"/>
XATYP="IPv4" XAVAL="198.51.100.127" XPNUM="6803"
<vspace blankLines="0"/>
PROTO="6" XDAVAL="192.0.2.57" TRIG="IPKT"]</t>
</list>
Character count: about 260. Adding the internal destination address
type, address value and port would bring this to 300.
</t>
</section> <!-- sessEx -->
</section> <!-- SessCode -->
<section anchor="BIBCode" title="BIB Entry Creation and Deletion">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>NAT BIB entry creation event is indicated by MSGID set to
"BADD";</t>
<t>NAT BIB entry deletion event is indicated by MSGID set to
"BDEL".</t>
</list>
For both events, the associated SD-ELEMENT is tagged by SD-ID "nbib".
The contents of the nbib SD-ELEMENT are shown in <xref
target="tab_nbib"/>. The requirements for these contents are derived
from the description in <xref target="BIBCrDe"/>. The differences from
the nsess SD-ELEMENT are the omission of the XDAVAL (external
destination address) field in all cases and potentially the IDATYP and
IDAVAL (internal destination address type and value) fields if mapping
is required.</t>
<texttable anchor="tab_nbib" title="Contents Of the SD-ELEMENT Section For Logging the BIB Entry Creation and Deletion Events">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>IRLM</c>
<c><xref target="encIRLM"/></c>
<c>MANDATORY</c>
<c>GIATYP</c>
<c><xref target="encGIATYP"/></c>
<c>MANDATORY</c>
<c>GIAVAL</c>
<c><xref target="encGIAVAL"/></c>
<c>MANDATORY</c>
<c>IPNUM</c>
<c><xref target="encIPNUM"/></c>
<c>MANDATORY</c>
<c>XRLM</c>
<c><xref target="encXRLM"/></c>
<c>MANDATORY</c>
<c>XATYP</c>
<c><xref target="encXATYP"/></c>
<c>MANDATORY</c>
<c>XAVAL</c>
<c><xref target="encXAVAL"/></c>
<c>MANDATORY</c>
<c>XPNUM</c>
<c><xref target="encXPNUM"/></c>
<c>MANDATORY</c>
<c>PROTO</c>
<c><xref target="encPROTO"/></c>
<c>MANDATORY</c>
<c>TRIG</c>
<c><xref target="encTRIG"/></c>
<c>OPTIONAL</c>
</texttable>
<t>For the BADD event type (MSGID), TRIG can take on the values
"OPKT", IPKT", or "ADMIN". For the BDEL event type, TRIG can take on
the values "ADMIN", "AMDEL", or "AUTO".</t>
<t>Using the same assumptions as in <xref target="sessEx"/>, the
corresponding BIB entry 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"/>
BADD [nbib IRLM="MonteCristo-089" GIATYP="IPv6"
<vspace blankLines="0"/>
GIAVAL="2001:db8:a5e6:3900::/56" IPNUM="49178" XRLM="EXTv4"
<vspace blankLines="0"/>
XATYP="IPv4" XAVAL="198.51.100.127" XPNUM="6803"
<vspace blankLines="0"/>
PROTO="6" TRIG="IPKT"]</t>
</list>
Character count is about 245.
</t>
</section> <!-- BIBCode -->
<section anchor="ABindCode" title="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"/>. The differences
from the nbib SD-ELEMENT are the omission of the IPNUM, XPNUM, and
PROTO (port number and protocol) fields.</t>
<texttable anchor="tab_namap" title="Contents Of the SD-ELEMENT Section For Logging the Address Mapping Creation and Deletion Events">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>IRLM</c>
<c><xref target="encIRLM"/></c>
<c>MANDATORY</c>
<c>GIATYP</c>
<c><xref target="encGIATYP"/></c>
<c>MANDATORY</c>
<c>GIAVAL</c>
<c><xref target="encGIAVAL"/></c>
<c>MANDATORY</c>
<c>XRLM</c>
<c><xref target="encXRLM"/></c>
<c>MANDATORY</c>
<c>XATYP</c>
<c><xref target="encXATYP"/></c>
<c>MANDATORY</c>
<c>XAVAL</c>
<c><xref target="encXAVAL"/></c>
<c>MANDATORY</c>
<c>TRIG</c>
<c><xref target="encTRIG"/></c>
<c>OPTIONAL</c>
</texttable>
<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>Again using the same assumptions as in <xref target="sessEx"/>,
but assuming the address mapping was created earlier, the
corresponding address mapping entry creation report would look like
this:
<list style="empty">
<t><142>1 2013-05-07T22:14:12.95628Z record.example.net NAT 5063
<vspace blankLines="0"/>
AMADD [namap IRLM="MonteCristo-089" GIATYP="IPv6"
<vspace blankLines="0"/>
GIAVAL="2001:db8:a5e6:3900::/56" XRLM="EXTv4"
<vspace blankLines="0"/>
XATYP="IPv4" XAVAL="198.51.100.127" TRIG="OPKT"]</t>
</list>
Character count is about 215.
</t>
</section> <!-- ABindCode -->
<section anchor="PSetCode" title="Port Set Allocation and Deallocation">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Port set allocation event is indicated by MSGID set to
"PTADD";</t>
<t>Port set deallocation event is indicated by MSGID set to
"PTDEL".</t>
</list>
For both events, the associated SD-ELEMENT is tagged by SD-ID "npset".
The contents of the npset SD-ELEMENT are shown in <xref
target="tab_npset"/>. The requirements for these contents are derived
from the description in <xref target="portAssgn"/>.</t>
<texttable anchor="tab_npset" 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>IRLM</c>
<c><xref target="encIRLM"/></c>
<c>MANDATORY</c>
<c>GIATYP</c>
<c><xref target="encGIATYP"/></c>
<c>MANDATORY</c>
<c>GIAVAL</c>
<c><xref target="encGIAVAL"/></c>
<c>MANDATORY</c>
<c>XRLM</c>
<c><xref target="encXRLM"/></c>
<c>MANDATORY</c>
<c>XATYP</c>
<c><xref target="encXATYP"/></c>
<c>MANDATORY</c>
<c>XAVAL</c>
<c><xref target="encXAVAL"/></c>
<c>MANDATORY</c>
<c>PTENUM</c>
<c><xref target="encPTENUM"/></c>
<c>MANDATORY</c>
<c>PTSNUM</c>
<c><xref target="encPTSNUM"/></c>
<c>MANDATORY</c>
<c>RGLEN</c>
<c><xref target="encRGLEN"/></c>
<c>OPTIONAL</c>
<c>RGSTEP</c>
<c><xref target="encRGSTEP"/></c>
<c>OPTIONAL</c>
<c>TRIG</c>
<c><xref target="encTRIG"/></c>
<c>OPTIONAL</c>
</texttable>
<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 the first example in <xref target="portAssgn"/>, where two
ranges, 1024-1535 and 2048-2559 are allocated to the address mapping
on which the example in <xref target="ABindCode"/> is based. The
corresponding port set allocation report would look like this:
<list style="empty">
<t><142>1 2013-08-15T09:14:38.12229Z record.example.net NAT 5063
<vspace blankLines="0"/>
PTADD [npset IRLM="MonteCristo-089"
<vspace blankLines="0"/>
GIATYP="IPv6" GIAVAL="2001:db8:a5e6:3900::/56" XRLM="EXTv4"
<vspace blankLines="0"/>
XATYP="IPv4" XAVAL="198.51.100.127" PTSNUM="1024" PTENUM="2559"
RGLEN="512" RGSTEP="1024" TRIG="IPKT"]</t>
</list>
Character count is about 260.
</t>
</section> <!-- PSetCode -->
</section> <!-- resAllocCode -->
<section anchor="omEventsCode" title="Events Directed Toward Operations and Maintenance">
<t>As indicated in <xref target="hdrFMT"/>, the event reports
specified in this section MUST have APP-NAME="NATMTC" in the SYSLOG
message header.</t>
<section anchor="PoolTCode" title="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>POOLID</c>
<c><xref target="encPOOLID"/></c>
<c>MANDATORY</c>
</texttable>
<t>Example, assuming a local-use Facility value of 16 and a Severity
level of 4 (warning) to calculate the PRI value at the beginning:
<list style="empty">
<t><132>1 2013-08-15T09:15:16.08716Z record.example.net NATMTC 5025
<vspace blankLines="0"/>
POOLHT [npool POOLID="13"]</t>
</list>
Character count is about 90.</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>GAMCNT</c>
<c><xref target="encGAMCNT"/></c>
<c>MANDATORY</c>
</texttable>
<t>Example, assuming a local-use Facility value of 16 and a Severity
level of 4 (warning) to calculate the PRI value at the beginning.
Suppose the threshold was set to 690000, so it has already been
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 NATMTC 5025
<vspace blankLines="0"/>
GAMHT [ngamht GAMCNT="690015"]</t>
</list>
Character count is about 90.</t>
</section> <!-- GAMHTCode -->
<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>TRIG</c>
<c><xref target="encTRIG"/></c>
<c>MANDATORY</c>
</texttable>
<t>For the global address map limit exceeded event, TRIG can take on
the values "OPKT" or "ADMIN".</t>
<t>Example, assuming a local-use Facility value of 16 and a Severity
level of 3 (error) to calculate the PRI value at the beginning.
<list style="empty">
<t><131>1 2013-08-15T09:15:16.08716Z record.example.net NATMTC 5025
<vspace blankLines="0"/>
GAMLIM [ngaml TRIG="OPKT"]</t>
</list>
Character count is about 90.</t>
</section> <!-- GAMLIMCode -->
<section anchor="GBHTCode" title="Global BIB Entry High-Water-Mark Threshold Event">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Global BIB entry high-water-mark threshold event is indicated by
MSGID set to "GBHT"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "ngbht".</t>
</list>
The contents of the ngbht SD-ELEMENT are shown in <xref
target="tab_ngbht"/>. The requirements for these contents are derived
from the description in <xref target="transThresh"/>.</t>
<texttable anchor="tab_ngbht" title="Contents Of the SD-ELEMENT Section For Logging the Global BIB Entry High-Water-Mark Threshold Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>GBCNT</c>
<c><xref target="encGBCNT"/></c>
<c>MANDATORY</c>
</texttable>
<t>Example, assuming a local-use Facility value of 16 and a Severity
level of 4 (warning) to calculate the PRI value at the beginning.
Suppose the threshold was set to 2000000, so it has already been
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 NATMTC 5025
<vspace blankLines="0"/>
GBHT [ngbht GBCNT="2000023"]</t>
</list>
Character count is about 90.</t>
</section> <!-- GBHTCode -->
<section anchor="GBLIMCode" title="Global BIB Entry Limit Exceeded">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Global BIB entry limit exceeded event is indicated by
MSGID set to "GBLIM"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "ngbl".</t>
</list>
The contents of the ngbl SD-ELEMENT are shown in <xref
target="tab_ngbl"/>. The requirements for these contents are derived
from the description in <xref target="transMapLim"/>.</t>
<texttable anchor="tab_ngbl" title="Contents Of the SD-ELEMENT Section For Logging the Global BIB Entry Limit Exceeded Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>TRIG</c>
<c><xref target="encTRIG"/></c>
<c>MANDATORY</c>
</texttable>
<t>For the global BIB entry limit exceeded event, TRIG can take on
the values "OPKT", "IPKT", or "ADMIN".</t>
<t>Example, assuming a local-use Facility value of 16 and a Severity
level of 3 (error) to calculate the PRI value at the beginning.
<list style="empty">
<t><131>1 2013-08-15T09:15:16.08Z record.example.net NATMTC 5025
<vspace blankLines="0"/>
GBLIM [ngbl TRIG="OPKT"]</t>
</list>
Character count is about 90.</t>
</section> <!-- GBLIMCode -->
<section anchor="SBHTCode"
title="Subscriber-Specific BIB Entry High-Water-Mark Threshold Event">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t> Subscriber-specific BIB entry high-water-mark threshold event is
indicated by MSGID set to "SBHT"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "nsbht".</t>
</list>
The contents of the nsbht SD-ELEMENT are shown in <xref
target="tab_nsbht"/>. The requirements for these contents are derived
from the description in <xref target="subsThresh"/>.</t>
<texttable anchor="tab_nsbht" title="Contents Of the SD-ELEMENT Section For Logging the Subscriber-Specific BIB Entry High-Water-Mark Threshold Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>IRLM</c>
<c><xref target="encIRLM"/></c>
<c>MANDATORY</c>
<c>GIATYP</c>
<c><xref target="encGIATYP"/></c>
<c>MANDATORY</c>
<c>GIAVAL</c>
<c><xref target="encGIAVAL"/></c>
<c>MANDATORY</c>
<c>SBCNT</c>
<c><xref target="encSBCNT"/></c>
<c>MANDATORY</c>
</texttable>
<t>Example, assuming a local-use Facility value of 16 and a Severity
level of 5 (notice) to calculate the PRI value at the beginning.
Suppose the threshold was set to 1500 and the number of BIB entries
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 NATMTC 5025
<vspace blankLines="0"/>
SBHT [nsbht SBCNT="1501" IRLM="MonteCristo-089"
<vspace blankLines="0"/>
GIATYP="IPv6" GIAVAL="2001:db8:a5e6:3900::/56"]</t>
</list>
Character count is about 155.</t>
</section> <!-- SBHTCode -->
<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>TRIG</c>
<c><xref target="encTRIG"/></c>
<c>MANDATORY</c>
</texttable>
<t>For the global active host limit exceeded event, TRIG can take on
the values "OPKT" or "ADMIN".</t>
<t>Example, assuming a local-use Facility value of 16 and a Severity
level of 3 (error) to calculate the PRI value at the beginning.
<list style="empty">
<t><131>1 2013-08-15T09:15:16.08421Z record.example.net NATMTC 5025
<vspace blankLines="0"/>
GSLIM [ngsl TRIG="OPKT"]</t>
</list>
Character count is about 85.</t>
</section> <!-- GSLIMCode -->
<section anchor="SBLIMCode" title="Subscriber-Specific Limit On Number of BIB Entries Exceeded">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Subscriber-specific BIB entry limit exceeded event is indicated by
MSGID set to "SBLIM"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "nsbl".</t>
</list>
The contents of the nsbl SD-ELEMENT are shown in <xref
target="tab_nsbl"/>. The requirements for these contents are derived
from the description in <xref target="subsMapLim"/>.</t>
<texttable anchor="tab_nsbl" title="Contents Of the SD-ELEMENT Section For Logging the Subscriber-Specific BIB Entry Limit Exceeded Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>IRLM</c>
<c><xref target="encIRLM"/></c>
<c>MANDATORY</c>
<c>GIATYP</c>
<c><xref target="encGIATYP"/></c>
<c>MANDATORY</c>
<c>GIAVAL</c>
<c><xref target="encGIAVAL"/></c>
<c>MANDATORY</c>
<c>TRIG</c>
<c><xref target="encTRIG"/></c>
<c>MANDATORY</c>
</texttable>
<t>For the subscriber-specific BIB entry limit exceeded event, TRIG
can take on the values "OPKT", "IPKT", or "ADMIN".</t>
<t>Example, assuming a local-use Facility value of 16 and a Severity
level of 4 (warning) to calculate the PRI value at the beginning.
<list style="empty">
<t><132>1 2013-08-15T09:15:16.08528Z record.example.net NATMTC 5025
<vspace blankLines="0"/>
SBLIM [nsbl IRLM="MonteCristo-089"
<vspace blankLines="0"/>
GIATYP="IPv6" GIAVAL="2001:db8:a5e6:3900::/56" TRIG="OPKT"]</t>
</list>
Character count is about 160.</t>
</section> <!-- SBLIMCode -->
<section anchor="QUOTACode" title="Quota Exceeded">
<t>As shown in <xref target="tab_events"/>:
<list style="symbols">
<t>Quota exceeded event is indicated by
MSGID set to "QUOTA"; and</t>
<t> the associated SD-ELEMENT is tagged by SD-ID "nqpkt".</t>
</list>
The contents of the nqpkt SD-ELEMENT are shown in <xref
target="tab_nqpkt"/>. The requirements for these contents are derived
from the description in <xref target="quota"/>.</t>
<texttable anchor="tab_nqpkt" title="Contents Of the SD-ELEMENT Section For Logging the Quota Exceeded Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>QID</c>
<c><xref target="encQID"/></c>
<c>MANDATORY</c>
<c>IRLM</c>
<c><xref target="encIRLM"/></c>
<c>OPTIONAL</c>
<c>GIATYP</c>
<c><xref target="encGIATYP"/></c>
<c>OPTIONAL</c>
<c>GIAVAL</c>
<c><xref target="encGIAVAL"/></c>
<c>OPTIONAL</c>
<c>PSRLM</c>
<c><xref target="encPSRLM"/></c>
<c>OPTIONAL</c>
<c>PSATYP</c>
<c><xref target="encPSATYP"/></c>
<c>OPTIONAL</c>
<c>PSAVAL</c>
<c><xref target="encPSAVAL"/></c>
<c>OPTIONAL</c>
<c>PSPNUM</c>
<c><xref target="encPSPNUM"/></c>
<c>OPTIONAL</c>
<c>PDAVAL</c>
<c><xref target="encPSAVAL"/></c>
<c>OPTIONAL</c>
<c>PDPNUM</c>
<c><xref target="encPSPNUM"/></c>
<c>OPTIONAL</c>
<c>PROTO</c>
<c><xref target="encPROTO"/></c>
<c>OPTIONAL</c>
<c>TRIG</c>
<c><xref target="encTRIG"/></c>
<c>OPTIONAL</c>
</texttable>
<t>For the quota exceeded event, TRIG can take on the values "OPKT",
"IPKT", or "ADMIN".</t>
<t>First example, assuming a local-use Facility value of 16 and a Severity
level of 4 (warning) to calculate the PRI value at the beginning. The
quota was triggered by the arrival of a UDP/IPv4 packet from the
exterior. An address mapping already exists, so that the generalized
internal address corresponding to the packet destination is known and
must be presented.
<list style="empty">
<t><132>1 2013-08-15T09:15:16.08Z record.example.net NATMTC 5025
<vspace blankLines="0"/>
QUOTA [nqpkt QID="21" IRLM="MonteCristo-089"
<vspace blankLines="0"/>
GIATYP="IPv6" GIAVAL="2001:db8:a5e6:3900::/56" PROTO="17"
<vspace blankLines="0"/>
PSRLM="EXTv4" PSATYP="IPv4" PSAVAL="203.0.113.26" PSPNUM="9803"
<vspace blankLines="0"/>
PDAVAL="198.51.100.127" PDPNUM="49853" TRIG="IPKT"]</t>
</list>
Character count is about 280.</t>
<t>Second example, assuming a local-use Facility value of 16 and a
Severity level of 5 (notice) to calculate the PRI value at the
beginning. The quota was triggered by a PCP request based on <xref
target="I-D.pcp-port-set"/> to allocate more ports to an existing
address mapping. Since the address mapping already exists, the
generalized internal address corresponding to the request is known and
must be presented.
<list style="empty">
<t><133>1 2013-08-15T09:15:16.08Z record.example.net NATMTC 5025
<vspace blankLines="0"/>
QUOTA [nqpkt QID="48" IRLM="MonteCristo-089"
<vspace blankLines="0"/>
GIATYP="IPv6" GIAVAL="2001:db8:a5e6:3900::/56"
<vspace blankLines="0"/>
PSRLM="EXTv4" PSATYP="IPv4" PSAVAL="198.51.100.127" TRIG="ADMIN"]</t>
</list>
Character count is about 220.</t>
</section> <!-- QUOTACode -->
<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>PSRLM</c>
<c><xref target="encPSRLM"/></c>
<c>MANDATORY</c>
<c>PSATYP</c>
<c><xref target="encPSATYP"/></c>
<c>MANDATORY</c>
<c>PSAVAL</c>
<c><xref target="encPSAVAL"/></c>
<c>MANDATORY</c>
<c>PDAVAL</c>
<c><xref target="encPDAVAL"/></c>
<c>MANDATORY</c>
<c>GIATYP</c>
<c><xref target="encGIATYP"/></c>
<c>OPTIONAL</c>
<c>GIAVAL</c>
<c><xref target="encGIAVAL"/></c>
<c>OPTIONAL</c>
</texttable>
<t>Example, assuming a local-use Facility value of 16 and a Severity
level of 4 (warning) to calculate the PRI value at the beginning. 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 NATMTC 5025
<vspace blankLines="0"/>
FRAG [nfpkt PSRLM="MonteCristo-089"
<vspace blankLines="0"/>
PSATYP="IPv4" PSAVAL="192.0.0.1" PDAVAL="203.0.113.26"
<vspace blankLines="0"/>
GIATYP="IPv6" GIAVAL="2001:db8:a5e6:3900::/56"]</t>
</list>
Character count is about 200.</t>
</section> <!-- FRAGCode -->
</section> <!-- omEventsCode -->
</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="NATMTC", MSGID="POOLHT") is
obviously more urgent than the low-water-mark threshold event
(APP-NAME="NATMTC", 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="NATMTC"). 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 Suppress Event Reports">
<t>The event report types specified with APP-NAME="NATMTC" all relate to
limits or thresholds. By their nature, events of this sort will come
in bursts. The limit or threshold 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 when to suppress individual event report types, all
implementations MUST allow the operator to indicate through
configuration that a given event report type is to be completely
suppressed (i.e., disabled). This is particularly required to disable
destination logging when that is not required (see <xref
target="destLog"/>). It is also required when the operator prefers to
receive particular event notifications via SNMP rather than SYSLOG.
</t>
<t>The ability to suppress 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
suppressed messages 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 "NATMTC" 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. [Ed. note -- if we can get
experience or simulation results we may be able to add ballpark figures.]
</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> <!-- 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="omEvents"/> and <xref
target="omEventsCode"/> are less sensitive, but the subscriber-specific
threshold and limit events reveal internal realm and generalized internal
address information which might be of interest to outside attackers. The
quota event and the fragmentation limit event also provide 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="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>
<texttable anchor="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>nsess</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>IPNUM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XPNUM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PROTO</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>IDATYP</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IDAVAL</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IDPNUM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>XDAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XDPNUM</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>nbib</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>IPNUM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XPNUM</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>namap</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XAVAL</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>npset</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>XAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PTSNUM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PTSNUM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>RGLEN</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>RGSTEP</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>npool</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>POOLID</c>
<c>MANDATORY</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>GAMCNT</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>TRIG</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>ngbht</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>GBCNT</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>ngbl</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>TRIG</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>nsbht</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>SBCNT</c>
<c>MANDATORY</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>TRIG</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>nsbl</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>IRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>TRIG</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>nqpkt</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>QID</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>IRLM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>GIATYP</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>GIAVAL</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PSRLM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PSATYP</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PSAVAL</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PSPNUM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PDAVAL</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PDPNUM</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PROTO</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>nfpkt</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PSRLM</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PSATYP</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PSAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PDAVAL</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>GIATYP</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>GIAVAL</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
</texttable>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2663;
&RFC2685;
&RFC5424;
&RFC5425;
&RFC5848;
&RFC5952;
&RFC6145;
&RFC6146;
&RFC2119;
<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>
</references>
<references title="Informative References">
&RFC3022;
&RFC4787;
&RFC5101;
&RFC5382;
&RFC5969;
&RFC6264;
&RFC6333;
&RFC6674;
&RFC6887;
&RFC6888;
<reference anchor="I-D.behave-ipfix-nat-logging">
<front>
<title>IPFIX Information Elements for logging NAT Events (Work in progress) </title>
<author initials="S." surname="Sivakumar" fullname="S. Sivakumar">
<organization>Cisco Systems</organization>
</author>
<author initials="R." surname="Penno" fullname="R. Penno">
<organization>Cisco Systems</organization>
</author>
<date month="August" year="2013"/>
</front>
</reference>
<reference anchor="I-D.softwire-public-4over6">
<front>
<title>Public IPv4 over IPv6 Access Network (Work in progress)</title>
<author initials="Y." surname="Cui" fullname="Y. Cui">
<organization>Tsinghua University</organization>
</author>
<author initials="J." surname="Wu" fullname="J. Wu">
<organization>Tsinghua University</organization>
</author>
<author initials="P." surname="Wu" fullname="P. Wu">
<organization>Tsinghua University</organization>
</author>
<author initials="O." surname="Vautrin" fullname="O. Vautrin">
<organization>Juniper Networks</organization>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee">
<organization>Comcast</organization>
</author>
<date month="July" 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.softwire-unified-cpe">
<front>
<title>Unified IPv4-in-IPv6 Softwire CPE (Work in progress)</title>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="I." surname="Farrer" fullname="I. Farrer">
<organization>Deutsche Telekom</organization>
</author>
<date month="May" 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>
<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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:52 |